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

Стратегия 1 Стратегия 2

Рис. ТЗ.З

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

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

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

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

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

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

При разработке сложных ПС верификация и тестирование требуют значительных ресурсов в течение всего ЖЦ ПС, и наиболее критичным ресурсом является допустимое время поэтапного выполнения этих проце­дур. Интенсивность выявления дефектов при тестировании программ прак­тически экспоненциально убывает в зависимости от времени, затрачивае­мого на их обнаружение, и соответственно возрастают интервалы между очередными проявлениями дефектов. На основе экспериментальных дан­ных созданы математические модели, которые позволяют прогнозиро­вать интервалы времени между последовательными обнаружениями де­фектов или ошибок в программных компонентах при некотором методе и этапе верификации или тестирования (см. лекцию 10). Например, если при тестировании определенного модуля или компонента ПС выявлено опре­деленное число дефектов (например, 5 или 10), то модели позволяют оце­нить ресурсы (время), необходимое для обнаружения следующего дефек­та, и рентабельность продолжения тестирования используемым методом. Рациональное изменение стратегии или метода выявления дефектов мо­жет приводить к кратковременному повышению интенсивности их прояв­ления, а затем к постепенному ее снижению.

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

Современные системы систематического тестирования и отлад­ки программных компонентов высокого и контролируемого качества дол­жны обеспечивать:

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

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