测试分析与设计的底层逻辑一位京东老神的分享

lsekfe

测试分析与设计的底层逻辑
　　说到测试分析与设计，我认为这个是测试人员最核心的能力。
　　之前讲到的黑盒测试、输入输出模型，只是针对功能测试的方法，虽然一般的系统测试中功能测试占到80%-90%左右，但并不是全部。而且也只是测试中的一个阶段一个类型，要想做好测试，测试分析和设计是必不可少的。
　　大家可以思考一个问题：拿到一个项目，你如何来测试，如何保障质量？
　　面试中很多人给我的答案是：分析需求-编写用例-执行测试-发报告。
　　这个只是测试的流程，只是告诉了我们测试的先后顺序，但并不能指导一个测试人员如何去测试，如何去做测试分析，更无法保障系统的质量。
　　拿到一个项目，你如何来测试？
　　可以借用5W2H方法来分析，其实作为测试架构师，不需要5W也不需要3W，2W+1H 就够了！
　　因为这2W+1H 是最重要的，也是最容易被经验代替然后就忽略的。
　　日常的测试工作由于产品的形态及系统的架构基本固定，所以测试方案思路也基本固定，这样就导致拿到类似的项目就不再有思考，基本很快就按照经验开始干了，一旦遇到不同类型的系统，或者遇到新的业务就不知如何下手，这时候2W1H分析法就可以帮助我们解决这个问题。
　　测试架构师只需要思考三个问题（2W+1H） 就够了：
　　1、Why？为什么做这个项目？项目的背景是什么？——只有知道为什么，才知道用户想要什么。
　　2、What？这个项目我们需要测什么？我们的测试范围有哪些？——只有范围明确，测试才不会遗漏。
　　3、How? 这个项目我们怎么测？我们应该使用哪些测试策略、测试方法？——这里告诉我们测试应当有策略有方法。
　　测试负责人（也可能是测试架构师）还需确定的两个问题：
　　4、When? 项目期望的完成时间？
　　5、Who? 可以调用的资源有哪些？
　　项目经理需要考虑的另外两个问题（测试负责人也需要思考的2个问题）：
　　6、Where？是否需要集中封闭，是否需要研发测试坐到一起？
　　测试人员还可以思考需要在什么环境下测试？测试环境？预发环境？线上环境？windows环境？Linux环境？ios环境？Android？什么浏览器？什么版本等等。
　　7、How Much？这个项目成本是多少？需要多少人日？需要多少服务器资源？
　　测试分析和设计的底层逻辑就是如何回答好2W1H这三个问题；Why和What可以指导我们进行测试分析，了解项目的【背景】，确认测试的【范围】。
　　How可以指导我们去进行测试设计，根据项目背景及测试范围确定测试的【策略】。大家也可以自己去了解学习一下，就是HTSM启发式测试策略模型，这个模型正好与2W+1H是相对应的。
　　测试人员的内功修炼
　　作为测试人员，“沟通表达等软技能”被认为是优秀测试人员的三大核心能力之一，根据上面的统计数据，90%以上的人都是认可的。下面把我之前的一些总结分享一下：
　　主动沟通
　　在电商领域，特点就是快速和变化，有些需求或项目，经常要求快速上线，由于时间短，PRD里有些逻辑就可能会存在漏洞或者根本没有考虑到，面对这样的情况，我们测试该怎么办呢？
　　这时就需要沟通，与产品随时沟通需求，与开发随时沟通设计，与其他系统随时沟通联调，没有沟通，项目里的坑很容易就会被遗漏。沟通还必须得是主动出击，找产品、找研发、找其他条线的测试，把自己当成老板，这个项目的质量基本就有保障了。
　　把自己当成老板的员工，一定是最让老板放心的员工。
　　要有自己的标准
　　系统测试最基本的依据就是需求规格说明书。作为测试人员，我们是最后一道保障，测试必须有自己的分析，不能轻易就跟着研发的思路走，因为他告诉你的已经是经过他们思考加工过的，与原始需求可能已经存在了偏差，这也正是测试的价值所在。
　　即使他们说的99%都是对的，但是也只能作为我们分析的一个材料，我们必须自己通过需求去分析。
　　对一切都要有怀疑的态度
　　需求是测试的依据，但是依据也有错的时候，所以对PRD也要有怀疑的态度。
　　测试就是要怀疑一切， 每一个流程每一个细节，我看需求的时候第一遍基本默认他是对的。等对整体有了一定的理解，我就开始怀疑：流程是否完整， 是否存在漏洞，模块功能是否能满足用户的要求， 非正常操作是否会出现问题，用户是否会用，这个功能是否真的为客户解决了问题等等。
　　这些问题可以通过我们的一些质量标准、测试策略以及测试经验去怀疑，去思考。总之，测试每一个功能都要“三思”。
　　站在公司和用户的角度思考
　　公司越大，部门越多，系统就会越复杂；相互依赖越多，出问题的几率也会越大。
　　因为边界多了，沟通成本也就高了，需要沟通的点多了，只要有些细节没有沟通到位，或者都没有考虑到，或者都认为是对方负责，那坑就出现了。
　　当然这样的坑大部分会在联调测试阶段发现，但对于测试进度影响非常大，经常会造成返工、延期等风险。
　　要想这些坑能够在测试阶段发现，这时候就需要有一个主测试了。但我觉得主测试不应该是一个人，所有测试人员都应该是“主测试”，作为测试人员，软件质量的最后把关者，不能只看到自己负责的这一块，不能局限于自己的部门、团队，只要对整个系统有疑问，我们都有责任提出来，去找人解决。
　　测试不能只看局部，要看全局，要站在公司的位置和用户的角度去思考，去测试。
　　上面主要是总结了我的一些经验，测试中的一些道，有不足之处或不够全面的也希望大家多多补充。
　　后续还会继续分享我认为很重要的 HTSM模型，以及我认为非常重要的等价类划分，场景测试、基因测试、探索式测试的一些好的方法等。总之，我想把我的一些有价值的经验都分享出来以共享。