Хабр не выдержал хабраэффекта )

Универсальное резюме :)

Автотесты на автотесты ?

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

Наверное, почти любой тестер скажет - "Хорошо, когда разработчики пишут unit-тесты на свои библиотеки".. Кто-то при этом дополнит " а если не пишут, то давайте напишем мы..." Для чего? Конечно же для того, чтобы итоговый продукт был более качественным. Это все банально и понятно.  Но когда дело касается кода тестерских либ, то тут повсеместно наблюдается весьма странная вещь  - код этих библиотек довольно редко обкладывается тестами.

Попробуем разобраться, почему так происходит...

1. многим тестировщикам просто в голову не приходит , что их код это тоже код и он тоже может содержать ошибки
2. кто по вдумчивее скажет: тестерский код часто меняется, не решает бизнес-задач пользователя, денег не несет и потому риски багов  в нем ничтожны - да, это аргумент
3. кто-то понимает , что "по-хорошему надо бы обложить тестами", но не делает этого ввиду нехватки времени, желания , а порой отсутствия такой активности как таковой в группе тестирования, отсуствия такого прецедента....

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

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

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

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

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

uml для описания тест-кейсов

Уже довольно продолжительное время приходится заниматься дизайном тестов для ПО из сферы телекомуникаций.
Как правило тест-кейсы направлены на проверку взаимодействия абонента, сетевого оборудования , ААА-серверов и т.д.
Для описания тестовых случаев мною обычно применялся классический способ - текстовое описание предусловий, последовательности действий, результата.
С некоторых пор стал замечать, что описанным классическим способом тестовым случаям не хватает наглядности, а само описание текстом последовательности пакетов, действий с БД и так далее - довольно утомительное занятие, при котором сам дизайнер нет-нет да оставит что-то между строк как само собой разумеещееся.
Все это приводит к появлению риска неполного или неправильного понимания описания тестировщиком, увеличивает число уточняющих вопросов к дизайнеру при выполении теста. Для решения этой "проблемы" решил попробовать uml-диаграммы. А точнее activity-диаграммы.
Например:
 
На мой взгляд, гораздо нагляднее и лаконичнее, чем расписанная по пунктам последовательность действий, пакетов , ответов...
И чем сложнее тестовый-случай (взять хотя бы сценарий использования Cisco SSG , личного кабинета с какой-нибудь турбокнопкой ) , тем оправданнее становится применение подобных схем. Текстовое описание входных данных , к которым прикрепляется подобная activity-диаграмма делают тест-кейсы подобного рода более наглядными и понятными конечному тестировщику.
Конечно же возникает вопрос способа рисования такой диаграммы.
Лично я не использую никаких десктопных приложений в стиле "перенеси и брось", а просто компиллирую uml-код в изображение.

Вот код для картинки, которая помещена выше:

@startuml
title 
Тест-кейс "Неверный пароль"
end title

participant User
participant NAS
participant Radiusd
participant DB

User    -> NAS: Start internet session with username = 'ivan' and password='007'
NAS     -> Radiusd: Access Request 
Radiusd -> DB: User authentication (check username and password)
DB      -> Radiusd: Incorrect password
Radiusd -> NAS: Access Reject
NAS     -> User: failed to establish internet connection

@enduml

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