Cтраница 3
При тестировании всегда встречается еще один интересный парадокс: с одной стороны, хочется найти не слишком много ошибок и уложиться в график, а с другой стороны, понятно, что цель тестирования - найти как можно больше ошибок. Это еще одно подтверждение двух обязательных принципов, уже обсуждавшихся выше: критерии завершения должны формулироваться в негативном духе ( например, фаза тестирования не закончена, пока не обнаружено заранее установленное число ошибок) и, кроме того, тестирование должно выполняться независимой организацией, которая не испытывает давления календарных планов организации-разработчика. [31]
Краузе, Фассл и Вызотски ( 1981) показали, что зависимости, установленные для одномерной последовательности суждений, справедливы также для суждений, описывающих отношения между объектами в трехмерном пространстве. В фазе тестирования нужно было ответить на вопросы о пространственном положении объектов, причем в исходных предложениях соответствующие пространственные взаимоотношения в явном виде не были указаны. Описанные выше зависимости обнаружились и в этих условиях. [32]
Модель корреляции, предложенная Хелдом, для эфферентных и зрительных ( повторно вызываемых вследствие движения глаз) сигналов, поступающих с глаза. Компаратор представляет собой фазу тестирования в системе процесса опережения. [33]
К настоящему моменту система построена, а ее программные единицы протестированы. Теперь разработчики могут передать ее группе тестирования. Если процесс CADM соблюдался на должном уровне, фаза тестирования должна пройти достаточно гладко. [34]
Книга разделена на четыре части. В части II ( главы 3 - 21) подробно рассматривается каждая фаза методологии, а также инструментальные средства Oracle Designer и утилиты, которые поддерживают каждую фазу. Каждой фазе посвящена одна или две главы, хотя описание фаз тестирования, реализации и сопровождения объединено в одной главе. Материал по Oracle Designer вплетен в ткань обсуждения методологии и излагается по завершении рассмотрения процесса инсталляции. После главы о каждой фазе следует глава о поддержке в Oracle Designer действий на этой фазе. [35]
ПО является процедурой снизу вверх. Тестируются первые модули кода, затем модули интегрируются в процессы, которые тестируются, и, наконец, процессы интегрируются в результирующую систему. Методы, описанные здесь, в наибольшей степени применимы к фазе тестирования и интеграции системы при разработке снизу вверх. Они могут быть применимы с некоторой модификацией к другим фазам тестирования. [36]
Во все экранные модули должна быть встроена хорошая интерактивная справочная система. Как правило, создание справки не считается первостепенным вопросом. О ней даже не задумываются до тех пор, пока система не вступит в фазу тестирования. Часто только на этой фазе недостаток справочной системы начинает ощущаться. Внесение справочной информации в систему на фазе тестирования очень дорого. Добавление справочных сведений к системе в ходе ее разработки значительно дешевле. [37]
Если программа тщательно проверена, то, прежде чем она поступит в производственную эксплуатацию, ее необходимо снабдить документацией. Документация должна предоставлять полную информацию об обрабатываемых данных и инструкцию оператору о том, как обращаться с программой при ее работе. Она также должна содержать описание логики программы, для того чтобы предоставить возможность внесения в нее изменений либо в связи с изменениями в постановке задачи, либо из-за обнаружения скрытых ошибок, не выявленных на фазе тестирования, а проявившихся лишь на более поздней стадии. В табл. 8Л приведены основные этапы, необходимые при производстве программ. [38]
На всех фазах разработки системы при использовании репозитория и его прикладных систем требуется выполнять административные задачи. Кроме того, нужно манипулировать данными репозитория и запрашивать их надлежащим образом. В главе 20 обсуждается, какую роль играет Oracle Designer на фазах тестирования, внедрения и сопровождения. В частях III и IV описываются различные операции Oracle Designer, выполняемые на этих фазах. [39]
Мы представили жизненный цикл CADM последовательно - от одной фазы к другой. Однако мы сознаем, что разработка системы не является простым линейным процессом. Границы проекта могут изменяться в любое время. Новые требования могут поступить от пользователя в любой точке процесса, даже на фазе тестирования. Кроме того, могут потерпеть неудачу проверки качества системы. Действительность всегда вносит свои коррективы в наш чисто теоретический процесс. Поэтому в главе 21 рассматриваются действия в непредвиденных ситуациях. [40]
Одной из важнейших характеристик книги проекта является наличие в ней достаточной информации для поддержки системы тестирования. Другими словами, тестировщик сможет выяснить, соответствует ли данное приложение предъявляемым ему системным требованиям. Одна из причин составления плана тестирования заключается в том, что он заставляет проектировщиков проанализировать, достаточна ли книга проекта для поддержки фазы тестирования. Всестороннее обсуждение этой фазы отложим до главы 19, но план тестирования следует разработать именно в конце фазы проектирования. [41]
Выходная информация программы 1NTSUM передается программе эвристического поиска RULEGEN, которая играет в Meta-DENDRAL ту же роль, что и программа CONGEN в DENDRAL. Но в отличие от CONGEN, она формирует не гипотезы о структурах молекул, а более общие гипотетические правила расщепления, которые, например, могут предполагать и множественные разрывы связей в молекулах. Эти правила должны охватывать все случаи, представленные в обучающей выборке, сформированной программой INTSUM. После того как будет сформировано множество гипотетических правил, в дело вступает программа RULEMOD, на которую возложено выполнение последней фазы процесса, - фазы тестирования и модификации правил. [42]
Эти сотрудники выполняют схожие тесты на фазах построения и тестирования. Тем самым они подтверждают корректное и соответствующее запланированному функционирование приложения. На фазе построения выполняются тесты уровня программных единиц или уровня модулей, в которых центром внимания является каждый из модулей. А на фазе тестирования выполняются тесты уровня системы, в которых проверяются группы модулей и то, как модули взаимодействуют между собой. [43]
Во все экранные модули должна быть встроена хорошая интерактивная справочная система. Как правило, создание справки не считается первостепенным вопросом. О ней даже не задумываются до тех пор, пока система не вступит в фазу тестирования. Часто только на этой фазе недостаток справочной системы начинает ощущаться. Внесение справочной информации в систему на фазе тестирования очень дорого. Добавление справочных сведений к системе в ходе ее разработки значительно дешевле. [44]
На фазе тестирования важно также проверить, удовлетворяются ли на самом деле требования, выполненные с помощью таблиц. Для подобных требований нужно создать еще один ассоциативный тип, называемый Requirements to Tables, который будет следить за связью этих двух элементов. Он создается на фазе предварительного проектирования и заполняется информацией на фазе проектирования. Поэтому для данных объектов нужно включить примечания в требования, предъявляемые к таблице. На фазе тестирования проверяется, надлежащим ли образом удовлетворены требования с помощью таблиц. [45]