testomat.io управление авто тестамиУспех автоматизации тестирования во многом зависит от того, как тесты будут разработаны. Это напрямую влияет на то, насколько быстро тесты будут разрабатываться, насколько легко в них можно будет сориентироваться, насколько хорошо они смогут локализовать проблему, насколько хорошо они смогут выявлять проблему вообще. На эти и многие другие параметры влияет то, как будут структурированы тесты. То есть немаловажную роль в этом играет тест-дизайн. Ведь именно тестовый сценарий или тестовое предписание служит основой для реализации автоматического теста. Поэтому, если повлиять на процесс на стадии тест-дизайна, то можно заметно улучшить процесс автоматизации тестирования. Итак, что нужно тестам, чтобы их потом легче было легче автоматизировать:
- Все тесты (или большинство) начинаются с некоторого фиксированного состояния - это соответствует пользовательскому сценарию по работе с некоторой системой. Зачастую, есть общий набор действий, от которого уже потом отталкивается тест. С точки зрения автоматической реализации, будет написан некоторый метод или другой вид модуля, который приводит систему в исходное состояние и потом возвращает в него (если надо). Во многих решениях автоматизации подобная реализация предусмотрена специальными блоками (setUp, tearDown в JUnit-e, appstate в СилкТесте и т.п.).
- Тесты не зависят друг от друга - это очень болезненный момент. Нехорошо, когда сбой в одном из тестов повлечет за собой ошибки в других тестах. В этом случае непонятна сегментация тестов. Фактически, получаем один длинный workflow-тест, который разбит просто на подпункты и сбой в одном месте влечет за собой "эффект домино". Чтобы избежать подобного эффекта, лучше сразу предусмотреть возможность выполнения теста как в пакете, так и отдельно. Подобное выравнивание достигается фиксацией начального состояния (см. предыдущий пункт), а также определением дополнительных условий, необходимых именно для данного теста. Зачастую, эта проблема соприкасается с проблемой организации внешних данных для тестов.
- Одна функция - один тест - идея заключается в том, чтобы тесты делать не огромными, которые бы охватывали множество разных аспектов или какой-то длинный workflow, а более-менее сосредотачивались на некоторой одной функции. То есть, тест строится на том, что мы перешли в некоторое состояние, из которого доступна тестируемая функция, сделали ввод и проверили результаты заботы функции, а затем вышли. Не больше, не меньше. Если уже затрагивается более одного бизнес-функционала в одном тесте, при этом эти функции не являются взаимо-зависимыми, то в результате наши автоматизированные тесты рискуют пропустить ошибку в одном функционале, если будет выявлена критичная ошибка в другом функционале, который проверялся раньше. С точки зрения дизайна разница в предложенных подходах незначительная, но с точки зрения реализации появляются проблемы с выравниванием состояния приложения, чтобы можно было продолжить тест. Безусловно, глупо плодить тысячи мелких и крайне похожих тестов, но и слишком длинные сценарии вредны. Нужно искать некоторый баланс, удобный и для дизайна и для реализации
- Имеется фиксированный набор выполняемых команд и верификаций - имеется ввиду, что было бы неплохо сформировать достаточно узкий и в то же время покрывающий по максимуму набор выполняемых команд с поправкой на параметры. Например, если мы тестируем Content Management System, то у нас для разного типа содержимого есть фиксированный набор операций: перейти - создать и заполнить - сохранить и проверить - переоткрыть - модифицировать - сохранить и проверить. Вот по такому шаблону можно пройтись по всем типам содержимого, специфику составляют только используемые ресурсы. В этом случае, тест-дизайнер делает много дублирований, которые потом устраняются во время автоматизации, а ведь настоящий джедай знает, что Copy/Paste sucks. Более того, есть различные подходы в автоматизации тестирования, которые эффективны именно при определенном дизайне. Так вот тот же keyword-driven подход как раз наиболее эффективен, когда можно выделить фиксированный набор действий. Поэтому, формирование единого каркаса для группы тестов, резко уменьшает работу тест-дизайнеру, а затем и автоматизатору
Процесс тестирования не является ни изолированным, ни разрозненным, поэтому есть возможность подумать об упрощении своей работы еще до того, когда она к вам поступила. А грамотный тест-дизайн позволит минимизировать ваши проблемы в реализации в дальнейшем