Содержание
- 2. Test Design. Тест дизайн – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые
- 3. Test Design. План работы. Анализ имеющихся проектных артефактов: документация (спецификации, требования, планы), модели, исполняемый код и
- 4. Test Design. Roles. Тест аналитик - определяет "ЧТО тестировать?" Тест дизайнер - определяет "КАК тестировать?" Попросту
- 5. Тест аналитик. Исследует продукт; Составляет логическую карту продукта; Разбивает программный продукт на основные части; Расставляет приоритеты
- 6. Тест аналитик. Исследование программного продукта. Понимание цели создания продукта; Какими способами цель должна достигаться; Какие и
- 7. Тест аналитик. Логическая карта продукта. Интеллект - карта - техника представления любого процесса, события, мысли или
- 8. Тест аналитик. Логическая карта продукта.
- 9. Интеллект - карта. Для чего? Цельный взгляд на весь проект дает возможность отследить логические связи внутри
- 10. Приоритезация. Требования клиента; Степень риска; Сложность системы; Временные ограничения.
- 11. Тест дизайнер. Человек, который должен выстроить процесс тестирования всех важнейших частей продукта, используя минимально возможное количество
- 12. Test Design. гипотеза тест, проверяющий гипотезу разработка теста Каждый тест либо подтверждает, либо опровергает нашу гипотезу.
- 13. Test Design.
- 14. Test Design. Можно провести аналогию с тестированием программного продукта. Гипотезы, которые мы можем проверять в этом
- 15. Test Design. И возможные тесты по проверке будут такими: Проверить работу одной функции; Проверить работу другой
- 16. Test Design. Цели. Главные цели: Придумать тесты, которые обнаружат наиболее серьезные ошибки продукта. Да, мы можем
- 17. Test Design. Необходимые навыки. Умение разделять систему на составляющие (делать декомпозицию). То есть, нужно уметь видеть
- 18. Test Design Technics. Многие тестируют и пишут тестовые случаи (test cases), но не многие пользуются специальными
- 19. Test Design Technics. Главные. 1. Эквивалентное разделение (Equivalence Partitioning - EP). 2. Анализ граничных значений (Boundary
- 20. Test Design Technics. Главные. 6. Таблица принятия решений (Decision table). 7. Тестирование состояний и переходов (State
- 21. Test Design Technics. Эквивалентное разделение. Тестовые данные разбиваются на определенные классы допустимых значений. В рамках каждого
- 22. Test Design Technics. Эквивалентное разделение. Алгоритм. 1. Определить классы эквивалентности. 2. Выбрать одного представителя от каждого
- 23. Test Design Technics. Эквивалентное разделение. Представим, что мы тестируем модуль для рекрутера, который проверяет возможность принятия
- 24. Test Design Technics. Эквивалентное разделение. Класс эквивалентности NO: 0 - 16 лет; Класс эквивалентности PART: 16
- 25. Test Design Technics. Эквивалентное разделение. Таким образом у нас остается 4 позитивных тест - кейса из
- 26. Test Design Technics. Анализ граничных значений. В отличии от эквивалентного разбиения, которое ориентировано на покрытие тестами,
- 27. Test Design Technics. Анализ граничных значений. Эта техника основана на том факте, что одним из самых
- 28. Test Design Technics. Анализ граничных значений. Вернемся к примеру, рассмотренному в технике “Классов эквивалентности”: 0 -
- 29. Test Design Technics. Анализ граничных значений. Для правильного применения техники, необходимо записать условие по - другому:
- 30. Test Design Technics. Анализ граничных значений. Таким образом набор значений, по которым будут составлены тесты будет
- 31. Test Design Technics. Предугадывание ошибки. Тестировщик использует свои знания системы и способность к интерпретации спецификации на
- 32. Test Design Technics. Исчерпывающее тестирование. Крайний случай. Тестировщик должен проверить все возможные комбинации входных значений, и
- 33. Test Design Technics. Причина/Следствие. Ввод комбинаций условий (причин), для получения ответа от системы (следствие). Например, вы
- 34. Test Design Technics. Таблица принятия решений. Это удобный инструмент для фиксирования требований и описания функциональности приложения.
- 35. Test Design Technics. Таблица принятия решений. Таблицы принятия решений описывают логику приложения основываясь на условиях системы,
- 36. Таблица принятия решений. Пример.
- 37. Таблица принятия решений. Пример. Предоставление скидки в зависимости от комбинации условий будет нашим действием в приложении.
- 38. Test Design Technics. Таблица состояний и переходов. Система переходит в то или иное состояние в зависимости
- 39. Таблица состояний и переходов. Пример.
- 40. Таблица состояний и переходов. Состояние (представлено в виде круга); Переход (Представлен в виде стрелки); Событие (Представлено
- 41. Test Design Technics. Метод парного тестирования. Основан на следующей идее: подавляющее большинство багов, выявляются тестами, проверяющими
- 42. Test Design Technics. Метод парного тестирования.
- 43. Test Design Technics. Другие Функциональное тестирование (это проверка всех функций продукта, одна за одной) Тестирование на
- 44. Домашнее задание https://habr.com/ru/company/infopulse/blog/261061/ Создать таблицу состояний для Авторизации в приват24 web версии или моб версии
- 46. Скачать презентацию