Введение
Подошло то время, когда от философствования по поводу тестирования(Обеспечение качества. Контроль качества. Тестирование и Необходимые и достаточные условия для проведения тестирования) надо спуститься на землю и поговорить о самых незначительных составляющих его, а именно о тестовых случаях (test cases).Приходя в новую компанию, зачастую встречаешься с тем, что правила написания тест кейсов отличаются от тех, которые вы использовали раньше. Есть вариант - смирится и писать по-новому, а есть более сложный - попытаться всех обратить в свою веру. Второй вариант наиболее труден, по-скольку придется доказать всем, что подход предложенный вами во-первых наиболее правильный, во-вторых - лучше имеющегося. И чтобы это сделать надо оперировать не только руками и жестами, но и теорией с практикой, и приводя примеры, из которых становится очевидно превосходство вашего подхода.
Далее в статье я постараюсь обратить вас в свою веру и рассказать, какой подход использую при написании тестовых случаев.
Тестовый случай (Test Case)
Да простят меня гуру тестирования и отцы самых передовых теорий, но я не буду давать определения, предложенные ими, а попытаюсь сформулировать свое, основанное на личной опыте и имеющимися теоретическими знаниями:Тестовый случай (Test Case) - это последовательность действий, по которой можно проверить соответствует ли тестируемая функция установленным требованиям.
Под последовательностью действий понимается структура вида:
Action > Expected Result > Test Result
Пример:
Action | Expected Result | Test Result(passed/failed/blocked) |
Open page "login" | Login page is opened | Passed |
Структура Тестовых Случаев (Test Case Structure)
На просторах интернета вы сможете найти очень много информации о структуре тест кейсов, уровне их детализации и количестве проверок в них, я собираюсь рассказать о подходе используемом мной, и который я хочу предложить использовать вам.Каждый тест кейс должен иметь 3 части:
PreConditions | Список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния. |
Test Case Description | Список действий переводящий систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям |
PostConditions | Список действий, переводящий систему в первоначальное состояние (состояние до проведения теста - initial state) |
Примечание: Post Conditions не является обязательной частью. Это скорее всего - правило хорошего тона: "намусорил - убери за собой". Это особенно актуально при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов.
Пример тест кейса: do A1, verify B1
do A2, verify B2
do A3, verify B3
В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом имеем:
Action | Expected Result | Test Result (passed/failed/blocked) |
PreConditions | ||
do A1 | verify B1 | |
do A2 | verify B2 | |
Test Case Description | ||
do A3 | verify B3 | |
PostConditions | ||
PostConditions в данном примере не было описаны, но по логике вещей надо выполнить шаги, которые бы вернули систему в первоначальное состояние. (например, удалили созданную запись, или отменили бы изменения сделанные в документе)
Теперь ответим на вопрос: "Почему данное разбиение удобно использовать?"
Ответ: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает.
Action | Expected Result | Test Result (passed/failed/blocked) |
PreConditions | ||
do A1 | verify B1 | passed |
do A2 | verify B2 | failed |
Test Case Description: | ||
do A3 | verify B3 | blocked |
PostConditions | ||
Детализация описания тест кейсов (Test Case Details Elaboration)
Бытует много разных мнений об уровне детализации при написании тест кейсов, а также количестве проверок в одном тест кейсе. Все они по своему правильные. Мое мнение, что уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кесов.Пример тест кейса 1:
Проверка отображения страницы | ||
Действие | Ожидаемый результат | Результат теста |
Открыть страницу Логин | - Окно Логин открыто - Название окна - Логин - Логотип компании отображается в правом верхнем углу - На форме 2 поля - Имя и Пароль - Кнопка Логин доступна - Линк забыл пароль - доступен | ... |
Пример тест кейса 2:
Название: Проверка отображения страницы
Действие: Открыть страницу Логин
Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем скринншот страницы Логин)
В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Мне кажется, что второй пример будет даже нагляднее.
5 комментариев:
Дополнить основу Action > Expected Result > Test Result можно так:
Abstract (Case Description) > Action (я это называл "Steps to reproduce" > Expected results > Actual result > Comments
"Steps to reproduce" (шаги воспроизведения) чего?
STR более соответсвуют Багу, а не тестовому случаю (ИМХО).
В крайнем случае можна заменить на Action steps. Хотя Action более лаконично :)
Согласен с последним комментарием, если быть точным, STR действительно больше подходит к багрепорту, чем к тест кейсу... Но великий и могучий русский язык тем могуч и велик, что может одно и тоже выразить поразному...
Я своим постом лишь расписал основу (костяк) тест кейса, с которой рекомендовал бы начать. А вот во что ее заворачивать, и как расширять - это уже тема другой статьи.
Коллеги, с точки зрения чистоты теории - да, в тест-кейсе STR не пишут. Но я практик, и я начал так писать просто потому, что эти два термина тождественны.
Если я провожу тест строго по скрипту, и нахожу дефект, то в трекер я просто копирую эти самые STR, они же Action, они же "былина о том, что и как нажималось, да и что из этого получилось".
спасибо!! как раз то что нужн...точно и по сути...без лишних отклонений от темы и ненужных усложнений
Отправить комментарий