Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
примерное количество тест-кейсов на каждый пункт из предположения, что мы будем проводить достаточно глубокое тестирование этого требования: • Все параметры корректные {1 тест-кейс}. • Несуществующий/некорректный путь для: o SOURCE_DIR {3 тест-кейса}; o DESTINATION_DIR {3 тест-кейса}. • Недопустимое имя файла LOG_FILE_NAME {3 тест-кейса}. • Значения SOURCE_DIR и DESTINATION_DIR являются корректными име- нами существующих каталогов, но DESTINATION_DIR находится внутри SOURCE_DIR {3 тест-кейса}. • Недопустимые/несуществующие имена объектов ФС указаны в более чем одном параметре {5 тест-кейсов}. • Значения SOURCE_DIR и DESTINATION_DIR не являются корректными/су- ществующими именами каталогов, и при этом DESTINATION_DIR находится внутри SOURCE_DIR {3 тест-кейса}. У нас получилось примерно 22 тест-кейса. Также давайте для большей пока- зательности примера предположим, что часть тест-кейсов (например, 10) уже была создана ранее. Теперь сведём полученные данные в таблицу 2.6.a, где также отразим коли- чество проходов. Этот показатель появляется из соображения, что некоторые тест- кейсы будут находить дефекты, что потребует повторного выполнения тест-кейса для верификации исправления дефекта; в некоторых случаях дефекты будут от- крыты заново, что потребует повторной верификации. Это относится лишь к части тест-кейсов, потому количество проходов может быть дробным, чтобы оценка была более точной. Количество проходов для тестирования новой функциональности в общем случае можно грубо оценивать так: • Простая функциональность: 1–1.5 (не все тесты повторяются). • Функциональность средней сложности: 2. • Сложная функциональность: 3–5. Таблица 2.6.a — Оценка количества создаваемых и выполняемых тест-кейсов Создание Выполнение Количество 12 22 Повторения (проходы) 1 1.2 Общее количество 12 26.4 Время на один тест-кейс Итоговое время Осталось заполнить ячейки со значениями времени, необходимого на разра- ботку и выполнение одного тест-кейса. К сожалению, не существует никаких маги- ческих способов выяснения этих параметров — только накопленный опыт о вашей собственной производительности, на которую среди прочего влияют следующие факторы (по каждому из них можно вводить коэффициенты, уточняющие оценку): • ваш профессионализм и опыт; • сложность и объёмность тест-кейсов; • производительность тестируемого приложения и тестового окружения; • вид тестирования; • наличие и удобство средств автоматизации; • стадия разработки проекта. Оценка трудозатрат Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 230/298 Тем не менее существует простой способ получения интегральной оценки вашей собственной производительности, при котором влиянием этих факторов можно пренебречь: нужно измерять свою производительность на протяжении дли- тельного периода времени и фиксировать, сколько создать и выполнить тест-кей- сов вы можете в час, день, неделю, месяц и т.д. Чем больший промежуток времени будет рассмотрен, тем меньше на результаты измерений будут влиять кратковре- менные отвлекающие факторы, появление которых сложно предсказывать. Допустим, что для некоторого выдуманного тестировщика эти значения ока- зались следующими — за месяц (28 рабочих дней) ему удаётся: • Создать 300 тест-кейсов (примерно 11 тест-кейсов в день, или 1.4 в час). • Выполнить 1000 тест-кейсов (примерно 36 тест-кейсов в день, или 4.5 в час). Подставим полученные значения в таблицу 2.6.a и получим таблицу 2.6.b. Таблица 2.6.b — Оценка трудозатрат Создание Выполнение Количество 12 22 Повторения (проходы) 1 1.2 Общее количество 12 26.4 Время на один тест-кейс, ч 0.7 0.2 Итоговое время, ч 8.4 5.2 ИТОГО 13.6 часа Если бы оценка производительности нашего выдуманного тестировщика производилась на коротких отрезках времени, полученное значение нельзя было бы использовать напрямую, т.к. в нём не было бы учтено время на написание отчё- тов о дефектах, участие в различных собраниях, переписку и прочие виды деятель- ности. Но мы потому и ориентировались на итоги измерений за месяц, что за 28 типичных рабочих дней все эти факторы многократно проявляли себя, и их влияние уже учтено в оценке производительности. Если бы мы всё же опирались на краткосрочные исследования, можно было бы ввести дополнительный коэффициент или использовать допущение о том, что работе с тест-кейсами за один день удаётся посвятить не 8 часов, а меньше (напри- мер, 6). Итого у нас получилось 13.6 часа, или 1.7 рабочих дня. Помня идею о за- кладке небольшого «буфера», можем считать, что за два полных рабочих дня наш выдуманный тестировщик точно справится с поставленной задачей. В заключение этой главы ещё раз отметим, что для уточнения собственной производительности и улучшения своих навыков оценки трудозатрат стоит форми- ровать оценку, после чего выполнять работу и сравнивать фактический результат с оценкой. И повторять эту последовательность шагов раз за разом. Задание 2.6.c: разработайте на основе итогового чек-листа {156} , представ- ленного в разделе 2.4, тест-кейсы и оцените свою производительность в процессе выполнения этой задачи. Примеры использования различных техник тестирования Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 231/298 2.7. Примеры использования различных техник тестирования 2.7.1. Позитивные и негативные тест-кейсы Ранее мы уже рассматривали {150} алгоритм продумывания идей тест-кейсов, в котором предлагается ответить себе на следующие вопросы относительно тести- руемого объекта: • Что перед вами? • Кому и зачем оно нужно (и насколько это важно)? • Как оно обычно используется? • Как оно может сломаться, т.е. начать работать неверно? Сейчас мы применим этот алгоритм, сконцентрировавшись на двух послед- них вопросах, т.к. именно ответы на них позволяют нам придумать много позитив- ных {79} и негативных {79} тест-кейсов. Продолжим тестировать наш «Конвертер фай- лов {57} », выбрав для исследования первый параметр командной строки — SOURCE_DIR — имя каталога, в котором приложение ищет файлы, подлежащие конвертации. Что перед нами? Путь к каталогу. Казалось бы, просто, но стоит вспомнить, что наше приложение должно работать {58} как минимум под управлением Windows и Linux, что приводит к необходимости освежить в памяти принципы работы фай- ловых систем в этих ОС. А ещё может понадобиться работа с сетью. Кому и зачем оно нужно (и насколько это важно)? Конечные пользователи не занимаются конфигурированием приложения, т.е. этот параметр нужен админи- стратору (предположительно, это человек квалифицированный и не делает явных глупостей, но из его же квалификации вытекает возможность придумать такие ва- рианты использования, до которых не додумается рядовой пользователь). Важ- ность параметра критическая, т.к. при каких-то проблемах с ним есть риск полной потери работоспособности приложения. Как оно обычно используется? Здесь нам понадобится понимание прин- ципов работы файловых систем. • Корректное имя существующего каталога: o Windows: ▪ X:\dir ▪ “X:\dir with spaces” ▪ .\dir ▪ ..\dir ▪ \\host\dir ▪ Всё вышеперечисленное с “\” в конце пути. ▪ X:\ o Linux: ▪ /dir ▪ “/dir with spaces” ▪ host:/dir ▪ smb://host/dir ▪ ./dir ▪ ../dir ▪ Всё вышеперечисленное с “/” в конце пути. ▪ / Позитивные и негативные тест-кейсы Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 232/298 И всё, т.е. в данном конкретном случае существует единственный вариант верного использования первого параметра — указать корректное имя существую- щего каталога (пусть вариантов таких корректных имён и много). Фактически мы получили чек-лист для позитивного тестирования. Все ли варианты допустимых имён мы учли? Может быть, и не все. Но эту проблему мы рассмотрим в следующей главе, посвящённой классам эквивалентности и граничным условиям {234} В настоящий момент важно ещё раз подчеркнуть мысль о том, что сначала мы проверяем работу приложения на позитивных тест-кейсах, т.е. в корректных условиях. Если эти проверки не пройдут, в некоторых совершенно допустимых и типичных ситуациях приложение будет неработоспособным, т.е. ущерб качеству будет весьма ощутимым. Как оно может сломаться, т.е. начать работать неверно? Негативных тест-кейсов (за редчайшим исключением) оказывается намного больше, чем пози- тивных. Итак, какие проблемы с именем каталога-источника (и самим каталогом- источником) могут помешать нашему приложению? • Указанный путь не является корректным именем каталога: o Пустое значение (“”). o Слишком длинное имя: ▪ Для Windows: более 256 байт. (Важно! Путь к каталогу длиной в 256 байт допустим, но надо учесть ограничение на полное имя файла, т.к. его превышение может быть достигнуто естествен- ным образом, что приведёт к возникновению сбоя.) ▪ Для Linux: более 4096 байт. o Недопустимые символы, например: ? < > \ * | " \0. o Недопустимые комбинации допустимых символов, например: “....\dir”. • Каталог не существует: o На локальном диске. o В сети. • Каталог существует, но к нему нет прав доступа. • Доступ к каталогу утерян после запуска приложения: o Каталог удалён или переименован. o Изменены права доступа. o Потеря соединения с удалённым компьютером. • Использование зарезервированного имени: o Для Windows: com1-com9, lpt1-lpt9, con, nul, prn. o Для Linux: “..”. • Проблемы с кодировками, например: имя указано верно, но не в той коди- ровке. Если погружаться в детали поведения отдельных операционных систем и файловых систем, данный список можно значительно расширить. И тем не менее открытыми будут оставаться два вопроса: • Все ли эти варианты надо проверить? • Не упустили ли мы что-то важное? На первый вопрос ответ можно найти, опираясь на рассуждения, описанные в главе «Логика создания эффективных проверок» {149} Ответ на второй вопрос по- могут найти рассуждения, описанные в двух следующих главах, т.к. классы эквива- лентности, граничные условия и доменное тестирование значительно упрощают решение подобных задач. Позитивные и негативные тест-кейсы Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 233/298 Задание 2.7.a: как вы думаете, почему в вышеприведённых чек-листах мы не учли требование о том, что SOURCE_DIR не может содержать внутри себя DESTINATION_DIR? Классы эквивалентности и граничные условия Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 234/298 2.7.2. Классы эквивалентности и граничные условия В данной главе мы рассмотрим примеры упомянутых ранее техник тестиро- вания на основе классов эквивалентности {91} и граничных условий {92} Если уточнить определения, получается: Класс эквивалентности (equivalence class 348 ) — набор данных, обраба- тываемых одинаковым образом и приводящих к одинаковому результату. Граничное условие (border condition, boundary condition 349 ) — значение, находящееся на границе классов эквивалентности. Иногда под классом эквивалентности понимают набор тест-кейсов, пол- ное выполнение которого является избыточным. Это определение не про- тиворечит предыдущему, т.к. показывает ту же ситуацию, но с другой точки зрения. В качестве пояснения идеи рассмотрим тривиальный пример. Допустим, нам нужно протестировать функцию, которая определяет, корректное или некорректное имя ввёл пользователь при регистрации. Требования к имени пользователя таковы: • От трёх до двадцати символов включительно. • Допускаются цифры, знак подчёркивания, буквы английского алфавита в верхнем и нижнем регистрах. Если попытаться решить задачу «в лоб», нам для позитивного тестирования придётся перебрать все комбинации допустимых символов длиной [3, 20] (это 18- разрядное 63-ричное число, т.е. 2.4441614509104E+32). А негативных тест-кейсов здесь и вовсе будет бесконечное количество, ведь мы можем проверить строку дли- ной в 21 символ, 100, 10000, миллион, миллиард и т.д. Представим графически классы эквивалентности относительно требований к длине (см. рисунок 2.7.a). Рисунок 2.7.a — Классы эквивалентности для значений длины имени пользова- теля Поскольку для длины строки невозможны дробные и отрицательные значе- ния, мы видим три недостижимых области, которые можно исключить, и получаем окончательный вариант (см. рисунок 2.7.b). Мы получили три класса эквивалентности: • [0, 2] — недопустимая длина; • [3, 20] — допустимая длина; • [21, ∞] — недопустимая длина. 348 An equivalence class consists of a set of data that is treated the same by a module or that should produce the same result. [Lee Copeland, «A practitioner’s guide to software test design»] 349 The boundaries — the «edges» of each equivalence class. [Lee Copeland, «A practitioner’s guide to software test design»] 0 2 3 20 21 Допустимо Недопустимо Недопустимо Недостижимо Классы эквивалентности и граничные условия Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 235/298 Рисунок 2.7.b — Итоговое разбиение на классы эквивалентности значений длины имени пользователя Обратите внимание, что области значений [0, 2] и [21, ∞] относятся к разным классам эквивалентности, т.к. принадлежность длины строки к этим диапазонам проверяется отдельными условиями на уровне кода программы. Граничные условия уже отмечены на рисунке 2.7.b — это 2, 3, 20 и 21. Зна- чение 0 тоже стоит включить в этот набор на всякий случай, т.к. в программирова- нии ноль, NULL, нулевой байт и т.п. исторически являются «опасными значениями». В итоге мы получаем следующий набор входных данных для тест-кейсов (сами символы для составления строк можно выбирать из набора допустимых сим- волов случайным образом, но желательно учесть все типы символов, т.е. буквы в обоих регистрах, цифры, знак подчёркивания). Таблица 2.7.a — Значения входных данных для тест-кейсов (реакция на длину имени пользователя) Позитивные тест-кейсы Негативные тест-кейсы Значе- ние AAA 123_zzzzzzzzzzzzzzzz AA Пустая строка 1234_zzzzzzzzzzzzzzzz Поясне- ние Строка ми- нимальной допустимой длины Строка максимальной допустимой длины Строка не- допустимой длины по нижней границе Строка не- допустимой длины, учтена для надёжно- сти Строка недопустимой длины по верхней гра- нице Осталось решить вопрос с недопустимыми символами. К сожалению, столь же наглядно, как с длиной, здесь не получится. Даже если подойти строго научно, т.е. выбрать кодировку и по её кодовой таблице определить диапазоны кодов сим- волов (на рисунке 2.7.c приведён пример такого разделения для ASCII-таблицы), у нас нет никакой гарантии, что символы с кодами из каждого диапазона трактуются единообразно. Здесь мы видим ярчайший пример случая, в котором тестирование по ме- тоду белого ящика сильно облегчило бы нам жизнь. Если бы мы видели, как в коде приложения реализована проверка на допустимые и недопусти- мые символы, мы могли бы подобрать очень показательные значения входных данных. Рисунок 2.7.c — Неудачный способ поиска классов эквивалентности для наборов допустимых и недопустимых символов (коды символов приведены по ASCII- таблице) 0 2 3 20 21 Допустимо Недопустимо Недопустимо Цифры 48 0 47 57 58 65 90 64 91 96 97 122 94 95 123 255 Буквы A-Z Буквы a-z _ Классы эквивалентности и граничные условия Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 236/298 Раз оказалось, что по кодам символов подбирать классы эквивалентности в нашем случае нерационально, посмотрим на ситуацию по-другому (и намного проще). Поделим символы на недопустимые и допустимые, а последние, в свою очередь, — на группы (см. рисунок 2.7.d). Рисунок 2.7.d — Классы эквивалентных допустимых и недопустимых символов Интересующие нас комбинации допустимых символов (с представителями всех групп) мы уже учли при проверке реакции приложения на имена пользователя допустимых и недопустимых длин, потому остаётся учесть только вариант с допу- стимой длиной строки, но недопустимыми символами (которые можно выбирать случайным образом из соответствующего набора). В таблицу 2.7.a добавим одну колонку и получим таблицу 2.7.b. Таблица 2.7.b — Значения всех входных данных для тест-кейсов Позитивные тест-кейсы Негативные тест-кейсы Зна- чение AAA 123_zzzzzzzzzzzzzzzz AA Пустая строка 1234_zzzzzzzzzzzzzzzz #$% Пояс- нение Строка мини- мальной допусти- мой длины Строка максимальной допустимой длины Строка недопу- стимой длины по ниж- ней гра- нице Строка недопу- стимой длины, учтена для надёж- ности Строка недопустимой длины по верхней гра- нице Строка допусти- мой длины, недопу- стимые символы Конечно, в случае критически важных приложений (например, системы управления ядерным реактором) мы бы проверили с помощью средств ав- томатизации реакцию приложения на каждый недопустимый символ. Но предположив, что перед нами некое тривиальное приложение, мы можем считать, что одной проверки на недопустимые символы будет достаточно. Теперь мы возвращаемся к «Конвертеру файлов» {57} и ищем ответ на во- прос {232} о том, не упустили ли мы какие-то важные проверки в главе «Позитивные и негативные тест-кейсы» {231} Начнём с того, что выделим группы свойств SOURCE_DIR, от которых зави- сит работа приложения (такие группы называются «измерениями»): • Существование каталога (изначальное и во время работы приложения). • Длина имени. • Наборы символов в имени. • Комбинации символов в имени. • Расположение каталога (локальный или сетевой). • Права доступа к каталогу (изначальные и во время работы приложения). • Зарезервированные имена. Цифры Буквы A-Z Буквы a-z Знак _ Все остальные символы Допустимо Недопустимо |