近期趁着项目间隙，咱们团队开始着手审计产品接收功能自动化。基于堡垒机审计团队“天池”自动化框架，本宝宝在“天池”自动化平台舀了一瓢“圣水”，以为可以过把“圣女”瘾，没想到宝宝中毒太深……接下来受天池”圣水洗礼，浅谈下自动化用例设计。
自动化用例设计思路
针对自动化用例的挑选方面咱不多说，本次SAS一期自动化工程主要以设备生产自动化和基本接收功能自动化为主。
接下来主要说的是自动化用例的设计。主要考虑方向为将基本接收（回归测试）功能转为自动化用例，大体流程及思路如下：
说明：针对待自动化的手工用例（接收测试用例、回归测试用例、发布测试用例等），需要规范手工用例的编写，比如：操作步骤与预期结果一一对应。在进行手工用例设计与编写时，尽量预留字段说明该用例是否需自动化、是否已自动化、适用的版本、硬件平台等，考虑后续自动化的便捷性（如下）。
手工用例转自动化
手工用例转自动化用例，需要清楚该手工用例测试的意图、操作的每一步步骤及过程数据。将手工用例最小单元化后，才便于自动化用例最小单元设计。举个例子，审计产品的某个基本接收用例（HTTP网页浏览审计）转为自动化测试用例，用例拆分与设计图如下：
数据接口与流程接口剥离
一个成功的自动化测试设计与实现，通常融合了“关键字驱动测试”和“数据驱动测试”两类测试架构。该架构由核心数据驱动引擎、功能函数组件，以及支持库所构成。即拥有测试逻辑与测试数据相互分离的优点，又集成了关键字驱动的先进架构。
将数据存在独立的数据文件中，测试时输入数据直接从文件中读取，这样可以利用同样的过程对不同的数据输入进行测试。测试数据主要分为两大类：即全局测试数据和局部测试数据。
全局测试数据对于测试用例集中的所有脚本都是可见的、可共享的，通常是那些可配置的参数，是所有脚本的基础数据。如：设备IP、登录用户名、全局专业参数等。如下：
局部数据只对其所创建的功能脚本可见，可随机生成数据信息。如下，webformdata.py脚本中的数据信息仅适用于create_webform.py流程脚本。
功能（流程）接口实现
多次踩了“天池”坑后，笔者觉得在功能接口实现方面主要考虑实现方法的选取及实现过程中的性能问题。
1. 实现方法的选取
针对我们产品而言，目前实现功能接口的主要方法有：基于WEB界面实现、基于WEB接口实现、及集成测试实现。
(1) web界面实现方式（selenium）
WEB界面实现方式主要是基于UI层验证测试业务功能。未绕过前台校验，需要关注web界面各对象、策略等元素的增删改查操作的常性。
(2) web接口实现方式（webpost、urlpost）
主要基于WEB接口验证测试业务功能。绕过前台校验，勿需关注界面元素的增删改查操作的正常性。如某个测试用例主要目的是测试客户网络流量能否正常告警，该测试用例涉及策略的新建，而策略的新建操作可以理解为该用例的前置条件。那么对于策略的新建功能，则可以使用webpost、urlpost方法来实现。
(3) 集成测试实现方式（ssh）
主要从服务器后台接口验证测试业务功能。这一类方式通常运用在需要操作后台文件，如：设置专业参数修改xml文件、操作后台数据库等。
2. 考虑自动化实现中的性能问题
(1) 优化循环，循环之外能做的事不要放在循环内。
(2) 优化字符串。在字符串连接的使用尽量使用 join() 而不是 +；当对字符串可以使用正则表达式或者内置函数来处理时，优先选择内置函数。
(3) 使用局部变量，避免”global” 关键字。python访问局部变量会比全局变量要快很多。
(4) 不借助中间变量交换两个变量的值。使用a,b=b,a而不是c=a;a=b;b=c;来交换a,b的值，可以快1倍以上。
(5) 使用if is，使用 if is True 比 if == True 将近快一倍。
(6) while 1 比 while True 更快，while 1 比 while true快很多，原因是在python2.x中，True是一个全局变量，而非关键字。
(7) 使用性能分析工具。对于比较复杂的代码可以借助一些工具来定位，python 内置了丰富的性能分析工具，如 profile,cProfile 与 hotshot 等。在标准输出中看到每一个函数被调用的次数和运行的时间，从而找到程序的性能瓶颈，然后可以有针对性地优化。
自动化用例生成与合并
在“天池”架构平台进行流程接口合并时，笔者发现了一个问题：多个基本功能接收用例之间存在部分重复步骤，多个用例是秉承高内聚低耦合仍保持独立性呢，还是让其强关联进行合并呢？
- 独立的优势：可移植性、可阅读性强
- 合并的优势：执行耗时短
- 为了解答该问题，笔者用如下方格来举例说明。
存在如下三个手工CASE，其中同一坐标表示同一接口、或界面、或功能、或步骤。
case1 ：A1->A2->A3；
case2：B1->B2->B3；
case3：C1->C2->C3。
理论而言，自动化CASE也应为以上三个CASE，既然我们选择自动化的目的是将繁琐重复的手工用例交由程序来实现，为什么不让程序也尽量少做一些重复性工作呢？
进一步分析，不难发现，我们在进行自动化用例设计时，可以从以下两个方面考虑：
1. 上下文弱关联型case
在上方格中，若case1内A1-A3无关联（或弱关联），或case1与case2之间无关联（或弱关联）。那么以上手工case可转为如下自动化case：
case1：A1、B1、C1；
case2：A2->B2、C2；
case3：A3->B3->C3。
task任务：case集合{case1、case2、case3}
2. 上下文强关联型case
在上方格中，若case1内A1-A3有关联（或强关联），或case1与case2之间有关联（或强关联）。那么自动化case仍与手工case保持一致。比如：
case1中，A2为构造http网页浏览操作，A3为查看http网页浏览日志；
case2中，B2为构造ftp文件传输操作，B3为查看ftp文件传输日志。
为了保证测试结果的准确性，进行B2操作前，需要清空A3数据。此种情况下可以将其归为上下文有关联型case。
至此，笔者总算给自动化用例设计中多接口合并问题给了自己一个答案~~
自动化任务执行
在进行自动化任务执行时，笔者主要强调一点，重视debug调试日志包括用例执行的结果、脚本的输入输出参数、报错信息、任务执行的时长等，以便于我们排查问题及观察运行结果。
最后悄悄地告诉大家一句：“圣水虽好，可不要贪杯哦”~
如果您需要了解更多内容，可以
加入QQ群：570982169、486207500
直接询问：010-68438880-8669