Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Шаги Ожидаемые результаты Конвертация из всех поддерживаемых коди- ровок Приготовления: • Создать в корне любого диска четыре от- дельные папки для входных файлов, выход- ных файлов, файла журнала и временного хранения тестовых файлов. • Распаковать содержимое прилагаемого ар- хива в папку для временного хранения те- стовых файлов. 1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произволь- ное). 2. Скопировать файлы из папки для времен- ного хранения в папку для входных файлов. 3. Остановить приложение. 1. Приложение запускается и выводит сообще- ние о своём запуске в консоль и файл жур- нала. 2. Файлы из папки для входных файлов пере- мещаются в папку для выходных файлов, в консоли и файле журнала отображаются со- общения о конвертации каждого из файлов с указанием его исходной кодировки. 3. Приложение выводит сообщение о завер- шении работы в файл журнала и завершает работу. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 135/298 В этом тест-кейсе есть всё необходимое для понимания и выполнения, но при этом он стал короче и проще для выполнения, а отсутствие строго указанных значений приводит к тому, что при многократном выполнении тест-кейса (особенно — разными тестировщиками) конкретные параметры будут менять свои значения, что увеличивает вероятность обнаружения ошибки. Ещё раз главная мысль: сами по себе специфичность или общность тест- кейса не являются чем-то плохим, но резкий перекос в ту или иную сторону снижает качество тест-кейса. Баланс между простотой и сложностью. Здесь не существует академиче- ских определений, но принято считать, что простой тест-кейс оперирует одним объ- ектом (или в нём явно виден главный объект), а также содержит небольшое коли- чество тривиальных действий; сложный тест-кейс оперирует несколькими равно- правными объектами и содержит много нетривиальных действий. Преимущества простых тест-кейсов: • их можно быстро прочесть, легко понять и выполнить; • они понятны начинающим тестировщикам и новым людям на проекте; • они делают наличие ошибки очевидным (как правило, в них предполагается выполнение повседневных тривиальных действий, проблемы с которыми видны невооружённым взглядом и не вызывают дискуссий); • они упрощают начальную диагностику ошибки, т.к. сужают круг поиска. Преимущества сложных тест-кейсов: • при взаимодействии многих объектов повышается вероятность возникнове- ния ошибки; • пользователи, как правило, используют сложные сценарии, а потому слож- ные тесты более полноценно эмулируют работу пользователей; • программисты редко проверяют такие сложные случаи (и они совершенно не обязаны это делать). Рассмотрим примеры. Слишком простой тест-кейс: Шаги Ожидаемые результаты Запуск приложения 1. Запустить приложение. 1. Приложение запускается. Слишком сложный тест-кейс: Шаги Ожидаемые результаты Повторная конвертация Приготовления: • Создать в корне любого диска три отдель- ные папки для входных файлов, выходных файлов, файла журнала. • Подготовить набор из нескольких файлов максимального поддерживаемого размера поддерживаемых форматов с поддерживае- мыми кодировками, а также нескольких фай- лов допустимого размера, но недопустимого формата. 1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произволь- ное). 2. Файлы постепенно перемещаются из вход- ной в выходную папку, в консоли и файле журнала появляются сообщения об успеш- ной конвертации файлов. 3. Файлы постепенно перемещаются из вход- ной в выходную папку, в консоли и файле журнала появляются сообщения об успеш- ной конвертации файлов. 5. Файлы постепенно перемещаются из вход- ной в выходную папку, в консоли и файле журнала появляются сообщения об успеш- ной конвертации файлов допустимого фор- мата и сообщения об игнорировании фай- лов недопустимого формата. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 136/298 2. Скопировать в папку для входных файлов несколько файлов допустимого формата. 3. Переместить сконвертированные файлы из папки с результирующими файлами в папку для входных файлов. 4. Переместить сконвертированные файлы из папки с результирующими файлами в папку с набором файлов для теста. 5. Переместить все файлы из папки с набором файлов для теста в папку для входных фай- лов. 6. Переместить сконвертированные файлы из папки с результирующими файлами в папку для входных файлов. 6. Файлы постепенно перемещаются из вход- ной в выходную папку, в консоли и файле журнала появляются сообщения об успеш- ной конвертации файлов допустимого фор- мата и сообщения об игнорировании фай- лов недопустимого формата. Этот тест-кейс одновременно является слишком сложным по избыточности действий и по спецификации лишних данных и операций. Задание 2.4.d: перепишите этот тест-кейс, устранив его недостатки, но сохранив общую цель (проверку повторной конвертации уже ранее скон- вертированных файлов). Примером хорошего простого тест-кейса может служить тест-кейс 3 {134} из пункта про специфичность и общность. Пример хорошего сложного тест-кейса может выглядеть так: Шаги Ожидаемые результаты Много копий приложения, конфликт фай- ловых операций Приготовления: • Создать в корне любого диска три от- дельные папки для входных файлов, вы- ходных файлов, файла журнала. • Подготовить набор из нескольких фай- лов максимального поддерживаемого размера поддерживаемых форматов с поддерживаемыми кодировками. 1. Запустить первую копию приложения, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произвольное). 2. Запустить вторую копию приложения с теми же параметрами (см. шаг 1). 3. Запустить третью копию приложения с теми же параметрами (см. шаг 1). 4. Изменить приоритет процессов второй (“high”) и третьей (“low”) копий. 5. Скопировать подготовленный набор ис- ходных файлов в папку для входных фай- лов. 3. Все три копии приложения запускаются, в файле журнала появляются последовательно три записи о запуске приложения. 5. Файлы постепенно перемещаются из входной в выходную папку, в консоли и файле журнала появляются сообщения об успешной конверта- ции файлов, а также (возможно) сообщения вида: a. “source file inaccessible, retrying”. b. “destination file inaccessible, retrying”. c. “log file inaccessible, retrying”. Ключевым показателем корректной работы яв- ляется успешная конвертация всех файлов, а также появление в консоли и файле журнала сообщений об успешной конвертации каждого файла (от одной до трёх записей на каждый файл). Сообщения (предупреждения) о недоступности входного файла, выходного файла или файла журнала также являются показателем коррект- ной работы приложения, однако их количество зависит от многих внешних факторов и не мо- жет быть спрогнозировано заранее. Иногда более сложные тест-кейсы являются также и более специфичными, но это лишь общая тенденция, а не закон. Также нельзя по сложности тест-кейса однозначно судить о его приоритете (в нашем примере хорошего сложного тест- кейса он явно будет иметь очень низкий приоритет, т.к. проверяемая им ситуация является искусственной и крайне маловероятной, но бывают и сложные тесты с самым высоким приоритетом). Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 137/298 Как и в случае специфичности и общности, сами по себе простота или слож- ность тест-кейсов не являются чем-то плохим (более того — рекомендуется начи- нать разработку и выполнение тест-кейсов с простых, а затем переходить ко всё более и более сложным), однако излишняя простота и излишняя сложность также снижают качество тест-кейса. «Показательность» (высокая вероятность обнаружения ошибки). Начи- ная с уровня тестирования критического пути {76} , можно утверждать, что тест-кейс является тем более хорошим, чем он более показателен (с большей вероятностью обнаруживает ошибку). Именно поэтому мы считаем непригодными слишком про- стые тест-кейсы — они непоказательны. Пример непоказательного (плохого) тест-кейса: Шаги Ожидаемые результаты Запуск и остановка приложения 1. Запустить приложение с корректными пара- метрами. 2. Завершить работу приложения. 1. Приложение запускается. 2. Приложение завершает работу. Пример показательного (хорошего) тест-кейса: Шаги Ожидаемые результаты Запуск с некорректными параметрами, несу- ществующие пути 1. Запустить приложение со всеми тремя пара- метрами (SOURCE_DIR, DESTINA- TION_DIR, LOG_FILE_NAME) , значения ко- торых указывают на несуществующие в файловой системе пути (например: z:\src\, z:\dst\, z:\log.txt при условии, что в системе нет логического диска z). 1. В консоли отображаются нижеуказанные со- общения, приложение завершает работу. Сообщения: a. Сообщение об использовании. b. SOURCE_DIR [z:\src\]: directory not exists or inaccessible. c. DESTINATION_DIR [z:\dst\]: directory not exists or inaccessible. d. LOG_FILE_NAME [z:\log.txt]: wrong file name or inaccessible path. Обратите внимание, что показательный тест-кейс по-прежнему остался до- статочно простым, но он проверяет ситуацию, возникновение ошибки в которой несравненно более вероятно, чем в ситуации, описываемой плохим непоказатель- ным тест-кейсом. Также можно сказать, что показательные тест-кейсы часто выполняют какие- то «интересные действия», т.е. такие действия, которые едва ли будут выполнены просто в процессе работы с приложением (например: «сохранить файл» — это обычное тривиальное действие, которое явно будет выполнено не одну сотню раз даже самими разработчиками, а вот «сохранить файл на носитель, защищённый от записи», «сохранить файл на носитель с недостаточным объёмом свободного про- странства», «сохранить файл в папку, к которой нет доступа» — это уже гораздо более интересные и нетривиальные действия). Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 138/298 Последовательность в достижении цели. Суть этого свойства выражается в том, что все действия в тест-кейсе направлены на следование единой логике и достижение единой цели и не содержат никаких отклонений. Примерами правильной реализации этого свойства могут служить представ- ленные в этом разделе в избытке примеры хороших тест-кейсов. А нарушение мо- жет выглядеть так: Шаги Ожидаемые результаты Конвертация из всех поддерживаемых коди- ровок Приготовления: • Создать в корне любого диска четыре от- дельные папки для входных файлов, выход- ных файлов, файла журнала и временного хранения тестовых файлов. • Распаковать содержимое прилагаемого ар- хива в папку для временного хранения те- стовых файлов. 1. Запустить приложение, указав в параметрах соответствующие пути из приготовления к тесту (имя файла журнала — произволь- ное). 2. Скопировать файлы из папки для времен- ного хранения в папку для входных файлов. 3. Остановить приложение. 4. Удалить файл журнала. 5. Повторно запустить приложение с теми же параметрами. 6. Остановить приложение. 1. Приложение запускается и выводит сообще- ние о своём запуске в консоль и файл жур- нала. 2. Файлы из папки для входных файлов пере- мещаются в папку для выходных файлов, в консоли и файле журнала отображаются со- общения о конвертации каждого из файлов с указанием его исходной кодировки. 3. Приложение выводит сообщение о завер- шении работы в файл журнала и завершает работу. 5. Приложение запускается и выводит сообще- ние о своём запуске в консоль и заново со- зданный файл журнала. 6. Приложение выводит сообщение о завер- шении работы в файл журнала и завершает работу. Шаги 3–5 никак не соответствуют цели тест-кейса, состоящей в проверке кор- ректности конвертации входных данных, представленных во всех поддерживаемых кодировках. Отсутствие лишних действий. Чаще всего это свойство подразумевает, что не нужно в шагах тест-кейса долго и по пунктам расписывать то, что можно заме- нить одной фразой: Плохо Хорошо 1. Указать в качестве первого параметра при- ложения путь к папке с исходными файлами. 2. Указать в качестве второго параметра при- ложения путь к папке с конечными файлами. 3. Указать в качестве третьего параметра при- ложения путь к файлу журнала. 4. Запустить приложение. 1. Запустить приложение со всеми тремя кор- ректными параметрами (например, c:\src\, c:\dst\, c:\log.txt при условии, что соответствую- щие папки существуют и доступны приложе- нию). Вторая по частоте ошибка — начало каждого тест-кейса с запуска приложе- ния и подробного описания по приведению его в то или иное состояние. В наших примерах мы рассматриваем каждый тест-кейс как существующий в единственном виде в изолированной среде, и потому вынуждены осознанно допускать эту ошибку (иначе тест-кейс будет неполным), но в реальной жизни на запуск приложения бу- дут свои тесты, а длинный путь из многих действий можно описать как одно дей- ствие, из контекста которого понятно, как это действие выполнить. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 139/298 Следующий пример тест-кейса не относится к нашему «Конвертеру файлов», но очень хорошо иллюстрирует эту мысль: Плохо Хорошо 1. Запустить приложение. 2. Выбрать в меню пункт «Файл». 3. Выбрать подпункт «Открыть». 4. Перейти в папку, в которой находится хотя бы один файл формата DOCX с тремя и более страницами. 1. Открыть DOCX-файл с тремя и более страни- цами. И сюда же можно отнести ошибку с повторением одних и тех же приготовле- ний во множестве тест-кейсов (да, по описанным выше причинам в примерах мы снова вынужденно делаем так, как в жизни делать не надо). Куда удобнее объеди- нить тесты в набор {143} и указать приготовления один раз, подчеркнув, нужно или нет их выполнять перед каждым тест-кейсом в наборе. Проблема с подготовительными (и финальными) действиями идеально решена в автоматизированном модульном тестировании 301 с использова- нием фреймворков наподобие JUnit или TestNG — там существует специ- альный «механизм фиксаций» (fixture), автоматически выполняющий ука- занные действия перед каждым отдельным тестовым методом (или их со- вокупности) или после него. Неизбыточность по отношению к другим тест-кейсам. В процессе созда- ния множества тест-кейсов очень легко оказаться в ситуации, когда два и более тест-кейса фактически выполняют одни и те же проверки, преследуют одни и те же цели, направлены на поиск одних и тех же проблем. Способ минимизации количе- ства таких тест-кейсов подробно описан в главе «Виды и направления тестирова- ния {64} » (см. такие техники тестирования, как использование классов эквивалентно- сти {91} и граничных условий {92} ). Если вы обнаруживаете несколько тест-кейсов, дублирующих задачи друг друга, лучше всего или удалить все, кроме одного, самого показательного, или пе- ред удалением остальных на их основе доработать этот выбранный самый показа- тельный тест-кейс. Демонстративность (способность демонстрировать обнаруженную ошибку очевидным образом). Ожидаемые результаты должны быть подобраны и сформулированы таким образом, чтобы любое отклонение от них сразу же бро- салось в глаза и становилось очевидным, что произошла ошибка. Сравните вы- держки из двух тест-кейсов. Выдержка из недемонстративного тест-кейса: Шаги Ожидаемые результаты 5. Разместить в файле текст «Пример длин- ного текста, содержащего символы русского и английского алфавита вперемешку.» в ко- дировке KOI8-R (в слове «Пример» буквы «р» — английские). 6. Сохранить файл под именем «test. txt» и от- править файл на конвертацию. 7. Переименовать файл в «test.txt». 6. Приложение игнорирует файл. 7. Текст принимает корректный вид в коди- ровке UTF-8 с учётом английских букв. 301 Unit testing (component testing). The testing of individual software components. [ISTQB Glossary] Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 140/298 Выдержка из демонстративного тест-кейса: Шаги Ожидаемые результаты 5. Разместить в файле текст «Ё╥╔═┼╥ ╘┼╦╙╘┴.» (Эти символы представляют со- бой словосочетание «Пример текста.» в коди- ровке KOI8-R, прочитанной как CP866). 6. Отправить файл на конвертацию. 6. Текст принимает вид: «Пример текста.» (кодировка UTF8). В первом случае тест-кейс плох не только расплывчатостью формулировки «корректный вид в кодировке UTF-8 с учётом английских букв», там также очень легко допустить ошибки при выполнении: • забыть сконвертировать вручную входной текст в KOI8-R; • не заметить, что в первый раз расширение начинается с пробела; • забыть заменить в слове «Пример» буквы «р» на английские; • из-за расплывчатости формулировки ожидаемого результата принять оши- бочное, но выглядящее правдоподобно поведение за верное. Второй тест-кейс чётко ориентирован на свою цель по проверке конвертации (не содержит странной проверки с игнорированием файла с неверным расшире- нием) и описан так, что его выполнение не представляет никаких сложностей, а лю- бое отклонение фактического результата от ожидаемого будет сразу же заметно. |