Как можно сломать автоматическое тестирование?
(Все фотографии в этой статье взяты из Интернета)
Успех автоматизированного тестирования может быть по-разному и определен по-разному, но провал автоматизированного тестирования очень прост: автоматическое тестирование больше не проводится или команда уничтожается из-за автоматического тестирования. Так какие же проблемы могут привести к сбою автоматического тестирования, даже если вы очень постараетесь?
Проблема 1. Слишком поздно писать автоматизированные тестовые примеры.
традиционный Автоматизированное тестирование Типичная проблема неудачной реализации:«Слишком поздно писать автоматизированные тесты»,Другими словами, скорость написания вариантов использования не может идти в ногу со скоростью удовлетворения спроса.,привести к Автоматизированное «Обязательства» молодежи растут. Потому что в обычном понимании так называемое Автоматизированное тестирование,По сути, это «автоматизация», выполняемая тестовым вариантом использования.,Процесс написания и отладки сценариев использования тестов по-прежнему выполняется вручную.,И это требует от тестировщиков выполнения дополнительной работы в дополнение к ручному выполнению тестовых задач. Поэтому данный вид реализации автоматизации,Существует линейная зависимость между входом и выходом.,То есть один человек может посадить один саженец риса.,Результаты всего за один день,голосовать за двух человек,Это результат деятельности двух людей. Даже при расширении масштабов инвестиций,Негативные последствия синергии также снизят норму прибыли этого подхода.
Поэтому многие команды решили увеличить инвестиции в рабочую силу, 996 и другие методы для накопления вариантов использования и стремятся стать отцом богатого второго поколения. Например, некоторые команды создают специальный так называемый пост по разработке тестов, основная задача которого — перевод тестовых сценариев, написанных тестировщиками вручную, в автоматизированные сценарии использования. Вред этой модели будет проанализирован в следующих разделах.
В отрасли есть поговорка (на самом деле моя): «Необходимым условием успешного автоматизированного тестирования является наличие достаточного количества автоматизированных вариантов использования». Успех будет невозможен, не кажется ли это бесконечным циклом? Поэтому, когда некоторые студенты недавно присоединяются к команде и жалуются, что существующая среда/платформа автоматизированного тестирования недостаточно хороша и ее лучше заменить или перестроить, вам действительно следует изменить свое мышление, если есть возможность унаследовать старые деньги. вам она не понравится. Банкнота недостаточно новая или она вам не понравится, потому что ее количество недостаточно велико? Поэтому, даже если это обновление, мы должны рассмотреть возможность включения в него существующих вариантов использования.
Подавляющее большинство людей по-прежнему выполняют обычную работу по тестированию в обычных командах тестирования. Так как же нам вырваться из упомянутого выше бесконечного цикла и избавиться от этой линейной зависимости рентабельности инвестиций? Автор считает, что повышение эффективности написания автоматизированных тест-кейсов — единственный способ для команды быстрее выбраться из инвестиционной трясины автоматизированного тестирования, быстрее выйти на точку безубыточности и сформировать положительную обратную связь по автоматизированному тестированию. Это одна из причин, почему автор никогда не интересовался созданием так называемой платформы автоматизированного тестирования. Потому что многие такие платформы фактически фокусируются на требованиях управления и игнорируют основной пользовательский опыт «повышения эффективности написания вариантов использования». Они предоставляют только функцию написания вариантов использования в пользовательском интерфейсе. не хуже традиционного Excel. Есть даже команды, которые разработали для этой цели такие функции, как «Импорт вариантов использования автоматизации Excel/CSV».
За счет ссылок на интерфейсы (нет необходимости писать URL-адрес/ключ параметра), предустановленных данных параметров (нет необходимости записывать значения параметров), записи и генерации ожидаемых результатов (нет необходимости писать утверждения) и других подобных мер можно повысить эффективность написания вариантов использования. быть улучшено в определенной степени. Но в целом эти меры по-прежнему представляют собой частичную оптимизацию в традиционных рамках, и их эффект заключается лишь в увеличении наклона рентабельности инвестиций.
Итак, есть ли способ выйти за рамки стандартного и добиться нелинейной рентабельности инвестиций за счет революционных улучшений? В настоящее время к более эффективным технологиям относятся запись и воспроизведение трафика, инверсия журналов и т. д., которые используют наблюдаемые данные для достижения цели быстрого и бесплатного создания автоматизированных вариантов использования. В отрасли также есть подобные JVM-SANDBOX-repeaterи Сундук с сокровищами лунного света по мотивамrepeaterполный привод。Автор также сделал простой инструмент записи и воспроизведения для разработчиков.,Заинтересованные читатели могут обратиться к《Запись и воспроизведение для выполнения бесплатных тестовых случаев》。конечно,Этот тип варианта использования в основном подходит для объединения и интеграции одного микросервиса.
Кроме того, варианты использования также могут генерироваться с помощью MBT и других методов. Одной из трудностей в решении этого типа является Test Oracle, который заключается в автоматическом генерировании ожидаемых результатов. Следовательно, этот тип метода больше подходит для использования в некоторых сценариях аномального тестирования или в конкретных областях бизнеса, таких как тестирование протоколов связи.
Конечно, разработка программного обеспечения сейчас вступила в эпоху LLM, и крупные компании также вкладывают ресурсы в исследования автоматического создания тестовых примеров. Конечно, в настоящее время он в основном ориентирован на автоматическую генерацию тест-кейсов вручную (даже в основном тест-поинтов, без конкретных шагов и данных). Для автоматизированных тестовых случаев это в основном модульные тестовые сценарии и тестовые сценарии с одним интерфейсом. Для системных тестовых случаев решения, включающие несколько шагов, настройку контекста и другие задачи, все еще относительно редки. Однако я считаю, что по мере того, как движение DevOps продолжает углубляться, а цифровой уровень всего процесса исследований и разработок улучшается, будет появляться все больше и больше «цифровых интеллектуальных» решений для создания тестовых сценариев, наложенных на возможности LLM.
о Автоматизированное Самая распространенная критика новостей — «Автоматизированное». обучение Невозможно своевременно и всесторонне обнаружить дефекты. Читатели также могут посчитать дефекты, обнаруженные их собственной командой. тестирование Доля вариантов использования。Автор также написал специальную статью, посвященную обсуждению этого вопроса.《Почему автоматизированные тесты находят дефекты?》。Автор считает,Автоматизированное Обучение не должно стать серверной задачей, а должно стать способом работы и в конечном итоге стать единственным или основным способом выполнения варианта использования теста. Ранее автор упоминал, что так называемая должность разработки тестов или Автоматизированное создана специально для того, чтобы «переводить сценарии использования вручную в сценарии использования автоматизации». молодая банда. Ценность таких позиций также часто подвергается сомнению, поскольку недостатки трудно обнаружить.
На самом деле, всем известно, что если жевать сахарный тростник, пережеванный другими, ты не сможешь выжать много сока, как бы сильно ты ни старался.
Только в прошлой практике,Тестирование новых функций и написание автоматизированных тестовых примеров часто представляют собой два действия, причем последнее часто имеет определенную задержку. Это основная причина, по которой автоматическое тестирование может создать у людей впечатление, что найти дефекты «трудно».Потому что новые дефекты часто вызваны новыми требованиями к трансформации системы.。программное обеспечениетест Одна из основных школ мысли основана на риске.тест,Это тоже так.
Цель «Автоматизированного тестирования» — найти недостатки.,Фактически, его следует преобразовать в«Может ли первое выполнение (ручного) тестового примера быть выполнено так же, как автоматизированный тест?»Такая цель。Первое выполнение вашего варианта использования,Это было заказано вручную,Или он вызывается в IDE или в конвейере?
Режим проверки «Ручной-автоматический»
Автор однажды реализовал тестовый режим определенной базовой системы. проверки «Ручной-автоматический»。Базовая система, естественно, представляет собой систему, которая может работать независимо.、проходитьинтерфейс Взаимодействуйте с внешним миром,Включает интерфейс промышленных протоколов, интерфейс профилей и интерфейс баз данных. Вариант использования теста разработан в соответствии со сценарием использования автоматизации.,Текущая предпосылка — поддерживать среду, конфигурацию и особенно данные. Когда вариант использования выполняется впервые,персонал тестировщика определяет, соответствует ли тест ожиданиям,если оно не оправдает ожиданий,Затем сообщите о дефекте. Если оно соответствует ожиданиям,затем включите вариант использования в библиотеку вариантов использования,Регрессия как вариант использования автоматизации. Этот метод изменился по сравнению с прошлым, когда команда сначала делала это вручную.,Затем реализуйте шаблон автоматизации на следующей итерации.
Если команда внедрила TDD/BDD/ATDD, это больше соответствует вышеуказанным характеристикам, поскольку разработка и выполнение автоматизированных тестов происходит раньше. Я считаю, что в такой команде мало кто обратит внимание на то, должно ли автоматическое тестирование находить дефекты. Потому что автоматическое тестирование — это их основной или даже единственный способ реализовать варианты использования.
Команды, которые преодолели технические барьеры на пути автоматического создания автоматизированных тестовых примеров, также могут использовать такие методы, как запись и воспроизведение трафика, для более плавного достижения «ручной и автоматической интеграции». Записывая процесс тестирования ручных тестировщиков по требованию, автоматически генерируемые. тестовые примеры можно использовать повторно.
После автоматизации посредством написания тест-кейсов создание вариантов использования больше не является узким местом, а затраты команды на получение автоматизированных тест-кейсов близки к 0. В этом случае пик нагрузки приходится на анализ результатов выполнения тестов.
Как и другие тесты, автоматическое тестирование также имеет проблемы «ложных срабатываний» и «пропущенных отрицательных результатов».
Из-за огромного количества вариантов использования,Даже небольшая вероятность ложного отказа,Также будет значительное количество неудачных случаев использования, требующих устранения неполадок вручную. Однако, поскольку это случаи ложного сбоя,Результатом расследования должен стать «марш смерти»,Весь процесс должен быть полон стресса,Но это приносит только разочарование команде. Это Автоматизированное от команды. тестирование Самая большая ловушка, с которой может столкнуться движение после его начала。Многие автоматические тесты фактически отказываются от всей работы по автоматизированному тестированию после того, как команда усердно работала над созданием слишком большого количества автоматизированных тестовых случаев и превысила свои возможности обслуживания, потому что ни у кого больше не хватает смелости исправить эти ложные сценарии использования (эффект разбитого окна).
В этом случае команде следует рассмотреть возможность внедрения автоматического анализа результатов тестирования, чтобы иметь возможность определять варианты использования «ложных сбоев (ложных срабатываний)» и продолжать повышать их достоверность. В конце концов, неправильная оценка «ложных сбоев» может напрямую привести к онлайн-дефектам.
Существуют и другие факторы, которые могут привести к тому, что набор вариантов использования станет неприемлемым, например, необоснованная структура вариантов использования (слишком много вариантов использования автоматизации пользовательского интерфейса) ((Здесь мы дадим Новая работа Юнды «Многоуровневая автоматизация» приносит что-то новое. )), изменения в составе команды (увольнения в артерии или основной персонал переведен/уволен), передача владения приложением (наборы вариантов использования передаются от одной команды к другой), обновления архитектуры, трансформация стека технологий (наборы вариантов использования требуют большого количество работ по обслуживанию и обновлению Зоны) и т. д., одно или несколько воздействий могут привести к Автоматизированному Маршрут обучения. Я даже видел ситуации, когда приходилось поддерживать сотни вариантов использования из-за обратной несовместимости (новые обязательные поля). Кроме того, в целях осуществления Автоматизированного тестирование Количество вариантов использования,Слепо добавляйте варианты использования,Однако варианты использования не включены в конвейер непрерывного тестирования.финальныйпривести к В большинстве случаев использования не удается выполнить последнюю ситуацию сброса.。
Наконец, я воспользуюсь KIMI, чтобы написать краткий обзор:
1.Точная идентификация проблемы:Статья была успешно идентифицирована Автоматизированное Три главных вопроса в тестировании: своевременность написания вариантов использования, Автоматизированное обучение Умение находить дефекты и Автоматизированное улучшение ремонтопригодности вариантов использования. Это все Автоматизированное некоторые практические проблемы, часто возникающие в ходе реализации.
2.Глубокий анализ причин:Автор не просто указал на проблему,Также представлен углубленный анализ причин этих проблем. Например,для“Слишком поздно писать Автоматизированное Проблема «обучения варианта использования», в статье анализируется Автоматизированное обучение Линейные отношения ввода-вывода, записанные в зависимости от варианта использования,и возможные неадекватные ответы команды.,Например, чрезмерная зависимость от человеческого вклада.
3.Предоставьте решения:Статья не ограничивается выявлением проблем и анализом причин.,Также представлены некоторые возможные решения. Например,Внедряя такие технологии, как запись и воспроизведение трафика, а также инверсию журналов,,и автоматически генерировать тестовые варианты использования с использованием моделей машинного обучения,Улучшить написание и качество сценариев использования тестов.
4.Подчеркните важность тестовых случаев:В статье подчеркиваетсятест Вариант использования находится в Автоматизированное Центральное положение молодежи в Автоматизированном Успех обучения во многом зависит от существующих высококачественных сценариев использования тестов. Этот момент является важным напоминанием для многих команд о том, что в стремлении к автоматизации не следует упускать из виду ценность самого варианта использования теста.
5.продвигать Режим проверки «Ручной-автоматический»:предложено в статье Режим проверки «Ручной-автоматический» — это инновационный момент, который призывает рассмотреть возможность автоматизации при первом выполнении сценария использования теста, чтобы проблемы можно было обнаружить раньше и включить в Автоматизированное. тестированиепроцесс。
6.Критика платформ автоматизированного тестирования:Автор комментирует некоторые Автоматизированное развитию критического мышления на платформе тоже стоит уделить внимание на, отметил, что эти платформы могут быть слишком сосредоточены руководство апеллирует, но игнорирует ключевую проблему повышения эффективности написания сценариев использования.
7.Взгляд на будущие тенденции:Статья правильная Автоматизированное тестирование Будущие тенденции,Особенно в эпоху LLM (большая языковая модель).,тест Возможность автоматического формирования вариантов использования,Это дает читателям возможность взглянуть в будущее.
В целом, в этой статье представлены идеи и практические советы для специалистов по автоматизированному тестированию, которые помогают командам избежать распространенных ошибок и повысить эффективность и результативность автоматизированного тестирования.