Вопросы объединения процессов тестирования и кадрового обеспечения 142 Часть П. Технологии быстрого тестирования и советы 159
 Скачать 4.53 Mb.
|
|
Глава 5. Системные испытания 129 Идентификатор дефекта: Кем обнаружен: Дата обнаружения: Обнаружен в сборке: Сообщение о дефекте Степень серьезности дефекта (катастрофический, крупный, незначительный): Идентификатор теста: Краткое описание проблемы: Подробное описание проблемы: Как воспроизвести проблему: (Если был использован недокументированный тест, подробно опишите методику тестирования. При необходимости дайте схему конфигурации средств тестирования.) Рис. 5.3. Шаблон сообщения об ошибке Правильно составленное сообщение о дефекте обладает совершенно другими свойствами: • О н о описывает фактический дефект программного продукта. • В нем четко описаны признаки проблемы через отклонения поведения систе мы от нормы. • . О н о содержит процедуру пошагового воспроизведения проблемы. Анализ обнаруженных дефектов Если бы процесс обнаружения и исправления дефектов был совершенным, то необ ходимость в анализе дефектов отпала бы сама по себе. К сожалению, человеческий фактор вступает в действие уже на стадии системных испытаний, впрочем, как и на других этапах цикла разработки. Ошибки могут неожиданно обнаружиться в тесто вых случаях, в конфигурациях средств тестирования или в интерпретации данных тестирования. Когда обнаружен дефект, необходимо проследить за тем, чтобы свое временно был назначен исполнитель, ответственный за его устранение, что обеспе чит исправление дефекта и проверку результатов этого исправления. Один из способов проверки результатов тестирования и предотвращения возник новения ошибок при отслеживании дефектов предусматривает еженедельный анализ дефектов, обнаруженных во время системных испытаний. Назначение анализа де фектов состоит в том, чтобы: 130 Часть I. Процесс быстрого тестирования • Выявить все очень серьезные дефекты, требующие немедленного внимания • Выявить все дефекты, которые требуют более глубокого исследования или не могут быть воспроизведены. • Определить изменения состояний дефектов. Анализ дефектов проводится не так, как пересмотр программных кодов или дру гих рабочих продуктов. В большинстве случаев экономически нецелесообразно вести учет времени, затраченного исполнителями на подготовку к анализу, к тому же роли участников не расписаны так же четко, как в случае перепроверки программных ко дов и тестовых случаев. Тем не менее, полезно выработать подходящую процедуру проведения анализа дефектов. Часто в испытательных лабораториях совещания, по священные анализу дефектов, проводят ведущие инженеры, при этом дефекты, тре; бующие анализа, представлены в рамках отчетного доклада, который можно рас сматривать как высокоуровневую информацию о дефектах. П р и м е р формата отчет ного доклада, посвященного дефектам, показан на рис. 5.4. Анализ дефектов проекта Дата анализа: день/месяц/год Участники: Иденти фикатор дефекта В1233 В1234 В1235 Состоя ние Новый Новый Новый Серьез ность дефекта Катаст рофиче ский Крупный Незначи тельный Дата обнару жения День/ месяц/ год День/ месяц/ год День/ месяц/ год Краткое описание дефекта Нарушение функций резервиро вания/восстановления - невоз можен поиск данных после ре зервирования. Нельзя открыть резервный эк ран из меню; обходной путь - использование командной стро ки. Проблема удобства использо вания - не работает вызов функции поиска через клавишу ускоренного доступа. Действие Исправить Исправить Отложить Примечания: В1235 — эта проблема требует изменений в архитектуре программного продукта, в силу чего ее решение откладывается до следующей версии. Рис. 5.4. Пример отчета по результатам анализа дефектов Глава 5. С и с т е м н ы е и с п ы т а н и я 131 В примере сообщения на рис. 5.4 приводится список всех дефектов с указанием их идентификаторов, а также содержится информация об их состоянии, степени серь езности и дате обнаружения. Дается краткое описание проблем, но если потребуется подробное описание конкретного дефекта, возникает потребность в первоначальном сообщении о дефекте. Одним из ключевых полей в отчете является столбец "Дейст вие". В поле предполагаемого действия можно определить какое-то значение еще до того, как будет выполнен анализ, однако основной результат совещания заключается в определении конкретных состояний, которые должны быть указаны в этом столбце. В сообщении, приведенном на рис. 5.4, резервируется место для ввода данных анализа, для перечисления участников, а также поле "Примечания", которое может использоваться для документирования обоснования решений, принятых на совеща нии. Если по результатам анализа все поля заполняются корректно, итоговый отчет послужит источником для того, чтобы расписать совещание по минутам. Прогон тестов До сих пор основное внимание уделялось дефектам, ибо обнаружение дефектов явля ется основной причиной для прогона тестов. Далее мы сосредоточимся на изучении самого процесса тестирования, следуя обзорной диаграмме, которая показана на рис. 5.1. Вход в системные испытания При передаче группе тестирования новой сборки применяется некоторый набор критериев входа в испытания. Перед началом системных испытаний должен быть разработан и утвержден план проведения испытаний и тестовые случаи. Группа раз работки должна закончить тестирование модулей и проверку взаимодействия и функционирования компонентов этой сборки. О н и должны исправить все катастро фические дефекты, обнаруженные во время испытаний, и только затем передавать сборку группе тестирования. Первый тест, прогоняемый на новой сборке, — это обычно тест "на герметич ность", который служит для проверки возможности установки программы на целевой платформе, возможности успешного обновления и определения факта работоспо собности, по меньшей мере, базовых функций. П р и ч и н а проведения теста на герме тичность довольно проста: если программа не работает на целевой платформе, ее просто невозможно тестировать. К сожалению, нередки случаи, когда новая сборка не проходит испытания на гер метичность, особенно если перед ее передачей тестировщикам проверка взаимодей ствия и функционирования компонентов была выполнена в недостаточных объемах. Разработчики могли настолько сосредоточиться на том, чтобы заданные функции успешно работали в среде разработки, что до проблем системного уровня, таким как, скажем, установка программы и ее работа в среде заказчика, просто не доходили руки. 132 Часть I. Процесс быстрого тестирования Циклы тестирования Вход в системное тестирование должно означать начало совместных работ при уча стии групп разработчиков и тестировщиков. Тестировщики выполняют прогон за планированных тестов, выявляют дефекты и пишут сообщения о дефектах. Разра ботчики читают сообщения о дефектах, воспроизводят проблемы и исправляют про граммный код. Вопрос заключается вот в чем: как исправления передаются в группу тестирования? Ответ на этот вопрос зависит от цикла создания программного обеспечения. Раз работчики регистрируют проделанные исправления в системе управления конфигу рациями в рамках подготовки к периодическим построениям сборок. Построение сборки обычно выполняется на базе ежедневного или еженедельного цикла, после чего блок передается группе тестирования в соответствии с их потребностями. Возникают различные вопросы относительно того, как часто группа тестирова ния может принимать новые сборки. Если сборки приходят слишком часто, устойчи вость среды тестирования может оказаться нарушенной — потребуется время на уста новку новых сборок, прогон тестов на герметичность и проверку того, что дефекты, которые были обнаружены в предыдущей версии сборки, исправлены. Если "смесь сборок" будет излишне "пестрой", то попросту не хватит времени на прогон доста точного количества тестов, дабы обеспечить эффективное обнаружение дефектов в соответствии с выбранной методологией тестирования. С другой стороны, если сборки поступают слишком медленно, то и в этом случае нельзя достичь высокой эффективности обнаружения дефектов. Довольно часто из менения, вносимые в программный код, приводят к тому, что обнаруживаются новые дефекты, либо выявляются дефекты, которые и раньше были в сборке, но были за маскированы теперь уже устраненными дефектами. Это значит, что включать новые сборки в цикл тестирования нужно достаточно часто, чтобы можно было обнаружить следующую партию дефектов. То, как часто доводится принимать новые сборки от разработчиков, зависит от нескольких факторов, в том числе и от сложности программного обеспечения, от численности штата тестировщиков, от процентного отношения автоматизированных тестов к общему числу тестов. Например, если можно прогнать все тесты в течение трех дней, вероятно, имеет смысл принимать новые сборки каждые четыре-пять дней. В этом случае три дня можно отвести на прогон тестов, а день или около того — на проверку исправлений дефектов, на прогон специализированных тестов в некото рых многообещающих областях, на подготовку отчетов об устранении дефектов и на регулярный анализ дефектов. В идеальном случае цикл тестирования (test cycle) состоит из прогона полного набо ра тестов на некоторой сборке программного обеспечения. План проведения испы таний обычно предусматривает выполнение некоторого количества циклов тестиро вания, причем на каждый цикл затрачивается определенное время. Например, этот план может предусматривать выполнение трех или четырех циклов длительностью в одну или две недели каждый. На практике тестирование не всегда проводится с соблюдением плана проведения испытаний. Первый цикл тестирования может продолжаться одну-две недели, однако может потребоваться большое число сборок, чтобы тестирование оказалось доста точно устойчивым и можно было прогнать большую часть тестов. Когда очередная Глава 5. С и с т е м н ы е и с п ы т а н и я 133 новая сборка поступает на тестирование, принимается решение, нужно ли выпол нить повторный прогон всех тестов с самого начали или продолжать тестирование в прежней последовательности. Обычно более эффективной оказывается выборочная проверка новой сборки, которая дает возможность убедиться в том, что ее можно остановить и запустить в работу, а обнаруженные ранее дефекты уже устранены. По сле этого тестирование продолжается без повторного прогона всех тестов. Подходя щим моментом для очередного запуска тестирования может служить начало нового тестового цикла. Это означает, что может произойти так, что на промежуточной сборке не будет выполнен полный набор тестов. Исключением из этой стратегии яв ляется завершающая сборка программного обеспечения, так называемая "золотая сборка", на которой прогоняются все тесты. Один из способов отслеживания тестов, прогон которых выполнен на заданной сборке, предусматривает ведение списка прогона тестов на сборке для каждой сборки тестируемого программного обеспечения. П р и м е р списка прогона тестов на сборке показан на рис. 5.5. В этом списке в качестве заголовка указан идентификатор сборки и дата прогона теста; список прогона тестов, по существу, представляет собой список того, "что нужно сделать" каждому специалисту по тестированию. Если планируется применение испытательных комплексов или рабочих станций коллективного поль зования, этот список позволит избежать конфликтов, если в нем для каждого специа листа по тестированию будет указываться испытательный комплекс, на котором должны запускаться тесты. Если же возникнут конфликты требований на использо вание испытательного комплекса, то в таких случаях может потребоваться разработ ка рабочего графика для комплексов. В списке прогона тестов на сборке один стол бец резервируется под краткое изложение результатов тестирования. Список прогона тестов на сборке Идентификатор сборки: Дата начала тестирования: Номер теста 1. 2. 3. 4. Идентификатор теста А10 А11 В11 В11 Имя тести- ровщика JimD. Jim D. BobZ. BobZ. Конфигурация средств тестирования 1А на системе 1 1А на системе 1 2В на системе 2 2В на системе 2 Результат (P/F/NR) Pass (тест прошел) Pass (тест прошел) Fail (тест не прошел) Not run (тест не выполнялся) Рис. 5.5. Пример списка прогона тестов на сборке 134 Часть I. Процесс быстрого тестирования Список прогона тестов на сборке может оказаться исключительно полезным при частой передаче сборок в группу тестирования. На основе информации о тестах, прогон которых выполнялся на предыдущих сборках, список можно составить так, чтобы обеспечить эффективное покрытие тестами свойств программного продукта на некоторой последовательности сборок. Список прогона тестов на сборке помогает также приспосабливаться к ситуации, когда в заданной сборке присутствуют дефек ты, которые не позволяют обеспечить покрытие конкретной области программного кода. Как только блокирующий дефект будет исправлен, можно сосредоточить свое внимание на этой области и обеспечить высокую степень покрытия. Регистрация результатов тестирования Когда тестировщик получает задание прогнать некоторую последовательность тестов на конкретной сборке, он должен следовать пошаговой методике тестирования, ого воренной в тестовом случае, и протоколировать результаты тестирования. Как видно из примера тестового случая, приведенного в главе 4 (рис. 4.2), в нем отводится спе циальное место, куда тестировщик заносит результаты выполнения каждого шага, равно как и исход испытания (прошел, не прошел). Кроме того, выделяется также и место, куда заносится идентификатор любого дефекта, обнаруженного во время ис пытаний. Один из способов регистрации результатов прогона тестов предусматрива ет использование формата тестового случая, который показан на рис. 4.2. Другой способ заключается в применении журнала испытаний, изображенного на рис. 5.6. Этот журнал испытаний удобен для сведения воедино результатов всех тес тов, выполненных одним специалистом по тестированию на одной сборке. В нем также есть место для регистрации общего результата "прошел/не прошел/тест не выполнялся", а также для идентификатора любого дефекта, обнаруженного во время прогона теста. Предусматривается также место для комментариев — обычно в нем протоколируется информация, которая может впоследствии оказаться полезной при воспроизведении проблемы или для понимания условий, в которых проблема наблю далась. Независимо от того, какой метод будет использоваться для регистрации результа тов тестирования, очень важно, чтобы результат каждого теста был зарегистрирован и сохранен в безопасном архиве. Заархивированные результаты тестирования могут позже понадобиться в силу различных причин: подтверждение факта проведения тестирования, поддержка воспроизведения проблемы или хронологические записи, обосновывающие трудозатраты на разработку программного продукта. Шаблоны списка прогона тестов на сборке, тестовых случаев и журналов испыта ний приводятся в данной книге в форме текстовых документов, тем не менее, их можно реализовать и как часть системы ввода данных через Web либо инструмен тальных средств организации испытаний. Использование автоматизированных средств для сохранения тестовых случаев, прогона тестов и генерации отчетов по испытаниям может существенно повысить качество построения эффективной стра тегии системных испытаний. Глава 5. Системные испытания 135 Журнал испытаний Дата: день/месяц/год Цикл тестирования: 1 Идентификатор сборки: В020202 Конфигурация средств тестирования: 1А Тестирование выполнял: Jim D. Тест № 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Идентификатор теста А10 А11 А12 А13 А14 А15 В1 В2 ВЗ В4 Исход Pass/Fail/Not run Р Р Р F Р F NR NR NR NR Идентификатор дефекта XY1233 XY1234 Комментарий Эта проблема характер на для конфигурации средств тестирования. Тестовый набор забло кирован дефектом XY1234. Заблокирован Заблокирован Заблокирован Рис. 5.6. Журнал испытаний Составление отчетов по результатам тестирования Обычно требуются два вида отчетов по результатам тестирования. Первый из них — это регулярный доклад о ходе тестирования, который часто делается на еженедель ных совещаниях. На таких совещаниях представители всех коллективов, ответствен ных за успех проекта, отчитываются о проделанной работе. Доклад о ходе тестиро вания обычно состоит из отчета о ходе работ по тестированию и отчетного доклада об обнаруженных дефектах. Доклад о ходе работ должен дать ответ на вопрос "на сколько далеко мы продвинулись в тестировании?". Отчетный доклад об обнаружен ных дефектах предназначен для выяснения степени успешности тестовых мероприя тий в контексте обнаружения дефектов. Одна из его целей состоит в получении те кущей оценки качества тестируемого программного продукта. Эти отчеты рассмат риваются в двух следующих разделах. 136 Часть I. Процесс быстрого тестирования Второй тип доклада по результатам тестирования представляет собой формаль ную сводку результатов тестирования, которая составляется по окончании систем ных испытаний. Доклад второго типа предназначен для документирования результа тов тестирования с тем, чтобы в будущем можно было получить ответ на вопросы о том, что подвергалось тестированию, какие были получены результаты, и какого мнения придерживалась группа тестирования относительно готовности продукта к выпуску. Этот отчет рассматривается далее в разделе "Отчетный доклад". Отчет о ходе работ по тестированию Отчет, показанный на рис. 5.7, дает представление о ходе работ по тестированию. Из информации о дате, идентификаторе сборки и цикле тестирования видно, какой программный продукт проходит тестирование и приблизительно насколько прово димое тестирование отклоняется от плана. Последний столбец отчета, % Run ("про цент прогонов"), есть мера того, сколько прогонов тестов было выполнено относи тельно общего количества запланированных тестов. Число тестов, прогон которых завершился неудачно, указывается в столбце "# Fail" (тест не прошел) — этот показа тель дает приближенные данные о том, сколько дефектов будет зафиксировано в проверяемом программном продукте. Столбец "# Not Run" (тест не выполнялся) по казывает, сколько тестов заблокировано по причине неустраненных дефектов или других проблем. Общее количество тестов приводится в столбце "# Tests", а количе ство успешно пройденных тестов - в столбце "# Pass". Отчет о ходе работ по тестированию Дата составления отчета: день/месяц/год Идентификатор сборки: В123 Цикл тестирования: 2/3 Дата начала тестовых работ: месяц / день / год Тестовый набор Ввод данных Редактирование Резервирование и восстановление Обмен данными Итого # Tests 20 15 25 18 78 #Pass 12 10 12 8 42 # Fail 2 4 6 8 20 # Not Run 6 1 7 2 16 % Run 7 0 % 9 3 % 7 2 % 8 9 % 7 9 % Рис. 5.7. Пример отчета о ходе работ по тестированию Отчет об устранении дефектов Другим видом анализа положения дел в тестировании является отчет об устранении дефектов, пример которого представлен на рис. 5.8. В этом отчете показано общее число неустраненных дефектов как функция от времени в неделях. Временная ось Глава 5. С и с т е м н ы е и с п ы т а н и я 137 часто градуируется в датах, а не в "неделя 1", "неделя 2" и т.д. Количество дефектов заданной серьезности (катастрофические, крупные и незначительные) в этом отчете выглядит как столбик соответствующей высоты в выбранном масштабе, а также ука зывается явно в числовой форме. Например, на третьей и четвертой неделе тестиро вания в программном продукте было зафиксировано 4 катастрофических дефекта, а на второй неделе —32 незначительных дефекта. Общее количество неустраненных дефектов есть показатель качества программ ного продукта. Вполне понятно, что большое количество дефектов высокого уровня серьезности не говорит в пользу качества программного продукта. Окончательным определителем качества программного продукта является то, насколько он устраива ет заказчика. Разумеется, заказчик вряд ли будет доволен, если в предоставленной ему версии продукта присутствует слишком много дефектов. Иногда имеются смягчаю щие вину обстоятельства, когда наиболее важной является скорость поставки про дукта, а заказчик согласен даже на версию с дефектами, лишь бы что-то работало. По мере того как работы по тестированию приближаются к завершению, есть все основания ожидать, что число неустраненных дефектов будет уменьшаться, посколь ку разработчики исправляют их, а тестировщики проверяют, насколько правильно были выполнены исправления. Степень серьезности дефектов по мере продвижения тестирования также имеет тенденцию к снижению. Пример, представленный на рис. 5.8, необычен тем, что количество неустраненных катастрофических и крупных де фектов остается практически на одном уровне, в то время как число незначительных дефектов существенно снижается. Более типичным случаем является быстрое устра нение дефектов с высоким уровнем серьезности, в то время как менее серьезные де фекты остаются не устраненными в течение более длительного времени; возможно даже, что их устранение откладывается до будущих выпусков. 138 Часть I. Процесс быстрого тестирования Другой отчет, который часто используется при анализа состояния проекта, — от чет об анализе дефектов, представленный в таблице 5.5. Диаграмма на рис. 5.4 доста точно точно характеризует ход тестовых работ и служит показателем качества про граммного продукта, однако все решения относительно того, исправления каких де фектов будут включаться в выпуск, и в каком порядке дефекты будут устраняться, требуют более подробной информации о неустраненных дефектах. В некоторых компаниях функции анализа проекта и анализа дефектов объединены, причем оба вида анализа регулярно ставятся на повестку дня заседаний группы контроля за вне сением изменений ССВ (change control board). Как правило, в состав группы ССВ входят представители руководства, отдела маркетинга, организаций, которые зани маются разработкой и тестированием. Отчетный доклад В отчетном докладе должны быть отражены следующие моменты: • Какой программный продукт тестировался • Насколько фактические работы по тестированию отклонились от плана прове дения испытаний • Насколько график работ и трудозатраты отличаются от соответствующих пока зателей в плане проведения испытаний • Какие дефекты были обнаружены • Какие дефекты остались неустраненными по завершении тестовых работ и что с ними делать дальше. О т ч е т н ы й доклад по результатам тестирования не обязательно должен содержать результаты прогона каждого теста, в то же время он может ссылаться на такие ре зультаты, если они где-то накапливаются и архивируются. Сбор и архивирование всех тестовых результатов — это одно из преимуществ, которое дает использование серийных инструментальных средств управления тестированием. Если это инстру ментальное средство сводит результаты тестирования в единый документ, то на этот документ можно сослаться в отчетном докладе. Один из способов указать, какой продукт подвергается тестированию, предусмат ривает использование набора окончательных вариантов журналов испытаний (рис. 5.6) на каждом цикле испытаний. Этот способ позволяет показывать результаты про гона каждого теста без использования пошагового отчета наподобие приведенного на рис. 4.2 в главе 4. Другой полезный отчет можно получить за счет компиляции полного набора данных о ходе работ по тестированию (см. рис. 5.7). Важно понять, насколько фактический процесс тестирования отклоняется от плана проведения испытаний, поскольку план проведения испытаний представляет собой утвержденное определение объемов тестирования и соглашение о том, сколь ко сотрудников принимают участие в этих работах, и сколько времени будет затраче но на выполнение работ. Особенно важно отметить, какие области не были охвачены тестированием в полном объеме, поскольку эти области являются источниками рис ков снижения качества программного продукта и источниками распространения де фектов в различные части продукта. Если тестирование проходит в соответствии с планом, этот факт можно просто отметить в отчетном докладе; если имеют место Глава 5. С и с т е м н ы е и с п ы т а н и я 139 етные отклонения от плана, необходимо отметить их в специальном заявлении. информация полезна при учете затраченных ресурсов, и в то же самое время ит исходными данными для дальнейшего планирования. Если производится сбор ^^ д дставительных статистических данных для сравнения запланированных и факти- S ^ n K H x трудозатрат, то она благоприятствует возможности повышения точности бу- ^™ их оценок. Несмотря на то что база данных отслеживания дефектов должна содержать пол ный набор данных о дефектах, обнаруженных во время тестирования программного продукта, сводку дефектов, обнаруженных во время системных испытаний, целесо образно включить в отчетный доклад. В таком случае всем сторонам, заинтересован ным в успехе разработки, не потребуется обращаться в базу данных дефектов за све дениями о ходе работ по тестированию и о качестве программного продукта. Окон чательная версия отчета по результатам анализа дефектов (рис. 5.4), в котором пока заны все обнаруженные дефекты и их окончательные состояния, а также оконча тельная редакция отчета о категориях неустраненных дефектов (рис. 5.8) являются полезными дополнениями отчетного доклада о тестировании. Отчетный доклад о результатах тестирования должен содержать список всех не устраненных дефектов с указанием того, будут ли они исправлены в более поздних выпусках или же их исправление откладывается на неопределенное время. Дальней шие выпуски программного продукта все еще будут содержать неустраненные дефек ты до тех пор, пока они не будут исправлены. В силу этого обстоятельства желательно вести за такими дефектами наблюдение, чтобы не тратить дополнительные усилия на их выявление в будущих выпусках продукта. В плане проведения испытаний будущих выпусков должны присутствовать ссылки на список неустраненных дефектов; это позволит тестировщикам понять, что их ожидает во время тестирования нового вы пуска программного продукта. П р и м е р отчетного доклада о результатах тестирования, котором реализованы все идеи из этого раздела, включен в третью часть книги. Критерий выхода из испытаний и готовность выпуска программного продукта Существует множество способов определить подходящий момент для останова испы таний, одни из них простые, другие же — очень сложные. Вот некоторые из условий, которые используются для принятия решения о прекращении испытаний: • Время, отведенное на т е с т и р о в а н и е , истекло. Если зафиксирован некоторый предельный срок, неизбежно наступает день, когда вы просто прекращаете все работы, связанные с тестированием, и задаете себе вопрос: "Насколько плох программный продукт?". Любой другой метод останова придает гораздо боль шую уверенность в качестве поставляемого программного продукта. • З а в е р ш е н ы все з а п л а н и р о в а н н ы е ц и к л ы т е с т и р о в а н и я . Если план проведе ния испытаний предусматривает три цикла, то в конце третьего цикла вы, по- видимому, зададите тот же вопрос: "Насколько плох программный продукт?" Если план проведения испытаний выполнен, то тестовое покрытие, скорее 140 Часть I. Процесс быстрого тестирования всего, будет лучше, чем в случае, когда просто не хватило времени для доведе ния тестирования до конца. • Профиль дефектов соответствует критерию выхода из испытаний. Если в результате выполнения алгоритма SWEEP (Software Error Estimation Program — Программа оценки ошибочности программного продукта) становится ясно, что предел, т.е. количество неустраненных ошибок на тысячу строк программ ного кода, достигнут, появляются все основания прекратить тестирование. (Подробную информацию по алгоритму SWEEP можно найти в главе 11.) В по добной ситуации опять-таки придется задаться вопросом: "Насколько плох программный продукт?" Принимая решение прекратить работы по тестированию, следует учесть несколь; ко факторов, которые играют важную роль при оценке готовности программного продукта к поставкам. Обычным набором факторов, которые определяют готовность программного продукта к поставкам, являются: • Количество катастрофических дефектов, обнаруженных в процессе тестиро вания, которые остаются неисправленными • Общее количество дефектов, которые не были исправлены • Процентное отношение количества тестов, которые завершились успешным исходом, к числу всех запланированных тестов • Количество тестов, прогон которых не может быть выполнен, поскольку они заблокированы дефектами. С целью выработки оценки готовности выпуска отлаженного программного про дукта проводятся специальные совещания. В некоторых организациях оценку готов ности определяет группа тестирования; в других организациях совещание проводит руководитель проекта либо руководитель разработки. В любом случае в задачу группы тестирования входит представление результатов тестирования и выработка реко мендаций относительно готовности продукта к поставкам. Хотя оценка готовности может проводиться формально, подобно тому, как выполняется инспекция про граммного кода, в любом случае потребуется зафиксировать имена участников и при нятое ими решение, касающееся поставок программного продукта. Чтобы оценка готовности содержала результаты и рекомендации организации, проводившей тес тирование, эта оценка должна содержать ссылку на отчетный доклад по результатам тестирования. Что дальше В этой главе мы обсуждали вопросы отслеживания дефектов, проведения системных испытаний и составления отчетов по результатам тестирования. Рассматривались следующие ключевые моменты: • Обзор системных испытаний • Обнаружение и отслеживание дефектов • Определение состояния дефектов • Основные особенности отслеживания дефектов |