Ограничения тестирования программного обеспечения тестировщиком

Ограничения тестирования программного обеспечения тестировщиком

Ограничения тестирования программного обеспечения тестировщиком

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

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

Позитивистская спецификация

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

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

Невозможность полной спецификации

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

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

Неформальный вход

Клиенты обычно описывают свои требования с помощью правил :

Если A, то X. Но если B, то Y.

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

Практическим следствием могут быть случаи, когда:

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

Неустановленный результат

Это случай, когда FS определяет поведение только для части всех теоретически возможных ситуаций (декартова, поддерево ). Таким образом, в приведенном ниже примере явно указано требование для ситуаций A и D. Однако оно не указывает напрямую другие возможности. В этом случае анализ (тестирование документации) может привести к нескольким результатам:

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

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

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

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

Поделитесь с друзьями и коллегами в социальных сетях!
Учитесь вместе!