Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Спецификация теста (test specification 292 ) — документ, состоящий из специ- фикации тест-дизайна (test design specification 293 ), спецификации тест-кейса (test case specification 289 ) и/или спецификации тест-процедуры (test procedure specifica- tion 294 ). Тест-сценарий (test scenario 295 , test procedure specification, test script) — до- кумент, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»). Внимание! Из-за особенностей перевода очень часто под термином «тест- сценарий» («тестовый сценарий») имеют в виду набор тест-кейсов {143} Цель написания тест-кейсов Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне в зависи- мости от множества факторов). Наличие же тест-кейсов позволяет: • Структурировать и систематизировать подход к тестированию (без чего круп- ный проект почти гарантированно обречён на провал). • Вычислять метрики тестового покрытия (test coverage 296 metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл). • Отслеживать соответствие текущей ситуации плану (сколько примерно пона- добится тест-кейсов, сколько уже есть, сколько выполнено из запланирован- ного на данном этапе количества и т.д.). • Уточнить взаимопонимание между заказчиком, разработчиками и тестиров- 288 Low level test case. A test case with concrete (implementation level) values for input data and expected results. Logical operators from high level test cases are replaced by actual values that correspond to the objectives of the logical operators. [ISTQB Glos- sary] 289 Test case specification. A document specifying a set of test cases (objective, inputs, test actions, expected results, and execution preconditions) for a test item. [ISTQB Glossary] 290 Test item. The individual element to be tested. There usually is one test object and many test items. [ISTQB Glossary] 291 Test object. The component or system to be tested. [ISTQB Glossary] 292 Test specification. A document that consists of a test design specification, test case specification and/or test procedure specifi- cation. [ISTQB Glossary] 293 Test design specification. A document specifying the test conditions (coverage items) for a test item, the detailed test approach and identifying the associated high level test cases. [ISTQB Glossary] 294 Test procedure specification (test procedure). A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [ISTQB Glossary] 295 Test scenario. A document specifying a sequence of actions for the execution of a test. Also known as test script or manual test script. [ISTQB Glossary] 296 Coverage (test coverage). The degree, expressed as a percentage, to which a specified coverage item (an entity or property used as a basis for test coverage, e.g. equivalence partitions or code statements) has been exercised by a test suite. [ISTQB Glossary] Тест-кейс и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 119/298 щиками (тест-кейсы зачастую намного более наглядно показывают поведе- ние приложения, чем это отражено в требованиях). • Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или как минимум — не пытаться удержать в голове сотни страниц текста). • Проводить регрессионное тестирование {84} и повторное тестирование {84} (ко- торые без тест-кейсов было бы вообще невозможно выполнить). • Повышать качество требований (мы это уже рассматривали: написание чек- листов и тест-кейсов — хорошая техника тестирования требований {49} ). • Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту. Жизненный цикл тест-кейса В отличие от отчёта о дефекте, у которого есть полноценный развитый жиз- ненный цикл {167} , для тест-кейса речь скорее идёт о наборе состояний (см. рисунок 2.4.a) , в которых он может находиться (жирным шрифтом отмечены наиболее важ- ные состояния). Рисунок 2.4.a — Жизненный цикл (набор состояний) тест-кейса • Создан (new) — типичное начальное состояние практически любого арте- факта. Тест-кейс автоматически переходит в это состояние после создания. • Запланирован (planned, ready for testing) — в этом состоянии тест-кейс нахо- дится, когда он или явно включён в план ближайшей итерации тестирования, или как минимум готов для выполнения. Создан Запланирован Выполняется Пройден успешно Закрыт Т ре б уе т д ор аб от ки Провален Заблокирован Не выполнен Пропущен Тест-кейс и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 120/298 • Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен. • Выполняется (work in progress) — если тест-кейс требует длительного вре- мени на выполнение, он может быть переведён в это состояние для подчёр- кивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как пра- вило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован». • Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса от- меняется по соображениям нехватки времени или изменения логики тести- рования. • Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактиче- ским результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидае- мыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте). • Пройден успешно (passed) — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхож- дением ожидаемых и фактических результатов его шагов. • Заблокирован (blocked) — данное состояние означает, что по какой-то при- чине выполнение тест-кейса невозможно (как правило, такой причиной явля- ется наличие дефекта, не позволяющего реализовать некий пользователь- ский сценарий). • Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, остав- ляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В данное состояние в некоторых системах управления тест-кейс переводят, чтобы подчеркнуть тот факт, что на данной итерации тестирования все дей- ствия с ним завершены. • Требует доработки (not ready) — как видно из схемы, в это состояние (и из него) тест-кейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния. Ещё раз подчеркнём, что в отличие от жизненного цикла дефекта, который достаточно стандартизирован и формализован, для тест-кейса описанное выше но- сит общий рекомендательный характер, рассматривается скорее как разрозненный набор состояний (а не строгий жизненный цикл) и может сильно отличаться в раз- ных компаниях (в связи с имеющимися традициями и/или возможностями систем управления тест-кейсами). Атрибуты (поля) тест-кейса Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 121/298 2.4.3. Атрибуты (поля) тест-кейса Как уже было сказано выше, термин «тест-кейс» может относиться к фор- мальной записи тест-кейса в виде технического документа. Эта запись имеет об- щепринятую структуру, компоненты которой называются атрибутами (полями) тест- кейса. В зависимости от инструмента управления тест-кейсами внешний вид их за- писи может немного отличаться, могут быть добавлены или убраны отдельные поля, но концепция остаётся неизменной. Общий вид всей структуры тест-кейса представлен на рисунке 2.4.b. UG_U1.12 A R97 Га- ле- рея Панель загрузки Загрузка картинки (имя со спецсимволами) Приготовления: создать непустой файл с именем #$%^&.jpg. 1. Выбрать вкладку «За- грузить». 2. Нажать кнопку «Вы- брать». 3. Выбрать из списка приготовленный файл. 4. Нажать кнопку «OK». 5. Нажать кнопку «Доба- вить в галерею». 1. Вкладка «Загрузить» становится активной. 2. Появляется диалого- вое окно браузера вы- бора файла для за- грузки. 3. Имя выбранного файла появляется в поле «Файл». 4. Диалоговое окно файла закрывается, в поле «Файл» появля- ется полное имя файла. 5. Выбранный файл появляется в списке файлов галереи. Рисунок 2.4.b — Общий вид тест-кейса Теперь рассмотрим каждый атрибут подробно. Идентификатор (identifier) представляет собой уникальное значение, позво- ляющее однозначно отличить один тест-кейс от другого и используемое во всевоз- можных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суф- фиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например: UR216_S12_DB_Neg). Приоритет (priority) показывает важность тест-кейса. Он может быть выра- жен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трёх до пяти. Приоритет тест-кейса может коррелировать с: • важностью требования, пользовательского сценария {143} или функции, с кото- рыми связан тест-кейс; • потенциальной важностью дефекта {176} , на поиск которого направлен тест- кейс; Иденти- фикатор Приоритет Связанное с тест-кейсом требование Модуль и подмо- дуль приложения Заглавие (суть) тест-кейса Исходные данные, не- обходимые для выпол- нения тест-кейса Шаги тест-кейса Ожидаемый результат по каждому шагу тест-кейса Атрибуты (поля) тест-кейса Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 122/298 • степенью риска, связанного с проверяемым тест-кейсом требованием, сце- нарием или функцией. Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертво- вать в некоей форс-мажорной ситуации, не позволяющей выполнить все заплани- рованные тест-кейсы. Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное — по- тому, что один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость {140} Частые вопросы, связанные с заполнением этого поля, таковы: • Можно ли его оставить пустым? Да. Тест-кейс вполне мог разрабатываться вне прямой привязки к требованиям, и (пока?) значение этого поля опреде- лить сложно. Хоть такой вариант и не считается хорошим, он достаточно рас- пространён. • Можно ли в этом поле указывать несколько требований? Да, но чаще всего стараются выбрать одно самое главное или «более высокоуровневое» (например, вместо того, чтобы перечислять R56.1, R56.2, R56.3 и т.д., можно просто написать R56). Чаще всего в инструментах управления тестами это поле представляет собой выпадающий список, где можно выбрать только одно значение, и этот вопрос становится неактуальным. К тому же многие тест-кейсы всё же направлены на проверку строго одного требования, и для них этот вопрос также неактуален. Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект цели- ком, и вопрос «как протестировать это приложение» становится недопустимо слож- ным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). И вот уже для таких не- больших частей приложения придумать чек-листы и создать хорошие тест-кейсы становится намного проще. Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. Теперь — самое сложное: как выбираются модули и подмодули. В реально- сти проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении {57} можно выделить такую иерархию модулей и под- модулей: • Механизм запуска: o механизм анализа параметров; o механизм сборки приложения; o механизм обработки ошибочных ситуаций. • Механизм взаимодействия с файловой системой: o механизм обхода дерева SOURCE_DIR; o механизм обработки ошибочных ситуаций. Атрибуты (поля) тест-кейса Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 123/298 • Механизм преобразования файлов: o механизм определения кодировок; o механизм преобразования кодировок; o механизм обработки ошибочных ситуаций. • Механизм ведения журнала: o механизм записи журнала; o механизм отображения журнала в консоли; o механизм обработки ошибочных ситуаций. Согласитесь, что такие длинные названия с постоянно повторяющимся сло- вом «механизм» читать и запоминать сложно. Перепишем: • Стартер: o анализатор параметров; o сборщик приложения; o обработчик ошибок. • Сканер: o обходчик; o обработчик ошибок. • Преобразователь: o детектор; o конвертер; o обработчик ошибок. • Регистратор: o дисковый регистратор; o консольный регистратор; o обработчик ошибок. Но что делать, если мы не знаем «внутренностей» приложения (или не очень разбираемся в программировании)? Модули и подмодули можно выделять на ос- нове графического интерфейса пользователя (крупные области и элементы внутри них), на основе решаемых приложением задач и подзадач и т.д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению. Внимание! Частая ошибка! Модуль и подмодуль приложения — это НЕ действия, это именно структурные части, «куски» приложения. В заблуж- дение вас могут ввести такие названия, как, например, «печать, настройка принтера» (но здесь имеются в виду именно части приложения, отвечаю- щие за печать и за настройку принтера (и названы они отглагольными су- ществительными), а не процесс печати или настройки принтера). Сравните (на примере человека): «дыхательная система, лёгкие» — это модуль и подмодуль, а «дыхание», «сопение», «чихание» — нет; «голова, мозг» — это модуль и подмодуль, а «кивание», «думание» — нет. Наличие полей «Модуль» и «Подмодуль» улучшает такое свойство тест- кейса, как прослеживаемость {140} Атрибуты (поля) тест-кейса Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 124/298 Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест- кейсов. Сравните. Плохо Хорошо Тест 1 Запуск, одна копия, верные параметры Тест 2 Запуск одной копии с неверными путями Тест 78 (улучшенный) Запуск, много копий, без конфликтов Остановка Остановка по Ctrl+C Закрытие Остановка закрытием консоли … … Заглавие тест-кейса может быть полноценным предложением, фразой, набо- ром словосочетаний — главное, чтобы выполнялись следующие условия: • Информативность. • Хотя бы относительная уникальность (чтобы не путать разные тест-кейсы). Внимание! Частая ошибка! Если инструмент управления тест-кейсами не требует писать заглавие, его всё равно надо писать. Тест-кейсы без за- главий превращаются в мешанину информации, использование которой сопряжено с колоссальными и совершенно бессмысленными затратами. И ещё одна небольшая мысль, которая может помочь лучше формулировать заглавия. В дословном переводе с английского «test case» обозначает «тестовый случай (ситуация)». Так вот, заглавие как раз и описывает этот случай (ситуацию), т.е. что происходит в тест-кейсе, какую ситуацию он проверяет. Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например: • Состояние базы данных. • Состояние файловой системы и её объектов. • Состояние серверов и сетевой инфраструктуры. То, что описывается в этом поле, готовится БЕЗ использования тестируемого приложения, и таким образом, если здесь возникают проблемы, нельзя писать от- чёт о дефекте в приложении. Эта мысль очень и очень важна, потому поясним её простым жизненным примером. Представьте, что вы дегустируете конфеты. В поле «исходные данные» можно прописать «купить конфеты таких-то сортов в таком-то количестве». Если таких конфет нет в продаже, если закрыт магазин, если не хва- тило денег и т.д. — всё это НЕ проблемы вкуса конфет, и нельзя писать отчёт о дефекте конфет вида «конфеты невкусные потому, что закрыт магазин». Некоторые авторы не следуют этой логике и допускают в разделе «приго- товления» работу с тестируемым приложением. И здесь нет «правильного варианта» — просто в одной традиции решено одним образом, в другой — другим. Во многом это — ещё и терминологическая проблема: «preparation», «initial data» и «setup» вполне логично выполнять без уча- стия тестируемого приложения, в то время как «precondition» по смыслу ближе к описанию состояния тестируемого приложения. В реальной рабо- чей обстановке вам достаточно будет прочитать несколько тест-кейсов, уже созданных вашими коллегами, чтобы понять, какой точки зрения на данный вопрос они придерживаются. |