Содержание
- 2. Какие бывают тесты Перед вами обыкновенная ручка. Давайте подумаем, как её можно протестировать?
- 3. Тесты на основе требований (requirements based tests) Извлекается и вставляется ли в ручку стержень? Присутствует ли
- 4. Сравнительные («параллельные») тесты (parallel testing) Что мы можем сказать об этой ручке в сравнении с другими
- 5. Тесты ошибочных ситуаций (fault injection tests) Что произойдёт, если препятствовать выходу стержня в рабочее положение? Какое
- 6. Тесты упаковки и документации (packaging/documentation tests) Вложена ли в упаковку копия текста о гарантийных обязательствах? Ясно
- 7. Тесты производительности (performance tests) Сколько текста можно написать ручкой в единицу времени? Как быстро ручку можно
- 8. Класс эквивалентности (equivalence class) – набор тестов, полное выполнение которого является избыточным и не приводит к
- 9. Несколько тестов эквивалентны, если: Они направлены на поиск одной и той же ошибки Если один из
- 10. Граничные условия (или просто – границы) – это те места, в которых один класс эквивалентности переходит
- 11. Пример: Необходимо проверить, как работает поле, в которое можно ввести целое число в диапазоне от 1
- 12. Тесты, которые мы выполним: Ввести 1, 99, 50 Ввести 0 Ввести 100 Ввести 50.5 Ввести букву
- 13. Пример: Открытие файла. Чтобы добавить файл в свою фотогалерею на сайте, пользователь должен кликнуть по кнопке
- 14. «Корректный» файл Очень большой файл Несуществующий файл «Файл по сети» (Доступный. Недоступный будет эквивалентен несуществующему) Уже
- 15. Классы эквивалентности не всегда очевидны. Как правило, негативных тестов получается больше, чем позитивных. Принадлежность теста к
- 16. Упрощенная форма тест-кейса Главный принцип чек-листов заключается в том, что каждый тестировщик по-своему проходит их, расширяя
- 17. Разбивайте приложение на модули (модуль авторизации, модуль настроек и т.д.) Используйте «косметику» Используйте техники ускорения написания
- 18. Результатом документирования тестов является тест-кейс. Набор тест-кейсов – Test Suite. Документирование тестов
- 19. IEEE Std 610-1990: «A set of test inputs, execution conditions, and expected results developed for a
- 20. «Планирование, и только потом – выполнение!» Тест-кейсы дают нам структурированный системный подход, что снижает вероятность пропуска
- 21. Тест-кейсы могут быть: Специфичными или общими. Простыми или сложными. Независимыми или связанными друг с другом. Позитивными
- 22. Когда все детали прописаны до мелочей, при повторных выполнениях теста всегда будут выполняться строго одни и
- 23. Рассмотрим на примере. Где в ниже перечисленном простые тест-кейсы, а где – сложные? Набор 1: 1.
- 24. Простые тесты оперируют за раз одним объектом. Каковы преимущества простых тест-кейсов? Их легко выполнять. Они понятны
- 25. Каковы преимущества независимого самостоятельного тест-кейса? Его легко и просто выполнить. Такие тесты могут работать даже после
- 26. Позитивные тесты проверяют, что приложение делает то, на что оно рассчитано (т.е. такие тесты используют корректные
- 27. Идентификатор теста (id) Связанное с тестом требование (related requirement) Краткое заглавие теста (title) Модуль и подмодуль
- 28. Документирование тестов
- 29. Начинайте с простых очевидных тестов. Затем переходите к более сложным тестам. Помните о граничных условиях. Если
- 30. Используйте активный залог: («open», «paste», «click»). В русском языке используйте безличную форму: «открыть» (вместо «откройте») Описывайте
- 31. Обладает высокой вероятностью обнаружения ошибки. Не выполняет ненужных действий. Не является избыточным по отношению к другим
- 32. Тестовый набор – набор тестов (тест-кейсов), собранных в последовательность для достижения некоторой цели. Хороший тестовый сценарий
- 33. Пишите набор для отдельной части приложения. Пишите отдельно набор для Smoke и Critical Path тестов. Постепенно
- 34. Copy-paste. Если по ходу разработки тестов возникают вопросы, пишите их прямо в документ с тестами, помечая
- 35. Сбор информации (требования, мок-апы и т. д.) Разделение приложения на модули Написание чек-листов Написание тест-кейсов Шаги
- 36. Начинайте как можно раньше, ещё до выхода первого билда. Разбивайте приложение на отдельные части/модули. Для каждой
- 37. Простые позитивные. Простые негативные. Сложные позитивные. Сложные негативные. Последовательность разработки и выполнения тестов
- 38. Что такое notepad? Какие функции для него важны? Что еще? Учимся составлять первый тест-кейс
- 39. Итак, вот наш Smoke test Перенесём его в шаблон для разработки тестов. Учимся составлять первый тест-кейс
- 40. Фактически, это – чек-лист. И сами пункты грамотно сформированного чек-листа – готовые заголовки тест-кейсов. Учимся составлять
- 41. Когда мы распишем наши тесты по правилам, Smoke Test примет следующий вид: Учимся составлять первый тест-кейс
- 42. Аналогичным образом начинаем и продолжаем работать с тестом критического пути: Учимся составлять первый тест-кейс
- 43. Детализируем чек-лист: Учимся составлять первый тест-кейс
- 44. Продолжаем детализацию до тех пор, пока не получим логичный и достаточный набор тестов. После этого переносим
- 46. Скачать презентацию