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

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

　　静态测试

　　测试设计

　　验证覆盖

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

　　什么是静态测试

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

　　静态测试的特质

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

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

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

　　静态测试的好处

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

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

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

　　运用静态测试后：

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

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

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

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

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

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

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

　　运用静态测试后：

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

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

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

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

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

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

　　运用静态测试后：

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

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

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

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

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

原文转自：http://www.uml.org.cn/Test/201208244.asp