Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Много лет назад я выступил с миссией.

Покрытие, казалось, было важным словом в тестировании, но я начал осознавать, что думал о нем как-то туманно, попросту. Я чувствовал, что я в этом не одинок.

Я хотел знать, что люди имеют в виду, говоря о покрытии. Я хотел знать, что я имею в виду, говоря о покрытии.

В материалах курса Rapid Software Testing Джеймс Бах описывал покрытие как "пропорцию протестированного продукта". Это не имело для меня смысла.

Можем ли мы думать о продукте в таких терминах? Продукт может быть множеством вещей для множества людей. Мы можем смотреть на продукт, как на набор байтов на жестком диске, но это не слишком-то полезно. Продукт – это набор файлов и модулей, содержащих код, создающий объекты, данные и функции. Продукт взаимодействует с железом и другим ПО – как созданным нами, так и созданным другими людьми. Продукт предоставляет (предположительно ценные) функции и характеристики людям. У продукта есть интерфейсы, через которые люди и программы могут взаимодействовать с ним, передавать ему данные, получить доступ под капот, получить результаты.

ПО – это не нечто статичное и осязаемое; это набор взаимоотношений. Как будет выглядеть 100% продукта, набора взаимоотношений? Это важный вопрос, потому что если мы не знаем, как выглядит 100%, то идея "пропорции" не выдерживает разумной критики.

Мы с Джеймсом поспорили об этом.

Я обратился к книгам по тестированию. Если покрытие вообще упоминалось, то большая часть книг вызывала вопрос, что это вообще такое. Книги, которые описывали покрытие, говорили о нем в терминах покрытия кода – строк кода, веток, путей, условий… "Testing Computer Software", например, цитировала Бориса Бейзера, говоря, что "тестирование до "полного" покрытия найдет в лучшем случае половину багов". Эээ? Как это может иметь смысл?

В итоге в Индии я нашел копию книги Бейзера Software Testing Techniques, содержащую интригующую подсказку в каталоге: "любая метрика завершения с учетом критерия выбора тестов". Хоть книга и говорила о покрытии кода, она также говорила о путях в терминах функциональных потоков в приложении.

Джеймс полемизировал, что "любая метрика завершения с учетом критерия выбора тестов" – это тоже не слишком полезно. "Критерий выбора тестов" всегда основан на некой модели продукта, сказал он.

Модель – это идея, деятельность или объект (например, идея в вашей голове, диаграмма, список слов, таблица, человек, игрушка, уравнение, демонстрация или программа), представляющие – буквально, представляющие – нечто сложное в более простых терминах. Давая представление о чем-то более простом, хорошая модель дает нам ступеньку для понимания более сложного.

Способов моделирования ПО столько же, сколько способов представить его, его части, или то, с чем он взаимодействует. К примеру, мы можем смоделировать продукт, представив его компоненты на диаграмме. Мы можем смоделировать продукт, описав его в спецификации – которая, в свою очередь, будет моделью требований к продукту. Мы можем представить информацию, хранящуюся в продукте, в форме схемы базы данных.

Мы можем моделировать продукт в плане его интерфейсов – API, командных строк, GUI, сетевых протоколов, портов печати. Мы можем представить взаимодействия людей с продуктом через сетевые графики, юзер-стори, обучающие материалы или списки задач. И, конечно, мы всегда моделируем продукт неявно в форме набора идей в нашей голове. Эти идеи можно представить любым количеством способов.

Код – это не продукт. Продукт – это набор взаимоотношений между ПО, железом, людьми, их нуждами и желаниями, индивидуально и группами. Код продукта – сам по себе модель продукта. Покрытие кода – это один из способов описать, насколько мы покрыли продукт тестированием.

И где-то в ходе этих бесконечных обсуждений с Джеймсом для меня забрезжил свет.

В терминологии Rapid Software Testing, говоря о покрытии в целом, мы имеем в виду вот что:

Покрытие – это то, насколько тщательно мы исследовали продукт, согласно определенной модели.

Когда мы говорим о покрытии, то речь идет об определенной модели.

• Функциональное покрытие: насколько тщательно мы изучили продукт согласно определенной модели функций продукта.
• Покрытие требований: насколько тщательно мы изучили продукт согласно определенной модели требований
• Покрытие производительности: насколько тщательно мы изучили продукт согласно определенной модели производительности.
• Покрытие рисков: насколько тщательно мы изучили продукт согласно определенной модели рисков.
• Покрытие кода: насколько тщательно мы изучили продукт согласно определенной модели кода.

Должно быть заметно, что покрытие кода отличается от покрытия рисков; покрытие кода не покрывает все возможные риски, которым подвергается продукт. Должно быть также ясно, что покрытие рисков (насколько тщательно мы изучили продукт согласно определенной модели рисков) необязательно покроет весь код.

И это подводит нас к следующей статье: что имеется в виду под глубоким и поверхностным тестированием.

Обсудить в форуме