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

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

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

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

Другим свойством модульного проектирования является то, что модули организу­ ются в иерархию. Иерархия есть результат разбиения системы на компоненты, и она позволяет в каждый конкретный момент времени работать с одним уровнем системы. Это обстоятельство отражается на архитектуре тестов, которая может включать в себя несколько тестовых наборов, ориентированных на проверку высокоуровневых функциональных свойств системы, а также тестовые наборы или тестовых случаи, служащих для проверки детализированных функциональных свойств системы. На­ пример, может быть один тестовый набор, предназначенный для проверки GUI-интерфейса, и еще один тест для проверки средств обеспечения безопасности систе­ мы. В состав тестового набора могут быть включены, с одной стороны, тесты, кото­ рые работают с экранами ввода специфических данных или с экранами для опреде­ ления запросов. Тестовый набор отображается на одно конкретное требование или на некоторый набор логически связанных требований, в то время как более детали­ зированные тестовые случаи отображаются на элементы функциональной специфи­ кации системы. Более подробно вопросы структурирования тестов рассматриваются в разделе " Архитектура тестов" в главе 3.

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

один КРУПНЫЙ ТЕСТ? — БОЛЕЕ ПОДРОБНО ОБ АРХИТЕКТУРЕ ТЕСТОВ

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

тест? Очевидно, что это явно не самый эффективный подход.

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

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

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

Тестирование на базе технических требований позволяет качественно организовать испы­ тания. Технические требования обычно объединяются в группы по функциональным свойствам. Свои тесты можно организовать по тому же принципу. Тесты, относящиеся к подготовке к работе технических средств заказчика, можно объединить в одну группу, равно как и тесты, предназначенные для проверки средств установки и наращивания возможностей программного продукта. Как следует из главы 3, группы логически свя­

занных.тестов могут быть помещены в один тестовый набор (test suite).

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