14.2. Организация и методы оценивания характеристик сложных комплексов программ

Характеристики качества функционирования программных средств зависят не только от их внутренних свойств, но и от свойств внешней среды, в которой они применяются (см. ISO 12119). Для сокращения неопределенностей и прямых ошибок при оценивании качества ПС необходимо до начала испытаний определить основные параметры внешней среды, при которых должен функционировать комплекс программ с требуемыми характеристиками при оценивании его качества и эксплуатации. Для этого заказчик и разработчик совместно должны структурировать, описать и согласовать модель внешней среды и ее параметры в среднем, типовом режиме применения ПС, а также в наиболее вероятных и критических режимах, в которых должны обеспечиваться требуемые характеристики качества функционирования ПС. Такая модель должна отражать и фиксировать характеристики:

• внешних потоков информации, в том числе, их распределение по видам источников, характеристикам качества данных и возможности их дефектов;

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

• возможных негативных и несанкционированных воздействий от внешней среды при применении ПС;

• необходимые характеристики вычислительных средств, на которых предназначено функционировать комплексу программ с требуемым качеством.

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

Внутренние квалификационные испытания качества программных средств (ис­пытания главного конструктора), которые зачастую совмещаются с завершением комплексной отладки, должны оформляться документаль­но и являются основанием при предъявлении ПС заказчику на квалификационные испытания для завершающего оценивания характеристик качества программного продукта (см. ISO 12207, ISO 15504, ISO 16326). Разработчик должен реализовать и оценить проект, комплекс программ, тесты, результаты тестирования и документацию для пользователя, учитывая:

• полноту охвата испытаниями всех требований спецификаций к компонентам и к ПС в целом;

• согласованность с требуемыми заказчиком и ожидаемыми результатами применения ПС;

• возможность интеграции и тестирования ПС в составе системы;

• возможность функционирования и сопровождения версий ПС в соответствии с требованиями контракта.

Любые испытания ограничены допусти­мым количеством и объемом проверок, а также длительностью работы комиссии испытателей, поэтому не могут гарантировать абсолютную проверку качества продукта. Для повышения достоверности определения и улучшения оценивания характеристик ПС после внутренних ис­пытаний, комплекс программ целесообразно передавать некоторым пользователям на опытную эксплуатацию в типовых усло­виях. Это позволяет более глубоко оценить эксплуатационные ха­рактеристики созданного комплекса и устранить некоторые дефекты и ошибки. Опытную эксплуатацию целесообразно проводить разработчиками с учас­тием испытателей-заказчиков и некоторых пользователей, назначаемых заказчи­ком. Результаты и характеристики качества опытной эксплуатации после испытаний главного конструктора могут учитываться при про­ведении заказчиком квалификационных испытаний для их сокращения.

В лекции 13 рассмотрены этапы тестирования компонентов и ПС в целом с позиции последовательного увеличения функциональной сложности тестов и взаимодействия с объектами внешней среды. При этом не учитывались организационные этапы испытаний в соответствии со стандартами, и их подотчетность разработчикам-поставщикам и заказчикам. Этапы и процессы квалификационного тестирования ПС с целью формального удостоверения для заказчика достигнутых характеристик качества комплекса программ и его компонентов в составе системы регламентированы в стандартах ISO 12207, ISO 15504. В них выделены три основных, функциональных этапа реализации квалификационного тестирования и испытаний (рис. 14.2):

• квалификационное тестирование функциональных компонентов и ПС в целом вне аппаратуры системы;

• интеграция и тестирование программного средства в целом в составе аппаратуры системы;

• квалификационное тестирование и полные испытания системы в комплексе с программным средством.

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

Разработчик должен определить и зарегистрировать процесс подготовки к тестированию, тестовые варианты, сценарии и процедуры, которые должны использоваться для квалификационного тестирования компонента и проследить соответствие между тестовыми вариантами и требованиями контракта. Он должен подготовить тестовые данные, необходимые для выполнения тестовых вариантов, и предварительно уведомить представителя заказчика о времени и месте проведения квалификационного тестирования. Если испытание компонента должно быть засвидетельствовано представителем заказчика, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что ПС готово для проведения тестирования в присутствии представителя заказчика. Результаты этих проверок должны быть зарегистрированы в файлах разработки ПС, а тестовые варианты и процедуры соответствующим образом модифицированы для устранения выявленных дефектов. Следует выполнить все необходимые изменения в ПС, предварительно уведомив об этом представителя заказчика, осуществить повторное тестирование в необходимом объеме, модифицировать файлы разработки ПС и другие программные продукты, основываясь на результатах интеграции и тестирования модулей и компонентов. Результаты этих действий должны быть включены в отчет для заказчика о проведенных разработчиком предварительных испытаниях.

Интеграция и тестирование ПС в составе аппаратуры системы содержит их объединение, тестирование полученного в результате комплекса с целью определения работают ли они вместе, как требуется по контракту, и должно продолжать этот процесс до тех пор, пока интеграция и тестирование не будут выполнены для всех компонентов программ и аппаратуры. Тестовые варианты должны покрывать все аспекты системного уровня и требуемые характеристики качества проекта. Разработчик должен выполнить необходимые корректировки программ, принять участие в повторном тестировании в необходимом объеме и модифицировать файлы разработки ПС и другие программные компоненты, основываясь на результатах интеграционного тестирования.

Квалификационное тестирование системы и программного продукта в целом выполняется, чтобы продемонстрировать представителю заказчика, что удовлетворены все требования технического задания, и характеристики качества соответствуют условиям контракта. Оно должно покрывать все требования в спецификациях системы и подсистем, а также требования к интерфейсу с внешней средой. Испытания должны включать тестирование на объектной вычислительной системе или на альтернативной модели системы, одобренной представителем заказчика. Разработчик должен участвовать в разработке и регистрации процесса подготовки к тестированию, тестовых вариантов, сценариев и тестовых процедур, которые нужно использовать для полного испытания системы, и в прослеживании соответствия между тестовыми вариантами и требованиями к характеристикам качества системы. Каждое проверяемое требование должно соответствовать конкретным обоснованным характеристикам системы, иметь уникальный для проекта идентификатор, чтобы можно было провести тестирование и проследить его выполнение с помощью объективного теста. Для каждого требования должны выбираться квалификационные методы для подсистем и компонентов ПС, которые необходимо прослеживать в требованиях к системе. Степень детализации требований следует выбирать, учитывая в первую очередь те характеристики качества, которые внесены в условия приемки системы, и отдавать приоритет тем из них, которые заказчик требует обеспечить обязательно.

Все полученные результаты должны быть включены в отчет о тестировании ПС и системы. Если квалификационное тестирование системы должно быть засвидетельствовано представителем заказчика, то до его проведения разработчик должен проверить тестовые варианты и тестовые процедуры, чтобы гарантировать, что они полны и точны и что система готова для проведения тестирования в присутствии представителя заказчика. Испытания должны быть выполнены в соответствии с утвержденными заказчиком тестовыми вариантами, сценариями и процедурами.

Оценивание качества программного продукта при квалификационных, приемо-сдаточных испытаниях проводится комиссией заказчика, в которой участвует руководитель (главный конструктор) разработки и некоторые ведущие разработчики, или аттестованная сертификационная лаборатория. Комиссия при испытаниях должна руководствоваться следую­щими документами (см. рис. 14.2):

• утвержденными заказчиком и согласованными с разработчиком контрактом, техническим заданием и спецификациями требований на ПС;

• действующими государственными и ведомственными стандар­тами на жизненный цикл и испытания программ, на технологическую и эксплуатационную до­кументацию, а также стандартами де-факто, согласованными с заказчиком для использования  профилем стандартов и нормативных документов;

• Программой испытаний по всем требованиям контракта, технического задания и спецификаций;

• методиками испытаний, охватывающими каждый раздел требований тех­нического задания, спецификаций и Программы испытаний;

• комплектом адекватной эксплуатационной и технологической документации на комплекс программ.

Программа испытаний является планом проведения серии экспериментов и должна разрабатываться с позиции допустимой минимизации объема тестирования в процессе проведения испытаний для проверки выполнения требований технического задания и соответствия предъявленной до­кументации. Программа испытаний, методики их проведения и оценки результатов, разработанные совместно заказчиком и разработчиком, должны быть согласованы и утверждены. Они должны содержать уточ­нения и детализацию требований технического задания и спецификаций для данного ПС, а также гарантировать корректную проверку всех заданных ха­рактеристик качества. Программа испытаний должна содержать следующие четко сформулированные разделы:

• объект испытаний, его назначение и перечень основных до­кументов, определивших его разработку;

• цель испытаний с указанием всех требований технического задания, характеристик и атрибутов качества, подлежащих проверке, и ограничений на проведение испыта­ний;

• собственно Программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствие с техническим за­данием и план проведения тестирования для проверки по всем разделам техни­ческого задания и дополнительных требований, формализованных отдельными решениями разработчиков и заказчика;

• методики испытаний, однозначно определяющие все понятия проверяемых характеристик качества, условия и сценарии тестирования, инструментальные средства, используемые для испытаний;

• методики обработки и оценки результатов тестирования по каждому разделу Программы испытаний.

Методика испытаний должна содержать: описание организации процесса тестирования, тестовые варианты, сценарии и процедуры, которые используются при испытаниях отдельного компонента или ПС в целом. Каждый тест должен иметь уникальный для данного проекта идентификатор; должны быть представлены инструкции для проведения тестирования; описание аппаратуры и ПС для реализации тестирования, а также инструкции для повторного тестирования. Кроме того, должны быть приведены ссылки на проверяемые требования, указаны условия выполнения (конфигурация аппаратуры и компонентов ПС), входные данные, эталонные и ожидаемые результаты, критерии оценки качества результатов, процедура проведения тестирования для каждого тестового варианта, допущения и ограничения.

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

Большой объем разнородных данных, получаемых при испытаниях крупномасштабных ПС, и разнообразие возможных способов их обра­ботки, интерпретации и оценки приводят к тому, что важнейшими факторами становятся методики обработки и оценки результатов, а также протоколы проверки по пунктам Программы испытаний. В соот­ветствии с методиками испытаний средства автоматизации должны обеспечивать всю полноту проверок характеристик по каждому раз­делу методик. Результаты испытаний фиксируются в протоколах, ко­торые обычно содержат следующие разделы:

• назначение тестирования и раздел требований технического задания, по которому проводились испытания;

• указания разделов методик в соответствии, с которыми проводились испытания, обработка и оценка результатов;

• условия и сценарии проведения тестирования и характерис­тики исходных данных;

• обобщенные результаты испытаний с оценкой их на соответс­твие требованиям технического задания и другим руководящим документам, а также технической документации;

• описание отличий тестовой и реальной эксплуатационной сред;

• описание обнаруженных дефектов и ошибок и рекомендуемых улучшений в испытываемом ПС;

• выводы о результатах испытаний и о соответствии созданного ПС или компонента определенному разделу требований технического задания и исходных спецификаций.

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

Наиболее полным и разносторонним испытаниям должна подвергаться первая базовая версия ПС. При испытаниях очередных модернизированных версий ПС возможны значительные сокращения объемов тестирования апробированных повторно используемых компонентов. Однако комплексные и завершающие испытания каждой новой версии ПС, как правило, проводятся в полном объеме, гарантирующем проверку выполнения всех требований модифицированного технического задания. Для вы­явления дефектов в процессе эксплуатации серийных образцов в каждом из них должен быть предусмотрен некоторый минимум средств для проверки функционирования и обнаружения искажений результатов. Эти средства должны позволять фиксировать условия непра­вильной работы программ и характер проявления дефектов при применении ПС. Последу­ющее исправление ошибок должно проводиться специалистами, осу­ществляющими сопровождение.

До начала квалификационных испытаний ПС подлежат проверке и паспортизации средства, обеспечивающие получение эталонных данных, средства имитации тестов от внешних объектов, средства фиксирования и об­работки результатов тестирования. Завершаются квалификационные ПС испытания предъявлением заказчику на утверждение комплекта документов, содержащих результаты комплексных испытаний версии программ­ных средств:

• откорректированные тексты программ и данных на языке программирования и в объектном коде, а также полные спецификации требований на программные компоненты и ПС в целом после полного завершения тестирования и испытаний;

• Программу испытаний ПС по всем требованиям технического задания;

• комплект методик испытаний и обработки результатов по всем разделам программы испытаний;

• тесты, сценарии и генераторы тестовых данных, использо­ванные для испытаний программных и информационных компонентов и вер­сии ПС в целом;

• результаты и протоколы квалификационного тестирования, функциональные и конструктивные характеристики ПС в реальной внешней среде;

• отчет о подт­верждении заданного качества, полные характеристики достигнутого качества функционирования, а также степени покрытия тестами спецификации требований к ПС;

• план, методики и средства автоматизации обучения заказчи­ка и пользователей применению испытанной версии ПС;

• комплект эксплуатационной документации, описание ПС и ру­ководство пользователя в соответствии с условиями контракта;

• технические условия на версию ПС, базу данных и эксплуа­тационную документацию для тиражирования и серийного производс­тва;

• руководство по инсталляции, генерации пользовательской вер­сии ПС и загрузке базы данных в соответствии с условиями и ха­рактеристиками внешней среды;

• отчет о технико-экономических показателях завершенного проекта версии ПС, выполнении планов и использованных ресурсах;

• акт о завершении испытаний и готовности к поставке и/или предъявлению для сертификационных испытаний версии ПС.

Представленная выше организация испытаний крупных ПС ориентирована на наличие конкретного заказчика комплекса программ и ограниченное число пользователей, контролируемых заказчиком. Несколько иначе организуются испытания коммерческих пакетов прикладных программ, создаваемых по инициативе фирмы или коллектива разработчиков для продажи широкому кругу пользователей при отсутствии конкретного заказчика. Для таких коммерческих комплексов программ принято проводить квалификационные испытания на соответствие критериям, формализо­ванным руководителем проекта в два последовательных этапа  Альфа и Бета тестирова­ние. Они заключаются в нормальной и форсированной (стрессовой) опытной эксплуатации конечными поль­зователями оформленного программного продукта в соответствии с эксплуатационной документацией и различаются количеством участвующих пользователей и уровнем их квалификации.

При Альфа тестировании привлекаются конечные пользователи, работающие преимущественно в той же компании, но не участвовавшие непосредствен­но в разработке комплекса программ. Для Бета тестирования прив­лекаются добровольные пользователи (потенциальные покупатели), которым бесплатно передается версия ПС для опытной эксплуатации. При этом особое значение имеет участие компетентных, заинтересованных и доброжелательных пользователей, способных выявить дефекты и своими рекомендациями улучшить качество тестируемых программ. Их деятельность стимулируется бесплатным и ранним получением и освоением нового программного продукта и собственной оценкой его качества. Эти пользователи обязуются сообщать разработчикам сведения о всех выявленных дефектах и ошибках, а также вносить изменения в прог­раммы и данные или заменять версии исключительно по указаниям разработчиков. Только после успешной эксплуатации и Бета тестирования ограни­ченным контингентом пользователей, руководителем проекта или фирмы разработчиков может приниматься решение о передаче ПС в продажу для широкого круга пользователей. Обобщенные результаты Бета тестирования могут использоваться как основа для сертифи­кационных испытаний.

При Альфа и Бета испытаниях принято разделять прогрессив­ное и регрессионное тестирование. Под прогрессивным  понимается тестирование новых программных компонентов, для выявления дефектов и ошибок в исходных текстах программ и спецификациях. Регрессион­ное тестирование предназначено для контроля качества и коррект­ности программ и данных после проведения корректи­ровок. Необходимость и широта регрессионного тестирования определяется тем, что значительная доля изменений после Альфа и Бета тестирования в свою очередь содержат дефекты и ошибки. Количество тестов и дли­тельность обоих этапов тестирования определяются экспертно раз­работчиками или руководителем проекта в зависимости от сложности комплекса программ и интенсивности потока изменений.