Качество программного обеспечения. Стандарты тестирования программного обеспечения

1.

Качество программного обеспечения.
Стандарты тестирования программного
обеспечения.

2. Ключевые стандарты тестирования ПО:

1. ISO/IEC 25000 определяет общие подходы и
терминологию
для
оценки
качества
программных продуктов. Он состоит из ряда
подстандартов, которые охватывают различные
аспекты, такие как модели качества, метрики и
процессы оценки.
2. IEEE 829 определяет формат и содержание
документации по тестированию, такой как
планы,
сценарии,
описания
процедур,
результаты и отчеты о тестировании. Этот
стандарт
является
одним
из
основных
инструментов
для
обеспечения
структурированного,
документированного
подхода к тестированию ПО.

3. Ключевые стандарты тестирования ПО:

3. ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013
Системная
и
программная
инженерия.
Тестирование
программного
обеспечения.
Часть 1. Понятия и определения
4. ГОСТ Р 56921-2016/ISO/IEC/IEEE 29119-2:2013
Системная
и
программная
инженерия.
Тестирование
программного
обеспечения.
Часть 2. Процессы тестирования
5. ГОСТ Р 56921-2016/ISO/IEC/IEEE 29119-3:2013
Системная
и
программная
инженерия.
Тестирование
программного
обеспечения.
Часть 3. Документация тестирования

4. Тестирование ПО. Характеристики качества.

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

5. Тестирование ПО. Характеристики качества.

3. Правильность (корректность) - способность
программного
средства
обеспечивать
правильные или приемлемые для пользователя
результаты и внешние эффекты.
4. Способность к взаимодействию - свойство
программных средств и их компонентов
взаимодействовать с одной или большим числом
компонентов внутренней и внешней среды.
5. Защищённость - способность компонентов
программного средства защищать программы и
информацию от любых негативных воздействий.

6. Тестирование ПО. Характеристики качества.

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

7. Тестирование ПО. Характеристики качества.

9. Сопровождаемость
приспособленность
программного средства к модификации и
изменению конфигурации и функций.
10.Мобильность
подготовленность
программного средства к переносу из одной
аппаратно-операционной среды в другую.

8. Тестирование ПО. Ещё немного о качестве.

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

9. Тестирование ПО. Ещё немного о качестве.

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

10. Помните! :)

11.

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

12. Соотношение объемов тестов

.

13. 1. Модульное тестирование (Unit testing).

Этот
уровень
тестирования
позволяет
проверить функционирование отдельно взятого
элемента системы. Что считать элементом –
модулем системы определяется контекстом.
Наиболее полно данный вид тестов описан
в стандарте IEEE 1008-87 «Standard for
Software
Unit
Testing»,
задающем
интегрированную концепцию систематического
и документированного подхода к модульному
тестированию.

14.

Модульное (unit) тестирование – проверка
функционирования
первого
компонента
системы, самого элементарного. Обычно
берется самый минимально возможный для
тестирования компонент, например, одна
функция программы.
В данном виде тестирования используется
метод «белого ящика». Обычно модульное
тестирование выполняется программистами.
Цель этого вида тестирования – изолировать
отдельные части программы, протестировать их
и
показать,
что
в
отдельности
они
работоспособны.

15.

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

16.

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

17. 2. Интеграционное тестирование (Integration testing).

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

18.

Таким образом, мы получаем на входе
протестированные модули, затем объединяем
их в группы, тестируем эти группы. И на выходе
получаем протестированные группы модулей.
Этот вид тестирования проводится через
интерфейс программы - методом «черного
ящика».
Также с помощью метода «черного ящика»
тестируется следующий уровень.

19. 3. Системное тестирование (System testing).

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

20.

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

21.

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

22. Вывод

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

23. Задание

Изучить ГОСТ Р 56920-2016/ISO/IEC/IEEE 29119-1:2013
Системная и программная инженерия. Тестирование
программного обеспечения. Часть 1. Понятия и
определения
Составить в текстовом документе тест по Терминам и
определениям (пункт 4) из 12 заданий. В каждом задании
пишем вопрос и не менее 4 вариантов ответов,
правильные ответы выделить цветом.
Варианты определены в задании, делаем по указанным
понятиям:
1 вариант – 4.1-4.12
2 вариант – 4.13-4.24
3 вариант – 4.25-4.36
4 вариант – 4.37-4.48
5 вариант – 4.49-4.60
6 вариант – 4.61-4.72
7 вариант – 4.73-4.84
8 вариант – 4.85-4.96