Что такое test suite
CUnit: Автоматическое тестирование с динамической загрузкой тестов
Задача: создать «дружелюбное» окружение над фреймворком CUnit, позволяющие разработчикам/тестерам без дополнительных телодвижений добавлять новые тесты. Почему в качестве фреймворка используется CUnit? Все просто: звезды так сошлись.
Здесь я не буду описывать как работает CUnit или как писать тест-кейсы и тест-сьюты с использованием данного фреймворка. Все это есть в официальной документации, которая расположена по адресу http://cunit.sourceforge.net/doc/index.html.
Итак, вначале определимся со структурой каталогов и файлов:
Каждый тест-сьют будет расположен в отдельном файле в каталоге suites. Задача разработчика или тестировщика только написать тест-сьют и положить его в папку suites. Других телодвижений от разработчика/тестера не требуется, тест-сьют будет автоматически подхвачен системой сборки для компиляции, а потом собственно и исполняемой программой при запуске тестов.
После сборки на выходе мы должны получить runtests — исполняемая программа и модули с тест-сьютами.
Соглашение о наименовании функций
Договоримся, что тест-кейсы будут иметь префикс test_. То есть если мы тестируем библиотечную функцию foo(), то тест-кейс для функции должен называться test_foo().
В каждом динамическом модуле тест-сьюте должна быть экспортирована функция runSuite(), которая будет вызываться в исполняемой программе. В даной функции должен создаваться тест-сьют, средствами CUnit, с которым связываются тест-кейсы. Прототип функции:
Шаблон динамического модуля — тест-сьют
suite1.c:
Как это должно работать
В момент запуска исполняемой программы runtests она загружает все динамические модули — тест-сьюты из каталога suites, если не задана переменная окружения TEST_MODULES_DIR, и выполняет функцию runSuite() каждого модуля. Если указана переменная среды окружения TEST_MODULES_DIR, то модули будут загружаться из каталога на который указывает эта переменная
Реализация
Первым дело реализуем основную программу и вспомогательную функцию поиска динамических модулей. Функции будут реализованы в файле main.c:
Вспомогательные функции и макросы окружения
Для того чтобы постоянно вручную не писать префикс у тест-кейсов или, чего хуже, если в последующем префикс будет изменен, не переименовывать все тест-кейсы напишем вспомогательный макрос TEST_FUNCT:
Теперь вместо того чтобы писать:
Добавим еще один макрос ADD_SUITE_TEST для добавления тест-кейсов к тест-сьюту:
Ну и последние, что нам нужно — это вспомогательная функция для создания тест-сьюта CUnitCreateSuite()
Макросы и пртотипы вспомогательных функций расположены в файл utils.h:
В файле utils.c реализуем вспомогательные функции:
Что такое test suite
Тестовый набор включает в себя, кроме тестовых сценариев, ещё и тестовые данные и правила их генерации.
На примере Test Suite можно рассмотреть так:
Test Case – это один кирпич из стены.
Тест дизайн (Test Design) – это этап процесса тестирования ПО, на котором проектируются и создаются тестовые случаи (Test Case), в соответствии с определёнными ранее критериями качества и целями тестирования.
Существуют системы для описания тест-кейсов, например: TestLink, TestRail, QaTraq, (и как расширения для Jira, например, Zephyr Scale).
Тест кейсы разделяют по ожидаемому результату на позитивные и негативные:
Высокоуровневый тест-кейс (high level test case) — тест-кейс без конкретных входных данных и ожидаемых результатов.
Как правило, ограничивается общими идеями и операциями, схож по своей сути с подробно описанным пунктом чек-листа. Достаточно часто встречается в интеграционном тестировании и системном тестировании, а также на уровне дымового тестирования. Может служить отправной точкой для проведения исследовательского тестирования или для создания низкоуровневых тест-кейсов.
Низкоуровневый тест-кейс (low level test case) — тест-кейс с конкретными входными данными и ожидаемыми результатами. Представляет собой «полностью готовый к выполнению» тест-кейс и вообще является наиболее классическим видом тест-кейсов.
Начинающих тестировщиков чаще всего учат писать именно такие тесты, т.к. прописать все данные подробно — намного проще, чем понять, какой информацией можно пренебречь, при этом не снизив ценность тест-кейса.
Спецификация тест-кейса (test case specification) — документ, описывающий набор тест-кейсов (включая их цели, входные данные, условия и шаги выполнения, ожидаемые результаты) для тестируемого элемента (test item, test object).
Спецификация теста (test specification) — документ, состоящий из спецификации тест-дизайна (test design specification), спецификации тест-кейса (test case specification) и/или спецификации тест-процедуры (test procedure specification).
Тест-сценарий (test scenario, test procedure specification, test script) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»). Внимание! Из-за особенностей перевода очень часто под термином «тест-сценарий» («тестовый сценарий») имеют в виду набор тест-кейсов.
Гибкая система тестирования и сбора метрик программ на примере LLVM test-suite
Введение
Большинство разработчиков однозначно слышали о довольно значимых open-source разработках таких, как система LLVM и компилятор clang. Однако LLVM сейчас не только непосредственно сама система для создания компиляторов, но уже и большая экосистема, включающая в себя множество проектов для решения различных задач, возникающих в процессе любого этапа создания компилятора (обычно у каждого такого проекта существует свой отдельный репозиторий). Часть инфраструктуры естественно включает в себя средства для тестирования и бенчмаркинга, т.к. при разработке компилятора его эффективность является очень важным показателем. Одним из таких отдельных проектов тестовой инфраструктуры LLVM является test-suite (официальная документация).
LLVM test-suite
При первом беглом взгляде на репозиторий test-suite кажется, что это просто набор бенчмарков на C/C++, но это не совсем так. Помимо исходного кода программ, на которых будут производиться измерения производительности, test-suite включает гибкую инфраструктуру для их построения, запуска и сбора метрик. По умолчанию он собирает следующие метрики: время компиляции, время исполнения, время линковки, размер кода (по секциям).
Test-suite естественно полезен при тестировании и бенчмаркинге компиляторов, но также он может быть использован для некоторых других исследовательских задач, где необходима некоторая база кода на C/C++. Те, кто когда-то предпринимал попытки сделать что-то в области анализа данных, думаю, сталкивались с проблемой недостатка и разрозненности исходных данных. А test-suite хоть и не состоит из огромного количества приложений, но имеет унифицированный механизм сбора данных. Добавлять собственные приложения в набор, собирать метрики, необходимые именно Вашей задаче, очень просто. Поэтому, на мой взгляд, test-suite (помимо основной задачи тестирования и бенчмаркинга) — хороший вариант для базового проекта, на основе которого можно строить свой сбор данных для задач, где нужно анализировать некоторые особенности программного кода или некоторые характеристики программ.
Структура LLVM test-suite
Структура простая и понятная.
Принцип работы
Как видно за всю работу по описанию сборки, запуска и сбора метрик отвечают CMake и специальный формат lit-тестов.
Если рассматривать очень абстрактно, понятно, что процесс бенчмаркинга с помощью это системы выглядит просто и весьма предсказуемо: 
Как же это выглядит более детально? В данной статье хотелось бы остановится именно на том, какую роль во всей системе играет CMake и что из себя представляет единственный файл, который Вы должны написать, если хотите что-то добавить в данную систему.
1. Построение тестовых приложений.
В качестве билд-системы используется ставший уже фактически стандартом для программ на C/C++ CMake. CMake производит конфигурацию проекта и генерирует в зависимости от предпочтений пользователя файлы make, ninja и т.д. для непосредственного построения.
Однако в test-suite CMake генерирует не только правила, как собрать приложения, но и производит конфигурацию самих тестов.
Но так как данный файл генерируется автоматически, то именно в файле CMake для бенчмарка описывается: как получить объектные файлы, как их собрать в приложение, а потом еще и что с этим приложением нужно делать.
Для лучшего понимания поведения по умолчанию и того, как же это описывается, рассмотрим пример некоторого CMakeLists.txt
Флаги могут устанавливаться в зависимости от платформы, в test-suite cmake modules входит файл DetectArchitecture, который определяет целевую платформу, на которой запускаются бенчмарки, поэтому просто можно использовать уже собранные данные. Также доступны и другие данные: операционная система, порядок байтов и т.д.
В принципе, в данной части не должно быть ничего нового для людей, которые хотя бы когда-то видели или писали простой CMake файл. Естественно, Вы можете использовать библиотеки, строить их сами, в общем, использовать любые средства, предоставляемые CMake для того, чтобы описать процесс сборки Вашего приложения.
Есть 2 базовых макроса llvm_multisource и llvm_singlesource, которых для большинства тривиальных случаев хватает.
Если Вас это устраивает, это просто замечательно, Вам хватит одной дополнительной строчки (вызова llvm_multisource или llvm_singlesource), чтобы запустить приложение и получить следующие метрики: размер кода (по секциям), время компиляции, время линковки, время исполнения.
Но, естественно, редко бывает все так гладко. Вам может потребоваться изменить одну или несколько стадий. И это возможно тоже с помощью простых действий. Единственное, нужно помнить, что, если переопределяете некоторую стадию, нужно описать и все остальные (даже если алгоритм их работы по умолчанию устраивает, что, конечно, немного огорчает).
В API существуют макросы для описания действий на каждой стадии.
Про макрос llvm_test_prepare для подготовительной стадии особенно писать нечего, туда просто в качестве параметра передаются команды, которые нужно выполнить.
Что может понадобиться в секции запуска? Самый предсказуемый случай – приложение принимает некоторые аргументы, входные файлы. Для этого есть макрос llvm_test_run, который принимает только аргументы запуска приложения (без имени исполняемого файла) в качестве параметров.
Для изменения действий на этапе проверки корректности используется макрос llvm_test_verify, который принимает любые команды в качестве параметров. Конечно, для проверки корректности лучше использовать инструменты, включенные в папку tools. Они предоставляют неплохие возможности для сравнения сгенерированного выхода с ожидаемым (существует отдельная обработка для сравнения вещественных чисел с некоторой погрешностью и т.п.). Но можно где-то и просто проверить, что приложение завершилось успешно и т.д.
А что, если есть необходимость собирать некоторые дополнительные метрики? Для этого существует макрос llvm_test_metric.
Например, для dhrystone можно получить специфичную для него метрику.
Конечно, если нужно собрать для всех тестов дополнительные метрики данный способ несколько неудобен. Нужно либо добавлять вызов llvm_test_metric в высокоуровневые макросы, предоставляемые интерфейсом, либо можно использовать TEST_SUITE_RUN_UNDER (переменную CMake) и специфичный скрипт для сбора метрик. Переменная TEST_SUITE_RUN_UNDER довольна полезна, и может быть использована, например, для запуска на симуляторах и т.п. По сути в нее записывается команда, которая примет на вход приложение с его аргументами.
В итоге же получаем некоторый CMakeLists.txt вида
Интеграция не требует дополнительных усилий, если приложение уже собирается с помощью CMake, то в CMakeList.txt в test-suite можно включить уже существующий CMake для сборки и дописать несколько простых вызовов макросов.
В результате своей работы CMake сгенерировал специальный тестовый файл по заданному описанию. Но как этот файл выполняется?
lit всегда использует некоторый конфигурационный файл lit.cfg, который, соответственно, существует и в test-suite. В данном конфигурационном файле указываются различные настройки для запуска тестов, в том числе задается формат исполняемых тестов. Test-suite использует свой формат, который находится в папке litsupport.
Данный формат описан в виде класса теста, унаследованного от стандартного lit-теста и переопределяющий основной метод интерфейса execute. Также важными компонентами litsupport является класс с описанием плана выполнения теста TestPlan, который хранит все команды, которые должны быть выполнены на разных стадиях и знает порядок стадий. Для предоставления необходимой гибкости в архитектуру также внесены модули, которые должны предоставлять метод mutatePlan, внутри которого они могут изменять план тестирования, как раз и внося описание сбора нужных метрик, добавляя дополнительные команды для измерения времени к запуску приложения и т.д. За счет подобного решения архитектура хорошо расширяется.
Примерная схема работы test-suite теста (за исключением деталей в виде классов TestContext, различных конфигураций lit и самих тестов и т.д.) представлена ниже.
Lit вызывает выполнение указанного в конфигурационном файле типа теста. TestSuiteTest парсит сгенерированный CMake тестовый файл, получая описание основных стадий. Затем вызываются все найденные модули для изменения текущего плана тестирования, запуск инструментируется. Потом полученные тестовый план исполняется: выполняются по порядку стадии подготовки, запуска, проверки корректности. При наличии необходимости может быть выполнено профилирование (добавляемое одним из модулей, если при конфигурации устанавливалась переменная, показывающая необходимость профилирования). Следующим шагом собираются метрики, функции для сбора которых были добавлены стандартными модулями в поле metric_collectors в TestPlan, а затем происходит сбор дополнительных метрик, описанных пользователем в CMake.
3. Запуск test-suite
Запуск test-suite возможен двумя способами:
Результаты от разных запусков можно сравнить и без LNT (хотя данный фреймворк предоставляет большие возможности для анализа информации с помощью разных инструментов, но он нуждается в отдельном обзоре), воспользовавшись скриптом, входящим в test-suite
Системы управления тест кейсами. Какую выбрать для немедленной работы?
Как будем искать систему?
В чем сложность выбора?
Во-первых система должна нравиться и удовлетворять вашим предпочтениям. Например: легкое и простое создание кейсов, гибкая настройка (кастомизация), удобство использования, определите для себя, какая система должна быть?
Не подходят 100%
TestLink. Плюсы открытое ПО. Минусы: морально и физически устарела, при установке могут возникнуть сложности, сложная или невозможная интеграция с Jira.
TXT, DOC, XLSX. Плюсы: Бесплатно, можно сразу планировать работу, можно создавать черновики тест-кейсов, использовать как архив или заготовки. Минусы: никакой интеграции, нет контроля и учета времени.
Testia Tarantula. Плюсы: бесплатная. Минусы: плохая отчетность, нет интеграции, нет кастомизации.
Qtest. Триал версия только под заказ.
Practitest. Дорогая.
TestLodge. Будет отдельный абзац, см. ниже
Фавориты YouTube и статей: TestRail, Zephyr for Jira, QASE
Zephyr for Jira
Начнем с того, что Зефир – это не самостоятельная программа, это плагин для Jira. Поэтому, если вы не используете Jira, она вам скорее всего сразу же не подойдет.
Отдельно из минусов отмечу, что посмотреть на YouTube обзор без знания английского не получится, так, я смотрел туториал на этом канале, а он на «индийском» английском.
Ну очень много всего нужно сделать чтоб что-то заработало. Хорошая интеграция, красивые красочные отчеты, но сделана не для людей, пока заполняешь все обязательные поля для создания тест кейса, а затем столько же, а точнее, даже и больше полей, чтоб запустить тест ран, проходит много времени, а поля обязательные.
Если коротко, то просмотрел 90 минут видео-туториала, в котором к тест рану так и не приступили. Усложненная система написания тест-кейсов. – это и хорошо и плохо одновременно.
Т.к. инструмент очень мощный, то и времени и внимания требует к себе очень много. Подход к проверкам учитывает всё время, потраченное на написание тест-кейса и включает в себя: Review Story, Write Test Case, Execute Test Case всё происходит в виде тасок и подтасок на панели Скрам в формате спринтов.
TestRail
Честно, очень долгое время боготворил эту систему, т.к. отзывы везде положительные, так с энтузиазмом сравнивают с Zephyr For Jira на многих ресурсах, в т.ч. в статьях на HABR. Ну что ж, раз ее так расхваливают, значит нужно брать тестовый период и пробовать заполнять репозиторий, и назначать себе тест-раны. Но только уже при составлении тест-кейсов сразу нашелся непоправимый минус, который поменял мой взгляд на TestRail – нельзя помечать пройденный шаг. Еще один минус – тестовый период, мне кажется очень короткий. Я уже примерно месяц выбираю инструмент для хранения кейсов – и честно скажу – это достаточно сложная задача, т.к. тебе нужно опробовать все или почти все системы и дать объективный ответ, почему ты сделал такой выбор.
В целом, у TestRail достаточно большой список интеграций: Slack, Jira, GitHub и др. Инструмент достаточно мощный, но, к сожалению, мне не подошел.
А TestLodge чем не угодила?
Ну с Лоджем, очень интересно, после рассмотрения TestRail и QASE – Lodge кажется очень не доработанным, мало того, я вам скажу, что функционала в блокноте (NotePad) может и не больше, но вот Excel 100% может Lodge переплюнуть, т.к. в составленных мною кейсах в Excel – имеется возможность напротив каждого шага ставить резолюцию и прохождении или непрохождении каждого шага, например, я реализовывал данную фичу заливкой разных цветов – Зеленый – passed, Красный – Failed, Фиолетовый – Blocked и т.д., т.к. количество цветов не ограничено.
Давайте перечислим минусы TestLodge:
Ввод шагов сплошным текстом
Естественно, мы не можем на каждом шаге оставлять резолюцию пройден он или пропущен или вообще здесь БАГ
Ожидаемый результат указывается только один при прохождении всех шагов
Резолюция прохождения кейса описывается всего тремя сценариями – PASS, FAIL, SKIP
Система QASE
Неожиданно, после долгих скитаний по ресурсам интернет-статей видео на ютюб, случайно в одной из статей на аж 8м месте нашел неприметную систему QASE. Удивительно, что такая хорошая (на мой взгляд) система оказалась недооценена и о ней так мало информации. Самый большой плюс, помимо ее бесплатности – это возможность оставлять резолюции с комментариями на каждом шаге тест-кейса. Давайте оформим плюсы системы в виде списка, так будет нагляднее.
Для каждого шага есть поле для вводных данных, а также ожидаемый результат, что позволяет сделать более широкое покрытие тест-кейсами (включать микро-сценарии по ранее заведенным ошибкам), а также более подробно описать каждый шаг, а самое главное – что мы от него ожидаем.
У каждого шага можно выбрать одно из 4х состояний (Скрин 1): Pass, Fail, Skip, Block – это позволяет тест-кейсу быть более гибким, в него можно включить «экзотические сценарии» (без фанатизма), основанные и выявленные на фоне ранее заведенных ошибок. По опыту работы в Яндексе асессор-тестировщиком могу сказать, что это ужасно удобный функционал, т.к. шаг, на котором выявлено несоответствие сразу заносится в баг репорт, а также заносится окружение, стенд, и ранее пройденные шаги, вам остается придумать и написать правильный заголовок.
Для каждого шага можно написать комментарий.
У каждого тест-кейса может быть 5 состояний (Скрин 2): Passed, Failed, Blocked, Skiped, Invalid (такое редко, но бывает, Когда тест кейс есть, но он сломан или не актуален).
Программа бесплатна (до 3-х пользователей).
Имеется возможность кастомизации.
Поиск по ключевым словам, которые ранее сами занесете.
Скрин 1 – Комментарий и статус к каждому шагу 
Скрин 2 – Возможность выбирать статусы тест-кейса
Попарное тестирование: суть техники, инструменты и примеры
Что такое попарное тестирование и почему оно является эффективной техникой тест-дизайна? Поговорим об этом ниже. Статья предназначена для начинающих специалистов по тестированию.
В этой статье пойдет речь о комбинаторной технике попарного тестирования (известной также как Pairwise testing или All-pairs testing).
Умное тестирование служит во благо экономии времени. Часто команда тестировщиков вынуждена работать в рамках жестких сроков 90% своего времени. По этой причине техники тест-дизайна должны быть эффективными, чтобы с их помощью можно было достичь максимально возможной степени покрытия тестами и вероятности обнаружения дефектов.
Что такое попарное тестирование?
Попарное тестирование — это техника тест-дизайна, которая обеспечивает полное тестовое покрытие.
ISTQB определяет попарное тестирование как технику тест-дизайна методом черного ящика, при которой тест-кейсы создаются таким образом, чтобы выполнить все возможные отдельные комбинации каждой пары входных параметров.
Результат работы приложения зависит от многих факторов, например, входных параметров, переменных состояний и конфигураций среды. Для определения возможных значений могут быть полезны такие техники, как анализ граничных значений и использование классов эквивалентности. Однако тестировать все возможные комбинации значений для всех факторов — непрактично. Поэтому, чтобы удовлетворить все факторы, генерируется подмножество комбинаций.
Техника попарного тестирования очень помогает при разработке тестов для приложений, включающих множество параметров. Тесты разрабатываются таким образом, что для каждой пары входных параметров существуют все возможные комбинации этих параметров. Тестовые наборы (тест-сьюты, Test suite) охватывают все комбинации. Поэтому техника хоть и не обеспечивает исчерпывающее тестирование, но все же является эффективной для поиска ошибок.
Давайте посмотрим, как применять технику попарного тестирования на примере.
Пример применения попарного тестирования
Приложение для заказа автомобиля:
С помощью приложения можно покупать и продавать машины. Приложение должно поддерживать оказание услуг в Дели и Мумбаи.
В приложении должны содержаться регистрационные номера, которые могут быть валидными и невалидным. Оно должно разрешать продажу следующих марок автомобилей: BMW, Audi и Mercedes.
Доступны два типа бронирования: бронирование через интернет и в офлайн-магазине.
Заказы доступны к размещению только в рабочие часы.
Шаг 1. Перечислим задействованные переменные.
Категория заказа
а. Купить
б. Продать
Местоположение
а. Дели
б. Мумбаи
Марка автомобиля
а. BMW
б. Audi
в. Mercedes
Регистрационные номера
а. Валидные (5000)
б. Невалидные
Тип заказа
а. Заказ через Интернет
б. Заказ в магазине
Время заказа
а. Рабочие часы
б. Нерабочие часы
Если тестировать все возможные допустимые комбинации: 2 X 2 X 3 X 5000 X 2 X 2 = получаем 240 тысяч комбинаций 🙁 Кроме того, недопустимых комбинаций вообще может быть бесконечное количество.
Шаг №2: Давайте упростим
Используем умную репрезентативную выборку.
Используем классы эквивалентности и граничные значения, даже если данные — непрерывные.
Сокращаем регистрационные номера до двух типов:
Валидный регистрационный номер
Невалидный регистрационный номер
Теперь посчитаем количество возможных комбинаций: = 2 X 2 X 3 X 2 X 2 X 2 = 96
Шаг 3. Упорядочивание задействованных переменных и значений.
Когда мы классифицируем задействованные переменные и значения, то получим что-то вроде этого:
Теперь отсортируем переменные так, чтобы переменные с наибольшим количеством значений шли первыми, а с наименьшим — последними.
Шаг 4. Расставляем переменные для создания набора тестов.
Давайте начнем заполнять таблицу столбец за столбцом. Изначально таблица выглядит примерно таким образом. Три значения в столбце «Марка авто» (переменная с наибольшим количеством значений) напишем дважды каждое (потому что следующая переменная, «Категория заказа», содержит два значения.
Столбец «Категория заказа» содержит два значения. И именно столько раз нам надо вставить значения первого столбца «Марка авто».
Для каждого набора значений в первом столбце мы помещаем оба значения второго столбца. Повторяем то же самое для третьего столбца.
Теперь у нас есть Покупка&Дели, но нет Покупка&Мумбаи. Есть Продажа&Мумбаи, но нет Продажа&Дели. Давайте поменяем значения из второго набора в третьем столбце.
Так уже выглядит получше.
Повторим шаги для столбцов 3 и 4.
Если сравнить столбцы 3 и 4, каждое значение из столбца 3 имеет пару с обоими значениями из столбца 4. Но если сравнить второй и четвертый столбец, у нас есть комбинации Покупка&Валидный и Продажа&Невалидный, но нет комбинаций Покупка&Невалидный и Продажа&Валидный. Следовательно, нам надо поменять местами последний набор значений в четвертом столбце.
С шестым столбцом (Время заказа) у нас проблемка: не хватает пар Покупка&Нерабочие часы и Продажа&Рабочие часы. Нам не удастся получить недостающие пары, поменяв значения местами, поскольку мы ранее уже поменяли местами все строки, и если мы снова начнём их менять, то есть риск пропустить другие возможные пары. Поэтому добавим еще два тестовых случая, которые содержат эти пары. Заполним пустые строки!
Теперь мы заполним пустые ячейки на свое усмотрение, потому что другие значения переменных являются произвольными (обозначим знаком тильды
Итого мы получили всего 8 тест-кейсов вместо 96.
Мы увидели, насколько эффективной может быть техника попарного тестирования. Она здорово повышает шансы найти баги, при этом сохранив время.
Однако эта техника имеет и некоторые ограничения. Она не сработает, если:
выбранные для тестирования значения некорректны;
мало внимания уделяется комбинациям, которые могут привести к ошибке с высокой долей вероятности;
взаимодействие между переменными недостаточно изучено.
Инструменты попарного тестирования:
Приведем примеры популярных инструментов, которые помогают эффективно автоматизировать процесс дизайна тест-кейсов путем создания компактного набора значений параметров в качестве желаемых тест-кейсов:
PICT – Попарное независимое комбинаторное тестирование от Microsoft Corp.
IBM FoCuS – Единое решение для функционального покрытия от IBM.
ACTS – Расширенная комбинаторная система тестирования от NIST, агентства правительства США.
VPTag – бесплатный инструмент попарного тестирования
Заключение:
Техника попарного тестирования помогает существенно уменьшить количество комбинаций проверок, достаточных для обеспечения необходимого уровня качества программного обеспечения. Это в самом деле умная техника тест-дизайна, которая гарантирует беспроигрышный результат как с точки зрения усилий и задействованных ресурсов, так и с точки зрения эффективности тестирования.
Об этой технике стоит помнить на этапе планирования тестирования. Независимо от того, генерируются ли тестовые случаи вручную или используется какой-либо вспомогательный инструмент, она становится необходимым компонентом тест-плана, потому что влияет на оценку тестирования.
Всех желающих приглашаем на бесплатное demo-занятие «Теория тестирования: виды тестирования». Чтобы быть хорошим специалистом, нужно понимать, какие виды тестирования бывают. На этом занятии мы:
— обсудим, по каким направлениям можно протестировать наш программный продукт;
— узнаем, что скрывается за белыми и черными ящиками;
— а также обсудим, чем отличаются стресс тесты от нагрузочных.