我的E家

目录一、前言二、技术方案评审到底要不要做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、能否先用竞争对手快速给到使用——产品的端到端交付效...

目录前言一、核心观点二、日常 产品需求 面临的几大问题三、需求质量的反面例子四、可选解决方案1、项目价值走关卡2、项目管理机制3、迭代管理线上化前言如果你是一位技术人员(研发人员、QA), 每天面临的就是源源不断的产品需求。但除了做了本职工作(产品的技术实现，质量保障)外， 哪些数据可以体现自己作为某种角色对于产品的价值呢？比如，作为研发人员/QA， 产品因为有你而有了什么不同呢？ 如果你的工作仅仅局限于本职工作，那么你的可替代性就非常强。 举个例子：作为一.

一、引言从自动化方案整体设计角度，谈谈自动化的架构设计。二、自动化测试的范围狭义理解<!-- https://mvnrepository.com/artifact/dom4j/dom4j --> <dependency> <groupId>dom4j</groupId> <artifactId>dom4j</artifactId> &...

环境复杂度一直都非常高，要进行彻底解决也不是一朝一夕的事情，而且需要长期运作需要看两个数据：1是调用是否成功，2是调用是否拿到正确结果而我们在S1具体聚焦的还是第一个点，调用是否成功，因为这是第二个点的前提条件https://www.atatech.org/articles/124020什么是测试环境优劣 当有人问你什么是好用的测试环境？你怎么回答? 你可能...

业务实现频繁变动专门对业务实现代码， 为了测试，做改造。 例子 ， 异步转成同步使用底层服务接口。 接口A 变动了， 必须变动使用不被业务使用的接口。 接口下线，被改， 不再维护了使用太多临时数据使用公共数据过度依赖太多开关不稳定的原罪要归结于： 自动化同学对自动化测试架构设计的力有未逮。如果但从效率提升方面，可能能起到作用， 但一旦从稳定性方面来评估整体的自动化效果， 类似的自动化测试方案设计就显得”相形见绌“了。用个不...

什么是端到端自动化实现web前端/APP/小程序直接调用的服务端接口。常见形式L:HTTP(S)对于后端自动化来说， 是集成程度最高的自动化实现形式，也是最有bug发现价值的自动化实现形式端到端自动化实现难点接口的入参如何快速代码表达；接口如何串联起来；举例：http://xxx?入参： json串出参： json串一个接口如何表达对于每个接口而言：1）拼接入参2）执行3）解析出参(供后续接口获取)1、 fastjson 实现 入参、出..

线下测试活动ps： 想象两种极端的质量活动：第一种： 90%时间放到基础的功能业务需求层面的测试；10%时间放到其他更高层面的质量活动上(性能、稳定性、问题定位等等)显而易见的结论： 研发质量差第二种：10%时间放到基础的功能业务需求层面的测试； 90%时间放到其他更高层面的质量活动上(性能、稳定性、问题定位等等)结论：研发质量极高 更进一步，基础的功能业务需求层面 ， 压根不需要专门的测试同学跟进，直接由业务/产品同学把控。线上测试活动一般来说，线上测试，一般有几个目的：.

目录一、什么是出口消息报文二、测试需求三、出口消息报文，人工如何测试的四、出口消息报文，自动化测试五、总结一、什么是出口消息报文业务A，业务B，属于不同域，甚至不同事业部。 业务A 会给业务B发消息，消息的内容格式有json串，xml格式等等。 此时的消息内容称之为 消息报文。 对于业务A来说，是消息报文发送方，故而对于业务A来说，改消息内容称之为 出口消息报文。二、测试需求对于业务A来说，由于业务需求、技术重构等等原因，需要回归测试、或业务测试 此段 消息报文 有无被“

目录一、背景二、测试人员的时间都花在了哪里三、测试人员突破边界的几个方向四、写在最后一、背景 无论什么角色(开发、产品、测试、运营等等)，说起拓宽自己的边界，可能大多数理解都是：做自己本职工作外的事情；而且要自己本职工作的工作量不太多的情况下，因为大多数同学的工作日常就是：低效/重复的工作太多，累到吐血，忙的要死，哪有时间来做本职工作外的事情。 其实，拓宽自己的边界，自己的理解：1、并非100%去做本职工作外的事情，一定是在...

目录一、为什么需要验证测试的有效性？2、 测试有效性度量的方法有哪些？3、 变异测试4、如何往代码注入变异5、变异与业务6、 总结一、为什么需要验证测试的有效性？ 测试工作，从技术角度看，可以理解为是验证技术实现的有效性。 如果技术实现符合业务需求，则技术实现是有效的，否则技术实现是无效的，换句话说，就是通常意义上说的代码存在bug。 那么测试工作可以验证技术实现的有效性， 但是存在一种情况： 如果测试工作有500+自动...

目录一、背景二、配置类规则的常见线上测试方法1、线上配置后，运营同学/测试同学做专门验证，看在线上是否正常2、 层层审批3、自动化巡检三、设置配置检查卡点四、总结一、背景 典型的电商类、金融类、视频类需求， 往往伴随着各种各样的运营活动配置， 各种各样的营销活动纷纷上线， 运营同学 改了又改，可能因为如下原因，导致规则实际并没有在线上生效：1. 运营人员手抖配置错了，完全不自知2、 体验问题，比如活动过期，还在线上3. 系统配置被误用，实际并...

前言 接触越来越多的团队后，发现无论是QA人员的绩效考核、晋升，还是平时的交流，越来越少的人明确从整体来评估产品质量(ps:这里产品质量-包括需求质量，开发质量，测试质量，上线质量，运营质量等)的提升情况了，更别说测试质量的整体情况了。就拿QA人员来说，除了“天花乱坠”的说自己的自动化、持续集成、测试难题的解决等等话题外，很少从上帝的眼光，来评估整体测试质量的情况了。...

目录如何判断自动化测试方案的优劣？1、对测试效率的提升2、对测试覆盖度的提升3、测试效果上4、测试发现问题后的解决效率5、自动化方案对整体测试方案的补充程度如何判断自动化测试方案的优劣？1、对测试效率的提升测试时间的节省 测试脚本的运行时间/速度/并发度 测试脚本的维护成本(通常涉及自动化框架/平台的开发维护)2、对测试覆盖度的提升代码覆盖率/分支覆盖...

背景项目测试过程中，不同的测试深度、测试广度，会面临不同程度的“不便”。例如：复杂的技术架构、技术实现，导致某些场景不可测或不容易测试。无法满足自动化/质量运营要求。例如，技术实现中，异步流程过于复杂，导致自动化不易开展某些场景/实现严重影响了测试效率，或给测试增加了不少困难。同步的自动化测试过程：目前大部分的自动化测试用例的过程： 创建业务场景---产生待测数据-》检查待...

测试领域的叫法测试，QA， 质量保障团队，质量团队等等避免歧义与争议，叫法不同，但做的事情，属于不同的深度和广度：很多是别人玩剩下的；还有就是，统一的一件事，不同玩家效果会产生很大不同。 拿自动化来说，现在随便拎出来一个测试同学，哪怕是纯功能测试的，都不会说没做自动化。 但拿做的比较好的来说，拿自动化效果来说，恐怕很多团队都会啪啪打脸。 根本原因： 没有真正理解自动化测试的本质，不...

目录摘要译文内容缺少测试用例缺少功能测试错误或不正确异常处理后续测试步骤摘要许多人将100％的单元测试覆盖率等同于高代码质量，但这还不够。 代码覆盖率工具仅衡量测试是否执行代码； 他们对测试的有效性没有判断力。 测试人员应审查单元测试，即使它们具有较高的覆盖率，也可以帮助改进测试或在必要时补充额外的测试。译文内容当开发人员进行的单元测试中100％覆盖我们...

目录个人看法摘要译文内容了解您的用户可视化KPI指标将测试优先级化观察回归设置警报使用模板调查问题量化bug的重要性对团队实施监控个人看法要想交付高可用的产品，最重要的是了解产品，从而制定整体的测试方案/测试策略。比如，什么是对用户最重要需要。更加贴近用户：量化你的用户如何使用产品。摘要监视使您的测试工作更加轻松，帮助您管理可能存在的...

目录个人理解摘要译文内容减少系统测试中的bug缩短错误处理时间提高测试效率减少测试用例寻找更多人选择你的战斗个人理解将测试周期缩短，不同团队应该根据实际情况，侧重不同的落脚点。 比如，一个处于疯狂迭代期的初级产品，和一个处于成熟期的维护性产品，测试人员的落脚点显然不同。又比如，合作的，一个是提测质量相对较差的团队，另一个是提测质量相对好的团队，测试人员的...

目录个人理解译文内容信息丢失信息控制更好的信息交流个人理解测试人员通常被认为是项目的最后一把控制屏障，发现bug(这里bug是从宏观层面来说得，是指影响用户体验、易用性方面的问题，以交付高可用产品为目标下，发现的种种问题或潜在风险)后，大多数情况下，开发人员会修复其中的绝大多数问题；在于业务人员、产品人员沟通中，往往会将一些问题，定为延期修复，或由于不存在某些业务场景，...

摘要许多测试人员倾向于将测试时记录的信息最小化。 当以后发现问题时（可能是在软件投入生产后），挑战就来了。 我们如何记起自己的所作所为，何时？ 我们必须参考哪些记录？ 作为测试人员，我们如何回答“如何测试？”的问题内容许多测试人员，特别是在制定详细的测试说明时，往往会尽量减少他们在测试时记录的信息。 从记录变量或值的起始值和结束值到简单地指出测试“通过”，这可能会有所不同。当以后发现问...

摘要当人们没有做好自动化的时候，这几乎不是因为所使用的工具，而是几乎总是因为错误的自动化策略，错误的期望以及错误的自动化采用。 自动化工具只能回答自动化的“方式”，而拥有自动化策略则可以回答谁，何时何地，什么以及为什么。 这就是为什么拥有测试自动化策略如此重要的原因。个人感悟： 自动化工具是皮，自动化策略才是真正的灵魂内容自动化测试与软件编程本身一样古老，但是许多公司和团队在其工作...

目录摘要内容数据类型数据质量数据收集数据存取维护摘要关于我们生成的用于评估产品质量的数据，已有很多出版物发表。 很少有关于数据测试人员为自己使用而生成的讨论可以帮助我们改善工作的讨论，而关于数据收集的推荐做法的讨论则更少。 测试数据收集，管理并使用所有功能进行前期计划和持续维护。 测试人员可以通过以下方式改进这些做法。内容可以肯定地说，所有测试人员有时都...

目录摘要内容摘要测试自动化的最佳实践强调可靠性，可移植性，可重用性，可读性，可维护性等。 但是您现有的自动化测试套件如何实现这些特征的？ 您应该使用当前的测试解决这些问题，还是创建一套全新的测试？ 以下是一些问题，可以帮助您确定测试自动化维护程序是否按预期方式运行。内容“自动化”在业界并不是一个新的流行语。 随着电子商务的发展和对移动技术的快速访问，一段时间以来，尽快交付软...

目录一、简介奶酪是什么二、假定变化三、拥抱变化一、简介两只小老鼠“嗅嗅”、“匆匆”和两个小矮人“哼哼”、“唧唧”，他们生活在一个迷宫里，奶酪是他们要追寻的东西。有一天，他们同时发现了一个储量丰富的奶酪仓库，便在其周围构筑起自己的幸福生活。很久之后的某天，奶酪突然不见了。这个突如其来的变化使他们的心态暴露无疑：嗅嗅，匆匆随变化而动，立刻穿上始终挂在脖子上的鞋子，开始...