Funny Docs基于shell的测试框架技术交底书
0、缩略语和关键术语定义
| 名词 | 全称 | 描述 |
| Linux | / | 一种免费使用和自由传播的类UNIX操作系统，基于POSIX的多用户、多任务、支持多线程和多CPU的操作系统。 |
| Shell | / | 一个命令解释器，类似于DOS下的command。它接收用户命令，然后调用相应的应用程序。 |
| 自动化测试框架 | / | 提供最基础的自动化测试功能，用于组织、管理和执行那些独立的自动化测试用例，测试完成后统计测试结果。 |
| SAT | Shell Auto Test | 基于Shell的自动化测试框架，自定义命名为SAT |
1、相关技术背景（背景技术），与本发明最相近似的现有实现方案（现有技术）
如今，人们的衣食住行、社会的各行各业都离不开各类操作系统、软件的正常运作和支持。小到手机里五花八门的APP：骑车、付款、购物，大到关乎国计民生的大系统：铁路运输的调控系统，卫星发射的操控系统，这些产品的质量，重要性不言而喻，而测试工程师则是质量的“把关者”。
面对产品繁琐的测试点，测试工程师需要消耗大量的时间对其进行测试，随着产品的不断适配与迭代，工作量越来越大，怎么保质保量并且高效的完成测试任务呢？自动化测试就是其中一个解决方案，通过自动化的测试来代替人工手动测试，提高测试效率的同时，还可释放人工人力做其他事情。
自动化测试实现的方式有很多，简单的几行代码，复杂的几万行代码，但是随着测试内容的增加、或者协同人员的增加，怎么让测试代码更容易管理、更规范、更易于维护？怎么整合测试用例？怎么协调测试资源？代码移植到其他系统能否复用？测试完成后是否能清晰的看到测试结果？这些都是需要面临的问题。
本专利中的自动化测试框架，主要用于解决以上问题，为自动化测试提供基础运行环境，整合所有测试用例、资源统一进行测试，测试结束后有规范统一的测试报告/日志输出，用于定位问题。让自动化测试真正达到无人值守，完成测试准备、测试、输出测试结果全套流程。
目前行业内也存在通过Shell实现的自动化测试框架：
shunit2
bats-core
以上两款自动化测试框架都能做到，自动整合测试用例、执行测试、测试结束后输出测试报告。
1.1、与本发明相关的现有技术一
1.1.1、现有技术一的技术方案
使用shunit2自动化框架进行测试，需要用户提供测试用例文件，测试文件中可包含多条用例，这里的文件命名和用例命名只要按照框架规范设置，则可以被框架自动识别。
测试时可批量执行框架根目录下所有测试用例文件，也可以单独执行某一个测试文件，在测试过程中可同步在终端查看测试用例的执行进度，终端会输出每一条用例的执行结果，若执行失败会高亮标记，且展示对应的输出内容与提示信息，也可以在测试结束后查看终端输出的历史记录，获取测试结果。
1.1.2、现有技术一的缺点
使用shunit2自动化框架针在批量执行用例时，仅会扫描框架根目录下文件是否为测试文件，并不支持扫描其他路径，若项目中涉及的测试人员、测试模块逐渐增多，那么在用例文件的管理会略显混乱，所有的测试文件都拥挤的存放在同一个目录中，不具备分类管理的能力。
测试开始以前可以对测试环境进行初始化，保证测试用例执行的正确性，但是若当前环境中不满足某用例依赖条件，框架无法进行进一步措施，例如终止测试、标记关联用例状态。
测试用例的执行状态仅有‘通过’和‘失败’，但若是功能变更导致测试命令修改，执行测试用例会报错，此时用例状态还是‘失败’，这类‘错误’状态无法被识别，需要根据失败用例进行分析得出结论，这里框架支持的用例执行状态不够丰富。
自动化测试用例也是通过功能用例转换的，只是通过自动化的形式来执行，但在框架中自动化用例与功能用例的管理没有直接性的关联，若用例执行失败，还需要查看用例代码才能定位对应哪一条功能用例，较为不便。
测试中和测试完成后，都能看到用例执行状态，执行状态为‘失败’的用例，可以看到其错误输出，辅助定位问题，但是结果执行状态为‘通过’，无法看到命令的标准输出，无法进一步验证执行状态的准确性，例如断言代码错误导致用例执行结果本来应该为‘失败’，结果最终结果为‘通过’，但通过表象无法识别，这里会存在巨大风险。
测试结果输出在终端，若想保存测试结果只能通过重定向保存本地，但因为测试结果中存在关键字色彩展示，所以重定向的测试报告文件中会包含颜色代码标识，若在Linux以外的操作系统查看测试报告不仅没有色彩，还会影响阅读性，且在其他系统查看测试报告、归档测试报告的场景是比较常见的。
图1：非Linux系统查看测试报告对比
除此以外因为该框架开发者为国外研发人员，所以不管是注释，还是测试报告等内容，均不支持中文，所以在框架的使用和测试报告的阅读上不是太友好，同时也都存在一定使用、阅读门槛。
1.2、与本发明相关的现有技术二
1.2.1、现有技术二的技术方案
使用bats-core自动化框架进行测试，总体功能与方案一差异不大，只是实现的方式和展示存在一些差异，但在测试文件管理这方便要更加灵活。
该框架的测试文件后缀只要以‘.bats’结尾即可识别，对文件路径不存在强依赖情况，所以可以通过不同的测试人员、不同的测试模块，更清晰的分类管理测试文件，且不影响测试文件的批量执行，可以递归执行某目录下所有的测试文件。
1.2.2、现有技术二的缺点
bats-core自动化框架与方案一大体上较为相似，所以方案一存在的缺点，方案二大部分都存在。
除了测试文件管理的实现方式更灵活与优以外，在测试报告的保存上也更优化，重定向之后不会在文档中出现颜色代码标识，在其他系统的阅读性体现的更友好。
2、本发明技术方案的详细阐述
2.1、本发明所要解决的技术问题
本发明主要解决以下技术问题：
测试文件在多项目、多人协作场景下管理混乱。
测试开始前没有用例执行环境监测流程，需要测试完毕才能暴露问题，没有流程管控能力，若测试量巨大，则会消耗大量时间成本。
测试用例执行状态比较单一，针对不通过用例，需要测试完成后进行深入分析定位，同样会消耗不少时间成本。
自动化用例与手工用例在测试报告中不具备关联性，需要查看代码才能查出对应功能用例。
无完整的测试命令结果输出日志(标准/错误输出)，在用例自检方便存在风险。
框架的使用对国人缺乏友好性，例如所有页面展示元素、报告内容、说明文档、代码注释等等，均为英文，具备一定使用门槛，需要大量学习成本。
框架可扩展性较低，只能通过二次开发扩展功能，在开发前同样需要消耗大量时间成本。
测试完毕后感知与归档测试结果能力较弱，需要人工跟进与处理。
2.2、本发明提供的完整技术方案
为了解决上述技术问题，本发明提供了一种新的自动化测试框架，这里命名为SAT(shell auto test)，包含测试文件的合理管理、测试环境监测与控制、测试用例的执行与输出，测试日志/报告的生成与通知，使测试变得更加效率与简单，具体运行流程如下：
图2：bats-core/shunit2框架与SAT框架运行流程图
通过以上流程图对比差异，可以初步看出，SAT测试框架使用更友好（可视化菜单、中/英文环境），在整个测试流程中增加了更多的流程控制(运行环境监测、测试环境监测)，实现了更多的实用功能(测试模式、详细日志、机器人通知、邮件归档测试报告/日志)，以达到优化测试流程、提升测试效率得目的。
方案设计流程：
- 进行框架的初步配置，针对根目录下配置文件，有以下配置项：
(1) 项目名称；
(2) 测试人员名称；
(3) 运行权限控制：root/普通用户；
(4) 环境监测控制：若监测不通过，是否终止测试；
(5) 语言环境控制：指定语言/自动匹配；
运行一键部署工具，会针对配置文件进行扫描，自动部署与生效配置项，并自动生成对应的目录结构，用于对项目、测试人员、测试资源、用例文件的管理，使之更为清晰化。
框架有设计默认项目和默认测试人员，项目中包含Linux系统部分测试内容（文件系统、内核...），可直接运行测试，为用户提供一定的使用参考（README.md中也有详细说明）。
一键部署之后，对应的项目目录中会自动生成测试用例模板，此时用户需要根据自己的项目情况，编写对应的测试用例文件。测试用例以函数的形式存在，按照用例模板规范，用例中包含用例信息：用例标题(中/英文)、用例ID(关联功能用例)、测试人员编号、测试命令类型(正常命令、异常命令)、测试命令、断言，这些信息与功能用例强关联，方便管理与定位问题。
框架的测试模式支持全量测试、自定义测试，用户可根据不同使用场景，可选择不同的测试方式：
(1) 全量测试：执行项目下所有测试用例
(2) 自定义测试：仅执行项目下某测试人员、某模块、某条用例
- 运行框架启动工具，进行环境检测和初始化：
(1) 环境检测：检测当前用户权限是否满足框架运行条件；
(2) 环境初始化：检测当前系统语言环境，加载不同语言配置。根据其他配置项，整合组件运行框架并展示菜单项。
- 用户根据引导逐步选择菜单：
图3：框架中/英文可视化菜单（菜单1为默认项目，菜单2/3为后续添加项目）
- 根据菜单选择的测试场景，组合对应的测试用例，并对用例执行测试环境做检查(检测项可配)，列出检查结果后，若配置文件中检测控制项‘开关状态’为启用，出现检查不通过项，则终止后续测试。
图4：检测不通过实例（网卡检测失败，后续数字为影响用例编号）
- 若测试环境检测通过，则正是开始执行测试用例。在执行的过程中，框架会对命令执行结果进行解析，初步分析出通过、不通过、错误三种用例执行状态。
图5：执行命令解析流程
同步步骤9初步解析后，再结合断言，得出最终执行状态结果。因为Linux系统有不同架构：x86、arm、mips等等，部分测试用例是区分架构的，并不通用，所以断言功能中额外支持‘不兼容’状态。
得出用例执行结果后，框架会输出内容至终端，同时在后台收集命令的标准输出、错误输出、用例信息、用例执行状态等，形成详细的用例运行日志。
图6：终端输出用例执行状态
- 测试完成后整合数据，生成本地测试报告、测试日志（日志单独剥离了error状态日志，方便快速定位用例执行问题），把测试报告内容输出至终端。
图6：测试结果(a/b为测试人员编号，可自定义配置)
图7：本地保存测试报告/日志与截取日志部分内容
- 触发通知事件，获取企业微信机器人接口地址、测试人员邮箱，若获取成功，则在企业微信进行通知（内容可配），整理测试报告、测试日志等附件，通过邮件发送至测试人员邮箱，快速完成测试结果归档，并通过日志协助问题定位。
图8：企业微信机器人通知
综上，一套完整的测试流程已经完成，除此之外，框架的扩展性和易用性较好，提供了很多实用型工具与配置，以下例举了部分内容：
| 类型 | 名称 | 说明 |
| 配置 | 色彩 | 框架的菜单、提醒、报告等等可视化元素色彩均支持配置，满足个人审美 |
| 配置 | 语言 | 框架语言可指定中/英文、自动匹配，满足个人阅读习惯 |
| 配置 | 机器人 | 支持目前国内常用的企业微信、钉钉等办公软件机器人，在配置机器人地址后，测试完成时，机器人会播报测试结果，使用户能第一时间掌握测试结果，该项可缺失 |
| 配置 | 邮箱 | 在配置邮箱后，在测试完成时，框架会自定扫描测试结果，整合测试结果文件，以附件的形式发送至配置邮箱地址，该项可缺失 |
| 配置 | 框架运行日志 | 配置启动后，终端和本地都会输出框架运行日志，可清晰的看到框架运行原理，便于理解框架和二次开发 |
| 配置 | 项目 | 随着项目增加，可配置默认项目以外的其他项目，配置该项后，运行部署工具，会在默认项目平级创建新项目目录，框架提供自动整合支撑 |
| 配置 | 测试人员 | 随着自动化协作人员增加，用例文件若集中存放，会异常混乱，配置该项后，运行部署工具，会在项目/测试资源目录下自动按照测试人员创建子目录，框架提供自动整合支撑 |
| 工具 | 自动部署工具 | 主要用于配置项目和测试人员后，一键自动增加菜单、目录结构，增加框架易用性，无需学习/查看代码，即可快速完成框架扩展 |
| 工具 | 代码规范检查工具 | 自动扫描框架内所有shell文件，指出错误并提示修改建议，解决多人协作下，代码编写风格不规范、差异大的问题 |
| 工具 | 格式规范检查工具 | 封装了规范的代码格式(换行、缩进等)，自动扫描框架内所有shell文件，对其格式进行自动修改，解决代码不美观、不易读问题 |
| 工具 | Git提交控制工具 | Git提交控制工具：若通过Git管理框架，可一键部署自动代码扫描，针对Shell代码规范与格式做检查，若存在错误项则禁止提交，解决了代码管理约定，执行不到位问题 |
2.3、本发明技术方案带来的有益效果
本发明通过“方案设计流程”部分中步骤1-13与扩展工具/配置，解决了前文提及的所有技术问题：
(1) 为自动化测试中多项目、多人协作场景，使测试文件的管理更加具备层次与清晰；
(2) 测试开始前支持更灵活的环境检测，自定义检测项，并增加流程控制功能，使测试流程的进行更具备逻辑性，规避无效测试；
(3) 增加更丰富的测试用例执行结果状态，减少测试结束后分析定位时间，提高结果分析效率；
(4) 增强自动化用例与手工用例的关联性，可通过测试结果直接明了的定位出对应的功能用例，并引入到测试报告中，减少问题定位效率；
(5) 对测试用例执行结果(标准/错误输出)，进行完整的捕获，并整合为测试结果日志，为加强自检强度提供支撑，消除隐患，提高测试用例有效性；
(6) 自动识别当前系统语言环境，自动匹配中文/英文，包含提示、菜单、终端输出、测试报告等内容，自动切换中文/英文展示，同时增加可视化的操作菜单，用户只需要输出编号，即可完成测试，提高了对国人的友好性，降低使用门槛，提高易用性；
(7) 框架增加扩展性，详情见“方案设计流程”末尾工具/配置例举部分，提升各种不同场景的适应性；
(8) 测试完毕后自动生成本地测试报告，同时把测试结果通知到企业微信、测试报告邮件到测试人员邮箱，提高归档/验收效率。
2.4、针对上述技术方案，是否还有替代方案同样能完成发明目的
暂无
3、本发明的技术关键点和欲保护点是什么
本发明的技术关键点包括整个测试框架的运行机制、流程控制与扩展：
(1) 框架与项目、协作人员相结合的分层管理结构技术方案的设计与实现
(2) 框架运行过程中流程控制时机、控制项的检查机制技术方案的设计与实现
(3) 测试过程数据解析、收集与整合技术方案的设计与实现
(4) 符合大环境下的测试实时汇报与归档技术方案的设计与实现
(5) 框架整体易用性与扩展性(语言环境的解析与匹配、辅助工具集、自定义配置项)技术方案的设计与实现
4、附件
参考文献
l Shell编程