从另一个角度看软件测试

lsekfe

本文将从岗位要求看软件测试、软件测试技术的认识和理解、质量保障与软件测试的关系、构建质量保障系统的要点这四个方面简单聊一聊作者的理解，带你换个角度来认识软件测试。

一、从岗位要求看软件测试

首先，我想请大家和我一起思考一个问题：我们要以什么标准来区分初级、中级、高级软件测试工程师、测试专家这几个岗位。也就是这4个职位怎么去界定，我们自己属于哪个级别呢？（为什么选这4个呢？因为现在整个行业基本都是这么去划分软件测试工程师岗位级别的。）

从众多的招聘信息上看到，似乎是可以用工作年限来界定的：1年以下是初级、1-3年是中级、3-5年是高级、5年以上是专家。那有的人就会想了，我已经工作5年了，是不是我可以去应聘测试专家了呢？答案是不一定。为什么呢？因为先不说以工作年限作为判断的标准是对还是不对，仅仅简单地依据年限来判断这个方法就是会有偏差的。不是有个段子嘛，说是10年工作经验，其实是用1年的经验工作了10年。

继续从众多的招聘信息上看到，似乎是可以用工作技能来界定，功能测试是初级、会用工具是中级、能开发自动化脚本是高级、能开发自动化框架是专家。那又有人会想了，现在这么多培训，线上线下都有，各种方面的，比如python编程，自动化测试培训等等。那是不是我参加这些培训班，学会了python、学会了自动化测试框架的使用，那我至少可以应聘高级软件测试工程师了吧？答案还是不一定，为什么这么说？我们先把这个问题记下，继续往下，看完我后面的认知理解，我们再回来看这个问题应该就能有答案了。

二、软件测试技术的认识和理解

现在我们稍微转换个话题，讨论一下什么是软件测试，什么是软件测试技术。

很多时候，很多从业者一提到软件测试技术，想到的就是自动化测试、测试开发这样的字眼，比如接口自动化、UI自动化、性能测试；什么postman、Jmeter、selenium、appium、RobotFramework、Cucumber等等，似乎简历里不带有这些字眼就体现不出技术能力。不过呢，如果把这些信息从简历里拿掉后，我们又会发现绝大部分简历似乎都一样了。难道说软件测试技术真的就是通过上面所说的测试类别或内容、测试工具或框架来体现的？

我个人认为这个理解没有错，但是呢不全面。这个理解是站在狭义的技术上去看，让我们换个角度，从广义的技术上来看软件测试应该是什么样。我理解的软件测试技术包括四个方面：工艺、工序、方法、手段。这四个方面环环相扣、是个有机的整体。其中工艺、工序是一对，理解起来略显抽象；方法和手段是一对，这一对是我们经常谈到的。

这里先举个例子做下说明，便于大家对我接下来要说的内容能更好地理解。我们大家都有过体检的经历，体检就是对人体这个复杂的系统进行一项项的检验，来确认健康或者是有什么问题。体检的时候我们要验血、验尿等，化验的有很多细分项，比如血小板、红细胞、白细胞、血红蛋白、（尿糖、尿蛋白）等，每项都有个正常的指标范围；然后查心脏会拍心电图、查肝脾肾会做B超、查肺会拍X光等等，影像或者片子出来后，医生会以他脑子里记忆的正常标准的影像图来进行比对，从而确定是否健康。讲到这儿，思维比较活跃的人是不是已经感觉到体检和咱们测试很像了？只不过体检测的是人体系统；而咱们测试呢，测的是软件系统，被测物不一样、指标不一样、方法手段不一样而已，但道理是一样的。

好了，我们回来接着聊广义的软件测试技术。

首先来说工艺，它是指测试的指标体系，也就是标准。构建指标体系，就是针对测试对象，从多个方面，不同维度，构建一个测试指标项的集合。测试的指标项简单地来看，就是

我们常说的测试点或检查点或checklist再加上针对这些点的指标要求，它是工艺的核心，更是软件测试技术的根本。就好比我们体检时要做哪些检查项，每项检查中细分哪些指标的检测。体检结果准不准，主要就看检查的指标全不全、细不细。同理，我们的测试做得好不好，就要看我们的指标体系构建的合理不合理、完整不完整了。

接着来说工序，它是指测试的工作项的顺序，也就是流程。就像我们体检的时候要先查什么、后查什么，哪些项可以没有顺序，哪些项又必须串行，查某项的时候有什么前提，比如空腹、憋尿等等。我们有不少从业者一说起测试流程就是参加需求评审、评估测试周期、设计测试用例，有的流程严谨些的会有测试用例评审，有的可能没有，然后是执行测试，记录、跟踪并验证bug，测试总结报告，就完了。太粗犷！不妨借鉴某些食品或者饮品广告里说的“经过21道工序加工而成”来仔细琢磨一下，我们还做了什么必不可少的环节？比方说功能需求or软件需求到测试需求的转换、梳理上下游系统的关联和交互、根据调用链or数据流圈定回归测试范围、结合业务设计全流程覆盖的测试场景并造数据等等。当你把工序细化到每一项有明确产出物的工作项时，你就会清楚哪做得到位，哪做得还不够；同时，对应这些工序要做到什么程度也就有了目标了。

在工艺和工序上深入思考，就能基本上搞清楚“测什么”这个问题。下面我们再继续来谈谈怎么测。

先说方法，它是指测试的方法和策略，也就是思路。这个是大家经常讨论，有很多借鉴和参考，并且已经有很多方法论可供学习的。核心也基本上都是从软件产品质量六性出发，划分出测试类别，然后针对测试类别思考采用什么测试方法。需要注意的是对于测试方法的灵活运用，以及考虑投入和产出的平衡。这部分内容在网络上或者测试专业书籍都有大量的、详细的介绍，大家有兴趣可以自行搜索阅读。

再说手段，它是指我们测试方法的具体落实，也就是实操。大多数情况下工具就代表了

手段，毕竟咱们人类使用工具基本上已经成了一种本能。做什么事之前都会想想有什么可用的工具没有，这正是工欲善其事，必先利其器。它和测试方法经常被一起提及，我相信大家说起来也是如数家珍。手段这方面是目前大多数软件测试职业培训主打的一点，也是大多数想入行或者入行后想迅速提升的同学们可以选择的路径。但是请大家注意，手段只是软件测试技术中的一个方面，应该重视，但不能过于重视。也不能因为会用工具、会些自动化测试就鄙视手工测试，因为两者没有优劣之分。让我们一起看下测试武功论就会明白了。（测试武功论这个说法是我自己的理解，因为我个人比较喜欢看武侠小说，所以拿武功来类比了一下软件测试。）

我认为软件测试的武功分内功和招式，像功能测试、性能测试、安全性测试、兼容性测试等等，是一种思想理念的体现，一种方法论，所以是内功心法。其中功能测试又是一门基本功法，是一切的基础。像前面提到的LR、Jmeter、postman、selenium、appium、Robtframework、Cucumber等等都是刀枪剑戟等兵器以及配套的招式。有人会问，那手工测试算什么？我的回答是，手工测试是拳脚招式。兵器好选、招式好练，但是内功积累就不容易了。仅仅会招式，有兵器不行，这是花架子，遇到懂行的一碰就倒。这也是为什么学会python编程，经过测试工具或者测试开发培训也不可能轻易从0基础达到高水平的原因。但仅仅是内功深厚也是不够的，因为你与人比武时，总不能遇到谁都不过招，上来就比拼内力吧？这就从侧面回答了为什么内功也就是功能测试达到登峰造极，也要最好能用一些工具或者能懂自动化、有编程能力；为什么没有内功，即便有神兵利器也发挥不出威力，也就是自动化测试需要先做好测试再来谈自动化，测试开发也一样。综上，如果想要达到武功天下第一，成为一代宗师，最好内外兼修，不仅内力深厚，而且招式精妙、兵器趁手。

有了上面软件测试技术和测试武功论的理解，我们再回过头看之前遗留的那个问题。我帮大家回忆一下啊，问题是“学会了python、学会了自动化测试框架的使用，是不是就可

以应聘高级软件测试工程师了？”我回答是不一定，为什么就不用再多说了吧。

我们再看最初始的问题，怎么界定初、中、高和专家级软件测试工程师呢？难道招聘要求有误吗？并不是的，因为招聘方是通过设定的年限标准，测试工具、编程能力的技能标准来筛选简历。其实也好理解，年限界定是为了衡量这个人内功的深厚程度，毕竟如果正常发展（修炼），内力是随着时间的增长而增长的；技能的界定是为了衡量这个人招式熟练程度以及会使用的兵器，毕竟在招聘方的角度来看，招式越娴熟，兵器会得越多当然越好。之所以有时候觉得经验、能力和工作年限不匹配，主要原因还是我们自己把功能测试做成了功能点的测试，把软件系统的测试做成了软件的测试。举个例子，接口自动化测试的应聘者在面试的时候被问到：“接口测试脚本中要做哪些校验？”一般的回答：根据入参得到的回参来判断接口是否符合预期。稍微全面些的回答：不仅要校验回参是否符合预期，还要校验数据库中落库的数据是否符合预期。但是这样就够了吗？还不够，因为曾经就看到过这样的事故案例：接口测试只做了回参和落库的校验，漏掉了对于调用链上关联系统MQ消息的幂等校验，结果因为订单退款流程涉及的一系列系统幂等没有做好，一个订单能够多次退款，也就是每单退款公司都多给客户返还了好几笔钱，造成了相当严重的资损。虽然责任不全在测试，但是实际上如果测试人员多思考系统结构、上下游系统关联关系，多思考接口调用链路、数据链路，是完全有可能在线下测试的时候就发现这个bug的。所以仅仅是掌握了一些测试工具的使用、仅仅会做些自动化脚本的开发、仅仅会做软件的测试而不懂软件系统的测试是完全不够的。

讲到这，我想特意讲一下测试架构师这个传说中的职位。为什么说是传说，因为现在很少有人讲如何进阶到这样的段位，通过招聘信息看到的也多数都是类似于测试开发、自动化测试这样的要求，顶多是加一条具备测试框架开发能力。所以大多数从业者对这个职位的内涵也是相对模糊的，好像编码能力强的测试工程师就是测试架构师。这样的理解是不准确的，

就如同编码能力强的开发工程师并不一定是系统架构师一样。因为系统架构师要做软件层面的模块拆分、系统分层、架构设计、框架选型、接口定义、协议规范、库表规划等等，还要做硬件层面的网络拓扑结构设计、安全防护节点设置及设备选型、硬件设备容量规划等等。测试架构师要做的包括系统结构和调用关系梳理、业务场景所涉及的接口链路和数据流的分析、测试内容和范围的规划、测试策略和方法的选取、分层测试的维度或边界的定义、测试覆盖的评估、测试质量和有效性的评价等等。测试架构师要有一个清晰的认识，就是测试是无法穷尽的，无法做到100%覆盖；也不是所有手段、技术都上了就一定是好的测试。测试架构师所追求的是极限的、刚刚好的测试，是一个时间、成本、质量动态最平衡的点。所以一定要结合产品的质量目标、时间周期、资源成本等等来考虑测试方法、手段。测试架构师不是说代码能力要有多强，而是要能针对被测物构建全面、完整的测试指标体系，所有的测试方法、手段都了然于胸，针对不同目标和需要，划定最科学、合适的测试范围，采用最合理的测试手段，达到测试结果能清晰、准确的评价产品质量。当然我也不是说编码能力无用论啊，既懂测试又会编码的人是最好的。我只是说不能过分强调代码能力，毕竟测试架构师的基本功还得是测试。

三、质量保障与软件测试的关系

说了这么多的软件测试，我们再来聊聊现在我们常谈论的质量保障，也就是QA（QualityAssurance）。大家可以在网上搜索QA，也可以阅读ISO9000、CMMI的过程管理标准，都有详细地介绍QA的定义、过程管理规范、职责和组织结构等等。所以以上内容就不在本文中赘述了。这里要和大家聊的是质量保障与软件测试的关系。

在互联网公司，大家都习惯把测试人员叫QA。但其实测试只是质量保障中的一个环节。质量保障是随着产品的全生命周期而一直延续的一个过程，测试只是在产品开发出来后进行

质量验证的一个步骤。只不过这个步骤基本上已经是质量保障的最后一道检查关，因此显得尤为重要。质量保障其实是整个产研、甚至是整个公司都要投入去做的一件事；如果没有运营、产品、研发、测试和运维的通力合作，仅靠测试一个部门想把质量保障做好还是有一定难度的。因此，有些公司寄希望于通过建立一个测试部门，招些软件测试工程师进行软件测试工作，就能彻底解决质量问题，这个期望是过高了。这种举措能够达到在短时间内提升产品质量的目的，但是如果不从工作组织模式、职责分工上做改变，所有人都还认为质量保障都是测试的事，质量问题都是测试的问题，那这个公司的产品质量将很难有质的改变；或者能有改变，但也要花费巨大的成本，测试同学也将苦不堪言。

那除了进行运行时的软件测试以外，还有什么途径可以保障质量呢？其实大家平时都有在做，比如各个方面的评审（需求评审、设计评审、用例评审、上线计划评审）、codereview、单元测试、开发联调、静态代码审查（sonar）、bug回顾和分析、产品验收、项目复盘等等。

但是仅有这些步骤还不够，还需要有输入输出标准要求。就拿开发联调来举例，研发同学做完自己模块的开发工作，与其他上下游模块能调通就算联调完成，那这个质量要求就太低了。至少也需要对于本次需求的业务场景的主流程能跑通才算是联调完成，如果能涉及到异常场景就更好了。因为大家都有这个常识，就是质量问题越前置，所需要花费的修复成本就越小。如果所有问题都等到测试人员介入去发现，都落到运行态测试这一关，那投入的成本将至少是开发加测试，有时还不仅仅是这些。

但问题又来了，如果所有质量保障工作都前置了，是不是就不需要测试了呢？这个问题偷换了概念，把测试人员和测试工作划了等号。质量保障工作都前置，并且做到完美，是有可能不需要测试人员的，但是相应的测试工作并没有减少，只不过是以其他形式做了拆分，然后分摊到其他岗位上去了而已。

四、构建质量保障系统的要点

知道了质量保障与测试的关系，我们来看看以测试部门来推动质量保证体系的建设有哪些要点。

首先，质量保障必须要落实在系统上，这是为了规范的统一、数据的自动采集和度量操作的一致，也就是标准化。

其次，质量保障系统要尽可能自动化，将规则的判断交给系统，减少人为干预，也减少人工操作的成本；

再次，质量保障需要有量化评估模型对质量进行评估，进而评价质量保障的效果。

最后，有时候换个角度看问题，你会发现塞翁失马、焉知非福。既然大多数人都认为质量保障是测试的事，质量问题要测试负责，那么作为测试就可以反过来要求这些人对他们的输出负责，从而反向推动大家质量意识的提升。

简单介绍下我们天鹅到家正在建设的质量保障系统：

在需求提出时，就要确定出明确的需求范围，功能点，团队成员以及预期收益；需求评审通过后，功能点自动在用例管理系统中创建出本次的测试用例初稿；团队成员根据需求在排期系统中做任务拆解和时间安排。详设阶段，研发同学根据需求确定改动的功能模块，将模块与需求关联；在关联模块时，会根据需求的团队成员确定可见的模块范围，不是团队成员的工程，或者团队成员没有develop/master权限的工程，将无法关联。需求和详设阶段这样安排，目的是为了使需求边界尽量清晰，减少后续“反复拉抽屉”的成本。

模块关联完成，进入开发阶段，会有三个动作，一是研发人员可拉取需求关联的模块所对应工程的分支代码，非本需求团队成员，无法在开发阶段对模块进行拉分支的操作，即使该同学具有该模块的develop/master权限；这个是人工通过系统进行操作，会受系统中规则的限制。二是模块所对应的容器镜像&系统运行所需服务的镜像均开始准备，并在容器中

进行测试环境搭建；三是被拉取工程及上下游模块所对应的测试用例与前一步创建的测试用例初稿（Test Case_Original）在测试用例管理系统中一并形成本次需求的测试用例初始集合，测试人员可在此基础上快速完成测试用例的设计；这两个动作都是系统自动完成。这样就建立了一条需求id、功能点、代码分支、环境、用例版本的数据链，便于回溯。

开发在联调完成后进行提测，走持续集成，这个很多公司都有，此处不过多赘述。只是特别说明一下，多数可能做的是全量的代码覆盖率，最好是做增量部分代码覆盖率。一方面是为后续测试工作做一个基线，一方面是能更准确评估单测的精准度。因为除非100%覆盖，否则80%以上的代码覆盖也无法保证改动部分是被全覆盖了。

线下测试环节没有特别特殊的地方，稍有特点的，可能就是不论什么环境测出来的bug都要求是需求负责人（产品经理）来进行处理，是关闭还是带bug上线，而不是由测试人员来处理，这就反向推动需求负责人（产品经理）关注质量，提早并持续进行验收动作。

线下测试完成，进入沙箱测试之前要制定上线计划，否则系统无法打包并部署沙箱环境。很多时候上线事故都是由于上线步骤混乱、或者遗漏某个操作环节、或者没有完善的回滚计划造成的。这一步要做到的目标是所有执行操作尽量自动化，减少人工干预。包括：沙箱准备工作中数据库执行操作及顺序、ES索引执行操作、MQ主题申请、配置文件及配置中心上的设置、数据字典配置、菜单及权限的配置、角色及数据权限的配置等，线上环境数据准备，编排集群上线顺序，回滚方案等等。这样就能在沙箱环境将上线计划也一并进行验证。

沙箱环境环境部署好后，将准备好的线上流量在沙箱环境进行回放，监控系统检测系统运行情况、业务运转情况，验证本次需求上线后是否会对现有生产系统以及业务运转造成影响。测试人员更集中精力在沙箱环境中验证本次需求的新增和改动。几个核心要点：调用链反查流量入口、流量复制、流量回放、流量染色、监控系统、熔断、影子库/影子表等。

质量评估通过，将允许上线。质量评估也是一个比较大的话题，有机会再做详细介绍，

这里给大家提供几个指标，分别是：缺陷对应到模块的一个分布情况、缺陷处理结束的时长、缺陷探测率或者缺陷遗漏率、帕累托图、代码的圈复杂度、测试覆盖的精准度、代码规模等。

上线过程就是将沙箱验证过的上线计划再重新执行一遍，上线后测试人员进行回归，需求负责人（产品经理）进行验收。通过后收集相关数据自动形成测试报告模板，测试人员在其中填入测试评价后，由系统发给相关干系人。

上线并不代表着质量保障结束，后续还有收益回收、质量保障效果评价、项目复盘等环节。为本次需求而做这些动作仅仅是一方面，主要的目的还是为后续怎么持续优化质量保障来做思考。

好了，本文到这里就告一段落。最后，借用吴军老师《信息论40讲》里的一段话与大家共勉：在年轻的时候，或者事业刚开始起步的时候，以增加技能为改进的核心，以融入社会为基础；有了足够的专业技能，对社会有了了解之后，以增加见识为改进核心，以提供价值为目标；再往后，以洞察大势为核心，以理解多元文化为基础。最后，不论走到什么高度，都要常怀敬畏之心，在边界里做事情。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任

maxcomcn

说的不错

但是太理想化

质量文化不能普及 这些都是水中月

jingzizx

Miss_love

需求评审通过后，功能点自动在用例管理系统中创建出本次的测试用例初稿； 想了解一下 这个是怎么做到的。。。