Анализ тестов на уровне разработки (структурный подход)

Необходимо провести анализ с целью определения требований к тестам, относящихся к созданию тестов для уровня разработки. Анализ на уровне модульного и комплексного тестирования известен также как структурный анализ.
Метод структурного анализа, основанный на архитектуре, подразумевает обзор детализированного описания архитектуры и/или программного кода. Особое значение придается входным и выходным данным программного модуля. Полученные в этом случае требования к тестам основываются на проверке логики архитектуры или реализации программного кода, если детализированная спецификация архитектуры недоступна. Метод анализа, основанный на архитектуре системы, позволяет сформулировать требования к тестам с использованием стратегии белого ящика, проверяющей поведение внутренних компонентов системы, таких как управление, логика и потоки данных. Анализ, основанный на исследовании архитектуры, часто называют также структурным покрытием, что подчеркивает его интерес к структуре программного кода. (more…)

АНАЛИЗ ТРЕБОВАНИЙ К ТЕСТАМ

Как и при разработке приложения, необходимо однозначно определить требования к тестам до начала проектирования тестов. Для того чтобы все сотрудники, занятые в проекте, получили представление об основе проведения тестирования, все требования к тестам должны быть четко определены и документально зафиксированы. Их извлекают из формулировки требований в результате анализа требований к тестам. Целью анализа является определение различных типов тестов, проведение кото-рых необходимо для проверки работы системы. Его проводят посредством изучения системы с разных углов зрения в зависимости от фазы тестирования. (more…)

Введение в анализ

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

Полезная литература

1. Адаптация ANSI/IEEE Std 1008 - 1987.
2. Rational Unified Process 5.0. Jacobson, I., Booch, G., Rumbaugh, J. The Uni¬fied Software Development Process. Reading, MA: Addison-Wesley, 1998.
3. Humphrey, W.S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.

Итог

? Группа тестирования должна исчерпывающе документировать планы программы тестирования, а тестировщики обязаны подробно изучить содержание этих планов. Создание плана тестирования — итеративный процесс, требующий обратной связи с различными участниками проекта и их согласия с определенными в нем подходами, стратегиями тестирования и сроками выполнения работ. (more…)

Итоги

? Элемент методологии жизненного цикла автоматизированного тестирования, называемый «планирование тестирования», включает в себя анализ всех работ, необходимых для проведения тестирования. Он предполагает, что процессы тестирования, методы, методики, персонал, инструменты, план-график и оборудование организованы и применяются эффективно. (more…)

Примерный план тестирования

Примерный план тестирования, приведенный в приложении D, демонстрирует планирование тестирования в вымышленной компании Automation Services Incorporated (AMSI), которая тестирует Систему под названием WallStreet Financial Trading System (WFTS). Примерный план тестирования составлен исключительно для иллюстрации того, какие виды информации и способы ее представления могут использоваться. Поэтому не все его разделы согласованы в полной мере.

Планирование тестирования

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

ПЛАН ТЕСТИРОВАНИЯ

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

Сборка и настройка тестовой среды

По крайней мере один из сотрудников группы тестирования должен обладать навыками администрирования сетей, баз данных и систем. Он поможет при установке и сборке аппаратных компонентов, будучи представителем группы тестирования. Он также мог бы отвечать за установку и настройку программных компонентов, включая инструменты автоматизированного тестирования и все необходимые программы для копирования среды разработки. Необходимо сконфигурировать тестовую среду и разработать скрипты для восстановления конфигурации тестовой среды. В главе 8 описывается использование скриптов настройки среды. (more…)