![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Часть II. Технологии быстрого тестирования и советы. нить, что код является невыполняемым и поэтому не может быть протестирован
нить, что код является невыполняемым и поэтому не может быть протестирован. Или, скажем, в принципе новый код является выполняемым, но выполняется только при удовлетворении какого-то маловразумительного условия. Какое бессмысленное рас ходование времени и ресурсов с нулевой эффективностью, поскольку ни одна ошибка не обнаруживается!
Проектирование случаев использования и прогнозирование частоты использова ния каждого из них позволяет определить приоритеты тестовых случаев. Чтобы можно было оптимизировать ресурсы и эффективность тестирования, эти приори теты должны быть положены в основу разработки тестовых случаев и порядка их прогона.
Прежде чем применить к тестированию подход, основанный на случаях использо вания, тестировщики и разработчики должны обеспечить гарантированное соответ ствие случаев использования списку требований и коду. Несоответствие документа ции по требованиям и кода — это недостаток, который часто отмечается во время аудита многих проектов по созданию программного обеспечения. В некоторых орга низациях документации по программе уделяется не такое пристальное внимание, как документации для пользователя. Иногда случаи использования, разработанные на основе исходных требований, передаются группе тестирования без проверки на со ответствие текущим требованиям. Однако за это время исходные требования могли претерпеть изменения. В таких ситуациях тестировщики, используя информацию о случаях использования, могут получить ложное обнаружение ошибок. В ходе даль нейших исследований выяснится, что код удовлетворяет списку требований, но не случаям использования. Вероятность наличия ошибок в тестовом случае и результа тах будет высокой, а усилия, потраченные на разработку тестового случая, окажутся напрасными.
Псевдоотладка/видоизменение
Псевдоотладка (bebugging), являющаяся одной из форм видоизменения программы, —это способ определения эффективности стратегий тестирования, применяемых в проекте. Прежде чем приступать к псевдоотладке, необходимо заручиться поддерж кой и тестировщиков, и разработчиков. Как бы вы ответили на вопрос, часто зада ваемый руководителем разработки: " Когда можно ожидать выявления большинства ошибок в этой версии? ". Обычно руководитель тестирования задает встречный во прос: " А сколько мелких ошибок нам нужно найти? " Основным показателем прогрес са тестирования должно быть процентное отношение числа найденных ошибок к числу скрытых ошибок, которые нужно найти. Проблема, связанная с вычислением упомянутого показателя, состоит в том, что и числитель, и знаменатель этого отно шения неизвестны.
Псевдоотладка заключается в преднамеренном внесении ошибок в программу. Да лее полученная версия тестируется, и после этого определяется эффективность тес тирования путем сравнения обнаруженных и искусственно созданных ошибок. От ношение числа обнаруженных искусственно созданных ошибок к числу созданных ошибок должно быть равно отношению числа найденных ошибок к числу скрытых ошибок в продукте. Этот метод позволяет оценить показатель прогресса тестирова ния, определенный чуть выше.
Организации, в которых применяется быстрое тестирование, находят, что псев доотладка может ускорить проведение тестирования благодаря определению условий его прекращения. Фактически, процесс преднамеренного внесения ошибок требует творческого подхода. Если искусственно созданные ошибки распределяются по ти пам в соответствии с исторически сложившейся моделью ошибок аналогичных раз работок, с использованием того же языка программирования, и если обнаруженные ошибки таким же образом распределены по типам, то анализ прогресса тестирования можно выполнить по типам. В этом случае можно не только со всей определенностью ответить на вопрос: " Когда можно ожидать выявления большинства ошибок в этой версии? ", но и сказать: " Мы нашли большинство логических ошибок в программе, а теперь заняты разработкой дополнительных тестовых случаев для проверки надеж ности модулей обработки ошибок". Аналогично, все искусственно созданные ошибки могут быть распределены по уровням серьезности. И тогда, если обнаруженные ошибки также распределить по уровням серьезности, можно не только ответить на заданный вопрос, но и сказать: " Мы нашли большинство ошибок с уровнями серьез ности 1 и 3, а сейчас разрабатываем дополнительные тестовые случаи для обнаруже ния ошибок с уровнями серьезности 2 и 4".
Аналогичные подходы к видоизменению программы могут использоваться в от ношении ошибок, которые не связаны с исходным кодом, в том числе неправильных данных в базе данных, некачественных коммуникационных линий, поврежденных данных, неправильных данных, вводимых пользователем, ненадежных интерфейсов между процессами и т.п. Видоизменение программы представляет собой эффектив ное средство, которое может использоваться разрабатывающей организацией, кото рая повторно использует код из другого проекта. Частью процесса повторного ис пользования исходного кода является его сопровождение. Псевдоотладка может применяться для проверки хода этого сопровождения, определяя конечные цели тес тирования, которые будут использоваться при разработке новых тестовых случаев.
Трассировка/трассировка снизу вверх/ мгновенные дампы/постпечать
Специалисты по тестированию могут воспользоваться рядом инструментальных средств, которые существуют и применяются в современных разработках. Четырьмя из этих средств являются трассировка, трассировка снизу вверх, мгновенные дампы и постпечать. Опытные программисты, помнящие времена больших компьютеров, мо гут решить, что этот раздел посвящен выводу на печать или чтению системной диаг ностической информации, в том числе шестнадцатеричных системных дампов и со общений редактора связей, для определения природы, места и исходного уровня причины системной ошибки. На самом деле это не так. Несмотря на сходные терми ны, мы определяем технологии, исходя из современных спецификаций и средств. Например, в программу, основанную на применении транзакций, проектировщики часто включают функцию трассировки транзакций, которая может избирательно включаться любым пользователем, выбирающим эту опцию в своей конфигурации. Эта опция создает файл трассировки с отображением входных и выходных данных транзакции и форматированные мгновенные дампы данных запроса. Естественно, испытатель должен тестировать систему без включения этой опции, поскольку для
|