我的E家

文化属性与命运的因果关系，传播强势文化的逻辑、道德、价值观；

增量覆盖率，应作为可选指标，对测试准出有帮助就用，无用甚至有妨碍时，不用即可

长链路 + 跨部门业务下，如何保障链路稳定性

QA能像研发一样改动业务代码吗？如果改动代码， 风险如何控制？

定时任务通常因为执行周期长、逻辑复杂、业务限制、涉及第三方等导致测试麻烦且效率低下，想知道联盟是如何通过链路解耦来实现业务线内[随时测试]、[快速测试]、[多次测试]吗？来一起看下广告联盟的实践与经验。 大家有更多保障手段与经验，也欢迎一起讨论与交流。

作为QA，在对业务代码的理解上越深越好。这里自己有一个原则： 除了业务代码本身不是QA写的外，QA最好直接关于业务代码的一切。

没有因为自测需求引发的线上问题纳入自测的需求，业务风险及改动量、涉及自测场景 少且简单QA根据需求改动，对自测需求进行不同程度的介入： 100%自测、研发自测+QA CR代码 、研发自测+ QA准备用例、研发自测+ QA回归测试。

业内常见的单元测试做的很重，导致编写&维护成本很大，整体落地ROI不高，最终导致团队成员落地意愿不高。 比如，需求一改，对应的单元测试的代码也得改，容易导致最后写单元测试的工作量比开发的工作量还要大。 那么能不能对单元测试进行“瘦身”，让单测的ROI高起来呢？ ...

一、可测性改造的目的项目测试过程中，不同的测试深度、测试广度，会面临不同程度的“不便”。比如，联盟有不少作为kafka的consumer消费方，由于线下上游业务线没有丰富的流量，或者压根没有流量，多数情况下，上游业务线不涉及改动。由于各个业务线的业务复杂度不同，技术实现不同，历史包袱也不同，那么在保持"原生态实现"，不进行任何改造的情况下，面临的测试难点和痛点也会非常不同。2）上下文代码逻辑(上面逻辑，下面逻辑)，涉及全量数据的加工处理，离线在线数据的diff等等，十分耗时，但本身未涉及改动。...

可测性改造(CR后，评估使用哪种改造方式，改造的整体方案；比如，生成0-24点数据，0-9点数据是异常的，其他时间点是正常的，由于0-9点大多非集成测试时间，可能会遗漏。例子调用第三方接口或核心交互处未添加try/catch异常处理，导致一旦报错，阻塞掉后续所有处理。方法1未正常给某个key赋值，方法2获取了该值，导致逻辑处理异常；例子大型定时任务，生成0-24点数据，某些时刻数据有问题。比如，整个逻辑，不会生成0点时刻的数据。提测前，研发之间的CR更加侧重关注机器解决不了的问题。...

如何巧借测试左移，来最大化QA的价值？

目录一、数据质量常见问题二、数据的最终用途三、数据需求/数据业务的几个目标四、数据质量的几个层次根据个人日常数据测试经验和体会，浅谈对数据质量的理解。其中不免有偏颇之处，欢迎大家一起讨论与交流。一、数据质量常见问题1)数据缺失：业务看报表，发现某一天的成交gmv暴跌，经过排查发现，是当天的数据缺失。2)第三方异常：某指标一直等于0、数据产出延迟3）数据错误：系统故障引发数据错误4）数据口径问题：由于口径不一致导致最终数值不一致，即用户在不同入口看到同一个数据指标有不同

①数据生产链路数据生产分成两部分：第一部分：离线数据生产。常见实现方案：1、若干互相依赖的大任务；2、每个大任务负责数据清洗、加工、处理；3、大任务将处理后数据落宽表，以供后续任务处理第二部分：实时数据生产。常见实现方案：1、从上游获取海量实时数据流；2、自身业务内快速完成数据流处理；3、将数据流转发出去；②各类报表数据常见报表如：1、实时数据类报表，如小时报表2、离线数据类报表，如 T-1类报表3、分析预测类报表常见实现方案：业务实现

一、大数据业务分类可分为2类:①、大数据应用隶属于业务线。可以理解为它输出的各种报表数据，会直达客户或用户。所有数据带着强烈的业务属性，属于业务层。②、大数据平台可以理解为它属于中台层/数据仓库，没有自己的业务， 或者说他的业务就是提供算力去支撑客户的业务。也就是大数据平台类的产品提供的是一些原始算力， 用户需要调用这些算力来满足他们的业务。一般大公司还会有基础架构组，大致如图所示：二、离线数据构造①、数据应用下的数据构造需求...

那些心有戚戚焉的经验： 诊断工具 调试用户问题效率，弥补开发人员所需的技术数据， 和普通用户反馈问题直接的鸿沟： 收集特定信息--》分析用户操作--》用户授权同意后(保护用户隐私信息)--》分析数据发送给合适的开发人员(客户支持团队)加速问题解决。 打上beta后，快速对外发布 一个产品的基本核心功能实现后，立刻对外发布使用，从用户那里得到真实反馈。单元测试测试开发工程师，一个开发角色，编写需求mock和fake工具，同时在开发人员不知道哪些地方需要单元测试的时候可以明确指出

不久前，公司邀请外企大厂经验的大佬，分享Google的经验，本人特意问了一个问题：日常需求项目中，功能测试(测试用例的准备、执行)、性能测试等等，QA人员会参与执行吗？大佬回答：不会。是开发人员的工作几点自己的思考：Google能把这个质量是研发活动的一部分，彻底贯彻执行下去，需要从上到下的强大执行力。 国内的大小厂，据本人有限的所见所闻来说， 没有全部由开发人员编写用例、执行用例的实践 其实国内，开发和测试很大程度是2个团队负责，隔离开的。测试时 开发活动的下一个节点，...

这点自己比较认同，无论是团队何种角色(产品同学、研发同学、QA同学、UI同学等等)， 对于一个尚未熟悉的新系统，首先需要弄清楚什么是最重要的业务点，关注点最需要放在哪里：

一、背景伟大的数学家雅迪也经常说一句话：反过来想，总是反过来想。 1986年6月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让人振聋发聩。在毕业典礼上，芒格没有告诉即将毕业的同学如何得到幸福，而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦，那么我们就可以最大程度上的去避免它。 同样地，这里按照逆向思维的思考方式，在互联网软件行业中，探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...

一、背景伟大的数学家雅迪也经常说一句话：反过来想，总是反过来想。 1986年6月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让人振聋发聩。在毕业典礼上，芒格没有告诉即将毕业的同学如何得到幸福，而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦，那么我们就可以最大程度上的去避免它。 同样地，这里按照逆向思维的思考方式，在互联网软件行业中，探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...

一、背景 伟大的数学家雅迪也经常说一句话：反过来想，总是反过来想。 1986年6月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让人振聋发聩。在毕业典礼上，芒格没有告诉即将毕业的同学如何得到幸福，而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦，那么我们就可以最大程度上的去避免它。 同样地，这里按照逆向思维的思考方式，在互联网软件行业中，探探自己对”怎样才能让需求无法如期顺利上线“ 的一些感悟和思考。...

目录一、背景二、开发阶段能做的事情1、以下情况，也千万别写技术方案2、技术实现方案千万别和 下游业务线同学、本业务线QA沟通3、API接口文档有修改时，千万别和 前端同学说4、在不熟悉现有代码实现的情况下，请直接接动手改5、代码编写完，千万别做什么单测，自测，上下游业务线联调测试6、影响团队其他角色时，请不要提前周知到人7、影响需求实现的点，不要提前通知QA,产品 给他们来个措手不及8、和其他业务线有交互逻辑时，千万不能让对方100%了解自己的技术实现及交互逻辑9

目录一、背景二、需求阶段能做的事情1、需求文档描述要尽可能粗2、不要考虑需求完整度，如不用考虑下游业务线3、不用考虑需求的可行性4、需求评审一定要快5、需求评审后要尽可能多需求变动6、将可以放到一个需求中实现的改动，尽可能多做拆分，增加改动频繁度和并发度三、写在最后一、背景伟大的数学家雅迪也经常说一句话：反过来想，总是反过来想。 1986年6月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让...

目录一、背景二、让需求无法如期上线的整体策略一、背景伟大的数学家雅迪也经常说一句话：反过来想，总是反过来想。1986年6月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让人振聋发聩。在毕业典礼上，芒格没有告诉即将毕业的同学如何得到幸福，而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦，那么我们就可以最大程度上的去避免它。 同样地，这里按照逆向思维的思考方式，在互联网软件行业中，探探自己对”...

目录一、前言二、技术方案评审到底要不要做1、 主动型团队2、 被动型团队三、无技术方案评审对QA同学意味着什么四、 当开发团队没有技术方案评审时怎么办1、线下与对应开发同学沟通2、QA个人梳理技术实现细节,来自我提升3、不要强推开发团队统一进行技术方案评审写在最后一、前言之前写过一篇博文技术视角——团队如何更好的合作，打造高质量团队。 这里的团队成员，其实是默认都是可以独当一面，可以相互补位的。 但“林子大了，什么鸟都有”， 随着与越来越多的团队合作， 会发.

目录背景作为候选人经验1：事先电话尽可能多确认职位方向与自己的匹配度经验2：尽可能争取先电话面试一轮，初步确认与面试官匹配度经验3：避免陷入面试官的思路，而无法展示自己的亮点经验4：避免陷入与面试官关于“术”的争论之中作为面试官经验1：为尽快评估候选人是否与职位需求匹配，应该先电话/视频沟通一下。经验2： 根据职位要求，精心准备面试题目经验3：尽可能多根据简历+候选人自身介绍有针对性沟通经验4：避免陷入与候选人关于“术”的争论之中背景 毕...

目录一、什么是敏捷二、敏捷团队项目举例感受到的优点三、敏捷的误区1、 与 质量的关系2、 缺陷的处理3、 项目过程文档4、 团队成员合作方式5、 敏捷适用范围6、 质量意识方面7、 安全生产方面四、个人经验：敏捷最让人满意的点五、是不是只有实行敏捷，才能高效呢一、什么是敏捷理论派角度看，敏捷宣言强调的敏捷软件开发的四个核心价值是：个体和互动高于流程和工具工作的软件高于详尽的文档客户合作高于合同谈判响应变化高于遵循计划个人理解：1）敏

目录前言一、代码实现类bug的危害1、 对于项目而言2、对于产品而言3、对于项目成员而言二、代码实现类bug隐藏的价值三、可以带着缺陷上线吗？四、 缺陷与质量关系前言缺陷的根本的原因很多，代码实现、需求原因、体验问题、环境问题、脏数据、测试人员操作问题、外部第三方系统报错... 在一个大型项目中，通常代码实现类bug会比较多，上线后直接导致线上故障的，大概率也是 代码实现问题。 所以这里以【代码实现类bug】为例， 一起探讨下bug的价值。bug给项目本身带来的.

背景 要说QA同学经常比较苦恼的一件事，莫过于提测质量了。 因为提测质量的好坏，大大影响了测试质量、以及需要的测试时间、风险控制等。举个例子：业务A提测质量极差，主流程都不通。这个时候，QA通常的做法是执行提测打回流程，让开发同学继续自测； 硬着头皮不打回，边催促开发同学修复bug,边继续测试。 但无论QA同学怎么做，提测质量差已经成为事实了，这是任...

全量技术重构背景质量保障方案历史包袱

目录1、原始阶段： 服务端单接口测试2、配置化阶段： web配置化自动化接口测试平台3、专项测试阶段：专项业务痛点4、测试服务化阶段：测试工具服务化5、测试大集成平台：测试大集成平台[纵向业务域]自动化实现优劣评价——以ROI为导向下的自动化评价指标[横向平台]平台价值评价1、原始阶段： 服务端单接口测试普遍采用的是Maven+Java+TestNg框架。 运行方式：testng执行方式 ...

目录一、引流测试的优点二、边界三、天生缺陷四、核心问题五、业务适用性分析写在最后一、引流测试的优点线上海量的用户真实数据的特点：海量丰富多样二、边界1、 不常用的用户场景， 无法保证100%覆盖到，甚至极有可能无法覆盖到。 比如， TOB类产品， 某个操作不是必需的2、重复的流量，无疑增大了很多“冗余”量3、用户数据， 可能存在一些噪声数据，需要去噪；4、完全随机的取线上用户场景， 很大概率会造成场景的侧重， 需要有针对性的筛选、过滤三、天生缺

一、智能调度1、含义智能调度，目标是解决资源最优使用问题。将需求和可用资源进行最优匹配，以求达到资源利用的最优化。常见例子：外卖骑手接单、抢单；滴滴司机接单、抢单。以滴滴司机接单、抢单为例，目标是解决的是司机和乘客的匹配：1）司机侧： 达到资源利用最优化。 比如，离乘客距离，交通阻塞情况2）乘客侧：达到资源利用最优化。 比如，满足呼叫车型前提下尽可能减少等待时间3）平台侧： 达到资源利用最优化。 (个人猜想)比如， 司机经验，已接单数，好评等等。不能让司机一直接不到单；平台.

https://www.atatech.org/articles/128284

目录一、面临的数据问题二、自动化数据清理方案规划1、自动化定时清理2、人工清理三、数据清理闭环思考四、实战-仓储数据清理方案1、清理方案概述2、清理方案实现一、面临的数据问题根本原因：未完结的数据量过多，直接阻塞或影响正常的业务测试。问题描述：操作timeout或根本无法操作二、自动化数据清理方案规划数据日常清理需要满足如下需求：1、自动化定时清理针对日常新增的未完结数据， 需要定时清理；但清理时，需要重点考虑如下问题：1）数据清理...

一、前言测试用例，可以说是质量的保障中最关键的一环。 测试用例中没有的内容，可以说99%的情况下后续测试执行的时候，不会覆盖。当然不排除某些情况下，突发灵感，想起某些测试场景， 并将其加入测试用例中。但这是概率事件，非必然事件。测试用例——广发意义上的，无论谁执行；典型测试用例的用途： 无论谁在编写测试用例(新手、老手、哪怕是开发同学)，保障测试用例的场景覆盖二、测试用例准备的难点说起难点， 不妨看下以下测试用例的套路：需求上x1需求点——对应几条测试用例；需求上x2需求点——.

目录一、引言二、稳定性因素分析1、技术实现技术实现-DB依赖技术实现-RPC接口技术实现-缓存技术实现-消息技术实现-定时任务技术实现-开关技术实现-监控技术实现-灰度2、暴露手段暴露手段-测试广度&深度暴露手段-提升效率暴露手段-质量闭环暴露手段-提升质量思维3、应急响应4、流程机制三、系统自检一、引言确保系统的稳定性，可以说是所有高质量产品都应该保证的。换句话说， 一个经常由于产品本身不稳定，而影响用户体验.

vff

https://www.atatech.org/articles/113934https://www.atatech.org/articles/138824质量的狭义定义；广义定义；质量就是软件与“需求”相一致的程度。这里的需求，包含“明确的需求”和“隐含的需求”。明确的需求，一般以业务需求PRD为主。隐含的需求，这里指符合行业标准的质量特性，如，健壮性、安全性、可测试性、可维护性等。这里有个问题：如果 需求本身就是有问题的， 那么即便 软件与需求100%一致，也无法达到想要的质...

目录一、必要信息周知 [到] 相关影响人二、互相补位，互相赋能三、高质量心态做产品写在最后一、必要信息周知 [到] 相关影响人要点：必须周知[到] ： 你通知了别人，确保别人也GET到你的点了反面例子：针对十分复杂的问题，群里 @所有人，用及时消息做繁琐的文字性描述。正面例子：针对十分复杂的问题，1、当面沟通，并收到了相关人的反馈；2、书面性(如邮件/在线系统) 做鸡柳需要周知[到]的信息类型各种各样， 通常来说，如果一个信息，影响/干扰到了其他人的工作，均需要做周知

前言之前的一篇技术视角——从日常产品需求看产品研发周期管理中说过核心观点：团队中的各个角色(业务/产品/研发/QA/运营...)不是为彼此工作，而是要通过合作，打造一款具有强大竞争力的产品。此篇还是以这个核心观点作为出发点，但想站在QA的角度， 来讨论一下 作为整个产品研发周期中，相对工作比较靠后的角色，如何发挥对产品的最大价值。关系 产品在行业/市场中的竞争力的几个因素1、能否真正解决用户问题——需求层面需要解决的问题2、能否先用竞争对手快速给到使用——产品的端到端交付效...