同济大学软件学院特聘教授朱少民谈《测试，从哪里来，到哪里去》

朱少民：

各位嘉宾上午好！首先祝贺首届中国云测试行业峰会隆重开幕，这是Testin第一次举办这样一次大会，就像周老师讲的，Testin给我们提供了一个很好的交流平台，我们不同领域不同行业不同单位的测试人员大家齐聚一堂。

哲学上有三问 “我是谁，从哪里来，到哪里去”，今天这个题目是“测试从哪里来到哪里去”我想不会谈得很深奥，或者说我们不一定要清楚测试究竟从哪里来、到哪里去，特别是从哪里来可能大家不关心，不过大家关心的是到哪里去，将来测试向哪一个方向发展？今天讲有这个题目是有原因的，8月份看到这样一篇文章，歌手张翔，主要不是唱歌，原来是程序员、软件负责人，新技术探索者和布道者。不像一般理工男比较单纯，他在多个方面都有思考，而且思考也有深度。他写了一篇文章讲：软件测试人，你们正在逐渐失去一些东西。我看了几遍，引起我的思考。

有的网友也讲了，就像刚才提问同学讲的，现在大家太关注技术和自动化测试，但是质量究竟有没有保证，这个大家可能没有怎么想。就是你究竟达到什么样质量？或者全链路自动化测试可以完成，这个平台当然挺好的，那你测什么？测试依据是什么？有很多测试脚本，也不代表很好的覆盖或者能保证质量。人的精力是有限的，关注自动化技术，关注自动化脚本，那关注覆盖率就比较少了，所以从这个角度来讲，我们为什么要测试，或者做测试的目的是什么？这可能是我们初心。

无独有偶，另外一个叫高翔，两个姓不一样但是确实比较巧合，都在同一个月写了类似的一篇文章，他讲测试12年六道轮回后的初心能否找回？我们为什么要做测试，不仅仅是个人为什么做测试，我们单位为什么做测试，测试存在意义是什么？这个是值得大家思考的，所以从这两篇文章引出我今天的演讲题目——《测试，从哪里来，到哪里去？》。

我们主要是从三方面和大家一起交流，第一个是今天测试大概是什么样子、我们测试初心究竟是什么样的初心。最后谈谈我们测试的明天是什么样的。

今天的测试，在座的各位都有体会，你们现在想想：软件测试大概是什么样的？昨天吃饭的时候还在说今天的测试可能更忙、加班更多，我们每两周、每个月可能发布一个版本。早些时候，我们可能几个月发布一个版本，几个月有那么几天特别忙；现在，我们是一周要发布一次，可能每个礼拜都有一两天特别忙。谈到开发，我们总觉得开发一直进步的很快，因为我们大家也清楚这个软件日新月异，如果半年你不做软件开发或者软件测试，可能你觉得跟软件开发和测试就有点脱离了，就赶不上了。所以你看到开发的新模式有敏捷开发，有精益开发，DevOps这些开发模式。

技术方面更多了，编程语言日新月异，例如，我们看极客时间那个学习GO语言的人也是挺多的。除了这个，现在软件架构的改变，如微服务。还有人工智能、安全技术、容器技术，今天就有一个主题谈容器技术怎么在测试环境中的应用。

从环境来讲，Testin就是云计算的一个典型应用，当然也包括物联网、移动应用方面的测试。移动应用涉及面广，特别是像众测，大家每个人都可以提交Bug，这也是云测试重点领域之一。还有区块链、大数据和其他的技术。

我们测试究竟是怎么样的？我最近有篇文章畅想测试的未来，就有同学说：持续集成对整个质量有很好的作用。我们大家的确关注持续集成，不管你搞敏捷开发还是传统瀑布开发，大家都启动了持续集成或者说有的公司已经做得很好。所以，冒烟测试、静态分析等都会融合在持续集成里，另外也会倒逼开发改Bug，因为整个持续集成过程是挺透明的，有问题就及时暴露出来，这样的话，开发有时候想逃避问题也逃避不了。

另外，自动化测试应该是一个很热门的主题，今天大会分享这类主题也是比较多的。而且我之前做了一次调查，就是《软件质量报道》公众号做了一次调查，大家最为关注的就是自动化测试，这也很自然，因为我们搞计算机搞软件，为什么自己不自动化？为什么要手工呢？我们之前搞信息化，也是为了财务、税务等行业的业务处理自动化，那我们自己本身就是搞软件的，更应该自动化了。而且，测试跟开发最大的不同是回归测试方面，开发可能讲把新功能代码写了、不正确的代码改了，工作就做完了。测试，不仅仅要测试这些东西，还要扩展到其它区域进行回归测试，这对测试就是挑战，自动化是解决回归测试问题的最重要手段之一。

现在大家都建成了各种各样的测试平台。不考虑少数公司，70%、80%的公司都有测试平台，有的是自动化测试平台，包括自动化测试框架，和持续集成、开发系统集成起来，甚至和运维系统集成起来。当然，还有一些自动化没有做得很好，但是至少把测试数据、测试报告、测试结果很好地管理起来，包括缺陷管理，今天这方面来讲是比较成熟的。

其次，开源工具应用也越来越多，根据赛宝认证中心上个月发布的测试调查报告，显示开源工具使用占到60%到70%，其中测试管理工具是70%，而功能测试工具是60%。从调查结果看，大家越来越喜欢使用开源工具。开源工具有一个明显的好处，我们想要实现什么功能自己改就可以了，如果让某些商家改商业工具一个功能，那就不知道等到什么时候，特别是一个小公司提出一个需求，可能商家根本不理你，所以，大多数公司都会使用开源的测试工具。

静态分析相对来讲一劳永逸。静态开源工具，每天都可以用，虽然刚开始虽然要制定规则、引入新规则，包括构建持续集成环境等，需要做一些工作。但相对来讲，可以经常去运行、经常去检查代码以保证代码的质量，所以从这个角度来讲，后期的维护投入的工作量还是很低的，我们要经常做静态分析。数据显示，从2009年开始，国际上静态分析的比重就开始超过动态测试了，所以，静态测试值得大家特别关注的，或者说，某些公司已经非常关注了。但从调查报告看，静态分析还不是很好，大概只有30%左右，所以这个比例相对还比较低，我们希望能做到100%。

大数据和云平台测试已引起大家关注，Testin就是一个非常典型的例子，刚才Testin合伙人讲了已经运行了1.6亿的测试了，所以这个就不需要多讲了，大家能够体会到，后面也会有一些嘉宾和讲师分享大数据测试和云平台测试。

我们可以看到各式各样微信群、网站、培训机构，所以总体来讲，测试社区还是比较活跃的。

刚才讲了一些我们测试的好的方面、积极的一面，当然还有一些不好的方面。就像刚才提到的两篇文章，不少测试人员处在比较困惑和迷茫的阶段，或者说许多测试人员担心自己将来会被淘汰。大家以前谈测试重要性，一般会提到哪家公司呢？微软。以前，我们自豪地把微软作为测试的典范，他们是一个开发一个测试，甚至一个开发两个测试，例如某个web研发团队有900个开发，1800个测试，Windows操作系统研发团队，测试也是开发的两倍。差不多4年前，微软已经把所有的“测试工程师”头衔去掉了，都变成“软件工程师”，以前微软有一万多专职的测试工程师，今天据说只有300个测试工程师，那一万多个专职的测试工程师，说没就没了。

从这样的变化看，大家是有压力，但实际上，从一个公司来讲，不管怎么变，就是从微软来讲把测试工程师头衔去掉了，测试还在做，只是软件工程师来做，但是质量还是要的。所以质量这种基础设施建设还需要有，究竟达成什么样的质量，这个问题必须考虑，不能讲不要质量，也不能不要测试，测试肯定永存的。

质量最重要的是构建出来的，不是测试测出来的，我们经常这么讲，但是测试是很重要的、守护质量的一道墙。我们至少需要确保交付出去的产品是符合客户需求的。借助测试，好产品才能出去，差的产品留下来。更重要的，我们还有强调如何构建质量。现在有50%-60%公司搞敏捷开发，但是真正做单元测试或者对代码覆盖率要求比较高的，不多。我们做了调查，有大概50%以上的公司对单元测试没有要求，只有10%-20%公司对代码覆盖率需要达到80%的强制性要求。所以说，大家并没有更侧重构建质量，当然最突出的问题不在这里（单元测试），而是在需求。

大家之前也看过产品经理和开发打架，当然可能还没有杀人，但是，走到这一步都有可能，因为大家抱怨最厉害的问题就是需求变更、需求不清楚、需求不稳定。今天来看，质量最不好的部分可能是需求质量。

现在看各种招聘广告，招测试开发比较多多。招测试开发，究竟是招测试还是招开发，是不是大家有时候没有想清楚？测试开发招过来，很可能是重复构建自动化框架，有时候类似的自动化框架已经有了，不需要重新造轮子，但是总是想自己构建一套东西，当然，这样也好像领导交代。

另一个问题是，大家更热衷技术，对测试本身想得很少。测试本身最重要的是什么？大家没怎么想。例如敏捷开发，究竟怎么做敏捷测试，我觉得在座的许多同学还比较困惑，就是敏捷测试应该怎么做？应该有什么开发就有什么测试，有瀑布开发就有瀑布测试，有敏捷开发就有敏捷测试。敏捷测试跟瀑布开发中测试差别很大。什么是敏捷开发？就是快速迭代，这只是现象和特征，并不是本质。现在敏捷开发测试，瀑布模型测试，流程还不够有效，大家知道参与需求分析和讨论、参与代码评审，但许多时候我们是被动参与这个过程，或者任务压的比较紧，可能就没有时间去参加；有时候，有时间也没有主动地去做这个事。

测试肯定也一直在进步，不能说测试没有进步，只是某些方面进步快，某些方面进步慢。前面说了，大家都认为自动化测试重要、都很关注自动化测试的，但是现状并不是那么好。这是一个国际上的调查，可以看到2017年比2016年有进步，从26%提高到32%，大概三分之一公司或者团队大部分的测试是自动化的、超过50%。另外，这边数据显示更低一点，加起来只有23%超过50%，当然也有4%公司或者团队超过90%。非常优秀的公司可以做到90%，或者更高的自动化率，但是大多数还是比较差的。从这里来看大多数是手工测试的，这个比重比自动化测试要高。

我们看国内的调查，是我亲自做的调查，样本是750个，可以看到绝大部分自动化测试的大于80%的只有10%,还不符合20/80原则，实际上，我们只有10%的公司是优秀的，能做到80%的自动化测试。

然后50%以上的只有14.13%，加起来也就是24%，和国际上的调查23%比较接近， 24%和23%基本上算是比较客观的。我们看赛宝的最近调查结果，样本量比我的大，是1000多个，分布更广一点，但显示自动化测试更糟糕了。大于40%、50%以上，即两者加起来只有7.7%。所以，从这个数据来看，自动化测试效果还比较差，我们还没有讨论自动化投入产出比的问题。究竟投入那么大，产出怎么样？这个还需要做进一步分析，或者从刚才同学提问看，我们产出可能很糟糕，有时候自动化测试表面上看起来还可以，但是产出比这个投入还低，甚至低得多。这样的自动化测试也不能说不能做，刚开始总是要吃点苦或者要走一些曲线，最终可能会慢慢地把自动化测试产出/投入比有提高。可能需要经过这一个过程，不能一口吃成一个胖子。

今天还有一些其它的困惑，测试与开发有没有界限？因为现在我们讲开发和测试融合，当然有时候也不敢融合，有时候敢融合但又融合不起来。融合以后，测试是不是应该由开发来做？开发是不是可以做测试？当然以前我们交流过，开发做测试当然可以做，可能会有心理障碍、思维障碍，所以有了TDD、ATDD，测试驱动开发就能避免没有心理障碍和思维障碍，但是现在只有百分之几公司做TDD，不到10%，ATDD做的多些，比例也不高。

另外谁来做测试更好？做，谁都能做，开发可以做测试，测试也可以做开发，现在也有很多测试转开发的，就像微软之前的测试工程师，60%以上的都去做开发了。当然微软情况比较特殊，一些好的公司招聘开发测试要求是一样的，但是国内测试差别较大，不管怎么样，学一门编程语言、学一些开发技术，这本身并不是很难。从这个角度来讲开发做测试，测试做开发都可以，关键是谁做得好、谁做成本低？你两万招一个开发人员，我1.5万招一个测试人员，你觉得用两万开发人员做测试好还是用一万五的测试人员做测试好？而且我这里还是更专业的测试人员。大家一般也认可社会分工越细越好，越专业越熟练，越精通越好。当然还有不同观点，时间关系就不展开讨论了。

如何更好开展测试？刚才讲了敏捷测试，或者今天这种环境下我们如何开展测试？或者当我们追求五个开发一个测试、甚至七个开发一个测试的时候，我们测试应该怎么做？如何更好地反馈质量？你找到一个Bug自然是一个Bug，但是这不代表是质量，可能隐含了质量信息，你怎么透过Bug看到这些质量信息和质量风险，然后反馈给开发、让开发避免这种质量风险，这样才能对整个开发更有帮助。

测试的度量也一直困扰着大家，究竟什么情况下测试效率是高还是低？测试充分性、测试覆盖率等，一直是问题，或者有时候问：什么时候测试可以结束？测试结束标志是什么？你怎么判断测试是充分的？这些大家想清楚了吗？

我们刚才讨论了今天测试的情况，然后我们从开头的两篇文章来看，测试区的初心在哪里？我们为什么要做测试？相信大家可以理解——测试就是保证质量的一个重要手段，这应该是最基本的，但是还不够基本。怎么更好去理解我们做测试的初心？我觉得，最重要的初心还按时交付用户满意的产品，现在虽然说云平台，数据中心在自己的公司里，我们可以随时打一个补丁，随时更新一个版本，很快把Bug修正了，感觉今天漏掉一个Bug成本比较低。有些公司、有些产品是这样的，但是某些产品不是这样的，缺陷或Bug一定会对用户有影响，如银行或者其他金融产品就不能产生Bug，产生Bug问题可能会很严重。从这个角度看，不管怎么样，不管你用敏捷还是用什么，中国有一句古话，欲速则不达，你发布版本快，不一定代表效益就高。软件工程有一个问题，就是很难做对比实验，让一个团队用瀑布模型、另一个用敏捷模型，我们比一比究竟谁效益高，没法做。

但是从初心来讲，我们最终要交付用户满意的产品，客户还是上帝，我们要让客户满意，客户要求和期望体现在质量上，测试有很多其它的价值，一般来讲，特别是今天搞敏捷测试和敏捷开发，测试最重要的是发现Bug，我们尽快地、尽可能地把Bug找出来。什么是缺陷？自然是质量的对立面，有时候问测试工程师：你知道产品质量模型吗？使用质量模型吗？许多测试工程师不知道，对质量没有很好理解，我认为他们就不是合格的工程师。对质量不理解，怎么做测试？

缺陷的确不是测试人员造成的，是程序员写出来的、是产品经理错误想法或者错误概念造成的……但是这些都需要在整个过程去很好地评审或者通过更好的一些措施预防这些问题发生。只要有人就会犯错误，全过程做测试，不管敏捷还是传统的，应该是毫无疑问的。

而且需求还是最重要的，今天来看，大家可能把“需求变更”看做是正常的，不变更是不正常的。按照敏捷宣言最后一句话：拥抱变化胜于遵循计划，大家觉得变化是正常，需求变更也是正常的，但我觉得敏捷宣言里讲的“拥抱变化”一定是用户真实需求的变化。如果是真正需求在变化，当然你要拥抱它，及时响应用户变化的需求，不是因为你对需求不认真、不重视，自己觉得以后有时间去修改它，反正代码总是容易改、反正我可以不断地迭代，所以对需求不重视，我想怎么写就怎么写，错了就错了、下次改就是了。这样的想法你觉得是敏捷精神或者敏捷宣言里所提倡的价值观吗？我认为不是，你们觉得是吗？我想也没有多少人会同意。因为这样一定会浪费公司的钱、一定增加开发的成本，我们产品经理要把需求写好。所以，这个图比较经典，大家可以看到越到后期这个成本越高。测试价值不仅仅是发现问题，还提供质量反馈，监督问题解决，提高产品质量，可以揭示质量风险，缩短开发周期。测试可以评估和提高质量信息，过程改进、持续改进是公司永远的一个主题，究竟改进得怎么样、有没有改进、质量有没有提高？这些都需要靠测试提供数据来检验改进的效果。

然后就是根因分析，针对产品线上漏掉的Bug进行根本原因分析。产生Bug给公司带来多大成本，这个值得核算，和发现一个Bug投入多大进行比较，这样就可以看到测试不是成本中心，它也是利润中心，能给公司带来利润，带来长期竞争力的。最终来看，一个公司能否长久存在或者说能否长期发展，还是要靠质量，就像华为公司，发展到今天也一直重视质量，今天来看华为差不多拥有最多的测试人员，大概有一万测试人员。我还是认为，质量是企业生命力，今天也不为过，虽然今天的互联网服务要求更快地交付产品，竞争更激烈，效率和速度是很重要，但是长期来看，最终还是需要靠质量竞争的。

我们如何做好软件测试？需要好的基础设施、好的流程，好的框架，曾经有一个互联网公司，开发很难做、测试也很难做，交付一个功能特性特别累，为什么呢？是产品架构不好，被测系统不好，这也是问题的源头，这个系统不可测你怎么测？我们测试的策略是什么？我们组织文化如何？对测试重视不重视、对质量重视不重视？一般来讲，对质量不重视，不可能对测试重视。

策划、分析、设计、执行、评估这些是最基本的测试活动，每个环节怎么做好，需要我们认真的考量。你的技术、工具、策略和流程或者基础设施和方法是不是适当、是不是适用，也需要考量。当然，也包括管理、流程。例如，敏捷的站立会议，要求15分钟、只能回答三个问题，以前CMMI严格，也没规定开会只能开多长时间。哪有这么强制、这么野蛮？不应该这样，因为每一个团队都不一样、每一天都不一样。从侧面看，流程也很重要，虽然敏捷宣言里有一句话：个体与协作胜过流程和工具。

这个是测试预言（test oracle），测试人员每天都要碰到的，测试结果对不对就是要基于这个来判断，这是测试结果的判断准则。过去可以对照需求文档可以做验证，今天拿不到这样的需求文档，还需要考虑竞争对手的产品，那你怎么判断竞争是对是错。需求描述更不清楚，更不具有可测性，这些都是测试风险。测试风险，不仅体现在测试预言上，还体现在测试的输入、操作、上下文等方面。输入空间很大，难于覆盖，手机操作也很多，规则之间还有组合，然后今天运行环境也很复杂。基于风险的测试策略始终有价值，今天，竞争更频繁，开发周期更短，基于风险的测试则更有价值。

大家都熟悉这座金字塔，这应该是自动化测试金字塔，建议少做手工测试、或UI方面的自动化测试，更多做API测试、单元测试的自动化。还有两座金字塔，大家经常谈测试往往把设计看成核心，但其基础是分析。如果哪些地方有风险，哪些地方需要关注、重点测试，这些分析不清楚，设计可能是空中楼阁，或者说设计也很设计好。大家容易忽视测试分析。另外，也要关注整个测试过程的评估，你执行有没有到位、设计当中有没有问题或者执行时候有没有执行测试用例之外的测试？这些都需要评估，如果发现新的问题，可以帮助我们改进测试。

还有，就是我们经常讲的，你要去分析，从业务角度去分析，业务是最高层次。你完成了所有功能的测试，老板问你：业务会不会有影响、业务会不会出问题，你可能回答不了这个问题。我们开发所有的产品或者做所有的测试，最终都是为了业务，如果忽视了业务大谈功能特性，这也是错误的。所以最好一座金字塔告诉我们，应该从业务开始，从需求到功能特性到用例——用户行为分析，然后再到每一个用户行为的应用场景，最后再分解成测试用例。如果沿着这条路走通了，测试用例或者测试就有良好的质量保证。

怎么衡量你的测试效益、测试效果呢？测试怎么做到足够好或者刚刚好呢？一方面体现了你的质量理念、质量目标，另一方面就是大家一直考虑的——测试的充分性和测试效率。代码、功能特性或者刚才讲的业务，而且不仅仅是控制流，还有数据流，真正度量起来，是2乘3，从6方面衡量测试的充分性。

测试用例质量如果很低，再多测试用例也没有价值。有时，直接衡量交付的特性，这个可能更有价值。怎么去衡量你的效率呢？可以从两方面考虑，我跟这个行业比怎么样，其次，自己水平虽然低，但是每天都在进步，这也很好。

谈一下最后一个问题——测试的明天。测试明天究竟会怎么样呢？除了刚才讲的微软的例子，这可能也是一个现实，大家也是要面对。另外，就是测试本身来讲，我们测试是不是要快？大家都在追求快，竞争肯定越来越激烈，越来越要求我们产品发布更快，测试自然要进行得快，就像前一段时间写的文章讲的，不能让测试成为敏捷开发的瓶颈。许多时候，测试就成了敏捷开发的瓶颈，怎么样让它不成为瓶颈？怎么做得更快、做到高度自动化？自动化测试现状不好，但我们还需要做，因为如果要快，还是需要自动化。

我们怎么给它赋能，我两天和老同事聊，有些团队没有专职的测试人员了，开发自己做测试了，但没有衡量测试做的怎么样、开发测试能力怎么样，这是很危险的。谷歌还有一个对团队测试能力的认证，或者说团队需要有一个测试教练及其辅导，培养和提高团队和开发者的测试能力。如果没有这种机制，就让开发者做测试，谁知道结果怎么样。

系统越来越复杂，新的技术，包括物联网，将来测试会更具挑战。

我们测试要求越来越快，一个测试超过60秒就没有价值了，每个测试要低于60秒，这算是一个测试用例执行的时间。假如，要求我们一个小时完成一万个测试用例，你怎么做？手工测试不可能，自动化测试也不一定可能。如果基于UI的测试肯定是不可能的，就算用10套环境也不行，更何况一般情况下很难拿到10套测试环境，许多单位部署两套测试环境都比较困难。

这就需要基于API的测试，包括基于API的功能测试、性能测试，特别是要施行契约驱动测试，它会带来这些好处（时间关系，就不能详谈了）。

现在的自动化测试，测试脚本是自己开发的，这个投入不算小，还特别大，怎么算自动化测试呢？只是自动化执行测试——测试执行是自动化的，所以不算真正的自动化，真正自动化是基于模型测试（MBT）的自动化，自动生成测试用例、自动生成测试数据。MBT也在增长，根据调查结果，过去达到百分之十几，华为等一些公司，很多年前做了一些探索，最近一两年也有一些成效。

为什么自动化测试做的这么困难，因为没有用MBT。有时候需求模糊，通过抽象建模慢慢就把需求搞清楚了，这些收益大家可能看不到。一个好的TA是这样的（见PPT），有时候业务复杂，BDD是有困难的，但是ATDD一定能做的，对需求、开发、测试都是有帮助的。全过程的、高度集成的、跨平台的自动化测试框架，是一个比较理想的框架，大家仔细看一下这张图，就比较清楚了。

今天上午一个主题演讲会谈到人工智能，这里谈AI，不是要赶潮流、趁热点，但实际上，AI时代已经来了，我写了一篇文章介绍AI工具，有一万多的阅读量。

再拿出这个测试模型来看，刚才讲过测试输入、操作等，这个输入空间是特别大的空间，通过人工智能算法来搜索和优化这个空间，自动生成测试用例、测试数据，模拟用户操作，就可以提高测试效率和覆盖率。中间这里，可以基于代码生成单元测试的脚本，虽然还不是很成熟，但是还有一些很好的应用成果，然后程序执行过程，不仅仅通过源代码，而且可以借助二进制文件的分析，将静态分析和动态分析结合起来，进行更深入、更准确的分析，因为经过编译，我们更清楚代码如何执行、执行的路径有哪些。业务规则可以学习，测试过程可以优化，这里AI可以做很多的事情。以前，蜕变测试就是解决test Oracle的问题，现在可以借助AI来改进蜕变测试。甚至结合AI自然语言处理，完成对需求的认知来建立test oracle，这些都是未来要研究的地方。

以前为其它公司做过稳定性的AI工具和模型，然后结合代码分析可以做得更精细些。之前，也有很多代码的依赖性分析、代码比较分析，今天借助AI，CLDIFF做得更好，不仅知道代码之间的差异，还能知道代码差异之间的关系，更精细的分析，更好服务回归测试。

大家知道游戏测试也是最难的，之前主要是手工测试，要去写自动化脚本几乎不可能，只有通过AI来做。我们可以将蒙特卡洛概率算法和人工智能算法结合起来，去模拟人工操作，可以通过多个小机器人去达到模拟效果，最终通过150次模拟，达到很好的效果，甚至超过一般游戏玩家。

之前可能用随机算法来完成遍历测试，但是那个操作空间是很大的，要么效率很低，要么会走不完、死机。基于人工机器学习，这个可以实现。刚才讲了MBT，如果将MBT和AI结合起来，可以达到更好的效果。

总的来讲，测试发展趋势：

第一，会看到“需求即测试”。我们为什么要有ATDD/BDD，就是要让产品、开发和测试在需求层面达到一致，这是最有效的，因为需求始终是源头，需求不解决，设计、代码和测试一定会浪费很多成本。

第二，今天软件不是一种产品不是服务，我们要支持从开发到运维这样一个完全贯通的DevOps集成模式。

第三，分层测试或者基于API驱动，基于契约驱动测试应该越来越多。我们被测系统会慢慢变成大中台结构、微服务架构，这时更多的测试自然就是基于API测试。

第四，我之前写过一篇文章谈到今天如何解释“测试”，等于“已知的检测+未知的试验”。未知的、新的东西，不知道怎么测的，需要以探索式方式测，如果知道怎么测，就可以交给机器和工具去测。如果结合人工智能，后来我由写了一篇文章（“对软件测试的幻想”），探索式测试就是给机器提供数据，就是训练这个模型，因为人工智能需要数据，数据从什么地方来？就是探索式测试出来的数据。以后测试应该是这样的：人只做探索式测试，不需要写测试用例和测试脚本，背后自动生成测试脚本。这个脚本不同于以前的录制回放，那种是机械的，你想到哪里、测到哪里、录到哪里，没有想到不会加的。但是，加入人工智能以后，你没有想到的，AI会扩充相关的测试用例，没有覆盖的它也会覆盖，经过优化的测试脚本。你手工做的测试相对比较少，但是生成的测试脚本是完整的、全覆盖的。达到这样的效果，也有赖于建立良好的模型。

最后，测试人员做创造性、建模性、分析性的工作，其它的测试工作都交给建模工具、AI测试工具去做。

谢谢大家！

本文来自：2018中国首届云测试峰会，举办方：Testin 云测

Testin，让应用更有价值：www.testin.cn

关注公众号“Testin”，了解更多测试行业动态和测试知识。

同济大学软件学院特聘教授朱少民谈《测试，从哪里来，到哪里去》相关推荐

软件测试方法与技术第三版课后答案完整版,软件测试方法与技术朱少民第三章答案部分答案.docx...
软件测试方法与技术朱少民第三章答案部分答案 3.综合应用边界值和等价类划分方法设计相应的测试用例,包括尽可能多的无效等价类:输入三个参数作为边,分别满足一般三角形,等腰三角形和等边三角形.答:边边边输 ...
软件项目管理-敏捷先锋朱少民
前言软件项目管理相关内容第一章:概述项目管理的生命周期项目管理的生命周期--"启动.计划.执行.控制.结束"演进顺序项目的概念项目是为完成某个独特的产品或服务所做的一次 ...
软件测试方法和技术，朱少民，第三章习题答案
1.逻辑覆盖方法中,语句覆盖.判定覆盖.条件覆盖和基本路径覆盖,哪一种覆盖率高?为什么? 答:基本路径覆盖的覆盖率高,顾名思义,基本路径覆盖就是设计所有的测试用例,来覆盖程序中所有可能的.独立的执行路 ...
重读朱少民《全程软件测试》
今年是在凡客度过的第三个年头了,回想起去年年底总结的时候,觉得是比较收获的一年,俩个测试团队组建成功,人员基本上都配齐了,加上各种培训,各个成员都能按照要求完成工作,虽然那一年过的很累,很苦,加班很多 ...
推荐文章：《同济大学软件学院万院长谈择业》
同济大学软件学院万院长谈择业一.关于企业计算方向企业计算(Enterprise Computing)是稍时髦较好听的名词,主要是指企业信息系统,如ERP软件(企业资源规划).CRM软件(客户关系管 ...
同济大学软件学院万院长谈择业（转载）
本文乃同济大学软件学院王院长(JacksonWan)在同济网论坛发表的帖子<谈谈软件学院高年级同学的学习方向>,再此转载用于备份一.关于企业计算方向企业计算(Enterprise Co ...
同济大学软件学院院长谈择业—关于嵌入式方向
同济大学软件学院院长谈择业-关于嵌入式方向一.关于企业计算方向企业计算(Enterprise Computing)是稍时髦较好听的名词,主要是指企业信息系统如ERP软件(企业资源规划).CRM软件 ...
同济大学软件学院万院长谈择业 [zt]
同济大学软件学院万院长谈择业一.关于企业计算方向企业计算(Enterprise Computing)是稍时髦较好听的名词,主要是指企业信息系统,如ERP软件(企业资源规划).CRM软件(客户关系管 ...
同济大学软件学院万院长谈择业- -(转)
正好... 同济大学软件学院万院长谈择业- - 一.关于企业计算方向企业计算(Enterprise Computing)是稍时髦较好听的名词,主要是指企业信息系统,如ERP软件(企业资源规划).CR ...

同济大学软件学院特聘教授朱少民谈《测试，从哪里来，到哪里去》

同济大学软件学院特聘教授朱少民谈《测试，从哪里来，到哪里去》相关推荐

最新文章

热门文章