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