Тестирование и поиск ошибок программного обеспечения

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

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

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

Тестирование программного обеспечения (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.

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

Что такое тестирование и отладка?

.

Что такое тестирование и отладка?

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

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

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

Отладка

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

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

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

Инструменты для тестирования и отладки

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

Типы тестирования и отладки

.

Типы тестирования и отладки

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

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

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

Типы отладки

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

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

Создание и использование тестовых примеров

.

Создание и использование тестовых примеров

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

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

Шаги для начала

1. Определите назначение вашего продукта: Будь то приложение, веб-сайт и т.д., важно определить назначение продукта, чтобы создавать эффективные тестовые примеры.
2. Определите целевую аудиторию: Понимание целевой аудитории вашего продукта поможет определить, какие тестовые примеры следует создать.
3. Определите объем тестирования: решите, какой тип тестов вы будете использовать, в каких средах будет тестироваться продукт и какие функциональные возможности будут тестироваться.
4. Проанализируйте продукт и определите, как лучше всего поступить: определите типы тестов, которые необходимо выполнить, и спланируйте порядок, в котором они должны выполняться.
5. Создайте тестовые наборы: Создайте тестовые наборы, которые будут охватывать все функции, сценарии и области продукта.
6. Запустите тестовые наборы: Выполните тестовые наборы и проверьте результаты на соответствие ожидаемым базовым показателям.
7. Исправьте любые ошибки: Если будут обнаружены какие-либо недочеты, исправьте их и повторите тестирование до тех пор, пока все неполадки не будут устранены.
8. Следите за результатами: Как только продукт будет выпущен, следите за производительностью и отслеживайте данные об использовании.

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

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

.

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

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

Выгоды

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

Методы

• Модульное тестирование: Это включает в себя тестирование базовых блоков кода и гарантирует, что все отдельные блоки кода работают должным образом и в соответствии с ожиданиями.
• Функциональное/ интеграционное тестирование: С помощью этого метода проверяются различия между функциональностью, ожидаемой при разработке программного обеспечения, и фактическим написанным кодом. Это также включает в себя тестирование различных пользовательских взаимодействий.
• Тестирование процесса: Используется для проверки ошибок, которые могут возникнуть в процессе запуска программы. Он проверяет наличие условий, которые могут привести к ошибкам в приложении.
• Тестирование производительности: Это включает в себя тестирование различных сценариев применения в условиях стресса и нагрузки. Цель состоит в том, чтобы проверить, может ли приложение масштабироваться и быстро реагировать в определенной ситуации.
• Тестирование безопасности/проникновения: Это включает в себя проверку на наличие уязвимостей в коде и оценку безопасности приложения.

Вывод

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

Отладка с использованием различных методов

Регрессионное тестирование и отладка

.

Регрессионное тестирование и отладка

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

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

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

Типы регрессионных тестов

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

Отладка

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

Вывод

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

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

.

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

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

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

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

Разница между тестированием безопасности и отладкой

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

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

Преимущества тестирования и отладки безопасности

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

Вывод

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

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

Завершение и сопровождение процесса тестирования и отладки

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

Завершение и сопровождение процесса тестирования и отладки

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

Этапы завершения и сопровождения процесса тестирования и отладки:

1. Планирование:Первым шагом в завершении и поддержании процесса тестирования и отладки является создание плана.

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

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

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

3. Выполнение теста:Как только тестовая среда настроена, следующим шагом является выполнение тестов.

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

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

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

5. Обзор:После того, как ошибки будут исправлены, следующим шагом будет просмотр результатов тестирования.

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

6. Поддержание среды отладки и тестирования:Наконец, следует поддерживать среду тестирования и отладки.

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

Основные вопросы по теме «Тестирование и отладка»

Неэффективное планирование тестирования

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

Недостаточные навыки

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

Проблемы с производительностью

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

Неадекватное тестирование

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

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

Список используемой литературы:

Библиографическое описание:

Пивоваров, Д. О. Отладка и тестирование программного обеспечения / Д. О. Пивоваров. — Текст : непосредственный // Молодой ученый. — 2022. — № 25 (420). — С. 14-15. — URL: https://moluch.ru/archive/420/93470/ (дата обращения: 11.06.2023).

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

Ключевые слова:



программное обеспечение, тестирование, функциональное тестирование, тип тестирования.

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

Процесс отладки состоит из нескольких этапов:

– определение ошибки;

– определение местонахождения ошибки;

– анализ ошибки;

– автоматизация тестирования;

– покрытие ущерба.

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

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

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

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

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

Ниже приведен список преимуществ отладки:

– экономия времени;

– создание отчетов об ошибках;

– простая интерпретация.

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

Существуют различные стратегии отладки:

– стратегия обучения;

– опыт;

– форвардный анализ;

– обратный анализ.

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

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

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

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

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

Типы тестирования, зависящие от объекта тестирования:

– модульное/unit-тестирование — проверка корректной работы отдельных модулей;

– интеграционное тестирование — проверка взаимодействия между несколькими модулями;

– системное — проверка работы программного обеспечения целиком;

– приемное — оценка соответствия требованиям, указанным в техническом задании.

Все эти типы необходимы и используются в тестировании ПМ ОО.

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

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

– тестирование производительности — работа ПОпод сильной нагрузкой;

– тестирование пользовательского интерфейса — удобство пользователя при взаимодействии с разными параметрами интерфейса;

– тестирование UX — правильность логики использования;

– тестирование защищенности — определение безопасности ПО;

– инсталляционное тестирование — поиск возникновения проблем при установке;

– тестирование совместимости — тестирование работы ПО в определенном окружении;

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

– тестирование локализации — оценка правильности версии.

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

– тестирование белого ящика;

– тестирование черного ящика;

– тестирование серого ящика.

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

– нерабочие и неоптимизированные участки кода;

– безопасность;

– ввод данных;

– условные процессы;

– неправильная работа объектов;

– некорректное отображение информации.

Основным подходом в этой стратегии является анализ кода программы.

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

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

Литература:

1. Гленфорд Майерс. Тестирование программного обеспечения. Базовый курс / Майерс Гленфорд, Баджетт Том, Сандлер Кори. — 3-е изд., 2022. — 298 c. — Текст: непосредственный.
2. Отладка (debugging): что это. — Текст: электронный // Skillfactory: [сайт]. — URL: https://blog.skillfactory.ru/glossary/otladka-debugging/ (дата обращения: 22.06.2022).

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

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

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

В задачи функционального тестирования входят:

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

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

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

Предпосылки функционального тестирования:

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

7.3. Инфраструктура процесса тестирования ПС

Под инфраструктурой процесса тестирования понимается:

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

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

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

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

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

7.3.1. Методы поиска ошибок в программах

Международный стандарт ANSI/IEEE-729-83 разделяет все ошибки в разработке программ на следующие типы.

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

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

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

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

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

Ошибки на этапах процесса тестирования.Приведенные типы ошибок распределяются по этапам ЖЦ и им соответствуют такие источники их возникновения [7.12]:

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

Рассмотрим процесс тестирования, исходя из рекомендаций стандарта ISO/IEC 12207, и приведем типы ошибок, которые обнаруживаются на каждом процессе ЖЦ.

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

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

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

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

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

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

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

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

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

Все ошибки, которые возникают в программах, принято подразделять на следующие классы [7.12]:

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

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

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

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

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

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

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

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

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

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

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

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

Приведем следующую классификацию типов отказов:

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

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

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

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

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

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