软件测试川模型下 络安全产品的自动化测试架构设计与实践分享3

直接给大家做案例分享。我们做整个架构设计的时候先经过了两个步骤，第一个步骤是测试体系与测试平台的整合；先做的一件事情是把模板进行整合，无规矩不成方圆，大家也都理解，我们是把整个测试用例的模板、测试的计划模板、 告模板全都进行平台化的整合，它可以让我们手动编写，但是编写的所有内容都能无缝与自动化测试的平台进行翻译和提取，这是第一步要做的；第二步是做方法的整合，把一些测试的设计方法，测试的执行方法和一些分析方法进行了合规化的统计、标注；第三是规范，测试流程、测试评审的规范，缺陷管理的规范，这是第一步做的测试体系与测试平台整合的内容。

第二部分是用例的标准化，大家都理解了，第一是可重用的用例，为什么要说这一点？是因为我们真正要设计的时候会发现，很多测试工程师写的用例，让第二个人看的时候用不了，或者说他看不懂，甚至他要再经过二次加工，这个时候其实它的利用率、效益比也是很低的。作为公司是不允许这样做的，甚至他应该是想办法解决的。这时候我们这个平台做了一件事情，是把很多通用的测试用例进行了一些标准化的设计。比如说测界面的、测UI的、测兼容性的、测试安全性的，这些所有的用例，整个提出了一套自动化的用例标准库，任何一个新入职的员工或者一个工程师他进了这个标准库的时候就完全可以解决所有的问题，就可以重用了，重用之后的下一步就是复用，不同测试工程师共享测试用例库，这是复用的概念。

该完善的完善，下一步是整个流程的把控，这是整个项目，这个流程从一开始的调研阶段直到最后验收结束和提供的测试 告，把它规定的都很清晰。这里面也是分了三条线，大家可以看出来，最上面的线就是验收方案设计标准，中间有一个需求级和业务级测试的流程的把控。中间有一个测试环境的搭建，这个测试环境是和业务级测试以及需求级测试是相同的，他们会用同一套环境来进行实际的设计与测试。执行的时候，我们用到最多的就是这几个模式，使用这套模型测试的时候用的最多的是基于任务、探索的、基于风险和业务场景的测试方法论。大家可以看一下。

说一下平台，大家看过这个平台有一个最大的印象是“这不是一个简单的自动化测试的软件”，它是真正的一套架构设计的东西”为什么？大家看最底层，我们真正细粒化的是发现我们连虚拟机群、硬件群、测试标准区库、测试案例库、产品案例区、交互区全都在这个平台里面，而这里面我们真正能用到的自动化的平台，其实是中间测试区的测试控制台、工具池以及执行规程做的内容。这个时候我们是真正的打通了所有的人、所有的范围。这样平台算搭起来的，整个平台监控端，这个平台监控端是给CTO、CEO等各种O看的，他们能看到我们真正的项目管理、测试管理还有一些产品研发测试的实际工作的情况。

我们在整个部署过程当中出现过一些小插曲，很多用户不理解“你这个自动化测试为什么非要把我的环境也给我改造、甚至于把我的硬件群、虚拟机群都相应的变更？”我说，不要把自动化测试想象成狭义的测试软件，其实它是很宽泛的。比如我们测试一个软件安装卸载到底正不正确，有人说我就得用自动化测试工具，那么如果我们用一个文件目录监控软件，它能干吗？在你安装软件系统的时候把这个软件打开，里面所有文件目录的变化，文件的MD5值、注册表的更改以及链接库的更改都能监控到的话，这也符合自动化测试。因为下一次再进行安装卸载时，发现它更改的地方只是开发所涉及到的三个文件，这三个文件所代表的含义、功能对大家来说是明确的，你们测试的时候是不是有针对性的知道重点要测哪些内容了？这个事情，像测试区工具池一样，不一定是测试软件，一个很简单的文件监控软件也是测试工具，同样的，一些注册表更改的软件也算是，哪怕自己写个脚本，写批处理文件，写个文件监控也可以。这时不要把测试自动化想的太窄了，很多客户找我或者一些朋友，他说你教我们做一下自动化测试吧。这些是我们能替代的东西，一旦把环境、测试区、资源区合在一起的时候就真正实现了自动化测试，这么一个框架。