13. Автоматизация модульного тестирования.

Оболочки тестирования (frameworks) – программные средства для разработки unit-тестов. Они включают в себя построение тестов, их выполнение, вывод результатов их прохождения. Они м.б. использованы не только как программные тестирования, но и как программные средства разработки. Эти оболочки могут использоваться на любой стадии разработки, включая разработку программной архитектуры, дизайна, реализацию кода, отладку, оптимизацию производительности и обеспечение качества.

Семейство XUnit состоит из следующих реализация:

JUnit – для тестирования java-кода,

CppUnit – для тестирования С++ кода,

NUnit – для тестирования .NET-приложений и тд

Для получения результатов тестирования с использованием семейства XUnit необходимо иметь:

1. Test Case

2. Test Suite = Test Result

3. Test Runner

1. – класс, наследуемый от базового XUnitTestCase – класса. TestCase состоит из одного или нескольких тестов, описанных в методах этого класса. Обычно TestCase содержит в себе методы для тестирования одной функциональной направленности.

2. – группа тестов, предназначенная для сборки родственных тестов. По умолчанию создается TestSuite, включающий все имеющиеся тесты.

3. - тестовый исполнитель, объект для запуска тестовых наборов (TestSuite). XUnit предоставляет несколько тестовых исполнителей, которые наследуются от интерфейса BaseTestRunner.

Преимущества и недостатки XUnit:

Преим-ва:

1. реализация XUnit – надстройки над языком. Физически это – набор библиотек классов. Поэтому для написания и прогонки тестов необходимо иметь эти наборы библиотек.

2. могут использоваться на различных платформах

3. высокая скорость работы скриптов, т.к. отсутствует посредник – веб-браузер.

Реализация XUnit при тестировании веб-приложений позволяет обойти браузер и получить доступ к сайту напрямую. Происходит эмуляция поведения браузера, включая заполнение форм, работу с элементами на странице, работа с cookies. Т.о. происходит тестирование методом «серого ящика» - напрямую с сервером без участия браузера.

4. тестируется чистое приложение без учета работы браузера

5. XUnit’s являются свободно распространяемыми продуктами.

Недостатки:

1. В их возможности не входит работа с flash and ActiveX

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

3. Нет возможности записи действий пользователя над тестируемым приложением с целью их последующего воспроизведения для регрессионного теста. Т.о. тестовые случаи разрабатываются исключительно вручную

4. При таком тестировании не осуществляется проверка на правильное отображение страниц, проверка дизайна.

14. Тестовые случаи и их свойства. Процесс разработки тестовых случаев.

Тестовые сценарии (случаи, TestCase) – документ, в котором описывается алгоритмы проверки каждой функциональности программы. Также – совокупность тестовых случаев.

Тестовый случай – алгоритм проверки некоторой функциональности программы.

• уник. ID

• д. им. ссылку на треб-е, кот. он б. проверять

• д. им. название модуля или экрана, в кот. б. происходить тест-е

• д. им. шаги воспроизведения

• ожидаемые рез-ты

Наиб. Удобным вар-ом написания тест-х сценариев является табличный.

№	№ треб.	Название модуля	Название подмодуля	Описание Т Случай	Ожидаемые результаты	Пройден ли тест	Коммента рии
1	R1	Пароль	Пароль	1 ввести имя пользователя 2 в пароль 3 [Далее]	1 с-ма позволит ввести имя …
2	R2	Работа с товаром	Создание	…

Этапы разработки тестовых случаев:

1. ознакомление с требованиями и тестовым планом

2. проектирование тестовых случаев

3. разработка тестовых случаев

4. тестирование тестовых случаев.

Свойства тестовых случаев:

1. Тест-й случай д. обладать высокой степенью вер-сти обнаруж-я бага: нельзя делать предполож-я, что тот или иной функционал работает исправно. Проверять следует весь функционал.

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

3. Тест-й случай д. обладать четко опред-ными ожидаемыми рез-тами и критериями успешного или неудачного вып-я теста: Обычно ожид. рез-ты и критерии испыт-й тесно связаны. Если ожид-й рез-т получен – тест пройден. Иначе – тест не пройден.

4. Тест-й сценарий не д.б. избыточным: Оптимальный рабочий график тестир-я требует, чтобы тестер выполнял объем тестир-я, дост-ный для обнаружения всех багов. Н:о тестер не д. тратить время на провед-е избыточных тестов. Этот вопрос тесно связан с разбиением на классы эквивалентности и анализом граничных значений.