7.2 测试用例编号规则
每个测试用例都有自己唯一的编号。根据工作的实际需要，我们规定在每个用例名称前面必须写上用例编号，用例编号的定义分以下几大类：
1、根据需求编写测试用例：
需求编号＋用例一级目录号＋用例二级目录号＋用例号
R001 ＋ 01 ＋ 01 01
2、根据功能编写测试用例：
用例一级目录号＋用例二级目录号＋用例号
F001 ＋ 001 ＋ 001
在编写测试用例时，我们会根据系统模块的具体情况从不同的角度去考虑测试用例的编写，有些是通过操作步骤来编写，有些则是根据功能条件来编写，更有可能是根据测试目的来编写，为了区分这些用例，我们规定在每种用例前写上对应的编码。具体见下表：
|
需求 |
功能 |
业务 |
性能 |
|
R(Requirement) |
F(Function) |
B(Business) |
P(Performance) |
8、 测试用例编写方法
8.1 测试用例编写准备
从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
8.2 测试用例编写方法
测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：
1. 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2. 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3. 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4. 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5. 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6. 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7. 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。
8. 等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9. 错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10. 效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11. 可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
12. 可移植性：在不同操作系统及硬件配置情况下的运行性。
13. 回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员
14. 比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较。
【说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同】
1. 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。
2. 单元（模块）测试（组件、控件）测试：重点测试第5项。
3. 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。
4. 系统测试：重点测试第3、7、10、11、12、14项。
5. 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。
6. GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。
7. 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。
