0 added
0 removed
Original
2026-01-01
Modified
2026-02-26
1
<p>Полный доступ к материалам</p>
1
<p>Полный доступ к материалам</p>
2
<h2>Как составлять тест-кейсы</h2>
2
<h2>Как составлять тест-кейсы</h2>
3
<p>Чтобы составить понятный тест-кейс, необходимо придерживаться некоторых принципов. Их можно найти довольно много, но мы приведем здесь несколько основных, о которых чаще всего забывают:</p>
3
<p>Чтобы составить понятный тест-кейс, необходимо придерживаться некоторых принципов. Их можно найти довольно много, но мы приведем здесь несколько основных, о которых чаще всего забывают:</p>
4
<ol><li><p>Тест-кейсы должны быть атомарными. Другими словами, один кейс должен проверять только одно конкретное требование, не включая в себя несколько действий или проверок. Если кейс включает в себя несколько шагов, лучше разбить его на несколько</p>
4
<ol><li><p>Тест-кейсы должны быть атомарными. Другими словами, один кейс должен проверять только одно конкретное требование, не включая в себя несколько действий или проверок. Если кейс включает в себя несколько шагов, лучше разбить его на несколько</p>
5
</li>
5
</li>
6
<li><p>Тест-кейсы не должны зависеть друг от друга. Лучше проверять функциональность так, чтобы проверки разных функций шли независимо друг от друга, не соединяясь в цепочку</p>
6
<li><p>Тест-кейсы не должны зависеть друг от друга. Лучше проверять функциональность так, чтобы проверки разных функций шли независимо друг от друга, не соединяясь в цепочку</p>
7
</li>
7
</li>
8
<li><p>Тест-кейсы должны быть легкими в поддержке. При изменении функциональности мы не должны тратить слишком много времени на обновление тест-кейсов. Нужно писать так, чтобы нам не пришлось все переписывать с нуля</p>
8
<li><p>Тест-кейсы должны быть легкими в поддержке. При изменении функциональности мы не должны тратить слишком много времени на обновление тест-кейсов. Нужно писать так, чтобы нам не пришлось все переписывать с нуля</p>
9
</li>
9
</li>
10
<li><p>Тест-кейсы должны быть уникальными. Они должны проверять уникальные аспекты функциональности приложения и отличаться друг от друга. Не стоит проверять одно и то же - это только увеличит время и затраты на тестирование</p>
10
<li><p>Тест-кейсы должны быть уникальными. Они должны проверять уникальные аспекты функциональности приложения и отличаться друг от друга. Не стоит проверять одно и то же - это только увеличит время и затраты на тестирование</p>
11
</li>
11
</li>
12
<li><p>Тест-кейсы должны включать в себя всю необходимую информацию. Например, если мы проверяем авторизацию, нам нужно заранее найти логин и пароль пользователя, зарегистрированного в системе. Иначе нам придется постоянно отвлекаться от тестирования, что увеличит когнитивную нагрузку и время работы</p>
12
<li><p>Тест-кейсы должны включать в себя всю необходимую информацию. Например, если мы проверяем авторизацию, нам нужно заранее найти логин и пароль пользователя, зарегистрированного в системе. Иначе нам придется постоянно отвлекаться от тестирования, что увеличит когнитивную нагрузку и время работы</p>
13
</li>
13
</li>
14
<li><p>В тест-кейсе не должно быть лишних деталей, которые не относятся к цели проверки. Например, в кейсе для проверки авторизации не нужно описывать результат отображения аватарки и цвет кнопки "Авторизоваться". Это только затруднит использование кейса и увеличит затраты на тестирование</p>
14
<li><p>В тест-кейсе не должно быть лишних деталей, которые не относятся к цели проверки. Например, в кейсе для проверки авторизации не нужно описывать результат отображения аватарки и цвет кнопки "Авторизоваться". Это только затруднит использование кейса и увеличит затраты на тестирование</p>
15
</li>
15
</li>
16
</ol><h2>Ошибки при составлении тест-кейса</h2>
16
</ol><h2>Ошибки при составлении тест-кейса</h2>
17
<p>Рассмотрим несколько распространенных ошибок в формулировке тест-кейса.</p>
17
<p>Рассмотрим несколько распространенных ошибок в формулировке тест-кейса.</p>
18
<ol><li><p>Неправильное название. Название должно четко описывать результат, к которому мы хотим прийти:</p>
18
<ol><li><p>Неправильное название. Название должно четко описывать результат, к которому мы хотим прийти:</p>
19
</li>
19
</li>
20
<li><p>Ветвление в шагах или ожидаемом результате. Если ваш кейс начинает ветвиться, лучше разделить его на два:</p>
20
<li><p>Ветвление в шагах или ожидаемом результате. Если ваш кейс начинает ветвиться, лучше разделить его на два:</p>
21
</li>
21
</li>
22
<li><p>Лишние детали. Не стоит включать дополнительную информацию, которая будет отвлекать от тестирования:</p>
22
<li><p>Лишние детали. Не стоит включать дополнительную информацию, которая будет отвлекать от тестирования:</p>
23
</li>
23
</li>
24
<li><p>Недостаток деталей. При этом не стоит использовать и слишком абстрактные формулировки - здесь нужен баланс. В тест-кейсе должны быть важные детали и пояснения:</p>
24
<li><p>Недостаток деталей. При этом не стоит использовать и слишком абстрактные формулировки - здесь нужен баланс. В тест-кейсе должны быть важные детали и пояснения:</p>
25
</li>
25
</li>
26
</ol><h2>Рекомендуемые программы</h2>
26
</ol><h2>Рекомендуемые программы</h2>