Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <h2>Тест-дизайн</h2>

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

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

4 Разработка тестов начинается после проведения исследования ПО, когда цели определены, а критерии тестирования заданы и выполняются.

5 <h2>Техники тест-дизайна</h2>

6 Техники тест-дизайна помогают:

7 <ol><li>Исключить непродуктивные тест-кейсы и сократить общее количество кейсов</li>

8 <li>Покрыть тестами как можно больше функциональности</li>

9 <li>Провести все тесты и не пропустить ничего важного</li>

10 </ol>Для работы с кодом (white-box) важны такие аспекты:

11 <ul><li>Покрытие операторов</li>

12 <li>Покрытие условий</li>

13 <li>Покрытие путей</li>

14 <li>Покрытие функций</li>

15 <li>Покрытие вход/выход</li>

16 <li>Покрытие значений параметров</li>

17 </ul>В работе с требованиями (black-box) тестирование проходит иначе:

18 <ul><li>Классы эквивалентности</li>

19 <li>Граничные значения</li>

20 <li>Попарное тестирование</li>

21 <li>Таблица принятия решений</li>

22 <li>Диаграмма состояний и переходов</li>

23 <li>Тестирование вариантов использования</li>

24 <li>Доменное тестирование.</li>

25 </ul><h2>Техники тест-дизайна на основании требований</h2>

26 <h3>Классы эквивалентности</h3>

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

28 Рассмотрим для примера перевод денег в банке. Размер комиссии зависит от суммы перевода:

29 <ul><li>от 1 до 999 долларов включительно - 0%</li>

30 <li>от 1000 до 4999 долларов включительно - 5%</li>

31 <li>от 5000 долларов - 7%</li>

32 </ul>Максимальная сумма перевода - 100000 долларов, при этом дробные числа не учитываются.

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

34 <ul><li>1-999 => ожидаем комиссию 0%</li>

35 <li>1000-4999 => ожидаем комиссию 5%</li>

36 <li>5000-100000 => ожидаем комиссию 7%</li>

37 </ul>Выбранные значения для проверки: 500, 2500, 7500.

38 <ul><li>На значение 500 система отреагирует так же, как и на любое другое значение из первого диапазона</li>

39 <li>На значение 2500 система отреагирует так же, как и на любое другое значение из второго диапазона</li>

40 <li>На значение 7500 система отреагирует так же, как и на любое другое значение из третьего диапазона</li>

41 </ul><h3>Граничные значения</h3>

42 Граничные значения - это значения, в которых один класс эквивалентности переходит в другой. По своей сути это техника, которая дополняет технику классов эквивалентности.

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

44 Например, неопытный программист при постановке "не больше 1000" может поставить значение <1000.

45 Вернемся к примеру с комиссией:

46 <ul><li>от 1 до 999 долларов включительно - 0%</li>

47 <li>от 1000 до 4999 долларов включительно - 5%</li>

48 <li>от 5000 долларов - 7%</li>

49 </ul>Максимальная сумма перевода - 100000 долларов, при этом дробные числа не учитываются. Вспомним классы эквивалентности:

50 <ul><li>1-999 => ожидаем комиссию 0%</li>

51 <li>1000-4999 => ожидаем комиссию 5%</li>

52 <li>5000-100000 => ожидаем комиссию 7%</li>

53 </ul>Граничные значения: 1, 999, 1000, 4999, 5000, 100000.

54 С учетом классов эквивалентности и граничных значений выбираем значения для проверки:1, 500,999,1000, 2500,4999,5000, 7500,100000.

55 <h3>Попарное тестирование (pairwise)</h3>

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

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

58 Рассмотрим пример. Возьмем наушники с такими характеристиками:

59 <ul><li>Тип подключения (беспроводной или проводной)</li>

60 <li>Микрофон (включен или выключен)</li>

61 <li>Подсветка (включена или выключена)</li>

62 </ul>Полный перебор даст нам восемь тест-кейсов. Это 2 в третьей степени, потому что у каждого из трех параметров может быть всего два значения:

63 Как правило, подобных характеристик в реальном мире куда больше, что неизбежно увеличивает количество тест-кейсов.

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

65 <ul><li>1 нет, нет, нет -> нет, нет, нет -> нет, нет, нет (00, 00, 00)</li>

66 <li>2 да, да, нет ->да, да, нет -> да, да, нет (11, 10, 10)</li>

67 <li>3 нет, да, да -> нет, да, да -> нет, да, да (01, 11, 01)</li>

68 <li>4 да, нет, да -> да, нет, да -> да, нет, да (10, 01, 11)</li>

69 </ul>При трех параметрах, каждый из которых имеет 3 значения, количество вариантов полного перебора - 27 (три в третьей) Применив pairwise, количество тест-кейсов сведётся к 9.

70 <h3>Таблица принятия решений</h3>

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

72 Это взаимосвязь между множеством условий и действий.

73 Таблица принятия решений содержит следующие элементы:

74 <ul><li>Условия - список возможных условий</li>

75 <li>Варианты - комбинация из выполнения и/или невыполнения условий этого списка</li>

76 <li>Действия - список возможных действий (вариантов исхода)</li>

77 </ul>Например, кредит выдаётся людям, удовлетворяющим трём условиям:

78 <ul><li>Возраст: 18-60 лет</li>

79 <li>Гражданство: Россия</li>

80 <li>Стаж работы: более 5 лет ИЛИ средняя месячная зарплата за год больше 100 тысяч рублей</li>

81 </ul><h3>Диаграмма состояний и переходов</h3>

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

83 Диаграммы состояний и переходов показывают только действительные переходы и исключают недействительные переходы.

84 Состояние А--переход-->Состояние Б

85 <h3>Тестирование вариантов использования</h3>

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

87 Вариант использования или юз-кейс - это описание конкретного использования системы субъектом или пользователем

88 Юз-кейсы содержат следующие сведения:

89 <ul><li>Кто использует сайт или приложение</li>

90 <li>Что пользователь хочет сделать</li>

91 <li>Какие шаги делает пользователь, чтобы совершить определенное действие</li>

92 <li>Как сайт или приложение реагируют на действия пользователя</li>

93 </ul><h3>Доменное тестирование</h3>

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

95 Доменное тестирование применяется для сокращения количества проводимых тестов без потери качества тестирования.

96 Очень часто классы эквивалентности, относящиеся к позитивным проверкам, можно проверять совместно.

97 Возьмем для примера такие требования:

98 <ul><li>Размер файла: до 200 МБ</li>

99 <li>Имя файла: от 5 до 24 символов, только латиница</li>

100 <li>Форматы файлов: только изображения</li>

101 </ul>В этом случае нужны такие проверки:

102 <ol><li>Загрузить файл менее 200 МБ</li>

103 <li>Загрузить файл с именем hexlet</li>

104 <li>Загрузить файл с расширением .jpg</li>

105 </ol>Можно заменить одной проверкой:

106 <ol><li>Загрузить файл менее 200 МБ, с именем hexlet.jpg</li>

107 </ol>Обратите внимание, что с негативными проверками так делать нельзя. При этом некоторые негативные проверки также можно исключать за счет несовместимости значений двух параметров.

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

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