文章目录

• 1、软件框架
• 2、测试方案设计
• • 2.1、测试覆盖
  • 2.2、功能测试和压力测试
  • 2.3、自动化测试
  • 2.4、持续集成

1、软件框架

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

2.2、功能测试和压力测试

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

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

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

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发生的故障率来说，用户自己修改的代码出现问题的概率最大。对应在四层模型中，和出错的概率最大。

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

2.3、自动化测试

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

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

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

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

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

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

2.4、持续集成

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

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

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

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

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