测试用例编写规范
超级详细的测试用例设计规范
超级详细的测试用例设计规范当设计测试用例时，遵循一定的标准和规范可以确保测试的全面性、一致性和有效性。
以下是一个详细的测试用例设计标准和规范，可根据实际情况进行调整：1. 测试用例命名规范：•用例名称应简洁而具有描述性，清楚地说明被测功能。
•使用有意义的单词和短语，避免使用模糊或不清楚的术语。
2. 测试用例编写规范：•每个测试用例应该有一个明确的目标和预期结果。
•测试用例应尽量独立，避免相互依赖。
•每个用例应包含一个简短但详细的描述，涵盖用例的目标和步骤。
3. 测试用例结构规范：•用例编号：每个用例应有唯一的编号。
•测试优先级：指明用例的优先级，如高、中、低。
•预置条件：描述运行用例所需的初始条件。
•测试步骤：详细列出执行测试所需的步骤。
•预期结果：描述每个步骤的预期结果，以便进行比对。
4. 测试数据规范：•用不同的测试数据组合编写多个测试用例，覆盖不同情况。
•包括边界值、无效输入、正常情况等测试数据。
5. 预期结果规范：•预期结果应具体、明确，可以是文本描述或数值。
•预期结果应与实际结果进行比对，以判断测试是否通过。
6. 步骤的顺序：•用例中的步骤应按照逻辑顺序编写，确保测试流程清晰。
7. 特殊情况和异常处理：•包括测试异常输入、错误处理机制等。
•确保测试能够捕获并正确处理各种异常情况。
8. 重复性测试规范：•在必要时，包括对于相同操作的多次执行测试，以验证重复性。
9. 跨平台/浏览器/设备测试规范：•如适用，确保测试在不同的平台、浏览器或设备上都能正常运行。
10. 结果记录和报告规范：•每次测试运行后，记录实际结果和测试日期。
•创建详细的测试报告，包括测试用例执行情况、结果、问题和建议。
11. 审查和验证：•所有编写的测试用例应该经过审查和验证，确保完整和正确性。
12. 定期维护和更新：•定期审查测试用例，以确保其与应用程序的变化保持同步。
遵循这些测试用例设计的标准和规范，可以帮助您创建清晰、一致且有效的测试套件，确保对软件功能的全面测试和稳定性验证。
测试用例编写规范
测试用例编写规范
（一）测试用例命名规则
以功能模块和业务流程进行命名。
（二）用例编号规则
以测试模块名称的第一个字母进行命名（大写），若测试模块名称比较长是，可进行简写。
一般简拼不超过5各字母。
如：
1.测试模块为“用户管理”，功能编号为“YHGL”
2.测试模块为“行政单位管理”，功能编号为“DWGL”
3.功能编号规则直接以001、002、003
（三）测试用例文档书写内容
1.被测试对象的介绍
2.测试范围与目的
3.测试环境与测试辅助工具的描述
4.功能测试用例主要元素
（四）前置/操作描述
1.前置条件（可选）：系统权限配置或前、后台配置描述（所有进行操作的前提条件）。
2.操作：测试的操作步骤描述。
（五）功能点
功能点描述
（六）输入数据
前期数据准备
（七）预期结果
描述输入数据后程序应该输出的结果
（八）测试结果
描述本条用例的实际测试情况，并判断实际测试结果与预期结果的差别。
（九）Bug编号/Bug简要描述：
需要进流程的对应事物流程的编号，及简要说明。
（十）备注
测试过程中遇到的问题等情况说明。
测试用例编写规范
测试用例编写规范一、测试用例编写准备从配置管理员处申请软件配置：《需求规格说明书》和《设计说明书》；根据需求规格说明书和设计说明书，详细理解用户的真正需求，并且对软件所实现的功能已经准确理解，然后着手制订测试用例。
二、测试用例制定的原则测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。
测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：1、正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。
2、容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出，输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示并进行相应处理。
把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。
3、完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。
4、接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。
5、数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。
6、边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。
7、压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。
进行测试。
8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。
9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。
10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。
11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。
测试用例规范
测试用例规范测试用例规范是指在软件测试过程中对测试用例进行规范化的描述。
它包括用例编号、用例名称、前置条件、测试步骤、预期结果、实际结果、测试结果等内容，旨在提高测试用例的可读性和可维护性，提高测试效率和质量。
一、用例编号用例编号是对测试用例进行唯一标识的编号，通常由字母和数字组成。
编号的命名应该具有唯一性和规律性，便于查找和管理。
二、用例名称用例名称是对测试用例进行简洁明了的描述，以便于测试人员快速了解用例的功能和目的。
三、前置条件前置条件是指执行测试用例之前需要满足的条件或准备工作。
这些条件可以是软件环境、硬件环境等。
四、测试步骤测试步骤是对测试用例具体操作的描述，包括输入数据、操作步骤和操作环境等。
五、预期结果预期结果是在执行测试步骤后期望得到的结果，通常是软件的输出、显示或状态改变等。
六、实际结果实际结果是在执行测试步骤后实际观察到的结果，可以与预期结果进行对比，以判断测试是否通过。
七、测试结果测试结果是根据实际结果对测试用例进行评估的结果，通常包括“通过”、“失败”和“阻塞”等。
八、补充说明补充说明是对测试用例中一些特殊情况或要求的描述，包括限制条件、特殊操作和预期行为等。
九、用例状态用例状态是指用例的执行状态，可以是“未执行”、“执行中”和“已执行”等。
十、用例设计人员用例设计人员是指负责设计和编写该用例的测试人员，有助于追溯和沟通。
以上是测试用例规范的主要内容，通过规范化的测试用例描述，可以提高测试效率和质量，减少测试人员之间的沟通成本，便于测试管理和追溯。
在实际测试过程中，应根据项目需求和实际情况进行适当的调整和优化。
软件测试测试用例编写及执行规范
软件测试测试用例编写及执行规范第1章测试用例编写概述 (4)1.1 测试用例定义 (4)1.2 测试用例目的 (4)1.3 测试用例编写原则 (4)第2章测试用例结构 (4)2.1 测试用例编号 (4)2.2 测试用例标题 (4)2.3 测试用例描述 (4)2.4 预置条件 (4)2.5 测试步骤 (4)2.6 预期结果 (4)2.7 实际结果 (4)2.8 测试结论 (4)第3章测试用例编写规范 (4)3.1 编写规则 (4)3.2 测试用例命名规范 (4)3.3 测试用例描述规范 (4)3.4 测试步骤与预期结果规范 (4)第4章测试用例执行流程 (4)4.1 测试用例执行准备 (4)4.2 测试用例执行过程 (4)4.3 测试用例执行结果记录 (5)4.4 测试用例执行异常处理 (5)第5章测试用例执行管理 (5)5.1 测试用例执行计划 (5)5.2 测试用例执行进度监控 (5)5.3 测试用例执行结果汇总 (5)5.4 测试用例执行报告 (5)第6章测试用例评审 (5)6.1 评审目的 (5)6.2 评审流程 (5)6.3 评审标准 (5)6.4 评审结果处理 (5)第7章测试用例维护 (5)7.1 测试用例更新时机 (5)7.2 测试用例更新流程 (5)7.3 测试用例版本管理 (5)7.4 测试用例维护记录 (5)第8章测试用例管理工具 (5)8.1 测试用例管理工具选型 (5)8.2 测试用例管理工具使用 (5)8.3 测试用例管理工具维护 (5)8.4 测试用例管理工具优化 (5)第9章自动化测试用例编写 (5)9.1 自动化测试用例特点 (5)9.2 自动化测试用例编写规范 (5)9.3 自动化测试用例编写工具 (5)9.4 自动化测试用例编写实践 (5)第10章自动化测试用例执行 (5)10.1 自动化测试用例执行策略 (5)10.2 自动化测试用例执行过程 (6)10.3 自动化测试用例执行结果分析 (6)10.4 自动化测试用例执行优化 (6)第11章移动端测试用例编写与执行 (6)11.1 移动端测试用例特点 (6)11.2 移动端测试用例编写规范 (6)11.3 移动端测试用例执行策略 (6)11.4 移动端测试用例执行实践 (6)第12章测试用例编写与执行最佳实践 (6)12.1 测试用例编写最佳实践 (6)12.2 测试用例执行最佳实践 (6)12.3 测试用例管理最佳实践 (6)12.4 测试团队协作最佳实践 (6)第1章测试用例编写概述 (6)1.1 测试用例定义 (6)1.2 测试用例目的 (6)1.3 测试用例编写原则 (7)第2章测试用例结构 (7)2.1 测试用例编号 (7)2.2 测试用例标题 (7)2.3 测试用例描述 (8)2.4 预置条件 (8)2.5 测试步骤 (8)2.6 预期结果 (8)2.7 实际结果 (8)2.8 测试结论 (8)第3章测试用例编写规范 (8)3.1 编写规则 (8)3.1.1 测试用例目的明确 (8)3.1.2 测试用例独立 (9)3.1.3 测试用例简洁明了 (9)3.1.4 测试用例分类 (9)3.1.5 测试用例优先级 (9)3.2 测试用例命名规范 (9)3.2.1 命名原则 (9)3.2.2 命名示例 (9)3.3 测试用例描述规范 (9)3.3.1 测试用例标题 (9)3.3.2 测试用例描述 (9)3.3.3 描述示例 (10)3.4 测试步骤与预期结果规范 (10)3.4.1 测试步骤 (10)3.4.2 预期结果 (10)3.4.3 步骤与预期结果示例 (10)第4章测试用例执行流程 (11)4.1 测试用例执行准备 (11)4.2 测试用例执行过程 (11)4.3 测试用例执行结果记录 (11)4.4 测试用例执行异常处理 (12)第5章测试用例执行管理 (12)5.1 测试用例执行计划 (12)5.2 测试用例执行进度监控 (13)5.3 测试用例执行结果汇总 (13)5.4 测试用例执行报告 (13)第6章测试用例评审 (14)6.1 评审目的 (14)6.2 评审流程 (14)6.3 评审标准 (14)6.4 评审结果处理 (15)第7章测试用例维护 (15)7.1 测试用例更新时机 (15)7.2 测试用例更新流程 (16)7.3 测试用例版本管理 (16)7.4 测试用例维护记录 (16)第8章测试用例管理工具 (17)8.1 测试用例管理工具选型 (17)8.2 测试用例管理工具使用 (17)8.3 测试用例管理工具维护 (17)8.4 测试用例管理工具优化 (18)第9章自动化测试用例编写 (18)9.1 自动化测试用例特点 (18)9.2 自动化测试用例编写规范 (18)9.3 自动化测试用例编写工具 (19)9.4 自动化测试用例编写实践 (19)第10章自动化测试用例执行 (20)10.1 自动化测试用例执行策略 (20)10.2 自动化测试用例执行过程 (20)10.3 自动化测试用例执行结果分析 (20)10.4 自动化测试用例执行优化 (21)第11章移动端测试用例编写与执行 (21)11.1 移动端测试用例特点 (21)11.2 移动端测试用例编写规范 (21)11.3 移动端测试用例执行策略 (22)11.4 移动端测试用例执行实践 (22)第12章测试用例编写与执行最佳实践 (23)12.1 测试用例编写最佳实践 (23)12.2 测试用例执行最佳实践 (23)12.3 测试用例管理最佳实践 (24)12.4 测试团队协作最佳实践 (24)第1章测试用例编写概述1.1 测试用例定义1.2 测试用例目的1.3 测试用例编写原则第2章测试用例结构2.1 测试用例编号2.2 测试用例标题2.3 测试用例描述2.4 预置条件2.5 测试步骤2.6 预期结果2.7 实际结果2.8 测试结论第3章测试用例编写规范3.1 编写规则3.2 测试用例命名规范3.3 测试用例描述规范3.4 测试步骤与预期结果规范第4章测试用例执行流程4.1 测试用例执行准备4.2 测试用例执行过程4.3 测试用例执行结果记录4.4 测试用例执行异常处理第5章测试用例执行管理5.1 测试用例执行计划5.2 测试用例执行进度监控5.3 测试用例执行结果汇总5.4 测试用例执行报告第6章测试用例评审6.1 评审目的6.2 评审流程6.3 评审标准6.4 评审结果处理第7章测试用例维护7.1 测试用例更新时机7.2 测试用例更新流程7.3 测试用例版本管理7.4 测试用例维护记录第8章测试用例管理工具8.1 测试用例管理工具选型8.2 测试用例管理工具使用8.3 测试用例管理工具维护8.4 测试用例管理工具优化第9章自动化测试用例编写9.1 自动化测试用例特点9.2 自动化测试用例编写规范9.3 自动化测试用例编写工具9.4 自动化测试用例编写实践第10章自动化测试用例执行10.1 自动化测试用例执行策略10.2 自动化测试用例执行过程10.3 自动化测试用例执行结果分析10.4 自动化测试用例执行优化第11章移动端测试用例编写与执行11.1 移动端测试用例特点11.2 移动端测试用例编写规范11.3 移动端测试用例执行策略11.4 移动端测试用例执行实践第12章测试用例编写与执行最佳实践12.1 测试用例编写最佳实践12.2 测试用例执行最佳实践12.3 测试用例管理最佳实践12.4 测试团队协作最佳实践第1章测试用例编写概述测试用例是软件测试过程中的核心组成部分，它对于保证软件质量、发觉潜在缺陷具有重要意义。
测试用例编写规范
测试⽤例编写规范1 ⽬的测试⽤例是测试⼈员执⾏测试的基本依据，因此测试⽤例质量的⾼低直接影响测试的有效性和效率。
为了保证测试执⾏⼈员使⽤最有效的测试⽤例，使测试⼯作能有序、合理化的进⾏，从⽽提⾼实施测试时对所测产品、系统或者模块的测试质量，最终提⾼仁科互动公司产品线的质量。
特编写统⼀测试⽤例编写规范，为测试设计⼈员提供测试⽤例设计编写指导，提⾼编写⽤例的可读性、可执⾏性、合理性。
2 ⽤途适⽤于对各业务线测试⼈员对功能测试⽤例和接⼝测试⽤例的编写。
3 ⽤例设计流程测试分析：进⾏测试⽤例编写的前提。
测试⼈员根据产品部门提供的PRD、⽤户故事以及研发部提供的设计⽂档进⾏测试需求分析，找出明显的和隐含的需求。
有些需求⽆法从需求⽂档中获得，可借助概要设计⽂档或者详细设计⽂档，或直接从最终的软件产品上获得。
测试设计：依据测试分析整理并编写出测试⽤例⼤纲，并将测试⼤纲细化为测试⽤例。
测试⽤例⼤纲⽤脑图的形式进⾏管理，在时间受限的情况下，测试⽤例评审对象是脑图，详细测试⽤例会抽取⼀些作为附加评审对象。
参加的⼈员应包括测试负责⼈、项⽬经理、开发⼈员及其他相关的测试⼈员。
测试⽤例完善：测试⽤例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试⽤例必须定期修改更新；在测试过程中发现设计测试⽤例时考虑不周，需要对测试⽤例进⾏修改完善；产品上线后客户反馈的软件缺陷，⽽缺陷⼜是因测试⽤例存在漏洞造成，也需要对测试⽤例进⾏完善。
任何测试⽤例的新增和更新均需要经过评审流程。
4 规范要求4.1 测试⽤例整体要求• 测试⽤例编写应严格根据PRD、⽤户故事及测试需求功能分析点进⾏，要求覆盖全部需求功能点• 测试⽤例编写应该制订统⼀的模板进⾏，并约定模板的使⽤⽅法• 测试⽤例中要写清楚测试的操作步骤和预期结果，能被不同测试⼈员理解和执⾏• 测试⽤例中要明确⼀级模块、⼆级模块和三级功能• 同⼀个功能点的测试⽤例，移动端和PC端需要单独编写，因为它们的界⾯和操作不同• 界⾯显⽰、错误信息提⽰、⽤户界⾯友好性等界⾯相关检查暂不作为测试范围，由UI/UE部门负责验收• 注重测试⽤例的可复⽤性，即在以后相似系统的测试过程中可以重复使⽤• 测试⽤例编写和评审都⽤Excel表格，评审通过后的测试⽤例导⼊testLink系统4.2 测试⽤例组成部分⼀般的测试⽤例包括如下组成部分：需求标识、⽤例标识、⽤例标题、摘要、重要性、前提条件、操作步骤、预期结果、⽤例编写者、状态、预期执⾏耗时、测试⽅式。
测试用例编写规范
测试⽤例编写规范⽬录：⼀.测试⽤例包含的元素⼆.测试⽤例编写原则及规范1. ⽤例模块划分规范2. ⽤例颗粒度划分规范3. ⽤例编写要求规范4. ⽤例维护规范三.测试⽤例编号规则⼀.测试⽤例包含的元素1. 序号：就是按顺序下去的。
2. 模块：该功能点具体属于哪个模块的，如：注册/登录模块3. 编号：对每个⽤例进⾏编号，⽅便后期跟进。
建议编号设计的有点规则，⽅便快速定位查找。
如：A0001。
其中A表⽰注册/登录模块。
00表⽰账号登录，01 表⽰账号密码登录下的第⼀个测试⽤例。
4. 功能点：具体指某个功能，如：账号登录、⾸页、发布等。
5. ⼦功能点：具体指功能点，如：账号密码登录、⼿机验证码登录、邮箱登录、第三⽅授权登录等。
6. ⽤例名称：具体测试⽤例的名称。
如：输⼊账号、输⼊密码、密码不合规等等。
7. 前置条件：指要达到预期测试结果，需要满⾜哪些条件才能达到。
8. 操作步骤：指要达到预期测试结果，需要按这些步骤来。
最好说明在什么页⾯，点击或操作什么内容，输⼊什么内容。
9. 预期结果：说明按照前⾯写的应该呈现出怎样的结果。
10. 测试结果：如果符合预期结果，直接填写正常或OK，如果不符合，则说明不符合或NO，11. 结果描述：如果正常，可以不⽤填写，如果不符合预期结果，则说明哪⾥不符合。
12. 测试⼈员：填写测试⼈的名字，⽅便后期跟踪BUG。
13. 测试⽇期：填写测试的时间，⽅便后期查询。
14. BUGID：跟测试编号⼀样，⾃⼰设定ID规则，⽅便快速查询。
15. BUG负责⼈：此处应该由技术那边填写，具体落实到某个⼈⾝上，才能更好的解决到问题。
⼆.测试⽤例编写原则及规范统⼀测试⽤例编写的规范，为测试设计⼈员提供测试⽤例编写的指导，提⾼编写的测试⽤例的可读性，可执⾏性、合理性。
测试⽤例，不仅仅⽤于QA阅读和执⾏。
它们也可能会被开发、PD、PM等阅读审查或执⾏；也更可能被其他测试⼈员或者新员⼯作为业务学习、测试执⾏的参照。
测试用例编写规范
测试用例编写规范概述测试用例是软件测试过程中的重要组成部分，它描述了预期结果和实际结果之间的差异，并确保软件的正确性和可靠性。
本文档旨在提供一些测试用例编写规范，以确保测试用例的质量和有效性。
编写测试用例的准则以下是编写测试用例的几个准则：清晰明确：每个测试用例应该清晰明确地描述测试的目标和预期结果。
确保测试步骤简洁明了，不含含糊或模棱两可的语句。
全面性：测试用例应该涵盖软件的不同功能和边界情况。
对于每个功能，至少编写一个正向测试用例和一个负向测试用例，以确保软件在不同情况下的正确性。
独立性：每个测试用例应该是相互独立的，不依赖于其他测试用例的执行结果。
这样可以更容易地跟踪和调试失败的用例，并提高测试效率。
可重复性：测试用例应该是可重复执行的，即无论多少次执行，结果都应该保持一致。
确保测试用例不受环境或测试数据的影响。
正确性验证：对于每个测试用例，应确保测试的是正确性。
通过验证测试结果是否符合预期来判断测试用例的正确性。
编写格式下面是测试用例编写的常见格式：测试用例名称：简短而具有描述性的名称测试目的：描述测试的目的和预期结果测试步骤：详细描述测试的步骤和操作预期结果：明确说明测试的预期结果实际结果：记录测试的实际结果测试结果：标记测试是否通过或失败示例测试用例：测试用例名称：用户登录测试目的：验证用户能够成功登录系统测试步骤：1. 打开登录页面2. 输入有效的用户名和密码3. 点击登录按钮预期结果：用户成功登录系统实际结果：用户成功登录系统测试结果：通过测试用例名称：用户登录 - 错误的用户名测试目的：验证用户输入错误的用户名时系统的反应测试步骤：1. 打开登录页面2. 输入错误的用户名和有效的密码3. 点击登录按钮预期结果：系统显示错误消息，提示用户输入正确的用户名实际结果：系统显示错误消息，提示用户输入正确的用户名测试结果：通过总结测试用例编写规范能够提高测试的质量和效率。
编写清晰明确、全面独立、可重复执行、正确性验证的测试用例，并遵循适当的格式可以帮助确保测试的准确性和可靠性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
测试用例编写规范
一．测试用例整体要求
一般的测试用例包括如下几个部分：需求标识、用例编号、用例名称、用例级别、预置条件、操作步骤、预期结果、备注、用例编写者、测试执行者、测试日期。
需求标识：唯一标识，与用例编号对应，为一对多关系。
用例编号：能够准确的标识每一条用例，每一个用例编号在所有测试用例中必须唯一。
用例名称：能够清晰表达测试用例的测试目的和关键测试要素。
用例级别：区分测试用例的重要程度，确定用例执行的级别。
预置条件：需要描述测试所需要处于的外部环境和测试前测试对象及辅助对象所需要处于的状态和配置。
需要保证在完成预置条件中所描述的状态和配置以及外部环境后，测试执行的正确性、一致性。
用例描述（测试步骤）：为了达到测试用例的测试目的，所需要执行的操作；每个操作步骤对应一个预期
结果。
预期结果：针对测试用例的测试目的，测试步骤中操作后对应的预期输出状态。
用例编写者：设计用例的人员。
测试执行者：按照该用例执行测试的人员。
测试日期：执行测试的时间。
二．测试用例实现规则
规则1：用例要素要求
需求标识、用例编号、用例名称、用例级别、预置条件、操作步骤、预期结果、实际结果为必选要素，不能为空，其他字段为可选要素。
规则2：用例名称描述要求
用例名称不允许出现重复、包含关系，或者仅有数字编号差异。
规则3：用例级别分为高、中、低3个级别
高（优先执行）：产品基本的功能验证，不设计配置及场景测试。
即关键路径的测试用例，包括最常执行的功能、基本流程的输入以及界面数据有效性校验作为高级别的测试用例；若该级别的测试用例完全执行通过，则表示该软件功能渐趋稳定。
中（次级执行）：产品功能测试，常见的配置、交互及场景的测试。
即可接收级测试的用例，包括不常执行的功能、异常流程的输入、边界值以及异常数据的输入作为中等级别的测试用例。
低（最后执行）：冷僻的产品功能，非常见的异常场景测试。
即建议执行的测试用例，也就是说该级别的测试用例不是不重要，而是该级别的用例在整个项目的生命周期内不是常常被运行，包括：界面显示、错误信息提示不统一、可用性、压力和性能测试等。
规则4：多条预置条件、测试步骤、预期结果描述要求
1）每一条预置条件、测试步骤、预期结果必须以序号编号。
测试用例编号方式为“AA-aa、”，AA为该用例模块的简写，aa为数字从1开始编号。
2）多条预置条件、测试步骤、预期结果之间必须用回车换行，并且分条写清楚。
规则5：预期结果与测试步骤对应要求
1）每一条预期结果与其对应的测试步骤的编号要求保持一致。
2）每一测试步骤只能对应一条预期结果。
规则6：用例描述中不包含模糊描述
测试用例的用例名称、预置条件、测试步骤、预期结果中均不允许出现模糊的描述，导致引起歧义或无法准确判断测试用例测试结果通过与否。
规格7：“验证结果”描述要求
1）通过（Pass）：测试运行结束，测试人得到了预料中的测试结果状态和测试行为。
2）失败（Fail）：测试的实际结果跟预期的测试结果不一致。
3）阻塞（Block）：一些因素会导致测试不能进行到底，例如某个功能欠缺或者测试环境的某个部分欠缺，需在备注里面写明原因。
三．测试用例设计步骤
测试需求分析：从产品需求文档中，找出待测模块的需求，通过自己的分析、理解，整理成为测试需求，要清楚被测对象具体包含哪些功能点。
测试用例设计：测试用例设计的类型主要包括功能测试、边界测试、异常测试等，在设计用例时要尽量考虑边界、异常等情况。
测试用例评审：由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、开发人员及其他相关的测试人员。
测试用例完善：测试用例必须定期修改更新；在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善；产品上线后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。
1）增添新的测试用例
对新增的功能，在评审过程及测试过程中发现缺少测试用例或者系统出现bug但是没有与之对应的测试用例，需要按照测试用例的标准进行增添。
增加测试用例时，需要在相同的功能模块的最下方插入新增的测试用例，并且在备注栏中加以说明。
2）删除过时的测试用例
因需求改变等一些原因使某些用例不再适用，需进行删除。
应该将删除的测试用例整行置灰，并在备注中说明原因。
当整个功能模块需要删除时，则将整个sheet状态置灰，并在备注中说明原因。
3）修改测试用例
随着项目的进展，测试需求可能有所更改，这时候需要对测试用例进行维护，修改已经不符合目前测试要求的用例，并在备注中说明。
四：记录测试结果
用例执行失败后，所发现的问题需要在teambition缺陷管理系统登记，登记后会得到问题编号（如bug-10），并且将这个编号记入“测试用例”excel表格中。
并且在该条bug里面备注清楚对应的用例编号及名称等信息。
.。