
- •1. Роль и место тестирования в жизненном цикле разработки по.
- •Проектирование
- •Тестирование
- •2. Тестирование методами “черного, белого и серого ящика”
- •3. Понятие «качество программного продукта». Экономические и психологические аспекты тестирования.
- •4. Основные составляющие «быстрого тестирования».
- •5. Каскадная, V-образная и спиралевидная модели разработки по.
- •6. Процесс разработки требований. Свойства и категории требований.
- •8. Модульное тестирование и его методы
- •9. Структурное тестирование.
- •If_then case
- •10. Интеграционное тестирование.
- •Заключается в том, что тестирование начинается с головного модуля (a). Тогда возникает проблема передачи данных в головной модуль. Решение проблемы:
- •11. Особенности объектно-ориентированного тестирования.
- •12. Тестирование классов.
- •13. Автоматизация модульного тестирования.
- •14. Тестовые случаи и их свойства. Процесс разработки тестовых случаев.
- •15. Сходства и различия тестовых случаев для приемочного, критического и углубленного тестов.
- •16. Эквивалентирование и анализ граничных значений.
- •17. Тестовый план. Тестовая стратегия.
- •18. Статическое тестирование, его виды.
- •19. Процесс динамического тестирования.
- •20. Ошибка. Свойства ошибки.
- •21. Правила составления отчета об ошибках.
- •22. Жизненный цикл ошибки. Системы документирования ошибок.
- •23. Специфика и ограничения тестирования Web-приложений.
- •24. Приемочный тест. Критерии непрохождения приемочного теста.
- •25. Критическое тестирование. Углубленное тестирование.
- •26. Использование контрольных перечней в углубленном тестировании.
- •27. Теория модели cmm
- •28. Автоматизированное тестирование, его этапы, преимущества и недостатки.
- •Достоинства автоматизированного тестирования.
- •Необоснованные ожидания от авто-го тестирования.
- •29. Метод функциональной декомпозиции
- •30. Методы Data-driven, Keyword-driven.
8. Модульное тестирование и его методы
Юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы. Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже написанных и оттестированных местах программы, а также облегчает локализацию и устранение таких ошибок.
Модуль – ограниченная часть кода программы с одной точкой входа и одной точкой выхода, выполняющая одну и только одну первичную функцию.
Методы модульного тестирования:
по степени автоматизации: ручные, автоматизированные.
по форме представления модуля: тест-е программ, написанных на языке программирования; -//- на машинном коде.
по компонентам программы, на которое направлено тестирование: тест-е структуры программы; тест-е преобразования данных.
по запускаемости модуля: динамическое, статическое.
Последовательность тестирования модуля:
обзор кода
тестирование структуры (диаграммы Чейпина, диаграммы Неси-Шнайдермана, ориентированные графы Мак-Кейна).
тестирование обработки данных
функциональное тестирование
Цикломатическое число графа (метрический показатель сложности программы): G=R(ребра) – V(вершины) + 2 G>=15 недопустимо.
Преимущества:
Поощрение изменений
Юнит-тестирование позже позволяет программистам проводить рефакторинг, будучи уверенными, что модуль по-прежнему работает корректно (регрессионное тестирование). Это поощряет программистов к изменениям кода, поскольку достаточно легко проверить, что код работает и после изменений.
Упрощение интеграции
Юнит-тестирование помогает устранить сомнения по поводу отдельных модулей и может быть использовано для подхода к тестированию «снизу вверх»: сначала тестируются отдельные части программы, затем программа в целом.
Документирование кода
Юнит-тесты можно рассматривать как «живой документ» для тестируемого класса. Клиенты, которые не знают, как использовать данный класс, могут использовать юнит-тест в качестве примера.
Отделение интерфейса от реализации
Поскольку некоторые классы могут использовать другие классы, тестирование отдельного класса часто распространяется на связанные с ним. Например, класс пользуется базой данных; в ходе написания теста программист обнаруживает, что тесту приходится взаимодействовать с базой. Это ошибка, поскольку тест не должен выходить за границу класса. В результате разработчик абстрагируется от соединения с базой данных и реализует этот интерфейс, используя свой собственный mock-объект. Это приводит к менее связанному коду, минимизируя зависимости в системе.
Этот тип тестирования обычно выполняется программистами.
Этапы модульного тестирования.
Планирование модульного тестирования;
Разработка тестов;
Формирование отладочных заданий;
Процесс тестирования;
Обработка результатов тестирования;
9. Структурное тестирование.
Изучение структуры программы. Как правило, тестирование структуры модуля происходит с помощью графического отображения модуля. Например, диаграммы Чейпина, диаграммы Насси-Шнайдермана, ориентированные графы Мак-Кейна.
В основу принято понятие, что узел – оператор, ребро – связь между узлами (операторами).