Удаленка для jenkins+selenide+selenoid+allure+docker спецов на 2-3 часа в день. 100% remote! Присоединиться к проекту

Как создать 3 тысячи уникальных объектов и сверить финальную стоимость каждого?

design-patterns
desktop
mobile
Теги: #<Tag:0x00007fedbb3a6ac8> #<Tag:0x00007fedbb3a6988> #<Tag:0x00007fedbb3a6848>

(Timur Colesnic) #1

Здравствуйте!

Есть ли способы автоматизировать тестирование в такой ситуации?

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

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

Каждое окно имеет множество параметров, которые возможно представить как древовидную структуру:

Я представил упрощенную схему, параметров на самом деле их намного больше.

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

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

Если не создавать 3 тысячи окон, но имея уверенность, что все баги в вычислениях пофиксили.
Какие есть способы наглядно представить результаты тестирования?


(Bohdan B) #2

Почему бы не использывать Pairwise техники для сокращения количества комбинаций, и для сокращенного списка написать Data-driven тест?


(Timur Colesnic) #3

Мы имеем на первом уровне a, b, c
На следующем уровне “a” может получить f , e , d
На следующем уровне “f” может получить j, k , l

И таких уровней 5-6 в зависимости от стартовой буквы

В итоге ветка “а” никогда не будет похожа на ветку b или c.

То есть мы никак не можем сократить количество комбинаций (веток)

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


#4

этот подход – это антипаттерн, http://www.professionalqa.com/exhaustive-testing


(Bohdan B) #5

Почему бы не ограничится единичной проверкой веток? a -> f -> k -> another -> another, a -> e -> another -> another + не до конца ясно как при уровне зависимости 5-6 уровней получается 3к объектов. Если всё-таки стоит задача перебрать все 5 - 6 веток, то почему бы топорно не написать 1 раз генератор входных данных и использовать полученные данные в тесте - хотя, как заметил комментатор выше, это антипаттерн


(Timur Colesnic) #6

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

И как оказалось - этого недостаточно для отчетности

Это всецело идея разработчиков создать покрытие тестами всех веток

На случай, если клиент спросит: а вы проверили вот эту ветку? И сам попробует перепроверить


(Timur Colesnic) #7

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


(Alex Gt) #8

Тимур, привет!

Как уже сказали выше, exhaustive testing или исчерпывающее тестирование - это антипаттерн. Зачастую невозможно либо не эффективно (финансово, по количеству затраченного времени, и т.д.) тестировать все возможные комбинации входных данных.

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

Иными словами, используя принцип Парето (20% тестов находят 80% ошибок), я бы выделил для тестирования наиболее часто встречающиеся комбинации параметров - это можно узнать у клиента, а оставшееся время потратил бы на более специфические варианты.

Кроме как Excel-таблицы с наименованием ветки и Actual \ Expected, вариантов не вижу. См. Data-driven testing

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


(Bolatbek) #9

Если идет речь о миллионах комбинаций - тогда можно говорить об антипаттерне.
А тут “всего” лишь 3000 штук.
Их перебрать можно и нужно (раз требует заказчик, или может потребует).


(Dmitri Komarist) #10

Вам нужно создать управляемый данными тест. Поскольку у Вас написано что нужно сверить стоимости то я полагаю что у Вас есть таблица в которой указаны параметры окна и стоимость. Параметры должны быть масивом и передаваться через Ваше API, стоимость ожидаемым результатом. Я бы не стал автоматизировать это через UI будет очень долго работать, а вот через API самое оно (20-30сек и тесты пройдены). Попросите разработчика сделать такой интеграционный тест на уровне бизнес-логики. А сами напишите UI тест на одну самую длинную ветку, что-бы проверить UI функциональность (чекбоксы, кнопки, выпадающие списки…).