1、软件框架

站在软件的角度，一个系统通常可以分为以下四个层次：

• 应用软件层(app layer)。用户重点自己开发的应用代码，例如我们的运动控制器要跑运动控制app，我们的示教器要跑qt用户交互app；
• 中间软件层(middle layer)。在用户app和os系统之间的软件，一般是一些通用的库文件，比如qt库、算法库；
• 操作系统层(os layer)。给用户层提供标准os服务的软件，一般包括kernel和驱动部分；
• 硬件层(hardware layer)。最低层的基本硬件；

2、测试方案设计

我们的最终目标是交付给用户高质量可靠地产品，我们希望我们的系统每个角落都是经过严格测试的，我们要在实验室里模拟到用户可能会碰到的各种问题，才能经得起大规模商用后大量用户场景的考验。

所以我们在设计测试方案时，要考虑到尽可能多的对软件路径进行测试覆盖。

软件测试和硬件测试对比，有以下难点：

• 测试对象比较虚幻。对硬件来说有可见的实体；对软件来说如果不了解细节你觉得它只是一个整体，但是当你了解细节以后，就会发现其中有越来越多的软件模块，每个模块都有自己的逻辑，都可能出错都需要被测试；
• 测试对象非常多。软件的逻辑模块非常多，通常高出硬件模块几个数量级；
• 测试对象逻辑复杂。对单个模块来说，软件模块可能出现的逻辑状态也是远高于硬件模块的；
• 逻辑组合非常复杂。最终产品是要把多个模块组合成一个整体的，多个模块组合在一起就是(N x M x …)的复杂度；

考虑到以上难点后，我们尝试使用以下手段来增加测试的覆盖度。

2.1、测试覆盖

上述的四层模型，每一层都为上一层提供服务，下一层的能力肯定是大于上一层的需要，因为上一层的应用用不到下一层所有的功能。

比如：同一hardware既支持linux os又支持vxworks os，同一linux os既支持运动控制又支持qt应用。

所以从严格意义上讲，四层的能力模型是一个金字塔型的：

在这种模型下，从任一上层层次来设计测试用例，它都会贯穿测试到下面的层次，但是下面层次都是有覆盖不到的情况：

既然是这种情况，那么是不是可以这样认为：如果已经从底层进行了完全的测试，那么是不是不需要经过上层的测试就能说明底层已经非常稳定？

答案是否定的。底层自我测试的面可能更广，但是自我测试模拟不了上层带来的场景。

比如我们针对os层已经做了针对os层的所有测试，这个时候我们还不能说os层完全没问题了。因为设计的测试用例只是尽可能覆盖，但是永远不可能完全模拟到所有真实的使用场景。我们还要经过中间层、应用层的测试完成后，我们才能说os在这种应用的场景中大部分是没问题的。

所以，一个完备的测试方案，需要在每一层次上设计测试用例，才能形成一个完整的测试覆盖：

2.2、功能测试和压力测试

上一节描述为了完备的测试覆盖，我们需要在每一层次上设计测试用例。

那么针对某一层次的测试用例，应该怎么样来设计呢？

从功能上可以简洁的分为两大类：功能测试和压力测试。

1、功能测试：

• 站在使用者的角度，测试提供的所有接口功能是否ok；
• 还可以进一步对这一层次代码进行单元测试、集成测试，来充分验证代码逻辑；

2、压力测试：

• 对提供的基本功能，进行一个时间、空间上的压力验证。例如：正常请求1s 1次，压力请求1s 1000次；正常流量10M，压力流量 100M。只有在测试环境中经过更加严苛的测试，才能经受住实际复杂环境的考验。
• 对于提供压力的形式也不是一味重载，还需要构造负载剧烈变化的场景。例如：重载、轻载、重载。。。。(随机变化)
• 如果每一层次都有了自己的测试用例，我们还可以把这些用例组合起来，生成新的压力场景。例如：os层进行压力测试的同时，app层进行功能测试，验证在压力场景下app的功能还是否正常。
• 使用自动化的方式，大量重复的去跑常规功能测试用例，这本身就是一个很好的压力测试场景。

对四层模型来说，每一层的功能测试和压力测试有以下特点：

Layer Function Test Pressure Test App Layer 1、从用户的角度测试所有提供的功能；

2、单元测试+集成测试，验证代码逻辑； 1、重载压力测试；

2、轻重载随机变化测试； Middle Layer 一般中间层可能没有源码以库的形式提供，而且用户对它的整个架构理解的也不充分。

1、如果条件允许，可以让中间层厂商提供对应的报告；

2、如果资源有限，很多时候也没有对中间层设计专门的测试用例； 依赖对应厂商 OS Layer 1、对OS kernel公共部分的功能测试，比如：cpu、内存。。。；

2、对OS driver部分的功能测试，比如：网口、USB、存储、显示、input。。。；

3、单元测试+集成测试，验证代码逻辑； 1、重载压力测试；

2、轻重载随机变化测试； Hardware Layer 对硬件功能的完备性测试，一般是在产线上进行的：

1、在硬件大规模量产时，会允许软件还有些bug，但是不允许硬件出现任何的功能性问题，因为硬件基本是不能修改的；

2、量产时需要提供硬件功能测试软件给产线，来筛选出硬件不良品； 在硬件出厂前，在产线上还需要对硬件进行老化，让每个元器件度过初始震荡期，进入平稳运行期：

1、提供老化测试软件，对硬件器件施加压力，让她们能迅速老化；

2、软件能筛选出老化失败的不良品；

另外从bug发生的故障率来说，用户自己修改的代码出现问题的概率最大。对应在四层模型中，app代码和os驱动代码出错的概率最大。

因为中间层代码、os kernel部分、hardware部分，使用的人一般很多，经过了多个用户的使用和测试后已经暴露出了较多的问题。而app代码和驱动代码基本都是用户自己开发/移植的，出错的概率更大一些。所以这两部分代码需要重点测试，给它们设计更多的测试用例。

2.3、自动化测试

从测试用例的数量和软件功能的数量来说，测试用例要大于软件功能的几倍，才能保证软件的质量。

同时这也带来一个问题，庞大的测试用例，如果用人工来执行，测试周期会非常久。这对bug的发现、bug的修复、版本的快速发布都是不可容忍的。

在今天这个产品开发周期越来越快的时代，越来越多的用到了自动化测试。如果是纯软件的项目，测试用例的自动化覆盖率应该达到100%；如果是嵌入式项目，测试用例的自动化覆盖率也应该达到80%以上。

1、自动化测试模型如下：

• 自动化测试pc通过控制通道和被测设备进行连接，可以控制被测设备的行为，一些内部测试用例可以直接这样就能测试。控制通道可能是串口、usb、网口等等；
• 自动化测试pc通过控制通道和测试仪器/设备进行连接，测试仪器/设备通过数据通道和被测设备进行连接，pc上的测试代码可以操控测试仪器对被测设备进行测试。需要挑选支持代码控制的测试仪；
• 跑在自动化测试pc上的自动化测试代码，一般使用python或者java来开发；

2、web管理 + 自动化测试：

在自动化测试的进阶阶段，有多套测试方案+多个测试开发人员+多个测试执行人员+多个开发人员，这样复杂的场景下需要一个有效的管理。

一般使用web来实现这些管理功能：

• 配置测试方案。测试哪个版本的软件，要测试哪些case，每个测试case的配置；
• 记录测试事件、测试log、测试结果、自动分析、自动提交bug；
• 从bug记录上可以找到具体的测试信息；
• 统计和报表呈现；
• 权限管理；

2.4、持续集成

测试用例自动化的一个重要目的，就是支持持续集成。

持续集成CI(Continuous integration)是来自于敏捷开发(Agile software development)的一个重要概念。在敏捷开发模式下，我们的产品是迭代式的开发，从最小功能做起，随时修改随时可用。产品随时保持可用的状态，可以随时发布。

在新的代码合入以后，需要测试在极短的测试时间中，验证代码合入的新功能，以及验证对原来的功能是否有影响。如果不使用自动化测试，人工测试是不可能完成的。

实现了持续集成以后，我们会得到这样的理想场景：

• 每天开发人员提交完代码，下班以后；
• 自动编译系统，拉取最新的代码进行编译；
• 编译完成后自动烧录到被测系统，并启动自动测试；
• 自动测试完成后，会把测试不过的情况和log邮件发送给前一天有对应代码提交的开发人员；
• 开发人员上班以后，处理前一天提交的错误，并开发新功能提交代码；
• 晚上，又是新一轮的自动验证；

今天的文章软件测试方案设计分享到此就结束了，感谢您的阅读，如果确实帮到您，您可以动动手指转发给其他人。