Часть II. Технологии быстрого тестирования и советы. нить, что код является невыполняемым и поэтому не может быть протестирован

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

Проектирование случаев использования и прогнозирование частоты использова­ ния каждого из них позволяет определить приоритеты тестовых случаев. Чтобы можно было оптимизировать ресурсы и эффективность тестирования, эти приори­ теты должны быть положены в основу разработки тестовых случаев и порядка их прогона.

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

Псевдоотладка/видоизменение

Псевдоотладка (bebugging), являющаяся одной из форм видоизменения программы, —это способ определения эффективности стратегий тестирования, применяемых в проекте. Прежде чем приступать к псевдоотладке, необходимо заручиться поддерж­ кой и тестировщиков, и разработчиков. Как бы вы ответили на вопрос, часто зада­ ваемый руководителем разработки: " Когда можно ожидать выявления большинства ошибок в этой версии? ". Обычно руководитель тестирования задает встречный во­ прос: " А сколько мелких ошибок нам нужно найти? " Основным показателем прогрес­ са тестирования должно быть процентное отношение числа найденных ошибок к числу скрытых ошибок, которые нужно найти. Проблема, связанная с вычислением упомянутого показателя, состоит в том, что и числитель, и знаменатель этого отно­ шения неизвестны.

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

Организации, в которых применяется быстрое тестирование, находят, что псев­ доотладка может ускорить проведение тестирования благодаря определению условий его прекращения. Фактически, процесс преднамеренного внесения ошибок требует творческого подхода. Если искусственно созданные ошибки распределяются по ти­ пам в соответствии с исторически сложившейся моделью ошибок аналогичных раз­ работок, с использованием того же языка программирования, и если обнаруженные ошибки таким же образом распределены по типам, то анализ прогресса тестирования можно выполнить по типам. В этом случае можно не только со всей определенностью ответить на вопрос: " Когда можно ожидать выявления большинства ошибок в этой версии? ", но и сказать: " Мы нашли большинство логических ошибок в программе, а теперь заняты разработкой дополнительных тестовых случаев для проверки надеж­ ности модулей обработки ошибок". Аналогично, все искусственно созданные ошибки могут быть распределены по уровням серьезности. И тогда, если обнаруженные ошибки также распределить по уровням серьезности, можно не только ответить на заданный вопрос, но и сказать: " Мы нашли большинство ошибок с уровнями серьез­ ности 1 и 3, а сейчас разрабатываем дополнительные тестовые случаи для обнаруже­ ния ошибок с уровнями серьезности 2 и 4".

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

Трассировка/трассировка снизу вверх/ мгновенные дампы/постпечать

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