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

• Название: 7 Принципов Тестирования Программного Обеспечения Кластеризация Дефектов и принцип Парето
• Дата: 17.02.2023
• Размер: 48.67 Kb.
• Имя файла: 7 принципов тестирования.docx
• Тип: Документы; #942749

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% дефектов обнаружены в модуле «Овердрафт».

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

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

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

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

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

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

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

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

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

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

Есть два варианта, с помощью которых мы можем предотвратить парадокс пестицидов, как показано ниже:

a) Напишите новый набор тестовых случаев, которые будут сосредоточены на другой области или модулях (кроме более ранних модулей, подверженных дефектам - Пример: «Овердрафт») программного обеспечения.

b) Подготовка новых тестовых случаев и добавление к существующим тестовым случаям.

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

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

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

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

Здесь, в нашем примере, вновь созданные тестовые случаи смогут помочь в выявлении дефектов в таких модулях, как Сводка по счету, Перевод средств и Постоянная инструкция. Однако тестировщики не могут игнорировать более ранние подверженные дефектам модули (пример: "Overdraft"), поскольку эти новые тестовые случаи объединяются с существующими тестовыми случаями.

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

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

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

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

Это, в свою очередь, уменьшит общее количество тестовых случаев.

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

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

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

Заключение

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

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

Большинство тестировщиков внедрили и испытали эти принципы во время фактического тестирования.

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

Приятного чтения!!