测试的基本理论与方法（3）

测试的基本理论与方法（3）

企业的测试策略

　　理念：

　　企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。

　　用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代价。

　　如何合理地减少测试工作量

　　减少冗余的测试

　　白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来），这样的测试是冗余的。

　　在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。

　　减少无价值的测试

　　无价值的测试通常是由于不懂得测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。

　　如何“偷工减料”

　　有一些“短、平、快”的项目，经费本来就少，用户对质量要求也马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要部分可以忽略或将来再测试。

　　“偷工减料”方法的测试优先级：

　　哪些功能是软件的特色？

　　哪些功能是用户最常用的？

　　如果系统可以分块卖的话，哪些功能块在销售时最昂贵？

　　哪些功能出错将导致用户不满或索赔？

　　哪些程序是最复杂、最容易出错的？

　　哪些程序是相对独立，应当提前测试的？

　　哪些程序最容易扩散错误？

　　哪些程序是全系统的性能瓶颈所在？

　　哪些程序是开发者最没有信心的？

　　测试何时结束？

　　一、基于测试用例的规则

　　（1）先构造测试用例（并请有关人员进行评审）。

　　（2）在测试过程中，当测试用例的不通过率达到20％时，则拒绝继续测试，待开发人员修正软件后再进行测试。

　　（3）当功能性测试用例通过率达到100％，非功能性测试用例通过率达到90％时，允许正常结束测试。

　　该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试用例非常糟糕，那么该规则就失效了。

　　二、基于“测试期缺陷密度”的规则

　　把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间－缺陷数”的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。

　三、基于“运行期缺陷密度”的规则

　　把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间－缺陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时，则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试阶段，即客户试运行软件期间。

　　需求经常变更怎么办

　　需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。

　　需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是上一次测试有可能白做了，如果软件变更比较大的话。

　　测试人员不要只是自认倒霉，应当主动作些应变：

　　（1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测试。

　　（2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。

　　（3）向领导反映需求变更对测试造成的影响，为自己争取余地。

　　（4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高）。

　　引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能，该怎么办？

　　如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试了事。两种情况都要报告给项目经理，有可能导致一系列的变更。

　　测试规范

　　测试流程

　　第一步：制定测试计划。该计划被批准后转向第二步。

　　第二步：设计测试用例。该用例被批准后转向第三步。

　　第三步：如果满足“启动准则” ，那么执行测试。

　　第四步：撰写测试报告。

　　第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。

　　测试信息流

　软件测试的策略

　　在软件工程中，测试过程应该按4个步骤进行，即单元测试、组装（集成）测试、确认测试和系统测试。下图给出了软件测试经历的4个步骤。

　　测试规范

　　测试启动准则

　　同时满足以下条件，允许开始测试：

　　（1）测试计划已经制定并且通过了审批；

　　（2）测试用例已经设计并且通过了审批；

　　（3）被测试对象已经开发完毕并等待测试。

　　测试完成准则

　　对于非严格系统可以采用“基于测试用例”的准则。同时满足以下条件允许结束测试：

　　（1）功能性测试用例通过率达到100％；

　　（2）非功能性测试用例通过率达到90％时。

　　对于严格系统，应当补充“基于测试期缺陷密度”的规则：

　　（3）相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。

　　《测试计划》：指明范围、方法、资源，以及相应测试活动的时间进度安排表的文档。

　　《测试方案》：指明为完成软件或软件集成特性的测试而进行的设计测试方法的细节文档。

　　《测试用例》：指明为完成一个测试项的测试输入、预期结果、预期执行条件等因素的文档。

　　《测试规程》：指明执行测试时测试活动序列的文档。

　　《测试报告》：指明执行测试结果的文档。

　　测试计划的参考模板

　建立测试计划

　　定义测试目标

　　开发测试矩阵

　　软件模型

　　结构特性

　　批量测试的阶段和用例

　　为在线系统作概念上的测试脚本

　　软件测试矩阵

　　定义测试管理

　　测试计划的一般性信息

　　定义测试里程碑

　　定义管理上的检查点

　　书写测试计划

　　评审测试计划

　　涉及评审的问题

　　评审测试的开始时间是否会延期

　　有没有抵触评审的角色

　　一段时间内是否很难得到工作的检查信息。

　　更换工具有可能导致他们反感评审工作

　　评审结果可能会影响对个人的工作评价

　　对于最终成品的检查

　　项目的需求规格说明书

　　软件返工/维护的文档

　　升级后的技术文档

　　被更改的源程序

　　测试计划

　　用户手册（包括在线帮助）

　　测试用例

　　测试用例的基本要素有：目的、前提条件、输入数据或动作、期望的响应。

　　建议测试方法

　　测试方法

　　测试用例的概念是简单的

　　建立有效的测试用例是复杂的

　设计测试文件

　　测试用例应当包含合法的和非法的输入

　　每一个动作只进行一次关键操作

　　输入测试数据

　　分析结果

　　尝试将测试文件违反程序的规则进行输入

　　压力测试的测试工具

　　以大信息量的数据进行输入

　　这是一个昂贵的测试，应根据需要来选择

　　在线系统需要做压力测试

　　测试报告

　　目标

　　表示出目前项目的实际状况

　　明确什么是测试做的工作，什么是不作的工作。

　　给出系统的操作性能的评价

　　明确什么时候系统可以进行产品化的工作

　　关注点

　　测试报告只有真正需要的时候才有用，需要配合市场和管理

　　测试的信息是不充分的（对于评价一个项目来说）

　　测试状况并不能真实的反应个人的状况

　　测试期间数据的收集

　　有关测试结果的积累数据

　　测试任务，测试集合和测试事件的描述

　　缺陷分析

　　由于计划的问题，导致没有发现的缺陷的数据

　　严重的缺陷

　　缺陷类型

　　为什么缺陷没有发现

　　效果

　　报告目前的软件状态

　　功能/测试矩阵

　　功能测试的状态报告，侧重点分析

　　关于功能的工作时间轴

　　期望发现 VS 实际发现的缺陷比

　　没有发现的缺陷和改正的缺陷的差距

　　按照类型分类，没有改正的缺陷的平均值

　　缺陷分类报告

　　测试活动报告

　　软件系统的主要测试内容及技术

　　接口与路径测试

　　功能测试

　　健壮性测试

　　性能测试

　　用户界面测试

　　信息安全测试

　　压力测试

　　可靠性测试

　　安装/反安装测试

　　接口与路径测试

　　数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常值”之分，所以输入的组合数可能并不少。根据接口的定义，可以推断某种输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑盒方式的功能测试，其方法十分相似。

　　一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。

　　对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一的输出，输入与输出之间的路径也是唯一的。由于接口测试中的输入是有代表性的，因此相应的路径也具有代表性，不用得着费煞苦心地去找测试路径。

　　路径测试的检查表

　　数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错误处理

　　由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没有被测试。预防措施有：

　　观察是否有程序语句从来没有被执行过。如果发生在这种情况，要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一些路径。

　　要特别留意函数体内的错误处理程序块（如果存在的话），这是最易被人疏忽的路径，隐患最多。