|
什么是静态测试?
起初的时候,我并不知道什么基于需求的测试,只知道静态测试。
静态测试,很多测试书籍中的定义是:相对动态测试而言,不需要运行代码,针对文档进行的测试。我们知道,一份软件产品包含三个部分,其一是代码,其二是数据,第三部分就是文档。可见,文档是软件产品的重要组成部分,那么,不言而喻,文档的质量将直接关系到软件产品的质量,将直接关系到软件研发的成败,将直接关系到软件产品的生命力!
在一次有关静态测试的技术交流会上,IBM的专家团队对在场的所有人发问:有什么证据可以证明你们已经做过这件事?——难道仅仅只是可运行的代码和游离于代码之上的数据吗?
我在思考:经验依靠什么方式来传承和积累?怎样积累企业的资产以便重用?怎样让接手的同事立马开展工作?怎样使Req. Spec.不同于poetry,不同的人有一致的理解?
有人会告诉我:质量和效率是硬币的两面!
我说,用长远的眼光来看,质量是矛盾的主要方面,最终产品是过程的产物,可以用不断的过程改进来提高产品的质量,而把过程文档化是保证质量的有效手段!
有人又会告诉我:网络世界日新月异,我们只有“敏捷”起来才能应对这些变化。
我说,“敏捷”离不开“高质量”的文档,如果离开了文档,那就是“被敏捷”!
有人又会问我:那到底什么是静态测试,难道就是找错别字吗?
下面是需求里的一句描述:“如果在ATM取现超过400美元则拒绝该请求,否则允许在ATM取现并更新客户帐户余额。”
静态测试时将会问道:
•不同品牌的ATM都会遵守这个取现规则吗?
•ATM的取现规则容许取现的最高额度是400美元吗?
•帐户余额是否可用?如果余额不足,会怎样?
•取400美元倍数的金额是否允许?
•那些类型的帐户允许在ATM上取现?
•如果卡片无效是否允许持卡人使用该卡的余额?
•如果取现请求被拒绝,应该提示客户什么信息?
这个表面上看起来比较完善和精确的需求,仔细一推敲,仍然可以派生出很多问题,如果这些问题被详细记录下来并被解决,成本将会比等到开始编码再来考虑这些问题的成本低很多。
这才是静态测试!
什么是基于需求的测试?
基于需求的测试(RBT:Requirements-based testing)是一种“黑盒”测试流程策略,主要是通过分析检查系统的需求定义,尽早地修正和验证需求,然后使用各种黑盒测试设计方法来设计最小数目的测试用例,同时满足最大的功能覆盖。
“基于需求的软件测试方法”由理查德•本德先生(Richard Bender )1977年始创并不断丰富,这一方法会使测试更加有效,因为它使测试更专注于质量问题产生的根源。RBT曾经成功的应用到几乎所有类型的应用,从C/S架构的软件系统到B/S架构的软件系统,再从嵌入式系统到超级计算机系统以及两者之间的任意类型系统,同时,RBT也能用来测试硬件的功能,所有的业务关键、任务关键、或者安全关键软件都应该采用RBT测试流程。因此,RBT从上世纪90年代起为中国软件测试工程师使用至今。
我个人认为,首先,RBT是一种测试流程策略,它包含着一系列的过程和方法;其次,RBT包含三个阶段:
•二义性评审;
•测试设计;
•验证覆盖。
其中第一阶段:二义性评审,静态测试的工作恰恰包含了这部分工作,并且远远不局限于此。
在后续的文章中,我将用“静态测试”代替“二义性评审”的描述,先从字面上予以区分。
参考文献:
James Bach 《Risk and Requirements-Based Testing》
Gary E. Mogyorodi, B.Math., M.B.A.Principal Consultant 《RBT Ambiguity Reviews》
STSC CrossTalk 《What Is Requirements-Based Testing》
陈能技 《基于需求的测试(RBT)》
邰晓梅 Blog-《基于需求的测试》
中国工商银行 《静态测试培训材料》
本研究隶属于万剑归宗项目组。 |
|