Врезка 4.1.

Определение целей теста

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

Техническое требование 2.2.1 распространяется на широкий набор функциональ­ ных свойств, но все они относятся к управлению документами, содержащими план проведения испытаний. Один из способов свести воедино тесты, относящиеся к это­ му требованию, предусматривает создание набора под названием " Test_Plans" (" Пла-ны_проведения_испытаний") и сбор в нем всех тестов, предназначенных для про­ верки требования 2.2.1. Например, перед тестами, входящими в этот набор, можно поставить следующие цели:

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

2. Проверить, что квалифицированный пользователь может сохранять и оты­ скивать любой составленный план проведения испытаний.

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

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

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

меньшей мере, функциональной спецификации или, возможно, дополнительной ин­формации из проектной документации по программному продукту.

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

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

• Четко сформулировать назначение каждого теста.

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

• Указать, что должен делать тест, но в то же время не следует объяснять, как это достигается — это должно быть указано в тестовом случае.

Определение спецификаций ввода

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

Каждому входному файлу или образу должен быть присвоен уникальный иденти­ фикатор, причем они должны храниться в среде, обеспечивающей управление вер­ сиями и регулярное дублирование. Хранилище входных данных должно быть описа­ но в плане проведения испытаний, а в спецификации ввода теста должны присутст­ вовать ссылки на это хранилище. Например, набор документов, содержащих план проведения испытаний, может понадобиться для тестов, описанных в предыдущем разделе. Они могут иметь имена TP_inputl.doc, TP_input2.doc и т.п., и храниться в каталоге, например, D: \Test\Project_Name\Test_Plan\Inputs.

Определение конфигурации средств тестирования

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