Control-Flow Based Testing (тестирование управляющей логики программы):
Ход 1: строим граф, обрисовывающий логику, реализованную в коде
Ход 2: создаем тест-кейсы для покрытия всех узлов графа, ребер графа (ветки, пути)
Statement coverage(покрытие операторов = Line coverage)
- любой оператор должен быть выполнен хотя бы один раз
§ не сильный критерий – нужное, но недостаточное условие
«-» затруднен анализ покрытия некоторых управляющих структур (не проверяется условные операторы при значении false, достаточно проверить лишь для значения true, дабы выполнить оператор)
не сильный критерий – в большинстве случаев не применяют
Пример:
If (a0)
c:=25;
— один тест для критерия statement coverage для a0
— пропускает диагностику того, что будет, в случае, если a
Вranch\Decision coverage (ветки операторов)
- каждое ответ должно принять значения ложь и истина по крайней мере один раз и для каждой точки входа должно быть выдано управление хотя бы один раз (IF, CASE, Loop)
§ Более сильный критерий, чем покрытие операторов
- «-» не учитываются условия с вызовами функций в условных операторов
§ Нужный минимум
- Определяем комплект дорог start-to-end, каковые покрывают все ветки графа и пишем для них тесты
Циклы (loops)
Несложный цикл
• Пропустить цикл
• Пройти один раз
• Пройти два раза
• В случае, если мах=n, тогда проходим n-1, n и n+1 раз
Положенный цикл
• Устанавливаем счетчик в min для наружных (внешних) циклов и контролируем внутренние
• Тестируем значения, выходящие за границы
• Все внешние циклы в min
• Пока не протестируем все циклы
Condition coverage (покрытие условий)
- Все вероятные результаты каждого решения в условии выполнялись хотя бы один раз (любая компонента логического условия в следствии исполнения тестовых примеров обязана принимать все вероятные значения) и каждой точке входа в программу либо подпрограмму должно быть передано управление хотя бы один раз
- Более сильный критерий, чем покрытие ответов
Data-Flow testing (тестирование потоков данных)
- Разбираем все переменные в коде: их определение (“definitions”\”write”) и применение (“uses”\”read”)
Определяем все DU пары (Def-Use pairs) и пишем тесты, покрывающие все DU пары для всех переменных:
Приложение 1
Конфигурационное управление – построение «билдов».(http://window.edu.ru/window_catalog/pdf2txt?p_id=31136p_page=4) Разглядим проект по разработке ПО. Что в нем есть аналогом материальных активов на простом производстве? Определенно, не стулья и столы, которыми пользуются разработчики. А также не компьютеры, запчасти к ним и другое оборудование. контроля и Учёта, сродни складскому, требуют файлыпроекта. В программном проекте их довольно много – тысячи и сотни кроме того для довольно маленьких проектов. Так как создать новый файл весьма легко. Многие технологии программирования поддерживают стиль, в то время, когда, к примеру, для каждого класса создается собственный отдельный файл. Файл – это виртуальная информационная единица. В чем основное отличие файла от материальных единиц учета? В том, что у файла возможно версия, и не одна, и породить эти версии весьма легко – достаточно скопировать этот файл в второе место на диске. Тогда как материальные предметы существуют на складе сами по себе, и для них нет понятия версии. Да, возможно пара однотипных предметов, различных заготовок изделия разной степени готовности. Но все это не то….. А версия файла – это весьма не несложный объект. Чем одна версия отличается от второй? Несколькими строками текста или полностью обновленным содержанием? И какая из двух и более предположений основнее, лучше? К этому добавляется еще да и то, что многие рабочие продукты смогут складываться из комплекта файлов, и любой из них может иметь по паре предположений. Как собрать корректную версию продукта? В итоге в программном проекте начинают происходить мистические и таинственные события. Шепетильно протестированная программа на показательных опробованиях не работает. Функциональность, о которой продолжительно просил клиент и которая была, наконец, добавлена в продукт, а новая версия празднично отослана клиенту, загадочным образом провалилась сквозь землю из продукта.На компьютере разработчика программа трудится, а у клиента – нет…. Разгадка несложна – все дело в предположениях файлов. В том месте, где все отлично, присутствуют файлы одной версии, а в том месте, где все не хорошо – второй. Но беда в том, что «версия всего продукта» – это абстрактное понятие. На деле имеется версии отдельных файлов. Один либо пара файлов в поставке продукта имеют не ту версию – все, дело не хорошо. Необходимоуправлять предположениями файлов, в противном случае подобная мистика может стать огромной проблемой. Она без шуток тормозит внутреннюю работу. То тестеры и разработчики трудятся с различными предположениями совокупности, то итоговая сборка совокупности требует особых напряжения упрочнений всего коллектива. Более того, вероятны неприятности на уровне управления. Разные курьезные обстановки, в то время, когда заявленная функциональность отсутствует либо не работает (снова не те файлы отправили!), смогут очень сильно портитьотношения с клиентом. Обиженный клиент может настойчиво попросить кроме того финансовой компенсации за то, что появляющиеся неточности через чур по долгу исправляются. А будет тут не продолжительно, в то время, когда разработчики не смогут воспроизвести и исправить неточность, поскольку немогут определить, из каких же исходных текстов была собрана эта версия! Итак, делается ясно, что в программных проектах нужна особая деятельность по поддержанию файловых активов проекта в порядке. Она и именуется конфигурационным управлением. Выделим две главные задачи в конфигурационном управлении – управление предположениями и управление сборками. Первое несёт ответственность за управление предположениями файлов и выполняется в проекте на базе особых программных достаточно – средств версионного контроля. Существует много таких средств – Микрософт Visual SourceSafe, IBM ClearCase, cvn, subversion и др. Управление сборками – это автоматизированный процесс изменения исходных текстов ПО в пакет исполняемых модулей, учитывающий бессчётные настройки проекта, настройки компиляции, и интегрируемый с процессом автоматического тестирования. Эта процедура есть замечательным средством интеграции проекта, базой итеративной разработки. Единицы конфигурационного управления Так чем же мы управляем в рамках данной деятельности? Любыми ли файлами, каковые имеются в проекте? Нет, не любыми, а лишь теми, каковые изменяются. К примеру, файлы с применяемым в проекте покупным ПО должны покоиться на CD-дисках либо в локальной сети. Книги, документы с внешними стандартами, применяемыми в проекте (к примеру, в телекоммуникациях довольно много различных стандартов на сетевые интерфейсы) и пр. кроме этого должны в том месте, где любой желающий их может забрать. В большинстве случаев, таковой информации в проекте мало, но, очевидно, она должна быть в порядке. Но для этого особый вид деятельности в проекте не нужен. Итак, конфигурационное управление имеет дело с изменяющимися в ходе продуктами, складывающимися из комплектов файлов. Такие продукты принято именовать единицами конфигурационного управления (configuration management items). Вот примеры: 1. пользовательская документация; 2. проектная документация; 3. исходные тексты ПО; 4. пакеты тестов; 5. инсталляционные пакеты ПО; 6. тестовые отчеты. У каждой единицы конфигурационного управления должно быть следующее. 1. Структура – комплект файлов. К примеру, пользовательская документация в html обязана включать индекс-набор и файл html-файлов, и комплект вынесенных картин (gif либо jpeg-файлы). Эта структура должна быть отлично выяснена и отслеживаться при конфигурационном управлении – что все файлы не утрачены и присутствуют, имеют однообразную версию, корректные ссылки друг на друга и т.д. 2. Важное лицо и, быть может, группу тех, кто их разрабатывает, и более широкую и менее важную группу тех, кто пользуется данной информацией. К примеру, определенной программной компонентой смогут в проекте пользоваться многие разработчики, но нести ответственность за ее разработку, исправление неточностей и пр. обязан кто-то один. 3. Практика конфигурационного управления – кто и в каком режиме, а также в какое место выкладывает новую версию элемента конфигурационного управления в средство управления предположениями, комментирования элемента и правила именования в данной версии, предстоящие манипуляции с ним в том месте и пр. Более высокоуровневые правила, связанные, к примеру, с правилами тестовых пакетов и изменения тестов при трансформации кода. Но, где-то тут лежит водораздел между иными видами и конфигурационным управлением деятельности в проекте 4. Автоматическая процедура контроля целостности элемента – к примеру, сборка для исходных текстов программ. Имеется не у всех элементов, к примеру, может не быть у документации, тестовых пакетов. Элементы конфигурационного управления смогут образовывать иерархию. Управление предположениями Управление предположениями файлов. Потому, что программисты имеют дело с огромным числом файлов, многие файлы одновременно смогут быть нужны нескольким людям и принципиально важно, дабы все они всегда составляли единую, как минимум, компилирующуюся версию продукта, нужно, дабы была налажена работа с файлами с исходным кодом. Кроме этого возможно налажена работа и с другими типами файлов. В данной ситуации файлы выясняются самыми младшими (по иерархии включения) элементами конфигурационного управления. Управление предположениями составных конфигурационных объектов. Понятие «ветки» проекта. В один момент существует пара предположений совокупности – и в смысле для различных клиентов и пр. (так сообщить, в громадном, настоящем смысле), и в смысле одного проекта, одного клиента, но как различный комплект исходных текстов. И в том и в другом случае в средстве управления предположениями образуются различные ветки. Остановимся чуть подробнее на втором случае. Любая ветка содержит полный образ исходного кода и других артефактов, находящихся в совокупности контроля предположений. Любая ветвь может развиваться независимо, быть может в определенных точках интегрироваться с другими ветвями. В ходе интеграции трансформации, произведенные в одной из ветвей, полуавтоматически переносятся в другую. Как пример возможно разглядеть следующую структуру разделения проекта на ветки. • V1.0 – ветвь, соответствующая выпущенному релизу. Внесение трансформаций в такие ветви запрещены и они хранят образ кода совокупности на момент выпуска релиза. • Fix V1.0.1 – ветвь, соответствующая выпущенному пакету исправлений к определенной версии. Подобные ветви ответвляются от исходной версии, а не от главной ветви и замораживаются сразу после выхода пакета исправлений. • Upcoming (V1.1) – ветвь, соответствующая релизу, подготавливающемуся к выпуску и находящемуся в стадии стабилизации. Для таких ветвей, в большинстве случаев, действуют более работа и строгие правила в них ведется более формально. • Mainline – ветвь, соответствующая главному направлению развития проекта. По мере созревания конкретно от данной ветви отходят ветви подготавливающихся релизов. • WCF Experiment – ветвь, созданная для проверки некоего технического ответа, перехода на новую разработку, либо внесения громадного пакета трансформаций, возможно нарушающих работоспособность кода на долгое время. Такие ветви, в большинстве случаев, делаются дешёвыми лишь для определенного круга разработчиков и убиваются по окончанию работ по окончании интеграции сосновной веткой. Управление сборками Итак, отчего же создания и процедура компиляции exe dll файлов по исходникам проекта – такая ответственная процедура? В силу того, что она многократно в сутки выполняется каждым разработчиком на его собственном компьютере, с его собственной версией проекта. Наряду с этим отличается: — комплект подпроектов, собираемых разработчиком; — он может собирать отнюдь не весь проект, а лишь какую-то его часть; — вторая часть или им не употребляется вовсе, или не пересобирается весьма в далеком прошлом, а по факту она в далеком прошлом изменилась; — отличаются параметры компиляции. Наряду с этим если не собирать систематично итоговую версию проекта, то неспециализированная интеграция может распознать довольно много различных неприятностей: — несоответствие друг другу разных частей проекта; — наличие своеобразных неточностей, появившихся по причине того, что отдельные проекты разрабатывались не учитывая параметров компиляции (в частности, переход в Visual Studio c debug на release версию довольно часто сопровождается возникновением бессчётных неприятностей). Поэтому процедуру сборки проекта довольно часто автоматизируют, другими словами делают не из среды разработки, а из особого скирпта – build-скрипта. Данный скрипт употребляется тогда, в то время, когда разработчику требуется полная сборка всего проекта. И он употребляется в процедуре постоянной интеграции (continues integration) – другими словами регулярной сборке всего проекта (в большинстве случаев – каждую ночь). В большинстве случаев, процедура постоянной интеграции включает в себя и регрессионное тестирование, и довольно часто – создание инсталляционных пакетов. Неспециализированная схема автоматизированной сборки: Забрать исходники из средства контроля предположениями — применяя настройки по умолчанию сборки позвать компилятор — прогон регрессионных тестов — в случае, если тесты прошли, то рассылаем отчет Тестировщики должны тестировать по возможности итоговую и целостную версию продукта, так что результаты регулярной сборки выясняются пользуются большим спросом. Помимо этого, наличие базисной, актуальной, целостной версии продукта разрешает организовать разработку в итеративно-инкрементальном стиле, другими словами на базе внесения трансформаций. Таковой стиль разработки именуется baseline-способ. Baseline – это базисная, последняя целостная версия некоего продукта разработки, к примеру, документации, кода программы и т.д. Подразумевается, что разработка идет не целым потоком, а с фиксацией промежуточных результатов в виде текущей официальной версии разрабатываемого актива. Принятие таковой версии сопровождается дополнительными действиями по оформлению, сглаживанию, тестированию, включению лишь законченных фрагментов и т.д. Это итог возможно взглянуть, дать тестеровщикам, передать клиенту и т.д. Baseline помогает хорошимсредством синхронизации групповой работы. Baseline возможно совсем несложной – веткой в средстве управления предположениями, где разработчики хранят текущую версию собственных исходных кодов. Единственным требованием в этом случае возможно только неспециализированная компилируемость проекта. Но помощь baseline возможно сложной формальной процедурой. Baseline может кроме этого поддерживаться постоянной интеграцией. Принципиально важно, что Baseline (особенно при в программными активами) не должна устанавливаться через чур рано. Сперва необходимо написать какое-то количество кода, дабы было что интегрировать. Помимо этого, сначала довольно много внимания уделяется разработке главных архитектурных ответов, и целостная версия оказывается не востребованной. Но начиная с какого-либо момента она просто нужна. Какой данный момент – решать участникам команды. Наконец, существую проекты, где автоматическая сборка не нужна вовсе – это простые проекты, разрабатываемые маленьким числом участников, где нет громадного количество исходных текстов программ, проектов, сложных параметров
Приложение 2
Рациональный унифицированный процесс (Rational Unified Process — RUP), Лилия Хаф
Рациональный унифицированный процесс (Rational Unified Process, RUP) — одна из спиральных методик разработки ПО. Методика поддерживается компанией Rational Software, обновление продукта происходит приблизительно каждые полгода. В качестве языка моделирования в общей базе знаний употребляется язык Unified Modelling Language (UML).
Итерационная разработка ПО в RUP предполагает разделение проекта на пара небольших проектов, каковые выполняются последовательно, и любая итерация разработки четко выяснена комплектом целей, каковые должны быть достигнуты в конце итерации. Конечная итерация предполагает, что комплект целей итерации обязан в точности совпадать с комплектом целей, указанных клиентом продукта, другими словами все требования должны выполняться.
RUP достаточно отлично формализован, и громаднейшее внимание уделяется начальным стадиям разработки проекта — моделированию и анализу. Так, эта методика направлена на понижение коммерческих рисков (risk mitigating) при помощи обнаружения неточностей на ранних стадиях разработки. Технические риски (assesses) оцениваются и «расставляются» в соответствии с приоритетам на ранних стадиях цикла разработки, а после этого пересматриваются с течением времени и с развитием проекта в течение последующих итераций. Новые цели появляются в зависимости от приоритетов данных рисков. Релизы предположений распределяются так, что самые приоритетные риски устраняются первыми.
Процесс предполагает эволюционирование моделей; итерация цикла разработки конкретно соответствует определенной версии модели ПО. Любая из итераций (workflow) содержит элементы управления жизненным циклом ПО: дизайн и анализ (моделирование), реализация, интегрирование, тестирование, внедрение. В этом смысле RUP есть реализацией спиральной модели, не смотря на то, что частенько изображается в виде графика-таблицы. Ниже мы приведем главные компоненты процесса.
Для успешного процесса разработки нужны три составляющие (Рис. 15):
— процесс (process),
— нотация (notation)
— комплект утилит (tools).
Процесс обрисовывает, что мы делаем, в каком порядке и как именно.
Нотация есть средством коммуникации.
Комплект утилит автоматизирует и руководит процессом.
Рис. 17. Треугольник успеха
В RUP представлены все три компонента. Сперва разглядим функции нотации, каковые создают следующие действия:
• осуществляет «склеивание» процесса в единое целое;
• есть языковым средством принятия ответов, каковые не очевидны из исходного кода;
• предоставляет семантику для отображения серьёзных стратегических и тактических ответов;
• предлагает форму, достаточную чтобы думать, а позже принимать средства и решения автоматизации процесса чтобы манипулировать формализованными данными.
Практически нотация охватывает разработку ПО, начиная с анализа и заканчивая внедрением продукта. Нотация при RUP–UML — формальное языковое средство описания процесса (об UML обращение отправится ниже). Потом разглядим структуру процесса, и приведем комплект утилит, применяемых в ходе управления разработкой проекта в соответствии с RUP.
Структура RUP
RUP предоставляет структурированный подход к итерационной разработке ПО, подразделяя процесс на четыре главные фазы во времени (milestones): Inception (изучение, начало), Elaboration (уточнение замысла), Construction (конструирование, построение) и Transition (переход, развертывание). К сожалению, в русском языке нет установившейся терминологии, исходя из этого в будущем мы будем применять британские термины, сопровождая их переводом на русский язык. На рис. 2 представлено обширно распространенное изображение фаз RUP. Целями каждой из данных фаз являются:
• Inception — познание, что мы создаем. Фаза анализа требований и сбора информации, определение образа проекта в целом;
• Elaboration — познание, как мы это создаем. проектирования анализа системы и Фаза требований, планирование нужных ресурсов и действий, спецификация особенностей и функций дизайна;
• Construction — создание бета-версии продукта. кодирования и Основная фаза разработки, построение продукта как восходящей последовательности итераций (предположений кода);
• Transition — создание конечной версии продукта. Фаза внедрения продукта, поставка продукта конкретному пользователю.
Рис. 18. Фазы RUP
Это фазы управления эволюцией продукта — итерациями жизненного цикла. RUP предполагает приближение к конечной цели, но, в отличие от хорошего стандарта ISO (методика «водопад»), где transition есть конечной фазой, любая из фаз может повторяться пара раз, отражая изменение требований клиента продукта.
Методика RUP основана на девяти главных потоках (семь дней), являющихся элементами итерации жизненного цикла ПО:
• Business modeling (бизнес-анализ) — предполагает анализ требований на данной итерации жизненного цикла, определение желаемых нужд пользователей и параметров системы;
• Requirements (требования) — формализация образа совокупности. Предполагает управление и сбор требований требованиями, перевод требований в функциональные спецификации. Тут начинается построение и анализ прецедентов use cases (пользовательских историй) — формальное отображение требований пользователя в UML. Результатом являются документы уровня менеджмента;
• Analysis and design (моделирование и анализ) — предполагает перевод собранных требований в формализованную программную модель. Результатом есть описание совокупности на фазе реализации (технический проект) — это документы уровня разработчиков совокупности. Язык формализации — Unified Modelling Language (UML), о котором обращение отправится ниже. В ходе итеративной разработки эволюционировать будет продукт конкретно этого потока — модель проекта.
Все трансформации привязываются в RUP конкретно к моделям, а средства автоматизации и достаточно эластичный язык моделирования разрешают руководить данным процессом более либо менее безболезненно в плане затрат времени и ресурсов. Тут имеется в виду тот факт, что результатом разработки есть не модель, а исполняемый код. Исходя из этого клиент в большинстве случаев не весьма обожает платить за моделирование, поскольку модели не являются продуктом, что ему нужен;
• Implementation (реализация, кодирование) — предполагает фактически написание кода. Элементы кода в RUP уже созданы на этапе дизайна и анализа, поскольку средство реализации UML — Rational Rose — разрешает создавать элементы кода на нескольких языках программирования. Методика — объектно-ориентированное программирование;
• Test (тестирование) — предполагает тестирование продукта на данной итерации. Стоит намерено подчернуть, что regression testing (возвратное тестирование, тестирование «неухудшения» продукта) в этом случае должно содержать все актуальные тесты от прошлой итерации и приемосдаточные тесты от прошлой transition-фазы;
• Deployment (внедрение) — предполагает установку продукта на полигоне клиента, подготовку персонала, запуск совокупности плюс приемо-сдаточные опробования, распространения стандартов продукта и подготовка упаковки, передача материалов отделу продаж (действия опциональны в зависимости от специфики продукта).
Вышеприведенные элементы не являются новыми в плане жизненного цикла разработки ПО, потому, что имеют место фактически в любой методологии — быть может, за исключением XP (где они, однако, представлены в очень уникальном виде).
Изюминкой реализации RUP являются временные выговоры, то есть — на каких итерациях будут господствовать те либо иные потоки, и наличие набора и универсального языка утилит, разрешающего обрисовывать процесс разработки.
Как мы видим на рис. 2, на начальных этапах эволюции продукта главное внимание уделяется формализации проекта (анализ, моделирование), что направлено на сокращение коммерческих рисков и понижение цены неточностей дизайна. В то время, когда картина более либо менее ясна, начинаются фактически разработка, тестирование и, наконец, внедрение продукта.
Preliminary interna — это практически документы, производимые техническим советом для менеджеров предприятия. Главная цель начальных этапов — заключение договора либо соглашения о намерениях. Предстоящие итерации — фактически начало работы коллектива разработчиков, что имеет ресурсы и время для построения формальных моделей.
UML в этом случае имеет средства, разрешающие отображать модель на элементы кода. К примеру, дерево объектов отображается конкретно, вариации зависят от мощности реализации выбранного разработчиками языка программирования, и от совпадения взоров Г.Буча и разработчиков данного языка на объектную модель. То же самое относится к способам.
Разглядим элементы, касающиеся помощи продукта — core supporting workflows:
• Configuration management (управление изменениями и конфигурацией) — замечательный слой административных действий, направленных на управление предположениями продукта, что предполагает контроль исходного кода (модели, исполняемых модулей, тестов, документации), контроль предположений продукта, корпоративные стандарты разработки документации и кода, отслеживание ошибок и изменений (bug tracking); тесно связан с поддержкой и тестированием пользователей (customers support);
• Management (управление проектом) — предполагает комплект административных действий управления проектом в соответствии с идеологии RUP, употребляются средства управления проектом (см. ниже перечень продуктов Rational);
• Environment (окружение) — предполагает создание и помощь средств анализа, проектирования, разработки, тестирования (как программное, так и аппаратное обеспечение).
В RUP рекомендовано направляться шести практикам, разрешающим удачно разрабатывать проект:
• итеративная разработка;
• управление требованиями;
• применение модульных архитектур;
• визуальное моделирование;
• проверка качества;
• отслеживание трансформаций.
Практики не являются конкретно частью процесса RUP, но настоятельно рекомендованы к применению. Часть практик прямо вытекает из идеологии RUP. Так, итеративная разработка заложена в структуру RUP, потому, что данный процесс есть одной из реализаций «спирали». Управление требованиями в RUP появляется на самых ранних стадиях анализа.
Теоретически модульная архитектура разрешает повторно применять код, и совокупность получается более эластичной. Потому что UML есть объектным языком, проигнорировать модульность возможно, но… пара затруднительно.
Визуальное моделирование разрешает действенно бороться с возрастающей сложностью совокупностей. Помимо этого, модели являются средствами коммуникации между разработчиками, но для этого разработчики должны сказать на UML, что предполагает определенный тренинг.
Визуальное моделирование довольно часто осуществляется посредством инструмента Rational Rose, что разрешает приобретать комплект очень нужных документов для менеджеров, системных администраторов, разработчиков, тестировщиков, конечно генерировать элементы кода. Данное средство не есть единственной реализацией UML — дешёвы как коммерческие альтернативы (к примеру, Микрософт Visio), так и некоммерческие. направляться подчернуть, что диалекты UML, реализованные в средствах моделирования, не всегда совпадают: диалект Rational имеет кое-какие важные различия, обрисованные как в документации, так и в книгах по UML.