什么是静态测试？
起初的时候，我并不知道什么基于需求的测试，只知道静态测试。
静态测试，很多测试书籍中的定义是：相对动态测试而言，不需要运行代码，针对文档进行的测试。我们知道，一份软件产品包含三个部分，其一是代码，其二是数据，第三部分就是文档。可见，文档是软件产品的重要组成部分，那么，不言而喻，文档的质量将直接关系到软件产品的质量，将直接关系到软件研发的成败，将直接关系到软件产品的生命力！
在一次有关静态测试的技术交流会上，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)》
邰晓梅：《基于需求的测试》
中国工商银行：《静态测试培训材料》
相关链接：
