为什么编写测试用例

我也不知道，自己百度

详细测试用例模板

测试用例字段介绍

用例目录： 用例归属哪个系统模块，用例平台可根据用例目录建立文件夹，清晰划分用例结构.
用例名称： 测试用例名称，体现测试要点，名称简洁易懂，不要包括具体操作步骤，不超过20个字符. 通过用例名称可快速知道测试验证功能点.
前置条件： 测试执行前需准备的相关操作，如测试数据、角色权限，或登入系统某页面等.
优先级： 测试用例的优先级别，分别为P0(核心用例)，P1（主功能正向流程），P2（功能点常规用例），P3（界面UI文案体验）
用例执行阶段： 用例编写时需注明此条用例适用于测试哪个阶段执行，测试阶段分为冒烟，迭代测试，回归，PL回归，生产回归. 需用例也可区分各个阶段, 估增加此类字段方便筛选，添加到不同的测试计划中.
冒烟阶段，执行冒烟用例，方便分析冒烟用例执行阶段产出缺陷.
迭代测试，执行迭代测试用例，迭代测试用例包含新功能用例与功能改动影响模块的回归用例
回归阶段，执行回归用例，回归用例针对版本质量，确保版本核心功能与老版本兼容质量.
PL阶段，挑选可执行的迭代测试用例+回归用例
生产阶段，挑选可执行的迭代测试用例+回归用例.
回归用例数量与用例等级关联，目的依次降低回归用例数量，减少无效覆盖，提高测试效率. 目前各测试执行人员判断，后期根据部门的代码染色覆盖率平台，流量回放平台，自动化平台，接口链路分析等达到精准回归.
P0：系统核心功能用例. 占全量的10%左右, 适用于生产回归执行
P１：系统正向流程功能点用例,使用频繁,占全量的20%左右, 适用于回归执行
P２：系统一般功能,使用频次低于P1,占全量60%左右, 适用与常规迭代及部分技改回归，也包含异常流程测试，如故障演练,多场景耦合并发等测试系统健壮性.
P３：文案UI类，占全量的10%左右,按需执行.
自动化覆盖： 分析自动化覆盖率，分为已覆盖，未覆盖，以及纯手动执行部分，方便统计自动化覆盖率，及制定未覆盖自动化部分完成计划.
自动化脚本类型：用例要区分类型，分为手动，自动化冒烟，自动化回归，自动化全链路（业务场景自动化）,自动化平台根据此类型建立不同的测试计划，达到环境快速检测，回归定期执行，生产快速回归,CI/CD持续集成.
标准用例： 是/否，增加此字段，可衡量标准用例产出及标准用例占比. 方便组长快速抽查标准用例质量.
创建人： 用例创建人，使用邮箱名，如suozhu.wang, 自动化平台根据此字段来确认用例编写人员，非根据导入用例人员判断.

用例操作步骤

强调清晰完整性：如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
操作和预期结果是一一对应的，但操作中不要包含结果的检查；
用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
用例描述中不允许出现二义性语句；

用例预期结果：

结果包含需要验证的所有结果输出，如页面检查，存储检查，消息检查等
结果涉及页面，需明确页面提示结果，数据变化
结果涉及存储，需明确关键值变化，数据库具体表和关键字字段变化；
结果涉及消息，需明确关键消息查看内容.
结果对应不同输入数据数据有差别时需分别对应描述清楚.

测试用例录入原则：

全面性
应尽可能覆盖程序的各种路径
应考虑存在跨年、跨月的等业务边界，可梳理研发边界实现场景在哪些业务功能上.
大量数据并发测试的准备
正确性
输入界面后的数据应与测试文档所记录的数据一致；
预期结果应与测试数据发生的业务吻合。
符合正常业务惯例
测试数据应符合用户实际工作业务流程。
兼顾各种业务变化的可能。
系统性
对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系。
对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系。
连贯性
对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确。
对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。
仿真性
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。
可操作性
测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。

测试用例设计步骤

测试需求分析
从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求。通过测试人员自己的分析、 理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。
业务流程分析
分析了解被测试项目所属的行业及其业务知识。对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）。
项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件。
测试用例设计
主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况。
测试用例评审
由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员及其他相关的测试人员，研发产品根据用例质量评估可判定通过或不通过. 衡量用例质量
测试用例完善
测试用例编写完成后，应对测试用例进行持续的维护：
新项目需求变更，应及时对测试用例进行修改；
维护期项目，可根据项目组情况周期对用例进行维护；
所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例，根据用例探测率衡量用例质量

测试用例案例：

测试用例校验点：

1、输入-》输出呈现效果，初步判断需求功能是否正常

2、用例操作所触发的服务接口，redis/数据库更新，服务之间消息传递（mq）等检查，判断研发逻辑是否正常

3、异常用例操作需查看服务日志是否有报错，判断系统健壮性.