Лабораторная работа 4 Тестирование программного обеспечения разработка тестов
 Скачать 435.93 Kb.
|
|
ЛАБОРАТОРНАЯ РАБОТА №4 Тестирование программного обеспечения: разработка тестов Цель работы: разработать рабочую тестовую документацию для тести- рования web-приложения. Теоретические сведения 1.1 Рабочая тестовая документация Создание тестовой документации значительно улучшает качество про- дукта за счет более тесного сотрудничества, уточнения деталей при разра- ботке плана тестирования и документации. После завершения тестирования наличие тестовой документации позволяет проверить, насколько успешно были проведены все этапы тестирования. Существует несколько разновидностей рабочей тестовой документации (таблица 1): 1. Check List 2. Acceptance Sheet 3. Test Survey 4. Test Cases Check List – высокоуровневый список проверок, набор правил и крите- риев, по которым проводится тестирование приложения. Описывает основ- ные проверки для типовой функциональности. Acceptance Sheet - документ, который содержит подробный перечень всех модулей и функций приложения, а также результаты всех тестов данных функций. Как правило, содержит статистику по наиболее важным показате- лям каждой сборки, определяющим ее качество. Test Survey - документ, который содержит подробный перечень всех модулей и функций приложения, конкретные проверки для них, а также ре- зультаты всех тестов. В некоторых случаях для проверок может быть указан ожидаемый результат. Как правило, содержит статистику по наиболее важ- ным показателям каждой сборки, определяющим ее качество. Test Cases (набор тест-кейсов) - набор входных значений, предусло- вий выполнения, ожидаемых результатов и постусловий выполнения, разра- ботанный для определенной цели или тестового условия, таких как выполне- ние определенного пути программы или же для проверки соответствия опре- деленному требованию. Основной фактор выбора тестовой документации – сложность бизнес- логики проекта. Кроме того, определяющими факторами могут быть сроки проекта, размер команды и объем проекта. На одном проекте могут комбинироваться несколько типов тестовой документации. Например, для всего проекта составлен Test Survey, но для наиболее сложных частей составлены тест-кейсы. ТАБЛИЦА 1 – ВИДЫ РАБОЧЕЙ ТЕСТОВОЙ ДОКУМЕНТАЦИИ Тип документации Что описываем Когда используем Пример Checklist Основные проверки Для типовой функцио- нальности Протестировать форму входа в почту Acceptance Sheet Части функциональности, подлежащие проверке. Небольшие, простые по бизнес-логике про- екты Часто выпоняемые те- сты (Smoke test) Форма входа на сайт Test Survey Конкретные проверки в рам- ках отдельных кусков функ- циональности. Может содержать ожидае- мый результат. Средние или большие проекты, с понятной бизнес-логикой Форма входа на сайт: - Корректные данные - Неверное имя пользователя - Неверный пароль... Test Cases Пошаговое описание, ин- струкции по тестированию. Всегда содержит ожидаемый результат. Большие и долгосроч- ные проекты, требую- щие глубоких знаний в предметной области Форма входа на сайт: 1. Откройте форму входа 2. Введите имя пользователя test1 3. Введите пароль test1 4. Нажмите кнопку «Войти» Ожидаемый результат: пользователь перехо- дит на домашнюю страницу 1.2 Тестирование web-приложения Web-приложениями будем называть любые приложения, предоставля- ющие web-интерфейс. В настоящее время такие приложения получают все большее распространение: системы управления предприятиями и драйверы сетевых принтеров, интернет-магазины и коммутаторы связи – это только небольшая часть приложений, обладающих web-интерфейсом. В отличие от обычного графического пользовательского интерфейса web-интерфейс отоб- ражается не самим приложением, а стандартизированным посредником – web-браузером. web-браузер берет на себя все взаимодействие с пользовате- лем и обращается к web-приложению только в случае необходимости. Web-приложения в первую очередь характеризуются тем, что их поль- зовательский интерфейс имеет стандартизированную архитектуру, в которой: 1) для взаимодействия с пользователем используется web-браузер; 2) взаимодействие с пользователем четко разделяется на этапы, в тече- ние которых браузер работает с одним описанием интерфейса; 3) эти этапы разделяются однозначно выделяемыми обращениями от браузера к приложению; 4) для описания интерфейса применяется стандартное представление (HTML); 5) коммуникации между браузером и приложением осуществляются по стандартному протоколу (HTTP). Поэтому тестирование web-приложений обладает рядом особенностей, и при проведении самого процесса тестирования необходимо обращать вни- мание на следующие аспекты: 1. единство дизайна; 2. навигация; 3. функциональность; 4. совместимость с браузером; 5. совместимость с операционной системой; 6. "дружественность"; 7. "работоспособность"; Единство дизайна. Под единством дизайна понимается не только, а точнее не столько сочетаемость цвета элементов (так как это удел дизайне- ра), сколько соблюдение выбранной цветовой гаммы, придающей всем стра- ницам сайта "единство". Сюда входят цвета фона (или рисунок), ссылок (в т.ч. посещенной и активной), а также любых других элементов, расположен- ных на странице. Кроме того, на этом же этапе необходимо оценивать размер и вид используемого шрифта для различных уровней вложения текста (заго- ловки различных уровне, собственно текст, ссылки, примечания и т.п.) Здесь же имеет смысл оценивать совместимость с дизайном звуков, рисунков и анимации, а также проверять имеет ли место единство отображения при ис- пользовании других экранных расширений и глубин цвета. Навигация. Навигация предполагает тестирование перемещения по сайту, что дает представление о возможности любого пользователя легко найти необходимый раздел, независимо от способа реализации меню (тек- стовые ссылки, картинки, единая картинка с картой ссылок и др.). На этом же этапе оценивается логичность перемещения между формами, кнопками и другими элементами страницы при помощи TAB, курсорных клавиш и т.п. Функциональность. Общие подходы к тестированию функционально- сти веб-страниц аналогичны таковым при тестировании приложений. Ниже приведен примерный перечень основной функциональности веб-страниц: ссылки (работоспособность, открытие в том же или новом окне и т.п., полное отсутствие битых ссылок) формы (ввод текста, чисел, использование маски, работа с незапол- ненными полями, длина вводимых символов, корректная работа чек-боксов, комбо-боксов, radio buttons, логичность установок "по умолчанию" и т.д.). базы данных (поиск, добавление информации, редактирование, уда- ление, проверка на дублирование информации). доступ (различные роли и права) секретность (работа с паролями, передача данных, защита и т.д.) кеширование (проверка на установку кеширования и обновления файлов) проверка работы с браузером (refresh, forward/back, изменение раз- меров окна, выбор кодировки, скроллинг, отключение флеша, скрипта) фреймы (загрузка страниц, скроллинг и т.п.) анимация (наличие, изменение размеров, загрузка и т.д.) аудио и видео (наличие, размещение, качество и др.) activex печать (корректно ли печатаются страницы) загрузка (как на сайт, так и с сайта) экспорт/импорт данных (если есть такая ф-я) интеграция (например: возможность входа на сайт через социальные сети или оплата услуг через paypal account) рекомендации для достижения хорошего веб приложения (в некото- рых частных случаях могут не соблюдаться - например, не всегда валидаци- онные сообщения будут красного цвета): как внешний вид так и наполнение сайта должны быть надлежащего уровня (с сайтом должно быть приятно и удобно работать); все элементы должны быть выровнены, выравнивание одних и тех же элементов в различных частях одного и того же сайта должно быть уни- фицировано (например: выравнивание кнопок по левому краю); шрифт всех ярлыков должен быть одинакового цвета; не должно быть битых ссылок (ссылок не ведущих на необходимый контент, несуществующих ссылок); каждая под-страница (так называемые "child pages" или "subpages") должна открываться в новом окне; на каждой странице должны присутствовать удобные элементы навигации. такие как: хлебные крошки, вперед/назад, сохранить/отменить и т.д.; если в таблице содержится больше 10 элементов информации, то должна присутствовать "пагинация" (навигационные ссылки: следую- щая/предыдущая, первая/последняя и номера страниц); у каждой страницы наряду с заголовком должен быть подзаголовок выдержанные в одном стиле (шрифт, цвет и т.д.); каждый ярлык должен начинаться с заглавной буквы; желательно, чтобы валидационные сообщения были красного цвета; все обязательные для заполнения поля должны быть жирного шриф- та или помечены специальным символом: *. Совместимость с браузером. Общеизвестно, что в силу конкуренции, тот или иной браузер имеет нередко даже существенные отличия в отобра- жении одной и той же страницы. Для того, чтобы убедится, что любой поль- зователь сможет получить всю необходимую информацию требуется прово- дить тестирование Web-страниц в различных браузерах. Кроме того имеются различия и в разных версиях одного и того же браузера. Это также необхо- димо учитывать при тестировании. "Дружественность". Под "дружественностью" мы понимаем то, насколько прост, легок в обращении и интуитивно понятен интерфейс сайта: легка ли навигация, доступно ли меню, не используются ли раздражающие пользователя приемы, не много ли всплывающих окон, все ли ссылки явля- ются "рабочими", все ли необходимые данные доступны для пользователя и т.д. Например, если на сайте есть файл для скачивания, то желательно, чтобы пользователь имел возможность заранее знать его размер, мог оценить время закачки. "Работоспособность". Проверка на "работоспособность" подразуме- вает оценку скорости загрузки как страниц сайта в целом, так и каждого эле- мента в отдельности. Сюда включается оценка размера используемых рисун- ков, html-файлов, аудио и видео файлов, адаптация их к различным типам со- единений (от обычного модемного dial-up соединения, начиная с 14400, до высокоскоростных технологий). 1.3 Основные проверки при проведении тестирования web- приложения В таблице 2 представлен перечень основных проверок необходимых при проведении тестирования web-приложения, где элементы с отметкой (B) – basic, т.е. являются основными проверками, которые необходимо сделать при тестировании Web-приложений; с отметкой (A) –advanced, т.е проверки, предоставляющие информацию для полноценного тестирования элементов Web-приложений. Таблица 2 – Перечень основных проверок при тестировании web-приложений Название элемента Functional Test GUI Test Поле (B) Обязательность ввода Обработка только пробелов Использование пробелов в тек- сте (1. пробелы в начале и в конце строки должны отсекаться при сохранении, 2. пробелы внутри текста отсекаться не должны) Минимально/максимально до- пустимое количество символов (осуществлять проверку на ввод большого текста без пробелов не нужно) Формат данных (исходя из его логического назначения и требо- ваний приложения) Формат числовых данных (если допускаются): негативные, дроб- ные с точкой и запятой, с точкой и запятой 123.123.123,00 ) Ввод тегов и скриптов (провер- ка должна осуществляться только в пользовательской части - ввод тегов в админку для проверки их применения на фронте не произ- водится. Введенные теги должны отобразиться в том же виде, в ко- тором они были введены) Использование специальных символов (введенные символы должны отобразиться в том же виде, в котором они были введе- ны, если только ввод спец. симво- лов не запрещен требованиями приложения) Возможность редактирования введенных значений Корректное распределение тек- ста по строкам (переход на новую строку автоматически) Уникальные данные (например, уникальность логина, email'а Название поля (спел- линг, соответствие с от- крытым модулем или страницей) Выравнивание назва- ний полей (выравнивание по левому краю или пра- вому краю (в зависимо- сти от требований при- ложения, отступы, иден- тичность расстояний между названием и по- лем) Корректное располо- жение текста внутри тек- ста, длинный текст не выходит за границы поля при вводе Унификация дизайна (цвет, шрифт, размер (высота/ширина), вырав- нивание полей) Расположение вводи- мого текста внутри поля (унификация, выравнива- ние по нижнему краю (для textarea - по верхне- му), если иное не опреде- лено специфичными тре- бованиями приложения) пользователя) Автоматическая постановка курсора в первое поле для ввода при открытии формы Кнопка (B) Отсутствие вызова одного и то- го же действия повторно при нажатии на кнопку несколько раз Недоступные кнопки не скры- ты, а заблокированы (если кнопка недоступна в данный момент, то она не должна пропадать с фор- мы, пользователь должен знать ее существовании; но кнопка должна быть задизейблена - некликабель- на и отображается более светлой) Нажатие на пространство меж- ду близко расположенными кноп- ками не должно приводить к дей- ствию Нажатие на пространство возле кнопки не должно приводить к действию Должно работать нажатие на всю площадь кнопки, а не только по ее названию Название кнопки (спеллинг, соответствие с действием) Эффект ‘нажатия’ (вид кнопки должен изменять- ся при нажатии, если это не противоречит возмож- ностям браузера) Название хинтов (со- ответствие с названием кнопки, спеллинг) Унификация дизайна (цвет, шрифт, размер (высота/ширина), цвет подсветки, выравнива- ние) . Проверка осу- ществляется как для кнопки, как элемента, так и для названия кнопки Радио баттон (B) Функциональность (включе- ние/выключение) Не может быть меньше 2 ра- диокнопок По умолчанию одна радиок- нопка должна быть включена Не может быть включено более 1 радиокнопки При переходе на следующую страницу и возвращении назад выбранная радио кнопка не долж- на сбрасываться Унификация дизай- на для всего приложения Выравнивание рас- положения радиобаттона с соответствующим названием Выравнивание рас- положений радио батто- нов (по краю) Чек бокс (B) Функциональность (включе- ние/выключение) Обязательность выбора хотя бы одного чекбокса Наличие дополнительного чекбокса, выставляюще- го/снимающего все чекбоксы при наличии больше 10 чекбоксов Унификация дизайна для всего приложения Выравнивание распо- ложения чек бокса с со- ответствующим названи- ем Корректность отобра- жения задисэйбленного При переходе на следующую страницу и возвращении назад выбранный чекбокс не должен сбрасываться Отсутствие функции сортиров- ки таблицы по полю, которое со- держит только чекбоксы чек бокса Поле со спис- ком/выпада ющий спи- сок (B) Сортировка по алфавиту или по смыслу В случае, если значения выхо- дят за границы списка, и нет воз- можности увеличения размера списка, то необходимо отображе- ние хинтов (всплывающих под- сказок) Выбор пункта списка по нажа- тии соответствующей первой бук- вы на клавиатуре Возможность выбора несколь- ких значений для поля со списком Возможность введения значе- ний вручную (если это позволяет приложение) Возможность выбора значния из списка указателем мыши либо стрелками с клавиатуры Спеллинг значений Подсветка при выборе каждого из значений, при выборе нескольких зна- чений одновременно Унификация дизайна (цвет, шрифт, размер (высота/ширина), цвет подсветки, выравнива- ние). Проверка осу- ществляется как для по- ля, как элемента, так и для значений, и их назва- ний Меню (B) Осуществление соответствую- щего перехода при выборе пункта меню Визуальное различие в момент работы на определенной вкладке (подсветка, подчеркивание) Подсветка таба при наведении курсора Изменение курсора при наведении Эффект ‘нажатия’, ес- ли это не противоречит возможностям браузера Если работа в данный момент в выбранной вкладке, то в меню она отличается визуально, при этом является некли- кабельной Совпадение названий в случае, если меню дубли- руется в нескольких ме- стах Окно (B) Возможность изменения разме- ра окна браузера. Несколько спо- Появление скролла при уменьшении (изменении) собов сменить разрешение окна браузера при тестировании: Сменить разрешение самого экрана. Воспользоваться виртуалкой. Воспользоваться расширениями для браузеров. Возможность изменения мас- штаба страницы. размера окна браузера Сохранение располо- жения элементов при уменьшении (изменении) окна браузера, при изме- нении масштаба. Если дефект воспроизводится только при смененном масштабе, то в описании дефекта одним из шагов можно указать «увели- чить/уменьшить масштаб до …%» Соответствие названия окна в зависимости от назначения страницы (например, название окна должно быть Profile, если пользователь находится на странице профиля) Спеллинг, синтаксис названий Унификация названий Скрол- линг (B) Отсутствие скролла в случае, если текст вмещается на странице без прокрутки. Соответствующее изменения текста при использовании скрол- ла. Возможность изменения поло- жения скролла при помощи мы- ши, кнопок Page up/down, Home/End. Унификация видов и типов скроллов на всех страницах (если есть ка- стомный скролл, он дол- жен быть применен на всех идентичных формах) Ссылка (B) Функционирование ссылки (должен осуществиться переход на соответствующую страницу) При наведении указателя мыши отображается подсказка (жела- тельно) Форматы ссылок и префиксов Срабатывание ссылки только при клике на саму ссылку, а не на пустую область возле нее Унификация стилей (в соответствие с дизайном сайта) Расположение ссылок (в соответствие с дизай- ном сайта). Например, расположение всех ссы- лок слева или справа от элементов Названия (унификация, идентичность названий ссылок одинакового назначения, спеллинг, соответствие с открытым модулем или страницей, вместимость названия ссылки в отведенном блоке) Измененение вида кур- сора при наведении на ссылку Изменение вида ссыл- ки при наведении курсо- ра (подчеркивание) Таблица (B) При появлении нескольких страниц есть кпопки Вперед, Назад, На первую, На последнюю страницу (пагинация) Проверка сортировок (+ про- верка сортировки по дефолту) Проверка фильтрации (если есть возможность) Апдейт значений таблицы по- сле добавле- ния/изменения/удаления данных Единичное/множественное выделение нескольких значений Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), вырав- нивание) Название (соответствие с текущим модулем, спеллинг) Выравнивание иконок сортировки в названии колонок Выравнивание назва- ний колонок, значений внутри таблицы Корректное отображе- ние длинных названий (соответсвующие перехо- ды на новые строки, со- кращение названий (по- явление ..., либо сокра- щение по слову) Корректное отображе- ние данных после ис- пользования сортировки (размеры колонок и столбцов фиксированы, текст не разбивает струк- туру таблицы) Поп-ап (B) Должен быть модальным Корректное выделение background'а страницы (если фон страницы изменяется при появле- нии поп апа, то при изменении Cпеллинг, синтаксис текста, расположенного на поп-апе Отображение поп-апа по центру страницы, ок- масштаба страницы фон должен заполнять всю страницу - размер измененного фона соответствует размеру страницы) Фиксированное положение поп-апа (динамическое изменение положения) в случае использова- ния скролла на, формы Выравнивание текста, представленного на поп- апе Корректное располо- жение текста на поп-апе: текст должен быть в рам- ках поп-апа, длинное название должно распо- лагаться на новой строке, если иное не определено специфичными требова- ниями приложения Кален- дарь (B) При возможности ввода даты вручную необходимо проверить разные форматы Проверки логичности ввода (даты в будущем, валидации воз- раста и т.д) Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), вырав- нивание) Отображение календа- ря рядом с полем Корректное выравни- вание всех элементов и ссылок в календаре Поле для загрузки файлов (B) Обязательность выбора файла Форматы Ограничения на размер При отсутствии изображений должен быть соответствующий thumbnail, либо картинка совсем не должна отображаться Контроль за размером (высо- та/ширина), должен быть ресайз Загрузка исполняемых файлов (EXE, PHP, JSP etc.). Переименованный EXE Унификация дизайна для всего приложения (цвет, шрифт, размер (высота/ширина), вырав- нивание) Выравнивание назва- ний загруженных файлов, самих thumbnails файлов Сообще- ния (B) Пользователь должен быть ин- формирован о действиях, проис- ходящих в системе посредством сообщений об успешном завер- шении операции На необратимые действия, та- кие как удаление, должны быть подтверждающие сообщения Введенные в форму данные не должны сбрасываться после появ- Сообщение о том, что нет соответствующих ай- темов (в таблицах, при поиске, при переходе на страницы) Спеллинг, синтаксис сообщений Соответствие сообще- ний по смыслу в зависи- мости от выполняемого ления сообщения об ошибке действия Соответствие названия требуемого действия в сообщении об ошибке действию, которое поль- зователь должен выпол- нить. Например, если необходимо выбрать зна- чение из списка, в сооб- щении об ошибке должно быть указано ‘Please select’, а не ‘Please enter’ Унификация стилей (цвет, размер) для всего приложения Соответствие цветов типу сообщений (крас- ный для сообщений об ошибках, зеленый для сообщений об успешном завершении операции), если данные цвета не противоречат специфич- ным требованиям прило- жения Соответствие назва- ний полей в сообщениях об ошибках и сообщени- ях об успешном заверше- нии операции названиям полей, форм, таблиц, кнопок, и т.д. Соответствие порядка выведения сообщений об ошибках в соответствие с порядком расположения полей, в которых были найдены ошибки Поле, в котором со- держится ошибка должно (желательно) выделяться цветом Невалидное значение не должно отображаться в сообщении об ошибке. Пример как быть не должно: 2309234@@mail.ru не со- ответствует допустимому формату”. Согласование числи- тельного и связанного с ним существительного должно соблюдаться. Например, "1 день", "2 дня", "5 дней". Общие про- верки (A) Перед тестированием каждой новой сборки необходимо осуще- ствить очистку кэша и кукис. Для полной очистки кэша и куки можно воспользоваться приложе- нием Ccleaner. 404 Error (переход по некор- ректному урлу должен вести на страницу с 404 ошибкой, а не просто на страницу Page cannot be found. страница 404 ошибки должна быть реализована в общем дизайне тестируемого приложе- ния) Tab order (сверху вниз слева направо). Поля, доступные для прочтения и задисэйбленные должны пропускаться Logo должен быть ссылкой на главную страницу Фокус на кнопке для исполне- ния действий (ввод данных -> нажатие Enter -> действие осуще- ствилось) Проверка Breadcrumbs ("Хлеб- ные крошки" - элемент навигации, являющийся признаком удобства пользования сайтом в целом и пе- ремещением по его структуре) Отображение flash-элементов при отключен- ном/неустановленном в браузере flash-плеере (пользователю долж- но быть предложено скачать и Уменьшение / увели- чение масштаба страницы (элементы должны соот- ветственно перераспреде- литься с сохранением пропорций) Уменьшение / увели- чение размера окна брау- зера (элементы должны соответственно перерас- пределиться с сохранени- ем пропорций, взаимо- расположение должно со- храняться) установить последнюю версию flash-плеера; на месте flash- объекта должно отображаться альтернативное изображение) Проверка работоспособности отправки email нотификаций (как админу, так и пользователю), если только отсутствие писем не явля- ется спецификой проекта Проверка работоспособности приложения при отключенном JavaScript. Основная функцио- нальность и навигация должна работать. Подробное описание то- го, как отключить JavaScript и на что обращать внимание, находит- ся здесь. Тестирование ссылок и прав доступа. Подробнее здесь. Всегда проверять взаимосвязь компонентов. Обращать внимание на то, как ведет себя один компо- нент при изменении/удалении другого. Например, при удалении категории товара не должны уда- ляться все товары в этой катего- рии. Порядок выполнения работы 1. Получить задание у преподавателя. 2. Разработать рабочую тестовую документацию для web-приложения. 3. Оформить отчет и защитить лабораторную работу. Содержание отчета 1. Цель работы. 2. Краткие теоретические сведения. 3. Рабочая тестовая документация. 4. Выводы по работе. Контрольные вопросы 1. Какие существуют разновидности рабочей тестовой документации? 2. Check List: что описывают и когда используют? 3. Acceptance Sheet: что описывают и когда используют? 4. Test Survey: что описывают и когда используют? 5. Test Cases: что описывают и когда используют? 6. Что такое web-приложение? 7. Какую архитектуру имеет web-приложение? 8. На какие особенности необходимо обращать внимание при тестиро- вании web-приложения, охарактеризуйте эти особенности. 9. Какие основные проверки необходимо выполнять при тестировании web-приложения? |