Тестирование ПО. Тестирование. Реферат актуальность. Основной всплеск интереса к теме тестирования пришёлся на 90е годы и начался в сша. Бурное развитие систем автоматизированной разработки
 Скачать 2.21 Mb.
|
|
Ожидаемый результат Результат теста Открыть страницу "Вход в систему" - окно "Вход в систему" открыто; - название окна - Вход в систему; - логотип компании отображается в правом верхнем углу; - на форме 2 поля - Имя и Пароль; - кнопка Вход доступна; - ссылка "забыл пароль" - доступна. Пример тест кейса 2: Название: Проверка отображения страницы Действие: Открыть страницу "Вход в систему" 37 Проверка: Проверьте, что отображаемая страница соответствует странице на картинке 1 (и прилагаем изображение страницы "Вход в систему") В примере 1 и 2 покрытие будет одинаковым, но вот время, которое потребуется для прохождения, будет разным. Второй пример будет нагляднее. 7.4.4 Атрибуты тест кейса В таблице 7.6 представлены часто используемые атрибуты тест кейса. Таблица 7.6 - Атрибуты тест кейса Атрибут тест кейса Описание Test Case ID Уникальное значение в пределах не только документа, но и всей фирмы Test Case Priority Приоритет. Измеряется от 1 до n 1 – самый высокий n – самый низкий (для не очень больших проектов рационально выбирать n=4) IDEA Описание идеи, проверяемой тест кейсом SETUP and ADDITIONAL INFO Входные параметры Revision History История редактирования. Пример формата: Created on Modified on Change – какие изменения и зачем они Execution Part Выполнимая часть тест кейса. Пример формата: Action – список команд EXPECTED RESULT – ожидаемый результат TEST RESULT – (passed, failed, blocked) Пример тест кейса: пусть для тестирования возможности оплаты услуги на сайте необходимо выполнить следующий алгоритм: 1) открыть vk.com; 2) ввести в поле “Имя пользователя” значение “user”; 3) ввести в поле “Пароль” значение “password”; 4) нажать кнопку “Войти”; 5) ввести в поле “Искать людей” значение “Петр Петров”; 6) нажать кнопку “Поиск”; 38 7) нажать на страницу с Петр Петров; 8) в открывшейся странице нажать на ссылку “Отправить подарок”; 9) в открывшейся странице нажать на любую ссылку с подарком; 10) в открывшейся странице нажать на кнопку “Подарить”; 11) в открывшейся странице нажать на ссылку “Банковские карты”; 12) ввести в поле “Номер карты” значение карты VISA “1111-1111-1111-1111”; 13) ввести в поле “Действительно до” значение “07/15”; 14) ввести в поле “CVC” значение “111”; 15) нажать кнопку “Оплатить”; 16) записать номер заказа; 17) запросить базу данных “select res from payment where id = <номер заказа>”. Ожидаемый результат: “10” В таблице 7.7 можно увидеть как для данного примера будет выглядеть тест кейс. Преимущество такой структуры тест кейса в отличии от первоначального списка заключается в том, что есть возможность протестировать по тому же сценарию другие данные (например: user2, password2, Джулия Робертс, 2222-2222-2222-2222). Для выполнения одного и того же сценария на N наборах тестовых данных создается N тестов. Этому правилу необходимо следовать. Таким образом, чтобы сделать подарок Ивану Иванову, нужно скопировать содержимое тест кейса VV12345, например, в тест кейс VV12346 и переписать только входные параметры. Такой вид тест кейса называется управляемый данными (data-driven). Проблемы сценария в примере: пункты 1-4 могут меняться в связи с миграцией сайта на новый домен, изменением интерфейса и т.д.; поиск друга в пунктах 5-7 “Петр Петров” может привести в никуда при удалении страницы; пункты 8-15 могут быть легко изменены за счет нового дизайна сайта. Следовательно, при любом таком изменении придется переписывать весь тест кейс, чтобы заново протестировать первоначальную задачу. 39 Таблица 7.7 - Тест кейс для примера Test Case ID/Priority VV12345 1 IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа> Revision History Created on 23/01/2014 by Иван Иванов Новый тест кейс Execution Part ACTION EXPECTED RESULT TEST RESULT 1) открыть vk.com; 2) ввести в поле “Имя пользователя” значение “user”; 3) ввести в поле “Пароль” значение “password”; 4) нажать кнопку “Войти”; 5) ввести в поле “Искать людей” значение “Петр Петров”; 6) нажать кнопку “Поиск”; 7) нажать на страницу с Петр Петров; 8) в открывшейся странице нажать на ссылку “Отправить подарок”; 9) в открывшейся странице нажать на любую ссылку с подарком; 10) в открывшейся странице нажать на кнопку “Подарить”; 11) в открывшейся странице нажать на ссылку “Банковские карты”; 12) ввести в поле “Номер карты” значение карты VISA “1111- 1111-1111-1111”; 13) ввести в поле “Действительно до” значение “07/15”; 14) ввести в поле “CVC” значение “111”; 15) нажать кнопку “Оплатить”; 16) записать номер заказа; 17) запросить базу данных “select res from payment where id = <номер заказа>”. 10 Если же разбить задачу на несколько тест кейсов, например, за пункты 1-4 будет отвечать тест кейс “Вход в систему”, за пункты 5-7 “Поиск друга”, 8-15 – “Оплата подарка” (на внутреннем уровне каждого из них возможно еще более детальное разделение), то можно переписать тест кейс так, как указано в таблице 7.8. 40 Возможен вариант, когда все, что нужно – это выполнение команды номер 5, при условии что другие команды выполнены заранее. В таблице 7.9 указан упрощенный вариант тест кейса. Таблица 7.8 - Упрощение тест кейса Test Case ID/Priority VV12347 1 IDEA: Оплата картой VISA “подарка другу” SETUP and ADDITIONAL INFO: Аккаунт: user/password Имя друга: Петр Петров Номер карты: 1111-1111-1111-1111 Срок действия: 07/15 CVC: 111 Запрос SQL: select res from payment where id = <номер заказа> Revision History Created on 23/01/2014 by Марина Гончарова Новый тест кейс Modified on 23/01/2014 by Иванов Евгений Упрощение шагов Execution Part ACTION EXPECTED RESULT TEST RESULT 1) войти в систему; 2) найти друга; 3) платить подарок; 4) записать номер заказа; 5) запросить базу данных “select res from payment where id = <номер заказа>”. 10 Таблица 7.9 - Упрощение тест кейса Test Case ID/Priority VV12348 1 IDEA: Подтверждение оплаты SETUP and ADDITIONAL INFO: Номер заказа: параметр Revision History Created on 23/01/2014 by Марина Гончарова Новый тест кейс Modified on 23/01/2014 by Иванов Евгений Упрощение шагов Modified on 24/01/2014 by Сергей Галкин Изменение структуры Execution Part ACTION EXPECTED RESULT TEST RESULT Запросить базу данных “select res from payment where id = <номер заказа>” 10 Неизвестным параметр < Номер заказа > после завершения выполнения теста получит свое значение, которое будет задокументировано [11]. 41 8 ДЕФЕКТЫ. ПРИЧИНЫ, ОПИСАНИЕ, ОТСЛЕЖИВАНИЕ Ошибками в программном обеспечении являются все возможные несоответствия между демонстрируемыми характеристиками его качества и сформулированными или подразумеваемыми требованиями и ожиданиями пользователей [8]. В англоязычной литературе используется несколько терминов, часто одинаково переводящихся как "ошибка" на русский язык: defect — самое общее нарушение каких-либо требований или ожиданий, не обязательно проявляющееся вовне (к дефектам относятся нарушения стандартов кодирования, недостаточная гибкость системы и пр.); failure — наблюдаемое нарушение требований, проявляющееся при каком-то реальном сценарии работы ПО. Это можно назвать проявлением ошибки; fault — ошибка в коде программы, вызывающая нарушения требований при работе (failures), то место, которое надо исправить. Хотя это понятие используется довольно часто, оно, вообще говоря, не вполне четкое, поскольку для устранения нарушения можно исправить программу в нескольких местах. Что именно надо исправлять, зависит от дополнительных условий, выполнение которых хотим при этом обеспечить, хотя в некоторых ситуациях наложение дополнительных ограничений не устраняет неоднозначность; error — используется в двух смыслах. Первый смысл — это ошибка в ментальной модели программиста, ошибка в его рассуждениях о программе, которая заставляет его делать ошибки в коде (faults). Это, собственно, ошибка, которую сделал человек в своем понимании свойств программы. Второй смысл — это некорректные значения данных (выходных или внутренних), которые возникают при ошибках в работе программы. Эти понятия некоторым образом связаны с основными источниками ошибок. Поскольку при разработке программ необходимо сначала понять задачу, затем придумать ее решение и закодировать его в виде программы, то, соответственно, основных источников ошибок три: неправильное понимание задач. Разработчики ПО не всегда понимают, что именно нужно сделать. Другим источником непонимания служит отсутствие его у самих пользователей и заказчиков — достаточно часто они могут просить сделать несколько не то, что им действительно нужно. Для предотвращения неправильного понимания задач программной системы служит анализ предметной области; неправильное решение задач. Зачастую, даже правильно поняв, что именно нужно сделать, разработчики выбирают неправильный подход к тому, как это делать. Выбираемые решения могут обеспечивать лишь некоторые из требуемых свойств, они 42 могут хорошо подходить для данной задачи в теории, но плохо работать на практике, в конкретных обстоятельствах, в которых должно будет работать программное обеспечение. Помочь в выборе правильного решения может сопоставление альтернативных решений и тщательный анализ их на предмет соответствия всем требованиям, поддержание постоянной связи с пользователями и заказчиками, предоставление им необходимой информации о выбранных решениях, демонстрация прототипов, анализ пригодности выбираемых решений для работы в том контексте, в котором они будут использоваться; неправильный перенос решений в код. Имея правильное решение правильно понятой задачи, люди, тем не менее, способны сделать достаточно много ошибок при воплощении этих решений. Корректному представлению решений в коде могут помешать как обычные опечатки, так и забывчивость программиста или его нежелание отказаться от привычных приемов, которые не дают возможности аккуратно записать принятое решение. С ошибками такого рода можно справиться при помощи инспектирования кода, взаимного контроля, при котором разработчики внимательно читают код друг друга, опережающей разработки модульных тестов и тестирования. В программировании баг (bug — жук) — жаргонное слово, обычно обозначающее ошибку в программе или системе, которая выдает неожиданный или неправильный результат. Большинство багов возникают из-за ошибок, сделанных разработчиками программы в её исходном коде, либо в её дизайне. Также некоторые баги возникают из-за некорректной работы компилятора, вырабатывающего некорректный код. Программу, которая содержит большое число багов и/или баги, серьёзно ограничивающие её функциональность, называют нестабильной или, на жаргонном языке, «глючной», «забагованной» (unstable, buggy). Термин «баг» обычно употребляется в отношении ошибок, проявляющих себя на стадии работы программы, в отличие, например, от ошибок проектирования или синтаксических ошибок. Отчет, содержащий информацию о баге также называют отчетом об ошибке или отчетом о проблеме (bug report). Отчет о критической проблеме (crash), вызывающей аварийное завершение программы, называют крэш репортом (crash report). «Баги» локализуются и устраняются в процессе тестирования и отладки программы. 8.1 Система отслеживания ошибок Система отслеживания ошибок (bug tracking system) — прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки (баги), найденные в программах, 43 пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий [5]. Главный компонент такой системы — база данных, содержащая сведения об обнаруженных дефектах. Эти сведения фиксируются в отчете об ошибке. Отчет об ошибке (баг репорт) - это документ, описывающий ситуацию или последовательность действий приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата. 8.2 Структура баг репорта Разные системы отслеживания ошибок, предлагают разные поля для заполнения и разные структуры описания ошибок. В таблице 8.1 указан шаблона баг репорта. Таблица 8.1 - Шаблон баг репорта Шапка Короткое описание (Summary) Короткое описание проблемы, явно указывающее на причину и тип ошибочной ситуации. Проект (Project) Название тестируемого проекта Компонент приложения (Component) Название части или функции тестируемого продукта Номер версии (Version) Версия на которой была найдена ошибка Серьезность (Severity) Наиболее распространена пятиуровневая система градации серьезности дефекта: s1 Блокирующий (Blocker); s2 Критический (Critical); s3 Значительный (Major); s4 Незначительный (Minor); s5 Тривиальный (Trivial). Приоритет (Priority) Приоритет дефекта: p1 Высокий (High); p2 Средний (Medium); p3 Низкий (Low). (подробнее в разделе Серьезность и приоритет ошибки) Статус (Status) Статус бага. Зависит от используемой процедуры и жизненного цикла бага (bug workflow and life cycle) Автор (Author) Создатель баг репорта Назначен на (Assigned To) Имя сотрудника, назначенного на решение проблемы Окружение ОС / Сервис Пак и т.д. / Браузера + версия / ... Информация об окружении, на котором был найден баг: операционная система, сервис пак, для WEB тестирования - имя и версия браузера и т.д. 44 Продолжение таблицы 8.1 Описание Шаги воспроизведения (Steps to Reproduce) Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке. Фактический Результат (Result) Результат, полученный после прохождения шагов к воспроизведению Ожидаемый результат (Expected Result) Ожидаемый правильный результат Дополнения Прикрепленный файл (Attachment) Файл с логами, скриншот или любой другой документ, который может помочь прояснить причину ошибки или указать на способ решения проблемы 8.3 Серьезность и приоритет ошибки Разные системы отслеживания ошибок предлагают разные пути описания серьезности и приоритета баг репорта, неизменным остается лишь смысл, вкладываемый в эти поля. серьезность (Severity) - это атрибут, характеризующий влияние ошибки на работоспособность приложения; приоритет (Priority) - это атрибут, указывающий на очередность выполнения задачи или устранения ошибки. Можно сказать, что это инструмент менеджера по планированию работ. Чем выше приоритет, тем быстрее нужно исправить дефект. Градация серьезности дефекта (severity): s1 Блокирующая (Blocker). Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна. Решение проблемы необходимо для дальнейшего функционирования системы; s2 Критическая (Critical). Критическая ошибка, неправильно работающая ключевая бизнес логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, без возможности решения проблемы, используя другие входные точки. Решение проблемы необходимо для дальнейшей работы с ключевыми функциями тестируемой системой; s3 Значительная (Major). Значительная ошибка, часть основной бизнес логики работает некорректно. Ошибка не критична или есть возможность для работы с тестируемой функцией, используя другие входные точки; s4 Незначительная (Minor). Незначительная ошибка, не нарушающая бизнес логику тестируемой части приложения, очевидная проблема пользовательского интерфейса. 45 s5 Тривиальная (Trivial). Тривиальная ошибка, не касающаяся бизнес логики приложения, плохо воспроизводимая проблема, малозаметная посредствам пользовательского интерфейса, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта. Градация приоритета ошибки (Priority): p1 Высокий (High). Ошибка должна быть исправлена как можно быстрее, т.к. ее наличие является критической для проекта; p2 Средний (Medium). Ошибка должна быть исправлена, ее наличие не является критичной, но требует обязательного решения; p3 Низкий (Low). Ошибка должна быть исправлена, ее наличие не является критичной, и не требует срочного решения. Порядок исправления ошибок по их приоритетам: High > Medium > Low. 8.4 Написание баг репорта Баг репорт - это технический документ и в связи с этим язык описания проблемы должен быть техническим. Должна использоваться правильная терминология при использовании названий элементов пользовательского интерфейса (editbox, lightbox, combobox, link, text area, button, menu, popup menu, title bar, system tray и т.д.), действий пользователя (click link, press the button, select menu item и т.д.) и полученных результатах (window is opened, error message is displayed, system crashed и т.д.). |