Процесс выполнения программы целью которого является выявление ошибок

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

Цель лекции:
ознакомиться с видами и способами
контроля и тестирования ПО, методами и
средствами отладки программ.

Недостаточно
выполнить проектирование и кодирование
программного продукта,
также необходимо обеспечить его
соответствие требованиям и спецификациям.
Многократно проводимые исследования
показали, что чем раньше обнаруживаются
те или иные несоответствия или ошибки,
тем боль­ше
вероятность их исправления и ниже его
стои­мость [4].
Современные
технологии разработки ПО преду­сматривают
раннее обнаружение ошибок за счет
выполнения контроля ре­зультатов
всех этапов и стадий разработки. На
начальных этапах кон­троль
осуществляют вручную или с использованием
CASE-средств,
на последних — он принимает форму
тестирования.

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

1. предполагаемые
   результаты должны быть известны до
   тестирования;

2. следует избегать
   тестирования программы автором;

3. необходимо
   досконально изучать результаты каждого
   теста;

4. необходимо
   проверять действия программы на неверных
   данных;

5. необходимо
   проверять программу на неожиданные
   побочные эффекты на неверных данных.

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

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

Ручной
контроль
используют на ранних эта­пах разработки.
Все проектные решения анализируются с
точки зрения их правильности и
целесообразности как можно раньше, пока
их можно легко пересмотреть. Различают
статический
и динамический
подходы к ручному контролю. При статическом
подходе
анализируют структуру, управляющие и
инфор­мационные связи программы, ее
входные и выходные данные. При динамическом
—
выполняют ручное
тестирование (вручную
моделируют про­цесс выполнения
программы на заданных исходных данных).
Исходными данными для таких проверок
являются: техническое зада­ние,
спецификации, структурная и функциональная
схемы программного продукта, схемы
отдельных компонентов, а для более
поздних этапов — алгоритмы и тексты
программ, а также тестовые наборы.
Доказано, что ручной контроль способствует
существенному увеличе­нию
производительности и повышению надежности
программ и с его помо­щью можно находить
от 30 до 70 % ошибок логического проектирования
и кодирования. Основными методами
ручного контроля являются: инспекции
исходного текста,
сквозные
просмотры,
проверка
за столом,
оценки
программ.

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

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

При
комплексном
тестирова­нии
используют тесты, построенные по методам
эквивалентных классов, граничных условий
и предположении об ошибках, поскольку
структурное тестирование для него не
при­менимо.
Одним
из самых сложных является вопрос о
завершении тестирования, так как
невозможно гарантировать, что в программе
не осталось ошибок. Часто тестирование
завершают потому, что закончилось время,
отведен­ное на его выполнение. Его
сворачивают, обходясь минимальным
тестированием
[15], которое
предпо­лагает:
тестирование граничных значений,
тщательную проверку руководства,
тестирование минимальных конфигураций
технических средств, возможности
редактирования команд и повторения их
в любой последовательности, устойчивости
к ошибкам пользователя.

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

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

1. синтаксические
   ошибки –
   сопровождаются комментарием с указанием
   их мес­тоположения, фиксируются
   компилятором (транслятором) при
   выполнении синтаксического и частично
   се­мантического анализа;

2. ошибки
   компоновки —
   обнаруживаются компоновщиком (редакто­ром
   связей) при объединении модулей
   программы;

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

1. ошибки
   определения исходных данных (ошибки
   передачи, ошибки преобразования, ошибки
   перезаписи и ошиб­ки данных);

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

3. ошибки
   накопления погрешностей результатов
   вычислений (игнорирование ограничений
   разрядной сетки и способов уменьшения
   погрешности).

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

1. ручного
   тестирования
   (при обнаружении ошибки нужно выполнить
   те­стируемую программу вручную,
   используя тестовый набор, при работе
   с ко­торым была обнаружена ошибка);

2. индукции
   (основан
   на тща­тельном анализе симптомов
   ошибки, которые могут проявляться как
   неверные результаты вычислений или
   как сообщение об ошибке);

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

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

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

Общая
методика отладки программных продуктов,
написанных для выполнения в операционных
системах MS
DOS
и Win32:

1
этап —
изучение проявления ошибки;

2
этап – определение
локализации
ошибки;

3
этап —
определение причины ошибки;

4
этап — исправление
ошибки;

5
этап — повторное
тестирование.

Процесс
отладки можно существенно упрос­тить,
если следовать основным рекомендациям
структурного подхода к про­граммированию:

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

2. выводить пользователю
   вводимые им данные для контроля и
   прове­рять их на допустимость сразу
   после ввода;

3. предусматривать
   вывод основных данных во всех узловых
   точках ал­горитма (ветвлениях, вызовах
   подпрограмм).

Дополнительную
информацию по теме можно получить в [1,
2, 4, 7, 9, 14, 15].

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Тестирование
и отладка программных продуктов

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

Соблюдение основных
правил тестирования и научно обоснованный подбор тестов может уменьшить их
количество.

 Процесс разработки
согласно современной модели жизненного цикла ПО предполагает три стадии
тестирования:

1.     
автономное тестирование компонентов ПО;

2.     
комплексное тестирование разрабатываемого
ПО;

3.     
системное или оценочное тестирование на
соответствие основным критериям качества.

Для повышения
качества тестирования рекомендуется соблюдать следующие основные принципы:

а)
предполагаемые результаты должны быть известны до тестирования;

б)
следует избегать тестирования программы автором;

в)
необходимо досконально изучать результаты каждого теста;

г) необходимо
проверять действия программы на неверных данных;

д)
необходимо проверять программу на неожиданные побочные эффекты на неверных
данных.

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

Существуют два
принципиально различных подхода к формированию тестовых наборов: структурный и
функциональный.

Структурный подход базируется на том, что известна структура тестируемого
ПО, в том числе его алгоритмы («стеклянный ящик»). Тесты строятся для проверки
правильности реализации заданной логики в коде программы.

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

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

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

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

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

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

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

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

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

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

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

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

Классификация
ошибок

а) синтаксические
ошибки – сопровождаются комментарием с указанием их мес­тоположения,
фиксируются компилятором (транслятором) при выполнении синтаксического и частично
се­мантического анализа;

б) ошибки компоновки
— обнаруживаются компоновщиком (редакто­ром связей) при объединении модулей
программы;

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

1) ошибки
определения исходных данных (ошибки передачи, ошибки преобразования, ошибки
перезаписи и ошиб­ки данных);

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

3) ошибки накопления
погрешностей результатов вычислений (игнорирование ограничений разрядной сетки
и способов уменьшения погрешности).

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

а) ручного
тестирования (при обнаружении ошибки нужно выполнить те­стируемую программу
вручную, используя тестовый набор, при работе с ко­торым была обнаружена
ошибка);

б) индукции (основан
на тща­тельном анализе симптомов ошибки, которые могут проявляться как неверные
результаты вычислений или как сообщение об ошибке);

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

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

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

Сопровождение
(поддержка) программного обеспечения

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

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

• для устранения ошибок;
• для модификации в
  соответствии с изменяющимися потребностями пользователей.

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

Принято выделять
несколько линий сопровождения (структура приведена на примере внешнего
сопровождения ПО):

0 линия
(call-center, информационный центр, горячая линия) — обработка телефонных
обращений от клиентов, передача обращений техническим специалистам (1-я линия
сопровождения)

1 линия (инженер по
сопровождению, инженер технической поддержки, support engineer) –
консультация/настройка/устранение ошибок в работе ПО/наполнение базы знаний,
составление мануалов

2 линия (инженер по
сопровождению, инженер технической поддержки, support engineer) функциональное
сопровождение/проектная деятельность на этапе запуска ПО на машинах заказчика

3 линия (инженер по
сопровождению, инженер технической поддержки, support engineer) — системное
сопровождение/проектная деятельность на этапе запуска ПО на оборудовании
заказчика

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

Ответьте на вопросы:

1)     
Что такое трансляторы?

2)     
Перечислите стадии тестирования? (3шт)

3)     
Перечислите основные стадии тестирования?

4)     
При каком условии тест считается удачным?

5)     
Виды подходов к формированию тестовых
наборов?

6)     
Структурный подход?

7)     
Функциональный подход?

     
Ручной контроль?

9)     
Отладка?

10) 
Классификация ошибок? (перечислите с
описание)

11) 
На какие группы делаться ошибки выполнения?

12) 
Дать определение Сопровождение программных
продуктов?

13) 
Для чего вносятся изменения в программный
продукт при сопровождении?

14) 
Линий сопровождения? (с описание)

Фундаментальная теория тестирования

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

Перейдем к основным понятиям

Тестирование программного обеспечения (Software Testing) — проверка соответствия реальных и ожидаемых результатов поведения программы, проводимая на конечном наборе тестов, выбранном определённым образом.

Цель тестирования — проверка соответствия ПО предъявляемым требованиям, обеспечение уверенности в качестве ПО, поиск очевидных ошибок в программном обеспечении, которые должны быть выявлены до того, как их обнаружат пользователи программы.

Для чего проводится тестирование ПО?

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

Принципы тестирования

• Принцип 1 — Тестирование демонстрирует наличие дефектов (Testing shows presence of defects).
  Тестирование только снижает вероятность наличия дефектов, которые находятся в программном обеспечении, но не гарантирует их отсутствия.
• Принцип 2 — Исчерпывающее тестирование невозможно (Exhaustive testing is impossible).
  Полное тестирование с использованием всех входных комбинаций данных, результатов и предусловий физически невыполнимо (исключение — тривиальные случаи).
• Принцип 3 — Раннее тестирование (Early testing).
  Следует начинать тестирование на ранних стадиях жизненного цикла разработки ПО, чтобы найти дефекты как можно раньше.
• Принцип 4 — Скопление дефектов (Defects clustering).
  Большая часть дефектов находится в ограниченном количестве модулей.
• Принцип 5 — Парадокс пестицида (Pesticide paradox).
  Если повторять те же тестовые сценарии снова и снова, в какой-то момент этот набор тестов перестанет выявлять новые дефекты.
• Принцип 6 — Тестирование зависит от контекста (Testing is context depending). Тестирование проводится по-разному в зависимости от контекста. Например, программное обеспечение, в котором критически важна безопасность, тестируется иначе, чем новостной портал.
• Принцип 7 — Заблуждение об отсутствии ошибок (Absence-of-errors fallacy). Отсутствие найденных дефектов при тестировании не всегда означает готовность продукта к релизу. Система должна быть удобна пользователю в использовании и удовлетворять его ожиданиям и потребностям.

Обеспечение качества (QA — Quality Assurance) и контроль качества (QC — Quality Control) — эти термины похожи на взаимозаменяемые, но разница между обеспечением качества и контролем качества все-таки есть, хоть на практике процессы и имеют некоторую схожесть.

QC (Quality Control) — Контроль качества продукта — анализ результатов тестирования и качества новых версий выпускаемого продукта.

К задачам контроля качества относятся:

• проверка готовности ПО к релизу;
• проверка соответствия требований и качества данного проекта.

QA (Quality Assurance) — Обеспечение качества продукта — изучение возможностей по изменению и улучшению процесса разработки, улучшению коммуникаций в команде, где тестирование является только одним из аспектов обеспечения качества.

К задачам обеспечения качества относятся:

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

Верификация и валидация — два понятия тесно связаны с процессами тестирования и обеспечения качества. К сожалению, их часто путают, хотя отличия между ними достаточно существенны.

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

Валидация (validation) — это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, его требованиям к системе.

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

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

1. Проектная документация — включает в себя всё, что относится к проекту в целом.
2. Продуктовая документация — часть проектной документации, выделяемая отдельно, которая относится непосредственно к разрабатываемому приложению или системе.

Этапы тестирования:

1. Анализ продукта
2. Работа с требованиями
3. Разработка стратегии тестирования и планирование процедур контроля качества
4. Создание тестовой документации
5. Тестирование прототипа
6. Основное тестирование
7. Стабилизация
8. Эксплуатация

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

Программный продукт проходит следующие стадии:

1. анализ требований к проекту;
2. проектирование;
3. реализация;
4. тестирование продукта;
5. внедрение и поддержка.

Требования

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

Атрибуты требований:

1. Корректность — точное описание разрабатываемого функционала.
2. Проверяемость — формулировка требований таким образом, чтобы можно было выставить однозначный вердикт, выполнено все в соответствии с требованиями или нет.
3. Полнота — в требовании должна содержаться вся необходимая для реализации функциональности информация.
4. Недвусмысленность — требование должно содержать однозначные формулировки.
5. Непротиворечивость — требование не должно содержать внутренних противоречий и противоречий другим требованиям и документам.
6. Приоритетность — у каждого требования должен быть приоритет(количественная оценка степени значимости требования). Этот атрибут позволит грамотно управлять ресурсами на проекте.
7. Атомарность — требование нельзя разбить на отдельные части без потери деталей.
8. Модифицируемость — в каждое требование можно внести изменение.
9. Прослеживаемость — каждое требование должно иметь уникальный идентификатор, по которому на него можно сослаться.

Дефект (bug) — отклонение фактического результата от ожидаемого.

Отчёт о дефекте (bug report) — документ, который содержит отчет о любом недостатке в компоненте или системе, который потенциально может привести компонент или систему к невозможности выполнить требуемую функцию.

Атрибуты отчета о дефекте:

1. Уникальный идентификатор (ID) — присваивается автоматически системой при создании баг-репорта.
2. Тема (краткое описание, Summary) — кратко сформулированный смысл дефекта, отвечающий на вопросы: Что? Где? Когда(при каких условиях)?
3. Подробное описание (Description) — более широкое описание дефекта (указывается опционально).
4. Шаги для воспроизведения (Steps To Reproduce) — описание четкой последовательности действий, которая привела к выявлению дефекта. В шагах воспроизведения должен быть описан каждый шаг, вплоть до конкретных вводимых значений, если они играют роль в воспроизведении дефекта.
5. Фактический результат (Actual result) — описывается поведение системы на момент обнаружения дефекта в ней. чаще всего, содержит краткое описание некорректного поведения(может совпадать с темой отчета о дефекте).
6. Ожидаемый результат (Expected result) — описание того, как именно должна работать система в соответствии с документацией.
7. Вложения (Attachments) — скриншоты, видео или лог-файлы.
8. Серьёзность дефекта (важность, Severity) — характеризует влияние дефекта на работоспособность приложения.
9. Приоритет дефекта (срочность, Priority) — указывает на очерёдность выполнения задачи или устранения дефекта.
10. Статус (Status) — определяет текущее состояние дефекта. Статусы дефектов могут быть разными в разных баг-трекинговых системах.
11. Окружение (Environment) – окружение, на котором воспроизвелся баг.

Жизненный цикл бага

Severity vs Priority

Серьёзность (severity) показывает степень ущерба, который наносится проекту существованием дефекта. Severity выставляется тестировщиком.

Градация Серьезности дефекта (Severity):

• Блокирующий (S1 – Blocker)
  тестирование значительной части функциональности вообще недоступно. Блокирующая ошибка, приводящая приложение в нерабочее состояние, в результате которого дальнейшая работа с тестируемой системой или ее ключевыми функциями становится невозможна.
• Критический (S2 – Critical)
  критическая ошибка, неправильно работающая ключевая бизнес-логика, дыра в системе безопасности, проблема, приведшая к временному падению сервера или приводящая в нерабочее состояние некоторую часть системы, то есть не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround (обходной путь/другие входные точки), позволяющий продолжить тестирование.
• Значительный (S3 – Major)
  не работает важная часть одной какой-либо функции/бизнес-логики, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
• Незначительный (S4 – Minor)
  часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определенном устройстве.
• Тривиальный (S5 – Trivial)
  почти всегда дефекты на GUI — опечатки в тексте, несоответствие шрифта и оттенка и т.п., либо плохо воспроизводимая ошибка, не касающаяся бизнес-логики, проблема сторонних библиотек или сервисов, проблема, не оказывающая никакого влияния на общее качество продукта.

Срочность (priority) показывает, как быстро дефект должен быть устранён. Priority выставляется менеджером, тимлидом или заказчиком

Градация Приоритета дефекта (Priority):

• P1 Высокий (High)
  Критическая для проекта ошибка. Должна быть исправлена как можно быстрее.
• P2 Средний (Medium)
  Не критичная для проекта ошибка, однако требует обязательного решения.
• P3 Низкий (Low)
  Наличие данной ошибки не является критичным и не требует срочного решения. Может быть исправлена, когда у команды появится время на ее устранение.

Существует шесть базовых типов задач:

• Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.
• Требование (requirement ) — задача, содержащая в себе описание реализации той или иной фичи.
• История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.
• Задача (task) — техническая задача, которую делает один из членов команды.
• Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.
• Баг (bug) — задача, которая описывает ошибку в системе.

Тестовые среды

• Среда разработки (Development Env) – за данную среду отвечают разработчики, в ней они пишут код, проводят отладку, исправляют ошибки
• Среда тестирования (Test Env) – среда, в которой работают тестировщики (проверяют функционал, проводят smoke и регрессионные тесты, воспроизводят.
• Интеграционная среда (Integration Env) – среда, в которой проводят тестирование взаимодействующих друг с другом модулей, систем, продуктов.
• Предпрод (Preprod Env) – среда, которая максимально приближена к продакшену. Здесь проводится заключительное тестирование функционала.
• Продакшн среда (Production Env) – среда, в которой работают пользователи.

Основные фазы тестирования

• Pre-Alpha: прототип, в котором всё ещё присутствует много ошибок и наверняка неполный функционал. Необходим для ознакомления с будущими возможностями программ.
• Alpha: является ранней версией программного продукта, тестирование которой проводится внутри фирмы-разработчика.
• Beta: практически готовый продукт, который разработан в первую очередь для тестирования конечными пользователями.
• Release Candidate (RC): возможные ошибки в каждой из фичей уже устранены и разработчики выпускают версию на которой проводится регрессионное тестирование.
• Release: финальная версия программы, которая готова к использованию.

Основные виды тестирования ПО

Вид тестирования — это совокупность активностей, направленных на тестирование заданных характеристик системы или её части, основанная на конкретных целях.

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

2. Классификация по доступу к коду и архитектуре:
   • Тестирование белого ящика — метод тестирования ПО, который предполагает полный доступ к коду проекта.
   • Тестирование серого ящика — метод тестирования ПО, который предполагает частичный доступ к коду проекта (комбинация White Box и Black Box методов).
   • Тестирование чёрного ящика — метод тестирования ПО, который не предполагает доступа (полного или частичного) к системе. Основывается на работе исключительно с внешним интерфейсом тестируемой системы.

3. Классификация по уровню детализации приложения:
   • Модульное тестирование — проводится для тестирования какого-либо одного логически выделенного и изолированного элемента (модуля) системы в коде. Проводится самими разработчиками, так как предполагает полный доступ к коду.
   • Интеграционное тестирование — тестирование, направленное на проверку корректности взаимодействия нескольких модулей, объединенных в единое целое.
   • Системное тестирование — процесс тестирования системы, на котором проводится не только функциональное тестирование, но и оценка характеристик качества системы — ее устойчивости, надежности, безопасности и производительности.
   • Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

4. Классификация по степени автоматизации:
   • Ручное тестирование.
   • Автоматизированное тестирование.

5. Классификация по принципам работы с приложением
   • Позитивное тестирование — тестирование, при котором используются только корректные данные.
   • Негативное тестирование — тестирование приложения, при котором используются некорректные данные и выполняются некорректные операции.

6. Классификация по уровню функционального тестирования:
   • Дымовое тестирование (smoke test) — тестирование, выполняемое на новой сборке, с целью подтверждения того, что программное обеспечение стартует и выполняет основные для бизнеса функции.
   • Тестирование критического пути (critical path) — направлено для проверки функциональности, используемой обычными пользователями во время их повседневной деятельности.
   • Расширенное тестирование (extended) — направлено на исследование всей заявленной в требованиях функциональности.

7. Классификация в зависимости от исполнителей:
   • Альфа-тестирование — является ранней версией программного продукта. Может выполняться внутри организации-разработчика с возможным частичным привлечением конечных пользователей.
   • Бета-тестирование — программное обеспечение, выпускаемое для ограниченного количества пользователей. Главная цель — получить отзывы клиентов о продукте и внести соответствующие изменения.

8. Классификация в зависимости от целей тестирования:
   • Функциональное тестирование (functional testing) — направлено на проверку корректности работы функциональности приложения.
   • Нефункциональное тестирование (non-functional testing) — тестирование атрибутов компонента или системы, не относящихся к функциональности.
     1. Тестирование производительности (performance testing) — определение стабильности и потребления ресурсов в условиях различных сценариев использования и нагрузок.
     2. Нагрузочное тестирование (load testing) — определение или сбор показателей производительности и времени отклика программно-технической системы или устройства в ответ на внешний запрос с целью установления соответствия требованиям, предъявляемым к данной системе (устройству).
     3. Тестирование масштабируемости (scalability testing) — тестирование, которое измеряет производительность сети или системы, когда количество пользовательских запросов увеличивается или уменьшается.
     4. Объёмное тестирование (volume testing) — это тип тестирования программного обеспечения, которое проводится для тестирования программного приложения с определенным объемом данных.
     5. Стрессовое тестирование (stress testing) — тип тестирования направленный для проверки, как система обращается с нарастающей нагрузкой (количеством одновременных пользователей).
     6. Инсталляционное тестирование (installation testing) — тестирование, направленное на проверку успешной установки и настройки, обновления или удаления приложения.
     7. Тестирование интерфейса (GUI/UI testing) — проверка требований к пользовательскому интерфейсу.
     8. Тестирование удобства использования (usability testing) — это метод тестирования, направленный на установление степени удобства использования, понятности и привлекательности для пользователей разрабатываемого продукта в контексте заданных условий.
     9. Тестирование локализации (localization testing) — проверка адаптации программного обеспечения для определенной аудитории в соответствии с ее культурными особенностями.
     10. Тестирование безопасности (security testing) — это стратегия тестирования, используемая для проверки безопасности системы, а также для анализа рисков, связанных с обеспечением целостного подхода к защите приложения, атак хакеров, вирусов, несанкционированного доступа к конфиденциальным данным.
     11. Тестирование надёжности (reliability testing) — один из видов нефункционального тестирования ПО, целью которого является проверка работоспособности приложения при длительном тестировании с ожидаемым уровнем нагрузки.
     12. Регрессионное тестирование (regression testing) — тестирование уже проверенной ранее функциональности после внесения изменений в код приложения, для уверенности в том, что эти изменения не внесли ошибки в областях, которые не подверглись изменениям.
     13. Повторное/подтверждающее тестирование (re-testing/confirmation testing) — тестирование, во время которого исполняются тестовые сценарии, выявившие ошибки во время последнего запуска, для подтверждения успешности исправления этих ошибок.

Тест-дизайн — это этап тестирования ПО, на котором проектируются и создаются тестовые случаи (тест-кейсы).

Техники тест-дизайна

Автор книги «A Practitioner’s Guide to Software Test Design», Lee Copeland, выделяет следующие техники тест-дизайна:

1. Тестирование на основе классов эквивалентности (equivalence partitioning) — это техника, основанная на методе чёрного ящика, при которой мы разделяем функционал (часто диапазон возможных вводимых значений) на группы эквивалентных по своему влиянию на систему значений.
2. Техника анализа граничных значений (boundary value testing) — это техника проверки поведения продукта на крайних (граничных) значениях входных данных.
3. Попарное тестирование (pairwise testing) — это техника формирования наборов тестовых данных из полного набора входных данных в системе, которая позволяет существенно сократить количество тест-кейсов.
4. Тестирование на основе состояний и переходов (State-Transition Testing) — применяется для фиксирования требований и описания дизайна приложения.
5. Таблицы принятия решений (Decision Table Testing) — техника тестирования, основанная на методе чёрного ящика, которая применяется для систем со сложной логикой.
6. Доменный анализ (Domain Analysis Testing) — это техника основана на разбиении диапазона возможных значений переменной на поддиапазоны, с последующим выбором одного или нескольких значений из каждого домена для тестирования.
7. Сценарий использования (Use Case Testing) — Use Case описывает сценарий взаимодействия двух и более участников (как правило — пользователя и системы).

Методы тестирования

Тестирование белого ящика — метод тестирования ПО, который предполагает, что внутренняя структура/устройство/реализация системы известны тестировщику.

Согласно ISTQB, тестирование белого ящика — это:

• тестирование, основанное на анализе внутренней структуры компонента или системы;
• тест-дизайн, основанный на технике белого ящика — процедура написания или выбора тест-кейсов на основе анализа внутреннего устройства системы или компонента.
• Почему «белый ящик»? Тестируемая программа для тестировщика — прозрачный ящик, содержимое которого он прекрасно видит.

Тестирование серого ящика — метод тестирования ПО, который предполагает комбинацию White Box и Black Box подходов. То есть, внутреннее устройство программы нам известно лишь частично.

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

Согласно ISTQB, тестирование черного ящика — это:

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

Тестовая документация

Тест план (Test Plan) — это документ, который описывает весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков.

Тест план должен отвечать на следующие вопросы:

• Что необходимо протестировать?
• Как будет проводиться тестирование?
• Когда будет проводиться тестирование?
• Критерии начала тестирования.
• Критерии окончания тестирования.

Основные пункты тест плана:

1. Идентификатор тест плана (Test plan identifier);
2. Введение (Introduction);
3. Объект тестирования (Test items);
4. Функции, которые будут протестированы (Features to be tested;)
5. Функции, которые не будут протестированы (Features not to be tested);
6. Тестовые подходы (Approach);
7. Критерии прохождения тестирования (Item pass/fail criteria);
8. Критерии приостановления и возобновления тестирования (Suspension criteria and resumption requirements);
9. Результаты тестирования (Test deliverables);
10. Задачи тестирования (Testing tasks);
11. Ресурсы системы (Environmental needs);
12. Обязанности (Responsibilities);
13. Роли и ответственность (Staffing and training needs);
14. Расписание (Schedule);
15. Оценка рисков (Risks and contingencies);
16. Согласования (Approvals).

Чек-лист (check list) — это документ, который описывает что должно быть протестировано. Чек-лист может быть абсолютно разного уровня детализации.

Чаще всего чек-лист содержит только действия, без ожидаемого результата. Чек-лист менее формализован.

Тестовый сценарий (test case) — это артефакт, описывающий совокупность шагов, конкретных условий и параметров, необходимых для проверки реализации тестируемой функции или её части.

Атрибуты тест кейса:

• Предусловия (PreConditions) — список действий, которые приводят систему к состоянию пригодному для проведения основной проверки. Либо список условий, выполнение которых говорит о том, что система находится в пригодном для проведения основного теста состояния.
• Шаги (Steps) — список действий, переводящих систему из одного состояния в другое, для получения результата, на основании которого можно сделать вывод о удовлетворении реализации, поставленным требованиям.
• Ожидаемый результат (Expected result) — что по факту должны получить.

Резюме

Старайтесь понять определения, а не зазубривать. Если хотите узнать больше про тестирование, то можете почитать Библию QA. А если возникнет вопрос, всегда можете задать его нам в телеграм-канале @qa_chillout.

ТЕСТИРОВАНИЕ И ОТЛАДКА

Определение и принципы тестирования

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

Процесс отладки включает:

 действия, направленные на выявление ошибок (тестирование);

 диагностику и локализацию ошибок (определение характера ошибок и их местонахождение);

 внесение исправлений в программу с целью устранения ошибок.

Из трех перечисленных видов работ самым трудоемким и дорогим является тестирование, затраты на которое приближаются к 45 % общих затрат на разработку ПС.

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

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

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

Программы, как объекты тестирования, имеют ряд особенно­стей, которые отличают процесс их тестирования от общепринято­го, применяемого при разработке аппаратуры и других технических изделий. Особенностями тестирования ПС являются:

 отсутствие эталона (программы), которому должна соответ­ствовать тестируемая программа;

 высокая сложность программ и принципиальная невозможность исчерпывающего тестирования;

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

Тестирование — это процесс многократного выполнения программы с целью выявления ошибок. Целью тестирования является обнаружение максимального числа ошибок. Поэтому тестовый прогон, в результате которого не выявлено ошибок, считается неудач­ным (неэффективным).

Существуют несколько эмпирических правил проведения тес­тирования программ, обобщающих опыт тестировщиков.

1. Процесс тестирования более эффективен, если проводится не автором программы. По своей сути тестирование — это процесс деструктивный (разрушительный). Именно этим и объясняется, поче­му многие считают его трудным. Особенно трудным и малоэффек­тивным он является для самого автора программы, так как после выполнения конструктивной части при проектировании и написания программы, ему трудно перестроиться на деструктивный образ мышления и, создав программу, тут же приступить к пристрастному выявлению в ней ошибок. Поэтому для проведения тестирования создаются специальные группы тестирования. Это не означает, что программист не может тестировать свою программу. Речь идет о повышении эффективности тестирования.

2. Необходимой частью тестового набора данных должно быть описание предполагаемых значений результатов тестовых прогонов. Тестирование как процесс многократного выполнения про­граммы проводится на многочисленных входных наборах данных. Чтобы определить правильность полученных в результате очеред­ного тестового прогона данных, необходимо знать ожидаемый ре­зультат. Таким образом, тестовый набор данных должен включать в себя два компонента: описание входных данных, описание точного и кор­ректного результата, соответствующего набору входных данных. Этот принцип сложно, а в некоторых случаях и невозможно реализовать на практике. Сложность его заключается в том, что при тестировании программы (модуля) необходимо для каждого входного набора данных рассчитать вручную ожидаемый результат или найти допустимый интервал изменения выходных данных. Процесс этот трудоемкий даже для небольших про­грамм, так как он требует ручных расчетов, следуя логике алгоритма программы. Из рассмотренного принципа, который трудно реализуем, но которого следует придерживаться логически, вытекает следующий.

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

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

5. Необходимо проверять не только, делает ли программа то, для чего она предназначена, но и не делает ли она того, чего не должна делать. Это утверждение логически вытекает из предыдущего. Необ­ходимо любую программу проверить на нежелательные побочные эффекты.

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

Основные определения

Тестирование (testing) — процесс выполнения программы или ее части с целью найти ошибки.

Доказательство (proof) — попытка найти ошибки в программе безотносительно к внешней для программы среде. Большинство методов доказательства предполагает формулировку утверждений о поведении программы и доказательство математических теорем о правильности программы. Доказательства могут рассматриваться как форма тестирования, хотя они и не предпола­гают прямого выполнения программы.

Контроль (verification) — попытка найти ошибки, выполняя программу в тестовой, или моделируемой, среде.

Испытание (validation) — попытка найти ошибки, выполняя программу в заданной реальной среде.

Аттестация (certification) — авторитетное подтверждение правильности программы. При тестировании с целью аттестации выполняется сравнение с некоторым заранее определенным стандартом.

Отладка (debugging) не является разновидностью тестирования. Хотя слова «отладка» и «тестирование» часто используются как синонимы, но под ними подразумеваются разные виды деятельности.

Тестирование — это деятельность, направленная на обнаружение ошибок.

Отладка направлена на установление точной природы известной ошибки, а затем на исправление этой ошибки. Эти два вида деятельности связаны, т.к. результаты тестирования являются исходными данными для отладки.

Тестирование модуля, или автономное тестирование (module testing, unit testing) — контроль отдельного программного модуля, обычно в изолированной среде (изолированно от всех остальных модулей).

Тестирование модуля иногда включает математическое доказательство.

Тестирование сопряжений (integration testing) — контроль сопряжений между частями системы (модулями, компонентами, подсистемами).

Тестирование внешних функций (external function testing) — контроль внешнего поведения, определенного внешними спецификациями.

Комплексное тестирование (system testing) — контроль и/или испытание системы по отношению к исходным целям.

Комплексное тестирование является процессом контроля, если оно выполняется в моделируемой среде, и процессом испытания, если выполняется в реальной среде.

Тестирование приемлемости (acceptance testing) — проверка соответствия программы требованиям пользователя.

Тестирование настройки (installation testing) — проверка соответствия каждого конкретного варианта установки системы с целью выявить любые ошибки, возникшие в процессе настройки системы.

Отношения между этими типами тестов и процессами проектирования показаны на рис. 15.

Стратегия проектирования тестов

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

1. Тестирование по отношению к спецификациям (не заботясь о тексте программы).

2. Тестирование по отношению к тексту программы (не заботясь о спецификациях).

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

Сторонники первого подхода проектирует тесты, исследуя внешние спецификации или спецификации сопряжения программы или модуля, которые он тестирует. Программа рассматривается как черный ящик. Логика их такова: «Меня не интересует, как выглядит эта программа, и выполнил ли я все команды. Я удовлетворен, если программа будет вести себя так, как указано в спецификациях». То есть в идеале проверить все возможные комбинации и значения на входе.

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

Ни одна из этих крайностей не является хорошей стратегией.

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

Интеграция модулей

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

Существует несколько подходов, которые могут быть использованы для слияния модулей в более крупные единицы. В большинстве своем они могут рассматриваться как варианты шести основных подходов, описанных ниже. Методы тестирования

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

Статическое тестирование — проводится без использова­ния ЭВМ путем просмотра текста программы после трансляции, проверки правил структурного построения программ и обработки данных. В качестве эталонов используются, во-первых, внутренние спецификации, а, во-вторых, коллективный опыт специалистов-тестировщиков. Применение статического тестирования достаточ­но эффективно. Для типичных программ, по данным фирмы IBM, можно находить от 30 % до 80 % ошибок логического проектирования и кодирования. Этот метод способствует существенному повыше­нию производительности и надежности программ, позволяет раньше обнаружить ошибки, а значит уменьшить стоимость ис­правления.

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

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

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

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

Восходящее тестирование

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

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

Нисходящее тестирование

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

При этом подходе возникают два вопроса: что делать, когда тестируемый модуль вызывает модуль более низкого уровня (которого в данный момент еще не существует), и как подаются тестовые данные. Ответ на первый вопрос состоит в том, что для имитации функций недостающих модулей программируются модули-заглушки, которые моделируют функции отсутствующих модулей. Фраза «напишите заглушку» часто встречается в описании этого подхода, но она способна ввести в заблуждение, поскольку задача написания «заглушки» может оказаться трудной. Ведь заглушка редко сводится просто к оператору RETURN, поскольку вызывающий модуль обычно ожидает от нее выходных параметров. В таких случаях в заглушку встраивают фиксированные выходные данные, которые она всегда и возвращает. Иногда это оказывается неприемлемым, так как вызывающий модуль может рассчитывать, что результат вызова зависит от входных данных. Поэтому в некоторых случаях заглушка должна быть довольно изощ­ренной, приближаясь по сложности к модулю, который она пытается моделировать.

Интересен и второй вопрос: в какой форме готовятся тестовые данные и как они передаются программе? Если бы головной модуль содержал все нужные операции ввода и вывода, ответ был бы простым: тесты пишутся в виде обычных для пользователей внешних данных и передаются программе через выделенные ей устройства ввода. Но так случается редко. В хорошо спроектированной программе физические операции ввода-вывода выполняются на нижних уровнях структуры, поскольку физический ввод-вывод — это абстракция довольно низкого уровня. Поэтому для того, чтобы решить проблему экономически эффективно, модули добавляются не в строго нисходящей последовательности (все модули одного горизонтального уровня, затем модули следующего уровня), а таким образом, чтобы обеспечить функционирование операций физического ввода-вывода как можно быстрее. Когда эта цель достигнута, нисходящее тестирование получает значительное преимущество: все дальнейшие тесты готовятся в той же форме, которая рассчитана на пользователя.

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

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

Преимуществом нисходящего подхода часто считают отсутствие необходимости в драйверах; вместо драйверов следует написать «заглушки». Однако это преимущество спорно.

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

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

Модифицированный нисходящий метод

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

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

Метод большого скачка

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

Метод большого скачка по сравнению с другими подходами имеет много недостатков и мало достоинств.

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

Метод большого скачка значительно усложняет отладку.

Если программа мала и хорошо спроек­тирована, метод большого скачка может оказаться приемлемым. Однако для крупных программ он обычно неприемлем.

Метод сандвича

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

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

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

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

Модифицированный метод сандвича

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

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

Сравнение методов тестирования

С точки зрения надежности ПО стратегии тестирования можно оценить по семи критериям (табл. 9).

Первый критерий — время до момента сборки модулей, поскольку это важно для обнаружения ошибок в сопряжениях и предположениях модулей о свойствах друг друга.

Второй критерий — время до момента создания первых работающих «скелетных» версий программы, поскольку здесь могут проявиться главные дефекты проектирования.

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

Пятый критерий — мера параллелизма, который возможен в начале или на ранних стадиях тестирования (но не концу цикла тестирования).

Шестой критерий связан с ответом на вопрос: возможно ли проверить любой конкретный путь и любое условие в программе?

Седьмой критерий характеризует сложность планирования, надзора и управления в процессе тестирования.

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

Ранняя сборка и раннее получение работающего каркаса программы, а также возможность тестировать любые конкретные условия, представляются наиболее важными, им дается вес 3.

Сложность подготовки заглушек, планирования и управления последовательностью тестов также важны, они получают вес 2.

Третий критерий, необходимость драйверов — вес 1 ввиду доступности общих инструментов тестирования.

Критерий, связанный с параллелизмом работы, имеет вес 1 (он может быть важен по другим причинам, но на надежность сильно не влияет).

Шестой критерий — вес 3.

Седьмой критерий получает вес 2.

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

Этапы тестирования

Процесс тестирования ППП начинается проверкой правильно­сти работы отдельных модулей и заканчивается приемкой после испытания ППП при его сдаче заказчику или началом коммерче­ских продаж ППП. Рассмотрим типичные этапы работы тестировщиков.

Тестирование программных модулей — наиболее форма­лизованный и автоматизированный процесс тестирования.

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

Проверяется корректность структуры модулей и их конструктивных основных компонентов: процедур, циклов, блоков, условий и т.д.

Тестирование планируется с учетом структуры модулей и особенностей обработки информации и осуществляется преиму­щественно детерминировано.

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

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

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

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

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

Сборка модулей в программный комплекс может осуществляться двумя методами: монолитным и пошаговым.

По­шаговая сборка может, в свою очередь, быть восходящей (снизу-вверх) и нисходящей (сверху-вниз).

В качестве примера рассмотрим программный пакет, состоя­щий из девяти модулей (рис. 16).

Монолитный метод сборки предполагает тестирование каж­дого из девяти модулей отдельно, а затем их одновременную сборку и тестирование в комплексе.

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

Рис. 16. Структура пакета из 9 модулей

Для рассматриваемого примера модули-драйверы нужны для всех модулей, кроме модуля М1, а модули-заглушки нужны для всех модулей, кроме М5, М6, М7, М8, М9 (т.е. модулей самого низ­шего уровня).

Таким образом, при монолитной сборке необходимо разрабо­тать восемь модулей-драйверов и минимум девять модулей-заглушек.

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

Предположим, что тестируем сверху-вниз. Тогда для модуля М1 нужно разработать три заглушки. Далее подключается модуль М2, для которого нужно предварительно разработать две заглушки, и тес­тируются модули М1-М2. Затем заглушка М5 заменяется модулем М5 и тестируется цепочка М1-М2-М5.

Процесс продолжается до тех пор, пока не будет собран весь комплекс. Есть возможность неко­торого распараллеливания работ и автономного тестирования це­почек М1-М2-М5 (М6), М1-М3-М7, М1-М4-М8 (М9).

Оказывается, что при пошаговой сборке сверху-вниз нужно разработать девять заглу­шек, но не нужны драйверы.

При тестировании снизу-вверх процесс организуется следую­щим образом: тестируются модули низшего уровня — М5, М6, М7, М8, М9. Для каждого из них нужен драйвер.

Далее параллельно проводится тестирование М5-М2, М6-М2, М7-М3, М8-М4, М9-М4. Затем подключается модуль М1 и проводится комплексное тес­тирование всего пакета.

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

Сравнивая монолитную и пошаговую сборки программ, можно отметить ряд достоинств и недостатков каждого из них.

Монолитная сборка требует больших затрат, так как предпола­гает дополнительно разработку драйверов и заглушек, в то время как при пошаговой сборке разрабатываются либо только заглушки, либо только драйверы.

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

Системное тестирование (или испытание программного комплекса) предназначено в основном для проверки соответствия пакета прикладных программ техническому заданию и для оценки его пригодности к регулярной эксплуатации и сопровождению.

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

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

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

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

Для таких коммерческих прикладных программ принято проводить испытания в два последовательных этапа, на­зываемых альфа- и бета-тестированием.

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

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

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

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

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

Лишь та ошибка, что не исправляется.

Конфуций

Отладка программного средства (ПС) — это деятельность, направленная на обнаружение и исправление ошибок в ПС с использованием процессов выполнения его программ. Отладку можно представить в виде многократного повторения трех процессов: тестирования, в результате которого может быть констатировано наличие в ПС ошибки, поиска места ошибки в программах и документации ПС и редактирования программ и документации с целью устранения обнаруженной ошибки. Другими словами: Отладка = Тестирование + Поиск ошибок + Редактирование.

Иногда тестирование и отладку считают синонимами.

Принципы и виды отладки программного средства

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

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

Рис. 17. Подходы к проектированию тестов

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

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

 на каждую используемую функцию или возможность — хотя бы один тест;

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

 на каждую особую (исключительную) ситуацию, указанную в спецификациях — хотя бы один тест.

Во втором случае стратегия базируется на принципе: каждая команда каждой программы ПС должна проработать хотя бы на одном тесте.

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

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

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

Заповеди отладки программного средства

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

Ниже приведены рекомендации по организации отладки в форме заповедей.

Заповедь 1. Считайте тестирование ключевой задачей разработки ПС, поручайте его самым квалифицированным и одаренным программистам; нежелательно тестировать свою собственную программу.

Заповедь 2. Хорош тот тест, для которого высока вероятность обнаружить ошибку, а не тот, который демонстрирует правильную работу программы.

Заповедь 3. Готовьте тесты, как для правильных, так и для неправильных данных.

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

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

Заповедь 6. Пропускайте заново все тесты, связанные с проверкой работы какой-либо программы ПС или ее взаимодействия с другими программами, если в нее были внесены изменения (например, в результате устранения ошибки).

Автономная отладка программного средства

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

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

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

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

К достоинствам восходящего тестирования относятся:

 простота подготовки тестов;

 возможность полной реализации плана тестирования модуля.

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

Недостатками восходящего тестирования являются следующие его особенности:

 тестовые данные готовятся, как правило, не в той форме, которая рассчитана на пользователя (кроме случая, когда отлаживается последний, головной, модуль отлаживаемой программы);

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

 необходимость специального тестирования сопряжения модулей.

К достоинствам нисходящего тестирования относятся следующие его особенности:

 большинство тестов готовится в форме, рассчитанной на пользователя;

 во многих случаях относительно небольшой объем отладочного программирования (имитаторы модулей, как правило, весьма просты и каждый пригоден для большого числа, нередко — для всех, тестов);

 отпадает необходимость тестирования сопряжения модулей.

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

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

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

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

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

Автономное тестирование модуля целесообразно осуществлять в четыре последовательно выполняемых шага.

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

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

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

4. Проверьте текст модуля, чтобы убедиться, что существуют тесты, проверяющие чувствительность к отдельным особым значениям входных данных. Добавьте недостающие тесты.

Комплексная отладка программного средства

При комплексной отладке тестируется ПС в целом, причем тесты готовятся по каждому из документов ПС. Тестирование этих документов производится, как правило, в порядке, обратном их разработке. Исключение составляет лишь тестирование документации по применению, которая разрабатывается по внешнему описанию параллельно с разработкой текстов программ — это тестирование лучше производить после завершения тестирования внешнего описания. Тестирование при комплексной отладке представляет собой применение ПС к конкретным данным, которые могут возникнуть у пользователя (в частности, все тесты готовятся в форме, рассчитанной на пользователя), но, возможно, в моделируемой (а не в реальной) среде. Например, некоторые недоступные при комплексной отладке устройства ввода и вывода могут быть заменены их программными имитаторами.

Тестирование архитектуры ПС. Целью тестирования является поиск несоответствия между описанием архитектуры и совокупностью программ ПС. К моменту начала тестирования архитектуры ПС должна быть уже закончена автономная отладка каждой подсистемы. Ошибки реализации архитектуры могут быть связаны, прежде всего, с взаимодействием этих подсистем, в частности, с реализацией архитектурных функций (если они есть). Поэтому хотелось бы проверить все пути взаимодействия между подсистемами ПС. При этом желательно хотя бы протестировать все цепочки выполнения подсистем без повторного вхождения последних. Если заданная архитектура представляет ПС в качестве малой системы из выделенных подсистем, то число таких цепочек будет вполне обозримо.

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

Тестирование качества ПС. Целью тестирования является поиск нарушений требований качества, сформулированных в спецификации качества ПС. Это наиболее трудный и наименее изученный вид тестирования. Далеко не каждый примитив качества ПС может быть испытан тестированием. Завершенность ПС проверяется уже при тестировании внешних функций. На данном этапе тестирование этого примитива качества может быть продолжено, если требуется получить какую-либо вероятностную оценку степени надежности ПС. Однако методика такого тестирования еще требует своей разработки. Могут тестироваться такие примитивы качества, как точность, устойчивость, защищенность, временная эффективность, в какой-то мере эффективность по памяти, эффективность по устройствам, расширяемость и, частично, независимость от устройств. Каждый из этих видов тестирования имеет свою специфику и заслуживает отдельного рассмотрения. Легкость применения ПС (критерий качества, включающий несколько примитивов качества) оценивается при тестировании документации по применению ПС.

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

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

Испытание программных продуктов Под испытанием программной продукции следует понимать экспериментальное определение количественных и/или качественных характеристик свойств продукции при ее функционировании в реальной среде и/или моделировании среды функционирования.

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

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

В соответствии с ГОСТ 19.004-80 под испытанием программ понимают установление соответствия программы заданным требованиям и программным документам. Это определение построено на предположении, что в техническом задании на разработку программы определены все требования (характеристики), обеспечение которых гарантирует пригодность программы к исполь­зованию по своему назначению.

При отсутствии технического задания (ТЗ) на разработку программного средства (ПС) или полного и обоснованного перечня требований к характеристикам разрабатываемого ПС задача испытания ПС становится неопределенной и неконструктивной.

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

Основными видами испытания программных продуктов (ПП) являются:

 предварительные;

 приемочные;

 эксплуатационные испытания, включая опытную эксплуатацию.

В зависимости от места проведения различают стендовые и полигонные испытания.

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

Если в основу стендовых испытаний положен принцип моделирования, то соответствующие испытательные стенды называют моделирующими.

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

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

По степени зависимости испытателей от разработчиков различают зависимые и независимые испытания.

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

Оценку результатов испытания производит комиссия при активном участии разработчиков.

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

Технологическая схема испытания

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

 знание назначения испытываемого ПС, условий его функционирования и требований к нему со стороны пользователей;

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

 ясное представление цели и последовательности испытания;

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

 систематический контроль, регулярное ведение протокола и журнала испытания;

 последовательное определение и выполнение плана испытания;

 сопоставление имеющихся ресурсов с предполагаемым объемом испытания;

 возможность обеспечения объективной количественной оценки полноты и достоверности результатов испытания на всех этапах.

Любому виду испытаний должна предшествовать тщательная подготовка.

В подготовку испытаний ПС входят следующие мероприятия:

 составление и согласование плана-графика проведения испытания;

 разработка, комплектование, испытание и паспортизация программно-технических средств, используемых при испытаниях;

 анализ пригодности испытательных средств, используемых во время предварительных испытаний, для проведения приемочных испытаний;

 анализ пригодности накопленных данных о качестве ПС для использования при окончательном определении значений показателей качества испытываемого ПС;

 проверка и согласование с представителем заказчика конструкторской документации на ПС, предъявляемой при испытаниях;

 разработка, согласование и утверждение программ и методик испытаний;

 аттестация специалистов на допуск к проведению испытаний;

 приемка испытываемого опытного образца ПС на носителе данных и документации;

 проведение мероприятий, направленных на обеспечение достоверности испытаний.

Следует подчеркнуть необходимость заблаговременной разработки и испытания программно-технических средств, которые будут использоваться при проведении испытаний.

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

На основании изложенного можно определить следующие пять этапов испытания:

1. Обследование проектируемого ПС, анализ проектной документации.

2. Определение наиболее важных подсистем и функций проектируемого ПС, подлежащих испытанию.

3. Анализ показателей качества ПС и методов определения их значений. Разработка программ и методик испытания.

4. Разработка (освоение) испытательных программно-техничес­ких средств, библиотек тестов и баз данных (если они требуются).

5. Непосредственное проведение испытаний, анализ результатов, принятие решения.

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

На рис. 18 изображена технологическая схема в виде этапов подготовки и проведения испытания и их связи с этапами разработки ПС.

Планирование и оценка испытаний

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

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

Рис. 18. Технологическая схема испытания ПС

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

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

4) ПС испытывают в реальной среде функционирования;

5) ПС испытывают в статистически моделируемой среде функционирования, адекватной реальной среде.

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

Методика решения задачи планирования испытания включает в себя следующие этапы:

 нахождение всех путей реализации;

 выделение минимального подмножества путей, обеспечивающих проверку всех участков программы;

 разработка тестов для проверки выделенных путей.

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

N = 1 — n/К,

где n —	количество обнаруженных и устраненных ошибок;
К -	количество экспериментов.

С возрастанием количества экспериментов критерий интенсивности обнаружения ошибок будет асимптотически стремиться к единице.

Тогда в качестве критерия прекращения испытаний можно принять, например, следующее условие: N > 0,95 при обнаружении в последних двухстах экспериментах не более трех несуще­ственных ошибок. Идея выбора такого критерия основана на том, что частота обнаружения ошибок, выраженная отношением n/К, по мере увеличения количества экспериментов должна уменьшаться и к моменту завершения испытаний принять значение, близкое к нулю. Следует иметь в виду, что оценка уровня завершенности испытаний будет достоверной лишь в случае, если каждый эксперимент проводится в новых условиях и испытатели стремятся обнаружить ошибки, а не доказать их отсутствие.

Критерий заданного значения средней наработки на отказ (критерий Дж.Д. Муса). Предположим, что суммарное количество обнаруженных и устраненных дефектов в программе n (под дефектом понимается любая причина неудовлетворенности свойствами программы) описывается показательной функцией времени функционирования t

где N0 —	исходное количество дефектов в программе; ъ
М0 —	общее количество дефектов, которое может проявиться за время эксплуатации ПС;
Т0 —	средняя наработка на отказ в начале испытаний;
С —	коэффициент сжатия тестов.

Коэффициент С 1 тогда, когда абсолютная реактивность программы при прогоне тестов или статистических испытаниях отличается от абсолютной реактивности при работе программы в реальных условиях.

Если, например, за один час испытаний моделируется управляемый процесс, происходящий в реальных условиях в течение десяти часов, то коэффициент сжатия С принимается равным 10. Скорость обнаружения и устранения дефектов, измеряемая относительно времени функционирования программы, пропорциональна интенсивности отказов. Количество зарегистрированных отказов m зависит от суммарного времени функционирования программы следующим образом:

Коэффициент пропорциональности В = n/m называется коэффициентом уменьшения дефектов.

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

В качестве критерия завершенности испытания можно принять достижение требуемого (заданного) значения средней наработки на отказ Т₀.

При планировании отладки и испытания программного обеспечения следует учитывать влияние следующих факторов:

 скорость выявления дефектов;

 скорость устранения дефектов;

 удовлетворенность машинным временем.

Первый фактор зависит от укомплектованности и квалификации испытателей, второй — от укомплектованности и квалификации группы программистов отладчиков, третий — от технической оснащенности разрабатывающей (испытывающей) организации.

Введение в тестирование программного обеспечения

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

Основные задачи тестирования программного обеспечения включают:

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

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

Функциональное тестирование

Функциональное тестирование — это тип тестирования программного обеспечения, который фокусируется на проверке возможностей и поведения приложения в соответствии с заданными требованиями. Основная цель функционального тестирования — убедиться, что программное обеспечение работает правильно, как задумано, и обеспечивает желаемую функциональность. Эта категория тестирования включает в себя различные методы тестирования, в том числе:

модульное тестирование

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

Интеграционное тестирование

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

Системное тестирование

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

Регрессионное тестирование

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

Приемочное тестирование

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

Нефункциональное тестирование

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

Тестирование производительности

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

Тестирование удобства использования

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

Тестирование безопасности

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

Тестирование на совместимость

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

Ручное тестирование

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

1. Исследовательское тестирование: При исследовательском тестировании тестировщики активно изучают приложение, разрабатывают тестовые случаи и одновременно выполняют их. Такой подход позволяет тестировщикам обнаружить дефекты, которые, возможно, не были предусмотрены на этапе разработки проекта. Исследовательское тестирование полезно, когда имеется ограниченное количество документации или формальных планов тестирования.
2. Тестирование удобства использования: Тестирование удобства использования в первую очередь направлено на оценку приложения с точки зрения конечного пользователя, анализируя, насколько легко им пользоваться и ориентироваться. Тестировщики оценивают общий пользовательский опыт, включая такие аспекты, как интуитивный дизайн, обучаемость и доступность. Этот вид тестирования помогает разработчикам улучшить пользовательский интерфейс приложения и решить любые проблемы с удобством использования, которые могут повлиять на успех приложения на рынке.
3. Регрессионное тестирование: Регрессионное тестирование направлено на обеспечение того, чтобы существующие функциональные возможности приложения не пострадали от новых изменений, таких как исправление ошибок, расширение функций или обновление системы. Тестировщики выполняют ранее запущенные тестовые случаи, чтобы убедиться, что изменения не привели к появлению новых проблем и что приложение продолжает соответствовать заданным требованиям.
4. Обнаружение ошибок: При выполнении ручных тестов тестировщики обычно следуют тестовым примерам, которые охватывают ожидаемые функциональные возможности и различные побочные случаи. С помощью этих тестовых примеров тестировщики могут найти ошибки, несоответствия и противоречия в поведении приложения.

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

Автоматизированное тестирование

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

1. Модульное тестирование: Модульное тестирование направлено на проверку правильности отдельных компонентов или функций в приложении. Разработчики пишут модульные тесты для проверки того, что их код соответствует заданным требованиям. Популярные платформы для модульного тестирования включают JUnit и TestNG для Java, NUnit для .NET и XCTest для iOS.
2. Интеграционное тестирование: Интеграционное тестирование проверяет взаимодействие между различными модулями или компонентами приложения, обеспечивая их правильную совместную работу. Этот тип тестирования помогает обнаружить проблемы, связанные с потоком данных, коммуникацией и зависимостями между модулями. Подходящие инструменты для интеграционного тестирования включают SoapUI и Postman для тестирования API и Selenium и Appium для тестирования пользовательского интерфейса.
3. Функциональное тестирование: Автоматизированное функциональное тестирование направлено на проверку соответствия функций и поведения приложения заданным требованиям. Тестировщики разрабатывают тестовые сценарии для имитации действий пользователя и проверяют, ведет ли приложение себя так, как ожидается в различных условиях. Selenium — широко используемый инструмент функционального тестирования для веб-приложений, а Appium популярен для тестирования мобильных приложений.
4. Тестирование нагрузки и производительности: Тестирование нагрузки и производительности помогает выявить узкие места, использование ресурсов и проблемы масштабируемости, которые влияют на общую производительность приложения и удобство работы пользователей при различных условиях нагрузки. Для тестирования нагрузки и производительности обычно используются такие инструменты, как JMeter, LoadRunner и Gatling.

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

Статическое тестирование

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

1. Обзор кода: Обзор кода — это процесс ручного просмотра исходного кода с целью выявления ошибок, проблем проектирования и несоответствий, которые могут повлиять на общее качество приложения. Обзоры кода способствуют сотрудничеству, обмену знаниями и соблюдению стандартов кодирования и лучших практик. Они помогают разработчикам выявить и устранить потенциальные проблемы до того, как их исправление станет сложным и дорогостоящим.
2. Статический анализ: Инструменты статического анализа автоматически анализируют исходный код для выявления проблем, связанных со стандартами кодирования, передовой практикой и потенциальными уязвимостями. Эти инструменты помогают разработчикам выявить мертвый код, утечки памяти, разыменования нулевого указателя и другие распространенные проблемы программирования. Популярные инструменты статического анализа включают SonarQube, Checkstyle и PMD.
3. Обзор документации: Обзор документации направлен на оценку проектной документации, такой как требования, проектная документация и руководства пользователя, на предмет точности, последовательности и ясности. Этот процесс помогает выявить двусмысленности, несоответствия и неполную информацию, которые могут привести к неправильным интерпретациям, предположениям и дефектам в приложении.

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

Динамическое тестирование

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

Динамическое тестирование может проводиться с использованием как ручных, так и автоматизированных методов и подразделяется на две основные категории:

Тестирование «черного ящика

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

К различным типам тестирования «черного ящика» относятся:

• функциональное тестирование
• интеграционное тестирование
• системное тестирование
• Приемочное тестирование
• Регрессионное тестирование

Тестирование «белого ящика

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

Типы тестирования «белого ящика» включают:

• модульное тестирование
• интеграционное тестирование
• анализ покрытия кода
• тестирование безопасности
• тестирование производительности

Инструменты и фреймворки для тестирования программного обеспечения

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

Управление и планирование тестирования

• HP Quality Center: Комплексный инструмент управления тестированием, который предлагает возможности планирования тестирования, выполнения тестов, управления дефектами и отчетности.
• Visual Studio Team Services: Решение для управления тестированием, интегрированное с Microsoft Visual Studio, которое поддерживает методологии гибкого тестирования.
• TestRail: веб-инструмент управления тестированием, предоставляющий возможности планирования, выполнения тестов и создания отчетов.

Функциональность и модульное тестирование

• Selenium: Инструмент автоматизации браузера с открытым исходным кодом для функционального тестирования веб-приложений, совместимый с различными языками программирования и браузерами.
• JUnit: Широко используемая система тестирования для Java-приложений, поддерживающая модульное тестирование, интеграционное тестирование и разработку на основе тестирования (TDD).
• TestNG: система тестирования для Java-приложений, созданная на основе JUnit, с дополнительными возможностями, такими как параллельное выполнение тестов и гибкость конфигурации.

Тестирование мобильных приложений

• Appium: Инструмент автоматизации тестирования с открытым исходным кодом для нативных, гибридных и мобильных веб-приложений, поддерживающий платформы Android и iOS.
• Espresso: система тестирования, специально разработанная для приложений Android, которая позволяет разработчикам писать UI-тесты для своих приложений.
• XCUITest: Система тестирования для iOS, разработанная компанией Apple для тестирования пользовательского интерфейса приложений для iOS.

Тестирование производительности и нагрузки

• JMeter: Инструмент тестирования производительности с открытым исходным кодом, используемый для нагрузочного, стресс-тестирования и функционального тестирования веб-приложений.
• LoadRunner: Широко используемый инструмент тестирования производительности, поддерживающий различные среды и протоколы приложений и обладающий широкими возможностями анализа.
• Gatling: Современный, высокопроизводительный инструмент нагрузочного тестирования веб-приложений с акцентом на масштабируемость и простоту использования.

Тестирование безопасности

• OWASP Zed Attack Proxy (ZAP): Сканер безопасности веб-приложений с открытым исходным кодом для обнаружения уязвимостей и тестирования безопасности.
• Burp Suite: Комплексная платформа для тестирования безопасности веб-приложений с различными инструментами для сканирования, эксплуатации и анализа уязвимостей.
• Metasploit: Широко используемая среда тестирования на проникновение, которая помогает специалистам по безопасности оценивать уязвимости, использовать слабые места и повышать общую безопасность.

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

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