关于嵌入式，自动化测试框架的理解

关于嵌入式，自动化测试框架的理解

在编写自动化测试脚本的时候，有很多的工作是反复的，假如建设socket连接，日志，错误处理，报表生成等。同时，对于测试人员来说，这些工作可能是比较艰难的。因此，设计一个框架，达到并隐藏这些反复和复杂的技术，让测试脚本的编写者将注意力集中在详细的测试逻辑上。

这样一个框架应该达到以下功能：

1.完成连接的初始化等根底工作。

2.捕获所有的错误，保证Test Case中的错误不会打断后续的Test Case执行。

3.自动检测和执行Test Case。新增的Test Case是独立的脚本文件，没须修改框架的代码或者配置。

4.音讯编解码，并以函数的方式提供给Test Case编写者调用。

5.方便的工具，如报表，日志等。

6.自动统计Test Case的运行结果并生成报告。

自动化测试框架的思维和一般的软件框架是一致的，就是避免反复劳动，降低开发难度。

下图是一个自动化测试框架的构造图：

每个Test Case都必需定义一个规定的Run函数，框架将依次调用，并提供相应的库函数供Test Case拿来发送命令和获得结果。这样，测试用例的编写者就只须要将注意力集中在测试自身。举例：

测试用例的编写者拥有的知识是“必需先翻开激光器其次才能向线路上插入错误”。而架构师能提供的是音讯收发，编解码，错误处理，报表生成等，并将这些为测试用例编写者隔离。

问题: open_laser, get_laser_state这些函数是谁写的？

问题：怎么样进一步达到知识的解耦？能否有更方便的语言来编写TestCase?

回归测试

有了自动化的测试脚本和框架，回归测试就变得很简略了。每当有新版本发布时，只需运行一遍现有的Test Case，分析测试报告，假如有测试失败的Case则回归测试失败，须要重新修改，直到所有的Case完全通过。完整的回归测试是软件质量的重要保证。

集成测试

集成测试要验证的是系统各个组成模块的接口是否工作正常。这是比系统测试更低层的测试，通常由开发人员和测试人员共有完成。

例如在一个典型的嵌入式系统中，FPGA，固件和界面是常见的三个模块。模块自身还能够划分为更小的模块，从而降低复杂度。嵌入式软件模块测试的常见问题是硬件没有固件则没法工作，固件没有界面就没法驱动;反过来，界面没有固件不能完整运行，固件没有硬件甚至没法运行。于是没有经过测试的模块直到集成的时候才能完整运行，发现问题后须要考虑所有模块的问题，定位和攻克的代价都很大。假设有模块A和B，各有十个bug。假如都没有经过模块测试直接集成，能够认为排错的工作量相当于10*10即是100。

所以，在设计一个模块的时候，首先要考虑，这个模块怎么样单独测试？假如，假如界面和固件之间是通过SOCKET通信的，那么就能够开发一个模拟固件，在同样的端口上提供效劳。这个模拟固件不执行现实中的操作，但是会响应界面的请求并返回模拟的结果。并且返回的结果能够笼罩到各种典型的情况，包含错误的情况。运用这样的技术，界面局部简直能够得到100%的验证，在集成阶段遇到错误的大大减少。

对固件而言，由于处于系统的中间，所以问题复杂一些。一方面，要让固件能够通过GUI以外的途径被调用；另一方面则要模拟硬件的功能。对于第一点，在设计的时候，要让接口和达到别离。接口能够随意的更换，假如和GUI的接口兴许是JSON，同时还能够提供telnet的TL1接口，但是达到是完全一样的。这样，在和GUI集成之前，就能够通过TL1进行完全的测试固件。对于第二点，则应该在设计的时候提取出硬件抽象层，让固件的主要达到和寄存器，内存地址等因素隔离开来。在没有硬件或者硬件设计未定的时候达到一个硬件模拟层，来保证固件能够完整运行并测试。