Методологические основы

Основные этапы систематического тестирования и испытаний крупного комплекса программ реального времени и его компонентов пред­ставлены на рис. 13.6. При тестировании и испытаниях корректности функциональных компонентов комплексов программ выделены этапы'.

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

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

• 
  Исходные Этапы тестирования Результаты
  
• 
  
  
• 
  Рис. 13.6
  
• 
  Сложность тестирования компонентов на этих этапах в значительной степени обусловлена несинхронным процессом их разработки и отладки отдельными специалистами в коллективах. Первично спланированная ло­гика сопряжения между собой отдельных компонентов и подключения их к операционной системе не всегда выполняется из-за задержек в разработ­ке и автономной отладке некоторых из них. Целесообразная последова­тельность тестирования определенных компонентов может нарушаться не­готовностью к сопряжению с ними других взаимодействующих программ.
  
• 
  Для обеспечения имитации объектов внешней среды и других взаи­модействующих групп программ на этих этапах используются преимуще­ственно детерминированные контрольные задачи или частные генераторы соответствующих тестов. Эти генераторы тестов целесообразно разраба­тывать и оформлять как отдельные модули или группы программ, функци­онирующие на той же технологической ЭВМ и в той же операционной среде, что и отлаживаемые компоненты. Совместно с ними также реализу­ются и функционируют частные специализированные программы для об­работки и обобщения отдельных результатов тестирования соответствую­щих групп программ.
  
• 
  После комплексирования основных, функциональных компонентов начинаются их тестирование и испытания в составе ПС в целом. Для них наиболее характерны следующие этапы квалификационного тестиро­вания и испытаний ПС в реальном времени (см. рис. 13.6):
  

• 
  по данным моделирующего стенда или генераторов тестов, имити­рующих отдельные объекты внешней среды;
  
• 
  с имитаторами отдельных объектов внешней среды и с реальными воздействиями от операторов-пользователей;
  
• 
  в полностью адекватной реальной или имитированной внешней среде и с реальными воздействиями от операторов-пользователей (см. лек­цию 14).
  

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

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

4. 
   Процессы тестирования структуры
   программных компонентов
   

• 
  Как отмечалось выше (см. п. 13.1), оценивание корректности про­граммных средств можно представить двумя видами работ:
  

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

• 
  Покрытие тестами может оцениваться по степени охвата тестирова­нием набора требований к программе или по покрытию тестами струк­туры программы. Прослеживание и покрытие тестами набора требований к программам трудно формализовать и оценить их влияние на достигае­мую корректность ПС. Имеющийся опыт показывает, что такой анализ вполне доступен для неформального анализа, но относительно слабее вли­яет на корректность, чем недостаточное тестирование структуры программ. Поэтому ниже внимание сосредоточено на оценивании тестирования и корректности структурного покрытия программ.
  
• 
  Анализ и оценивание покрытия тестами структуры программ позво­ляет выявить дефекты и ошибки, угрожающие наиболее тяжелыми по­следствиями при функционировании ПС. Ограниченные ресурсы трудо­емкости и времени на тестирование сложных комплексов программ для обеспечения их максимальной корректности приводят к необходимости рационального использования доступных ресурсов, прежде всего, для уст­ранения самых опасных ошибок. Тестирование фрагментов структуры про­граммы не гарантирует полное отсутствие ошибок в них, однако суще­ственно снижает их вероятность. Пропущенные при тестировании фраг­менты структуры заведомо могут содержать невыявленные ошибки, которые негативно отражаются на корректности программ. Таким обра­зом, тестирование структурного покрытия программ является необходи­мым условием обеспечения их относительной корректности, однако оно недостаточно для полного обеспечения корректности их функциониро­вания. В то же время тестирование и покрытие тестами структуры про­грамм наиболее доступно формализации для оценивания достигаемой от­носительной корректности и вероятности отсутствия ошибок в программе и позволяет устранять наиболее опасные ошибки, угрожающие отсутстви­ем или полным искажением требуемых результатов на выходе ПС.
  
• 
  На практике при отсутствии упорядоченного анализа потоков управ­ления некоторые маршруты в программе оказываются пропущенными при тестировании (до 50%), поэтому первая задача, которая должна решаться при тестировании структуры программ, — это получение информации о полной совокупности реальных маршрутов исполнения в каждой про­грамме и ее структурной сложности. Такое представление покрытия про­граммы позволяет упорядоченно контролировать достигнутую проверку маршрутов и, в некоторой степени, предохраняет от случайного пропуска отдельных нетестировавшихся маршрутов и их элементов.
  
• 
  Полное структурное покрытие программы тестами определяется чис­лом взаимодействующих компонентов, числом связей между компонента­ми и сложностью их взаимодействия. Структурная сложность и коррект­ность программного модуля зависит не столько от размера программы (числа строк текста), сколько от числа отдельных путей-маршрутов ее исполнения, существующих в программе. В пределе для обеспечения пол­ной структурной корректности все маршруты возможной обработки дан­ных должны быть проверены при создании программы, и тем самым опре­деляют сложность ее тестирования.
  
• 
  В ряде случаев подтверждена достаточно высокая адекватность ис­пользования структурной сложности программ для оценки трудоемкос­ти тестирования, вероятности невыявленных ошибок и затрат на разработку программных модулей и компонентов в целом. Сложность тестирования структуры программных модулей можно оценивать по чис­лу маршрутов, необходимых для их проверки, или более полно — по суммарному числу условий, которое необходимо задать в тестах для ис­полнения всех маршрутов программы. Анализ критериев тестирования, тестовых покрытий и выделение тестируемых маршрутов удобно прово­дить, используя графовые модели программ. При планировании тестиро­вания структуры программ возникают, прежде всего, две задачи', форми­рование критериев выделения маршрутов для тестирования и выбор стра­тегий упорядочения выделенных маршрутов.
  
•