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

---

Аннотация

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

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

Тестирование ПО, методы тестирования, полевые условия для тестирования, обнаружения ошибок, проблемы

---

I. Введение

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

A. Кто проводит тестирование

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

• менеджер проекта;
• тестировщик ПО;
• разработчик ПО;
• конечный пользователь.

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

B. Кто начинает тестирование

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

C. Когда прекращать тестирование

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

Ошибка — Неправильное требование (функциональное/нефункциональное), приводящее к непредвиденной работе программы.

Ошибка — Любая ошибка, допущенная разработчиком во время разработки.

Сбой — Симптом ошибки.

Сбой > Ошибка > Сбой

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

II. Мифы о тестировании

Ниже приведены некоторые распространённые мифы о тестировании программного обеспечения.

Миф 1

Миф: Тестирование слишком дорого.

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

Миф 2

Миф: Пропущенные дефекты — дело рук тестировщиков.

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

Миф 3

Миф: Полное тестирование возможно.

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

Миф 4

Миф: Тестирование занимает много времени.

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

Миф 5

Миф: Тестирование может выполнять только команда тестирования.

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

Миф 6

Миф: Качество продукта — ответственность тестировщиков.

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

Миф 7

Миф: Тестирование проводится только после полной разработки продукта.

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

Миф 8

Миф: После тестирования продукт полностью свободен от ошибок.

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

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

При тестировании программного обеспечения оно должно пройти три этапа:

1. а) модульное тестирование;
2. б) интеграционное тестирование;
3. в) системное тестирование;
4. г) приемочное тестирование, как показано на следующем рисунке.

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

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

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

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

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

Тестирование сверху вниз

В этом тестировании сначала тестируются основные модули, называемые верхним модулем, а затем тестируются все остальные модули.

Тестирование снизу вверх

В этом тестировании сначала тестируется модуль снизу вверх, а затем тестируются все модули.

Смешанный подход

Это лучший подход, поскольку он сочетает в себе особенности подходов «сверху вниз» и «снизу вверх».

В этом случае сначала устанавливаются все модули, а затем проводится тестирование.

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

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

Альфа-тестирование

Этот тип системного тестирования выполняется разработчиками программного обеспечения. Таким образом, команда разработчиков в основном отвечает за тестирование.

Бета-тестирование

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

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

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

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

Здесь рассматриваются два метода тестирования.

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

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

a. Тестирование на выявлении ошибок

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

б. Тестирование на основе покрытия

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

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

While (x!=y){
If (x<=y) then
	y=y-x;
else 
	x=x-y;
}
Return x;
}

Итак, для этой программы, если выбрать тестовый случай {(x=2,y=2), (x=3,y=2), (x=2,y=3)}, то все операторы программы будут выполнены хотя бы один раз.

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

If (x > y)
z = 4
else z = 5
z= z + z

B. Тестирование методом чёрного ящика

Используется для проверки функциональных требований. Выполняется для проверки всех входных и выходных данных этих требований.

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

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

1. a. Разбиение классов эквивалентности;
2. b. Анализ граничных значений.

Метрика цикломатической сложности Маккейба

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

Метод 1

Количество предикатов + 1, т.е. x и y — предикаты, поэтому 2 + 1 = 3.

Метод 2

E – N + 2, E — ребро, а N — узел, поэтому 6 – 5 + 2 = 3.

Метод 3

Количество замкнутых областей + 1, т.е. 2 + 1 = 3

V. Новый подход: тестирование объектно-ориентированных программ

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

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

Поэтому здесь я собираюсь рассмотреть два типа схем тестирования, применяемых к объектно-ориентированным программам.

A. Тестирование методом серого ящика

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

Тестирование модели состояния: проверяет каждый метод объекта, переход и пути перехода в каждом состоянии объекта.

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

B. Интеграционное тестирование: включает два основных типа

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

VI. Заключение

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

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

Затраты на тестирование можно снизить, используя различные инструменты автоматизации тестирования.

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

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

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

Ссылки

1. [1] C.Easteal and G.Davis, Software Engineering Analysis and Design, Tata McGraw Hill.
2. [2] Richard Fairley ,Software Engineeering Concepts ,Tata Mcgraw Hill.
3. [3] Ian Sommeriele, “Software Engineering”, Addison Wesley.
4. [4] Pressman, Software Engineering –A Practitioner’s Approach.
5. [5] Pankaj Jalote , An Integrated Approach to Software engineering, Narosa Publication.
6. [6] T.H. Shivkumar, ”Software Testing Techniques”Volume 2,Issye 10,ISSN:2277 128X.
7. [7] Jovanovi,c, Irena,”Software Testing Methods and Techniques”Page No-30-41.
8. [8] Software Testing Overview, available: http://www.tutorialspoint.com/software_testing/soft ware_testing_quick_guide.htm.