Файл: 7 Принципов Тестирования Программного Обеспечения Кластеризация Дефектов и принцип Парето.docx
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 17.03.2024
Просмотров: 24
Скачиваний: 0
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
Когда один и тот же код или модуль тестируется, снова и снова, используя набор тестовых случаев, чем во время начальных итераций, то количество дефектов велико, однако после некоторой итерации количество дефектов значительно уменьшится. Кластеризация дефектов указывает на то, что подверженная дефектам область должна быть тщательно проверена во время регрессионного тестирования.
Парадокс пестицидов
Когда обнаруживается, что один из модулей имеет больше дефектов, тестировщики прилагают дополнительные усилия для тестирования этого модуля.
После нескольких итераций тестирования качество кода улучшается, и количество дефектов начинает снижаться, поскольку большинство дефектов исправляется командой разработчиков, поскольку разработчики также осторожны при кодировании конкретного модуля, где тестировщики обнаружили больше дефектов.
Следовательно, в какой-то момент большинство дефектов обнаруживаются и исправляются, так что в этом модуле не обнаруживаются новые дефекты.
Тем не менее, иногда может случиться так, что, будучи особенно осторожным во время кодирования на одном конкретном модуле (здесь в нашем случае модуль «Овердрафт»), разработчик может пренебречь другими модулями, чтобы правильно его кодировать, или изменения, внесенные в этот конкретный модуль, могут оказать негативное влияние на другие функции, такие как сводка по счету, перевод средств и постоянные инструкции.
Когда тестировщики используют один и тот же набор тестовых случаев для выполнения модуля, в котором обнаружено большинство дефектов (модуль Овердрафт), то, после исправления этих дефектов разработчиками, эти тестовые случаи не очень эффективны для поиска новых дефектов. Как сквозной поток овердрафта, модуль тщательно тестируется, и разработчики также осторожно написали код для этого модуля.
Необходимо пересмотреть и обновить эти тестовые случаи. Также рекомендуется добавлять новые тестовые случаи, чтобы новые и новые дефекты можно было найти в разных областях программного обеспечения или приложения.
Профилактические методы парадокса пестицидов
Есть два варианта, с помощью которых мы можем предотвратить парадокс пестицидов, как показано ниже:
a) Напишите новый набор тестовых случаев, которые будут сосредоточены на другой области или модулях (кроме более ранних модулей, подверженных дефектам - Пример: «Овердрафт») программного обеспечения.
b) Подготовка новых тестовых случаев и добавление к существующим тестовым случаям.
В «методе А» тестировщики могут найти больше дефектов в других модулях, на которых они не были сосредоточены во время более раннего тестирования или разработчики не были особенно осторожны во время кодирования.
В приведенном выше примере тестировщики могут найти больше дефектов в модулях «Сводка по счету», «Перевод средств» или «Постоянные инструкции», используя новый набор тестовых случаев.
Но может случиться так, что тестировщики могут пренебречь более ранним модулем (пример: «Овердрафт»), где большинство дефектов было обнаружено в более ранней итерации, и это может быть риском, так как этот модуль (Овердрафт) мог быть введен с новыми дефектами после кодирования других модулей.
В "методе В" подготавливаются новые тестовые случаи таким образом, чтобы в остальных модулях можно было обнаружить новые потенциальные дефекты.
Здесь, в нашем примере, вновь созданные тестовые случаи смогут помочь в выявлении дефектов в таких модулях, как Сводка по счету, Перевод средств и Постоянная инструкция. Однако тестировщики не могут игнорировать более ранние подверженные дефектам модули (пример: "Overdraft"), поскольку эти новые тестовые случаи объединяются с существующими тестовыми случаями.
Существующие тестовые случаи были в большей степени ориентированы на модуль "Овердрафт", а новые тестовые случаи были сосредоточены на других модулях. Следовательно, все наборы тестовых случаев выполняются хотя бы один раз, даже изменение кода происходит в любом модуле. Это гарантирует, что будет выполнена правильная регрессия и дефект может быть идентифицирован из-за этого изменения кода.
При использовании второго подхода общее количество тестовых случаев значительно возрастает и приводит к увеличению усилий и времени, необходимых для выполнения. Это, очевидно, повлияет на сроки проекта и, самое главное, на бюджет проекта.
Следовательно, чтобы преодолеть эту проблему, избыточные тестовые случаи могут быть просмотрены, а затем удалены. Существует множество тестовых случаев, которые становятся бесполезными после добавления новых тестовых случаев и изменения существующих тестовых случаев.
Необходимо проверить, какие тестовые случаи не пройдены, чтобы выявить дефекты в последних 5 итерациях (предположим, 5 итераций), а какие тестовые случаи не очень важны. Также может случиться так, что одиночный поток, охватываемый несколькими тестовыми случаями, может быть покрыт в другом сквозном тестовом случае, а те тестовые случаи, которые имеют один поток, могут быть удалены.
Это, в свою очередь, уменьшит общее количество тестовых случаев.
Например, у нас есть 50 тестовых случаев, охватывающих один конкретный модуль, и мы видели, что из этих 50 тестовых случаев 20 тестовых случаев не смогли обнаружить новый дефект в последних нескольких итерациях тестирования (предположим, 5 итераций). Таким образом, эти 20 тестовых случаев должны быть тщательно рассмотрены, и нам нужно проверить, насколько важны эти тестовые случаи, и может быть принято соответствующее решение о том, сохранить ли 20 тестовых случаев или удалить их.
Перед удалением любого тестового случая убедитесь, что функциональный поток, охватываемый этими тестовыми случаями, описан в другом тестовом случае. Этот процесс необходимо соблюдать во всех модулях, чтобы общее количество тестовых случаев значительно сократилось. Это гарантирует, что общее количество тестовых случаев будет сокращено, но по-прежнему существует 100% покрытие требований.
Это означает, что все остальные тестовые случаи охватывают все бизнес-требования, следовательно, нет никаких компромиссов по качеству.
Заключение
Тестирование программного обеспечения является важным шагом в SDLC, поскольку оно проверяет, работает ли программное обеспечение в соответствии с потребностями конечного пользователя или нет.
Тестирование выявляет как можно больше дефектов. Следовательно, чтобы проводить тестирование эффективно и результативно, каждый должен знать и действительно понимать семь принципов тестирования программного обеспечения, и они известны как столпы для тестирования.
Большинство тестировщиков внедрили и испытали эти принципы во время фактического тестирования.
Как правило, термин принцип означает правила или законы, которые необходимо соблюдать. Следовательно, каждый в индустрии тестирования программного обеспечения должен следовать этим семи принципам, и если кто-то игнорирует любой из этих принципов, то это может стоить очень дорого для проекта.
Приятного чтения!!