юзабилити тестирование. Юзабилититестирование программного обеспечения
 Скачать 3.74 Mb.
|
|
Лабораторная работа №5 Поиск и документирование дефектов Цель: протестировать web-приложение и описать найденные дефекты. План занятия: 1. Изучить теоретические сведения. 2. Выполнить практическое задание по лабораторной работе. 3. Оформить отчет и ответить на контрольные вопросы. Теоретические сведения Дефекты, обнаруженные тестировщиком, должны быть корректно и понятно описаны, чтобы разработчик смог воспроизвести данный дефект и устранить его. Описание каждого дефекта сохраняется в специализированной – багтрэкинговой – системе (например, JIRA, Bugzilla, Mantis, Redmine и др.) или в предварительно созданном в программной среде Microsoft Excel файле (пример приведен в табли- це 5.1). Таблица 5.1 – Пример описания дефекта № Название де- фекта Важ- ность Алгоритм воспроиз- ведения Фактиче- ский ре- зультат Ожида- емый ре- зультат Прило- жение При- ме- чание 39 Администра- торская часть: Файлы: Вы- бор файла: Ссылка «Ска- чать файл»: Администра- тор не имеет возможности скачать за- груженные студентом файлы Critical Шаги по воспроизве- дению: 1. Входим на web- сайт … . 2. Проходим автори- зацию: admin/admin. 3. Выбираем в меню категорию «Файлы». 4. Выбираем подка- тегорию меню «Вы- бор файла». 5. Выбираем в поле «Обзор файла» лю- бой доступный файл. 6. Нажимаем на ссылку «Скачать файл» Переход к странице «HTTP Status 404» Происхо- дит ска- чивание выбран- ного фай- ла 39.png REQ- 26 Описание дефекта включает следующие обязательные поля: 48 1. Headline – название дефекта. 2. Severity – степень критичности (важность дефекта). 3. Description – алгоритм воспроизведения. 4. Result – фактический результат. 5. Expected result – ожидаемый результат. 6. Attachment – прикрепленные файлы (приложение). В багтрэкинговых системах для каждого дефекта автоматически генерируется его уникальный номер, в случае использования Microsoft Excel номер дефекту необходимо присваивать вручную. Требование спецификации, которое нарушает обнаруженный дефект, можно дополнительно вынести в примечание. Дополнительно в описании дефекта может быть указана Priority – степень срочности исправления дефекта разработчиком. Рассмотрим подробно каждую категорию описания дефекта. Headline (название дефекта). Цель составления заголовка дефекта – предо- ставить краткую и в тоже время понятную информацию о том, где, что и в резуль- тате чего произошло. Характеристиками качественного заголовка являются крат- кость, информативность, точная идентификация проблемы. Заголовок дефекта должен отвечать на три вопроса: 1. Где? В каком месте интерфейса пользователя находится проблема. В данной части заголовка следует также дополнительно указать особенности теста, если это поможет разобраться в проблеме (версия операционной системы, браузера, сторонних приложений, которые имеют отношение к тестируемому про- граммному средству). 2. Что? Что происходит или не происходит согласно спецификации или представлению о нормальной работе программного продукта. При этом необхо- димо указывать на наличие проблемы, а не на ее содержание (его указывают в описании). Если содержание проблемы варьируется, все известные варианты ука- зываются в описании. 3. Когда (при каких условиях)? В какой момент работы программы или по наступлению какого события проблема проявляется. Пример: в приложении есть диалог «Преобразовать данные» с кнопкой «Пре- образовать». При нажатии этой кнопки появляется сообщение об ошибке «Ошиб- ка 315». Заголовок дефекта по описанной методике составляется так: Где?: Диалог «Преобразовать данные». Что?: Показывается сообщение об ошибке. Когда?: При нажатии кнопки «Преобразовать». Итоговый заголовок будет иметь следующий вид: Диалог «Преобразовать данные» показывает сообщение об ошибке при нажатии кнопки «Преобразовать». 49 Уберем лишние слова, добавим код ошибки для удобства поиска: Диалог «Преоб- разовать данные»: сообщение об ошибке 315 при нажатии кнопки «Преобразо- вать». Если сформулировать заголовок по формуле Где? Что? Когда (при каких условиях)? трудно, то можно воспользоваться следующим алгоритмом действий: 1. Пропустите заголовок дефекта. 2. Напишите описание дефекта, фактический и ожидаемый результаты. 3. Выделите ключевые моменты, руководствуясь формулой Где? Что? Когда (при каких условиях)? 4. Сложите эти ключевые моменты вместе. 5. То, что получится в итоге, и будет составлять заголовок дефекта. Severity (степень критичности). Степень критичности (серьезности, важно- сти) показывает степень ущерба, который наносится проекту существованием де- фекта. В общем случае выделяют следующие градации критичности дефектов (таб- лица 5.2): Critical (критический), Major (значительный), Average (средней значи- мости), Minor (незначительный), Enhancement (предложение по улучшению). Description (алгоритм воспроизведения). Цель составления алгоритма вос- произведения дефекта – последовательно описать шаги для повторения дефекта. Description должен быть оформлен в виде списка перечисления действий: 1. Шаг #1. 2. Шаг #2. … n. Шаг #n. В случае, если для воспроизведения дефекта требуется ряд начальных усло- вий (например, должен быть создан определенный набор документов, пользова- тель или группа пользователей с особыми правами), то эти предусловия должны быть вынесены в начало описания: Предусловия. 1. Шаг #1. 2. Шаг #2. … n. Шаг #n. 50 Таблица 5.2 – Степени критичности дефектов Severity Описание Примеры Critical (критический) Функциональная ошибка, которая блокирует работу ча- сти функционала или всего приложения. Функциональная ошибка, которая нарушает ключевую (с точки зрения конечного пользователя или бизнеса за- казчика) функциональность приложения Заблокирована вкладка «Категория меню»). Неправильно подсчиты- вается итоговая сумма при вводе скидочного промоко- да. Раскрывается конфиден- циальная информация Major (значительный) Функциональная ошибка, которая нарушает нормаль- ную работу приложения, но не блокирует работу части функционала в целом Невозможно загрузить видеофайлы на персональ- ной страничке. Не работает система email-нотификации. Не работает интеграция с социальными сетями. Необходимо перезапус- кать приложение при вы- полнении типичных сцена- риев работы Average (средней значи- мости) Не очень важная функцио- нальная ошибка. Критичные дефекты GUI Не работает сортировка. «Уехал» текст за пределы окна Minor (незначительный) Редко встречающиеся не- значительные функциональ- ные дефекты. 90 % дефектов GUI Введены необязательные для заполнения поля, кото- рых нет в спецификации. Грамматические, пункту- ационные ошибки Enhancement (предложение по улучшению) Функциональные предло- жения, советы по улучшению дизайна (оформления), нави- гации и др. Такой дефект является не- обязательным для исправле- ния Добавить кнопку «Наверх» на длинных фор- мах. Увеличить размер шрифта 51 При составлении Description необходимо следовать приведенным ниже реко- мендациям. Description – это четкий алгоритм, в котором приветствуются короткие, по- нятные фразы и нумерация. Нельзя использовать личные предложения формата «Я думаю, что так будет лучше», «Я зашел на страницу…» и т. д. Можно использовать специальные символы «+», «=», «<>», которые помогут сделать подобие навигации: File > Open, DOC + XLS. Однако не рекомендуется писать шаги в строку через символы перехода – это затрудняет восприятие дефекта. Следует указывать специфичные условия воспроизведения дефекта, если та- ковые имеются. Например, под каким пользователем вы работаете (если это важно). Описание предложений по улучшению должно быть максимально полным и аргументированным. Result (фактический результат). Цель написания Result – четко описать по- лученный результат. Expected result (ожидаемый результат). Цель написания Expected result – привести аргументы разработчикам, как именно должно работать приложение. В Expected result должно быть четкое обоснование, почему именно так долж- но работать приложение. Лучше всего, если в нем приведена ссылка на конкрет- ный пункт спецификации. Если в Expected result приводится ссылка на спецификацию, сам тестировщик дополнительно цитирует текст спецификации, чтобы сократить время разработчи- ка на анализ документа и однозначно указать на способ решения проблемы. Если функция работает, но некорректно, то в Expected Result обязательно должно быть описание того, как она должна работать корректно. Если сделана ошибка в надписи или интерфейсе проекта, необходимо гра- мотно и полностью указать, как она должна быть исправлена – написать надпись без ошибки или описать требуемые изменения интерфейса. Expected Result всегда следует заполнять. Не стоит полагаться на очевидность представлений о правильном поведении приложения. Текст Expected result рекомендуется писать законченными полными безлич- ными предложениями. Attachment (приложения). Attachment – это прикрепленный к дефекту файл, дополняющий описание: скриншот, файлы, необходимые для воспроизведения дефекта, логи программы, видео ошибки и т. д. Attachment является вспомогатель- ным средством передачи информации о проблеме. Для всех GUI дефектов attachment обязателен. Если к дефекту прикрепляется файл, об этом обязательно должно быть указа- но в описании дефекта («See the file/screenshot/log/video attached»). Прикреплен- 52 ный файл не должен быть слишком большим по размеру (особенно это касается видео: до 10 Мбайт), а также должен относиться именно к описанной ошибке (например, из лога приложения стоит скопировать в прикрепляемый файл только данные об ошибке). Формат файла скриншота – PNG. Имя файла скриншота реко- мендуется делать числовым, нейтральным – 1.png, 25.png и т. п. Скриншот должен содержать следующие элементы: сама ошибка, выделение места ошибки, стрелка к прямоугольнику, описание ошибки: «Наблюдаемый ре- зультат» и/или «Ожидаемый результат». Текст на скриншоте также необходимо выделить: обвести в прямоугольник и набрать шрифтом, заметно отличающимся от шрифта программы. Качественно подготовленный скриншот должен давать возможность понять смысл дефекта без необходимости читать его описание (ри- сунок 5.1). Рисунок 5.1 – Пример скриншота, поясняющего обнаруженный дефект Делать снимок всего окна программы необязательно: на снимке должна быть видна ошибка и место, в котором она находится. Если для понимания дефекта не- обходим контекст, то помимо собственно ошибки фиксируют необходимую ин- формацию (браузер, в котором открыто web-приложение, все окно программы в фоне с названием диалогового окна, где эта ошибка появилась). Если необходимо привести снимки нескольких страниц проекта, связанных между собой, лучше сделать это на одном скриншоте, совместив изображения по горизонтали и при необходимости отметив стрелками переходы значений, полей и т. п. Далее приведены рекомендации по описанию дефектов. Часто сообщение об ошибке превращается в сокращенную запись только ос- новных действий, необходимых для воспроизведения ошибки, опуская все несу- щественные. Но, будучи незнакомым с внутренней структурой приложения, те- 53 стировщик не может знать, какие из выполненных им действий наиболее суще- ственны для диагностирования данной ошибки. Пренебрегая действиями, которые кажутся незначительными, повышается риск потери важной информации. Лучший способ избежать этой проблемы состоит в том, чтобы просто перечислить все дей- ствия, которые необходимы для воспроизведения ошибочного поведения, начиная с открытия нужной формы в проекте. Если есть подозрение на повторение дефекта в нескольких модулях проекта, этот факт нужно исследовать еще до внесения дефекта и при его описании указать все места, где дефект воспроизводится. Дефект не должен содержать фразу: «Это не работает», дефект должен пока- зать, что и при каких условиях не работает. Чтобы внести дефект, его следует воспроизвести минимум два раза, причем начиная с самых нейтральных условий воспроизведения, и только после гаранти- рованного повторения описать последовательность действий. Нельзя не описывать дефекты только потому, что их не получается воспроиз- вести. Факт невозможности выяснить причину дефекта в таком случае обязатель- но должен быть указан в описании дефекта. Дефекты целесообразно группировать, однако делать это необходимо в соот- ветствии с приведенными ниже правилами. GUI дефекты могут группироваться в один по признаку формы, на которой они находятся, т. е. если одна форма содержит несколько GUI дефектов с одина- ковым уровнем Severity, то их можно объединить. Функциональные дефекты группируются в том случае, если речь идет об од- нотипных дефектах, которые воспроизводятся в различных модулях, страницах или полях (например, динамическое обновление не работает в модулях 1, 2 и 4 или отсутствует валидация на спецсимволы на всех полях страницы). Группировка функциональных дефектов по признаку формы, на которой они найдены, не применяется. Недопустимо объединять в один дефекты разного типа, например функцио- нальные и GUI. В таком случае пишутся несколько дефектов на каждый тип. Рекомендации по хорошему описанию дефектов: 1. Шаги воспроизведения, фактический и ожидаемый результаты должны быть подробно описаны. 2. Дефект должен быть понятно описан (с использованием общеупотребимой лексики, точных названий программных средств). 3. Необходимо давать ссылку на соответствующее требование, к нарушению которого приводит фактический результат работы программного средства. 4. Если существует какая-либо информация, которая поможет быстрее обна- ружить или исправить дефект, необходимо сообщить эту информацию. 54 5. Окружение (ОС, браузер, настройки и т. п.), под которым возникла ошибка, должно быть четко указано. 6. Создавать дефект и описывать его необходимо сразу же, как только он был обнаружен. Откладывание «на потом» приводит к риску забыть о дефекте или ка- ких-либо деталях его воспроизведения. Несвоевременное создание дефекта не позволяет проектной команде реагировать на ее обнаружение в реальном времени. 7. После описания дефекта необходимо еще раз перечитать его, убедится, что все необходимые поля заполнены и все написано верно. Помимо собственно описания дефектов, результаты тестирования вносят в рабочую тестовую документацию (Acceptance Sheet, Test Survey, Test Cases). Для этого напротив выполненной проверки указывают степень критичности обнару- женного дефекта, его номер и заголовок. Если по результатам конкретной провер- ки выявлено несколько дефектов, то перечисляют номера всех дефектов, а в каче- стве степени критичности и заголовка указывают наиболее серьезный дефект. Практическое задание: 1. Выбрать объект реального мира (например: холодильник, блендер, лифт и др.), выделить в нем модули. 2. Разработать 20 и более тестовых проверок для выбранного объекта реаль- ного мира с указанием тестируемого модуля и глубины тестового покрытия (Smoke, MAT, AT). 3. Сформулировать по два возможных дефекта на каждый уровень Severity (Critical, Major, Average, Minor, Enhancement) для выбранного объекта реального мира. 4. Описать по одному дефекту на каждый уровень Severity (Critical, Major, Average, Minor, Enhancement) для выбранного объекта реального мира. 5. Протестировать web-приложение в соответствии с составленной ранее те- стовой документацией. 6. Описать все найденные дефекты в отчете о дефектах в среде Microsoft Excel. 7. В отчете о дефектах указать номер тестируемой сборки, название прило- жения, период времени тестирования, ФИО тестировщика, тестовое окружение (операционная система, браузер). 8. Для каждого дефекта указать его порядковый номер, заголовок, важность, алгоритм воспроизведения, фактический результат, ожидаемый результат, прило- жение, примечание. 9. Для каждого дефекта обязательно сделать скриншоты. 10. В рабочую тестовую документацию внести результаты тестирования с указанием напротив соответствующей проверки степени критичности обнаружен- ного дефекта, его номера и заголовка. 11. Оформить отчет и защитить лабораторную работу. 55 Содержание отчета: 1. Цель работы. 2. Отчет о результатах тестирования выбранного объекта реального мира с перечислением тестовых проверок, сформулированных дефектов на каждый уро- вень Severity, описания дефектов. 3. Отчет о найденных дефектах web-приложения. 4. Рабочая тестовая документация с внесенными дефектами web-приложения. 5. Выводы по работе. Контрольные вопросы: 1. Что такое дефект? 2. Какие характеристики необходимо указать при описании дефекта? 3. Что такое Headline/Summary в описании дефекта? 4. На какие три вопроса должен отвечать Headline/Summary? 5. Что такое Severity в описании дефекта? 6. Какие существуют степени Severity? Приведите примеры. 7. Что такое Description в описании дефекта? 8. Что такое Expected result в описании дефекта? 9. Зачем нужен Attachment при описании дефекта? 10. Какие существуют рекомендации по описанию дефектов? 11. Какие дефекты можно группировать? 56 Лабораторная работа №6 Документирование результатов тестирования Цель: составить итоговый отчет о результатах тестирования web-приложения. План занятия: 1. Изучить теоретические сведения. 2. Выполнить практическое задание по лабораторной работе. 3. Оформить отчет и ответить на контрольные вопросы. Теоретические сведения Итоговый отчет о качестве проверенного функционала является неотъемле- мой частью работы, которую каждый тестировщик должен выполнить по завер- шении тестирования. Итоговый отчет можно разделить на части с соответствующей информацией: 1. Общая информация. 2. Сведения о том, кто и когда тестировал программный продукт. 3. Тестовое окружение. 4. Общая оценка качества приложения. 5. Обоснование выставленного качества. 6. Графическое представление результатов тестирования. 7. Детализированный анализ качества по модулям. 8. Список самых критичных дефектов. 9. Рекомендации. Пример итогового отчета приведен на рисунке 6.1. Далее рассмотрим подробно каждую часть итогового отчета. Общая информация включает: название проекта; номер сборки; модули, которые подверглись тестированию (в случае, если тестировался не весь проект); виды тестов по глубине покрытия (Smoke Test, Minimal Acceptance Test, Acceptance Test), тестовые активности (New Feature Test, Regression Testing, Defect Validation); количество обнаруженных дефектов; вид рабочей тестовой документации (Acceptance Sheet, Test Survey, Test Cases). 57 Рисунок 6.1 – Пример итогового отчета о результатах тестирования Сведения о том, кто и когда тестировал программный продукт, включают ин- формацию о команде тестирования с указанием контактных данных и временном интервале тестирования. 58 Тестовое окружение содержит ссылку на проект, браузер, операционную си- стему и другую информацию, конкретизирующую особенности конфигурации. Общая оценка качества приложения выставляется на основании анализа ре- зультатов работы с приложением, количества внесенных дефектов, важности де- фектов. Обязательно учитывается этап разработки проекта – то, что не критично в начале работы, становится важным при выпуске программного продукта. Уровни качества: высокое (High), среднее (Medium), низкое (Low). Обоснование выставленного качества является наиболее важной частью отче- та, т. к. здесь отражается общее состояние сборки, а именно: качество сборки на текущий момент; факторы, повлиявшие на выставление именно такого качества сборки: ука- зание функционала, который заблокирован для проверки, перечисление наиболее критичных дефектов и объяснение их важности для пользователя или бизнеса за- казчика; анализ качества проверенного функционала: улучшилось оно или ухудши- лось по сравнению с предыдущей версией; если качество сборки ухудшилось, то обязательно должны быть указаны регрессионные места; наиболее нестабильные части функционала с указанием причин, по кото- рым они таковыми являются. Помимо вышеуказанных общих характеристик при выставлении и обоснова- нии оценки качества программного продукта активно используются числовые ха- рактеристики качества – метрики. Пример обоснования с использованием метрик выглядит следующим образом: «Реализовано 79 % требований (в том числе 94 % важных), за последние три билда тестовое покрытие выросло с 63 до 71 %, а об- щий показатель прохождения тест-кейсов вырос с 85 до 89 %». Метрики могут быть как прямыми (не требуют вычислений), так и расчетны- ми (вычисляются по формуле). Типичные примеры прямых метрик – количество разработанных тест-кейсов, количество найденных дефектов и т. д. Большинство общепринятых расчетных метрик могут быть собраны автома- тически с использованием инструментальных средств управления проектами: процентное отношение (не)выполненных тест-кейсов ко всем имеющимся; процентный показатель успешного прохождения тест-кейсов; процентный показатель заблокированных тест-кейсов; плотность распределения дефектов; эффективность устранения дефектов; распределение дефектов по важности и срочности; метрики покрытия. Простая расчетная метрика для определения показателя успешного прохож- дения тест-кейсов выглядит следующим образом: 59 T SP = T Success T Total ∙ 100 %, (6.1) где T Success – количество успешно выполненных тест-кейсов; T Total – общее количество выполненных тест-кейсов. Минимальные границы значений показателя успешного прохождения тест- кейсов на начальной фазе проекта равны 10 %, на основной фазе проекта – 40 %, на финальной фазе проекта – 85 %. Метрику покрытия требований тест-кейсами вычисляют по формуле R SimpleCoverage = R Covered R Total ∙ 100 %, (6.2) где R Covered – количество требований, покрытых хотя бы одним тест-кейсом; T Total – общее количество требований. Метрики являются мощнейшим средством сбора и анализа информации. Од- нако использование метрик требует ясного понимания их сущности, в противном случае может возникнуть ситуация использования «метрик ради метрик», когда многочисленные цифры и графики никто не может понять и правильно интерпре- тировать. Графическое представление результатов тестирования способствует более полному и быстрому пониманию текстовой информации (см. рисунок 4.1). Если необходимо продемонстрировать процентное соотношение, то целесо- образно использовать круговые диаграммы (например, процентное соотношение функциональных дефектов и дефектов GUI). Столбчатые диаграммы лучше подойдут там, где важно визуализировать ко- личество дефектов в зависимости от степени их критичности или в зависимости от локализации (распределение дефектов по модулям). Отразить в итоговом отчете динамику качества по всем сборкам лучше всего удастся с помощью линейного графика. Детализированный анализ качества по модулям В данной части отчета описывается более подробная информация о прове- ренных частях функционала, устанавливается качество каждой проверенной части функционала (модуля) в отдельности, дается аргументация выставленного уровня качества. Как правило, данный раздел отчета представляется в табличной форме. В зависимости от вида проводимых тестовых активностей эта часть отчета будет отличаться. При оценке качества функционала на уровне Smoke теста оно может быть ли- бо приемлемым (Acceptable), либо неприемлемым (Unacceptable). Если все наибо- лее важные функции работают корректно, то качество всего функционала на уровне Smoke может быть оценено, как приемлемое. Если это релизная или предрелизная сборка, то для выставления приемлемого качества на уровне Smoke не должно быть найдено функциональных дефектов. 60 В части о детализированной информации качества сборки следует более по- дробно описать проблемы, которые были найдены во время теста. При оценке качества функционала на уровне Defect Validation указываются результаты валидации дефектов, а именно: общее количество всех дефектов, поступивших на проверку; количество неисправленных дефектов и их процент от общего количества; список дефектов, которые не были проверены и причины, по которым это- го не было сделано; наглядная таблица с неисправленными дефектами. По вышеуказанным результатам выставляется качество теста. Если процент неисправленных дефектов меньше 10 %, то качество приемлемое (Acceptable), ес- ли больше 10 %, то качество неприемлемое (Unacceptable). При оценке качества функционала на уровне New Feature Test (полный тест нового функционала) качество отдельно проверенного функционала может быть высокое (High), среднее (Medium), низкое (Low). Важно отдельно указывать информацию о качестве каждого модуля нового функционала с аргументацией выставленной оценки. При оценке качества функционала на уровне Regression Testing нужно анали- зировать динамику изменения качества проверенной функциональности в сравне- нии с более ранними версиями сборки. Для этого приводится сравнительная ха- рактеристика каждой из частей функционала в сравнении с предыдущими версия- ми сборки, даются ясные пояснения о выставлении соответствующего качества каждой функции в отдельности. Так же как и у предыдущего вида тестов, качество может быть высокое (High), среднее (Medium), низкое (Low). Список самых критичных дефектов содержит 3–5 ссылок на наиболее кри- тичные дефекты с указанием их названия и уровня критичности. Рекомендации включают краткую информацию о всех проблемах приложе- ния с пояснениями, насколько оставшиеся проблемы являются критичными для конечного пользователя. Обязательно указывают функционал и дефекты, скорей- шее исправление которых является наиболее приоритетным. Кроме того, если сборка является релизной или предрелизной, то любое ухудшение качества явля- ется критичным и важно это обозначить. Практическое задание: 1. Составить итоговый отчет по результатам тестирования web-приложения. 2. Указать общую информацию о тестируемом продукте (название, номер сборки, виды выполненных тестов, количество обнаруженных дефектов, вид ра- бочей тестовой документации). 3. Указать, кто и когда тестировал программный продукт. 4. Описать тестовое окружение (ссылку на web-приложение, браузер). 61 5. Указать общую оценку качества протестированного приложения и по- дробно ее обосновать. 6. Графически (в виде круговой диаграммы) отразить процентное соотноше- ние дефектов GUI и функциональных дефектов. 7. Графически (в виде столбчатой диаграммы) отразить распределение де- фектов по различным степеням критичности. 8. Графически (в виде столбчатой диаграммы) отразить распределение де- фектов по модулям. 9. Произвести детальный анализ качества всех модулей протестированного приложения с аргументацией выставленных уровней качества. 10. Привести список пяти наиболее критичных дефектов. 11. Сформулировать рекомендации по улучшению качества программного продукта. 12. Оформить отчет и защитить лабораторную работу. Содержание отчета: 1. Цель работы. 2. Итоговый отчет о результатах тестирования web-приложения. 3. Выводы по работе. Контрольные вопросы: 1. Какова структура итогового отчета о результатах тестирования? 2. Что содержится в разделе «Общая информация»? 3. Что содержится в разделе «Тестовое окружение»? 4. Как выставляется общая оценка качества приложения? 5. Как обосновать выставленную оценку качества? 6. Что такое метрика в тестировании? 7. Приведите примеры прямых метрик. 8. Приведите примеры расчетных метрик. 9. Для чего используется графическое представление результатов тестиро- вания в итоговом отчете? 10. Что содержится в разделе «Детализированный анализ качества»? 11. Что содержится в разделе «Рекомендации»? |