Файл: Тестирование программного обеспечения.pdf

Тестовая документация состоит обычно из отдельных сценариев, которые называются тест-кейсами и могут быть для удобства объединены в группы или тест-сьюты.

Написание тестовой документации имеет много общего с написанием ПО: следует разбивать код на отдельные модули и избегать дублирования кода.

4.1. Что должна содержать тестовая документация и почему.

В общем случае, тестовая документация может содержать: заголовок, пошаговое описание, ожидаемый результат, критерий соответствия ожидаемого результата фактическому.

Тест-кейс должен обязательно содержать хотя бы ожидаемый результат (даже, может быть, без описания действий, которые к нему ведут). Например, "Программа должна уметь показывать файлы формата BMP". Такой тесткейс представляет собой просто перепечатку из документа с требованиями.

Однако, из такого тесткейса непонятно, как осуществить проверку. Человек, незнакомый с программой, может попросту не найти в ее интерфейсе, как показывать графические файлы, и напишет баг об отсутствии такой возможности.

Поэтому, кроме ожидаемого результата, необходимо еще пошаговое описание действий, которые позволят нам прийти к результату фактическому и сравнить его с ожидаемым.

Краткое описание тест-кейса имеет смысл вынести в заголовок.

Пример.

Заголовок: "Проверка того, что программа умеет показывать файлы формата BMP"

Шаг 1. Нажать кнопку "Выбрать файл"

Шаг 2. Выбрать файл с расширением BMP

Шаг 3. Нажать кнопку "Открыть"

Ожидаемый результат: содержимое файла показано в графическом виде, в полноэкранном режиме.

Здесь сравнение ожидаемого результата и фактического осуществить довольно просто, и критерий соответствия не нужен. Приведем более сложный пример:

Заголовок: "Проверка изменения домашнего телефона пользователя в ActiveDirectory"

Шаг 1. Нажать кнопку "Создать пользователя"

Шаг 2. Ввести имя пользователя, логин и пароль.

Шаг 3. Нажать кнопку OK

Шаг 4. Выбрать только что созданного пользователя в списке, кликнув на его логин.

Шаг 5. Нажать кнопку "Редактировать"

шаг 6. Ввести номер телефона в поле "Домашний телефон"

шаг 7. Нажать кнопку ОК

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

Здесь ожидаемый результат было бы неплохо также расписать в виде последовательности шагов: как посмотреть в ActiveDirectory, что домашний телефон сохранился. Это и будет описанием критерия соответствия. Можно записать эти шаги здесь же, начиная с номера 8, и уточнить ожидаемый результат:

Шаг 8. Залогиниться на сервер AciveDirectory

Шаг 9. Открыть оснастку dsa.msc

Шаг 10. Найти пользователя по логину

Шаг 11. Посмотреть значение поля Home phone

Ожидаемый результат: это значение соответствует номеру телефона в поле "Домашний телефон"

Однако, строго говоря, эти шаги не являются частью тестируемого сценария. При изменении или удалении сценария эта инструкция может быть потеряна. Поэтому имеет смысл записать ее на специальном сайте - базе знаний (Knowledge Base, KB), а в тесткейсе дать ссылку на эту инструкцию.

Кроме того, если эта инструкция будет использована в других тесткейсах, нам не нужно будет ее каждый раз копировать, достаточно будет давать ссылку.

Таким образом, возвращаемся к предыдущему варианту и вставляем ссылку в поле "Ожидаемый результат":

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

4.2. Тестовые объекты и тестовые данные

Вышеприведенный тесткейс должен проверять редактирование телефона пользователя. Однако же первые три шага не относятся к редактированию телефона. Это вспомогательные шаги по созданию пользователя - мы создаем тестовый объект, объект, который мы будем использовать в тестах. Целесообразно вынести эти шаги в отдельную секцию "Setup", и описать более кратко:

Setup:

Создать пользователя.

Шаг 1. Открыть список пользователей.

Шаг 2. Выбрать пользователя в списке, кликнув на его логин.

Шаг 3. Нажать кнопку "Редактировать"

шаг 4. Ввести номер телефона в поле "Домашний телефон"

шаг 5. Нажать кнопку ОК

Ожидаемый результат: домашний телефон сохранился в ActiveDirectory.

Секцию Setup, как и Ожидаемый результат, тоже можно сделать гиперссылкой на соответствующую инструкцию. Таким образом, мы избавимся от дублирования информации в разных тестах и улучшим читабельность тестов и их поддержку, если в системе что-то поменяется. Вообще, процесс написания и поддержки тестовой документации имеет много общего с написанием и поддержкой программного обеспечения. Здесь так же важно избавляться от дублирования кода и выделять его в отдельные процедуры.

Часто один и тот же тесткейс следует выполнять с разными тестовыми данными. Например, если программа должна уметь показывать файлы в формате BMP, JPG и GIF, логично написать один тесткейс и указать в специальной секции, что выполняться он должен с использованием трех файлов разного формата. По аналогии с программированием - мы выносим название формата в параметр процедуры. Такой тесткейс называется data-driven - управляемый данными.

Тестовую документацию следует писать так, чтобы ее было легко поддерживать при изменениях в продукте!

Можно сказать, что хорошим стилем в написании тестовой документации является высокоуровневое описание действий, имеющее ссылки на пошаговое описание. Такая документация пригодна для использования как опытными (знакомыми с продуктом) тестировщиками, так и неопытными или аутсорсерами. Опытным тестировщикам не надо тратить время на чтение пошаговых инструкций (как правило, они их и так знают), а неопытные всегда смогут их прочитать.

Если же стоит задача написать тестовую документацию в кратчайшие сроки, приходится выбирать между пошаговым и высокоуровневым стилем (без ссылок). Как правило, следует выбирать высокоуровневый стиль, потому что, во-первых, так быстрее писать, а во-вторых, снабдить такой документ ссылками на пошаговое описание в дальнейшем будет проще, чем зарефакторить пошаговые инструкции.

4.3. Идентификатор тесткейса, приоритет, время прохождения

Тесткейсы полезно снабжать уникальными идентификаторами, чтобы можно было легко на них ссылаться.

Приоритет тесткейса - это его важность. Логично, что наиболее важные, критичные тесткейсы следует проходить в первую очередь, менее важные - во вторую и т.д., чтобы при нехватке времени пропускались менее необходимые вещи. Приоритет имеет смысл обозначать числом. Существует несколько методик расстановки приоритетов.

Целесообразно также указывать планируемое время прохождения тесткейса (при его создании) - для оценки трудозатрат на тестирование. Это время может быть скорректировано с учетом реальной истории прохождения. Например, если первоначально планируемое время составляло 10 минут, а реально кейс был пройден за 30 минут, это повод узнать у тестировщика, в чем была загвоздка и по результатам либо попросить его работать в 3 раза быстрее, либо скорректировать оценку.

4.4. История изменений и история прохождений

Опять же по аналогии с ПО, имеет смысл документировать все изменения в тестовой документации, чтобы можно было понять, почему, кто и когда их сделал. В простейшем случае тестовая документация может храниться в системе контроля версий, например CVS или SVN, в виде отдельного документа на каждый тесткейс или на группу кейсов, связанную по смыслу.

Однако этот способ не так удобен, как применение специализированных систем поддержки тестовой документации, например TestRail или Testlink. Такие системы имеют ряд дополнительных функций, связанных с прохождением тесткейсов:

1. возможность назначать тесткейсы сотрудникам для прохождения;

2. возможность собирать статистику прохождений (фамилия сотрудника, потраченное время и найденные баги).

5. Тестирование мобильных приложений.

Тестирование – очень важный этап разработки мобильных приложений.

Стоимость ошибки в релизе мобильного приложения высока. Приложения попадают в Google Play в течении нескольких часов, в Appstore несколько недель. Неизвестно сколько времени будут обновляться пользователи. Ошибки вызывают бурную негативную реакцию, пользователи оставляют низкие оценки и истерические отзывы. Новые пользователи, видя это, не устанавливают приложение.

Мобильное тестирование сложный процесс: десятки различных разрешений экрана, аппаратные отличия, несколько версий операционных систем, разные типы подключения к интернету, внезапные обрывы связи.

Поэтому в отделе тестирования, как правило, работает множество сотрудников (обычно приходится по 0,5 тестировщика на программиста), за его развитием и процессами следит выделенный тест-лид.

5.1. Тестирование требований

Тестирование начинается до разработки. Отдел дизайна передает тестировщикам навигационную схему и макеты экранов, менеджер проекта – требования невидимые на дизайне. Если дизайн предоставляет заказчик, макеты до передачи в отдел тестирования проверяются штатными дизайнерами компании.

Рисунок 1 - Начальные этапы тестирования

Тестировщик анализирует требования на полноту и противоречивость. В каждом проекте исходные требования содержат противоречивую информацию. Тим-лидеры стараются решить их еще до начала разработки. Так же в каждом проекте требования неполны: не хватает макетов второстепенных экранов, ограничений на поля ввода, отображения ошибок, кнопки никуда не ведут. Неочевидны невидимые на макетах вещи: анимации, кеширование картинок и содержимого экранов, работа в нестандартных ситуациях.

Недостатки требований обсуждаются с менеджером проекта, разработчиками и дизайнерами. После 2-3 итераций, вся команда гораздо лучше понимает проект, вспоминает забытый функционал, фиксирует решения по спорным вопросам. В основном на этом этапе используется basecamp.

Когда требования стали полны и непротиворечивы, тестировщик составляет smoke-тесты и функциональные тесты, покрывающие исходные данные. Тесты деляется на общие и специфические для разных платформ. Для хранения и прогона тестов мы используем Sitechсo.

Рисунок 2 - Рабочая среда тестировщика (наполнение тестов)

После этого первый шаг тестирования заканчивается и проект уходит в разработку.

5.2. Билд-сервер

Как правило, проекты собираются на TeamCity билд-сервере.

Рисунок 3 - Интерфейс билд-сервера

Если менеджер проекта поставит галочку «для тестирования», тестировщикам уходит письмо о новой сборке для тестирования. Ее номер отображается на мониторе в кабинете тестировщиков. Красным отображаются билды выпущенные за последние сутки, их нужно тестировать активнее, чем белые. Тестирование билдов бывает быстрое и полное.