来源 | OSCHINA 社区
作者 | 京东云开发者-京东零售 张强
原文链接：https://my.oschina.net/u/4090830/blog/8575899
写这篇文章，是希望把我的一些我认为是非常有价值的经验总结出来，能够帮助刚做测试不久的新同事，或者是测试经验丰富的老同事以共享。希望我们可爱的新同事，准备要在测试领域耕耘的伙伴，能够通过我的文章了解到测试的底层逻辑，也就是我们测试工作中可能看不到隐藏较深的点，而不只是日常所见的写用例、提 bug、开发自动化、做平台；俗话说外行看热闹，内行看门道。我认为测试人员不应该成为 PRD 的搬运工，高级测试工程师也不应该只是测试工具得开发者；测试人员，最基本的测试基础理论一定要掌握，当然研发编码技术也必不可少；如果这两样缺少一样，都无法成为一个优秀的测试人员；之前有很多测试人员都是不喜欢写代码，然后做了测试；但在未来或者现在，一个不懂代码的测试人员，很难成为一个优秀的测试人员；但只懂代码，不了解测试理论基础的人（不懂得测试分析、用例设计、测试策略的人，或者即使了解一些 ，但实际工作中不怎么使用的人），一定也不是一个合格的测试人员。根据 Testerhome《2021 年度测试行业问卷调查报告》-【优秀测试人员应具备的技术 / 能力】分析，1、“编程 / 脚本 / 自动化、沟通表达、测试基础理论” 被认为是优秀测试人员的三大核心能力，继续领先其他项；2、数据库、性能测试、安全测试、大数据算法等技术要求，从 2020 年开始大幅增长；三大核心能力基本是大家公认的，也是稳定不变的；但新的技术要求近几年开始都有了大量需求；从分析数据可以看到，市场对测试人员的要求会随着新技术的出现而不断变化；但三大核心能力是测试人员的必修课，变化不会太大，会一直占据核心位置。自从 10 几年前的 QTP 开始，自动化测试就是测试人员追求的目标；直至今日，各种自动化技术、框架已经琳琅满目；市场对测试人员的要求也越来越高，测试人员不仅要会写自动化用例，还需要具备开发维护自动化框架平台的能力；纯黑盒的测试人员要么已经完成了能力升级，要么在升级的路上；完全依赖黑盒测试完成工作的已经越来越少，如果不会编写自动化用例或不了解编程语言，估计找工作简历都很难通过。但往往物极必反，测试人员的代码能力越来越强，测试基础能力却被忽视，测试领域的专业能力逐步被淡化；正如逆水行周，不进则退；三大核心能力应该是齐头并进，不应该顾此失彼。这些年参与了部门很多的招聘面试，我的感受就是很多测试人员虽然工作多年，但对测试用例的设计方法、策略等掌握并不好；至少有 60% 的人在用例设计中不会用什么用例设计方法，也不会思考怎么进行测试分析和设计，他们大部分只是功能测试的执行者，测试设计方面思考很少，测试计划更是很少有人写，测试用例也只是 PRD 的拆分；总之，测试人员一不小心就会成为 PRD 的搬运工。作为一个测试老人，还是希望测试行业能够健康发展，在新技能提升的情况下，测试的专业性也能与时俱进，毕竟质量保障是测试人员的根本。它是把程序看作一个黑盒子，在不考虑程序内部结构的情况下，检查程序功能是否按照 PRD 的规定正常使用，程序是否能适当地接收输入数据，产生正确的输出。这，其实就是黑盒测试的定义，也是黑盒测试的底层逻辑；一般人不会重视定义，但往往就是定义会告诉你真理。工作中有很多人在习惯了一种类型的系统测试，然后换一个新的业务类型，忽然就不知如何下手了；也许是新的总要有一个适应的时间；其实万变不离其宗，只要掌握了黑盒测试的底层逻辑，就能够让你很快上手不再需要适应调整；我们大部分做的都是黑盒测试，所以无论什么类型的系统，我们的测试方案都是 “ 检查程序功能是否按照 PRD 的规定正常使用，程序是否能适当地接收输入数据，产生正确的输出。” 。我们的测试依据是 PRD，首先必须对 PRD 了如执掌，然后分析他的输入有哪些，输出有哪些；这些都覆盖到了，你基本就可以做到 80 分了，也就是你拿下这个项目已不成问题。最后，我还是想再啰嗦强调一下， 就怕我讲的大家还是没有看懂，因为上面讲的大家都懂，第一天了解测试，就知道什么时候黑盒测试，什么输入输出了；但是往往真理就藏在平凡之间，记住他的定义！！！当你遇到项目不知如何下手测试时，把定义拿出来认真读三遍，一定会找到答案！！！强调： 实际当中纯黑盒的其实并不多，除了了解输入、输出，中间的处理逻辑也一定要清楚，这样对测试更有帮助；另外更重要的就是：必须熟读 PRD，必须对 PRD 里的内容分析透彻，不放过任何一段文字，一个词。其实 PRD 里和设计文档里也会有很多的漏洞等你挖掘。【输入】： 这里的输入，并不是简单的界面输入框才算是输入；任何只要能够触发系统运行的都是输入。按照代码架构分层，输入也可以做到如下分类：・正常的操作：输入框、按钮、单选复选框、按钮、下拉框等的规定操作异常的操作：输入框的异常值、超长输入等、按钮的多次点击、快速连续点击（很容易就会发现数据重复提交，或者系统反应缓慢等各种问题，说不定系统就此而奔溃）・组合操作：一般系统的功能都是各种操作的组合；另外一种跟业务场景相关，也就是各种业务场景同时组合进行操作。・并行操作：多人对同一功能点的并发操作；或者多人对同一个数据进行的操作，比如两个人同时对一条单价进行修改、删除等操作。・回退操作：通过浏览器或 APP 进行的回退操作取消操作：正常操作突然取消，例如用户填写很多表格内容，突然操作了取消，是否需要保存或提示呢？删除操作：通过系统提供的功能对数据进行删除・接口服务：对外提供的接口，对于系统来说也是很常见的一种输入，这种输入也是最容易出问题的；・文件上传：有些系统功能是通过获取 ftp 服务器上的 excel、xml 等文件来触发系统运行的，所以这时候的输入就变成了文件。・MQ 消息：也是京东最常见的一种输入形式，MQ 里也可能会包含文件地址等，这种输入就更加灵活了。・对于接口上游的输入，无论何种形式，都要分析上游数据的每一个字段，了解上游各种输入的可能。• 有些字段还必须从业务【源头】了解这个字段的含义，可能的枚举值，可能的结果等；・另外由于历史原因，源头的数据就可能存在各种想像不到的数据；・对于输入的分析非常重要，这时候你就可以使用【等价类】方法进行分析。・数据的变化：有很多后台处理的任务就是监控是否有新数据的插入或删除等数据字段的变化：后台处理任务监控数据状态的变化，或组合字段的变化等缓存数据的变化：除了数据库的变化，有的是缓存数据的变化时间的变化：定时任务除了数据是输入，时间也是他的输入。看的见的输出： 就是我们常见的系统操作反馈，用户能直接看到的变化；比如弹框、提示、跳转、数据的新增、修改、删除后的变化，图片、视频等操作后的变化等等。看不见的输出： 看不见的输出是最容易忽略也是最容易出问题的；【看不见的输出】包括：数据库的变化、缓存的变化、系统文件的变化、发送给下游接口的数据等【看的见的输出】虽然能够帮我们验证基本 90% 以上的功能，通过界面展示的数据也能验证我们新增或修改的数据，是否新增成功了或正确的被修改了；但是我们看到的只是一部分；还有很多字段是没有被展示的，有的可能只是给下游或其他系统使用的，也有可能是留给未来使用的；这些不可见的部分，经常就会引起系统的异常，也是隐藏在系统中最大的坑；所以测试，除了站在用户的角度去测试系统，还要站在设计者的角度去测试，更应该站在整个产品的角度去思考。
说到测试分析与设计，我认为这个是测试人员最核心的能力；上面讲到的黑盒测试、输入输出模型，只是针对功能测试的方法，虽然一般的系统测试中功能测试占到 80%-90% 左右，但并不是全部。而且也只是测试中的一个阶段一个类型，要想做好测试，测试分析和设计是必不可少的。大家可以思考一个问题：拿到一个项目，你如何来测试？如何保障质量？面试中很多人给我的答案是：分析需求，编写用例，然后执行测试，发报告；这个只是测试的流程，只是告诉了我们测试的先后顺序，但并不能指导一个测试人员如何去测试，如何去做测试分析，更无法保障系统的质量。可以借用 5W2H 方法来分析，其实作为测试架构师，不需要 5W 也不需要 3W，2W+1H 就够了！因为这 2W+1H 是最重要的，也是最容易被经验代替然后就忽略的；日常的测试工作由于产品的形态及系统的架构基本固定，所以测试方案思路也基本固定，这样就导致拿到类似的项目就不再有思考，基本很快就按照经验开始干了；一旦遇到不同类型的系统，或者遇到新的业务就不知如何下手，这时候 2W1H 分析法就可以帮助我们解决这个问题。测试架构师只需要思考三个问题（2W+1H） 就够了：1、Why？ 为什么做这个项目？项目的背景是什么？—— 只有知道为什么，才知道用户想要什么。2、What？ 这个项目我们需要测什么？我们的测试范围有哪些？—— 只有范围明确，测试才不会遗漏。3、How? 这个项目我们怎么测？我们应该使用哪些测试策略、测试方法？—— 这里告诉我们测试应当有策略有方法测试负责人（也可能是测试架构师）还需确定的两个问题：项目经理需要考虑的另外两个问题：（测试负责人也需要思考的 2 个问题）6、Where？是否需要集中封闭，是否需要研发测试坐到一起？测试人员还可以思考需要在什么环境下测试？测试环境？预发环境？线上环境？windows 环境？Linux 环境？ios 环境？Android？什么浏览器？什么版本等等7、How Much？这个项目成本是多少？需要多少人日？需要多少服务器资源？测试分析和设计的底层逻辑就是如何回答好 2W1H 这三个问题；Why 和 What 可以指导我们进行测试分析，了解项目的【背景】，确认测试的【范围】；How 可以指导我们去进行测试设计，根据项目背景及测试范围确定测试的【策略】。不过目前讲的还是方法论，具体的操作步骤还没有讲；由于这一部分内容比较多，可以通过一篇文章具体来讲；大家也可以自己去了解学习一下，就是 HTSM 启发式测试策略模型，这个模型正好与 2W+1H 是相对应的。
作为测试人员，“沟通表达等软技能” 被认为是优秀测试人员的三大核心能力一，根据上面的统计数据，90% 以上的人都是认可的。下面把我之前的一些总结分享一下：在电商领域，特点就是快速和变化；有些需求或项目，经常要求快速上线，由于时间短，PRD 里有些逻辑就可能会存在漏洞或者根本没有考虑到，面对这样的情况，我们测试该怎么办呢？这时就需要沟通，与产品随时沟通需求，与开发随时沟通设计，与其他系统随时沟通联调，没有沟通，项目里的坑很容易就会被遗漏。沟通还必需得是主动出击，找产品、找研发、找其他条线的测试，把自己当成老板，这个项目的质量基本就有保障了；把自己当成老板的员工，一定是最让老板放心的员工。系统测试最基本的依据就是需求规格说明书；作为测试人员，我们是最后一道保障；测试必须有自己的分析，不能轻易就跟着研发的思路走，因为他告诉你的已经是经过他们思考加工过的，与原始需求可能已经存在了偏差；这也正是测试的价值所在。即使他们说的 99% 都是对的，但是也只能作为我们分析的一个材料；我们必须自己通过需求去分析。需求是测试的依据，但是依据也有错的时候；所以对 PRD 也要有怀疑的态度。测试就是要怀疑一切； 每一个流程每一个细节；我看需求的时候第一遍基本默认他是对的，等对整体有了一定的理解，我就开始怀疑，流程是否完整？是否存在漏洞？模块功能是否能满足用户的要求？非正常操作是否会出现问题？用户是否会用？这个功能是否真的为客户解决了问题？等等，这些问题可以通过我们的一些质量标准、测试策略以及测试经验去怀疑，去思考。总之，测试每一个功能都要 “三思”。公司越大，部门越多，系统就会越复杂；相互依赖越多，出问题的几率也会越大；因为边界多了，沟通成本也就高了；需要沟通的点多了，只要有些细节没有沟通到位，或者都没有考虑到，或者都认为是对方负责，那坑就出现了；当然这样的坑大部分会在联调测试阶段发现，但对于测试进度影响非常大，经常会造成反工、延期等风险；要想这些坑能够在测试阶段发现，这时候就需要有一个主测试了；但我觉得主测试不应该是一个人，所有测试人员都应该是 “主测试”；作为测试人员，软件质量的最后把关者，不能只看到自己负责的这一块，不能局限于自己的部门、团队，只要对整个系统有疑问，我们都有责任提出来，去找人解决。测试不能只看局部，要看全局；要站在公司的位置和用户的角度去思考，去测试。上面主要是总结了我得一些经验，测试中的一些道，有不足之处或不够全面的也希望大家多多补充；后续还会继续分享我认为很重要的 HTSM 模型，以及我认为非常重要的等价类划分，场景测试、基因测试、探索式测试的一些好的方法等。总之，我想把我的一些有价值的经验都分享出来以共享。
这里有最新开源资讯、软件更新、技术干货等内容
点这里 ↓↓↓ 记得 关注✔ 标星⭐ 哦
