需求测试总结

1. 软件工程中的几个概念
 1) 软件开发模型：螺旋模型（waterfall model + prototype model= spiral model）
 2) 螺旋模型：需求定义、风险分析、工程实现、评审、迭代结果必需尽快收敛到客户允许或者可以接受的目标范围。
 3) 以形式化开发方法为基础的变换模型：
  (1) 软件定义：确定软件的工程需求，分为：可行性研究（决定“做还是不做”：经济、技术、社会环境和人）和需求分析（决定“做什么，不做什么” ：需求的获取、分析、规格说明、变更、验证、管理 ）两个阶段。
  (2) 通过测试用例来测试需求软件开发：按照需求规格说明的要求，从抽象到具体，逐步生成软件的过程（概要设计、详细设计、实现、集成测试、验收测试）。

2. 需求测试方法包括：
 1) 通过评审来测试需求：同行评审，组内评审;
 2) 通过测试用例来测试需求;
 3) 需求建模.
 注：我们这里的评审参与者：用户或用户代表，项目管理者，系统工程师和相关的开发人员、QA等。

2. 需求分析测试的误区：
 1) 客户说不清楚需求;
 2) 需求自身经常变动;
 3) 分析人员或客户理解有误。

3. 需求规格说明的特点
 1) 完整性：不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用 T B D (“待确定”)作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的 T B D项。
 2) 一致性：一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，才能知道某一项需求是否确实正确。
 3) 可修改性：在必要时或为维护每一需求变更历史记录时，应该修订 S R S。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在 S R S中出现一次。这样更改时易于保持一致性。另外，使用目录表、索引和相互参照列表方法将使软件需求规格说明更容易修改。
 4) 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（ f i n e - g r a i n e d）的方式编写并单独标明，而不是大段大段的叙述。

4. 需求说明的特性（检查点）
 1) 完整性：不遗漏必要和必需的信息;
 2) 正确性：每一项需求都必须准确地陈述其要开发的功能;
 3) 一致性：与原始需求一致、内部前后一致。与其它软件需求或高层（系统、业务）需求不矛盾（US & WireFrame & Other datum）;
 4) 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求（需先进行可行性分析）;
 5) 明确性：不使用含糊的词语。对所有需求说明的读者都只能有一个明确统一的解释;
 6) 健壮性：需求的说明中是否对可能出现的异常进行了分析，并且对这些一场进行了容错处理(错误输入后的处理提示);
 7) 必要性：不能回溯到出处的需求项可能是多余的;
 8) 可测性：每项需求都必需使可验证的;
 9) 可修改性：良好的组织结构使需求易于修改。每项需求只应在S R S 中出现一次;
 10) 可跟踪性：应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链;
 11) 优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量。