TEST 产品说明书的测试，需求文档测试

1.对产品说明书进行高级审查

测试产品说明书的第一步不是马上钻进去找缺陷，而是站在一个高度上进行审查。审查产品说明书是为了找出根本性问题、疏忽或遗漏之处。也许这更像是研究而不是测试，但是研究的根本是为了更好的了解软件该做什么。如果能够很好地理解产品说明书后的诸多为什么和怎么做，就可以更好的进行细节检查

1）.假设自己是客户

了解用户所想是很重要的。请记住。质量的定义是“满足客户需求”，软件测试员必须连接并测试软件是否符合那些要求。

假设什么知识也没有（相关行业的知识背景）。如果审查产品说明书的某一部分时不理解，不要假定他是对的而把它放掉。

2）.研究现有的标准和规范

公司惯用语和约定

行业要求

政府标准

图形用户界面（GUI）

安全标准

软件测试员的任务不是定义软件要符合何种标准和规范，那是项目经理或者编写软件说明书的人的任务。软件测试员要做的是观察，“检查”采用的是否正确，有无遗漏。在对软件进行确认和验收时，还要注意是否与标准和规范想抵触，把标准和规范视为产品说明书的一部分。

3）审查和测试类似软件

审查竞争对手的产品

规模：软件功能强大还是单一？代码多还是少？这些差别与测试有关吗？

复杂性：软件简单还是复杂？这会影响测试吗？

测试性：是否有足够的资源、时间和经验来测试软件？

质量和可靠性：软件是否完全满足质量要求？可靠性高还是低？

安全性：竞争对手软件的安全性和自身的比较起来如何？

　　阅读关于竞争对手软件的评价方面的联机或印刷文章，这对安全方面的问题特别有帮助，因为软件测试员偶然使用软件并不一定能发现安全方面的缺陷。然而在出版物中，这些问题会特别引起关注

2.产品说明书的低层次测试技术

1）产品说明书属性检查清单

　　优秀的产品说明书的8个重要属性

完整：是否有遗漏和丢失？完全吗？单独使用时是否包含所有内容？

准确：既定解决方案准确吗？目标定义明确吗？有没有错误？

精确、不含糊、清晰：描述是否一清二楚？是否有单独的解释？容易看懂和理解吗？

一致：产品功能描述是否自相矛盾，或与其他功能有无冲突（测试某一功能时要用系统功能的交互图和设计范围）

贴切：描述功能的陈述是否必要？有没有多余的信息？功能是否符合原来的客户要求？

合理：在规定的预算和进度下，以现有人力、工具和资源能否实现？

代码无关：产品说明书是否坚持定义产品，而不是定义其软件设计、架构和代码？

可测试性：功能能否测试？给测试员提供的建立验证操作的信息是否足够？

在测试产品说明书、阅读文字、检查图表时，要仔细对照上述清单，看看他们是否具有这些属性。如果不具备，那就是发现了需要指出的缺陷

2） 产品说明书术语检查清单

总是、每一种、所有、没有、从不。如果看到此类绝对或肯定的描述，需要确认的是这样的。软件测试原需要考虑违反这些的情况。

当然、因此、明显、显然、必然。这些话意图说服你接受假定情况，不要中了圈套。

某些、有时、常常、通常、惯常、经常、大多、几乎。这些话太过模糊。“有时”发生作用的功能无法测试

等等、诸如此类、以此类推、例如。以这样的次结束的功能清单无法测试。功能清单要绝对或者解释明确，以免让人对功能清单内容产生迷惑

良好、迅速、廉价、高效、小、稳定。这些无法量化的术语，无法测试。如果说明书中出现这些用语，必须进一步准确定义其含义

处理、进行、拒绝、跳过、排除。这些用户可能会隐藏大量需要说明的功能

如果.....那么......(没有否则)。找出“如果.....那么....”而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎么样.

完整性

　　1.所有的需求  包括：无论是功能、性能、设计约束、属性，还是外部接口，都必须确认和处理

　　2.对各类输入数据都做了处理

　　注意：包括非法数据

　　3.对所有数据、图表、框图和术语的定义进行了标识

　　4.使用TBD(to bo determined)标明缺陷

　　TBD的说明：1、必须说明造成不明确的原因；2、必须说明如何消除不明确的地方