Тестирование ПО

Тестирование может показать лишь наличие ошибок, но не их отсутствие.

Эдсгеру Дейкстре

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

Для выявления ошибок в программах, ЖЦ разработки ПО предусматривает процесс тестирования, который является достаточно трудоемким и занимает больше времени, чем кодирование. (Г. Майерс дает оценку 1/3 для тестирования, при том, что кодирование занимает примерно 1/6 [6]). Тестируемое ПО обычно называют SUT – Software Under Test. Цель тестирования – не убедиться в безошибочной работоспособности программы, а наоборот – найти ошибки. Поэтому в первую очередь, возникает вопрос – а что есть ошибка в программе?

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

При рассмотрении вопросов анализа программного кода порой удобнее применять еще одну, не рассмотренную в разделе 1, модель жизненного цикла. Её часто называют V-образной из-за расположения блоков на рисунке (См. Рис.7).

Рисунок 7. V-образная модель жизненного цикла разработки ПО

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

На первом этапе путем тестирования производится модульная верификация (MV), при которой поведение исполняемого программного кода проверяется на соответствие его DDD — описанию. Это наиболее трудоемкая и скрупулезная часть исследования. Она часто требует написания драйверов - моделей модулей, вызывающих процедуры тестируемого модуля, и заглушек — моделей процедур других модулей, вызываемых из тестируемого. Часто в MV отдельно выделяют процесс тестирования межмодульных связей, описанных в DDD.

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

При этом следует исходить из предположения, что ошибки всегда есть. Тестирование можно считать успешным если найдены ошибки, а не наоборот. В достаточно сложном ПО все ошибки могут не обнаруживаться даже после длительного тестирования, однако чем более тщательно ведется тестирование, тем меньше ошибок остается и тем менее вероятно возникновение не выявленных ошибок [6].

Дата добавления: 2014-12-26