Страница:
Из собственного опыта
Однажды, в очередной раз сообщив боссу о продвижении проекта и заверив его в том, что всё в порядке, я установил сборку и нажал на кнопку «выполнить наиболее критичную функцию проекта». Она не работала. Выяснилось, что уже много дней сборка была сломанной, хотя большинство об этом не знало. По нашему графику мы уже давно прошли период разработки и тестирования этой функции, и коль уж однажды она работала как часы, то должна была работать и сейчас. Сейчас мы поняли, что если наиболее критичная функция продукта была нестабильна, то состояние остальных функций, которые тогда работали, сейчас также неизвестно. Все были так заняты написанием нового кода и тестированием новых дополнительных функций, что никто не заметил того, что продукт больше не работал. Бета-версия была отложена на несколько недель.
В тот момент я и моя команда поняли всю важность автоматизации тестирования для нашего проекта. Мы начали писать автоматизированные регрессивные тесты для ключевых функций, запускать их каждый день и немедленно устранять серьёзные неполадки.
Чаще всего автоматизацию критикуют из-за времени, необходимого для создания хороших тестовых заданий. Да, тестовые задания требуют материальных и трудовых затрат, но, созданные на совесть, они приносят большие дивиденды. Я рекомендую выделить нескольких специалистов по автоматизации, чьей задачей в цикле разработки будет только написание автоматизированных тестовых заданий.
Время, необходимое для поддержания адекватности тестов будущим выпускам, также является объектом нападок. Особенно это относится к автоматизации тестирования пользовательского интерфейса. Если между выпусками в вашем пользовательском интерфейсе происходят серьёзные изменения, то тестовые сценарии могут не работать и потребовать больших усилий для их совершенствования. По этой причине при автоматическом тестировании следует сосредоточиться на функциях, не относящихся к пользовательскому интерфейсу. Автоматизируйте тестирование ключевых функций, а не деталей пользовательского интерфейса.
Отличная идея — строить продукт, изначально рассчитанный на тестирование. Если вы минимизируете свою зависимость от пользовательского интерфейса и создадите альтернативные способы ввода данных и просмотра выходных данных, то будете защищены от изменений в интерфейсе. Например, рассмотрите возможность использования файлов, записей реестра, параметров командной строки и СОМ-интерфейсов передачи входных данных. Для вывода данных вы можете использовать текстовые файлы, распечатку значений переменных или готовые компоненты, специально предназначенные для этой цели. Я не говорю о том, что пользовательский интерфейс не должен быть протестирован, — просто приоритетным должно быть автоматизированное тестирование ключевых функций продукта. Однако если вы решили автоматизировать тестирование пользовательского интерфейса, начните с «контактного» тестирования. При этом, чтобы проверить функциональность всего интерфейса, вызываются и закрываются все диалоговые окна.
Из собственного опыта
Работая в NuMega над BoundsChecker 5, мы знали, что команда, создающая внутренние компоненты, значительно опережает команду, занятую пользовательским интерфейсом. И мы должны были быть уверены в том, что сможем тестировать продукт, даже если у нас не будет пользовательского интерфейса месяц или больше. Команда, отвечающая за внутренние компоненты, разрабатывала простые драйверы, вызывавшие подсистему с данными, необходимыми для работы. Используя эти драйверы, мы могли тестировать продукт и убедиться, что он твёрд, как скала, задолго до того, как пользовательский интерфейс был готов. Помимо раннего тестирования продукта, эти драйверы предоставляли надёжный и простой способ автоматизированного тестирования подсистем разных выпусков.
Команды, процессы и культура
У вас есть опыт создания качественного ПО? Ваши технологические процессы производительны и эффективны или они обычно занимают кучу времени и ресурсов? Учитывается ли вопрос качества каждым человеком, участвующим в разработке ПО? Как далеко вы готовы пойти, чтобы обеспечить качество? О качестве заботится каждый или есть такие, которые говорят: «это не мой участок»?Эти вопросы могут определить, насколько группа успешна в разработке качественного ПО. Иногда говорят, что высшее руководство не желает брать на себя обязательства, необходимые для создания качественных продуктов. С другой стороны, они, может быть, и хотят поставлять качественный продукт, но не уверены в том, что у команды есть для этого эффективная система. Они считают, что увеличение количества процессов контроля качества всего лишь приведёт к дополнительным затратам времени и повысит расходы без улучшения продукта. Одной из задач этой книги является определение конкретного набора процессов контроля качества, которые позволят поставлять лучшие продукты в кратчайшие сроки, насколько это возможно. Однажды обзаведясь системой, в которой вы уверены, вы вероятнее всего станете поддерживать и постоянно использовать именно её.
Из собственного опыта
В NuMega менеджер проекта определял качество как главный приоритет для каждого члена команды. Он устанавливал продукт и использовал его почти ежедневно, фиксировал ошибки и обсуждал обнаруженные неполадки со своей командой на совещании, в обеденное время и встреч в коридоре. Это подгоняло всю команду, и каждый её участник включался в работу. Тестированием и оценкой результатов занимались все. Все осознали: ошибки — это зло, и с ними надо бороться. Мы давали всем понять, что до самого конца проекта о качестве будут помнить и не забудут после продажи продукта.
Что, когда и как тестировать
Тестирование эффективно, только если понятно, какую часть продукта, когда и как тестировать. Вроде вопросы простые, но если вы работаете в жёстком графике и с ограниченными людскими ресурсами, то вам нельзя терять время, тестируя объект слишком глубоко или, наоборот, слишком поверхностно. Нужно сосредоточиться на проверке в следующих ключевых областях продукта:
• процедуре установки;
• функциональных возможностях;
• интеграции функций;
• производительности.
Тестирование в этих областях должно происходить постоянно в течение всего цикла разработки. Однако для эффективного выполнения этой процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей. Короче говоря, для каждого крупного мероприятия в процессе разработки вы должны обладать набором хорошо определённых процессов и процедур, которые будут отлавливать проблемы. Эти процессы и процедуры источают в себя следующие компоненты:
• Входные тесты
Проверяют ПО перед подтверждением внесённых изменений.
• Ежедневные базисные тесты
Выполняются для каждой сборки программы.
• Тесты по завершении функции
Проверяют функцию сразу же после завершения работы над ней.
• Тесты при стабилизации и интеграции
Проверяется интеграция функций через определённые интервалы времени.
• Бета-тестирование и кандидаты на выпуск
Производится внешнее тестирование продукта через определённые интервалы времени.
В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.
• совместимостью между всеми машинами;
• простотой установки, запуска и выполнения;
• проверять ключевые функции или подсистемы продукта.
Входные тесты представляют наибольшую ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите работу остальных разработчиков, которые могут взять исходные файлы с ошибками, после внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в ежедневную сборку и сбой базисного теста.
Из собственного опыта
Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.
Заметьте: ежедневные базисные тесты не имели своей целью проверку незначительных функций, таких как проверка работоспособности предварительного просмотра перед печатью, или вызов справочной системы по нажатию клавиши H — все это легко проверить вручную. Мы концентрировались на ключевых функциях проекта.
Как и ежедневная сборка, данные о базисных тестах (предоставляемые в виде отчётов) совместно используются всей командой так, что каждому понятно, есть ли в продукте проблемы или нет. Если да, руководители разработчиков и тестировщиков должны провести расследование, быстро определить причину проблемы и назначить специалиста для её разрешения. Для этого специалиста разрешение данной проблемы должно быть наивысшим приоритетом.
Тестировщики почти всегда будут находить проблемы. Для их устранения в графике разработки должно быть отведено некоторое время в период разработки компонента или в ближайшем периоде стабилизации. Я советую выделять немного времени в обоих периодах. Скажем, в пятидневном задании должен быть предусмотрен один день как раз для устранения неполадок, то есть 20% «лишнего времени».
Как и для остальных крупных компонентов, для проверки процедуры установки нужно выделить оперативную команду. То есть задача создания и проверки процедуры установки назначается технологам и тестировщикам. Эта задача должна входить в план проверки качества и выполняться регулярно в течение цикла разработки. Помните, что обычно установка — очень сложная часть программы, она требует безупречной работы на самых разных конфигурациях. И здесь автоматическое тестирование незаменимо.
Вот список основных тестов процедуры установки, которые должны быть выполнены для любого продукта, который вы собираетесь поставить.
• Операционные системы
Проверка на всех операционных системах, поддерживаемых вашей программой.
• Сервисные пакеты
Проверка со всеми сервисными пакетами ОС, поддерживаемых вашей программой.
• «Чистая» установка
Проверка установки продукта на ОС, где не установлены предыдущие версии программы.
• «Грязная» установка
Проверка установки продукта на ОС с установленными предыдущими версиями программы.
• Конфигурации продукта
Проверка поддержки процедурой установки различных конфигураций продукта.
• Функции программы установки
Проверка собственных возможностей процедуры установки (онлайновая регистрация, кнопка «Далее», кнопка «Назад», кнопка «Отмена» и т.д.).
• Тест удаления
Проверка процедуры удаления продукта.
Хотя хорошая процедура установки прежде всего предназначена для пользователей, вы тоже увидите, что она играет важную роль в ускорении работы по контролю качества. Так как команда тестировщиков должна работать с самой последней сборкой программы, у вас постоянно должна быть надёжная процедура установки, которую они будут использовать. Ведь вы не хотите, чтобы команда тратила время на редактирование реестра, копирование файлов, редактирование параметров конфигурации и т.д. Вам нужно направить их усилия на тестирование продукта, а не на ручные процедуры, в которых легко могут появиться ошибки.
Надёжная и простая в использовании процедура установки будет полезна для всех членов команды, а не только для тестировщиков. Каждый сможет установить продукт для своих собственных целей. Техническим писателям потребуется установка для создания описания функций продукта, разработчикам — для отслеживания «жучков», проблем с производительностью и оценки пользовательского интерфейса. Ваша команда должна работать с продуктом, а не бороться с его установкой.
Из собственного опыта
Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.
• завершению всех отложенных тестов отдельных функций;
• проверке интеграции функций;
• проверке текущей производительности и нагрузки;
• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;
• тестированию бета-версий и кандидатов на выпуск.
Завершение каждого из этих этапов очень важно для начала работы над следующей частью проекта. Давайте подробнее рассмотрим каждый из них.
Не забудьте создать набор тестов, которые будут служить в качестве эталонных тестов для продукта, и выполнять их регулярно в цикле разработки. Выполняйте стрессовые тесты и оценивайте производительность системы по завершении определённых этапов и в моменты синхронизации и интеграции. Именно для этого разработка разбита на этапы. Выполнение тестов в эти моменты — лучший способ раннего обнаружения ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундаменте, содержащем ошибку.
Из собственного опыта
Во время разработки BoundsChecker одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики производительности продукта, добавив несколько строчек кода в критичные функции. Чтобы обнаружить источник проблем с производительностью, мы использовали несколько тестовых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture. Оно создавало 256 параллельных потоков и запрашивало и освобождало десятки тысяч блоков памяти в куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизилась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных тестов и сравнивать показатели производительности. С таким уровнем контроля мы обычно могли определять снижение производительности в сборке предыдущего дня. Весьма неплохо!
Это также подходящий момент решить, что имеет смысл улучшить во время следующего периода стабилизации и интеграции. Смотрите на фазу стабилизации и интеграции, как на проверку ПО и команды, которая его создаёт. Вы должны оценить производительность и программ, и людей и провести все необходимые изменения.
• попытаться добавить покупателя;
• некорректное добавление покупателя (проверка полей);
• повторное добавление одного и того же покупателя;
• редактирование сведений о покупателе (всех полей, ни одного поля);
• редактирование сведений о несуществующем покупателе;
• некорректное редактирование сведений о покупателе;
• удаление существующего покупателя;
• удаление несуществующего покупателя.
Завершив тестирование интеграции, вы будете обладать сведениями о производительности приложения. Как долго добавить покупателя? А удалить? Получить сообщение об ошибке? Хотя может быть несколько причин плохой производительности, если вы не можете быстро добавить покупателя в маленькой базе данных, возможно, имеется проблема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая структура БД? Нет ли претензий к промежуточному уровню? Чтобы это проверить, через определённое время нужно проводить мониторинг, устанавливать планку производительности для основных транзакций и регулярно сравнивать результаты, чтобы знать, что вы на верном пути.
Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, остановитесь и исправьте всё, что мешает двигаться вперёд.
Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протестировать в сборке, прежде чем предоставить её сторонним организациям. Конечно, вы не сможете заново протестировать весь продукт. Полное тестирование и доводка продукта займёт месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для большинства небольших и средних проектов норма составляет 7-10 дней.) В планы тестирования бета-версий и кандидатов на выпуск нужно включить:
• выполнение всего набора автоматических тестов;
• выполнение набора ручных тестов, включая:
* нормальную установку/проверку лицензии (полностью вручную);
* тестирование базовых функций продукта (полностью вручную);
* тестирование производительности и нагрузки (полностью вручную);
* выборочную проверку на всех поддерживаемых платформах;
* другие специфические разделы проекта.
Этот список послужит вам хорошей отправной точкой, но для каждого пункта вы должны определить конкретный сценарий тестирования. И если все эти тесты будут успешно пройдены, вы выпустите вашу программу. Если вы не можете успешно выполнить тесты, устраните неполадки и повторите процесс.
Одна из черт грамотного цикла тестирования бета-версии или кандидата на выпуск заключается в его предеказуемости. Вы должны знать, сколько времени займёт выполнение автоматических и ручных тестов. Имея эту информацию, вы сможете точно предсказать, сколько времени займёт тестирование следующей бета-версии или кандидата на выпуск. Зная, сколько времени нужно для тестирования другой сборки, вы сможете оценить риск и стоимость внесения дополнительных изменений.
• процедуре установки;
• функциональных возможностях;
• интеграции функций;
• производительности.
Тестирование в этих областях должно происходить постоянно в течение всего цикла разработки. Однако для эффективного выполнения этой процедуры вам нужно знать, когда и как проводить тесты в каждой из этих областей. Короче говоря, для каждого крупного мероприятия в процессе разработки вы должны обладать набором хорошо определённых процессов и процедур, которые будут отлавливать проблемы. Эти процессы и процедуры источают в себя следующие компоненты:
• Входные тесты
Проверяют ПО перед подтверждением внесённых изменений.
• Ежедневные базисные тесты
Выполняются для каждой сборки программы.
• Тесты по завершении функции
Проверяют функцию сразу же после завершения работы над ней.
• Тесты при стабилизации и интеграции
Проверяется интеграция функций через определённые интервалы времени.
• Бета-тестирование и кандидаты на выпуск
Производится внешнее тестирование продукта через определённые интервалы времени.
В оставшейся части этой главы мы поговорим об этих пяти ключевых разновидностях тестирования.
Входное тестирование
Позволяет разработчикам проверить важные функции в локальной сборке перед помещением кода в основную базу. Хорошие тесты должны обладать:• совместимостью между всеми машинами;
• простотой установки, запуска и выполнения;
• проверять ключевые функции или подсистемы продукта.
Входные тесты представляют наибольшую ценность для случаев, когда вы вносите исправления в критичную или сложную часть системы. Если входной тест выполняется неудачно, вы можете самостоятельно найти и устранить неполадку. Вы не нарушите работу остальных разработчиков, которые могут взять исходные файлы с ошибками, после внесения этих файлов вами в систему. Также входные тесты предотвращают внесение критических ошибок в ежедневную сборку и сбой базисного теста.
Ежедневное базисное тестирование
Ещё один способ реализации стратегии «тестировать как можно раньше», помимо входных тестов, — ежедневные базисные тесты. Так как вы строите продукт каждый день, то и тестировать его нужно ежедневно. Базисные тесты — это основной набор автоматизированных регрессивных тестов, проверяющих, что ключевые функции продукта работают. Они обеспечивают создание работоспособной сборки и гарантию того, что за прошедшие 24 часа не было значительных ухудшений. С добавлением новых ключевых компонентов базисные тесты также следует улучшать и расширять.Из собственного опыта
Продукт BoundsChecker компании NuMega хорошо известен за свою способность находить утечки памяти в приложениях C/C++. Ежедневные базисные тесты для этой программы включали в себя приложение BugBench, в котором было множество утечек памяти, а также других отвратительных «жучков». Мы использовали эту программу-пример для генерации ошибок, которые BoundsChecker должен был уметь искать. Если BoundsChecker находил не все ошибки в программе-примере, тогда по определению сборка считалась плохой. Нам нравилось получать по утрам «ещё дымящийся отчёт о тесте» с результатами проверки сборки минувшей ночи. Такой процесс позволял нашему проекту почти всегда быть стабильным и работающим, поскольку наши базисные тесты сразу находили критические проблемы.
Заметьте: ежедневные базисные тесты не имели своей целью проверку незначительных функций, таких как проверка работоспособности предварительного просмотра перед печатью, или вызов справочной системы по нажатию клавиши H — все это легко проверить вручную. Мы концентрировались на ключевых функциях проекта.
Как и ежедневная сборка, данные о базисных тестах (предоставляемые в виде отчётов) совместно используются всей командой так, что каждому понятно, есть ли в продукте проблемы или нет. Если да, руководители разработчиков и тестировщиков должны провести расследование, быстро определить причину проблемы и назначить специалиста для её разрешения. Для этого специалиста разрешение данной проблемы должно быть наивысшим приоритетом.
Тестирование реализованной функции
Итак, ваша задача — тестировать каждую функцию, как только работа над ней будет завершена. Для каждой важной функции должны быть назначены разработчик и тестировщик, которые вместе будут отвечать за своевременную и качественную поставку этой функции. Такое назначение будет способствовать совместной работе, обмену информацией и идеями, а успех или неудача разделятся поровну. Для каждой существенной функции должны быть заготовлены автоматические тесты, но вы также должны быть готовы, если понадобится, протестировать их вручную. В вашем плане контроля качества должна быть изложена вся информация так, чтобы было абсолютно понятно, когда и как тестируется каждая функция.Ключевые функции
Основные усилия команды, отвечающей за контроль качества, направляются на тестирование ключевых функций. Их можно тестировать как автоматически, так и вручную, но это надо делать сразу после того, как разработчик закончил кодирование. Чем раньше начать тестирование фикции, тем быстрее вы объективно оцените продвижение проекта и, если обнаружатся проблемы, начнёте их решать.Тестировщики почти всегда будут находить проблемы. Для их устранения в графике разработки должно быть отведено некоторое время в период разработки компонента или в ближайшем периоде стабилизации. Я советую выделять немного времени в обоих периодах. Скажем, в пятидневном задании должен быть предусмотрен один день как раз для устранения неполадок, то есть 20% «лишнего времени».
Установка
К сожалению, процедура установки — самая «забытая» часть любого продукта. Люди редко думают о том, что установка — это важнейшая функция программы, и поэтому не уделяют ей должного внимания. Если вы не протестируете процедуру установки, можете пожалеть: этот компонент программы используют все. Единственный способ создать великолепное первое впечатление — это разработать отличную процедуру установки. Иначе пользователь с первых минут будет недоволен вашей программой.Как и для остальных крупных компонентов, для проверки процедуры установки нужно выделить оперативную команду. То есть задача создания и проверки процедуры установки назначается технологам и тестировщикам. Эта задача должна входить в план проверки качества и выполняться регулярно в течение цикла разработки. Помните, что обычно установка — очень сложная часть программы, она требует безупречной работы на самых разных конфигурациях. И здесь автоматическое тестирование незаменимо.
Вот список основных тестов процедуры установки, которые должны быть выполнены для любого продукта, который вы собираетесь поставить.
• Операционные системы
Проверка на всех операционных системах, поддерживаемых вашей программой.
• Сервисные пакеты
Проверка со всеми сервисными пакетами ОС, поддерживаемых вашей программой.
• «Чистая» установка
Проверка установки продукта на ОС, где не установлены предыдущие версии программы.
• «Грязная» установка
Проверка установки продукта на ОС с установленными предыдущими версиями программы.
• Конфигурации продукта
Проверка поддержки процедурой установки различных конфигураций продукта.
• Функции программы установки
Проверка собственных возможностей процедуры установки (онлайновая регистрация, кнопка «Далее», кнопка «Назад», кнопка «Отмена» и т.д.).
• Тест удаления
Проверка процедуры удаления продукта.
Хотя хорошая процедура установки прежде всего предназначена для пользователей, вы тоже увидите, что она играет важную роль в ускорении работы по контролю качества. Так как команда тестировщиков должна работать с самой последней сборкой программы, у вас постоянно должна быть надёжная процедура установки, которую они будут использовать. Ведь вы не хотите, чтобы команда тратила время на редактирование реестра, копирование файлов, редактирование параметров конфигурации и т.д. Вам нужно направить их усилия на тестирование продукта, а не на ручные процедуры, в которых легко могут появиться ошибки.
Надёжная и простая в использовании процедура установки будет полезна для всех членов команды, а не только для тестировщиков. Каждый сможет установить продукт для своих собственных целей. Техническим писателям потребуется установка для создания описания функций продукта, разработчикам — для отслеживания «жучков», проблем с производительностью и оценки пользовательского интерфейса. Ваша команда должна работать с продуктом, а не бороться с его установкой.
Из собственного опыта
Не забудьте о процедуре удаления! В NuMega команды разработчиков и тестировщиков оценили значимость процедуры удаления. Ведь она позволяет получить чистую систему и не тратить время на ручное удаление записей реестра и файлов из системного каталога.
Тестирование при стабилизации и интеграции
До этого момента в цикле разработки тестирование было направлено на проверку отдельных функций. Но в период стабилизации и интеграции внимание уделяется:• завершению всех отложенных тестов отдельных функций;
• проверке интеграции функций;
• проверке текущей производительности и нагрузки;
• исправлению всех серьёзных ошибок, изъянов проекта или архитектурных проблем;
• тестированию бета-версий и кандидатов на выпуск.
Завершение каждого из этих этапов очень важно для начала работы над следующей частью проекта. Давайте подробнее рассмотрим каждый из них.
Завершение тестирования отдельных функций
Задача номер один — завершение всех тестов, которые могли быть отложены. Это вполне нормально, когда какой-то оперативной команде для завершения всех тестов требуется больше времени, даже после 4-6 недель упорной работы. Используйте это время для выполнения всех тестов, которые ещё не были выполнены, так вы сможете поддерживать параллельное тестирование до самого конца проекта.Проверка интеграции
Тестирование интеграции должно быть определено заблаговременно как часть плана тестирования. Лучший способ сделать это — создать набор примеров использования, предпочтительно с точки зрения пользователя, описывающих, как различные функции должны работать вместе. Перед тестированием вы должны быть уверены, что заданные функции находятся в рабочем состоянии и в принципе могут использоваться вместе. Именно сейчас время их совместной проверки, и если они не станут работать, то настанет время исправления ошибок.Тестирование производительности и нагрузки
Хотя конечный продукт нельзя оценить до тех пор, пока вся система не будет собрана воедино, для оценки прогресса или его отсутствия в цикле разработки могут проводиться наблюдения и предварительные измерения.Не забудьте создать набор тестов, которые будут служить в качестве эталонных тестов для продукта, и выполнять их регулярно в цикле разработки. Выполняйте стрессовые тесты и оценивайте производительность системы по завершении определённых этапов и в моменты синхронизации и интеграции. Именно для этого разработка разбита на этапы. Выполнение тестов в эти моменты — лучший способ раннего обнаружения ошибок и их исправления до того, как вы продолжите строить ваш продукт на фундаменте, содержащем ошибку.
Из собственного опыта
Во время разработки BoundsChecker одной из главных проблем была производительность. Ничего не стоило полностью поменять характеристики производительности продукта, добавив несколько строчек кода в критичные функции. Чтобы обнаружить источник проблем с производительностью, мы использовали несколько тестовых приложений, которые нагружали BoundsChecker до предела. Одно из таких приложений называлось Torture. Оно создавало 256 параллельных потоков и запрашивало и освобождало десятки тысяч блоков памяти в куче. В течение всего периода разработки мы запускали Torture (и подобные программы), чтобы определить, не снизилась ли производительность продукта. Так как мы хотели видеть результат сразу, мы стали каждую ночь запускать Torture как часть наших автоматических регрессивных тестов и сравнивать показатели производительности. С таким уровнем контроля мы обычно могли определять снижение производительности в сборке предыдущего дня. Весьма неплохо!
Коррекция после тестирования
Период стабилизации и интеграции также позволяет исправить серьёзные ошибки до перехода к следующему набору функций. Тестирование функций и их интеграции выявит множество ошибок, а это именно то, что нужно. Вы сможете заранее устранить эти ошибки, что увеличит продуктивность дальнейшей работы. Но время на поиск и исправление этих ошибок должно быть учтено в графике.Оценка после тестирования
Когда период стабилизации и интеграции подходит к концу, не забудьте оценить результаты и произвести изменения. Усовершенствовать ли аппаратную часть? Нужно лучше тестировать подсистемы? Требуется ли лучшее определение API? Больше людей? Какие бы изменения ни требовалось провести, это нужно сделать сейчас.Это также подходящий момент решить, что имеет смысл улучшить во время следующего периода стабилизации и интеграции. Смотрите на фазу стабилизации и интеграции, как на проверку ПО и команды, которая его создаёт. Вы должны оценить производительность и программ, и людей и провести все необходимые изменения.
Пример тестирования
Рассмотрим простой пример, чтобы показать, как все эти области работают вместе. Допустим, вы создаёте Web-приложение и проходите фазу стабилизации и интеграции. Вы уверены в работоспособности определённых функций. Скажем, вам нужно только создание, редактирование и удаление покупателей. Но чтобы заставить эти функции работать, нужно потрудиться. Их работа затрагивает пользовательский интерфейс, Web-сервер, промежуточные звенья и базу данных. Все эти компоненты взаимосвязаны. В этом случае проверка интеграции может состоять из таких заданий:• попытаться добавить покупателя;
• некорректное добавление покупателя (проверка полей);
• повторное добавление одного и того же покупателя;
• редактирование сведений о покупателе (всех полей, ни одного поля);
• редактирование сведений о несуществующем покупателе;
• некорректное редактирование сведений о покупателе;
• удаление существующего покупателя;
• удаление несуществующего покупателя.
Завершив тестирование интеграции, вы будете обладать сведениями о производительности приложения. Как долго добавить покупателя? А удалить? Получить сообщение об ошибке? Хотя может быть несколько причин плохой производительности, если вы не можете быстро добавить покупателя в маленькой базе данных, возможно, имеется проблема, требующая дополнительного исследования. Есть ли проблемы с драйверами БД? Может быть, у вас плохая структура БД? Нет ли претензий к промежуточному уровню? Чтобы это проверить, через определённое время нужно проводить мониторинг, устанавливать планку производительности для основных транзакций и регулярно сравнивать результаты, чтобы знать, что вы на верном пути.
Задача тестирования интеграции — убедиться в том, что к завершению первого этапа функциональность продукта удовлетворительна. Если это так, вы готовы приступить к следующему крупному этапу. Если нет, скажем, вы не можете добавить, отредактировать или удалить покупателя, остановитесь и исправьте всё, что мешает двигаться вперёд.
Тестирование бета-версий и кандидатов на выпуск
Тестирование бета-версий и кандидата на выпуск — ключевой этап проекта. Бета-тест — это возможность дать клиентам проверить и оценить ваше ПО за месяцы до его выпуска или применения в реальной рабочей среде. В большинстве проектов во второй половине цикла разработки предусматривается 2-3 бета-периода. Во время каждого такого периода привлекаются десятки или сотни, а иногда тысячи пользователей. Кандидат на выпуск потенциально является последней сборкой продукта, и он ещё важнее. Если последний круг тестирования завершился без серьёзных проблем, то он представляет ПО, которое вы намереваетесь предоставить потребителям. (Подробно о бета-тестировании см. главу 13, о тестировании кандидатов на выпуск — главу 14.)Одна из главных задач при работе с бета-версиями и кандидатами на выпуск — определить, что следует протестировать в сборке, прежде чем предоставить её сторонним организациям. Конечно, вы не сможете заново протестировать весь продукт. Полное тестирование и доводка продукта займёт месяцы, если не годы. Вместо этого вам нужно составить очень конкретный и хорошо продуманный план, который будет выполнен в очень сжатые сроки. (Для большинства небольших и средних проектов норма составляет 7-10 дней.) В планы тестирования бета-версий и кандидатов на выпуск нужно включить:
• выполнение всего набора автоматических тестов;
• выполнение набора ручных тестов, включая:
* нормальную установку/проверку лицензии (полностью вручную);
* тестирование базовых функций продукта (полностью вручную);
* тестирование производительности и нагрузки (полностью вручную);
* выборочную проверку на всех поддерживаемых платформах;
* другие специфические разделы проекта.
Этот список послужит вам хорошей отправной точкой, но для каждого пункта вы должны определить конкретный сценарий тестирования. И если все эти тесты будут успешно пройдены, вы выпустите вашу программу. Если вы не можете успешно выполнить тесты, устраните неполадки и повторите процесс.
Одна из черт грамотного цикла тестирования бета-версии или кандидата на выпуск заключается в его предеказуемости. Вы должны знать, сколько времени займёт выполнение автоматических и ручных тестов. Имея эту информацию, вы сможете точно предсказать, сколько времени займёт тестирование следующей бета-версии или кандидата на выпуск. Зная, сколько времени нужно для тестирования другой сборки, вы сможете оценить риск и стоимость внесения дополнительных изменений.
Кто должен тестировать?
За тестирование должны отвечать все участники проекта, невзирая на лица и отведённые им роли. При использовании продукта с любой целью и в любой форме делать это надо с критической точки зрения. Кем бы вы ни были: менеджером проекта, радостно рассматривающим новую функцию, автором руководства пользователя, проверяющим, как будет работать пример, или специалистом по инженерной психологии, устанавливающим продукт для проверки пользовательского интерфейса — вы должны отслеживать, искать и сообщать о проблемах качества.
Имея сжатые сроки и ограниченные ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах тестировщиков дефицит кадров проявляется чаще всего. Так что убедитесь в том, что ваши разработчики, технические писатели, инженерные психологи, менеджер продукта, менеджер проекта, вице-президент или студенты, проходящие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой ценой заставьте их сообщать о найденных проблемах.
Имея сжатые сроки и ограниченные ресурсы, трудно ожидать, что одна группа сможет провести всю работу по тестированию, особенно если учитывать, что в командах тестировщиков дефицит кадров проявляется чаще всего. Так что убедитесь в том, что ваши разработчики, технические писатели, инженерные психологи, менеджер продукта, менеджер проекта, вице-президент или студенты, проходящие летнюю практику, будут искать проблемы каждый раз, когда они используют продукт для своих нужд. Любой ценой заставьте их сообщать о найденных проблемах.