Инженер-испытатель заходит в бар и заказывает пиво;

Инженер-испытатель заходит в бар и заказывает чашку кофе;

Инженер-испытатель заходит в бар и заказывает 0,7 порции пива;

Инженер-испытатель заходит в бар и заказывает 2^32 пива;

Инженер-испытатель зашел в бар и попросил стакан воды;

Инженер-испытатель зашёл в бар и заказал asdfQwer@24dg!&*(@；

Инженер-испытатель заходит в бар и ничего не просит;

Инженер-испытатель вошел в бар, вышел, вошел через окно, вышел через заднюю дверь и залез в канализацию;

Инженер-испытатель заходит в бар, выходит, входит, выходит, заходит, снова выходит и, наконец, избивает владельца на улице;

Инженер-испытатель зашел в бар и заказал горячую чашку Кунджинкао;

Инженер-испытатель заходит в бар и просит стакан NaN Null;

Инженер-испытатель заходит в бар и заказывает пиво; батончик DROP TABLE;

Инженеры-испытатели покинули бар довольные.

Покупатель заказал жареный рис, и бар взорвался.

Инженер-испытатель был избит инженером-разработчиком.

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

01. Напишите впереди

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

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

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

02. Выбор кадра

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

1、промышленностьрамка：

• Рабочий стол: AutoIt, Selenium, Puppeteer, Mocha, Pywinauto, Sikuli;
• Мобильный терминал: UIAutoMator\Instrumentation\WDA\Appium\XCTest.

2、внутренняя платформа：

• QTA: Универсальная платформа для автоматизации,Внутри используется более крупная платформа;
• Чжиян: испытательный зал имеет более богатую схему конфигурации вариантов использования, аналогичную платформе QTA;
• Testone: включает использование Web Платформа автоматического тестирования с тем же исходным кодом DWT и среда автоматизированного тестирования интерфейса, основанная на записи и воспроизведении Rua；
• Wetest: В основном предоставляет терминальное оборудование и соответствующие решения по автоматизации тестирования.

3、Другие варианты：

• AirTest
• Самостоятельно разработанный SDK
• ....

Здесь перечислены не все платформы автоматизации, включая новые платформы, такие как liteapp и Flutter. У всех есть соответствующие платформы автоматизации. Здесь представлены только те платформы, которые были использованы и поняты. Каждая среда имеет свои особенности. Вы можете выбрать подходящую среду для тестирования автоматизации настольных систем на основе реальных потребностей и технического опыта. вы можете разработать структуру самостоятельно, в сочетании с глубокой настройкой бизнеса, это может быть более гибким и удобным, чем общая структура. Если автоматизация находится на ранней стадии и требуется меньше рабочей силы, вы можете рассмотреть возможность создания общей платформы. компания, которая может решать другие вспомогательные задачи, помимо самой автоматизации, такие как отчетность, кластеризация, отчетность и т. д. и другой сопутствующий контент. Если за контент автоматизации отвечает группа разработчиков, вы можете использовать платформы, связанные с бизнес-исходным кодом. Если он написан командой тестирования, используйте три часто используемых инструмента, такие как Python, JS, Go и т. д., если тестовые примеры выполняются вручную; более стандартизированы, например сценарии, шаги. Все контрольные точки шаблонизированы, поэтому вы можете обратиться к соответствующему второму пилоту для обучения, перейти к ИИ и автоматически генерировать варианты использования. Некоторые попытки также предпринимаются внутри компании. Но реальность такова, что вам ничего не дадут. Начиная с собственно внутренних дел, не всегда все гладко. В процессе адаптации тоже есть некоторые проблемы:

• Рабочий стол:

На ранних стадиях проекта я участвовал в команде веб-автоматизации Oteam, напрямую использовал платформу QTA для настольных компьютеров и вносил контент, связанный со встроенным Интернетом, в электронной форме. Начальная работа рабочего стола проходит относительно гладко, и варианты использования в основном выполняются. Судя по реальной ситуации с приложением, на ранней стадии возникает много проблем. Однако эти проблемы являются незначительными и будут решаться одна за другой. процесс автоматизации развертывания. Подробные решения. См. более раннюю документацию по автоматизации. После проверки и исследования мы выбрали метод объединения платформ Selenium и QTA, то есть используя Selenium для написания автоматизации пользовательского интерфейса, и в то же время переписывая связанные функции в подклассах, например, скриншоты, отказавшись от предыдущего метода ImageGrab.grab и используя его напрямую. Метод get_screenshot_as_file драйвера в selenium также улучшает метод starStep и передает журналы и снимки экрана, созданные новым подклассом, в QTA. Платформа решает проблемы безголовости и эффективности выполнения, а также решает проблемы управления архивированием отчетов, управления задачами и т. д. Нет необходимости создавать соответствующие периферийные устройства для автоматизации, и вам нужно только сосредоточиться на самом бизнесе автоматизации.

• Мобильная версия:

Документы в основном представлены в Webview на мобильном терминале. Anrdoid использует протокол CDP (протокол Chrome devtools) для отладки Android Webview с помощью метода adb. Это относительно распространенный способ. Однако для iOS это более болезненный сценарий смешанного тестирования. Поскольку конвейер собирает все пакеты выпускной версии, пакеты отладочной версии больше не предоставляются. При выполнении автоматического тестирования H5 отладку iOS Webview невозможно включить для автоматического тестирования H5. это первая проблема, с которой сталкивается автоматизация мобильного терминала. Сюда входят исследования различных методов, таких как взлом джейлбрейка и сопоставление изображений, но ни один из них не является реалистичным. Позже я случайно увидел, что многие интерфейсные разработчики в компании используют такие решения, как свисток, внедрение JS или добавление отладочного кода для повышения эффективности разработки. , а затем рассмотрите бизнес. Добавление кода отладки в код ограничено содержанием работы тестировщика и оценкой безопасности бизнес-среды с помощью компонента отладки. Для продолжения работы требуется консультация между тестировщиками, разработчиками, службами безопасности и другими сторонами. не будьте осторожны, тестовый код будет введен и вызовет функциональные проблемы, выигрыш перевешивает потери.

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

Кроме того, необходимо развернуть дополнительный сервер, обеспечивающий внедрение JS, называемый chiiserver. Адрес открытого исходного кода — GitHub — liriliri/chii: Инструмент удаленной отладки. После ряда модификаций появился внешний метод отладки. Pages вводится в автоматизированное тестирование. Это открывает возможности для автоматического тестирования IOS H5. Основная цель — реализовать набор решений протокола CDP. vConsole и weinre. Я не пробовал их по одному. Другой контент, такой как планирование задач и отчеты платформы, единообразно передается на платформу QTA в соответствии с предписанным форматом, что объединяет форматы и содержимое отчетов для настольных и мобильных устройств.

03. Начните пробовать

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

Процесс написания:

Процесс исполнения:

Из приведенного выше процесса легко увидеть, что автор вариантов использования или сопровождающий занимает большую часть доминирующего положения в процессе, то есть ценность автоматизации полностью определяется им. Если проблема не анализируется вовремя, использование не становится возможным. Корпус не ремонтируется вовремя, а вариант использования не обновляется вовремя. В этом сценарии автоматизация может только развлекать себя. В течение длительного периода времени автоматизация каждого конца обнаружила очень мало проблем, но затраты времени. и рабочая сила непрерывна. Однако для каждой версии данных почти нет. Сколько ошибок обнаруживается автоматически? Нет количественных данных, подтверждающих ценность автоматизации. Я считаю, что это также проблема, которая беспокоит некоторые команды. Если разработчики и ручное тестирование не берут на себя инициативу и не обращают внимания на ситуацию с автоматизацией, должны быть две линии. Каждый использует свой собственный метод для поиска проблем. Наличие или отсутствие автоматизации мало влияет на каждую из них. В конечном итоге автоматизация может оказаться слишком плохой.

Возможно, в процессе рассмотрения или исправления вариантов использования вы обнаружите некоторые ненормальные сценарии. Вы также можете оставить отзыв в группе. После отзыва вы автоматически исправите варианты использования. Стандартизированного процесса не существует, и в нем участвует автоматический человек. зарядка может отвечать за более чем дюжину задач. В зависимости от нехватки энергии обращайте внимание на каждый вариант использования каждый раз, когда вы его запускаете, и сосредоточьтесь на его исправлении. В настоящее время автоматизация работает уже давно, рабочая сила также инвестируется в течение длительного времени, и уровень успеха также очень высок. Однако было обнаружено мало проблем, что, с другой стороны, немного ошеломляет. , все по-прежнему предпочитают ручное тестирование. Хотя стоимость рабочей силы высока, мы по-прежнему считаем, что ручное тестирование очень популярно из-за его инициативности, инициативы и способности когнитивного обучения находить проблемы. Автоматизация совершенно несопоставима с механически закрепленной проверкой. Даже студенты, которые пишут автоматизацию, очень хотят проводить ручное тестирование и не хотят автоматизировать. Они чувствуют, что автоматизация не получит никакой обратной связи или роста, поэтому они слепо гонятся за автоматическим тестированием. сваливать автоматизированные скрипты в «холм», наполненный множеством однотипных Исходный открытый код click и xpath практически непонятен другим людям, кроме человека, который его написал. Постепенно он стал второсортным кодом в глазах других, не говоря уже о ожидании понимания вывода отчета. , ценность автоматизации до сих пор не видна.

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

На этом этапе произошли и другие невероятные ситуации:

• разговаривать UI автоматизация“обесцвечивание”

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

• Многие не знают, что существует автоматизация.

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

• автоматизация - это полная нагрузка

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

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

04. Есть проблемы

В предыдущем разделе было кратко подытожено, что автоматизированные задачи не играют большой роли в поддержании интеграции. На первый взгляд существует множество случаев тестовых задач. Единственный выход после завершения операции приходится на сопровождающего скрипта, и его основная задача — это. Это показатель успешности обслуживания и как можно более быстрое покрытие большего количества вариантов использования. Нет пересечения между пользователями и сопровождающими. Эти два процесса выполняются по двум параллельным линиям. Это приводит к тому, что пользователи должны получить выгоду от автоматизации. в этом смысле он отличается от оригинального отрывка Лично я считаю, что такая ценность немного искажена. Идеальная и правильная ценность заключается в том, кто ее использует и кто ее поддерживает. Автоматизация должна быть непосредственно связана с бизнесом, а не с пользователем. Изменить это только в таком состоянии можно достичь здорового развития. Слепое стремление к проценту покрытия автоматизированных тестовых случаев и стабильному показателю успеха только заставит пользователей чувствовать себя более комфортно на поверхности, но это не означает, что это более эффективный или действенный метод. .

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

1. Сложный бизнес и множество вариантов использования

Согласно тестпирамиде теории,Сквозная теставтоматизация находится на вершине пирамиды.,Вариантов рационального использования должно быть как можно меньше.,Но не так-то просто найти проблемы,Я могу писать только глубже и глубже,Чем больше пишешь, тем сложнее становится。

• Тип теста: Изменения внешнего интерфейсаиз Выпуск средытест、Версия клиента из теста среды выпуска、Требования к функциям из теста среды функций、daily Регулярное тестирование коммутируемой сети в реальном времени;
• Вид бизнеса;
• Охватываемая версия: Windows, Mac, IOS, Android, Интернет.

2. Многие слияния приводят к большим разрушениям.

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

3. Низкая эффективность и высокая стоимость.

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

• Понимание вариантов использования:

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

• Ситуация использования:

путь-->Открыть документ,исследовать-->Правильно отображать все кнопки инструментов。

• Фактическая ситуация:

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

• Написание варианта использования:

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

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

Давно хотел посчитать скорость покрытия вариантов использования одной рабочей силой, но к сожалению не могу получить окончательный ответ. Если бизнес понятен, данных достаточно, среда проблематична, инкапсуляция структуры завершена, элементы управления легко идентифицировать и контрольные точки легко расходятся, среднее количество автоматизированных вариантов использования может достигать около 30 случаев. и каждый случай может охватывать один или несколько сценариев использования. Ручные сценарии объединяют одни и те же сценарии или пути в один сценарий, просто добавляя разные контрольные точки, предполагая, что случай Охватывает 2 варианта функционального использования, то есть в идеале может охватывать 60 сценариев ручного тестирования, но реальность не идеальна, существуют различные проблемы и сложные сценарии, которые сводят людей с ума, например, такой сценарий: А создает документ и приглашает Б; Присоединяйтесь, установите разрешения B только на просмотр, установите флажок B открывает документ, разрешения отображаются нормально, B приглашает C войти в документ, C открывает документ, разрешения отображаются нормально. Существуют и другие распространенные проблемы, такие как отсутствие утверждений, чрезмерный сон и проблемы жесткого кодирования, которые я не буду вдаваться в подробности.

• Задача выполняется:

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

• Метод триггера:

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

• Нет времени заниматься:

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

• Подтверждение окружающей среды:

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

• Эффективность исполнения:

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

Например: это занимает 9174 секунды, что делает человека, который управляет заказом на изменение, чрезвычайно болезненным. Если процесс изменения связан, боль будет еще сильнее, и боль будет невыносимой, потому что вы не сможете сделать следующий шаг. без бега Это занимает слишком много времени, и вы засыпаете во время ожидания. Успех Если скорость слишком низкая, следующий шаг сделать невозможно.

• Место проблемы:

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

Пример 1: AttributeError: Объект «NoneType» не имеет атрибута «текст».

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

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

05. Практические случаи

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

5.1 Планирование процессов и оптимизация результатов

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

• Горизонтальное и вертикальное единство

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

Вертикально: одна и та же категория работает на разных платформах. Различаются только сторона ПК и сторона приложения. Требуется только один автоматизированный вариант использования. Если взять в качестве примера документ, он должен работать в веб-браузерах, корпоративном WeChat Win и Mac. Измените базовый класс в нижней части варианта использования. Базовые классы разных платформ вызываются для самоадаптации. Для специальных функций платформы, таких как селекторы системных файлов, достаточно специальной обработки. Это позволяет избежать необходимости писать три набора автоматизированных функций. сценарии для одного варианта использования вручную, что увеличивает рабочую нагрузку.

platform_type = config.Platform_Type
if platform_type == PLATFORM_WEB:
from wedoctest.wedocapp.web_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_WIN:
from wedoctest.wedocapp.win_test_case import WeDocBaseTestCase
elif platform_type == PLATFORM_MAC:
from wedoctest.wedocapp.mac_test_case import WeDocBaseTestCase


class LaunchWord(WeDocBaseTestCase):
"""
    word Базовый класс варианта использования каждой конечной автоматизации: совместимый Mac, Windows, Интернет
    """

• Расположение и работа управления

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

1. XPATH часто используемых элементов управления будет изменен с использованием сопоставления шаблонов:

2. В веб-бизнесе внедряйте методы JS для получения свойств управления через функции самого продукта, сводя к минимуму частые операции контроля для проверки.

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

3. На собственном клиенте, благодаря возможностям отладки среды разработки, соответствующий код может быть напрямую выполнен для реализации связанных операций со страницами и переходов. Например, автоматизация мобильного терминала должна работать в различных средах, и ее необходимо подготовить. в автономных пакетах. Запустите вариант использования; после частого переключения среды вам необходимо войти в меню отладки, нажать «Очистить автономный пакет», а затем загрузить автономный пакет. По статистике этот путь является слишком длинным. потребляет много ресурсов и подвержен ошибкам. Удаленно. Используйте интерпретатор команд или adb для отладки и выполнения кода oc. Способ достижения возможности нажатия кнопок — реализация операций на уровне пользовательского интерфейса (обратите внимание, что эта функция включена только в тестовом пакете Blue Shield).

Android проще. Он регистрирует трансляции и реализует логику, а затем напрямую использует команды adb для реализации связанных функций.

val filter = IntentFilter()
filter.addAction("com.tencent.wetest")
WwUtil.APPLICATION_CONTEXT.registerReceiver(QMInstructionReceiver(), filter)

Получение обновлений

adb shell am broadcast -a com.tencent.xxx--es action "sync_server"

нажмите кнопку

adb shell am broadcast -a com.tencent.xxx--es action "click_accept"

кнопка отклонения

adb shell am broadcast -a com.tencent.xxx--es action "click_reject"

Ожидающая кнопка

adb shell am broadcast -a com.tencent.xxx--es action "click_pending"

• Стандарты написания сценариев использования и ускорение

1. Инкапсуляция кода:

1) Уровень описания тестовых случаев

2) Уровень реализации тестовых случаев

3) Уровень интерфейса тестовых случаев

2. Характеристики варианта использования:

1) Варианты использования должны быть независимыми;

2) Результаты деятельности должны быть стабильными;

3) Скорость бега должна быть высокой.

3. Стандарты квалифицированных вариантов использования:

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

2) Стабильная работа: работа варианта использования не только включает в себя построение перед сценой и текущий путь работы пользовательского интерфейса сцены, она соответствует вышеуказанному уровню описания и сценарию программы. Это проявление намерения тестирования и необходимо. быть более гибко инкапсулированы для операций с бизнес-объектами, например: для операций с панелью инструментов Word мы просто инкапсулируем основные операции (жирный шрифт, установка шрифта, установка цвета фона и т. д.).

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

self.startStep('Выделить жирным шрифтом')
логика.set_bold()

3) Идеальная проверка: на первых порах многие сценарии использования автоматизации были логическими, то есть все они использовали интерфейс пользовательского интерфейса, и точки проверки не добавлялись. В результате, хотя многие сценарии были рассмотрены, они не были эффективно обнаружены. и страница была обновлена ​​своевременно. Появилось окно с напоминанием, но оно по-прежнему показывало неудачный статус. Чтобы избежать автоматизированных вариантов использования без контрольных точек, каждый вариант использования должен иметь соответствующие контрольные точки. В конфигурации git-hook для отправки кода добавляются правила проверки. Для файла варианта использования в папке тестового сценария указывается количество новых измененных строк. В зависимости от имени варианта использования определяется, содержит ли текущий вариант использования проверку, связанную с утверждением, и если нет, будут выданы соответствующие напоминания. Учитывая, что многие конечные контрольные точки одинаковы во многих различных сценариях, а многие операции оказываются похожими или идентичными в процессе покрытия, доля операций в каждой подтаблице (функции) рассчитывается отдельно, ориентируясь на модули с относительно высокая доля, кластеризовать этапы операций и точки проверки и использовать ситуацию кластеризации для руководства теми высокочастотными сценариями и методами проверки, которые необходимо инкапсулировать, чтобы их можно было быстро использовать при охвате других вариантов использования, без повторного обдумывания и. переписывание.

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

5.2 Планирование процессов и оптимизация результатов

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

• Замкнутый цикл задачи

Решение: система подписки;

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

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

• Эксплуатационные характеристики

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

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

• Оптимизация отчета

В отчетах по автоматизации суммируются результаты по завершении автоматизации. Их простота понимания приносит большую пользу и интерес для пользователей. Если на основе простоты понимания обнаруживаются проблемы, это будет большим подспорьем для распознавания задач автоматизации; К упомянутым пользователям относятся бизнес-тестеры и студенты, занимающиеся исследованиями и разработками. Каждый знаком с разными областями. Например, бизнес-тестеры знакомы с вариантами использования вручную, разработчики знакомы с синтаксисом кода и т. д. При условии, что сопровождающие и пользователи — это не одно и то же лицо. все больше людей заинтересованы в том, чтобы прийти. Поиск проблем становится чрезвычайно важным.

1) Повторно настройте отчет. Обратитесь к платформе отчетов QTA и настройте набор автоматических отчетов на основе существующей структуры отображения. Этот отчет объединяет формы для мобильных устройств и настольных компьютеров и использует полный набор стилей, особенно без необходимости использования мобильных устройств. Посетите платформу wetest и объедините чрезвычайно сложный процесс создания отчетов по загрузке zip-пакета с просмотром отчета.

В описании варианта использования полностью используется ручное описание варианта использования, которое легко понять.

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

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

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

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

3) Отчет понятен с первого взгляда, содержит более подробные и полные этапы работы, а также предыдущие исторические сравнения.

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

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

• Операционная эффективность

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

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

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

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

3) Ресурсы оборудования: полностью используйте ресурсы оборудования. Для автоматизации в клиенте Window как можно скорее повторно используйте учетные записи, чтобы избежать повторного переключения клиентов. Запускайте несколько наборов вариантов использования веб-автоматизации одновременно, чтобы полностью использовать их. ограниченных ресурсов Windows.

5.3 Совместная работа в команде и обмен вариантами использования

1. Создание и ведение задач по автоматизациитестирования. ,Вместе определите охват автоматизацией цели и направления,Расставьте приоритеты в общих проблемах, риск、Существуют потенциальные проблемы, которые легко не заметить и сосредоточиться на строительстве.
2. Поделиться примером использования автоматизации,общее использование,Вы можете создавать эксклюзивные задачи для своих модулей, каждая версия синхронизирует цели строительства и направления оптимизации;,Синхронно обмениваться методами повышения эффективности,Соберите отзывы от нескольких сторон.
3. научно-исследовательский центрсосредоточиться а, используйте отладочную тестовую рамку для повышения эффективности.

06. Результаты этапа

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

1. Уменьшите давление ручного тестирования

• Охват основного бизнеса охватывает более 70% случаев использования.

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

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

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

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

Вспомогательная возможность выставления счетов в один клик, статистика данных за более чем 1 месяц: обнаружено более 140 ошибок, более 60 серьезных проблем, полностью решена ситуация, когда о проблемах можно сообщить только в группе, но нельзя отслеживать в замкнутом цикле. , а также записывает данные количественной оценки связанных задач, что также облегчает последующее сравнение существующих сетевых отзывов и анализ качества покрытия автоматизации и областей, которые нуждаются в дальнейшем улучшении.

• Вся автоматизация среднесуточное время работы 150+ раз (без дублирования)、Общее количество библиотек вариантов использования: более 33 библиотек адресов кода.、Общее количество вариантов использования на магистральной ветке — 6000+.

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

2. Повышение эффективности тестирования и снижение затрат на техническое обслуживание и ремонт.

• Улучшение здоровья

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

• Стандартизация вариантов использования (читабельность, нормативность)

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

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

3. Заимствовать возможности автоматизации для расширения специальных проектов.

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

4. Накопление опыта автоматизированного тестирования.

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

07. Резюме и перспективы

Вы можете найти массу контента об автоматизированном тестировании во внутреннем и внешнем Интернете, в том числе о том, как проводить тесты на работоспособность, типы тестов, инвестиции в тестирование, стратегии и структуры тестирования. Однако когда дело доходит до различных реальных предприятий, производительность — это все. какие-то странные. Если бизнес требует обеспечения качества, его необходимо протестировать, если не может быть гарантировано отсутствие проблем после разработки. Перед лицом продуктового бизнеса для десятков миллионов людей никто не может гарантировать, что проблем не возникнет. Чем выше требования к частоте поставок, тем лучше время выполнения, тем важнее автоматизированное тестирование. , но на самом деле может показаться, что рабочая сила, вложенная в автоматизацию, по сути такая же, как и рабочая сила, непосредственно выполняющая сценарии использования вручную, что часто приводит к размышлениям о значении автоматизации, особенно автоматизации на стороне клиента, в дополнение к методам автоматизации. , у нас есть другие методы. Есть ли способ обеспечить и избежать проблем с качеством? ? Поразмыслив над этим долгое время, если бы мне пришлось дать ответ, то это были бы люди. Люди могут все. Раз автоматические этого сделать не могут, то давайте сделаем это вручную.

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

• Никогда не отделяйтесь от бизнеса: бизнес постоянно обновляется и совершенствуется.,Любой инструмент или платформа для улучшения качества,Никогда не покидайте бизнес,Не оставляйте свой бизнес в покое.,Примените это в первую очередь к бизнесу,Спрос исходит от бизнеса. Лицо, на данный момент ответственное за поддержание автоматизации,Активно участвовать в бизнесе в период релиза,Включая специальный тест, тест на возможность выпуска,Глубокое понимание продуктов и бизнеса,В то же время это также позволяет максимально быстро выполнить задачу автоматизации.,Используется многими людьми,Многие люди присоединяются к борьбе,Дайте полную свободу действий до максимального значения,Специалисты по сопровождению сценариев использования и пользователи задач находят свою ценность в инструменте и платформе.
• Открытые идеи автоматизации: необходимо знать текущий этап построения автоматизации и этап достижения цели,добиваться результатов в бизнесе,Затем постоянно внедряйте и исследуйте новые способы автоматизации тестирования. Даже если в краткосрочной перспективе не будет рабочей силы для изучения более продвинутых и передовых методов, ее можно быстро и автоматически создать.,Но все равно продолжаем оптимизировать и повышать квалификацию,Улучшите скорость конвертации,Оптимизация эффективности выполнения, эффективности обнаружения проблем и т. д.,Это также важная часть конструкции автоматизации. данное время,Большие модели более зрелые.,Подождите, пока формат вариантов использования не станет более стандартизированным.,Быстрая адаптация,Нет нужды снова проходить через этот бесполезный опыт.,Использовать и недействительно из сцены,автоматизациятестиз карманный и нашел проблему,Речь идет не только о больших объемах и полном покрытии.,и ставится там, где скорее всего появится из.,Сценарии с частыми изменениями спроса,Так открой свой разум,не чувствуй себяизавтоматизация Очень много работы Низкий: если вы можете эффективно находить проблемы, действительно стоит продолжать. В то же время вам следует продолжать пробовать новые решения и совершенствоваться. Вы не можете отказываться от себя.
• Обратите внимание на ценность автоматизации. Ценность определяет устойчивое развитие.,Слепое освещение на ранней стадии, но игнорирование статистики здесь, данные автоматизации.,Это вызвало много дискуссий о том, стоит ли сдаваться. Есть соответствующая статистика и метрики.,Вы можете измерить соответствующее качество строительства и цели,Будьте целенаправленными и целенаправленными. Также постройте хороший бизнес по автоматизациирамкаитестирования на основе кода.,Он также имеет потенциальную ценность и содержание.,Его нельзя описать сценарием второго типа по определению.,Это должно требоваться при более высоких стандартах формального программного кода.,Это удобнее для последующего накопления знаний и опыта и постоянного развития.
• Автоматизация управления здравоохранениемавтоматизациятест – это долгосрочная битва,Бизнес не остановился,Тест-тест тоже не остановится. Необходимо поддерживать и управлять позитивным и здоровым менталитетом.,Постановка обозначенных целей и обзор целей,Здоровые долгосрочные результаты,Рим строился не за один день,Обнаруживайте проблемы во время строительства.

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

-End-

Автор оригинала｜Хуан Фэй

Как вы думаете, в чем важность внедрения автоматизированного тестирования? Добро пожаловать, чтобы оставлять комментарии и сообщения.