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

Именно эффективность обнаружения тех или иных типов дефектов должна определять стратегию модульного тестирования, то есть расстановку акцентов при определении набора входных значений. У организации, занимающейся разработкой программного обеспечения, как правило, имеется историческая база данных (Repository) разработок, хранящая конкретные сведения о разработке предыдущих проектов: о версиях и сборках кода (build) зафиксированных в процессе разработки продукта, о принятых решениях, допущенных просчетах, ошибках, успехах и т.п. Проведя анализ характеристик прежних проектов, подобных заказанному организации, можно предохранить новую разработку от старых ошибок, например, определив типы дефектов, поиск которых наиболее эффективен на различных этапах тестирования.

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

Являясь по способу исполнения структурным тестированием или тестированием "белого ящика", модульное тестирование характеризуется степенью, в которой тесты выполняют или покрывают логику программы (исходный текст). Тесты, связанные со структурным тестированием, строятся по следующим принципам:

· На основе анализа потока управления. В этом случае элементы, которые должны быть покрыты при прохождении тестов, определяются на основе структурных критериев тестирования С0, С1, С2. К ним относятся вершины, дуги, пути управляющего графа программы (УГП), условия, комбинации условий и т. п.

· На основе анализа потока данных, когда элементы, которые должны быть покрыты, определяются на основе потока данных, т. е. информационного графа программы.

2.5 Регрессионное тестирование

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

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

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

В свою очередь тестировщик, проверяя внесенные программистом изменения, должен:

· Проверить и утвердить исправление ошибки. Для этого необходимо выполнить указанный в отчете тест, с помощью которого была найдена ошибка.

· Попробовать воспроизвести ошибку каким-нибудь другим способом.

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

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

2.6. Нагрузочное тестирование

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

В рамках нагрузочного тестирования реализуются проекты трех типов:

· исследование масштабируемости и оптимизация программного обеспечения;

· консалтинг в области нагрузочного тестирования;

· инфраструктурная оптимизация.

Исследование масштабируемости.

Масштабируемость — это способность системы адаптироваться к расширению предъявляемых требований и росту объемов решаемых задач, наращивать производительность при увеличении нагрузки и добавлении аппаратных ресурсов.

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

Исследование масштабируемости дает ответы на следующие вопросы:

· Какую нагрузку выдержит используемая аппаратно-программная конфигурация?

· Как повлияет на нагрузочные характеристики изменение аппаратно-программной конфигурации?

· Какие настройки системы оптимальны с точки зрения производительности?

· Как увеличить производительность, не закупая новое оборудование?

· Когда при текущем темпе роста нагрузки будет необходима смена платформы, портирование приложения или выбор нового решения для достижения результата?

· Как быстро устранить причину сбоев системы?

Консалтинг в области нагрузочного тестирования.

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