Документ представляет собой обширное введение в тестирование программного обеспечения, описывающее его цели, задачи и основные принципы. В нем рассматриваются этапы тестирования, роли тестировщика и QA-инженера, а также различные методы и подходы к тестированию. Также поднимается важность качественного тестирования для предотвращения ошибок и соответствия программного обеспечения ожиданиям пользователей.

1. Тестирование ПО

2. Введение в тестирование
 Что такое тестирование программного обеспечения?
 Проверка соответствия между реальным и ожидаемым поведением программы
 Процесс выполнения программы с целью нахождения ошибок
 Техническое исследование программы для получения информации о её
качестве с точки зрения производителя и потребителя

3. Необходимость тестирования
 высокие требования в области качества
 спецификаций производителя
 спецификаций потребителя
 низкое качество ПО ведет к:
 потере денег
 потере времени
 потере репутации
 даже к летальному исходу

4. Стоимости ошибки на каждой из
стадии разработки
Не выявленная и не решенная
проблема при использовании
программного обеспечения может
быть в 40-100 раз дороже при
решении чем выявленная проблема
на ранней стадии во время
разработки ПО

5. Необходимость тестирования
 создан Atomic Energy of Canada
Limited в 1982
 5 летальных исхода (1985-1987)
Therac 25

6. Цели и задачи тестирования
 Выявление дефектов на различных этапах жизненного цикла приложения
 Проверка того, что выявленный дефект был успешно устранён
 Выяснение того, что изменения, связанные с устранением выявленного
дефекта, не привнесли новых дефектов в систему

7. Базовая терминология тестирования
 Error (ошибка)
 Bug/Defect (Баг/Дефект)
 Failure (Отказ)
 Requirement (требование)
 Test Case (тестовый случай)
 Test Data (Тестовые Данные)

8. 7 принципов тестирования
1. Тестирование показывает наличие дефектов
(Testing shows the presence of bugs)
“Тестирование может показать наличие дефектов в программе, но не доказать их
отсутствие.”
2. Исчерпывающее тестирование невозможно
(Exhaustive testing is impossible)
“Невозможно тестировать все комбинаций пользовательского ввода и состояний
системы”
3. Раннее тестирование
(Early testing)
“Тестирование должно начинаться как можно раньше в жизненном цикле
разработки программного обеспечения”
4. Скопление дефектов
(Defect clustering)
“80% проблем содержатся в 20% модулей”

9. 7 принципов тестирования
5. Парадокс пестицида
(The pesticide paradox)
“ Одни и те же тесты находят все меньше новых ошибок “
6. Тестирование зависит от контекста
(Testing is context dependent)
“Выбор методологии, техники и типа тестирования будет напрямую зависеть от
природы самой программы”
7. Заблуждение об отсутствии ошибок
(Absence of errors fallacy)
“Нахождение и исправление дефектов будут не важны если система не будет
удовлетворять ожиданиям и потребностям пользователя”

10. Уровни Тестирования
 Component/Unit Testing (компонентное или модульное тестирование)
“тестировании различных модулей приложения, которые могут быть
протестированы по отдельности в силу своей автономности”
 Integration Testing (интеграционное тестирование)
“представляет собой исследование связей между компонентами приложения”
 System Testing (системное тестирование)
“направлено на исследование функциональных и нефункциональных особенностей
системы в целом”
 Acceptance Testing (приёмочное тестирование)
“соответствует ли система приёмочно/сдаточным критериям”
 Alpha Testing - имитацию реального использования продукта штатными разработчиками
либо командой тестировщиков
 Beta Testing - предполагает привлечение добровольцев из числа обычных будущих
пользователей продукта

11. Тестировщик и QA инженер
 Quality Management (управления качеством)
 Quality Control (контроль качества)
“ставит основной акцент на поиске дефектов, которые уже были внесены в
продукт”
 Quality Assurance (обеспечение качества)
предотвращение появления дефектов

12. Кто такой тестировщик?
“в обязанности тестировщика входит поиск дефектов ПО, а также, отчасти,
выявление их этимологии с формальным указанием условий возникновения
каждой ошибки”
 Testing (Тестированье) – это средство обнаружения ошибок
 Debugging (Отладка) – является средством поиска и устранения причин
уже обнаруженных ошибок

13. Кто такой тестировщик?
 тестировщик участвует в приёмке-сдаче готового продукта
 опыт разработки программного обеспечения - совершенно не обязательно
 тестирование и разработка – суть два различных процесса

14. Цели и задачи тестировщика
“Задача тестировщика состоит в том, чтобы поставлять разработчикам
информацию о соответствии продукта заданным спецификациям”
 обнаружениые дефектов кодирования
 выявление недостатков производительности системы
 контроль исправления, выявленных в процессе тестирования дефектов
…..

15. Кто такой QA инженер?
 Quality Assurance (обеспечение качества) - разработка и внедрение
превентивных мер по недопущению появления дефектов и составляет
основную задачу обеспечения качества
 Quality Assurance Engineer (QA инженер) ,задачей которого является
повышения качества процесса, с одной стороны, и продукта – с другой
 Process Engineering – PE (разработка процессов), поиск путей модернизации
процесса, с целью повышения качества производимой продукции;
 Software Quality Assurance (обеспечение качества), в основном состоящее в
удостоверении того, что разработка продукта соответствует определённым на
предприятии процессам (process consistency)

16. Цели и задачи QA (обеспечение качества)
 Process Engineering (Разработка процессов) – изучение опыта организации
процесса на производстве с целью его совершенствования и разработки
новых процессов, обеспечивающих производство качественного продукта
 Process Improvement (постоянное совершенствование процессов
производства), которое, как правило, выражается в предотвращении
дефектов (defects prevention), носящего форму изучения дефектов с
целью их предотвращения, а также опыта прошлых проектов с целью
поиска путей усовершенствования процессов разработки
 Process Consistency (удостоверение соответствия разработки продукта
определённым процессам)

17. Цели и задачи QA инженера
 разработка эффективных процессов для проектов
 контроль и обеспечение корректного использования процессов
 выбор эффективных методов и способов тестирования
 подбор и использование эффективных методов предотвращения дефектов

18. Цели и задачи тестировщика и QA инженера
 Основная цель тестировщиков и QA инженеров одна – обеспечение
качества конечного продукта
 QA инженер отвечает за обеспечение качества, а тестировщик – за его
контроль
 QA инженер и тестировщик работают на различных уровнях процесса, а
также в различных зонах ответственности

19. Тестирование в контексте процесса
разработки ПО
Каскадная модель
(Waterfall Model)
 Анализ требований
(Requirements Analysis)
 Проектирование программного
обеспечения
(Software Design)
 Реализация (Implementation)
 Тестирование программного
обеспечения (Testing)
 Установка (Deployment)
 Эксплуатация и поддержка
 Сопровождение (Maintenance)

20. Тестирование в контексте процесса
разработки ПО
V-образная модель
(V-model)
 Анализ требований потребителя -
приёмочное тестирование
 Анализ требований производителя -
системное тестирование
 Высокоуровневый проектирование -
интеграционное тестирование
 Детализированная проектирование -
компонентное или модульное
тестирование
 Разработка программного кода

21. Жизненный цикл тестирования ПО
(Fundamental Test Process)

22. Жизненный цикл тестирования ПО
 Анализ требований – На фазе анализа требований тестировщик должен
получить требования к тестируемому продукту и сформировать из них
«матрицу требований», это позволит в будущем следить, чтобы программа
оставалась такой, какой хочет видеть ее клиент;
 Анализ дизайна проекта - какой подход к тестированию будет
использоваться, важно для автоматизации тестов (automation testing)
 Планирование тестирования - это этап, на котором производиться
планирование тестов, тестировщики планируют как они будут проверять
требования предъявленные к продукту
 определение целей тестирования
 спецификация тестовых мероприятий

23. Жизненный цикл тестирования ПО
 Разработка тестов - разработка тестов ведется параллельно разработке
программы, как только разрабатывается часть программы, к ней
разрабатывают тест, который будет производить тестирование этой части
программы
 Выполнение тестов - выполнение тестов производиться постоянно в
процессе разработки продукта, для более раннего отслеживания дефектов
 Написание отчетов - тестировщики после выполнения тестирования
должны написать отчеты о найденных дефектах, и частях приложения
которые работают правильно
 Повторная проверка дефектов - когда отчеты были написаны и переданы
разработчикам, их задача исправить найденные дефекты приложения,
после исправления все приложение должно пройти повторную проверку
тестировщиками

24. Типы тестирования
 Функциональные виды
 функциональное тестирование (functional testing) - направлено на проверку
корректности выполняемых системой функций и может присутствовать на всех
уровнях тестирования;
 тестирование безопасности (security and access control testing) направлено
на проверку безопасности системы, а также оценку целостности подхода к
защите приложения от несанкционированного доступа и защите
конфиденциальных данных;
 тестирование взаимодействия (interoperability testing) - направлено на
оценку возможности приложения взаимодействовать с внешними
компонентами или системами, а также включает тестирование совместимости
(compatibility testing) и интеграционное тестирование (integration testing)

25. Типы тестирования
 Нефункциональные виды
 тестирование удобства использования (usability testing) связано с оценкой
степени удобства использования, а также понятности и привлекательности
пользовательского интерфейса приложения;
 тестирования производительности
 Performance and Load testing - нагрузка в пределах нормы
 Stress Testing (стрессовое тестирование) - нагрузки превышающей штатную
 Stability/Reliability Testing - нормальной нагрузки при длительном
функционировании
 volume testing (объёмное тестирование) - используется для оценки
поведения системы при условии увеличения объёма данных

26. Виды тестирования связанные с изменениями
 Регрессионное тестирование (regression testing) - предназначено для
проверки осуществлённых в системе изменений, а так же на
подтверждение того, что существовавшая до изменения ункциональность,
работает также как и прежде;
 Повторная проверка дефектов (retesting) - после исправления бага нужно
пройти повторную проверку
 дымовое тестирование (smoke testing) направлено на обзорную проверку
всех компонентов приложения на предмет работоспособности, а также на
выявление грубых дефектов, наличие которых можно определить, так
сказать, «невооружённым глазом»;

27. Подходы к тестированию
 Exploratory (ознакомительное) - одновременное обучение, дизайн теста и
выполнение теста
 Scripted (по сценарию) - набор инструкций, которые будут выполняться в
тестируемой системе, чтобы проверить, что система функционирует
должным образом
 Manual (ручное) - Ручное тестирование производиться человеком
 Automated (автоматическое) - автоматическое тестирование
производиться ПО

28. Подходы к тестированию
 Black Box (черный ящик) - тестировщик не имеет доступа к исходному
коду
 White Box (белый ящик) - позволяет тестировщику использовать исходный
код приложения (создание unit-test)
 Positive (Позитивное) - тестировщик играет роль «правильного»
пользователя (happy flow)
 Negative (негативное) - тестировщик должен играть роль хакера, который
пытается поломать программу, стоит приложить все возможные усилия
для проверки программы в самых не благоприятных условиях

29. Unit Test Example

30. Unit Test Example 2

31. Test Case (Тестовый случай)
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,
конкретных условий и параметров, необходимых для проверки реализации
тестируемой функции или её части
 Название теста
 Предусловия
 Шаги + Ожидаемый результат
 Фактический результат

32. Test Case Example

33. Лабораторная работа 1
Описать тест кейсы для проверки Регистраций на сайте ‘https://www.rambler.ru/’
 1 positive test case
 1 negative test case

34. Ошибки пользовательского интерфейса
Задача разработчиков сделать интерфейс
«дружественным» (user-friendly
interface) а тестировщики должны
проверить действительно ли
дружественный этот интерфейс
 Организация интерфейса - стоит
следить за тем, чтобы интерфейс
логически был разделен на группы
 Пропущенные команды – это дефект
интерфейса, когда в приложении
явно не хватает какой-то функции,
или просто не понятно как
пользоваться этой функцией

35. Ошибки пользовательского интерфейса
 Производительность – очень плохо,
когда пользователь видит как программа
с задержкой реагирует на его действия
 Выходные данные – выходными
данными программы называют все
результаты работы рограммы, будь то
информация, экспортированная в PDF
файл, или просто вывод в label на
клиентскую область окна
 Обработка ошибок –хорошо, когда в
программе невозникает ошибок или
когда они возникают, программа сама в
силах их исправить, но всех ошибок не
предусмотреть, поэтому очень важно
показывать подробный отчет об ошибке,
желательно выводить на экран
информацию о том, как исправить
возникшую ошибку.

36. Другие ошибки
 Ошибки граничных условий - нет проверки на формат входящих данных
 Ошибки документации
 Ошибки тестирования

37. Дружественный интерфейс
 Доступность - все элементы
управления будут понятны
максимальному количеству
пользователей
 Минимализм. В интерфейсе не
должно быть ничеголишнего,
отличным примером может
служить регулятор громкости в
windows.
 Уверенность. Очень важно
чтобы все элементы управления
просто «кричали» о том что они
делают

38. Лабораторная работа 2
Описать тест кейсы на сайте:
‘euzbor.md’
‘pneu.md’
 3 positive test case
 7 negative test case

39. Примеры ошибок

40. Вопросы ?