Сила связей в ручном тестировании. Часть 2: Связываем тест-кейсы с wiki-страницами

Оглавление

• Часть 1: Формулируем подход для решения сложных задач
  

  • Стоит ли вам читать эту статью

  • Контекст

  • Суть подхода

  • Эффект использования подхода на примере подготовки тестовых данных

• Часть 2: Связываем тест-кейсы с wiki-страницами
  

  • Использование проверочных скриптов

  • Использование артефактов тест-дизайна

  • Данные запросов и сообщений для интеграционного тестирования

Использование проверочных скриптов

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

Для тестирования я использовал SQL-запрос, описанный ниже. Под каждую таблицу с отдельным набором данных в CTE expected (реальные наборы данных и названия таблиц с проекта заменены на те, что я подготовил для статьи):

with
    expected as (
        select *
        from (
            -- Описываем записи с ожидаемыми данными, включая названия столбцов после t в конце CTE
            values
                ('16'		 , 'iPhone'	),
                ('Galaxy S23', 'Samsung'),
                ('14'		 , 'Xiaomi'	),
                ('P60'		 , 'Huawei'	),
                ('X6'		 , 'POCO'	)
        ) t("name", manufacturer)
    ),
    -- Ищем записи с фактическими данными по тем же столбцам, что заданы в предыдущем CTE
    fact as (
        select "name", manufacturer
        from smartphones.models
    ),
    -- Ищем несоответствия между ожидаемым и фактическим наборами записей
    mismatches as (
        select
            *,
            -- Добавляем столбец с текстовой строкой к записям для упрощения идентификации
            ' (Ожидаемая запись)' as status
        from (
            select *
            from expected
            except all
            select *
            from fact
        ) sq1
        union all
        select
            *,
            ' (Фактическая запись)' as status
        from (
            select *
            from fact
            except all
            select *
            from expected
        ) sq2
        order by manufacturer, status -- Добавляем сортировку несоответствий при необходимости
    ),
    -- Собираем полученную информацию
    info as (
        select
            (select count (*) from mismatches) as count_mismatches,
            (select string_agg(
                concat_ws(', ', manufacturer, "name") || status
            , E'\n') from mismatches) as mismatches,
            (select count (*) from expected) as count_expected,
            (select count (*) from fact) as count_fact
    )
select *
from info

Кстати, логика в этом запросе универсальна: его можно использовать для тестирования данных в любой таблице базы данных в СУБД типа SQL. Конечно, с предварительной заменой проверяемой таблицы, её столбцов и ожидаемого датасета. Если хотите попробовать применить такой запрос у себя на проекте - дайте знать, опишу, что нужно заменить.

Если датасеты идентичны, запрос показывает отсутствие несоответствий (mismatches):

Заменим, например, (16, 'iPhone') на (15, 'iPhone'). Теперь запрос показывает наличие несоответствий и дает по ним информацию:

Несоответствия также будут засчитаны при наличии лишних записей и/или при отсутствии ожидаемых:

Шаг, в котором есть ссылка на wiki-страницу с кодом, обычно содержит меньше текста, чем шаг, в котором нет такой ссылки Это связано с тем, что действия и их логика переносятся из текстового поля в скрипт. Тест-кейсы с такими шагами получаются менее многословными, что уменьшает количество времени на ознакомление с ними и на их выполнение. Это, в свою очередь, снижает влияние bus factor'а на проекте.

Сравним шаг для проверки соответствия фактических данных ожидаемым в БД (например, после выполнения какого-либо метода или алгоритма):

1-й вариант

Описание: Анализ данных в таблице models

Шаг:

1. Перейти по пути в DBeaver: _local.smartphones.models

2. Открыть раздел Data таблицы models

3. Сравнить записи в таблице с ожидаемыми:

Ожидаемый результат: Набор фактических записей в таблице models соответствует ожидаемому

2-й вариант

Описание: Анализ данных в таблице model

Шаг: Убедиться, что фактический набор записей соответствует ожидаемому, выполнив SQL-запрос:
Ссылка на wiki-страницу с кодом

Ожидаемый результат: Значение в столбце count_mismatches: 0

Сумма слов в разделах Шаг и Ожидаемый результат:

• В 1-м варианте: ~35 слов с учетом чисел в столбце name;

• В 2-м варианте: 15 слов без учета словосочетания Ссылка на wiki-страницу с кодом - вместо него, соответственно, предполагается ссылка. БД, в которой необходимо выполнить запрос (smartphones), - указывается на wiki-странице.

Разница - двукратная. И это пример с 1-м шагом и 4-мя проверяемыми записями. На реальном проекте с сотнями тест-кейсов и тысячами проверяемых значений получается крайне существенная экономия ресурсов. Выполнение запроса также занимает меньше времени, чем выполнение 3-х действий, описанных в 1-м варианте.

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

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

Для всех тест-кейсов:

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

  delete from smartphones.models
  where
  	"name" in ('X6', '16', 'Galaxy S23', '14', 'P60')
  	and manufacturer in ('POCO', 'iPhone', 'Samsung', 'Xiaomi', 'Huawei')

• Скрипт для очистки проверяемых данных, выполняемый в постусловии - чистим за собой, чтобы не захламлять БД (такой же, как в предусловии).

Для каждого отдельного тест-кейса:

• Создание:

  • Скрипт для проверки создания записей в таблице после их добавления на UI (описан выше, в начале раздела Использование проверочных скриптов в шагах);

• Чтение:

  • Скрипт для добавления проверяемых данных, выполняемый в предусловии:

    insert into smartphones.models
        (id, "name", manufacturer) 
    values
        (1, '16',           'iPhone'),
        (2, 'Galaxy S23',   'Samsung'),
        (3, '14',           'Xiaomi'),
        (4, 'P60',          'Huawei'),
        (5, 'GT',           'realme'),
        (6, 'X6',           'POCO');

• Обновление:

  • Скрипт для добавления проверяемых данных, выполняемый в предусловии (описан выше, в Чтении);

  • Скрипт для проверки изменения записей в таблице после их изменения на UI (запрос, аналогичный тому, что описан в начале раздела Использование проверочных скриптов в шагах, но с корректировкой одного из значения на изменяемое);

• Удаление:

  • Скрипт для добавления проверяемых данных, выполняемый в предусловии (описан выше, в Чтении);

  • Скрипт для проверки отсутствия записей в таблице после их удаления на UI:

    select exists (select * from smartphones.models)

Кстати, метаданные таблиц мы тоже проверяем автоматически:

Этот запрос также можно использовать с любой таблицей в СУБД типа SQL. Ему посвящена отдельная статья: https://habr.com/ru/articles/862562/

Использование артефактов тест-дизайна

Wiki-страницы пространства тестирования полезны не только для частичной автоматизации. Но и для структуризации большого количества тестовых данных. Бывают случаи, когда объект тестирования настолько комплексный, что даже после применения техник тест-дизайна все равно остается слишком много проверок. Я столкнулся с такой ситуацией при работе с алгоритмом, для которого предполагается передача 32-х входных параметров разных типов. Для одного из них валидными значениями считаются те, что относятся к определенному списку. Группа других - коэффициенты, для которых ожидаются значения в диапазоне от 0 до 1. Есть и группа строковых параметров, где каждый из них принимает лишь 1 валидное значение в текущей версии алгоритма. При этом 15 параметров - обязательны для заполнения перед каждым запуском, а остальные - опциональны.

После применения техник тест-дизайна получилось 111 проверок, необходимых для тестирования по поставленной задаче. 51 позитивная проверка и 60 - негативных. Позитивные проверки можно объединять и тестировать совместно в рамках 1-го шага, а вот каждую негативную проверку нужно выполнять отдельно. Это связано с тем, что в алгоритме единовременно возможно срабатывание только 1-го exception'а. После этого его выполнение завершается с ошибкой. С учетом подобных особенностей финальное количество наборов тестовых данных (ТД) составило 73. Мы их раскидали по 4-м тест-кейсам:

1. Все наборы ТД для позитивных проверок;

2. Все наборы ТД для негативных проверок;

3. Сокращенные наборы ТД для позитивных проверок;

4. Сокращенные наборы ТД для негативных проверок.

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

Наименьшее количество шагов среди этих тест-кейсов - в том, который содержит сокращенные наборы ТД для позитивных проверок, - 6 шагов. 3 из них содержат наборы значений, которыми нужно заполнить параметры (остальные служат для проверки факта заполнения таблиц после прогона алгоритма). С учетом того, того, что 15 входных параметров являются обязательными для заполнения, каждый из шагов будет содержать примерно такой текст:

1. В селекте "Алгоритм" выбрать "Алгоритм 1"

2. Заполнить входные параметры:
   

   1. param1:
      1

   2. param2:
      0

   3. param3:
      0

   4. param4:
      Y

   5. param5:
      simple-mode

   6. param6:
      12

   7. param7:
      6

   8. param8:
      calendar

   9. param9:
      history_value

   10. param10:
       new_value

   11. param11:
       history_table

   12. param12:
       new_table

   13. param13:
       value_table

   14. param14:
       resource;area;supplier

   15. param15:
       true

3. Нажать кнопку "Запустить". Перейти на страницу "Анализ выполнения алгоритмов"

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

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

1. В селекте "Алгоритм" выбрать "Алгоритм 1"

2. Заполнить входные параметры, используя ТД из wiki-страницы:
   Ссылка на страницу

3. Нажать кнопку "Запустить". Перейти на страницу "Анализ выполнения алгоритмов"

Примерно так и выглядит шаг из реального тест-кейса. На связанной wiki-странице у нас содержится та же информация, что во 2-м пункте, в предыдущем варианте. Здесь хранится 1 тестовый набор данных для каждого конкретного шага. С этой wiki-страницей связана другая, где хранятся сведения по логике формирования тестовых данных и таблица с описанием проверок. Покажу, как она выглядит для шага, описанного выше, но, для краткости, с информацией по 2-м параметрам вместо 15-ти:

Схема связей артефактов тестирования в этом случае выглядит так:

Здесь прямоугольники - это wiki-страницы, овалы - разделы wiki-страницы, пятиугольник - тест-кейс. На странице "Общие данные для строковых параметров с 1-м валидным значением" содержатся значения для параметров param8 - param15. Это те, что:

Есть и группа строковых параметров, где каждый из них принимает лишь 1 валидное значение в текущей версии алгоритма.

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

Выглядит это примерно так (значения параметров param8 - param15 наследуются, остальные - отличаются):

Wiki-страница с тестовыми данными 1

Общие данные для строковых параметров с 1-м валидным значением

1. param8:
   calendar

2. param9:
   history_value

3. param10:
   new_value

4. param11:
   history_table

5. param12:
   new_table

6. param13:
   value_table

7. param14:
   resource;area;supplier

8. param15:
   true

9. param1:
   1

10. param2:
    0

11. param3:
    0

12. param4:
    Y

13. param5:
    simple-mode

14. param6:
    12

15. param7:
    6

Wiki-страница с тестовыми данными 2

Общие данные для строковых параметров с 1-м валидным значением

1. param8:
   calendar

2. param9:
   history_value

3. param10:
   new_value

4. param11:
   history_table

5. param12:
   new_table

6. param13:
   value_table

7. param14:
   resource;area;supplier

8. param15:
   true

9. param1:
   0.5

10. param2:
    0.5

11. param3:
    0.5

12. param4:
    M

13. param5:
    advanced-mode

14. param6:
    24

15. param7:
    12

Кстати, диаграмма иллюстрирует тезис, который я описал в разделе Суть подхода:

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

Итак, связывание wiki-страниц с шагами тест-кейса позволяет:

• Сократить количество текста в шагах тест-кейсов;

• Переиспользовать повторяющиеся данные;

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

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

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

Данные запросов и сообщений для интеграционного тестирования

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

POST https://smartphones.ru/catalog

{
  "smartphones": [
    {
      "brand": "TechOne",
      "model": "X100 Pro",
      "release_date": "2024-03-15",
      "specs": {
        "display": "6.7 inch OLED",
        "processor": "Octa-core 3.2GHz",
        "ram": "12GB",
        "storage": "256GB",
        "camera": {
          "rear": "108MP + 12MP + 5MP",
          "front": "32MP"
        },
        "battery": "4500mAh",
        "os": "Android 14"
      },
      "price": 899,
      "colors": ["Black", "Silver", "Aurora Blue"]
    },
    {
      "brand": "Photonix",
      "model": "PX-Magic",
      "release_date": "2024-05-22",
      "specs": {
        "display": "6.5 inch AMOLED",
        "processor": "Hexa-core 2.9GHz",
        "ram": "8GB",
        "storage": "128GB",
        "camera": {
          "rear": "64MP + 16MP",
          "front": "20MP"
        },
        "battery": "4200mAh",
        "os": "Photonix OS 3.0"
      },
      "price": 649,
      "colors": ["Midnight Black", "Sunrise Gold", "Ocean Green"]
    },
    {
      "brand": "NebulaTech",
      "model": "Nebula Z2",
      "release_date": "2024-02-10",
      "specs": {
        "display": "6.8 inch Super Retina",
        "processor": "Quad-core 3.5GHz",
        "ram": "16GB",
        "storage": "512GB",
        "camera": {
          "rear": "200MP + 50MP + 12MP",
          "front": "40MP"
        },
        "battery": "5000mAh",
        "os": "Nebula OS 5.0"
      },
      "price": 1099,
      "colors": ["Space Gray", "Starlight White", "Cosmic Red"]
    },
    {
      "brand": "GalaxyPrime",
      "model": "Galaxy Ultra S",
      "release_date": "2024-06-30",
      "specs": {
        "display": "7.1 inch Dynamic AMOLED",
        "processor": "Deca-core 3.8GHz",
        "ram": "12GB",
        "storage": "256GB",
        "camera": {
          "rear": "150MP + 24MP + 10MP",
          "front": "32MP"
        },
        "battery": "4800mAh",
        "os": "GPrime OS 4.0"
      },
      "price": 999,
      "colors": ["Jet Black", "Pearl White", "Emerald Green"]
    },
    {
      "brand": "Solarion",
      "model": "Helios Max",
      "release_date": "2024-07-15",
      "specs": {
        "display": "6.9 inch Fluid AMOLED",
        "processor": "Octa-core 3.1GHz",
        "ram": "8GB",
        "storage": "128GB",
        "camera": {
          "rear": "100MP + 12MP + 8MP",
          "front": "24MP"
        },
        "battery": "4700mAh",
        "os": "Solarion UI 6.0"
      },
      "price": 749,
      "colors": ["Solar Black", "Sunburst Orange", "Twilight Blue"]
    },
    {
      "brand": "HyperNova",
      "model": "NovaX Edge",
      "release_date": "2024-08-25",
      "specs": {
        "display": "6.4 inch OLED",
        "processor": "Hexa-core 2.8GHz",
        "ram": "6GB",
        "storage": "64GB",
        "camera": {
          "rear": "48MP + 12MP",
          "front": "16MP"
        },
        "battery": "4100mAh",
        "os": "Hyper OS 2.0"
      },
      "price": 499,
      "colors": ["Graphite Gray", "Lunar Silver", "Coral Pink"]
    }
  ]
}

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

Тем временем привязанная к тест-кейсам таблица с описанием проверок дает значительно больше контекста по объекту тестирования. Это упрощает работу, что, в свою очередь, приводит к экономии ресурсов. Автору тест-кейса, который составил описанный выше http-запрос, вполне может через некоторое время прийти задача на расширение тестового набора в связи, например, с доработками по связанной функциональности. И если в рамках этой активности необходимо будет править тело запроса, то без артефакта тест-дизайна сделать это будет затруднительно. Особенно по прошествии времени, после переключения на другие задачи. В конце концов с объемными json'ами зачастую неудобно работать в TMS. Например, в Xray, в поле шага, отображается только часть текста и скролл.

Рассмотрим еще пример. В рамках тест-кейса с позитивными проверками необходимо отправить 2 http-запроса:

{
    "smartphones": [
        {
            "manufacturer": "Nothing",
            "model": "Nothing Phone 2",
            "price": 65000
        }
    ]
}

и

{
    "smartphones": [
        {
            "manufacturer": "Huawei",
            "model": "P60",
            "price": 55000,
            "country": "China"
        },
        {
            "manufacturer": "Xiaomi",
            "model": "Xiaomi Redmi Note 11 Pro 4G",
            "price": 25000
        }
    ]
}

Выглядит значительно проще. Тем не менее непонятно, почему в теле 1-го запроса - 1 объект в массиве smartphones, а во 2-м - 2 объекта. И почему во 2-м запросе, в 1-м объекте массива - 4 параметра, а во 2-м - 3. И должно ли все быть именно так. И как эти данные соотносятся с негативными проверками.

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

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

Wiki-страницы полезны и при работе с сообщениями MQ. Все, что описано для http-запросов, применимо и к таким сообщениям. Также в случае с MQ поддерживаемость можно упростить через наследование страницы с хэдерами на страницах с телом сообщения:

Продолжение - в следующей части.