Настоящий стандарт устанавливает общие положения по оценке качества программных средств вычислительной техники (далее — ПС), поставляемых через фонды алгоритмов и программ (ФАП), номенклатуру и применяемость показателей качества ПС.
Термины, применяемые в стандарте, и пояснения к ним приведены в приложении 1.
1 . ОБЩИЕ ПОЛОЖЕНИЯ
1.1 . Оценка качества осуществляется на всех этапах жизненного цикла ПС при:
— планировании показателей качества ПС;
— контроле качества на отдельных этапах разработки (техническое задание, технический проект, рабочий проект);
— контроле качества в процессе производства ПС;
— проверке эффективности модификации ПС на этапе сопровождения.
1.2 . Оценка качества ПС представляет собой совокупность операций, включающих выбор номенклатуры показателей качества оцениваемого ПС, определение значений этих показателей и сравнение их с базовыми значениями.
1.3 . Оценку качества проводят специалисты организаций:
— разработчика — на этапах разработки ПС;
Простые показатели качества модели регрессии (R2, критерии Акаике и Шварца)
— фондодержателя — на этапах приемки ПС в фонд;
— испытательных центров и центров сертификации ПС — на этапах испытаний и внедрения;
— изготовителя — на этапах тиражирования ПС;
— пользователя — на этапах внедрения, сопровождения и эксплуатации ПС.
1.4 . Основные задачи, решаемые при оценке качества ПС:
— планирование уровня качества;
— контроль значений показателей качества в процессе разработки и испытаний;
— эксплуатационный контроль заданного уровня качества;
— выбор базовых образцов по подклассам и группам;
— методическое руководство разработкой нормативно-технических документов по оценке качества.
1.5 . Методы определения показателей качества ПС различаются:
— по способам получения информации о ПС — измерительный, регистрационный, органолептический, расчетный;
— по источникам получения информации — традиционный, экспертный, социологический.
1.5.1 . Измерительный метод основан на получении информации о свойствах и характеристиках ПС с использованием инструментальных средств. Например, с использованием этого метода определяется объем ПС — число строк исходного текста программ и число строк — комментариев, число операторов и операндов, число исполненных операторов, число ветвей в программе, число точек входа (выхода), время выполнения ветви программы, время реакции и другие показатели.
1.5.2 . Регистрационный метод основан на получении информации во время испытаний или функционирования ПС, когда регистрируются и подсчитываются определенные события, например, время и число сбоев и отказов, время передачи управления другим модулям, время начала и окончания работы.
1.5.3 . Органолептический метод основан на использовании информации, получаемой в результате анализа восприятия органов чувств (зрения, слуха), и применяется для определения таких показателей как удобство применения, эффективность и т.п.
1.5.4 . Расчетный метод основан на использовании теоретических и эмпирических зависимостей (на ранних этапах разработки), статистических данных, накапливаемых при испытаниях, эксплуатации и сопровождении ПС. При помощи расчетного метода определяются длительность и точность вычислений, время реакции, необходимые ресурсы.
Оценка качества дошкольного образования и использование ее результатов для развития ОО
1.5.5 . Определение значений показателей качества ПС экспертным методом осуществляется группой экспертов-специалистов, компетентных в решении данной задачи, на базе их опыта и интуиции.
Экспертный метод применяется в случаях, когда задача не может быть решена никаким другим из существующих способов или другие способы являются значительно более трудоемкими. Экспертный метод рекомендуется применять при определении показателей наглядности, полноты и доступности программной документации, легкости освоения, структурности.
1.5.6 . Социологические методы основаны на обработке специальных анкет-вопросников.
2 . НОМЕНКЛАТУРА ПОКАЗАТЕЛЕЙ КАЧЕСТВА ПРОГРАММНЫХ СРЕДСТВ
2.1 . Номенклатура показателей качества и характеризуемые ими свойства программных средств приведены в табл. 1 , где представлены 2 уровня иерархической структуры показателей качества ПС:
Наименование групп и комплексных показателей качества
1 . Показатели надежности ПС
Характеризуют способность ПС в конкретных областях применения выполнять заданные функции в соответствии с программными документами в условиях возникновения отклонений в среде функционирования, вызванных сбоями технических средств, ошибками во входных данных, ошибками обслуживания и другими дестабилизирующими воздействиями
1.1 . Устойчивость функционирования
Способность обеспечивать продолжение работы программы после возникновения отклонений, вызванных сбоями технических средств, ошибками во входных данных и ошибками обслуживания
Способность программы функционировать в заданных режимах и объемах обрабатываемой информации в соответствии с программными документами при отсутствии сбоев технических средств
2 . Показатели сопровождения
Характеризуют технологические аспекты, обеспечивающие простоту устранения ошибок в программе и программных документах и поддержания ПС в актуальном состоянии
Организация всех взаимосвязанных частей программы в единое целое с использованием логических структур «последовательность», «выбор», «повторение»
2.2 . Простота конструкции
Построение модульной структуры программы наиболее рациональным с точки зрения восприятия и понимания образом
Наличие и представление в наиболее легко воспринимаемом виде исходных модулей ПС, полное их описание в соответствующих программных документах
Степень использования типовых проектных решений или компонентов, входящих в ПС
3 . Показатели удобства применения
Характеризуют свойства ПС, способствующие быстрому освоению, применению и эксплуатации ПС с минимальными трудозатратами с учетом характера решаемых задач и требований к квалификации обслуживающего персонала
3.1 . Легкость освоения
Представление программных документов и программ в виде, способствующем пониманию логики функционирования программы в целом и ее частей
3.2 . Доступность эксплуатационных программных документов
Понятность, наглядность и полнота описания взаимодействия пользователя с программой в эксплуатационных программных документах
3.3 . Удобство эксплуатации и обслуживания
Соответствие процесса обработки данных и форм представления результатов характеру решаемых задач
4 . Показатели эффективности
Характеризуют степень удовлетворения потребности пользователя в обработке данных с учетом экономических, вычислительных и людских ресурсов
4.1 . Уровень автоматизации
Уровень автоматизации функций процесса обработки данных с учетом рациональности функциональной структуры программы с точки зрения взаимодействия с ней пользователя и использования вычислительных ресурсов
4.2 . Временная эффективность
Способность программы выполнять заданные действия в интервал времени, отвечающий заданным требованиям
Минимально необходимые вычислительные ресурсы и число обслуживающего персонала для эксплуатации ПС
5 . Показатели универсальности
Характеризуют адаптируемость ПС к новым функциональным требованиям, возникающим вследствие изменения области применения или других условий функционирования
Возможность использования ПС в различных областях применения
Возможность применения ПС без существенных дополнительных трудозатрат на ЭВМ аналогичного класса
Обеспечение простоты внесения необходимых изменений и доработок в программу в процессе эксплуатации
6 . Показатели корректности
Характеризуют степень соответствия ПС требованиям, установленным в ТЗ, требованиям к обработке данных и общесистемным требованиям
6.1 . Полнота реализации
Полнота реализации заданных функций ПС и достаточность их описания в программной документации
Однозначное, непротиворечивое описание и использование тождественных объектов, функций, терминов, определений, идентификаторов и т.д. в различных частях программных документов и текста программы
6.3 . Логическая корректность
Функциональное и программное соответствие процесса обработки данных при выполнении задания общесистемным требованиям
Полнота проверки возможных маршрутов выполнения программы в процессе тестирования
— первый уровень определяет группы показателей качества ПС, характеризующие потребительски-ориентированные свойства, которые соответствуют потребностям населения, народного хозяйства и экспорта продукции;
— второй уровень определен комплексными показателями качества ПС, характеризующими программно-ориентированные свойства, которые обеспечивают достижение требуемых потребительски-ориентированных свойств.
2.2 . Выбор номенклатуры показателей качества для конкретного ПС осуществляется с учетом его назначения и требований областей применения. В табл. 2 представлена рекомендуемая применяемость показателей качества в зависимости от принадлежности ПС к тому или иному подклассу (группе) в соответствии с общесоюзным классификатором продукции.
2.3 . Выбранная номенклатура показателей качества фиксируется в ТЗ на разработку ПС.
Номер показателя по табл. 1
Применяемость показателя по подклассам (группам) ПС
Источник: znaytovar.ru
1.2.Критерии качества программ
Можно выделить целый ряд критериев качества программы. Вот некоторые из наиболее существенных критериев:
- Корректность – программа должна работать правильно при любых исходных данных.
- Эффективность – программа должна использовать, по возможности, минимальное количество ресурсов (память, время и др.).
- Эргономичность – программа должна быть удобной для пользователя.
- Читабельность – текст программы должен быть понятен для программиста.
- Портируемость — программа после незначительных изменений способна работать на компьютерной платформе отличной от исходной платформы.
1.3.Низкоуровневые и высокоуровневые языки программирования
Низкоуровневый язык программирования (язык программирования низкого уровня) это язык программирования, близкий к программированию непосредственно в машинных кодах используемого реального или виртуального (например, Java, Microsoft .NET) процессора. Для обозначения машинных команд обычно применяется мнемоническое обозначение. Это позволяет запоминать команды не в виде последовательности двоичных нулей и единиц, а в виде осмысленных сокращений слов естественного языка.
Общеизвестный пример низкоуровнего языка — язык ассемблера. Точнее это группа языков. Для каждого типа процессора существует свой ассемблер. Более того, для одного и того же процессора может существовать несколько видов языка ассемблера. Они совпадают в машинных командах, но различаются набором дополнительных функций -директив и макросов.
Также к языкам низкого уровня условно можно причислить CIL, применяемый в платформе Microsoft .NET, Форт, Java байт-код.
Программы, написанные на языках низкого уровня, сложны для понимания, их ручное создание требует больших трудозатрат, но зато использование языков низкого уровня позволяет создавать программы, эффективно использующие вычислительную технику.
Высокоуровневый язык программирования (язык программирования высокого уровня) — язык программирования, разработанный для быстроты и удобства использования программистом. Основная черта высокоуровневых языков — это абстракция, то есть введение смысловых конструкций, кратко описывающих такие структуры данных и операции над ними, описания которых на машинном коде или другом низкоуровневом языке программирования очень длинны и сложны для понимания.
Так, высокоуровневые языки стремятся не только облегчить решение сложных программных задач, но и упростить портирование программного обеспечения. Использование разнообразных трансляторов обеспечивает связь программ, написанных при помощи языков высокого уровня, с различными операционными системами и оборудованием, в то время как их исходный код остаётся, в идеале, неизменным.
Программы, написанные на языках высокого уровня, проще для понимания программистом, но менее эффективны, чем их аналоги, создаваемые при помощи низкоуровневых языков.
Примеры языков высокого уровня: C, C++, Java, Python, PHP, Perl, Basic, Delphi, Lisp.
1.4.Принципы структурного программирования
Структурное программирование — методология разработки программного обеспечения, в основе которой лежит представление программы в виде иерархической структуры блоков. Предложена в 70-х годах XX века Э.Дейкстрой, разработана и дополнена Н. Виртом.
В соответствии с данной методологией
- Любая программа представляет собой структуру, построенную из трёх типов базовых конструкций:
- последовательное исполнение — однократное выполнение операций в том порядке, в котором они записаны в тексте программы;
- ветвление — однократное выполнение одной из двух или более операций, в зависимости от выполнения некоторого заданного условия;
- цикл — многократное исполнение одной и той же операции до тех пор, пока выполняется некоторое заданное условие (условие продолжения цикла).
- В программе базовые конструкции могут быть вложены друг в друга произвольным образом, но никаких других средств управления последовательностью выполнения операций не предусматривается.
- Повторяющиеся фрагменты программы (либо не повторяющиеся, но представляющие собой логически целостные вычислительные блоки) могут оформляться в виде т. н. подпрограмм (процедур или функций). В этом случае в тексте основной программы, вместо помещённого в подпрограмму фрагмента, вставляется инструкция вызова подпрограммы. При выполнении такой инструкции выполняется вызванная подпрограмма, после чего исполнение программы продолжается с инструкции, следующей за командой вызова подпрограммы.
- Разработка программы ведётся пошагово, методом «сверху вниз». Сначала пишется текст основной программы, в котором, вместо каждого связного логического фрагмента текста, вставляется вызов подпрограммы, которая будет выполнять этот фрагмент. Вместо настоящих, работающих подпрограмм, в программу вставляются «заглушки», которые ничего не делают. Полученная программа проверяется и отлаживается. После того, как программист убедится, что подпрограммы вызываются в правильной последовательности (то есть общая структура программы верна), подпрограммы-заглушки последовательно заменяются на реально работающие, причём разработка каждой подпрограммы ведётся тем же методом, что и основной программы. Разработка заканчивается тогда, когда не останется ни одной «заглушки», которая не была бы удалена. Такая последовательность гарантирует, что на каждом этапе разработки программист одновременно имеет дело с обозримым и понятным ему множеством фрагментов, и может быть уверен, что общая структура всех более высоких уровней программы верна. При сопровождении и внесении изменений в программу выясняется, в какие именно процедуры нужно внести изменения, и они вносятся, не затрагивая части программы, непосредственно не связанные с ними. Это позволяет гарантировать, что при внесении изменений и исправлении ошибок не выйдет из строя какая-то часть программы, находящаяся в данный момент вне зоны внимания программиста.
Источник: studfile.net
Тестирование программного обеспечения
Для нетривиальных классов программ в общем случае не существует полного и надежного критерия, зависящего от программ или спецификаций.
Поэтому мы стремимся к идеальному общему критерию через реальные частные.
Классы критериев
- Структурные
- Функциональные
- Критерии стохастического тестирования формулируются в терминах проверки наличия заданных свойств у тестируемого приложения, средствами проверки некоторой статистической гипотезы.
- Мутационные критерии ориентированы на проверку свойств программного изделия на основе подхода Монте-Карло.
Структурные критерии
— используют модель программы в виде «белого ящика», что предполагает знание исходного текста программы или спецификации программы в виде потокового графа управления. Данный класс критериев часто используется на этапах модульного и интеграционного тестирования (Unit testing, Integration testing)
Структурные критерии базируются на основных элементах УГП (управляющий граф программы), операторах, ветвях и путях.
• Условие критерия тестирования команд (критерий С0) — набор тестов в совокупности должен обеспечить прохождение каждой команды не менее одного раза. Это слабый критерий, он, как правило, используется в больших программных системах, где другие критерии применить невозможно.
• Условие критерия тестирования ветвей (критерий С1) — набор тестов в совокупности должен обеспечить прохождение каждой ветви не менее одного раза. Это достаточно сильный и при этом экономичный критерий, поскольку множество ветвей в тестируемом приложении конечно и не так уж велико. Данный критерий часто используется в системах автоматизации тестирования.
• Условие критерия тестирования путей (критерий С2) — набор тестов в совокупности должен обеспечить прохождение каждого пути не менее 1 раз. Если программа содержит цикл (в особенности с неявно заданным числом итераций), то число итераций ограничивается константой (часто — 2, или числом классов выходных путей)..
Функциональные критерии
— важнейший для программной индустрии критерий тестирования. Он обеспечивает, прежде всего, контроль степени выполнения требований заказчика в программном продукте. Отражают взаимодействие тестируемого приложения с окружением. Используется модель «черного ящика». Проблема:трудоемкость; дело в том, что документы, фиксирующие требования к программному изделию (Software requirement specification, Functional specification и т.п.), достаточно объемны.
• Тестирование пунктов спецификации — набор тестов в совокупности должен обеспечить проверку каждого тестируемого пункта не менее одного раза.
• Тестирование классов входных данных — набор тестов в совокупности должен обеспечить проверку представителя каждого класса входных данных не менее одного раза. При создании тестов классы входных данных сопоставляются с режимами использования тестируемого компонента или подсистемы приложения, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов. Следует заметить, что мы вынуждены применять мощные тестовые наборы. Действительно, наряду с ограничениями на величины входных данных, существуют ограничения на величины входных данных во всевозможных комбинациях, в том числе проверка реакций системы на появление ошибок в значениях или структурах входных данных. Учет этого многообразия — процесс трудоемкий, что создает сложности для применения критерия
• Тестирование правил — набор тестов в совокупности должен обеспечить проверку каждого правила, если входные и выходные значения описываются набором правил некоторой грамматики.
• Тестирование классов выходных данных — набор тестов в совокупности должен обеспечить проверку представителя каждого выходного класса, при условии, что выходные результаты заранее расклассифицированы, причем отдельные классы результатов учитывают, в том числе, ограничения на ресурсы или на время (time out). При создании тестов классы выходных данных сопоставляются с режимами использования тестируемого компонента или подсистемы, что заметно сокращает варианты перебора, учитываемые при разработке тестовых наборов.
• Тестирование функций — набор тестов в совокупности должен обеспечить проверку каждого действия, реализуемого тестируемым модулем, не менее одного раза. Не обеспечивает покрытия части функциональности тестируемого компонента, связанной со структурными и поведенческими свойствами, описание которых не сосредоточено в отдельных функциях (т.е. описание рассредоточено по компоненту). Критерий тестирования функций объединяет отчасти особенности структурных и функциональных критериев. Он базируется на модели «полупрозрачного ящика», где явно указаны не только входы и выходы тестируемого компонента, но также состав и структура используемых методов (функций, процедур) и классов.
• Комбинированные критерии для программ и спецификаций — набор тестов в совокупности должен обеспечить проверку всех комбинаций непротиворечивых условий программ и спецификаций не менее одного раза.
Стохастические критерии
— применяется при тестировании сложных программных комплексов — когда набор детерминированных тестов имеет громадную мощность. В случаях, когда подобный набор невозможно разработать и исполнить на фазе тестирования
Необходимо разработать программы — имитаторы случайных последовательностей входных сигналов. Вычислить независимым способом значения для соответствующих входных сигналов и получить тестовый набор (X,Y). Протестировать приложение на тестовом наборе (X,Y), используя два способа контроля результатов:
• Детерминированный контроль — проверка соответствия вычисленного значения y значению y, полученному в результате прогона теста на наборе — случайной последовательности входных сигналов, сгенерированной имитатором.
• Стохастический контроль — проверка соответствия множества значений , полученного в результате прогона тестов на наборе входных значений , заранее известному распределению результатов F(Y).
В этом случае множество Y неизвестно (его вычисление невозможно), но известен закон распределения данного множества..
Критерии стохастического тестирования
• Cтатистические методы окончания тестирования — стохастические методы принятия решений о совпадении гипотез о распределении случайных величин. К ним принадлежат широко известные: метод Стьюдента, метод Хи-квадрат.
• Метод оценки скорости выявления ошибок — основан на модели скорости выявления ошибок, согласно которой тестирование прекращается, если оцененный интервал времени между текущей ошибкой и следующей слишком велик для фазы тестирования приложения.
Мутационный критерий
— постулируется, что профессиональные программисты пишут сразу почти правильные программы, отличающиеся от правильных мелкими ошибками или описками типа — перестановка местами максимальных значений индексов в описании массивов, ошибки в знаках арифметических операций, занижение или завышение границы цикла на 1 и т.п. Предлагается подход, позволяющий на основе мелких ошибок оценить общее число ошибок, оставшихся в программе.
Мутации — мелкие ошибки в программе.
Мутанты — программы, отличающиеся друг от друга мутациями.
Метод мутационного тестирования — в разрабатываемую программу P вносят мутации, т.е. искусственно создают программы-мутанты P1, P2. Затем программа P и ее мутанты тестируются на одном и том же наборе тестов (X,Y).
Если на наборе (X,Y) подтверждается правильность программы P и, кроме того, выявляются все внесенные в программы-мутанты ошибки, то набор тестов (X,Y) соответствует мутационному критерию, а тестируемая программа объявляется правильной.
Источник: testirovanieprob.blogspot.com