ЛЕКЦИЯ 13. Лекция 13 верификация, тестирование и оценивание корректности программных компонентов
 Скачать 200.7 Kb.
|
|
Спецификация требований к функциям и качеству системы Верификация соответствия спецификации требований к программному средству требованиям к функциям и качеству системы Верификация полноты и корректности спецификации и сценариев тестов системы Верификация соответствия спецификации требований к функциональным компонентам требованиям к программному средству Верификация полноты и корректности спецификаций и сценариев тестов программного средства Верификация полноты и корректности спецификаций и сценариев тестов программных компонентов Верификация соответствия спецификаций требований к программным и информационным модулям требованиям к функциональным компонентам Верификация полноты и корректности спецификаций и сценариев тестов программных и информационных модулей Верификация соответствия объектного кода спецификациям требований к текстам программных и информационных модулей Рис. 13.2 368 13.1. Принципы верификации и тестирования программ Для обеспечения высокого качества программного продукта параллельно с верификацией требований и программированием корректировок целесообразно разрабатывать и верифицировать спецификации и сценарии тестов, отражающие методы и конкретные процедуры проверки реализации изменений этих требований (рис. 13.2). Тестовые спецификации могут использоваться для проверки согласованности, внутренней непротиворечивости и полноты реализации требований без исполнения программ. Для каждого требования к комплексу программ, его архитектуре, функциональным компонентам и модулям должна быть разработана спецификация тестов, обеспечивающая проверку корректности, адекватности и возможности в последующем реализовать тестирование компонента на соответствие этому требованию. Такая взаимная проверка функций компонентов, отраженных в требованиях и в спецификациях тестов, обеспечивает повышение их качества, сокращение дефектов, ошибок, неоднозначностей и противоречий. При тестировании программ зачастую оказывается, что не каждое требование в спецификации описано достаточно полно и корректно, чтобы оно могло быть проверено тестами. При разработке тестов на основе таких спецификаций вследствие их возможной неопределенности может обнаруживаться, что не для каждого требования к программе или данным может быть подготовлен тест. С другой стороны, не для каждого теста может оказаться в спецификации адекватное требование на функции ПС. Спецификации тестов должны обеспечивать дополнительный контроль корректности спецификаций требований и верификацию взаимодействия компонентов на соответствующем уровне описания ПС. Независимая разработка спецификаций тестов на основе спецификаций требований создает базу для обнаружения, какие требования не тестировались или принципиально не могут быть проверены тестированием. Таким образом, верификация спецификаций требований на программные компоненты и ПС могут использоваться с двумя целями (см. рис. 13.2):
369 Лекция 13. Верификация, тестирование и оценивание корректности компонентов В результате совокупности спецификаций требований к тестам могут применяться при разработке и сопровождении как эталоны и вторая адекватная форма описания содержания программ для сквозной верификации спецификаций требований к тестам сверху вниз, а также сами подвергаться верификации на корректность соответствия исходным требованиям к компонентам текстов программ и данных разного уровня. Такие параллельные взаимные проверки спецификаций требований и текстов программ и спецификаций тестов способствуют выявлению и исключению множества вторичных дефектов и ошибок в ПС. Впоследствии эти спецификации тестов должны использоваться для непосредственного тестирования исполнения требований к программным компонентам соответствующего уровня. Кроме того, параллельная и независимая разработка, с одной стороны, спецификаций программ и спецификаций тестов, а также их реализации, с другой стороны, позволяет распараллеливать работы ЖЦ ПС, что ведет к сокращению сроков создания компонентов и комплексов программ. Реализация этих целей взаимодействия верификации и тестирования может производиться разными методами и независимыми специалистами — программистами и тестировщиками, что позволяет использовать результаты их деятельности для сравнения содержания одних и тех же программ, представленных на языках программирования и описанных на языках тестов. Особенности описаний и реализации программ, а также мышления программистов — на основе функций и процедур исполнения программ существенно отличаются от представлений и методов описаний тех же функций программ тестировщиками — создателями сценариев тестирования. Они акцентируют деятельность на конкретных процедурах проверки функционирования, возможных результатах и взаимодействии компонентов ПС. Это позволяет выявлять вторичные дефекты, появляющиеся при корректировках, и повышать качество разработки и сопровождения путем сопоставления двух методов и результатов описания одних и тех же программ, за счет того, что мала вероятность одинаковых ошибок в сценариях тестов и в реализации текстов программ. 370 13.2. Процессы и средства тестирования программных компонентов 13.2. Процессы и средства тестирования программных компонентов Относительная простота ПМ позволяет детально анализировать их внутреннюю структуру и любой маршрут исполнения программы. Это обеспечивает возможность реализации двух стратегий тестирования: от структуры и от данных. Этим двум стратегиям соответствуют два метода тестирования программ: метод анализа потоков управления и анализа потоков данных. Методы дополняют друг друга, и каждый может быть доминирующим на начальных этапах отладки в зависимости от типа объекта и условий тестирования. Стратегия 1 Стратегия 2 I Построение структуры ПМ I по тексту программы Подготовка теста для проверки функции и потока данных в ПМ * I Выделение и упорядочение маршрутов I по выбранным критериям Тестирование ПМ по сформированному тесту * I Формирование теста по условиям I в предикатах выбранного маршрута i Выявление ошибок в данных и вычислениях в ПМ I Тестирование маршрута ПМ I по сформированному тесту * Обобщение протестированных маршрутов ПМ I Сравнение реализованного маршрута I исполнения ПМ и исходного по тексту i I Выявление и устранение ошибок Формирование структуры ПМ по протестированным маршрутам I несоответствия маршрутов Выявление ошибок в вычислениях на выделенном маршруте 1_ Оценка покрытия исходной структуры ПМ протестированными маршрутами \ Оценка достаточности выполненного тестирования ПМ I Окончание-тестирования и регистрация степени корректности ПМ Рис. 13.3 371 Лекция 13. Верификация, тестирование и оценивание корректности компонентов При первой стратегии (рис. 13.3) за основу принимается структура ПМ, построенная по тексту программы в виде графа. В графе программы по некоторым критериям выделяются и упорядочиваются маршруты исполнения программы и условия-предикаты, при которых они могут быть реализованы. Эти условия используются для подготовки тестовых наборов, каждый из которых должен реализоваться по маршруту, принятому за эталон при подготовке теста. Отклонение исполнения теста от первоначально выбранного маршрута рассматривается как ошибка, причина которой может быть либо в первичной структуре ПМ, либо в реализации конкретного маршрута при данном тесте на входе. После устранения ошибок и несоответствия выбранных и реализованных маршрутов для каждого из них проверяется процесс обработки данных и выявляются ошибки в результатах их преобразования. Затем оценивается достаточность выполненного тестирования по степени по-крытия исходного графа программы проверенными маршрутами, которые выделялись по выбранному или заданному критерию. Завершается тестирование при требуемом покрытии графа программы протестированными маршрутами или при использовании ресурсов, выделенных на тестирование. В последнем случае необходимы оценка достигнутой корректности программы и регистрация этой величины. При этой стратегии некоторые выделяемые маршруты могут оказаться принципиально нереализуемыми из-за противоречивых условий в последовательных операторах — вершинах графа программы. Вследствие этого для некоторых модулей могут подготавливаться тесты, которые являются избыточными и не отражают реальное функционирование программы. Тем не менее данная стратегия имеет преимущества при тестировании логических программ с малой долей вычислений. При этом достаточно эффективно контролируется полнота тестирования при различных критериях выделения маршрутов и методах их упорядочения. При второй стратегии (см. рис. 13.3) за основу принимаются требования спецификаций, конкретные тестовые и эталонные значения, которые подготавливаются специалистами путем анализа переменных и предикатов в тексте программы. При каждом тесте программа исполняется по определенному маршруту, который регистрируется. При этом реализованный в соответствии с анализируемыми требованиями маршрут и поток данных рассматриваются как эталонные компоненты структуры програм- 372 13.2. Процессы и средства тестирования программных компонентов мы. По мере тестирования отмечаются проверенные операторы и оценивается полнота покрытия тестами требований спецификаций на маршрутах тестирования. Накопление и обобщение реализованных маршрутов позволяет воспроизвести структуру программы и контролировать степень покрытия каждого компонента. Для этого на каждом этапе тестирования выделяются компоненты программы, оставшиеся непроверенными, для которых необходимо подготавливать дополнительные тесты. Однако при такой стратегии трудно оценить степень покрытия и проверки всех маршрутов исполнения программы без использования структурного графа, построенного по ее исходному тексту. Данная стратегия имеет преимущества при сравнительно простой структуре программы и при преобладании в ней вычислительных операторов. На каждом маршруте упорядоченное варьирование переменных акцентирует внимание на вычислительной части программы, что существенно для такого класса ПМ. Однако возрастает риск пропустить сочетания предикатов, определяющих непроверенный маршрут. Поэтому практически всегда целесообразно совместное применение двух стратегий, с акцентом на одну из них в зависимости от особенностей тестируемого ПМ или его частей. Программы с преобладанием сложной логической структуры и с относительно малой вычислительной частью целесообразно начинать тестировать по первой стратегии и только для маршрутов с вычислительными операторами использовать анализ потоков данных (вторую стратегию). В модулях, имеющих простую структуру и содержащих значительный объем вычислений после первичной отладки по второй стратегии, целесообразна проверка полноты тестирования структуры и завершение отладки по первой стратегии. Известно, что в крупных ПС исчерпывающее тестирование, гарантирующее полное отсутствие в них дефектов и ошибок, принципиально невозможно и число дефектов, обнаруживаемых в программах даже независимыми тестировщиками, имеет пределы. Представленное выше прослеживание соответствия компонентов при верификации корректности сверху вниз от исходных требований к комплексу программ и тестирование покрытия компонентов на соответствие требованиям на каждом уровне их детализации может потребовать значительных вычислительных, трудовых и временных ресурсов. Реальные ограничения доступных ресурсов определяют количество неустраненных дефектов и достижимую корректность 373 Лекция 13. Верификация, тестирование и оценивание корректности компонентов компонентов и ПС в целом. На практике учитывать степень покрытия тестами достаточно трудоемко и зачастую желательно иметь более простой способ регламентирования и оценивания качества тестирования. Возникает проблема, как практически учесть ограничения ресурсов и когда прекратить верификацию и тестирование, а также какая при этом будет достигнута корректность программ и способна ли она удовлетворить заказчика и пользователя при эксплуатации ПС. При разработке сложных ПС верификация и тестирование требуют значительных ресурсов в течение всего ЖЦ ПС, и наиболее критичным ресурсом является допустимое время поэтапного выполнения этих процедур. Интенсивность выявления дефектов при тестировании программ практически экспоненциально убывает в зависимости от времени, затрачиваемого на их обнаружение, и соответственно возрастают интервалы между очередными проявлениями дефектов. На основе экспериментальных данных созданы математические модели, которые позволяют прогнозировать интервалы времени между последовательными обнаружениями дефектов или ошибок в программных компонентах при некотором методе и этапе верификации или тестирования (см. лекцию 10). Например, если при тестировании определенного модуля или компонента ПС выявлено определенное число дефектов (например, 5 или 10), то модели позволяют оценить ресурсы (время), необходимое для обнаружения следующего дефекта, и рентабельность продолжения тестирования используемым методом. Рациональное изменение стратегии или метода выявления дефектов может приводить к кратковременному повышению интенсивности их проявления, а затем к постепенному ее снижению. Для использования таких моделей в конкретной фирме для некоторого класса проектов при определенной квалификации разработчиков экспериментально может быть установлено число дефектов, которое должно быть обнаружено тестировщиками на определенном этапе тестирования программного компонента за выделяемое время. Если за это время выявлено число дефектов меньшее, чем задано априори, то это может означать либо очень хорошую работу программистов-разработчиков, либо недостаточное качество тестов и их исполнителей. Некоторое дополнительное тестирование, возможно, поможет решить эту альтернативу. Регулярная регистрация числа выявляемых дефектов за заданное время определенными тестировщиками, в результатах работы конкретных программистов, 374 13.2. Процессы и средства тестирования программных компонентов позволит оценить усредненную интенсивность выявления дефектов при тестировании на предприятии при разработке определенных типов проектов. Такие оценки могут использоваться при прогнозирования достигнутого качества соответствующих программных компонентов. При этом целесообразно учитывать категории выявленных дефектов по степени влияния на результаты функционирования программы: критические — недопустимо искажающие результаты, опасные — угрожающие небольшими искажениями результатов в редких случаях, а также слабо или практически не влияющие на результаты. Современные системы систематического тестирования и отладки программных компонентов высокого и контролируемого качества должны обеспечивать:
— эффективную реализацию отладочных заданий с целью дости жения максимальной корректности программ в условиях ограниченных ресурсов на тестирование;
375 Лекция 13. Верификация, тестирование и оценивание корректности компонентов Для отладки программных компонентов, входящих в сложные ПС и пригодных для повторного использования в различных проектах, необходим комплекс средств автоматизации, использующий основные современные методы выявления ошибок и дефектов в программах. Эти средства можно разделить на (рис. 13.4):
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||