Similar presentations:
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 54 июня 1996 года Ариане 5 взорвалась
через 40 секунд после запуска
Разрушенная ракета и ее груз были
оценены в 400 миллионов долларов
было вызвано при выполнении
преобразования данных из 64разрядного числа в 16-разрядное
целое число
8. Mars Climate Orbiter
338-килограммовый робот-спутник,запущенный НАСА в 1998 году
он должен был изучить климат
Марса, изменения атмосферы и
поверхности
Не удалось рассчитать правильную
орбиту Марса
не удалось преобразовать фунт
силы / с (фунты) в ньютон-секунды
Он должен был вращаться вокруг
Марса на расстоянии ~ 227 км. Но на
самом он опустился на 57 км.
9. Therac 25
Atomic Energy of Canada Limited in1982
как минимум 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 ControlTest 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
Шаги для воспроизведения