2015-04-23
2927
Основные этапы тестирования и испытаний комплекса программ и его компонентов представлены на рисунке 12.2. Для каждого этапа на рисунке представлены основные исходные данные и результаты тестирования и испытаний. При тестировании, отладке и испытаниях корректности компонентов комплексов программ выделены следующие этапы:
– комплексирование модулей и отладка автономных групп программ в статике без взаимодействия с другими компонентами и, возможно, без подключения к операционной системе реального времени;
– тестирование и отладка групп программ в статике с учетом взаимодействия с некоторыми другими важнейшими компонентами и с базой данных;
– тестирование и отладка отдельных программных компонентов в реальном времени во взаимодействии с другими функциональными компонентами и с основными компонентами операционной системы и базы данных.
Сложность тестирования компонентов на этих этапах в значительной степени обусловлена несинхронным процессом их разработки и отладки. Первично спланированная логика сопряжения между собой отдельных компонентов и подключения их к операционной системе не всегда выполняется из–за задержек в автономной отладке некоторых из них. Целесообразная последовательность отладки определенных компонентов может нарушаться неготовностью к сопряжению с ними других взаимодействующих программ. В результате к комплексному тестированию и испытаниям ПС могут быть готовы не все необходимые компоненты, и их приходится начинать с некоторой не всегда самой важной и целесообразной совокупности групп программ.
Для обеспечения имитации объектов внешней среды и других взаимодействующих групп программ на этих этапах используются частные генераторы соответствующих тестов. Эти генераторы тестов целесообразно разрабатывать и оформлять как отдельные модули или группы программ, функционирующие на той же технологической ЭВМ и в той же операционной среде, что и отлаживаемые компоненты. Совместно с ними также реализуются и функционируют частные специализированные программы для обработки отдельных результатов отладки соответствующих групп программ, что также требует некоторых ресурсов ЭВМ. При этом не всегда удается полностью реализовать реальный масштаб времени для отдельных функциональных компонентов и приходится применять стартстопный режим тестирования или растягивать циклы решения функциональных задач и имитировать псевдореальный масштаб.
После комплексирования основных функциональных компонентов начинаются тестирование и испытания ПС в целом. Для них наиболее характерны следующие стадии комплексного тестирования и испытаний ПС в реальном времени:
– по данным моделирующего стенда или генераторов тестов, имитирующих отдельные объекты внешней среды;
– с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов–пользователей;
– в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов–пользователей.
На всех стадиях отладки, кроме операций непосредственной проверки функционирования программ, можно выделить еще две важные группы работ. Первая группа – это работы по методическому обеспечению тестирования и по созданию средств автоматизированной генерации тестов. Вторая группа работ должна обеспечивать возможность обработки результатов тестирования и оценки достигнутых показателей качества функционирования программ.
Средства генерации тестов и обработки результатов отладки можно разделить на три вида (см. рисунок 12.2). Одни и те же средства автоматизации тестирования в статике обычно обеспечивают отладку групп программ как автономно, так и во взаимодействии с другими компонентами. Средства, имитирующие внешнюю среду в реальном времени, чаще всего ориентированы на отладку как функциональных компонентов, так и ПС в целом. Еще один вид генераторов тестов в той или иной степени использует реальные объекты внешней среды. Первоначально такими объектами являются имитирующие стенды с участием реального функционирования операторов–пользователей. Затем источниками тестов могут быть полные комплексы реальной аппаратуры внешних объектов или их аппаратные аналоги.
Рисунок. 12.2 – Схема этапов тестирования и испытаний сложных комплексов программ
Каждая из выделенных стадий тестирования может рассматриваться как обеспечивающая создание определенного промежуточного продукта – функциональной группы программ или программного средства с некоторыми ограниченными характеристиками качества. Эти характеристики выделяются и детализируются на основе первичного технического задания и спецификации требований на ПС. В процессе проектирования ПС они уточняются и конкретизируются в спецификациях требований на группы программ и их компоненты. В результате создается совокупность эталонов, имеющих последовательно расширяющиеся номенклатуру и наборы значений показателей качества, которым должны соответствовать отлаживаемые и испытываемые компоненты на каждой стадии тестирования.
Подобная совокупность эталонных показателей качества промежуточных продуктов обеспечивает возможность управления процессом тестирования с целью достижения необходимого качества конечного продукта – ПС при минимальных или разумных затратах. Для этого каждая стадия тестирования должна иметь фиксированный и документированный результат с определенными эталонами и достигнутыми характеристиками программ. Подобный систематизированный контроль тестирования гарантирует высокое качество ПС реального времени, к которым предъявляются обычно высокие требования по надежности. Кроме того, компоненты, прошедшие все стадии тестирования, с большой уверенностью могут применяться как повторно используемые компоненты в последующих версиях ПС.
Организация завершающих испытаний комплексов программ. Испытания главного конструктора, которые зачастую совмещаются с завершением комплексной отладки, должны оформляться документально и являются основанием для предъявления ПС заказчику на завершающиеся совместные испытания. Любые испытания ограничены допустимым объемом проверок и длительностью работы комиссии, поэтому не могут гарантировать абсолютную проверку изделия. Для повышения достоверности определения и улучшения характеристик ПС после испытаний главного конструктора программы целесообразно передавать некоторым пользователям на опытную эксплуатацию в типовых условиях. Это позволяет более глубоко оценить эксплуатационные характеристики созданного комплекса и устранить некоторые дефекты и ошибки. Опытная эксплуатация проводится разработчиками с участием испытателей и некоторых пользователей, назначаемых заказчиком. Результаты и показатели надежности опытной эксплуатации после испытаний главного конструктора могут учитываться при проведении совместных испытаний для их сокращения.
Совместные приемо–сдаточные испытания проводятся комиссией заказчика, в которой участвуют главный конструктор разработки и некоторые ведущие разработчики, аттестованные сертификационной лабораторией. Комиссия при испытании руководствуется следующими документами:
– утвержденным заказчиком и согласованным с разработчиком техническим заданием и спецификациями на ПС;
– действующими государственными и ведомственными стандартами на проектирование и испытания программ и на техническую документацию, а также согласованными с заказчиком стандартами «де–факто»;
– программой испытаний по всем требованиям технического задания;
– методиками испытаний по каждому разделу требований технического задания;
– комплектом эксплуатационной документации на комплекс про грамм.
Программа испытаний является планом проведения серии экспериментов и разрабатывается с позиции минимизации объема тестирования в процессе проведения испытаний для проверки выполнения требований технического задания и соответствия предъявленной документации. Программа испытаний, методики их проведения и оценки результатов, разработанные совместно заказчиком и разработчиком, должны быть согласованы и утверждены. Они должны содержать уточнения и детализацию требований технического задания для данного ПС, а также гарантировать корректную проверку всех заданных характеристик, в том числе надежности. Программа испытаний должна содержать следующие четко сформулированные разделы:
– объект испытаний, его назначение и перечень основных документов, определивших его разработку;
– цель испытаний с указанием всех требований технического задания, подлежащих проверке, и ограничений на проведение испытаний;
– собственно программу испытаний, содержащую проверку комплектности спроектированного ПС в соответствии с тexническим заданием, и план тестирования для проверки по всем разделам технического задания и дополнительным требoвaниям, формализованным отдельными решениями разработчиков и заказчика;
– методики испытаний, однозначно определяющие все понятия проверяемых характеристик, условия и сценарии тестирования, средства, используемые для испытаний;
– методики обработки и оценки результатов тестирования по каждому разделу программы испытаний.
Большой объем разнородных данных, получаемых при испытаниях крупномасштабных ПС, и разнообразие возможных способов их обработки, интерпретации и оценки приводят к тому, что важнейшими факторами становятся методики обработки и оценки результатов, а также протоколы проверки по пунктам программы испытаний. В соответствии с методиками испытаний средства автоматизации должны обеспечивать всю полноту проверок характеристик по каждому разделу методик. Результаты испытаний фиксируются в протоколах, которые обычно содержат следующие разделы:
– назначение тестирования и раздел требований технического задания, по которому проводились испытания;
– указания методик, в соответствии с которыми проводились испытания, обработка и оценка результатов;
– условия и сценарии проведения тестирования и характеристики исходных данных;
– обобщенные результаты испытаний с оценкой их на соответствие требованиям технического задания и другим руководящим документам, а также технической документации;
– выводы о результатах испытаний и соответствии созданного ПС определенному разделу требований технического задания.
Протоколы по всей программе испытаний обобщаются в акте, в результате чего делается заключение о соответствии системы требованиям заказчика и завершении работы с положительным или отрицательным итогом. При полном выполнении всех требований технического задания заказчик обязан принять систему, и работа считается завершенной.
Наиболее полным и разносторонним испытаниям должна подвергаться первая базовая версия ПС. При испытаниях очередных модернизированных версий ПС возможны значительные сокращения объемов тестирования повторно используемых компонентов. Однако комплексные и завершающие испытания каждой новой версии ПС, как правило, проводятся в полном объеме, гарантирующем проверку выполнения всех требований измененного технического задания. Для обеспечения выявления дефектов в процессе эксплуатации серийных образцов в каждом из них должен быть предусмотрен некоторый минимум средств проверки функционирования и обнаружения искажений результатов. Этот минимум средств должен позволять фиксировать условия неправильной работы программ и характер проявления дефектов. Последующее исправление ошибок должно проводиться специалистами, осуществляющими сопровождение.
При завершающих испытаниях основное внимание, кроме проверок функциональной пригодности, должно сосредоточиваться на подготовке стрессовых тестов, тестировании в режимах предельного использования ресурсов, надежности функционирования ПС. Задача испытателей и заказчика при проведении совместных испытаний состоит в выделении условий и области изменения переменных, которые недостаточно проверены разработчиком и важны для последующего надежного функционирования программ. При этом разработчик контролирует, чтобы планируемые сценарии и тесты не выходили из областей, заданных техническим заданием и спецификацией требований. Испытания за пределами технического задания могут квалифицироваться как его расширение или могут исключаться по требованию разработчика.
До начала испытаний подлежат проверке и паспортизации средства, обеспечивающие получение эталонных данных, средства имитации тестов от внешних объектов, средства фиксирования и обработки результатов тестирования. При испытаниях важную роль играют оценка и обеспечение близких значений методической и статистической достоверности результатов испытаний. Методическая достоверность приемо–сдаточных испытаний ПС определяется следующими факторами:
– полнотой программы испытаний и корректностью методик тестирования по охвату возможных условий и сценариев функционирования программ и областей изменения исходных данных;
– достоверностью и точностью эталонных значений, с которыми сравниваются результаты тестирования испытываемой про граммы или которые служат опорными при расчете параметров, зафиксированных в техническом задании;
– адекватностью и точностью моделей, используемых для имитации тестов от внешней среды и подыгрыша их реакции на управляющие воздействия;
– точностью и корректностью регистрации и обработки результатов тестирования, а также сравнения полученных данных с требованиями технического задания.
Представленная выше организация испытаний сложных ПС ориентирована на наличие конкретного заказчика комплекса программ и ограниченное число пользователей, контролируемых заказчиком. Несколько иначе организуются испытания коммерческих пакетов прикладных программ, создаваемых по инициативе разработчиков для широкого круга пользователей при отсутствии конкретного заказчика. Для таких коммерческих прикладных программ принято проводить испытания в два последовательных этапа – Альфа– и Бета–тестирование. Испытания проводятся на соответствие критериям, формализованным руководителем проекта. Они заключаются в нормальной и форсированной (стрессовой) опытной эксплуатации конечными пользователями оформленного программного продукта в соответствии с сопроводительной документацией и различаются количеством участвующих пользователей.
При Альфа–тестировании привлекаются конечные пользователи, работающие в той же компании, но не участвовавшие непосредственно в разработке комплекса программ. Для Бета–тестирования привлекаются добровольные пользователи (потенциальные покупатели), которым бесплатно передается версия ПС для опытной эксплуатации. При этом особое значение имеет выделение компетентных, тщательных и доброжелательных пользователей, способных своими рекомендациями улучшить качество испытываемых программ. Их деятельность стимулируется бесплатным и ранним получением и освоением нового программного продукта и собственной оценкой его качества. Эти пользователи обязуются сообщать разработчикам сведения о всех выявленных дефектах и ошибках, а также вносить изменения в программы и данные или заменять версии по указаниям разработчиков. Только после успешной эксплуатации и Бета–тестирования ограниченным контингентом пользователей, руководителем проекта или фирмы разработчиков принимается решение о передаче ПС в продажу для широкого круга пользователей. Обобщение результатов Бета–тестирования может использоваться как часть или основа сертификационных испытаний.
При Альфа– и Бета–испытаниях принято разделять прогрессивное и регрессивное тестирование. Под прогрессивным понимается тестирование новых программных компонентов, для выявления дефектов и ошибок в исходных текстах программ и спецификациях. Регрессивное тестирование предназначено для контроля качества и корректности изменении в программах и данных после проведения корректировок. Необходимость и широта регрессивного тестирования определяются тем, что значительная доля изменений после Альфа– и Бета–тестирования, в свою очередь, содержит ошибки. Объем тестов и длительность обоих этапов тестирования определяются руководителями проекта в зависимости от сложности комплекса программ и интенсивности потока изменений.
