Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 4. Проектирование и разработка тестов 103 меньшей мере, функциональной спецификации или, возможно, дополнительной ин формации из проектной документации по программному продукту. Обратите внимание на то обстоятельство, что примеры целей тестирования тре бует некоторой разъяснительной информации, когда дается определение следующе го "слоя луковицы". Цель номер 1 теста, например, не дает определения "квалифици рованного пользователя" — т.е. уточнения, которое зависит от того, как спроектиро вано управление доступом к программе. Должны быть построены тесты, проверяю щие, могут ли получить доступ к данным квалифицированные пользователи, и в то же время неквалифицированные пользователи не могут. Цели теста также ничего не говорят о том, что собой представляют "действующие типы документов с планом проведения испытаний", однако наличие этой формулировки подсказывает специа листу по тестированию, что нужно рассмотреть в качестве случаев как действующих, так и не действующих типов документов, если установлены конкретные критерии применимости. По сути дела, в процессе формулирования целей тестирования следует пользо ваться следующими рекомендациями: • Четко сформулировать назначение каждого теста. • Определить модульную структуру для тестов, так чтобы каждый тест имел единственную цель, и чтобы его можно было отобразить на помеченное требо вание в спецификации технических требований. Однако имейте в виду, что для тестирования некоторого конкретного требования может понадобиться более одного теста. • Указать, что должен делать тест, но в то же время не следует объяснять, как это достигается — это должно быть указано в тестовом случае. Определение спецификаций ввода Спецификации ввода регламентируют форматы файлов входных данных, записей баз данных, конфигурационных файлов, оборудования или других входных данных, не обходимых для того, чтобы привести испытательную систему в требуемое состояние для выполнения тестов. Спецификации ввода не охватывают ввод с клавиатуры или ввод при помощи мыши, который производится в процессе тестирования; такие ви ды ввода должны описываться в подробных методиках испытаний. Каждому входному файлу или образу должен быть присвоен уникальный иденти фикатор, причем они должны храниться в среде, обеспечивающей управление вер сиями и регулярное дублирование. Хранилище входных данных должно быть описа но в плане проведения испытаний, а в спецификации ввода теста должны присутст вовать ссылки на это хранилище. Например, набор документов, содержащих план проведения испытаний, может понадобиться для тестов, описанных в предыдущем разделе. О н и могут иметь имена TP_inputl.doc, TP_input2.doc и т.п., и храниться в каталоге, например, D:\Test\Project_Name\Test_Plan\Inputs. Определение конфигурации средств тестирования Прогон каждого теста должен выполняться в известной среде тестирования, чтобы результаты прогона были предсказуемыми и воспроизводимыми. Это означает, что конфигурация аппаратных средств, операционная система, версия тестируемого 104 Часть I. Процесс быстрого тестирования программного продукта и начальное состояние системы должны быть определены. Как отмечалось в главе 3, работа по составлению плана проведения испытаний долж на предусматривать анализ различных вариантов конфигурации средств тестирова ния и выбор из них конфигураций, пригодных для системных испытаний. Задача заключается в том, чтобы на стадии проектирования конкретного теста выбрать одну или несколько конфигураций, которые можно использовать для дости жения целей этого теста. Зачастую один и тот же тест нужно выполнить на некото ром множестве конфигураций, чтобы смоделировать различные рабочие условия заказчика. Например, крупный заказчик может использовать преимущественно стан дартные конфигурации операционной системы, процессора, накопителя на жестких дисках, сетевой операционной системы и оперативной памяти — такую конфигура цию можно смоделировать в лабораторных условиях с высокой степенью точности. Один из способов отслеживания конфигураций предусматривает их описание в плане проведения испытаний с присвоением каждой конфигурации уникальных идентификаторов. В таком случае в плане проведения испытаний гораздо проще ссылаться на одну или несколько избранных конфигураций. Документ проектов тестов Назначение документа проектов тестов состоит в том, чтобы собрать в одном месте всю информацию, порожденную в результате различных видов тестовой деятельно сти. Документ проектов тестов может быть представлен в виде электронной таблицы, в виде таблицы текстового процессора или в виде базы данных. Если вы пользуетесь инструментальным средством автоматизированного управления требованиями, его можно применить для сбора информации о проекте теста. П р и м е р записи в докумен те проектов тестов показан в таблице 4.1. Таблица 4.1. Пример записи в проектном документе тестов Идентифи- Идентифика- катор тор системно- Входные Конфи- определения го случая данные гурация Назначение требования тестирования теста теста теста RD2.2.1 ST2.2.4 TP_lnput1.doc ТС2.0 Т02.2.4. Проверить, что квалифицированный пользователь может отыскать и ознакомиться с любым ранее созданным документом, содержащим план проведения испытаний. Эта таблица в какой-то степени похожа на матрицу RTM (Requirement Traceability matrix — матрица прослеживаемости требований), которая рассматривалась в главе 2 (см. рис. 2.5). Два первых столбца таблицы должны соответствовать вхождениям в матрицу RTM, остальные столбцы соответствуют данным, описанным в трех преды дущих разделах данной главы. Как только проектный документ тестов будет готов, его нужно проверить в кон тексте связанных с ним материалов: документа определения требований (техниче- Глава 4. Проектирование и разработка тестов 105 ского задания), определения входных данных теста и конфигурации средств тести рования. Цели такой проверки связаны с необходимостью убедиться: • Ч т о рассматриваемым документом проектов тестов были охвачены все техни ческие требования. Если то или иное требование не тестируется, в матрице RTM или в документе проектов тестов должна присутствовать запись, пояс няющая, почему соответствующее требование не покрывается тестом. • Что каждый тестовый случай поддерживается соответствующими входными данными. • Ч т о для каждого тестового случая имеется подходящая конфигурация, причем эти конфигурации не являются избыточными. Документ проектов тестов служит основой для разработки детальной методики тестирования. В результате его пересмотра тесты могут распределяться среди испол нителей группы тестирования для дальнейшей детализации. Разработка тестовых случаев Тестовый случай представляет собой основной компонент динамического тестиро вания. По сути дела, этап системного тестирования — едва ли что-то большее, нежели просто прогон тестовых случаев на некоторой последовательности программных сборок с целью обнаружения и устранения дефектов. Это означает, что основная обязанность специалиста по тестированию заключается в написании и прогоне тес товых случаев. В этом разделе мы обсудим, как проектировать и создавать высокока чественные тестовые случаи. В главе 1 было дано определение тестирования программного обеспечения как процесса анализа или эксплуатации программного обеспечения с целью выявления дефектов. Тест (test) представляет собой набор операций, предназначенных для полу чения одного или большего числа ожидаемых результатов в некоторой программной системе. Если получены все ожидаемые результаты, считается, что тест прошел (т.е. выполнен успешно). Если фактический результат отличается от ожидаемого, счита ется, что тест не прошел (т.е. завершился неудачно). Первое, что следует отметить в приведенном определении, так это то, что каждый тест состоит из двух компонентов: (1) совокупность выполняемых вами действий и (2) последовательность событий, которые должны произойти в результате этих дей ствий. Выполняемые действия суть тестовые действия, которые в совокупности об разуют методику тестирования. Последовательность событий, происходящих в ре зультате этих действий, называются ожидаемыми результатами. Чтобы тест был эф фективным, должны быть четко и однозначно определены как методика, так и ожи даемые результаты. Во-вторых, если методика тестирования и ожидаемые результаты определены правильно, тест должен давать результат, но которому можно сделать однозначный вывод относительно успеха или неудачи испытания. При вводе в программу двух чи сел с целью получения их суммы тест считается пройденным, если на выходе про граммы будет получен корректный результат; в противном случае тест рассматрива ется как не пройденный. 106 Часть I. Процесс быстрого тестирования Как отмечалось ранее, для удобства выполнения тесты можно и далее разбивать на тестовые случаи. Если некоторый тест требует выполнения пространной методи ки тестирования с множеством ожидаемых результатов, имеет смысл разбить такой тест на тестовые случаи. Однако при этом следует иметь в виду, что тестовый случай есть наименьший модуль тестирования, и что с каждым тестовым случаем должен быть связан, по меньшей мере, один ожидаемый результат. В силу того, что целью тестирования является выявление дефектов, хорошим тес том считается тест с высокой вероятностью обнаружения дефекта. Чтобы спроекти ровать тест, обладающий высокой вероятностью обнаружения дефекта, специалист по тестированию должен стать на позицию "конструктивного разрушения" про граммного продукта. "Конструктивное разрушение" означает выявление проблем в программном продукте с целью их устранения. Сложность при этом связана с тем, что в задачи специалиста по тестированию не входит выявление обстоятельств, при которых программный продукт работает; наоборот, тестировщик пытается обнару жить такие ситуации, при которых продукт не работает. П р и проектировании тесто вого случая важно не делать никаких предположений относительно того, что та или иная функция программного продукта работает исправно. Вы не должны рассчиты вать на то, что какая-либо сборка программного кода будет установлена правильно, или на то, что структура базы данных соответствует проекту, или что программа са мостоятельно восстановится после потери напряжения в электросети. Нельзя также рассчитывать и на то, что если программа успешно работает на заданной платформе, то она будет работать столь же хорошо и на компьютере с меньшим пространством памяти или под управлением другой операционной системы. Другое свойство хорошо спроектированного теста — его повторяемость. Если прогон теста завершился неудачей, очень важно воспроизвести точные условия, при которых это произошло. По этой причине важно, чтобы начальное состояние систе мы было определено тестовым случаем в терминах используемой версии программ ного продукта, конфигурации аппаратных средств, количества пользователей систе мы и т.д. Важно также, чтобы была известной точная методика, используемая при выявлении неисправностей. В идеальном случае должна фиксироваться точная по следовательность нажатых клавиш, щелчков мыши или другие события, которые привели к отмеченным отклонениям от ожидаемых результатов. На практике все эти подробности могут оставаться неизвестными, возможно, из-за того, что методика тестирования не расписана во всех подробностях, или из-за того, что произошло ка кое-то неконтролируемое случайное событие без ведома тестировщиков. Вот почему, когда происходит сбой, важно, не жалея времени, немедленно воспроизвести неис правность, подробно фиксируя при этом действия, которые привели к сбою, если только они явно не расписаны в методике испытаний. Хорошо спроектированный тест снабжен одним или большим числом четко опре деленных ожидаемых результатов и четко определенными критериями успеш ных/неудачных испытаний. Обычно ожидаемые результаты и критерии успеш ных/неудачных испытаний тесно связаны. Если ожидаемый результат или некото рый набор ожидаемых результатов будет получен, когда система переводится из од ного заданного состояния в другое, то тестовый случай проходит. Если ожидаемые результаты не удается зафиксировать после выполнения заданных действий, тест не проходит. Например, предположим, что в поле ввода данных вводится значение поч- Глава 4. Проектирование и разработка тестов 107 тового индекса, и при этом ожидается, что на экран будет выведено название соот ветствующего штата после щелчка на кнопке "Укажите штат". Если после ввода неко торого набора почтовых индексов для каждого из них появляется правильное назва ние штата, это значит, что тест получает ожидаемые результаты и поэтому проходит. Если же при вводе почтового кода Сиэтла на экране отображается штат Флорида, считайте, что вам повезло в плане обнаружения дефекта, поскольку ожидаемый ре зультат не был получен. Следует отметить, по меньшей мере, один дополнительный признак хорошо спроектированного тестового случая — он не должен быть избыточным. Оптималь ный рабочий график тестирования требует, чтобы вы выполнили объем тестирова ния, достаточный для обнаружения всех неисправностей перед поставкой программ ного продукта заказчику, но вы не должны тратить время на прогон избыточных тес тов. В рассмотренном выше примере вы не должны тратить время на отображение на экране названия штата для каждого известного почтового индекса, если эта функция не критична для бизнес-операций заказчика. Если с отображением на экране почто вых индексов связана крупная неприятность, наверняка потребуется потратить вре мя на тестирование функции отображения. Кроме того, следует задуматься над во просами автоматизации этой утомительной задачи. Но если это свойство реализуется из соображений удобства, возможно, потребуется лишь проверить какой-нибудь до пустимый и несколько недопустимых индексов, дабы подтвердить правильность ба зовых функциональных свойств. Эта тема обсуждается в разделе "Разбиение на экви валентные классы" далее в этой главе, а также в главе 10. Резюмируя, можно утверждать, что с тестовым случаем должны быть связаны сле дующие признаки: • Он должен обладать высокой вероятностью обнаружения дефекта. • Он должен быть воспроизводимым. • Он должен обладать четко определенными ожидаемыми результатами и крите риями успешного или неудачного выполнения теста. • Он не должен быть избыточным. Разработка детализированных методик тестирования Детализированные методики тестирования могут быть разработаны на основе про ектов тестов. Уровень детализации методик тестирования, представленных в пись менном виде, зависит от квалификации и знаний исполнителей, которые выполняют прогон тестов. Вы планируете привлечь к выполнению системного испытания про граммного продукта исполнителей, мало знакомых с этим продуктом? Если это так, то они должны пройти определенную подготовку, а методика тестирования должна быть четко сформулирована с тем, чтобы они выполняли корректные тестовые дей ствия. В случае, когда тестировщики обладают подробными знаниями программного продукта, методика тестирования может быть менее детализированной. Решение относительно того, каким должен быть уровень детализации методик тестирования, имеет большое значение, ибо можно напрасно потратить время на описание излиш них подробностей для подготовленного пользователя. С другой стороны, напрасно потратить время можно и на обучение неподготовленных тестировщиков тому, как 108 Часть I. Процесс быстрого тестирования проводить испытания, если методика не содержит необходимых деталей. Так или иначе, желательно найти разумный компромисс. Отдельного рассмотрения заслуживает один специальный случай. Если тест за служивает того, чтобы быть автоматизированным, целесообразно выделить время на предварительную разработку детализированной методики тестирования, с помощью которой инженер по автоматизации сможет однозначно сформулировать задачу ав томатизации. Расплывчатая методика тестирования, скорее всего, приведет к появ лению неточных или неэффективных автоматизированных тестов. Рекомендуемый уровень детализации методики тестирования прояснится после дальнейшего обсуж дения ожидаемых результатов. Существует широкий выбор технологий, которые могут использоваться для тес тирования программных продуктов. В этой главе мы будем рассматривать техноло гии тестирования методом черного ящика. Тестирование методом черного ящика представляет собой тестирование на системном уровне, которое имеет дело только со "внешними" аспектами программы. Тестирование методом черного ящика не предполагает каких-либо знаний о внутреннем функционировании программного продукта и проводится с использованием только внешних интерфейсов, таких как пользовательские интерфейсы или интерфейсы API (Application Programming Inter face — интерфейс программирования приложений). Более подробный анализ тести рования методом черного ящика можно найти в [17], [15] и [27]. Более подробную информацию о тестировании с использованием метода черного ящика можно найти в главе 10 настоящей книги. Двумя широко распространенными технологиями разработки тестов для тестиро вания методом черного ящика являются разбиение на классы эквивалентности и ана лиз граничных значений. Обе технологии помогают уменьшить общее количество тестовых случаев или проверяемых условий, которые необходимы для полного по крытия функциональных возможностей программы. Вполне понятно, что эти методы являются ценной частью понятия быстрого тестирования, ибо чем меньше требуется разрабатывать и прогонять тестов с целью получения того же функционального по крытия, тем эффективнее становится тестирование. Разбиение на классы эквивалентности. Разбиение на классы эквивалентности пред ставляет собой технологию проектирования тестов, ориентированную на снижение общего числа тестов, необходимых для подтверждения корректности функциональ ных возможностей программы. Основная идея, стоящая за разбиением на классы эк вивалентности, заключается в том, чтобы разбить область ввода программы на клас сы данных. Если проектировать тесты для каждого класса данных, но не для каждого члена класса, то общее количество требуемых тестов уменьшается. В качестве примера рассмотрим программу отображения почтовых индексов, ко торая рассматривалась ранее в главе. Предположим, что когда пользователь вводит пятизначный почтовый индекс и общую массу отправляемого груза в унциях, про грамма возвращает стоимость доставки пакета. Областью ввода для этой программы являются почтовые индексы и масса брутто отправляемого груза. Область ввода поч тового кода может быть разбита на класс допустимых вводов и класс недопустимых вводов следующим образом: |