Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
2.4. Чек-листы, тест-кейсы, наборы тест-кейсов 2.4.1. Чек-лист Как легко можно понять из предыдущих глав, тестировщику приходится ра- ботать с огромным количеством информации, выбирать из множества вариантов решения задач и изобретать новые. В процессе этой деятельности объективно не- возможно удержать в голове все мысли, а потому продумывание и разработку тест- кейсов рекомендуется выполнять с использованием «чек-листов». Чек-лист (checklist 281 ) — набор идей [тест-кейсов]. Последнее слово не зря взято в скобки 282 , т.к. в общем случае чек-лист — это просто набор идей: идей по тестированию, идей по разработке, идей по планированию и управлению — любых идей. Чек-лист чаще всего представляет собой обычный и привычный нам список: • в котором последовательность пунктов не имеет значения (например, список значений некоего поля); • в котором последовательность пунктов важна (например, шаги в краткой ин- струкции); • структурированный (многоуровневый) список, который позволяет отразить иерархию идей. Важно понять, что нет и не может быть никаких запретов и ограничений при разработке чек-листов — главное, чтобы они помогали в работе. Иногда чек-листы могут даже выражаться графически (например, с использованием ментальных карт 283 или концепт-карт 284 ), хотя традиционно их составляют в виде многоуровне- вых списков. Поскольку в разных проектах встречаются однотипные задачи, хорошо про- думанные и аккуратно оформленные чек-листы могут использоваться повторно, чем достигается экономия сил и времени. Внимание! Очень частым является вопрос о том, нужно ли в чек-листах писать ожидаемые результаты. В классическом понимании чек-листа – нет (хоть это и не запрещено), т.к. чек-лист – это набор идей, а их детали- зация в виде шагов и ожидаемых результатов будет в тест-кейсах. Но ожи- даемые результаты могут добавляться, например, в следующих случаях: • в некоем пункте чек-листа рассматривается особое, нетривиальное по- ведение приложения или сложная проверка, результат которой важно отметить уже сейчас, чтобы не забыть; • в силу сжатых сроков и/или нехватки иных ресурсов тестирование про- водится напрямую по чек-листам без тест-кейсов. 281 Понятие «чек-листа» не завязано на тестировании как таковом — это совершенно универсальная техника, которая может применяться в любой без исключения области жизни. В русском языке вне контекста информационных технологий чаще используется понятное и привычное слово «список» (например, «список покупок», «список дел» и т.д.), но в тестирова- нии прижилась калькированная с английского версия — «чек-лист». 282 Если у вас возник вопрос «почему тут использованы квадратные скобки», ознакомьтесь с синтаксисом «расширенной формы Бэкуса-Наура», который де-факто является стандартом описания выражений в ИТ. См. «Extended Backus–Naur form», Wikipedia. [ https://en.wikipedia.org/wiki/Extended_Backus%E2%80%93Naur_form ] 283 «Mind map», Wikipedia. [ http://en.wikipedia.org/wiki/Mind_map ] 284 «Concept map», Wikipedia. [ http://en.wikipedia.org/wiki/Concept_map ] Чек-лист Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 113/298 Для того чтобы чек-лист был действительно полезным инструментом, он дол- жен обладать рядом важных свойств. Логичность. Чек-лист пишется не «просто так», а на основе целей и для того, чтобы помочь в достижении этих целей. К сожалению, одной из самых частых и опасных ошибок при составлении чек-листа является превращение его в свалку мыслей, которые никак не связаны друг с другом. Последовательность и структурированность. Со структурированностью всё достаточно просто — она достигается за счёт оформления чек-листа в виде многоуровневого списка. Что до последовательности, то даже в том случае, когда пункты чек-листа не описывают цепочку действий, человеку всё равно удобнее вос- принимать информацию в виде неких небольших групп идей, переход между кото- рыми является понятным и очевидным (например, сначала можно прописать идеи простых позитивных тест-кейсов {79} , потом идеи простых негативных тест-кейсов, потом постепенно повышать сложность тест-кейсов, но не стоит писать эти идеи вперемешку). Полнота и неизбыточность. Чек-лист должен представлять собой аккурат- ную «сухую выжимку» идей, в которых нет дублирования (часто появляется из-за разных формулировок одной и той же идеи), и в то же время ничто важное не упу- щено. Правильно создавать и оформлять чек-листы также помогает восприятие их не только как хранилища наборов идей, но и как «требования для составления тест- кейсов». Эта мысль приводит к пересмотру и переосмыслению свойств качествен- ных требований (см. главу «Свойства качественных требований» {41} ) в применении к чек-листам. Задание 2.4.a: перечитайте главу «Свойства качественных требова- ний» {41} и подумайте, какие свойства качественных требований можно также считать и свойствами качественных чек-листов. Итак, рассмотрим процесс создания чек-листа. В главе «Пример анализа и тестирования требований» {51} приведён пример итоговой версии требований {57} , ко- торый мы и будем использовать. Поскольку мы не можем сразу «протестировать всё приложение» (это слиш- ком большая задача, чтобы решить её одним махом), нам уже сейчас нужно вы- брать некую логику построения чек-листов — да, их будет несколько (в итоге их можно будет структурированно объединить в один, но это не обязательно). Типичными вариантами такой логики является создание отдельных чек-ли- стов для: • типичных пользовательских сценариев {143} ; • различных уровней функционального тестирования {76} ; • отдельных частей (модулей и подмодулей {122} ) приложения; • отдельных требований, групп требований, уровней и типов требований {36} ; • частей или функций приложения, наиболее подверженных рискам. Этот список можно расширять и дополнять, можно комбинировать его пункты, получая, например, чек-листы для проверки наиболее типичных сценариев, затрагивающих некую часть приложения. Чтобы проиллюстрировать принципы построения чек-листов, мы воспользу- емся логикой разбиения функций приложения по степени их важности на три кате- гории (см. классификацию по убыванию степени важности функций приложения {76} ): Чек-лист Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 114/298 • Базовые функции, без которых существование приложения теряет смысл (т.е. самые важные — то, ради чего приложение вообще создавалось), или нарушение работы которых создаёт объективные серьёзные проблемы для среды исполнения. (См. «Дымовое тестирование» {76} ). • Функции, востребованные большинством пользователей в их повседневной работе. (См. «Тестирование критического пути» {77} ). • Остальные функции (разнообразные «мелочи», проблемы с которыми не сильно повлияют на ценность приложения для конечного пользователя). (См. «Расширенное тестирование» {78} ). Функции, без которых существование приложения теряет смысл Сначала приведём целиком весь чек-лист для дымового тестирования, а по- том разберём его подробнее. • Конфигурирование и запуск. • Обработка файлов: Форматы входных файлов TXT HTML MD Кодировки входных фай- лов WIN1251 + + + CP866 + + + KOI8R + + + • Остановка. Да, и всё. Здесь перечислены все ключевые функции приложения. Конфигурирование и запуск. Если приложение невозможно настроить для работы в пользовательской среде, оно бесполезно. Если приложение не запуска- ется, оно бесполезно. Если на стадии запуска возникают проблемы, они могут нега- тивно отразиться на функционировании приложения и потому также заслуживают пристального внимания. Примечание: в нашем примере мы столкнулись со скорее нетипичным слу- чаем — приложение конфигурируется параметрами командной строки, а потому разделить операции «конфигурирования» и «запуска» не представляется возмож- ным; в реальной жизни для подавляющего большинства приложений эти операции выполняются раздельно. Обработка файлов. Ради этого приложение и разрабатывалось, потому здесь даже на стадии создания чек-листа мы не поленились создать матрицу, от- ражающую все возможные комбинации допустимых форматов и допустимых коди- ровок входных файлов, чтобы ничего не забыть и подчеркнуть важность соответ- ствующих проверок. Остановка. С точки зрения пользователя эта функция может не казаться столь уж важной, но остановка (и запуск) любого приложения связаны с большим количеством системных операций, проблемы с которыми могут привести к множе- ству серьёзных последствий (вплоть до невозможности повторного запуска прило- жения или нарушения работы операционной системы). Функции, востребованные большинством пользователей Следующим шагом мы будем выполнять проверку того, как приложение ве- дёт себя в обычной повседневной жизни, пока не затрагивая экзотические ситуа- ции. Очень частым вопросом является допустимость дублирования проверок на Чек-лист Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 115/298 разных уровнях функционального тестирования {76} — можно ли так делать. Одно- временно и «нет», и «да». «Нет» в том смысле, что не допускается (не имеет смысла) повторение тех же проверок, которые только что были выполнены. «Да» в том смысле, что любую проверку можно детализировать и снабдить дополнитель- ными деталями. • Конфигурирование и запуск: o С верными параметрами: ▪ Значения SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME указаны и содержат пробелы и кириллические символы (повто- рить для форматов путей в Windows и *nix файловых системах, обратить внимание на имена логических дисков и разделители имён каталогов (“/” и “\”)). ▪ Значение LOG_FILE_NAME не указано. o Без параметров. o С недостаточным количеством параметров. o С неверными параметрами: ▪ Недопустимый путь SOURCE_DIR. ▪ Недопустимый путь DESTINATION_DIR. ▪ Недопустимое имя LOG_FILE_NAME. ▪ DESTINATION_DIR находится внутри SOURCE_DIR. ▪ Значения DESTINATION_DIR и SOURCE_DIR совпадают. • Обработка файлов: o Разные форматы, кодировки и размеры: Форматы входных файлов TXT HTML MD Кодировки входных фай- лов WIN1251 100 КБ 50 МБ 10 МБ CP866 10 МБ 100 КБ 50 МБ KOI8R 50 МБ 10 МБ 100 КБ Любая 0 байт Любая 50 МБ + 1 Б 50 МБ + 1 Б 50 МБ + 1 Б - Любой недопустимый формат Любая Повреждения в допустимом формате o Недоступные входные файлы: ▪ Нет прав доступа. ▪ Файл открыт и заблокирован. ▪ Файл с атрибутом «только для чтения». • Остановка: o Закрытием окна консоли. • Журнал работы приложения: o Автоматическое создание (при отсутствии журнала). o Продолжение (дополнение журнала) при повторных запусках. • Производительность: o Элементарный тест с грубой оценкой. Обратите внимание, что чек-лист может содержать не только «предельно сжатые тезисы», но и вполне развёрнутые комментарии, если это необходимо — лучше пояснить суть идеи подробнее, чем потом гадать, что же имелось в виду. Также обратите внимание, что многие пункты чек-листа носят весьма высо- коуровневый характер, и это нормально. Например, «повреждения в допустимом формате» (см. матрицу с кодировками, форматами и размерами) звучит расплыв- чато, но этот недочёт будет устранён уже на уровне полноценных тест-кейсов. Чек-лист Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 116/298 Остальные функции и особые сценарии Пришло время обратить внимание на разнообразные мелочи и хитрые ню- ансы, проблемы с которыми едва ли сильно озаботят пользователя, но формально всё же будут считать ошибками. • Конфигурирование и запуск: o Значения SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME: ▪ В разных стилях (Windows-пути + *nix-пути) — одно в одном стиле, другое — в другом. ▪ С использованием UNC-имён. ▪ LOG_FILE_NAME внутри SOURCE_DIR. ▪ LOG_FILE_NAME внутри DESTINATION_DIR. o Размер LOG_FILE_NAME на момент запуска: ▪ 2 –4 ГБ. ▪ 4+ ГБ. o Запуск двух и более копий приложения с: ▪ Одинаковыми параметрами SOURCE_DIR, DESTINATION_DIR, LOG_FILE_NAME. ▪ Одинаковыми SOURCE_DIR и LOG_FILE_NAME, но разными DESTINATION_DIR. ▪ Одинаковыми DESTINATION_DIR и LOG_FILE_NAME, но раз- ными SOURCE_DIR. • Обработка файлов: o Файл верного формата, в котором текст представлен в двух и более поддерживаемых кодировках одновременно. o Размер входного файла: ▪ 2 –4 ГБ. ▪ 4+ ГБ. Задание 2.4.b: возможно, вам захотелось что-то изменить в приведённых выше чек-листах — это совершенно нормально и справедливо: нет и не может быть некоего «единственно верного идеального чек-листа», и ваши идеи вполне имеют право на существование, потому составьте свой соб- ственный чек-лист или отметьте недостатки, которые вы заметили в при- ведённом выше чек-листе. Как мы увидим в следующей главе, создание качественного тест-кейса может потребовать длительной кропотливой и достаточно монотонной работы, которая при этом не требует от опытного тестировщика сильных интеллектуальных усилий, а потому переключение между работой над чек-листами (творческая составляю- щая) и расписыванием их в тест-кейсы (механическая составляющая) позволяет разнообразить рабочий процесс и снизить утомляемость. Хотя, конечно, написание сложных и притом качественных тест-кейсов может оказаться ничуть не менее творческой работой, чем продумывание чек-листов. Тест-кейс и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 117/298 2.4.2. Тест-кейс и его жизненный цикл Терминология и общие сведения Для начала определимся с терминологией, поскольку здесь есть много пута- ницы, вызванной разными переводами англоязычных терминов на русский язык и разными традициями в тех или иных странах, фирмах и отдельных командах. Во главе всего лежит термин «тест». Официальное определение звучит так. Тест (test 285 ) — набор из одного или нескольких тест-кейсов. Поскольку среди всех прочих терминов этот легче и быстрее всего произно- сить, в зависимости от контекста под ним могут понимать и отдельный пункт чек- листа, и отдельный шаг в тест-кейсе, и сам тест-кейс, и набор тест-кейсов и… про- должать можно долго. Главное здесь одно: если вы слышите или видите слово «тест», воспринимайте его в контексте. Теперь рассмотрим самый главный для нас термин — «тест-кейс». Тест-кейс (test case 286 ) — набор входных данных, условий выполнения и ожидаемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Под тест-кейсом также может пониматься соответствующий документ, представляющий формальную запись тест-кейса. Мы ещё вернёмся к этой мысли {149} , но уже сейчас критически важно понять и запомнить: если у тест-кейса не указаны входные данные, условия выполнения и ожидаемые результаты, и/или не ясна цель тест-кейса — это плохой тест-кейс (ино- гда он не имеет смысла, иногда его и вовсе невозможно выполнить). Примечание: иногда термин «test case» на русский язык переводят как «те- стовый случай». Это вполне адекватный перевод, но из-за того, что «тест-кейс» ко- роче произносить, наибольшее распространение получил именно этот вариант. Остальные термины, связанные с тестами, тест-кейсами и тестовыми сце- нариями, на данном этапе можно прочитать просто в ознакомительных це- лях. Если вы откроете ISTQB-глоссарий на букву «T», вы увидите огром- ное количество терминов, тесно связанных друг с другом перекрёстными ссылками: на начальном этапе изучения тестирования нет необходимости глубоко рассматривать их все, однако некоторые всё же заслуживают вни- мания. Они представлены ниже. Высокоуровневый тест-кейс (high level test case 287 ) — тест-кейс без кон- кретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в ин- теграционном тестировании {74} и системном тестировании {75} , а также на уровне ды- мового тестирования {76} . Может служить отправной точкой для проведения исследо- вательского тестирования {82} или для создания низкоуровневых тест-кейсов. 285 Test. A set of one or more test cases. [ISTQB Glossary] 286 Test case. A set of input values, execution preconditions, expected results and execution postconditions, developed for a particular objective or test condition, such as to exercise a particular program path or to verify compliance with a specific requirement. [ISTQB Glossary] 287 High level test case (logical test case). A test case without concrete (implementation level) values for input data and expected results. Logical operators are used; instances of the actual values are not yet defined and/or available. [ISTQB Glossary] Тест-кейс и его жизненный цикл Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 118/298 Низкоуровневый тест-кейс (low level test case 288 ) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса. Спецификация тест-кейса (test case specification 289 ) — документ, описываю- щий набор тест-кейсов (включая их цели, входные данные, условия и шаги выпол- нения, ожидаемые результаты) для тестируемого элемента (test item 290 , test ob- ject 291 ). |