Cтраница 3
Кроме того, как показывает рис. 10.1, большая часть сегодняшних знаний концентрируется вокруг внутренних процессов разработки программного обеспечения. Знания в области проектирования, кодирования и тестирования отдельных модулей довольно велики, в то время как о процессах начальных ( требования, цели, внешнее проектирование) и заключительных ( например, комплексное тестирование системы) известно мало. [31]
Поскольку методы доказательств все еще далеки от совершенства, а также из-за перечисленных выше проблем, этот метод нельзя рекомендовать для употребления в большинстве современных проектов. В тех случаях, когда он применяется, его можно использовать вместо процессов структурного контроля и автономного тестирования, но он не может заменить остальные процессы тестирования, такие, как тестирование сборки, внешних функций и комплексное тестирование, а также тестирование приемлемости. Доказательства, однако, могут и сегодня представлять ценность в определенных критических ситуациях, когда в разработку проекта возможно вложить дополнительные затраты ради повышения достоверности результата. [32]
Тестирование модулей ( или тестирование блоков) выполняется с отдельными компонентами автономно. При объединении отдельных компонентов в подсистемы или системы проводится комплексное тестирование темы с целью проверки правильной совместной работы ее составных частей. При комплексном тестировании особое внимание обычно уделяется взаимодействию компонентов. В противоположность этому при системном тестировании вся система в целом обычно рассматривается как некоторый черный ящик; поведение этой системы исследуют, не вникая в подробности отдельных ее компонентов и взаимодействия между ними. Назначением приемочных испытаний является проверка пригодности системы для эксплуатации; такие испытания обычно проводятся под контролем поставщика системы. [33]
Для упрощения процесса тестирования комплексы программ рекомендуется первоначально тестировать по отдельным функциональным группам программ, предназначенным для решения крупных относительно самостоятельных функциональных задач. Отладив такие группы, можно переходить к тестированию комплекса программ в целом. Каждый этап комплексного тестирования отличается своим набором тестов. [34]
После прохождения обучения по программе, равной или превышающей 72 часа, слушателям учебных курсов ГНОЦ CALS-технологий выдается удостоверение государственного образца. Этот объем слушатели могут набрать, прослушав либо только базовый курс Б-2-1, либо комбинацию из других курсов, общая продолжительность которых составляет не менее 72 часов. Перед получением удостоверения слушатель должен пройти комплексное тестирование знаний, гарантирующее, качество обучения. Тестирование состоит из ответов на контрольные вопросы по курсу и ( для курса Б-2-1) защиты выпускной работы. [35]
Комплексное тестирование, вероятно, самая непонятная форма тестирования. Во всяком случае, комплексное тестирование не является тестированием всех функций полностью собранной системы; тестирование такого типа называется тестированием внешних функций. Элементами, участвующими в комплексном тестировании, служат сама система, описание целей продукта и вся документация, которая будет поставляться вместе с системой. Внешние спецификации, которые были ключевым элементом тестирования внешних функций, играют лишь незначительную роль в комплексном тестировании. [36]
Необходимо подчеркнуть, что тестирование и отладка также состоят из нескольких этапов, особенно при разработке больших программ. Около половины всех трудозатрат на тестирование и отладку приходится на проверку соответствия отдельных модулей внутренним спецификациям. Этот этап иногда называют автономное тестирование и отладка. На втором этапе, называемом комплексное тестирование и отладка, осуществляется объединение модулей и проверка внешних спецификаций программы. [37]
Проверку корректности ПО и его отладку производят на этапе тестирования. Тестирование подразделяют на три стадии: автономное, комплексное и системное. При автономном тестировании каждый программный модуль проверяют с помощью данных, подготавливаемых программистом. Модуль, прошедший автономное тестирование, подвергают комплексному тестированию, при котором проверяют отдельные группы программных модулей. В результате комплексного тестирования возможно обнаружение ошибок, пропущенных при автономном тестировании. При системном тестировании испытывают ППП с помощью независимых тестов. [38]
Организация, выполняющая интеграцию, отвечает за сопровождение очередного спина в контролируемых ею библиотеках, утверждение всех изменений ( что предполагает анализ текста всех изменений на исходном языке), сборку каждого спина, документирование способа использования и ограничений каждого спина, а также рассылку каждого спина организациям-разработчикам. Зга организация сначала рассылает спин 0 и затем ждет получения всех сборочных узлов, запланированных для следующего спина. Она добавляет эти узлы к прежнему спину ( создавая таким образом новый спин), добавляет все необходимые программы-подпорки, тестирует регрессию нового спина, чтобы убедиться, что система не регрессирует, и затем распространяет новый спин по организациям-разработчикам. После того как создан последний спин, продукт готов к комплексному тестированию. [39]
Кроме перечисленных процедур, тестирование может охватывать и отдельные составляющие программы. Так, например, тестированию могут подвергаться исходные данные или данные, полученные в результате решения задачи. В программах тестированию могут подвергаться сопряжения между модулями, или отдельными частями программы, или между программами ( задачами) сопряжения в системе. В таком случае полный набор всех процедур тестирования в системе может носить характер комплексного тестирования, поскольку он охватывает практически все составляющие системы. [40]
Нужно, чтобы тесто-вик думал так же, как пользователь или покупатель, а это предполагает доскональное понимание того, для чего система будет применяться. Поэтому возникает вопрос, кто же должен выполнять комплексное тестирование, и в частности кто должен проектировать тесты. Во всяком случае, этого не должны делать программисты или организации, ответственные за разработку системы. Группа тестирования системы должна быть независимой организацией и должна включать профессиональных специалистов по комплексному тестированию систем, несколько пользователей, для которых система разрабатывалась, основных аналитиков и проектировщиков системы и, возможно, одного или двух психологов. Очень важно включить самих проектировщиков системы. Это не противоречит аксиоме, согласно которой невозможно тестировать свою собственную систему, поскольку система прошла через много рук после того, как ее описали архитектор или проектировщик. В действительности проектировщик и не пытается тестировать собственную систему; он ищет расхождения между окончательной версией и тем, что он первоначально - возможно, год или два назад - имел в виду. Для комплексного тестирования желательно также иметь информацию о рынке или пользователях, уточняющую предположения о конфигурации и характере применения системы. [41]
Проверку корректности ПО и его отладку производят на этапе тестирования. Тестирование подразделяют на три стадии: автономное, комплексное и системное. При автономном тестировании каждый программный модуль проверяют с помощью данных, подготавливаемых программистом. Модуль, прошедший автономное тестирование, подвергают комплексному тестированию, при котором проверяют отдельные группы программных модулей. В результате комплексного тестирования возможно обнаружение ошибок, пропущенных при автономном тестировании. При системном тестировании испытывают ППП с помощью независимых тестов. [42]
Комплексное тестирование, вероятно, самая непонятная форма тестирования. Во всяком случае, комплексное тестирование не является тестированием всех функций полностью собранной системы; тестирование такого типа называется тестированием внешних функций. Элементами, участвующими в комплексном тестировании, служат сама система, описание целей продукта и вся документация, которая будет поставляться вместе с системой. Внешние спецификации, которые были ключевым элементом тестирования внешних функций, играют лишь незначительную роль в комплексном тестировании. [43]
Нужно, чтобы тесто-вик думал так же, как пользователь или покупатель, а это предполагает доскональное понимание того, для чего система будет применяться. Поэтому возникает вопрос, кто же должен выполнять комплексное тестирование, и в частности кто должен проектировать тесты. Во всяком случае, этого не должны делать программисты или организации, ответственные за разработку системы. Группа тестирования системы должна быть независимой организацией и должна включать профессиональных специалистов по комплексному тестированию систем, несколько пользователей, для которых система разрабатывалась, основных аналитиков и проектировщиков системы и, возможно, одного или двух психологов. Очень важно включить самих проектировщиков системы. Это не противоречит аксиоме, согласно которой невозможно тестировать свою собственную систему, поскольку система прошла через много рук после того, как ее описали архитектор или проектировщик. В действительности проектировщик и не пытается тестировать собственную систему; он ищет расхождения между окончательной версией и тем, что он первоначально - возможно, год или два назад - имел в виду. Для комплексного тестирования желательно также иметь информацию о рынке или пользователях, уточняющую предположения о конфигурации и характере применения системы. [44]