Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 3. Планирование испытаний 85 Часто знаменательные даты проекта сводятся в отдельную таблицу, которая полу чила название поэтапного графика. Примером поэтапного графика, который может ис пользоваться руководством и персоналом, проводящим испытания, служит таблица 3.4. Таблица 3.4. Пример поэтапного графика Этап Дата Завершение разработки плана тестирования 1/8 Завершение разработки тестового случая 1/18 Начало системных испытаний 1/18 Цикл 1 испытаний завершен 1/25 Цикл 2 испытаний завершен 2/1 Цикл 3 испытаний завершен 2/12 Проверка готовности программного продукта 2/14 Завершение системных испытаний 2/14 Оценка рисков, связанных с графиком работ Как только будет получена оценка количества исполнителей, оборудования и време ни, необходимого для тестирования программного продукта, потребуется оценить риски, связанные с этими оценками. Это делается исходя из предположения, что мо жет выйти из строя во время проведения испытаний. Далее несложно составить план устранения возникающих проблем. Объем трудозатрат, необходимых для смягчения последствий от овеществленных рисков, даст представление о том, насколько полу ченные оценки могут отклоняться от фактических значений затрат времени и средств. Риски, встроенные в полученные оценки, — это первое, о чем следует доло жить вышестоящему руководству в процессе пересмотра оценок. Ниже приводятся примеры рисков, которые оказывают слияние на график работ по тестированию: • Аппаратные средства, необходимые для проведения тестирования, отсутству ют на начальной стадии испытаний • Тестируемый программный продукт не поступил на испытания • Тестовые случаи не готовы к началу испытаний • Исполнители, которым поручено проведение испытаний, не могут приступить к тестированию • Внесение изменений в требования в процессе разработки тестов или во время испытаний • Изменение пользовательских интерфейсов в процессе разработки тестов или во время испытаний • Освоение персоналом новых средств тестирования не завершено к началу ис пытаний Анализ рисков часто влечет за собой разработку плана смягчения последствий от овеществления рисков. Например, если вы убеждаетесь в том, что тестовые случаи не 86 Часть I. Процесс быстрого тестирования готовы ко времени проведения испытаний, появляются все основания предложить привлечь к испытаниям дополнительные трудовые ресурсы. Если работы по тестиро ванию зависят от поставки нового оборудования, необходимого для реализации про екта, то, заложив эту зависимость в график работ и давая оценку связанных с ней рисков, вы ставите в известность руководство проекта о том, что сроком поставки нового оборудования должно быть начало испытаний, а не дата его отгрузки. Обычная практика управления при допущении риска предусматривает связь каж дого риска с вероятностью осуществления этого риска и меры воздействия на проект, если риск все же случится. Например, возможно, вскроется тот факт, что, скорее все го (с вероятностью 90%), основные специалисты по тем или иным причинам не смо гут приступить к тестированию в запланированные сроки, поэтому возможность на рушения графика работ оценивается как критическая (по шкале критическая, высо кая, средняя, малая). Риск, который оказывает большое влияние на выполнение про екта и характеризуется высокой вероятностью осуществления, относится к катего рии тех рисков, в случае возникновения которых у вас должен быть план дополни тельных мероприятий. В подобной ситуации, возможно, потребуется обсудить воз можность внесения изменений в план работ или изменить очередность подключения специалистов различного профиля, участие которых необходимо для проведения испытаний. Предполагаемый перечень действий для оценки рисков выглядит следующим об разом: • Составить список всех рисков, какие, по вашему мнению, представляют угрозу выполнению графика работ по тестированию. Проведите анализ статистиче ских данных, таких как оценки выполнения проектов или информация о не обычных случаях сбоев, имевших место при выполнении предыдущих проек тов. Получите оценку зависимости от других групп, обсудив с ними вероят ность того, что они выполнять предложенные вами критерии вхождения в ис пытания. • Дать оценку вероятности осуществления каждого выявленного риска. • Дать оценку последствий осуществления риска в отношении выполнимости плана испытаний. Для описания этого влияния воспользуйтесь шкалой крити ческое, высокое, среднее, малое. • Разработать план снижения вероятности осуществления рисков или их влия ния, начиная с тех из них, которые обладают высокой вероятностью осуществ ления или чреваты тяжелыми последствиями. Существует много литературы по вопросам управления при допущении риска. Для пополнения своиъ знаний рекомендуем обратиться к [43], [42] и [30], которые со держат краткую, но в то же время весьма полезную информацию. Глава 3. Планирование испытаний 87 Подготовка и пересмотр документов, содержащих планы проведения испытаний Формат плана проведения испытаний После выбора стратегии тестирования, определения испытательной системы и оценки трудозатрат можно приступать к составлению плана проведения испытаний. План проведения испытаний представляет собой документ или некоторый набор до кументов, представляющих собой результат выполнения определенных видов дея тельности по планированию испытаний. Этот документ не является раз и навсегда установленным планом, он меняется по мере изменения требований. Полезные ре- комендации по разработке плана проведения испытаний предлагает стандарт IEEE Standard 829: IEEE Standard for Software Test Documentations [22] (стандарт IEEE по со ставлению документированию испытаний программного обеспечения). Конечно, можно воспользоваться другим форматом, однако потребуется оформить все мате риалы, рекомендуемые указанным выше стандартом IEEE в любом подходящем фор мате. Другие идеи и форматы рассматриваются в [15], а также в [30], [40] и [33]. В данном разделе при построении шаблона плана проведения испытаний будет исполь зоваться стандарт IEEE Standard 829. Согласно рассматриваемому стандарту, план проведения испытаний должен со держать 16 разделов: 1. Идентификатор плана проведения испытаний 2. Введение 3. Компоненты, которые должны тестироваться 4. Характеристики и свойства, которые должны тестироваться 5. Характеристики и свойства, которые не должны тестироваться 6. Подход 7. Критерий успешных и неудачных испытаний 8. ' Критерий приостановки испытаний и требования возобновления испытаний 9. Выходные результаты тестов 10. Задачи тестирования 11. Требования окружающей среды 12. Распределение ответственности 13. Подбор кадров и подготовка персонала 14. График работ 15. Риски и непредвиденные обстоятельства 16. Утверждение плана проведения испытаний. Если внимательно проанализировать этот список, несложно понять, чем этот план не является — он не представляет собой подробное описание того, как должен выполняться прогон тестов, и не является местом сосредоточения результатов тес- 88 Часть I. Процесс быстрого тестирования тирования. Некоторые организации, специализирующиеся на тестировании про граммных продуктов, объединяют один или большее число пунктов списка с содер жимым плана проведения испытаний, тем самым организуя всю тестовую документа цию в одном месте. Это может дать прекрасные результаты, однако в данной книге мы преследуем цель достижения большей модульности комплекта документов, кото рая совпадает с целью упомянутого выше стандарта. Тот факт, что указанный стандарт направлен на разделение планов проведения испытаний, процедур и результатов, становится очевидным из содержащихся в нем определений следующих документов [22]. План проведения испытаний. Это документ описывает возможности, подход, ре сурсы и график исполнения различных видов тестовой деятельности. Он опреде ляет объекты тестирования, функции, которые должны тестироваться, тестовые задания, исполнителей каждого тестового задания, и любой из рисков, требую щий планирования на случай непредвиденных обстоятельств. Спецификация методики тестирования. Этот документ описывает последова тельность действий при выполнении конкретного теста. Отчетный доклад о тестировании. Этот документ обобщает виды тестовой дея тельности и их результаты. Он также содержит оценку соответствующих тестовых объектов. Спецификация методики тестирования изучается в главе 4 как часть работ, вы полняемых при разработке тестов, а отчетные доклады о тестировании рассматри ваются в главе 5, в которой речь идет о выполнении тестов. В идеальном случае все эти документы должны быть связаны в эффективную, скоординированную систему, которая поддерживает процесс тестирования от начала до конца. В данном разделе мы проведем анализ содержимого плана проведения испытаний и оптимизацию его структуры для целей быстрого тестирования. По каждому пункту этого плана мы попытаемся найти приемлемый способ быстро и эффективно удовле творить его требования. Разумеется, некоторые предложенные решения не будут со ответствовать вашим потребностям, но тогда вы должны будете выполнить такой же анализ в контексте собственной среды разработки. Каждый пронумерованный ниже пункт соответствует пункту эскиза плана, приве денного в предыдущем разделе. П р и м е р ы плана проведения испытаний, специфика ции методики тестирования и отчета о тестировании приводятся в третьей части книги. 1. Идентификатор плана проведения испытаний. В долгосрочной перспективе можно сэкономить время, если присвоить всем тестовым документам идентификато ры, которые нетрудно отслеживать. По существу, возможность отслеживания доку ментов позволяет получить следующие преимущества: • Наличие уникального идентификатора каждого тестового документа позволяет воспрепятствовать тому, что кто-либо из исполнителей напрасно затратит вре мя на изучение не того документа, что надо. Таким идентификатором может быть алфавитно-цифровая строка, которая может содержать данные, отобра жающие название продукта, номер версии, дату и любую другую информацию, позволяющую отслеживать этот документ. Рекомендуется отдавать предпочте- Глава 3. Планирование испытаний 89 ние идентификаторам, которые вписываются в общую систему управления до кументов. • Построить хранилище документов (возможно, сетевой дисковый накопитель), которое позволяет исполнителям и руководству быстро находить документы, имеющие отношение к тестированию. Если во время очередного кризиса вам придется отыскивать нужную версию того или иного документа, вы убедитесь, насколько полезным является подобное хранилище документов. • Построить систему отслеживания документов, поддерживающую управление версиями. В любой момент может возникнуть необходимость внести измене ния в тестовые документы, в том числе планы проведения тестирования. Вы должны иметь возможность донести до исполнителей и руководства последние изменения. Управление версиями может быть таким же простым, как докумен тирование статистических данных на титульном листе документа и поддержа ние актуальной версии, помещенной в хранилище документов. 2. Введение. Цель введения заключается в том, чтобы дать краткую информацию для любого исполнителя, желающего воспользоваться планом проведения испытаний. Суть состоит в необходимости указания во вводном разделе плана проведения испы таний исходных документов, служащих входными данными выполняемого тести рования. Например, можно составить список документов с требованиями и функциональ ных спецификаций для тестируемого программного продукта. П р и составлении это го списка желательно указать расположения документов (путь в сетевом дисковом накопителе или URL-адрес Web-страницы), что даст возможность быстро получить к ним доступ. Наиболее подходящий способ заключается в помещении в план проведе ния испытаний ссылки на исходный документ, благодаря которой пользователь смо жет переходить из недокументальной копии плана на соответствующие справочные материалы. Преимущество такого подхода связано с возможностью автоматического выхода пользователя на последнюю версию входного документа. Другим аспектом, который совершенно не связан с обеспечением быстрого поис ка входных документов, является минимизация временных затрат на написание вве дения. Пример, сопровождающий стандарт IEEE Standard 829, содержит цели плана проведения испытаний, предварительные данные о программном продукте, объем тестирования, предусмотренный планом проведения испытаний, и перечень ссылок. Размер такого документа не превышает половины страницы. Если при этом имеются ограничения, оказывающие влияние на процесс планирования, например, срок вы хода продукта на рынок, их можно перечислить здесь же. 3. Компоненты, которые должны тестироваться. Здесь приводятся высокоуровне вые списки компонент, которые вы намерены тестировать. В этом разделе будут упо мянуты некоторые из них: • Идентификатор выпуска/версии тестируемого программного проекта • Исправления дефектов, обнаруженных в предыдущей версии. Если список де фектов приводится в спецификации функций, необходимо указать ссылку на спецификации функций и не дублировать их здесь 90 Часть I. Процесс быстрого тестирования • Описание среды, используемой для распределения программного продукта (например, компакт-диски, Web- или ftp-сайты) • Документы для конечного пользователя, такие как руководство пользователя, инструкции по установке, примечания по версии продукта. Обратите внимание на тот факт, что это перечень представляет собой ни что иное, как входные данные для выполняемого тестирования. Все эти материалы должны быть получены своевременно, чтобы не нарушать сроки тестирования, по этому в плане они помечаются как зависимости. Следует обладать полной ясностью относительно того, что тестируется, дабы ничто не смогло ускользнуть из внимания. Например, существует вредная привычка до последней минуты "забывать" проводить тестирование документов для пользователя. Пытаясь исправить подобную забывчи вость в конце разработки проекта, легко допустить срыв графика работ и, что еще хуже, поставить заказчику продукт с необнаруженными дефектами. 4. Характеристики и свойства, которые должны тестироваться. Стандарт IEEE Standard 829 предлагает следующее определение свойства программного обеспечения (software feature): это отличительная характеристика программного компонента, на пример, производительность, переносимость или функциональные возможности. Это очень общее определение, поскольку оно должно охватить большое количе ство понятий. Возможно, имеет смысл давать определения свойств в бизнес- терминах. Рассмотрим свойство быть тем, "что может продаваться заказчику". На пример, если приложение работает медленнее, чем это нужно заказчику, то увеличе ние быстродействия его наиболее часто используемых функций может подаваться как свойство. Более совершенный новый способ ввода ускорения ввода данных или запроса в базу данных также может продать как свойство. Ключевым моментом для специалистов по тестированию является то, что если что-то было обещано заказчику, оно должно быть отражено в плане проведения ис пытаний с тем, чтобы протестировать его до поставки объекта заказчику. Основным источником, позволяющим узнать, что было обещано заказчику, служат документы определения требований, на которые существуют ссылки во введении. Перечень свойств в этом разделе предоставляет в ваше распоряжение контроль ную таблицу для вычисления трудозатрат, необходимых для проведения испытаний программного продукта. Каждая позиция этого списка соответствует конкретным пунктам документов описания требований, в то же время каждой такой позиции дол жен соответствовать один или большее число тестов, определенных в спецификации методики тестирования. 5. Характеристики и свойства, которые не должны тестироваться. Этот раздел предназначен для того, чтобы заблаговременно и однозначно определить, какие объ екты не должны охватываться тестированием. В число объектов, объявляемых как "не подлежащие тестированию", могут входить следующие: • Функции, реализация которых отложена до последующих инкрементальных версий продукта Глава 3. Планирование испытаний 91 • Конфигурации компьютерных средств, которые невозможно проверить по причине отсутствия необходимого оборудования. Иногда используются на столько дорогостоящие конфигурации компьютерного оборудования, что их невозможно продублировать в условиях испытательных лабораторий. Если вы не можете воспроизвести операционную среду, но в то же время можете ее смоделировать, об этом потребуется сообщить в разделе "Подход". Если вы во обще не можете проводить испытания в операционной среде, этот вопрос сле дует рассмотреть в разделе, в котором обсуждаются "риски". • Комбинации настроек или конфигурации аппаратных средств, которые не мо гут быть испытаны за время, выделенное для выхода программного продукта на рынок. Если принято решение ограничить объем тестирования некоторого конкретного свойства, необходимо обсудить данные ограничения и обосновать их в этом разделе. На завершающих стадиях проекта, когда, как правило, на группу тестирования оказывают давление в плане поторопиться с окончанием работ, очень полезно иметь в своем распоряжении документ, в котором оговаривается, что планируется тестиро вать, а что нет. В пылу предфинишной лихорадки люди склонны забывать, какие со глашения были достигнуты — совсем неплохо опереться на этот раздел плана прове дения испытаний при ответах на вопросы, почему то или иное свойство не охвачено тестированием. Разумеется, если проблема возникнет в области, которая не подвер галась тестированию в вашей лаборатории, она должна быть устранена и проверена после выпуска очередной версии программного продукта. Поскольку стоимость ис правления дефектов после сдачи программного продукта в эксплуатации очень вели ка, важно получить по возможности точную оценку рисков, прежде чем принимать решение не проводить испытаний того или иного свойства или конфигурации. в. Подход. Этот раздел плана проведения испытаний предназначен для описания на высоком уровне, как вы намерены проводить испытания программного продукта. Это описание не является подробной спецификацией всех методик испытаний, которые планируется использовать. Подход, описание которого включено в план проведения испытаний, должен быть основано на соображениях, рассмотренных в одном из пре дыдущих разделов, а именно, в разделе "Определение подхода к тестированию". В этот раздел можно включить, например, такие темы: • Статическое тестирование требований и проектная документация • Статическое и динамическое тестирование, которое должно проводиться на стадиях тестирования программных кодов, модулей и проверки взаимодейст вия и функционирования компонентов системы • Тестирование свойств • Испытания при перегрузках/испытания под нагрузкой/тестирование произ водительности • Проверка средств защиты • Тестирование установки/обновления программного продукта • Тестирование средств дублирования/восстановления • Тестирование GUI-интерфейса 92 Часть I. Процесс быстрого тестирования • Регрессивное тестирование • Приемочные испытания: альфа-, бета- и другие виды испытаний на месте • Проверка результатов устранения дефектов • Прерывание испытаний, проводимых в автоматизированном и неавтоматизи рованном режимах • Виды тестирования, проведение которых поручается сторонним организациям • Использование системы отслеживания дефектов для ввода сообщений о неис правностях. Если реализуется лишь некоторая часть той или иной долгосрочной стратегии, например, автоматизация процесса тестирования и тестовых случаев, можно опреде лить, какие конкретные аспекты соответствующего долгосрочного плана будут реа лизованы в текущем проекте проведения испытаний, и сослаться на документ, в ко тором описывается стратегия автоматизации. Например, возможно, планируется применение некоторого инструментального средства или впервые предпринимается попытка автоматизации тестирования GUI-интерфейса. Кроме того, может планиро ваться использование услуг сторонних тестовых организаций для проведения испы таний продукта под нагрузкой и в условиях перегрузки. Этот раздел представляет со бой подходящее место для описания плана на концептуальном уровне и ссылок на любые письменные соглашения, которые удалось заключить со сторонними органи зациями. П р и выполнении тестирования инкрементальных версий программного продукта подход к тестированию каждой версии, по всей видимости, будет одним и тем же. Вы должны обладать возможностью экономить время за счет заимствования больших фрагментов того же раздела плана проведения испытаний, составленного для преды дущих версий, но в то же время тщательно анализировать последствия любых изме нений, внесенных в текущую версию программного продукта. 7. Критерии успешного/неудачного прохождения испытаний. Два к р и т е р и я ус пешного/неудачного прохождения испытаний заслуживают особого внимания при тестировании. Первый относится к индивидуальным тестам. Все тестовые случаи должны снабжаться наборами ожидаемых результатов; по существу, если получены ожидаемые результаты, итог прогона теста считается успешным, если нет — результат прогона теста расценивается как неудачный. Критерии успешного/неудачного про хождения отдельных тестов должны быть включены в сами тестовые случаи, в связи с чем их не следует помещать в план проведения испытаний. Однако не лишним будет указать в этом плане, что определение критериев успешного/неудачного прохожде ния испытаний является неотъемлемой частью тестового случая. Второй тип критериев успешного/неудачного прохождения испытаний имеет отношение к тестированию всего программного продукта. С самого начала вы долж ны определить, что следует считать успешным прохождением стадии тестирования, т.е. когда можно прекратить испытания продукта и наладить его поставку. В некото рых случаях критерий выхода из испытаний определяется в программе испытаний или даже в документе, который содержит формулировки требований, предъявляемых к программному продукту. Вне зависимости от того, что служит источником этих кри териев, полезно дать их четкую формулировку в плане проведения испытаний. |