Тестирование отдельных модулей

1. Тестирование отдельных модулей

2. Инструментарии анализа качества программных продуктов в среде разработки.

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

3. Дефектогенность  определяется влиянием следующих факторов:

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

4. Дефектабельность  характеризует наличие дефектов ИС

Дефектабельность
характеризует наличие
дефектов ИС
Другими факторами,
влияющими
на дефектабельность,
являются:
структурно-конструктивные
особенности ИС;
интенсивность и
характеристики ошибок,
приводящих к дефектам.

5. Дефектоскопичность  характеризует возможность проявления дефектов в виде отказов и сбоев

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

6. Совокупность нескольких критериев определяет показатель качества ,формируемый исходя из требований, предъявляемых к ИС. В

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

7. Далее формируются показатели, к числу которых могут быть отнесены:

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

8. Надо отметить, что один и тот же критерий может характеризовать несколько показателей:

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

9. Надо отметить, что один и тот же критерий может характеризовать несколько показателей:

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

10. Виды метрических шкал для измерения критериев

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

11. Виды метрических шкал для измерения критериев

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

12. Виды метрических шкал для измерения критериев

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

13. Модель классификации критериев качества информационных систем.

Модель классификации
критериев качества
информационных систем.

14. Software Quality Assurance

Software Quality Assurance (SQA) —
это комплекс мероприятий по
обеспечению качества в процессах
разработки программного
обеспечения.
SQA — это непрерывный процесс в
рамках жизненного цикла
разработки программного
обеспечения (SDLC), который
регулярно проверяет
разработанное программное
обеспечение, чтобы убедиться, что
оно соответствует требуемым
показателям качества.

15. Software Quality Assurance

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

16. Software Quality Assurance

Могут проводиться процессы:
Методология разработки
программного обеспечения
Управление проектом
Управление конфигурацией
Разработка требований /
Управление
Предварительный расчет
Разработка программного
обеспечения
Тестирование и др.

17. Выявление ошибок системных компонентов.

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

18. Методы идентификации сбоев и ошибок

Ошибка (error) - состояние программы, при
котором выдаются неправильные результаты,
причиной которых являются изъяны (flaw) в
операторах программы или в технологическом
процессе ее разработки, что приводит к
неправильной интерпретации исходной
информации, следовательно, и к неверному
решению.

19. Методы идентификации сбоев и ошибок

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

20. Методы идентификации сбоев и ошибок

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

21. Методы идентификации сбоев и ошибок

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

22. Методы идентификации сбоев и ошибок

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

23. Методы идентификации сбоев и ошибок

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

24. Методы идентификации сбоев и ошибок

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

25. Автоматизация тестирования в продуктивной среде

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

26. Автоматизация тестирования в продуктивной среде

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

27. Автоматизация тестирования в продуктивной среде

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

28. Автоматизация тестирования в продуктивной среде

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