Качество является одним из ключевых факторов, определяющих успех продукции и устойчивое развитие предприятий. Как хорошо работать в построении системы качества-это относительно большая тема, охватывающая широкий спектр, и не существует фиксированного стандарта измерения.
Когда вы открываете веб-сайт по подбору персонала интернет-компании и ищете вакансии “Инженер-испытатель”, вы обнаружите, что почти все JDs содержат требование “создавать или участвовать в создании системы качества для бизнеса, за который они отвечают”. Итак, когда дело доходит до обеспечения качества, является ли это просто обязанностью команды тестирования? Как команда тестирования играет свою роль в этом процессе? В этой статье будут обсуждаться взгляды и понимание построения системы качества, основанные на практике команды по тестированию сотового трафика в процессе создания системы качества с нуля.
Распространенные заблуждения в области управления качеством
Когда дело доходит до управления качеством, многие команды могут легко столкнуться с несколькими недоразумениями в самом начале:
Переориентируйтесь на ссылку для тестирования
В практических проектах на этапе тестирования обнаруживается большое количество ошибок, подобных реализации, и тестировщики каждый день проводят исследования и разработки, чтобы исправить ошибки. Либо они обнаруживают серьезную проблему, когда находятся рядом с интернетом, что приводит к нехватке времени для исправления и проверки, но только “трезвомыслящие” онлайн. Обеспечение качества должно проходить на протяжении всего этапа реализации проекта-от предложения требований до исследований и разработок и тестирования. Если дело дойдет до тестирования, будет слишком поздно обращать на это внимание.
Обеспечение качества-это вопрос качества
При хорошем качестве мы можем улучшить пользовательский интерфейс и уровень удержания. Как и в первом вопросе, многие люди думают, что качество-это всего лишь вопрос качества и имеет мало общего с другими ролями. На самом деле качество программного обеспечения постепенно формируется в ходе всего процесса исследований и разработок и не может быть отделено от команды контроля качества, но, безусловно, недостаточно полагаться на внимание команды контроля качества. Все роли в бизнесе должны повышать осведомленность о качестве: разработка должна способствовать самотестированию; продукт должен быть спланирован и протестирован заблаговременно, когда качество и онлайн-контент. Когда возникают конфликты, качество должно быть первым выбором. Работающие студенты должны протестировать свои собственные рабочие страницы, прежде чем выходить в Интернет, и так далее.
Тестировщикам не нужно разбираться в коде
В условиях быстрой итерации требования к навыкам тестирования становятся все выше и выше, а сотрудничество между тестированием и разработкой становится все более быстрым и тесным. На пути ручного тестирования существуют две основные проблемы. Одна из них-высокая стоимость времени, которая не может удовлетворить потребности текущей быстрой итерации и подвержена ошибкам. Другая заключается в том, что технический уровень самих тестировщиков не может быть улучшен, и их рост ограничен.
В дополнение к ручному тестированию необходимо своевременно выполнять автоматизацию интерфейса, автоматизацию пользовательского интерфейса, проверку кода и другую работу, чтобы повысить эффективность в соответствии с потребностями бизнеса и команды. Эффективное сочетание этих двух факторов является ключом к обеспечению качества испытаний.
Нормальная онлайн-связь будет иметь большой успех.
Проект из требований, разработки, тестирования, выпуска только что завершил автономный процесс, хотя система прошла тщательное тестирование, но, в конце концов, онлайн-ситуация и сценарии станут более сложными и изменчивыми. Только после того, как онлайн действительно выдержит проверку онлайн-пользователей, мы должны обратить внимание на онлайн-журналы, отзывы пользователей, онлайн-отчеты. Полиция и так далее, своевременное устранение онлайн-проблем и рационализаторские предложения пользователя по оптимизации продукта или спросу на продукт и его реализации, образуя весь замкнутый цикл.
Построение системы качества крупных транспортных исследований и разработок
Чтобы помочь пользователям лучше завершить процесс принятия решений о потреблении по замкнутому циклу, Honeycomb запустила крупномасштабный транспортный бизнес, предоставляя пользователям такие услуги, как авиабилеты, железнодорожные билеты и так далее. Чтобы повысить стабильность системы и лучше поддерживать высокий уровень параллелизма, служба трафика оригинальной архитектуры PHP реконструируется в архитектуру кластера Java, которая поддерживает высокий уровень параллелизма и стабильности. В то же время бизнес каждого модуля постепенно контейнеризируется для повышения общей производительности и ремонтопригодности системы.
Команда big traffic test в основном отвечает за проверку авиабилетов, железнодорожных билетов и бизнеса по использованию автомобилей. Во избежание четырех Недоразумений, упомянутых выше, и в сочетании с конкретной ситуацией команды НИОКР, построение системы качества НИОКР большого трафика в основном осуществляется с четырех аспектов: процесс проекта, бизнес-тестирование, онлайн-мероприятия и разработка инструментов. На современном этапе перед построением системы качества стоят две задачи:
- Сократите продолжительность автономных проектов и уменьшите количество ошибок в автономном режиме
- Уменьшите количество онлайн – проблем
Рынок систем качества показан на следующем рисунке. Деталь в рамке пунктирной линии запланирована или выполняется, а деталь в рамке сплошной линии завершена.
1. Контроль процесса проекта и повышение качества доставки
Качество продукции не может быть гарантировано командой или этапом. Его необходимо контролировать и управлять на протяжении всего процесса НИОКР и на каждом этапе.
1.1 Классификация требований и определение проектного цикла
Для разработки бизнес-функций необходима возможность быстрой итерации и доставки. В настоящее время принят двухнедельный режим итерации, что является более сложным. Для того, чтобы обеспечить качество во время быстрого запуска проекта, мы рассортировали узлы времени доставки в соответствии с различными типами и уровнями требований.
В настоящее время существует меньше клиентских страниц с большим трафиком, в основном интерфейсные страницы H5. Исходя из двухнедельной итерации, требования делятся на три категории:
- ежедневно – Период разработки короткий, и он может быть завершен в течение одной итерации.
- проект – Срок разработки составляет более 3 дней, и он может быть завершен примерно за 2 итерации.
- Онлайн-события Незапланированные чрезвычайные ситуации, обычно с высокой степенью срочности, могут напрямую повлиять на онлайн-бизнес и потребовать своевременного реагирования.
Требования включают требования к продукту и технические требования. Чтобы рационально распределить ресурсы для разработки, ежедневные потребности и требования к проекту обрабатываются двухнедельным ПК, и объем спроса на следующие две недели подтверждается в соответствии со стоимостью проекта, приоритетом и ситуацией с ресурсами. Основные рутинные и проектные процессы заключаются в следующем:
1.2 Визуальное управление графиком проекта
Чтобы сократить цикл доставки, как улучшить работу команды, необходимо рассмотреть проблему гибкого продвижения разработки продукта. Общая идея продвигается гибкой методологией SCRUM. Таких посадочных средств существует множество. Мы выбираем ЛЕНТУ для управления всем жизненным циклом НИОКР. Например, используйте стены истории для визуализации состояния планирования итераций для крупных проектов; используйте Канбан для поэтапной синхронизации для конкретных задач, прозрачной командной работы, чтобы каждая роль могла напрямую отвечать за прогресс, повысить эффективность совместной работы.
1.3 Непрерывный Интегрированный Рабочий Процесс
Чем позже будет обнаружена ошибка, тем больше времени потребуется для исправления ошибок и тем дольше продлится проект. Чтобы улучшить качество доставки каждой ссылки, уменьшить количество ошибок в автономном режиме и ускорить прогресс проекта, мы постепенно продвигали следующие механизмы для каждой роли в процессе:
i) Для продуктов и UI Мы договорились провести проверку требований в течение 3 дней после принятия требования PK, чтобы повысить скорость доставки требований; принять участие в показательном примере после завершения разработки и ввода в эксплуатацию, а также проверить и принять продукты в первый раз.
ii) Нацелен на исследования и разработки В среду тестирования CI/CD добавляется статическое сканирование кода сонара, которое может быть развернуто только через quality valve; случаи самопроверки запускаются после отладки, а результаты отмечаются в инструментах управления прецедентами; Демонстрационный случай организован так, чтобы показать основной процесс продукта, эксплуатации и тестирования.
iii) Для тестирования Время рассмотрения тестового случая будет увеличено, насколько это возможно в соответствии со временем рассмотрения технологического плана разработки, и изолированная тестовая среда будет развернута за два дня до тестирования на согласованность разработки и самопроверки.
(Изолированные тестовые среды используются для параллелизма между несколькими проектами и будут подробно описаны в последующих главах.)
iv) Студенты-операторы Поднятые требования пригласят операторов принять участие в приемке продукции на выставке как можно скорее.
1.4 Развитие сознания Всего Персонала в области управления проектами
В настоящее время в большой команде по транспортным технологиям нет штатного PM, и все PM в проекте работают неполный рабочий день. Для обеспечения того, чтобы все ежедневные и проектные работы могли быть завершены вовремя или даже с опережением графика, лучшей организации процесса проекта и оптимизации процесса проекта, три человека, такие как руководитель группы тестирования, одновременно назначаются в качестве PMO. Учитывая проблемы в процессе проекта, они обмениваются опытом и обучают сотрудников по НИОКР и продуктам, чтобы повысить их способность к управлению проектами и идентичность продукта. Процесс осознания процесса обучения.
Хорошая формулировка и оптимизация процесса проекта, посадка процесса проекта и высококачественная доставка каждой ссылки на следующую ссылку ответственного лица являются первым шагом к обеспечению качества продукции.
2. Усилить Бизнес-тестирование для реализации Функциональной гарантии
С быстрым развитием масштабов бизнеса, все более сложной бизнес-логикой и взаимодействием на системном уровне команды тестирования сталкиваются с большими проблемами. В команде тестирования большого трафика есть пять аспектов для улучшения возможностей бизнес-тестирования.
2.1 Знаком с бизнес-процессами и функциями
Для тестировщиков только тогда, когда они знакомы с бизнес-процессами, функциями и другими требованиями, они могут открыть свое сознание и иметь определенную цель в процессе тестирования. Например, билетный бизнес большого трафика требует высокой точности базовых данных, а также некоторых специальных функций, таких как пустой склад, обновление, смена рейса, перевозка, регистрация и так далее, которые должны быть тщательно поняты тестировщиками. Мы будем время от времени приглашать студентов, изучающих продукты и операции, для обучения бизнесу по продаже авиабилетов. В то же время тест также даст студентам возможность поговорить и обучить некоторым бизнес-навыкам.
С присоединением новых членов команды и увеличением сложности системы, чтобы избежать пропущенного обнаружения, мы начали работу по сортировке бизнес-функций и диаграмм матриц ввода функций. Например, в дополнение к странице пользователя C-терминала, операционная справочная информация и справочная информация поставщика также имеют соответствующие функции, поэтому нам необходимо учитывать все записи в бизнесе, связанном со страхованием билетов. Матричная диаграмма содержит рекомендации по оценке технической схемы, плану испытаний и составлению схемы испытаний.
2.2 Считывание внутреннего кода
Как инженеру по системному тестированию, вам не нужно знать все методы разработки кода, но необходимо правильно прочитать код и логику кода.
Java является основным источником внутреннего кода для исследований и разработок в области большого трафика. Исходя из знакомства с бизнесом, тестировщики с базой кода Java устанавливают цели производительности для чтения кода внутренних микросервисов каждый квартал, чтения кода, понимания микросервиса, базы данных или кэша, определения взаимосвязи между задачами синхронизации, перехода в документы и наоборот. Для разработки микросервиса эффект чтения оценивается по разработке. После прочтения части или даже всего кода следующие новые проекты могут более свободно контролировать качество продукта с самого начала, например, является ли техническая схема разумной, проверка кода для инкрементного кода может заранее находить ошибки, помогать в разработке и определении причины проблемы и способствовать разработке технической схемы, протокола интерфейса, оценке базы данных перед кодированием. Испытание.
Следующая диаграмма является частью блок-схемы, которую студенты, проходившие тест на билеты, расчесывали, когда они читали соответствующие коды доступа к базовым данным билета.
2.3 Статистика Охвата Тестированием
Охват является распространенным показателем целостности и эффективности тестов. В крупной транспортной бизнес-системе логические ветви некоторых проектов очень сложны. Чтобы оценить, могут ли методы тестирования черного ящика, такие как ручное управление, автоматизация интерфейса, автоматизация пользовательского интерфейса, охватывать все логические ветви кода. Недавно мы запустили проект по статистике покрытия инкрементного кода, который в настоящее время находится в стадии тестирования в небольших проектах. После завершения одного раунда тестирования мы проверяем статистику охвата. Во втором раунде тестирования мы сосредоточимся на покрытии деталей, не охваченных в первом раунде.
Иногда некоторым логическим ветвям очень сложно создавать тестовые сценарии, которые должны быть охвачены проверкой кода и другими средствами. Следует отметить, что даже если инкрементный код покрыт на 100%, это не значит, что все в порядке. Иногда при разработке будет отсутствовать разработка какой-либо части кода. В этом случае наилучший вариант достигается, когда обзор технического предложения и функциональная матричная диаграмма объединяются для разработки тестовых примеров, но мы рекомендуем рассмотреть их еще раз позже в ходе тестирования. В зависимости от того, есть ли какие-либо недостающие разработки в одно и то же время.
В дополнение к инкрементальному тестированию кода перед запуском каждого проекта требуется регрессионное тестирование основных бизнес-процессов.
2.4 Содействие Самотестированию Проекта
Некоторые из более простых рутинных и проектных тестов большого трафика не задействованы, и принят режим разработки самопроверки + приемка продукта. Студенты-тестировщики будут регулярно обучать основам тестирования для студентов, изучающих разработку и продукты, таким как: развертывание изолированной тестовой среды Java, развертывание кода PHP, переключение интерфейсных микросервисов, использование макетной платформы и т.д. Некоторые тесты проектов также будут предоставлять тестовые примеры, которые будут выполняться продуктами, посредством обучения, чтобы также можно было выполнять проекты без вмешательства тестов. Достаточная гарантия качества.
2.5 Статистический анализ данных
Для повышения качества кода нам необходимо ежемесячно собирать данные о проекте и ошибке. Анализируя данные, мы можем найти и обобщить проблемы и причины в процессе проекта, а также выдвинуть предложения по оптимизации проекта и повышению качества и содействовать внедрению в проектной команде.
Ежемесячный отчет фокусируется на повышении качества проекта, а не на самих статистических данных. Благодаря отображению данных вы также можете знать, что качество нашего проекта постоянно улучшается. Например, в случае нескольких параллельных крупных проектов по продаже авиабилетов общее количество ошибок в автономном режиме в 1 квартале Датуна в этом году на 1/4 меньше, чем в 4 квартале прошлого года. Благодаря этим данным вы можете почувствовать, что общее качество проекта становится все лучше и лучше, и это также является хорошим источником вдохновения для команды. 。
3. Сосредоточьтесь на линии, чтобы сформировать проблему замкнутого цикла
В первой части статьи мы говорили, что недостаточно сосредоточиться только на оффлайне. Мы должны сосредоточиться на онлайн и объединить офлайн и онлайн, чтобы сформировать замкнутый цикл. При выявлении, лечении и обобщении онлайн-проблем общественного транспорта были рассмотрены следующие аспекты:
3.1 Стандартизированный Процесс Обратной Связи
Команда тестирования разработала полный механизм онлайн-обработки проблем и обратной связи для уточнения рабочего процесса и приземлилась с помощью инструментов (TAPD).
После получения отзывов от внутренних пользователей и внешнего персонала службы поддержки клиентов операция и продукт регистрируются в TAPD. Персонал технической поддержки фильтрует вопросы, воспроизводит и подтверждает правильность вопросов. Если вопросы верны, оцените тип вопросов: если вопросы носят консультационный характер, служба технической поддержки ответит напрямую; если проблемы связаны с ошибками (т. Е. сбоями в сети), обратитесь за разработкой и решением; для улучшения продукта передайте записи о продукте. Руководитель группы уведомляется о серьезных проблемах. Независимо от того, какого типа проблема, она будет распространяться в ОТВЕТАХ до тех пор, пока репортер по проблемам не проверит и не закроет ее. В конечном счете, результаты обработки будут переданы внутренним и внешним пользователям.
Приоритетные вопросы будут расставлены по приоритетам, и обзоры неудач будут организованы, как только они будут обработаны.
3.2 Активный Поиск Проблем
В дополнение к онлайн-сигналу тревоги, служба технической поддержки будет регулярно проверять различные предприятия, чтобы предотвратить серьезные проблемы в Интернете, а также активно находить проблемы в Интернете и продвигать решения с помощью ненормальных данных, таких как рынок данных, ненормальные данные базы данных, почасовые отчеты и так далее.
3.3 Конференция по качеству
Еженедельные совещания по качеству будут проводиться регулярно, при поддержке технической поддержки, с участием разработчиков, тестирования, продукта и эксплуатации. Онлайн-проблемы прошлой недели будут рассмотрены одна за другой. Причины неполадок будут проанализированы, и все аналогичные проблемы будут решены по точкам и областям. Проблемы консалтинга будут перенесены на инструменты спроса и эксплуатации, высвободив рабочую силу. Дефекты продукции будут переданы на производство. Спрос на продукцию. В начале каждого месяца совещание по качеству также будет рассматривать онлайн-проблемы прошлого месяца, выдвигать предложения по качеству и продвигать посадку.
В настоящее время ежемесячные данные о сбоях в работе общественного транспорта в режиме онлайн имеют тенденцию к снижению, что тесно связано с повышением качества автономных проектов, еженедельными встречами по вопросам качества и повышением осведомленности персонала о качестве, а пользовательский опыт становится все лучше и лучше в соответствии с потребностями в улучшении продукта в режиме онлайн.
4. Улучшение конструкции инструмента и повышение эффективности испытаний
Только ручных очков недостаточно. Учитывая реальные бизнес-сценарии большого трафика, разработка инструментов команды тестирования в основном сосредоточена на поддержке среды, стресс-тестировании, тестовой платформе, автоматизации пользовательского интерфейса, автоматизации интерфейса и так далее.
4.1 Экологическая Поддержка
Независимо от того, насколько совершенен обзор кода, в конечном счете требуется интеграционное тестирование. Хорошая среда тестирования является гарантией эффективности тестирования и качества проекта. В то же время, подходит ли тестовая среда или нет, очень важно для подлинности и правильности результатов тестирования.
Существует три тестовые среды для большого трафика: среда разработки, среда контроля качества и расширенная среда. В предыдущих средах тестирования были некоторые очевидные проблемы, такие как:
- В случае упреждающей разработки среды разработки только два проекта по изменению кода Java (QA и Dev, каждый тестовый) могут быть протестированы одновременно, что серьезно влияет на эффективность.
- Частые развертывания в средах контроля качества вызывают прерывания тестирования.
- Реальные билеты, выпущенные в условиях контроля качества, привели к потере капитала.
- Среда разработки идеально подходит для разработки самопроверки, но после развертывания тестирования в среде контроля качества даже основной процесс не работает.
Для решения вышеуказанных проблем мы провели трансформацию тестовой среды и среды предварительного выпуска.
4.1.1 Улучшение тестовой среды
В ответ на вышеуказанные проблемы мы улучшим среду тестирования. Стабильность, параллелизм, Изоляция и реальное время В качестве ключевого показателя следует реформировать среду тестирования.
относительная стабильность :
– Развертывание контроля качества при необходимости
– Java-код: утилизация привилегий Дженкинса от одноклассников по разработке
– PHP-код: Содействие трансформации платформы развертывания PHP компании (AOS), которая может быть развернута только владельцем и пользователями
Параллелизм :
– Java: Плагины изоляции тестовой среды введены для всех микросервисов, при этом поддерживается параллельное тестирование нескольких проектов
Изоляция :
– Заказы на тестовые среды недоступны онлайн
– Доступ К Билетам: Перехват Заказов
Производительность в реальном времени :
– В дополнение к тестируемому коду, другой код должен обновляться в режиме реального времени.
Хорошая среда тестирования эффективно гарантирует параллельную разработку, согласованность и тестирование нескольких проектов. За два дня до теста тестируемые студенты начали оказывать помощь в разработке и развертывании среды изоляции проекта, развитии согласованности и самотестировании в среде изоляции. После прохождения самопроверки тестируемые студенты непосредственно тестировались в среде изоляции проекта, что значительно сэкономило время перехода от разработки к контролю качества.
4.1.2 Условия подготовки к доставке
База данных, MQ, Redis и другое промежуточное ПРОГРАММНОЕ обеспечение в среде тестирования большого трафика отделены от рабочей среды. Учетная запись-это виртуальная учетная запись, а билет-это имитированный билет. Таким образом, все еще существует большой разрыв между тестовой средой и производственной средой. В прошлом некоторые проекты, которые выходили в сеть сразу после окончания тестовой среды, не запускались даже после выхода службы в Сеть.
Чтобы протестировать в условиях, приближенных к производственной среде, и повысить вероятность успеха одноразового онлайн-тестирования, мы запустили технический проект по открытию среды предварительной выдачи авиабилетов и железнодорожных билетов. Наше позиционирование в среде, предшествующей выпуску, заключается в:
- Предварительный просмотр перед запуском
- Реальные Счета, Реальные Транзакции
- Изоляция кода и производства
После того, как среда предварительной выдачи авиабилетов и железнодорожных билетов была полностью открыта, все товары предварительно выдаются после завершения тестовой среды для основного возврата, а затем в режиме онлайн.
Текущий процесс тестирования выглядит следующим образом:
4.2 Испытание Давлением
В проектах поиска и деятельности со сценариями с высоким уровнем параллелизма мы проводим стресс-тестирование. Процесс измерения давления показан на следующем рисунке. Здесь вы можете сослаться на предыдущую статью о стресс-тестировании, опубликованную компанией Honeycomb Technologies Public, но это не так много для расширения.
4.3 Испытательная платформа
Тестовая платформа – это портал теста большого трафика. Java используется в задней части бизнес-линии исследований и разработок с большим трафиком, а VUE используется в передней части. Чтобы быстрее ознакомить всех с технологическим стеком исследований и разработок с большим трафиком, тестовая платформа использует ту же архитектуру, что и передняя и задняя части исследований и разработок.
Конечной целью тестовой платформы является интеграция инструментов, разработанных командой, таких как статистика покрытия кода, фабрика данных, отображение результатов испытаний под давлением и т.д. План последующих действий будет постепенно добавлять функции автоматизации интерфейса и автоматизации пользовательского интерфейса, постепенно улучшать функции тестовой платформы и открывать ее для внутреннего и внешнего персонала команды в виде интерфейса. Используйте для повышения эффективности тестирования.
4.4 Фабрика данных
Фабрика данных разработана на основе платформы для тестирования большого трафика. В некоторых требованиях для тестирования обратных транзакций сначала необходимо создать различные типы заказов в качестве тестовой предпосылки. Если заказ авиабилета оформляется с лицевой стороны, существует пять шагов: главная страница – > страница списка – > страница предложений – > страница заполнения заказа – > страница выбора пассажира. Чтобы упростить этапы создания заказов, облегчить приемку продукта и возврат для использования внешними командами, мы разработали и внедрили фабрику данных билетов. Мы надеемся выполнить ключевой заказ для внутреннего и международного тестирования билетов, быстро предоставить данные о заказах для исследований и разработок и тестирования, а также предоставить данные для регрессии тестовой среды.
В дополнение к среде изоляции проекта в тестовой среде крупных транспортных билетов поддерживается стабильная базовая среда. Коды в этой среде в основном соответствуют кодам в Интернете. Фабрики данных создают заказы на билеты на основе базовой тестовой среды.
В настоящее время фабрика данных разделена на четыре модуля: модуль внутреннего/международного списка учащихся по билетам, модуль аналоговой оплаты, модуль выдачи билетов и модуль регистрации. Связь вызова между четырьмя модулями и сервером билетов показана на следующем рисунке:
В настоящее время фабрика данных реализовала функции квитанции о рождении, аналоговой оплаты, выдачи билетов и журнала операций. После заполнения параметров он может нажать соответствующую кнопку непосредственно на главной странице.
4.5 Автоматизация интерфейса
Преимущества автоматизации интерфейса очевидны. Мы используем более общую структуру автоматизации интерфейса, Тестирование+Уверенность в себе+Maven, которая в настоящее время настроена и запущена на Jenkins, а затем подключена к тестовой платформе.
В настоящее время регрессионные тестовые примеры, охватывающие основной процесс, регулярно выполняются в тестовой среде, а автоматизация интерфейса класса поиска регулярно выполняется в режиме онлайн для мониторинга и оповещения при возникновении отклонений. Кроме того, автоматизация интерфейса также используется при создании данных, регрессии основных процессов и тестировании проектов миграции.
Некоторые возникшие трудности
В процессе построения системы качества мы также столкнулись с некоторыми трудностями:
1. Трудности в совершенствовании процесса
Например, внедрение сканирования статического кода гидролокатора. Раньше Sonar просто ставил его на платформу CI и не привязывал к CD или не вводил качественные клапаны. Ему нужен штатный персонал, чтобы побудить разработчиков сканировать и проверять результаты сканирования. Эффект от внедрения статического сканирования кода не очень хорош.
Чтобы позволить Sonar автоматически отображать эффективность проверки кода, мы внедрили Sonar в платформу CD для тестовой среды и разработали унифицированный клапан качества. Сканирование гидролокатора не может быть развернуто в тестовой среде без прохождения проверки качества. Сначала проект использовался в качестве пилотного, и проблемы были найдены и решены. Сейчас все проекты находятся в процессе тестирования. Прежде чем можно будет отправить тест, его необходимо отсканировать с помощью кода гидролокатора и пропустить через клапан качества.
2. Конфликт времени на бизнес-тестирование и разработку инструментов
В большом трафике нет штатных постов по тестированию и разработке. В случае конфликта приоритет должен быть отдан бизнес-тесту. Разработка инструмента должна быть выполнена в период перерыва в бизнес-тестировании. В этом случае некоторая работа по автоматизации, тесно интегрированная с бизнес-тестированием, выполняется медленно. В настоящее время автоматизация нашего интерфейса охватывает только ядро. Что касается вариантов использования, нам необходимо объединить автоматизацию интерфейса с большинством тестов проектов и применить автоматизацию интерфейса к тестированию проектов.
резюме
Команда по тестированию дорожного движения была создана менее года назад. После периода исследований и практики качество НИОКР в определенной степени улучшилось, но мы только начали строить систему качества. По мере того как бизнес-системы становятся все более и более сложными, требования к тестировщикам и системам качества будут становиться все выше и выше, и всем участникам необходимо постоянно совершенствовать качественное мышление и стремиться к качеству. В будущем мы будем продолжать накапливать методы, оптимизировать процессы и совершенствовать инструменты для обеспечения высокого качества и непрерывной доставки.
Автор этой статьи Сунь Хайян, эксперт по бизнес-тестированию трафика Horse Honeycomb и руководитель группы тестирования трафика.
(Карты вопросов взяты из Интернета)
Сосредоточьтесь на технологии Honeycomb и найдите Больше Того, что Вам нужно