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

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

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

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

Это зависит от процесса и связанных заинтересованных сторон проекта (ов). В ИТ-отрасли у крупных компаний есть команда, отвечающая за оценку разработанного программного обеспечения в контексте заданных требований. Более того, разработчики также проводят тестирование, которое называется Unit Testing . В большинстве случаев следующие специалисты участвуют в тестировании системы в рамках своих соответствующих возможностей —

• Тестер программного обеспечения
• Разработчик программного обеспечения
• Руководитель проекта / менеджер
• Конечный пользователь

Различные компании имеют разные обозначения для людей, которые тестируют программное обеспечение на основе своего опыта и знаний, таких как Software Tester, Software Quality Assurance Engineer, QA Analyst и т. Д.

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

Когда начинать тестирование?

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

Это также зависит от используемой модели развития. Например, в модели «Водопад» формальное тестирование проводится на этапе тестирования; но в инкрементальной модели тестирование выполняется в конце каждого приращения / итерации, и все приложение тестируется в конце.

Тестирование проводится в разных формах на каждом этапе SDLC —

• На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.

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

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

На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.

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

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

Когда прекратить тестирование?

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

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

• Завершение выполнения тестового примера

• Завершение функционала и покрытие кода до определенной точки

• Уровень ошибок падает ниже определенного уровня, и высокоприоритетных ошибок не обнаружено

• Управленческое решение

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

Завершение выполнения тестового примера

Завершение функционала и покрытие кода до определенной точки

Уровень ошибок падает ниже определенного уровня, и высокоприоритетных ошибок не обнаружено

Управленческое решение

Проверка и валидация

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

Sr.No.	верификация	Проверка
1	Верификация решает проблему: «Вы правильно ее строите?»	Валидация решает проблему: «Вы строите правильную вещь?»
2	Гарантирует, что система программного обеспечения соответствует всем функциональным возможностям.	Гарантирует, что функциональные возможности соответствуют предполагаемому поведению.
3	Проверка выполняется в первую очередь и включает проверку документации, кода и т. Д.	Проверка происходит после проверки и в основном включает проверку всего продукта.
4	Сделано разработчиками.	Сделано тестерами.
5	Он имеет статическую активность, так как включает в себя сбор отзывов, пошаговые руководства и проверки для проверки программного обеспечения.	Он имеет динамическую деятельность, так как включает в себя выполнение программного обеспечения в соответствии с требованиями.
6	Это объективный процесс, и для проверки программного обеспечения не требуется никаких субъективных решений.	Это субъективный процесс и включает субъективные решения о том, насколько хорошо работает программное обеспечение.

Тестирование программного обеспечения — мифы

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

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

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

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

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

Миф 3: тестируются только полностью разработанные продукты

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

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

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

Миф 5: протестированное программное обеспечение не содержит ошибок

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

Миф 6: пропущенные дефекты из-за тестеров

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

Миф 7: тестеры несут ответственность за качество продукции

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

Миф 8: Автоматизация испытаний должна использоваться везде, где это возможно, чтобы сократить время

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

Миф 9. Любой может протестировать приложение

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

Миф 10. Единственная задача тестера — найти ошибки

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

Тестирование программного обеспечения — QA, QC & Testing

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

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

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

Аудит и Инспекция

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

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

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

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

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

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

Тестирование программного обеспечения — Стандарты ИСО

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

ISO / IEC 9126

Этот стандарт касается следующих аспектов для определения качества программного приложения —

• Качественная модель
• Внешние показатели
• Внутренние показатели
• Метрики качества в использовании

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

• функциональность
• надежность
• Юзабилити
• КПД
• Ремонтопригодность
• портативность

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

ИСО / МЭК 9241-11

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

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

ИСО / МЭК 25000: 2005

ИСО / МЭК 25000: 2005 широко известен как стандарт, в котором приведены рекомендации по требованиям и оценке качества программного обеспечения (SQuaRE). Этот стандарт помогает в организации и совершенствовании процесса, связанного с требованиями к качеству программного обеспечения и их оценками. В действительности ISO-25000 заменяет два старых стандарта ISO, то есть ISO-9126 и ISO-14598.

SQuaRE состоит из следующих частей:

• ISO 2500n — Отдел управления качеством
• ISO 2501n — Отдел качественных моделей
• ISO 2502n — Отдел измерения качества
• ISO 2503n — Отдел требований к качеству
• ISO 2504n — Отдел оценки качества

Основное содержание SQuaRE —

• Термины и определения
• Эталонные модели
• Общее руководство
• Руководства по индивидуальному разделению
• Стандарт, относящийся к разработке требований (то есть процесс спецификации, планирования, измерения и оценки)

ISO / IEC 12119

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

• Набор требований к программным пакетам.
• Инструкция по тестированию поставляемого программного пакета на соответствие указанным требованиям.

Разнообразный

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

Sr.No	Стандарт и описание
1	IEEE 829 Стандарт для формата документов, используемых на разных этапах тестирования программного обеспечения.
2	IEEE 1061 Методология для установления требований к качеству, определения, реализации, анализа и валидации процесса и продукта метрик качества программного обеспечения.
3	IEEE 1059 Руководство по проверке и проверке программного обеспечения.
4	IEEE 1008 Стандарт для модульного тестирования.
5	IEEE 1012 Стандарт для проверки и подтверждения программного обеспечения.
6	IEEE 1028 Стандарт для проверок программного обеспечения.
7	IEEE 1044 Стандарт для классификации программных аномалий.
8	IEEE 1044-1 Руководство по классификации программных аномалий.
9	IEEE 830 Руководство по разработке спецификаций системных требований.
10	IEEE 730 Стандарт для планов обеспечения качества программного обеспечения.
11	IEEE 1061 Стандарт для метрик и методологии качества программного обеспечения.
12	IEEE 12207 Стандарт для процессов жизненного цикла программного обеспечения и данных жизненного цикла.
13	BS 7925-1 Словарь терминов, используемых при тестировании программного обеспечения.
14	BS 7925-2 Стандарт для тестирования программных компонентов.

IEEE 829

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

IEEE 1061

Методология для установления требований к качеству, определения, реализации, анализа и валидации процесса и продукта метрик качества программного обеспечения.

IEEE 1059

Руководство по проверке и проверке программного обеспечения.

IEEE 1008

Стандарт для модульного тестирования.

IEEE 1012

Стандарт для проверки и подтверждения программного обеспечения.

IEEE 1028

Стандарт для проверок программного обеспечения.

IEEE 1044

Стандарт для классификации программных аномалий.

IEEE 1044-1

Руководство по классификации программных аномалий.

IEEE 830

Руководство по разработке спецификаций системных требований.

IEEE 730

Стандарт для планов обеспечения качества программного обеспечения.

IEEE 1061

Стандарт для метрик и методологии качества программного обеспечения.

IEEE 12207

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

BS 7925-1

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

BS 7925-2

Стандарт для тестирования программных компонентов.

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

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

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

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

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

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

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

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

Что автоматизировать?

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

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

Когда автоматизировать?

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

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

Как автоматизировать?

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

• Определение областей в программном обеспечении для автоматизации
• Выбор подходящего инструмента для автоматизации тестирования
• Написание тестовых скриптов
• Разработка тестовых костюмов
• Выполнение скриптов
• Создать отчеты о результатах
• Определите любую потенциальную ошибку или проблемы с производительностью

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

Следующие инструменты могут быть использованы для автоматизации тестирования —

• HP Quick Test Professional
• Селен
• IBM Rational Functional Tester
• SilkTest
• TestComplete
• Тестирование везде
• WinRunner
• LoadRunner
• Visual Studio Test Professional
• Watir

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

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

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

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

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

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

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

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

Тестировщик должен заглянуть в исходный код и выяснить, какой блок / блок кода ведет себя неадекватно.

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

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

Тестирование серой коробки

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

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

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

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

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

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

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

В процессе тестирования существуют разные уровни. В этой главе дается краткое описание этих уровней.

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

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

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

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

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

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

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

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

меры	Описание
я	Определение функциональности, для которой предназначенное приложение предназначено.
II	Создание тестовых данных на основе спецификаций приложения.
III	Вывод основан на данных испытаний и спецификациях приложения.
IV	Написание тестовых сценариев и выполнение тестовых случаев.
В	Сравнение фактических и ожидаемых результатов на основе выполненных тестовых случаев.

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

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

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

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

Ограничения юнит-тестирования

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

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

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

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

Sr.No.	Метод тестирования интеграции
1	Восходящая интеграция Это тестирование начинается с модульного тестирования, за которым следуют тесты прогрессивно более высокого уровня комбинаций модулей, называемых модулями или сборками.
2	Интеграция сверху вниз В этом тестировании модули высшего уровня тестируются в первую очередь, а затем постепенно тестируются модули более низкого уровня.

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

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

Интеграция сверху вниз

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

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

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

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

Системное тестирование важно по следующим причинам:

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

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

• Приложение тестируется в среде, очень близкой к производственной среде, в которой оно будет развернуто.

• Системное тестирование позволяет нам тестировать, проверять и проверять как бизнес-требования, так и архитектуру приложения.

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

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

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

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

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

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

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

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

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

• Смягчает риски, когда регрессионное тестирование выполняется в приложении.

• Тестовое покрытие увеличивается без ущерба для сроков.

• Увеличьте скорость для продвижения продукта.

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

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

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

Тестовое покрытие увеличивается без ущерба для сроков.

Увеличьте скорость для продвижения продукта.

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

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

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

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

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

Этот тест является первым этапом тестирования и будет проводиться среди команд (разработчиков и команд QA). Модульное тестирование, интеграционное тестирование и тестирование системы в сочетании друг с другом называется альфа-тестированием. На этом этапе в приложении будут проверены следующие аспекты:

• Орфографические ошибки

• Неработающие ссылки

• Облачно

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

Орфографические ошибки

Неработающие ссылки

Облачно

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

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

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

• Пользователи установят, запустят приложение и отправят свои отзывы команде проекта.

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

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

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

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

Пользователи установят, запустят приложение и отправят свои отзывы команде проекта.

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

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

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

Наличие более качественного приложения при его публикации широкой публике повысит удовлетворенность клиентов.

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

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

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

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

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

• Сетевая задержка

• Обработка на стороне клиента

• Обработка транзакций базы данных

• Балансировка нагрузки между серверами

• Рендеринг данных

Сетевая задержка

Обработка на стороне клиента

Обработка транзакций базы данных

Балансировка нагрузки между серверами

Рендеринг данных

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

• Скорость (т.е. время отклика, рендеринг и доступ к данным)

• Вместимость

• стабильность

• Масштабируемость

Скорость (т.е. время отклика, рендеринг и доступ к данным)

Вместимость

стабильность

Масштабируемость

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

Нагрузочное тестирование

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

В большинстве случаев нагрузочное тестирование выполняется с помощью автоматизированных инструментов, таких как Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test и т. Д.

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

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

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

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

• Завершение или перезапуск сетевых портов случайным образом

• Включение или выключение базы данных

• Запуск различных процессов, которые потребляют ресурсы, такие как процессор, память, сервер и т. Д.

Завершение или перезапуск сетевых портов случайным образом

Включение или выключение базы данных

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

Юзабилити-тестирование

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

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

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

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

В дополнение к различным определениям юзабилити существуют некоторые стандарты и модели и методы качества, которые определяют юзабилити в форме атрибутов и податрибутов, таких как ISO-9126, ISO-9241-11, ISO-13407 и IEEE std. 610,12 и т. Д.

Пользовательский интерфейс против юзабилити-тестирования

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

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

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

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

• конфиденциальность

• целостность

• Аутентификация

• Доступность

• авторизация

• Неотрекаемость

• Программное обеспечение защищено от известных и неизвестных уязвимостей

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

• Программное обеспечение соответствует всем правилам безопасности

• Проверка и проверка ввода

• Атаки SQL-вставки

• Недостатки впрыска

• Вопросы управления сессиями

• Межсайтовые скриптовые атаки

• Уязвимости переполнения буфера

• Атаки с обходом каталогов

конфиденциальность

целостность

Аутентификация

Доступность

авторизация

Неотрекаемость

Программное обеспечение защищено от известных и неизвестных уязвимостей

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

Программное обеспечение соответствует всем правилам безопасности

Проверка и проверка ввода

Атаки SQL-вставки

Недостатки впрыска

Вопросы управления сессиями

Межсайтовые скриптовые атаки

Уязвимости переполнения буфера

Атаки с обходом каталогов

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

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

• Перенос установленного программного обеспечения с одного компьютера на другой.

• Сборка исполняемого файла (.exe) для запуска программного обеспечения на разных платформах.

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

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

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

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

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

• Интеграционное тестирование выполнено.

• Тестовая среда была создана.

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

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

Интеграционное тестирование выполнено.

Тестовая среда была создана.

Тестирование программного обеспечения — Документация

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

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

• План испытаний
• Тестовый сценарий
• Прецедент
• Матрица прослеживаемости

План испытаний

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

План тестирования включает в себя следующее —

• Введение в документ плана испытаний
• Допущения при тестировании приложения
• Список тестовых случаев, включенных в тестирование приложения
• Список возможностей для тестирования
• Какой подход использовать при тестировании программного обеспечения?
• Список результатов, которые должны быть проверены
• Ресурсы, выделенные для тестирования приложения
• Любые риски, связанные с процессом тестирования
• График выполнения задач и этапов

Тестовый сценарий

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

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

Прецедент

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

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

• Идентификатор теста
• Модуль продукта
• Версия продукта
• Лист регистраций изменений
• Цель
• Предположения
• Предпосылки
• меры
• Ожидаемый результат
• Фактический результат
• Постусловий

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

Матрица прослеживаемости

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

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

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

Тестирование программного обеспечения — методы оценки

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

Функциональный точечный анализ

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

• Выходы
• расспросы
• входные
• Внутренние файлы
• Внешние файлы

Анализ тестовых точек

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

Метод Марк-II

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

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

Разнообразный

Вы можете использовать другие популярные методы оценки, такие как —