测试的底层逻辑

以下为作者观点：
写这篇文章，是希望把我的一些我以为是非常有代价的经验总结出来，能够资助刚做测试不久的新同事，或者是测试经验丰富的老同事以共享。希望我们可爱的新同事，准备要在测试领域耕耘的同伴，能够通过我的文章了解到测试的底层逻辑，也就是我们测试工作中可能看不到隐蔽较深的点，而不但是日常所见的写用例、提 bug、开发自动化、做平台；俗话说外行看热闹，内行看门道。

我以为测试人员不应该成为PRD的搬运工，高级测试工程师也不应该只是测试工具得开发者；
测试人员，最基本的测试基础理论一定要掌握，当然研发编码技能也必不可少；如果这两样缺少一样，都无法成为一个良好的测试人员；之前有很多测试人员都是不喜好写代码，然后做了测试；但在未来或者如今，一个不懂代码的测试人员，很难成为一个良好的测试人员；但只懂代码，不了解测试理论基础的人（不懂得测试分析、用例设计、测试策略的人，或者即使了解一些 ，但实际工作中不怎么使用的人），一定也不是一个合格的测试人员。
下面带大家了解一些测试的底层逻辑，测试的门道。
一、良好测试人员应该具备的焦点能力

根据 TesterHome《2021年度测试行业问卷调查报告》-【良好测试人员应具备的技能/能力】分析：
1、“编程/脚本/自动化、沟通表达、测试基础理论” 被以为是良好测试人员的三大焦点能力，继续领先其他项；
2、数据库、性能测试、安全测试、大数据算法等技能要求，从 2020 年开始大幅增长；
三大焦点能力基本是大家公认的，也是稳定不变的；但新的技能要求近几年开始都有了大量需求；从分析数据可以看到，市场对测试人员的要求会随着新技能的出现而不断变革；但三大焦点能力是测试人员的必修课，变革不会太大，会不停占据焦点位置。
自从10几年前的QTP开始，自动化测试就是测试人员寻求的目的；直至今日，各种自动化技能、框架已经琳琅满目；市场对测试人员的要求也越来越高，测试人员不但要会写自动化用例，还必要具备开发维护自动化框架平台的能力；纯黑盒的测试人员要么已经完成了能力升级，要么在升级的路上；完全依赖黑盒测试完成工作的已经越来越少，如果不会编写自动化用例或不了解编程语言，估计找工作简历都很难通过。
但每每物极必反，测试人员的代码能力越来越强，测试基础能力却被忽视，测试领域的专业能力逐步被淡化；正如逆水行舟，不进则退；三大焦点能力应该是齐头并进，不应该顾此失彼。
这些年参与了部门很多的雇用口试，我的感受就是很多测试人员固然工作多年，但对测试用例的设计方法、策略等掌握并不好；至少有60%的人在用例设计中不会用什么用例设计方法，也不会思考怎么进行测试分析和设计，他们大部分只是功能测试的实行者，测试设计方面思考很少，测试筹划更是很少有人写，测试用例也只是 PRD 的拆分；总之，测试人员一不警惕就会成为 PRD 的搬运工。
作为一个测试老人，照旧希望测试行业能够康健发展，在新技能提升的情况下，测试的专业性也能与时俱进，究竟质量保障是测试人员的根本。
二、黑盒测试的底层逻辑

什么是黑盒测试？
它是把步伐看作一个黑盒子，在不思量步伐内部结构的情况下，检查步伐功能是否按照 PRD 的规定正常使用，步伐是否能得本地接收输入数据，产生正确的输出。
这，其实就是黑盒测试的定义，也是黑盒测试的底层逻辑；一样寻常人不会器重定义，但每每就是定义会告诉你真理。
工作中有很多人在风俗了一种范例的体系测试，然后换一个新的业务范例，忽然就不知怎样动手了；也许是新的总要有一个顺应的时间；其实万变不离其宗，只要掌握了黑盒测试的底层逻辑，就能够让你很快上手不再必要顺应调整；
我们大部分做的都是黑盒测试，以是无论什么范例的体系，我们的测试方案都是 “ 检查步伐功能是否按照 PRD 的规定正常使用，步伐是否能得本地接收输入数据，产生正确的输出。” 。
我们的测试依据是PRD，首先必须对PRD了如指掌，然后分析他的输入有哪些，输出有哪些；这些都覆盖到了，你基本就可以做到80分了，也就是你拿下这个项目已不成问题。
末了，我照旧想再啰嗦夸大一下， 就怕我讲的大家照旧没有看懂，由于上面讲的大家都懂，第一天了解测试，就知道什么时间黑盒测试，什么输入输出了；但是每每真理就藏在平凡之间，记取他的定义！！！
当你碰到项目不知怎样动手测试时，把定义拿出来认真读三遍，一定会找到答案！！！
夸大： 实际当中纯黑盒的其实并不多，除了了解输入、输出，中心的处理逻辑也一定要清楚，这样对测试更有资助；另外更重要的就是：必须熟读PRD，必须对 PRD里的内容分析透彻，不放过任何一段文字，一个词。其实PRD里和设计文档里也会有很多的漏洞等你发掘。

三、黑盒测试底层逻辑详解：【输入输出测试模子】

【输入】： 这里的输入，并不是简朴的界面输入框才算是输入；任何只要能够触发体系运行的都是输入。按照代码架构分层，输入也可以做到如下分类：
1、界面操作的输入：
正向操作：
1）单一操作：
•正常的操作：输入框、按钮、单选复选框、按钮、下拉框等的规定操作异常的操作：输入框的异常值、超长输入等、按钮的多次点击、快速连续点击（很轻易就会发现数据重复提交，或者体系反应迟钝等各种问题，说不定体系就此而崩溃）
2）复杂操作：
•组合操作：一样寻常体系的功能都是各种操作的组合；另外一种跟业务场景相干，也就是各种业务场景同时组合进行操作。
•并行操作：多人对同一功能点的并发操作；或者多人对同一个数据进行的操作，比如两个人同时对一条单价进行修改、删除等操作。
逆向操作：
3）逆向操作：
•回退操作：通过欣赏器或 APP 进行的回退操作取消操作：正常操作突然取消，比方用户填写很多表格内容，突然操作了取消，是否必要保存或提示呢？删除操作：通过体系提供的功能对数据进行删除
下面的输入是最轻易被忽略的：
2、服务层的输入：
•接口服务：对外提供的接口，对于体系来说也是很常见的一种输入，这种输入也是最轻易出问题的；
•文件上传：有些体系功能是通过获取 ftp 服务器上的 excel、xml 等文件来触发体系运行的，以是这时间的输入就酿成了文件。
•MQ 消息：也是京东最常见的一种输入形式，MQ 里也可能会包含文件地址等，这种输入就更加机动了。
夸大：
•对于接口上游的输入，无论何种形式，都要分析上游数据的每一个字段，了解上游各种输入的可能。
•有些字段还必须从业务【源头】了解这个字段的含义，可能的罗列值，可能的结果等；
•另外由于汗青原因，源头的数据就可能存在各种想象不到的数据；
•对于输入的分析非常重要，这时间你就可以使用【等价类】方法进行分析。
3、数据层的输入：
•数据的变革：有很多后台处理的使命就是监控是否有新数据的插入或删除等数据字段的变革：后台处理使命监控数据状态的变革，或组合字段的变革等缓存数据的变革：除了数据库的变革，有的是缓存数据的变革时间的变革：定时使命除了数据是输入，时间也是他的输入。
【输出】：输出分为可见输出和不可见输出
看得见的输出： 就是我们常见的体系操作反馈，用户能直接看到的变革；比如弹框、提示、跳转、数据的新增、修改、删除后的变革，图片、视频等操作后的变革等等。
看不见的输出： 看不见的输出是最轻易忽略也是最轻易出问题的；【看不见的输出】包括：数据库的变革、缓存的变革、体系文件的变革、发送给鄙俚接口的数据等
【看得见的输出】固然能够帮我们验证基本 90% 以上的功能，通过界面展示的数据也能验证我们新增或修改的数据，是否新增成功了或正确的被修改了；但是我们看到的只是一部分；还有很多字段是没有被展示的，有的可能只是给鄙俚或其他体系使用的，也有可能是留给未来使用的；这些不可见的部分，经常就会引起体系的异常，也是隐蔽在体系中最大的坑；
以是测试，除了站在用户的角度去测试体系，还要站在设计者的角度去测试，更应该站在整个产品的角度去思考。
四、测试分析与设计的底层逻辑

说到测试分析与设计，我以为这个是测试人员最焦点的能力；上面讲到的黑盒测试、输入输出模子，只是针对功能测试的方法，固然一样寻常的体系测试中功能测试占到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%以上的人都是认可的。下面把我之前的一些总结分享一下：
1、主动沟通
在电商领域，特点就是快速和变革；有些需求或项目，经常要求快速上线，由于时间短，PRD 里有些逻辑就可能会存在漏洞或者根本没有思量到，面临这样的情况，我们测试该怎么办呢？这时就必要沟通，与产品随时沟通需求，与开发随时沟通设计，与其他体系随时沟通联调，没有沟通，项目里的坑很轻易就会被遗漏。沟通还必须是主动出击，找产品、找研发、找其他条线的测试，把自己当成老板，这个项目的质量基本就有保障了；把自己当成老板的员工，一定是最让老板放心的员工。
2、要有自己的尺度
体系测试最基本的依据就是需求规格说明书；作为测试人员，我们是末了一道保障；测试必须有自己的分析，不能轻易就跟着研发的思绪走，由于他告诉你的已经是经过他们思考加工过的，与原始需求可能已经存在了毛病；这也正是测试的代价所在。即使他们说的 99% 都是对的，但是也只能作为我们分析的一个材料；我们必须自己通过需求去分析。
3、对一切都要有怀疑的态度
需求是测试的依据，但是依据也有错的时间；以是对 PRD 也要有怀疑的态度。测试就是要怀疑一切； 每一个流程每一个细节；我看需求的时间第一遍基本默认他是对的，等对团体有了一定的理解，我就开始怀疑，流程是否完备? 是否存在漏洞? 模块功能是否能满足用户的要求? 非正常操作是否会出现问题? 用户是否会用？这个功能是否真的为客户解决了问题？等等，这些问题可以通过我们的一些质量尺度、测试策略以及测试经验去怀疑，去思考。总之，测试每一个功能都要 “三思”。
4、站在公司和用户的角度思考
公司越大，部门越多，体系就会越复杂；相互依赖越多，出问题的概率也会越大；由于边界多了，沟通本钱也就高了；必要沟通的点多了，只要有些细节没有沟通到位，或者都没有思量到，或者都以为是对方负责，那坑就出现了；当然这样的坑大部分会在联调测试阶段发现，但对于测试进度影响非常大，经常会造成反工、延期等风险；
要想这些坑能够在测试阶段发现，这时间就必要有一个主测试了；但我觉得主测试不应该是一个人，全部测试人员都应该是 “主测试”；作为测试人员，软件质量的末了把关者，不能只看到自己负责的这一块，不能局限于自己的部门、团队，只要对整个体系有疑问，我们都有责任提出来，去找人解决。测试不能只看局部，要看全局；要站在公司的位置和用户的角度去思考，去测试。
上面重要是总结了我的一些经验，测试中的一些道，有不敷之处或不够全面的也希望大家多多补充；后续还会继续分享我以为很重要的 HTSM 模子，以及我以为非常重要的等价类分别，场景测试、基因测试、探索式测试的一些好的方法等。总之，我想把我的一些有代价的经验都分享出来以共享。
末了： 下方这份完备的软件测试视频学习教程已经整理上传完成，朋友们如果必要可以自行免费领取 【包管100%免费】

这些资料，对于【软件测试】的朋友来说应该是最全面最完备的备战仓库，这个仓库也伴随上万个测试工程师们走过最艰难的路程，希望也能资助到你！

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。