48237 (588527), страница 7

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

реорганизация структуры классов;

изменение интерфейса класса.

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

4.7 Сопровождение

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

Типичный порядок действий на этом этапе таков:

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

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

если позволяют ресурсы, планируют в следующем релизе менее интенсивные, более локализованные улучшения;

приступают к разработке следующего эволюционного релиза программы.

4.8 Заключение

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

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

5. Методика отладки и результаты работы программы

5.1 Особенности тестирования программных продуктов

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

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

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

невысокая степень формализации критериев качества процесса тестирования и достигаемого при этом качества программного обеспечения как объекта тестирования;

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

Неоднократно экспериментально установлено, что в любом сложном программном обеспечении в процессе эксплуатации обнаруживаются ошибки, даже если проведено самое тщательное тестирование. Тем самым объективно утверждается, что невозможно формализовать и обеспечить абсолютную полноту всех эталонных значений, а также провести всеобъемлющее исчерпывающее тестирование и гарантированно устранить все ошибки в сложных программных продуктах. Поэтому тестирование проводится в объемах, минимально необходимых для проверки программ в некоторых ограниченных пределах изменения параметров и условий функционирования. Ограниченность ресурсов тестирования привела к необходимости тщательного упорядочения методов и конкретных значений параметров с целью получения при тестировании наибольшей глубины проверок программ. Анализ многих проектов показывает, что до начала тестирования число ошибок в сложных программах составляет порядка 1-2% от общего числа объектных команд в программе, т.е. в программном обеспечении объемом 100 тысяч команд в процессе тестирования обычно выявляется 1-2 тысячи ошибок. При тщательном системном проектировании и программировании на языках высокого уровня начальное число ошибок в несколько раз меньше. Таким образом самое тщательное тестирование сложных программных комплексов позволяет получить программы с вероятностью ошибки в каждой команде порядка 10^-4-10^-5, т.е. несколько ошибок может остаться не выявленными.

5.2 Типичный процесс тестирования программного обеспечения

Процесс тестирования программ обычно включает:

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

статическое тестирование текстов разработанных программ и данных на выполнение всех заданных правил построения и описания без исполнения объектного кода;

тестирование программы с её исполнением в объектном коде и с разными уровнями детализации: детерминированное, стохастическое, и тестирование в реальном масштабе времени;

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

разработку изменения программы с целью исключения причин отклонения результатов от эталонных;

реализацию корректировки программы, обеспечивающую соответствие программы заданному эталону.

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

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

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

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

5.3 Особенности задачи в приложении к тестированию программ

5.3.1 Особенности среды программирования

Среда программирования Microsoft Visual Studio 6.0 и язык программирования в ней Microsoft Visual C++ имеют ряд особенностей, влияющих на тестирование программ:

Visual C++ является языком программирования высокого уровня, что сильно увеличивает значимость статического (символьного) тестирования;

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

Visual Studio имеет развитую систему автоматической символьной проверки. Она на этапе написания программы следит за корректностью вводимого текста и обнаруживает все синтаксические ошибки;

в комплект Visual Studio входит множество утилит для отладки, значительно облегчающих процесс тестирования программного обеспечения;

большую часть структуры программы в Visual C++ with Microsoft Foundation Classes занимают стандартные, автоматически создаваемые объекты, управляющие работой программы в ответ на действия пользователя. Поэтому ошибки в основном содержатся в алгоритмах процедур, написанных программистом.

5.3.2 Основные факторы, влияющие на надежность разрабатываемой системы

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

корректность структуры программы;

корректность обработки данных;

устойчивость к ошибочному вводу данных пользователем.

Устойчивость к ошибочному вводу данных пользователем осуществлена при помощи стандартных программных средств, реализованных в библиотеке MFC. Вводятся следующие ограничения на поля данных:

недопустимо непустое значение поля данных;

недопустимо значение поля данных, не входящее в заданный интервал допустимых значений.

В случае ввода неверных данных пользователю выводится на экран соответствующее сообщение.

5.3.2.1 Контроль структуры программы

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

Суть критерия состоит в выборе и анализе базовых маршрутов в программе, формируемых и оцениваемых на основе определения цикломатического числа исходного графа, определяющего структуру программы или ее фрагмента. Критерий наиболее широко применяется для оценки сложности и корректности тестирования программных модулей. Для определения цикломатического числа Z исходного графа фрагмента программы используется полное число его вершин N_п, связывающих их дуг Y и связных компонент L: Z = Y - N_п + L. Вычисление цикломатического числа осуществляется по величинам, определяемым по максимально связному графу, который получается из исходного путем замыкания дуги из конечной вершины в начальную. В результате в максимально связном графе появляются маршруты между любыми двумя вершинами. При этом предполагается, что исходный граф корректен, т.е. не содержит "висячих" и "тупиковых" вершин. В таком графе цикломатическое число равно максимальному количеству его линейно-независимых маршрутов. Величина L соответствует количеству связных компонент всего исходного графа, и обычно для графов не содержащих полностью независимых частей L=1. Иначе говоря, L измеряется количеством замыкающих дуг, необходимых для преобразования исходного графа в максимально сильно связный граф.

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

1) qtyCompl=operations.Qty();

2) if (!flags) {

Характеристики

Список файлов ВКР