Надежный тест-дизайн

Александр АлександровУЦ Luxoft

2

Немного о себе

1963-1999 – Вычислительный центр Московского Государственного университета им. М.В. Ломоносова (студент, сотрудник)

1999-2005 – Luxoft (руководитель группы тестирования, тест-менеджер)

2006-2007 – Auriga (директор по качеству)

С 2008 – Luxoft (эксперт по управлению качеством ПО)

C 2010 – эксперт ISTQB

Кандидат физико-математических наук, доцент, старший научный сотрудник

Сертифицированный инструктор университета Carnegie Mellon по тематике Quality Assurance

3

Опыт работы

Более 30 лет работы в области тестирования и обеспечения качества (МГУ, Luxoft, Auriga)

Более 5 лет работы в области управления качеством (Luxoft, Auriga)

Опыт cертификации ISO 9001 (Luxoft), CMM, CMMI (Luxoft, Auriga)

Опыт внедрения процессов в рамках модели CMMI (Luxoft, Auriga)

Сертификат обучения Project Management от Project Management Institute (2000)

Сертификат обучения Introduction to Capability Maturity Model Integration v. 1.2 от ProceXpert (2007)

4

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

Программа как совокупность функций– Проверить, как работает каждая функция отдельно– Проверить, как функции взаимодействуют друг с другом– Проверка навигации

Соответствие программного продукта предъявляемым функциональным требованиям– Все ли требования реализованы– Все ли требования реализованы правильно– Нет ли лишнего– Адекватная ли диагностика

Функциональные требования vs. Функциональное тестирование– Функциональные требования: определить что как должно работать– Функциональное тестирование: определить что не работает или

работает не так как должно Ориентируемся на ввод, обработку и выдачу данных

– Выводятся ожидаемые результаты в ответ на правильно вводимые данные

– Адекватная реакция на некорректные данные (соответствующие сообщения об ошибках)

5

Структура тест-плана

Уникальный идентификатор История изменений Разделы по типам тестирования Тестовые сценарии Тесты Ожидаемые результаты Связь с требованиями

– Может не выделяться в отдельный раздел, а указываться для каждого сценария

– Может быть использована матрица покрытия Классификация дефектов Критерии оценки качества

6

Этапы разработки тест-плана

1. Разработка плана тестирования– Тест менеджер поручает тест-проектировщику начать разработку плана тестирования – Тест-проектировщик разрабатывает методику тестирования продукта и определяет

структуру плана тестирования – Тест-проектировщик оформляет каждый тестовый сценарий– Тест-проектировщик согласовывает с тест-менеджером разработанный план

2. Детализация плана тестирования– По окончании работ по проектированию системы, а также при каждом изменении

требований тест менеджер поручает тест-проектировщику доработать план тестирования

– При использовании средств автоматизации тестирования тест менеджер поручает тест-проектировщику подготовку набора тестовых скриптов

– Если необходимо, тест менеджер поручает тест-проектировщику разработку тестовых данных

– Тест менеджер согласует с руководителем проекта подготовленный план тестирования3. Корректировка плана тестирования

– При обнаружении неточностей, неполноты и ошибок в ходе тестирования тест-проектировщик консультирует тестировщиков и дорабатывает план тестирования

– Тест-менеджер принимает решение о необходимости согласования новой версии плана тестирования

7

Характеристики хорошего тест-плана

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

очевидностью

8

Матрица покрытия требований тестовыми сценариями

Оценка и отслеживание покрытия является важной частью процесса тестирования

Мы должны знать какие требования покрыты или не покрыты тестовыми сценариями

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

Состоит из списка всех требований и тестовых сценариев, которые используются для проверки того, как реализованы эти требования

Также важно знать приоритетность и критичность требований. Часто бывает полезным для наиболее критичных требований делать более детальную проверку.

9

Domain testing

Работа с программным продуктом на уровне обрабатываемых данных

– Определить все данные, с которыми работает программа

– Определить, какие данные надо протестировать

– Определить какие данные надо тестировать в комбинации Включает:

– Декомпозицию

– Определение классов эквивалентности

– Анализ граничных значений

– Обработку ошибок

10

Domain testing

Классы эквивалентности - множество похожих входных данных, которые работают с приложением одинаково

Например, для калькулятора в качестве класса входных данных можно рассматривать множество всех неотрицательных чисел от 0 до MAXINT.

Неверные случаи– множество всех значений <0– множество всех значений > MAXINT– множество букв и нечисловых данных

11

Domain testing

Группа тестов является классом эквивалентности, если выполнены следующие условия:

– Все тесты предназначены для выявления одной и той же ошибки

– Если один из тестов выявит ошибку, остальные, скорее всего, тоже это сделают

– Если один из тестов не выявит ошибки, остальные, скорее всего, тоже этого не сделают

12

Domain testing

Практические критерии определения классов:

– Тесты включают значения из одних и тех же данных

– Для их проведения выполняются одни и те же операции программы

– В результате всех тестов формируются значения из одних и тех же выходных данных

– Либо ни один из тестов не вызывает выполнения блока обработки ошибок программы, либо выполнение этого блока называется всеми тестами группы

13

Domain testing

Поиск классов эквивалентности

– Учитывать классы, охватывающие заведомо неверные или недопустимые входные данные

– Представить перечень классов в виде таблицы или плана

– Определить диапазоны числовых значений

– Выяснить, какие значения принимают поля и параметры с конечным множеством значений

– Проанализировать возможные результаты выборов из списков и меню

14

Domain testing

Поиск классов эквивалентности

– Установить переменные, значения которых могут быть равными

– Установить классы значений, зависящих от времени

– Определить, на какие действия программа отвечает эквивалентными событиями

– Продумать варианты операционной среды

15

Domain testing

Какие тесты выбирать для классов

– Определить, сколько значений взять из каждого класса эквивалентности

– Зависит от размера класса необходимо привести характерные примеры

из множества

– Зависит от времени количество должно быть разумным

– Зависит от наличия автоматизации

16

Domain testing

Граничные значения - множества значений, лежащих на границе допустимых входных значений или радом с ней

MAXINT MAXINT + 1 MAXINT - 1 Строка, состоящая из MAXCHAR символов Пустая строка

Благодаря проверке граничных условий можно найти много ошибок

17

Domain testing

Граничные значения - рекомендации

– Проверять все классы эквивалентности

– Особенно граничные значения -- наибольшее, наименьшее, наискорейшее, наикратчайшее, самое быстрое, самое громкое и пр. значения класса.

– Некорректные неравенства (такие, как > вместо >=) приводят к ошибкам только на границах.

– Программа, которая отказывается работать на неграничных значения, обычно падает на границах тоже.

18

Domain testing

Тестовые сценарии должны включать комбинации верных и неверных входных данных для всех классов эквивалентности и граничных условий

Проверьте все наиболее вероятные последовательности действий пользователей

Если действия пользователя в одном режиме могут воздействовать на представление данных или набор предоставляемых программой возможностей в другом режиме, протестируйте эту зависимость

Необходимо поработать с программой в произвольном режиме

19

Domain testing

Обработка ошибок

– Распознана ли ошибка

– Как она обработана

– Соответствует ли ошибке выданное сообщение

– Действия программы после сообщения об ошибке

20

Основные особенности ревью

Артефакты изучают не те люди, которые их разрабатывали

Квалифицированный взгляд со стороны

Должна быть мотивация участников ревью

Очень действенный метод, позволяющий отловить весьма трудноуловимые ошибки

Наряду с проектной документацией по методикам STR может тестироваться и исходный код и прочие документы

21

Роли для формальной инспекции

Модератор (moderator)– Руководит процессом– Составляет расписание– Проводит инспекцию– Составляет отчет по ее результатам– Отслеживает внесение изменений

Автор (author)– Отвечает на вопросы в процессе инспекции– Ищет ошибки наравне с другими

22

Роли для формальной инспекции

Чтец (reader)– Изучает и описывает команде продукт или его раздел

Секретарь (recorder)– Классифицирует и записывает ошибки и вопросы

(роль может быть совмещена с ролью модератора)

Инспектор (inspector)– Старается найти ошибки в продукте (эту роль

фактически выполняют все участники команды)

23

Плотность обнаруженных дефектов– Среднее число обнаруженных дефектов на страницу

документа– Дефекты делятся на серьезные (влияющие на

выполнение проекта) и несерьезные (оформительские)

Производительность ревью– Среднее число страниц, обработанных рецензентом за

единицу времени (1 час)

Анализируется попадание в статистически достоверный диапазон

Метрики статического тестирования

24

Задания - Перечень действий

Разработка системных требований Ревью системных требований Разработка планов тестирования Ревью планов тестирования

25

Задания - Перечень артефактов

Системные требования Результаты ревью системных требований План(ы) тестирования Матрица покрытия требований тестовыми сценариями

26

Задание 1 - Решение квадратного уравнения

Программа получает на вход три вещественных числа и интерпретирует их как коэффициенты квадратного уравнения

Результатом работы программы являются два числа – корни этого квадратного уравнения

27

Задание 2 - Распознавание треугольника

Программа получает на вход три натуральных числа и интерпретирует их как длины сторон треугольника

Результатом работы программы является сообщение о том, является ли треугольник неравносторонним, равнобедренным или равносторонним

28

Задание 3 - Калькулятор

Программа получает на вход три целых числа Результатом работы программы является целое

число, равное сумме введенных целых чисел

29

Задание 4 - Банкомат

Банкомат должен выполнять следующие операции:

–Прием пластиковой карты

–Проверку ПИН-кода

–Выдачу наличных

–Выдачу чека с информацией об остатке на счете

30

Задание 5 - Web-сайт библиотеки

Библиотека должна позволять:

–Ведение реестра книг

–Выдачу и возврат книг

–Одновременную работу большого числа пользователей

31

Спасибо за внимание!

Вопросы?