Обзор тестирования программного обеспечения

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

Проверка программного обеспечения

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

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

Проверка программного обеспечения

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

  • Проверка гарантирует, что разрабатываемый продукт соответствует проектным спецификациям.
  • Проверка отвечает на вопрос: «Разрабатываем ли мы этот продукт, строго следуя всем проектным спецификациям?»
  • Проверки сосредоточены на дизайне и технических характеристиках системы.

Цель теста -

  • Errors- Это настоящие ошибки кодирования, допущенные разработчиками. Кроме того, существует разница в выводе программного обеспечения и желаемом выводе, что считается ошибкой.

  • Fault- При наличии ошибки возникает ошибка. Неисправность, также известная как ошибка, является результатом ошибки, которая может вызвать сбой системы.

  • Failure - отказ - это неспособность системы выполнить желаемую задачу. Отказ происходит, когда в системе существует неисправность.

Ручное против автоматизированного тестирования

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

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

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

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

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

Существуют программные и аппаратные средства, которые помогают тестировщику проводить нагрузочное тестирование, стресс-тестирование, регрессионное тестирование.

Подходы к тестированию

Испытания могут проводиться на основе двух подходов -

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

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

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

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

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

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

Методы тестирования черного ящика:

  • Equivalence class- Вход разделен на похожие классы. Если один элемент класса проходит проверку, предполагается, что пройден весь класс.

  • Boundary values- Входные данные делятся на верхнее и нижнее конечные значения. Если эти значения проходят проверку, предполагается, что все значения между ними также могут пройти.

  • Cause-effect graphing- В обоих предыдущих методах одновременно проверяется только одно входное значение. Причина (вход) - Эффект (выход) - это метод тестирования, при котором комбинации входных значений проверяются систематическим образом.

  • Pair-wise Testing- Поведение программного обеспечения зависит от множества параметров. При попарном тестировании несколько параметров проверяются попарно на предмет их различных значений.

  • State-based testing- Система меняет состояние при предоставлении ввода. Эти системы тестируются на основе их состояний и вводимых данных.

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

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

В этом методе тестирования тестировщику известны дизайн и структура кода. Программисты кода проводят этот тест на коде.

Ниже приведены некоторые методы тестирования белого ящика:

  • Control-flow testing- Цель тестирования потока управления - установить тестовые примеры, которые охватывают все операторы и условия перехода. Условия ветвления проверяются как на истинность, так и на ложность, чтобы можно было охватить все утверждения.

  • Data-flow testing- Этот метод тестирования направлен на охват всех переменных данных, включенных в программу. Он проверяет, где переменные были объявлены и определены и где они были использованы или изменены.

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

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

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

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

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

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

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

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

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

  • Functionality testing - Проверяет все функции программного обеспечения на соответствие требованиям.

  • Performance testing- Этот тест доказывает, насколько эффективно программное обеспечение. Он проверяет эффективность и среднее время, затрачиваемое программным обеспечением на выполнение желаемой задачи. Тестирование производительности выполняется посредством нагрузочного тестирования и стресс-тестирования, при котором программное обеспечение подвергается высокой пользовательской нагрузке и нагрузке на данные в различных условиях среды.

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

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

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

  • Alpha testing- Команда разработчиков сама выполняет альфа-тестирование, используя систему, как если бы она использовалась в рабочей среде. Они пытаются выяснить, как пользователь отреагирует на какое-либо действие в программном обеспечении и как система должна реагировать на ввод.

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

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

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

Документация по тестированию

Документы на тестирование готовятся на разных этапах -

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

Тестирование начинается с генерации тестовых случаев. Следующие документы необходимы для справки -

  • SRS document - Документ функциональных требований

  • Test Policy document - Здесь описывается, как далеко должно пройти тестирование до выпуска продукта.

  • Test Strategy document - Здесь подробно описаны аспекты группы тестирования, матрица ответственности и права / ответственность менеджера по тестированию и инженера по тестированию.

  • Traceability Matrix document- Это документ SDLC, связанный с процессом сбора требований. По мере поступления новых требований они добавляются в эту матрицу. Эти матрицы помогают тестировщикам узнать источник требований. Их можно проследить вперед и назад.

Во время тестирования

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

  • Test Case document- В этом документе содержится список тестов, которые необходимо провести. Он включает план модульного тестирования, план тестирования интеграции, план тестирования системы и план приемочного тестирования.

  • Test description - Этот документ представляет собой подробное описание всех тестовых примеров и процедур их выполнения.

  • Test case report - Этот документ содержит отчет о тестовом примере в результате тестирования.

  • Test logs - Этот документ содержит журналы тестирования для каждого отчета о тестировании.

После тестирования

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

  • Test summary- Эта сводка испытаний представляет собой коллективный анализ всех отчетов и журналов испытаний. Он подводит итоги и делает вывод о том, готово ли программное обеспечение к запуску. Программное обеспечение выпускается под системой контроля версий, если оно готово к запуску.

Тестирование против контроля качества, обеспечения качества и аудита

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

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

  • Software quality control- Это система для поддержания качества программного продукта. Он может включать в себя функциональные и нефункциональные аспекты программного продукта, которые повышают репутацию организации. Эта система гарантирует, что заказчик получает качественный продукт, соответствующий его требованиям, и что продукт сертифицирован как «пригодный для использования».

  • Software audit- Это обзор процедуры, используемой организацией для разработки программного обеспечения. Группа аудиторов, независимая от группы разработчиков, изучает программный процесс, процедуру, требования и другие аспекты SDLC. Целью аудита программного обеспечения является проверка того, что программное обеспечение и процесс его разработки соответствуют стандартам, правилам и нормам.