Д. А. Градусов а. В. Шутов теоретические вопросы разработки программного обеспечения учебное пособие

89 
тщательность 
тестирования, 
используя 
измерения 
покрытия 
структуры программы.
Покрытие – это часть структуры программы, которая была 
охвачена тестированием, выраженная в процентах. Если покрытие не 
равно 100%, то необходимо разрабатывать дополнительные тесты для 
покрытия пропущенных участков программы. Методики покрытия 
описаны в главе 4.
На всех уровнях тестирования, особенно в компонентном и 
компонентном интеграционном тестировании, могут использоваться 
инструментальные средства для измерения покрытия кода. 
Структурное тестирование может основываться на архитектуре 
системы, такой как иерархия вызовов. 
Методы структурного тестирования могут быть применены на 
системном, системном интеграционном и приемочном уровнях 
(например, применены к бизнес-моделям или структурам меню).
Тестирование изменений: подтверждающее и регрессионное 
тестирование 
После того, как дефект обнаружен и исправлен, программу 
необходимо перепроверить, чтобы убедиться, что исходный дефект 
успешно устранен. Это называется подтверждением. Отладка 
(локализация и исправление дефекта) относится к процессу 
разработки, а не тестирования.
Регрессионное тестирование – это повторное тестирование уже 
протестированных программ после внесения в них изменений, чтобы 
обнаружить дефекты, внесенные или пропущенные в результате этих 
действий. Эти дефекты могут быть как в проверяемом компоненте, 
так и в связанном или несвязанным с ним. Регрессионное 
тестирование выполняется, когда в программное обеспечение или его 
окружение 
вносятся 
изменения. 
Глубина 
регрессионного 
тестирования оценивается риском пропуска дефектов в программном 
обеспечении, которое работало ранее.

90 
Тесты должны быть повторяемыми, если они должны 
использоваться 
для 
подтверждающего 
или 
регрессионного 
тестирования.
Регрессионное тестирование может выполняться на всех 
уровнях 
тестирования 
и 
включает 
функциональное, 
нефункциональное и структурное тестирование. Регрессионные 
наборы тестов запускаются множество раз и меняются медленно, 
поэтому регрессионное тестирование является хорошим кандидатом 
на автоматизацию. 
4.5
Организация и независимость тестирования 
Эффективность поиска дефектов и рецензирования может быть 
повышена с помощью независимых тестировщиков, Варианты 
независимости могут быть следующими:
•
отсутствие 
независимых 
тестировщиков: 
разработчики 
тестируют собственный код;
•
независимые тестировщики в команде разработчиков;
•
независимая команда или группа тестирования в организации, 
отчитывающаяся 
менеджеру 
проекта 
или 
исполнительному 
менеджеру;
•
независимые тестировщики из бизнес-организации или 
сообщества пользователей;
•
независимые специалисты тестирования для отдельных типов 
тестирования, например, тестировщики удобства использования, 
тестировщики безопасности или тестировщики сертификации 
(которые сертифицируют ПО на соответствие стандартам и 
правилам);
•
независимые тестировщики, привлеченные на аутсорсинг или 
сторонние по отношению к организации.

91 

для больших, сложных или критичных с точки зрения 
безопасности проектов обычно лучше иметь несколько уровней 
тестирования, при этом некоторые или все уровни выполняются 
независимыми 
тестировщиками. 
Разработчики 
также 
могут 
участвовать в тестировании, особенно на низких уровнях, но 
недостаток объективности зачастую ограничивает их эффективность. 
Независимые тестировщики могут иметь право определять правила и 
процессы тестирования, но принимать роли в процессах должны 
только после недвусмысленного разрешения на это.
Преимущества независимого тестирования:
•
независимые тестировщики беспристрастны, видят другие, 
отличные дефекты;
•
независимые тестировщики могут проверять предположения, 
сделанные во время создания спецификаций и разработки системы.
Недостатки независимого тестирования:
•
изолированность от команды разработчиков (в случае полной 
независимости тестировщиков);
•
разработчики теряют чувство ответственности за качество; 

независимые тестировщики могут быть узким местом, их могут 
обвинить в задержке выпуска продукта.
Задачи тестирования могут выполняться людьми в специальной 
тестовой роли или кем-то в другой роли, например, менеджером 
проекта, менеджером по качеству, разработчиком, экспертом в 
бизнесе или предметной области, инфраструктуре или ИТ. 
4.6
Мониторинг тестирования и контроль тестирования 
Мониторинг прогресса тестирования 
Целью мониторинга тестирования является предоставление 
результата 
и 
обзора 
процесса 
тестирования. 
Информация 
отслеживается вручную или автоматически и может быть 

92 
использована для измерения критериев выхода, таких как покрытие. 
Метрики также могут быть использованы для оценки прогресса 
тестирования по сравнению с запланированным расписанием и 
бюджетом.
Обычные тестовые метрики включают в себя:
• процент проделанной работы по подготовке тестовых 
сценариев (или процентное соотношение запланированных и 
подготовленных сценариев);
• процент проделанной работы по подготовке тестового 
окружения;
• выполнение тестовых сценариев (например, количество 
выполненных\невыполненных 
тестовых 
сценариев, 
успешно 
пройденных\неудачных тестовых сценариев);
• информация о дефектах (например, плотность дефектов, 
количество найденных и исправленных дефектов, интенсивность 
отказов и результаты повторного тестирования);
• тестовое покрытие требований, рисков или кода;
• субъективная уверенность тестировщиков в продукте;
• даты контрольных точек тестирования;
• стоимость тестирования, включая стоимость по сравнению с 
выгодой нахождения следующего дефекта или запуска следующего 
теста.
Отчетность по тестированию 
Отчеты о тестировании предоставляют итоговую информацию о 
тестировании, включая:
• что произошло во время цикла тестирования, например, даты, 
когда были достигнуты критерии выхода;
• проанализированную информацию и метрики для поддержки 
рекомендаций и решений о последующих действиях, таких как оценка 
оставшихся дефектов, экономическое обоснование продолжения 

93 
тестирования, оставшиеся риски и уровень уверенности в 
тестируемом ПО.
Структура отчета о результатах тестирования приводится в 
«Стандарте по тестовой Документации для Программного 
Обеспечения» (IEEE Std 829-1998). 
Метрики, которые необходимо собрать во время и в конце 
уровня тестирования:
• соответствие целей тестирования уровню тестирования;
• адекватность выбора подхода к тестированию;
• эффективность тестирования в отношении установленных 
целей.
Контроль тестирования 
Контроль тестирования описывает любые направляющие или 
корректирующие действия, принятые как результат по полученной и 
собранной информации и значениям метрик. Контроль тестирования 
может затрагивать любые действия по тестированию, а также 
воздействовать на другие действия и задачи жизненного цикла ПО.
Примеры действий по контролю тестирования:
• принятие решений на основании данных мониторинга 
тестирования;
• повторная расстановка приоритетов при возникновении 
установленного риска (например, задержка выпуска ПО);
• изменение графика тестирования согласно доступности 
тестового окружения; 

установка 
критерия 
входа, 
требующего 
повторного 
(подтверждающего) 
тестирования 
исправлений, 
сделанных 
разработчиком, перед принятием их в сборку. 

94 

жүктеу/скачать 2,75 Mb.

Достарыңызбен бөлісу: