Sugar项目回顾（十）

  我们知道，编写系统测试用例的目的是验证系统功能是否符合需求规格定义/验证系统的可靠性、可维护性、可用性、稳定性、容错性。在实践中，我们是用QC来管理用例，让用例与需求建立对应的关联。用例应该根据系统需求规格说明书、各种规范来设计、依据的不是软件本身
不仅仅包括功能测试用例、同时还应该包含属性测验试用例。它的格式分为八大要素：

30号，我们对生成的几千条用例进行了评审，并全部录入到QC当中。用例设计的好坏直接影响测试的成败。主要是从覆盖率这个角度来考核测试用例的好坏。

  这里顺带提一下测试方案，一个测试方案它应该有：

1．概述：概述被测对象和特性，简要描述被测对象的需求要素、测试设计准则，以及测试对象的历史。

2．被测对象：确定被测对象及其版本/修订级别。

3．应测试的特性：确定应测试的所有特性和特性组合。

4．不被测试的特性：确定被测对象具有的哪些特性和特性组合将不被测试，说明不被测试的原因。

5．测试设计综述：指定一个可以保证这些特性被足够地测试的途径。

6．测试模型：明确本测试方案的测试原理和操作流程，为设计用例提供指导。

7．测试需求：根据本阶段的测试目标从不同角度来明确本阶段各种需求因素。a)环境需求b)被测对象需求c)测试工具需求d)测试代码需求

8．  测试设计：描述各个阶段需要运用的测试要素。（包括测试用例、测试工具、测试代码的设计思路和设计准则）测试工具设计/测试代码设计/测试规程设计/测试用例设计

由此可见，方案又决定了用例的成败，方案比计划更详细。