Легкий способ начать тестировать. Как тестировать только то, что нужно

Перейти на главную Тест план 1. ID Тестирование Блокнота версии 6.1 2. Введение Этот документ является тест планом по тестированию десктоп приложения Блокнот версии 6.1. Он описывает стратегию и подходы к тестированию продукта. План используется для валидации качества программного обеспечения. 3. Объекты тестирования Ниже приводится список объектов функционального тестирования:  работа с файлами,  печать,  изменение параметров работы,  правка,  форматирование,  изменение вида,  вызов справки 4. Что будет тестироваться? Функции Блокнота, с точки зрения пользователя, что будут тестироваться: - открытие файла с помощью Блокнота; - создание файла; - закрытие приложения; - печать; - изменение параметров работы; - правка; - форматирование; - изменение вида; - вызов справки. 5. Что не будет тестироваться? Функции Блокнота, с точки зрения пользователя, что не будут тестироваться: - функции «Печати» - диапазон страниц: выделение, выбор страницы, разобрать по копиям. Причина - во-первых: для тестирования не будет задействован физический принтер; вовторых: данная функциональность не активна на виртуальном принтере, а так же и для печати в файл. - функция «Параметры страницы» - способ подачи бумаги. Причина – данная функциональность отсутствует на виртуальном принтере 6. Подход Вовремя тестирования приложения будет проводится нефункциональное тестирование, а именно: - тестирование интерфейса - тестирование удобства использования/ юзабилити Для функционального тестирования будут использоваться следующие техники тестирования: 1) Разбиение на классы эквивалентности (Шрифты) 2) Анализ граничных значений (Шрифты) 3) Комбинаторное тестирование. Необходимо написать тест план, с указанием всех ключевых требований, подходов, а так же обязанностей и компетенций соответственно. Перейти на главную Написание тест кейсов в соответствии с распределёнными обязанностями, обязательное их согласование и занесение в тест менеджмент систему. При создании последнего тест кейса составление матрицы трассируемости требований и просчет покрытия требований тестами. 7. Критерии успешности тестирования Все тест кейсы с высоким приоритетом закрыты с результатом «пройден/pass». Тестовое покрытие проверено и является достаточным, где критерий достаточности составляет не менее 99% покрытия требований тестами. Тест репорт составлен и утвержден тест лидом и заказчиком. 8. Критерии прерывания и продолжения тестирования Критерием прерывания тестирования является появления и занесения в баг-трекинговую систему блокирующих багов. Критерием продолжения тестирования закрытие блокирующего бага в баг-трекинговой системе. 9. Результаты проведения тестирование Результатом проведения тестирования является получение следующих документов: тест план, тест кейсы, матрица трассируемости требований. 10.Задачи для проведения тестирования Задача Написание тест плана Написание тест кейсов Разработка критериев успешности тестирования Проведение тестирования и оценка результатов Создание отчетов о результатах тестирования Расположение Создание тест плана, обязанности Объекты тестирования, обязанности Критерии успешности тестирования Подход к тестированию, обязанности Результаты проведения тестирования 11.Технические требования Тестирование приложение будет происходить на следующих операционных системах: Windows XP, Windows 7 12.Обязанности Роль № п/п 1 Лид 2 Тестировщик 3 Тестировщик Обязанности Написание тест плана; написания тесткейсов для тестирования следующих функций: открытие, создание, закрытие; осуществление функционального тестирования вручную; составление матрицы трассируемости требований Написания тест-кейсов для тестирования следующей функции: сохранение; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования следующей функции: Параметры страницы; осуществление Ответственный Пасечник А. Цимбалюк А. Бутенко А. Перейти на главную 4 Тестировщик 5 Тестировщик 6 Тестировщик 7 Тестировщик 8 Тестировщик 9 Тестировщик функционального тестирования вручную Написания тест-кейсов для тестирования следующей функции: печать; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования следующей функции: Правка; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования следующей функции: Формат (кроме шрифтов), Вид, Справка; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования контекстного меню; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования горячих клавиш; осуществление функционального тестирования вручную Написания тест-кейсов для тестирования шрифтов; осуществление функционального тестирования вручную Костева В. Каверин А. Кононский А. Мирошник А. Полищук П. Мирошниченко С. 13.Необходимые компетенции и тренинги Для выполнения поставленных задач необходимо обладать следующими компетенциями: - знание и умение использования правил написания тест планов, в том числе основанных на стандарте IEEE-829; - знание и умение применить техники тест дизайна - знание различных типов тестирования в том числе функционального и нефункционального, такого как тестирование интерфейса и юзабилити - умение использование тест менеджмент системы, выбранной для текущего проекта И т.д. Необходимые тренинги для проведения тестирования проекта: - тренинг по тестированию шрифтов.=) - тренинг по использованию специфического программного обеспечения для более качественного и полного тестирования юзабилити 14.Расписание/ срок сдачи Срок утверждение и внесения всех тест кейсов в тест менеджмент систему – 30/03/2014 23:59:59 Срок составления отчетов 31/03/2014 23:59:59 Срок сдачи проекта – 1/04/2014 19:00:00 15.Риски и их устранение Возможные риски во время тестирования: - Недостаточное количество кадровых ресурсов для тестирования приложения в установленные сроки Перейти на главную - Отсутствие необходимого оборудования, программного обеспечения, данных или инструментов. - Изменения в оригинальных требований или инструкций. - Количество допустимых дефектов будет увеличено. - Тест команда будет работать сверхурочно. Это негативно может повлиять на боевой дух команды. - Объемы плана могут быть изменены. - тестирование приложения может быть просто остановлено (крайний случай) 16. Утверждение Утверждение тест кейсов – Ответственный тест лид – Пасечник Прием готового проекта - Ответственный - Аня =)

Тесты, проделанные нами на прошлом семинаре, как правило, проводятся не вручную. Для целей тестирования пишут специальную программу - тестовый драйвер, который и проводит тестирование. Более того, такие программы часто пишутся на другом языке, нежели тестируемая программа, или создаются автоматически, с помощью специальных утилит.

На этом семинаре мы сами напишем простой тестовый драйвер на C# для тестирования функций "Калькулятора", используя спецификацию второго семинара.

Замечание . Код программы слегка изменен для упрощения компиляции отдельных модулей. Так, исключена работа с переменной Program.res , а класс CalcClass объявлен как public .

Для начала рассмотрим функцию деления. Тест-требования к ней мы уже составили. Для простоты будем пользоваться лишь четырьмя общими тест- требованиями.

1. Оба входных параметра принадлежат допустимой области , и выходное значение принадлежит допустимой области .
2. Первый входной параметр принадлежит допустимой области , второй не принадлежит допустимой области
3. Первый входной параметр не принадлежит допустимой области , второй принадлежит допустимой области
4. Оба входных параметров принадлежат допустимой области , а значение функции не принадлежит допустимой области .

Составим программу:

Private void buttonStartDel_Click(object sender, EventArgs e) { try { richTextBox1.Text = ""; richTextBox1.Text += "Test Case 1\n"; richTextBox1.Text += "Входные данные: a= 78508, b = -304\n"; richTextBox1.Text += "Ожидаемый результат: res = 78204 && error = \"\""+"\n"; int res = CalcClass.Add(78508, -304); string error = CalcClass.lastError; richTextBox1.Text += "Код ошибки: " + error + "\n"; richTextBox1.Text += "Получившийся результат: " +"res = "+ res.ToString() +" error = "+error.ToString() +"\n"; if (res == 78204 && error == "") { richTextBox1.Text += "Тест пройден\n\n"; } else { richTextBox1.Text += "Тест не пройден\n\n"; } } catch (Exception ex) { richTextBox1.Text += "Перехвачено исключение: " + ex.ToString() + "\nТест не пройден.\n"; } try { richTextBox1.Text += "Test Case 2\n"; richTextBox1.Text += "Входные данные: a= -2850800078, b = 3000000000\n"; richTextBox1.Text += "Ожидаемый результат: res = 0 && error = \"Error 06\"\n"; int res = CalcClass.Add(-2850800078, 3000000000); string error = CalcClass.lastError; richTextBox1.Text += "Код ошибки: " + error + "\n"; richTextBox1.Text += "Получившийся результат: " + "res = " + res.ToString() + " error = " + error.ToString() + "\n"; if (res == 0 && error == "Error 06") { richTextBox1.Text += "Тест пройден\n\n"; } else { richTextBox1.Text += "Тест не пройден\n\n"; } } catch (Exception ex) { richTextBox1.Text += "Перехвачено исключение: " + ex.ToString() + "\nТест не пройден.\n"; } try { richTextBox1.Text += "Test Case 3\n"; richTextBox1.Text += "Входные данные: a= 3000000000, b = - 2850800078\n"; richTextBox1.Text += "Ожидаемый результат: res = 0 && error = \"Error 06\"\n"; int res = CalcClass.Add(3000000000, -2850800078); string error = CalcClass.lastError; richTextBox1.Text += "Код ошибки: " + error+"\n"; richTextBox1.Text += "Получившийся результат: " + "res = " + res.ToString() + " error = " + error.ToString() + "\n"; if (res == 0 && error == "Error 06") { richTextBox1.Text += "Тест пройден\n\n"; } else { richTextBox1.Text += "Тест не пройден\n\n"; } } catch (Exception ex) { richTextBox1.Text += "Перехвачено исключение: " + ex.ToString() + "\nТест не пройден.\n"; } try { richTextBox1.Text += "Test Case 4\n"; richTextBox1.Text += "Входные данные: a= 2000000000, b = 2000000000\n"; richTextBox1.Text += "Ожидаемый результат: res = 0 && error = \"Error 06\"\n"; int res = CalcClass.Add(2000000000, 2000000000); string error = CalcClass.lastError; richTextBox1.Text += "Код ошибки: " + error +"\n"; richTextBox1.Text += "Получившийся результат: " + "res = " + res.ToString() + " error = " + error.ToString() + "\n"; if (res == 0 && error == "Error 06") { richTextBox1.Text += "Тест пройден\n\n"; } else { richTextBox1.Text += "Тест не пройден\n\n"; } } catch (Exception ex) { richTextBox1.Text += "Перехвачено исключение: " + ex.ToString() + "\nТест не пройден.\n"; } } Листинг 7.1. Текст программы

Каждый тестовый пример находится внутри блока try-catch для того, чтобы перехватить любое сгенерированное исключение внутри методов Add() .

При этом файл CalcClass.dll , в котором и реализованы все математические методы, необходимо добавить в References проекта.

Проведем тестирование и получим следующий результат:

Test Case 1 Входные данные: a= 78508, b = -304 Ожидаемый результат: res = 78204 && error = "" Код ошибки: Получившийся результат: res = 78204 error = Тест пройден Test Case 2 Входные данные: a= -2850800078, b = 3000000000 Ожидаемый результат: res = 0 && error = "Error 06" Код ошибки: Error 06 Получившийся результат: res = 0 error = Error 06 Тест пройден Test Case 3 Входные данные: a= 3000000000, b = -2850800078 Ожидаемый результат: res = 0 && error = "Error 06" Код ошибки: Error 06 Получившийся результат: res = 0 error = Error 06 Тест пройден Test Case 4 Входные данные: a= 2000000000, b = 2000000000 Ожидаемый результат: res = 0 && error = "Error 06" Код ошибки: Error 06 Получившийся результат: res = 0 error = Error 06 Тест пройден

Точно такой же результат мы бы получили и при ручном тестировании , если бы выявленные ошибки были исправлены. Заметим, что при таком подходе к тестированию нам удается локализовать ошибки. Если что-то работает не так, как надо, то можно с уверенностью утверждать, что ошибка содержится именно в функции деления, в то время, как на прошлом семинаре мы не могли сказать, где именно она произошла.

Замечание . Мы считаем, что тестовый драйвер сам не содержит ошибок. Тестирование тестового драйвера выходит за пределы изучаемой темы.

7.4. Раздаточный материал

7.4.1. Программа

Будут выданы .dll файлы, которые нужно протестировать методом "черного ящика", и пример тестового драйвера.

7.5. Домашнее задание

Составить тест-план и провести модульное тестирование следующих методов:

Нахождение остатка.

Ручное тестирование - это кропотливый и порой рутинный процесс. Одной из проблем является то что при внесении изменений в код сложно предсказать какие тесты следует проделать заново, чтобы убедиться что все работает так как следует. Для этого прибегают к регрессионному тестированию и повторному прогону всех тестов. Такие операции требуют много времени. Но если вы разрабатываете свои решения на платформе.NET то у вас есть шанс значительно снизить трудозатраты тестировщиков, потому что вы будете точно знать, какие тесты следует провести а какие нет , так как изменения в коде не затронули их поведение. Звучит заманчиво?

Инструментальная обработка кода и Test Impact.

Изменения, которые программисты вносят в код приложения, при наличии системы контроля версий и процесса непрерывной интеграции, могут быть четко идентифицированы. При этом если проводить тесты от билда к билду, то благодаря анализу информации Code Coverage ручных тестов и ее сохранению для каждого пройденного тестового плана, мы можем четко предсказать то какой тест сломался, а какие тесты вообще не затронуты изменениями, которые внесли программисты. Это на первый взгляд весьма фантастично, но тем не менее уже работает в связке с Team Foundation Server 2013 и Microsoft Test Manager 2013.

Подробный сценарий, чтобы все стало понятно.

Рассмотрим на примере калькулятора подробный сценарий. В Microsoft Test Manager у нас определен основной тестовый план, и для каждого PBI соответствующие тесты функций:

В настройках тестов обязательно указано что при прогоне тестов у нас будет проводится анализ Test Impact:

Дополнительно обязательно укажем эту же опцию в правилах сборки билда:

Собираем билд и начинаем тестировать наше приложение согласно плана:


Это первая сборка нашего продукта, очевидно, что мы должны проделать все тесты чтобы убедится, что все работает так как надо. При прохождении тестов Microsoft Test Manager анализирует пути исполнения кода соответствующие каждому тесту и записывает эту информацию в базу данных.
Проходим все тесты фич нашего продукта:

У нас в плане 4 теста, умножение, деление, вычитание и сложение. В окне результатов видим что мы проверили все фичи нашего калькулятора и прошли все тесты плана:

Вносим изменения в код

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

Делаем чекин и собираем новый билд. Его будут проверять тестеры. После сборки билда в отчете помимо стандартной информации о том сколько пройдено модульных тестов, каков процент Code Coverage так же мы получаем информацию о том какие тесты были затронуты. Настоящая магия!

Помимо информации в отчете, тестировщик так же может получить список затронутых тестов прямо в Microsoft Test Manager. Прежде чем получить список рекомендованных тестов, назначим тестовому плану новый билд. При этом нам будет дана рекомендация по анализу перечня рекомендованных тестов:

При этом у тестировщика есть возможность делать анализ рекомендованных тестов от билда к билду:

Тем самым тестировщик может значительно сэкономить время на проверку билда, и провести только те тесты, которые были подвержены изменениям внесенным программистами в код приложения.

Если вы PHP-разработчик, и по разным обстоятельствам тесты для своих приложений не пишете, то эта статья для вас. В ней я постараюсь вкратце показать с чего начать и что делать, чтобы написание тестов приносило вам радость, а вашему приложению стабильность.

Итак, первый совет. Забудьте всё что вы знаете о юнит-тестах. Швырните табуреткой в человека, который сказал вам, что без них не обойтись. Попробуем разобраться, в каких случаях нужно их использовать, а в каких - нецелесообразно.

Я абсолютно уверен, что PHP-программисты редко пишут тесты, потому что начинают не с того конца. Все знают, что тесты это хорошо и клево. Но открыв сайт того же PHPUnit , и прочитав красочный пример о тестировании калькулятора умеющего выполнять операцию a + b, они спрашивают себя: какое отношение этот калькулятор имеет к моему приложению? Ответ: никакого. Ровно как все похожие примеры, на сайтах других фреймворков тестирования. Будто бы все забыли, что PHP прежде всего для веба. Будто бы все пишут калькуляторы, а не сайты на основе MVC-парадигмы.

Положим, вы создаете сайт или разрабатываете веб-приложение. На нем уже есть некоторые страницы, формы, возможно даже интерактивные элементы. Как вы (или, допустим, ваш заказчик) проверяете что сайт работает? Наверняка вы заходите на сайт, кликаете по ссылкам, заполняете формы, смотрите на результат. И по-хорошему, все эти рутинные процессы кликанья и заполнения форм, стоит автоматизировать в первую очередь.

И потому мы поговорим о функциональных тестах (или приемочных).

Функциональное тестирование - это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.

Википедия

Почему написание тестов стоит начать именно с них? Да просто, чтобы быть уверенным, что ваш сайт функционирует, и всё там работает. Приемочные тесты одинаково хорошо подойдут как для солидного веб-приложения, так и простенького сайта, склепанного за ночь на коленке. А потому начать стоит с них.

Что у нас есть для функционального тестирования? Из всего известного мне, это Codeception и, например, PHPUnit + Mink или прямое использование Selenium. Я хотел включить в этот печерень и Behat , но его автор попросил не использовать Behat для функционального тестирования .

Если бы тестировать с Selenium или PHPUnit + Mink было просто, вы бы уже наверняка их использовали. Потому остановимся на Codeception.

Тест в нем описывается так:

wantTo("see my site is working"); $I->amOnPage("/"); $I->see("Welcome, on my site!"); ?>

Всего в несколько строчек вы проверяете, что как минимум, главная страница вашего сайта открывается. За длительной работой, сломать её, не так и сложно.
Точно так же, вы можете описывать дальнейшие действия:

click("Feedback"); $I->see("Submit your feedback"); $I->fillField("Body","Your site is great!"); $I->click("Submit"); $I->see("Thanks for your feedback!"); ?>

Вот тут мы уже проверяем, что форма отзывов на вашем сайте работает. По крайней мере, пользователю, показывается, что его мнение было учтено.

А теперь попробуем определиться, с unit-тестами.

Модульное тестирование, или юнит-тестирование (англ. unit testing) - процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.

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

Википедия .

Беда их использования в том, что обычно веб-приложения основываются на CMS или фреймворках. И порой не всегда получается выделить конкретные модули для тестирования. Особенно неудобно получается, когда логика приложения раскидана по различным классам, а каждый конкретный юнит по сути не делает ничего. Процесс тестирования ещё будет усложнен тем, что все модули как-то взаимосвязаны, имеют много унаследованых методов, конфигураций, и выделить где код ваш, а где код библиотеки порой очень трудно.

Но если в рамках функциональных тестов вы проверили всё, что пользователь может сделать, то в юнит-тестах постарайтесь учесть, что он не должен сделать.

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

Или ещё один пример: у вас на сайте акция - каждый 100ый зарегистрированый пользователь получает подарок. Как бы так проверить, что подарки выдаются, и не создавать при этом 100 лишних пользователей? Вот тут уже пишите юнит-тесты. Без них, скорее всего, никак.

Если в вашем приложении четко выражена бизнес-логика, например: «этот метод создает пользователя, а этот метод позволяет менять статус группы», то вполне резонно покрыть и такие методы юнит-тестами.

И ещё: если вы создаете сайт или приложение на основе своего фреймворка, CMS, или каких-то своих модулей к этим фреймворкам и CMS - обязательно пишите к ним модульные тесты. Тут без вариантов. Если же вы используете сторонние популярные решения, а не изобретаете велосипеды, то скорее всего их код уже протестирован автором и зацикливаться на их тестировании не стоит.

Для юнит-тестирования фреймворков много.