юзабилити тестирование. Юзабилититестирование программного обеспечения
 Скачать 3.74 Mb.
|
|
Лабораторная работа №4 Тестирование программного обеспечения: разработка тестов Цель: разработать рабочую тестовую документацию для тестирования web- приложения. План занятия: 1. Изучить теоретические сведения. 2. Выполнить практическое задание по лабораторной работе. 3. Оформить отчет и ответить на контрольные вопросы. Теоретические сведения Рабочая тестовая документация значительно улучшает качество последующе- го тестирования за счет анализа и детального планирования тестов. После завер- шения тестирования наличие тестовой документации позволяет оценить, насколь- ко успешно были проведены все этапы тестирования, а для заказчика является подтверждением реального объема работ. Рабочую тестовую документацию тестировщик может разрабатывать исклю- чительно на основе спецификации еще до поставки программного обеспечения. В этом случае после поставки на тестирование версии программного продукта спе- циалист по тестированию может сразу приступить к поиску дефектов. Существуют следующие виды рабочей тестовой документации (таблица 4.1): 1. Check List. 2. Acceptance Sheet. 3. Test Survey. 4. Test Cases. Основные факторы выбора тестовой документации – сложность бизнес- логики проекта, сроки проекта, размер команды и объем проекта. На одном проекте могут комбинироваться несколько типов тестовой доку- ментации. Например, для всего проекта составлен Acceptance Sheet, но для наибо- лее сложных частей составлены Test Cases. Если какие-либо модули программно- го продукта будут подвергаться автоматизированному тестированию, то для таких модулей в обязательном порядке составляются Test Cases. 31 Таблица 4.1 – Виды рабочей тестовой документации и их характеристика Тип документации Что описывают Когда используют Check List Вспомогательный тип документации, содержащий список основных проверок Для типовой функци- ональности Acceptance Sheet Перечень всех модулей и функций при- ложения, подлежащих проверке Небольшие (до 3 меся- цев), простые по бизнес- логике проекты Test Survey Перечень всех модулей и функций при- ложения, а также конкретные проверки для них. Может содержать ожидаемый результат Средние или большие проекты с понятной бизнес-логикой Test Cases Перечень всех модулей и функций при- ложения, а также конкретные проверки для них. Каждая проверка содержит набор входных значений, предусловий, шагов выполнения и ожидаемых резуль- татов. Всегда приводятся ожидаемые результа- ты для каждого шага проверки Большие и долгосроч- ные проекты, проекты со сложной бизнес- логикой, проекты с большой командой При составлении рабочей тестовой документации необходимо указать номер тестируемой сборки, тип выполняемой тестовой активности, период времени те- стирования, ФИО тестировщика, тестовое окружение (операционная система, браузер и др.). Рабочая тестовая документация представляет собой перечень всех проверок для модулей/подмодулей приложения. В качестве одного модуля, как правило, выступает рабочее окно приложения, в качестве подмодулей – логически завер- шенные блоки этого окна. Для каждого модуля в обязательном порядке выполняется тестирование GUI, а также общие функциональные проверки (General) для любого типа приложения (навигация, скроллинг, табуляция и др.). Далее в рамках модуля формулируются проверки соответствия функционала приложения требованиям, заявленным в спе- цификации. Степень детализации каждой из таких функциональных проверок за- висит от выбранного типа тестовой документации (Acceptance Sheet, Test Survey, Test Cases). В частности, для Acceptance Sheet все проверки только перечисляют. Для Test Survey для каждого элемента прописывают позитивные и негативные проверки, источником которых могут служить базовые проверки (в виде чеклиста) 32 для соответствующих элементов GUI. Для Test Cases каждую из позитивных и негативных проверок описывают в виде последовательности шагов с указанием ожидаемого результата. Для Test Survey напротив каждой проверки указывается глубина тестирования: Smoke, MAT, AT. Для Acceptance Sheet в качестве глубины тестирования всегда указывается AT. Примеры фрагментов рабочей тестовой документации Check List, Acceptance Sheet, Test Survey приведены в таблице 4.2. Таблица 4.2 – Примеры Check List, Acceptance Sheet, Test Survey Вид рабочей тестовой документации Пример Глубина тестиро- вания 1 2 3 Check List Протестировать форму авторизации Acceptance Sheet Форма авторизации: 1. GUI. 2. General. 3. Поле «Эл. адрес». 4. Поле «Пароль». 5. Кнопка «Войти». 6. Чек-бокс «Не выходить из системы». 7. Ссылка «Забыли пароль» AT AT AT AT AT AT AT Test Survey Форма авторизации: 1. GUI. 2. General. 3. Валидный эл. адрес + валидный пароль. 4. Валидный эл. адрес с пробелами в начале и в конце + валидный пароль с пробелами в начале и в конце. 5. Валидный эл. адрес с пробелами в середине + ва- лидный пароль с пробелами в середине. 6. Валидный эл. адрес минимально допустимой дли- ны + валидный пароль минимально допустимой дли- ны. 7. Валидный эл. адрес максимально допустимой дли- ны + валидный пароль максимально допустимой длины. 8. Пустое поле эл. адреса + пустое поле пароля. AT AT Smoke MAT MAT MAT MAT AT 33 Продолжение таблицы 4.2 1 2 3 9. Валидный эл. адрес + невалидный пароль (спец- символы). 10. Валидный эл. адрес + невалидный пароль (русские буквы). 11. Валидный эл. адрес + невалидный пароль (длина превышает максимально допустимую). 12. Валидный эл. адрес + невалидный пароль (длина меньше минимально допустимой). 13. Невалидный эл. адрес (спецсимволы кроме ’_’, ’-’, ’@’, ’. ’) + валидный пароль. 14. Невалидный эл. адрес (русские буквы) + валидный пароль. 15. Невалидный эл. адрес (использование символа ’@’ дважды) + валидный пароль. 16. Невалидный эл. адрес (отсутствие символа ’.’) + валидный пароль. 17. Невалидный эл. адрес (длина превышает макси- мально допустимую) + валидный пароль. 18. Невалидный эл. адрес (длина меньше минимально допустимой) + валидный пароль. 19. Запомнить данные: выйти из системы и зайти об- ратно. 20. Ссылка «Забыли пароль» АТ АТ AT AT AT AT AT AT AT AT MAT MAT Тест-кейс (таблица 4.3) – набор входных данных, условий выполнения и ожи- даемых результатов, разработанный с целью проверки того или иного свойства или поведения программного средства. Под тест-кейсом также понимают соответствующий документ, представляю- щий формальную запись тест-кейса. Высокоуровневый тест-кейс – тест-кейс без конкретных входных данных и ожидаемых результатов. Как правило, ограничивается общими идеями и операци- ями, схож по своей сути с подробно описанными пунктами чек-листа. Низкоуровневый тест-кейс – тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой полностью готовый к выполне- нию тест-кейс и является наиболее классическим видом тест-кейсов. Начинающих тестировщиков чаще всего учат писать именно такие тесты, т. к. прописать все 34 данные подробно намного проще, чем понять, какой информацией можно прене- бречь, при этом не снизив ценность тест-кейса. В зависимости от внутренних шаблонов компании и инструмента управления тест-кейсами внешний вид их записи может немного отличаться (могут быть до- бавлены или убраны отдельные поля), но концепция остается неизменной. Общая структура тест-кейса включает (см. таблицу 4.3): идентификатор; связанное с тест-кейсом требование; модуль и подмодуль приложения; заглавие тест-кейса; исходные данные, приготовления к тест-кейсу; шаги тест-кейса; ожидаемые результаты по каждому шагу тест-кейса. Таблица 4.3 – Пример Test Case Номер тест- кейса Прио- ритет Требо- вание Модуль Под- модуль Описание тест- кейса Ожидаемые ре- зультаты 18 А REQ3.7 Главная страница Форма автори- зации Авторизация с помощью ва- лидного эл. ад- реса и валид- ного пароля. 1. Ввести в по- ле «Эл. адрес» abc@mail.ru. 2. Ввести в по- ле «Пароль» qwerty. Нажать кнопку «Войти» 1. В поле «Эл. адрес» отобра- жается abc@mail.ru. 2. В поле «Па- роль» отобража- ется qwerty. Осуществляется переход на до- машнюю стра- ницу пользова- теля abc@mail.ru, qwerty Идентификатор представляет собой уникальное значение, позволяющее одно- значно отличить один тест-кейс от другого и используемое во всевозможных ссылках. В общем случае идентификатор тест-кейса может представлять собой просто уникальный номер, но (если позволяет инструментальное средство управ- ления тест-кейсами) может включать префиксы, суффиксы и иные осмысленные 35 компоненты, позволяющие быстро определить цель тест-кейса и часть приложе- ния (или требований), к которой он относится. Приоритет показывает важность тест-кейса. Он может быть выражен буквами (A, B, C, D, E), цифрами (1, 2, 3, 4, 5), словами («крайне высокий», «высокий», «средний», «низкий», «крайне низкий») или иным удобным способом. Количество градаций также не фиксировано, но чаще всего лежит в диапазоне от трех до пяти. Приоритет тест-кейса может коррелировать с важностью требования, с которым связан тест-кейс; потенциальной важностью дефекта, на поиск которого направ- лен тест-кейс. Основная задача этого атрибута – упрощение распределения вни- мания и усилий команды, а также упрощение планирования и принятия решения о том, чем можно пожертвовать в некоей форс-мажорной ситуации, не позволяю- щей выполнить все запланированные тест-кейсы. Связанное с тест-кейсом требование показывает то основное требование, проверке выполнения которого посвящен тест-кейс. Наличие этого поля улучшает такое свойство тест-кейса, как прослеживаемость. При этом следует отметить, что некоторые тест-кейсы могут разрабатываться вне прямой привязки к требованиям. Хоть такой вариант и не считается хорошим, он достаточно распространен. Модуль и подмодуль приложения указывают на части приложения, к кото- рым относится тест-кейс, и позволяют лучше понять его цель. Идея деления при- ложения на модули и подмодули проистекает из того, что в сложных системах практически невозможно охватить взглядом весь проект целиком. Тогда приложе- ние логически разделяется на компоненты (модули), а те, в свою очередь, на более мелкие компоненты (подмодули). Для таких небольших частей приложения разра- ботать тест-кейсы становится намного проще. Как правило, иерархия модулей и подмодулей создается как единый набор для всей проектной команды, чтобы ис- ключить путаницу из-за того, что разные люди будут использовать разные подхо- ды к такому разделению или даже просто разные названия одних и тех же частей приложения. Модули и подмодули можно выделять на основе графического ин- терфейса пользователя (крупные области и элементы внутри них), на основе ре- шаемых приложением задач и подзадач и т. д. Главное, чтобы эта логика была одинаковым образом применена ко всему приложению. Заглавие тест-кейса призвано упростить быстрое понимание основной идеи тест-кейса без обращения к его остальным атрибутам. Именно это поле является наиболее информативным при просмотре списка тест-кейсов. Заглавие тест-кейса должно быть информативным, уникальным. Исходные данные, необходимые для выполнения тест-кейса, позволяют опи- сать все то, что должно быть подготовлено до начала выполнения тест-кейса, 36 например, состояние базы данных, состояние файловой системы и ее объектов, со- стояние серверов и сетевой инфраструктуры. Шаги тест-кейса описывают последовательность действий, которые необхо- димо реализовать в процессе выполнения тест-кейса. Общие рекомендации по написанию шагов таковы: не пишите лишних начальных шагов (запуск приложения, очевидные опе- рации с интерфейсом и т. п.); даже если в тест-кейсе всего один шаг, нумеруйте его; если вы пишете на русском языке, используйте безличную форму (напри- мер, «открыть», «ввести», «добавить» вместо «откройте», «введите», «добавьте»); соотносите степень детализации шагов и их параметров с целью тест-кейса, его сложностью, уровнем и т. д.; в зависимости от этих и многих других факторов степень детализации может варьироваться от общих идей до предельно четко про- писанных значений и указаний; ссылайтесь на предыдущие шаги и их диапазоны для сокращения объема текста (например, «повторить шаги 3–5 со значением…»); пишите шаги последовательно, без условных конструкций вида «если… то…». Ожидаемые результаты по каждому шагу тест-кейса описывают реакцию приложения на действия, описанные в поле «шаги тест-кейса». Номер шага соот- ветствует номеру результата. По написанию ожидаемых результатов можно поре- комендовать следующее: описывайте поведение системы так, чтобы исключить субъективное толко- вание (например, вместо недопустимого «приложение работает верно» следует писать «появляется окно с надписью…»); пишите ожидаемый результат по всем шагам без исключения, даже если результат некоего шага будет совершенно тривиальным и очевидным; пишите кратко, но не в ущерб информативности; избегайте условных конструкций вида «если… то…». Наличие тест-кейсов позволяет: структурировать и систематизировать подход к тестированию; вычислять метрики тестового покрытия и принимать меры по его увеличе- нию; отслеживать соответствие текущей ситуации плану (сколько примерно по- надобится тест-кейсов, сколько уже есть, сколько выполнено и т. д.); уточнить взаимопонимание между заказчиком, разработчиками и тести- ровщиками (тест-кейсы зачастую намного более наглядно показывают поведение приложения, чем это отражено в требованиях); 37 хранить информацию для длительного использования и обмена опытом между сотрудниками и командами; проводить регрессионное тестирование и повторное тестирование; повышать качество требований. Далее рассмотрим подробно базовые проверки графического интерфейса пользователя и функциональности web-, desktop- и mobile-приложений. Для любого приложения выполняется тестирование графического интерфейса пользователя (таблица 4.4). Таблица 4.4 – Перечень основных GUI-проверок для всего приложения Название проверки Описание проверки 1 2 1. Правописание Лексические, грамматические и пунктуационные ошибки 2. Расположение и выравнивание Выравнивание по левому или правому краю (в зависи- мости от требований приложения), отступы, идентич- ность расстояний между названием и полем. Корректное расположение текста, длинный текст не вы- ходит за границы поля при вводе 3. Длинные названия Длинные названия корректно обрезаются с помощью многоточия в конце, при наведении возникают хинты с полнотекстовым вариантом 4. Соответствие названий форм/элементов GUI их назначе- нию Проверка названий форм/элементов GUI с точки зрения их смысловой нагрузки 5. Унификация (сти- ля, цвета, шрифта, названий) Единообразие цвета, шрифта, размеров (высо- ты/ширины), выравнивания полей, названий полей, кате- горий меню и др. в рамках всего приложения 6. Эффект «нажатия» Изменение вида ссылок, кнопок, позиций меню и др. при наведении курсора. Изменение вида курсора при наведении на ссылки, кнопки, позиции меню и др. 7. Хинты Проверка всплывающих подсказок с точки зрения пра- вописания, выравнивания, соответствия назначению 38 Продолжение таблицы 4.4 1 2 8. Сообщения об успеш- ном/неуспешном завершении дей- ствия, о под- тверждении дей- ствия Проверка верхней панели (логотипа и названия) формы с сообщением. Если присутствует кнопка «Отмена», то в правом верхнем углу формы с сообщением присутствует «крестик» для альтернативной возможности закрыть форму. Сообщения о подтверждении удаления по умолчанию ак- тивированы на кнопку «нет» 9. Изменение раз- меров окна, из- менение мас- штаба страницы Появление скроллинга при уменьшении размера окна. Сохранение взаимного расположения элементов при уменьшении окна, изменении масштаба). Перераспределение элементов с сохранением пропорций при изменении масштаба страницы Общие проверки функциональности для всех типов приложений, а также об- щие проверки для web-приложений приведены в таблицах 4.5, 4.6. Таблица 4.5 – Перечень общих проверок функциональности для любого типа приложения Название проверки Описание проверки 1. Табуляция Перемещение с помощью клавиатуры должно осуществ- ляться сверху вниз слева направо. Недоступные поля должны пропускаться 2. «Хлебные крош- ки» «Хлебные крошки» – элемент навигации, являющийся признаком удобства пользования приложением в целом и перемещением по его структуре 3. Скроллинг Отсутствие скроллинга в случае, если текст вмещается на странице без прокрутки. Соответствующее изменения текста при использовании скроллинга. Возможность изменения положения скроллинга при по- мощи мыши, кнопок Page up/down, Home/End 4. Взаимосвязь ком- понентов Поведение одного компонента при изменении/удалении другого (например, при удалении категории товара не должны удаляться все товары в этой категории) 5. Фокус на кнопке для исполнения действий Ввод данных → нажатие Enter → действие осуществи- лось 39 Таблица 4.6 – Перечень общих проверок функциональности для web-приложений Название проверки Описание проверки 1. Подготовка к тести- рованию Перед тестированием каждой новой сборки необхо- димо осуществить очистку кэша и cookies. Для этого можно воспользоваться приложением CСleaner 2. 404 Error Переход по некорректному адресу должен вести на страницу с Error 404, а не на страницу Page cannot be found, например. Страница Error 404 должна быть ре- ализована в общем дизайне тестируемого приложения 3. Логотип Логотип должен быть ссылкой на главную страницу 4. Email-нотификации Проверка работоспособности отправки email- нотификаций (как администратору, так и пользовате- лю), если только отсутствие писем не является спе- цификой проекта 5. Отображение flash- элементов при от- ключенном или не- установленном в браузере flash-плеере Пользователю должно быть предложено скачать и установить последнюю версию flash-плеера; на месте flash-объекта должно отображаться альтернативное изображение 6. Проверка работоспо- собности приложе- ния при отключен- ном JavaScript Основная функциональность и навигация должна ра- ботать В таблицах 4.7–4.16 приведены основные проверки для элементов пользова- тельского интерфейса: поле для ввода данных, поле для загрузки файлов, поле для ввода даты, поле со списком/выпадающий список, кнопка, радиобаттон, чек-бокс, меню, таблица, календарь, ссылка, сообщения, поп-ап (всплывающие окна). 40 Таблица 4.7 – Перечень основных проверок для поля ввода данных Functional Test GUI Test 1. Обязательность ввода. 2. Обработка только пробелов. 3. Использование пробелов в тексте: 3.1. Пробелы в начале и в конце строки должны отсекаться при сохранении. 3.2. Пробелы внутри текста отсекаться не долж- ны. 4. Минимально/максимально допустимое количе- ство символов. 5. Формат данных (исходя из его логического назначения и требований приложения). 6. Формат числовых данных (если допускаются): негативные, дробные с точкой и запятой. 7. Использование специальных символов (введен- ные символы должны отобразиться в том же ви- де, в котором они были введены, если только ввод специальных символов не запрещен требо- ваниями приложения). 8. Возможность редактирования введенных значе- ний. 9. Корректное распределение текста по строкам (переход на новую строку автоматически). 10. Уникальные данные (например, уникальность логина, email). 11. Автоматическая постановка курсора в первое поле для ввода при открытии формы. 12. Ввод тегов и скриптов (введенные теги и скрип- ты должны отобразиться в том же виде, в кото- ром они были введены) 1. Название поля (право- писание, соответствие названия тематике мо- дуля/страницы). 2. Выравнивание назва- ний полей (выравнива- ние по левому или пра- вому краю в зависимо- сти от требований при- ложения, отступы, идентичность расстоя- ний между названием и полем). 3. Корректное расположе- ние текста, длинный текст не выходит за границы поля при вво- де. 4. Унификация дизайна по отношению ко всему приложению (цвет, шрифт, размер (высо- та/ширина), выравни- вание полей). 5. Расположение вводи- мого текста внутри по- ля (унификация, вырав- нивание) Таблица 4.8 – Перечень основных проверок для поля загрузки файлов Functional Test GUI Test 1 2 1. Обязательность выбора файла. 2. Форматы: корректные/некорректные. 3. Корректный формат, но отсутству- ет/модифицировано расширение. 1. Унификация дизайна по отношению ко всему приложению (цвет, шрифт, высота/ширина). 41 Продолжение таблицы 4.8 1 2 4. Ограничения на размер (включая загрузку файлов нулевого размера, большого размера).Загрузка исполняемых файлов (EXE, PHP, JSP др.). 5. Загрузка переименованного EXE-файла. 6. Путь к файлу меньше 259 символов. 7. Путь к файлу равен 260 символов. 8. Путь к файлу больше 260 символов. 9. Корректный путь введен с клавиатуры. 10. Имитировать сбой загрузки (например, с использованием flash-накопителя). 11. Одновременная загрузка нескольких файлов 2. Выравнивание названий загружен- ных файлов Таблица 4.9 – Перечень основных проверок для радиобаттона Functional Test GUI Test 1. Функциональность: включение/выключе- ние. 2. Не может быть меньше двух радиокнопок. 3. По умолчанию одна радиокнопка должна быть включена. 4. Не может быть включено более одной ра- диокнопки. 5. При переходе на следующую страницу и возвращении назад выбранная радиокноп- ка не должна сбрасываться. 6. Активация путем нажатия как на символ, так и на текст 1. Унификация дизайна по от- ношению ко всему приложе- нию. 2. Выравнивание расположения радиокнопки с соответству- ющим названием. 3. Выравнивание расположений радиокнопок. 4. Изменение радиокнопки при наведении курсора. 5. Изменение курсора при наведении на радиокнопку Таблица 4.10 – Перечень основных проверок для чек-боксов Functional Test GUI Test 1 2 1. Функциональность: включение/выключе- ние. 2. Наличие дополнительного чек-бокса, вы- ставляющего/снимающего все чекбоксы при наличии больше 10 чек-боксов. 1. Унификация дизайна по от- ношению ко всему приложе- нию. 2. Выравнивание расположения чек-бокса с соответствую- щим названием. 42 Продолжение таблицы 4.10 1 2 3. При переходе на следующую страницу и возвращении назад выбранный чек-бокс не должен сбрасываться. 4. Активация путем нажатия как на символ, так и на текст 3. Изменение чек-бокса при наведении курсора. 4. Изменение курсора при наведении на чекбокс Таблица 4.11 – Перечень основных проверок для поля со списком Functional Test GUI Test 1. Сортировка по алфавиту или по смыслу. 2. В случае, если значения выходят за грани- цы списка и нет возможности увеличения размера списка, то необходимо отображе- ние хинтов (всплывающих подсказок). 3. Выбор пункта списка по нажатии соответ- ствующей первой буквы на клавиатуре. 4. Возможность введения значений вручную (если это позволяет приложение). 5. Возможность выбора значения из списка как с помощью мыши, так и с клавиатуры 1. Правописание. 2. Подсветка при выборе каж- дого из значений, при выборе нескольких значений одно- временно. 3. Унификация дизайна (цвет, шрифт, размер (высо- та/ширина), цвет подсветки, выравнивание) Таблица 4.12 – Перечень основных проверок для меню Functional Test GUI Test 1. Осуществление соот- ветствующего пере- хода при выборе пункта меню. 2. Визуальное различие в момент работы на определенной вклад- ке (подсветка, под- черкивание) 1. Подсветка категории меню при наведении курсо- ра. 2. Изменение курсора при наведении на категорию меню. 3. Если в данный момент выполняется работа в вы- бранной вкладке, то в меню она отличается визу- ально и является неактивной. 4. Совпадение названий категорий меню в случае, если меню дублируется в нескольких местах 43 Таблица 4.13 – Перечень основных проверок для ссылки Functional Test GUI Test 1. Функционирование ссылки (должен осуществиться пе- реход на соответствующую страницу). 2. Переход по загруженной ссылке должен осуществ- ляться в новой вкладке или во всплывающем окне. 3. Форматы ссылок и префик- сов. 4. Срабатывание ссылки толь- ко при нажатии на саму ссылку, а не на пустую об- ласть возле нее 1. Унификация стилей (в соответствии с ди- зайном сайта). 2. Расположение ссылок (в соответствии с ди- зайном сайта). Например, расположение всех ссылок слева или справа от элементов. 3. Названия (унификация, идентичность назва- ний ссылок одинакового назначения, спел- линг, соответствие с открытым модулем или страницей, вместимость названия ссылки в отведенном блоке). 4. Изменение вида курсора при наведении на ссылку. 5. Изменение вида ссылки при наведении кур- сора (подчеркивание) Таблица 4.14 – Перечень основных проверок для таблицы Functional Test GUI Test 1. При появлении нескольких страниц есть кнопки Вперед, Назад, На первую, На по- следнюю страницу (пагина- ция). 2. Проверка сортировок, в том числе сортировки по умол- чанию. 3. Обновление значений таб- лицы после добавления, из- менения, удаления данных. 4. Единичное/множественное выделение нескольких зна- чений 1. Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), вы- равнивание). 2. Название (соответствие с текущим модулем, спеллинг). 3. Выравнивание значков сортировки в назва- нии колонок. 4. Выравнивание названий колонок, значений внутри таблицы. 5. Корректное отображение длинных названий (соответствующие переходы на новые стро- ки, сокращение названий (появление много- точия либо сокращение по слову). 6. Корректное отображение данных после ис- пользования сортировки (размеры колонок и столбцов фиксированы, текст не разбивает структуру таблицы) 44 Таблица 4.15 – Перечень основных проверок для календаря Functional Test GUI Test 1. Ввод даты с помощью календаря. 2. Ввод даты вручную: разные форма- ты, номер месяца: > 12, день: > 31 (+ для февраля). 3. Логика работы поля (например, под- счет возраста после ввода даты рож- дения; невозможность ввести дату рождения свыше текущего дня) 1. Унификация дизайна для всего при- ложения (цвет, шрифт, размер (вы- сота/ширина), выравнивание). 2. Отображение календаря рядом с по- лем. 3. Корректное выравнивание всех эле- ментов и ссылок в календаре Таблица 4.16 – Перечень основных проверок для сообщений Functional Test GUI Test 1. Пользователь должен быть информирован о действиях, происходящих в системе посредством сообщений об успешном завершении операции. 2. На необратимые дей- ствия, такие как удаление, должны быть подтвер- ждающие сообщения. 3. Введенные в форму дан- ные не должны сбрасы- ваться после появления сообщения 1. Правописание сообщений. 2. Соответствие сообщений смыслу выполняемо- го действия. 3. Соответствие названий полей в сообщениях названиям полей, форм, таблиц, кнопок и т. д. 4. Унификация стилей (цвет, размер) для всего приложения. 5. Если присутствует кнопка «Отмена», то в пра- вом верхнем углу формы с сообщением при- сутствует «крестик» для альтернативной воз- можности закрыть форму. 6. Сообщения о подтверждении удаления по умолчанию активированы на кнопку «нет». 7. Соответствие цвета типу сообщения (красный для сообщений об ошибках, зеленый для со- общений об успешном завершении операции). 8. Невалидное значение не должно отображаться в сообщении об ошибке (неправильно: «Email 2309234@@mail.ru не соответствует допусти- мому формату»). 9. Согласование числительного и связанного с ним существительного (например, «1 день», «2 дня») 45 Практическое задание: 1. Получить у преподавателя спецификацию с требованиями к web- приложению. 2. В зависимости от сложности бизнес-логики web-приложения выбрать наиболее подходящий вид рабочей тестовой документации (Acceptance Sheet, Test Survey, Test Cases). 3. Анализируемое web-приложение разбить на модули и подмодули. 4. Разработать рабочую тестовую документацию для всех модулей и подмо- дулей web-приложения. 5. Указать номер тестируемой сборки, название приложения, тип выполняе- мой тестовой активности, период времени тестирования, ФИО тестировщика, те- стовое окружение (операционная система, браузер). 6. Предусмотреть проверки GUI для каждого модуля. 7. Предусмотреть общие функциональные проверки (General) для каждого модуля. 8. В рамках каждого модуля предусмотреть функциональные проверки. Сте- пень детализации каждой из функциональных проверок должна соответствовать выбранному на этапе 1 типу тестовой документации. 9. Для каждой проверки указать глубину тестового покрытия (Smoke, MAT, AT) с учетом выбранного на этапе 1 типа тестовой документации. 10. Оформить отчет и защитить лабораторную работу. Содержание отчета: 1. Цель работы. 2. Рабочая тестовая документация. 3. Выводы по работе. Контрольные вопросы: 1. Какие существуют разновидности рабочей тестовой документации? 2. Check List: что описывают и когда используют? 3. Acceptance Sheet: что описывают и когда используют? 4. Test Survey: что описывают и когда используют? 5. От чего зависит степень детализации каждой функциональной проверки? 6. Какая глубина тестирования указывается для проверок в Acceptance Sheet? 7. Какая глубина тестирования указывается для проверок в Test Survey? 8. Что такое Test Case? 9. Какова структура описания Test Case? 10. Что содержит Идентификатор в описании Test Case? 11. Что приводится в поле Приоритет описания Test Case? 46 12. Что приводится в поле Требование описания Test Case? 13. Что приводится в поле Модуль и подмодуль приложения описания Test Case? 14. Что приводится в поле Заглавие описания Test Case? 15. Что приводится в поле Исходные данные, приготовления описания Test Case? 16. Что приводится в поле Шаги описания Test Case? 17. Что приводится в поле Ожидаемые результаты описания Test Case? 18. Для чего нужны Test Cases? 19. Какие проверки выполняют при тестировании GUI? 20. Какие общие функциональные проверки выполняют для всего приложе- ния? 21. Перечислите базовые проверки для поля ввода данных. 22. Перечислите базовые проверки для поля загрузки файлов. 23. Перечислите базовые проверки для ввода даты. 24. Перечислите базовые проверки для поля со списком. 25. Перечислите базовые проверки для радиобаттона. 26. Перечислите базовые проверки для чек-бокса. 27. Перечислите базовые проверки для меню. 28. Перечислите базовые проверки для таблиц. 29. Перечислите базовые проверки для ссылок. 30. Перечислите базовые проверки для сообщений. |