Документирование как основа тестирования

Август 4, 2022

Главная
Информатика
Документирование как основа тестирования

Содержание

2. Проблемы терминологии В современной IT-промышленности терминология, касающаяся QA и тестирования, весьма запутана пример: термины тест, тестовая
3. Определение теста – IEEE ТЕСТ – набор, состоящий из одного или нескольких тестовых примеров и процедур
4. Другое определение теста В настоящее время широко используется термин test case (тестовый пример) в качестве синонима
5. Типичный набор документов (IEEE Std 829-1998) Функциональная спецификация (Functional specification, FS) Спецификация программных требований (Software requirement
6. «Классический» проект: разработка и кодирование
7. «Классический» проект: тестирование
8. Пример Functional Specification
9. Тестовый план Это документ, включающий: объем ресурсы календарный план работ по тестированию выполняемые тесты тестируемые элементы
10. Назначение тестового плана продукт (стОит дороже) рабочий инструмент служит для поиска ошибок облегчает управление работами и
11. Разработка тестового плана Как правило, применяется эволюционный подход (проведение тестирования параллельно с разработкой его плана) Первый
12. Направления развития плана Наиболее вероятные ошибки (чем больше ошибок обнаружено в некоторой области программы, тем больше
13. Компоненты тестового плана списки таблицы планы матрицы отчетов и экранных форм вх. и вых. переменных возможностей
14. Матрицы: аппаратной и программной совместимости аппаратных конфигураций операционных окружений комбинаций входных значений сообщений об ошибках и
15. Пример таблицы ввода-вывода
16. Иерархический список функций системы Перечень всех высокоуровневых действий пользователя Подфункции всех функций (все доступные опции и
17. Разделы тестового плана по стандарту идентификатор введение тестируемые элементы (программные компоненты, подлежащие тестированию) тестируемые функции нетестируемые
18. Структура Test specification Как у обычного проектного документа: Заголовок Авторы История модификации Логотипы Сведения о степени
19. Test Specification – обязательный документ Test Specification – документ, обязательный к исполнению: все, что там написано
20. Пример Test specification
21. Структура Test Log – основные поля Список тестовых примеров Список версий продукта (билдов) Отметки об успешном
22. Пример Test Log
23. Структура Test Log – дополнительные поля Разбиение по платформам, конфигурациям, средам выполнения, ... Приоритеты Группы и
24. Выводы по результатам проведения тестирования Тестирование пройдено/не пройдено (для билда) Статистика: Время выполнения В среднем на
25. Примеры отчетов (Терехов А.А.) Такие отчеты могут выполнять две основных функции: фиксировать состояние в данной контрольной
26. Разработка тестовых примеров (ТС)
27. Структура тестового примера (test case) - основное Идентификатор Название Автор Название проекта Цель Ссылки Среда выполнения
28. Структура тестового примера – дополнительные поля Краткое описание Полное описание Метка (для конфигурационного менеджмента) Приоритет Статус
29. Test case 16.1.1 Security – Login Form
33. Еще пример test case
35. Скачать презентацию

Слайд 2

Проблемы терминологии
В современной IT-промышленности терминология, касающаяся QA и тестирования, весьма запутана
пример:

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

Слайд 3

Определение теста – IEEE
ТЕСТ – набор, состоящий из одного или нескольких

тестовых примеров и процедур
ТЕСТОВАЯ ПРОЦЕДУРА – перечень большого числа этапов со своими входными данными, каждый из которых имеет свои промежуточные ожидаемые результаты
ТЕСТОВЫЙ ПРИМЕР – комбинация специфических входных данных и ожидаемых результатов

Слайд 4

Другое определение теста
В настоящее время широко используется термин test case (тестовый

пример) в качестве синонима слова тест
Тестовый пример (test case) – это совокупность
Конфигурации системы
Входных данных
Начальных условий
Алгоритма действий (сценарий). Может содержать ветвления (условия, переходы), однако лучше, чтобы он был линейным и как можно более коротким
Ожидаемых результатов (и конечного состояния, которое может отличаться от начального состояния/условий)

Слайд 5

Типичный набор документов
(IEEE Std 829-1998)
Функциональная спецификация (Functional specification, FS)
Спецификация программных требований

(Software requirement specification, SRS)
Traceability matrix (матрица прослеживаемости)
Тест-план (Test plan, test strategy - TP)
Тестовая спецификация (Test specification, TS)
Test cases
Тестовые процедуры
Test log
Bug report

Слайд 6

«Классический» проект: разработка и кодирование

Слайд 7

«Классический» проект: тестирование

Слайд 8

Пример Functional Specification

Слайд 9

Тестовый план
Это документ, включающий:
объем
ресурсы
календарный план работ по тестированию
выполняемые тесты
тестируемые элементы
задачи тестирования
ответственные

сотрудники
вероятность возникновения непредвиденных обстоятельств и меры, которые потребуется при этом принимать
(стандарт ANSI/IEEE 829-2983 for Software Test Documentation)

Слайд 10

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

и контроль хода их выполнения
облегчает организацию технических аспектов тестирования
помогает организовать и скоординировать усилия сотрудников, разрабатывающих и тестирующих программный продукт
повышает эффективность и полноту тестирования
документация должна быть не объемной, а эффективной. Любые составляющие плана, не помогающие в поиске ошибок и организации тестирования, являются пустой тратой ресурсов

Слайд 11

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

разработкой его плана)
Первый этап - начальная разработка:
Проработка спецификации / пользовательской документации
Первая версия списка функций программы (полнота списка определяет полноту тестирования) (список будет постепенно расширяться)
Анализ входных данных и ограничений (простейший анализ граничных условий)

Слайд 12

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

программы, тем больше их там же)
Наиболее заметные ошибки (пользователю)
Наиболее часто используемые области программы
Отличительные особенности программы (то, что отличает от конкурентов)
Самые сложные аспекты для тестирования
Самые понятные функциональные области

Слайд 13

Компоненты тестового плана
списки таблицы планы матрицы
отчетов и экранных форм
вх. и вых. переменных
возможностей

и функций
файлов
сообщений об ошибках
совместимого оборудования
совместимых программ
публикуемых документов
конфигураций совместимой операционной среды
перечень материалов

отчетов
вх. и вых. значений
ввода-вывода
решений
клавиатурных комбинаций
совместимых принтеров
диаграмма граничных значений
диаграмма потоков данных

иерархический список функций

Слайд 14

Матрицы:
аппаратной и программной совместимости
аппаратных конфигураций
операционных окружений
комбинаций входных значений
сообщений об ошибках и

клавиатурных комбинаций

Источники материалов:
спецификация
заметки разработчиков
черновики руководства пользователя и другой документации
устные беседы с руководством и программистами
результат собственного опыта, полученного в ходе экспериментов над программой

Слайд 15

Пример таблицы ввода-вывода

Слайд 16

Иерархический список функций системы
Перечень всех высокоуровневых действий пользователя
Подфункции всех функций (все

доступные опции и варианты)
Детализация до элементарных логических действий программы
Перечислить входные и выходные условия для каждой функции и подфункции
Список всех способов диалога с программой при выполнении каждой из функций (клавиатура, мышь)

Каждая строка этого списка в конце концов преобразуется в тестовый пример

Слайд 17

Разделы тестового плана по стандарту
идентификатор
введение
тестируемые элементы (программные компоненты, подлежащие тестированию)
тестируемые функции
нетестируемые

функции
подход к тестированию (кто, виды работ, технологии и средства, критерии, крайние сроки)
критерии прохождения тестов
документация
необходимое оборудование
календарный план
ответственность
…

Слайд 18

Структура Test specification
Как у обычного проектного документа:
Заголовок
Авторы
История модификации
Логотипы
Сведения о степени

конфиденциальности
Содержание
Введение
Фактическая часть – тестовые примеры (test cases)

Слайд 19

Test Specification – обязательный документ
Test Specification – документ, обязательный к исполнению:

все, что там написано – д.б. выполнено
Оптимизация Test Specification – одна из основных задач
Вообще набор видов тестирования содержится в Test Plan’е

Слайд 20

Пример Test specification

Слайд 21

Структура Test Log – основные поля
Список тестовых примеров
Список версий продукта (билдов)
Отметки

об успешном или неуспешном прохождении

Слайд 22

Пример Test Log

Слайд 23

Структура Test Log – дополнительные поля
Разбиение по платформам, конфигурациям, средам выполнения,

...
Приоритеты
Группы и подгруппы
Детализация результатов выполнения
Критический/некритический/косметический
Номер ошибки в системе сопровождения ошибок
Комментарии относительно хода выполнения

Слайд 24

Выводы по результатам проведения тестирования
Тестирование пройдено/не пройдено (для билда)
Статистика:
Время выполнения
В среднем

на тестовый пример (возможно доп. разбивка по подгруппам)
На каждый билд
На последний билд
На каждой платформе
Процент покрытия функциональности/тестовых примеров
по каждому билду
По каждой платформе
По последнему тестируемому билду
.......

Слайд 25

Примеры отчетов (Терехов А.А.)
Такие отчеты могут выполнять две основных функции:
фиксировать состояние

в данной контрольной точке, т.е. отчет отвечает на вопрос вида "да или нет'' — выполнены необходимые для этой точки условия или нет;
показывать динамику процесса и переход от одной его фазы к другой, т.е. отчет предоставляет информацию для принятия решения о возможности перехода от одного этапа процесса к последующему.

Слайд 26

Разработка тестовых примеров (ТС)

Слайд 27

Структура тестового примера (test case) - основное
Идентификатор
Название
Автор
Название проекта
Цель
Ссылки
Среда выполнения
Пошаговое описание
Критерий выполнения

Слайд 28

Структура тестового примера – дополнительные поля
Краткое описание
Полное описание
Метка (для конфигурационного

менеджмента)
Приоритет
Статус
Название модуля

Слайд 29

Test case 16.1.1 Security – Login Form

Слайд 30

Слайд 31

Слайд 32

Слайд 33

Документирование как основа тестирования

Содержание

Проблемы терминологииВ современной IT-промышленности терминология, касающаяся QA и тестирования, весьма запутанапример:

Определение теста – IEEEТЕСТ – набор, состоящий из одного или нескольких

Другое определение тестаВ настоящее время широко используется термин test case (тестовый

Типичный набор документов(IEEE Std 829-1998)Функциональная спецификация (Functional specification, FS)Спецификация программных требований

«Классический» проект: разработка и кодирование

«Классический» проект: тестирование

Пример Functional Specification

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

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

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

Компоненты тестового планасписки таблицы планы матрицыотчетов и экранных формвх. и вых. переменныхвозможностей

Матрицы:аппаратной и программной совместимостиаппаратных конфигурацийоперационных окруженийкомбинаций входных значенийсообщений об ошибках и

Пример таблицы ввода-вывода

Иерархический список функций системыПеречень всех высокоуровневых действий пользователяПодфункции всех функций (все

Структура Test specificationКак у обычного проектного документа: ЗаголовокАвторыИстория модификацииЛоготипыСведения о степени

Test Specification – обязательный документTest Specification – документ, обязательный к исполнению: