2. Введение в тестирование
Что такое тестирование программного обеспечения?
Проверка соответствия между реальным и ожидаемым поведением программы
Процесс выполнения программы с целью нахождения ошибок
Техническое исследование программы для получения информации о её
качестве с точки зрения производителя и потребителя
3. Необходимость тестирования
высокие требования в области качества
спецификаций производителя
спецификаций потребителя
низкое качество ПО ведет к:
потере денег
потере времени
потере репутации
даже к летальному исходу
4. Стоимости ошибки на каждой из
стадии разработки
Не выявленная и не решенная
проблема при использовании
программного обеспечения может
быть в 40-100 раз дороже при
решении чем выявленная проблема
на ранней стадии во время
разработки ПО
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)
Анализ требований потребителя -
приёмочное тестирование
Анализ требований производителя -
системное тестирование
Высокоуровневый проектирование -
интеграционное тестирование
Детализированная проектирование -
компонентное или модульное
тестирование
Разработка программного кода
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 (негативное) - тестировщик должен играть роль хакера, который
пытается поломать программу, стоит приложить все возможные усилия
для проверки программы в самых не благоприятных условиях
31. Test Case (Тестовый случай)
Тестовый случай (Test Case) - это артефакт, описывающий совокупность шагов,
конкретных условий и параметров, необходимых для проверки реализации
тестируемой функции или её части
Название теста
Предусловия
Шаги + Ожидаемый результат
Фактический результат
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
