文章目录1、软件框架2、测试计划设计2.1、测试覆盖2.2、功能测试和压力测试2.3、自动化测试2.4、持续集成
一、软件框架
从软件的角度来看，一个系统通常分为以下四个等级。
APP应用层(app layer )。 重点是用户自己开发的APP应用程序代码。 例如，我们的运动控制器跑运动控件app，我们的示教器跑qt用户的交互app； 中间软件层(middle layer )。 用户app和操作系统之间的软件一般是qt库、算法库等常见库文件的操作系统层。 为用户层提供标准操作系统服务的软件。 一般包括kernel和驱动程序部分； 硬件层。 最低层的基本硬件； 2、测试计划设计我们的最终目标是为用户提供高质量可靠的产品。 我们希望我们的系统每个角落都经过严格测试。 我们要在实验室模拟用户可能遇到的各种问题，经得起大规模商用后大量用户场景的考验。
所以，我们在设计测试方案时，要考虑测试覆盖尽可能多的软件路径。
将软件测试与硬件测试进行比较，存在以下难点。
测试对象比较虚幻。 硬件有可见的实体； 如果对软件来说不知道细节，我想那只是一个整体，但是自从mdhb知道了细节之后，其中有越来越多的软件模块，每个模块都有自己的逻辑，可能会出现错误，需要经过测试测试对象非常多。 的逻辑模块非常多，通常比硬件模块高几个数量级； 测试对象的逻辑很复杂。 对一个模块来说，软件模块可能比硬件模块更符合逻辑。 逻辑组合非常复杂。 最终产品将多个模块集成在一起，考虑到多个模块组合(N x M x …)的复杂性和以上难点，尝试采用以下手段提高测试展望度。
2.1、测试涵盖上述四层模型，每层服务于上层，下层能力一定大于上层需求。 因为上层的应用不能使用下层的所有功能。
例如，同一台hardware同时支持Linux操作系统和vxworks os操作系统，而同一台Linux操作系统同时支持运动控制和Qt APP。
所以从严格意义上说，四层能力模型是金字塔型的：
在此模型中，如果从某个更高的级别设计测试用例，它将穿透到更低的级别，但可能无法复盖更低的级别。
由于是这种情况，请参阅如果已经从底层进行了完全的测试，那么是不是不需要经过上层的测试就能说明底层已经非常稳定？
答案是否定的。 底层自我测试的面可能更广，但自我测试无法模拟高层带来的场景。
例如，我们对操作系统层进行了所有操作系统层测试，但此时不能说操作系统层完全没有问题。 虽然设计的测试用例只是尽可能地覆盖，但并不能完全模拟所有的实际使用场景。 在中间层、APP应用层测试完成后，操作系统在这种APP应用场景下可以说几乎没有问题。
因此，完整的测试方案要求在每个级别设计测试用例，以形成完整的测试覆盖。
2.2、功能测试和压力测试前一节的说明需要各级设计测试用例，以实现完整的测试覆盖。
那么针对某一层次的测试用例，应该怎么样来设计呢？
从功能上来说，可以简单地分为两类：功能测试和压力测试。
1、功能测试：
从用户的角度来看，也可以进一步对提供的所有接口功能进行单元测试、集成测试，充分验证代码逻辑2、压力测试：
对提供的基本功能进行时间和空间上的压力验证。 例如，通常要求1s 1次，压力要求1s 1000次； 正常流量10M，压力流量100M。 只有在测试环境中经过更严格的测试，才能经得起实际复杂环境的考验。 对于施加压力的形式，也不能只是施加重负荷，而需要构筑负荷急剧变化的场景。 例如，重载、轻载、重载。 我想知道我想知道我想知道(随机变化)如果每个级别都有自己的测试用例，则还可以将这些测试用例组合在一起以生成新的压力场景。 例如，操作系统层在进行压力测试的同时，APP层进行功能测试，验证在压力场景下APP的功能是否还正常。 使用自动化的方法大量重复运行普通的功能测试用例，本身就是一个很好的压力测试场景。 对于四层模型，每层功能测试和压力测试具有以下特点：
layerfunctiontestpressuretestapplayer 1、从用户的角度测试提供的所有功能；
2、单元测试集成测试，代码逻辑验证； 1、重载压力测试；
2、轻载随机变化测试； Middle Layer的典型中间层可能没有将源代码作为库提供，并且用户可能对整个体系结构不够了解。
1、在条件允许的情况下，可以让中层厂商提供相应的报告；
2、在资源有限的情况下，往往依赖于厂商操作系统层1，也没有专门针对中间层设计的测试用例，对操作系统关键部分进行功能测试，如cpu、内存。 我想知道我想知道；
2、操作系统驱动程序部分的功能测试，如网口、USB、存储器、显示屏、输入。 我想知道我想知道；
3、单元测试集成测试，代码逻辑验证； 1、重载压力测试；
2、轻重载随机变化测试； Hardware Layer 对硬件功能的完备性测试，一般是在产线上进行的：1、在硬件大规模量产时，会允许软件还有些bug，但是不允许硬件出现任何的功能性问题，因为硬件基本是不能修改的；
2、量产时需要提供硬件功能测试软件给产线，来筛选出硬件不良品； 在硬件出厂前，在产线上还需要对硬件进行老化，让每个元器件度过初始震荡期，进入平稳运行期：
1、提供老化测试软件，对硬件器件施加压力，让她们能迅速老化；
2、软件能筛选出老化失败的不良品；
另外从bug发生的故障率来说，用户自己修改的代码出现问题的概率最大。对应在四层模型中，app代码和os驱动代码出错的概率最大。
因为中间层代码、os kernel部分、hardware部分，使用的人一般很多，经过了多个用户的使用和测试后已经暴露出了较多的问题。而app代码和驱动代码基本都是用户自己开发/移植的，出错的概率更大一些。所以这两部分代码需要重点测试，给它们设计更多的测试用例。
2.3、自动化测试从测试用例的数量和软件功能的数量来说，测试用例要大于软件功能的几倍，才能保证软件的质量。
同时这也带来一个问题，庞大的测试用例，如果用人工来执行，测试周期会非常久。这对bug的发现、bug的修复、版本的快速发布都是不可容忍的。
在今天这个产品开发周期越来越快的时代，越来越多的用到了自动化测试。如果是纯软件的项目，测试用例的自动化覆盖率应该达到100%；如果是嵌入式项目，测试用例的自动化覆盖率也应该达到80%以上。
1、自动化测试模型如下：
2、web管理 + 自动化测试：
在自动化测试的进阶阶段，有多套测试方案+多个测试开发人员+多个测试执行人员+多个开发人员，这样复杂的场景下需要一个有效的管理。
一般使用web来实现这些管理功能：
配置测试方案。测试哪个版本的软件，要测试哪些case，每个测试case的配置；记录测试事件、测试log、测试结果、自动分析、自动提交bug；从bug记录上可以找到具体的测试信息；统计和报表呈现；权限管理； 2.4、持续集成测试用例自动化的一个重要目的，就是支持持续集成。
持续集成CI(Continuous integration)是来自于敏捷开发(Agile software development)的一个重要概念。在敏捷开发模式下，我们的产品是迭代式的开发，从最小功能做起，随时修改随时可用。产品随时保持可用的状态，可以随时发布。
在新的代码合入以后，需要测试在极短的测试时间中，验证代码合入的新功能，以及验证对原来的功能是否有影响。如果不使用自动化测试，人工测试是不可能完成的。
实现了持续集成以后，我们会得到这样的理想场景：
每天开发人员提交完代码，下班以后；自动编译系统，拉取最新的代码进行编译；编译完成后自动烧录到被测系统，并启动自动测试；自动测试完成后，会把测试不过的情况和log邮件发送给前一天有对应代码提交的开发人员；开发人员上班以后，处理前一天提交的错误，并开发新功能提交代码；晚上，又是新一轮的自动验证；