Организация процесса тестирования ПО

Следуя общей логике итеративности, превалирующей во всех современных моделях разработки ПО, жизненный цикл тестирования также представляется замкнутой последовательностью фаз (этапов), схематично показанной на рис. 1.

 

 

Рис. 1 Жизненный цикл тестирования ПО

Длина каждой итерации этого цикла может варьироваться в широчайшем диапазоне – от единиц часов до десятков месяцев. Как правило, если речь идет о длительном промежутке времени, он разбивается на множество относительно коротких итераций, но сам при этом «тяготеет» к той или иной стадии в каждый момент времени (например, в начале проекта больше планирования, в конце – больше отчетности).

На первой фазе осуществляется планирование, в ходе которого определяется:

– кто будет тестировать и на каких этапах (разработчики продукта, независимая группа тестировщиков или совместно);

–какие компоненты системы будут тестироваться (будут ли подвергнуты тестированию все компоненты программного продукта или только некоторые, например те, которые угрожают наибольшими потерями для всего проекта);

–когда надо тестировать (будет ли это непрерывный процесс, выполняемый в специальных контрольных точках, или процесс, выполняемый на завершающей стадии разработки);

–как надо тестировать (будет ли тестирование сосредоточено только на проверке того, что ПО должно выполнять, или также на том, каким образом оно реализовано; какие аспекты работы ПО будут выбраны для проверки);

–в каком объеме тестировать (каким образом определить, в достаточном ли объеме выполнено тестирование; как распределить ограниченные ресурсы, выделенные под тестирование).

На фазе планирования осуществляются: создание графика (расписания) разработки тест-кейсов для каждой тестируемой подсистемы; оценка необходимых человеческих, программных и аппаратных ресурсов; разработка расписания проведения тест-кейсов.

На этой фазе формулируются или уточняются метрики и признаки возможности или необходимости начала последующих фаз тестирования, приостановки, возобновления и завершения тестирования.

На второй фазе создается множество тест-кейсов путем ручной разработки или автоматической генерации в некоторой среде тестирования. На этой стадии также возможны уточнение, доработка или переработка тест-кейсов, полученных на предыдущих итерациях жизненного цикла тестирования ПО.

В литературе для термина «тест-кейс» («test case») приведено множество синонимов [1-4]: тест, тестовый вариант, тестовый случай, тестовая ситуация, тестовый пример.

Каждый тест-кейс состоит из следующих составляющих:

– набор входных (тестовых) данных;

– сценарий выполнения;

– набор ожидаемых выходных данных (результатов работы программы).

Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса.

В качестве примера рассмотрены возможные тест-кейсы для программы решения квадратных уравнений  (таблица 1).

Таблица 1 Примеры тест-кейсов для программы решения квадратных уравнений.

№ тест-кейса	Входные данные	Сценарий выполнения	Ожидаемые выходные данные
1		1) Ввести значения , ,  в соответствующие поля. 2) Нажать кнопку «Вычислить».
2
3			Нет действительных решений

 

 

Из тест-кейсов формируются тестовые наборы, которые организованы в определенном порядке, отражающем свойства тест-кейсов.

Хорошим считается тест-кейс, который обладает большой вероятностью обнаружения еще не раскрытой ошибки.

Цель проектирования тест-кейсов – систематическое обнаружение различных классов ошибок при минимальных затратах времени и стоимости.

Основная проблема тестирования – нахождение множества тест-кейсов, достаточного для истинности вывода о правильности реализации ПО.

Полную проверку программы гарантирует исчерпывающее тестирование. Оно требует проверить все наборы исходных данных, все варианты их обработки и включает большое количество тест-кейсов. Однако, исчерпывающее тестирование во многих случаях осуществить не реально, поскольку срабатывают ресурсные ограничения (например, по времени).

Задача о выборе конечного набора тест-кейсов для проверки программы в общем случае неразрешима. Поэтому на практике остается искать частные случаи ее решения.

На третьей фазе осуществляются фактически параллельно два взаимосвязанных действия: выполнение тест-кейсов, разработанных на предыдущей фазе, и фиксация найденных дефектов.

В ходе выполнения (прогона) каждого тест-кейса осуществляется сеанс работы системы, в рамках которого на вход системы подаются наборы данных и фиксируются результаты их обработки, затем сравниваемые с ожидаемыми результатами. Если фактический результат отличается от ожидаемого, значит, обнаружен дефект (факт расхождения с требованиями), который фиксируется сразу после обнаружения. В итоге формируется протокол результатов выполнения тест-кейсов.

В качестве примера в таблице 2 рассмотрены фактические результаты работы программы решения квадратного уравнения после выполнения тест-кейсов из таблицы 1.

Таблица 2 Пример сравнения фактических и ожидаемых результатов.

№ тест-кейса	Входные данные	Ожидаемые выходные данные	Фактические результаты
1
2			– не совпадает с ожидаемыми результатами (обнаружен дефект)
3		Нет действительных решений	Нет действительных решений

Успешным (или удачным) называют тест-кейс, который обнаруживает до сих пор не раскрытую ошибку.

Часто после выполнения всех тест-кейсов и написания всех отчетов о найденных дефектах проводится явно выделенная стадия уточнения, на которой все отчеты о дефектах рассматриваются повторно с целью формирования единого понимания проблемы и уточнения таких характеристик дефекта, как важность и срочность.

На четвертой фазе осуществляются фактически параллельно два взаимосвязанных действия: а нализ результатоввыполнения тест-кейсов и формирование отчетности.

Выводы, получаемые в ходе анализа результатов выполнения тест-кейсов, напрямую зависят от результатов, полученных на фазе планирования. На основе этих выводов формируется отчетность. Выводы, полученные на четвертой фазе, могут служить основой для первой фазы следующей итерации тестирования.

На стадии анализа, в частности, определяется, выполнилось ли успешно достаточное количество тест-кейсов в соответствии с выбранным критерием тестирования, и, соответственно, может ли программный продукт считаться готовым к эксплуатации.

Если тест-кейсы не обнаруживают ошибок, появляется сомнение в том, что тест-кейсы достаточно продуманы и что в ПО нет скрытых ошибок. Такие ошибки будут, в конечном итоге, обнаруживаться пользователями и корректироваться разработчиком на этапе сопровождения (когда стоимость исправления возрастает во много раз по сравнению с этапом разработки).

Результаты, накопленные в ходе тестирования, могут оцениваться формальным способом на основе моделей надежности ПО, выполняющих прогноз надежности по реальным данным об интенсивности ошибок.

При разработке систем повышенной надежности, например, авиационных, гарантии надежности достигаются с помощью четкой организации процесса тестирования, определения его связи с остальными процессами жизненного цикла, введения количественных характеристик, позволяющих оценивать успешность тестирования. При этом, чем выше требования к надежности системы (ее уровень критичности), тем более жесткие требования предъявляются. Качество системы при таком подходе является следствием организованного процесса разработки, а не самостоятельным неуправляемым результатом.

⇐ Предыдущая12

Поделиться:

Воспользуйтесь поиском по сайту: