Тестирование в жизненном цикле разработки программного обеспечения

До начала 80-х годов процесс тестирования программного обеспечения был разделен с процессом разработки: вначале программисты реализовывали заданную функциональность, а затем тестировщики приступали к проверке качества созданных программ. Такая модель жизненного цикла разработки ПО называется каскадной (или водопадной) и состоит из 5 основных этапов: разработка требований к программе, проектирование, реализация, тестирование и сопровождение. Однако описанный выше подход создает множество проблем. Например, разработка программ может оказаться достаточно длительной (скажем, несколько месяцев), чем тогда в это время должны заниматься тестировщики? Другая, более серьезная проблема заключается в плохой предсказуемости результатов такого процесса разработки. Ключевым вопросом здесь может быть: какое количество времени потребуется на завершение продукта, в котором существует 500 известных ошибок? На самом деле, предугадать это совершенно невозможно, так как разные ошибки будут требовать разного количества времени на исправление, а исправление известных ошибок будет неизбежно связано с внесением новых. Существует следующая мрачная статистика: даже однострочное изменение в программе с вероятностью 55 % либо не исправляет старую ошибку, либо вносит новую. Если же учитывать изменения любого объема, то в среднем менее 20 % изменений корректны с первого раза.

В связи с этим, в 90-х годах появилась другая методика разработки, которую вслед за компанией Microsoft называют zero-defect mindset. Основная идея этой методики заключается в том, что качество программ проверяется не post factum, а постоянно в процессе разработки. Например, программист не может перейти к разработке новой функциональности, если существуют известные ошибки высокого приоритета в частях, разработанных им ранее. Так появились шарнирно-каскадная (или V-образная), а также спиралевидная модели разработки ПО.

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

---

На разных этапах жизненного цикла ПО тестирование проводится в разных формах:

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

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

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

Уровни тестирования[5]

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

Цель: проверка правильности реализации функциональных / нефункциональных требований в модуле, раннее обнаружение ошибок.

Объект: модуль / компонент / unit.

Базис: дизайн системы, код, спецификация компонента.

Типичные ошибки: ошибка в реализации требований, ошибка в коде.

Ответственный: разработчик (редко тестировщик).

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

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

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

Цель: проверка правильности реализации взаимодействия между компонентами / модулями / частями системы.

Объект: модули, состоящие из нескольких компонентов; подсистемы, API, микросервисы.

Базис: дизайн системы, архитектура системы, описание связей компонентов.

---

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

Ответственный: разработчик и тестировщик.

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

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

Цель: проверка работы системы в целом.

Объект: система, конфигурации системы, рабочее окружение.

Базис: системные требования, бизнес требования, сценарии использования, User Stories, системные руководства, инструкции.

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

Ответственный: тестировщик.

Системное тестирование может включать в себя различные типы тестирования. Эти тесты все чаще автоматизируется и именно этот вид автоматизации сейчас очень востребован (JAVA, Python, JavaScript, C#, Selenium и т.п.)

Приёмочное тестирование — проверяет соответствие системы потребностям, требованиям и бизнес-процессам пользователя.

Существуют несколько форм приемочного тестирования:

Пользовательское приемочное тестирование (User Acceptance testing, UAT) — проверяет пригодность системы к эксплуатации конечными пользователями.

Контрактное приемочное тестирование — проводится в соответствии с критериями, указанными в контракте приемки специального ПО.

Альфа-тестирование (alpha testing) и бета-тестирование (beta-testing) — используются для получения обратной связи от потенциальных или существующих клиентов.

Альфа-тестирование проводится “внутри” компании, без участия разработчиков / тестировщиков продукта.

Бета-тестирование проводится реальными пользователями системы.

Цель: проверка готовности системы.

Объект: система, конфигурация системы, бизнес процессы, отчеты, аналитика.

---

Базис: системные требования, бизнес требования, сценарии использования, User Stories.

Типичные ошибки: бизнес-требования неправильно реализованы, система не соответствует требованиям контракта.

Ответственный: заказчик / клиент / бизнес-аналитик / product owner и тестировщик.

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

1.2 ВИДЫ И МЕТОДЫ ТЕСТИРОВАНИЯ

1.2.1 ВИДЫ ТЕСТИРОВАНИЯ ПО ЦЕЛИ

Все виды тестирования программного обеспечения, в зависимости от преследуемых целей, можно условно разделить на следующие группы[1]:

• 
  Функциональные.
  
• 
  Нефункциональные.
  
• 
  Связанные с изменениями.
  

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

Функциональные тесты базируются на функциях и особенностях, а также на взаимодействии с другими системами и могут быть представлены на всех уровнях тестирования: компонентном или модульном (Component/Unit testing), интеграционном (Integration testing), системном (System testing), приемочном (Acceptance testing). Функциональные виды тестирования рассматривают внешнее поведение системы. Далее перечислены одни из самых распространенных видов функциональных тестов.

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

1. Функциональные тесты основываются на функциях, выполняемых системой, и могут проводиться на всех уровнях тестирования (компонентном, интеграционном, системном, приемочном). Как правило, эти функции описываются в требованиях, функциональных спецификациях или в виде случаев использования системы (use cases).

Тестирование функциональности может проводиться в двух аспектах[1]:

• 
  Требования.
  
• 
  Бизнес-процессы.
  

Тестирование в аспекте «требования» использует спецификацию функциональных требований к системе, как основу для дизайна тестовых случаев (Test Cases). В этом случае необходимо сделать список того, что будет тестироваться, а что нет, приоритезировать требования на основе рисков (если это не сделано в документе с требованиями), а на основе этого приоритезировать тестовые сценарии (test cases). Это позволит сфокусироваться и не упустить при тестировании наиболее важный функционал.

Тестирование в аспекте «бизнес-процессы» использует знание бизнес-процессов, которые описывают сценарии ежедневного использования системы. В этом аспекте тестовые сценарии (test scripts), как правило, основываются на случаях использования системы (use cases).

---

2. Тестирование безопасности (Security and Access Control Testing)

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

---

Смотрите также файлы

• Все мы едины, все мы оренбургцы так писал поэт и общественный деятель Гавриил Романович Державин.docx

• Протокол от 2022г. Рассмотрено на педагогическом совете Протокол .docx

• Отчет по производственной практике (по профилю специальности) Лит. Листов 100 втжт филиал ргупс содержание.pdf

• 10кл. Бжб2. Жер планетасындаы ауіпті алдытар, леуметтік тесіздік адам ытары жне кмек.docx

• Седьмая.docx