SOFTWARE TESTING Manual Testing 1
Программа Курса
Преимущества курса
Введение в тестирование
Необходимость тестирования
Стоимости ошибки на каждой из стадии разработки
Mars Climate Orbiter
Therac 25
Цели и задачи тестирования
Базовая терминология тестирования
7 принципов тестирования
7 принципов тестирования
Test Levels (Уровни Тестирования)
Тестирование в контексте процесса разработки ПО
Fundamental Test Process
Testing Types (Типы тестирования)
Non-Functional Testing
Testing Methods
Testing Methods
Testing Methods
Test Case (Тестовый случай)
Test Case Example (Positive)
Test Case Example (Negative)
Test Case Example
Exercise
User Interface Bugs
User Interface Bugs
Defect (Bug) Report
Defect (Bug) Report
Defect (Bug) Report
Failed Test Case
Defect (Bug) Report Example
1.81M
Category: programmingprogramming

Software testing. Manual testing

1. SOFTWARE TESTING Manual Testing 1

2. Программа Курса

Manual Testing : ~ 3-4 недели
Introduction to Data Bases : ~ 3-4 недели
JAVA(Object-Oriented programming) : ~ 2 месяца
Automation Testing : ~ 2 месяца

3. Преимущества курса

Курс длится всего 6 месяцев, после чего:
Вы можете стать Manual Software Tester
Вы можете стать Automation Software Tester
У вас есть знания в области программирования (JAVA)
Вы можете пройти сертификацию ISTQB
(The Certified Tester Foundation Level in Software Testing)
большинство студентов курса сейчас работают в ITкомпаниях (>80%)

4. Введение в тестирование

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

5. Необходимость тестирования

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

6. Стоимости ошибки на каждой из стадии разработки

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

7.

Ariane 5
4 июня 1996 года Ариане 5 взорвалась
через 40 секунд после запуска
Разрушенная ракета и ее груз были
оценены в 400 миллионов долларов
было вызвано при выполнении
преобразования данных из 64разрядного числа в 16-разрядное
целое число

8. Mars Climate Orbiter

338-килограммовый робот-спутник,
запущенный НАСА в 1998 году
он должен был изучить климат
Марса, изменения атмосферы и
поверхности
Не удалось рассчитать правильную
орбиту Марса
не удалось преобразовать фунт
силы / с (фунты) в ньютон-секунды
Он должен был вращаться вокруг
Марса на расстоянии ~ 227 км. Но на
самом он опустился на 57 км.

9. Therac 25

Atomic Energy of Canada Limited in
1982
как минимум 5 смертельных
случаев 1987-1989
программное обеспечение было
разработано так, чтобы было
практически невозможно
протестировать его
автоматическим способом
плохие методы проектирования и
разработки программного
обеспечения

10. Цели и задачи тестирования

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

11. Базовая терминология тестирования

Error (ошибка) - ошибка, допущенная человеком
Bug/Defect (Баг/Дефект) - oшибка в коде
Failure (Отказ) - если выполняется Дефект, это может привести к сбою
системы
Requirement (требование) - набор условий / спецификаций того, что
должно делать программное обеспечение и как оно должно себя вести
Test Case (тестовый случай) - сценарий с исполняемыми шагами и
ожидаемыми результатами
Test Suite - набор тестовых случаев, которые относятся к общей
функциональности
Test Data (Тестовые Данные) - конкретные данные, которые используются
в тестовых случаях
Test Plan (План тестирования) - документ, определяющий цели
тестирования и его деятельность

12. 7 принципов тестирования

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

13. 7 принципов тестирования

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

14. Test Levels (Уровни Тестирования)

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

15. Тестирование в контексте процесса разработки ПО

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

16. Fundamental Test Process

Test Planning and Control
Test Analysis and Design
Test implementation and Execution
Evaluating Exit Criteria and Reporting
Test Closure Activities

17. Testing Types (Типы тестирования)

Functional Testing – тестирование системы для определения того,
насколько хорошо система выполняет свои функции на основе
функциональных требований
(“what” the system should do?/ что делает программное обеспечение?)
Non-Functional Testing – тестирование системы на основе нефункциональных
требований
(“how well” the system behaves/как работает программное обеспечение?)

18. Non-Functional Testing

Performance Testing - Тестирование производительности
Security Testing - Тестирование безопасности
Usability Testing - связано с оценкой степени удобства использования, а также
понятности и привлекательности пользовательского интерфейса приложения
Load Testing - нагрузка в пределах нормы
Stress testing - нагрузки превышающей штатную
Accessibility testing ..
и т.д.

19. Testing Methods

Black-Box Testing – тестировщик не имеет доступа к
исходному коду
White-Box Testing – позволяет тестировщику использовать исходный
код приложения (создание unit-test)

20. Testing Methods

Виды тестирования связанные с изменениями:
Regression Testing – предназначено для проверки осуществлённых в системе
изменений, а так же на подтверждение того, что существовавшая до изменения
ункциональность, работает также как и прежде;
Retesting – Повторная проверка дефектов, после исправления бага нужно пройти
повторную проверку

21. Testing Methods

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

22. Test Case (Тестовый случай)

Test Case - набор шагов и ожидаемых результатов, выполняемых тестером для
проверки функциональности программного обеспечения
Название теста
Предусловия
Шаги + Ожидаемый результат

23. Test Case Example (Positive)

24. Test Case Example (Negative)

25. Test Case Example

26. Exercise

Напишите 1 Test Case, чтобы проверить следующие требования:
System Under Test(SUT): https://edition.cnn.com/
Функциональность: элементы в меню заголовка связанные с регионами
Requirements(Требования):
1. Ссылка “World”, расположенная в меню заголовка страницы, при нажатии должна открыть
меню “Regions”
2. Следующие ссылки: “U.S.” , “Africa” , “Americas”, “Asia”, “Australia”, “China”, “Europe”,
“Middle East”, должны перенаправить пользователя на соответствующие страницы,
имеющие те же заголовки, что и ссылки.

27. User Interface Bugs

28. User Interface Bugs

29. Defect (Bug) Report

Objectives:
Provide developers and other parties with information about any adverse event that
occurred
Предоставлять разработчикам и другим сторонам информацию о любых
неблагоприятных событиях, которые произошли
Provide test managers a means of tracking the quality of the work product and the
impact on the testing
Предоставление менеджерам по тестированию, средства отслеживания качества
рабочего продукта и влияния на тестирование
Provide ideas for development and test process improvement
Предоставлять идеи для развития и улучшения процесса тестирования

30. Defect (Bug) Report

A defect report usually includes:
Отчет о дефектах обычно включает:
An identifier
Идентификатор
A title and a short summary of the defect being reported
Заголовок и краткое описание обнаруженного дефекта
Date of the defect report, issuing organization, and author
Дата отчета о дефекте, организация-эмитент и автор
The development lifecycle phase(s) in which the defect was observed
Фаза (ы) жизненного цикла разработки, в которой обнаружен дефект

31. Defect (Bug) Report

A defect report usually includes:
logs, database dumps screenshots, or recordings (if found during test
execution)
журналы, скриншоты дампов базы данных или записи (если они
обнаружены во время выполнения теста)
Expected and actual results
Ожидаемые и фактические результаты
Scope or degree of impact (severity) of the defect
Степень или степень воздействия (серьезности) дефекта
Urgency/priority to fix
Срочность / приоритет для исправления
State of the defect report
Состояние отчета о дефекте
Steps to reproduce
Шаги для воспроизведения

32. Failed Test Case

33. Defect (Bug) Report Example

English     Русский Rules