测试工程师要遵守的用例编写规范

在软件开发的快速迭代和不断更新的背景下测试用例规范的重要性愈发凸显。它不仅帮助测试人员明确测试的目标和方法还确保测试过程的一致性和可重复性。通过遵循统一的规范我们可以减少人为错误提高测试覆盖率从而确保软件的质量。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用例等级定义BVT1.该类用例涉及系统基本功能用例数量应受到控制占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并且移动到归档测试用例目录下。