测试工程师要遵守的用例编写规范
在软件开发的快速迭代和不断更新的背景下，测试用例规范的重要性愈发凸显。它不仅帮助测试人员明确测试的目标和方法，还确保测试过程的一致性和可重复性。通过遵循统一的规范，我们可以减少人为错误，提高测试覆盖率，从而确保软件的质量。
01什么是测试用例
测试用例是测试过程中操作行为的方法指引，用例让整个测试过程有章可循，高效快捷，不至于有所疏漏;
用例设计的准确性、合理性、覆盖率直接体现测试的效率与质量;
一份合格的测试用例一定要具备逻辑清晰，尽可能覆盖所有功能点，执行快捷的特性等;
测试用例设计是整个测试工作的核心，也是一个优秀测试人员的基本功，注意我这里用的是“设计”而不是简单的“编写”，一份合格的测试用例一定是设计出来的，它需要从各个角度去思考以覆盖到所有可能的测试点，最终尽可能达到系统没有任何缺陷的完美程度。
02用例设计流程
1)测试分析：进行测试用例编写的前提。测试人员根据产品部门提供的PRD、用户故事以及研发部提供的设计文档进行测试需求分析，找出明显的和隐含的需求。有些需求无法从需求文档中获得，可借助概要设计文档或者详细设计文档，或直接从最终的软件产品上获得。
2)测试设计：依据测试分析整理并编写出测试用例大纲，并将测试大纲细化为测试用例。测试用例大纲用脑图的形式进行管理，在时间受限的情况下，测试用例评审对象是脑图，详细测试用例会抽取一些作为附加评审对象。参加的人员应包括测试负责人、项目经理、开发人员及其他相关的测试人员。
3)测试用例完善：测试用例编写完成之后需不断完善，软件产品新增功能或更新需求后，测试用例必须定期修改更新;在测试过程中发现设计测试用例时考虑不周，需要对测试用例进行修改完善;产品上线后客户反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成，也需要对测试用例进行完善。任何测试用例的新增和更新均需要经过评审流程。
03用例编写规范
3.1 用例编写原则
3.1.1 覆盖所有需求和业务场景
需覆盖软件需求规格说明、核心业务流程
需覆盖正向场景、异常场景
需覆盖核心数据和业务规则的有效&无效等价类、边界条件的校验
3.1.2 可维护性
须使测试用例的分解符合高内聚和低耦合的特征，如按模块划分、按功能和业务流程划分
须使测试用例每个步骤的结构和描述合理，简洁、清晰。
3.2 测试用例的必要元素
3.2.1 用例编号
可以根据软件名称、模块名称和数字组合定义，如CMS系统的登录模块用例，编号可以设置成cms_login_001;
3.2.2 用例优先级
每个测试用例须根据测试设计和执行的进度和质量要求的重要和紧急程度进行设置，在项目执行过程中用例优先级不是一成不变的。
P1(占比：10%~20%)：冒烟用例、主流程用例、用户最常用功能或者影响用户体验的性能、质量特性等
P2(占比：60%~70%)：正常场景用例，从测试效率角度，边界区域更容易发现缺陷，测试边界区域的用例优先级相对较高;从修改成本考虑，逻辑方面的缺陷修复比简单功能缺陷修复成本高，逻辑方面的测试用例优先级要相对较高
P3(5%~10%)：异常场景用例，发布前如果时间限制，不需要回归，不会产生重大不良影响的用例
P4(占比：<5%)：极度异常场景用例，生僻场景，使用频率比较低
3.2.3 前提条件
用例执行的前置条件，如测试角色权限，修改代码或程序配置等要求。
3.2.4测试数据
执行用例前需要准备的测试数据
3.2.5 操作步骤
每一个测试用例步骤的输入描述必须是一个，或一组明确的、无需进一步说明的测试操作行为
每一个测试用例步骤的期望结果是由此步骤的一个，或一组输入操作产生的，并且必须具有唯一性
每一个测试用例步骤的输入数据必须在执行测试前完成设计，并且必须满足真实的业务数据要求
3.2.6 预期结果
每一个测试用例步骤都有明确的期望结果，用例编写时预期结果不应出现详见需求、页面展示正确之类的笼统描述。
预期结果规则：
一个操作步骤对应一个预期结果
预期结果根据软件需求以及最终实现效果输出
预期结果描述要清晰、明确，没有含糊的概念和一般性的描述，如：大概、可能、应该等。
预期结果应详细具体，尽量做到不同的人看这个结果理解一致
相同测试预期结果可以不同重复写，如不同界面插入U盘,提示语验证;建立通话，通话UI描述。
预期结果中提示语、标题、softkey、翻译等大小写、是否有空格、特殊字符符号等都要描述准确
04用例等级定义
BVT：
1.该类用例涉及系统基本功能，用例数量应受到控制，占10-15%的比例。
2.划分依据：该用例执行的失败会导致多处重要功能无法运行，可以认为是发生概率较高而且经常使用的一些功能用例。
3.该级别的测试用例在每一轮版本测试中都必须执行。
高：
1.该类用例涉及系统的重要功能，用例数量较多，占20-30%的比例。
2.划分依据：主要包括一些功能交互相关、各种主要应用场景、使用频率较高的正常功能测试用例。
3.在系统测试版本中基本都需要进行验证，以保证系统所有的重要功能都能够正常实现。
中：
1.该类用例涉及系统的一般功能，用例数量较多，占40-60%的比例。
2.划分依据：使用频率低于高级别的用例。例如：数值或数据的边界情况、特殊字符、字符串超长等。
低：
1.如果没有可以不适用该级别
2.该级别用例一般非常少，占10-15%的比例。
3.划分依据：该类用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的触发条件非常特殊，仍然应该被置入低级别用例中。如界面规范化的测试也可归入低级用例。在实际使用中使用频率非常低、对用户可有可无的功能。
4.在系统测试中有某些正常原因(包括：环境、人力、时间等)经过项目经理同意可以不进行测试。
3.在系统测试的中后期并不一定需要每个版本都进行测试。
05用例编写方法
1）基于需求列测试大纲
熟悉需求是编写测试用例的前提条件，测试人员可以通过参与需求宣讲、阅读需求文档熟悉软件需求。在熟悉需求的过程中，使用思维导图梳理测试大纲，比较清晰、直观地罗列清楚要测试的需求点。
2）使用模板用例编写
可以根据用例模板进行用例编写，也可以用xmind按照用例模板格式定义好层级，进行用例编写，比较直观，且完成后导出excel。
3）用例评审
--组织方式：用例编写完成后测试人员可以发起用例评审，如组织会议评审、邮件评审;测试用例评审的参与人员是：开发、产品、测试人员;
--评审目的：
完善测试的覆盖率，产品参与核对用例是否覆盖软件需求;
开发人员从代码角度给出建议，保证测试的全面性，防止漏测、过渡测试、无效测试等;
确保各角色对需求理解的一致性
4）选择有效的测试用例
4.1冒烟测试用例
用例评审通过后，可以抽取P1级别的功能用例做为冒烟测试用例，冒烟用例是版本转测前由研发同学冒烟自测的执行依据。
4.2有效的回归用例
1.用例按需求模块或业务流程或组件划分清楚，划分方式和研发对齐
根据研发修改的范围，评估影响范围，抽取要回归的用例，做到测试执行的有效性
没有修改的模块或流程，执行优先级降低，时间来不及可以不覆盖(前提是和研发沟通好上线范围和影响)
2.根据测试情况、需求变更情况，及时更新、调整测试用例
已知需求变更，用例对应修改
测试过长中拨测场景发现严重问题，要丰富对应场景的测试用例
用例的优先级，根据不同版本的修改范围和影响，应灵活调整
06用例维护
1）新增测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明
2）修改测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明
3）删除冗余的测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个增添新的测试用例
4）归档过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的归档。当前测试用例状态会被更改为Obsolete并且移动到归档测试用例目录下。