![]() Главная страница Случайная страница КАТЕГОРИИ: АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника |
Врезка 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.
Определение конфигурации средств тестирования
Прогон каждого теста должен выполняться в известной среде тестирования, чтобы результаты прогона были предсказуемыми и воспроизводимыми. Это означает, что конфигурация аппаратных средств, операционная система, версия тестируемого
|