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

1. Надежный тест-дизайн Александр Александров УЦ 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. Этапы разработки тест-плана • Разработка плана тестирования • Тест менеджер поручает тест-проектировщику начать разработку плана тестирования • Тест-проектировщик разрабатывает методику тестирования продукта и определяет структуру плана тестирования • Тест-проектировщик оформляет каждый тестовый сценарий • Тест-проектировщик согласовывает с тест-менеджером разработанный план • Детализация плана тестирования • По окончании работ по проектированию системы, а также при каждом изменении требований тест менеджер поручает тест-проектировщику доработать план тестирования • При использовании средств автоматизации тестирования тест менеджер поручает тест-проектировщику подготовку набора тестовых скриптов • Если необходимо, тест менеджер поручает тест-проектировщику разработку тестовых данных • Тест менеджер согласует с руководителем проекта подготовленный план тестирования • Корректировка плана тестирования • При обнаружении неточностей, неполноты и ошибок в ходе тестирования тест-проектировщик консультирует тестировщиков и дорабатывает план тестирования • Тест-менеджер принимает решение о необходимости согласования новой версии плана тестирования

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. Спасибо за внимание!Вопросы?