12_Тестирование программ

1.

2.

Тестирование программного обеспечения —
процесс исследования, испытания
программного продукта, имеющий своей
целью проверку соответствия между
реальным поведением программы и её
ожидаемым поведением на конечном наборе
тестов, выбранных определённым образом
75% времени при создании программ уходит
вовсе не на программирование.
2

3.

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

4.

IEEE 829—2008 IEEE Standard for Software and
System Test Documentation Описывает виды
документов, служащих для подготовки тестов.
ANSI/IEEE Std 1008—1987 — IEEE Standard for
Software Unit Testing Описывает организацию
модульного тестирования
ISO/IEC/IEEE 29119-1:2013 Software and systems
engineering — Software testing — Part 1: Concepts
and definitions
ISO/IEC/IEEE 29119-2:2013 Software and systems
engineering — Software testing — Part 2: Test
processes
ISO/IEC/IEEE 29119-3:2013 Software and systems
engineering — Software testing — Part 3: Test
documentation
4

5.

ISO/IEC 12119:1994 (аналог AS/NZS
4366:1996 и ГОСТ Р-2000, также принят
IEEE под номером IEEE 1465-1998)
Information Technology. Software packages
— Quality requirements and testing.
Описывает требования к процедурам
тестирования программных систем.
5

6.

Программ без ошибок не бывает: любая
может выдать непредсказуемый результат
в ответ на самые обычные действия.
Разработчик, скорее всего, не заметит этих
дефектов в коде, зато конечному
пользователю они могут отравить жизнь.
Бывают ошибки мелкие и незначительные,
а бывают и такие, что всё перестаёт работать.
6

7.

7

8.

Статическое, без запуска программы, и динамическое — с запуском.
Статическое обычно делают в самом начале работы: инженеры проверяют
проектную документацию и спецификации, вычитывают уже написанный код.
Затем проводят динамическое тестирование: программу запускают
и проверяют, как она ведёт себя во время работы, определяют время отклика
и то, насколько она загружает процессор и память.
С помощью функционального тестирования проверяют, как программа решает
задачи, нужные клиенту. При нефункциональном исследуют
производительность системы, её надёжность и защищённость, работу
с окружением — операционной системой и оборудованием.
Тестирование по принципу «чёрного» и «белого» ящика. В первом случае
тестировщик не смотрит на код и работает только с программным
интерфейсом. Он проверяет производительность программы, все ли нужные
функции реализованы, ищет ошибки в её интерфейсе и поведении.
Во втором — инженер имеет доступ к коду. Он проверяет структуру и логику
всей программы или отдельных её компонент. Часто этим занимается сам
программист.
Ручное и автоматическое тестирование. В первом случае работу кода
проверяют вручную, без использования программных средств. Во втором —
применяют специально написанные автоматические тесты, которые постоянно
обновляют.
8

9.

Модульное тестирование делается в самом начале, когда готовы
те куски кода, которые можно проверить по отдельности: объекты,
классы, функции, программные модули. Тесты пишутся отдельно для
каждой функции или метода. На этом этапе проверяют
работоспособность части кода, нет ли регрессии — не появились ли
после изменения кода ошибки там, где раньше всё работало
нормально. Это самый нижний уровень тестирования, часто это
делают те, кто пишет код.
К интеграционному тестированию переходят после модульной
проверки. Здесь тестируют связи между проверенными элементами
и то, как программа взаимодействует с операционной системой,
оборудованием.
Системное тестирование показывает, соответствует ли готовая
система функциональным и нефункциональным требованиям.
Приёмочное тестирование проходит, когда заказчик принимает
приложения от разработчиков. Его цель — убедиться, что продукт
удовлетворяет требованиям клиента. На основании этого покупатель
решает, готова ли программа или её нужно дорабатывать.
9

10.

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

11.

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

12.

12

13.

Составляют тест-план, где описан весь объём
работ по тестированию и определено, когда
их можно закончить. Это примерный
документ — в процессе разработки в него
не раз внесут изменения: уточнят стратегию
и виды тестирования, расписание работ и так
далее.
Разрабатывают тест-кейсы — перечень
конкретных действий и сценарии для проверки
каких-то определённых функций программы.
Решают, нужна ли автоматизация: стоит ли
разрабатывать и запускать автоматические
тесты или можно обойтись тестированием
вручную.
13

14.

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

15.

Регрессионное тестирование. Тестировщики
ищут баги в новых участках кода и в тех
местах, где исправляли ранее найденные
ошибки.
Проверка в разных уровнях: испытывают
её функциональность, производительность,
работу с окружением. Это можно делать
вручную или с помощью автоматических
тестов-кейсов.
Автоматизированное тестирование облегчает
проверку и экономит время. Лучше всего это
работает в сложных приложениях с большой
функциональностью.
15

16.

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

17.

Интеллектуальные возможности человека
Неправильный перевод как причина
ошибок в программных средствах
Модель перевода
17

18.

способность к перебору,
способность к абстракции,
способность к математической индукции
n – число элементов системы
n < 7 (6! = 720 < 1000)
n > 7 (7! = 5040)
n = 7
18

19.

19

20.

20

21.

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

22.

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

23.

Стандарт ISO 9126:2001 определяет наборы метрик для оценки
каждого атрибута. Примеры:
Полнота реализации функций — процент реализованных
функций по отношению к перечисленным в требованиях.
Используется для измерения функциональной пригодности.
Корректность реализации функций — правильность их
реализации по отношению к требованиям. Используется для
измерения функциональной пригодности.
Отношение числа обнаруженных дефектов к
прогнозируемому. Используется для определения зрелости.
Отношение числа проведенных тестов к общему их числу.
Используется для определения зрелости.
Отношение числа доступных проектных документов к
указанному в их списке. Используется для измерения удобства
проведения анализа.
Наглядность и полнота документации. Используется для
оценки понятности.
23

24.

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

25.

Эффективность верификации и валидации,
как и эффективность разработки ПО в целом,
зависит от полноты и корректности
формулировки требований к программному
продукту.
25

26.

Методы и техники, связанные с выяснением свойств ПО во время его
работы. Это все виды тестирования, а также профилирование и
измерение количественных показателей качества, которые можно
определить по результатам работы ПО — эффективности по времени
и другим ресурсам, надежности, доступности и пр.
Методы и техники определения показателей качества на основе
симуляции работы ПО с помощью моделей разного рода. К этому
виду относятся проверка на моделях (model checking) и
прототипирование (макетирование), используемое для оценки
качества принимаемых решений.
Методы и техники, нацеленные на выявление нарушений
формализованных правил построения исходного кода ПО,
проектных моделей и документации. К ним относится
инспектирование кода, заключающееся в целенаправленном поиске
определенных дефектов и нарушений требований в коде на основе
набора шаблонов, автоматизированные методы поиска ошибок в
коде, не основанные на его выполнении, методы проверки
документации на согласованность и соответствие стандартам.
Методы и техники обычного или формализованного анализа
проектной документации и исходного кода для выявления их
свойств: многочисленные методы анализа архитектуры ПО, методы
формального доказательства свойств ПО и формального анализа
эффективности применяемых алгоритмов.
26

27.

27

28.

defect — самое общее нарушение каких-либо требований или
ожиданий, не обязательно проявляющееся вовне (к дефектам
относятся нарушения стандартов кодирования, недостаточная
гибкость системы и пр.).
failure — наблюдаемое нарушение требований, проявляющееся при
каком-то реальном сценарии работы ПО. Это можно назвать
проявлением ошибки.
fault — ошибка в коде программы, вызывающая нарушения
требований при работе (failures), то место, которое надо исправить.
Хотя это понятие используется довольно часто, оно, вообще говоря,
не вполне четкое, поскольку для устранения нарушения можно
исправить программу в нескольких местах. Что именно надо
исправлять, зависит от дополнительных условий, выполнение
которых мы хотим при этом обеспечить, хотя в некоторых ситуациях
наложение дополнительных ограничений не устраняет
неоднозначность.
error — используется в двух смыслах:
Первый — это ошибка в ментальной модели программиста,
ошибка в его рассуждениях о программе, которая заставляет его
делать ошибки в коде (faults). Это, собственно, ошибка, которую
сделал человек в своем понимании свойств программы.
Второй смысл — это некорректные значения данных (выходных
или внутренних), которые возникают при ошибках в работе
программы.
28

29.

абстракции и уточнения,
модульная разработка (принципы:
выделение интерфейсов и сокрытие
информации; адекватность, полнота,
минимальность и простота интерфейсов;
разделение ответственности; слабая
связность (coupling) модулей и сильное
сродство (cohesion) функций в одном
модуле)
переиспользование
29

30.

test-driven development, TDD — техника разработки
программного обеспечения, которая основывается на
повторении очень коротких циклов разработки: сначала
пишется тест, покрывающий желаемое изменение, затем
пишется код, который позволит пройти тест, и под
конец проводится рефакторинг нового кода к
соответствующим стандартам.
Кент Бек, считающийся изобретателем этой техники,
утверждал в 2003 году, что разработка через
тестирование поощряет простой дизайн и внушает
уверенность.
В 1999 году при своём появлении разработка через
тестирование была тесно связана с концепцией «сначала
тест» (test-first), применяемой в экстремальном
программировании, однако позже выделилась как
независимая методология.
30

31.

Тестированием программы занимаются специалисты
по контролю качества программного обеспечения — QAинженеры. У них есть разные специализации: тестировщики
баз данных, специалисты автоматизированного тестирования,
аналитики, разработчики тестов, специалисты
по безопасности приложений и другие.
Если проект большой, над ним работает целая команда: одни
тестировщики готовят тесты, другие проверяют их полноту
и логику, третьи занимаются непосредственно тестированием.
Над небольшими задачами может работать один специалист,
причём удалённо.
Тестировщики — среди самых востребованных сейчас
специалистов-айтишников. Появляется множество новых
программ, и каждой из них нужен контроль качества. QAспециалистов нанимают крупные компании-разработчики ПО,
они могут стать фрилансерами и работать сразу на несколько
фирм.
31

32.

32

33.

33

34.

34