一、背景在数字经济背景下，产品会依据市场需求不停更新迭代，新产品会不断淘汰老产品。在新老产品更替的过渡时期，老服务将会进入维护状态，研发的投入会急剧减少，服务的维护人员也会发生较大变动。因此，对于基础设施升级或者服务合并的情况，旧服务的测试工作就会变得相当棘手。总结有以下2个痛点：服务中存在很多的废弃代码和接口，服务处于亚健康状态。旧服务的接口自动化难以维护和覆盖全面。基于以上的2个痛点，需要有工具可以自动评估服务的接口优先级。通过该工具，测试人员可以抓住服务的重点接口，保障老旧服务的质量。二、现状分析我司目前有一套比较完善的监控系统，可以拉取接口流量以及接口的详细数据。但由于日志的时限性，监控系统最多保留7天数据。而我们的诉求是想知道更长时间内的接口访问情况，时间越长，越能对接口的重要性有准确的评估，从而辅助判断接口的优先级。针对该现状，我们需要做一次新的开发。三、实现3.1、基本框架的设计基于背景的思考，希望有个平台拥有以下3点功能：沉淀每日API请求数据。根据请求频率和请求次数来决定接口的优先级。做成可接入式，方便公司内其他组的接入。一键式接入，节省使用方的时间。3.2、思路拆解对应平台的功能，主要可以拆解成3个模块。分别是服务接入、巡检模块和前台展示。如下图，服务接入主要做的是初始化操作，即从网关读取服务的所有接口进行入库操作。巡检模块是对服务的每日数据进行整理与入库，前台展示将在后续第4章进行详细描述。3.2.1

一、背景：接口自动化是一种能提高服务回归效率，保证服务稳定性的重要方式。但是对很多做接口自动化的测试来说，往往痛苦大于快乐。主要问题还是在于接口自动化的校验。写校验成本较高。很多接口响应字段可能非常多，结构体复杂，要做到详细校验编写成本很高。而越详细的校验，维护成本也越高。测试数据的变动，开发的改造，往往能让人崩溃。校验不够详细。很多接口case为了急于求成没有写返回校验，或者校验深度不够，这会导致接口自动化流于形式，不能发挥真正的作用；基于此，希望有一个快速编写接口响应校验的方法，要求简单、便捷、有效、可维护性高。本以为接口自动化大家都在做，通用的响应校验网上应该有很多现成的，但是找了下却没有找到满意的。通用的json校验有，但是接口响应未必都是json格式的。DeepDiff在功能上基本满足要求，但是它是python的，而本人需要的是java的。基于此，就考虑自己封装出一个基于java的通用的接口响应校验方法，降低接口响应校验的编写和维护成本。二、实现：使用java编写，响应校验实现逻辑大致如下。入参这里actualResp是实际的接口响应，exceptResp是期望的接口响应。2.1

“利特莫斯”是什么？Litmus由测试效能开发，用于检测代码质量的平台。Litmus支持代码异味、重复代码、复杂度、单元测试成功率、单元测试覆盖率等指标的获取。只有提测的代码质量越高，我们交付的产品的质量才有可能越高。上述指标的获取基于开源工具Sonar和Jacoco。下图为Litmus设计的流程图：Litmus接入CI,成为发布平台代码质量卡点依据后，Litmus的日均任务量从100多涨到了1000多，到现在快2000，原先的Litmus性能较差，无法承载这样的任务量下的构建，下面是Litmus月任务数看板，可以看到一年内的任务量的暴涨。Litmus接入CI初期，平台存在以下问题：Jenkins任务pengding时间过长。Sonar频繁崩溃。Sonar报告生成时间过长。Sonar磁盘不足等问题。“利特莫斯”优化过程针对这些问题，我们做了下面的优化。针对Jenkins

背景酷家乐有一套自己的UI自动化框架--Hades，其主要以puppeteer与playwright为核心进行了二次封装改造，并整合了许多酷家乐设计工具前端api。使得UI自动化对canvas交互、前端性能测试有比较好的支持。除了能力上的扩展以外，Hades还有一个显著特点是:它将puppeteer/playwright中的api都代理到一个pyBell对象上，使得我们无需关注browser、page、element等对象，大大简化了用例编写的难度。对于酷家乐设计工具而言，UI

一、前置云原生给各中小公司工程效率带来了很大的便利，多家云厂商的架构体系不完全相同，在选择云厂商以及业务上云的过程中，整体的集群切换会是一个比较复杂的课题。酷家乐在2022年初进行了一次整体集群切割，实际的切换过程由于前期的认真准备和各项策略的实施取得了符合预期的效果。本文期望给做整体集群切换的质量团队做一个分享。机房切割可能在自有机房和公有云之间的迁移，或者公有云间的迁移。酷家乐碰到的场景是在公有云之间做迁移，文中姑且描述为A云到B云的切换，A云为旧生产集群，B云为新集群。集群迁移涉及到工作面非常多，选出部分关键内容进行分享。二、目标和背景目标原因测试挑战切割后不能影响重要商家重要核心商家功能不能有阻断，否则会带来公司信誉受损，甚至资损主功能回归之外还要注意分支逻辑务必一次切换成功因为集群迁移整体回滚难度大，意味着二次切割，所以需要全力争取一次切换成功回归测试务必充分切割时间需控制在2小时涉及国际业务线，国内白天为国外工作时段，业务方能接受的硬性要求，停服时间控制在2小时以内，几乎是多家其他公司做B云迁移史上的最严苛要求前置准备需要充分切割验证需要快速有明确Deadline工作倒排其一是春节是唯一长时间国内流量低峰期，风险可控，该时间为国内国际业务和商务同学沟通后的最佳时间。其二项目涉及团队太多，每轮回归会牵扯多团队人员的投入，测试过程需要有连续性，否则可能面临二次测试的问题验证效率需要保障，需要引入一些技术手段缩短时间三、测试方案和策略3.1

一、为什么开发场景化Apollo框架介绍：适用于酷家乐业务体系，多功能接口测试框架。随着公司业务的快速扩大，对业务质量的要求也越来越高，原先的框架无法支撑起复杂的业务自动化，需要重新进行升级改造。二、期望改变什么想要提高人效和接口收益率，为此我从以下两方面进行了设想：

使用缓存优化后效果build模型的时间仍有了一定程度的降低，整体响应时间降低20%~30%总结：单接口耗时，不同阶段的时间分布，可以对不同阶段进行耗时分析，进一步分析可以优化的空间四、总结

kurepeater录制的流量我们将其存储在ES，但这个ES库不是专属实例，它还共享着公司其他应用。随着一些核心应用接入kurepeater，kurepeater的存储规模也增加起来。

一、背景随着业务的快速发展，酷家乐数据库量越来越大，其中部分数据表达到二十亿级别。前段时间int整型溢出导致的故障就是一个典型案例，作为公司第一张表达到20亿级别。单库或单表数据量过大，会导致数据库的查询压力越来越大，数据库读写耗时持续上升。实际工作中我们会发现，对于复杂链路场景，数据库的读写性能往往会成为业务发展的瓶颈。一般来说对于数据量较大的表，我们会在业务迭代过程中会使用分库分表来降低单实例的查询压力和请求耗时。此外，不少场景对数据读取耗时要求非常高，尤其是一些关联性非常高的核心表，为了进一步降低请求耗时，也会接入ES等搜索引擎。二、方案设计一般数据迁移需要考虑以下两个问题：数据同步的一致性和线上业务无感知渲染在过去两年内进行了多次的分库分表及数据迁移任务，并攒下了不少经验，供大家参考。数据迁移大致可以分为以下几个步骤：迁移过程设计、影响范围评估、数据同步与验证、开关操作与代码清理前面两步相信大家都轻车熟路了，链路梳理完后基本会对业务整体有个清晰的认识，并能给出一个初步的影响范围评估。这个数据迁移过程中核心环节主要有两个：数据同步与验证，开关控制。为了尽可能降低对业务的影响，实现数据的平滑迁移，一般我们会通过开关控制整个项目进度。确认数据同步完成与校验通过后，逐步打开外网的开关，灰度实现数据的迁移。同时开关为我们提供了一种应急响应方案，迁移过程中一旦新库出现稳定性或数据一致性问题，可快速切回旧库，保证数据库的稳定和数据可靠。通常我们数据迁移操作主要为以下几个节点：代码上线。开关支持双写切换、读切换，且已在内网验证过；执行双写。打开开关同步写入新老库。默认情况下新库自增主键id来自旧库。存量数据同步。将旧库存量数据同步到新库中；写顺序切换。改写入顺序为先写入新库，旧库自增主键id来自新库。数据同步校验与业务测试验证。切换读开关。改为读新库。观察一段时间，若无问题反馈，则停写旧库、下线开关及迁移代码通常情况下，线上库每天的写入量是巨大的，因此需要先保证增量数据同步写入新库和旧库后，才会去做存量数据的同步。这里需要优先保证迁移的代码及其开关上线。数据同步本身的过程相对简单，但是数据源订阅的切换及顺序操作才是风险最大的地方。因此业务逻辑代码实现必须首先得到保障。另外一个需要注意的地方，数据库迁移之前一定要完成数据表的读写收拢，避免迁库完成后数据不一致，尤其是写入操作主键冲突。一般情况下原数据表是默认有效且可靠的，那么迁表初期自增主键取自旧表；当数据同步完成且校验一致后，自增主键id则可切换到新表。因为外网和beta共用数据库，两个环境顺序不一致就会有可能导致自增主键冲突写入失败，尤其像renderpic，两个环境时刻都在大量写入操作，风险较大。。当然如果数据表比较简单且业务量不大，那么选择深夜直接切换会相对比较简单。三、数据同步在进行数据同步时，首先需要确认主键，只有确定了主键ID才能实现数据同步操作。如果当前表使用了自增主键id，那么在分库分表前需要将主键id的增长规则确定，一般建议采用sequence表同步。数据同步一般有两种方式：基于特定框架或者工具，自定义代码实现数据同步。1、存量数据同步

TesterHome：kujiale-qa

背景介绍概念引入在微服务架构的前提下，服务数量众多，相互之间接口依赖关系错综复杂。在敏捷迭代的情况下，各个发布频繁；尤其是中台服务的变更影响范围非常大。对于Tob公司来说，有很多SKA这种大客户，需要保障这些用户使用到的核心功能的稳定。而各个前台业务线功能的稳定性不仅仅依赖自身服务的稳定性，而且需要全链路的稳定。每个版本的发布，都需要对应的所有测试场景验证通过。这样，BVT的概念就比较清晰了：版本验证测试(Build

改方案名称为乱码问题：由于镜像变更导致的乱码，确实是没有被评估到的，毕竟这个镜像在国内已经被广发使用，相对成熟。对于国际化以后的测试建议是重点测试多语言及时区。五、第四阶段：全面接入微服务体系5.1

单插件前端自动化将数据保存起来，每次迭代运行API测试，保证数据的准确性推荐阅读酷家乐专项测试之弱网实战基于大数据日志系统的流量回放平台从0到1，错误码如何设计和实现

一、为什么做mesh回归随着3D云设计工具的发展，用户可通过云设计工具，进行家居、公装、建筑、地产等全空间领域的云设计。目前，云设计工具中包含较多的设计工具，如硬装、定制和BIM等。众多的工具衍生出众多的测试工作量，需要有一种针对性的效能回归方案。二、什么是mesh一个3D模型的统一表达方式，所有的面拆分成多个三角形，进行表示。如下图所示：三、mesh回归的应用场景|

一、专项背景在酷家乐设计工具迭代中，发生了若干个线上故障，最后排查后发现在弱网情况下触发。那么从测试的角度来说，需要额外关注的场景就远不止断网、网络故障等情况了。对于我们的设计工具来说，弱网下工具的前端显示效果，数据的稳定性，给出正确提示尤为重要1.1故障背景去年某月—部分用户在弱网环境下，触发云图保存数据操作，引发接口回调过慢，最终导致方案大量数据发生丢失情况。并且该故障在三周内增加2000+客诉，在一定程度上反映出了当前用户网络情况：仍然有不少用户的网络环境并没有预期的好，并且该事例体现出数据稳定对于酷家乐设计工具的重要性。二、进行弱网测试的目的最重要的四个目的：1.保证方案数据的一致性和准确性。例如：网络状况比较差时，不能发生方案内的数据丢失或者数据异常。2.保证界面显示的正确性。例如：加载方案时，页面的加载可以一直在刷加载动画，

一、说明这篇文章想阐述的，除了提供当前大数据组流量回放平台的思路和实现，也提醒大家：通过日志系统可以做很多事情，比如获取并分析用户行为，实现基于用户行为的精准测试，又或者是线上巡检等等，而我只是小试牛刀。。。二、背景2020H1正在对大数据引擎服务-浑天仪进行重构升级，这个项目主要的场景是：将业务方发送的json(dsl)翻译成sql，查询大数据各类存储引擎的数据，验证重点是：确保查询大数据存储数据接口的请求和返回的处理结果跟原来保持一致。而主要的难点在于：仅从手工造数据的方式很难覆盖各种业务场景，尤其是如何构造请求参数组合和检查各种返回的内容，难度相当于测试mysql等数据库的sql语法。于是想到了基于流量回放对比的方式提高测试效率。三、工具调研虽然团队内部已经有了基于jvm-sandbox-repeater和基于goreplay

1.背景由酷家乐、阿里、有赞和e签宝四家公司讲师出席分享的杭州第六届测试沙龙在20年12月19号落下了帷幕。除了公司(酷家乐)对举办技术类分享的大力支持外，还有一支团队在默默地操办着一切，这就是"团队影响力运营小组"！近年来在测试领域，无论是杭州测试圈还是知名社区(诸如Testerhome社区)和分享大会(诸如MTSC)上，都可以看到酷家乐质量效能团队的身影，团队的存在感与知名度在逐步提升。这些也都离不开影响力运营小组在背后的付出。2.小组介绍团队影响力运营小组是财宝(岗位：测试总监)在19年6月份组建的虚拟小组，旨在组织好内部的分享与提升质量团队的影响力，成员来自于各业务线的测试同学。这一年半以来主要负责的工作有：1.

一、为什么做错误码随着3D云设计工具的发展，用户可通过云设计工具，进行家居、公装、建筑、地产等全空间领域的云设计。目前，群核科技（酷家乐）广泛应用于企业的设计、营销、管理等解决方案中，用以提升企业的效能。在3D云设计工具的功能不断丰富和完善中，整个设计系统涉及到的业务线和功能模块越来越多。以云设计工具4.0为例，其中包含较多的设计工具，如硬装、定制和BIM等。对于工具的线上问题反馈，存在线上问题定位难、排查效率低和信息不全等问题，导致用户线上问题解决链路长、时效性低，运营和业务支撑侧人力资源成本高，产研侧问题定位和排查成本高等问题。思考：是否可在用户出现线上问题时，给与一定的错误提示来引导和解决问题？二、错误码是什么在用户遇到业务异常时，系统提供相应的“错误码”，给与帮助和引导问题解决，进行问题的快速定位。用户场景演示

哪些会影响“稳定性”？类似对于ui自动化中问题的分析解决一样，我们首先去了解一个用例的执行过程，其次分析这个过程中有哪些“不稳定”的影响因素，再次还需了解对于云设计平台来说，又有哪些独特之处。3.1

一、产生背景众所周知，酷家乐是国内首屈一指的大家居全案设计平台及生态解决方案提供商，致力于为数字化升级提供一站式的解决方案，客户多是以中文为主的公司。虽然有英文版，但是实际使用中还是会遇到很多问题：语言问题：酷家乐以中文为主，英文版支持不够完整，且无其他语言。

结果从0到1实现了铺贴UI自动化自动化闭环：部署-自动化回归-报告展示5.2

前文链接：流量回放框架jvm-sandbox-repeater的实践1.前言前文中，我们已经介绍了jvm-sandbox-repeater的原理，以及我们对它的初步实践。本文将进一步介绍我们目前的平台化实践工作。我们将该平台称为kurepeater。篇幅限制，这里主要介绍下kurepeater的基本架构和录制回放的优化设计。2.基本架构kurepeater主要由repeater(jvm-sandbox-repeater)、console、es、db、前台页面5部分组成。前端页面结构参考了官方demon并结合实际需要进行设计，采用公司内部框架进行开发；后台基于官方开源代码，并进行一些定制化的改造。前台页面只和console进行交互，console操控整个流程。各模块间交互关系如下图所示。要启动repeater进行录制时，需先从前台进行配置和模块安装。配置我们存储在了DB里面。模块安装负责将jvm-sandbox-repeater安装到目标服务器上。点击激活，启动和录制流程如下图。录制数据序列化后存入es。录制结束，可以在前台选择需要回放的流量和方式，通知console。后台回放流程如下。回放成功后，我们可以在前台页面查看回放结果数据，成功失败信息，并对失败接口进行排查。3.录制优化平台化后，使用kurepater平台对流量进行录制，特别是线上环境，遇到了如下两个问题1）有些接口不想录制怎么办2）线上各接口流量严重不均衡，高频接口录制了一堆，低频接口可能一次都没录到对于问题1，一开始我们在白名单httpEntrancePatterns里面写正则过滤这些接口，比如^((?!/error$)).*$，然后重新启动服务。但是频繁的修改httpEntrancePatterns和重启服务比较麻烦，另外正则配置在辨识度和易用性上也存在一定的困难。为此，我们增加了黑名单blackEntrancePatterns过滤功能。与httpEntrancePatterns相对应，在blackEntrancePatterns中的接口都不录制。blackEntrancePatterns优先级高于httpEntrancePatterns。对于问题2，其中一种解决办法就是当某个接口录制的量太大了，我们就把这个接口加进黑名单，然后重新激活服务继续录制。如此循环，确保高频接口量不至于太多，低频接口也有录制到。当要录制的接口比较少时，这种方法还行。但当要录制大量接口时，这种操作就有点繁琐尴尬了，所以最好是一开始就根据不同的接口qps赋予接口级别采样率。为此，我们在官方实现的http插件里面加了点代码，大致如下前端配置界面如下。第一个采样率是统一的采样率，供所有需要录制但是没有特别强调接口采样率的接口使用。console里面的配置读存也做了修改。3.回放优化录制流量后对流量进行回放，发现回放结果比对失败的很多。经过对失败原因进行排查和统计，发现有些是真的新代码有bug导致的失败，但更多的失败并不是代码bug，例如1）代码修改，修改了子调用，导致mock失败2）有不支持的子调用，导致失败3）子调用有随机参数相关，导致mock匹配不上4）响应的内容用了随机数或者时间相关参数，导致比对失败5）repeater代码缺陷还有一些其它原因，这里不一一赘述。失败原因很多，真正有效的失败数很少。如此一来，每次回放失败的排查成本就非常高，这违背了我们的初衷，也给平台的内部推广带来了困难。我们迫切期望过滤无效的失败，节约不必要的排查时间。3.1

背景介绍每次上线一大堆代码改动，到底影响了哪些功能，比较依赖经验测试完了之后，不清楚把这次改动涉及到的功能点是否都测到了在敏捷迭代的背景下，发布频繁，测试时间不足，我们必须要了解核心流量在哪里，优先保障核心流量经过的功能高可用服务中的废弃代码，留着又不知道做什么的，删的话又没把握微服务架构下，如何评估对业务方的影响方案设计对于上述测试痛点，要解决的核心问题就是测试效率和测试质量，我们从以下几个方面来逐个击破：首先要解决的问题就是，科学地评估代码变更影响到的功能点；最好能够做到智能推荐用例再就是要获取到测试的增量覆盖，清楚的知道哪些变更的代码还未覆盖到完成以上两点，就解决了测试前清楚该测什么和测试中应该补充测试哪些测试点的问题测试功能点评估这里涉及到几个关键能力：1.

背景随着酷家乐网站功能的不断迭代，业务场景也越来越复杂。网站页面多且层级深，账号类型多且权限易变，导致测试人员的回归测试工作冗余和繁杂。为了减轻回归工作，日常巡检能力是必要的，本文主要介绍网页巡检工具在酷家乐的使用和实践。实现原理如何获取网页信息是网页巡检的核心点，对此我们选取了Puppeteer开源工具，Puppeteer是Node.js工具引擎，它提供了一系列API，通过Chrome

推荐阅读1、如何提高接口测试的效率2、故障演练平台开发实践3、代码度量平台4、Android精准测试探索：测试覆盖率统计5、覆盖率平台开发实践6、一站式压测平台实践公众号：酷家乐技术质量

背景酷家乐作为一个中国顶尖的家居装修网站，为消费者提供各种室内装修设计方案，户型图绘制工具，装修效果图，定制家居等等，其背后都离不开茁壮的技术架构和稳定的基础设施。定制设计工具作为酷家乐工具中帮助用户实现其定制化服务的工具，其能完成定制柜体从建模到设计到图纸再到生产输出，都离不开数据二字，这也就意味着，定制数据的复杂性及多变性在测试过程中会成为一大难点。接口测试作为测试过程中必不可少且极其重要的一环，其数据的正确性在这里会极大地得到保障。接口测试通过率也被加入到发布过程中卡点数据，其重要性显而易见。如何设计接口测试优秀的后端测试开发最基础的素养就是懂得如何设计接口测试用例。下图简述了如何做好接口测试。本文不做展开接口测试痛点

通过自研将混沌工程形成的各种标准和规范，以产品化的形式整合为故障演练平台。ChaosBlade阿里巴巴开源的一款遵循混沌工程原理和混沌实验模型的实验注入工具，具有以下特点:适用场景丰富

因忙于部门内部火星日比赛的活动，上周技术文章推送比平时晚了几天，在此表示歉意。什么是火星日火星日是酷家乐质量效能部半年举办一次的技术专题竞赛活动(然鹅并不是纪念我们来自火星)~竞赛主题由整个部门同学提前2-3个月投票选出，所有同学都均可报名参加，报名的同学只需要提交PPT等相关资料，最后决出前三名比赛获奖者。(为了尽快进入精彩环节，特意将火星日比赛规则挪到文章末尾)2020H1火星日2020年上半年火星日主题经过投票后定为"前端测试"，可以是前端测试领域内任何相关内容。本次有7位同学报名，数量比上一届少了将近一半，但内容更加丰富、呈多元化，涵盖了国际化业务、前端性能、前端埋点、前端自动化、前端框架等领域。主题背景说到前端测试，大家可能认为这有什么难度？流程点点点，用个自动化UI框架代替手工测试不就完事了吗？难点顶多是元素变更带来的手工维护成本。我想说的是，咱们酷家乐前端的还真不一样！酷家乐产品主打大家居室内智能设计，前端测试的难度主要集中在工具线。前端主要作为一块画布，设计师在上面进行新建更改户型、铺设地板瓷砖、任意拖动橱衣柜模型、更改材质尺寸、自动生成家具(生成移门、台面等)、智能设计摆放饰品等等不胜枚举的专业设计操作。天马行空的创意设计、不胜枚举的交互功能，专业的大场景大方案，由此给测试在回归测试和前端交互性能方面都带来了很大的挑战，并且似乎业界也没有太多可以参考和借鉴的案例。如果您有任何好的想法，欢迎随时交流~精彩作品前端自动化Selenium等业界开源工具根本直接无法满足酷家乐前端自动化的需求。最终，在公司最高级别产研协委员会立项，成立前端自动化框架项目组，就是为了攻克前端自动化测试难题。为了提高产品的可测性，测试和开发同学配合设计封装了一系列前端操作API，由此搭建了酷家乐前端测试框架pybell。动图仅供参考前端性能前端性能作为新版设计工具需要解决的头号挑战，我们在这个领域进行了多方面的尝试，包括性能基线和性能场景看板。前端监控前端监控分级策略为发现性能问题带来清晰的问题排查思路，也为灰度发布计划带来了科学合理的依据。前端自动化框架最后压轴展示的是，酷家乐自主研发的前端自动化框架pybell。经过不断地优化，代码量压缩了85%，还提高了稳定性。评委风少对此的评价是，这体现了框架作者对技术的极致追求~火星日规则比赛形式比赛总共两轮，分为初赛和决赛。1.

背景公司业务飞速发展，技术团队不断扩张，面对这样的局势，技术团队引入了很多高P的人才，他们有着不同的大公司背景，在引导团队不断向前的同时，也面临着技术上的挑战。大部分技术人员来自不同的公司，有着不同的技术背景，也深受着以往公司的技术文化影响，大家的编码风格、编码规范都带着过去的影子。甚至有些同学不知道做单测意义，觉得测试同学有接口自动化就足够，团队内部同一个项目中也会出现不同的风格，开发主管也没有那么多精力去review开发的每行代码。这个时候就需要通过一些技术手段来解决代码规范检查的问题，协助开发完成单测、安全检查。通过一些自动化的方式来度量开发的代码质量，并能够及时发现问题，保证开发提交的代码都是高可用，高质量的。同时可以为团队的管理人员提供一些有效的量化结果，指导做一些流程和技术上的优化。通过提升研发代码质量，增强研发对于提交测试代码的信心。同时保证代码的高质量，高可用性，高可读性，随时保证代码分支的代码纯净，并能够很好的支持CI/CD。为达到上述目的，我们开发了代码度量平台。目标平台目标:代码优化的依据衡量研发质量做到质量闭环具体实现分以下四个方面来逐步实现规范化:

}}step3:修改AndroidManifest.xml文件1、在中声明InstrumentedActivity2、声明使用SD卡权限3、单独声明JacocoInstrumentation

背景作为一个测试人员，保证产品的软件质量是其工作首要目标，为了这个目标，测试人员常常会通过很多手段或工具来加以保证，而覆盖率就是其中比较重要的一个环节。覆盖率是用来度量测试完整性的一个手段，是测试技术有效性的度量。希望有个平台可以统计整个迭代的后端覆盖率数据报告，

简介一站式压测平台是基于开源压测工具的基础上，结合公司的业务需要，面向研发同学的一款集压测流程管控，压测任务管理、自动化性能基线为一体的一站式压测平台。产生背景时间成本：单次压测临时申请施压机，增加时间成本和金钱成本。且多次压测采用不同的环境压测，结果不具有对比性。数据成本：脚本、测试数据、压测机器、测试报告无法沉淀流程带来的风险成本：生产压测缺乏平台流程管控，无管控的线上测试是一个非常有风险的操作。自动化问题：自动化性能基线无统一平台支撑基于这些因素，随着大家对压测诉求的逐步增多，我们决定推进压测的平台化建设。这篇我们主要介绍压测平台的建设和实践。业务架构：重点功能介绍：生产压测流程管控模块压测流程管控流程图：通过以上流程操作，做到生产压测有审核、实施有通知、结果透明化。压测管理模块实现脚本、参数文件、报告数据的汇总。压测时可结合公司监控系统查看被压机器指标。在线脚本编辑模块说明：提取出压测实施过程中经常变动的参数，支持常用参数的实时修改。通过动态调整以上参数，达到以下效果：1）随时调整压测并发及压测时长。2）随机变化压测参数文件3）控制不同取样器的压测速率及压测比例4）支持梯度压测模式5）随时调整压测机器等等共享压测机器模块支持了K8S节点和固定虚拟机两种模式。随时新增和删除压测节点新增节点示意图：自动化性能基线模块敏捷开发流程的特点是小步快走，快速试错，迭代周期短，需求变化频繁。很难定义完善的性能测试目标，也没有时间在每个迭代开展详细的性能测试，可以通过建立性能基线，通过比较每次迭代中的性能表现变化，判断迭代是否达到了目标。性能基线结果展示：基线的结果分为三块数据：1）应用指标数据2）机器的负载表现数据3）若接口为异步接口，则还有队列的关键指标数据。1）应用指标数据

前言你是否和我一样遇到过以下的问题？1）服务重构，一堆接口需要回归，让人头疼2）每次迭代，都要花很多精力来进行回归测试3）线上bug，线下复现不了4）接口自动化用例写辛苦，维护更辛苦…