Теперь, когда вы узнали про требования, базис теории и терминологию тестирования программного обеспечения, пришло время заняться тест-планами. В тестпланах содержится полный план тестирования тестируемой системы. Затем они выполняются, т. е. человек или автоматизированный инструмент тестирования проходит все шаги тест-плана, и его результаты сравниваются с тем, что получено на самом деле. Иными словами, мы будем проверять соответствие ожидаемого поведения системы (то, что мы написали в нашем тест-плане) тому поведению, которое мы наблюдаем (то, что на самом деле выполняет система).
Тест-план по своей сути является просто набором тест-кейсов. Тест-кейсы — это отдельные тесты, которые составляют тест-план. Давайте предположим, что вы создаете тест-план для тестирования нового приложения, которое говорит вам, является ли ваш кофе слишком горячим, чтобы его пить. Маркетологи нашего гипотетического приложения любят холодный кофе и решили не создавать никакой функционал, сообщающий о том, что температура кофе слишком низкая. Имеются два требования:
FUN-COFFEE-TOO-HOT — если измеренная температура кофе составляет 80 °C или выше, на экране приложения должно отображаться сообщение "СЛИШКОМ ГОРЯЧО";
FUN-COFFEE-JUST-RIGHT — если измеренная температура кофе составляет меньше 80 °C, на экране приложения должно отображаться сообщение "САМОЕ ТО".
Как мы может разработать тест-план для нашего приложения по измерению температуры кофе? Есть одно входное значение — измеренная температура кофе — и два возможных выходных, одно из набора ["СЛИШКОМ ГОРЯЧО", "САМОЕ ТО"]. Мы проигнорируем, что большинство людей посчитают, что кофе температуры 7 °C далеко не "САМОЕ ТО".
Единственное входное значение и одно из двух возможных выходных значений являются простым случаем разбиения класса эквивалентности, поэтому давайте разобьем эти классы эквивалентности:
JUST-RIGHT — [–INF, –INF + 1, ..., 79, 80] → "САМОЕ ТО";
TOO-HOT — [81, 82, ..., INF– 1, INF] → "СЛИШКОМ ГОРЯЧО".
Нашими граничными значениями являются 80 и 81, т. к. они отмечают разделение между двумя классами эквивалентности. Давайте также использовать два внутренних значения: 57 °C для класса "САМОЕ ТО" и 93 °C для класса "СЛИШКОМ ГОРЯЧО". Для этого конкретного примера тест-плана мы проигнорируем неявные граничные значения бесконечности и отрицательной бесконечности (или, в представлении системы, MAXINT и MININT).
Используя эти значения и общее представление, что мы хотим протестировать, мы можем начать создавать тест-кейсы. Хотя в разных инструментах и компаниях применяют различные шаблоны для ввода тест-кейсов, существует относительный стандарт, который может быть использован или модифицирован для большинства проектов:
1. Идентификатор, такой как "16", "DB-7" или "DATABASE-DROP-TEST", который однозначно идентифицирует тест-кейс.
2. Тест-кейс — описание тест-кейса и определение, что он тестирует.
3. Предусловия — любые предусловия для состояния системы или мира перед началом теста.
4. Входные значения — любые значения, напрямую подаваемые на вход в тесте.
5. Шаги исполнения — фактические шаги теста, которые должны быть выполнены тестировщиком.
6. Выходные значения — любые значения, полученные на выходе теста.
7. Постусловия — любые постусловия состояния системы или мира, которые должны быть истинны после выполнения теста.
Не беспокойтесь, если у вас возникли какие-либо вопросы по поводу этих определений. В дальнейшем мы рассмотрим их более глубоко и приведем примеры.
