最近工作过程中没少开会，产品总监与研发总监就产品可用性和稳定性开始了一轮大战。

于是我搜集网络资源，罗列一些稳定性测试，只为分享。

1       关于软件稳定性测试的思路

如何测试软件的稳定性其实是很难的，按照常规思路，只有长期的用户场景测试才能一定程度上保证软件的稳定性是可靠的，但并不能百分之百确定软件就是稳定的。软件测试本身就是由局限和尽头的，无穷的测试只能带来高成本的投入和无限期的计划延长。

 

其实，可以从反面角度来看待软件的稳定性，我们从一个简单的数学定理入手：

 

原命题成立，则逆否命题也成立。

 

原命题：软件没有明显缺陷，所以是足够稳定的

逆否命题：软件并不是很稳定，所以有明显的缺陷

 

假设原命题是正确的，那么你否命题应该也是正确的。

 

我们从原命题出发，很难说服团队去相信软件是足够稳定的，因为稳定的软件是没有明显缺陷的，没有数据的支撑和客观的事实，简单的例子就是，一我们不可能发现软件中所有的缺陷；二我们不可能花2~3个月不定地运行软件然后生成报告说经过长时间的实验软件十分稳定，时间不允许，就算时间允许我们也不敢保证3个月后程序是否还继续稳定如初。

 

从逆否命题出发会简单许多，我们可以短时间内投入足够的精力去想办法证明软件很不稳定，比如让软件在高负荷下持续运行，给不同的压力和并发请求，进行破坏操作等等，如果软件没有出现明显的缺陷那么说明原命题也是成立的，从这个角度思考就可以从容地解决软件稳定性验证的问题。

 

 

2       app测试–稳定性测试

稳定性测试的概念有2种，

一， 稳定性测试，对应于异常性测试，即发生异常情况时，系统如何反应的测试。包含：

　　1 交互性测试，被打扰的情况，如来电，短信，低电量等。这些其实在上章的功能测试中有提到。

　　2 异常性测试，断网，断电，服务器异常等情况

二，稳定性测试指的是性能测试，压力测试

　　1 基准性能测试，通过压服务器端口及客户端在不同网络环境下响应速度

　　2 大数据测试，在特定环境下，客户端一次性更新大量数据及人员列表

另有其它文章，提到性能测试，为评估APP的时间和空间特性（真是高深啊，时间和空间，再来个4维，5维？），包括：

　　1 极限测试：在各种边界压力情况下，如电池，存储，网速等，验证app是否能正确响应

　　–内存满时安装app

　　–运行app手机断电

　　–运行app时断掉网络

　　这几点倒是与第一条的内容重复

　　2 响应能力测试：测试app中的各类操作是否满足用户响应时间要求

　　–app安装 ，卸载的响应时间

　　–app各类功能性操作的影响时间

　　3 压力测试：反复、长期操作下，系统资源是否占用异常

　　–app反复进行安装卸载，查看系统资源是否正常（弄个几次就行吧，正常人，谁反复安装卸载啊）

　　–其它功能反复进行操作，查看系统资源是否正常（这倒是应该的）

　　4 性能评估：评估典型用户应用场景下，系统资源的使用情况

　　这里要定义，什么是典型用户应用场景

　　5 benchmark测试（基线测试），应该不是基准性能测试：与竞争产品的benchmarking，产品演变对比测试等（没有多大意义）。

简要步骤：adb devices—了解包名–adb shell monkey -p 包名 -v 运行次数（多个参数的组合形成不同的用例以求最大的覆盖）–当崩溃或无响应时分析monkey日志

常规monkey命令（可直接在项目里使用）:

adb shell monkey -p com.jiochat.jiochatapp –throttle 100 –ignore-crashes –ignore-timeouts –ignore-security-exceptions –ignore-native-crashes –monitor-native-crashes -v -v -v 1000000>d:\b.log

重现bug：monkey日志搜索关键词ANR exception，将之前的事件重新操作，尤其是seed值要一模一样，如monkey -p 包名 -v seed 0 500

日志分析：查看是否有crash等关键字，找上下文，进行简单分析将你所能定位的错误信息发给开发。

该工具用于进行压力测试。 开发人员结合monkey 打印的日志 和系统打印的日志，修改测试中出现的问题。Monkey 是SDK中附带的一个工具,所有的事件都是随机产生的，不带任何人的主观性。

 

 

3       软件稳定性测试

1 稳定性测试就测试系统的长期稳定运行能力。在系统运行过程中，对系统施压，观察系统的各种性能指标，以及服务器的指标。

2 测试场景：模拟平常的压力，模拟实际中日常的用户数进行操作。数据库要存有一定的数据。

3 稳定性测试是概率性的测试，就是说即使稳定性测试通过，也不能保证系统实际运行的时候不出问题。所以要尽可能的提高测试的可靠性。可以通过多次测试，延长测试时间，增大测试压力来提高测试的可靠性。

4 稳定性测试的测试时间和压力存在一定的关系。在测试时间不能保证的情况下，可以通过增强压力在一定程度上来挽救。

观察系统的各种监控指标曲线，预测系统的发展状况。响应时间是否有增长，可用内存是否在减少，CPU利用率是否在上升等等都可以说明系统是否存在问题

 

 

4       系统稳定性测试之基础知识

一、定义     

稳定性测试是在保证基本功能完整正确的前提下，软件或系统在一定时间或压力下，检验功能稳定运行的情况及性能优劣趋势，以减少系统或软件崩溃的发生。

 

二、关注点

稳定性测试直接的关注点，就是软件或者系统功能特别是用户常用功能的稳定性；其次关注的是性能指标的变化；在测试过程中，我们需要特别考虑多线程进程及不同测试环境问题。

 

三、工作的内容

 

 

 

 

5       软件测试—软件性能测试和可靠性测试

1.软件性能测试的基本概念

 

软件的性能是软件的一种非功能特性，它关注的不是软件是否能够完成特定的功能，而是软件在完成该功能时展示出来的及时性。

（1）软件性能的指标

1）响应时间：是指系统对请求作出响应的时间，并且这个时间被人们的接收程度是随着系统的不同而不同的（一个游戏相应3秒无法忍受，一个编译程序编译3分钟也是可以接受的）

2）系统相应时间和应用延迟时间：前面的响应时间主要是指用户感受到的响应时间，其中还可以具体分为系统响应时间和呈现时间，性能测试比较关注系统响应时间

而系统响应时间又可以具体分为网络传输时间和应用延迟时间，性能测试比较关注应用延迟时间

3）吞吐量：吞吐量是指系统在单位时间内处理请求的数量，但是并不是访问人数越多吞吐量越高，因为随着访问人数的增多系统的可分配的资源会减少造成吞吐量下降等

4）并发用户数：是指系统可以同时承载的正常使用系统功能的用户数，与1秒钟几十万吞吐量相比上千用户的并发量是一个更直观但也更笼统的性能指标

5）资源利用率：反映在一段时间内资源平均被占用的情况

 

（2）软件性能的角度

用户视角：对于用户而言，性能就是响应时间，对于大量的数据，如果一边返回数据一边呈现对于用户而言响应时间也是很快的

管理员视角：管理员可以通过使用软件提供的管理功能等手段来对系统性能进行优化，但是一般不涉及到源代码的修改

开发人员视角：开发人员的角度和管理员的角度基本是一致的，但是开发人员更需要深入的关注软件的性能

 

（3）性能测试的目标

发现缺陷

性能调优

能力检验与规划

 

（4）性能测试的分类

性能测试

并发测试

压力测试

可靠性测试

负载测试

配置测试

失效恢复测试

性能测试类型包括负载测试，强度测试，容量测试等。 负载测试（Load Testing）：负载测试是一种主要为了测试软件系统是否达到需求文档设计的目标，譬如软件在一定时期内，最大支持多少并发用户数，软件请求出错率等，测试的主要是软件系统的性能。 压力测试（Stress Testing）：强度测试也就是压力测试，压力测试主要是为了测试硬件系统是否达到需求文档设计的性能目标，譬如在一定时期内，系统的cpu利用率，内存使用率，磁盘I/O吞吐率，网络吞吐量等，压力测试和负载测试最大的差别在于测试目的不同。 容量测试（Volume Testing）：确定系统最大承受量，譬如系统最大用户数，最大存储量，最多处理的数据流量等。 性能测试中包含以下测试类型： 基准测试 – 比较新的或未知测试对象与已知参照标准（如现有软件或评测标准）的性能。 争用测试：- 核实测试对象对于多个主角对相同资源（数据记录、内存等）的请求的处理是否可以接受。 性能配置 – 核实在操作条件保持不变的情况下，测试对象在使用不同配置时其性能行为的可接受性。 负载测试- 核实在保持配置不变的情况下，测试对象在不同操作条件（如不同用户数、事务数等）下性能行为的可接受性。 强度测试- 核实测试对象性能行为在异常或极端条件（如资源减少或用户数过多）之下的可接受性。 容量测试- 核实测试用户同时使用软件程序的最大数量。 性能评价通常是和用户代表一起协作并且以多级方法执行的。 性能分析的第一级涉及单一主角/用例实例的结果评价和多个测试执行的结果比较。例如，在测试对象上没有其他活动的情况下，记录单一主角执行单一用例的性能行为，并将结果与相同主角/用例的其他几个测试执行进行比较。第一级分析有助于确定可以表明系统资源中存在争用的趋势，该趋势将影响从其他性能测试结果所得出的结论的有效性。 分析的第二级检查特定主角/用例执行的摘要统计信息和实际数据值，以及测试对象的性能行为。摘要统计信息包括响应时间的标准偏差和百分位分布，这些信息显示了系统响应的变动情况，正如每个主角所见到的一样。 分析的第三级有助于理解性能问题的起因和加权值。该详细分析采用低级数据并且使用统计方法，帮助测试员从数据中得出正确的结论。详细分析为决策提供客观和定量的标准，但是它耗时较长，并且要求对统计学有基本的理解。 当性能行为差异确实存在，或是由于某些与测试数据收集相关的随机事件引起时，详细分析使用统计加权值的概念来帮助理解。即认为在基本级上，任何事件都具有随机性。统计测试确定是否存在无法用随机事件解释的系统差异。

 

2.软件性能测试的执行

 

与功能测试相比，性能测试更复杂，执行难度更大，对测试工具的依赖也更强，更需要过程模型的指导（如：PTGM性能测试通用模型）

PTGM模型主要包括6个步骤：

（1）测试前期准备，通常要求软件已经通过功能测试并修正了缺陷

（2）引入测试工具

（3）指定测试计划，需要明确性能测试的目标

（4）测试设计和开发，准备好软件运行的软硬件环境，用户并发使用软件的测试场景，每个用户具体如何使用该软件

（5）测试执行和管理

（6）测试结果分析

 

SEI负载测试计划过程：

测试负载主要考虑一下六个方面

（1）目标，指的是商业目标而不是技术目标，明确软件达到什么样的负载能力才能满足项目的商业目标

（2）用户，是指可能产生负载或使用资源的人和软件过程

（3）用例，是指用户对软件的不同使用方式

（4）使用环境，软件在实际交付的运行环境中

（5）测试环境，在测试中的环境

（6）使用场景

 

LoadRunner的性能测试过程：

这是一个针对LoadRunner工具进行设计的测试过程，总体上是满足PTGM的

（1）指定测试计划

（2）设计测试用例

（3）设计测试脚本（将测试用例转换成可以执行的测试脚本）

（4）创建测试环境（测试脚本运行的测试环境）

（5）运行测试脚本

（6）分析测试结果

 

3.性能分析

 

（1）性能下降曲线的分析

主要包括三个区间：性能平坦区，性能轻微下降区，性能急剧下降区

（2）快速性能瓶颈识别：优先考虑吞吐量，优先考虑简单的测试用例，优先考虑基础系统的性能

（3）性能计数器的分析：内存，处理器，I/O磁盘，进程等分析

 

4.性能测试的自动化

 

包括创建进程或者线程来模拟用户产生压力

对性能进行监控

对结果进行分析

依赖一些性能测试工具

 

5.软件可靠性的概念

 

（1）错误，缺陷，故障和失效

错误：指的是软件在生命周期中各个阶段的状态和行为与人们的期待不一致的偏差，不单单是软件系统本身，中间产品的偏差也算是软件错误

缺陷：指的是软件中一切不好的方面，比错误的范围更广，如，一个不易理解的软件不是错误的，但是可以归为缺陷

故障：是指软件代码中的错误

失效：是指由故障引起的在软件运行期间的错误

 

（2）软件可靠性的定义

在规定的条件下，在规定的时间内，软件不引起系统失效的概率

在规定的时间周期内，在所述条件下程序执行所要求的功能的能力

 

6.软件可靠性测试的执行

 

软件可靠性测试的目的是收集软件测试时揭示的软件故障的情况，并对其进行整理

主要包括5个步骤：

（1）确定可靠性目标

（2）定义软件运行剖面

（3）设计测试用例

（4）实行可靠性测试

（5）分析测试结果

 

7.软件可靠性分析

 

（1）失效模式影响分析

（2）严酷度分析

（3）故障树分析

（4）事件树分析

（5）潜在路线分析