Как составить test suite - Исправление недочетов и поиск решений вместе с Examum.ru

Введение

Большинство разработчиков однозначно слышали о довольно значимых 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

test-suite
|----CMakeLists.txt	 // Базовый CMake файл, проводящий первичные настройки, добавляющий 
|                               //  модули и т.д.
|
|---- cmake
|     |---- .modules	// Файлы с описанием макросов и функций общего назначения, 
|                              // фактически являющихся API для интеграции тестов
|
|---- litsupport          // Модуль Python, описывающий собственный формат теста для test-suite, 
|                             // распознаваемый средством тестирования lit (входит в LLVM)
|
|---- tools                // Содержит дополнительные инструменты: для сравнения результатов 
|                             // работы программ с ожидаемым выходом(с настройками для точности 
|                             // проверки), измерения времени и т.д.
|
|   // Остальные директории содержат бенчмарки
|
|---- SingleSource     // Содержит тестовые программы, состоящие из одного файла с исходным 
|                              // кодом. В одной директории может находиться много разных тестов.
|     
|---- MultiSource       // Содержит тестовые программы, состоящие из множества файлов с 
|                              // исходным кодом. В одной директории обычно находятся файлы для 
|                              // одного приложения.
|     
|---- MicroBenchmarks // Программы, использующие библиотеку google-benchmark. В них 
|                                // определяются функции, которые выполняются несколько раз, пока 
|                                // результаты измерений не будут статистически значимыми
|     
|---- External             // Содержит описание для программ, которые не входят в test-suite, а 
|                               // именно, исходные коды программ находятся (или могут находиться) 
|                               // где-то в другом месте

Структура простая и понятная.

Принцип работы

Как видно за всю работу по описанию сборки, запуска и сбора метрик отвечают CMake и специальный формат lit-тестов.

Если рассматривать очень абстрактно, понятно, что процесс бенчмаркинга с помощью это системы выглядит просто и весьма предсказуемо:

Как же это выглядит более детально? В данной статье хотелось бы остановится именно на том, какую роль во всей системе играет CMake и что из себя представляет единственный файл, который Вы должны написать, если хотите что-то добавить в данную систему.

1. Построение тестовых приложений.

В качестве билд-системы используется ставший уже фактически стандартом для программ на C/C++ CMake. CMake производит конфигурацию проекта и генерирует в зависимости от предпочтений пользователя файлы make, ninja и т.д. для непосредственного построения.
Однако в test-suite CMake генерирует не только правила, как собрать приложения, но и производит конфигурацию самих тестов.

После запуска CMake в build директорию будут записаны еще файлы (с расширением .test) с описанием того, как приложение должно выполняться и проверяться на корректность.

Пример наиболее стандартного файла .test

RUN: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football/football 
VERIFY: cd <some_path_to_build_directory>/MultiSource/Benchmarks/Prolangs-C/football ; <some_path_to_build_directory>/tools/fpcmp %o football.reference_output

В файле с расширением .test могут быть следующие секции:

PREPARE — описывает любые действия, которые должны быть сделаны до запуска приложения, очень похоже на метод Before существующий в разных фреймворках для unit-тестирования;
RUN — описывает как запустить приложение;
VERIFY — описывает как проверить корректность работы приложения;
METRIC — описывает метрики, которые нужно собрать дополнительно в стандартным.

Любая из данных секций может быть опущена.

Но так как данный файл генерируется автоматически, то именно в файле CMake для бенчмарка описывается: как получить объектные файлы, как их собрать в приложение, а потом еще и что с этим приложением нужно делать.

Для лучшего понимания поведения по умолчанию и того, как же это описывается, рассмотрим пример некоторого CMakeLists.txt

list(APPEND CFLAGS -DBREAK_HANDLER -DUNICODE-pthread)	# необходимые для приложения флаги компиляции (остальные более общие флаги компиляции вроде уровня оптимизации и т.п. лучше указывать при вызове CMakе, чтобы иметь возможность в дальнейшем ставить эксперименты) 
list(APPEND LDFLAGS -lstdc++ -pthread) # необходимые для приложения флаги для линкера

Флаги могут устанавливаться в зависимости от платформы, в test-suite cmake modules входит файл DetectArchitecture, который определяет целевую платформу, на которой запускаются бенчмарки, поэтому просто можно использовать уже собранные данные. Также доступны и другие данные: операционная система, порядок байтов и т.д.

if(TARGET_OS STREQUAL "Linux")
  list(APPEND CPPFLAGS -DC_LINUX)
endif()
if(NOT ARCH STREQUAL "ARM")
  if(ENDIAN STREQUAL "little")
    list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=0)
  endif()
  if(ENDIAN STREQUAL "big")
    list(APPEND CPPFLAGS -DFPU_WORDS_BIGENDIAN=1)
  endif()
endif()

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

А дальше нужно обеспечить генерацию .test файла. Какие средства предоставляет интерфейс tets-suite для этого?

Есть 2 базовых макроса llvm_multisource и llvm_singlesource, которых для большинства тривиальных случаев хватает.

llvm_multisource используется, если приложение состоит из нескольких файлов. Если Вы не передадите файлы с исходным кодом как параметры при вызове этого макроса в своем CMake, то будут использованы все файлы исходного кода, находящиеся в текущей директории, в качестве базы для построения. На самом деле, сейчас происходят изменения в интерфейсе данного макроса в test-suite, и описанный способ передачи исходных файлов в виде параметров макроса – это текущая версия, находящаяся в master ветке. Раньше была другая система: файлы с исходным кодом должны были быть записаны в переменную Source (так было еще в релизе 7.0), а макрос не принимал никаких параметров. Но основная логика реализации осталась прежней.
llvm_singlesource считает, что каждый .c/.cpp файл – это отдельный бенчмарк и для каждого собирает отдельный исполняемый файл.

По умолчанию, оба описанных выше макроса для запуска построенного приложения генерируют команду, которая просто вызывает это приложение. А проверка корректности происходит за счет сравнения с ожидаемым выходом, находящимся в файле с расширением .reference_output (также с возможными суффиксами .reference_output.little-endian, .reference_output.big-endian).

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

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

В API существуют макросы для описания действий на каждой стадии.

Про макрос llvm_test_prepare для подготовительной стадии особенно писать нечего, туда просто в качестве параметра передаются команды, которые нужно выполнить.

Что может понадобиться в секции запуска? Самый предсказуемый случай – приложение принимает некоторые аргументы, входные файлы. Для этого есть макрос llvm_test_run, который принимает только аргументы запуска приложения (без имени исполняемого файла) в качестве параметров.

llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm)

Для изменения действий на этапе проверки корректности используется макрос llvm_test_verify, который принимает любые команды в качестве параметров. Конечно, для проверки корректности лучше использовать инструменты, включенные в папку tools. Они предоставляют неплохие возможности для сравнения сгенерированного выхода с ожидаемым (существует отдельная обработка для сравнения вещественных чисел с некоторой погрешностью и т.п.). Но можно где-то и просто проверить, что приложение завершилось успешно и т.д.

llvm_test_verify("cat %o | grep -q 'exit 0'")  # %o - это специальный placeholder для выходного файла, который понимает lit. Так как дальше эти команды будут выполняться с помощью lit, то можно использовать все, что он способен распознать. Подробной информации о lit (инструмент для тестирования, входящий в LLVM) в данном материале не будет (можно ознакомиться с <a href="https://llvm.org/docs/CommandGuide/lit.html">официальной документацией</a>)

А что, если есть необходимость собирать некоторые дополнительные метрики? Для этого существует макрос llvm_test_metric.

llvm_test_metric(METRIC <имя метрики> <команда, позволяющая получить значение>)

Например, для dhrystone можно получить специфичную для него метрику.

llvm_test_metric(METRIC dhry_score grep 'Dhrystones per Second' %o | awk '{print $4}')

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

В итоге же получаем некоторый CMakeLists.txt вида

# У нас нет специфичных флагов компиляции
llvm_test_run(--fixed 400 --cpu 1 --num 200000 --seed 1158818515 run.hmm)
llvm_test_verify("cat %o | grep -q 'exit 0'")
llvm_test_metric(METRIC score grep 'Score' %o | awk '{print $4}')
llvm_multisource()              # llvm_multisource(my_application) в новой версии

Интеграция не требует дополнительных усилий, если приложение уже собирается с помощью CMake, то в CMakeList.txt в test-suite можно включить уже существующий CMake для сборки и дописать несколько простых вызовов макросов.

2. Запуск тестов

В результате своей работы CMake сгенерировал специальный тестовый файл по заданному описанию. Но как этот файл выполняется?

lit всегда использует некоторый конфигурационный файл lit.cfg, который, соответственно, существует и в test-suite. В данном конфигурационном файле указываются различные настройки для запуска тестов, в том числе задается формат исполняемых тестов. Test-suite использует свой формат, который находится в папке litsupport.

config.test_format = litsupport.test.TestSuiteTest()

Данный формат описан в виде класса теста, унаследованного от стандартного lit-теста и переопределяющий основной метод интерфейса execute. Также важными компонентами litsupport является класс с описанием плана выполнения теста TestPlan, который хранит все команды, которые должны быть выполнены на разных стадиях и знает порядок стадий. Для предоставления необходимой гибкости в архитектуру также внесены модули, которые должны предоставлять метод mutatePlan, внутри которого они могут изменять план тестирования, как раз и внося описание сбора нужных метрик, добавляя дополнительные команды для измерения времени к запуску приложения и т.д. За счет подобного решения архитектура хорошо расширяется.

Примерная схема работы test-suite теста (за исключением деталей в виде классов TestContext, различных конфигураций lit и самих тестов и т.д.) представлена ниже.

Lit вызывает выполнение указанного в конфигурационном файле типа теста. TestSuiteTest парсит сгенерированный CMake тестовый файл, получая описание основных стадий. Затем вызываются все найденные модули для изменения текущего плана тестирования, запуск инструментируется. Потом полученные тестовый план исполняется: выполняются по порядку стадии подготовки, запуска, проверки корректности. При наличии необходимости может быть выполнено профилирование (добавляемое одним из модулей, если при конфигурации устанавливалась переменная, показывающая необходимость профилирования). Следующим шагом собираются метрики, функции для сбора которых были добавлены стандартными модулями в поле metric_collectors в TestPlan, а затем происходит сбор дополнительных метрик, описанных пользователем в CMake.

3. Запуск test-suite

Запуск test-suite возможен двумя способами:

Ручным, т.е. последовательным вызовом команд.

cmake -DCMAKE_CXX_COMPILER:FILEPATH=clang++ -DCMAKE_C_COMPILER:FILEPATH=clang test-suite  # конфигурация
make # непосредственно построение
llvm-lit . -o <output>  # запуск тестов

с помощью LNT (еще одна система из экосистемы LLVM, которая позволяет запускать бенчмарки, сохранять результаты в БД, анализировать результаты в веб-интерфейсе). LNT внутри своей команды запуска тестов выполняет те же шаги, что и в предыдущем пункте.
```
lnt runtest test-suite --sandbox SANDBOX --cc clang --cxx clang++ --test-suite test-suite
```

Результат для каждого теста выводится в виде

PASS: test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test (m of n)
********** TEST 'test-suite :: MultiSource/Benchmarks/Prolangs-C/football/football.test' RESULTS **********
compile_time: 1.1120 
exec_time: 0.0014 
hash: "38254c7947642d1adb9d2f1200dbddf7" 
link_time: 0.0240 
size: 59784 
size..bss: 99800 
…
size..text: 37778 
**********

Результаты от разных запусков можно сравнить и без LNT (хотя данный фреймворк предоставляет большие возможности для анализа информации с помощью разных инструментов, но он нуждается в отдельном обзоре), воспользовавшись скриптом, входящим в test-suite

test-suite/utils/compare.py results_a.json results_b.json

Пример сравнения размера кода одного и того бенчмарка от двух запусков: с флагами -O3 и -Os

test-suite/utils/compare.py -m size SANDBOX1/build/O3.json SANDBOX/build/Os.json 
Tests: 1
Metric: size

Program                                                      O3                Os              diff  
                                                                                
test-suite...langs-C/football/football.test        59784         47496        -20.6%

Заключение

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

Источник

Суть
О правильном названии
Быстрый пример
Характеристики
Типы тест-свитов
Когда их создают
Шаблон тестового набора
Чем отличаются тест-план, тестовый сценарий, тест-кейс и тестовый набор
Как объединять тест-кейсы в тестовый набор
Важность в энтерпрайзе
Лучшие практики

Суть

Тестовый набор — контейнер для выполнения тест-кейсов, сгруппированных по функциональности.

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

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

Тестовый набор (далее также «тест-свит») может иметь статусы Активный, В процессе, и Завершен.

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

О правильном названии

Примечание: в русскоязычном QA-сообществе сложилась практика написания и произношения «тест-сьют». Чтобы наши материалы смогли увидеть и прочитать больше людей, стремящихся в QA, мы ориентируемся на поисковые запросы; и «тест-сьют» встречается в поисковых запросах гораздо чаще, чем «тест-свит». Но, реагируя на замечания наших читателей в обсуждении в Телеграм-канале, мы исправили определение: «тест-свит» действительно более корректно («свит как сладкий», а не «сьют как костюм»). Еще о термине test suite здесь.

Быстрый пример

Например, тестирование функции покупки в онлайн-магазине будет состоять примерно из таких тест-кейсов:

Логин
Выбор товара и добавление в корзину
Проверка правильности данных
Покупка
Выход из системы

Большие подробные тест-свиты формируют при дымовом и системном тестировании.

Характеристики тестового набора

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

Типы

По предназначению можно выделить:

Абстрактный тест-свит, создаваемый при так называемом тестировании на основе моделей. Состоит из группы абстрактных тест-кейсов, созданных на основе высокоуровневой модели приложения. QA-команда не может применять такие тест-свиты непосредственно (как обычные), поскольку они недостаточно подробно описывают приложение и тестовое окружение, и не могут запускаться/выполняться автоматизированно.
Выполняемый тест-свит, то есть обычный. Разрабатывается на основе абстрактного и может выполняться (и соответственно автоматизироваться). Работает на «низком уровне», то есть на привычном для junior-тестировщика уровне, и активно взаимодействует с приложением.

Часто применяемые тестовые наборы

Тестирование верификации билда. Тестовый набор базовой проверки основной функциональности. Когда есть готовый билд.

Регрессионные тесты. Набор регрессионного тестирования функциональности.

Дымовые тесты. Набор тест-кейсов базовой проверки функциональности в экспресс-режиме, обычно после модификации кода.

Функциональные. Набор, верифицирующий обычно часть функциональности, ее отдельные аспекты.

Сквозные интеграционные, набор сквозной проверки интеграции подсистем в приложении.

Шаблон тестового набора

Шаблон стандартного тест-набора.

Саммари. Чаще довольно детализированное описание «о чем этот набор».

Дизайн. Описание дизайна.

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

Пред- и пост-условия. Условия «входа и выхода» данного набора, то есть что должно быть сделано перед его выполнением, и после.

Ожидаемые результаты. Критерии успешности набора. После его выполнения полученные результаты сравниваются с ожидаемыми.

Анализ рисков. Идентификация всех возможных рисков, влияющих на результаты, и как их будут избегать/обходить.

Тест-кейсы. Секция непосредственно тест-кейсов, и их тестовых окружений.

Документы и репорты, а также скриншоты, записи выполнения и другие релевантные данные.

Чем отличаются тест-план, тестовый сценарий, тест-кейс, и тестовый набор

Тест-план	Тестовый сценарий	Тест-кейс	Тестовый набор
Описание масштаба, цели, и подхода к тестированию в тестовых наборах	Описание проверки функциональности	Важный (опорный) документ, составляющая часть тестового набора	Набор тест-кейсов, объединенных по функциональности
Три типа: главный (мастер-план), план по типу тестов, и план по уровню тестов	Все описывается с точки зрения пользователя, может быть разным	Двух типов: формальный тест-кейс и неформальный	Два типа: абстрактный и выполняемый
Создается из use-кейсов, описания продукта, и требований к продукту (SRS)	Создается на основе use-кейсов, для повышения тестового покрытия и проверки пользовательских путей	Создается на основе требований и сценария тестирования	Создается по группам функциональности из нескольких тест-кейсов
По стандартному шаблону, описывающему процессы	Описывает операции QA-команды	Описывает проверку набора требований по проверке функциональности	Описывает цели тест-кейсов

Как объединять тест-кейсы в тестовый набор

Как уже говорилось выше, удобнее всего объединять на основе функциональности. Можно также создавать под-наборы в рамках болшого набора.

Более гибкий подход: древовидная структура тест-свита, без ограничений на количество кейсов-«ветвей».

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

Чаще всего формируют стандартные «дымовые» и регрессионные тестовые наборы. При необходимости добавляя/удаляя оттуда тест-кейсы.

Важность в энтерпрайзе

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

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

В целом в enterprise (и десктопе) — водопадные модели, большие объемы разработки, крупные изменения бывают редко но регулярно, стабильная и надежная архитектура, соответственно тестовые наборы ориентированы на 100%-ное соблюдение требований.

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

Сквозные тесты. «Всеобъемлющие» e2e-наборы дают уверенность в коде в целом; результаты будут близки к реальным пользовательским сценариям сразу же как появится билд.

Лучшие практики создания тестовых наборов

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

Быстрый. Если в наборе много интеграционных тестов и мало модульных, он, очевидно, будет долго выполняться. Быстрый тест-свит даст быстрый фидбэк, разработка пойдет эффективнее.

Полный. Если свит покрывает 100% кодовой базы или чуть меньше, он найдет все дефекты, созданные после изменения функции; полнота дает уверенность.

Надежность. Надежный тест-свит это надежный стабильный фидбэк независимо от изменений вне области тестирования; ненадежный, с моргающими тестами = нет фидбэка по недавним изменениям кода.

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

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

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

Выбрать ЯП и фреймворки. Современное сложное приложение чаще пишется на нескольких ЯПах, каждый из которых имеет свои плюсы и минусы. Нужно учитывать уровень опыта команд и скиллы разработчиков. Если например разработчики посоветовались и решили, что Python будет основным языком проекта, то у QA-автоматизаторов нет выбора. Язык тестового фреймворка чаще всего совпадает с языком разработки. Позитив от одного ЯП для всех команд в том, что разработчики могут выступать бесплатными менторами для QA, когда у тех возникнут проблемы.

***

Источник

1. Лекция 10 (ч. 1) Тест-сеты, тест-сьюты и тест-кейсы. Правила их составления. Практическое занятие 6 Создание тест-сета.

Лекция 10 (ч. 1)
Тест-сеты, тест-сьюты и тесткейсы. Правила их
составления.
Практическое занятие 6
Создание тест-сета. Написание
первого тест-кейса.

2.

Содержание занятия:
•Что такое тест-сет, тест-сьют и тесткейс.
•Правила оформления тест-кейсов.
•Практическое занятие 6: Создание
тест-сета. Написание первого тесткейса.

3.

Тест-сет (Test Set, TS) – набор тестовых сценариев
полученных на основании внутренней структуры
компонента или спецификации, предназначенный для
убеждения в 100% достижении заданных критериев
покрытия (Smoke, Regression Testing).
Тест-сьют (Test Suite, TS) – комплект тестовых наборов
для исследуемого компонента или системы, в котором
обычно постусловие одного теста используется в качестве
предусловия для последующего (Feature Testing).
Тест-кейс (Test Case, TC) – набор входных значений,
предусловий выполнения, ожидаемых результатов и
постусловий
выполнения,
разработанный
для
определенной цели или тестового условия, таких как
выполнения определенного пути программы или же для
проверки соответствия определенному требованию. [IEEE
610]

4.

Но, проще говоря, тест-кейс (ТК) – это подробное
описание проверки. Такое, которое можно будет дать
человеку с улицы и он все поймет. В тест-кейсе есть
название, предварительные шаги, шаги и результат. И куча
других примочек, которые будут зависеть от стандартов
оформления на вашей работе.
По сути, Тест-сет и Тест-сьют (ТС) – это практически одно
и то же, поэтому мы будем использовать формулировку
сьютов.
Грубо говоря, тест-кейсы это как файлики для нашей
программы (всякие так экзешники, файлы справки,
библиотеки и т. п.), т. е., всё, что относится к программе. А
тест-сет/сьют – как папка для этих файликов, чтобы они не
перемешались с файлами других программ.

5.

Правила оформления тест-кейсов
Прежде, чем писать ТК, мы должны создать тестсет/сьют (ТС) и заполнить необходимую информацию:
— название тест-сета/сьюта;
— приоритет ТС среди других подобных в этом спринте;
— на кого назначен ТС (как правило, на того же
тестировщика, который писал ТК);
— название функционала, на который пишутся эти ТК.
Важно помнить, что ТС мы создаём для группы ТК,
которые будут проверять определённый функционал
(фичу) в данном спринте.

6.

ТК имеет стандартные атрибуты:
ID — уникальный идентификатор. Если проставляется
руками, то желательно делать его осмысленным. Часто
генерируется автоматически.
Priority (приоритет тест кейса) – атрибут, который
указывает приоритетность ТК, и принимает значение,
согласно принятой в компании классификации (A-B-C-D-E,
High-Medium-Low и тд.)
Req. ID – атрибут, указывающий на связанный с тестом
пункт требования
Module – здесь указывается связанный с тест кейсом
модуль.
Sub-Module – аналогично предыдущему пункту, только
вписывается более мелкая структурная единица.

7.

Test description (описание тест кейсов) – важный атрибут, в
котором указывается заголовок (SUMMARY, суть теста),
условия для его выполнения, шаги и действия после
прохождения теста. Test description, соответственно, может
и должен содержать:
— Pre-Conditions
— Steps to Reproduce (STR)
— Post-Conditions
Expected result (ожидаемый результат тест кейса) – данный
атрибут отражает ожидаемый результат по каждому шагу.
Result – сюда заносятся данные о результате пройденного
теста (passed/failed и др.)
Comment – сюда можно вносить свои примечания к тесту
(вопросы заказчику, какие-либо наблюдения или детали).

8.

Правила описания ТК:
1. SUMMARY:
— Пишем в стиле «Что (проверяем)-Где (проверяем)
Когда/При каких условиях/Как именно (проверяем)»
Напр.: Проверить, что пользователь авторизуется в
систему (ЧТО) | с помощью правильно заполненной
формы логина (ГДЕ) | и при нажатии кнопки «Вход» на
ней (КОГДА).
-Используем «Verify that / Check that / Проверить, что» в
начале Summary, чтобы указать на сам факт проверки.
Напр.: Verify that user can be authorized in the system
using properly filled login form and clicked on the “Enter”
button on it.
ВАЖНО: выбрав для себя вариант Verify that или Check
that, придерживаться его во всех остальных ТК навсегда.

9.

Можно использовать формулировку «Verification of … /
Проверка …», но это более чек-листовый формат, поэтому
лучше всё-таки использовать рекомендации выше.
Также, лучше избегать словосочетания «Make sure that …»,
т. к. чисто семантически это не означает проверку в
значении «протестировать», а значит «убедиться,
обратить внимание» (но не вдаваясь в подробности).
Обычно эту формулировку мы будем использовать в шагах
нашего теста, чтобы заострить на чём-либо внимание
тестировщика.
-Быть не длинным и не коротким.
Бывают случаи, когда мы не можем вместить всю
информацию в Summary, тогда мы можем немного
обобщить.

10.

Напр.: у нас проверка отображения плитки товара на
странице с товарами (проверка того, что плитка имеет
изображение товара, артикул, название товара, цену,
кнопку «Купить»).
Плохой пример: Verify that item tile has item image, item
article number, item name, price and «BUY» button on the
page with products.
Хороший пример: Verify that item tile has specified attributes
on the page with products.

11.

Дополнительно в этом поле может быть указан тип ТК (QA
или DEV), принадлежность к User Story (US)/Use Case (UC) с
её номером и сквозной нумерацией.
Напр.:
QA US4.1 Verify that system displays an additional
occupancies section if service chosen by user has one or more
occupancies
Этот ТК для исполнения тестировщиком, написан для US4,
порядковый номер 1 (первый).
Аналогичный для разработчика будет такой:
DEV US4 Verify that system displays an additional
occupancies section if service chosen by user has one or more
occupancies
Часто DEV ТК порядковых номеров не имеют.

12.

NOTE: если в системе есть триггер для пометки QA/DEV ТК,
то смысла в Summary указывать эту инфу нет.
ИТОГО: Summary нашего ТК должен рассказывать о чём
этот тест и как его можно пройти, т. е., по этому полю
должно быть на 90% ясно что проверяется и как проверять,
не открывая шагов, но при этом не быть слишком
длинным, но и не слишком коротким (кроме тех случаев,
если иное невозможно).

13.

2. DESCRIPTION (как правило, отдельное поле сразу за
Summary):
Краткое описание о чём тест. Как правило, в стиле
Verification of login ability
3. Pre-Conditions:
Это всё то, что поможет нам пройти тест-кейс, но прямого
отношения к текущему тесту не имеет, т. е., подготовит
почву для нашего непосредственного теста.
Напр.: регистрация нового пользователя в системе для
проверки возможности логина.
— имеют собственную нумерацию.
— пишется в стиле «что-то должно быть сделано» (перед
началом самого теста. New user should be registered in the
system.

14.

— пишется обезличено: избегаем «я/ты/мы/вы/I/you/we»,
вместо этого заменяем на «user/client/customer».
User should see opened pop-up.
— писать нужно в едином стиле: все пункты
предварительных шагов должны быть по одному шаблону
(«что-то должно быть сделано»)
— можно ссылаться на инструкции, документацию или
другие ТК (но очень нежелательно, т. к. со временем
файлы, на которые ссылаются, могут изменить своё
расположение или вовсе быть удалены). В данном случае
рекомендую создать свой файл-инструкцию или копию и
приложить к ТК, сославшись в тексте шага, где он нужен, на
него.
New user should be created (please refer to «User
creation.doc») – for attached file OR (please refer to «User
creation» TC) – for another Test Case.

15.

ВАЖНО: не увлекаемся слишком ссылками на другие ТК (а
вообще стараемся избегать, помним, да?).
-предварительных шагов может и не быть вовсе – это
нормально, ведь не всегда нам есть что сделать до начала
теста (но, как минимум, зайти на тестовый энвайронмент
мы всегда можем и описать это здесь).
4. STR:
Здесь описываем непосредственно шаги нашего теста.
— писать нужно в едином стиле: использовать нейтральные
глаголы: click on / press / нажать, do / make / сделать,
navigate / пойти, open / открыть.
— можно прикреплять мокапы и ссылаться на них (зачастую
для UI ТК) в шаге, где они уместны: «… (please refer to
“Main Logo.jpg”).

16.

— можно описывать тестовые данные для ввода в шагах.
Напр.: у нас проверка возможности создания 2
пользователей с заполнением полей «Имя», «Фамилия» и
«Адрес». Тогда шаг у нас будет таким:
N. Create 2 users with the next attributes:
USER 1: Ivan Petrov, Gogolevskaia St., 21, Kyiv;
USER 2: Ihor Ivanov, Lesi Ukrainki St., 124, Lviv.
А можно (и нужно) создать отдельный *.xls файл с
вводными данными, прикрепить и сослаться на него, как с
мокапами.
N. Create 2 users with defined attributes (please refer to
«Users’ data.xls»)
— каждый основной шаг должен иметь ожидаемый
результат.

17.

Step
Expected Result
N. Create 2 users with defined attributes (please
refer to «Users’ data.xls»)
2 users should be created
successfully with defined attributes
— 1 шаг = 1 действие (как правило).
— иметь минимум шагов для максимального описания
(тривиальные шаги можно объединять: «Залогиниться в
систему и открыть страницу Х»).
— последний шаг ТК – проверочный в стиле «Проверить,
что <что-то работает как и ожидается>». Это
обязательный шаг, т. к. в ТК может быть много шагов и к
концу шагов тестировщик забудет на что ему нужно будет
обратить внимание и может упустить цель теста. Тогда
придётся проходить заново.

18.

5. Post-Conditions:
Это те действия, которые приводят нашу систему в
изначальное состояние. Напр.: если мы создавали
пользователей в системе для теста, то по его окончании мы
должны их удалить, чтобы следующий ТК проходить в
идеальных условиях.
На практике так делают редко, ведь часто каждый
предыдущий ТК – предусловие для следующего (при
грамотном планировании ТК и описании проверок в
хронологическом порядке). Поэтому, если Pre-Conditions
может не быть, то Post-Conditions будет всегда (как
минимум, закрыть браузер или вкладку, разлогиниться и т.
п.).

19.

— имеют собственную нумерацию.
— пишется в стиле «что-то должно быть сделано» (после
окончания самого теста.
1. New user should be deleted from the system.
2. Browser should be closed.

20.

Другие атрибуты ТК:
Assignee – ответственный за этот тест-кейс (правки,
исполнение), QA или DEV (зависит от типа ТК — для
тестировщика или разработчика)
Reviewer – ответственный за проверку соответствия ТК
реквайрментам после написания
Product Owner – ответственный за фичу (разработчик
реквайрментов)
Test Case Priority – приоритет для исполнения ТК
Automation Status – manual / automated

21.

Time to Write – затраченное время на написание
(конкретно этого)
Time to Run – оценочное время на прохождение ТК
(конкретно этого)
Complexity – сложность, насколько сложные шаги (как
много нужно сделать предподготовок, предусловий и т. п.)

Источник

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

Планируем тестирование

Виды планирования Стратегическое Направление движения Перечень задач Приоритеты Оперативное Оценка ресурсозатраты Обновление планов Контроль результатов

Стратегическое планирование Зачем? Достижение целей Дехаотизация Как? IEEE, RUP – стандартные шаблоны В свободной форме Где применимо? Везде.

Цели стратегического планирования Учитывать все условия Сохранять здравый рассудок Резервировать ресурсы Ничего не забыть Возможность выбрать наиболее важное Обосновывать руководству

Тестовая Стратегия — Что Это? Стратегия — общий, не детализированный план какой-либо деятельности, охватывающий длительный период времени, способ достижения сложной цели.

Тестовая Стратегия — Что Это? Стратегия Тестирования ПО – это общий, не детализированный план контроля качества ПО, охватывающий длительный период времени, главная цель которого достижение и обеспечение высокого качества ПО.

Тестовая стратегия ЭТО синонимы: Мастер тест план Master Plan Master Test Plan В повседневной жизни на проекте может быть один Мастер Тест План и несколько детальных тест планов, описывающих отдельные модули одного приложения.

Что пишем в стратегию?

1. Описание проекта и продукта Описание Процесс и инфраструктура Документация Стадия разработки Модель взаимодействия Команда

2. Подход к тестированию Предотвращающий Реактивный

3. Что тестируем? Продукты и их части Технологии и инструменты

4. Тестовые окружения

5. Уровни тестирования Компонентное тестирование Интеграционное тестирование Системное тестирование Приемочное тестирование GUI/Not-GUI функциональность Инструменты Подходы

6. Типы тестирования

7. Техники тестирования (сложные) Decision tables State-based Pairwise testing tests Classification trees Checklist-based … tests

8. Согласование разработки и тестирования Подгоняем процесс методологию разработки и тестирования Контроль версий Критерии начала тестирования Роли И в проекте и их взаимодействие другое

9. Инфраструктура тестирования Инструмент управления задачами и дефектами: Google Docs Багтрекер Outlook Тест менеджмент инструмент: Zephyr Test. Rail Google Docs Документ менеджмент Wiki Google Docs Хранилище данных Dropbox Shared folders Google Docs Шаблоны и др. Wiki

10. Артефакты тестирования Тестовая План итерации (для SCRUM) Набор User стратегия или тест план тестов story Отчеты о проблемах Отчеты о выполнении и качестве продукта Описание инфраструктуры разработки необходимой для тестирования Политика автоматического тестирования

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

12. Метрики тестирования Критичность имеющихся дефектов Рекомендации относительно того какие дефекты исправлять Тестовое покрытие и глубина тестирования Типы тестирования Тестовые окружения Покрытие Unit тестами и % ошибок Про метрики еще немного в конце

13. Автоматизация тестирования Что автоматизировать и как? С какими приоритетами? Какие инструменты? Какие подходы? Инфраструктура

14. Команда 1) Размер 2) Роли и Обязанности 3) Разбивка команды по функциональности и типам тестов

15. Необходимость в тренингах и др.

16. Расписание и оценка работ

План тестирования Часть мастер плана Отдельный документ На проекте может быть несколько Может быть без мастер плана

Кому создавать тест-план? Руководителю проекта по тестированию Руководителю группы Руководителю направления (автоматизации, тест-дизайна и т. д. ) Тестировщику, работающему в одиночку

Создаём тест-план – IEEE 1. Test Plan Identifier 2. Introduction 3. Test Items 4. Features To Be Tested 5. Features Not To Be Tested 6. Approach 7. Item Pass/Fail Criteria 8. Suspension Criteria and Resumption Requirements 9. Test Deliverables 10. Environmental Needs 11. Responsibilities 12. Staffing and Training Needs 13. Schedule 14. Risks and Contingencies 15. Approvals

Создаём тест-план – RUP Introduction Purpose Background Scope Project Identification Requirements for Test Strategy Resources Roles System Project Milestones Deliverables Test Model Test Logs Defect Reports

Что всегда нужно в тест-плане? Что тестировать Как это тестировать Что НЕ тестировать Трудозатраты на тестирование Приоритеты Последовательности Риски Всякие формальности

Что всегда нужно в тест-плане? Фича Математические функции Инсталляция Справка Новая фича #113: Кнопка Сохранить» Что тестировать Все базовые тесты Установку на Win 7 и Win Vista Ничего Полный цикл Что не тестировать Приоритет Детальные тесты с приоритетом ниже 3 Установку на другие ОС 1 Стандартные тесты 16 часов 3 Стандартные тесты 8 часов 4 Стандартные тесты 2 Стратегия • Проверить работу после различных операций • Использование разными пользователями • . . Для тестирования необходимо создать чек-листы и автоматизировать тесты с приоритетом >3 Трудо-затраты Тестирование – 8 ч Написание тестов – 8 ч Автоматизация тестов – 18 ч

Проектные риски Выявляем Подключаем других участников Определяем стоимость Определяем вероятность Определяем стратегию работы с риском Превентивные меры Учитывать риск в планах Оставить всё как есть Проработать «План Б»

Успех создания тест-плана Понимание целей: не «для галочки» Согласование с заинтересованными лицами Поддержка И в актуальном состоянии опыт, сын ошибок трудных

Способы оценки трудозатрат Экспертный способ оценки Я угадаю эту мелодию с трёх нот! Тщательная декомпозиция подзадач Связать свитер = сделать 28000 петель Классификация задач «Простая» мелодия угадывается с трёх нот «Сложная мелодия» угадывается с пяти нот Сбор метрик В среднем, свитер вяжется за 4 недели Все способы – взаимодополняющие!

Экспертный способ оценки «Я протестирую этот функционал за 4 дня» Гарантий – ноль (-) Срок обычно подстраивается под требования, ожидания (-) Индекс ошибки у сотрудников предсказуем (+)

Декомпозиция задачи «Для тестирования нам надо выполнить 250 тест-кейзов» Невозможно дать ответ руководству за 10 секунд (-) Высокая точность планирования пропорционально глубине декомпозиции (+)

Классификация задач Для тестирования, нам надо выполнить 4 задачи «А» и 6 задач «Б» Нужен предварительный сбор статистики и «отладка» (-) Наиболее точный и быстрый способ планирования при наличии метрик (+)

Инструменты для планирования Стратегическое планирование MS Word MS Project Планирование оперативных задач MS Project Testlink / HP QC / Jira / Test management systems Сбор статистики MS Project Excel Test. Link/QC/TMS

Контроль результатов По задачам в средстве планирования Daily reports, Weekly reports Сотрудники в тонусе Вы в курсе Регулярность контроля – атрибут задачи ОБНОВЛЯЕМ ПЛАНЫ!

Планирование – выводы Планирование – это ИНВЕСТИЦИЯ Наличие планов – залог того, что мы потратим ресурсы эффективно Ключевые параметры планов: Набор задач Риски и их решения Приоритеты задач Трудозатраты Планы должны актуализироваться Инструменты зависят от условий Задачи всегда должны идти от большего к меньшему

Составляем тест-план

Калькулятор Исследовательское тестирование

Тест план для проверки калькулятора может быть таким Name Проверка основной функциональности Ввод данных Проверка арифметических операций Проверка вывода результата на экран Проверка работы интерфейса пользователя Проверка работы на различных ОС Операции с памятью Закрытие программы Проверка работы с минимальными правами Корректность обработки ошибок Ввод некорректных символов Арифметические операции с некорректными данными Ввод больших данных Работа при нехватке системных ресурсов Нагрузочное тестирование Запуск нескольких копий калькулятора Операции с большими данными Проверка на наличие утечек Проверка документации

Как планируют в Google

«Волшебный» метод ACC Расшифровывается просто: Attribute Component Capability

Все тот же калькулятор

Никогда до этого мы его не видели

Определяем атрибуты (Attribute) Ключевая характеристика системы Прилагательное (дело вкуса!) Небольшое количество Обычно прилагательное Описывает основные крутые особенности системы.

Как выделить Атрибуты? Спросить у отдела маркетинга Спросить у ПМа Поспрашивать у программистов Реклама продукта Интуиция Если изменятся в ходе работы – не страшно

Пример атрибутов калькулятора Простой Удобный Настраиваемый Надёжный

Определяем компоненты (Component) Модуль или часть системы Не очень крупный Не слишком мелкий Число больше, чем у Атрибутов

Как разбить систему на Компоненты? Поговорить с разработчиками Интуиция – всему голова Можно дополнить позже

Компоненты калькулятора Арифметические операции Память Строка ввода-вывода Преобразование единиц Журнал операций Встроенные листы (я тоже о них не знала) View -> Worksheets ☺

Атрибуты готовы Компоненты готовы Тест-план уже готов?

Нет, готова только таблица!

И тут появляются Capabilities Это почти как фичи, только: Относятся к Компонентам системы Обеспечивают Атрибуты системы Возможности, фактически, это фичи системы. Отличия только в вводе в ACC

Характеристики Возможностей Частота отказов – 5 ступеней Критичность отказов – 5 ступеней

Выглядит всё это так

Критерии установки характеристик Уже найденные ошибки Сложность реализации Важность для пользователя Новизна и изученность Главный вопрос как эти характеристики определять?

Вводим Возможности в систему

Получаем результат

Можно привязать тесты и баги К каждой добавленной возможности можно легко привязать тесты и баги из багтрекера и tms соответственно. В текущей версии работает не очень.

Результат налицо Получили наглядную карту рисков Узнали обо всех возможностях программы Получили список возможностей по атрибутам и компонентам Наладили учёт багов и тест-кейсов для возможностей системы Найденные ошибки учитываются при расчёте рисков

«Скрытые» результаты Картина продукта «на расстоянии» Представление о наименее надёжных модулях Возможность приоритизации по рискам и атрибутам Надёжная и удобная основа для тестовых сценариев и тестпланов Просто поддерживать в актуальном состоянии

Где посмотреть, потрогать ACC Веб-приложение с открытым исходным кодом – Test. Analytics http: //code. google. com/p/test-analytics/ Попробовать можно тут https: //test-analytics. appspot. com/

РИСКИ

Как работать с рисками

Структура следующих слайдов Название проблемы Комментарий 1 Комментарий 2 … Риск 1 Риск 2 … Рекомендация 1 Рекомендация 2 …

Стратегия тестирования отсутствует/не поддерживается Отсутствие согласованного понимания порядка подготовки и проведения тестирования в проекте Хаотичная передача версий на тестирование Нет базы тестирования Низкое качество тестирования Риск нехватки ресурсов тестирования Разрабатывать стратегию тестирования Согласовывать и утверждать стратегию тестирования

Стратегия тестирования Критерии начала и завершения тестирования Отсутствуют критерии начала тестирования Отсутствие / Нечеткость классификации серьезности дефектов Нет понятия готовности объекта тестирования (модульное тестирование, BATS …) Коммуникационные проблемы с разработчиками (тестирование) и заказчиком (приемка) Разработать однозначные критерии начала и завершения тестирования для каждого этапа проекта

Стратегия тестирования Риски тестирования Не рассматриваются и не анализируются наряду с остальными проектными рисками Не используется исторический опыт рисков тестирования Тестирование становится неадекватно высоко рисковой частью проекта Высока вероятность неуспешного тестирования Совместно с менеджером проекта анализировать, рассматривать и отслеживать риски тестирования наряду со всеми проектными рисками

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

Стратегия тестирования Проблемы, с которыми вы сталкивались когдалибо. . .

Анализ требований Требования не ранжированы по приоритетам Сомнительно, что все требования имеют одинаковый приоритет Нет возможности упорядочить и указать приоритеты для разработки и прогона тестовых сценариев Невозможность проведения первоочередного / тщательного тестирования ключевых требований Провести анализ существующих требований и определить приоритеты требований Учитывать эти приоритеты при определении очередности разработки и тестовых сценариев и покрытии требований тестовыми сценариями

Анализ требований Требований в проекте нет/они постоянно изменяются Ситуация в принципе невозможная/нормальная Имеется в виду либо отсутствие документально зафиксированных требований либо их высокая изменчивость Невозможность проведения тестирования по плану Невозможность адекватной оценки качества объекта тестирования Провести анализ существующих требований и способа их представления Разработать планы тестирования Применять планы тестирования

Анализ требований Нет аналитика – некому поддерживать требования Или «Давайте будем поддерживать все» Разница между ролью и ресурсом Невозможность создания актуального плана тестирования Невозможность адекватной оценки качества объекта тестирования Предусмотреть в плане-графике работы по сбору, анализу и поддержанию требований Наделить конкретный проектный ресурс ролью аналитика

Дизайн Архитектура системы не учитывается при разработке стратегии тестирования Необходимо для повышения эффективности тестирования (например, нужен ли и как организовать доступ на уровне СУБД) Необходимо для организации интеграционного тестирования Неэффективное тестирование (большие затраты при скромных результатах) Знакомство тестировщиков с архитектурой системы Планирование тестирования с учетом архитектуры системы

Дизайн Нет единого решения по пользовательским интерфейсам Неоправданный разнобой в реализации интерфейсов приложения Неудобство для заказчика Замечания тестировщиков на это тему игнорируются ( «Такого требования нет!» ) Низкое качество Usability объекта тестирования Не удается найти дефекты Usability Использовать как явные, так и подразумеваемые требования Специфицировать интерфейсы (документ, прототип …)

Дизайн У объекта тестирования отсутствует пользовательский интерфейс Непонятно, как «подобраться» к объекту тестирования Непонятно, как визуализировать фактический результат для сравнения с ожидаемым Замечания тестировщиков на это тему игнорируются Невозможность провести тестирование Использовать заглушки / тест-драйверы Планировать их разработку в стратегии тестирования и плане-графике проекта

Дизайн Нет требований к окружению системы Требования к окружению не сформулированы явно, а определяются в процессе разработки системы Требования неизвестны тестировщикам и не учитываются при создании среды тестирования Большое число «ложных» дефектов Низкое качество тестирования Зафиксировать требования к тестовой среде Проводить тестирование при соблюдении (в некоторых случаях – и при несоблюдении) этих требованиях Отразить требования в описании инсталляции и пользовательской документации

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

План тестирования Не проводится оценка качества плана тестирования в процессе разработки Как определить, что разработка плана тестирования завершена Как определить качество разработанного плана тестирования Низкое качество плана тестирования – низкое качество тестирования Результаты ревью плана тестирования позволяют оценить его качество

План тестирования Не проводится оценка качества плана тестирования в процессе применения Тестовые сценарии не находят дефектов Тестовые сценарии не находят существенных дефектов Тестовые сценарии находят одни и те же дефекты Неоправданно большие затраты на поиск дефектов Большое число пропущенных дефектов Пропущены существенные дефекты Мониторинг результативности тестирования Коррекция плана тестирования

План тестирования Ревью плана тестирования не планируется/не производится Считается сильно затратным Считается неэффективным План тестирования содержит дефекты Про эти дефекты никто не знает Они обнаруживаются при тестировании (хорошо, если это так) Планировать ревью плана тестирования аналитиками Планировать ревью требований тестировщиками

План тестирования Тестовые сценарии не содержат деталей Конкретные действия тестировщика / инженера по автоматизации придумываются во время тестирования Затраты на воспроизведение действий при воспроизведении дефекта Низкое качество тестирования из-за неполного набора действий Невозможность проверки степени покрытия пользовательского интерфейса Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности

План тестирования Тестовые сценарии содержат детали Изменение требований и дизайна вызывает объемные изменения планов тестирования Затраты на обеспечение актуальности планов тестирования Затраты на переучивание тестировщиков Зафиксировать требуемый уровень детальности в стратегии тестирования Проектировать и разрабатывать планы тестирования с учетом этого уровня детальности Использовать двухуровневую структуру плана тестирования – тестовый сценарии + тесты

План тестирования Проектирование и разработка тестовых данных не планируется и не производится Данные придумываются во время тестирования Данных недостаточно (например, используются только корректные данные) Тестирование миграции без проектирования тестовых данных невозможно Затраты на воспроизведение данных для воспроизведения дефекта Низкое качество тестирования из-за малого набора тестовых данных Проектировать и разрабатывать тестовые данные с использованием классов эквивалентности и граничных значений

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима в любом проекте Завышенные требования к команде тестировщиков Заниженная оценка трудозатрат на тестирование Невозможность проведения автоматизированного тестирования Поздний переход на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима только для регрессионного тестирования Как правило, но не всегда Пример: проекты redevelopment Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Автоматизация функционального тестирования применима только при большом числе раундов тестирования Как правило, но не всегда Пример: проекты mission-critical Невозможность проведения ручного тестирования Рост затрат на ручное тестирование Детальный анализ целесообразности автоматизации тестирования

Автоматизация тестирования (повторяем) Раннее проведение нагрузочного тестирования Исправление функциональных дефектов, как правило, вызывает перезапись и повторный прогон нагрузочных скриптов Как правило, но не всегда Пример: нагрузочное тестирование прототипа Необходимость выделения ресурсов для повторного проведения нагрузочного тестирования Детальное планирование момента проведения нагрузочного тестирования

Автоматизация тестирования (повторяем) Неадекватная модель нагрузки Совокупность: ролей (кто работает) характеристических профилей сценариев (что делает) (доля и частота) не соответствует бизнесу заказчика Неадекватные результаты нагрузочного тестирования Несоответствие ожиданием заказчика Согласование модели нагрузки с заказчиком

Среда тестирования Тестирование выполняется в среде разработки одного или нескольких проектов Путаница версий Нестабильность объекта тестирования (исправления «на лету» ) Невозможность обнаружения части дефектов Низкое качество тестирования Сложность коммуникаций с разработчиками (невозможность воспроизвести дефект) Создание обособленной среды тестирования Сборка объекта тестирования из baseline

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

Тестирование Не хватает ресурсов тестирования Проанализировать, почему Невозможность выполнить запланированные работы в срок Установление причины нехватки ресурсов (заниженные оценки, низкое качество объекта тестирования, незнание требований и предметной области, изменение сроков тестирования) Перепланирование активностей тестирования Привлечение дополнительных ресурсов

Тестирование Невозможно идентифицировать версию объекта тестирования Неясно, был ли обновлен объект тестирования Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Невозможно понять, например, обнаружен дефект или нереализованная функциональность Соглашение об идентификации версий Разработка и применение BATS (Build Acceptance Test Suite)

Тестирование Объект тестирования не работоспособен Сбой в процессе сборки Отсутствие четкой регламентации процесса сборки (путаница версий кода) Потеря времени на тестирование неработоспособного объекта тестирования Неэффективное тестирование и большое количество «ложных» дефектов Разработка и применение BATS (Build Acceptance Test Suite)

Тестирование Дефекты возникают из-за неверной конфигурации системы / среды тестирования Непонятно, как идентифицировать, где найден и где исправлен дефект Непонятно, как отличать от дефектов кода Невразумительные сведения в системе управления дефектами – дефект найден и исправлен в одной и той же версии объекта тестирования Недостоверная статистика по дефектам Принятие решения о регистрации и учете таких дефектов на корпоративном / проектном уровнях Классификация локализации дефекта (например, «Требования» , «Дизайн» , «Код» , «Конфигурация» , «Пользовательская документация» и др. )

Тестирование Протоколы тестирования не создаются В них нет описания дефектов Если дефекты не найдены, то создание протоколов – пустая трата времени Нет данных об объеме проведенного тестирования Нет данных о качестве системы (непонятно, проверяли ли работу конкретной функциональности) Фиксировать результаты тестирования в максимально удобной для проектной команды форме (например, в матрице Test Run Coverage) Использовать автоматические средства протоколирования ручного тестирования

Тестирование Как оформлять описание дефекта В протоколе тестирования + регистрация в системе управления дефектами В системе регистрации дефектов вместе с регистрацией В отдельном документе + регистрация в системе управления дефектами Неразбериха с неоднородным оформлением дефектов Дополнительные затраты на поиск описания Принятие решения в рамках проекта (проектов), исходя из удобства и эффективности для всех членов проектной команды (и заказчика, если необходимо)

Тестирование Метрики тестирования не используются Качественной оценки может быть недостаточно Трудно анализировать динамику выполнения проекта Работа с метриками требует проектной культуры Неточное / неверное представление о качестве объекта тестирования Выбрать / применить набор понятных и эффективных метрик тестирования (плотность дефектов, доля трудозатрат, эффективность поиска, доля серьезных дефектов и др. )

Тестирование Сокрытие дефектов ЧП! Негативные последствия для всей проектной команды Ничего не дает – заказчик все равно этот дефект обнаружит! Недостоверные данные о качестве объекта тестирования Не допускать возникновения такой ситуации Оперативно с ней бороться (в том числе и эскалацией проблемы) Разъяснять, что обнаруженный и исправленный дефект – это гораздо лучше, чем отсутствие дефекта

Тестирование Пользовательская документация не тестируется Не запланировано тестирование документации (включая Help) Нет ресурсов для тестирования Тестируют только тестировщики — технические писатели ревью не проводят Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования

Тестирование Не проводится системное тестирование Системное тестирование не планируется Нет времени для системного тестирования Допустимо в проектах сопровождения Низкое качество пользовательской документации (неполная, непонятная, не соответствующая реализации) Планировать и производить тестирование технической документации как путем ревью, так и в рамках системного тестирования

Приемка Не согласована процедура приемки Что предшествует и что следует за приемо-сдаточными испытаниями Каковы ожидания заказчика на момент приемки Кто принимает решение об успешном завершении проекта со стороны заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая приемо-сдаточные испытания)

Приемка Верификация и валидация Разница этих понятий Ликвидация (минимизация) расхождений между требованиями и ожиданиями заказчика Проблемы во время приемки Задержка сдачи проекта и работа без оплаты заказчиком Поддержка актуальности и приоритетов требований и их учет в плане приемо-сдаточных испытаний

Приемка План приемо-сдаточных испытаний Несоответствие объемов приемо-сдаточных испытаний и системного тестирования Нет ничего, кроме плана приемо-сдаточного тестирования Увеличение времени приемо-сдаточных испытаний Задержка сдачи проекта и работа без оплаты заказчиком Планирование и согласование процедуры приемки (включая разработку и модификацию плана приемо-сдаточных испытаний) с начала проекта

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

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

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

Метрики

Согласно международному стандарту ISO 14598: Метрика — это количественный масштаб и метод, который может использоваться для измерения. Введение и использование метрик необходимо для улучшения контроля над процессом разработки, а в частности над процессом тестирования.

Классификация задач: процесс

Примеры метрик

Сбор статистики Что собирать: Отличие план/факт Что сколько времени занимает Связь с внешними метриками Зачем собирать: Чтобы найти оптимальные способы планирования Чтобы не повторять ошибок в планировании

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

Метрика 1 Метрика: Доля повторно открытых дефектов. Повторно открытые дефекты = заново открытые / открытые в первый раз (на одной итерации тестирования) Ограничение: Не считаем дефекты, критичность которых ниже чем «незначительные» . Обоснование: Повторно открытые дефекты это двойная работа, это потенциально опасные места, т. к. после закрытия такого бага нет гарантии, что он не всплывет у клиента. Ведутся в таблице с предположением что делать если метрика больше нормы меньше нормы и т. д.

Метрика 2 Метрика: Убойность тестов = число дефектов*100 / число тестов. Убойность тестов – это количество дефектов на 100 тестов Число дефектов – все дефекты, которые были найдены по шагам из тестов на данной итерации тестирования. Число тестов – все тесты, которые были пройдены за итерацию. Ограничение: Не считаем дефекты критичность которых ниже чем «незначиельные. » Обоснование: Эта метрика косвенно отображает качество нашей работы, или работы программистов.

Метрика 3 Метрика: Число дефектов найденных вне теста. (антиубойность) Число дефектов найденных вне теста = число дефектов, найденных вне тестов*100 / число тестов Требует введение следующего Правила: «Нельзя приписывать тесту найденный дефект, если шаги для воспроизведения этого дефекта отличаются больше чем на 30% от шагов, описанных в тесте» . . . (ограничения и определения пропущены) Обоснование: Эта метрика напрямую отображает недостатки методики (тестов). Идеальным было бы, чтобы все баги находились при прохождении шагов по тесту.

Метрика 4 Метрика: Эффективность тестирования = число дефектов/трудозатраты (чел/ч). Определение. Эффективность тестирования – это число дефектов, найденных за один час одним человеком. Обоснование: Эта метрика отображает эффективность использования ресурсов Метрики хранились в Access базе было написано приложение в котором тестировщики вовремя или по завершению тестирования вносили данные приложение само раскидывала числа по табличкам.

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

Поймите для чего вы хотите что-то мерить!!! Метрики должны иметь своей целью УЛУЧШЕНИЕ процесса. Для этого надо знать КРИТЕРИИ УСПЕШНОСТИ этого самого процесса. После чего необходимо заполучить инструменты, позволяющие выяснить ПРИЧИНУ проблем, чтобы работать с их корнями.

Перед измерением метрик Сначала надо проводить грамотные пост мортемы, обсуждать, выяснять, с какими проблемами столкнулись. Анализировать их: как они повредили, как вы можете оценить масштабы их вреда и т. д. Благодаря пост мортемам можно: выявить проблемы и договориться о путях улучшения Потом выяснить, что считать проблемами, и как это измерять — то есть, заложить базис для системы метрик. Затем уже что-то мерять…

Зачем вообще что-то мерять? Непрерывно оценивать качество процесса, продукта , услуги Улучшать процессы Делать приемку товаров, услуг Оценивать достижение целей Принимать обоснованные решения — управлять

Зачем вообще что-то мерять? Зачем непрерывно оценивать качество процесса, продукта , услуги? Инструментарий. Контрольная диаграмма (Control Chart) Пример. Количество дефектов в очередной итерации, спринте, релизе

Зачем вообще что-то мерять? Зачем улучшать процессы, продукт, сервис? Инструментарий. Процесс улучшений Пример. Улучшить эффективность устранения дефектов.

Зачем вообще что-то мерять? Зачем Ддлать приемку товаров/услуг Инструментарий. Договорные обязательства, специфический инструментарий, запланированные процедуры контроля критериев Примеры: Программный продукт должен содержать не более 10 несущественных дефектов Вебсайт должен быть доступен не менее 99. 8% времени Отчет А в среде Б должен формироваться не более чем за В секунд

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

Зачем вообще что-то мерять? Принимать обоснованные решения — Управлять

Условия успеха для внедрения метрик

Условия успеха Люди В предметной области измерений В метриках, применимых к предметной области В адекватном выборе метрик В процессах Подготовленные (обученные) В инструментарии Доступные Деятельность, ответственности и полномочия утверждены Выделяется достаточно времени

Условия успеха Процессы Должны быть внедрены и настроены Должны отвечать нуждам бизнеса Им должны следовать Должны быть измеримыми Должны быть открытыми для улучшений

Условия успеха Инструментарий Репозитории: Документированных стандартных процессов, шаблонов, инструкций Документов и кода, результатов инспекций документов и кода Контроля качества (документация или системы управления дефектами) Системы автоматизированной инспекции кода Системы планирования Средства оценки объема работ Системы учета рабочего времени Процедуры (желательно автоматические) сбора данных для метрик Реестры метрик, автоматизированные системы обработки и представления метрик Важно! Нужно стремиться к максимальной автоматизации.

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

Основные Концепции Метрик

Размер – условная единица объема работы

Понятие Размера (Size) Оценка размера (Size Estimate) в некоторых условных единицах используя определенные методики. Методики и единицы: Функциональные единицы (Function Points Analysis — FPA) и разновидности FPA Единицы вариантов использования (Use Case Points — UCP) Строки кода (LOC, KLOC) Story points (SCRUM) Любые другие единицы работы, которые могут осмысленно выразить общий объем работ или его существенную часть (веб страница для верстки, страница текста для перевода, одно требование в спецификации, один шаг тестового сценария, класс, и т. п. )

Понятие Размера (Size) Зачем нужен Size: Абстрагирование от уровня знаний и опыта исполнителей Отображение реального объема работ Использования в метриках, KPI для оценки производительности, качества Оценки производительности команды или персональной Для прогнозирования: времени, качества, расходов Для использования в Модели размера — учета многочисленных факторов (сложность, определенность требований, производительность системы, уровни зрелости как разработчиков так и пользователей, и т. п. ) Оценки временн. Ых затрат (Effort Estimate)

Понятие Размера (Size) Размер спецификаций Способы измерения размера спецификаций: По количеству требований, договоренность об уровне декомпозиции По количеству страниц, договоренность о стиле, шаблоны По количеству разделов По весу напечатанных требований ☺

Понятие Размера (Size) Размер тестирования Способы измерения размера тестирования: По количеству шагов в тест кейсах/сценариях По количеству пунктов в чек листах По необходимости подготовки предусловий По необходимости и количеству отчетности По типам тестирования

Модель размера. Пример

Измерения по фазам жизненного цикла

Измерения по фазам жизненного цикла Шаблоны обнаружения дефектов (Defect Arrival Patterns)

Измерения по фазам жизненного цикла

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

Модель реестра метрик Состав реестра метрик Описание метрики (метрик) представленных в реестре, их назначение, взаимосвязь с целями проекта, компании, заказчика Формула метрики Источники измерений Частота сбора измерений Формат представления измерений и метрик – таблицы, графики Анализ поведения метрик – допустимые пределы; желаемые показания, тренды; корректирующие воздействия при достижении допустимых пределов и т. п.

Модель реестра метрик

Инспектирование документов

Функциональное тестирование Основные характеристики качества: Плотность дефектов (Defect Density) – степень качества, количество дефектов на единицу размера Эффективность устранения дефектов (Defect Removal Efficiency) – степень качества для заказчика Происхождение дефектов (Defect Origin) – показывает, на какой стадии был внесен дефект

Функциональное тестирование Defect density (степень качества) Плотность дефектов (Defect Density) – количество дефектов на единицу размера. На весь продукт, на часть функционала, на релиз, на итерацию, на спринт, на документ, на объем трудозатрат и т. п. DD = Σ Дефектов / Релиз DD = Σ Дефектов / Σ KLOC DD = Σ Дефектов / Σ Story_Points_per_Sprint DD = Σ Дефектов / Σ Шагов_Тест. Кейсов DD = Σ Дефектов / Σ Размер_Спецификации

Функциональное тестирование Эффективность устранения дефектов (Defect Removal Efficiency) – соотношение количества устраненных дефектов до окончания стадии и общего количества найденных дефектов DRE = Σ Устраненные_Дефекты ÷ (Σ Устраненные_Дефекты + Σ Обнаруженные_Позже) * 100%

Функциональное тестирование Происхождение дефектов (Defect Origin) – показывает, на какой стадии был внесен дефект, необходимо для выявления наиболее проблемных процессов с целью принятия фокусных улучшений

Функциональное тестирование При подсчете плотности дефектов (Defect Density) и эффективность устранения дефектов (Defect Removal Efficiency) можно использовать их ≪тяжесть≫ (Severity): Считать DD и DRE отдельно по разным категориям ≪тяжести≫ (High, Middle, Low), и/или Ввести весовые коэффициенты ≪тяжести≫, например: High = 5, Middle = 3, Low = 1 IEEE J-STD-016 -1995 предлагает такую классификацию дефектов: 1 – Критические ошибки; 2 – Ошибка, которую нельзя обойти ; 3 – Ошибка, которую можно обойти; 4 – Неточность; 5 – Запрос об изменении; 6 – Консультация

Функциональное тестирование Оценка качества тестирования: Аудит – выборочное ре-тестирование (5 -10%? ) Эффективность устранения дефектов (DRE) Степень покрытия тестированием функциональности продукта Матрица прослеживаемости требований (Requirements Traceability Matrix — RTM). Инструмент – MS Excel, Testlink, и т. п. Покрытие = (Колич. Покр. Треб/Колич. Всех. Треб)*100%

Burn up/down charts Burn down. Инструмент анализа и визуализации Прогресс команды внутри итерации Спринт, релиз, проект Burn up. Инструмент анализа и визуализации Прогресс команды и предсказание завершения в Проекте, релизе Размер Product Backlog Решения о перепланировании Решения о приоритетах Единицы размера Часы трудозатрат Story Points Др. единицы

Задание Составить стратегию и план тестирования для приложения Paint

Составьте test suite для функционального тестирования формы авторизации

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

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

Чтобы сделать выбор в сторону автоматизации, следует разобраться в ее плюсах и минусах.

Преимущества, которые дает тестировщику автоматизация:

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

Вместе с тем автоматизация имеет место и ряд недостатков, таких как:

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

Что нужно учитывать перед автоматизацией тестирования?

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

Автоматизация тестирования с помощью 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, надо понимать, что инструмент не может заменить полностью человека, но он, безусловно, поможет сделать работу тестировщика более легкой и полезной.

В этой статье мы рассмотрим, как мы можем провести тестирование на основе данных с помощью Junit. Для этого я собираюсь использовать библиотеку под названием EasyTest.

Для TestNG, как мы знаем, встроен поставщик данных. Используя простой тест, мы можем использовать Junit для тестирования данных.

Что такое тестирование на основе данных?

Когда вы проводите тестирование на основе ваших данных, это относится к тестированию на основе данных. Формальное определение можно найти в вики.

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

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

Где я использую этот подход?

1. Когда мне нужно проверить большое количество данных и их вывод против методов БД или веб-API (REST / SOAP).

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

3. Когда мне нужно изолировать поведение изменения даты от изменений конфигурации.

Как мы собираемся достичь?

Мы собираемся решить это с помощью параметризованных тестов. И эти параметры будут принимать значения (тестовые данные) из наших определенных файлов. Это недостающая часть из TestNG с Junit. Мы решим с помощью библиотеки EasyTest.

Примечание: это не единственная причина, по которой мы используем Easy test. Простые тесты также имеют много впечатляющих функций. Мы увидим один за другим. Вот простая ссылка на тестовый проект в github.

Давайте учиться на примере:

Для обучения я использую простой класс калькулятора ( ссылка на Github ). Просто добавив два числа и ожидая результата, все в типе Double.

public class Calculator {

public Double add(Double a, Double b){

return a+b;

}

И, давайте сделаем тестовый случай без Easy Test.

public class SimpleTest extends DataDrivenTest{

@Test public void testAddition(){

Assert.assertEquals(25.5,calculator.add(10.5,15.0),0.01);

}

Мы будем развивать этот простой тестовый пример с помощью Easy Test. Итак, давайте начнем с создания проекта.

Шаг А: Создание проекта Maven:

1. Создайте проект maven с вашим любимым идентификатором группы и идентификатором артефакта. (Я использовал org.automation & datadriven)

2. Включите следующие зависимости.

Для Junit (как мы используем)

dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.12</version>

</dependency>

Для легкого теста

<dependency>

<groupId>org.easetech</groupId>

<artifactId>easytest-core</artifactId>

<version>1.4.0</version>

</dependency>

И для регистрации (это необязательно)

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-api</artifactId>

<version>1.7.21</version>

</dependency>

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-log4j12</artifactId>

<version>1.7.21</version>

</dependency>

[Этого будет достаточно, чтобы использовать простую проверку внутренней регистрации. ]

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

<dependency>

<groupId>org.easetech</groupId>

<artifactId>easytest-core</artifactId>

<version>1.4.0</version>

</dependency>

<dependency>

<groupId>junit</groupId>

<artifactId>junit</artifactId>

<version>4.12</version>

</dependency>

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-api</artifactId>

<version>1.7.21</version>

</dependency>

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-log4j12</artifactId>

<version>1.7.21</version>

</dependency>

</dependencies>

<build>

<resources>

<resource>

<directory>src/test/resources</directory>

<includes>

<include>**/*</include>

</includes>

</resource>

</resources>

</build>

</project>

Шаг B: Создание файлов данных: поддержка Easy Test

1. Excel: формат Office 97/2003 (расширение xls)

2. CSV: значение, разделенное запятыми

3. XML

4. Формат JSON через файлы CSV.

Примечание: Easy test также поддерживает пользовательские типы данных (мы пропустим эту часть, чтобы упростить ее в блоге, пример вы можете увидеть в Github)

Для CSV и EXCEL следуйте этим правилам

1. Первая строка, первый столбец будет именем метода (поэтому каждая строка этого столбца будет пустой)

2. Первая строка Во втором столбце все будет именем переменной параметра.

3. Все строки столбца, где написано имя метода, будут пустыми.

CSV:

Excel (.xls):

XML:

Вы можете увидеть все мои файлы из этого в github .

Теперь давайте загрузим данные из другого загрузчика данных.

Для загрузки данных, как правило, мы используем аннотации

1. @DataLoader для определения источника файла.

2. @Param, чтобы определить, какие данные столбца будут рассматриваться как элемент для получения.

Поскольку эти аннотации относятся к Easy Test, нам нужно запустить этот тестовый класс с DataDrivenTestRunner.class, который предоставляется

Итак, сначала мы видим загрузчик данных CSV.

@RunWith(DataDrivenTestRunner.class)

public class CSVLoaderExample extends DataDrivenTest {

@Test @DataLoader(filePaths = "calculator.csv", loaderType = LoaderType.CSV)

public String testAddFromCSV(@Param(name = "a") Double a,

@Param(name = "b") Double b,

@Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

return "success";

}

@Test @DataLoader(filePaths = "calculator2.csv")

public void testAdd(@Param(name = "a") Double a, @Param(name = "b")Double b, @Param(name = "expected")Double expected){

Assert.assertEquals(expected, calculator.add(a,b),0.1);

}

Здесь вы можете видеть, я

=> запуск теста с DataDrivenTestRunner.class

=> загрузка calculator.csv (и другой тоже)

=> получение параметра с именем a, b, ожидается.

Вот как выглядит содержимое файла CSV

testAddFromCSV,a,b,expected

,15.0,25.0,40

,900.0,250.0,1150.0

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

Рекомендация. Я использовал один файл для предоставления входных данных и ожидаемого результата. Вы можете использовать отдельный файл для этого.

Точно так же, если мы посмотрим на загрузчик данных Excel:

@RunWith(DataDrivenTestRunner.class)

public class ExcelLoaderExample extends DataDrivenTest {

@Test @DataLoader(filePaths = "calculator.xls", loaderType = LoaderType.EXCEL)

public void testAddFromExcel(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

@Test @DataLoader(filePaths = {"calculator2.xls"})

public void testAdd(@Param(name = "a") Double a, @Param(name = "b")Double b, @Param(name = "expected")Double expected){

Assert.assertEquals(expected, calculator.add(a,b),0.1);

}

И XML загрузчик данных

@RunWith(DataDrivenTestRunner.class)

public class XMLLoaderExample extends DataDrivenTest {

@Test @DataLoader(filePaths = "calculator2.xml", loaderType = LoaderType.XML)

public String testAddXMLOutput(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

return "success";

}

Замечания :

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

2. Если вы используете загрузку одного файла, вы можете избежать параметра LoaderType.

3. Когда вы используете для загрузки несколько файлов одного типа, убедитесь, что у вас нет одинакового имени столбца. Если то же самое, столбцы из 2-го или более позднего файла будут учитываться. (Кстати, последний файл будет учтен)

4. Не поддерживает разные типы загрузчиков в одном методе. Таким образом, вы не можете загрузить Excel и CSV для одного и того же метода с одним загрузчиком данных. Только первый будет работать.

5. Один метод / класс не поддерживает множественные аннотации загрузчика данных.

6. Загрузчик данных уровня метода перегрузит загрузчик данных уровня класса.

7. Используйте загрузчик данных на уровне класса, когда вы используете один файл для нескольких параметров метода тестирования.

8. В параметре данные используются в формате Long, String, Double. Но мы можем использовать пользовательский тип данных с нашими собственными парсерами. Простой тест имеет интерфейс для этого. (используйте AbstractConverter <YourDataType>)

9. Если нам нужно настроить отображение данных этого параметра, мы можем использовать аннотацию @Display при работе с загрузчиком. Вы можете увидеть пример здесь .

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

@RunWith(DataDrivenTestRunner.class)

public class MultipleDataLoaderExample extends DataDrivenTest {

public void testAdd(@Param(name = "a") Double a, @Param(name = "b")Double b, @Param(name = "expected")Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

@RunWith(DataDrivenTestRunner.class)

public class MultipleDataLoaderExampleSameType extends DataDrivenTest{

@Test @DataLoader(filePaths = {"calculator3.csv","calculator2.csv"})

Assert.assertEquals(expected, calculator.add(a,b),0.1);

}

Итак, вы можете увидеть более подробные примеры здесь.

Теперь, кроме загрузки данных, Easy test имеет множество других функций. Я не буду вдаваться в подробности, но у меня есть примеры для каждого. Итак, я добавляю по одному с небольшим объяснением.

Отчетность: легкий тест обеспечивает действительно легкий отчет… :). Просто используйте аннотацию. Вот несколько примеров.

Отчет по умолчанию: (введите PDF и сохраните в каталоге пользователя)

@RunWith(DataDrivenTestRunner.class)

@Reportpublic class DefaultReportExample extends DataDrivenTest{

@Test @DataLoader(filePaths = "calculator2.xls")

public void testAdd(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

Отчет с изменением пути к классу в classpath: (отчеты хранятся в директории сборки, целевая папка в maven). Будет создано имя папки TestReports

@RunWith(DataDrivenTestRunner.class)

@Report(outputLocation = "classpath:TestReports")

public class ClassPathExampleReport extends DataDrivenTest{

@Test @DataLoader(filePaths = "calculator.xls")

public void testAddFromExcel(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

@Test @DataLoader(filePaths = "calculator2.xls")

public void testAdd(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

Отчет с изменением пути к классу в пути к папке: (мы указываем в нашей файловой системе)

@RunWith(DataDrivenTestRunner.class)

@Report(outputLocation = "file:TestReports")

@Test @DataLoader(filePaths = "calculator.xls")

public void testAddFromExcel(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

@Test @DataLoader(filePaths = "calculator2.xls")

public void testAdd(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

В репозитории github я привел больше примеров, которые просты для понимания. Вот важные заметки.

1. Существует два типа отчета о функциональном тестировании и отчет о тестировании производительности (включая время для запуска тестов). Мы можем создать несколько типов отчетов.

2. Составление отчетов происходит медленно, поэтому время составления отчета будет учитываться как время выполнения теста.

3. Существует 3 типа формата файла отчета. Excel, PDF & HTML, где pdf является выбором по умолчанию. Мы можем создать несколько типов отчетов.

4. @Report может использоваться на уровне класса, что означает, что при создании он включает в себя все результаты метода тестирования.

5. Расположение отчета может быть сохранено по конкретному пути к файлу или в каталоге сборки, пути к классам. Отчет о пути к классам будет очищен при использовании mvn clean, поэтому выбирайте осторожно.

Пример отчета в формате PDF:

Параллельные потоки: Easy test имеет простую аннотацию @Parallel, где мы можем определить, сколько потоков JVM выделит для тестирования для тестового класса.

@Parallel(threads = 5)

@Test @DataLoader(filePaths = "calculator.xls", loaderType = LoaderType.EXCEL)

public void testAddFromExcel(@Param(name = "a") Double a, @Param(name = "b")Double b, @Param(name = "expected")Double expected){

Assert.assertEquals(expected, calculator.add(a,b),0.1);

}

Как видите, этот тест будет выполняться с 5 потоками.

Мы можем запустить наш тестовый костюм параллельно с ParallelSuit

@RunWith(Suite.class)

@ParallelSuite(threads = 3)

@Suite.SuiteClasses({RepeatExample.class, TestWithPolicyExample.class})

public class ParallelSuitExample {

}

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

Повторение теста: в Easy Test мы можем повторить метод теста с аннотацией @Repeat.

@RunWith(DataDrivenTestRunner.class)

@TestPolicy(PolicyExample.class)

public class RepeatExample extends DataDrivenTest {

@Test @Repeat(times = 5)

public void testAddFromExcel(@Param(name = "a") Double a,

@Param(name = "b") Double b,

@Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

Это серийно работает, а не параллельно.

Свойство Test: Easy test имеет приятную аннотацию @TestProperties, которую можно использовать для непосредственного добавления свойства test из пути к классам.

public class TestPropertiesExample extends DataDrivenTest_withDefaultAnnotation {

@TestProperties(value = {"test.properties"})

private Properties myProps;

@Test public void testAddition() {

Assert.assertEquals("Easy Test Demos", myProps.getProperty("test.title"));

}

[Игнорировать расширяющуюся часть, которая не нужна. Чтобы держать тест хорошо, я использовал. Вы можете увидеть форму источников GitHub. ]

Тестовая политика: тестовая политика – очень полезная вещь в Easy test, где мы можем определить тестовую политику в отдельном классе и использовать ее в тестовом классе.

Для этого определите класс политики.

@Ignore@Parallel(threads = 2)

@Report(reportTypes = {Report.REPORT_TYPE.DEFAULT,

Report.REPORT_TYPE.METHOD_DURATION},

outputFormats = Report.EXPORT_FORMAT.PDF,

outputLocation = "file:TestReports")

@DataLoader(filePaths = "calculator.xls")

public class PolicyExample {

}

И использовать его в тестовом классе

@RunWith(DataDrivenTestRunner.class)

@TestPolicy(PolicyExample.class)

public class TestWithPolicyExample extends DataDrivenTest {

@Test public void testAddFromExcel(@Param(name = "a") Double a, @Param(name = "b") Double b, @Param(name = "expected") Double expected) {

Assert.assertEquals(expected, calculator.add(a, b), 0.1);

}

Итак, мы видим, что политика будет определять файл данных + отчетность и параллельные потоки для потоков.
Где использовать?

=> Во время тестирования, если мы чувствуем, что у нас есть тестовая конфигурация отдельно.

=> Когда у нас есть отдельная конфигурация тестирования для запуска в другой ситуации. Например, тестирование в ПК разработчика или в CI, или для отчета о тестировании, или другой тип тестирования, и т. Д.

Минусы:

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

2. Выполнение Parallels может привести к тому, что связанный с ошибкой ресурс заблокирован или занят.

3. Пустой символ в Excel или CSV может вызвать ошибку. Поэтому будьте осторожны при создании файла данных.

4. Есть некоторые известные ошибки. Одной из популярных ошибок является то, что отчет о неудачном тесте генерируется только с помощью Excel data loader. Другие загрузчики данных не могут генерировать отчеты о неудачных тестах (генерируется только отчет о прохождении теста).

Надеюсь, этот пост поможет использовать Easy test. Пример моего Github: https://github.com/sarkershantonu/Automation-Getting-Started/tree/master/junit-easytest

Todo: Пример конвертера пользовательских типов данных. Я буду добавлять постепенно.

Ruby Автор: Александр Симаков

Оригинальная публикация

Тестирование web-приложений является неотъемлемой частью процесса их разработки. Существуют различные уровни тестирования, вот некоторые из них:

модульное тестирование;
интеграционное тестирование;
системное тестирование;
приемочное тестирование.

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

В этой статье рассказывается о высокоуровневой методике тестирования web-приложений которую можно использовать как для приемочного так и для системного тестирования. Ключевую роль при этом играет Ruby-библиотека Watir (Web Application Testing In Ruby). Библиотека Watir позволяет запрограммировать действия браузера Internet Explorer на языке Ruby. Таким образом можно автоматизировать значительную часть ручной работы тестеров по заполнению форм, переходу по ссылкам, проверке User-Stories т.д.

Подробнее…

Авторы: Сардарян Рубен, Новичков Александр
Материал предоставлен компанией CMconsult

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

Статья состоит из двух частей:

Практика использования;
Экстремальное программирование в IBM Rational Unified Process.

Подробнее…

Автор: Дмитрий Юшкевич

В основу этой методики лег тот факт, что все развитые промышленные СУБД имеют то или иное средство профилирования своих процедур. Его основное предназначение — оценка производительности написанного кода (функции, процедуры и т.д.). Но есть и приятная второстепенная особенность: обычно это средство (в Oracle — пакет dbms_ profiler) имеет возможность получать статистику по номерам выполненных строк кода.

Подробнее…

Автор: Сергей Мартыненко

Статья написана в стиле «Давайте начнем». На простом примере рассматривается модульное тестирование в среде VisualStudio 2005 Team Suite.

Исходная задача: Требуется создать библиотеку для вычисления факториалов.

Для работы нам понадобится VisualStudio 2005 Team Suite. VisualStudio 2005 Express Edition или VisualStudio 2005 Professional не поддерживает модульное тестирование.

Подробнее…

Автор: Ларри Квесада, специалист по Rational, IBM

Источник публикации

Excel-плагин для TestManager — это набор макросов, включенных в Microsoft Excel, который расширяет функциональность IBM Rational TestManager. Практики в области тестирования могут использовать плагин вместе с TestManager на всем продолжении цикла тестирования для облегчения разработки набора тестовых данных, его импорта в TestManager, а также передачи отчётов. Менеджеры по обеспечению качества могут использовать плагин для получения доступа к статусу тестовой программы, не запуская её саму. В конце концов, как только отчёты созданы в Excel, можно использовать любую функцию Excel, например, копирование и вставку из книги Excel в документ Word, создание графиков и диаграмм, сводных таблиц, функций, создание версий для печати и т.д.

Подробнее…

Автор: Scott Sehlhorst
Оригинал: Test Smarter, Not Harder
Перевод: Дмитрий Дудников по заказу Software-Testing.Ru

Эта статья о комбинаторных методах построения тестов первоначально была написана для developer.* в марте 2006 года. Недавняя статья на Dailytech обращает внимание на одно очень интересное исследование о новых методах генерации многомерных комбинаций (четверок и более), выполненное Лабораторией информационных технологий Национального института стандартов и технологий США (NIST, the National Institute of Standards and Technology). Данная переработанная и дополненная версия статьи учитывает эти результаты.

Введение

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

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

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

Подробнее…

Автор: Андрей Козлов

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

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

Я предлагаю модель, которая помогает существенно снизить риски неадекватного планирования. Суть её сводится к выделению сценариев использования приложения и наполнению их конкретными данными.

Подробнее…

Автор: Семенкин Максим

Оригинальная публикация

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

Подробнее…

Автор: Мартыненко Сергей

Оригинальная публикация: Часть 1, Часть 2.

Часть первая, рациональная

Эта часть статьи написана по мотивам доклада на первой конференции русскоязычного комьюнити тестировщиков 21 апреля 2007.

Под автоматизированным тестированием в этой статье понимается только и исключительно функциональное тестирование через GUI при помощи одного из инструментов: Rational Robot, QTP, TestComplete (священная корова, примерно соответствующая Oracle у DBA). Сделано это для того, чтобы не писать во всей статье оговорки.

Выбор регрессионных автоматических тестов

Для предотвращения «расползания» кода и раннего обнаружения ошибок широко применяется практика ежедневного тестирования в автоматическом режиме.

В мировой практике наиболее распространены следующие виды тестов:

Подробнее…

Автор: Евгений Россинский

Оригинальная публикация: http://blog.netstream.ru/2009/03/squis/

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

В этой статье я хочу рассказать какой инструментарий мы используем для тестирования наших desktop приложений, написанных на Qt.

Пол года назад в ходе исследования инструментов для тестирования GUI в поле моего зрения попал продукт Squish компании froglogic. Из плюсов данного решения можно отметить следующие:

тесная дружба Squish c классами Qt (в том числе и itemы в QGraphiscScene);
кроссплатформенность;
поддержка скриптовых языков (Javascript, Python);
автоматизированная генерация текста теста;
удобная система запуска тестов из консоли.

На другую чашу весов легла стоимость лицензии 93 000 руб. (это по августовскому курсу 2650 евро).

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

Подробнее…

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

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

Systems Sciences Institute
при IBM выявили, что стоимость исправления ошибки, выявленной после релиза, была в 4-5 раз выше, чем стоимость выявленной и исправленной ошибки во время разработки.
Следовательно, стоит тщательно тестировать веб-приложение до его выпуска.

Ниже приведен обзор 6 шагов, которые помогут в этом.

Шаг 1. Функциональное тестирование (Functional Testing)

Первым шагом тестирования веб-приложения является проверка функциональности системы.

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

Обычно функциональное тестирование включает в себя:

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

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

Шаг 2. Юзабилити тестирование (Usability Testing)

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

Юзабилити тестирование включает в себя следующие шаги:

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

Шаг 3. Тестирование интерфейса (Interface Testing)

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

Шаг 4. Тестирование совместимости (Compatibility Testing)

Ключевой шаг в тестировании веб-приложений — это обеспечение совместимости приложения со всеми веб-браузерами и устройствами.

Совместимость с веб-браузерами.

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

Кроме тестирования приложения на различных браузерах (и даже на Internet Explorer! :)), следует убедиться, что и другие версии одного и того же браузера обеспечивают корректную работу приложения.

Совместимость с мобильными устройствами.

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

Шаг 5. Тестирование производительности.

После проверки работы веб-приложения на различных браузерах и устройствах, следует проверить его на производительность во время высокой нагрузки. С помощью данного вида тестирования, можно проследить, как работает приложение при различной скорости интернета, а также как приложение себя поведёт при нормальных и пиковых нагрузках (load testing).

Чтобы определить предел работы приложения, оно подвергается высокому (стрессовому) уровню нагрузки до тех пор, пока не нарушится его функциональность (stress testing). Также это помогает проверить, как приложение восстанавливается после сбоев.

Шаг 6. Тестирование безопасности.

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

Тестирование безопасности включает в себя следующие шаги:

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

Большую пользу приносит чек-лист тестирования безопасности, так как он поможет организовать и структурировать тестовую работу. Чек-лист должен включать в себя задачи из таких областей:

Безопасная передача данных;
Аутентификация;
Управление сеансом;
Авторизация;
Криптография;
Проверка данных;
Отказ в обслуживании (Denial of Service);
Специфические функциональные тесты;
Обработка ошибок.

Заключение.

Мы провели обзор 6 шагов в тестировании веб-приложений. Если выполнять эти действия в процессе разработки приложения, они помогут найти и исправить как можно больше ошибок до того, как уже будет поздно.

В этой статье мы рассмотрим тестирование сайта
(веб-приложения
) с помощью наборов тестов. Она довольно длинная, поэтому усаживайтесь по удобнее.

Основные виды тестирования сайта (веб-приложения)

Тестирование функциональности;
Тестирование удобства использования;
Тестирование интерфейса;
Тестирование совместимости;
Тестирование производительности и скорости загрузки сайта;
Тестирование безопасности.

1. Тестирование функциональности

Проверьте все ссылки

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

Проверьте формы

Формы используются для получения информации от пользователей и взаимодействия с ними.

Что нужно проверить в формах:

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

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

Есть различные виды валидации, например, проверка электронной почты, финансовой информации пользователя и т.д. Все поля с валидацией нужно протестировать в ручном или автоматическом режиме.

Тестирование файлов cookie

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

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

Проверьте HTML/CSS

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

Тестирование базы данных

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

Проверьте, все ли запросы к базе данных выполняются правильно, данные извлекаются и обновляются должным образом.

При тестировании функциональности сайтов нужно проверить:

Ссылки

Внутренние ссылки;
Внешние ссылки;
Ссылки на электронную почту;
Битые ссылки.

Формы

Валидация полей;
Сообщения об ошибке при неверном вводе;
Обязательные и необязательные к заполнению поля.

База данных

Следует проверить целостность базы данных.

2. Тестирование удобства использования (юзабилити сайта)

Тестирование юзабилити — это анализ взаимодействия пользователя и сайта, поиск ошибок и их устранение.

При этом проверяется:

Легкость обучения;
Навигация;
Субъективная удовлетворенность пользователей;
Общий вид.

Проверка навигации

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

Проверка юзабилити:

Сайт должен быть простым в использовании;
Инструкции должны быть очень четкими;
Проверьте, достигают ли предоставленные инструкции поставленной цели;
Главное меню должно быть доступно на каждой странице;
Главное меню должно быть построено в логической последовательности.

Проверка контента

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

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

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

Другая информация для пользователей

Варианты поиска, карта сайта, справочные материалы и т.д. Проверьте работу всех ссылок в карте сайта. Функция «Поиск по сайту
» должна помогать легко находить нужный контент.

3. Тестирование интерфейса

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

Основные интерфейсы:

Интерфейсы веб-сервера и приложения.
Интерфейсы сервера базы данных и сервера приложения.

Если база данных или веб-сервер для какого-либо запроса, исходящего от сервера приложения, возвращает сообщение об ошибке, сервер приложения должен фиксировать его и отображать пользователю.

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

4. Проверка совместимости

Нужно проверить:

Совместимость с браузерами;
Совместимость с операционными системами;
Просмотр на мобильных устройствах;
Параметры печати.

Совместимость с браузерами

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

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

Проверьте работу веб-приложения в браузерах Internet Explorer
, Firefox
, Netscape Navigator
, AOL
, Safari
, Opera
разных версий.

Совместимость с операционными системами

Некоторые функции веб-приложения могут быть несовместимы с определенными операционными системами. Не во всех из них поддерживаются новые технологии, используемые в веб-разработке. Поэтому проверьте работу приложения в Windows
, Unix
, MAC
, Linux
, Solaris
и их различных версиях.

Просмотр на мобильных устройствах

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

Параметры печати

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

5. Тестирование производительности сайта

Тестирование производительности сайта или веб-приложения должно включать в себя:

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

Проверьте производительность приложения на различной скорости интернета.

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

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

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

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

Скорость соединения

Сплит тестирование сайта
при использовании различных вариантов интернет-соединения: через модем, ISDN
и т.д.

Нагрузка

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

Стрессовая нагрузка

Производительность памяти, процессора, обработки файлов и т. д.

6. Тестирование безопасности

Ниже приведены некоторые наборы для тестирования веб-безопасности:

Проверка с помощью вставки внутреннего URL
в адресную строку браузера без авторизации. Внутренние страницы при этом не должны открываться.
После авторизации с помощью логина и пароля, а также просмотра внутренних страниц попробуйте изменять URL
. Например, вы проверяете какую-то статистику сайта под идентификатором ID= 123
. Попробуйте изменить ID URL
на другой ID
сайта, который не имеет отношения к авторизованному пользователю. В любом случае доступ этого пользователя к просмотру других показателей должен быть запрещен.
Попробуйте ввести неверные данные в поля формы для авторизации. Выясните, как система реагирует на ввод недопустимых данных.
Каталоги или файлы не должны быть доступны напрямую, если для них не предусмотрена возможность скачивания.
Проверьте работу капчи для защиты от автоматического входа с помощью программного кода.
Проверьте, используется ли в целях безопасности SSL
. Если да, то должно отображаться сообщение при переходе пользователя с незащищенных HTTP-страниц
к защищенным и наоборот.
Все операции, сообщения об ошибках, нарушения безопасности должны записываться в файл журнала на веб-сервере.

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

Сетевое сканирование;
Сканирование уязвимостей;
Возможность потенциального взлома паролей;
Обзор журнала;
Средства для проверки целостности;
Обнаружение вирусов.

Моменты, которые следует учитывать при тестировании сайта

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

Есть множество типов серверов и браузеров различных версий. Между ними есть небольшие, но значимые различия.

Пример сценариев тестирования сайта

Дополнительные факторы, которые следует учесть при тестировании сайта:

Какова ожидаемая нагрузка на сервер (например, количество запросов за единицу времени
)?
Какая производительность требуется при различных видах нагрузки (время ответа веб-сервера, время отклика базы данных на запрос
)?
Какие инструменты потребуются для тестирования производительности?
Кто является целевой аудиторией? Какие браузеры будут использовать пользователи? Какова скорость подключения? Предназначен ли сайт для использования внутри организации или будет доступен в интернете для широкого круга пользователей?
Какую производительность ожидает получить клиент (насколько быстро должны загружаться страницы, как должны себя вести анимации, апплеты, нагрузка и запуск
)?
Будут ли разрешены простои сервера и техническое обслуживание, а также обновление контента? Если да, в каком количестве?
Какие средства безопасности требуются (файерволы, шифрование, пароли и т.д.
), и какую работу они будут выполнять? Как их можно проверять?
Насколько надежным должно быть интернет-соединение? Как оно будет влиять на резервное копирование системы?
Как будет выполняться управление обновлением контента сайта?
Требования для технического обслуживания, отслеживания и контроля содержимого веб-страниц, графических элементов, ссылок и т.д.
Какая спецификация HTML
будет соблюдаться? Насколько точно?
Как будут проверяться и обновляться внутренние и внешние ссылки? Насколько часто?
Как будет происходить управление и проверка CGI
апплетов, сценариев JavaScript
, компонентов ActiveX
и т.д.?
Максимальный размер веб-страницы не должен превышать 3-5 экранов, кроме случаев, когда контент сосредоточен на одной теме. Если размер веб-страницы больше, предоставьте внутренние ссылки для навигации по ней.
Разметка веб-страницы и элементы дизайна должны быть последовательными и логично связанными.
Отображение веб-страниц должно быть независимо от типа браузера.
На каждой странице следует указать ссылку для связи.

Перевод статьи “Web Testing Complete Guide (Web Application Testing Tips and Scenarios)
” был подготовлен дружной командой проекта

Тестирование веб-приложений

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

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

Виды тестирования веб-приложений

Вот несколько основных видов тестирования веб-приложений:

1. Функциональное тестирование.
Это тестирование используется для проверки всех ссылок веб-страниц; Тестирования форм, файлов cookie и подключение к базе данных.

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

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

4. Тестирование совместимостb.
Тестирование на совместимость очень важно, так как оно проверяет совместимость браузера, совместимость с операционной системой, параметры браузера и печати.

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

6. Тестирование безопасности.
Проверяет безопасность веб-приложений. В целях безопасности внутренние страницы не должны открываться, если вы не вошли на веб-сайт. Другая статистика не должна отображаться, даже если пользователь вошел в систему. Файлы должны быть доступны только при входе в аккаунт, и к ним нельзя получить доступ без этого. CAPTCHA для автоматизации входа должна быть также протестирована. SSL должен быть протестирован на меры безопасности.

После завершения тестирования всех веб-приложений необходимо провести тестирование в реальном времени для веб-приложений и веб-сайтов. Затем загрузите сайт и выполните полное тестирование.

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

Возможны многочисленные способы использования приложения (Entry-Exit)

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

Даже в том же браузере приложения могут выполняться по-разному в зависимости от локальных нюансов, таких как разрешение экрана / аппаратная / программная конфигурация системы

Приложения могут потребовать тестирования на совместимость и удобство использования

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

А развить навыки успешного тестировщика Вам помогут наши — звоните и записывайтесь прямо сейчас!

Описание курса:

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

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

Программа курса:

Занятие 1. Вводная. Протокол SOAP

Коротко о лекторе;
Цели курса;
Что такое API, WS и зачем они нужны;
Роль тестирования API в процессе обеспечения качества;
Обзор инструментария для тестирования WS;
Методики применяемые в тестировании WS;
История возникновения SOAP;
Терминология и главные понятия (XML, XSD, Endpoint, WSDL).

Занятие 2: Протокол SOAP. Архитектура REST

Терминология и главные понятия (UDDI, XSLT, XPath, XQuery, HTTP methods, HTTP statuses);
Структура и главные компоненты SOAP;
Сфера применения;
Особенности работы;
Преимущества и недостатки;
Особенности REST архитектуры;
Терминология и главные понятия (WADL, RESTful, JSON, JSONPath);
Принципы REST;
Статус код и основные статусы;
CRUD глаголы;
Преимущества и недостатки.

Занятие 3. Знакомство с SoapUI. Работа с REST проектом

Установка Java;
Установка SoapUI;
Обзор основных элементов интерфейса;
Подключение учебного проекта;
Обзор методов проекта;
Отправка запроса и анализ полученного ответа;
Изучение доступных веб-сервисов проекта;
Составление плана тестирования;
Написание тест-кейсов;
Элементы “TestSuite», “TestCase”, “TestSteps”.

Занятие 4. Работа с REST проектом (XML)

Блок “Assertions”;
Запуск тестов на различных уровнях;
Элемент “Properties”, основные возможности;
Работа с Properties;
Элемент “Property Transfer”;
Работа с Assertions.

Занятие 5. Работа с REST проектом (JSON)

Условия и ветвления;
Работа с Assertions;
TestRunner, особенности работы;
Запуск TS, TC из командной строки;
Работа с Test runner;
Работа с Groovy скриптами.

Занятие 6. Работа с Groovy скриптами

Работа со статическими и динамическими данными;
Генерируем тестовые данные;
Получаем данные из “Properties”;
Запись и трансфер данных;
Условия и ветвления;
Script Assertion.

Занятие 7. Дополнительные возможности

Подключение внешних библиотек и кастомных классов;
Mock-сервисы;
Зачем нужны Mock-сервисы;
Пример работы с Mock-сервисом;
А как же CI?
Устанавливаем Jenkins;
Запуск проекта на Jenkins.

Тестирование веб-приложений 2.0

Duration 11:28:40

Тестирование веб-приложений 2.0 — Полный список уроков

Развернуть / Свернуть

Урок 1. Общая теория. Что такое тестирование и что такое программа

00:07:27
Урок 2. Что нужно тестировать

00:09:53
Урок 3. Структура программы и её интерфейсы

00:10:45
Урок 4. Внутреннее устройство браузера

00:05:38
Урок 5. HyperText Markup Language (HTML)

00:11:02
Урок 6. Тестирование разметки

00:18:14
Урок 7. Тестирование текстового содержимого страниц

00:06:03
Урок 8. Тестирование ссылок

00:12:17
Урок 9. Тестирование локализации

00:06:51
Урок 10. Клиент-серверная архитектура

00:14:01
Урок 11. HyperText Transfer Protocol (HTTP)

00:09:58
Урок 12. Перехват запросов и ответов

00:14:52
Урок 13. HTTP. Продолжение

00:22:10
Урок 14. Протоколирование запросов и ответов на сервере

00:12:35
Урок 15. User-Agent — браузеры и боты

00:12:36
Урок 16. Отправка на сервер поддельных запросов

00:07:59
Урок 17. Адреса ресурсов. Domain Name Service (DNS)

00:13:47
Урок 18. Что происходит с запросом на сервере

00:14:08
Урок 19. Генерация полезной нагрузки

00:14:24
Урок 20. Источники данных (файлы, база данных)

00:15:46
Урок 21. Кеширование данных на стороне сервера

00:12:06
Урок 22. Многоуровневая архитектура

00:12:01
Урок 23. Аутентификация и авторизация

00:21:46
Урок 24. Тестирование прав доступа

00:13:19
Урок 25. Тестирование производительности серверной части

00:12:15
Урок 26. Ввод данных в формы

00:14:32
Урок 27. Типы запросов GET и POST

00:09:41
Урок 28. Неявные параметры запроса

00:07:32
Урок 29. Функциональное тестирование

00:18:04
Урок 30. Автоматизация функционального тестирования

00:19:35
Урок 31. Тестирование производительности

00:13:23
Урок 32. Тестирование защищенности

00:18:14
Урок 33. Cascading Style Sheets (CSS)

00:09:03
Урок 34. Cascading Style Sheets (CSS), продолжение

00:14:41
Урок 35. Автоматическая проверка CSS

00:12:09
Урок 36. Тестирование верстки (layout)

00:10:43
Урок 37. Адаптивная верстка

00:10:44
Урок 38. Семантическая верстка

00:06:40
Урок 39. JavaScript
00:13:33
Урок 40. Анимация без JavaScript

00:04:53
Урок 41. Document Object Model (DOM)

00:12:48
Урок 42. Валидация данных в формах

00:14:06
Урок 43. Асинхронные запросы (AJAX)

00:13:27
Урок 44. Одностраничники (Single Page Application, SPA)

00:10:16
Урок 45. REST API
00:16:09
Урок 46. Клиентская производительность

00:10:59
Урок 47. Инструменты для оценки клиентской производительности

00:14:18
Урок 48. Оптимизация клиентской производительности

00:13:45
Урок 49. Тестирование функциональности

00:18:13
Урок 50. Тестирование производительности

00:13:30
Урок 51. Тестирование удобства использования и доступности

00:19:13
Урок 52. Мониторинг

00:13:02
Урок 53. Сплит-тестирование

00:14:09
Урок 54. Оптимизация для поисковиков и социальных сетей

00:09:25

Курс посвящен особенностям тестирования веб-приложений (HTML, CSS, JavaScript) и специфике применения техник тест-дизайна для приложений такого типа. Тренинг полностью перезаписан весной 2018 года.
Чем тестирование веб-приложений отличается от тестирования каких-нибудь других приложений? При тестировании веб-приложений применяются те же самые классические методы и техники проектирования тестов. Веб-приложения обычно имеют более простой интерфейс, чем «десктопные» программы. Браузером все умеют пользоваться, для этого не нужны какие-то специальные навыки.

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

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

После прохождения тренинга учащийся будет:

понимать принципы работы веб-приложений и знать, какие технологии при этом используются,
знать особенности тестирования веб-приложений по сравнению с десктопными приложениями,
уметь проектировать тесты с учётом особенностей веб-приложений и оценивать покрытие тестами функциональности приложения,
уметь выполнять тесты, при необходимости используя инструментальные средства для преодоления ограничений, накладываемых браузером,
владеть инструментами, для выполнения специфических проверок, характерных для веб-приложений:
- анализ целостности ссылок,
- анализ соответствия веб-стандартам,
понимать причины возникновения уязвимостей в веб-приложениях и уметь обнаруживать наиболее критические уязвимости в веб-приложениях,
понимать принципы оценки производительности веб-приложений и уметь выполнять анализ серверной и клиентской производительности веб-приложений,
уметь рассуждать об удобстве использования веб-приложений:)

Каждое занятие будет сопровождаться практическими заданиями, которые помогут быстрее и увереннее начать применять знания на практике.

Источник

In Junit, test suite allows us to aggregate all test cases from multiple classes in one place and run it together.

To run the suite test, you need to annotate a class using below-mentioned annotations:

@Runwith(Suite.class)
@SuiteClasses(test1.class,test2.class……) or@Suite.SuiteClasses ({test1.class, test2.class……})

With above annotations, all the test classes in the suite will start executing one by one.

Steps to create Test Suite and Test Runner

Step 1) Create a simple test class (e.g. MyFirstClassTest) and add a method annotated with @test.

Step 2) Create another test class to add (e.g. MySecondClassTest) and create a method annotated with @test.

Step 3) To create a testSuite you need to first annotate the class with @RunWith(Suite.class) and @SuiteClasses(class1.class2…..).

Step 4) Create a Test Runner class to run our test suite as given below;

Code Explanation:

Code Line 8: Declaring the main method of the class test which will run our JUnit test.
Code Line 9: Executing test cases using JunitCore.runclasses which takes the test class name as a parameter (In the example above, you are using TestSuiteExample.class shown in step 3).
Code Line 11: Processing the result using for loop and printing out failed result.
Code Line 13: Printing out the successful result.

Output: Here is the output which shows successful test with no failure trace as given below:

Consider a more complex example

JunitTest.java

JunitTest.java is a simple class annotated with @RunWith and @Suite annotations. You can list out number of .classes in the suite as parameters as given below:

package guru99.junit;		
import org.junit.runner.RunWith;		
import org.junit.runners.Suite;		

@RunWith(Suite.class)				
@Suite.SuiteClasses({				
  SuiteTest1.class,
  SuiteTest2.class,  			
})		

public class JunitTest {				
			// This class remains empty, it is used only as a holder for the above annotations		
}

SuiteTest1.java

SuiteTest1.java is a test class having a test method to print out a message as given below. You will use this class as a suite in above mentioned class.

package guru99.junit;		

import static org.junit.Assert.assertEquals;				

import org.junit.Test;		

public class SuiteTest1 {				

    public String message = "Saurabh";							

    JUnitMessage junitMessage = new JUnitMessage(message);							

    @Test(expected = ArithmeticException.class)					
    public void testJUnitMessage() {					

        System.out.println("Junit Message is printing ");					
        junitMessage.printMessage();			

    }		

    @Test		
    public void testJUnitHiMessage() {					
        message = "Hi!" + message;							
        System.out.println("Junit Hi Message is printing ");					
        assertEquals(message, junitMessage.printHiMessage());					
        System.out.println("Suite Test 2 is successful " + message);							
    }		
}

SuiteTest2.java

SuiteTest2.java is another test class similar to SuiteTest1.java having a test method to print out a message as given below. You will use this class as suite in JunitTest.java.

package guru99.junit;		

import org.junit.Assert;		
import org.junit.Test;		

public class SuiteTest2 {				
   	

    @Test		
    public void createAndSetName() {					
        		

        String expected = "Y";					
        String actual = "Y";					

        Assert.assertEquals(expected, actual);					
        System.out.println("Suite Test 1 is successful " + actual);							
    }		

}

Output

After executing JunitTest.java which contains a suite having test1.java and test2.java, you will get below output:

Summary

In this tutorial, you have learned basics of test harness and test suites in details with an example.

Test harness or automation Testing is a software or a collection of software, which allows a user to test data with multiple inputs and control the execution
Test harness actually enables a test framework that does all the work of executing tests using a test library and generating a test report
In Junit, test suite allows us to aggregate all test cases of many classes in one place and run it together.

Источник