Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Тестовая стратегия (test strategy 329 ) и подходы (test approach 330 ). Описание процесса тестирования с точки зрения применяемых методов, подходов, ви- дов тестирования, технологий, инструментальных средств и т.д. • Критерии (criteria). Этот раздел включает следующие подразделы: o Приёмочные критерии, критерии качества (acceptance criteria 331 ) — любые объективные показатели качества, которым разрабатываемый продукт должен соответствовать с точки зрения заказчика или пользо- вателя, чтобы считаться готовым к эксплуатации. o Критерии начала тестирования (entry criteria 332 ) — перечень условий, при выполнении которых команда приступает к тестированию. Нали- чие этого критерия страхует команду от бессмысленной траты усилий в условиях, когда тестирование не принесёт ожидаемой пользы. o Критерии приостановки тестирования (suspension criteria 333 ) — пе- речень условий, при выполнении которых тестирование приостанав- ливается. Наличие этого критерия также страхует команду от бессмыс- ленной траты усилий в условиях, когда тестирование не принесёт ожи- даемой пользы. o Критерии возобновления тестирования (resumption criteria 334 ) — пе- речень условий, при выполнении которых тестирование возобновля- ется (как правило, после приостановки). o Критерии завершения тестирования (exit criteria 335 ) — перечень условий, при выполнении которых тестирование завершается. Нали- чие этого критерия страхует команду как от преждевременного прекра- щения тестирования, так и от продолжения тестирования в условиях, когда оно уже перестаёт приносить ощутимый эффект. • Ресурсы (resources). В данном разделе тест-плана перечисляются все необ- ходимые для успешной реализации стратегии тестирования ресурсы, кото- рые в общем случае можно разделить на: o программные ресурсы (какое ПО необходимо команде тестировщиков, сколько копий и с какими лицензиями (если речь идёт о коммерческом ПО)); 329 Test strategy. A high-level description of the test levels to be performed and the testing within those levels (group of test activities that are organized and managed together, e.g. component test, integration test, system test and acceptance test) for an organi- zation or program (one or more projects). [ISTQB Glossary] 330 Test approach. The implementation of the test strategy for a specific project. It typically includes the decisions made that follow based on the (test) project’s goal and the risk assessment carried out, starting points regarding the test process, the test design techniques to be applied, exit criteria and test types to be performed. [ISTQB Glossary] 331 Acceptance criteria. The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity. [ISTQB Glossary] 332 Entry criteria. The set of generic and specific conditions for permitting a process to go forward with a defined task, e.g. test phase. The purpose of entry criteria is to prevent a task from starting which would entail more (wasted) effort compared to the effort needed to remove the failed entry criteria. [ISTQB Glossary] 333 Suspension criteria. The criteria used to (temporarily) stop all or a portion of the testing activities on the test items. [ISTQB Glossary] 334 Resumption criteria. The criteria used to restart all or a portion of the testing activities that were suspended previously. [ISTQB Glossary] 335 Exit criteria. The set of generic and specific conditions, agreed upon with the stakeholders for permitting a process to be officially completed. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task which have not been finished. Exit criteria are used to report against and to plan when to stop testing. [ISTQB Glossary] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 210/298 o аппаратные ресурсы (какое аппаратное обеспечение, в каком количе- стве и к какому моменту необходимо команде тестировщиков); o человеческие ресурсы (сколько специалистов какого уровня и со зна- ниями в каких областях должно подключиться к команде тестировщи- ков в тот или иной момент времени); o временные ресурсы (сколько по времени займёт выполнение тех или иных работ); o финансовые ресурсы (в какую сумму обойдётся использование имею- щихся или получение недостающих ресурсов, перечисленных в предыдущих пунктах этого списка); во многих компаниях финансовые ресурсы могут быть представлены отдельным документом, т.к. явля- ются конфиденциальной информацией. • Расписание (test schedule 336 ). Фактически это календарь, в котором указано, что и к какому моменту должно быть сделано. Особое внимание уделяется т.н. «ключевым точкам» (milestones), к моменту наступления которых должен быть получен некий значимый ощутимый результат. • Роли и ответственность (roles and responsibility). Перечень необходимых ролей (например, «ведущий тестировщик», «эксперт по оптимизации произ- водительности») и область ответственности специалистов, выполняющих эти роли. • Оценка рисков (risk evaluation). Перечень рисков, которые с высокой веро- ятностью могут возникнуть в процессе работы над проектом. По каждому риску даётся оценка представляемой им угрозы и приводятся варианты вы- хода из ситуации. • Документация (documentation). Перечень используемой тестовой докумен- тации с указанием, кто и когда должен её готовить и кому передавать. • Метрики (metrics 337 ). Числовые характеристики показателей качества, спо- собы их оценки, формулы и т.д. На этот раздел, как правило, формируется множество ссылок из других разделов тест-плана. Метрики в тестировании являются настолько важными, что о них мы погово- рим отдельно. Итак. Метрика (metric 337 ) — числовая характеристика показателя качества. Мо- жет включать описание способов оценки и анализа результата. Сначала поясним важность метрик на тривиальном примере. Представьте, что заказчик интересуется текущим положением дел и просит вас кратко охаракте- ризовать ситуацию с тестированием на проекте. Общие слова в стиле «всё хо- рошо», «всё плохо», «нормально» и тому подобное его, конечно, не устроят, т.к. они предельно субъективны и могут быть крайне далеки от реальности. И совсем иначе выглядит ответ наподобие такого: «Реализовано 79 % требований (в т.ч. 94 % важ- ных), за последние три спринта тестовое покрытие выросло с 63 % до 71 %, а общий показатель прохождения тест-кейсов вырос с 85 % до 89 %. Иными словами, мы полностью укладываемся в план по всем ключевым показателям, а по разработке даже идём с небольшим опережением». 336 Test schedule. A list of activities, tasks or events of the test process, identifying their intended start and finish dates and/or times, and interdependencies. [ISTQB Glossary] 337 Metric. A measurement scale and the method used for measurement. [ISTQB Glossary] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 211/298 Чтобы оперировать всеми этими числами (а они нужны не только для отчёт- ности, но и для организации работы проектной команды), их нужно как-то вычис- лить. Именно это и позволяют сделать метрики. Затем вычисленные значения можно использовать для: • принятия решений о начале, приостановке, возобновлении или прекращении тестирования (см. выше раздел «Критерии» тест-плана); • определения степени соответствия продукта заявленным критериям каче- ства; • определения степени отклонения фактического развития проекта от плана; • выявления «узких мест», потенциальных рисков и иных проблем; • оценки результативности принятых управленческих решений; • подготовки объективной информативной отчётности; • и т.д. Метрики могут быть как прямыми (не требуют вычислений), так и расчётными (вычисляются по формуле). Типичные примеры прямых метрик — количество раз- работанных тест-кейсов, количество найденных дефектов и т.д. В расчётных мет- риках могут использоваться как совершенно тривиальные, так и довольно сложные формулы (см. таблицу 2.6.1). Таблица 2.6.1 — Примеры расчётных метрик Простая расчётная метрика Сложная расчётная метрика 𝑇 𝑆𝑃 = 𝑇 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 𝑇 𝑇𝑜𝑡𝑎𝑙 ∙ 100%, где 𝑇 𝑆𝑃 — процентный показатель успеш- ного прохождения тест-кейсов, 𝑇 𝑆𝑢𝑐𝑐𝑒𝑠𝑠 — количество успешно выпол- ненных тест-кейсов, 𝑇 𝑇𝑜𝑡𝑎𝑙 — общее количество выполнен- ных тест-кейсов. Минимальные границы значений: • Начальная фаза проекта: 10 %. • Основная фаза проекта: 40 %. • Финальная фаза проекта: 85 %. 𝑇 𝑆𝐶 = ∑ (𝑇 𝐿𝑒𝑣𝑒𝑙 ∙𝐼) 𝑅𝐿𝑒𝑣𝑒𝑙 𝐵 𝐿𝑒𝑣𝑒𝑙 𝑀𝑎𝑥𝐿𝑒𝑣𝑒𝑙 𝐿𝑒𝑣𝑒𝑙 , где 𝑇 𝑆𝐶 — интегральная метрика прохождения тест-кейсов во взаимосвязи с требованиями и дефектами, 𝑇 𝐿𝑒𝑣𝑒𝑙 — степень важности тест-кейса, 𝐼 — количество выполнений тест-кейса, 𝑅 𝐿𝑒𝑣𝑒𝑙 — степень важности требования, проверяемого тест-кейсом, 𝐵 𝐿𝑒𝑣𝑒𝑙 — количество дефектов, обнаруженных тест-кей- сом. Способ анализа: • Идеальным состоянием является непрерывный рост значения 𝑇 𝑆𝐶 • В случае отрицательной динамики уменьшение значе- ния 𝑇 𝑆𝐶 на 15 % и более за последние три спринта мо- жет трактоваться как недопустимое и являться доста- точным поводом для приостановки тестирования. В тестировании существует большое количество общепринятых метрик, мно- гие из которых могут быть собраны автоматически с использованием инструмен- тальных средств управления проектами. Например 338 : • процентное отношение (не) выполненных тест-кейсов ко всем имеющимся; • процентный показатель успешного прохождения тест-кейсов (см. «Простая расчётная метрика» в таблице 2.6.1); • процентный показатель заблокированных тест-кейсов; • плотность распределения дефектов; • эффективность устранения дефектов; • распределение дефектов по важности и срочности; • и т.д. 338 «Important Software Test Metrics and Measurements — Explained with Examples and Graphs» [ http://www.softwaretest- inghelp.com/software-test-metrics-and-measurements/ ] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 212/298 Как правило, при формировании отчётности нас будет интересовать не только текущее значение метрики, но и её динамика во времени, которую очень удобно изображать графически (что тоже могут выполнять автоматически многие средства управления проектами). Некоторые метрики могут вычисляться на основе данных о расписании, например метрика «сдвига расписания»: 𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒 = 𝐷𝑎𝑦𝑠𝑇𝑜𝐷𝑒𝑎𝑑𝑙𝑖𝑛𝑒 𝑁𝑒𝑒𝑑𝑒𝑑𝐷𝑎𝑦𝑠 − 1 , где 𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒 — значение сдвига расписания, 𝐷𝑎𝑦𝑠𝑇𝑜𝐷𝑒𝑎𝑑𝑙𝑖𝑛𝑒 — количество дней до запланированного завершения работы, 𝑁𝑒𝑒𝑑𝑒𝑑𝐷𝑎𝑦𝑠 — количество дней, необходимое для завершения работы. Значение 𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒 не должно становиться отрицательным. Таким образом, мы видим, что метрики являются мощнейшим средством сбора и анализа информации. И вместе с тем здесь кроется опасность: ни при каких условиях нельзя допускать ситуации «метрик ради метрик», когда инструменталь- ное средство собирает уйму данных, вычисляет множество чисел и строит десятки графиков, но… никто не понимает, как их трактовать. Обратите внимание, что к обеим метрикам в таблице 2.6.1 и к только что рассмотренной метрике 𝑆𝑐ℎ𝑒𝑑𝑢𝑙𝑒𝑆𝑙𝑖𝑝𝑝𝑎𝑔𝑒 прилагается краткое руководство по их трактовке. И чем сложнее и уникальнее метрика, тем более подробное руководство необходимо для её эф- фективного применения. И, наконец, стоит упомянуть про так называемые «метрики покрытия», т.к. они очень часто упоминаются в различной литературе. Покрытие (coverage 339 ) — процентное выражение степени, в которой ис- следуемый элемент (coverage item 340 ) затронут соответствующим набором тест-кейсов. Самыми простыми представителями метрик покрытия можно считать: • Метрику покрытия требований (требование считается «покрытым», если на него ссылается хотя бы один тест-кейс): 𝑅 𝑆𝑖𝑚𝑝𝑙𝑒𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = 𝑅 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 𝑅 𝑇𝑜𝑡𝑎𝑙 ∙ 100% , где 𝑅 𝑆𝑖𝑚𝑝𝑙𝑒𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 — метрика покрытия требований, 𝑅 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 — количество требований, покрытых хотя бы одним тест-кейсом, 𝑅 𝑇𝑜𝑡𝑎𝑙 — общее количество требований. • Метрику плотности покрытия требований (учитывается, сколько тест-кейсов ссылается на несколько требований): 𝑅 𝐷𝑒𝑛𝑠𝑖𝑡𝑦𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = ∑ 𝑇 𝑖 𝑇 𝑇𝑜𝑡𝑎𝑙 ∙𝑅 𝑇𝑜𝑡𝑎𝑙 ∙ 100% , где 𝑅 𝐷𝑒𝑛𝑠𝑖𝑡𝑦𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 — плотность покрытия требований, 𝑇 𝑖 — количество тест-кейсов, покрывающих i-е требование, 𝑇 𝑇𝑜𝑡𝑎𝑙 — общее количество тест-кейсов, 𝑅 𝑇𝑜𝑡𝑎𝑙 — общее количество требований. 339 Coverage, Test coverage. The degree, expressed as a percentage, to which a specified coverage item has been exercised by a test suite. [ISTQB Glossary] 340 Coverage item. An entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements. [ISTQB Glossary] Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 213/298 • Метрику покрытия классов эквивалентности (анализируется, сколько классов эквивалентности затронуто тест-кейсами): 𝐸 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = 𝐸 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 𝐸 𝑇𝑜𝑡𝑎𝑙 ∙ 100% , где 𝐸 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 — метрика покрытия классов эквивалентности, 𝐸 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 — количество классов эквивалентности, покрытых хотя бы одним тест-кейсом, 𝐸 𝑇𝑜𝑡𝑎𝑙 — общее количество классов эквивалентности. • Метрику покрытия граничных условий (анализируется, сколько значений из группы граничных условий затронуто тест-кейсами): 𝐵 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 = 𝐵 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 𝐵 𝑇𝑜𝑡𝑎𝑙 ∙ 100% , где 𝐵 𝐶𝑜𝑣𝑒𝑟𝑎𝑔𝑒 — метрика покрытия граничных условий, 𝐵 𝐶𝑜𝑣𝑒𝑟𝑒𝑑 — количество граничных условий, покрытых хотя бы одним тест-кейсом, 𝐵 𝑇𝑜𝑡𝑎𝑙 — общее количество граничных условий. • Метрики покрытия кода модульными тест-кейсами. Таких метрик очень много, но вся их суть сводится к выявлению некоей характеристики кода (ко- личество строк, ветвей, путей, условий и т.д.) и определению, какой процент представителей этой характеристики покрыт тест-кейсами. Метрик покрытия настолько много, что даже в ISTQB-глоссарии дано определение полутора десяткам таковых. Вы можете найти эти определе- ния, выполнив в файле ISTQB-глоссария поиск по слову «coverage». На этом мы завершаем теоретическое рассмотрение планирования и пере- ходим к примеру — учебному тест-плану для нашего приложения «Конвертер фай- лов {57} ». Напомним, что приложение является предельно простым, потому и тест- план будет очень маленьким (однако, обратите внимание, сколь значительную его часть будет занимать раздел метрик). Пример тест-плана Для того чтобы заполнить некоторые части тест-плана, нам придётся сде- лать допущения о составе проектной команды и времени, отведённом на разра- ботку проекта. Поскольку данный тест-план находится внутри текста книги, у него нет таких типичных частей, как заглавная страница, содержание и т.п. Итак. Цель Корректное автоматическое преобразование содержимого документов к еди- ной кодировке с производительностью, значительно превышающей производи- тельность человека при выполнении аналогичной задачи. Области, подвергаемые тестированию ( См. соответствующие разделы требований.) • ПТ-1 .*: дымовой тест. • ПТ-2 .*: дымовой тест, тест критического пути. • ПТ-3 .* : тест критического пути. • БП-1 .*: дымовой тест, тест критического пути. • АК-2 .*: дымовой тест, тест критического пути. • О-4 : дымовой тест. • О-5 : дымовой тест. • ДС -*: дымовой тест, тест критического пути. Тест-план и отчёт о результатах тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 214/298 Области, не подвергаемые тестированию • СХ-1 : приложение разрабатывается как консольное. • СХ-2 , О-1 , О-2 : приложение разрабатывается на PHP указанной версии. • АК-1.1 : заявленная характеристика находится вблизи нижней границы произ- водительности операций, характерных для разрабатываемого приложения. • О-3 : не требует реализации. • О-6 : не требует реализации. Тестовая стратегия и подходы Общий подход. Специфика работы приложения состоит в однократном конфигурировании опытным специалистом и дальнейшем использовании конечными пользователями, для которых доступна только одна операция — размещение файла в каталоге-при- ёмнике. Потому вопросы удобства использования, безопасности и т.п. не исследу- ются в процессе тестирования. Уровни функционального тестирования: • Дымовой тест: автоматизированный с использованием командных файлов ОС Windows и Linux. • Тест критического пути: выполняется вручную. • Расширенный тест не производится, т.к. для данного приложения вероят- ность обнаружения дефектов на этом уровне пренебрежимо мала. В силу кроссфункциональности команды значительного вклада в повышение качества можно ожидать от аудита кода, совмещённого с ручным тестированием по методу белого ящика. Автоматизация тестирования кода не будет применяться в силу крайне ограниченного времени. Критерии • Приёмочные критерии: успешное прохождение 100 % тест-кейсов уровня ды- мового тестирования и 90 % тест-кейсов уровня критического пути (см. мет- рику « Успешное прохождение тест-кейсов ») при условии устранения 100 % дефектов критической и высокой важности (см. метрику « Общее устранение дефектов »). Итоговое покрытие требований тест-кейсами (см. метрику « По- крытие требований тест-кейсами ») должно составлять не менее 80 %. • Критерии начала тестирования: выход билда. • Критерии приостановки тестирования: переход к тесту критического пути до- пустим только при успешном прохождении 100 % тест-кейсов дымового теста (см. метрику « Успешное прохождение тест-кейсов »); тестирование может быть приостановлено в случае, если при выполнении не менее 25 % запла- нированных тест-кейсов более 50 % из них завершились обнаружением де- фекта (см. метрику « Стоп-фактор »). • Критерии возобновления тестирования: исправление более 50 % обнаружен- ных на предыдущей итерации дефектов (см. метрику « Текущее устранение дефектов »). • Критерии завершения тестирования: выполнение более 80 % запланирован- ных на итерацию тест-кейсов (см. метрику « Выполнение тест-кейсов »). |