Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 3. Планирование испытаний 93 Разумеется, нереально ожидать, что любые критерии, объявленные в плане проведе ния испытаний, будут автоматически управлять выпуском программного продукта. Выпуск программного продукта определяется соображениями экономического ха рактера, которые основываются на информации о качестве продукта, но в то же вре мя во внимание принимаются и ряд других экономических факторов. 8. Критерий приостановки испытаний и требования возобновления испытаний. Выше в этой главе мы установили, что критерий вхождения в испытание показывает, что необходимо предпринять, прежде чем начнете тестирование, а критерий выхода из испытаний описывает, что, по вашему мнению, требуется для завершения испыта ний. Критерии приостановки и возобновления испытаний описывают, что происхо дит, когда продолжению испытаний препятствуют дефекты. Например, можно объя вить, что если модуль содержит устойчивую системную ошибку, исключающую ус пешную установку программного продукта, тестирование приостанавливается на пе риод времени, необходимый для устранения этой ошибки. Разумеется, нельзя оста навливать тестирование каждый раз, когда какая-то часть тестов заблокирована де фектами, однако следует поставить в известность руководство в ситуациях, когда программный продукт содержит такое количество дефектов, что продолжать испы тания нецелесообразно. 9. Выходные результаты тестов. Этот раздел плана проведения испытаний является тем местом, в котором определяются выходные данные работ по тестированию, на пример, можно предложить следующий список: • План проведения испытаний • Документы, регламентирующие проектирование тестов • Документ, содержащий спецификацию тестов • Сообщения о результатах прогона тестов • Сообщения об обнаруженных дефектах • Примечания по выпуску программного продукта (если это вменяется вам в обя занности). Всегда полезно напомнить ответственным исполнителям конкретных документов .предельные сроки оформления документа. Чтобы исключить напрасную трату вре мени на более поздних стадиях, можно подготовить шаблоны, или "козы", этих доку ментов на этапе составления плана проведения испытаний, а затем установить связи или ссылки на "фиктивные" документы. Например, может оказаться полезным зара нее подготовить шаблон отчета по результатам тестирования и заполнять его тесто выми данными по мере их готовности. Кроме того, шаблон проекта теста может ус корить работы по проектированию тестов. Удивительно, как много времени можно понапрасну терять, споря о формате и содержании любого из перечисленных выше документов. Определение и согласование того, что вы намереваетесь опубликовать по завер шении тестирования на раннем этапе жизненного цикла, может стать хорошей прак тикой, поскольку в этом случае упрощается построение реалистичного плана работ. Дабы не закладывать в план работ неоправданных накладных расходов, нежелатель- 94 Часть I. Процесс быстрого тестирования но отображать в плане результаты работ, которые не существенны для достижения конечной цели, каковой в рассматриваемом случае является максимально быстрая поставка программного продукта. 10. Задачи тестирования. Если план проведения испытаний применяется для обос нования произведенной оценки трудозатрат на тестирование, этот раздел является подходящим местом для определения индивидуальных задач, которые необходимы для подготовки и выполнения тестирования. Еще лучше, если вы занесете вашу оцен ку в динамическую электронную таблицу. Другой способ предполагает использование программы управления проектами, например, Microsoft Project, для того, чтобы в этом разделе плана организовать ссылку на другой документ. Это еще один подходя щий момент, чтобы указать ссылку на справочный документ или, по крайней мере, путь к соответствующему файлу или сетевому дисковому накопителю. 11. Информация о конфигурации средств тестирования (требования окружаю щей среды). Дайте описание аппаратных и программных средств, необходимых для проведения испытаний, и начертите диаграммы, показывающие, как аппаратные компоненты соединяются друг с другом. Этот раздел предназначен для того, чтобы позволить любому другому заинтересованному лицу построить такую же испытатель ную установку в случае необходимости воспроизведения неисправности или провер ки, что неисправность устранена. Данный раздел плана проведения испытаний дол жен составляться на базе анализа, проведенного в разделах "Среда тестирования" и "Конфигурации средств тестирования" ранее в этой главе. Возможно, потребуется расширить рамки этого раздела и включить в него архитектуру тестов (т.е. как орга низованы тесты) и инструментальные средства тестирования, которые вы намерены использовать. Обе темы затрагиваются в разделе "Определение испытательной сис темы" в начале главы. 12. Распределение ответственности при проведении тестирования. Если возмож ности вашей тестовой группы по завершению тестирования каким-то образом зави сят от деятельности другой группы, в этом разделе плана проведения тестирования должно быть указано, кто что делает. Например, если вы рассчитываете на разработ чиков программного обеспечения в том, что в проводимую ими проверку взаимодей ствия и функционирования компонентов программного продукта будет включен не который конкретный набор тестов, данный раздел является подходящим местом для формулировки соответствующих условий. Возможно, в этом испытании намерены принять участие инженеры, обслуживающие заказчика, занявшись тестированием пользовательского интерфейса или проверкой документации. В качестве другого примера распределения ответственности, о чем целесообразно упомянуть в этом разделе, можно привести привлечение к тестовым работам терри ториально удаленных организаций (например, привлеченная к сотрудничеству по контракту лаборатория в другом городе или даже в другой стране), которые прини мают на себя выполнение определенной части тестовых работ. Во всех этих случаях полезно составить матрицу ответственности, где задачи соотносятся с исполни телями. Глава 3. Планирование испытаний 95 Если ни одна из упомянутых ситуаций не имеет места, в этом разделе можно по местить стандартную фразу, дескать, организация XYZ, специализирующаяся на тес тировании, будет проводить испытания программного продукта и сообщать об обна руженных дефектах разработчикам. В этом разделе не указываются служебные обя занности конкретных инженеров и техников; для этой цели предназначен следующий раздел плана проведения испытаний. 13. П о д б о р кадров и подготовка персонала. В этом разделе можно привести список персонала, который вы намерены привлечь к тестированию программного продукта. Одна из причин включения такого списка связана с тем, что своевременное выпол нение ключевых этапов тестирования зависит от возможности участия этих людей на стадии тестирования. Если кто-либо из этих специалистов был переброшен на другой проект или вообще уволился, у вас появляются серьезные основания для привлече ния других исполнителей или смещения сроков тестирования. Этот раздел также является подходящим местом для определения, какую подго товку должен пройти персонал группы тестирования, чтобы приобрести квалифика цию, которая потребуется для проведения запланированных испытаний. 14. График работ. Этот раздел обычно не является местом, в котором оглашается подробный график проектных работ — для таких целей существует общий план про ектных работ или самостоятельный файл, который может подвергаться изменениям независимо от плана проведения испытаний. В конце концов, подробный план работ может быть очень динамичным документом, однако содержимое того, что вы тести руете, кадровые проблемы, рабочие продукты тестирования и другие компоненты плана проведения испытаний остаются достаточно статичными. Скорее всего, в план проведения испытаний потребуется включить краткий спи сок ключевых этапов тестирования, например, срок начала тестовых работ, когда бета-версия продукта должна поступить к первым пользователям и когда завершатся испытания. С другой стороны, можно просто принять решение обращаться к планам проектных работ или самостоятельному плану работ, используя для этих целей ссыл ку на Web-странице или путь к сетевому дисковому накопителю. 15. Риски и непредвиденные обстоятельства. Риски могут описываться в таблице, в которой указываются риски, вероятность овеществления этого риска, влияние этого риска и план мероприятий по снижению от овеществления рисков. Процесс по строения такой таблицы описан в разделе "Оценка рисков невыполнения графика работ". 16. Утверждение плана проведения испытаний. Для решения этой задачи на ти тульном листе плана проведения тестовых работ потребуется составить список лиц, утверждающих план, и получить их одобрение. Можно также отправить утверждаю щему лицу по электронной почте копию плана проведения испытаний и получить ответ с утвержденным планом. Хранить сообщения и ответы электронной почты ре комендуется в совместно используемом сетевом каталоге, который дублируется через регулярные промежутки времени, либо присоединить все ответы и подтверждения к специальному приложению к плану проведения испытаний. 96 Часть I. Процесс быстрого тестирования Проверка выполнения плана проведения испытаний План проведения испытаний — это важный рабочий продукт жизненного цикла раз работки, в силу чего он должен быть подвергнут тщательной проверке. По возможно сти он должен пройти формальную проверку (см. раздел "Методы статического тес тирования" в главе 2 и раздел "Проверки/сквозной контроль/экспертные оценки" в главе 9, где содержится более подробная информация о проверках). В проверках должны участвовать не только члены группы тестирования, но и представители кол лективов разработчиков, групп маркетинга и руководства (по меньшей мере, через электронную почту). Проверки преследуют сразу несколько целей: • Все исполнители, принимающие участие в разработке программного продукта, должны понимать и одобрять цели, покрытия, ограничения и риски, связан ные с проведением тестирования. • Подход к тестированию должен быть пересмотрен с целью обеспечения его технической корректности и обеспечения проверки им всех требований, вы полнение которых было обещано заказчику. • Критерии входа и выхода из испытаний должны правильно пониматься всеми исполнителями, принимающими участие в проекте. Любые зависимости от деятельности других групп должны быть четко зафиксированы, а группы, от ветственные за те или иные этапы разработки, в установленные сроки должны предоставлять группе тестирования соответствующие рабочие продукты. Несмотря на то что обмен информацией между группой тестирования и другими группами должен поддерживаться в течение всего процесса разработки программно го продукта, периодические проверки хода выполнения плана проведения испыта ний представляют собой прекрасную возможность обеспечить согласованное выпол нение проектных работ на ранних стадиях жизненного цикла. Любые недоразумения и ошибки при выборе тестового покрытия, которые останутся незамеченными при проверке хода выполнения плана проведения испытаний, могут серьезно помешать проведению испытаний в запланированные сроки. Что дальше В этой главе мы обсудили планирование работ по тестированию и получение оценок. Затраты времени и усилий на планирования могут серьезно повлиять на способность вашей группы успешно реализовать план тестирования и достичь его целей. Ключе выми этапами процесса составления плана тестирования являются: • Определение стратегии тестирования • Определение состава и структуры испытательной системы (аппаратные и про граммные средства) • Оценка трудозатрат на проведение тестирования (необходимые ресурсы и график работ) • Оценка рисков и выполнения графика работ и подготовка планов смягчения последствий от овеществления рисков • Подготовка и проверка документов плана проведения испытаний. Глава 3. Планирование испытаний 97 Выходные результаты этих этапов представляют собой набор документов, опре деляющих план проведения испытаний, который используются при управлении дальнейшими испытаниями. В следующей главе мы познакомимся, с чем придется столкнуться во время разра ботки тестов. Стратегия тестирования, архитектура тестов и конфигурации средств тестирования, определения которых были даны на стадии планирования, играют важную роль при разработке набора эффективных тестовых случаев. Проектирование и разработка тестов Темы, рассматриваемые в главе: • Разработка тестов • Разработка тестовых случаев • Пересмотр и отладка тестов Q Автоматизация т е с т о в ы х случаев Q Ч т о дальше Ключ к успешным испытаниям лежит в эффективности выбранных тестовых случаев. Как было показано в главе 3, четкое планирование и подготовка тестирования игра ют большую роль, но в условиях проведения окончательного анализа выбранные слу чаи тестирования должны обеспечить обнаружение дефектов в программном про дукте, иначе все планирование и подготовка окажутся напрасными. Цель данной гла вы заключается в том, чтобы подготовить базу для проектирования и разработки на дежных динамических тестовых случаев, которые могут использоваться для систем ных и приемочных испытаний. Диаграмма действий, обеспечивающих проектирование и разработку тестов, по казана на рис. 4.1. Основными входными данными для этого процесса является набор документов, составляющих план проведения испытаний, которые были описаны в главе 3. План проведения испытаний должен дать описание подхода, который преду сматривается задействовать при проведении тестирования, а также объемы трудоза трат на тестирование. В нем должна быть определена архитектура тестов, т.е., по меньшей мере, должны быть определены соответствующие наборы тестов. В нем также должен быть определен набор конфигураций средств тестирования, вокруг которых проектируются тесты. Выходными результатами таких видов деятельности, как проектирование и раз работка, являются набор пересмотренных и отлаженных тестовых случаев, которые готовы для использования в системных и приемочных испытаниях. Должно быть обеспечено обратное отображение тестовых случаев на технические требования. Кроме того, тестовые случаи должны обеспечить хорошее покрытие тестами, по меньшей мере, всех технических требований с наивысшими приоритетами, а в иде альном случае — абсолютно всех требований заказчика. Тестовые случаи должны Глава 4. Проектирование и разработка тестов 99 обеспечить хорошее покрытие программного кода продукта за счет выполнения большей части, если не всех, логических путей в программном коде. По мере воз можностей, существенная часть тестовых случаев должна быть автоматизирована для поддержки высококачественно регрессивного тестирования. н> На системные испытания Рис. 4.1. Проектирование и реализация тестов Как показано на рис. 4.1, с разработкой тестовых случаев связан собственный жизненный цикл. Цикл предусматривает стадию проектирования, на которой фор мулируются цели теста, спецификации входных данных, определяются конфигура ции средств тестирования. Цикл включает также этап разработки, в рамках которого даются подробные определения методик тестирования, а также этап проверки и от ладки, на котором тесты подвергаются пересмотру и отладке. Каждый этап жизнен ного цикла разработки конкретного тестового случая рассматривается далее в этой главе. Более подробная информация о технологиях, используемых при динамиче ском тестировании, приводится во второй части, а примеры тестовых случаев можно отыскать в третьей части книги. Разработка тестов Как отмечалось в главе 3, подготовка к тестированию подобна разделению луковицы на чешуйки — это многоуровневый процесс последовательной конкретизации усло вий. Подготовка начинается с концептуального определения стратегии тестирова ния, затем к нему добавляются все большее количество слоев детализации, которые описывают архитектуру тестирования и условия испытаний. В конечном итоге будут 100 Часть I. Процесс быстрого тестирования разработаны проверенные и отлаженные методики тестирования, собрана испыта тельная система, после чего можно смело приступать к системным испытаниям. Разработку тестовых случаев можно сравнить со снятием одного слоя луковицы. Проекты тестов содержат в себе больше подробностей, нежели концептуальный план построения тестов, но в то же время они еще не предусматривают конкретных дейст вий, необходимых для прогона конкретного теста. Многоуровневый подход к разра ботке тестов подобен подходу, используемому при разработке программного обеспе чения. В рамках высокотехнологичного процесса разработчики не переходят от формулирования требований непосредственно к написанию программных кодов. Сначала они выполняют предварительный или системный проект, в котором опре деляют концепцию программного продукта, после чего составляют программу или рабочий план, в котором оговариваются все детали проектирования. В области тес тирования план проведения испытаний играет такую же роль, что и проектное зада ние в области разработки программного обеспечения, а проект теста соответствует рабочему проекту программного обеспечения. Одним из признаков высокого качества технического проектирования является его модульность. В условиях модульного проектирования система разбивается на от дельные компоненты, при этом каждый компонент имеет свое назначение и четко определенные входы и выходы. П р и н ц и п ы модульного проектирования часто при меняются при проектировании программного обеспечения; они так же хорошо под ходят и для проектирования тестов. Модульным компонентом в тестировании явля ется тестовый случай. Это означает, что перед каждым тестовым случаем должна быть поставлена четко сформулированная цель, чтобы было ясно, что подвергается тестированию. Для каждого тестового случая должна быть строго определена среда тестирования с известными начальными условиями, благодаря чему можно рассчи тывать на то, что при каждом прогоне конкретный тест будет выдавать одни и те же результаты. Наконец, каждый тестовый случай должен давать строго определенный ожидаемый результат (выход) с тем, чтобы можно было воспользоваться однознач ным критерием успешного/неудачного испытания. Другим свойством модульного проектирования является то, что модули организу ются в иерархию. Иерархия есть результат разбиения системы на компоненты, и она позволяет в каждый конкретный момент времени работать с одним уровнем системы. Это обстоятельство отражается на архитектуре тестов, которая может включать в себя несколько тестовых наборов, ориентированных на проверку высокоуровневых функциональных свойств системы, а также тестовые наборы или тестовых случаи, служащих для проверки детализированных функциональных свойств системы. На пример, может быть один тестовый набор, предназначенный для проверки GUI- интерфейса, и еще один тест для проверки средств обеспечения безопасности систе мы. В состав тестового набора могут быть включены, с одной стороны, тесты, кото рые работают с экранами ввода специфических данных или с экранами для опреде ления запросов. Тестовый набор отображается на одно конкретное требование или на некоторый набор логически связанных требований, в то время как более детали зированные тестовые случаи отображаются на элементы функциональной специфи кации системы. Более подробно вопросы структурирования тестов рассматриваются в разделе "Архитектура тестов" в главе 3. Глава 4. П р о е к т и р о в а н и е и р а з р а б о т к а т е с т о в 101 И последнее, что необходимо сказать о модульности, это то, что она способствует обнаружению дефектов на ранних стадиях цикла разработки. Теоретически каждый из уровней, на которые разбита система, должен проверяться на предмет присутст вия дефектов, а только после этого становится возможным переход на следующий уровень. На практике план проведения испытаний может пересматриваться и кор ректироваться перед переходом на следующий уровень, коим является проектирова ние тестов. Проекты тестов могут пересматриваться и корректироваться до того, как начнется работа над детализированными тестовыми случаями. Эти промежуточные контрольные точки препятствуют распространению дефектов рабочих вариантов тестов далее по жизненному циклу тестирования, что может служить причиной воз никновения проблем, приводящих к срывам рабочего графика. один КРУПНЫЙ ТЕСТ? — БОЛЕЕ ПОДРОБНО ОБ АРХИТЕКТУРЕ ТЕСТОВ В принципе, можно разработать гигантский тест, который покрыл бы все аспекты тести р у е м о г о программного продукта, однако существует несколько причин, в силу которых эту идею нельзя реализовать на практике. Предположим, что в результате прогона это- го гигантского теста обнаружено сразу несколько дефектов. Когда разработчик пред- принимает попытку воспроизвести один из этих дефектов, дабы отыскать основную при- чину возникшей проблемы и устранить ее, то как же ему поступить в такой ситуации? Неужели снова выполнять прогон этого большого теста? Предположим, что всеми прав илами и неправдами ему все-таки удалось устранить неисправность. Как теперь прове трить, что дефект и в самом деле устранен — опять-таки прогонять тот же самый супер- тест? Очевидно, что это явно не самый эффективный подход. Поэтому лучше всего выбрать такую структуру, чтобы каждый тест охватывал конкрет- ную часть функциональных возможностей тестируемого программного продукта. Если прогон такого теста завершается неудачей, то разработчику нетрудно будет еще раз прогнать этот тест и воспроизвести дефект, затем провести анализ результатов тестиро- вания и устранить неисправность. В идеальном случае объем такого теста сводится до минимального набора действий, необходимого для выявления неисправности. Если в основу тестирования программного продукта положены предъявляемые к нему технические требования, то эмпирическое правило для определения объема теста со- стоит в том, что на каждое техническое требование должен приходиться, по меньшей мере, один тест. Принцип "по меньшей мере, один тест на одно техническое требова н и е " не только позволяет выбирать размерность теста в разумных пределах, но и под- дер'живает разработку плана проведения испытаний. На базе пересмотра перечня техни ч е с к и х требований можно оценить, сколько новых тестов потребуется для тестирования нового программного продукта. Как только вы начнете создавать тесты, руководствуясь этим принципом, вы сможете подсчитать, сколько времени потребуется на разработку и прогон теста на основании ранее полученных результатов. Тестирование на базе технических требований позволяет качественно организовать испы т а н и я . Технические требования обычно объединяются в группы по функциональным свойствам. Свои тесты можно организовать по тому же принципу. Тесты, относящиеся к подготовке к работе технических средств заказчика, можно объединить в одну группу, равно как и тесты, предназначенные для проверки средств установки и наращивания возможностей программного продукта. Как следует из главы 3, группы логически свя занных .тестов могут быть помещены в один тестовый набор (test suite). Для тестирования конкретного технического требования может понадобиться более од- ного сценария. Например, если вы тестируете техническое требование, регламенти- рующее ввод данных заказчика, то требуемый тип данных и их количество может ме няться в зависимости от того, принадлежит ли заказчик к "серебряному классу", "золо- тому классу" или "платиновому классу". Тест для проверки этого требования придется модифицировать в соответствии с классом заказчика. 102 Часть I. Процесс быстрого тестирования Один из способов разрешения подобного рода ситуаций заключается в создании трех различных тестовых случаев, по одному для каждого класса заказчика. Тестовый случай (test case) представляет собой совокупность входных данных теста, условий выполнения и ожидаемых результатов, которые разработаны для конкретной цели. Тестовый случай представляет наименьшую единицу тестирования, которую можно самостоятельно вы полнить от начала до конца. Врезка 4.1. Определение целей теста Самой первой задачей, с которой начинается проектирование теста, является стро гая формулировка его целей или назначения. Предположим, что вы разрабатываете тесты для приложения ТМТ, описание которого приводится в главе 2 и в третьей части книги. Одно из технических требований этого приложения выглядит следую щим образом (другие требования представлены на рис. 2.4 в главе 2): 2 . 2 . 1 . Приложение должно п р е д о с т а в и т ь с р е д с т в а с о з д а н и я , модифи к а ц и и , п р о с м о т р а , х р а н е н и я и п о и с к а д о к у м е н т о в , имеющих о т н о ш е н и е к п л а н у п р о в е д е н и я и с п ы т а н и й . Техническое требование 2.2.1 распространяется на широкий набор функциональ ных свойств, но все они относятся к управлению документами, содержащими план проведения испытаний. Один из способов свести воедино тесты, относящиеся к это му требованию, предусматривает создание набора под названием "Test_Plans" ("Пла- ны_проведения_испытаний") и сбор в нем всех тестов, предназначенных для про верки требования 2.2.1. Например, перед тестами, входящими в этот набор, можно поставить следующие цели: 1. Проверить, что программа предоставляет квалифицированному пользовате лю средства создания всех действующих типов документов, которые имеют отношение к плану проведения испытаний. 2. Проверить, что квалифицированный пользователь может сохранять и оты скивать любой составленный план проведения испытаний. 3. Проверить, что программа предоставляет квалифицированному пользовате лю средства модификации всех документов с планом проведения испытаний, которые были составлены и сохранены в памяти. 4. Проверить, что квалифицированный пользователь может отыскать и пере смотреть любой документ, содержащий план проведения испытаний, который был составлен и сохранен в памяти. Каждая цель теста устанавливает, что тест будет делать, но отнюдь не то, как он это будет делать. Как — это дело подробной методики тестирования, которая разра батывается в виде части соответствующего случая тестирования. Цели теста пред ставляют собой уточнение плана проведения испытаний, другими словами, тест дол жен быть ориентирован на проверку технического требования 2.2.1. Другим отличи ем проекта теста от тестового случая является то, что проекты тестов обычно созда ются с использованием спецификации технических требований. Тестовые случаи, требующие более подробного знакомства с программным продуктом, требуют, по |