Ошибки ПО являются функцией от входной информации и состояния системы. Ошибки несут систематический характер.
Надежность ПО базируется на понятиях корректности и устойчивости.
Программа считается корректной, если она выполняет запланированные действия и не имеет побочных эффектов. Корректность – узкое понятие, т.к. ее полная проверка для большинства программных систем практически невыполнима. Корректность базируется на тщательной спецификации требований пользователя. Возможна ситуация, когда программа корректна с точки зрения разработчика, но некорректна с точки зрения пользователя. Если ПО удовлетворяет своей спецификации, то оно корректно. Систему можно считать надежной, если велика вероятность того, что при обращении к ней можно получить требуемую услугу. Программа рассматривается как ненадежная, если она допускает сбои в особых ситуациях, даже если эти ситуации имеют небольшой процент от времени пользования системой.
Под устойчивостью программы понимается ее способность выполнять правильное действие при наличии отказов в работе аппаратуры и ошибках в исходных данных. При оценке устойчивости должны быть заданы параметры окружающей среды , по отношению к которым программа должна быть устойчивой. Обычно разработчик ПО не располагает средствами эффективного контроля за окружающей средой и его задача сводится к локализации нарушений или изменения характеристик окружающей среды и описанию способов их устранения.
Под надежностью ПО понимается свойство ПО выполнять предписанные функции в соответствии с требованиями заказчика при определенных условиях функционирования в течение заданного времени и обусловленное корректностью и устойчивостью.
Критерии надежности
Критерии надежности – это показатели, позволяющие оценивать предпочтительность тех или иных решений при создании и эксплуатации систем по степени достижения основных целей и с учетом затрат, при которых эти цели достигаются [4].
21
При исследовании надежности основная цель состоит в разработке эффективных методов и обеспечении длительной работоспособности систем с заданными функциональными характеристиками.
Основной задачей теории надежности остается оценка технических решений, позволяющих создать систему с заданными показателями надежности и заданными совокупными затратами.
Критерии:
Детерминированные – оценка количества ошибок в программе на том или ином этапе работы.
Вероятностные – вероятностная оценка свойств ПО.
Все ошибки носят детерминированный характер, но вероятностным оказывается процесс внесения ошибок. Проявление ошибок также носит вероятностный характер.
Примеры критериев:
Корректность ПО.
Число серьезных текущих ошибок в программе и время, необходимое для их устранения.
Обслуживаемость системы – степень влияния ошибок ПО на обслуживаемость системы.
Безопасность системы. Частота отказов.
Вероятность безотказной работы за время t при условии времени отладки
.
Средняя наработка на программный отказ при условии исправления или неисправления обнаруженных отказов.
Верификация программ – процесс формального доказательства правильности программы, т.е. корректности.
Верификация:
Статическая.
Динамическая (частный случай – тестирование).
С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:
1. Разработанное ПО в начальной стадии эксплуатации может потребовать менее жестких критериев и большего времени для его совершенствования.
22
2.После выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО.
3.Имеют место разбросы, вызываемые различием в условиях применения и использования ПО.
4.Эффективность работ по исправлению ошибок, проводимых разработчиками ПО, зависит от частоты проявления ошибок, что, в свою очередь, зависит от информации, поступающей от пользователей.
5.Необходимость соблюдения ограничений по быстродействию и производительности, если таковые диктуются пользователями.
Характеристики ПО
1.Количественные характеристики (оцениваются числом): объем программы; количество сопряжений; количество ветвлений; точки входа/выхода; количество процедур; уровень вложения; количество комментариев;
количество страниц документации; требуемое машинное время.
2.Качественные характеристики (оцениваются числом):
трудности проектирования; трудности в эксплуатации из-за ошибок; тип программ;
данные о персонале (количество, коэффициент загруженности).
3.Качественные характеристики как объективное суждение.
23
Испытания ПО
1.Стендовые (многократные проверки в реальных условиях).
2.Приемосдаточные (подтверждение требуемых характеристик и передача в эксплуатацию).
3.Системные (оценивают правильность взаимодействия с другими системами).
4.Демонстрация в реальных условиях.
5.Сертификационные испытания.
Основные параметры персонала
1.Данные, характеризующие программиста.
2.Данные, характеризующие выполнение конкретной работы. В результате формируются критерии, учитывающие конкретно-
го программиста в конкретной работе.
|
Параметры |
Оценка |
Оцениваемые |
||
|
программиста |
факторы |
|||
|
А |
Уровень |
1 – 5 |
1) ОП=А+Б+В+Г |
|
|
знаний |
||||
|
2) ОПКР=(20-Д)*ОП |
||||
|
Б |
Уровень |
1 – 5 |
||
|
способностей |
ОП – оценка |
|||
|
В |
Стиль работы |
1 – 5 |
программиста |
|
|
ОПКР – оценка |
||||
|
Г |
Степень |
1 – 5 |
||
|
программиста |
||||
|
ответственности |
||||
|
и конкретной работы. |
||||
|
Д |
Параметры |
0 – 10 |
||
|
конкретной работы |
||||
24
Цель анализа программных ошибок при сертификации и оценке надежности ПО
Определение структурных свойств программ и характеристик процесса их разработки, влияющих на надежность.
Организация методов сбора данных о надежности. Категоризация возможных программных ошибок по их причи-
нам и проявлениям.
Выработка рекомендаций по совершенствованию бездефектных программ.
Разработка моделей надежности ПО.
Извещения об ошибке
Исходная информация об ошибках может быть представлена в извещении об ошибке. В нем указывается:
1.Объект затруднения (подсистема, БД, ОС и т.д.).
2.Дата и время ошибки.
3.Пример или задача, на которой зафиксирована ошибка.
4.Конфигурация активной структуры ПО.
5.Содержание ошибки.
6.В соответствие ставится извещение о закрытии ошибки, в котором содержится:
информация о закрытии ошибки; генерация новой конфигурации;
правильность распознавания объекта затруднения; существо ошибки.
25
Основные задачи в области надежности ПО (рис. 1.6)
|
Надежность ПО |
|||||
|
Определения |
|||||
|
Корректность |
Устойчивость |
||||
|
Анализ |
Синтез |
||||
|
1 |
2 |
3 |
4 |
5 |
|
|
1.1 |
1.2 |
1.3 |
3.1 |
3.2 |
2.12.2
Рис. 1.6. Основные задачи в области надѐжности ПО
1.Классификация ошибок.
1.1.Организация систем сбора данных.
1.2.Рекомендации по совершенствованию.
1.3.Построение модели.
2.Верификация программ.
2.1.Статическая верификация.
2.2.Динамическая верификация.
3.Тестирование.
3.1.Выбор тестов.
3.2.Управление тестированием.
4.Защита информации.
5.Защита вычислительного процесса.
Количественные вероятностные характеристики надежности ПО
P(t) – вероятность безошибочной работы. Q(t) – вероятность появления ошибок. a(t) Q (t) – частота появления ошибок.
(t) – интенсивность появления ошибок. T0 – среднее время между ошибками.
26
ξk и ξm
Рассмотрим методику вычисления основных параметров. Программа испытывается на одном компьютере.
– время k-го и m-го прогонов, окончившихся отказами. Nотк – количество прогонов, окончившихся отказом.
|
m |
||
|
j 1, Nотк |
j |
l , ξl – время l-го успешного прогона. |
l k 1
υj – время между j-м и (j+1)-м отказами.
– статистическое среднее время между двумя ошибками, N – общее количество прогонов.
–среднее время между двумя ошибками.
–экспоненциальный закон надежности.
|
t |
|
|
(t )dt |
|
|
P(t) e 0 |
– обобщенный закон надежности (λ≠const) |
|
P ( t ) |
||
|
T |
0 |
t |
|
0 |
||
27
Классификация ошибок ПО
Основные проблемы классификации.
1. Где произошла ошибка? 1.1. Персонал.
Информация по категориям персонала включает структуру
ипроцедуры. Это операционные процедуры, правила кодирования
ипроверки, а также стандарты документирования.
1.1.1.Структура.
Технический – для конкретного модуля определяется имя, квалификация разработчика, а именно опыт программирования, знание языков и ответственность.
Административный – определяет административную информацию.
1.1.2.Процедура.
Операционные процедуры включают информацию о рабочей среде, т.е. пакетный или интерактивный режим работы, свободный или ограниченный доступ.
Правила кодирования и проверки. Они содержат информацию о степени использования, например, структурного программирования.
Стандарты документации включают форматы и процедуры документирования данного модуля.
1.2.Оборудование.
1.2.1.Компьютер.
Перечень оборудования и интерфейсов.
1.2.2.Связь.
Содержит информацию о внешнем оборудовании в комплекте ПК, включая линии связи с терминалами.
1.2.3.Сопровождающее обеспечение.
Информация обо всем оборудовании, для подготовки модуля к работе.
1.3.ПО.
1.3.1.Внутреннее ПО.
Языковой процессор, загрузчик, редактор связей, ути-
литы.
28
1.3.2.Применение.
Это размеры, смежные модули, область применения. Каждый из этих разделов обеспечивает идентификацию относящихся к ним программ по имени, номеру версии и т.д.
2.На что похожа ошибка?
2.1.ПО.
2.1.1.Внутреннее ПО.
ОС, редактор связей, загрузчик, утилиты.
2.1.2.Применение.
Каждый ошибочный элемент характеризуется именем, номером версии и будет специфицировать любой ошибочный код и любое диагностическое сообщение, являющееся следствием данной ошибки элемента.
2.2.Функции.
Категория функций идентифицирует с помощью имени точку, в которой зафиксирована ошибка. Эта точка может относиться к процедурам ввода/вывода или использования ресурсов.
2.2.1.Процедура.
В процедурах ввода/вывода подразумевается наличие неправильных значений данных.
2.2.2.Использование ресурса.
При использовании ресурсов наиболее критичными ошибками являются:
неправильное использование терминальных устройств; ошибки синхронизации; ошибки в описании форматов вводимой и выводимой информации.
2.3.Ресурсы.
2.3.1.Имя.
2.3.2.Использование ресурса.
2.4.Область.
2.4.1.Структура программы.
2.4.2.Приложение.
29
3.Как была сделана ошибка?
3.1.Данные.
3.1.1.Входные.
3.1.2.Внутренние.
3.2.Процедуры.
3.2.1.Вычисление.
3.2.2.Контроль.
3.2.3.Интерфейс.
4.Когда была сделана ошибка?
4.1.Начальная разработка.
4.2.Внедрение.
4.3.Функционирование.
5.Почему произошла ошибка?
5.1.Механические причины.
5.1.1.Подстановка.
5.1.2.Путаница.
5.1.3.Пропуск.
5.2.Умственные причины.
5.2.1.Концептуализация.
5.2.2.Реализация.
5.3.Коммуникационные причины.
5.3.1.Персонал.
5.3.2.Документация.
Целью задачи классификации ошибок ПО является создание методов упорядочивания информации о программных ошибках с тем, чтобы на основе этой информации выяснить причины, породившие ненадежность и о путях их предупреждения.
30
Дефекты программного обеспечения можно обнаружить на каждом этапе разработки и тестирования продукта. Чтобы гарантировать исправление наиболее серьезных дефектов программного обеспечения, тестировщикам важно иметь хорошее представление о различных типах дефектов, которые могут возникнуть.
В этой статье мы обсудим самые распространенные типы ПО дефекты и способы их выявления.
Что такое дефект?
Дефект программного обеспечения — это ошибка, изъян, сбой или неисправность в компьютерной программе, из-за которой она выдает неправильный или неожиданный результат или ведет себя непреднамеренным образом. Программная ошибка возникает, когда фактические результаты не совпадают с ожидаемыми. Разработчики и программисты иногда допускают ошибки, которые создают ошибки, называемые дефектами. Большинство ошибок возникает из-за ошибок, которые допускают разработчики или программисты.
Обязательно прочтите: Разница между дефектом, ошибкой, ошибкой и сбоем
Типы программных ошибок при тестировании программного обеспечения
Существует множество различных типов дефектов программного обеспечения, и тестировщикам важно знать наиболее распространенные из них, чтобы они могут эффективно тестировать их.
Ошибки программного обеспечения подразделяются на три типа:
- Дефекты программного обеспечения по своей природе
- Дефекты программного обеспечения по их приоритету
- Дефекты программного обеспечения по их серьезности
Обычно мы можем видеть приоритет и серьезность классификаторов в большинстве инструментов отслеживания ошибок. Если мы настроим классификатор в соответствии с характером ошибки, а также приоритетом и серьезностью, это поможет легко управлять распределением обязанностей по исправлению ошибок соответствующим командам.
#1. Дефекты программного обеспечения по своей природе
Ошибки в программном обеспечении имеют широкий спектр природы, каждая из которых имеет свой собственный набор симптомов. Несмотря на то, что таких багов много, сталкиваться с ними можно не часто. Вот наиболее распространенные ошибки программного обеспечения, классифицированные по характеру, с которыми вы, скорее всего, столкнетесь при тестировании программного обеспечения.
#1. Функциональные ошибки
Как следует из названия, функциональные ошибки — это те, которые вызывают сбои в работе программного обеспечения. Хорошим примером этого может служить кнопка, при нажатии на которую должно открываться новое окно, но вместо этого ничего не происходит.
Функциональные ошибки можно исправить, выполнив функциональное тестирование.
#2. Ошибки на уровне модуля
Ошибки на уровне модуля — это дефекты, связанные с функциональностью отдельного программного модуля. Программный модуль — это наименьшая тестируемая часть приложения. Примеры программных модулей включают классы, методы и процедуры. Ошибки на уровне подразделения могут существенно повлиять на общее качество программного обеспечения.
Ошибки на уровне модуля можно исправить, выполнив модульное тестирование.
#3. Ошибки уровня интеграции
Ошибки уровня интеграции — это дефекты, возникающие при объединении двух или более программных модулей. Эти дефекты может быть трудно найти и исправить, потому что они часто требуют координации между несколькими командами. Однако они могут оказать существенное влияние на общее качество программного обеспечения.
Ошибки интеграции можно исправить, выполнив интеграционное тестирование.
#4. Дефекты юзабилити
Ошибки юзабилити — это дефекты, влияющие на работу пользователя с программным обеспечением и затрудняющие его использование. Дефект юзабилити — это дефект пользовательского опыта программного обеспечения, который затрудняет его использование. Ошибки юзабилити — это такие ошибки, как если веб-сайт сложен для доступа или обойти, или процесс регистрации сложен для прохождения.
Во время тестирования удобства использования тестировщики программного обеспечения проверяют приложения на соответствие требованиям пользователей и Руководству по доступности веб-контента (WCAG) для выявления таких проблем. Однако они могут оказать существенное влияние на общее качество программного обеспечения.
Ошибки, связанные с удобством использования, можно исправить, выполнив тестирование удобства использования.
#5. Дефекты производительности
Ошибки производительности — это дефекты, влияющие на производительность программного обеспечения. Это может включать в себя такие вещи, как скорость программного обеспечения, объем используемой памяти или количество потребляемых ресурсов. Ошибки уровня производительности сложно отследить и исправить, поскольку они могут быть вызваны рядом различных факторов.
Ошибки юзабилити можно исправить, выполнив тестирование производительности.
#6. Дефекты безопасности
Ошибки безопасности — это тип дефекта программного обеспечения, который может иметь серьезные последствия, если его не устранить. Эти дефекты могут позволить злоумышленникам получить доступ к конфиденциальным данным или системам или даже позволить им получить контроль над уязвимым программным обеспечением. Таким образом, очень важно, чтобы ошибкам уровня безопасности уделялось первоочередное внимание и устранялись как можно скорее.
Ошибки безопасности можно исправить, выполнив тестирование безопасности.
#7. Дефекты совместимости
Дефекты совместимости — это те ошибки, которые возникают, когда приложение несовместимо с оборудованием, на котором оно работает, или с другим программным обеспечением, с которым оно должно взаимодействовать. Несовместимость программного и аппаратного обеспечения может привести к сбоям, потере данных и другому непредсказуемому поведению. Тестировщики должны знать о проблемах совместимости и проводить соответствующие тесты. Программное приложение, имеющее проблемы с совместимостью, не работает последовательно на различных видах оборудования, операционных системах, веб-браузерах и устройствах при подключении к определенным программам или работе в определенных сетевых условиях.
Ошибки совместимости можно исправить, выполнение тестирования совместимости.
#8. Синтаксические ошибки
Синтаксические ошибки являются самым основным типом дефекта. Они возникают, когда код нарушает правила языка программирования. Например, использование неправильной пунктуации или забывание закрыть скобку может привести к синтаксической ошибке. Синтаксические ошибки обычно мешают запуску кода, поэтому их относительно легко обнаружить и исправить.
#9. Логические ошибки
Логические ошибки — это дефекты, из-за которых программа выдает неправильные результаты. Эти ошибки может быть трудно найти и исправить, потому что они часто не приводят к каким-либо видимым ошибкам. Логические ошибки могут возникать в любом типе программного обеспечения, но они особенно распространены в приложениях, требующих сложных вычислений или принятия решений.
Общие симптомы логических ошибок включают:
- Неверные результаты или выходные данные
- Неожиданное поведение
- Сбой или зависание программного обеспечения
Чтобы найти и исправить логические ошибки, тестировщикам необходимо иметь четкое представление о коде программы и о том, как она должна работать. Часто лучший способ найти такие ошибки — использовать инструменты отладки или пошаговое выполнение, чтобы отслеживать выполнение программы и видеть, где что-то идет не так.
#2. Дефекты программного обеспечения по степени серьезности
Уровень серьезности присваивается дефекту по его влиянию. В результате серьезность проблемы отражает степень ее влияния на функциональность или работу программного продукта. Дефекты серьезности классифицируются как критические, серьезные, средние и незначительные в зависимости от степени серьезности.
#1. Критические дефекты
Критический дефект — это программная ошибка, имеющая серьезные или катастрофические последствия для работы приложения. Критические дефекты могут привести к сбою, зависанию или некорректной работе приложения. Они также могут привести к потере данных или уязвимостям в системе безопасности. Разработчики и тестировщики часто придают первостепенное значение критическим дефектам, поскольку их необходимо исправить как можно скорее.
#2. Серьезные дефекты
Серьезный дефект — это программная ошибка, существенно влияющая на работу приложения. Серьезные дефекты могут привести к замедлению работы приложения или другому неожиданному поведению. Они также могут привести к потере данных или уязвимостям в системе безопасности. Разработчики и тестировщики часто придают первостепенное значение серьезным дефектам, поскольку их необходимо исправить как можно скорее.
#3. Незначительные дефекты
Незначительный дефект — это программная ошибка, которая оказывает небольшое или незначительное влияние на работу приложения. Незначительные дефекты могут привести к тому, что приложение будет работать немного медленнее или демонстрировать другое неожиданное поведение. Разработчики и тестировщики часто не придают незначительным дефектам приоритет, потому что их можно исправить позже.
#4. Тривиальные дефекты
Тривиальный дефект – это программная ошибка, не влияющая на работу приложения. Тривиальные дефекты могут привести к тому, что приложение отобразит сообщение об ошибке или проявит другое неожиданное поведение. Разработчики и тестировщики часто присваивают тривиальным дефектам самый низкий приоритет, потому что они могут быть исправлены позже.
#3. Дефекты программного обеспечения по приоритету
#1. Дефекты с низким приоритетом
Дефекты с низким приоритетом, как правило, не оказывают серьезного влияния на работу программного обеспечения и могут быть отложены для исправления в следующей версии или выпуске. В эту категорию попадают косметические ошибки, такие как орфографические ошибки, неправильное выравнивание и т. д.
#2. Дефекты со средним приоритетом
Дефекты со средним приоритетом — это ошибки, которые могут быть исправлены после предстоящего выпуска или в следующем выпуске. Приложение, возвращающее ожидаемый результат, которое, однако, неправильно форматируется в конкретном браузере, является примером дефекта со средним приоритетом.
#3. Дефекты с высоким приоритетом
Как следует из названия, дефекты с высоким приоритетом — это те, которые сильно влияют на функционирование программного обеспечения. В большинстве случаев эти дефекты необходимо исправлять немедленно, так как они могут привести к серьезным нарушениям нормального рабочего процесса. Дефекты с высоким приоритетом обычно классифицируются как непреодолимые, так как они могут помешать пользователю продолжить выполнение поставленной задачи.
Некоторые распространенные примеры дефектов с высоким приоритетом включают:
- Дефекты, из-за которых приложение не работает. сбой
- Дефекты, препятствующие выполнению задачи пользователем
- Дефекты, приводящие к потере или повреждению данных
- Дефекты, раскрывающие конфиденциальную информацию неавторизованным пользователям
- Дефекты, делающие возможным несанкционированный доступ к системе
- Дефекты, приводящие к потере функциональности
- Дефекты, приводящие к неправильным результатам или неточным данным
- Дефекты, вызывающие проблемы с производительностью, такие как чрезмерное использование памяти или медленное время отклика
#4. Срочные дефекты
Срочные дефекты — это дефекты, которые необходимо устранить в течение 24 часов после сообщения о них. В эту категорию попадают дефекты со статусом критической серьезности. Однако дефекты с низким уровнем серьезности также могут быть классифицированы как высокоприоритетные. Например, опечатка в названии компании на домашней странице приложения не оказывает технического влияния на программное обеспечение, но оказывает существенное влияние на бизнес, поэтому считается срочной.
#4. Дополнительные дефекты
#1. Отсутствующие дефекты
Отсутствующие дефекты возникают из-за требований, которые не были включены в продукт. Они также считаются несоответствиями спецификации проекта и обычно негативно сказываются на пользовательском опыте или качестве программного обеспечения.
#2. Неправильные дефекты
Неправильные дефекты — это те дефекты, которые удовлетворяют требованиям, но не должным образом. Это означает, что хотя функциональность достигается в соответствии с требованиями, но не соответствует ожиданиям пользователя.
#3. Дефекты регрессии
Дефект регрессии возникает, когда изменение кода вызывает непреднамеренное воздействие на независимую часть программного обеспечения.
Часто задаваемые вопросы — Типы программных ошибок< /h2>
Почему так важна правильная классификация дефектов?
Правильная классификация дефектов важна, поскольку она помогает эффективно использовать ресурсы и управлять ими, правильно приоритизировать дефекты и поддерживать качество программного продукта.
Команды тестирования программного обеспечения в различных организациях используют различные инструменты отслеживания дефектов, такие как Jira, для отслеживания дефектов и управления ими. Несмотря на то, что в этих инструментах есть несколько вариантов классификации дефектов по умолчанию, они не всегда могут наилучшим образом соответствовать конкретным потребностям организации.
Следовательно, важно сначала определить и понять типы дефектов программного обеспечения, которые наиболее важны для организации, а затем соответствующим образом настроить инструмент управления дефектами.
Правильная классификация дефектов также гарантирует, что команда разработчиков сможет сосредоточиться на критических дефектах и исправить их до того, как они повлияют на конечных пользователей.
Кроме того, это также помогает определить потенциальные области улучшения в процессе разработки программного обеспечения, что может помочь предотвратить появление подобных дефектов в будущих выпусках.
Таким образом, отслеживание и устранение дефектов программного обеспечения может показаться утомительной и трудоемкой задачей. , правильное выполнение может существенно повлиять на качество конечного продукта.
Как найти лежащие в основе ошибки программного обеспечения?
Определение основной причины программной ошибки может быть сложной задачей даже для опытных разработчиков. Чтобы найти лежащие в основе программные ошибки, тестировщики должны применять систематический подход. В этот процесс входят различные этапы:
1) Репликация. Первым этапом является воспроизведение ошибки. Это включает в себя попытку воспроизвести тот же набор шагов, в котором возникла ошибка. Это поможет проверить, является ли ошибка реальной или нет.
2) Изоляция. После того, как ошибка воспроизведена, следующим шагом будет попытка ее изоляции. Это включает в себя выяснение того, что именно вызывает ошибку. Для этого тестировщики должны задать себе несколько вопросов, например:
– Какие входные данные вызывают ошибку?
– При каких различных условиях возникает ошибка?
– Каковы различные способы проявления ошибки?
3) Анализ: после Изолируя ошибку, следующим шагом будет ее анализ. Это включает в себя понимание того, почему возникает ошибка. Тестировщики должны задать себе несколько вопросов, таких как:
– Какова основная причина ошибки?
– Какими способами можно исправить ошибку?
– Какое исправление было бы наиболее эффективным? эффективно?
4) Отчет. После анализа ошибки следующим шагом является сообщение о ней. Это включает в себя создание отчета об ошибке, который включает всю соответствующую информацию об ошибке. Отчет должен быть четким и кратким, чтобы разработчики могли его легко понять.
5) Проверка. После сообщения об ошибке следующим шагом является проверка того, была ли она исправлена. Это включает в себя повторное тестирование программного обеспечения, чтобы убедиться, что ошибка все еще существует. Если ошибка исправлена, то тестер может подтвердить это и закрыть отчет об ошибке. Если ошибка все еще существует, тестировщик может повторно открыть отчет об ошибке.
Заключение
В индустрии программного обеспечения дефекты — неизбежная реальность. Однако благодаря тщательному анализу и пониманию их характера, серьезности и приоритета дефектами можно управлять, чтобы свести к минимуму их влияние на конечный продукт.
Задавая правильные вопросы и применяя правильные методы, тестировщики могут помочь обеспечить чтобы дефекты обнаруживались и исправлялись как можно раньше в процессе разработки.
TAG: qa
Ошибки ПО являются функцией от входной информации и состояния системы. Ошибки несут систематический характер.
Надежность ПО базируется на понятиях корректности и устойчивости.
Программа считается корректной, если она выполняет запланированные действия и не имеет побочных эффектов. Корректность – узкое понятие, т.к. ее полная проверка для большинства программных систем практически невыполнима. Корректность базируется на тщательной спецификации требований пользователя. Возможна ситуация, когда программа корректна с точки зрения разработчика, но некорректна с точки зрения пользователя. Если ПО удовлетворяет своей спецификации, то оно корректно. Систему можно считать надежной, если велика вероятность того, что при обращении к ней можно получить требуемую услугу. Программа рассматривается как ненадежная, если она допускает сбои в особых ситуациях, даже если эти ситуации имеют небольшой процент от времени пользования системой.
Под устойчивостью программы понимается ее способность выполнять правильное действие при наличии отказов в работе аппаратуры и ошибках в исходных данных. При оценке устойчивости должны быть заданы параметры окружающей среды , по отношению к которым программа должна быть устойчивой. Обычно разработчик ПО не располагает средствами эффективного контроля за окружающей средой и его задача сводится к локализации нарушений или изменения характеристик окружающей среды и описанию способов их устранения.
Под надежностью ПО понимается свойство ПО выполнять предписанные функции в соответствии с требованиями заказчика при определенных условиях функционирования в течение заданного времени и обусловленное корректностью и устойчивостью.
Критерии надежности
Критерии надежности – это показатели, позволяющие оценивать предпочтительность тех или иных решений при создании и эксплуатации систем по степени достижения основных целей и с учетом затрат, при которых эти цели достигаются [4].
21
При исследовании надежности основная цель состоит в разработке эффективных методов и обеспечении длительной работоспособности систем с заданными функциональными характеристиками.
Основной задачей теории надежности остается оценка технических решений, позволяющих создать систему с заданными показателями надежности и заданными совокупными затратами.
Критерии:
Детерминированные – оценка количества ошибок в программе на том или ином этапе работы.
Вероятностные – вероятностная оценка свойств ПО.
Все ошибки носят детерминированный характер, но вероятностным оказывается процесс внесения ошибок. Проявление ошибок также носит вероятностный характер.
Примеры критериев:
Корректность ПО.
Число серьезных текущих ошибок в программе и время, необходимое для их устранения.
Обслуживаемость системы – степень влияния ошибок ПО на обслуживаемость системы.
Безопасность системы. Частота отказов.
Вероятность безотказной работы за время t при условии времени отладки.
Средняя наработка на программный отказ при условии исправления или неисправления обнаруженных отказов.
Верификация программ – процесс формального доказательства правильности программы, т.е. корректности.
Верификация:
Статическая.
Динамическая (частный случай – тестирование).
С учетом сложившейся практики выбора критериев оценки надежности необходимо принимать во внимание следующее:
1. Разработанное ПО в начальной стадии эксплуатации может потребовать менее жестких критериев и большего времени для его совершенствования.
22
2.После выпуска новой версии некоторое время потребуются также менее строгие критерии качества ПО.
3.Имеют место разбросы, вызываемые различием в условиях применения и использования ПО.
4.Эффективность работ по исправлению ошибок, проводимых разработчиками ПО, зависит от частоты проявления ошибок, что, в свою очередь, зависит от информации, поступающей от пользователей.
5.Необходимость соблюдения ограничений по быстродействию и производительности, если таковые диктуются пользователями.
Характеристики ПО
1.Количественные характеристики (оцениваются числом): объем программы; количество сопряжений; количество ветвлений; точки входа/выхода; количество процедур; уровень вложения; количество комментариев;
количество страниц документации; требуемое машинное время.
2.Качественные характеристики (оцениваются числом):
трудности проектирования; трудности в эксплуатации из-за ошибок; тип программ;
данные о персонале (количество, коэффициент загруженности).
3.Качественные характеристики как объективное суждение.
23
Испытания ПО
1.Стендовые (многократные проверки в реальных условиях).
2.Приемосдаточные (подтверждение требуемых характеристик и передача в эксплуатацию).
3.Системные (оценивают правильность взаимодействия с другими системами).
4.Демонстрация в реальных условиях.
5.Сертификационные испытания.
Основные параметры персонала
1.Данные, характеризующие программиста.
2.Данные, характеризующие выполнение конкретной работы. В результате формируются критерии, учитывающие конкретно-
го программиста в конкретной работе.
|
Параметры |
Оценка |
Оцениваемые |
||
|
программиста |
факторы |
|||
|
А |
Уровень |
1 – 5 |
1) ОП=А+Б+В+Г |
|
|
знаний |
||||
|
2) ОПКР=(20-Д)*ОП |
||||
|
Б |
Уровень |
1 – 5 |
||
|
способностей |
ОП – оценка |
|||
|
В |
Стиль работы |
1 – 5 |
программиста |
|
|
ОПКР – оценка |
||||
|
Г |
Степень |
1 – 5 |
||
|
программиста |
||||
|
ответственности |
||||
|
и конкретной работы. |
||||
|
Д |
Параметры |
0 – 10 |
||
|
конкретной работы |
||||
24
Цель анализа программных ошибок при сертификации и оценке надежности ПО
Определение структурных свойств программ и характеристик процесса их разработки, влияющих на надежность.
Организация методов сбора данных о надежности. Категоризация возможных программных ошибок по их причи-
нам и проявлениям.
Выработка рекомендаций по совершенствованию бездефектных программ.
Разработка моделей надежности ПО.
Извещения об ошибке
Исходная информация об ошибках может быть представлена в извещении об ошибке. В нем указывается:
1.Объект затруднения (подсистема, БД, ОС и т.д.).
2.Дата и время ошибки.
3.Пример или задача, на которой зафиксирована ошибка.
4.Конфигурация активной структуры ПО.
5.Содержание ошибки.
6.В соответствие ставится извещение о закрытии ошибки, в котором содержится:
информация о закрытии ошибки; генерация новой конфигурации;
правильность распознавания объекта затруднения; существо ошибки.
25
Основные задачи в области надежности ПО (рис. 1.6)
|
Надежность ПО |
|||||
|
Определения |
|||||
|
Корректность |
Устойчивость |
||||
|
Анализ |
Синтез |
||||
|
1 |
2 |
3 |
4 |
5 |
|
|
1.1 |
1.2 |
1.3 |
3.1 |
3.2 |
2.12.2
Рис. 1.6. Основные задачи в области надѐжности ПО
1.Классификация ошибок.
1.1.Организация систем сбора данных.
1.2.Рекомендации по совершенствованию.
1.3.Построение модели.
2.Верификация программ.
2.1.Статическая верификация.
2.2.Динамическая верификация.
3.Тестирование.
3.1.Выбор тестов.
3.2.Управление тестированием.
4.Защита информации.
5.Защита вычислительного процесса.
Количественные вероятностные характеристики надежности ПО
P(t) – вероятность безошибочной работы. Q(t) – вероятность появления ошибок. a(t) Q (t) – частота появления ошибок.
(t) – интенсивность появления ошибок. T0 – среднее время между ошибками.
26
ξk и ξm
Рассмотрим методику вычисления основных параметров. Программа испытывается на одном компьютере.
– время k-го и m-го прогонов, окончившихся отказами. Nотк – количество прогонов, окончившихся отказом.
|
m |
||
|
j 1, Nотк |
j |
l , ξl – время l-го успешного прогона. |
l k 1
υj – время между j-м и (j+1)-м отказами.
– статистическое среднее время между двумя ошибками, N – общее количество прогонов.
–среднее время между двумя ошибками.
–экспоненциальный закон надежности.
|
t |
|
|
(t )dt |
|
|
P(t) e 0 |
– обобщенный закон надежности (λ≠const) |
|
P ( t ) |
||
|
T |
0 |
t |
|
0 |
||
27
Классификация ошибок ПО
Основные проблемы классификации.
1. Где произошла ошибка? 1.1. Персонал.
Информация по категориям персонала включает структуру
ипроцедуры. Это операционные процедуры, правила кодирования
ипроверки, а также стандарты документирования.
1.1.1.Структура.
Технический – для конкретного модуля определяется имя, квалификация разработчика, а именно опыт программирования, знание языков и ответственность.
Административный – определяет административную информацию.
1.1.2.Процедура.
Операционные процедуры включают информацию о рабочей среде, т.е. пакетный или интерактивный режим работы, свободный или ограниченный доступ.
Правила кодирования и проверки. Они содержат информацию о степени использования, например, структурного программирования.
Стандарты документации включают форматы и процедуры документирования данного модуля.
1.2.Оборудование.
1.2.1.Компьютер.
Перечень оборудования и интерфейсов.
1.2.2.Связь.
Содержит информацию о внешнем оборудовании в комплекте ПК, включая линии связи с терминалами.
1.2.3.Сопровождающее обеспечение.
Информация обо всем оборудовании, для подготовки модуля к работе.
1.3.ПО.
1.3.1.Внутреннее ПО.
Языковой процессор, загрузчик, редактор связей, ути-
литы.
28
1.3.2.Применение.
Это размеры, смежные модули, область применения. Каждый из этих разделов обеспечивает идентификацию относящихся к ним программ по имени, номеру версии и т.д.
2.На что похожа ошибка?
2.1.ПО.
2.1.1.Внутреннее ПО.
ОС, редактор связей, загрузчик, утилиты.
2.1.2.Применение.
Каждый ошибочный элемент характеризуется именем, номером версии и будет специфицировать любой ошибочный код и любое диагностическое сообщение, являющееся следствием данной ошибки элемента.
2.2.Функции.
Категория функций идентифицирует с помощью имени точку, в которой зафиксирована ошибка. Эта точка может относиться к процедурам ввода/вывода или использования ресурсов.
2.2.1.Процедура.
В процедурах ввода/вывода подразумевается наличие неправильных значений данных.
2.2.2.Использование ресурса.
При использовании ресурсов наиболее критичными ошибками являются:
неправильное использование терминальных устройств; ошибки синхронизации; ошибки в описании форматов вводимой и выводимой информации.
2.3.Ресурсы.
2.3.1.Имя.
2.3.2.Использование ресурса.
2.4.Область.
2.4.1.Структура программы.
2.4.2.Приложение.
29
3.Как была сделана ошибка?
3.1.Данные.
3.1.1.Входные.
3.1.2.Внутренние.
3.2.Процедуры.
3.2.1.Вычисление.
3.2.2.Контроль.
3.2.3.Интерфейс.
4.Когда была сделана ошибка?
4.1.Начальная разработка.
4.2.Внедрение.
4.3.Функционирование.
5.Почему произошла ошибка?
5.1.Механические причины.
5.1.1.Подстановка.
5.1.2.Путаница.
5.1.3.Пропуск.
5.2.Умственные причины.
5.2.1.Концептуализация.
5.2.2.Реализация.
5.3.Коммуникационные причины.
5.3.1.Персонал.
5.3.2.Документация.
Целью задачи классификации ошибок ПО является создание методов упорядочивания информации о программных ошибках с тем, чтобы на основе этой информации выяснить причины, породившие ненадежность и о путях их предупреждения.
30
71,8% бесплатных материалов
1049 руб. средняя цена курсовой работы
369 руб. средняя цена домашнего задания
121 руб. средняя цена решённой задачи
167 руб. средняя цена лабораторной работы
174 руб. средняя цена реферата
173 руб. средняя цена доклада
1634 руб. средняя цена ВКР
669 руб. средняя цена диссертации
596 руб. средняя цена НИР
364 руб. средняя цена отчёта по практике
280 руб. средняя цена ответов (шпаргалок)
204 руб. средняя цена лекций
240 руб. средняя цена семинаров
279 руб. средняя цена рабочей тетради
189 руб. средняя цена презентации
67 руб. средняя цена перевода
138 руб. средняя цена изложения
149 руб. средняя цена сочинения
374 руб. средняя цена статьи
Гарантия возврата средств