Файл: 7 Принципов Тестирования Программного Обеспечения Кластеризация Дефектов и принцип Парето.docx

ВУЗ: Не указан

Категория: Не указан

Дисциплина: Не указана

Добавлен: 17.03.2024

Просмотров: 21

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

7 Принципов Тестирования Программного Обеспечения: Кластеризация Дефектов И Принцип Парето

Последнее обновление:Июнь 13, 2022

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

Я уверен, что все знают о «Семи принципах тестирования программного обеспечения».

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

Что вы узнаете: [прятать]

  • Семь принципов тестирования программного обеспечения

    • #1) Тестирование показывает наличие дефектов

    • #2) Раннее тестирование

    • #3) Исчерпывающее тестирование невозможно

    • #4) Тестирование зависит от контекста

    • #5) Кластеризация дефектов

    • #6) Парадокс пестицидов

    • #7) Отсутствие ошибки

    • Кластеризация дефектов

    • Парадокс пестицидов

      • Профилактические методы парадокса пестицидов

    • Заключение

    • Рекомендуемая литература

Семь Принципов Тестирования Программного Обеспечения


Прежде чем подробно рассмотреть эти два принципа, давайте кратко рассмотрим семь принципов тестирования программного обеспечения.

Давайте исследуем!!

#1) Тестирование показывает наличие дефектов


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

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


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

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

Пример 1:

Рассмотрим банковское приложение, это приложение тщательно протестировано и проходит различные этапы тестирования, такие как SIT, UAT и т. Д., И в настоящее время в системе не выявлено никаких дефектов.

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

Пример 2:

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

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

#2) Раннее тестирование


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

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





[источник изображения]

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

Теперь вопрос в том, как рано должно начинаться тестирование?

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

#3) Исчерпывающее тестирование невозможно


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

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

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

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

#4) Тестирование зависит от контекста


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

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

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

#5) Кластеризация дефектов


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

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

#6) Парадокс пестицидов


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

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

#7) Отсутствие ошибки


Если программное обеспечение протестировано полностью и если дефекты не обнаружены до выпуска, то мы можем сказать, что программное обеспечение на 99% без дефектов. Но что, если это программное обеспечение протестировано на соответствие неправильным требованиям? В таких случаях даже поиск дефектов и их своевременное устранение не поможет, поскольку тестирование проводится по неправильным требованиям, которые не соответствуют потребностям конечного пользователя.

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

Это семь принципов тестирования программного обеспечения.

Теперь давайте подробно рассмотрим кластеризацию дефектов, принцип Парето и парадокс пестицидов.

Кластеризация дефектов


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

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

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

Кластеризация дефектов основана на «принципе Парето», который также известен как правило 80-20. Это означает, что 80% обнаруженных дефектов связаны с 20% модулей в приложении. Концепция принципа Парето была первоначально определена итальянским экономистом Вильфродо Парето.

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

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



[источник изображения]

На приведенном выше рисунке показано, что из 32 дефектов в функционале Овердрафта имеется 18 дефектов, что означает, что 60% дефектов обнаружены в модуле «Овердрафт».

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