) Поставщики коммерческих СУБД также не располагают подобными средствами.

тестовые данные в самол1 начале никла разработки. Реакция соответствующих инстанций на запросы о предоставлении таких данных обычно запаздывает), и группы, занимающиеся разработкой, вынуждены создавать базу данных вручную. Эту по существу рутинную, трудоемкую и нудную работу можно было бы значительно сократить при наличии средства, позволяющего генерировать таблицы и массивы данных для целей стендовых испытаний. Такое вспомогательное средство долх(но формировать промежуточные значения Переменных, находящиеся между их предельными значениями, создавать особенности, на- пример, типа разрывов непрерывности, а также обеспечивать определенные сочетания значений данных. Оно должно также извлекать данные.из блоков других существующих баз данных и проводить их форматные преобразования. Применение указанного средства должно способствовать созданию мощного потока данных для моделирования наиболее критических с точки зрения рабочей нагрузки условий, а также обеспечивать возможность выдачи информации на магнитную ленту и перфокарты. Выгода использования такого средства состояла бы в высвобождении значительной части времени разработчиков, которое они могли бы уделить процедурам отладки и проверки программ до начала испытаний на уровне подсистем и системы в целом.

Компаратор базы данных. Одним из средств, которыми располагала группа испытаний Проекта 3 и которые оказались чрезвычайно эффективными, был компаратор базы данных. Это средство обеспечивало поэлементное сравнение базы данных в исходном состоянии и регистрацию всех случаев несовпадений после исполнения программ. Таким образом удавалось гарантировать, что изменения или перенастройка программ (например, использование отладочных программ для целей испытаний) не нарушат правильного функционирования всей системы программного обеспечения.

4.7.5. Выводы по результатам исследований Проекта 3

Естественный вывод, который можно сделать на основании вышеприведенного анализа данных по Проекту 3, состоит в том, что по возможности больший объем тестирования следует проводить до начала этапа формализованных испытаний на уровне подсистем и системы в целом. Согласно полученной оценке, 72,9% ошибок, потребовавших изменения программ, могли быть обнаружены путем тщательного тестирования программ с применением специальных средств. Однако при этом возникает ряд вопросов. Например, были ли запланированы в базовых проектах всесторонние испытания программ и если да, то были ли они проведены? Оказывается, что такие испытания были запланированы, хотя и не с той степенью детализации, которая предлагалась в предыдущих разделах. Кроме того, были предусмотрены также комплексные испытания подсистем. Однако ни один из видов испытаний не был выполнен в полном объеме, так как в рамках семимесячного срока этого невозможно было сделать до передачи программного обеспечения независимой группе, ответственной за аттестационные испытания. В реальных условиях напряженных графиков при нехватке времени страдают именно этапы, запланированные на конец цикла разработки, и поэтому просто не хватило времени на проведение всего объема испытаний на программном уровне.

Мох<ет возникнуть вопрос: предвиделась ли не-возмохчность проведения полного объема программных испытаний и если да, то какие были приняты меры? Ситуация в цикле разработки прояснилась довольно рано, о чем свидетельствуют еженедельные отчеты разработчиков о ходе проектирования, представляемые руководству, а также документация и регистрационные книги отдела, ответственного за компоновку систем программного обеспечения. Для исправления ситуации предпринималось многое, но .получению программного изделия приемлемого качества в назначенный срок больше, чем любая другая.

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

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

Следующим напрашивается вопрос: в какой степени бездефектным оказалось программное обеспечение в условиях его промышленной эксплуатации? Если использовать для вычисления оценки упрощенное соотношение между объемом программного обеспечения и числом ошибок, требующих изменения программ, то можно сказать, что в работающем программном обеспечении при его периодическом функционировании примерно в течение одного года было обнарзжено 1,7 ошибки на 1000 обобщенных операторов входного языка) (0,61 ошибки на 1 команду машинного языка). В п-?риод испытаний, предшествовавших эксплуатации, этот показатель был равен 17,5 (6,3 ошибки на 1 машинную команду). Ф\нк-ционирующее программное обеспечение было передано заказчику в срок и позволило ему эффективно решать свои повседневные задачи. Не будучи особенно продуктивным, подход, сводящийся к сочетанию аттестационных, приемочных, системных и эксплуатационных испытаний, оказался эффективным с точки зрения вылавливания ошибок, которые должны были быть обнаружены в ходе программных испытаний. Следует, однако, предупредить, что подавляющее большинство систем программного обеспечения не так прозрачно для испытаний, как программное обеспечение Проекта 3, ориентированное на пакетный рехсим обработки информации и написанное на языке высокого уровня. Ориентация