Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

354 Глава 7

Описание входов

Указывают все входы/условия, требуемые для выполнения набора тестов. Входы могут

указываться значениями входных данных или именами (для таблиц, файлов транзакций).

Указывают все используемые базы данных, файлы, сообщения, области памяти. Указывают

любые требуемые зависимости между входами (например, по времени).

Описание результатов

Указывают все результаты и характеристики (например, время ответа), требуемые для

тестируемого элемента. Для каждого результата или характеристики указывают точные

значение (с допустимой погрешностью).

Условия среды

Указывают требования к характеристикам аппаратной конфигурации.

Указывают требования к системному и прикладному ПО, необходимому для выполне-

ния наборов тестов (например, ОС, компиляторы, инструменты тестирования, СУБД и др.).

Прочее

Любые другие специальные требования или требования к квалификации персонала.

Особые процедурные требования

Указывают любые ограничения, касающиеся процедур выполнения наборов тестов (на-

пример, настройки, условия вмешательства оператора, правила останова тестов).

Зависимости между тестами

Перечисляют идентификаторы наборов тестов, которые должны выполняться перед дан-

ным набором тестов, и указывают причины.

Более простая структура описания набора тестов может быть представлена в виде

таблицы MS Excel (рисунок 7.10).

Дата: __________ Автор_____________

Идентификатор теста ______________Тип _______________

Описание _______________________________________________

ПС/Версия/ Модуль/Объект _______________________________

Цель тестирования: ______________________________________

Приоритет: _____________________________________________

Предусловие выполнения:_________________________________

Описание тестовых условий: ______________________________

а. Правильные условия____________________________________

б. Не правильные условия__________________________________

Тестовые данные:

а. для правильных условий:_________________

б. для не правильных условий:_____________________

Ожидаемое поведение (результаты):

а. для правильных условий:________________________

б. для не правильных условий:______________________

Полученные результаты:

Отклонения:

Идентификатор проблемы: _________

Идентификатор тестовой процедуры: _______________

Рис. 7.10. Упрощенная структура описания набора тестов

Стандартная структура больше подходит для формального тестирования (при прове-

дении испытаний), для тестирования критических компонентов или тестирования в рамках

процессов V&V. В остальных случаях – можно использовать для описания наборов тестов

структуру, представленную на рисунке 7.10.

Глава 7 355

Процедура тестирования – это документ, содержащий подробные инструкции для

выполнения наборов тестов. Структура этого документа, рекомендуемая стандартом IEEE

Std. 829, приведена ниже, а на рисунке 7.11 представлена более простая структура описания

процедуры тестирования.

Идентификатор процедуры тестирования

Уникальный идентификатор процедуры.

Назначение

Указывают назначение процедуры и ссылки на связанные с ней наборы тестов, а также

ссылки на соответствующие разделы документации (например, на процедуры использова-

ния тестируемого элемента).

Специальные требования

Указывают перечень всех процедур, предшествующих данной, требования к квалифика-

ции исполнителей, требования к аппаратно-программной среде и инструментам.

Шаги выполнения процедуры

Перечисляют действия, необходимые для выполнения процедуры:

- регистрация. Указывают методы и форматы протоколирования результатов выполне-

ния тестов, фиксации проблем и любых событий, касающихся выполнения процедуры;

- установка/настройка. Указывают действия, необходимые для подготовки к выполне-

нию процедуры.

- запуск. Указывают действия, необходимые для начала выполнения процедуры.

- выполнение. Указывают действия, необходимые во время выполнения процедуры.

- измерения. Указывают методы выполнения измерений результатов работы теста (на-

пример, указывают, как измеряется время выполнения).

- приостановка. Указывают, как прервать выполнение теста.

- возобновление. Указывают любые предусмотренные точки возобновления работы про-

цедуры и действия, требуемые для возобновления процедуры в каждой точке.

- останов теста. Указывают действия, нужные для завершения работы процедуры.

- восстановление. Описывают действия, необходимые для восстановления среды.

непредвиденные события. Описывают действия, предпринимаемые при возникновении

аномальных событий при выполнении процедуры.

Дата: ___________Автор:______________

Идентификатор процедуры:____________ Тип ____________

Описание:________________________________

Цель тестирования (тестовое требование):___________ Приори-

тет:______________

Файл спецификации _________________

Идентификаторы тестов:

__________________

Рис. 7.11. Упрощенная структура процедуры тестирования

Помимо документов, рекомендуемых стандартами, для объединения логически свя-

занных процедур могут разрабатываться сценарии тестирования.

Предлагаемая структура описания сценария тестирования приведена ниже.

356 Глава 7

Идентификатор сценария:____________________

ПС/Версия: ______________________

Общее описание:

Указывают, как использовать сценарий

Предусловия выполнения:

Указывают действия по настройке среды и подготовке к выполнению тестов (например,

должны быть заполнены файлы или БД).

Постусловия выполнения:

Что необходимо делать после выполнения сценария (удалить тестовые записи и др.).

Выполнение:

Указывают пошаговые инструкции для выполнения каждого набора тестов с отметками

о результатах.

Время:

Указывают ожидаемое время выполнения сценария.

Примечания:

Указывают любые расхождения между полученными и ожидаемыми результатами, а

также описывают любые проблемы, возникшие при выполнении тестов.

Задача 5.3. Подготовка тестовых данных.

Заключается в подготовке наборов данных (например, в файлах, БД), необходимых

для выполнения тестов. Тестовые данные должны быть максимально приближены к реаль-

ным и включать допустимые, граничные и недопустимые значения.

Задача 5.4. Подготовка журналов по тестированию.

Журналы предназначены для регистрации выполняемых тестов. Заполнение журна-

лов осуществляется по ходу тестирования.

Структура журнала тестирования, рекомендуемая стандартом IEEE Std. 829, пред-

ставлена ниже. При желании, можно использовать структуру журнала, предлагаемую стан-

дартом ДСТУ 2851 [53].

Идентификатор журнала

Уникальный идентификатор журнала

Общие сведения

Перечисляют тестируемые элементы с указанием их версии и ссылки на паспорт объекта

Указывают условия аппаратно-программной среды тестирования.

Регистрация работ и результатов

Указывают дату и время начала и завершения работы (запуска и завершения теста), а

также фамилию оператора, регистрирующего события.

Описание выполнения

Указывают идентификаторы выполняемых процедур тестирования и ссылки на их опи-

сания. Перечисляют участников: тестировщиков, операторов, наблюдателей и их функции.

Результаты выполнения процедуры

Для каждого теста фиксируют видимые результаты (ожидаемые / не ожидаемые), а так-

же место их размещения (экран, файл.). Отмечают успешно или не успешно выполнен тест.

Среда тестирования

Указывают любые условия среды, касающиеся выполнения теста.

Аномальные события

Для каждого события, появление которого не ожидалось, фиксируют предыдущее и по-

следующее событие/условие. Фиксируют любые обстоятельства, касающиеся невозможно-

сти начать выполнение процедуры или ее завершить.

Идентификаторы отчетов о проблемах

Перечисляют идентификаторы отчетов о проблемах (инцидентах), при их возникнове-

нии.

Глава 7 357

Задача 5.5 Проверка тестовых документов.

Цель проверки - гарантировать, что все цели тестирования (тестируемые функции и

области риска отказа) охвачены наборами тестов. Эта задача может также выполняться в

рамках процесса верификации.

Для проверки может использоваться таблица покрытия (рисунок 7.12)

Функция

Идентификатор Описание

Оценка

риска

Идентификатор

набора тестов

Рис. 7.12. Таблица покрытия функций наборами тестов

При проверке можно использовать контрольный вопросник, включающий, например,

такие вопросы:

•

Охватывают ли наборы тестов входные данные с максимальными, минимальны-

ми и нормальными значениями?

•

Включены ли в набор граничные и недопустимые данные/условия? Можно ли

придумать другие неправильные входные условия, не охваченные тестами?

•

Включены ли в набор тестов тесты проверки сообщений об ошибках?

•

Включены ли тесты для обнаружения возможных ошибок?

В инструментах управления тестированием с каждой функцией, указанной в иерар-

хии целей, можно связать набор тестов и процедуры.

7.5.7. Автономное и интеграционное тестирование

Задачи, решаемые на этом шаге тестирования, описаны ниже петитом.

Задача 6.1. Автономное тестирование.

Выполняется программистом параллельно с разработкой и отладкой программных

компонентов, с использованием основных методов тестирования (функционального и

структурного). Методами функционального тестирования программист должен гарантиро-

вать, что каждая функция компонента протестирована на допустимых, граничных и недо-

пустимых данных. Методами структурного тестирования, он должен убедиться в том, что

все операторы кода и условия протестированы не менее 1 раза, все вызовы и обращения к

процедурам, модулям и функциям компонента протестированы не менее 1 раза. Методом

предположения о дефектах могут быть разработаны дополнительные тесты для выявления

ожидаемых ошибок.

Подробные рекомендации по выполнению автономного тестирования приведены в

стандарте ANSI/IEEE Std. 1008 [14].

Задача 6.2. Повторное тестирование после устранения дефектов.

Выполняется для проверки того, что исправления сделаны правильно, и что новые

ошибки не внесены.

На уровне автономного тестирования отказы и дефекты не фиксируются в форме от-

четов о проблемах, а результаты исправления отмечаются в журнале (в таблице Excel).

Задача 6.3. Анализ результатов автономного тестирования.

Для определения подверженных дефектам модулей и уточнения оценок риска отказа

могут использоваться метрики подсчета дефектов и распределения дефектов по модулям

(профили дефектов). Для таких модулей разрабатываются дополнительные тесты.

По результатам автономного тестирования разработчик готовит отчет, в котором

указываются:

- достигнутая полнота по метрикам структурного и функционального покрытия;

- состояние всех протестированных модулей с указанием оставшихся дефектов;

- недостаточно протестированные модули и области (данные и условия среды) и

причины, по которым они не были протестированы (нехватка времени, низкий риск отказа);

358 Глава 7

- возможные риски отказа, связанные с оставшимися дефектами;

- реальное время и трудоемкость тестирования.

В случае преждевременного завершения процесса из-за недостатка времени или об-

наружения дефектов, требующих изменений в проекте, необходимо отразить эту информа-

цию в отчете с указанием всех не устраненных дефектов.

Задачи 6.1- 6.3 выполняются циклически (кроме подготовки отчета) до дос-

тижения установленного критерия завершения тестирования. Минимальные цели,

которые должны быть достигнуты при автономном тестировании:

- 100% покрытие операторов и не менее 85% условий;

- все запланированные функциональные тесты прошли (все области дан-

ных, подверженные отказам охвачены);

- нет не устраненных серьезных дефектов;

- общая устойчивая работа компонента в среде разработки.

Задача 6.4. Интеграционное тестирование.

Интеграция и тестирование может выполняться программистами или группой тести-

рования, в зависимости от условий интеграции и «распространенности» проекта, но в лю-

бом случае интегрируемые компоненты должны находиться под контролем конфигурации.

Это означает, что все изменения в совместно используемых библиотеках и схемах

БД, а также интерфейсах между компонентами должны выполняться согласованно, а обна-

руженные отказы фиксироваться в журнале тестирования.

Задача 6.5. Повторное тестирование после устранения дефектов.

Задача выполняется циклически до достижения установленного критерия завершения

тестирования (версия ПО собрана). Повторяются только те тесты интеграции, при выполне-

нии которых были обнаружены проблемы.

Задача 6.6. Анализ результатов интеграционного тестирования.

Решение задачи заключается в том, чтобы определить степень готовности интегриро-

ванной версии ПО к функциональному тестированию.

По результатам интеграционного тестирования группа тестирования готовит отчет и

паспорт объекта тестирования (версии ПО).

Структура паспорта протестированного объекта, рекомендуемая IEEE Std. 829,

представлена ниже. Паспорт объекта подтверждает его готовность к тестированию и слу-

жит сопроводительным документом этого объекта.

Идентификатор паспорта объекта

Уникальный идентификатор объекта

Передаваемые элементы

Перечисляют передаваемые на тестирование элементы с указанием их версии и ссылок

на соответствующие документы по этим элементам и план тестирования. Указывают ответ-

ственных за передаваемые элементы.

Местонахождение элементов

Указывают носители, на которых размещены элементы, имена передаваемых файлов и

библиотек, пути доступа.

Состояние элементов

Указывают состояние передаваемых элементов, любые отклонения от проектной доку-

ментации и плана тестирования.

Подписи

Указывают подпись ответственного за передачу.

Глава 7 359

7.5.8. Тестирование программного обеспечения системы

С момента определения версии ПО как базовой, она отторгается от разработ-

чиков и «замораживается». Внесение изменений в базовую версию должно выпол-

няться только с целью исправления дефектов и на основании отчетов о проблемах,

обнаруженных тестировщиками. При продолжительном тестировании наряду с от-

четами о каждой проблеме должны составляться промежуточные отчеты о ходе

тестирования. По завершении функционального тестирования готовится сводный

отчет о выполненном цикле функционального тестирования.

Задачи, решаемые в этом шаге тестирования, описаны ниже петитом.

Задача 7.1. Утверждение среды тестирования.

Перед началом тестирования должна быть создана соответствующая аппаратная и

программная среда, включающая, например, рабочие станции, сервер, нужные версии ком-

понентов общесистемного ПО и т.д., а также установлены и конфигурированы инструменты

тестирования. Необходимо проверить, что среда установлена и соответствует требуемой.

Любые отклонения или задержки в установке должны фиксироваться и рассматриваться как

возможный риск срыва процесса (например, некоторые тесты не будут выполнены). Воз-

можная структура протокола приведена на рисунке 7.13.

Протокол утверждения среды тестирования

Дата: __________

Шифр (идентификатор) проекта: ____________

Уровень и вид

тестирования

Требуемая конфигура-

ция среды (по плану)

Установленная

конфигурация

Возможные послед-

ствия

Утверждено:

_____________________ Дата: ______________

Рис. 7.13. Структура протокола утверждения среды тестирования

Задача 7.2. Утверждение ресурсов тестирования.

Необходимо проверить, что все требуемые ресурсы (трудовые, финансовые, времен-

ные) выделены в соответствии с планами и достаточны для проведения тестирования. Лю-

бые отклонения от плана, например, сдвиг сроков передачи версии ПО группе тестирова-

ния, нехватка тестировщиков, должны фиксироваться и рассматриваться как возможный

риск срыва процесса. Возможная структура протокола приведена на рисунке 7.14.

Протокол утверждения ресурсов тестирования

Дата: __________

Шифр (идентификатор) проекта: ____________

Уровень и вид

тестирования

Требуемые ресурсы

(по плану)

Фактические

ресурсы

Возможные по-

следствия

Утверждено:

_____________________ Дата: ______________

Рис. 7.14. Структура протокола утверждения ресурсов тестирования

360 Глава 7

Задача 7.3. Тестирование ПО.

Группа тестирования использует проекты и описания наборов тестов, а также проце-

дуры, основанные на упорядоченных по критичности сценариях функционального тести-

рования ПО.

Помимо функционального тестирования на этом уровне выполняется проверка доку-

ментации на ПО (руководства пользователя) и справочной системы (Help) по критериям:

- простота использования и понятность. Определяется, насколько легко найти

нужные сведения;

- достоверность. Выполняются все описанные в документации примеры и проце-

дуры пользователя и сверяются ПО, документация и Help;

- полнота и точность. Определяется, все ли функции и действия описаны? Все ли

гиперссылки указаны правильно?

Тестирование по документации помогает выявить дефекты в ПО.

Все результаты выполнения тестов протоколируются в журнале тестирования, а лю-

бые отклонения или отказы фиксируются в отчетах о проблемах (рисунок 7.15).

Отчет о проблеме

1. Идентификатор отчета:_____________2. Идентификатор паспорта объек-

та____________

3. Идентификатор теста __________________________

4. Дата: ___________5. Время:___________

6. Проект: ____________

7. Программа/Модуль: ___________________8. Версия: _______________

9. Среда тестирования: _________________ 10. Аппаратная среда: ______

11. Уровень тестирования: ________________ 12. Цикл:______

13. Симптом: _____________

14. Серьезность (1-4): _________

15. Частота появления: _______

16. Статус (открыто/закрыто): ____________________________

17. Описание: _________________________________________

18. Составитель отчета ____________19. Передан: ___________________

20. Комментарий:

21. Решение:______________

22. Приоритет устранения(1-5): _________

23. Рассмотрено:________________ Дата_________

24. Проверено__________________ Дата:_________

25. Считать отложенным (да/нет):__________________

Рис. 7.15. Структура отчета о проблеме

Отчет о проблеме. Это основной документ, предназначенный для взаимодействия

между разработчиками и группой тестирования. В нем фиксируются любые непредвиден-

ные или некорректные результаты выполнения тестов, обнаруженные группой тестирова-

ния. Основной целью составления отчета является исправление обнаруженного дефекта,

поэтому отчет должен составляться сразу после обнаружения проблемы, содержать четкое

описание проблемы и способа ее воспроизведения.

Первые три поля предназначены для увязывания отчета с тестовыми документами,

что нужно для анализа проблемы программистом.

Поля 4 и 5 (дата и время) служат для последующего отслеживания устранения про-

блемы (при анализе результатов эти данные используются для определения возраста дефек-

тов, анализа тенденций и динамики обнаружения дефектов).

Следующие поля (6-10) используются для идентификации объекта и среды тестиро-

вания.

Глава 7 361

Поля 11-12 нужны для анализа процесса тестирования.

В поле 13 указывается краткое описание проявления проблемы (симптома), опреде-

ляемого тестировщиком, а в поле 14 - серьезность проблемы (критическая, серьезная и др.).

Классификация проблем по данным категориям представлена в разделе 6.5. В поле 15 ука-

зывается порядковый номер появления данной проблемы (при повторном ее обнаружении).

В поле 16 указывается состояние проблемы (открыта или закрыта). В поле 17 указывается

описание проблемы и способ ее воспроизведения.

В поле 18 указывается фамилия тестировщика (или другого составителя отчета, на-

пример, пользователя), а в 19 – фамилия программиста. В поле 20 программист может запи-

сать, как устранена проблема, почему не устранена или отложена, и с чем она связана.

Поле 21 используется для описания состояния проблемы, например, «Отклонить»,

«Рассматривается», «Не может быть исправлена», «Исправлена» и заполняется программи-

стом (в отличие от поля 16, которое заполняется тестировщиком). В поле 22 указывается

код приоритета устранения (классификация приведена в разделе 6.5). В поле 23 указывается

подпись программиста, ответственного за устранение проблемы, а в поле 24 – тестировщи-

ка, проверившего устранение дефекта. Поле 25 заполняется тестировщиком, если он не со-

гласен с приоритетом устранения «Отложить», или «Отклонить», установленным програм-

мистом или руководителем проекта.

Для отслеживания динамики выполнения тестирования используются сводные дан-

ные об обнаруженных дефектах в виде промежуточных отчетов группы тестирования (на-

пример, еженедельно). В результате анализа этих отчетов могут быть уточнены первона-

чальные оценки рисков отказа функций, определены недостаточно протестированные об-

ласти ПО и для них разработаны и выполнены дополнительные тесты.

На рисунках 7.16 и 7.17 приведено два типа недельных отчетов (промежуточных) о

результатах тестирования, которые составляются на основании отчетов о проблемах.

Отчет о динамике обнаружения дефектов

Дата:__________ Тип отчета: недельный

Идентификатор

отчета о проблеме

Дата обнару-

жения

Описание Серьезность

Всего обнаружено дефектов:______

Из них:

Критических:________

Серьезных:__________

Незначительных:______

Продолжительность тестирования:_________

Рис.7.16. Отчет о количестве обнаруженных дефектов

Отчет о динамике устранения дефектов

Дата:__________ Тип отчета: недельный

Идентификатор

отчета о проблеме

Дата от-

крытия

Описание Приоритет

устранения

Дата за-

крытия

Всего обнаружено: ______

Всего устранено:_______

Открыто: ________

Рис. 7.17. Отчет о динамике устранения дефектов

362 Глава 7

Первый из отчетов - основной отчет тестировщика о результатах недельной работы.

В нем указываются все обнаруженные за неделю проблемы, упорядоченные по серьезности.

Второй вид отчета отражает динамику устранения дефектов и составляется тести-

ровщиком по данным о «закрытых» отчетах о проблемах.

Задача 7.4. Повторное тестирование после устранения дефектов.

Задача выполняется циклически до достижения заданного критерия завершения.

Задача 7.5. Анализ результатов тестирования.

После выполнения запланированных тестов производится анализ покрытия функций

набором тестов и анализ оставшихся не устраненных дефектов. Определяется риск отказов

из-за оставшихся дефектов и принимается решение о продолжении или завершении тести-

рования ПО. По завершении тестирования группа тестирования готовит отчет о выполне-

нии цикла тестирования (рисунок 7.18).

Отчет о выполнении тестирования ПО

Дата составления отчета:__________

Проект/Программа:________Версия:_________ Цикл:______________

Дата начала тестирования: __________ Уровень/Задача тестирования:___________

Серьезность дефектов Устранено Отложено Отклонено

Критические

Серьезные

Средние

Прочие

Всего

Продолжительность тестирования (дней):____________

Трудоемкость тестирования:___________

Отчет составил:______________________

Рис. 7.18. Отчет о выполнении цикла тестирования

Задача 7.6. Проектирование комплекта регрессионных тестов для регрес-

сионного тестирования.

Цель: определить наборы тестов, сценарии и процедуры, которые должны быть со-

хранены для регрессионного тестирования в следующей версии ПО.

Решение должно быть основано на функциональных требованиях к системе, резуль-

татах анализа риска и анализе дефектов, которые имели место при функциональном тести-

ровании.

Задача 7.7. Автоматизация наборов тестов для регрессионного тестиро-

вания (необязательная).

При автоматизированном тестировании процедуры создаются в виде тестовых

скриптов (автоматизированных процедур). Эти скрипты могут быть сгенерированы автома-

тически путем «проигрывания» сценария работы или написаны вручную на языке скриптов

инструмента тестирования. Тестовый скрипт должен храниться и обновляться при каждом

новом выполнении повторного тестирования.

Связанные логикой работы отдельные процедуры объединяются в тестовые сценарии

посредством создания процедур-оболочек (shell procedure).

7.5.9. Системное тестирование

На этом шаге тестирования решаются следующие задачи, представленные

ниже петитом.

Задача 8.1. Утверждение среды тестирования.

Аналогична задаче 7.1.

Глава 7 363

Создание среды и имитация реальных и предельных нагрузок на систему требует

значительных ресурсов, поэтому для моделирования условий среды требуются инструмен-

ты тестирования.

Задача 8.2. Утверждение ресурсов тестирования.

Аналогична задаче 7.2

Задача 8.3. Системное тестирование.

Выполняется в соответствии с планом, проектами и описаниями наборов тестов, сце-

нариями и процедурами тестирования, основанными на сценариях работы пользователей.

Все результаты выполнения тестов фиксируются в журналах тестирования, а обнаруженные

отказы - в отчетах о проблемах, и передаются разработчику для анализа и устранения.

Системные тесты должны быть разрушительными по характеру и нацелены на то,

чтобы найти области, где система не соответствуют техническим характеристикам.

При тестировании на надежность и производительность, тестовые данные выбирают-

ся из входного пространства по частоте использования функций в сценариях (по методам,

основанным на анализе использования). Эти виды тестирования требуют измерения интер-

валов времени выполнения и моментов возникновения отказов. Системные тесты должны

охватывать наиболее критичные по производительности и надежности функции системы,

особенно те, отказы в которых могут привести к серьезным последствиям.

Помимо системных тестов, на этом уровне должна проверяться эксплуатационная

документации на систему - на соответствие функциям и целям, реализованным в системе.

Для отслеживания динамики выполнения тестирования, как и при тестировании ПО,

формируются сводные данные об отказах в виде промежуточных отчетов (см. рисунки 7.16

и 7.17). В результате анализа этих отчетов могут быть уточнены первоначальные оценки

рисков отказа, и для них разработаны и выполнены дополнительные тесты. Эти данные со-

ставляют основу для вычисления метрик надежности и прогнозирования надежности ПС

при эксплуатации.

Задача 8.4. Повторное тестирование после устранения дефектов.

Эта задача выполняется циклически до достижения установленного критерия завер-

шения, инициируется по результатам анализа отчетов о проблемах и еженедельных отчетов.

Задача 8.5. Анализ результатов тестирования.

Аналогична задаче 7.5.

Для системного тестирования критерий завершения формируется по каждому виду

целевого тестирования.

Задача 8.6. Тестирование инсталляции.

Цель - выполнить тестирование процедур инсталляции в моделируемой и реальной

среде. Это тестирование должно выполняться на «чистой» машине (без установленных

компонентов системы).

Задача 8.7. Автоматизация тестирования.

Для выполнения этой задачи должны применяться инструменты сбора статистики о

временных показателях выполнения и моментах возникновения отказов (путем встраивания

счетчиков выполнения). Кроме того, могут использоваться специальные промышленные

инструменты тестирования (приложение 4).

7.5.10. Анализ результатов тестирования

Задачи, решаемые в этом шаге тестирования, представлены ниже петитом.

Задача 9.1. Анализ данных о результатах тестирования.

Решение задачи состоит в том, чтобы собрать и обобщить все данные о результатах

функционального и системного тестирования, выполнить классификацию и анализ отказов

и дефектов. Вычислить метрики тестирования. По результатам анализа определить степень

достижения установленного критерия завершения тестирования.