Lekciya1.2-Viditipiioblastitestirovaniya

Содержание

Слайд 2

Что должен делать тестировщик
Сохранять здравый рассудок в творческой обстановке ИТ-проекта
Хорошо знать продукт

Что должен делать тестировщик Сохранять здравый рассудок в творческой обстановке ИТ-проекта Хорошо
и то, как его используют клиенты
Находить ошибки в продукте
Помогать разработчикам исправлять ошибки
Тестировать проектную документацию
Предоставлять руководству всю необходимую для принятия решений информацию
Оценивать качество продукта
Выявлять способы улучшения продукта
И много-много других не менее важных задач!

Слайд 3

Тестирование, QC, QA

Тестирование – исследование продукта и предоставление информации (дефекты, отчеты, метрики)
Контроль

Тестирование, QC, QA Тестирование – исследование продукта и предоставление информации (дефекты, отчеты,
качества (QC, Quality Control) – Тестирование + принятие
решения о выпуске продукта.
Обеспечение качества (QA, Quality Assurance) – процессный
менеджмент, определяющий пути повышения качества продукта (не только в области тестирования).
Валидация – верификация + тестирование требований.

Слайд 4

Тестирование, QC, QA

Тестирование, QC, QA

Слайд 5

Стоимость исправления ошибок
Широко известна оценка распределения трудоемкости между фазами создания программного продукта:

Стоимость исправления ошибок Широко известна оценка распределения трудоемкости между фазами создания программного
40%-20%-40%
Миссия тестирования – снизить стоимость разработки путем раннего обнаружения дефектов

Слайд 6

Самые худшие баги человечества
1962 г. Космический аппарат Mariner I стартовал по направлению

Самые худшие баги человечества 1962 г. Космический аппарат Mariner I стартовал по
к Венере. Корабль перешел на собственную систему пилотирования. Но эта система содержала обидный маленький баг. В результате аппарат полетел совсем не в ту сторону и его пришлось подорвать над Атлантическим океаном. Последующее расследование установило, что в процессе программирования системы навигации была совершена маленькая опечатка - при вводе одной из формул был пропущен один символ.
1982 г. Авария на Транссибирском трубопроводе. Оперативники ЦРУ внедрили баг (отчет в формате PDF) в канадское программное обеспечение, управлявшее газовыми трубопроводами. Советская разведка получила это ПО как объект промышленного шпионажа и внедрила на Транссибирском трубопроводе. Результатом стал самый большой неядерный взрыв в истории человечества.
1993 г. Процессор Intel Pentium неправильно производил деление с плавающей запятой, ошибаясь на 0,006%. Хотя эта проблема реально коснулась немногих пользователей, но стала настоящим кошмаром для имиджа Intel. Поначалу фирма согласилась менять процессор только для тех пользователей, которые могли доказать, что им в вычислениях нужна подобная точность, но затем согласилась поменять процессор всем желающим. Этот баг стоил Intel около $475 млн.
1996 г. Новая ракета-носитель Ariane 5, результат многолетней работы европейских ученых, гордость стран Евросоюза, взорвалась через 40 секунд после старта. Переполнение буфера, система навигации подала недопустимо большое значение параметра горизонтальной скорости. Инженеры сняли защиту от ошибок переполнения буфера в программном модуле, поскольку были уверены, что такого значения горизонтальной скорости не может быть в принципе. Только научное оборудование на борту ракеты стоило около $500 млн.
1985-87 гг. Несколько человек получили смертельную дозу облучения во время сеансов радиационной терапии с медицинским ускорителем Therac-25. «Улучшение" состояло в том, что вместо электромеханической защиты пациента в устройстве была реализована программная защита, якобы более надежная. Функция была некорректно реализована неопытным программистом, результатом чего стали как минимум пять смертей и огромное количество несмертельных случаев переоблучения.

Слайд 7

Виды тестирования. Интеллект-карта

Виды
тестов

Что проверяем?

Что знаем о продукте изнутри?

Какие ожидания от проверки?

Как проверяем?

Какую

Виды тестирования. Интеллект-карта Виды тестов Что проверяем? Что знаем о продукте изнутри?
часть проверяем?

Как проверяем?

Модуль (Unit testing)

Связь модулей
(Integration testing)
Все в целом (System testing)

Вручную (Manual testing)

Автоматизированно (Automated testing)

Интуитивно

(Ad hoc testing)

Исследуем (Exploratory testing)

По заранее созданным сценариям
Функционал

(Functional)
Производительность (Performance)

Нагрузки (Load)

Совместимость (Сompatibility )

Удобство использования

(Usability)
Окружения

Ничего (Black-box)

Все (White-box)

Немножко(Gray-box)

Должно работать (Positive)

Не должно работать (Negative)

Не знаю что должно быть

Слайд 8

Позитивное и негативное тестирование

Позитивное и негативное тестирование

Слайд 9

Функциональное и нефункциональное тестирование

Функциональное и нефункциональное тестирование

Слайд 10

Модульное и интеграционное тестирование

Модульное и интеграционное тестирование

Слайд 11

Альфа- и бета-тестирование
Альфа-тестирование – реальная работа с продуктом штатными сотрудниками команды разработки

Альфа- и бета-тестирование Альфа-тестирование – реальная работа с продуктом штатными сотрудниками команды
(программисты, тестировщики, аналитики, менеджер и т.д.) в роли конечных пользователей.
Бета-тестирование – использование почти готовой версии продукта группой сторонних пользователей с целью выявления
максимального числа «нетипичных» дефектов для их исправления перед выходом продукта в релиз.
Бета-тестирования может использоваться как часть стратегии
продвижения продукта на рынок:
Бесплатная раздача бета-версий привлекает вниманием многих пользователей к окончательной, платной, версии.
Сбор отзывов о продукте от широкого круга пользователей.

Слайд 12

Регрессионное тестирование
Регрессионное тестирование (regression testing, от лат. regressio
– движение назад) – собирательное название

Регрессионное тестирование Регрессионное тестирование (regression testing, от лат. regressio – движение назад)
методов
тестирования, направленных на обнаружение дефектов в уже протестированных частях продукта, которые не должны
изменяться.
Такие ошибки появляются в результате влияния новых изменений на
уже существующие части продукта.
Плохой дизайн и архитектура ПО – благодатная почва регрессионных
дефектов.
“Фундаментальная проблема при сопровождении программ состоит в том, что исправление одной ошибки с большой вероятностью (20-50%) влечет появление новой”. Фредерик Брукс - Мифический человеко-месяц или как создаются программные системы. (Премия Тьюринга 1999г.)

Слайд 13

Приемочное тестирование
Приемочное тестирование (acceptance testing) – выполняется на
основании набора типичных сценариев использования

Приемочное тестирование Приемочное тестирование (acceptance testing) – выполняется на основании набора типичных
ПО,
разработанных на основе требований к данному ПО.
Выполняется с целью демонстрации заказчику возможностей готового продукта. Заказчик принимает решение о принятии или отправлении на доработку продукта.

Слайд 14

Smoke-тестирование
Smoke-тестирование – выполнение минимального набора тестов на явные ошибки.
Выполняется:
Самим программистом после модификации

Smoke-тестирование Smoke-тестирование – выполнение минимального набора тестов на явные ошибки. Выполняется: Самим
кода. Если тест не пройдет, нет смысла отдавать продукт в глубокое тестирование
В условиях критического недостатка времени на регрессионное тестирование при внесении небольших изменений
История термина:
Впервые использовался у печников Повторное рождение в электронике

Слайд 15

Ad hoc тестирование
Ad hoc – (англ.) устроенный для данной цели.
Ad hoc тестирование

Ad hoc тестирование Ad hoc – (англ.) устроенный для данной цели. Ad
– интуитивное тестирование, выполняемое
без тест-кейсов, планирования и документации.
Выполняется:
При приемке/сдаче продукта, если тесты не формализованы
В довесок к документированному тестированию
Код уже написан, нужно срочно протестировать

Слайд 16

Связь уровней тестирования

Модульное тестирование

Интеграционное тестирование

Системное тестирование

Приемочное тестирование

Связь уровней тестирования Модульное тестирование Интеграционное тестирование Системное тестирование Приемочное тестирование

Слайд 17

Качество ПО
Тестирование - это возможный способ оценки качества программного обеспечения в терминах

Качество ПО Тестирование - это возможный способ оценки качества программного обеспечения в
найденных дефектов.
Качество ПО (Quality) – характеристика ПО как степень соответствия ПО требованиям к нему.
По стандарту ISO 9001: качество есть степень соответствия присущих характеристик требованиям.
Говорят, что программный продукт обладает хорошим качеством, если :
При работе пользователя с программным продуктом возникает небольшое число отказов .Этот факт свидетельствует о том, что на рабочее место
просочилось лишь небольшое число дефектов .
Программный продукт надежен, а это означает ,что его прогон редко завершается аварийным отказом или что он редко демонстрирует непредсказуемое поведение при работе в среде заказчика .
Программный продукт удовлетворяет требованиям большинства пользователей .

Слайд 18

Критерии качества ПО
Тестирование является одним из наиболее устоявшихся способов обеспечения качества разработки

Критерии качества ПО Тестирование является одним из наиболее устоявшихся способов обеспечения качества
программного обеспечения
Корректность
наличие/отсутствие дефектов в спецификации, проекте и реализации
Практичность
легкость изучения и использования
Эффективность
степень использования системных ресурсов
Надежность
способность системы выполнять необходимые функции; интервал между отказами
Целостность
способность предотвращать неавторизованный или некорректный доступ
Адаптируемость
возможность использования в других областях и средах
Правильность
степень безошибочности данных, выдаваемых системой
Живучесть
способность продолжать работу при недопустимых данных или в напряженных условиях

Слайд 19

Критерии качества ПО

Критерии качества ПО
Имя файла: Lekciya1.2-Viditipiioblastitestirovaniya.pptx
Количество просмотров: 30
Количество скачиваний: 0