Чек-лист тестирования: определение, разработка, виды и их специфика
Чек-лист — это набор инструкций. Чек-лист и тестирование могут быт ь связаны, если в чек-листе прописать подробные инструкции о том , что должно быть протестировано на конкретном ресурсе. Самое важное , что дает чек-лист , — он исключает вероятность , что тестировщик забудет провести какой-либо тест. Даже опытные тестировщики могут что-то забыть, а когда это записано перед глазами, тогда забыть труднее.
Чек-лист в тестировании устроен просто. Обычно он имеет табличную форму, где в каждой строке описана задача, которую нужно выполнить , а напротив каждой задачи есть ячейка для записи ее статуса. Например:
|
Выполняемая задача |
Статус |
|
Регистрация по e-mail |
Passed |
|
Регистрация через Facebook |
Passed |
- passed — пройдено;
- failed — неудачно;
- blocked — заблокировано;
- skipped — пропущено;
- not run — не работает.
- видно статус каждого пункта, что улучшает видимость всей системы тестирования;
- дает возможность понять объем проделанной и предстоящей работы;
- помогает не запутаться в тестировании: не проводить тестирование одного и того же компонента и наоборот — не забыть протестировать что-то;
- и др.
Разновидности чек-листов в тестировании
- Специальный чек-лист. Такой чек-лист создается специально под конкретный проект, поэтому учитывает всю специфику проекта. Данный чек-лист не может быть использован в другом проекте. В подобном чек-листе могут быть такие пункты: при наведении кнопка должна поменять цвет на синий, на странице «Товары» должно всплыть определенное уведомление и др.
- Универсальный чек-лист. Такой чек-лист можно использовать на проектах разного рода. В нем указаны пункты проверки, которые не привязаны к графическим или функциональным элементам проекта. В таком чек-листе могут быть следующие пункты: страница «Магазин» должна открыться, оплата должна пройти, при нажатии на кнопку открывается форма, при нажатии на пункт «М еню » осуществляется переход на соответствующую страницу и др.
Чек-лист и тестирование: как составить
- один пункт в чек-листе — это один вид проверки или проверка одного элемента;
- в составе чек-листа должны отражаться требования к программе , и ничего лишнего;
- сложные тестовые задачи нужно разбивать на небольшие пункты в чек-листе;
- чек-лист может быть вложенным в другой чек-лист, если задача очень сложная;
- должен легко читаться и быть понятным.
Пример чек-листа в тестировании
- проверить открытие и доступность сайта;
- проверить открытие и доступность сайта повторно после его закрытия;
- проконтролировать, чтобы работали все пункты в меню;
- проконтролировать, чтобы нажимались кнопки на сайте;
- проверить, чтобы открывались все ссылки;
- посмотреть , чтобы не было битых ссылок;
- заполнить и проверить все формы на сайте;
- проверить работоспособность основных элементов сайта;
- загрузить документы и проверить корректность загрузки;
- и др.
- проверить кодировку сайта, чтобы была UTF-8;
- проконтролировать загрузку и работоспособность шрифтов;
- проверить наличие ошибок HTML и CSS;
- посмотреть корректность работы сайта на разных размерах экрана;
- проверить верстку в разных браузерах;
- проверить наличие тегов H1 на страницах;
- проверить наличие фавикона;
- и др.
- проверить, можно ли заполнить все поля формы;
- отправляется ли форма после нажатия кнопки «Отправить»;
- приходит ли ответное письмо на электронный адрес, указанный при регистрации;
- проверить , как поля передаются в запросе;
- и др.
- есть ли кнопки «Заказать», «Купить», «Добавить в корзину» в карточке товара;
- проверить возможность положить товар в корзину;
- приходит ли оповещение о заказе на электронную почту;
- проверить работу фильтров для товаров;
- проверить работоспособность формы обратной связи;
- проверить наличие страницы «Контакты» и контактов на ней;
- проконтролировать работоспособность ссылок на соцсети интернет-магазина;
- проверить наличие «хлебных крошек»;
- и др.
Заключение
Чек-лист облегчает тестирование, потому что все пункты теста находятся перед глазами и не нужно гадать. Тестировщик составляет чек-лист самостоятельно, поэтому количество и качество пунктов будут зависеть от него самого.
Нужен ли чек-лист при тестировании? Безусловно , нужен, потому что на его составление не уходит много времени, а качество теста он выводит на новый уровень.
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
7. Неполные и пропущенные тесты
Когда вы работаете над новым тестовым классом, вы можете начать с написания пустых тестовых методов для отслеживания тех тестов, которые нужно написать, например:
public function testSomething() >
Проблема с пустыми тестовыми методами состоит в том, что фреймворком PHPUnit они интерпретируется как успешно пройденные. Это ошибочное толкование приводит к тому, что отчёты о покрытии становятся бесполезными — вы не сможете увидеть, действительно ли тест прошёл, либо он просто ещё не реализован. Вызов $this->fail() в нереализованном тестовом методе также не поможет, поскольку тогда тест будет интерпретироваться как не пройденный. Это было бы так же неверно, как и считать нереализованный тест как пройденный.
Если мы думаем об успешном тестировании как о зелёном свете, а о непройденном тесте как о красном цвете, то нам нужен дополнительный жёлтый цвет для обозначения теста как неполного или ещё не реализованного. PHPUnit\Framework\IncompleteTest — это интерфейс для обозначения исключения, выбрасываемого тестовым методом как результат на то, что данный тестовый метод неполный или в данный момент ещё не реализован. PHPUnit\Framework\IncompleteTestError — стандартная реализация этого интерфейса.
Пример 7.1 показывает тестовый класс SampleTest , содержащий один тестовый метод testSomething() . Вызывая удобный метод markTestIncomplete() (который автоматически вызывает исключение PHPUnit\Framework\IncompleteTestError ) в тестовом методе, мы отмечаем, что данный тест является неполным.
Пример 7.1 Маркировка теста как неполного
php use PHPUnit\Framework\TestCase; class SampleTest extends TestCase public function testSomething() // Необязательно: протестируйте здесь что-нибудь, если хотите. $this->assertTrue(true, 'This should already work.'); // Остановиться тут и отметить, что тест неполный. $this->markTestIncomplete( 'Этот тест ещё не реализован.' ); > >
Неполный тест обозначается I в выводе исполнителя тестов командной строки PHPUnit, как показано в следующем примере:
$ phpunit --verbose SampleTest PHPUnit |version|.0 by Sebastian Bergmann and contributors. I Time: 0 seconds, Memory: 3.95Mb There was 1 incomplete test: 1) SampleTest::testSomething Этот тест ещё не реализован. /home/sb/SampleTest.php:12 OK, but incomplete or skipped tests! Tests: 1, Assertions: 1, Incomplete: 1.
Таблица 7.1 показывает API для маркировки тестов как неполных.
| Метод | Описание |
|---|---|
| void markTestIncomplete() | Помечает текущий тест как неполный. |
| void markTestIncomplete(string $message) | Помечает текущий тест как неполный, используя $message в качестве пояснительного сообщения. |
Пропущенные тесты
Не все тесты могут выполняться в любом окружении. Рассмотрим, например, уровень абстракции базы данных, содержащий несколько драйверов для различных систем баз данных, которые он поддерживает. Разумеется, тесты для драйвера MySQL могут выполняться только в том случае, если доступен сервер MySQL.
Пример 7.2 демонстрирует тестовый класс DatabaseTest , содержащий один тестовый метод testConnection() . В шаблонном методе setUp() тестового класса мы проверяем, доступно ли расширение MySQLi, и используем метод markTestSkipped() для пропуска этого теста в противном случае.
Пример 7.2 Пропуск теста
php use PHPUnit\Framework\TestCase; class DatabaseTest extends TestCase protected function setUp() if (!extension_loaded('mysqli')) $this->markTestSkipped( 'Расширение MySQLi недоступно.' ); > > public function testConnection() // . > >
Пропущенный тест обозначается S в выводе исполнителя тестов командной строки PHPUnit, как показано в следующем примере:
$ phpunit --verbose DatabaseTest PHPUnit |version|.0 by Sebastian Bergmann and contributors. S Time: 0 seconds, Memory: 3.95Mb There was 1 skipped test: 1) DatabaseTest::testConnection Расширение MySQLi недоступно. /home/sb/DatabaseTest.php:9 OK, but incomplete or skipped tests! Tests: 1, Assertions: 0, Skipped: 1.
Таблица 7.2 показывает API пропущенных тестов.
| Метод | Описание |
|---|---|
| void markTestSkipped() | Отмечает текущий тест как пропущенный. |
| void markTestSkipped(string $message) | Отмечает текущий тест как пропущенный, используя $message в качестве пояснительного сообщения. |
Пропуск тестов с помощью @requires
В дополнение к вышеперечисленным методам можно также использовать аннотацию @requires , чтобы предоставить общие предварительные условия для тестового класса.
| Тип | Возможные значения | Примеры | Дополнительный пример |
|---|---|---|---|
| PHP | Любой идентификатор версии PHP | @requires PHP 5.3.3 | @requires PHP 7.1-dev |
| PHPUnit | Любой идентификатор версии PHPUnit | @requires PHPUnit 3.6.3 | @requires PHPUnit 4.6 |
| OS | Регулярное выражения для PHP_OS | @requires OS Linux | @requires OS WIN32|WINNT |
| OSFAMILY | Любое семейство ОС | @requires OSFAMILY Solaris | @requires OSFAMILY Windows |
| function | Любой корректный параметр для function_exists | @requires function imap_open | @requires function ReflectionMethod::setAccessible |
| extension | Имя расширения вместе с необязательным идентификатором версии | @requires extension mysqli | @requires extension redis 2.2.0 |
Пример 7.3 Пропуск тестового класса с использованием @requires
php use PHPUnit\Framework\TestCase; /** * @requires extension mysqli */ class DatabaseTest extends TestCase /** * @requires PHP 5.3 */ public function testConnection() // Тест требует расширения mysqli и PHP >= 5.3 > // . Все остальные тесты требует расширения mysqli >
Если вы используете синтаксис, который не компилируется с определённой версией PHP, посмотрите на версии, от которых зависят тестовые классы в XML-конфигурации (см Набор тестов )
© Copyright 2018, Sebastian Bergmann. Revision 65b89c43 .
Read the Docs v: latest
Versions latest Downloads pdf htmlzip epub On Read the Docs Project Home Builds Free document hosting provided by Read the Docs.
Skip и xfail : работа с тестами, которые не могут быть пройдены¶
Тестовые функции, которые не могут быть запущены на определенных платформах или от которых вы ожидаете сбоя, можно пометить так, чтобы pytest работал с ними соответствующим образом и представлял сводку сеанса тестирования, считая набор тестов пройденным и помечая его зеленым.
skip (пропуск) используется в случае, когда вы ожидаете, что ваш тест пройдет только при соблюдении некоторых условий, в противном случае pytest должен полностью пропустить выполнение теста. Распространенными примерами являются пропуск тестов только для windows на платформах, отличных от windows, или пропуск тестов, зависящих от внешнего ресурса, который в данный момент недоступен (например, базы данных).
xfail применяется, когда вы ожидаете, что тест по каким-то причинам должен упасть. Обычный пример — это тест на еще не реализованную функцию или еще не исправленную ошибку. Когда тест, помеченный pytest.mark.xfail , проходит, несмотря на ожидаемое падение, в сводке результатов он будет помечен как xpass.
pytest подсчитывает и перечисляет тесты, помеченные skip и xfail , отдельно. Подробная информация о пропущенных / упавших тестах по умолчанию не отображается, чтобы не загромождать выходные данные. Чтобы увидеть детали, соответствующие «коротким» буквам, показанным в ходе выполнения теста, можно использовать параметр -r , как показано ниже:
pytest -rxXs # показывать дополнительную информацию о тестах xfailed, xpassed, и skipped
Больше информации о параметре -r можно получить, выполнив команду pytest -h (вызов справки).
Пропуск тестовых функций¶
Простейший способ пропустить тестовую функцию — пометить ее декоратором skip , которому может быть передана в качестве параметра reason причина пропуска:
@pytest.mark.skip(reason="no way of currently testing this") def test_the_unknown(): .
Также можно пропустить тест непосредственно во время выполнения, вызвав функцию pytest.skip(reason) :
def test_function(): if not valid_config(): pytest.skip("unsupported configuration")
Такой способ может быть полезен, когда невозможно определить условие пропуска во время импорта.
Можно также пропустить выполнение всего тестового модуля — для этого на уровне модуля используется метод pytest.skip(reason, allow_module_level = True) :
import sys import pytest if not sys.platform.startswith("win"): pytest.skip("skipping windows-only tests", allow_module_level=True)
skipif ¶
Этот декоратор используется, если вы хотите пропускать или не пропускать тесты в зависимости от выполнения какого-либо условия. Ниже — пример тестовой функции, которую следует пропустить при запуске интерпретатора Python ниже версии 3.6:
import sys @pytest.mark.skipif(sys.version_info (3, 6), reason="requires python3.6 or higher") def test_function(): .
Если во время сбора данных условие выполняется (принимает значение True ) — тестовая функция будет пропущена, а указанная причина при использовании параметра -rs отобразится в отчете.
Маркер skipif можно использовать совместно для нескольких модулей. Рассмотрим следующий тестовый модуль:
# content of test_mymodule.py import mymodule minversion = pytest.mark.skipif( mymodule.__versioninfo__ (1, 1), reason="at least mymodule-1.1 required" ) @minversion def test_function(): .
Можно импортировать маркер и использовать его в другом тестовом модуле:
# test_myothermodule.py from test_mymodule import minversion @minversion def test_anotherfunction(): .
Для больших наборов тестов обычно рекомендуется иметь один файл, в котором определяются маркеры, которые затем последовательно применяются во всем наборе тестов.
Кроме того, можно использовать строки условий (см. Conditions as strings instead of booleans) вместо логических значений, но их нельзя легко переносить между модулями, поэтому они поддерживаются главным образом из соображений обратной совместимости.
Пропуск всех тестовых функций класса или модуля¶
Маркер skipif (так же, как и остальные маркеры) можно использовать для класса:
@pytest.mark.skipif(sys.platform == "win32", reason="does not run on windows") class TestPosixCalls: def test_function(self): "will not be setup or run under 'win32' platform"
Если условие выполняется, маркер будет применен для каждого тестового метода класса.
Если вы хотите пропустить все тестовые функции модуля, вы можете использовать pytestmark на глобальном уровне:
# test_module.py pytestmark = pytest.mark.skipif(. )
Когда к тестовой функции применяется несколько декораторов skipif , она будет пропущена, если верно любое из условий пропуска.
Пропуск файлов и директорий¶
Иногда может потребоваться пропустить весь файл или каталог, например, если тесты основаны на специфических для версии Python функциях или содержат код, который вы не хотите запускать с помощью pytest . В этом случае необходимо исключить файлы и каталоги из коллекции. Дополнительную информацию смотрите в разделе Настройка поиска тестов .
Пропуск тестов в зависимости от успешности импорта¶
Вы можете пропустить тесты в случае неудачного импорта, применив pytest.importorskip на уровне модуля, в рамках теста или «setup»-фикстуры:
docutils = pytest.importorskip("docutils")
В данном случае, если docutils не будет импортирован, то тест будет пропущен. Также можно пропустить тест в зависимости от версии импортируемой библиотеки:
docutils = pytest.importorskip("docutils", minversion="0.3")
При этом версия считывается из специального атрибута модуля __version__ .
Краткая сводка¶
Вот краткая шпаргалка, как пропускать тесты в различных ситуациях:
- Пропустить все тесты модуля:
pytestmark = pytest.mark.skip("all tests still WIP")
- Пропустить все тесты модуля при выполнении какого-то условия:
pytestmark = pytest.mark.skipif(sys.platform == "win32", reason="tests for linux only")
- Пропустить все тесты модуля при неудачном импорте:
pexpect = pytest.importorskip("pexpect")
XFail : маркируем тесты, которые должны упасть¶
Маркер xfail используется для пометки ожидаемо падающих тестов:
@pytest.mark.xfail def test_function(): .
Такой тест будет запущен, но при падении не вызовет сообщения об ошибке. В отчете он будет помещен в раздел ожидаемых сбоев ( XFAIL ) или неожиданно прошедших ( XPASS ).
Маркировку xfail можно установить непосредственно в функции (или в «setup»-фикстуре):
def test_function(): if not valid_config(): pytest.xfail("failing configuration (but should work)")
def test_function2(): import slow_module if slow_module.slow_function(): pytest.xfail("slow_module taking too long")
Эти два примера иллюстрируют ситуации, в которых вы не хотите проверять условие на уровне модуля.
Обратите внимание, что в случае вызова pytest.xfail (в отличие от маркировки с помощью @pytest.mark.xfail ) код, расположенный после этого вызова, выполняться не будет. Это происходит потому, что внутренне метод реализуется путем создания определенного исключения.
Параметр strict ¶
Ни XFAIL , ни XPASS по умолчанию не приводят к падению всего набора тестов. Но это можно изменить, установив параметру strict значение True :
@pytest.mark.xfail(strict=True) def test_function(): .
В этом случае, если тест будет неожиданно пройден ( XPASS ), то это приведет к падению всего тестового набора.
Значение по умолчанию параметра strict можно изменить в настройках (в файле«pytest.ini«), используя опцию xfail_strict :
[pytest] xfail_strict=true
Параметр reason ¶
Так же, как и при использовании skipif, можно установить зависимость маркировки xfail от определенного условия:
@pytest.mark.xfail(sys.version_info >= (3, 6), reason="python3.6 api changes") def test_function(): .
Параметр raises ¶
Если вы хотите уточнить причину сбоя теста, вы можете указать одно исключение или кортеж исключений в параметре raises :
@pytest.mark.xfail(raises=RuntimeError) def test_function(): .
В этом случае тест будет объявлен в отчете, как обычный сбой, если он не выполняется с исключением, упомянутом в параметре raises .
Параметр run ¶
Если тест должен быть помечен и учитываться в отчете как маркированный xfail , но при этом даже не должен выполняться, можно установить параметр run в значение False :
@pytest.mark.xfail(run=False) def test_function(): .
Это особенно полезно для тестов xfail , которые приводят к сбою интерпретатора и должны быть исследованы позже.
Игнорирование xfail ¶
Используя параметр —runxfail , можно принудительно запускать и выполнять тесты, помеченные xfail , как обычные непомеченные тесты:
pytest --runxfail
В этом случае метод pytest.xfail также будет игнорироваться.
Примеры¶
Простой тест с несколькими примерами:
import pytest xfail = pytest.mark.xfail @xfail def test_hello(): assert 0 @xfail(run=False) def test_hello2(): assert 0 @xfail("hasattr(os, 'sep')") def test_hello3(): assert 0 @xfail(reason="bug 110") def test_hello4(): assert 0 @xfail('pytest.__version__[0] != "17"') def test_hello5(): assert 0 def test_hello6(): pytest.xfail("reason") @xfail(raises=IndexError) def test_hello7(): x = [] x[1] = 1
Запустив его с параметром -rx (report-on-xfail), получим следующий отчет:
example $ pytest -rx xfail_demo.py =========================== test session starts ============================ platform linux -- Python 3.x.y, pytest-5.x.y, py-1.x.y, pluggy-0.x.y cachedir: $PYTHON_PREFIX/.pytest_cache rootdir: $REGENDOC_TMPDIR/example collected 7 items xfail_demo.py xxxxxxx [100%] ========================= short test summary info ========================== XFAIL xfail_demo.py::test_hello XFAIL xfail_demo.py::test_hello2 reason: [NOTRUN] XFAIL xfail_demo.py::test_hello3 condition: hasattr(os, 'sep') XFAIL xfail_demo.py::test_hello4 bug 110 XFAIL xfail_demo.py::test_hello5 condition: pytest.__version__[0] != "17" XFAIL xfail_demo.py::test_hello6 reason: reason XFAIL xfail_demo.py::test_hello7 ============================ 7 xfailed in 0.12s ============================
Skip / xfail с параметризацией¶
При использовании параметризации можно маркировать skip/xfail отдельные экземпляры тестов:
import pytest @pytest.mark.parametrize( ("n", "expected"), [ (1, 2), pytest.param(1, 0, marks=pytest.mark.xfail), pytest.param(1, 3, marks=pytest.mark.xfail(reason="some bug")), (2, 3), (3, 4), (4, 5), pytest.param( 10, 11, marks=pytest.mark.skipif(sys.version_info >= (3, 0), reason="py2k") ), ], ) def test_increment(n, expected): assert n + 1 == expected
pytest
- Что такое pytest
- Установка
- Содержание
- Примеры
- Конфигурирование
- Лицензия
- Skip и xfail : работа с тестами, которые не могут быть пройдены
- Пропуск тестовых функций
- skipif
- Пропуск всех тестовых функций класса или модуля
- Пропуск файлов и директорий
- Пропуск тестов в зависимости от успешности импорта
- Краткая сводка
- Параметр strict
- Параметр reason
- Параметр raises
- Параметр run
- Игнорирование xfail
- Примеры
Навигация:
- Оглавление
- Предыдущий раздел: Маркировка тестов
- Следующий раздел: Параметризация фикстур и тестовых функций
Полезные ссылки
- pytest @ PyPI
- pytest @ GitHub
- 3rd party plugins
- Issue Tracker
- PDF Documentation
©2015–2020, holger krekel and pytest-dev team. | Powered by Sphinx 2.1.0 & Alabaster 0.7.12 | Page source
Тест кейсы
Тестовый случай (Test Case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.
Высокоуровневый тест-кейс — тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполнению тест-кейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, поскольку прописать все данные подробно намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса — документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента.
Спецификация теста — документ, состоящий из спецификации тест-дизайна, спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»).
Цель написания тест-кейсов:
Тестирование можно проводить и без тест-кейсов (не нужно, но можно; да, эффективность такого подхода варьируется в очень широком диапазоне, в зависимости от множества факторов). Наличие же тест-кейсов позволяет:
- Структурировать и систематизировать подход к тестированию (без чего крупный проект почти гарантированно обречён на провал).
- Вычислять метрики тестового покрытия (test coverage metrics) и принимать меры по его увеличению (тест-кейсы здесь являются главным источником информации, без которого существование подобных метрик теряет смысл).
- Отслеживать соответствие текущей ситуации плану (сколько примерно понадобится тест-кейсов, сколько уже есть, сколько выполнено из запланированного на данном этапе количества и т.д.).
- Уточнить взаимопонимание между заказчиком, разработчиками и тестировщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях)..
- Хранить информацию для длительного использования и обмена опытом между сотрудниками и командами (или, как минимум, не пытаться удержать в голове сотни страниц текста).
- Проводить регрессионное тестирование и повторное тестирование (которые без тест-кейсов было бы вообще невозможно выполнить).
- Повышать качество требований (написание чек-листов и тест-кейсов — хорошая техника тестирования требований).
- Быстро вводить в курс дела нового сотрудника, недавно подключившегося к проекту.
Жизненный цикл тест-кейса
В отличие от отчёта о дефекте, у которого есть полноценный развитый жизненный цикл, для тест-кейса речь идёт о наборе состояний, в которых он может находиться (См. рис.4.2. Жирным шрифтом отмечены наиболее важные состояния).
Рис. 4.2. Жизненный цикл тест-кейса
Создан (new) — типичное начальное состояние практически любого артефакта. Тест-кейс автоматически переходит в это состояние после создания.
Запланирован (planned, ready for testing) — в этом состоянии тест-кейс находится, когда он или явно включён в план ближайшей итерации тестирования, или, как минимум, готов для выполнения.
Не выполнен (not tested) — в некоторых системах управления тест-кейсами это состояние заменяет собой предыдущее («запланирован»). Нахождение тест-кейса в данном состоянии означает, что он готов к выполнению, но ещё не был выполнен.
Выполняется (work in progress) — если тест-кейс требует длительное время для выполнения, то он может быть переведён в это состояние для подчёркивания того факта, что работа идёт, и скоро можно ожидать её результатов. Если выполнение тест-кейса занимает мало времени, это состояние, как правило, пропускается, а тест-кейс сразу переводится в одно из трёх следующих состояний — «провален», «пройден успешно» или «заблокирован».
Пропущен (skipped) — бывают ситуации, когда выполнение тест-кейса отменяется по соображениям нехватки времени или изменения логики тестирования.
Провален (failed) — данное состояние означает, что в процессе выполнения тест-кейса был обнаружен дефект, заключающийся в том, что ожидаемый результат по как минимум одному шагу тест-кейса не совпадает с фактическим результатом. Если в процессе выполнения тест-кейса был «случайно» обнаружен дефект, никак не связанный с шагами тест-кейса и их ожидаемыми результатами, тест-кейс считается пройденным успешно (при этом, естественно, по обнаруженному дефекту создаётся отчёт о дефекте).
Пройден успешно (passed) — данное состояние означает, что в процессе выполнения тест-кейса не было обнаружено дефектов, связанных с расхождением ожидаемых и фактических результатов его шагов.
Заблокирован (blocked) — данное состояние означает, что по какой-то причине выполнение тест-кейса невозможно (как правило, такой причиной является наличие дефекта, не позволяющего реализовать некий пользовательский сценарий).
Закрыт (closed) — очень редкий случай, т.к. тест-кейс, как правило, оставляют в состояниях «провален / пройден успешно / заблокирован / пропущен». В некоторых системах управления тест-кейс переводят в данное состояние, чтобы подчеркнуть тот факт, что на данной итерации тестирования все действия с ним завершены.
Требует доработки (not ready) — как видно из схемы, в это состояние (или из него) тест-кейс может быть переведён в любой момент времени, если в нём будет обнаружена ошибка, если изменятся требования, по которым он был написан, или наступит иная ситуация, не позволяющая считать тест-кейс пригодным для выполнения и перевода в иные состояния.
Структура тест кейса
Идентификатор (identifier) представляет собой уникальное значение, позволяющее однозначно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управления тест-кейсами) может быть и куда сложнее: включать префиксы, суффиксы и иные осмысленные компоненты, позволяющие быстро определить цель тест-кейса и часть приложения (или требований), к которой он относится (например, UR216_S12_DB_Neg).
Приоритет (priority) показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но, чаще всего, лежит в диапазоне от трёх до пяти.
Приоритет тест-кейса может коррелировать с:
- важностью требования, пользовательского сценария или функции, с которыми связан тест-кейс;
- потенциальной важностью дефекта, на поиск которого направлен тест-кейс;
- степенью риска, связанного с проверяемым тест-кейсом требованием, сценарием или функцией.
Основная задача этого атрибута — упрощение распределения внимания и усилий команды (более высокоприоритетные тест-кейсы получают их больше), а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяющей выполнить все запланированные тест-кейсы.
Связанное с тест-кейсом требование (requirement) показывает то основное требование, проверке выполнения которого посвящён тест-кейс (основное, поскольку один тест-кейс может затрагивать несколько требований). Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. Заполнение этого поля является не обязательным.
Модуль и подмодуль приложения (module and submodule) указывают на части приложения, к которым относится тест-кейс, и позволяют лучше понять его цель. Идея деления приложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком, и вопрос «как протестировать это приложение» становится недопустимо сложным. Тогда приложение логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Как правило, иерархия модулей и подмодулей создаётся как единый набор для всей проектной команды, чтобы исключить путаницу из-за того, что разные люди будут использовать разные подходы к такому разделению или даже просто разные названия одних и тех же частей приложения. В реальности проще всего отталкиваться от архитектуры и дизайна приложения. Например, в уже знакомом нам приложении можно выделить такую иерархию модулей и подмодулей:
- Механизм запуска:
- механизм анализа параметров;
- механизм сборки приложения;
- механизм обработки ошибочных ситуаций.
- механизм обхода дерева SOURCE_DIR;
- механизм обработки ошибочных ситуаций.
Заглавие (суть) тест-кейса (title) призвано упростить и ускорить понимание основной идеи (цели) тест-кейса без обращения к его остальным атрибутам.
Исходные данные, необходимые для выполнения тест-кейса (precondition, preparation, initial data, setup), позволяют описать всё то, что должно быть подготовлено до начала выполнения тест-кейса, например:
- состояние базы данных;
- состояние файловой системы и её объектов;
- состояние серверов и сетевой инфраструктуры.
Шаги тест-кейса (steps) описывают последовательность действий, которые необходимо реализовать в процессе выполнения тест-кейса.
Общие рекомендации по написанию шагов таковы:
- Начинайте с понятного и очевидного места, не пишите лишних начальных шагов (запуск приложения, очевидные операции с интерфейсом и т.п.).
- Даже если в тест-кейсе всего один шаг, нумеруйте его (иначе возрастает вероятность в будущем случайно «приклеить» описание этого шага к новому тексту).
- Если вы пишете на русском языке, то используйте безличную форму (например, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»), в английском языке не надо использовать частицу «to» (т.е. «запустить приложение» будет «start application», не «to start application»).
- Соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т.д. В зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно чётко прописанных значений и указаний.
- Ссылайтесь на предыдущие шаги и их диапазоны для сокращения объёма текста (например, «повторить шаги 3–5 со значением…»).
- Пишите шаги последовательно, без условных конструкций вида «если… то…».
Ожидаемые результаты (expected results) по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соответствует номеру результата.
По написанию ожидаемых результатов можно порекомендовать следующее:
- Описывайте поведение системы так, чтобы исключить субъективное толкование (например, «приложение работает верно» — плохо, «появляется окно с надписью…» — хорошо).
- Пишите ожидаемый результат по всем шагам без исключения, если у вас есть хоть малейшие сомнения в том, что результат некоего шага будет совершенно тривиальным и очевидным (если вы всё же пропускаете ожидаемый результат для какого-то тривиального действия, лучше оставить в списке ожидаемых результатов пустую строку — это облегчает восприятие).
- Пишите кратко, но не в ущерб информативности.
- Избегайте условных конструкций вида «если… то…».
Набор тест-кейсов (test case suite, test suite, test set) — совокупность тест-кейсов, выбранных с некоторой общей целью или по некоторому общему признаку.
Наборы тест-кейсов можно разделить на свободные (порядок выполнения тест-кейсов не важен) и последовательные (порядок выполнения тест-кейсов важен).
Преимущества свободных наборов:
- Тест-кейсы можно выполнять в любом удобном порядке, а также создавать «наборы внутри наборов».
- Если какой-то тест-кейс завершился ошибкой, это не повлияет на возможность выполнения других тест-кейсов.
Преимущества последовательных наборов:
- Каждый следующий в наборе тест-кейс, в качестве входного состояния приложения, получает результат работы предыдущего тест-кейса, что позволяет сильно сократить количество шагов в отдельных тест-кейсах.
- Длинные последовательности действий куда лучше имитируют работу реальных пользователей, чем отдельные «точечные» воздействия на приложение.
К отдельному подвиду последовательных наборов тест-кейсов (или даже неоформленных идей тест-кейсов, таких, как пункты чек-листа) можно отнести пользовательские сценарии (или сценарии использования), представляющие собой цепочки действий, выполняемых пользователем в определённой ситуации для достижения определённой цели.
Классификация наборов тест-кейсов
- Набор изолированных свободных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы можно выполнять в любом порядке.
- Набор обобщённых свободных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы можно выполнять в любом порядке.
- Набор изолированных последовательных тест-кейсов: действия из раздела «приготовления» нужно повторять перед каждым тест-кейсом, а сами тест-кейсы нужно выполнять в строго определённом порядке.
- Набор обобщённых последовательных тест-кейсов: действия из раздела «приготовления» нужно выполнить один раз (а потом просто выполнять тест-кейсы), а сами тест-кейсы нужно выполнять в строго определённом порядке.
Главное преимущество изолированности: каждый тест-кейс выполняется в «чистой среде», на него не влияют результаты работы предыдущих тест-кейсов.
Главное преимущество обобщённости: приготовления не нужно повторять (экономия времени).
Главное преимущество последовательности: ощутимое сокращение шагов в каждом тест-кейсе, т.к. результат выполнения предыдущего тест-кейса является начальной ситуацией для следующего.
Главное преимущество свободы: возможность выполнять тест-кейсы в любом порядке, а также то, что при провале какого-то тест-кейса (приложение не пришло в ожидаемое состояние) остальные тест-кейсы по-прежнему можно выполнять.
Набор тест-кейсов всегда создаётся с какой-то целью, на основе какой-то логики, и по этим же принципам в набор включаются тесты, обладающие подходящими свойствами.
Подходы к составлению наборов тест-кейсов:
- На основе чек-листов.
- На основе разбиения приложения на модули и подмодули. Для каждого модуля (или его отдельных подмодулей) можно составить свой набор тест кейсов.
- По принципу проверки самых важных, менее важных и всех остальных функций приложения.
- По принципу группировки тест-кейсов для проверки некоего уровня требований или типа требований, группы требований или отдельного требования.
- По принципу частоты обнаружения тест-кейсами дефектов в приложении (например, мы видим, что некоторые тест-кейсы раз за разом завершаются неудачей, значит, мы можем объединить их в набор, условно названный «проблемные места в приложении»).
- По архитектурному принципу: наборы для проверки пользовательского интерфейса и всего уровня представления, для проверки уровня бизнес-логики, для проверки уровня данных.
- По области внутренней работы приложения, например, «тест-кейсы, затрагивающие работу с базой данных», «тест-кейсы, затрагивающие работу с файловой системой», «тест-кейсы, затрагивающие работу с сетью».
- По видам тестирования.
- Пропуск тестовых функций