会上，安畅物联网CEO、川测试模型创始人李龙做《在软件测试川模型下网络安全产品的自动化测试架构设计与实践分享》。李龙指出，“在进行软件开发或软件测试的项目之前，需要做整体流程的把控。尤其是把测试人员工作的切入、切出方式、与研发的无缝对接方法以及提高软件质量保证的意义提高到一定程度上。而川测试模型，在借鉴前辈的模型实践基础上，创新性的使用了三条测试实施方法正好做到了这几点。”
以下为李龙演讲实录：
很高兴今天和大家做一个分享，我没有想到刚才陈老师作为中国平安的技术专家，我一直以为他会分享技术内容，结果一听是很多有关软件测试生涯的哲学问题，确实受益匪浅。借着刚才陈老师说的话题和大家分享一下，我这个题目起的有点窄了，但是其实是很宽泛的话题，主要是以川测试模型为指导下，我们在测试开发过程当中做的一些自动化测试构架的设计以及实践的分享。
首先讲一下软件测试模型的使用情况调查，这个调查我是在2014-2015年之间做的，只是取了两百多个单位，但是这两百多个确实是国家一些比较前沿的，可以理解成TOP100或者TOP200以内的企业做的一些测试模型实际的使用情况。但是结果其实不太理想，大家可以看一下，最终有87%的企业不清楚或不知道我们到底使用什么模型进行相关的软件测试或者过程管理的。
原因可能有这些，测试根据开发的思路推进，没有明确的时间版本或者相关概念，团队里更改需求或者人员指派比较随意。但是我们通过刚才调查出来的内容发现，之前我们听说过一些模型，比如V模型、W模型、H模型或者瀑布模型等模型。第一个问题，测试与开发的关系、归程到底是否是互融互通的，比如，V和W模型是从上往下严格的节点关系，这种节点关系很难反推，需求确定了、测试方案确定了、开发确定了，我们测试的时候，一旦后面反推这个项目的时候，基本上很难推翻上面的节点，这时会导致测试/开发工作量成倍的增加，质量也很难把控。还有比如，测试对质量的保证意义所处在的层级，咱们都很清楚，其实我们应该尽早的、尽快的将测试嵌入到整个软件项目或者一个开发周期里去。但是，实际上很多企业都会发现，等到研发工程师或者研发部门把他们的设计架构都已经做完了，可能才会告诉我们，你们开始进行测试吧，去写测试需求说明书、写方案吧，这个时候我们已经在滞后了，虽然市面上说我们应该提前介入但是因为没有合适的规程、规范，导致我们没有办法提前进入。当然所有的原因我总结的很简单，我们现在所使用的一些测试的管理规程、模型，是从国外引进的。因为我是从二零一几年开始创业，到现在为止创了n个公司，发现了一些问题，我们应该去改变一些东西，用我们自己的规则去想办法适合我们现在软件行业国情下的软件测试的方法模式。这个时候我才真正开始研究一套真正适合在中国发展的软件测试的模型，我起的名叫川模型。
大家看这个图可以理解一些，这套模型今天算是第二次和大家进行分享，最早一次是在上海，上海十周年庆典上做了一次分享。之所以叫川模型，是因为在整个软件测试过程当中我们是分了三条业务执行线的，最左边一条业务执行线属于验收测试的实施模型；中间这条执行线是需求级的，而最后一条执行线是属于业务测试实施的流程。这样在我们整个软件测试过程当中，其实是把一个测试团队分成三类不同的人群，而不是把部门分成了比如自动化组、性能组、功能组、安全性组。不是这样划分的，我们划分的模式是把测试团队划分成三条业务执行线，他们执行的内容是有区别的。那么，我们整个一套系统进行敏捷测试的时候怎么办？要快速的迭代出来，快速出测试报告、测试结果，这时我们最多使用的是业务测试的实施流程，相当于我们使用基于场景的、风险的、探索的测试方法论来快速的测试20%的模块，而这20%大家也可以理解是八二法则的划分，它可能隐藏着80%的缺陷，这时候我们就能够很快的迭代出这些内容，这些迭代的内容会应用到敏捷的方法，我讲的是一套流程管理体系。
我们相关行业在实际做产品的过程中，不可能每一次都说“我选择用户使用最多的一些功能”。它可能只占20%的功能，实际上是业务场景80%以上需求的时候，不能完全使用业务场景的方式来测试，我们用什么场景？同时进行着需求级测试，需求级测试是大部分企业或者合作单位用的最多的，是从需求的，比如案例设计、和概要设计的对称、对接，中间完成一些测试的构建，比如，包含单元集成、功能、自动化、性能稳定性测试，还有相关的安全测试等，这个就比较多了。还有一条线是我们遇到大部分的情况，我们是要把产品交给用户的，而用户实际上他所需要的东西，就是我们一开始和用户、甲方谈出来的，他的验收测试的内容。一开始是要把验收测试评定出来的，而这时候在有个验收标尺的时候，把验收测试里面的功能性能项解决掉，就达到了验收执行流程。而整个三个方面是在模型提出来到现在试用过程当中有几个大的企业，在使用过程当中确实是把测试的质量、覆盖率已经提高到一定档次了，因为它是一种方法论，它是和V模型、W模型相等平的，这套模型在2015年中科院某所和发改委等这几个单位做过发表，还有在国际上做了一些学术的论文，大家可以了解一下。
这套模型解决的问题：1、提高了测试人员的使命感和荣誉感，在这个过程中让他们认同我们作为测试工程师、测试负责人，我们从项目一开始就应该切入了，我们的荣誉感、使命感这个时候是最强的。2、减少过程的冗余，尽早的不断地进行软件测试和以测试者引导开发等等。这是这些模型解决的问题。
刚才把模型介绍了一下，没有实际的方法是纸上谈兵，所以今天我把实际的方法给大家摘出来一些，主要介绍这几个部分：1、对于提前准备测试环境、数据的工作的方式方法。2、在自动化测试平台搭建的方式方法上。3、专项测试的设计方法；4、基于业务、风险、探索的测试设计方法和框架的整合。5、测试数据资料的完备性与可追溯性设计与体系的挂钩。
这里讲了基于场景自动化的设计，着重说一下思维导图的。口头聊一下思维导图的设计，因为上一次分享聊完之后，很多朋友特别关注基于思维导图如何进行用例或者测试方案的设计和分析。
首先给大家解释一下我们会把思维导图分成两大部分，一个是用例分析的模块，另一块是我们需求分析的模块。而需求分析它是分为三步的，第一步是我们的明确需求分析；第二是继承需求；第三是一些隐含的需求，明确需求大家都理解，我们在设计测试方案或者相关项目方案的时候，明确需求是很容易获取到的，它包含一些和甲方的项目开发合同，也包含一些产品的使用说明书、需求说明书，这是我们可以看到的明确需求相关的内容。继承需求是什么，我们在设计用例、方案的时候，这套产品不是平白无故过来的，一定会有一个对标的产品或者对标的项目，我们就要学会把它的对标的项目拿过来，比如，同版本的或者是不同版本的，然后相同行业软件的，但是不是我们公司自己软件的时候，我们把他们的需求给提取过来，然后去做一些测试需求的提取；第三个隐含的，行业内部或者我们的经验值，像军工行业、安全行业测试的时候有一些国际标准的，国标体系、国家强制标准、行标，而这里面的内容其实是很多的，但是我们作为测试人员去设计的时候，往往会忽略掉这块，因为我们的甲方/客户可能不懂，或者我们的产品经理也不明白，比如，我们的安全系统或者所有的系统、特种装备设备，它的性能要求到底是怎么样，高低温要求到底是什么状态，甚至我们进行一些动态的探索、探测渗透的时候达到什么情况才能满足这个要求，有些东西是国标、行业标准甚至国际标准，是完全已经规定好了，但是我们设计的时候没有想到的话，就一定会漏测或者测的准确度是不高的，这是我说的思维导图需求分析的左半部分。
右半部分是用例分析的模块方案设计。它主要包含六大模块，第一是功能性测试，第二是性能测试，第三是兼容性测试，第四是稳定性测试，第五是安全性测试，还有一个是安装性测试。这六个测试的用例或者方案设计的大体模型把我们整个测试的场景已经完全给涵盖进去了，这是用例分析。后面还有一些分级的问题，我们设计相关的思维导图的时候分三个等级，因为大家没法形象的看这个事情，大体聊一下。第一级就是分为安装性、功能、性能、稳定性、兼容性、安全性这样几块；第二级是我们对它进行的不同的功能细节的划分，比如像安全性测试一样，我们划分成平台安全性、数据安全性、业务安全性，这么三个大块，不同得大块代表的含义大家也都大体理解一些，我们测试的时候不可能只测试我们的数据安全，大部分人都说，安全性测试用AppScanner就可以了，这个也是很难的，它有些测试不全，因为我们还有平台安全，包含对于内存或者操作系统，尤其国家现在对于国产化的要求，我们会用中标麒麟或者达梦数据库，金蝶或者WPS。
直接给大家做案例分享。我们做整个架构设计的时候先经过了两个步骤，第一个步骤是测试体系与测试平台的整合；先做的一件事情是把模板进行整合，无规矩不成方圆，大家也都理解，我们是把整个测试用例的模板、测试的计划模板、报告模板全都进行平台化的整合，它可以让我们手动编写，但是编写的所有内容都能无缝与自动化测试的平台进行翻译和提取，这是第一步要做的；第二步是做方法的整合，把一些测试的设计方法，测试的执行方法和一些分析方法进行了合规化的统计、标注；第三是规范，测试流程、测试评审的规范，缺陷管理的规范，这是第一步做的测试体系与测试平台整合的内容。
第二部分是用例的标准化，大家都理解了，第一是可重用的用例，为什么要说这一点？是因为我们真正要设计的时候会发现，很多测试工程师写的用例，让第二个人看的时候用不了，或者说他看不懂，甚至他要再经过二次加工，这个时候其实它的利用率、效益比也是很低的。作为公司是不允许这样做的，甚至他应该是想办法解决的。这时候我们这个平台做了一件事情，是把很多通用的测试用例进行了一些标准化的设计。比如说测界面的、测UI的、测兼容性的、测试安全性的，这些所有的用例，整个提出了一套自动化的用例标准库，任何一个新入职的员工或者一个工程师他进了这个标准库的时候就完全可以解决所有的问题，就可以重用了，重用之后的下一步就是复用，不同测试工程师共享测试用例库，这是复用的概念。
该完善的完善，下一步是整个流程的把控，这是整个项目，这个流程从一开始的调研阶段直到最后验收结束和提供的测试报告，把它规定的都很清晰。这里面也是分了三条线，大家可以看出来，最上面的线就是验收方案设计标准，中间有一个需求级和业务级测试的流程的把控。中间有一个测试环境的搭建，这个测试环境是和业务级测试以及需求级测试是相同的，他们会用同一套环境来进行实际的设计与测试。执行的时候，我们用到最多的就是这几个模式，使用这套模型测试的时候用的最多的是基于任务、探索的、基于风险和业务场景的测试方法论。大家可以看一下。
说一下平台，大家看过这个平台有一个最大的印象是“这不是一个简单的自动化测试的软件”，它是真正的一套架构设计的东西”为什么？大家看最底层，我们真正细粒化的是发现我们连虚拟机群、硬件群、测试标准区库、测试案例库、产品案例区、交互区全都在这个平台里面，而这里面我们真正能用到的自动化的平台，其实是中间测试区的测试控制台、工具池以及执行规程做的内容。这个时候我们是真正的打通了所有的人、所有的范围。这样平台算搭起来的，整个平台监控端，这个平台监控端是给CTO、CEO等各种O看的，他们能看到我们真正的项目管理、测试管理还有一些产品研发测试的实际工作的情况。
我们在整个部署过程当中出现过一些小插曲，很多用户不理解“你这个自动化测试为什么非要把我的环境也给我改造、甚至于把我的硬件群、虚拟机群都相应的变更？”我说，不要把自动化测试想象成狭义的测试软件，其实它是很宽泛的。比如我们测试一个软件安装卸载到底正不正确，有人说我就得用自动化测试工具，那么如果我们用一个文件目录监控软件，它能干吗？在你安装软件系统的时候把这个软件打开，里面所有文件目录的变化，文件的MD5值、注册表的更改以及链接库的更改都能监控到的话，这也符合自动化测试。因为下一次再进行安装卸载时，发现它更改的地方只是开发所涉及到的三个文件，这三个文件所代表的含义、功能对大家来说是明确的，你们测试的时候是不是有针对性的知道重点要测哪些内容了？这个事情，像测试区工具池一样，不一定是测试软件，一个很简单的文件监控软件也是测试工具，同样的，一些注册表更改的软件也算是，哪怕自己写个脚本，写批处理文件，写个文件监控也可以。这时不要把测试自动化想的太窄了，很多客户找我或者一些朋友，他说你教我们做一下自动化测试吧。这些是我们能替代的东西，一旦把环境、测试区、资源区合在一起的时候就真正实现了自动化测试，这么一个框架。
如图，这是几年前搭建起来的，这就是一套环境，这么多交换机、路由器之类的设备，我们测试是离不开交换机、路由器的，但是你想领导会让你买那么多吗？不能买，我们自己去构造、去改、去写，因为大家作为技术都知道，我们是有软路由的，随便找到一个功能机安装软路由软件，代表路由器，一千块钱买个八口的软路由的工控机，安装软路由软件至少可以替代四台路由器，这时候我们是把测试的数据准备出来，用到很多的工具库、工具池，把任何来的一套系统，测试的东西都可以在里面的任何一个节点无缝的运行，把测试效率提高了很多，这是整个环境的状态。
自动化部署的平台图，有个上位机、下位机、交换机还有云服务端的服务器进行相关的测试，这里面测试举的例子是给他们做嵌入式行业或者安全行业的东西，对于互联网金融也一样，我们只需要把下位机连接到被测系统上，通过上位机的定位，调取云端服务器的资源。那些资源是什么，可能刚才跟大家说了，就是我们的工具池、测试库、测试区、硬件环境区相关的东西，就可以完全进行相关的调取、监控。
这里有几个简单的页面，大家可以看一下，已经集成了很多性能测试、安全性测试、自动化、环境搭建等的内容。还有写的小软件，我们可以自己定制，现在代码开发成本这么低，可以用Python、用易语言的模式，写出我们想要的东西，其实是很简单的，还有自我保护、自动化测试工具的情况，我们看软件自己的保护能力、文件变化的情况、注册表、目录、他们监控的状态。
今天，就给大家分享这些内容。
