Cтраница 2
Важнейшим принципом комплексной отладки является последовательное сопряжение программных модулей начиная с наиболее простых по решаемым задачам и имеющих минимальные связи с другими программами. Для сокращения объема и уменьшения количества отладочных тестов целесообразно сопрягать программы в порядке увеличения информации, передаваемой при взаимодействии. В этом случае предшествующая по исполнению программа может являться источником значительной части данных для последующей, что сокращает объем подготовки необходимых тестов и имитаторов. [16]
Сказанное призвано проиллюстрировать трудность высококачественного проектирования тестов. Должно стать ясным, что разработка тестов - творческий процесс, требующий не только особого искусства, но и в некотором смысле разрушительного склада ума. Имеется, однако, несколько простых правил, которыми можно пользоваться, чтобы составить разумный набор тестов. Они рекомендуют сначала рассмотреть модуль как черный ящик ( левая граница спектра стратегий), а затем исследовать его внутреннее устройство для подготовки дополнительных тестов. [17]
При испытаниях КП на надежность функционирования необходимо разделять причины отказов и отказовых ситуаций на обусловленные ненадежностью аппаратуры и ошибками в программах. Устойчивые отказы аппаратуры селектируются достаточно просто. Однако кратковременные сбои в аппаратуре и последствия ошибок в программе требуют тщательного анализа для выделения и диагностики их источника. Эта программа автоматически регистрирует наличие отказа и отка-зовой ситуации, а также условия их возникновения, осуществляет первичный анализ и классификацию возможных источников аномалий функционирования. Для диагностики и локализации причин отказа обычно требуется дополнительное стохастическое и детерминированное тестирование, которое позволяет либо выделить первичную ошибку в программе, либо отнести источник отказа к сбою в аппаратуре. При дополнительном тестировании одна из задач заключается в подготовке стохастических тестов, способных значительно повысить частость проявления отказов вследствие ошибок. Это позволяет в конце концов зафиксировать значения тестовых данных, при которых происходит отказ, и детерминированным тестированием локализовать ошибку. [18]
Невозможно тестировать свою собственную программу. Ни один программист не должен пытаться тестировать свою собственную программу. Это относится ко всем формам тестирования, как к тестированию системы, так и к тестированию внешних функций и даже отдельных модулей. Тестирование должно быть в высшей степени разрушительным процессом, но имеются глубокие психологические причины, по которым программист не может относиться к своей собственной программе как разрушитель. Дополнительное давление ( например, жесткий график) на отдельного программиста или весь коллектив разработчиков проекта часто мешает программисту или всему коллективу выполнить адекватное тестирование. Более того, если модуль содержит дефекты вследствие каких-то ошибок перевода, довольно высока вероятность того, что программист допустит ту же ошибку перевода ( например, неправильно интерпретирует спецификации) и при подготовке тестов. [19]