Home

Автор: Баранцев Алексей

Это эссе описывает учебный пример создания тестов для веб-приложения. Сначала показано, как создаётся и как выглядит план тестирования. Затем рассматривается модель, которая будет определять критерий отбора тестов. После чего строится собственно набор тестов.

Содержание:

1. Введение
   
2. Описание тестируемой системы, SRS
   
3. План тестирования, TP
   
4. Модель тестирования, TDS
   
5. Комплект тестов, TCS
   
6. Заключение

1. Введение

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

Первое эссе посвящено тому, как я тестировал простейшее веб-приложение — скрипт, предназначенный для формирования страничек новостей на нашем сервере (http://software-testing.ru/news/).

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

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

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

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

[ Содержание ]

2. Описание тестируемой системы, SRS

Итак, что же мы тестируем?

Тестируемая система представляет собой реализованный на языке PHP скрипт, который формирует страничку новостей на этом сайте: http://software-testing.ru/news/. Этот скрипт имеет один параметр topic, идентификатор новости. Если параметр не указан или имеет пустое значение, скрипт выдает список последних десяти новостей. Если параметр имеет непустое значение, скрипт пытается показать новость, имеющую идентификатор, определяемый значением этого параметра. Новости на самом деле берутся из специальной ветки форума, и идентификатор новости — это идентификатор темы в форуме. Идентификатор — положительное целое число, если значение параметра не является положительным целым числом, скрипт выдает сообщение об ошибке. Если в форуме не существует темы с указанным идентификатором, или она существует, но находится не в упомянутой специальной ветке, а в какой-то другой, тоже выдается соответствующее сообщение об ошибке. Если же все хорошо — скрипт показывает первое сообщение темы с данным идентификатором.

Всё описанное в предыдущем параграфе — это требования. Вот их-то мы и будем проверять путём тестирования. Впрочем, проверять мы будем не все перечисленные требования. И об этом пойдет речь в следующей главе, посвященной составлению плана тестирования.

[ Содержание ]

3. План тестирования, TP

Ещё раз повторю: когда я на самом деле тестировал этот скрипт, я план не писал. Зачем же он мне нужен сейчас?

Дело в том, что тогда я был один. А сейчас я пытаюсь рассказать то, что я сделал, большому количеству людей. И кто-нибудь обязательно спросит: почему не протестирован вот этот аспект? почему я считаю, что мой набор тестов полон? почему... И вот тут я с довольным видом скажу — смотрите в план! Ну, пока смотреть-то некуда. Давайте сначала напишем его, а потом уж будем в него смотреть.

Я не люблю изобретать велосипеды. Поэтому я не стану оригинальничать и напишу стандартный план. То есть — соответствующий стандарту. Мне нравится стандарт IEEE 829, написанные в соответствии с ним документы получаются короткими, простыми, понятными и практичными. А тот, кто будет говорить, что шаблон RUP или ещё какой-нибудь другой лучше — пусть сам и пишет в соответствии с этим шаблоном, так ему и надо.

Текст стандарта IEEE 829 не находится в открытом доступе, но интересующий нас раздел 4 этого стандарта, вычлененный и оформленный в виде шаблона плана тестирования, можно найти, например, здесь: http://www.utsc.utoronto.ca/~rosselet/cscd08/ref05/ieee829.html.

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

План тестирования http://software-testing.ru/news/

1. Ссылки
   • [SRS] Software Requirement Specification — см. требования, описанные в разделе 2 этой статьи.
   • [TDS] Test Design Specification — см. раздел 4 этой статьи.
   • [TCS] Test Case Specification — см. раздел 5 этой статьи
2. Введение
   Данный документ представляет собой план тестирования скрипта, генерирующего страничку новостей http://software-testing.ru/news/. Этот план предназначен для учебных целей. В рамках данного плана предполагается выполнить функциональное тестирование скрипта в режиме генерации странички отдельной новости. Тестирование производится с точки зрения конечного пользователя, и разработанные тесты могут быть использованы для приёмочного тестирования.
3. Тестируемая система
   Тестируемая система представляет собой реализованный на языке PHP скрипт, который формирует страничку новостей на этом сайте: http://software-testing.ru/news/. Требования к системе описаны в [SRS].
   У скрипта можно выделить два режима работы — (R1) генерация странички отдельной новости и (R2) генерация списка нескольких последних новостей. Первый режим соответствует непустому значению параметра topic, а второй — пустому значению этого параметра.
4. Тестируемые аспекты
   В рамках данного плана предполагается выполнить:
   • Функциональное тестирование системы в режиме (R1).
5. Нетестируемые аспекты
   В рамках данного плана не предполагается выполнять:
   • Функциональное тестирование системы в режиме (R2).
   • Нефункциональное тестирование, в том числе нагрузочное тестирование, тестирование производительности, тестирование удобства использования (usability) генерируемых страничек новостей.
6. Подход к тестированию
   Уровень тестирования: системное, с точки зрения конечного пользователя.
   Специальные средства тестирования: отсутствуют, тестирование будет производиться вручную.
   Метрики: покрытие путей в модели, описанной в [TDS]. В рамках данного плана предполагается создать комплект тестов, полный относительно этой метрики.
7. Критерии успешности тестирования
   Система передается в эксплуатацию, когда разработан полный комплект тестов и все разработанные тесты выполняются без ошибок.
8. Критерии прекращения тестирования
   Система возвращается на доработку, если хотя бы один из разработанных тестов обнаруживает ошибку. После исправления ошибки система снова передается на тестирование.
9. Поставка
   В результате выполнения данного плана должны появиться:
   • Документ [TDS]
   • Комплект тестов, оформленный в виде [TCS]. Более точно, будут созданы два комплекта тестов: один для тестового окружения, другой — для реального.
10. Требования к окружению
    Для выполнения тестов требуется установленный форум IPB v2.0.*, и в нем должны быть созданы темы так, чтобы для каждого теста можно было найти подходящую тему, удовлетворяющую его входным условиям.

Вот это — мой план. Самое важное в нем написано в середине: пункты с третьего по восьмой. Пункты 3, 4, 6 и 7 — позитивные, они говорят о том, что будет сделано и как именно. Пункты 5 и 8 — негативные, они могут использоваться в качестве отмазки, если до этого дойдёт дело.

[ Содержание ]

4. Модель тестирования, TDS

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

Какой-нибудь комплект тестов может написать всякий, это не представляет особой сложности. Но возникает вопрос — насколько хорош или плох он будет?

Достаточно ли полон наш комплект тестов, не забыли ли мы протестировать что-нибудь? Не слишком ли он велик, нет ли лишних тестов? Последнее особенно актуально для ручного тестирования, так как обычно тесты приходится выполнять не раз и не два, поэтому чем меньше их будет, тем лучше. Но без ущерба для полноты тестирования, разумеется. Молот и наковальня — тестов нужно достаточно много и, вместе с тем, как можно меньше.

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

В данном случае в качестве модели оказалось удобно использовать блок-схему. Вот она:

Рис 1. Модель поведения тестируемой системы

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

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

Итак, считаем, сколько же получилось путей в этой модели. Я насчитал восемь. Именно столько тестов и нужно сделать. По одному на каждый путь.

[ Содержание ]

5. Комплект тестов, TCS

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

1. http://software-testing.ru/news/?topic="'~!@$%^*()?>,./\<[]|
   Этот тест соответствует самому левому пути — значение параметра topic не является числом. В качестве значения параметра указана абракадабра, предложенная одним из участников нашего форума в своём блоге на роль «достаточно плохого» строкового значения.
   Ожидается появление сообщения о том, что указан неправильный идентификатор новости.
2. http://software-testing.ru/news/?topic=-1
   Значение параметра topic является числом, но неположительным (см. также тест 3).
   Ожидается появление сообщения о том, что указан неправильный идентификатор новости.
3. http://software-testing.ru/news/?topic=0
   Значение параметра topic является числом, но неположительным (см. также тест 2).
   Ожидается появление сообщения о том, что указан неправильный идентификатор новости.
4. http://software-testing.ru/news/?topic=1000000
   Значение параметра topic хорошее, но слишком большое, в форуме нет темы с таким идентификатором, мы ещё столько не написали.
   Ожидается появление сообщения о том, что не существует новости с указанным идентификатором (см. также тесты 5 и 6).
5. http://software-testing.ru/news/?topic=2675
   В форуме существует тема с таким идентификатором, но она находится в ветке «Тестирование», а не в ветке «Новости».
   Ожидается появление сообщения о том, что не существует новости с указанным идентификатором (см. также тесты 4 и 6).
6. http://software-testing.ru/news/?topic=2411
   В форуме существует тема с таким идентификатором, но она находится не непосредственно в ветке «Новости», а в одной из ее подветок.
   Ожидается появление сообщения о том, что не существует новости с указанным идентификатором (см. также тесты 4 и 5).
7. http://software-testing.ru/news/?topic=2054
   Всё хорошо — в форуме существует тема с таким идентификатором, и она находится в ветке «Новости», причем тема состоит ровно из одного сообщения.
   Ожидается появление текста новости.
8. http://software-testing.ru/news/?topic=1796
   Всё хорошо — в форуме существует тема с таким идентификатором, и она находится в ветке "Новости", причем тема содержит несколько сообщений.
   Ожидается появление текста новости — первого сообщения в указанной теме.

[ Содержание ]

6. Заключение

Ну вот, комплект тестов готов. Теперь вернемся ещё раз к плану тестирования и посмотрим, насколько успешно мы его выполнили.

На этот раз важными будут пункты 7, 8 и 9. В процессе тестирования находились ошибки, и система несколько раз возвращалась на доработку в соответствии с пунктом 8. В конце концов, все тесты прошли успешно и в соответствии с пунктом 7 система была сдана в эксплуатацию. Кроме того, согласно пункту 9 были сделаны модель тестирования (TDS) и набор тестов (TCS), которые и легли в основу частей 4 и 5 этого эссе (за исключением комплекта тестов для тестового окружения, которые, впрочем, ничего нового к изложенному материалу не добавляют и поэтому в статью не попали).

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

В следующем эссе я расскажу о том, почему термин «критерий тестирования» — это нонсенс. А пока всё.

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