Сложности performance-тестирования / Андрей Акиньшин (JetBrains)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3009.html
Если вас волнует производительность вашего приложения, то рано или поздно у вас могут появиться мысли о том, чтобы написать тесты на эту самую производительность. К сожалению, внедрить такие тесты в процесс разработки намного сложнее, чем может показаться на первый взгляд.
В этом докладе мы будем разговаривать про типичные проблемы тестирования производительности и возможные подходы к их решению.
Сложности performance-тестирования / Андрей Акиньшин (JetBrains)Ontico
HighLoad++ 2017
Зал «Пекин+Шанхай», 7 ноября, 11:00
Тезисы:
http://www.highload.ru/2017/abstracts/3009.html
Если вас волнует производительность вашего приложения, то рано или поздно у вас могут появиться мысли о том, чтобы написать тесты на эту самую производительность. К сожалению, внедрить такие тесты в процесс разработки намного сложнее, чем может показаться на первый взгляд.
В этом докладе мы будем разговаривать про типичные проблемы тестирования производительности и возможные подходы к их решению.
Why I do not like to be a tester in Agile project?SQALab
The document discusses some of the challenges of being a tester in an Agile project. It notes that while Agile teams are more effective at delivering functionality, they tend to have lower quality than traditional teams. It suggests that testers can help improve quality by taking a "whole team approach" where they work closely with developers and business representatives. This includes collaborating at daily stand-up meetings to ensure quality across all test levels. However, the document also points out some potential issues, noting that unit tests alone have limited effectiveness at finding bugs, and independent testing by a separate team may be needed to achieve high bug detection rates.
How to manoeuvre as test/QA responsible in agile teams to get the "right" pro...SQALab
Knud Hangaard presented on agile development at Saxo Bank and how testers can maneuver to achieve the right quality. He discussed how Saxo Bank uses Scrum, Kanban and Prince2 methodologies in development. Testers focus on risk-based testing and time-boxed cycles. Key lessons included having clear and flexible processes, effective communication, and adopting a risk-focused mindset to test the highest priority areas first.
The document discusses how QA at Just Eat has evolved over time, with a focus on increased automation and exploratory testing approaches. It notes that engineering processes are different now, with automation being a big recent change for QA. It encourages teams to be efficient, explore issues, take exploration to alpha testing phases through events like bug bashes, and leverage crowdsourcing. The conclusion discusses how QA will continue to change, such as through new quality-as-a-service models, to achieve the benefits of both automation and manual testing.
This document discusses test automation strategies and tools used at Wikimedia. It covers topics like communication, maintainability, browser automation, code visibility, continuous integration, test results, code reuse, speeding up tests, how to get involved, local development environments, and reasons for using Ruby. Key tools mentioned include Cucumber, page object pattern, Selenium, Sauce Labs, Git, Gerrit, GitHub, Jenkins, Bugzilla, parallel_tests, RVM, Bundler, and MediaWiki-Vagrant. The document provides an overview of Wikimedia's test automation approach across 11 pages.
1. The document describes a presentation about using testing techniques like equivalence partitioning, boundary value analysis, and decision tables to select a partner, representing the selection process as a type of testing.
2. It provides examples of how to model the partner selection process using these techniques, such as creating equivalence classes for attributes like age, gender, and interests.
3. The presentation suggests exploratory testing may be the most appropriate technique to use in real-life partner selection, as requirements can change, and despair and changing options are natural parts of the process.
От архитектуры приложения до приемочных автоматических тестов, или тестирован...SQALab
This document discusses software architecture testing. It begins by introducing the author and their background. It then defines software architecture and discusses how it is formed based on business needs, users, and systems. Quality attributes, also called non-functional requirements, are introduced along with examples. Acceptance criteria are discussed and an example is provided using Gherkin syntax. The document outlines a process for defining acceptance tests including gathering quality attributes, generating scenarios, breaking scenarios into steps, defining steps in a quality criteria language, and generating test stubs.
Reversed Test Pyramid - Testing and dealing with Legacy CodeSQALab
The document discusses reversing the tests pyramid for legacy code by starting with end-to-end tests before introducing unit and integration tests through refactoring. It warns that end-to-end tests are long and costly to maintain, so the goal is to refactor code to introduce unit tests from the outside-in. Maintaining a low technical debt by refactoring during slack times can help pay it back over time. The key is to introduce changes gradually through a reversed tests pyramid rather than rewriting everything from scratch.
КГТУ Лекция 6: Обеспечение Качества Программного Обеспечения Iosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 6: Обзор методов создания тестовых сценариев
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Why I do not like to be a tester in Agile project?SQALab
The document discusses some of the challenges of being a tester in an Agile project. It notes that while Agile teams are more effective at delivering functionality, they tend to have lower quality than traditional teams. It suggests that testers can help improve quality by taking a "whole team approach" where they work closely with developers and business representatives. This includes collaborating at daily stand-up meetings to ensure quality across all test levels. However, the document also points out some potential issues, noting that unit tests alone have limited effectiveness at finding bugs, and independent testing by a separate team may be needed to achieve high bug detection rates.
How to manoeuvre as test/QA responsible in agile teams to get the "right" pro...SQALab
Knud Hangaard presented on agile development at Saxo Bank and how testers can maneuver to achieve the right quality. He discussed how Saxo Bank uses Scrum, Kanban and Prince2 methodologies in development. Testers focus on risk-based testing and time-boxed cycles. Key lessons included having clear and flexible processes, effective communication, and adopting a risk-focused mindset to test the highest priority areas first.
The document discusses how QA at Just Eat has evolved over time, with a focus on increased automation and exploratory testing approaches. It notes that engineering processes are different now, with automation being a big recent change for QA. It encourages teams to be efficient, explore issues, take exploration to alpha testing phases through events like bug bashes, and leverage crowdsourcing. The conclusion discusses how QA will continue to change, such as through new quality-as-a-service models, to achieve the benefits of both automation and manual testing.
This document discusses test automation strategies and tools used at Wikimedia. It covers topics like communication, maintainability, browser automation, code visibility, continuous integration, test results, code reuse, speeding up tests, how to get involved, local development environments, and reasons for using Ruby. Key tools mentioned include Cucumber, page object pattern, Selenium, Sauce Labs, Git, Gerrit, GitHub, Jenkins, Bugzilla, parallel_tests, RVM, Bundler, and MediaWiki-Vagrant. The document provides an overview of Wikimedia's test automation approach across 11 pages.
1. The document describes a presentation about using testing techniques like equivalence partitioning, boundary value analysis, and decision tables to select a partner, representing the selection process as a type of testing.
2. It provides examples of how to model the partner selection process using these techniques, such as creating equivalence classes for attributes like age, gender, and interests.
3. The presentation suggests exploratory testing may be the most appropriate technique to use in real-life partner selection, as requirements can change, and despair and changing options are natural parts of the process.
От архитектуры приложения до приемочных автоматических тестов, или тестирован...SQALab
This document discusses software architecture testing. It begins by introducing the author and their background. It then defines software architecture and discusses how it is formed based on business needs, users, and systems. Quality attributes, also called non-functional requirements, are introduced along with examples. Acceptance criteria are discussed and an example is provided using Gherkin syntax. The document outlines a process for defining acceptance tests including gathering quality attributes, generating scenarios, breaking scenarios into steps, defining steps in a quality criteria language, and generating test stubs.
Reversed Test Pyramid - Testing and dealing with Legacy CodeSQALab
The document discusses reversing the tests pyramid for legacy code by starting with end-to-end tests before introducing unit and integration tests through refactoring. It warns that end-to-end tests are long and costly to maintain, so the goal is to refactor code to introduce unit tests from the outside-in. Maintaining a low technical debt by refactoring during slack times can help pay it back over time. The key is to introduce changes gradually through a reversed tests pyramid rather than rewriting everything from scratch.
КГТУ Лекция 6: Обеспечение Качества Программного Обеспечения Iosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 6: Обзор методов создания тестовых сценариев
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Solit 2013, Эволюция тестирования на Selenium, Мычко Алексейsolit
Алексей Мычко, Минск, компания JazzTeam, Software Engineer (test automation)
«Эволюция тестирования на Selenium». Лекция и мастер-класс. Development секция. Для заинтересованных.
Для автоматизации web-приложений самым популярным средством является Selenium. Этот продукт дает возможность создавать как очень простые тесты, так и сложные тестовые фреймворки, позволяющие тестировать системы любой сложности.
В мастер-классе будет наглядно показано создание следующих видов тестов:
- с использование программ, генерирующих тесты по манипуляциям с браузером
- тесты в стиле процедурного программирования
- тесты в стиле объектно-ориентированного программирования
- тесты на DSL (Domain Specific Language) языке
В преддверии тренинга Тест-дизайн и все все все, который пройдет этой осенью в четырех городах (24-25 сентября в Харькове; 15-16 октября в Нижнем Новгороде; 29-30 октября в Москве; 18-19 ноября в Самаре) Александр Федоров решил лучше познакомиться со своей аудиторией и провести бесплатный вебинар Тест-дизайн «в цикле».
Любые процессы цикличны по своей природе, и разработка тестов не исключение. Тест-кейсы придумываются, создаются и используются на продукте и иногда в его последующих версиях. На разных этапах разработки к тестированию и тест-дизайну выдвигаются разные требования, которые мы рассмотрим в рамках вебинара.
Особенности тест-дизайн при итерационной разработке
Польза и спорная эффективность автоматизации тестирования
Наследование тест-кейсов новыми и «родственными» версиями продукта
Поддержание тест-кейсов в актуальном состоянии на разных этапах жизненного цикла продукта
КГТУ Лекция 4: Обеспечение Качества Программного Обеспечения Iosif Itkin
КГТУ - Костромской Государственный Технологический Университет
Курс Лекций:
Обеспечение Качества Программного Обеспечения
Лекция 4: Автоматизация тестирования программного обеспечения
Максим Рудовский, Инновационные Трейдинговые Системы
Иосиф Иткин, Exactpro Systems
Поговорим, как и зачем функционально тестировать хайлоад, получать от тестов больше, чем «прошёл/не прошёл», а их количество превратить в качество продукта.
Presentation from 11th SQADays conference in Kiev (April 2012) and Selenium Camp 2013 (February 2013) about how to measure what functional tests are really testing from requirements, code and UI perspective.
This document discusses continuous performance testing (CPT) and introduces the Jagger CPT solution. It provides an overview of why performance testing is important, outlines the principles and goals of CPT, and describes the key parts of the Jagger CPT platform including load generation, metrics collection, test data management, and environment management. It also provides an example customer success story where Jagger was used for continuous performance testing of a large ecommerce site.
Мощь переполняет с JDI 2.0 - новая эра UI автоматизацииSQALab
This document provides an overview of the JDI (Java UI test automation framework). It discusses features of JDI including being UI element oriented, providing common UI elements and solutions to common problems. It provides examples of how to write tests using JDI annotations and page object pattern. The document also summarizes benefits of JDI such as reducing test code, improving test clarity, reuse across projects. Finally it outlines new features planned for JDI 2.0 including layout verification, page object generator, integration with Selenium and expanding JDI to other languages like Python.
The document discusses testing of geolocation systems. It provides an overview of geolocation, including definitions and importance. It then outlines the speaker's experience and work testing GIS systems. The rest of the document details approaches to testing geolocation, including simulating calls, checking responses and databases, and verifying accuracy. It also discusses common data formats, projections, tools like PostGIS and QGIS, and potential bugs to watch for like coordinate jumbling. The conclusion emphasizes starting simple, practicing to improve, and for tests to grow with knowledge as geolocation is important for future IT.
2. Обо мне
Роман Шейко
• В тестировании с 2006 года (Motorola, General
Satellite, Acronis, Luxoft)
• Веду блог www.33testers.blogspot.com
• Познакомился с оракулами в рамках курса Black Box
Software Testing (Foundation)
• Проводил тренинги по их использованию
• Изучал оракулы на практике в рамках Weekend
Testing
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
2
3. Цели доклада
• Осветить тему оракулов в
тестировании
• Показать их использование на
примерах
• Мотивировать к дальнейшему
изучению и использованию оракулов
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
3
4. План доклада
1. Что такое оракулы в тестировании
2. Использование оракулов
3. Подведение итогов
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
4
5. 1. Что такое оракул?
Оракул
Оракул – механизм,
который помогает нам
определить результат
выполнения теста.
К/Ф «Матрица»
Другие определения:
• Программа-эталон, с которой мы сравниваем нашу программу
• Метод генерации ожидаемого результата
• Метод сравнения фактического результата с ожидаемым
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
5
6. Пример: тест калькулятора
Проверить сложение
1. Введите 2 в поле «Первое
слагаемое»
2. Введите 2 в поле «Второе
слагаемое»
3. Нажмите «=».
Приложение - калькулятор
Оракула в тесте нет. Нужен ли он?
2
+
2
=
?
* Умеет только
складывать
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
6
7. Пример: тест калькулятора
Проверить сложение
1. Введите 2 в поле
«Первое
слагаемое»
2. Введите 2 в поле
«Второе
слагаемое»
3. Нажмите «=»
4. Проверьте, что
сумма равна 4.
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
7
8. Пример: тест калькулятора
1-й вариант
Проверить сложение
1. Введите 2 в поле
«Первое
слагаемое»
2. Введите 2 в поле
«Второе
слагаемое»
+
3. Нажмите «=»
4. Проверьте, что
сумма равна 4
2-й вариант
Проверить сложение
1-3. То же самое.
4. Проверьте, что
сумма равна 4
5. Проверьте, что
время
выполнения
операции
меньше минуты
Оракул не помог обнаружить
проблему с быстродействием
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
8
9. Пример: тест калькулятора
1-й вариант
Проверить сложение
1. Введите 2 в поле
«Первое
слагаемое»
2. Введите 2 в поле
«Второе
слагаемое»
3. Нажмите «=»
4. Проверьте, что
сумма равна 4
(Оракул не помог
обнаружить проблему с
быстродействием)
2-й вариант
Проверить сложение
1-3. То же самое.
4. Проверьте, что
сумма равна 4
5. Проверьте, что
время
выполнения
операции
меньше минуты
+
(Оракул не помог
обнаружить проблему с
освобождением памяти)
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
3-й вариант
Проверить сложение
1-3. То же самое.
4. Проверьте, что
сумма равна 4
5. Проверьте, что
время
выполнения
операции
меньше минуты
6. Проверьте
освобождение
памяти
9
10. Увеличение оракула
Оракул 1-го варианта
теста
Оракул 2-го варианта
теста
Оракул 3-го варианта
теста
Выводы:
1. Чем достовернее оракул, тем, как правило, он больше и сложнее
2. Автоматизация требует повышенного внимания к оракулам
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
10
11. Полные и частичные оракулы
• Полный оракул – механизм, который на
100% достоверно может определить
результат теста
• Частичный оракул – механизм, который
не может с полной достоверностью
определить результат теста, но требует
меньше ресурсов для использования
Elaine Weyuker, “On testing nontestable” (1980)
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
11
12. Ошибки использования оракулов
1. Промах – когда оракул не помог
обнаружить проблему, но она есть
2. Ложная тревога – когда оракул
обнаружил проблему, но на самом
деле ее нет
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
12
13. 2. Использование оракулов
Ваши собственные оракулы
Оракулы соответствия Джеймса Баха
и Майкла Болтона
Оракулы Дуга Хоффмана
Эмоции в качестве оракулов
…
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
13
14. Классификации оракулов
Джеймс Бах
Майкл Болтон
1. FEW HICCUPPS
Дуг Хоффман
2. Таксономия
оракулов
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
14
15. Классификация Баха и Болтона
(FEW HICCUPPS)
• Основана на наблюдениях авторов за
тем, как тестировщики обнаруживают
проблемы
• Классификацию часто называют
оракулами соответствия
• Она также известна как FEW HICCUPPS
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
15
16. Классификация Баха и Болтона
(Оракулы соответствия)
FEW HICCUPPS
Оракул
Описание
History
Соответствие продукта предыдущим версиям
Image
Соответствие имиджу компании
Comparable products
Соответствие сравнимым продуктам
Claims
Соответствие требованиям (обещаниям)
User’s Expectations
Соответствие ожиданиям пользователей
Product
Соответствие другим частям продукта
Purpose
Соответствие назначению продукта
Statutes and standards
Соответствие уставам и стандартам
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
16
17. Классификация Баха и Болтона
(Оракулы соответствия)
FEW HICCUPPS
Оракул
Описание
Familiarity
Несоответствие схожим проблемам
Explainability
Соответствие поведению, которое можно объяснить
World
Соответствие представлениям о мире
FEW HICCUPPS
СОМ ПИТОНИУС
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
17
18. Пример использования FEW HICCUPPS:
Просмотр расписания поездов rzd.ru
Памятка оракулов:
•F (Схожесть)
•E (Объяснимость)
•W (Мир)
Пустые результаты поиска поездов:
«Дата отправления находится за пределами
периода предварительной продажи»
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
•H (История)
•I (Имидж)
•С (Требования)
•С (Сравнимые
продукты)
•U (Ожидания
пользователей)
•P (Назначение)
•P (Продукт)
•S (Уставы и
стандарты)
18
19. Пример использования FEW HICCUPPS:
Вход на сайт при оформлении заказа
Поиск
рейсов
Выбор
поезда и
вагона
Вход
на сайт
Вход под
существующим
login
Регистрация
Начальная
страница
Активация
Оформление
заказа
1. После регистрации происходит переход
на начальную страницу
2. Но после входа под известным
пользователем продолжается
оформление заказа
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
Памятка оракулов:
•F (Схожесть)
•E (Объяснимость)
•W (Мир)
•H (История)
•I (Имидж)
•С (Требования)
•С (Сравнимые
продукты)
•U (Ожидания
пользователей)
•P (Назначение)
•P (Продукт)
•S (Уставы и
стандарты)
19
20. Пример использования FEW HICCUPS:
О чем мы не поговорили?
• Мы рассмотрели не все оракулы
соответствия на примере
• Попробуйте применить
остальные оракулы FEW
HICCUPPS в своей работе
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
Памятка оракулов:
•F (Схожесть)
•E (Объяснимость)
•W (Мир)
•H (История)
•I (Имидж)
•С (Требования)
•С (Сравнимые
продукты)
•U (Ожидания
пользователей)
•P (Назначение)
•P (Продукт)
•S (Уставы и
стандарты)
20
21. Классификация Дуга Хоффмана
• Эта классификация оракулов создавалась
в основном для автоматизации
тестирования
• Ее называют Таксономией оракулов
Хоффмана
• Хоффман предположил, что полных
оракулов не существует, но в то же время
есть множество полезных частичных
оракулов
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
21
22. Классификация Дуга Хоффмана
(Таксономия оракулов)
Оракул
Описание
Constraint oracle
Оракул ограничений
Regression oracle
Оракул регрессии
Self-verifying data oracle
Оракул самопроверяемых данных
Physical model oracle
Оракул физической модели
Business model oracle
Оракул бизнес модели
Statistical model oracle
Оракул статистической модели
State model oracle
Оракул модели состояний
Interaction model oracle
Оракул модели взаимодействия
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
22
23. Классификация Дуга Хоффмана
(Таксономия оракулов)
Оракул
Описание
Calculation oracle
Оракул вычислений
Inverse oracle
Оракул инверсии
Reference program
Оракул образцовой программы
И много много других..
См. материалы в конце доклада
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
23
24. Пример: разработка автотестов для функции
суммирования в таблицах Google Docs
Памятка оракулов:
•Оракул ограничений
•Оракул регрессии
•Оракул самопроверяемых
данных
•Оракулы моделей
(физической, бизнес,
статистической, состояний,
взаимодействия)
•Оракул вычислений
•Оракул инверсии
•Оракул образцовой
программы
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
24
25. Пример: разработка автотестов для функции
построения диаграмм в таблицах Google Docs
Памятка оракулов:
•Оракул ограничений
•Оракул регрессии
•Оракул самопроверяемых
данных
•Оракулы моделей
(физической, бизнес,
статистической, состояний,
взаимодействия)
•Оракул вычислений
•Оракул инверсии
•Оракул образцовой
программы
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
25
26. Пример использования таксономии оракулов:
О чем мы не поговорили?
• Мы рассмотрели не все
оракулы из таксономии
• Попробуйте остальные
оракулы из таксономии
оракулов Хоффмана
Памятка оракулов:
•Оракул ограничений
•Оракул регрессии
•Оракул самопроверяемых
данных
•Оракулы моделей
(физической, бизнес,
статистической, состояний,
взаимодействия)
•Оракул вычислений
•Оракул инверсии
•Оракул образцовой
программы
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
26
27. Сравнение классификаций
Области
применения
Сильные стороны
Слабые
стороны
FEW
HICCUPPS
• Заведение
• Мнемоника
Не совсем
убедительных • Универсальность подходит для
баг репортов
разработки
• Тест дизайн
автотестов
Таксономия
оракулов
• Тест дизайн
• Разработка
автотестов
• Оракулы хорошо Описание плохо
программируемы структурировано
(ИМХО)
• Оракулы
конкретны
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
27
29. Другие идеи использования
оракулов
• Эмоции могут быть оракулом для
тестировщика (Майкл Болтон)
• Эмоции для тестировщика – как датчик
дыма, который сигнализирует о том, что
есть проблема
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
29
30. 3. Summary
1.
2.
3.
4.
5.
6.
Оракул – механизм, который помогает нам определять
результат теста
2 наиболее популярные классификации оракулов – оракулы
соответсвия (FEW HICCUPPS) и таксономия оракулов
Хоффмана
Обе классификации помогают нам обнаруживать ошибки и
разрабатывать тесты
FEW HICCUPPS успешно применяется для заведения
убедительных баг репортов
Таксономия оракулов Хоффмана хорошо подходит для
автоматизации
Существует множество идей использования оракулов в
тестировании. Например, в качестве оракула тестировщик
может использовать свои эмоции
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
30
31. Материалы
Материалы для первого знакомства с оракулами:
• Cтатья Майкла Болтона про оракулы соответствия:
http://www.developsense.com/articles/2005-01-TestingWithoutAMap.pdf
• Cтатьи про FEW HICCUPPS:
– http://www.developsense.com/blog/2012/07/few-hiccupps/
– http://www.testingeducation.org/BBST/foundations/Kelly_UsingTestOracles.pdf
– http://www.associationforsoftwaretesting.org/2012/06/12/observation-inferenceoracle/
• Cтатья Дуга Хоффмана об оракулах-эвристиках:
http://www.softwarequalitymethods.com/Papers/STQE%20Heuristic.pdf
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
31
32. Материалы
Материалы для более глубокого изучения:
•
•
•
Статьи Майкла Болтона об эмоциях в качестве оракула:
– http://www.developsense.com/blog/2011/09/the-cooking-detector/
– http://www.developsense.com/blog/2011/10/confusion-as-an-oracle/
Статья Кема Канера о проблеме оракулов: http://kaner.com/?p=190
Другие статьи Майкла Болтона по оракулам:
http://www.developsense.com/blog/category/oracles/
•
Множество материалов Дуга Хоффмана о таксономии оракулов:
http://softwarequalitymethods.com/html/papers.html#taxonomy
•
Статья Элейн Вейюкер о тестировании нетестируемого:
http://www.testingeducation.org/BBST/foundations/Weyuker_ontestingnontestab
le.pdf
Твиттер: @Rsheyko
Прогресс доклада
Блог: 33testers.blogspot.com
E-mail: r.sheyko@gmail.com
32