基于需求的测试研究-静态测试(1)

lsekfe

基于需求的测试分为三个阶段：

• 静态测试
• 测试设计
• 验证覆盖
  
  
  

接下来让我带领大家一起揭开RBT第一个阶段也是最重要的一个阶段——静态测试的面纱！

什么是静态测试

静态测试是基于期望属性、专业经验、通用标准来对工作件的特征进行详细检查的一种测试方法。所谓工作件，也就是静态测试的测试对象，是不同种类的产品交付件，即一切项目过程文档，例如系统设计说明书、产品需求文档、开发设计文档（详细设计说明书、数据库设计说明书）、源代码以及测试文档。

静态测试的特质

静态测试的查错和分析功能是其他方法所不能替代的。

静态测试的目的是确保工作件中的缺陷被尽早发现和处理，尽可能在软件开发生命周期的早期阶段关闭缺陷产生的源头。

静态测试人员主要是寻找三类缺陷：错误，意味着没有进行正确的改变；遗漏，意味着有些该改变的没有改变；额外，意味着非有意的改变或增加。

静态测试的好处

1、 静态测试有助于缓解测试执行阶段工作的压力

传统测试方法，测试部门的工作往往是前松后紧，工作分配和工作压力极不平衡。

分析：大家经常会听到测试人员反应“现在在测试准备阶段，就是写写测试用例，不忙，忙的时候还是测试执行的时候，经常要加班加点”。造成这种现象的原因就在于，测试人员还只是把测试开发完成后的“软件成品“当做“测试工作的内容”，并不把前期的用于制造软件的“设计图纸”——需求、设计文档当做测试对象来花时间和精力进行测试。

运用静态测试后：

加深对项目的理解，使测试计划和测试设计质量得到提高；

使得测试用例全面、有效，从“撞问题”转变为有目的的“找问题”

提前了对项目的理解，减少了测试执行时的摸索时间，从而加快测试进度

提前发现问题，降低缺陷修复成本、回归测试成本以及沟通成本，同时降低项目风险，减轻测试执行时的压力

2、 静态测试可有效缓解因工期和人力因素对项目的影响

目前软件项目普遍都存在：项目周期短和人力资源不足的情况。

分析：在这种情况下，往往会延长开发时间、压缩设计和测试执行的时间，以保证项目能如期完成。项目自身抵抗风险的能力下降，某些高风险的缺陷一旦在测试阶段暴露，将可能会导致设计被推翻，需求被迫变更，大量的代码重写和之前测试工作的徒劳，严重影响项目质量和项目进度，让项目陷入恶性循环。

运用静态测试后：

提前发现设计问题，协同开发一起做好功能设计，避免项目走弯路

完善测试设计，明确描述分歧，细化处理功能，提高编码质量和测试质量

一定程度地缓解项目工期压力和人力资源压力

3、 静态测试有助于发挥测试人员的潜力

传统的测试是按照需求设计文档来验证程序的问题，没料到这个”唯一的”“测试依据”其实很多时候都靠不住，问题丛生，暗含杀机。

分析：当测试人员养成完全依赖UC（或者PRD）的习惯后，变会缺乏主动思考、创新思考的能力。下意识的就把UC和PRD当成测试的立足点，以此来验证软件产品的质量，这样将导致测试人员发现的问题质量低，问题深度不够，难以发现用户体验相关的缺陷，并且容易使测试人员当因某个测试问题与开发意见不一时，争辩时腰板挺不直，使问题得过且过，丧失测试人员的地位。

运用静态测试后：

激发了测试人员的潜力，层层深入业务核心，从被动接受，转变为主动思考，敢于质疑设计，敢于异议架构！

对测试人员思考和分析能力的锻炼；

姿态的转变——“客户的代言人”

4、 静态测试有助于测试准备阶段对测试人员的绩效评估

分析：传统测试在测试准备阶段，测试经理除了通过测试用例对测试人员的工作情况进行评估外，很难有其他方法对其绩效进行了解。而测试设计和测试用例的产出相对是滞后的，这样就给测试经理提前预警带来了难度，一旦到了测试准备阶段后期才发现问题，就让测试准备工作陷入被动的境地。

运用静态测试以后

每天可以对每位测试人员按功能模块提交的静态测试问题数进行统计；

每周都可以为每位测试人员应提交的静态测试问题数目制定目标；

每周可以对每位测试人员的静态测试问题质量进行评估和总结，营造积极进取的测试团队氛围

静态测试的问题分类及切入点

文档规范问题

“文档规范”类的问题属于所有问题分类中比较浅显，但同时也是问题数量较为庞大的一类。诸如软需中字段缺失，字段描述错误，错别字等等。

查找方法：多采用横向对比、纵向对比、多元对比的方法，细心、耐心的查找即可做好。当项目大或者工期紧的情况，可以不必花太多精力在此类问题上。

设计错误问题——“设计出来了，但是设计错了”

此类问题需要对程序处理流程和业务处理逻辑非常清楚才能挖掘出来，具有较高的难度，测试经理和测试骨干应多关注和发现此类的问题。

查找方法：可在编写流程图、mm图和状态迁移图的时候，理清楚程序处理流程和业务处理逻辑，再结合PRD、UC和开发设计文档查找设计得不对的静态测试问题。

设计不完善问题——“设计出来了，但是设计得不好”

“设计不完善”类的问题在大多数文档中是频频出现的，比如前后逻辑矛盾，表述歧义，表达不清晰，逻辑混乱，存在误解等等。此类问题应该是项目组成员重点关注的问题，因为这直接影响了了解需求的深度和广度，直接影响了测试用例的编写实效，以及将来测试执行时的测试粒度和深度。

查找方法：要发现此类问题，同样可以借助编写流程图和状态迁移图，同时多思考，多分析，多询问，多考察，借助所有提交静态测试的文档，真正做到“咀嚼需求”，这样能提示测试质量和测试效果，是事半功倍。

设计遗漏问题

此类问题在各项目静态测试中所占比重是较小的，但若是有，则是将是高质量的问题。此类问题需要站得高，看得远，没有多年的相关业务背景的积淀，和对项目的充分广泛的涉猎，此类问题是很难发现的。

查找方法：在充分了解业务相关背景的基础上，凭借业务设计经验，充分理解了文档和设计思想后，才能发现其中没有考虑到的问题。

需求问题

此类问题是以发现目前设计与原始需求相矛盾、相抵触或者不一致的问题为目的，弥补因某些原因错写、漏写的需求要点，保证设计的完整性、完善性和正确性。

查找方法：综合前面所有的查找方法。

wangqiang88