 ПОЗНАВАТЕЛЬНОЕ Сила воли ведет к действию, а позитивные действия формируют позитивное отношение Как определить диапазон голоса - ваш вокал Игровые автоматы с быстрым выводом Как самому избавиться от обидчивости Противоречивые взгляды на качества, присущие мужчинам Вкуснейший "Салат из свеклы с чесноком" Натюрморт и его изобразительные возможности Применение, как принимать мумие? Мумие для волос, лица, при переломах, при кровотечении и т.д. Как научиться брать на себя ответственность Зачем нужны границы в отношениях с детьми? Световозвращающие элементы на детской одежде Как победить свой возраст? Восемь уникальных способов, которые помогут достичь долголетия Классификация ожирения по ИМТ (ВОЗ) Глава 3. Завет мужчины с женщиной
Оси и плоскости тела человека - Тело человека состоит из определенных топографических частей и участков, в которых расположены органы, мышцы, сосуды, нервы и т.д.
| b)Структура Тестовых Случаев (Test Case Structure). 12
Каждый тест кейс должен состоять из трех частей. В таблице показаны эти части. Таблица. Структура Test case.
Примечание: Post Conditions не является обязательной частью. Эта часть актуальна при автоматизированном тестировании, когда за один прогон можно наполнить базу данных сотней или даже тысячей некорректных документов. Пример тест-кейса: do A1, verify B1 do A2, verify B2 do A3, verify B3. В приведенном примере конечная проверка - В3. Это значит, что именно она является ключевой. Значит, A1 и А2 - это действия приводящие систему в тестопригодное состояние. А В1 и В2 - условия того, что система находится в состоянии пригодном для тестирования. Таким образом, в таблице ниже показано условие тест-кейса. Таблица. Условие тест-кейса.
PostConditions в данном примере не были описаны, но по логике вещей надо выполнить шаги, которые бы вернули систему в первоначальное состояние. (например, удалили созданную запись, или отменили бы изменения сделанные в документе) Нужно ответить на вопрос: "Почему данное разбиение удобно использовать?" Ответ в таблице ниже: конечная проверка одна, т.е. в случае если тест провален (test failed) будет сразу ясно из-за чего. Т.к. если провальными окажутся проверки В1 и/или В2, то тест кейс будет заблокирован (test blocked), из-за того, что функцию не возможно привести в тестопригодное состояние (состояние пригодное для проведения тестирования), но это не значит, что тестируемая функция не работает. Таблица. Один из вариантов результата.
c)Детализация описания тест кейсов. Уровень детализации тест кейсов должен быть таков, чтобы обеспечивать разумное соотношение времени прохождения к тестовому покрытию. Т.е. до тех пор пока покрытие тестами определенного функционала не меняется, можно уменьшать детализацию тест кейсов. В таблице ниже можно увидеть пример детализации тест-кейса: Таблица. Пример тест-кейса 1.
Пример тест кейса 2: Название: Проверка отображения страницы Действие: Открыть страницу "Вход в систему" Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему"). В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Второй пример будет нагляднее. D)Атрибуты тест-кейса. В таблице ниже представлены часто используемые атрибуты тест-кейса. Таблица. Атрибуты тест кейса.
Пример тест кейса: пусть для тестирования возможности оплаты услуги на сайте необходимо выполнить следующий алгоритм: 1) открыть vk.com; 2) ввести в поле “Имя пользователя” значение “user”; 3) ввести в поле “Пароль” значение “password”; 4) нажать кнопку “Войти”; 5) ввести в поле “Искать людей” значение “Петр Петров”; 6) нажать кнопку “Поиск”; 7) нажать на страницу с Петр Петров; 8) в открывшейся странице нажать на ссылку “Отправить подарок”; 9) в открывшейся странице нажать на любую ссылку с подарком; 10) в открывшейся странице нажать на кнопку “Подарить”; 11) в открывшейся странице нажать на ссылку “Банковские карты”; 12) ввести в поле “Номер карты” значение карты VISA “1111-1111-1111-1111”; 13) ввести в поле “Действительно до” значение “07/15”; 14) ввести в поле “CVC” значение “111”; 15) нажать кнопку “Оплатить”; 16) записать номер заказа; 17) запросить базу данных “select res from payment where id = <номер заказа>”. Ожидаемый результат: “10” В таблице ниже можно увидеть как для данного примера будет выглядеть тест-кейс. Преимущество такой структуры тест кейса в отличии от первоначального списка заключается в том, что есть возможность протестировать по тому же сценарию другие данные (например: user2, password2, Джулия Робертс, 2222-2222-2222-2222). Для выполнения одного и того же сценария на N наборах тестовых данных создается N тестов. Этому правилу необходимо следовать. Таким образом, чтобы сделать подарок Ивану Иванову, нужно скопировать содержимое тест кейса VV12345, например, в тест кейс VV12346 и переписать только входные параметры. Такой вид тест кейса называется управляемый данными (data-driven). Проблемы сценария в примере: – пункты 1-4 могут меняться в связи с миграцией сайта на новый домен, изменением интерфейса и т.д.; – поиск друга в пунктах 5-7 “Петр Петров” может привести в никуда при удалении страницы; – пункты 8-15 могут быть легко изменены за счет нового дизайна сайта. Следовательно, при любом таком изменении придется переписывать весь тест кейс, чтобы заново протестировать первоначальную задачу. Таблица. Тест-кейс для примера.
Если же разбить задачу на несколько тест-кейсов, например, за пункты 1-4 будет отвечать тест-кейс “Вход в систему”, за пункты 5-7 “Поиск друга”, 8-15 – “Оплата подарка” (на внутреннем уровне каждого из них возможно еще более детальное разделение), то можно переписать тест-кейс так, как указано в таблице ниже. Таблица. Упрощение тест-кейса.
Возможен вариант, когда все, что нужно – это выполнение команды номер 5, при условии что другие команды выполнены заранее. В таблице ниже указан упрощенный вариант тест-кейса. Таблица. Упрощение тест-кейса.
Неизвестным параметр <Номер заказа> после завершения выполнения теста получит свое значение, которое будет задокументировано. 12 |
