Тестирование частей против тестирования целого

Любая система разрабатывается по частям — как набор процессов или модулей. Можно ее так и тестировать — сначала отдельные части, а потом уже их взаимодействие. Такая стратегия называется восходящей (bottom-up).

Выяснив, что отдельные элементы программы в порядке, специалист приступает к тестированию их совместной работы. И тут может оказаться, что вместе они работать отказываются. Например, если программист слу­чайно поменяет местами параметры вызываемой функции, при выполне­нии вызова произойдет ошибка. И выявлена она будет только при проверке совместной работы обеих функций — вызывающей и вызываемой.

Тестирование совместной работы программных модулей называют интеграционным. В ходе такого тестирования модули сначала объединяются в пары, потом в большие блоки, пока наконец все модули не будут объединены в единую систему.

Восходящее тестирование — это прекрасный способ локализации оши­бок. Если ошибка обнаружена при тестировании единственного модуля, то очевидно, что она содержится именно в нем — для поиска ее источника не нужно анализировать код всей системы. А если ошибка проявляется при совместной работе двух предварительно протестированных модулей, значит, дело в их интерфейсе. Еще одним преимуществом восходящего тестирования является то, что выполняющий его программист концентрируется на оченьузкой области (единственном модуле, передаче данных между парой модулей и т.п.). Благодаря этому тестирование проводится более тщательно и с большей вероятностью выявляет ошибки.

Главным недостатком восходящего тестирования является необходимость написания специального кода-оболочки, вызывающего тестируемый модуль. Если он, в свою очередь, вызывает другой модуль, для него нужно написать заглушку. Заглушка — это имитация вызываемой функции, возвращающая те же данные, но ничего больше не делающая.

Понятно, что написание оболочек и заглушек замедляет работу, а для конечного продукта они абсолютно бесполезны. Но написанные однажды, этиэлементы могут использоваться повторно при каждом изменении про­граммы. Хороший набор оболочек и заглушек — это очень эффективный инструмент тестирования.

В противоположность восходящему тестированию, стратегия целостного тестирования предполагает, что до полной интеграции системы ее отдельныемодули не проходят особо тщательного тестирования.

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

· Очень трудно выявить источник ошибки. Это главная проблема. ь; Поскольку ни один из модулей не проверен как следует, в большин­стве из них есть ошибки. Получается, что вопрос не столько в том, в каком модуле произошла обнаруженная ошибка, сколько в том, какая из ошибок во всех вовлеченных в процесс модулях привела к полученному результату. И когда накладываются ошибки несколь­ких модулей, ситуацию может быть гораздо труднее локализовать и повторить.

Кроме того, ошибка в одном из модулей может блокировать тестирование другого. Как протестировать функцию, если вызывающий ее модуль не работает? Если не написать для этой функции програм­му-оболочку, придется ждать отладки модуля, а это может затянуться надолго.

· Трудно организовать исправление ошибок. Если программу пишут несколько программистов (а именно так и бывает в больших систе­мах), и при этом неизвестно, в каком модуле ошибка, кто же будет ее искать и исправлять. Один программист будет указывать на другого, тот, выяснив, что его код ни при чем, снова обратится к первому, а в результате будет сильно страдать скорость разработки.

· Процесс тестирования плохо автоматизирован. То, что на первый взгляд кажется преимуществом целостного тестирования — отсут­ствие необходимости писать оболочки и заглушки, — на самом деле оборачивается его недостатком. В процессе разработки программа ежедневно меняется, и ее приходится тестировать снова и снова. А оболочки и заглушки помогают автоматизировать этот однообразный труд.

Поскольку большинство руководителей проектов отнюдь не глупы, когда кто-нибудь из них выбирает целостное тестирование, мы предпола­гаем, что в своем конкретном случае он видит такие преимущества этого подхода, о которых в разговоре с нами просто не упоминает. Есть и такие руководители, которые вообще не слишком заботятся об эффективности тестирования. Главное для них — как можно скорее отрапортовать началь­ству о завершении работ, даже если на самом деле ничего не работает. Если после этого с проектом возникнут проблемы, они будут обвинять законы Мэрфи, тестировщиков, невезение, но только не самих себя — собствен­ную часть работы они будут считать выполненной успешно и в срок. Мы не понимаем такой позиции, хотя каждый из нас был в свое время руко­водителем проекта, а также встречался с руководителями, действующими подобным образом.