我的E家

测试人员的价值是什么——你好刀用在刀刃上了吗？

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

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

ISO9126 软件质量模型是评价软件质量的国际标准，由6个特性和27个子特性组成。互联网行业，ISO 9126作为一个指导性的质量模型，它会确保质量不会有方向性的大纰漏。无论是开发还是测试，无论是各端质量还是服务质量，质量上的大方向不会跳出9126的模型。...

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

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

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

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

引言流程平台——从测试角度看code review_多则惑少则明的博客-CSDN博客直接bug;异常处理问题；可测性改造(CR后，评估使用哪种改造方式，改造的整体方案； )；技术设计: 写死的逻辑；出问题时无法验证；打点监控；核心日志(如链路与第三方交互；出现问题时方便排查；)...

目录原则1： T-1范围内的统计指标统计，提前规避潜在的性能问题原则2： 严重依赖第三方数据源的核心预估收入类数据，需要快速止血原则3： 考虑存量数据量级，提前规避潜在边界/性能/处理速度/数据倾斜问题原则4：评估数据质量检测，提前检测到异常数据并做异常处理原则5：评估技术实现与业务需求的匹配度原则6：评估技术实现可扩展性实现原则7： 评估当前技术实现下是否存在可测性问题大数据技术方案评审，提前规避问题：原则1： T-1范围内的统计指标统计，提前规避潜在的性能问题

目录基建-环境1、链路特别长，且由不同团队负责2、线下数据流： 第三方上游无数据流3、链路加工的复杂4、数据正确性校验(数据加工、数据报表)5、可测性改造与易测性改造6、 线上质量卡点7、监控体系8、数据质量衡量基建-环境1）数据目前共有两套环境：staging 和预上线环境： 用于测试联调和自测（与线上隔离）2）稳定性维护： 随时可自测/联调/集成测试3) 数据量级： 存量数据尽可能同线上(如，风险允许下，可直接读取线上数据)1、链路特别长

那些心有戚戚焉的经验： 诊断工具 调试用户问题效率，弥补开发人员所需的技术数据， 和普通用户反馈问题直接的鸿沟： 收集特定信息--》分析用户操作--》用户授权同意后(保护用户隐私信息)--》分析数据发送给合适的开发人员(客户支持团队)加速问题解决。 打上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月，查理·芒格在哈佛学校的毕业典礼上做了一场演讲，虽然内容短小，但是所用的修辞手法却让人振聋发聩。在毕业典礼上，芒格没有告诉即将毕业的同学如何得到幸福，而是告诉他们如何保证过上痛苦的生活。如果知道这些方法会带来痛苦，那么我们就可以最大程度上的去避免它。 同样地，这里按照逆向思维的思考方式，在互联网软件行业中，探探自己对”...

目录一、什么是用户体验测试(UAT)二、UAT进行的时机三、参与UAT的成员四、UAT的目标五、测试人员能否找到用户体验方面的bug?六、用户体验问题的几种典型形式一、什么是用户体验测试(UAT)在将产品交付客户之前处于用户角度进行的一系列体验使用，如：界面是否友好、操作是否流畅、功能是否达到用户使用要求等二、UAT进行的时机实际项目中，一般来说，UAT是在 测试人员完成测试之后，产品正式发布线上之前。 当然，个别特殊情况，可能在测试尾声的时候。三、参与UAT的.

从维基百科的定义也不难看出 CR 目的：找出缺陷，提升代码质量，降低修复成本团队协作，知识共享，提升开发者技术希望尽早的code review，尽量降低“返工”的代价谷歌在Code Review方面执行的很好，尽管谷歌的工程师的平均研发水平都很高，但你会发现，只要是提交Review的代码，照样会有很多comment（修改意见）。即便自己觉得足够牛逼的代码，只要经过不停的推敲，都是有持续改进的空间的。只要对技术有追求的团队，就不能把开发当成外包：只要代码可以运行就提交，黑盒狠命测一把，验出b

目录背景作为候选人经验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、巨大的全链路联调成本3、整体加大 研发难度4、整体加大测试难度5、技术重构、架构升级、融合时业务场景梳理难度大6、整体项目时间跨度大，引入不可控风险巨多一、背景之前写过测试创新——长链路+复杂业务下的自动化测试痛点与难点， 接下来，将介绍下在长链路+复杂业务下， 需要跨多个团队协作的业务在的自动化测试痛点与难点。跨多个团队协作项目的整体特点：1、通常涉及若干个(>=2)域一起协同作业。例如，长链...

引言之前聊过关于故障的一些感悟：故障的坑,你踩了多少遍、如何减少线上故障、典型故障分析、从稳定性保障角度看故障演练。其实关于故障的讨论，需要先达成几点共识：故障不可能长期100%避免；故障的产生是团队中各角色都”恰巧不正确作为“才出现的。 即，各角色任何一方在线下识别出此问题，就不会引发线上故障；除了思考如果尽可能避免故障，还应该建立一套故障发现、快速恢复机制线下任何一个阶段的工作不到位，都会给故障的产生提供温床为了便于讨论， 下文中的故障讨论，会变成线下bug的讨论。故障.

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

质量sense ， 是团队成员 都必须要具有的，成员之间需要互为backup, 任何一方“过弱”，都会把质量压力抛给其他方，最终都会面临很多质量风险。需求质量sense这个至关重要， 不好的需求质量的例子：十几个人员拼命加班几周，“赶时间”做出的新功能，上了线，结果boss一句话，下掉了。对于某个功能点，上次迭代改成了A， 这次迭代改成了B，还不知道以后还要不要改。。。需求提给了团队A， 经历需求评审、代码code后，提测了，结果发现需求实现不符合预期，应该提给团队B；若干页的需求文

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

目录一、目标与能力目标需要的能力二、境界之前的博文：《从菜鸟到测试架构师一个测试工程师的成长日记》笔记与思考一、目标与能力目标测什么 怎么测 拿结果1、测试方案设计测试的深度和广度是什么 测试的重点和难点是什么2、技术方案设计工具平台开发3、高可用的产品方案理解测试的本质 能用技术手段解决产品问题需要的能力要有业务理解广度，也要有技术...

目录一、稳定性保障的三个层面二、故障演练目的三、如何选择故障演练场景1、分析历史年限上的故障2、系统强弱依赖分析3、核心中间件异常分析四、故障演练的环境五、演练的风险控制感悟一、稳定性保障的三个层面稳定性保障有三个层面：1、常态下的稳定性(功能稳定性,通常功能测试覆盖)；2、高压下的稳定性(通过性能测试覆盖)；3、异常时的稳定性(通过故障演练...

最近参加了一个测试大会，会上各种自动化、性能、新型测试方法扑面而来。听后确实思路有所开阔，但又不禁想：为什么类似的分享/大会几乎很少有人专门讲测试思维、测试本质之类的思想。各个公司，各个业务，几乎都有相似的测试方法，而不同的是具体的测试实施、以及不同业务实现的测试；各个测试人员由于经验，眼界的不同，对测试的理解也不一。故而这里，想来说说脱离于具体测试任务之外的测试思想/测试本质的一些...

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

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