что такое тест сьют в тестировании
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 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) — документ, описывающий последовательность действий по выполнению теста (также известен как «тест-скрипт»). Внимание! Из-за особенностей перевода очень часто под термином «тест-сценарий» («тестовый сценарий») имеют в виду набор тест-кейсов.
Test Suite — удобный инструмент автоматического тестирования
Перед тестировщиками в компаниях обычно стоит широкий спектр задач, для решения которых необходимо применять различные подходы к тестированию. Как правило, наиболее востребовано функциональное тестирование, то есть определение способности ПО в конкретных условиях решать задачи, нужные пользователям. В такой работе тестировщикам приходится постоянно повторять большой объем рутинных операций, на что уходит большое количество времени, часто — много больше, чем этого времени есть у сотрудников отдела тестирования.
Очевидным выходом здесь может стать автоматизация процесса тестирования. Для нее существует много инструментов, а целесообразность ее внедрения определяется финансовой окупаемостью решения, которая в первую очередь зависит от возможностей, предоставляемых тестировщику, от того, насколько быстро можно автоматизировать тот или иной кейс, какой уровень навыков для этого нужен, и как дорого будет эту автоматизацию поддерживать. Конечно, у автоматического тестирования есть не только преимущества, но и свои ограничения.
Чтобы сделать выбор в сторону автоматизации, следует разобраться в ее плюсах и минусах.
Преимущества, которые дает тестировщику автоматизация:
Автоматизация тестирования с помощью RPA
Роботизация бизнес-процессов (RPA) интенсивно развивается и, в силу сходства бизнес задач и подходов, может быть полезной в автоматизации тестирования и разработки. При том, что по миру сейчас процент покрытия автоматизированным тестированием в среднем не больше 30%, применение гибких и простых инструментов, таких как RPA, может помочь его поднять до приемлемых величин (считается, что хорошим процентом покрытия для автоматизации тестирования является 60-70%).
Частые изменения экосистемы приложения
Мы уже упоминали среди системных минусов автоматического тестирования частые изменения тех продуктов, с которыми надо работать. К сожалению, пока эта проблема не решена вендорами и если ваша среда тестирования постоянно изменяется — это будет серьезно ограничивать возможности для его автоматизации.
Современные решения, такие как UiPath RPA позволяют частично эту проблему снять за счет применения “умного” захвата элементов UI, понимающего, что внешний вид приложения или структура может, в определенных пределах, меняться; и репозитория объектов, который позволяет централизованно управлять таксономией UI элементов.
Недостаточно знаний бизнеса
Если специалисты не знают функциональности систем, которые они автоматизируют и не понимают самих бизнес-процессов, то в итоге их тест-кейсы могут быть не релевантны решаемой бизнес-задаче. Может произойти ситуация, когда тестировщики что-то тестируют, а реальные сценарии использования продукта остаются в стороне или покрыты только базовые случаи.
Синергия с RPA хорошо помогает здесь тем, что роботизаторы, как правило, глубоко погружаются в бизнес-процессы. Применение опыта полученного при автоматизации бизнес-процессов позволяет создавать действительно работающие и полезные тесты.
Отсутствие тестовых данных и сред
Это большая проблема: для того чтобы сделать хороший тест нужно иметь реальные данные. В свою очередь для этого нужно работать с живой системой, в которой ничего нельзя менять. Нельзя в действующем электронном магазине купить товаров на 100 тысяч, так как собьется вся статистика. Теоретически у тестировщика для работы должен быть тестовый магазин-двойник с теми же самыми данными, но, к сожалению, реализовать подобное очень сложно и, зачастую, непосильно дорого. Для банковских систем эта проблема еще более актуальна и в этой сфере еще меньше реальных тестовых данных.
Вопрос стоит очень остро. В Test Suite есть функционал по работе с генерируемыми тестовыми данными, что, конечно, проблему не решает, но частично снимает, например за счет возможности гибко настраивать сценарии тестирования для того и параметризировать их для запуска в разных средах.
Наличие user friendly инструментов автоматизации
Инструмент для автоматизации тестирования должен быть гибким и легким в освоении, это снижает порог вхождения и позволяет большему количеству сотрудников создавать тесты. Платформа UiPath дружественна к пользователю и наличие онлайн академии, форума, telegram-сообщества в России и т.д. позволяет быстро обучаться. Освоение инструментария UiPath до уровня, необходимого для создания хороших кейсов, намного проще, чем обучение хардкорным вещам типа Selenium. При этом для тех, кто уже уверенно владеет подобными инструментами, изучение UiPath не составит никакой сложности.
На рынке сегодня существует потребность в инструменте, который облегчил бы тестировщикам и инженерам по автоматизации работу с вышеупомянутыми пробелами. Решение Test Suite призвано сделать тестирование и его автоматизацию интуитивно понятными и простыми в обслуживании, так, чтобы у компаний не было больших расходов.
Преимущества Test Suite
Один инструмент для RPA и автоматизации тестирования
Платформа UiPath многофункциональна, совмещает в себе возможности для роботизации и автоматизации тестирования. Это позволяет обмениваться артефактами автоматизации, созданными во всей организации. Кроме того, в рамках тестового пространства платформа способна интегрироваться и работать более чем со 190 технологиями, что значительно облегчает ее внедрение.
Замена устаревших систем на современные
В любой большой экосистеме предприятия или организации функционирует большое количество разных приложений. Совершенно обычна ситуация, когда рядом работают приложения, выпущенные в 90-м году и в 2020, веб-сайты на разных движках и мобильные приложения на разных технологиях. Проблема «зоопарка систем» при тестировании заключается в том, что определенный инструмент подходит для тестирования одного-трех приложений, но не всех сразу. Есть приложения, которые хорошо тестируют веб-сайты и совсем не умеют работать с «толстым» клиентом. Test Suite позволяет создавать единую экосистему и эффективно тестировать ПО различных категорий и версий. В Test Suite можно одновременно тестировать мобильное приложение и веб-ресурсы и не переключаться между большим количеством разных окон.
Минимальные знания программирования
Тестировщик должен заниматься тестированием системы, а не беспокоиться о кодировании. С помощью Test Suite он получает универсальный инструмент тестирования — все задачи, которые у него есть он может решать в одном инструменте с единой методологией и единым подходом, не вдаваясь в детали реализации.
Оркестровка корпоративного уровня
С помощью UiPath можно тестировать и живое, находящееся в эксплуатации, ПО, не обязательно в тестовом контуре. Для этого используются те же технологии, что и для роботизации реальных бизнес-процессов.
Test Suite хорошо интегрируется с CI/CD, в нем есть готовые коннекторы к большинству основных платформ issue tracking, плагины к Jira и SAP Solution Manager.
Простота создания и обслуживания
Решение для тестирования UiPath демонстрирует не только простоту использования, но и снижает затраты на техническое обслуживание. Некоторые из клиентов UiPath уже сообщили о двукратном увеличении тестового покрытия с помощью Test Suite.
При всех преимуществах автоматизации тестирования с помощью Test Suite, надо понимать, что инструмент не может заменить полностью человека, но он, безусловно, поможет сделать работу тестировщика более легкой и полезной.
Гибкая система тестирования и сбора метрик программ на примере 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
Phoronix Test Suite, или как тестировать процессоры it-шнику. Часть 1: Intel vs AMD
Привет, малочисленный народ «клокеров», не потерявший голову от бесконечного потока ругани в комментариях. Отдельное 01101000 01100101 01101100 01101100 01101111 it-шникам, коих тут еще меньше.
реклама
В этой статье я попытаюсь рассказать об инструменте тестирования процессоров (как и системы в целом), который почему-то не популярен в RU-сегменте Интернета и YouTube. Причем не популярен он незаслуженно, ибо этот пакет, нет, «пакетище!» тестов очень комплексно показывает производительность ПК: дисковой подсистемы, gpu, оперативки, и конечно CPU.
Речь сегодня пойдет про автоматизированный пакет тестов Phoronix Test Suite. Этот набор бенчмарков разрабатывался под Linux, но ничего не мешает Вам, особенно тебе 69 74 20 65 6e 67 69 6e 65 65, поставить WSL и посредством bash запустить этот бенч.
Особая фишка в том, что Phoronix Test Suite может: автоматически скачивать пакеты для тестов (и необходимые зависимости), которые ты %username% выберешь, загружать итоговые данные на портал openbenchmarking.org, сохранять результаты в xml и просматривать их в виде красивых графиков в браузере. А еще, Phoronix Test Suite может в мониторинг температуры компонентов системы и измерение потребляемого питания во время тестов, но об этом во второй части.
реклама
Ну что, заинтригован %username%? Ставь аниме на паузу, наливай кофе, готовь сэндвичи. Поехали!
Intro
Тестовая система
реклама
Я запущу пакет с параметром «benchmark 1810170-SK-COREI999026» (заранее сконфигурированный набор тестов и настроек), который установит более двух десятков тестов различной направленности. На каждом этапе бенчмарк сопоставит результат моего 9700К с результатами процессоров:
Все процессоры были в стоке. Память использовалась одна и та же (3200Mhz, Corsair, 16-18-18-36). Бывалый %username% спросит: «Эти модели процессоров, почему выбрал ты, мой юный падаван?» Да потому что именно их я считаю хорошим выбором для рабочей станции современного it-шника.
реклама
P.S. Да, результаты тестов новых Ryzen уже есть в сети, но в базе openbenchmarking.org пока все скудно. 🙁
Результаты тестов
Я выложил сюда результаты не всех тестов, также ограничился количеством протестированных моделей CPU. Больше тестов и моделей процессоров по этой ссылке доступны по данной ссылке.
Компиляция, сборка, научные расчеты
Итак, начнем с тестов по компиляции и сборке проекта при работе с различными языками программирования. Забегая вперед скажу, что тут «решает» быстрый «однопоток» и подсистема памяти, но не во всех тестах.
Один из тестов Java. Комплексная нагрузка на память и процессор. Из-за более высокой частоты на одно ядро и большего кэша 9900К вырывается в лидеры. Threadripper смотрится неплохо. Приятно удивил 8700К.
Знаменитая «шахматная решалка» Stockfish любит многоядерные процессоры. Неожиданностью стал для меня отрыв 9700К от 8700К. По параметру цена/производительность тут у Ryzen 2700X нет конкурентов. Хотелось бы отметить, что этот шахматный движок поддерживает до 512 потоков!
Общая производительность CPU
Далее мы «пройдемся» по тестам, которые покажут производительность CPU в задачах, более распространенных в среде простых пользователей (за исключением BRL-CAD, это все таки тест больше для инженеров).
Далее рассмотрим пару тестов, отображающих производительность CPU при работе c 3D.
Рендер GPL 3D, который поддерживает OpenMP и Intel Threading Building Blocks с множеством различных режимов рендеринга.
Второй тест называется Airckrack-ng. Он предназначен: для обнаружения беспроводных сетей и перехвата их траффика (сниффер), а также для проверки стойкости ключей шифрования WEP и WPA/WPA2-PSK. В отличии от прошлого теста тут важно преимущество процессора по IPC, а также быстрая память и кэш.
Итак, если тебе %username% нравится сериал «Мистер Робот» и вообще ты «крутой хацкер», то ты теперь знаешь какой процессор покупать 🙂
Outro
Каюсь, я не стал вставлять сюда все данные тестов (знатная бы простыня получилась), так как некоторые из них отказались устанавливаться в автоматическом режиме, и мне пришлось доставлять их вручную, например:
. и многие другие. Все результаты тестов можно посмотреть перейдя по данной ссылке.
Что же касается результатов тестирования, то навязывать свое мнение я никому не буду, пусть каждый сам сделает свои выводы, ведь все данные перед глазами. Тем более, что целью статьи ставилось не столько сравнение процессоров, сколько предварительное ознакомление читателя с тестовым пакетом Phoronix.
Post Scriptum
Во второй части статьи я сделаю больше тестов по компиляции, тех что просили в комментариях: С++, Gradle, Chrome (webkit-build), а также добавлю: сборку NodeJS, пару тестов по PHP и Apache, а также бенчмарки по базам данных: SQL Lite, PostgreSQL, MongoDB и возможно Redis, применяемый в качестве кэширующего слоя при работе с БД.