Тестирование приложений. Обеспечения Базовый курс (3е издание) Версия книги 15 от 31. 03. 2022
 Скачать 5.07 Mb.
|
|
Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы: • начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т.п.); • даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает ве- роятность в будущем случайно «приклеить» описание этого шага к новому тексту); • если вы пишете на русском языке, используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «до- бавьте»), в английском языке не надо использовать частицу «to» (т.е. «запу- стить приложение» будет «start application», не «to start application»); • соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем {76} и т.д. — в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до пре- дельно чётко прописанных значений и указаний; • ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»); • пишите шаги последовательно, без условных конструкций вида «если… то…». Внимание! Частая ошибка! Категорически запрещено ссылаться на шаги из других тест-кейсов и другие тест-кейсы целиком: если те, другие тест- кейсы будут изменены или удалены, ваш тест-кейс начнёт ссылаться на неверные данные или в пустоту, а если в процессе выполнения те, другие тест-кейсы или шаги приведут к возникновению ошибки, вы не сможете закончить выполнение вашего тест-кейса. Ожидаемые результаты (expected results) по каждому шагу тест-кейса опи- сывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата. По написанию ожидаемых результатов можно порекомендовать следующее: • описывайте поведение системы так, чтобы исключить субъективное толкова- ние (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо); • пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совер- шенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие); • пишите кратко, но не в ущерб информативности; • избегайте условных конструкций вида «если… то…». Внимание! Частая ошибка! В ожидаемых результатах ВСЕГДА описыва- ется КОРРЕКТНАЯ работа приложения. Нет и не может быть ожидаемого результата в виде «приложение вызывает ошибку в операционной си- стеме и аварийно завершается с потерей всех пользовательских данных». При этом корректная работа приложения вполне может предполагать отображение сообщений о неверных действиях пользователя или неких критических ситуациях. Так, сообщение «Невозможно сохранить файл по указанному пути: на целевом носителе недостаточно свободного места» Атрибуты (поля) тест-кейса Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 126/298 — это не ошибка приложения, это его совершенно нормальная и правиль- ная работа. Ошибкой приложения (в этой же ситуации) было бы отсут- ствие такого сообщения, и/или повреждение, или потеря записываемых данных. Для более глубокого понимания принципов оформления тест-кейсов реко- мендуется прямо сейчас ознакомиться с главой «Типичные ошибки при разработке чек-листов, тест-кейсов и наборов тест-кейсов» {157} Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 127/298 2.4.4. Инструментальные средства управления тестированием Инструментальных средств управления тестированием (test management tool 297 ) очень много, к тому же многие компании разрабатывают свои внутренние средства решения этой задачи. Не имеет смысла заучивать, как работать с тест-кейсами в том или ином ин- струментальном средстве — принцип везде един, и соответствующие навыки нара- батываются буквально за пару дней. Что на текущий момент важно понимать, так это общий набор функций, реализуемых такими инструментальными средствами (конечно, то или иное средство может не реализовывать какую-то функцию из этого списка и/или реализовывать не вошедшие в список функции): • создание тест-кейсов и наборов тест-кейсов; • контроль версий документов с возможностью определить, кто внёс те или иные изменения, и отменить эти изменения, если требуется; • формирование и отслеживание реализации плана тестирования, сбор и ви- зуализация разнообразных метрик, генерирование отчётов; • интеграция с системами управления дефектами, фиксация взаимосвязи между выполнением тест-кейсов и созданными отчётами о дефектах; • интеграция с системами управления проектами; • интеграция с инструментами автоматизированного тестирования, управле- ние выполнением автоматизированных тест-кейсов. Иными словами, хорошее инструментальное средство управления тестиро- ванием берёт на себя все рутинные технические операции, которые объективно необходимо выполнять в процессе реализации жизненного цикла тестирования {27} Огромным преимуществом также является способность таких инструментальных средств отслеживать взаимосвязи между различными документами и иными арте- фактами, взаимосвязи между артефактами и процессами и т.д., подчиняя эти дей- ствия системе разграничения прав доступа и гарантируя сохранность и коррект- ность информации. Для общего развития и лучшего закрепления темы об оформлении тест-кей- сов {121} мы сейчас рассмотрим несколько картинок с формами из разных инструмен- тальных средств. Здесь вполне сознательно не приведено никакого сравнения или подробного описания — подобных обзоров достаточно в Интернете, и они стремительно уста- ревают по мере выхода новых версий обозреваемых продуктов. Но интерес представляют отдельные особенности интерфейса, на которые мы обратим внимание в каждом из примеров (важно: если вас интересует подроб- ное описание каждого поля, связанных с ним процессов и т.д., обратитесь к офици- альной документации — здесь будут лишь самые краткие пояснения). 297 Test management tool. A tool that provides support to the test management and control part of a test process. It often has several capabilities, such as testware management, scheduling of tests, the logging of results, progress tracking, incident management and test reporting. [ISTQB Glossary] Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 128/298 QAComplete 298 Рисунок 2.4.c — Создание тест-кейса в QAComplete 1. Id (идентификатор), как видно из соответствующей надписи, автогенерируе- мый. 2. Title (заглавие), как и в большинстве систем, является обязательным для за- полнения. 3. Priority (приоритет) по умолчанию предлагает на выбор значения high (высо- кий), medium (средний), low (низкий). 4. Folder name (расположение) является аналогом полей «Модуль» и «Подмо- дуль» и позволяет выбрать из выпадающего древовидного списка соответ- ствующее значение, описывающее, к чему относится тест-кейс. 5. Status (статус) показывает текущее состояние тест-кейса: new (новый), ap- proved (утверждён), awaiting approval (на рассмотрении), in design (в разра- ботке), outdated (устарел), rejected (отклонён). 6. Assigned to (исполнитель) указывает, кто в данный момент является «основ- ной рабочей силой» по данному тест-кейсу (или кто должен принять решение о, например, утверждении тест-кейса). 7. Last Run Status (результат последнего запуска) показывает, прошёл ли тест успешно (passed) или завершился неудачей (failed). 8. Last Run Configuration ( конфигурация, использованная для последнего за- пуска) показывает, на какой аппаратно-программной платформе тест-кейс 298 QAComplete [ http://smartbear.com/product/test-management-tool/qacomplete/ ] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 129/298 выполнялся в последний раз. 9. Avg Run Time (среднее время выполнения) содержит вычисленное автома- тически среднее время, необходимое на выполнение тест-кейса. 10. Last Run Test Set (в последний раз выполнялся в наборе) содержит инфор- мацию о наборе тест-кейсов, в рамках которого тест-кейс выполнялся по- следний раз. 11. Last Run Release (последний раз выполнялся на выпуске) содержит инфор- мацию о выпуске (билде) программного средства, на котором тест-кейс вы- полнялся последний раз. 12. Description (описание) позволяет добавить любую полезную информацию о тест-кейсе (включая особенности выполнения, приготовления и т.д.). 13. Owner (владелец) указывает на владельца тест-кейса (как правило — его ав- тора). 14. Execution Type (способ выполнения) по умолчанию предлагает только значе- ние manual (ручное выполнение), но при соответствующих настройках и ин- теграции с другими продуктами список можно расширить (как минимум доба- вить automated (автоматизированное выполнение)). 15. Version (версия) содержит номер текущей версии тест-кейса (фактически — счётчик того, сколько раз тест-кейс редактировали). Вся история изменений сохраняется, предоставляя возможность вернуться к любой из предыдущих версий. 16. Test Type (вид теста) по умолчанию предлагает такие варианты, как negative (негативный), positive (позитивный), regression (регрессионный), smoke-test ( дымовой). 17. Default host name ( имя хоста по умолчанию) в основном используется в авто- матизированных тест-кейсах и предлагает выбрать из списка имя зареги- стрированного компьютера, на котором установлен специальный клиент. 18. Linked Items (связанные объекты) представляют собой ссылки на требова- ния, отчёты о дефектах и т.д. 19. File Attachments (вложения) могут содержать тестовые данные, поясняющие изображения, видеоролики и т.д. Для описания шагов исполнения и ожидаемых результатов после сохране- ния общего описания тест-кейса становится доступным дополнительный интер- фейс: Рисунок 2.4.d — Добавление шагов тест-кейса в QAComplete При необходимости можно добавить и настроить свои дополнительные поля, значительно расширяющие исходные возможности системы. Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 130/298 TestLink 299 Рисунок 2.4.e — Создание тест-кейса в TestLink 1. Title (заглавие) здесь тоже является обязательным для заполнения. 2. Summary (описание) позволяет добавить любую полезную информацию о тест-кейсе (включая особенности выполнения, приготовления и т.д.). 3. Steps ( шаги выполнения) позволяет описать шаги выполнения. 4. Expected Results ( ожидаемые результаты) позволяет описать ожидаемые ре- зультаты, относящиеся к шагам выполнения. 5. Available Keywords ( доступные ключевые слова) содержит список ключевых слов, которые можно проассоциировать с тест-кейсом для упрощения клас- сификации и поиска тест-кейсов. Это ещё одна вариация идеи «Модулей» и «Подмодулей» (в некоторых системах реализованы оба механизма). 6. Assigned Keywords ( назначенные ключевые слова) содержит список ключе- вых слов, проассоциированных с тест-кейсом. Как видите, инструментальные средства управления тест-кейсами могут быть и достаточно минималистичными. 299 TestLink [ http://sourceforge.net/projects/testlink/ ] 1 2 3 4 5 6 Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 131/298 TestRail 300 Рисунок 2.4.f — Создание тест-кейса в TestRail 1. Title (заглавие) здесь тоже является обязательным для заполнения. 2. Section ( секция) — очередная вариация на тему «Модуль» и «Подмодуль», позволяющая создавать иерархию секций, в которых можно размещать тест- кейсы. 3. Type (тип) здесь по умолчанию предлагает выбрать один из вариантов: auto- mated (автоматизированный), functionality (проверка функциональности), per- formance (производительность), regression (регрессионный), usability (удоб- ство использования), other (прочее). 4. Priority (приоритет) здесь представлен числами, по которым распределены следующие словесные описания: must test (обязательно выполнять), test if 300 TestRail [ http://www.gurock.com/testrail/ ] 1 2 3 4 5 6 7 8 9 10 Инструментальные средства управления тестированием Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 132/298 time (выполнять, если будет время), don’t test (не выполнять). 5. Estimate ( оценка) содержит оценку времени, которое необходимо затратить на выполнение тест-кейса. 6. Milestone (ключевая точка) позволяет указать ключевую точку проекта, к ко- торой данный тест-кейс должен устойчиво показывать положительный ре- зультат (выполняться успешно). 7. References (ссылки) позволяет хранить ссылки на такие артефакты, как тре- бования, пользовательские истории, отчёты о дефектах и иные документы (требует дополнительной настройки). 8. Preconditions (приготовления) представляет собой классику описания пред- варительных условий и необходимых приготовлений к выполнению тест- кейса. 9. Step Description (описание шага) позволяет добавлять описание отдельного шага тест-кейса. 10. Expected Results ( ожидаемые результаты) позволяет описать ожидаемый ре- зультат по каждому шагу. Задание 2.4.c: изучите ещё 3–5 инструментальных средств управления тест-кейсами, почитайте документацию по ним, посоздавайте в них не- сколько тест-кейсов. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 133/298 2.4.5. Свойства качественных тест-кейсов Даже правильно оформленный тест-кейс может оказаться некачественным, если в нём нарушено одно из следующих свойств. Правильный технический язык, точность и единообразие формулиро- вок. Это свойство в равной мере относится и к требованиям, и к тест-кейсам, и к отчётам о дефектах — к любой документации. Основные идеи уже были описаны (см. главу «Атрибуты (поля) тест-кейсов» {121} ), а из самого общего и важного напом- ним и добавим: • пишите лаконично, но понятно; • используйте безличную форму глаголов (например, «открыть» вместо «от- кройте»); • обязательно указывайте точные имена и технически верные названия эле- ментов приложения; • не объясняйте базовые принципы работы с компьютером (предполагается, что ваши коллеги знают, что такое, например, «пункт меню» и как с ним ра- ботать); • везде называйте одни и те же вещи одинаково (например, нельзя в одном тест-кейсе некий режим работы приложения назвать «графическое представ- ление», а в другом тот же режим — «визуальное отображение», т.к. многие люди могут подумать, что речь идёт о разных вещах); • следуйте принятому на проекте стандарту оформления и написания тест- кейсов (иногда такие стандарты могут быть весьма жёсткими: вплоть до ре- гламентации того, названия каких элементов должны быть приведены в двойных кавычках, а каких — в одинарных). Баланс между специфичностью и общностью. Тест-кейс считается тем более специфичным, чем более детально в нём расписаны конкретные действия, конкретные значения и т.д., т.е. чем в нём больше конкретики. Соответственно, тест-кейс считается тем более общим, чем в нём меньше конкретики. Рассмотрим поля «шаги» и «ожидаемые результаты» двух тест-кейсов (по- думайте, какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему): Тест-кейс 1: Шаги Ожидаемые результаты Конвертация из всех поддерживаемых коди- ровок Приготовления: • Создать папки C:/A, C:/B, C:/C, C:/D. • Разместить в папке C:/D файлы 1.html, 2.txt, 3.md из прилагаемого архива. 1. Запустить приложение, выполнив команду «php converter.php c:/a c:/b c:/c/con- verter.log ». 2. Скопировать файлы 1.html, 2.txt, 3.md из папки C:/D в папку C:/A. 3. Остановить приложение нажатием Ctrl+C. 1. Отображается консольный журнал приложе- ния с сообщением «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log », в папке C:/C появляется файл converter.log, в котором появляется за- пись «текущее_время started, source dir c:/a, destination dir c:/b, log file c:/c/converter.log ». 2. Файлы 1.html, 2.txt, 3.md появляются в папке C:/A , затем пропадают оттуда и появляются в папке C:/B. В консольном журнале и файле C:/C/converter.log появляются сообщения (записи) «текущее_время processing 1.html (KOI8-R) », «текущее_время processing 2.txt (CP-1251) », «текущее_время processing 3.md (CP-866) ». 3. В файле C:/C/converter.log появляется за- пись «текущее_время closed». Приложение завершает работу. Свойства качественных тест-кейсов Тестирование программного обеспечения. Базовый курс. © EPAM Systems, 2015–2022 Стр: 134/298 Тест-кейс 2: Шаги Ожидаемые результаты Конвертация из всех поддерживаемых коди- ровок 1. Выполнить конвертацию трёх файлов допу- стимого размера в трёх разных кодировках всех трёх допустимых форматов. 1. Файлы перемещаются в папку-приёмник, ко- дировка всех файлов меняется на UTF-8. Если вернуться к вопросу «какой тест-кейс вы бы посчитали хорошим, а какой — плохим и почему», то ответ таков: оба тест-кейса плохие потому, что первый является слишком специфичным, а второй — слишком общим. Можно сказать, что здесь до абсурда доведены идеи низкоуровневых {118} и высокоуровневых {117} тест- кейсов. Почему плоха излишняя специфичность (тест-кейс 1): • при повторных выполнениях тест-кейса всегда будут выполняться строго одни и те же действия со строго одними и теми же данными, что снижает вероятность обнаружения ошибки; • возрастает время написания, доработки и даже просто прочтения тест-кейса; • в случае выполнения тривиальных действий опытные специалисты тратят дополнительные мыслительные ресурсы в попытках понять, что же они упу- стили из виду, т.к. они привыкли, что так описываются только самые сложные и неочевидные ситуации. Почему плоха излишняя общность (тест-кейс 2): • тест-кейс сложен для выполнения начинающими тестировщиками или даже опытными специалистами, лишь недавно подключившимися к проекту; • недобросовестные сотрудники склонны халатно относиться к таким тест-кей- сам; • тестировщик, выполняющий тест-кейс, может понять его иначе, чем было за- думано автором (и в итоге будет выполнен фактически совсем другой тест- кейс). Выход из этой ситуации состоит в том, чтобы придерживаться золотой сере- дины (хотя, конечно же, какие-то тесты будут чуть более специфичными, какие-то — чуть более общими). Вот пример такого срединного подхода: Тест-кейс 3: |