Выполнение примера 2.

1. Позитивный тест: строка допустимых символов длиной от 3 до 20-ти символов. Тест: ABC, ABCDEFGHIJKLMNOPQRST, abc_12_def.

2. Негативный тест: строка короче трёх символов. Тест: AA, {пустая строка}.

3. Негативный тест: строка длиннее 20-ти символов. Тест: AAAAAAAAAAAAAAAAAAAAA (21 символ)

4. Негативный тест: строка длиной от трёх до 20-ти символов, содержащая недопустимые символы. Тест: Abcd#23456%@#&#%^#

ВЫВОД:

• Классы эквивалентности не всегда очевидны.

• Как правило, негативных тестов получается больше, чем позитивных.

• Принадлежность теста к позитивным или негативным зависит от требований.

Последовательность разработки и выполнения тестов: Простые позитивные. → Простые негативные. → Сложные позитивные. → Сложные негативные.

Простые тесты оперируют за один раз одним объектом. Пример простого теста:

1. Откройте файл «1.txt». Файл открыт.

2. Введите слово «Дом». Появляется слово «Дом.

3. Сохраните файл. Кнопка «Сохранить» теряет активность.

Преимущества простых тестов:

· Легко выполняются.

· Понятны новичкам.

· Упрощают диагностику ошибки.

· Делают наличие ошибки очевидным.

Пример сложного теста: в документе размером более 100 Мб создайте таблицу 100x100, в ячейку 50x50 вставьте картинку размером 30 Мб, применив к ней функцию «Авторасположение». Проверьте результат.

Преимущества сложных тестов:

· Больше шансов что-то сломать.

· Пользователи, как правило, используют сложные сценарии.

· Программисты сами редко проверяют такие варианты.

Следует постепенно повышать сложность тестов. Помимо классификации «простые – сложные», тесты классифицируют как «независимые – связанные»).

· Независимые тесты не ссылаются ни на какие другие.

· Связанные тесты явно или неявно ссылаются на другие (как правило, на предыдущий).

Промышленным стандартом являются независимые тесты. Преимущества независимых тестов:

1. Их легко и просто выполнять.

2. Такие тесты могут работать даже после краха приложения на других тестах.

3. Такие тесты можно группировать любым образом и выполнять в любом порядке.

Преимущества связанных тестов и связанных сценариев:

1. Имитируют работу реальных пользователей.

2. Удобны для интеграционного тестирования.

3. Удобны для разбиения на части тестов с большим количеством шагов.

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

Язык написания тестов:

1. Используйте активный залог: («open», «paste», «click»). В русском языке используйте безличную форму: «открыть» (вместо «откройте»).

2. Описывайте поведение системы: «появляется окно», «приложение закрывается».

3. Используйте простой технический стиль.

4. ОБЯЗАТЕЛЬНО указывайте ТОЧНЫЕ названия всех элементов приложения.

5. Не объясняйте базовые понятия работы с ОС.

И ещё пару слов о хороших тестах. Хороший тест:

а) обладает высокой вероятностью обнаружения ошибки (рис. 7.8)

Рисунок 7.8– Пример тестов с низкой и высокой вероятностью обнаружения ошибки

б) исследует соответствующую («ту, которую надо») область приложения (рис. 7.9)

Рисунок 7.9 – Пример теста, исследующего «не ту, которую надо» область приложения

в) не выполняет ненужных действий (рис. 7.10)

Рисунок 7.10– Пример теста, выполняющего ненужное действие

г) является не слишком простым, но и не слишком сложным (рис. 7.11)

Рисунок 7.11 – Пример не слишком простого, но и не слишком сложного теста

г) не является избыточным по отношению к другим тестам (рис. 7.12)

Рисунок 7.12– Пример теста, избыточного по отношению к другим тестам

г) делает обнаруженную ошибку очевидной (рис. 7.13)

Рисунок 7.13 – Пример теста, делающего обнаруженную ошибку очевидной

г) позволяет легко диагностировать ошибку (рис. 7.14)

Рисунок 7.14 – Пример теста, позволяющего легко диагностировать ошибку

Процесс разработки тестов:

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

2. Разбивайте приложение на отдельные части/модули.

3. Для каждой области/модуля пишите чек-лист.

4. Пишите вопросы, уточняйте детали, добавляйте «косметику», используйте copy-paste.

5. Получите рецензию коллег, разработчиков, заказчиков.

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

Тестовые сценарии. Тестовый сценарий, тест-сьют (test scenario, test-suite) – это набор тест-кейсов, собранных в группу (последовательность) для достижения некоторой цели. Общие рекомендации по оформлению тестовых сценариев:

· Пишите сценарий для отдельной части приложения.

· Пишите отдельно сценарии для Smoke и Critical Path тестов.

· Постепенно повышайте сложность тестов.

· Организуйте сценарий логично.

Рисунок 7.15 – К рекомендациям по оформлению тестовых сценариев