1 Документирование как основа тестирования. - презентация

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

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

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

4 4 Типичный набор документов (IEEE Std ) Функциональная спецификация (Functional specification, FS) Спецификация программных требований (Software requirement specification, SRS) Traceability matrix (матрица прослеживаемости) Тест-план (Test plan, test strategy - TP) Тестовая спецификация (Test specification, TS) Test cases, Тестовые процедуры Test log Bug report

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

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

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

8 8 Пример Functional Specification

9 Определение объемов тестовых работ Тестируйте в первую очередь требования с наивысшим приоритетом Тестируйте новые функциональные возможности и программный код, который изменялся Используйте разбиение на эквивалентные классы и анализ граничных значений Тестируйте те участки, в которых наиболее вероятно присутствие проблем Сосредоточьте свое внимание на функциях и конфигурациях, с которыми наиболее часто будет иметь дело конечный пользователь Павловская Т.А. (СПбГУ ИТМО) 9

10 10 Тестовый план Это документ, включающий: объем ресурсы календарный план работ по тестированию выполняемые тесты тестируемые элементы задачи тестирования ответственные сотрудники вероятность возникновения непредвиденных обстоятельств и меры, которые потребуется при этом принимать (стандарт ANSI/IEEE for Software Test Documentation)

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

12 Павловская Т.А. (СПбГУ ИТМО) 12 Составление тест-плана

13 13 Совершенствование тестового плана Как правило, применяется эволюционный подход (проведение тестирования параллельно с разработкой его плана) Первый этап - начальная разработка: 1. Проработка спецификации / пользовательской документации 2. Первая версия списка функций программы (полнота списка определяет полноту тестирования) (список будет постепенно расширяться) 3. Анализ входных данных и ограничений (простейший анализ граничных условий)

14 14 Направления развития плана 1. Наиболее вероятные ошибки (чем больше ошибок обнаружено в некоторой области программы, тем больше их там же) 2. Наиболее заметные ошибки (пользователю) 3. Наиболее часто используемые области программы 4. Отличительные особенности программы (то, что отличает от конкурентов) 5. Самые сложные аспекты для тестирования 6. Самые понятные функциональные области

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

16 16 Матрицы: аппаратной и программной совместимости аппаратных конфигураций операционных окружений комбинаций входных значений сообщений об ошибках и клавиатурных комбинаций Кроме того, ведется матрица прослеживаемости требований (отображение каждого требования на тест-кейсы).

17 17 Пример таблицы ввода-вывода Входная переменнаяВыходная переменнаяСвязь Цена_товара Цена_товара_в_счете = Цена_товара Общая_стоимость Сумма стоимостей заказанных товаров Налог_с_продаж7% от Общая_стоимость

18 18 Иерархический список функций системы 1. Перечень всех высокоуровневых действий пользователя 2. Подфункции всех функций (все доступные опции и варианты) 3. Детализация до элементарных логических действий программы 4. Перечислить входные и выходные условия для каждой функции и подфункции 5. Список всех способов диалога с программой при выполнении каждой из функций (клавиатура, мышь) Каждая строка этого списка в конце концов преобразуется в тестовый пример

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

20 20 Test Specification – обязательный документ Test Specification – документ, обязательный к исполнению: все, что там написано – д.б. выполнено Оптимизация Test Specification – одна из основных задач Вообще набор видов тестирования содержится в Test Planе

21 21 Структура Test specification Как у обычного проектного документа: Заголовок Авторы История модификации Логотипы Сведения о степени конфиденциальности Содержание Введение Фактическая часть – тестовые примеры (test cases)

22 22 Пример Test specification Более подробно о создании тест-кейсов - далее

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

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

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

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

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

28 Пример ТС 28

29 29 Структура тестового примера (ТС) - основное Идентификатор (уникальный) Название Автор Название проекта Цель (идея ТС, краткое описание) Ссылки (в т.ч. на спецификацию) Среда выполнения (setup & additional info) Пошаговое описание Критерий выполнения (ожидаемый результат)* * Лучше, когда ожидаемый результат один, но м.б. и несколько.

30 30 Структура тестового примера – дополнительные поля Журнал изменений (created… modified… change…) Метка (для конфигурационного менеджмента) Краткое описание Полное описание Приоритет Статус (new, modified, retired) Название модуля

31 Улучшение поддерживаемости тест-кейса 1. Сделать тест-кейс data-driven ( по возможности вынести конкретные данные в «шапку», чтобы их было легко изменить ). 2. Не описывать шаги по явно очевидным сценариям ( например, логин, если проверяется не он ). 3. Не давать конкретных деталей, если они не играют роли при исполнении тест-кейса ( например, имя товара ). 4. Вынести во внешний документ повторяющиеся сценарии ( например, семь шагов оплаты ). (из Р. Савина) 31

32 Пример 32 Другое оформ ление ТС

33 К чему необходимо стремиться при создании ТС 1. Независимость тест-кейсов друг от друга ( отсутствие ссылок на другие тест-кейсы; независимость от "следов", оставленных другими тест-кейсами в ПО или базе данных ) 2. Четкая формулировка шагов ( хороший ТС может без труда воспроизвести другой человек, а также вы сами через год; излишние детали тоже ни к чему). 3. Четкая формулировка идеи и/или ожидаемого результата ( ожидаемый результат это информация, на основании которой, вкупе с фактическим результатом, принимается решение об исходе тест-кейса. Следовательно, точность и четкость в формулировке ожидаемого результата играют важнейшую роль. Не рекомендуется отсылка к внешнему документу ). 33

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

35 35 Примеры тест-кейсов ##Test point / Description CTC#1.19 Location register verification Description: TC is to verify data from Location register. PURPOSE: To verify data from Location register, check values and the type of fields. DataSet: DDEMO2 1.Open Location register: Registers->Location data->Location 2.Add Location by pressing add button. Take values from below table. Write value. 3.Press Save button 4. Repeat this test case with min, max and invalid values. 3.Close Location register by pressing Exit button. 4.End.

36 36 ##Test point / DescriptionComment CTC#1.1 Date of closing the books register verification Description: TC intended to verify data from Date of closing the books register with min, max and invalid value. PURPOSE: To verify data of Date of closing the books register, check values and the type of fields. DataSet: DDEMO2 Language is English in General and Unit settings. The user identifier and password is Open Date of closing the books register: Registers->Date of closing the books The Last Date of closing the books is Add Date of closing the books register by pressing add button. Date of closing the books = Press Save button 4.Press Cancel button 5.Add Date of closing the books register by pressing add button. Date of closing the books = Press Save button 7.Press Delete button 8.Add Date of closing the books register by pressing add button. Date of closing the books = Press Save button 10.Press Delete button 11.Close Date of closing the books register by pressing Exit button. 12End

37 37 Test point / DescriptionTes ted Error /r Req. Comment CTC# Security – Login form Description: TC is intended to verify the new Login form of ZZZZZ application Predefined conditions: User 1111 with password = 1111 exists in the system Run ZZZZZ applicationLogin form should be displayed - Check that the correct caption is written in the main frame of the application: Economa Fixed Assets ZZZZZ Check that the form caption is Login Select Windows authenticationCheck that Login name and Password fields are disabled Select SQL Server authenticationCheck that Login name and Password fields are enabled

38 38 Press More >> buttonCheck that the hidden fields are displayed: - SQL server; - Database Check that label More>> is changed to label

39 39 Change the name of the server to the nonexistent one, for example add 1 to the end of the server name Press OK button Wait… The error message box should be displayed: Wrong SQL Server name! [server doesnt exist or…] (the language of the text in the [] depends on the regional settings) Press OK button in the error message Change the name of the server to the correct one Change the name of the database to the nonexistent one, for example add 1 to the end of the database name Press OK button Wait… The error message box should be displayed: Wrong database name! Press OK button in the error message

40 40 Change the name of the server to the correct one Press OK button You are successfully logged into the ZZZZZ application Open Settings | User IDs form Create new user: Press Add button - Select Windows authentication - Register: DOMAIN\LOGIN_NAME, for example: ARCADIA\Natasha – where ARCADIA is the name of the domain, Natasha is the name of the login to this domain (Please register the domain and user name correctly to your situation) Register User Name = TEST USER for LOGIN Press Save button Close the User Ids form with Exit button Close ZZZZZ application Run ZZZZZ application Select Windows authentication Press OK buttonYou are successfully logged into the ZZZZZ application End

41 Тест-комплект (test case suite) Совокупность тест-кейсов, которые проверяют: - какую-то определенную часть проекта (например, "Оплату") - и/или определенный спек (например, спек номер 1455 "Рассылка пользователям е-мейлов на основании истории заказов"). - Обычно располагается в одном файле. 41

42 Домашнее задание Прочитать: Савин - с , , Канер - гл. 7, Калбертсон – с , гл. 15. Скачать с сайта pta-ipm.narod.ru примеры ТС и изучить их Разработать не менее 6 тест-кейсов различной сложности для BugPad: язык - английский. форма таблиц – аналогичная примерам. Срок выполнения – до зачетной недели. Темы «Тестирование белого ящика» и «Автоматизация тестирования» – самостоятельно. Те, кому нужен зачет по УИРС, должны в дополнение к двум заданиям (баги и тест-кейсы) написать итоговый тест (на зачетной неделе или ранее, как скажете). 42