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

• Название: Уровни тестирования
• Дата: 27.07.2022
• Размер: 370.53 Kb.
• Имя файла: уровни тестирования.pdf
• Тип: Документы; #636999

1
Учебные материалы
по теме
«Уровни тестирования»
(ДПО)
Тестирование – это процесс оценки системы или ее компонентов с целью выяснить, удовлетворяет ли она указанным требованиям или нет.
Проще говоря, тестирование – это выполнение системы с целью выявления пробелов, ошибок или отсутствующих требований, противоречащих фактическим требованиям.
В соответствии со стандартом ANSI / IEEE 1059 тестирование можно определить как – процесс анализа элемента программного обеспечения для выявления различий между существующими и требуемыми условиями (то есть дефектами / ошибками / ошибками) и для оценки характеристик элемента программного обеспечения.
Кто проводит тестирование?
Это зависит от процесса и связанных заинтересованных сторон проекта (ов). В ИТ-отрасли у крупных компаний есть команда, отвечающая за оценку разработанного программного обеспечения в контексте заданных требований. Более того, разработчики также проводят тестирование, которое называется Unit Testing. В большинстве случаев следующие специалисты участвуют в тестировании системы в рамках своих соответствующих возможностей –
 Тестер программного обеспечения.
 Разработчик программного обеспечения.
 Руководитель проекта / менеджер.
 Конечный пользователь.
Различные компании имеют разные обозначения для людей, которые тестируют программное обеспечение на основе своего опыта и знаний, таких как Software Tester, Software Quality Assurance Engineer, QA
Analyst и т. д.
Невозможно протестировать программное обеспечение в любое время в течение его цикла. В следующих двух разделах указано, когда следует начинать тестирование и когда его завершать во время SDLC.
Когда начинать тестирование?
Своевременное начало тестирования снижает затраты и время на доработку и создание безошибочного программного обеспечения, которое доставляется клиенту. Однако в жизненном цикле разработки программного обеспечения (SDLC) тестирование можно начинать с этапа сбора требований и продолжать до развертывания программного обеспечения.

2
Это также зависит от используемой модели развития. Например, в модели «Водопад» формальное тестирование проводится на этапе тестирования; но в инкрементальной модели тестирование выполняется в конце каждого приращения / итерации, и все приложение тестируется в конце.
Тестирование проводится в разных формах на каждом этапе SDLC:
 На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.
 Проверка проекта на этапе проектирования с целью улучшения дизайна также рассматривается как тестирование.
 Тестирование, выполняемое разработчиком по завершении кода, также относится к категории тестирования.
На этапе сбора требований анализ и проверка требований также рассматриваются как тестирование.
Проверка проекта на этапе проектирования с целью улучшения дизайна также рассматривается как тестирование.
Тестирование, выполняемое разработчиком по завершении кода, также относится к категории тестирования.
Когда прекратить тестирование?
Трудно определить, когда прекратить тестирование, поскольку тестирование является бесконечным процессом, и никто не может утверждать, что программное обеспечение протестировано на 100%.
Следующие аспекты должны быть рассмотрены для остановки процесса тестирования:
 Сроки тестирования.
 Завершение выполнения тестового примера.
 Завершение функционала и покрытие кода до определенной точки.
 Уровень ошибок падает ниже определенного уровня, и высокоприоритетных ошибок не обнаружено.
 Управленческое решение.
Проверка и валидация.
Эти два термина очень запутаны для большинства людей, которые используют их взаимозаменяемо. В следующей таблице указаны различия между проверкой и проверкой.

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

4
4. Миф: полное тестирование возможно.
Реальность – становится проблемой, когда клиент или тестер считает, что полное тестирование возможно. Возможно, что все пути были проверены командой, но полное тестирование никогда не возможно.
Могут существовать некоторые сценарии, которые никогда не выполняются группой тестирования или клиентом в течение жизненного цикла разработки программного обеспечения и могут выполняться после развертывания проекта.
5. Миф: протестированное программное обеспечение не
содержит ошибок.
Реальность – это очень распространенный миф, в который верят клиенты, менеджеры проектов и команда менеджеров. Никто не может с полной уверенностью утверждать, что программное приложение не содержит ошибок на 100%, даже если тестировщик с превосходными навыками тестирования протестировал тестирование. приложение.
6. Миф: пропущенные дефекты из-за тестеров.
Реальность.
Это неправильный подход к обвинению тестировщиков в ошибках, которые остаются в приложении даже после проведения тестирования. Этот миф относится к ограничениям времени, стоимости и требований. Однако стратегия тестирования может также привести к тому, что команда тестирования пропустит ошибки.
7. Миф: тестеры несут ответственность за качество
продукции.
Реальность.
Это очень распространенное неправильное толкование того, что только тестировщики или группа тестирования должны отвечать за качество продукта. В обязанности тестировщиков входит выявление ошибок для заинтересованных сторон, а затем они сами решают, исправят ли они ошибку или выпустят программное обеспечение. Выпуск программного обеспечения в то же время оказывает большее давление на тестеров, так как они будут обвинены в любой ошибке.
8. Миф: Автоматизация испытаний должна использоваться
везде, где это возможно, чтобы сократить время.
Реальность – да, это правда, что автоматизация тестирования сокращает время тестирования, но невозможно запустить автоматизацию тестирования в любой момент во время разработки программного обеспечения. Тестовый автомат должен быть запущен, когда программное обеспечение было проверено вручную и в какой-то степени стабильно. Более того, автоматизация тестирования никогда не может быть использована, если требования постоянно меняются.

5
9. Миф. Любой может протестировать приложение.
Реальность – люди за пределами IT-индустрии думают и даже верят, что любой может протестировать программное обеспечение, и тестирование – это не творческая работа. Однако тестеры очень хорошо знают, что это миф. Думая об альтернативных сценариях, попытка сбить программное обеспечение с целью изучения потенциальных ошибок не представляется возможным для человека, который его разработал.
10. Миф. Единственная задача тестера – найти ошибки.
Реальность. Поиск багов в программном обеспечении – задача тестировщиков, но в то же время они являются экспертами в области конкретного программного обеспечения.
Разработчики несут ответственность только за конкретный компонент или область, назначенную им, но тестировщики понимают общую работу программного обеспечения, каковы зависимости и влияние одного модуля на другой модуль.
Тестирование программного обеспечения – QA, QC & Testing.
Тестирование, обеспечение качества и контроль качества.
Большинство людей смущаются, когда дело доходит до определения различий между обеспечением качества, контролем качества и тестированием. Хотя они взаимосвязаны и в некоторой степени они могут рассматриваться как одни и те же виды деятельности, но существуют отличительные моменты, которые выделяют их. В следующей таблице перечислены пункты, которые различают QA, QC и
Testing.
Гарантия качества
Контроль качества
тестирование
QA включает в себя действия, которые обеспечивают реализацию процессов, процедур и стандартов в контексте проверки разработанного программного обеспечения и предполагаемых требований.
Он включает в себя действия, которые обеспечивают проверку разработанного программного обеспечения в отношении задокументированных (или не в некоторых случаях) требований.
Он включает в себя действия, которые обеспечивают выявление ошибок / ошибок / дефектов в программном обеспечении.
Ориентирован на процессы и процедуры, а не на проведение реальных испытаний в системе.
Ориентирован на фактическое тестирование, выполняя программное обеспечение с целью выявления ошибок / дефектов посредством реализации процедур и процессов.
Ориентирован на фактическое тестирование.
Процессно-ориентированные мероприятия.
Товарно-ориентированная деятельность.
Товарно-ориентированная деятельность.
Профилактические мероприятия.
Это корректирующий процесс.
Это профилактический процесс.
Это подмножество жизненного цикла тестирования программного обеспечения (STLC).
КК можно рассматривать как подмножество обеспечения качества.
Тестирование является подмножеством контроля качества.

6
Аудит и Инспекция.
Аудит – это систематический процесс, позволяющий определить, как в действительности проводится процесс тестирования в организации или команде. Как правило, это независимая проверка процессов, участвующих в процессе тестирования программного обеспечения.
Согласно IEEE, это обзор задокументированных процессов, которые организации внедряют и выполняют. Типы аудита включают Аудит соответствия требованиям законодательства, Внутренний аудит и
Системный аудит.
Инспекция – это формальный метод, который включает в себя формальные или неформальные технические проверки любого артефакта путем выявления любой ошибки или пробела. Согласно IEEE94, инспекция – это формальная методика оценки, в которой требования к программному обеспечению, проекты или коды детально изучаются лицом или группой, кроме автора, для выявления ошибок, нарушений стандартов разработки и других проблем.
Официальные инспекционные собрания могут включать в себя следующие процессы: планирование, обзорная подготовка, инспекционная встреча, доработка и контроль.
Тестирование и отладка.
Тестирование – включает в себя выявление ошибок / ошибок / дефектов в программном обеспечении без их исправления. Обычно в выявлении ошибок участвуют профессионалы с опытом обеспечения качества. Тестирование проводится на этапе тестирования.
Отладка – включает в себя выявление, изоляцию и устранение проблем / ошибок. Разработчики, которые пишут программное обеспечение, проводят отладку при обнаружении ошибки в коде. Отладка является частью тестирования White Box или модульного тестирования.
Отладка может быть выполнена на этапе разработки во время проведения модульного тестирования или на этапах при исправлении обнаруженных ошибок.
Тестирование программного обеспечения – Стандарты ИСО.
Многие организации по всему миру разрабатывают и внедряют различные стандарты для улучшения требований к качеству своего программного обеспечения. В этой главе кратко описаны некоторые из широко используемых стандартов, связанных с обеспечением качества и тестированием.

7
ISO / IEC 9126.
Этот стандарт касается следующих аспектов для определения качества программного приложения –
 Качественная модель.
 Внешние показатели.
 Внутренние показатели.
 Метрики качества в использовании.
Этот стандарт представляет некоторый набор атрибутов качества для любого программного обеспечения, такого как –
 Функциональность.
 Надежность.
 Юзабилити.
 КПД.
 Ремонтопригодность.
 Портативность.
Вышеупомянутые атрибуты качества далее подразделяются на подфакторы, которые вы можете изучить, когда изучите стандарт подробно.
ИСО / МЭК 9241-11.
Часть 11 этого стандарта касается того, в какой степени продукт может использоваться указанными пользователями для достижения указанных целей с помощью Эффективности, Эффективности и
Удовлетворенности в указанном контексте использования.
В этом стандарте предложена структура, которая описывает компоненты юзабилити и отношения между ними. В этом стандарте удобство использования рассматривается с точки зрения производительности и удовлетворенности пользователей. В соответствии с ISO 9241-11, удобство использования зависит от контекста использования, и уровень удобства будет меняться при изменении контекста.

8
ИСО / МЭК 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.
Этот стандарт касается пакетов программного обеспечения, доставляемых клиенту. Это не фокусируется или не касается процесса производства клиентов. Основное содержание относится к следующим пунктам –
 Набор требований к программным пакетам.
 Инструкция по тестированию поставляемого программного пакета на соответствие указанным требованиям.

9
Разнообразный.
Некоторые из других стандартов, связанных с процессами обеспечения качества и тестирования, упомянуты ниже:
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.
Руководство по проверке и проверке программного обеспечения.

10
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.
Стандарт для тестирования программных компонентов.