Юзабилититестирование программного
 Скачать 0.61 Mb.
|
Лабораторная работа №6Документирование результатов тестированияЦель: составить итоговый отчет о результатах тестирования web-приложения. Планзанятия: Изучить теоретические сведения. Выполнить практическое задание по лабораторной работе. Оформить отчет и ответить на контрольные вопросы. Теоретическиесведения Итоговый отчет о качестве проверенного функционала является неотъемле- мой частью работы, которую каждый тестировщик должен выполнить по завер- шении тестирования. Итоговый отчет можно разделить на части с соответствующей информацией: Общая информация. Сведения о том, кто и когда тестировал программный продукт. Тестовое окружение. Общая оценка качества приложения. Обоснование выставленного качества. Графическое представление результатов тестирования. Детализированный анализ качества по модулям. Список самых критичных дефектов. Рекомендации. Пример итогового отчета приведен на рисунке 6.1. Далее рассмотрим подробно каждую часть итогового отчета. Общая информация включает: название проекта; номер сборки; модули, которые подверглись тестированию (в случае, если тестировался не весь проект); виды тестов по глубине покрытия (Smoke Test, Minimal Acceptance Test, Acceptance Test), тестовые активности (New Feature Test, Regression Testing, Defect Validation); количество обнаруженных дефектов; вид рабочей тестовой документации (Acceptance Sheet, Test Survey, Test Cases). 56  Рисунок 6.1 – Пример итогового отчета о результатах тестированияСведения о том, кто и когда тестировал программный продукт, включают ин- формацию о команде тестирования с указанием контактных данных и временном интервале тестирования. 57 Тестовое окружение содержит ссылку на проект, браузер, операционную си- стему и другую информацию, конкретизирующую особенности конфигурации. Общая оценка качества приложения выставляется на основании анализа ре- зультатов работы с приложением, количества внесенных дефектов, важности де- фектов. Обязательно учитывается этап разработки проекта – то, что не критично в начале работы, становится важным при выпуске программного продукта. Уровни качества: высокое (High), среднее (Medium), низкое (Low). Обоснование выставленного качества является наиболее важной частью отче- та, т. к. здесь отражается общее состояние сборки, а именно: качество сборки на текущий момент; факторы, повлиявшие на выставление именно такого качества сборки: ука- зание функционала, который заблокирован для проверки, перечисление наиболее критичных дефектов и объяснение их важности для пользователя или бизнеса за- казчика; анализ качества проверенного функционала: улучшилось оно или ухудши- лось по сравнению с предыдущей версией; если качество сборки ухудшилось, то обязательно должны быть указаны регрессионные места; наиболее нестабильные части функционала с указанием причин, по кото- рым они таковыми являются. Помимо вышеуказанных общих характеристик при выставлении и обоснова- нии оценки качества программного продукта активно используются числовые ха- рактеристики качества – метрики. Пример обоснования с использованием метрик выглядит следующим образом: «Реализовано 79 % требований (в том числе 94 % важных), за последние три билда тестовое покрытие выросло с 63 до 71 %, а об- щий показатель прохождения тест-кейсов вырос с 85 до 89 %». Метрики могут быть как прямыми (не требуют вычислений), так и расчетны- ми (вычисляются по формуле). Типичные примеры прямых метрик – количество разработанных тест-кейсов, количество найденных дефектов и т. д. Большинство общепринятых расчетных метрик могут быть собраны автома- тически с использованием инструментальных средств управления проектами: процентное отношение (не)выполненных тест-кейсов ко всем имеющимся; процентный показатель успешного прохождения тест-кейсов; процентный показатель заблокированных тест-кейсов; плотность распределения дефектов; эффективность устранения дефектов; распределение дефектов по важности и срочности; метрики покрытия. Простая расчетная метрика для определения показателя успешного прохож- дения тест-кейсов выглядит следующим образом: 58  Total TSP = TSuccess ∙ 100 %, (6.1) T где TSuccess – количество успешно выполненных тест-кейсов; TTotal – общее количество выполненных тест-кейсов. Минимальные границы значений показателя успешного прохождения тест- кейсов на начальной фазе проекта равны 10 %, на основной фазе проекта – 40 %, на финальной фазе проекта – 85 %. Метрику покрытия требований тест-кейсами вычисляют по формуле  Total RSimpleCoverage = RCovered ∙ 100 %, (6.2) R где RCovered – количество требований, покрытых хотя бы одним тест-кейсом; TTotal – общее количество требований. Метрики являются мощнейшим средством сбора и анализа информации. Од- нако использование метрик требует ясного понимания их сущности, в противном случае может возникнуть ситуация использования «метрик ради метрик», когда многочисленные цифры и графики никто не может понять и правильно интерпре- тировать. Графическое представление результатов тестирования способствует более полному и быстрому пониманию текстовой информации (см. рисунок 4.1). Если необходимо продемонстрировать процентное соотношение, то целесо- образно использовать круговые диаграммы (например, процентное соотношение функциональных дефектов и дефектов GUI). Столбчатые диаграммы лучше подойдут там, где важно визуализировать ко- личество дефектов в зависимости от степени их критичности или в зависимости от локализации (распределение дефектов по модулям). Отразить в итоговом отчете динамику качества по всем сборкам лучше всего удастся с помощью линейного графика. Детализированныйанализкачествапомодулям В данной части отчета описывается более подробная информация о прове- ренных частях функционала, устанавливается качество каждой проверенной части функционала (модуля) в отдельности, дается аргументация выставленного уровня качества. Как правило, данный раздел отчета представляется в табличной форме. В зависимости от вида проводимых тестовых активностей эта часть отчета будет отличаться. При оценке качества функционала на уровне Smoke теста оно может быть ли- бо приемлемым (Acceptable), либо неприемлемым (Unacceptable). Если все наибо- лее важные функции работают корректно, то качество всего функционала на уровне Smoke может быть оценено, как приемлемое. Если это релизная или предрелизная сборка, то для выставления приемлемого качества на уровне Smoke не должно быть найдено функциональных дефектов. 59 В части о детализированной информации качества сборки следует более по- дробно описать проблемы, которые были найдены во время теста. При оценке качества функционала на уровне Defect Validation указываются результаты валидации дефектов, а именно: общее количество всех дефектов, поступивших на проверку; количество неисправленных дефектов и их процент от общего количества; список дефектов, которые не были проверены и причины, по которым это- го не было сделано; наглядная таблица с неисправленными дефектами. По вышеуказанным результатам выставляется качество теста. Если процент неисправленных дефектов меньше 10 %, то качество приемлемое (Acceptable), ес- ли больше 10 %, то качество неприемлемое (Unacceptable). При оценке качества функционала на уровне New Feature Test (полный тест нового функционала) качество отдельно проверенного функционала может быть высокое (High), среднее (Medium), низкое (Low). Важно отдельно указывать информацию о качестве каждого модуля нового функционала с аргументацией выставленной оценки. При оценке качества функционала на уровне Regression Testing нужно анали- зировать динамику изменения качества проверенной функциональности в сравне- нии с более ранними версиями сборки. Для этого приводится сравнительная ха- рактеристика каждой из частей функционала в сравнении с предыдущими версия- ми сборки, даются ясные пояснения о выставлении соответствующего качества каждой функции в отдельности. Так же как и у предыдущего вида тестов, качество может быть высокое (High), среднее (Medium), низкое (Low). Список самых критичных дефектов содержит 3–5 ссылок на наиболее кри- тичные дефекты с указанием их названия и уровня критичности. Рекомендации включают краткую информацию о всех проблемах приложе- ния с пояснениями, насколько оставшиеся проблемы являются критичными для конечного пользователя. Обязательно указывают функционал и дефекты, скорей- шее исправление которых является наиболее приоритетным. Кроме того, если сборка является релизной или предрелизной, то любое ухудшение качества явля- ется критичным и важно это обозначить. Практическоезадание: Составить итоговый отчет по результатам тестирования web-приложения. Указать общую информацию о тестируемом продукте (название, номер сборки, виды выполненных тестов, количество обнаруженных дефектов, вид ра- бочей тестовой документации). Указать, кто и когда тестировал программный продукт. Описать тестовое окружение (ссылку на web-приложение, браузер). 60 Указать общую оценку качества протестированного приложения и по- дробно ее обосновать. Графически (в виде круговой диаграммы) отразить процентное соотноше- ние дефектов GUI и функциональных дефектов. Графически (в виде столбчатой диаграммы) отразить распределение де- фектов по различным степеням критичности. Графически (в виде столбчатой диаграммы) отразить распределение де- фектов по модулям. Произвести детальный анализ качества всех модулей протестированного приложения с аргументацией выставленных уровней качества. Привести список пяти наиболее критичных дефектов. Сформулировать рекомендации по улучшению качества программного продукта. Оформить отчет и защитить лабораторную работу. Содержаниеотчета: Цель работы. Итоговый отчет о результатах тестирования web-приложения. Выводы по работе. Контрольныевопросы: Какова структура итогового отчета о результатах тестирования? Что содержится в разделе «Общая информация»? Что содержится в разделе «Тестовое окружение»? Как выставляется общая оценка качества приложения? Как обосновать выставленную оценку качества? Что такое метрика в тестировании? Приведите примеры прямых метрик. Приведите примеры расчетных метрик. Для чего используется графическое представление результатов тестиро- вания в итоговом отчете? Что содержится в разделе «Детализированный анализ качества»? Что содержится в разделе «Рекомендации»? 61 |