Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 3. Планирование испытаний 69 Окончание табл. 3.2 Извлекаемая выгода Комментарий Сокращение сроков тестирования Уменьшение времени Единожды разработанные и отлаженные автоматизированные прогона тестов тестовые случаи обычно требуют меньше времени для прогона, чем неавтоматизированные тесты. На анализ результатов Автоматизированные испытания обычно генерируют журналы и тестирования требуется отчеты по испытаниям, меньше времени Меньшие затраты Большая часть автоматизированных средств управления времени на определение тестированием способны быстро генерировать данные о состоянии состояния теста и на тестирования, в которых указываются количество выполненных составление отчетов тестов, количество удачно и неудачно завершенных тестов и другие по испытаниям полезные статистические данные. Планы относительно автоматизации процесса тестирования должны быть вклю чены в раздел Подход плана проведения испытаний. Если ожидается большой объем трудозатрат на проведение автоматизации, возможно, стоит иметь план автоматиза ции тестирования в виде отдельного документа, регламентирующего все аспекты проекта автоматизации: анализ за и против с целью выбора компромиссного реше ния, объем трудозатрат, распределение обязанностей, анализ инструментальных средств и график работ. Определение стратегии тестирования После определения стратегии тестирования можно выходить на следующий уровень детализации процесса планирования испытаний: к определению испытательной сис темы. Понятие испытательной системы относится не только к аппаратным средст вам, необходимым для проведения испытаний, но и к архитектуре тестов и к тесто вым конфигурациям. Обсуждение начнем с архитектуры тестов. Архитектура тестов Архитектура тестов имеет отношение к организационной структуре тестовых случа ев. На практике целесообразна такая организация тестов, когда каждый тест рассчи тан на проверку некоторой четко заданной части функциональных возможностей программного продукта. Если тест закончится неудачей, разработчик легко может повторно прогнать этот тест и воспроизвести обнаруженный дефект, затем проана лизировать его и попытаться выявить причину. В идеальном случае границы обсле дования теста должны быть сужены, а сам тест должен выполнять некоторый мини мальный набор действий, необходимых для того, чтобы вызвать отказ системы. Если основой проводимых испытаний служат требования к программному про-" дукту, то практическим правилом для определения границ обследования конкретного теста может служить критерий, по условиям которого на каждое такое требование полагается, по меньшей мере, один тест. Помимо того, что это правило определяет эффективные размеры тестов, принцип "по меньшей мере, один тест на требование" упрощает поддержку планирования проведения испытаний. На основе анализа тех- 70 Часть I. Процесс быстрого тестирования нического задания можно получить представление о том, сколько нужно новых тес тов для испытания нового программного продукта. Если составлять тесты, руково дствуясь этим принципом, несложно оценить, какое время отымет разработка и про гон тестов, основанных на ранее полученных результатах. Испытания по описанному выше принципу позволяют систематизировать органи зацию тестов. Требования обычно объединяются в группы по функциональным при знакам. Вы можете организовать свои тесты по такому же принципу. Тесты, осущест вляющие проверку готовности к работе технических средств заказчика, могут быть объединены в одну группу; точно так же тесты, проверяющие механизмы установки и наращивания возможностей системы, образуют другую группу. Группа родственных тестов называется тестовым набором (test suite). Каждое требование может состоять из нескольких компонентов. Например, тре бование, регламентирующее процедуру редактирование элементов базы данных конг кретного заказчика, может определять несколько различных сценариев. Тестовый случай (test case) есть набор входных данных тестов, условий выполнения тестов и ожидаемых результатов, который ориентирован на достижение конкретной цели. Тестовый случай представляет собой минимальный тестовый модуль, допускающий независимое выполнение от начала до конца. Отношения, связывающие тестовые наборы, тесты и тестовые случаи, показаны на рис. 3.3 и в табл. 3.3. Рис. 3.3. Архитектура тестов После того, как удалось определить организационную структуру тестов, возникает необходимость дать описание хранилища для хранения тестов и средств управления версиями для последующего воспроизводства тестов. Это хранилище должно обла дать определенными характеристиками: • Специалисты по тестированию, разрабатывающие и осуществляет прогон тес тов, должны иметь простой доступ к хранилищу. Часто в качестве хранилища используется сетевой дисковый накопитель коллективного доступа. Глава 3. Планирование испытаний 71 • С этого хранилища регулярно снимаются копии, а полученные резервные ко пии файлов периодически восстанавливаются с целью проверки правильности функционирования средств копирования и восстановления. Необходимость дублирования всех планов проведения испытаний, тестовых случаев, результа тов тестирования очевидна, тем не менее, зачастую такое дублирование игно рируется. • Должно быть налажено управление версиями, что обеспечит простое выявле ние более старых тестов. Управление версиями при необходимости обеспечи вает воспроизведение любого теста, который когда-либо выполнялся на про граммном продукте. Таблица 3.3. Иерархия тестов Уровень Определение Набор тестов Совокупность тестов, используемых для проверки связанных групп требований и функций. Тест Один или большее число тестов, которые предназначаются для проверки выполнения одного требования или функции. Тестовый случай Наименьший тестовый модуль, который может выполняться самостоятельно от начала до конца. Инструментальные средства тестирования В начале этой главы отмечалось, что решение перейти на автоматическое тестирова ние оказывает влияние на всю стратегию тестирования. В этом разделе основное внимание будет уделяться инструментальным средствам тестирования. Общая стра тегия автоматизации тестирования не ограничивается лишь одним программным продуктом; эта стратегия должна быть глобальной, распространяющаяся на многие проекты, и тщательно интегрированной с процессом тестирования. Таким образом, план проведения испытаний конкретного программного продукта определяет, какой фрагмент общей стратегии автоматизации будет реализован в те кущем проекте. Возможно, потребуется добавить автоматизированное испытание программного продукта под нагрузкой, либо автоматизировать тестирование GUI- интерфейса. Может быть, возникнет желание воспользоваться автоматизированным генератором отчетов, который пересылает результаты тестирования и метрики про граммного продукта на Web-страницу. После определения затрат времени и средств, связанных с оценкой и приобретением (или построением) инструментария, который необходим для завершения автоматизации, и последующей оценки трудозатрат на обучение новому инструментальному средству, скорее всего, будет принято решение о включении в проект только одного-двух инструментальных средств подобного рода. Включение большего числа новых инструментальных средств мало того, что непро дуктивно, но еще и требует существенных затрат. Существует широкое разнообразие инструментальных средств, служащих для под держки тестирования. Некоторые из этих средств перечислены в табл. 3.4. Эта таб лица отображает инструментальные средства на этапы жизненного цикла разработ ки, где они могут использоваться. 72 Часть I. Процесс быстрого тестирования Более подробную информацию по инструментальным средствам тестирования можно найти в [15], [30] и [40]. Каждый перечисленный источник содержит также полезную информацию, связанную с планированием испытаний. Таблица 3.4. Характерные инструментальные средства тестирования Инструментальное средство тестирования Помогает тести ровщику выполнить: Стадия жизненного цикла Средство отслеживания дефектов Средства организации испытаний Средства организации требований Средства обнаружения утечек памяти и ошибок во время выполнения программы Инструментальное средство тестирования исходного кода Анализаторы программных кодов и тестового покрытия Блок сравнения исходных кодов Вводить и сохранять сообщения о дефектах, генерировать метрики программного продукта и итоговые отчеты. Сохранять планы проведения испытаний, тестовые случаи (ручные или автоматизированные), результаты тестирования. Уведомлять о состоянии тестирования. Организовывать и отслеживать требования. Прослеживать тесты до породивших их требований Прогон тестов для обнаружения утечек памяти и ошибок во время выполнения программы. Проверка сложности, цикломатической сложности и соответствия стандартам. Использование инструментальных средств контроля для измерения фрагмента программного кода, покрытого средствами динамического тестирования. Сравнение двух версий исходного кода на предмет их идентичности; если коды не идентичны, определяются их различия. Все стадии Все стадии Соответствующие данные первоначально вводятся на стадии анализа и оценки, но могут быть использованы на протяжении всего жизненного цикла Обычно используется на этапе тестирования программных кодов, модульного тестирования и проверки взаимодействия и функционирования компонентов системы Обычно используется на этапе тестирования программных кодов, модульного тестирования и проверки взаимодействия и функционирования компонентов системы Используется в рамках динамического тестирования на стадии на стадиях проверки взаимодействия и функционирования компонентов или системных испытаний Системные испытания и регрессивное тестирование Глава 3. Планирование испытаний 73 Окончание табл. 3.4 Инструментальное средство тестирования Помогает тести ров щи ку выполнить: Стадия жизненного цикла Генераторы тестовых данных Инструментальные средства реализации сценариев для GUI-интерфейсов Инструментальные средства, обеспечивающие загрузку, измерение рабочих характеристик и предельные нагрузки системы Сетевые инструментальные средства тестирования Средства написания сценариев командной строки Генерация тестовых данных и заполнение баз данных. Запись выполненных пользователем нажатий клавиш и щелчков кнопками мыши, воспроизведение этих пользовательских действий, сравнение результатов тестирования с ожидаемыми результатами. Одновременное выполнение нескольких клиентских программ с целью нагрузки сервера. Выполнение клиентских программ в условиях предельных нагрузок с целью определения момента выхода из строя системы. Оценка способности сервера и сети безошибочно передавать данные. Все этапы тестирования: модульное тестирование проверка взаимодействия и функционирования компонентов, системные и регрессивные испытания Системные и регрессивные испытания Системные и регрессивные испытания Системные и регрессивные испытания Автоматизация команд для настройки Все этапы тестирования: испытательной установки, загрузки тестовых данных или анализа результатов тестирования . модульное тестирование проверка взаимодействия и функционирования компонентов, системные и регрессивные испытания Среда тестирования Среда тестирования состоит из физических средств тестирования, операционной системы, под управлением которой выполняется программный продукт, и вычисли тельной платформы, на которой эксплуатируется программный продукт. Многие компании, занимающиеся тестированием программных продуктов, обзавелись собст венными испытательными лабораториями. Как и автоматизация, развертывание хо рошей испытательной лаборатории связано с долгосрочными инвестициями, кото рые ложатся на множество проектов и требуют отдельных усилий. Разумеется, хоро шего качества тестирования можно добиться и на одном компьютере, установленном в отдельном крохотном помещении, однако общепринятой нормой стало создание испытательных лабораторий, обеспечивающих настройку тестовой среды и условий, в рамках которых производится оценка качества программного продукта. Рекс Блек (Rex Black) в [33] развернул дискуссию вокруг вопросов оснащения и организации испытательных лабораторий. Он предлагает следующее: прежде чем принимать решение относительно необходимости создавать специализированную испытательную лабораторию, потребуется дать ответы на приводимые ниже вопро- 74 Часть I. Процесс быстрого тестирования сы. К созданию специализированной испытательной лаборатории можно присту пать, если вы ответите "да" на хотя бы один из следующих вопросов: • Существует ли необходимость в крупногабаритном стационарном оборудова нии, таком как, например, камера искусственного климата, генераторы данных и анализаторы или приборы измерения электромагнитного излучения? • Должны ли предприниматься специальные меры безопасности по защите кон фиденциальной информации или крупных вложений? • Нужно ли тщательно следить за условиями, в которых проводятся испытания, и регулировать их? Это может, например, означать, что персонал, не прини мающий непосредственного участия в испытаниях, не должен иметь доступа к системным испытаниям во имя предотвращения изменений в условиях испы таний. • Требуется ли поддерживать некоторый набор фиксированных тестовых кон фигураций в течение продолжительного периода времени, например, при под держке итеративного набора версий? Планируя тестирование конкретной версии программного продукта, следует оп ределить, какой аспект общей стратегии построения испытательной лаборатории нужно реализовать. Например, может возникнуть необходимость добавить опреде ленное оборудование, генерирующее данные, либо дополнительные платформы для испытания программного продукта под нагрузкой или при перегрузках. Конфигурации аппаратных средств тестирования Предположим, что тестируемый программный продукт, в соответствии со специфи кацией, должен выполняться на широком наборе сетевых конфигураций, использует несколько различных конфигураций клиентских машин, должен работать под управ лением различных операционных систем и быть доступным из разных браузеров. После исследований числа возможных конфигураций оборудования, могут быть по лучены, например, такие комбинации: • 5 сетевых конфигураций • 10 сочетаний браузеров и операционных систем • 20 комбинаций клиентских конфигураций (центральный процессор, жесткие диски, видеоадаптеры и периферийные устройства) Таким образом, количество возможных тестовых конфигураций есть 5 хЮх20=1000. Если вы рассчитываете на то, что два специалиста по тестированию способны провести запланированные системные испытания на одной конфигурации, то для полного завершения тестирования всех конфигураций вам потребуются 240000 человеко-часов, или 125 человеко-лет! Если необходимые средства и большой штат специалистов по тестированию отсутствует, либо же если просто нет достаточ ного времени, подобное тестирование не имеет смысла. В начале главы мы сформулировали основной принцип тестирования, который гласит: исчерпывающее тестирование программы провести невозможно. То же самое справедливо и в случаях, когда приходится выполнять тестирование нескольких ком бинаций возможных конфигураций системы: невозможно полностью протестировать Глава 3. Планирование испытаний 75 абсолютно все конфигурации системы. Основной способ состоит в установке соот ветствующих приоритетов конфигурациям. А вот дальше уже можно решать, какие конфигурации нужно подвергать полной отладке, а к каким применять частичное тестирование. Установка приоритетов для конфигураций обычно зависит от следующих фак торов: • Частота использования: сколько экземпляров заданной конфигурации скорее всего будет использоваться? ш Риск отказа в работе системы: существуют ли ответственные конфигурации для важных заказчиков? • Вероятность отказа системы: фиксировались ли в прошлом отказы конкретных конфигураций? После определения конфигурации для полного или частичного тестирования сле дующим действием должно быть определение, какие тесты необходимо выполнить на конфигурациях, подлежащих частичному тестированию. Предполагая, что приори теты тестам уже присвоены (см. раздел "Определение объемов тестовых работ" ранее в главе), можно выполнять прогон только тестов с высокими приоритетами на неко торых конфигурациях и тестов с высокой вероятностью отказа на конфигурациях, на которых имели место проблемы в прошлом. После идентификации тестируемых конфигураций потребуется определить их во всех деталях, чтобы специалисты по тестированию могли их установить и воспроиз вести в момент, когда возникнет необходимость прогона тестов. Каждая конфигура ция средств тестирования может быть определена при помощи блок-схемы и специ фикации запасных частей или, если связность между компонентами системы очевид на, конфигурацию можно задать списком компонент. Оценка трудозатрат на тестирование Одной из наиболее важных компонент планирования является оценка трудозатрат и времени, необходимых для тестирования. Затраты на тестирование могут составлять существенную часть сметной стоимости проекта, при этом жизненно важно для успе ха этой операции, чтобы тестирование проводило достаточное число специалистов и у них было достаточно времени на качественное выполнение своих задач. Получение оценки трудозатрат на выполнение проекта можно разбить на пять этапов: 1. Определение задач, которые должны быть выполнены. Эта оценка начи нается с определения работ, которые необходимо выполнить для того, чтобы тестирование программного продукта считалось состоявшимся. В рамках не которых методологий на этом этапе вполне достаточно разбить работу на за дачи. Если используются менее формальные методы, то результатом этого этапа может быть простой список задач. 2. Оценка трудозатрат на решение отдельных задач и всего жизненного цик ла тестирования. Каждая задача, выявленная на первом этапе, требует для своего решения определенных трудозатрат, представляющих собой объем ра бот, необходимых для выполнения соответствующей задачи. Трудозатраты 76 Часть I. Процесс быстрого тестирования представлены в виде произведения количества исполнителей на затраченное ими время и измеряется в таких единицах как человеко-день или человеко- месяц. Существуют различные методы оценки трудозатрат, часть из которых рассматривается далее в разделе. 3. Определение времени, требуемого для решения каждой задачи и длитель ности всего жизненного цикла тестирования. Время, необходимое для ре шения задачи, измеряется в днях, неделях или месяцах. Время, необходимое для выполнения той или иной задачи, зависит от количества исполнителей, но как будет показано ниже, эта зависимость не обязательно линейная. Сум марная продолжительность работ по тестированию зависит от продолжи тельности решения отдельных задач, однако это не простое суммирование, поскольку некоторые задачи можно решать одновременно с другими. 4. Построение подробного расписания и поэтапного графика каждой тесто вой задачи. На основе результатов трех предыдущих этапов можно построить график выполнения работ, возможно, в виде диаграммы Ганта (Gantt), и вы числить сумму наиболее важных временных значений. 5. Оценка рисков невыполнения графика работ и формулировка планов их снижения. Примите во внимание проблемы, которые могут возникнуть при решении задач за запланированные промежутки времени, и предусмотрите средства решения этих проблем. Прежде чем приступить к более подробному анализу перечисленных шагов, важно понять, насколько точными могут быть наши оценки. В самом начале проекта (перед выявлением и изучением требований) очень трудно определить, какой окажется стоимость проекта. Фактическая стоимость проекта становится известной только на завершающей стадии проекта. На начальной стадии проектирования может иметь место как недооценка, так и переоценка фактической стоимости проекта, причем приблизительно в четыре раза. После того, как все требования будут проанализиро ваны и начальная фаза планирования завершена, оценка стоимости проекта обычно отличается от окончательной, фактической стоимости проекта примерно в два раза [40]. Точность оценки иллюстрируется графиком, показанным на рис. 3.4. Ввиду неточностей, свойственных процессу оценки, целесообразно периодически возвращаться к оценке трудозатрат и графика выполнения работ и считать это не отъемлемой частью организации работ по тестированию. Если затраты времени и трудозатраты начинают превышать исходные оценки, желательно как можно быст рее поставить в известность об этом факте руководство проекта, а не ждать, когда эта ситуация переродится в настоящий кризис. Следующие несколько разделов данной главы дают обзор процесса оценки. Пред лагаются альтернативные стратегии выполнения трех основных действий из приве денного выше списка, причем вместе со всеми за и против. Более подробно техноло гии оценки, особенно те из них, которые относятся к категории алгоритмической оценки, будут рассматриваться в главе 12. Хорошим справочным пособием по оценке является уже ставшая классикой [40]. Кроме того, внимание заслуживает также и от носительно недавняя публикация [33], в которой описывается модель оценки СОСОМО II. |