Средняя наработка на отказ
Среднее время восстановления
3. Интенсивность восстановления объекта в момент времени t, отсчитываемый от момента начала восстановления
Параметр потока отказов
5. Коэффициент готовности объекта определяется как вероятность того, что в произвольный момент времени объект
6. Коэффициент простоя – это вероятность нахождения объекта в произвольный момент времени в состоянии отказа.
7. Коэффициент оперативной готовности R(t) – это вероятность того, что объект окажется в работоспособном состоянии в произвольный момент времени, кроме планируемых периодов, в течение которых применение объекта по назначению не предусматривается и, начиная с этого момента, будет работать безотказно заданный интервал времени.
3. Требования к программному продукту и их свойства.
Требования – описание того, что должна выполнять программа, а также условия необходимые для ее выполнения.Спецификация требований – это формализованное представление требований, предъявляемых программе, которое должны быть удовлетворены при ее разработке, а также описание условий и эффекта действий без указания способов их достижения.
Пример требований: Разрабатываемая программа должна предоставлять текущую информацию о вкладах клиента в банк. Спец = Информацию о текущих вкладах предоставлять в печатной форме в виде таблиц. Требования пишет technical writer.
Этапы:
- Опросы заказчика
Проводятся виде интервью, где бизнес-аналитик должен узнать все, что необходимо реализовать.
- технологии разработки требований: JAD(присутствие заказчика на каждом этапе разработки) и JAR(совместная разработка требований)
- Подготовка документа требования
- Подготовка спецификации
- Составления матрицы прослеживаемости требований
- Тестирование требований
Категории требований.
1) функциональные средства – описывают все функции, которые должна выполнять программа
2) интерфейсы – входы полученные из внешних систем и выходы во внешние системы
3) данные – описывается объем данных, скорость передачи, точность вычислений и т д.
4) производительность – описывает проблемы масштабирования и синхронизации.
5) Пользователи и человеческий фактор – описывается кто будет работать с системой, квалификация, уровень удобства и простоты.
6) Безопасность – как осуществляется доступ к системе, к данным
7) Устранение неисправностей – как система должна реагировать на возникновение неисправностей.
8) Сопровождение – описывается, как происходит устранение проблем, временной график поставки.
4. Надежность программного обеспечения.Особенности ПО по сравнению с аппаратурой
Надежность ПО – вероятность работы без отказов в течение определенного периода времени, рассчитанная с учетом стоимости для пользователя каждого отказа
Надежность ПО (ISO/IEC 9126: 2001) – это способность программных средств поддерживать заданный уровень функционирования при эксплуатации в заданных спецификацией условиях.
Надежности соответствуют следующие характеристики:
1. Завершенность – способность программных средств избежать отказа в результате ошибок ПО.
2. Устойчивость к ошибке – способность программных средств поддерживать заданный уровень функционирования при наличии ошибок в ПО или при нарушении его заданного интерфейса.
3. Восстанавливаемость - способность программных средств восстанавливать заданный уровень функционирования или восстанавливать данные, поврежденные в случае отказа.
В отличие от аппаратуры не происходит износа или старения ПО, а снижение надежность ПО происходит из-за ошибок требований, проектирования, реализации. Таким образом, отказы в работе ПО зависят от способа использования ПО и контекста используемой среды и не зависят от времени.
Особенности ПО по сравнению с аппаратурой:
1. Ошибки в ПО проявляются при выполнении программ на некоторых наборах исходных данных; в аппаратуре ошибки происходят из-за сбоев и отказа аппаратуры.
2. Компоненты программ не присущи старения и износ.
3. Коррекция ошибок в программе приводит к изменению ее конфигурации и обычно устраняет возможность повторного проявления ошибки.
4. Анализ типа отказа и его влияние непрактичны в сложных программах.
5. Основные причины появления ошибок в ПО.
Одним из самых распространенных определений ошибки является ее несоответствие спецификации. Ошибка в ПО представляет собой некоторый дефект в его разработке, который вызывает несоответствие ожидаемых результатов с полученными. Дефект может возникнуть в каждой работе процесса разработки.
Проблема требований
Ошибка программиста
--интеграции
--enviroment
Сложность системы
Плохая организация
6. Основные процессы жизненного цикла разработки ПО.
Жизненный цикл – это структура, состоящая из процессов, работ и задач, включающая в себе разработку, эксплуатацию и сопровождение ПО.
Основные процессы жизненного цикла:
1) Процесс заказа содержит работы и задачи выполненные заказчиком и состоит из определения потребностей заказчика к системе, выпуска заявки на подряд и выбора поставщика.
2) Процесс поставки состоит из работ и задач, выполняемых поставщиком, начиная с решения о подготовке предложения и вступления с заказчиком в договорные отношения.
3) Процесс разработки содержит 13 работ:
1. Подготовка процессов (должны быть выбраны и адаптированы стандарты, инструментарии и языки программирования для выполнения работ в процессе разработке.)
2. Анализ требований к системе. Результатом этой работы должна быть документально оформленная спецификация требований к системе.
3. Проектирование системной архитектуры. Должна быть определена общая архитектура всей системы, должны быть указаны объекты технических и программных средств и ручных операций.
4. Анализ требований к программным средствам.
5. Проектирование программной архитектуры. Требования к программному объекту должны быть преобразованы к программной архитектуре, которая описывает общую структуру программного объекта и определяет компоненты объекта.
6. Техническое проектирование программных средств. Должен быть разработан технический проект для каждого компонента программного объекта.
7. Программирование и тестирование. Должен быть разработан и документально оформлен каждый программный модуль и база данных, а также протестированы каждый модуль и база данных на соответствие требованиям.
8. Сборка программных средств. Здесь все модуль и компоненты должны быть собраны в единый программный объект и протестированы.
9. Квалификационные испытания программных средств. Должны быть произведены испытания на соответствие требований.
10. Сборка системы. Программные объекты должны быть собраны в единую систему вместе с объектами технической конфигурации и при необходимости другими система.
11. Квалификационное испытание системы. Тестирование системы по требованиям.
12. Ввод программного средства в действие.
13. Обеспечение приёмки программных средств.
4) Процесс эксплуатации
5) Процесс сопровождения
7. Вспомогательные процессы жизненного цикла разработки ПО.
1. Документирование – процесс формализованного описания информации, созданный в процессе или работе ж.ц.
2. Управление конфигурированием – процесс применения административных и технических процедур на всем протяжении ж.ц. программных средств.
3. Обеспечение качества – процесс обеспечения соответств. гарантий того, что программные средства и процессы ж.ц. соответствуют установленным требованиям и утвержденным планам (QL - инженеры)
4. Верификация – это процесс определения того, что программное средство функционирует в полном соответствии с требованиями или условиями, реализованными в предшествовавших работах. Верификация может применятся к любым результатам работы.
5. Аттестация – процесс определения полноты соответствия установленных требований созданной системы их функциональным назначениям. Аттестации подвергаются любые промежуточные и завершающие продукты процессов (тестировщики).
6. Совместный анализ – процесс оценки состояний и результатов работ по всему проекту. Проводится в течении всего ж.ц. как на уровне управления проектом, так и на уровне реализации.
7. Аудит – процесс определения соответствия к требованиям, планам и условиям договора.
8. Решения проблем – это процесс анализа и решения проблем, которые обнаружены в ходе эксплуатации.
8. Сложность ПО.
Сложность ПО – сложность программ является одной из главных причин их ненадежности. Существуют следующие критерии оценки сложности:
-- кол-во операторов
-- цикломатическое число (число Маккейла) – вычисляется по потоковому графу программы (графическое отображение программного кода). На графах вершины являются операторы, а ребрами – связь между операторами.
G = R – V + 2, где R – ребра, V – вершины. Формулу можно использовать только для замкнутого графа. Если граф не замкнутый, то считается вручную.
Показывает 2 вещи: Сложность графа (G>15 – программный модуль необходимо разбить на части), минимальное количество тестовых проходов для тестирования программного модуля.
Проход – путь по графу от первого узла, к последнему.
Мера сложности Холстеда. Кроме измерений длины программы Холстед предложил учитывать количество операндов и число появления операторов и операндов. Ввел следующие меры:
ᵑ1 – Число различных операторов;
ᵑ2 – Число различных операндов;
ᵑ = ᵑ1+ᵑ2
N1 – число появлений операторов;
N2 – число появлений операндов;
N =N1 + N2
9. Способы обеспечения надежности ПО.
Выделяет 4 способа обеспечения надежности ПО:
1) Использование технологий программирования способствующих созданию безошибочного ПО.
2) Доказательства корректности и верификации. Доказательство корректности состоит в формальном доказательстве соответствия ПО своей спецификации.
3) Создание ПО, устойчивого к отказам. Устойчивость ПО достигается за счет внесений в него различных форм избыточности, например, использования метода n-версионного программирования.
4) По средствам тестирования и отладки ПО.
10. Основные стандарты оценки качества.
Надежность является одной из характеристик качества. Для оценки качества действую стандарты:
1) Межгосударственный стандарт стран СНГ – ГОСТ 28195-99 «Оценка качества программных средств. Общие положения»
2) Национальный стандарт РБ – СТБ ИСО/МЭК 9126-2003 «Информационные технологии, оценка программной продукции. Характеристики качества и руководство по их применению»
3) Международная серия стандартов ISO/IES 9126-1-4: 2001-2004 «Программная инженерия. Качество продукта»
4) международная серия стандартов ISO/IES 14598-1-6: 1998-2001 «Информационные технологии. Оценка программного продукта»
СТБ – перевод международного стандарта ISO/IES 9126 редакции 1991. Россия использует в качестве своего
11. Тестирование методами «черного, белого и серого ящиков».
В терминологии фразы «тестирование белого ящика» и «тестирование черного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.
При тестировании белого ящика, разработчик теста имеет доступ к исходному коду программ. Это типично для юнит-тестирования, при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции — работоспособны и устойчивы, до определенной степени.
При тестировании чёрного ящика, тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.
Недостатки:
- некоторые ошибки возникают редко, поэтому их трудно воспроизвести и обнаружить
- невозможно найти взаимоуничтожающиеся ошибки
Чтобы не быть связанным ограничениями, присущими каждому предыдущему методу в отдельности, можно применить сочетание различных методов, что называтется методом "серого" или "полупрозрачного" ящика, при котором код программы тестировщику виден частично. Используются средства автоматизации тестирования.
12. Процесс разработки тестовых случаев. Свойства тестовых случаев.
-ознакомление с планом тестирования и выявление стратегии тестирования
-проектирование тестовых случаев; --разработка тест-х случаев
-пересмотр и отладка тестовых случаев
1)выбор объекта для тестирования(лошадь детская)
2)Требования к лошадке
3)среда эксплуатации и др.
Как правило набор тестовых случаев группируют в 3-и раздела:
1) приемочный тест-это проверка основной функциональности программы. Проводится одним чел-ком не более получаса. Принять или не принять для дальнейшего тестирования.
2) Критический раздел- это проверка абсолютно всей функциональности программы при стандартной ее работе(при верных данных, при верно нажатых клавишах)
3)углубленный -это проверка работы программы в нестандартных ситуациях.
Как правило тестовые случаи оформляются в виде таблицы.Поля табл. могут быть: №теста, №требования, название модуля, последоват-сть действий, ожидаемый результат, пройден ли тест, комментарии.
Свой-ва тестовых случаев.
1.Каждый тестовый случай должен иметь четко поставленную цель.
2.Для каждого теста должна быть определена среда тестирования. Благодаря этому можно рассчитывать что при каждом прогоне этот тест будет выдавать один т тот же результат.
3.Каждый тестовый случай должен давать строго определенный рез-тат(для для однозначности трактовки прохождения теста)
4.Тестовый случай должен проверять минимальный функционал (чем мельче тесты, тем удобнее пользоваться)
5.Тестовые случаи должны организовываться в иерархию(тестовые сценарии).
Послед-сть тестов в иерархии должна быть удобной для использования, что позволит в каждый конкретный момент времени работать с одним уровнем системы.
Начинать с админа.
Тестовый случай должен обладать высокой вероятностью обнаружения ошибки. Для этого тестеры должны стать на позицию конструктивного разрушения. Нельзя делать предположения. Тестовый случай д.б. воспроизводимым. Тестовый случай не д.б. избыточным.
Полный функциональный тест состоит из 3 этапов:
1. приемочное тестирование – короткий тест, который длится не более 30 минут для того, чтобы проверить самую глобальную функциональность системы и сделать вывод о пригодности ПП для тестирования вообще.
2. критическое – проверка работы программы при стандартных условиях.
3. углубленное (расширенное) – проверка работы программы для нестандартных ситуаций.
13. Эквивалентирование и анализ граничных значений.
Граничные значения – значения, которые находятся на границе допустимых значений.
Эквивалентные значения – значения, которые условно покрывают весь диапазон допустимых значений(среднее значение, малое и большое).
[0; 100]
Критический тест Углубленный тест
0, 100 -1, 101
1, 99, 50 -2, 1000, симв. данные
Область входных данных проги можно разбить на конечное число классов эквивал-ти.
Суть: многие состояния ввода очень похожи др. на друга, тогда если выполнять одно состояние ввода, существует большая вероятность верного ввода и другого состояния. Как минимум все состояния ввода делятся на 2 класса:
- верные значения;
- неверные значении.
Т.о. ускоряется процесс тестирования. Под граничными значениями понимается ситуация, возникшая непосредственно на границе входного условия.
14. Ошибка. Свойства ошибки.
Ошибка – изъян в разработке программы, который вызывает несоответствие ожидаемых результатов с фактическими. Свойства:
- Важность: критическая, серьезная средняя, низкая.
- Приоритет: очень высокий, высокий, средний, низкий.
- Воспроизводимость: всегда, иногда
- Симптом(категория ошибки): неожиданное поведение, недружественное поведение, неверное действие, отказ системы, потеря данных, искажение данных, низкая производительность, локализационная проблема, инсталляционная проблема, ошибка документации, различия со спецификацией, отсутствующая функциональность, запрос на улучшение
Ошибка (дефект, Bug) – расхождение м-ду прогой и ее спецификацией.
или если прога не делает того, что пользователь от нее вполне обоснованно ожидает.
Если прога не делает того, что польз-ль от нее ожидает – программная ошибка.
Чтобы ошибку было легче исправить, ее нужно точно описать, т.е. составить хороший отчет по найденной ошибке. В отчете указываются св-ва этой ошибки.
Свойства ошибок:
1. Важность:
1) критическая ошибка – происходит крах прилож-я, крах сервера, ОС, невозможность продолж-я раб. с прил-ем без его перезапуска.
2) серьезная – не работает основной функционал.
3) средняя – не раб. или неправильно раб. неосн. функц-ть, но есть др. сп-б для ее реализ-ии: не раб Save As(раб. Save).
4) низкая – все дефекты, не влияющие на функциональность (грам. ошибки, некорректная табуляция и т.д.)
2. Воспроизводимость – как часто проявляется ошибка: всегда, иногда при каком-то условии
3. Симптом – категория ошибки: Неверное действие; Неожиданное поведение программы; Недружественной поведение программы; Отказ системы; Потеря данных; Искажение данных; Косметическая ошибка; Ошибка документации; Различие со спецификацией.
4. Приоритет ошибки по отношения с другими ошибками: Очень высокий; - Высокий; - Средний; - Низкий.
15. Правила составления отчетов об ошибках.
Отчет должен составляться быстро, но при этом его тон и содержание должны максимально способствовать решению проблемы. Цель – исправление. Правила:
· Максимально доступно и подробно объясните, как воспроизвести ошибку или проблемную ситуацию. -Тщательно проанализируйте ошибку, чтобы описать ее предельно кратко и четко. Слишком пространное и расплывчатое описание проблемы затрудняет понимание ее сути.
· Отчет стоит составлять немедленно. Не стоит откладывать его оформление, написав лишь короткие заметки.
Как только ошибка найдена, она должна быть задокументирована, т.к. цель поиска ошибок – их исправление для повышения качества продукта. Для того чтобы ошибку было легче исправить, ее нужно точно описать, т. е. составить хороший отчет о найденной ошибке.
Памятка:
-составляйте отчет об ошибке сразу же после ее обнаружения, т.к. про нее м. забыть.
-не сост-те отчет на бумаге (можно легко потерять), а сразу занесите ее в систему док-ции ошибок.
-придумайте краткое, но емкое назв-е ошибки (иногда вместо термина назв-е исп-ся термин summary), ведь по назв-ю ошибки менеджер разр-ов будет отправлять эту ошибку для исправления тому или другому спец-у, - составьте-опишите шаги для воспроизведения обнаруженной ошибки для того, чтобы разработчик смог их повторить и увидеть ошибку.
-составьте полное описание обнаруженной ошибки с указанием ОС и Browser или др. подробностей. -не путайте шаги воспроизведения и описание ошибки, а также название ошибки с ее описанием. -укажите серьезность ошибки, ее симптом, частоту проявления и приоритет.
-пользуйтесь простым языком для описания ошибок.
-не обвиняйте никого в обнаруженной ошибке, отчет не должен приводить к конфликту между разработчиком и тестировщиком, а лишь способствовать улучшению качества.
16. Жизненный цикл ошибки. Системы документирования ошибок.
ЖЦ ошибки начинается с ее обнаружения и присвоения статуса «новая» или «найдена». Затем ошибка направляется для исправления и получает статус «присвоена». После исправления ошибка получает статус «исправлена». Затем исправленная ошибка вновь отправляется тестировщику, как правило в новой версии, и если ошибка не повторяется, она получает статус «проверена».
Возможны такие случаи:
1. Когда исправленная ошибка повторяется снова. Тогда тестировщик присваивает ей статус «повторить» и отправляется на исправление.
2. Когда задокументированная ошибка не воспроизводится, тогда разработчик
присваивает ей статус «не воспроизводится».
3. Когда задокументированная ошибка не может быть исправлена в текущей версии или ее не следует исправлять вообще, тогда ошибку откладывают с присвоением ей статуса «отложена»
Тестировщик: найдена, закрыта, повторить
Программист: присвоена, исправлена, не воспроизводится, отложена
Системы документирования и отслеживания ошибок.
Каждая ошибка подлежит документированию и отладке. В большинстве своем эти системы не ограничиваются работой с ошибками, а представляют собой систему управления ошибками. Она позволяет отслеживать процесс тестирования, проверять и составлять отчеты.
Назначение:
1) повышать взаимодействие между сотрудниками
2) ни одна ошибка не должна быть не исправлена, потому что так решил разработчик
3) как можно меньше ошибок должно остаться из-за проблем взаимодействия сотрудников.
Несмотря на то, что существует много систем тестирования, жизненный цикл ошибки остается тем же.
Виды систем: 1) свободное распространение (bugrilla)
2) за деньги (Bat ional Clear Quest, Sea pine Test Track Pro)
Критерии выбора ВТС(вид тестовой системы):
1) доступная система на различные платформы
2) наличие клиент-серверного приложения
3) поддержка работы с различными БД 4) стоимость и схемы рецензирования
5) интегрирование в различные среды 6) гибкость настройки системы
7) электронная поддержка формирования событий и отчетов
17. Критическое и углубленное тестирование.