КонтролепригодностьКонтролепригодность (testability) программного продукта выражает его способность к демонстрации неисправностей путем тестирования (как правило, контрольного прогона). По меньшей мере 40% стоимости разработки качественно спроектированных систем связано с тестированием. Следовательно, попытки программных архитекторов снизить эту стоимость не лишены смысла. В частности, контролепригодность основывается на предположении о том, что, если у программного продукта есть хотя бы одна неисправность, она проявится во время следующего контрольного прогона. Рассчитать такую вероятность весьма сложно, поэтому, добравшись до количественной меры реакции, мы приведем другие единицы измерения. Для надежного тестирования системы требуется возможность: 1) контроля внутреннего состояния и входных данных каждого из ее компонентов и 2) наблюдения за ее выходными данными. Довольно часто для этих целей используются специализированные тестовые программы (test harness), проводящие испытания тестируемого программного обеспечения. К примеру, для данных, записанных посредством нескольких интерфейсов, может потребоваться проверить возможность считывания, а для двигателя — целый отсек. Тестирование — заключительная операция ряда этапов жизненного цикла продуктов — проводится силами ряда разработчиков, тестировщиков, верификаторов и пользователей. Тестированию, в зависимости от ситуации, подвергаются участки кода, проектное решение или даже вся система. Количественная мера реакции в случае с контролепригодностью зависит от того, насколько эффективно тесты позволяют обнаруживать неисправности и как долго должно проводиться тестирование для того, чтобы достичь желаемого покрытия. Общие сценарии контролепригодности Пример сценария контролепригодности, а конкретнее тестирования отдельного блока, представлен на рис. 4.7. «Тестировщик блоков проводит тестирование готового компонента системы с интерфейсом, обеспечивающим контроль поведения и наблюдаемость выходных данных; 85-процентное покрытие путей достигается за три часа».
♦ Источник стимула. Тестирование может проводиться тестировщиком бло-ков, сборки или системы, а также клиентом. Проверка проектного решения иногда доверяется сторонним разработчикам. В нашем случае тестирование проводится тестировщиком. ♦ Стимул. Стимулом к тестированию выступает завершение одного из этапов процесса разработки — например, анализа или проектирования, кодирования класса, окончательной сборки подсистемы или даже разработки системы в целом. В нашем примере тестирование проводится после завершения работы над блоком кода. ♦ Артефакт. Артефактом может быть проектное решение, участок кода или вся система. В нашем примере тестируется блок кода. ♦ Условия. Тестирование может проводиться в периоды проектирования, раз-работки, компиляции или размещения. В примере на рис. 4.7 тест проводится во время разработки. ♦ Реакция. Поскольку контролепригодность тесно связана с наблюдаемостью и контролируемостью, реакция, в идеале, должна предусматривать возможности контроля над системой с целью проведения предполагаемых тестов и наблюдения реакций на каждый из них. В нашем примере и то и другое возможно. ♦ Количественная мера реакции. В качестве единиц измерения используются такие показатели, как процент исполнения исполняемых операторов, длина наибольшей цепочки зависимостей (дает представление о сложности тестирования) и вероятность обнаружения дополнительных неисправностей. На рис. 4.7 приводится процент покрытия исполняемых операторов. Варианты составления общего сценария контролепригодности приводятся в табл. 4.5.
|
