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

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

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

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

В этой статье обсуждаются некоторые мои представления и мнения по теме автоматического тестирования.

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

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

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

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

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

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

Давайте поговорим о многоуровневости автоматизированных тестов.

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

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

Но с точки зрения фактической сложности реализации автоматизация пользовательского интерфейса сложнее, чем автоматическое тестирование интерфейса.

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

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

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

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

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

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

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

На самом деле не рекомендуется слишком полагаться на покрытие в качестве KPI или ядра отчетности в практике автоматического тестирования, иначе все просто будут накапливать сценарии использования или сценарии.

Даже в целях измерения и оценки при разработке показателей измерения рекомендуется следовать и учитывать следующие моменты:

1. Избегайте создания показателей на основе индикаторов/KPI;
2. Учитывая стоимость резервирования, индикаторов не должно быть слишком много;
3. Индикаторы разрабатываются для улучшения качества, а не для получения данных;
4. Разрабатывать метрики с целью проведения Автоматизированного тестирования;
5. Сравнение показателей должно основываться на том, решены ли болевые точки;
6. Метрики являются вспомогательными критериями оценки и не являются единственными правильными результатами;
7. При формулировании индикаторов мы должны учитывать, какие индикаторы более практичны и эффективны, и начинать с точки зрения решения проблем;
8. Метричные показатели не должны оцениваться каким-то одним способом, а должны сочетаться с несколькими измерениями для всесторонней оценки и проведения измерений качества;