Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 1. Понятие о технологии быстрого тестирования 25 словами, невозможно построить точную модель процесса разработки программного продукта в виде некоторого набора автономных стадий, а именно это и предполагает каскадная модель. Другие модели, в частности, спираль, поэтапная передача, эволю ционирующая прототипная модель, гораздо лучше отражают итеративный характер разработки программного обеспечения. Итеративные модели более подробно рас сматриваются в главе 2. Если вы работали в качестве специалиста по тестированию в условиях каскадных моделей разработки, вы, скорее всего, имеете опыт решения другой задачи, которая довольно часто встречается в каскадных моделях. Если не предпринять специальных предосторожностей, все ошибки, допущенные при формулировании требований, при проектировании системы и при написании программных кодов перетекают в организацию тестов. В случае применения каскадной модели тестовая группа может обнаружить массу дефектов перед самым окончанием разработок — дефектов, воз никновение которых прослеживается вплоть до стадий формулирования требова ний, проектирования или кодирования п р о ф а м м н о г о продукта. Возврат к началу каскадного процесса разработки сопряжен с существенными трудностями и больши ми затратами времени и средств, поскольку все рабочие продукты, которые якобы уже прошли завершающие стадии, должны подвергнуться повторной проверке. Несмотря на все порождаемые проблемы, каскадная модель достойна того, чтобы ее изучить, поскольку она содержит основные компоненты, необходимые для разра ботки программных продуктов. Независимо от используемой модели, разработка программного обеспечения должна начинаться с понимания того, что нужно постро ить, другими словами, с выявления и анализа требований. Процесс разработки дол жен включать проектирование, кодирование и тестирование невзирая на то, выпол няются ли они в виде линейной последовательности, что характерно для каскадной модели, или в рамках итеративной последовательности, характерной для моделей эволюционного прототипирования и поэтапной передачи. Мы используем каскадную модель в качестве контекста для обсуждения, как добиться улучшения процесса, од нако базовые принципы быстрого тестирования должны применяться независимо от выбранной модели жизненного цикла. Каскадный процесс тестирования В традиционной каскадной модели (см. рис. 1.2) роль организации тестов остается неясной до стадий системного тестирования и приемочных испытаний. Большая часть видов деятельности, характерных для ранних стадий, таких как проектирова ние, кодирование и модульное тестирование, в первую очередь связано с коллекти вом разработчиков программного обеспечения. По этой причине имеет смысл по строить соответствующую модель жизненного цикла процесса тестирования. Из то го, что разработка динамических тестов является процессом, во многом совпадаю щим с процессом разработки программного обеспечения, следует, что каскадная мо дель жизненного цикла динамического тестирования довольно сильно похожа на мо дель, которая обсуждалась в предыдущем разделе. П р и м е р каскадной модели жизнен ного цикла процесса тестирования приводится на рис. 1.3. Обратите внимание на тот факт, что данная модель описывает динамическое тестирование, однако в ней не от ражено статическое тестирование. 26 Часть I. Процесс быстрого тестирования Рис. 1.3. Каскадный процесс тестирования Сводка входных и выходных данных для каждой стадии каскадного процесса от ладки представлена в таблице 1.1. Далее будет дано краткое описание действий, вхо дов и выходов для каждой стадии каскадного процесса тестирования. Другие подроб ности рассматриваются в оставшихся главах первой части. Анализ требований На этапе анализа требований цели, которые преследует группа специалистов по тес тированию и коллектив разработчиков, различаются в ряде аспектов. Обоим коллек тивам нужны четкие, недвусмысленные спецификации требований, которые служат входными данными для их работы. Разработчики желают получить полный набор требований, которыми можно воспользоваться для формулирования функциональ ных требований к системе и которые позволили бы проводить работы по проектиро ванию и кодированию программного продукта. С другой стороны, тестовой группе нужен набор требований, который позволил бы им составить план проведения испы таний и выполнить системные и приемочные испытания. Глава 1. Понятие о технологии быстрого тестирования 27 Таблица 1.1. Входные и выходные данные для каскадного процесса тестирования Вид деятельности Входы Выходы Анализ требований Планирование испытаний Проектирование тестов Реализация тестов Отладка тестов Системное тестирование Приемочные испытания Эксплуатация и сопровождение Определение требований, спецификация требований Спецификация требований, матрица прослеживаемости требований Спецификация требований, матрица прослеживаемости требований, план проведения испытаний Функциональная спецификация программного обеспечения, матрица прослеживаемости требований, план проведения испытаний, проекты тестов "Ранний вариант" кода, тестовые случаи, рабочая испытательная система План испытания системы, матрица прослеживаемости требований, завершающие тестовые случаи, рабочая испытательная система План приемочных испытаний, матрица прослеживаемости требований, бета- вариант программного кода, тестовые случаи для приемочных испытаний, рабочая испытательная система Скорректированный код, тестовые случаи для контроля дефектов, регрессионные тестовые случаи, рабочая испытательная система Матрица прослеживаемости требований План проведения испытаний — стратегия тестирования, испытательная система, оценка объема работ и расписание тестирования Проектирование тестов — спецификация входных данных тестов, конфигурации тестов Тестовые случаи — методы проверки и автоматизированные тесты Тестовые случаи для заключительных испытаний Результаты тестирования — сообщения о дефектах, сообщения о состоянии испытаний, суммарный отчет о результатах тестирования Результаты тестирования Местоположение обнаруженных дефектов Очень полезным выходным документом стадии анализа требований, как для раз работчиков, так и для тестовой группы, является матрица прослеживаемости требо ваний. Матрица прослеживаемости требований (requirements traceability matrix) представля ет собой документ, который отображает каждое требование на промежуточные ре зультаты процесса разработки, такие как компоненты проекта, модули программного обеспечения и результаты тестирования. Она может быть представлена в виде элек тронной таблицы, таблицы текстового процессора, базы данных или Web-страницы. Матрица прослеживаемости требований и ее роль в "соединении" различных видов деятельности процессов разработки и тестирования подробно рассматривается в главе 2. 28 Часть I. Процесс быстрого тестирования Планирование испытаний Под планированием испытаний понимается определение объемов испытаний, под ходов, ресурсов и расписания выполнения намеченных действий. Для того чтобы тестирование было эффективным, необходимо потратить значительные средства и усилия па планирование, а также быть готовым пересматривать этот план в динами ке, соответственно изменениям в требованиях, расчетах или программных кодах по мере выявления дефектов. Очень важно, чтобы все требования подверглись тестиро ванию, либо же, если требования выстроены по некоторой системе приоритетов, по крайней мере, должны быть проверены требования с максимальными приоритетами. Матрица прослеживаемости требований является полезным инструментальным средством на стадии планирования испытаний, поскольку она может использоваться при расчете объемов тестирования, необходимого для охвата важнейших тре бований. В идеальном случае планирование испытаний должно принимать в расчет как ста тическое, так и динамическое тестирование, но поскольку процесс тестирования, отраженный на рис. 1.3 и в таблице 1.1, отдает предпочтение динамическому тести рованию, временно оставим статическое тестирование в покое. Действия, выпол няемые на стадии планирования испытаний, представляют собой подготовительные этапы для этапов системных и приемочных испытаний, которые расположены ближе к концу каскада, и должны включать: • Определение того, что подлежит тестированию, и подхода, который при этом будет использоваться. • Отображение тестов на требования. • Определение критериев входа и выхода для каждой стадии процесса тестиро вания. • Оценка персонала, необходимого для выполнения тестовых работ, по квали ф и к а ц и и и степени занятости. • Оценка времени, необходимого для выполнения работ по тестированию. • Планирование основных этапов работ. • Определение тестовой системы (аппаратных и программных средства), необ ходимой для проведения тестирования. • Определение рабочих продуктов для каждой фазы тестирования. • Оценка рисков, связанных с тестированием, и план по их уменьшению. Промежуточные результаты или выходы, являющиеся результатами этих дейст вий, могут быть включены в план проведения испытаний, который, как правило, со стоит из одного или большего числа документов. Более подробно планирование ис пытаний будет рассматриваться в главе 3, а с примером плана проведения испытаний можно ознакомиться в третьей части книги. Проектирование тестов, реализации и отладка Динамическое тестирование основано на выполнении заданного набора операций на конкретном модуле программного продукта и сравнении фактически полученных результатов с ожидаемыми. Если после прогона получен ожидаемый результат, счи- Глава 1. П о н я т и е о технологии быстрого тестирования 29 тается, что модуль прошел тест. Если зафиксировано аномальное поведение, тест считается неудачным, однако он может оказаться успешным в смысле обнаружения дефекта. Заданный набор выполняемых операций образует тестовый случай. Следует подчеркнуть, что тестовые случаи должны быть спроектированы, закодированы и отлажены до того, как их можно будет использовать. Проектирование тестов состоит из двух компонентов: архитектуры тестов и под робных планов тестов. Архитектура тестов упорядочивает тесты по группам, таким как функциональные тесты, испытания для определения рабочих характеристик, проверка безопасности и т.д. Она также описывает структуру и соглашения по име нованию хранилища тестов. Подробные планы тестов описывают назначение каждо го теста, технические средства и данные, необходимые для выполнения теста, ожи даемые результаты каждого теста, а также указывают на требование, на подтвержде ние выполнения которого ориентируется данных тест. Между требованиями и пла нами тестов должно существовать, по меньшей мере, отношение один к одному. На основе планов тестов могут быть разработаны подробные методики проверки. Уровень детализации, необходимый для представления методики проверки в виде письменного документа, зависит от квалификации и уровня знаний персонала, вы полняющего прогон тестов. Следует найти компромисс между временем, необходи мым для написания подробной, последовательной методики, и временем, которое заинтересованное лицо тратит на обучение правильному выполнению тестов. Даже если тест должен быть автоматизирован, в общем случае затраты времени на заблаго временное подробное описание методики проверки оправдываются, поскольку перед специалистом по автоматизации ставится четкая и однозначная задача автоматиза ции теста. Как только методика тестирования будет описана, ее потребуется проверить на каком-либо модуле программного продукта. Поскольку, скорее всего, этот тест будет проверяться на "изобилующей ошибками" программе, особо внимательно следует анализировать случаи, когда тест не проходит, что позволит определить, где нахо дится причина неудачи — в тестируемом коде или в самом тесте. Системное тестирование Набор завершенных, отлаженных тестов может использоваться и на следующей ста дии каскадного процесса тестирования, т.е. на этапе системных испытаний. Систем ное тестирование проводится для удостоверения того, что программное обеспечение делает именно то, что от него ожидает пользователь. Существуют два основных типа системных испытаний: функциональная проверка и испытания для определения ра бочих характеристик. Функциональная проверка (functional testing) не требует от тестировщика знаний принципов работы программного продукта, в то же время она требует знаний функ циональных требований, предъявляемых к системе. Она использует набор тестов, которые определяют, выполняет ли система все то, что она должна делать с точки зрения пользователя. После того, как тестирование подтвердило адекватность базовой функционально сти системы, задачей тестирования становится проверка, насколько хорошо система выполняет свои функции. В рамках испытаний для определения рабочих характеристик (performance testing) выполняются такие проверки, как тестирование в предельных ре- 30 Часть I. Процесс быстрого тестирования жимах, нагрузочные испытания, контроль синхронизации и проверка восстанавли ваемости. Испытания на надежность, на эксплуатационную готовность, проверка приспособленности к техническому обслуживанию также можно включить в число испытаний для определения рабочих характеристик. Помимо функциональной проверки и испытаний для определения рабочих харак теристик, возможны различные дополнительные проверки, проведение которых может понадобиться на стадии системных испытаний. В их число могут входить про верка безопасности, установочная проверка, проверка на совместимость, проверка удобства и простоты использования, проверка возможностей наращивания. Более подробно системное тестирование рассматривается в главе 5 и в главах второй части. Приемочные испытания По завершении системного тестирования продукт может быть передан пользователю для проведения приемочных испытаний. Если пользователи принадлежат той же компании, что и разработчики, такое тестирование обычно называется альфа- тестированием (alpha testing). Если пользователями являются заказчики, готовые рабо тать с программным продуктом еще до его официальной готовности, то такое тести рование называется бета-тестированием (beta testing). И альфа-, и бета-тестирование представляют собой соответствующие формы контрольных испытаний (pilot tests), в условиях которых система устанавливается на экспериментальной базе с целью выяв ления дефектов. Другой формой приемочных испытаний являются аттестационные испытания (benchmark test), когда заказчик выполняет заранее определенный набор тестовых слу чаев, имитирующих типовые условия, в которых система будет работать после ввода в эксплуатацию. Для аттестационных испытаний могут быть использованы тестовые случаи, которые разработаны и отлажены вашей тестирующей организацией и кото рые в то же время были проверены и одобрены заказчиком. По завершении кон трольных и аттестационных испытаний заказчик должен уведомить вас, какие требо вания не удовлетворены, а какие должны быть изменены, чтобы можно было перейти к заключительным испытаниям. Заключительным типом приемочных испытаний является установочная проверка (installation test), по условиям которой завершенная версия программного продукта устанавливается на площадках заказчика с целью получить от него подтверждение, что программный продукт соответствует всем требованиям и заказчик согласен на его поставку. Сопровождение Сопровождение программного продукта часто ставит разработчиков и тестировщи- ков перед необходимостью решения определенных задач. Сопровождения для разра ботчика — это исправление дефектов, которые были обнаружены заказчиком во вре мя эксплуатации программного продукта, а также расширение функциональных воз можностей продукта, которое призвано удовлетворить возросшие требования заказ чика. Что касается организации тестирования, то сопровождение означает проверку результатов исправления дефектов, тестирование расширенных функциональных возможностей и выполнение регрессионных тестов (regression tests) на новых версиях Глава 1. Понятие о технологии быстрого тестирования 31 программного продукта. Цель всего этого заключается в получении подтверждения того, что ранее исправно работавшие функциональные средства не пострадали от внесения изменений в программный продукт. Какими бы ни были важными приемочные испытания и сопровождение про граммного продукта, в данной книге они подробно не обсуждаются. Базовые принци пы регрессионного тестирования и верификации дефектов хорошо вписываются в эти фазы жизненного цикла. За подробным анализом сопровождения программного обеспечения в перспективе тестирования рекомендуем обратиться к [30]. Связь тестирования и разработки В нескольких предыдущих разделах были описаны каскадные модели процесса разра ботки программного обеспечения и процесса тестирования. У обоих моделей общие исходные и конечные точки, однако группы разработчиков и тестировщиков все время заняты различными видами деятельности. В этом разделе даны описания двух моделей, которые связывают оба эти вида деятельности воедино. О д и н из способов продемонстрировать, как соотносятся тестирование и разра ботка, показан на V-образной диаграмме, изображенной на рис. 1.4. В этой модели, на которую также ссылаются как на шарнирно-каскадную, оба вида деятельности, анализ и проектирование, образуют левую сторону V. Кодирование находится в самой ниж ней точке диаграммы, а тестирование образует ее правую сторону. Для простоты из ложения, вид деятельности, подобный сопровождению, на диаграмме не показан. Рис. 1.4. Шарнирно-каскадная, или V-диаграмма 32 Часть I. Процесс быстрого тестирования Пунктирные линии со стрелками на концах определяют отношения между видом тестовой деятельности на правой стороне и видом проектной деятельности на левой. Самая верхняя пунктирная линия со стрелками показывает, что цель приемочных испытаний заключается в подтверждении требований, а сами приемочные испыта ния основаны на требованиях. Аналогично, системные испытания служат для про верки проекта системы, а системные тесты получены по результатам проектирования системы. Следовательно, одно из назначений V-диаграммы состоит в том, чтобы по казать, какова цель видов тестовой деятельности в терминах контроля и аттестации на ранних стадиях разработки. Несмотря на то что V-диаграммы служат иллюстрацией отношений, связывающих разработку и тестирование, она не отражает двух параллельных потоков деятельно сти, которые две эти группы специалистов осуществляют в процессе разработки. Ил люстрацией одного из способов показать отдельные действия, связанные с разработ кой и тестированием, служит параллельная каскадная модель на рис. 1.5. Эта диаграмма несколько сложнее предыдущих моделей, однако, она обладает не сколькими важными свойствами, которые оправдывают наличие дополнительной сложности. • Отчетливо видны параллельные потоки разработки и тестирования. • Стрелка, соединяющая системное тестирование и проектирование системы, говорит о том, что цель стадии системного тестирования заключается в про верке проекта системы. • Стрелка, соединяющая приемочные испытания с требованиями, показывает, что назначение приемочных испытаний заключается в подтверждении требо ваний. • Аналогичные стрелки говорят о том, что назначение тестирования модулей и проверки взаимодействия и функционирования компонентов системы заклю чается в контроле разработки программы, а цель отладки тестов состоит в кон троле разработки тестов. • Каждая оставшаяся стадия потоков разработки и тестирования имеет "петли обратной связи", назначение которых заключается в проверке того, что про межуточные результаты системного проектирования, проектирования про грамм, планирования испытаний и тому подобного, соответствуют требовани ям, предъявленных к ним в начале соответствующей стадии. Такая проверка выполняется в рамках статического тестирования. Несложный анализ рис. 1.5 показывает, почему тестирование программного обес печения является столь ответственной и трудоемкой задачей. Даже при работе в тра диционной каскадной среде группа специалистов по отладке должна уметь выполнять широкий спектр действий, каждое из которых зависит от результатов деятельности коллектива разработчиков. Между потоками разработки и тестирования этого про цесса должен надежно поддерживаться обмен данными, и каждая группа должна уча ствовать в некоторых контрольных действиях другой группы. Например, группа тес- тировщиков должна участвовать в контроле системного проектирования, а группа разработчиков — принимать участие в проверке плана тестирования. Глава 1. П о н я т и е о т е х н о л о г и и б ы с т р о г о т е с т и р о в а н и я 33 Рис. 1.5. Параллельная каскадная модель 34 Часть I. Процесс быстрого тестирования Что дальше В этой главе были даны определения основных понятий тестирования программного обеспечения. Идея быстрого тестирования представлена как способ ускорения тес тирования без ущерба для качества программного продукта. Мы установили, на сколько важна роль персонала, собственно процесса, статического тестирования и динамического тестирования для организации эффективного процесса быстрой от ладки. Были исследованы каскадный процесс разработки программного обеспечения и динамический процесс тестирования, и в результате обнаружено, что оба они должны быть тесно интефированы, если мы заботимся о высокой эффективности работ по тестированию. Наконец, были рассмотрены V-диаграмма и параллельная каскадная модель как средства, связующие воедино процессы разработки и тестиро. вания. Интеграция процессов тестирования и разработки была начата с построения па раллельной каскадной модели, однако впереди еще предстоит проделать большую работу, прежде чем определение процесса быстрого тестирования будет окончатель но сформулировано. Потребуется проанализировать каждую стадию процесса тести рования на предмет возможной оптимизации ее скорости и эффективности. Эта ра бота будет начата в следующей главе. Анализ требований и тестирование Темы, рассматриваемые в главе: • Процесс формулирования требований О Тестирование требований • Что дальше В предыдущей главе мы установили, что в целях ускорения производства программ ного продукта, разработка и все виды тестовой деятельности должны тесно интегри роваться. Такая интеграция разработки и тестовой деятельности должна начинаться на ранних стадиях процесса разработки, когда формулируются требования к разраба тываемому программному продукту при непосредственном участии пользователя. Для проектирования системы программного обеспечения коллективу разработчиков не обходим четкий набор требований, в то же время группе специалистов по отладке также необходимы четко сформулированные, однозначные требования, что даст возможность составить план тестирования и проекты тестов. Если оба коллектива вступают в сотрудничество на ранних стадиях процесса разработки, то велика веро ятность того, что им удастся сформулировать необходимые требования уже на ран них этапах временного графика. Другая причина привлечения к сотрудничеству группы специалистов по тестиро ванию на стадии формулирования и анализа требований к программному продукту продиктована необходимостью проведения статического анализа этих требований. В отчете группы Standish Group по обследованию более чем 350 компаний, опублико ванном в 1994 году, сообщается, что только 9% из свыше 8000 проектов создания программных продуктов были выполнены в срок и уложились в финансовую смету [48]. Тридцать один процент всех проектов были аннулированы еще до их заверше ния. Последующие исследования [49] проводились с целью выявления причин не удачных проектов. Исследование основных факторов, вызвавших перерасход средств на создание продукта или неудачу проекта в целом, показали, что более чем в 50% случаев эти факторы имеют отношение к процессу выработки требований к про граммному продукту. Основные факторы, имеющие отношение к процессу формули рования требований, перечисляются ниже; там же указано и процентное отношение 36 Часть I. Процесс быстрого тестирования проектов, для которых соответствующая проблема стала фактором, повлекшим за собой провал проекта: • Неполнота требований (13.1%) • Неучастие пользователя в разработке требований (12.4%) • Нереалистичные ожидания (9.9%) • Изменение требований и спецификаций (8.7%) • Отпала потребность в системе (7.5%). Одним из результатов этого отчета является вывод о том, что большое число де фектов может быть внесено в продукт уже на стадии формулирования требований. Когда дефекты попадают в требования, возникает их волнообразное распростране ние на весь процесс разработки, устранение последствий которого требует больших затрат средств и времени. Боем (Boehm) и Папаччио (Papaccio) (которые цитируют ся в [42]) утверждают, что если затраты на обнаружение и устранение дефекта на ста дии формулирования требований составляют $1, то на стадии проектирования эти затраты увеличиваются до $5, на стадии кодирования — $10, на стадии модульного тестирования — $20, а после поставки программного продукта заказчику стоимость работ по устранению того же дефекта достигает $200. Диаграмма, иллюстрирующая затраты на устранение дефекта на разных стадиях разработки, показана на рис. 2.1. По большей части такая эскалация затрат связана с необходимостью повторного вы полнения работ на стадии, предшествующей той, на которой этот дефект был обна ружен и устранен. $200- Требования Проектирование Кодирование Модульное Сопровождение Стадия тестирование Рис. 2.1. Стоимость устранения дефекта на стадии разработки. Приводится из [28] |