Документ представляет собой исчерпывающее руководство по тестированию и обеспечению качества программного обеспечения, включая опыт автора в области управления качеством и разработки тест-планов. Он охватывает функциональное тестирование, методы оценки покрытия требований, доменное тестирование, а также важность ревью и формальных инспекций. В заключение представлены примеры заданий для тестирования программных продуктов.

1. Надежный тест-дизайн
Александр Александров
УЦ Luxoft

2. Немного о себе
 1963-1999 – Вычислительный центр Московского
Государственного университета им. М.В. Ломоносова
(студент, сотрудник)
 1999-2005 – Luxoft (руководитель группы
тестирования, тест-менеджер)
 2006-2007 – Auriga (директор по качеству)
 С 2008 – Luxoft (эксперт по управлению качеством ПО)
 C 2010 – эксперт ISTQB
 Кандидат физико-математических наук, доцент,
старший научный сотрудник
 Сертифицированный инструктор университета
Carnegie Mellon по тематике Quality Assurance 2

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)
3

4. Функциональное тестирование
 Программа как совокупность функций
– Проверить, как работает каждая функция отдельно
– Проверить, как функции взаимодействуют друг с другом
– Проверка навигации
 Соответствие программного продукта предъявляемым функциональным
требованиям
– Все ли требования реализованы
– Все ли требования реализованы правильно
– Нет ли лишнего
– Адекватная ли диагностика
 Функциональные требования vs. Функциональное тестирование
– Функциональные требования: определить что как должно работать
– Функциональное тестирование: определить что не работает или
работает не так как должно
 Ориентируемся на ввод, обработку и выдачу данных
– Выводятся ожидаемые результаты в ответ на правильно вводимые
данные
– Адекватная реакция на некорректные данные (соответствующие
сообщения об ошибках)
4

5. Структура тест-плана
 Уникальный идентификатор
 История изменений
 Разделы по типам тестирования
 Тестовые сценарии
 Тесты
 Ожидаемые результаты
 Связь с требованиями
– Может не выделяться в отдельный раздел, а указываться для каждого
сценария
– Может быть использована матрица покрытия
 Классификация дефектов
 Критерии оценки качества
5

6. Этапы разработки тест-плана
1. Разработка плана тестирования
– Тест менеджер поручает тест-проектировщику начать разработку плана тестирования
– Тест-проектировщик разрабатывает методику тестирования продукта и определяет
структуру плана тестирования
– Тест-проектировщик оформляет каждый тестовый сценарий
– Тест-проектировщик согласовывает с тест-менеджером разработанный план
2. Детализация плана тестирования
– По окончании работ по проектированию системы, а также при каждом изменении
требований тест менеджер поручает тест-проектировщику доработать план
тестирования
– При использовании средств автоматизации тестирования тест менеджер поручает тест-
проектировщику подготовку набора тестовых скриптов
– Если необходимо, тест менеджер поручает тест-проектировщику разработку тестовых
данных
– Тест менеджер согласует с руководителем проекта подготовленный план тестирования
3. Корректировка плана тестирования
– При обнаружении неточностей, неполноты и ошибок в ходе тестирования тест-
проектировщик консультирует тестировщиков и дорабатывает план тестирования
– Тест-менеджер принимает решение о необходимости согласования новой версии
плана тестирования
6

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

8. Матрица покрытия требований
тестовыми сценариями
 Оценка и отслеживание покрытия является важной частью процесса
тестирования
 Мы должны знать какие требования покрыты или не покрыты тестовыми
сценариями
 Покрытие тестами сложных систем трудно отслеживать без
систематической оценки и измерений
 Состоит из списка всех требований и тестовых сценариев, которые
используются для проверки того, как реализованы эти требования
 Также важно знать приоритетность и критичность требований. Часто
бывает полезным для наиболее критичных требований делать более
детальную проверку.
8

9. Domain testing
 Работа с программным продуктом на уровне обрабатываемых
данных
– Определить все данные, с которыми работает программа
– Определить, какие данные надо протестировать
– Определить какие данные надо тестировать в комбинации
 Включает:
– Декомпозицию
– Определение классов эквивалентности
– Анализ граничных значений
– Обработку ошибок
9

10. Domain testing
 Классы эквивалентности - множество похожих
входных данных, которые работают с
приложением одинаково
 Например, для калькулятора в качестве
класса входных данных можно рассматривать
множество всех неотрицательных чисел от 0
до MAXINT.
 Неверные случаи
– множество всех значений <0
– множество всех значений > MAXINT
– множество букв и нечисловых данных
10

11. Domain testing
 Группа тестов является классом эквивалентности,
если выполнены следующие условия:
– Все тесты предназначены для выявления одной
и той же ошибки
– Если один из тестов выявит ошибку, остальные,
скорее всего, тоже это сделают
– Если один из тестов не выявит ошибки,
остальные, скорее всего, тоже этого не сделают
11

12. Domain testing
 Практические критерии определения классов:
– Тесты включают значения из одних и тех же
данных
– Для их проведения выполняются одни и те же
операции программы
– В результате всех тестов формируются
значения из одних и тех же выходных данных
– Либо ни один из тестов не вызывает
выполнения блока обработки ошибок
программы, либо выполнение этого блока
называется всеми тестами группы
12

13. Domain testing
 Поиск классов эквивалентности
– Учитывать классы, охватывающие заведомо
неверные или недопустимые входные данные
– Представить перечень классов в виде таблицы или
плана
– Определить диапазоны числовых значений
– Выяснить, какие значения принимают поля и
параметры с конечным множеством значений
– Проанализировать возможные результаты выборов
из списков и меню
13

14. Domain testing
 Поиск классов эквивалентности
– Установить переменные, значения которых могут
быть равными
– Установить классы значений, зависящих от времени
– Определить, на какие действия программа отвечает
эквивалентными событиями
– Продумать варианты операционной среды
14

15. Domain testing
 Какие тесты выбирать для классов
– Определить, сколько значений взять из каждого
класса эквивалентности
– Зависит от размера класса
 необходимо привести характерные примеры
из множества
– Зависит от времени
 количество должно быть разумным
– Зависит от наличия автоматизации
15

16. Domain testing
 Граничные значения - множества значений,
лежащих на границе допустимых входных
значений или радом с ней
 MAXINT
 MAXINT + 1
 MAXINT - 1
 Строка, состоящая из MAXCHAR символов
 Пустая строка
 Благодаря проверке граничных условий можно
найти много ошибок
16

17. Domain testing
 Граничные значения - рекомендации
– Проверять все классы эквивалентности
– Особенно граничные значения -- наибольшее,
наименьшее, наискорейшее, наикратчайшее,
самое быстрое, самое громкое и пр. значения
класса.
– Некорректные неравенства (такие, как > вместо
>=) приводят к ошибкам только на границах.
– Программа, которая отказывается работать на
неграничных значения, обычно падает на
границах тоже.
17

18. Domain testing
 Тестовые сценарии должны включать комбинации
верных и неверных входных данных для всех
классов эквивалентности и граничных условий
 Проверьте все наиболее вероятные
последовательности действий пользователей
 Если действия пользователя в одном режиме
могут воздействовать на представление данных
или набор предоставляемых программой
возможностей в другом режиме, протестируйте
эту зависимость
 Необходимо поработать с программой в
произвольном режиме
18

19. Domain testing
 Обработка ошибок
– Распознана ли ошибка
– Как она обработана
– Соответствует ли ошибке выданное сообщение
– Действия программы после сообщения об
ошибке
19

20. Основные особенности ревью
 Артефакты изучают не те люди, которые их
разрабатывали
 Квалифицированный взгляд со стороны
 Должна быть мотивация участников ревью
 Очень действенный метод, позволяющий отловить весьма
трудноуловимые ошибки
 Наряду с проектной документацией по методикам STR
может тестироваться и исходный код и прочие документы
20

21. Роли для формальной инспекции
 Модератор (moderator)
– Руководит процессом
– Составляет расписание
– Проводит инспекцию
– Составляет отчет по ее результатам
– Отслеживает внесение изменений
 Автор (author)
– Отвечает на вопросы в процессе инспекции
– Ищет ошибки наравне с другими
21

22. Роли для формальной инспекции
 Чтец (reader)
– Изучает и описывает команде продукт или его раздел
 Секретарь (recorder)
– Классифицирует и записывает ошибки и вопросы (роль
может быть совмещена с ролью модератора)
 Инспектор (inspector)
– Старается найти ошибки в продукте (эту роль
фактически выполняют все участники команды)
22

23. Метрики статического тестирования
 Плотность обнаруженных дефектов
– Среднее число обнаруженных дефектов на страницу
документа
– Дефекты делятся на серьезные (влияющие на
выполнение проекта) и несерьезные (оформительские)
 Производительность ревью
– Среднее число страниц, обработанных рецензентом за
единицу времени (1 час)
 Анализируется попадание в статистически
достоверный диапазон
23

24. Задания - Перечень действий
 Разработка системных требований
 Ревью системных требований
 Разработка планов тестирования
 Ревью планов тестирования
24

25. Задания - Перечень артефактов
 Системные требования
 Результаты ревью системных требований
 План(ы) тестирования
 Матрица покрытия требований тестовыми сценариями
25

26. Задание 1 - Решение квадратного
уравнения
 Программа получает на вход три вещественных
числа и интерпретирует их как коэффициенты
квадратного уравнения
 Результатом работы программы являются два
числа – корни этого квадратного уравнения
26

27. Задание 2 - Распознавание треугольника
 Программа получает на вход три натуральных
числа и интерпретирует их как длины сторон
треугольника
 Результатом работы программы является
сообщение о том, является ли треугольник
неравносторонним, равнобедренным или
равносторонним
27

28. Задание 3 - Калькулятор
 Программа получает на вход три целых числа
 Результатом работы программы является целое
число, равное сумме введенных целых чисел
28

29. Задание 4 - Банкомат
 Банкомат должен выполнять следующие
операции:
– Прием пластиковой карты
– Проверку ПИН-кода
– Выдачу наличных
– Выдачу чека с информацией об остатке на счете
29

30. Задание 5 - Web-сайт библиотеки
 Библиотека должна позволять:
– Ведение реестра книг
– Выдачу и возврат книг
– Одновременную работу большого числа
пользователей
30

31. Спасибо за внимание!
Вопросы?
31