Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Прослеживаемость. Из содержащейся в качественном тест-кейсе информа- ции должно быть понятно, какую часть приложения, какие функции и какие требо- вания он проверяет. Частично это свойство достигается через заполнение соответ- ствующих полей тест-кейса {121} («Ссылка на требование», «Модуль», «Подмодуль»), но и сама логика тест-кейса играет не последнюю роль, т.к. в случае серьёзных нарушений этого свойства можно долго с удивлением смотреть, например, на какое требование ссылается тест-кейс, и пытаться понять, как же они друг с другом свя- заны. Пример непрослеживаемого тест-кейса: Тре- бо- ва- ние Модуль Подмо- дуль Шаги Ожидаемые результаты ПТ-4 Прило- жение Совмещение кодировок Приготовления: файл с не- сколькими допустимыми и недопустимыми кодиров- ками. 1. Передать файл на конвер- тацию. 1. Допустимые кодировки конвер- тируются верно, недопустимые остаются без изменений. Да, этот тест-кейс плох сам по себе (в качественном тест-кейсе сложно полу- чить ситуацию непрослеживаемости), но в нём есть и особые недостатки, затруд- няющие прослеживаемость: • Ссылка на несуществующее требование (убедитесь сами, требования ПТ-4 нет {57} ). • В поле «Модуль» указано значение «Приложение» (по большому счёту можно было оставлять это поле пустым — это было бы столь же информа- тивно), поле «Подмодуль» не заполнено. • По заглавию и шагам можно предположить, что этот тест-кейс ближе всего к ДС-5.1 и ДС-5.3 , но сформулированный ожидаемый результат не следует явно из этих требований. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 141/298 Пример прослеживаемого тест-кейса: Требование Модуль Подмодуль Шаги Ожидаемые результаты ДС-2.4 , ДС-3.2 Стартер Обработчик ошибок Запуск с некоррект- ными параметрами, несуществующие пути 1. Запустить приложе- ние со всеми тремя параметрами, зна- чения которых ука- зывают на несуще- ствующие в файло- вой системе пути. 1. В консоли отображаются нижеуказанные сообще- ния, приложение завер- шает работу. Сообщения a. SOURCE_DIR [ путь]: directory not exists or inaccessible. b. DESTINATION_DIR [ путь]: directory not exists or inaccessible. c. LOG_FILE_NAME [ имя]: wrong file name or inaccessible path. Можно подумать, что этот тест-кейс затрагивает ДС-2 и ДС-3 целиком, но в поле «Требование» есть вполне чёткая конкретизация, к тому же указанные мо- дуль, подмодуль и сама логика тест-кейса устраняют оставшиеся сомнения. Некоторые авторы также подчёркивают, что прослеживаемость тест-кейса связана с его неизбыточностью {139} по отношению к другим тест-кейсам (намного проще дать ссылку на один уникальный тест-кейс, чем выбирать из нескольких очень похожих). Возможность повторного использования. Это свойство редко выполня- ется для низкоуровневых тест-кейсов {118} , но при создании высокоуровневых тест- кейсов {117} можно добиться таких формулировок, при которых: • тест-кейс будет пригодным к использованию с различными настройками те- стируемого приложения и в различных тестовых окружениях; • тест-кейс практически без изменений можно будет использовать для тести- рования аналогичной функциональности в других проектах или других обла- стях приложения. Примером тест-кейса, который тяжело использовать повторно, может яв- ляться практически любой тест-кейс с высокой специфичностью. Не самым идеальным, но очень наглядным примером тест-кейса, который может быть легко использован в разных проектах, может служить следующий тест- кейс: Шаги Ожидаемые результаты Запуск, все параметры некорректны 1. Запустить приложение, указав в качестве всех параметров заведомо некорректные значения. 1. Приложение запускается, после чего выво- дит сообщение с описанием сути проблемы с каждым из параметров и завершает ра- боту. Повторяемость. Тест-кейс должен быть сформулирован таким образом, чтобы при многократном повторении он показывал одинаковые результаты. Это свойство можно разделить на два подпункта: • во-первых, даже общие формулировки, допускающие разные варианты вы- полнения тест-кейса, должны очерчивать соответствующие явные границы (например: «ввести какое-нибудь число» — плохо, «ввести целое число в диапазоне от -273 до +500 включительно» — хорошо); • действия (шаги) тест-кейса по возможности не должны приводить к необра- тимым (или сложно обратимым) последствиям (например: удалению данных, нарушению конфигурации окружения и т.д.) — не стоит включать в тест-кейс Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 142/298 такие «разрушительные действия», если они не продиктованы явным обра- зом целью тест-кейса; если же цель тест-кейса обязывает нас к выполнению таких действий, в самом тест-кейсе должно быть описание действий по вос- становлению исходного состояния приложения (данных, окружения). Соответствие принятым шаблонам оформления и традициям. С шабло- нами оформления, как правило, проблем не возникает: они строго определены име- ющимся образцом или вообще экранной формой инструментального средства управления тест-кейсами. Что же касается традиций, то они отличаются даже в раз- ных командах в рамках одной компании, и тут невозможно дать иного совета, кроме как «почитайте уже готовые тест-кейсы перед тем как писать свои». В данном случае обойдёмся без отдельных примеров, т.к. выше и без того приведено много правильно оформленных тест-кейсов, а что касается нарушений этого свойства, то они прямо или косвенно описаны в главе «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов» {157} Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 143/298 2.4.6. Наборы тест-кейсов Терминология и общие сведения Набор тест-кейсов (test case suite 302 , test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому об- щему признаку. Иногда в такой совокупности результаты завершения од- ного тест-кейса становятся входным состоянием приложения для следую- щего тест-кейса. Внимание! Из-за особенностей перевода очень часто вместо «набор тест- кейсов» говорят «тестовый сценарий». Формально это можно считать ошибкой, но это явление приобрело настолько широкое распространение, что стало вариантом нормы. Как мы только что убедились на примере множества отдельных тест-кейсов, крайне неудобно (более того, это ошибка!) каждый раз писать в каждом тест-кейсе одни и те же приготовления и повторять одни и те же начальные шаги. Намного удобнее объединить несколько тест-кейсов в набор или последова- тельность. И здесь мы приходим к классификации наборов тест-кейсов. В общем случае наборы тест-кейсов можно разделить на свободные (поря- док выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен). Преимущества свободных наборов: • Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы внутри наборов». • Если какой-то тест-кейс завершился ошибкой, это не повлияет на возмож- ность выполнения других тест-кейсов. Преимущества последовательных наборов: • Каждый следующий в наборе тест-кейс в качестве входного состояния при- ложения получает результат работы предыдущего тест-кейса, что позволяет сильно сократить количество шагов в отдельных тест-кейсах. • Длинные последовательности действий куда лучше имитируют работу ре- альных пользователей, чем отдельные «точечные» воздействия на приложе- ние. Пользовательские сценарии (сценарии использования) В данном случае речь НЕ идёт о use cases (вариантах использования), представляющих собой форму требований {36} . Пользовательские сцена- рии как техника тестирования куда менее формализованы, хотя и могут строиться на основе вариантов использования. К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии 303 (или сценарии использования), представляющие со- бой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели. 302 Test case suite (test suite, test set). A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one. [ISTQB Glossary] 303 A scenario is a hypothetical story, used to help a person think through a complex problem or system. [Cem Kaner, «An Introduction to Scenario Testing », http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf ] Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 144/298 Поясним это сначала на примере, не относящемся к «Конвертеру файлов». Допустим, пользователь хочет распечатать табличку на дверь кабинета с текстом «Идёт работа, не стучать!» Для этого ему нужно: 1) Запустить текстовый редактор. 2) Создать новый документ (если редактор не делает это самостоятельно). 3) Набрать в документе текст. 4) Отформатировать текст должным образом. 5) Отправить документ на печать. 6) Сохранить документ (спорно, но допустим). 7) Закрыть текстовый редактор. Вот мы и получили пользовательский сценарий, пункты которого могут стать основой для шагов тест-кейса или целого набора отдельных тест-кейсов. Сценарии могут быть достаточно длинными и сложными, могут содержать внутри себя циклы и условные ветвления, но при всём этом они обладают рядом весьма интересных преимуществ: • Сценарии показывают реальные и понятные примеры использования про- дукта (в отличие от обширных чек-листов, где смысл отдельных пунктов мо- жет теряться). • Сценарии понятны конечным пользователям и хорошо подходят для обсуж- дения и совместного улучшения. • Сценарии и их части легче оценивать с точки зрения важности, чем отдель- ные пункты (особенно низкоуровневых) требований. • Сценарии отлично показывают недоработки в требованиях (если становится непонятно, что делать в том или ином пункте сценария, — с требованиями явно что-то не то). • В предельном случае (нехватка времени и прочие форс-мажоры) сценарии можно даже не прописывать подробно, а просто именовать — и само наиме- нование уже подскажет опытному специалисту, что делать. Последний пункт проиллюстрируем на примере. Классифицируем потенци- альных пользователей нашего приложения (напомним, что в нашем случае «поль- зователь» — это администратор, настраивающий работу приложения) по степени квалификации и склонности к экспериментам, а затем дадим каждому «виду поль- зователя» запоминающееся имя. Таблица 2.4.a — Классификация пользователей Низкая квалификация Высокая квалификация Не склонен к экспериментам «Осторожный» «Консервативный» Склонен к экспериментам «Отчаянный» «Изощрённый» Согласитесь, уже на этой стадии не составляет труда представить себе от- личия в логике работы с приложением, например, «консервативного» и «отчаян- ного» пользователей. Но мы пойдём дальше и озаглавим для них сами сценарии, например, в си- туациях, когда такой пользователь позитивно и негативно относится к идее внедре- ния нашего приложения: Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 145/298 Таблица 2.4.b — Сценарии поведения на основе классификации пользователей «Осторожный» «Консерватив- ный» «Отчаянный» «Изощрённый» Позитивно «А можно вот так?» «Начнём с ин- струкции!» «Гляньте, что я придумал!» «Я всё оптимизи- рую!» Негативно «Я ничего не по- нимаю.» «У вас вот здесь несоответ- ствие…» «Всё равно поло- маю!» «А я говорил!» Проявив даже самую малость воображения, можно представить, что и как будет происходить в каждой из получившихся восьми ситуаций. Причём на созда- ние пары таких таблиц уходит всего несколько минут, а эффект от их использова- ния на порядки превосходит бездумное «кликанье по кнопкам в надежде найти баг». Куда более полное и техничное объяснение того, что такое сценарное те- стирование, как его применять и выполнять должным образом, можно про- честь в статье Сэма Канера «An Introduction to Scenario Testing» 304 Подробная классификация наборов тест-кейсов Представленный здесь материал сложно отнести к категории «для начи- нающих» (и вы можете сразу перейти к пункту «Принципы построения наборов тест-кейсов» {147} ). Но если вам любопытно, взгляните на подроб- ную классификацию, которая представлена ниже. Подробная классификация наборов тест-кейсов может быть выражена сле- дующей таблицей. Таблица 2.4.c — Подробная классификация наборов тест-кейсов По изолированности тест-кейсов друг от друга Изолированные Обобщённые По образованию тест- кейсами строгой по- следовательности Свободные Изолированные свободные Обобщённые свобод- ные Последовательные Изолированные последовательные Обобщённые последовательные • Набор изолированных свободных тест-кейсов (рисунок 2.4.g): действия из раздела «приготовления» нужно повторить перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в любом порядке. • Набор обобщённых свободных тест-кейсов (рисунок 2.4.h): действия из раз- дела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы можно выполнять в любом порядке. • Набор изолированных последовательных тест-кейсов (рисунок 2.4.i): дей- ствия из раздела «приготовления» нужно повторить перед каждым тест-кей- сом, а сами тест-кейсы нужно выполнять в строго определённом порядке. • Набор обобщённых последовательных тест-кейсов (рисунок 2.4.j): действия из раздела «приготовления» нужно выполнить один раз (а потом просто вы- полнять тест-кейсы), а сами тест-кейсы нужно выполнять в строго опреде- лённом порядке. 304 «An Introduction to Scenario Testing», Cem Kaner [ http://www.kaner.com/pdfs/ScenarioIntroVer4.pdf ] Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 146/298 Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов. Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени). Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего. Главное преимущество свободы: возможность выполнять тест-кейсы в лю- бом порядке, а также то, что при провале некоего тест-кейса (приложение не при- шло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять. Рисунок 2.4.g — Набор изолированных свободных тест-кейсов Рисунок 2.4.h — Набор обобщённых свободных тест-кейсов Приготовления Тест 1 Тест 2 Тест 3 Приготовления Приготовления Приготовления Тест 1 Тест 2 Тест 3 Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 147/298 Рисунок 2.4.i — Набор изолированных последовательных тест-кейсов Рисунок 2.4.j — Набор обобщённых последовательных тест-кейсов Принципы построения наборов тест-кейсов Теперь — о самом главном: как формировать наборы тест-кейсов. Правиль- ный ответ звучит очень кратко: логично. И это не шутка. Единственная задача набо- ров — повысить эффективность тестирования за счёт ускорения и упрощения вы- полнения тест-кейсов, увеличения глубины исследования некоей области приложе- ния или функциональности, следования типичным пользовательским сценариям {143} или удобной последовательности выполнения тест-кейсов и т.д. Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то ло- гики, и по этим же принципам в набор включаются тесты, обладающие подходя- щими свойствами. Если же говорить о наиболее типичных подходах к составлению наборов тест-кейсов, то можно обозначить следующее: • На основе чек-листов. Посмотрите внимательно на примеры чек-листов {113} , которые мы разработали в соответствующем разделе {112} : каждый пункт чек- листа может превратиться в несколько тест-кейсов — и вот мы получаем го- товый набор. Приготовления Тест 1 Тест 2 Тест 3 Приготовления Приготовления Приготовления Тест 1 Тест 2 Тест 3 Наборы тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 148/298 • На основе разбиения приложения на модули и подмодули {122} . Для каждого модуля (или его отдельных подмодулей) можно составить свой набор тест- кейсов. • По принципу проверки самых важных, менее важных и всех остальных функ- ций приложения (именно по этому принципу мы составляли примеры чек-ли- стов {113} ). • По принципу группировки тест-кейсов для проверки некоего уровня требова- ний или типа требований {36} , группы требований или отдельного требования. • По принципу частоты обнаружения тест-кейсами дефектов в приложении (например, мы видим, что некоторые тест-кейсы раз за разом завершаются неудачей, значит, мы можем объединить их в набор, условно названный «проблемные места в приложении»). • По архитектурному принципу (см. «многоуровневая архитектура» 149 самосто- ятельно): наборы для проверки пользовательского интерфейса и всего уровня представления, для проверки уровня бизнес-логики, для проверки уровня данных. • По области внутренней работы приложения, например: «тест-кейсы, затра- гивающие работу с базой данных», «тест-кейсы, затрагивающие работу с файловой системой», «тест-кейсы, затрагивающие работу с сетью», и т.д. • По видам тестирования (см. главу «Подробная классификация тестирова- ния» {66} ). Не нужно заучивать этот список. Это всего лишь примеры — грубо говоря, «первое, что приходит в голову». Важен принцип: если вы видите, что выполнение некоторых тест-кейсов в виде набора принесёт вам пользу, создавайте такой набор. Примечание: без хороших инструментальных средств управления тест-кей- сами работать с наборами тест-кейсов крайне тяжело, т.к. приходится самостоя- тельно следить за приготовлениями, «недостающими шагами», изолированностью или обобщённостью, свободностью или последовательностью и т.д. |