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

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

· Спецификации тестирования компонент, определяющие тест-кейсы для отдельных программных компонент. Они могут составлять разделы спецификаций детализированного дизайна.

Системное и приемочное тестирование требует огромного количества отдельных тест-кейсов.

С целью того, чтобы знать, какие требования тестируется какими тест-кейсами, часто формируется указатель со ссылками между требованиями и тест-кейсами. Обычно его называют указателем ссылок верификации (Verification Cross Reference Index – VCRI) и помещают в виде приложения к тестовой спецификации. Указатели ссылок так же могут использоваться при тестировании компонент и интеграции ПО.

Для проектирования тест-кесов важно как позитивное тестирование, так и негативное тестирование. Позитивное тестирование проверяет, что ПО делает то, что должно.

Негативное тестирование проверяет, что ПО не делает того, что не должно.

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

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

3.4.4. Тестовые процедуры

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

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

Тестовые процедуры всегда должны быть отделены друг от друга, так как они вполне могут иметь дело с деталями, не соответствующими программным спецификациям. Если используются AdaTEST или Cantata, то тестовые процедуры могут быть сразу написаны в виде сценариев AdaTEST или Cantata.

3.4.5. Протоколы

· Протокол о проведении тестовых испытаний составляется в обязательном порядке и должен содержать следующую информацию :

· дата;

· наименование Заказчика;

· наименование Исполнителя;

· объект тестовых испытаний;

· цель испытаний. Цель может быть сформулирована, например, следующим образом : "Определение соответствия адаптированной Исполнителем 1С:АС требованиям Заказчика". Для повторного тестирования может быть добавлено, например, следующее : "Подтвердить исправление ошибок, выявленных при проведении тестовых испытаний, описанных Протоколом № … от ….";

· вид тестирования;

· тип тестовых испытаний: первичное или повторное;

· методы испытаний: на контрольных примерах, моделирующий реальные данные, на реальных данных и т.д.;

· этап тестовых испытаний: промежуточные испытания или окончательные;

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

¾ технические требования (или группа требований) на проверку выполнения которого (которых) направлен пример;

¾ исходные данные примера;

¾ предполагаемые результаты/характеристики ( например для "правильно работающей 1С:АС");

¾ фактически полученные результаты/ характеристики.

· Тестирование производительности. Формулировать наименование показателей требуется конкретно и доступно для понимания. Например:

¾ Допустимая скорость обработки операций при работе пользователей в сетевом режиме;

¾ Время работы отчета "Наименование", и т.д.

· условия проведения тестовых испытаний. Необходимо указать последовательность тестирования, состав и структуру используемых технических средств;

· результат испытаний. Оформляется либо заключение о работоспособности ПС( например 1С:АС), либо перечень необходимых доработок;

· перечень необходимых доработок. Заполняется в случае, если ПС( например 1С:АС) признана непригодной к эксплуатации;

· контрольные суммы (размер) *.md - файла, содержащего информацию по адаптированной конфигурации и дата его последней модификации (для 1С:АС);

· подписи представителей Заказчика и Исполнителя, принимавших участие в проведении тестирования;

· в качестве приложения 1 к Протоколу- отчет (краткий или детальный) об изменениях, сделанных в типовой конфигурации. Отчет необходимо сформировать стандартными средствами конфигуратора, используя режим объединения конфигураций. Для этого рекомендуется запустить типовую конфигурацию в режиме "Конфигуратора" и запустив режим объединения конфигураций, выбрать *.md - файл адаптированной конфигурации. Не производя объединения сформировать отчет об изменениях и распечатать его (для 1С:АС).

3.4.6. Документирование результатов тестирования

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

Каждое выполнение теста должно быть зарегистрировано в журнале тестирования. Журнал тестирования будет содержать записи о том, когда запускался каждый тест, итог выполнения каждого теста и может также содержать важные наблюдения, сделанные при выполнении теста. Зачастую журнал тестирования не ведут для нижних уровней тестирования (тестов компонент и интеграции ПО).

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

4. ИНТЕГРАЦИОННОЕ ТЕСТИРОВАНИЕ

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

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