我的E家

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

目录前言自动化整体方案不合理的证据自动化整体方案不合理的几个原因写在最后前言 一直以来，测试团队都面临一个迫在眉睫的问题：自动化测试收效甚微，甚至被认为是”为了实现自动化而自动化“。之前写过一篇博客自动化测试的评价维度，其实自动化的评价不乏有其他的评价指标。但这里想说的一点是，自动化方案产出低的一个重要原因是自动化整体方案的不合理。下面根据自己的经...

一、前言比较成熟的项目质量方案中，往往会有稳定性建设，其大概包括几个部分：全链路压测。模拟线上场景，来暴露稳定性方面的问题 故障演练。根据强弱依赖，模拟线上出问题的场景，来暴露稳定性方面的问题 预案演练。一般有以下目标：1、模拟线上出问题时，实现快速恢复线上的目标;2、为了确保100%稳定性的场景，例如，大促等，对某些实现准备一些backup方案，确保大促期间的业务稳定性。有了...

目录面临问题方法论数据支撑质量[一段时间内]有多少次需求变动、插入需求、紧急需求上线、hotfix[一段时间内]有多少需求、上线、回滚[每次迭代]各个节点出现了多少问题[一段时间内]线下bug数据(严重级别、根源、修复周期等等)[一段时间内]线上bug数据(严重级别、根源、修复周期等等)面临问题月末、季度末、年末，为了用数据来”证明“自己的成绩，于是不得不到...

目录背景测试数据引发的问题测试数据准备目标测试数据准备实战背景 无论是大数据项目、分布式项目、抑或是常见的电商、广告等等业务，几乎都会面临不同程度的脏数据问题。脏数据的来源多种多样，主要的几个来源：上游业务问题，直接把脏数据同步过来了 代码问题，导致直接存储了脏数据。 数据修改引发的脏数据。比如，QA同学为了创造某个场景，直接修改了数据库，但并未...

接口自动化测试的“能“1. 接口自动化的目标用于项目的API层的http接口的功能逻辑验证：减少手工测试的工作（回归验证；跨模块的验证）；实现手工验证不能做的验证（如接口涉及大量数据的排序比较）手工很难充分验证的功能逻辑（如接口的功能验证涉及大量的数据）2. 接口自动化case用例设计原则切记：不要为了做自动化而做自动化，做的首要目标是问题出现时，能

1. 数据报表类项目需求特点： 后端: 专门和DB数据库打交道，负责更新数据入库，从库中取出数据，通过各种公式/汇总维度，对数据汇总，并提供HTTP接口；前端: 从http接口拿数据， 以图表的形式展示2. 各个角色需要做的评估需求文档的评审需求评审阶段，需求文档需要包括：1）必须提供各个指标详细的计算公式，汇总维度，以及 各种 特殊情况的考虑； 提供具体的例子

根本目标测试环境中，保证新增接口功能正确性，原有接口的回归（保证原有接口不被修改“坏”）；生产环境中，保证接口层面服务可用，功能的正确性（保证服务挂掉时，及时发现）接口自动化功能正确性保证(第一阶段)该阶段主要是保证功能提供的正确性。所谓正确性，是指返回的数据正确，功能正确。  阶段特点：对接口进行最为详细的检查（接口返回json的正确性），QA对系统的熟悉程度和对接口的熟

接口自动化vs监控关于接口自动化的目标和难点可以参考http://blog.csdn.net/huazhongkejidaxuezpp/article/details/52267126。其中，接口自动化由于对接口的检查太过详细，不仅依赖于项目需求的变动频率，而且往往跑完一遍所有接口检查耗时较长（ps:接口越多，检查越详细，耗时越长），所以接口自动化检查，往往不太适合作为接口的监控。因为如果要去

restful接口的用途？如何实现一个restful接口，想必这个问题对于会点代码的人来说，简直太简单了：springmvc ，Jersey，Spark Framework等等。1）但是如果进一步提高要求：实现一个提供restful接口配置的框架，即输入任意的URL 和 期望返回的json串，配置完成后就可以立刻使用该restful接口了，想必这样的框架还是需要一点精力的。之前曾经写过一个re...

接口设计的规范接口设计一般在开发真正code之前，一般来说，前后端定义出接口返回之后，就各自code去了。但这里在接口设计方面往往存在一些问题，会对接口本身或者接口测试存在干扰：接口设计缺少对异常情况的处理，甚至遇到不规范输入，异常值时，直接返回5xx; 接口的默认传参缺少/不生效，这往往是前后端开发对默认场景下参数的传值与实现未定义好； 接口性能方面评估，修改/新增一个接口，往往功能...

接口自动化测试带来了什么互联网公司几乎对QA都有一个统一的要求：自动化测试。一个擅长自动化测试和不太擅长自动化测试的QA来说，毫无疑问，一定是前者胜出。这里我们只讨论接口自动化给项目测试，乃至整个项目质量提高带来的一点思考。说说接口自动化测试带来的好处：提高测试效率。这几乎是所有自动化测试的好处，如果自动化测试比手工测试还要慢，那么无疑，这种情况下，根本没必要做自动化，得不偿失的。 ...

接口diff的定义接口diff即接口对比，就是对接口的返回结果进行对比，找出结果的差异之处。广泛意义上说，接口diff不局限于接口的个数(1/2/3/4/...个接口)，也不局限于接口的返回形式(json/string/xml....) ，当然也不局限与接口的请求方式(http/https/thirft等等)。接口diff基本类似于如git中的代码diff，根本目的在于找出差异。项目测试中...

项目上线风险控制上线项目应该尽可能减少发布失败的可能性，但也需要在失败确实发生时，能尽可能及时的将服务恢复发布前的正常水平。项目上线风险控制-策略这里之谈从测试开始到上线后中间的策略：

需求目的已有数据的基础上，经过各种加工，汇总，呈现出数据结果。需求评估1 . 源数据 是否正确；针对产品提出的指标，确认和需求是否是同一个数据源。一般说来，数据源大致分为两类:1) 本系统产生的数据。 此时对数据的完整性和正确性基本无异议了。2）上游系统同步过来的数据。此时，需要核对 需求中需要的数据 本系统是否已经同步，同步的是否符合要求了。此

测试人员对架构的关注QA对架构的评估时，可以考虑整体设计在正常及异常情况下，是否仍然通用。例子1：异常情况下暴露出了架构设计的弊端

场景 1）接口尚未开发完成前后端项目中，后端接口开发完成之前，接口联调；依赖的上游项目的接口尚未开发完成，需要接口联调测试；2)    接口返回不满足目前需求目前的接口虽然已实现，但个别字段/返回不满足目前的测试要求（比如，一个字段有3中状态，但接口只能返回2种） 接口mock的几个阶段阶段一：直接修改对应的DB数据，使其对应的接口返回满足要求适用场...

代码的审查复查的目的：编码错误；处理逻辑错误；算法错误；回归性错误；可以改进的地方；经验的传授 ps: 团队成员之间互相了解，工作流程熟悉，代码风格统一；原有功能的回归范围；公共代码修改的review；微软质量管理经验bug bash: bug大扫荡，不同角色人员，针对某一类型bug,找bug，并作出一定的奖励；事

测试人员的特质测试人员拿了工资就是要告诉你他们所了解的一切事实，甚至有时候他们会直白得说你的小宝宝很丑，还给出一些列论据。测试人员的关键特质：好奇心(想弄清楚事物是怎么运行的)喜欢动手实验(想知道不同场景究竟发生什么)胆子大（不怕破坏东西，不怕据理力争）善于学习(工作性质要求)ps:办公室政治不擅长不容易相信任何人(别人总是告诉他们模块x不需要测试，或代码y“没

什么是白盒测试刚刚入门测试的时候，写过白盒测试，现在看起来就太简单了，根本构不成一篇博文。随着对测试理解的不断加深，个人任务，整个测试流程大致分为两个阶段：1、由内到外测试单元测试；2、由外到内测试冒烟测试（快速验证主要功能）；全面测试(功能+性能+安全等等)；探索式测试;回归测试；只不过，在实际的项目中，只有少数公司会严格实施 [由内到外测试]的单元测试。 为什么要...

一、故障原因根据故障产生的直接原因分类：代码合并。前端/后端开发合并代码导致最后的故障，例如代码误删，代码被覆盖等。 此类故障如果代码合并没有严格的检查流程，加上影响的是原有的边缘功能的话，是极难发现的。测试未覆盖。测试用例遗漏相关功能点的测试。如果被“改坏”点属于主干功能、业务测试范畴，还是比较容易覆盖的。但如果被“改坏”点恰恰属于原有的边缘功能，那成为“漏网之鱼”的可能性就大大提高了。chec