Теперь, когда у нас есть список требований и тест-план для их тестирования, что еще остается? Конечно, можно отправиться домой и насладиться любимым напитком после того, как целый день маялся в шахтах данных. Но есть кое-что еще, что можно обсудить. Мы неформально разработали тесты, которые, как мы полагаем, удовлетворяют требованиям, но мы можем перепроверить, что наши требования и тест-план синхронизированы, путем создания матрицы трассируемости.
Матрица трассируемости является простым способом определить, какие требования совпадают с тест-планами, и отобразить это на понятной диаграмме. Она состоит из списка требований (обычно просто идентификаторов требований) и списка номеров тест-кейсов, которые соответствуют этим требованиям (т. е. тех, что тестируют конкретные аспекты данного требования).
В качестве примера вернемся к спецификации требований для приложения по измерению температуры кофе. Вы обратите внимание, что список требований немного изменился — и это нормально при разработке программ!
FUN-COFFEE-TOO-HOT. Если измеренная температура кофе составляет 80 °C и выше, то приложение должно отображать на дисплее сообщение "СЛИШКОМ ГОРЯЧО".
FUN-COFFEE-JUST-RIGHT. Если измеренная температура кофе меньше 80 °C, но больше 55 °C то приложение должно отображать на дисплее сообщение "САМОЕ ТО".
FUN-COFFEE-TOO-COLD. Если измеренная температура кофе составляет 55 °C и меньше, то приложение должно отображать на дисплее сообщение "СЛИШКОМ ХОЛОДНО".
FUN-TEA-ERROR. Если жидкостью, температуру которой измеряют, является чай, то приложение должно отображать на дисплее сообщение "ИЗВИНИТЕ, ЭТО ПРИЛОЖЕНИЕ НЕ ПОДДЕРЖИВАЕТ РАБОТУ С ЧАЕМ".
Мы запишем идентификаторы требований и оставим пространство для идентификаторов тест-планов:
FUN-COFFEE-TOO-HOT:
FUN-COFFEE-JUST-RIGHT:
FUN-COFFEE-TOO-COLD:
FUN-TEA-ERROR:
Теперь давайте посмотрим на завершенный тест-план и определим, какие тесткейсы соответствуют тестированию заданных требований. Для каждого подходящего тест-кейса запишем его идентификатор рядом с требованием:
FUN-COFFEE-TOO-HOT: 1, 2
FUN-COFFEE-JUST-RIGHT: 3, 4, 5
FUN-COFFEE-TOO-COLD: 6, 7
FUN-TEA-ERROR: 8
Легко увидеть, что для каждого требования есть по крайней мере один покрывающий его тест. Если бы было другое требование, скажем:
FUN-COFFEE-FROZEN. Если кофе находится в твердом, а не жидком состоянии, то приложение должно отображать на дисплее сообщение "ЭТОТ КОФЕ МОЖЕТ БЫТЬ ТОЛЬКО СЪЕДЕН, НО НЕ ВЫПИТ",
и мы попытались бы создать матрицу трассируемости, то было бы легко увидеть, что для проверки этого требования тестов нет:
FUN-COFFEE-TOO-HOT: 1, 2
FUN-COFFEE-JUST-RIGHT: 3, 4, 5
FUN-COFFEE-TOO-COLD: 6, 7
FUN-TEA-ERROR: 8
FUN-COFFEE-TOO-FROZEN:
Точно так же матрицы трассируемости могут позволить нам определить, есть ли у нас "бесполезные" тесты, которые не тестируют ни одного из требований. Например, представим, что мы создали "Тест-кейс 9":
ИДЕНТИФИКАТОР: 9
ТЕСТ-КЕЙС: определить, правильно ли приложение показывает температуру пуделя.
ПРЕДУСЛОВИЕ: пудель живой и в добром здравии, с нормальной для пуделя температурой 38 °С.
ВХОДНЫЕ ДАННЫЕ: Нет.
ШАГИ ВЫПОЛНЕНИЯ: навести датчик на пуделя на пять секунд. Прочитать значение с дисплея.
ВЫХОДНЫЕ ЗНАЧЕНИЯ: Нет.
ПОСТУСЛОВИЯ: на экране демонстрируется сообщение "С пуделем всё в порядке".
В нашей матрице трассируемости снова появляется пробел, но на этот раз на стороне требований. Тест-кейс 9 не соответствует ни одному из требований, и это будет ненужный тест:
FUN-COFFEE-TOO-HOT: 1, 2
FUN-COFFEE-JUST-RIGHT: 3, 4, 5
FUN-COFFEE-TOO-COLD: 6, 7
FUN-TEA-ERROR: 8
???: 9
Время от времени в "реальном мире" могут найтись тесты, которые не подходят к какому-либо определенному требованию. Например, если системный инженер не создал требование по надежности, тест-план все равно может включать тест, позволяющий убедиться, что система работает, даже если она запущена целый день. Это определенно не наилучшая практика, но такое иногда встречается. Если это произошло, лучшим выходом станет создание требования по надежности, которое можно протестировать.
Конечно, матрица трассируемости дает очень простой обзор тестового покрытия. Тот факт, что каждое требование было протестировано, не означает, что каждое требование было протестировано тщательно. Например, что если у системы есть проблемы с чрезвычайно горячим кофе? Наибольшая температура, которую мы проверяли, составляла 93 °С, но проблема может возникнуть при температуре 94 °С. Также в матрице трассируемости нет проверки, что наши тесты хорошие. Если мы тестировали, соответствует ли система требованию FUN-COFFEE-TOOHOT путем помещения системы в ледяную воду, и при этом утверждаем, что тесткейс соответствует требованию FUN-COFFEE-TOO-HOT, то об этом никак нельзя сказать по матрице трассируемости.
Матрицы трассируемости являются хорошим способом перепроверить вашу работу и сообщить другим людям за пределами вашей команды, насколько хорошо покрыта система с точки зрения тестирования. Если время поджимает, вы или ваш менеджер можете решить, что определенные части или функции системы более важны для тестирования, чем другие, и поэтому вы можете даже не писать тесты для этих менее важных частей. Опять-таки, это не наилучшая практика, но, по крайней мере, вы можете использовать матрицу трассируемости для отслеживания пробелов в вашем тестовом покрытии.
Потребителям и менеджменту, особенно в таких зарегулированных отраслях, как оборона и медицина, также могут потребоваться матрицы трассируемости как способ доказать, что системы были протестированы по крайней мере на базовом уровне.