（1）为用例的质量负责，使用例编写工作能够有序、合理；
（2）统一测试用例编写的规范，为测试设计人员提供测试用例编写的指导，提高编写的测试用例的可读性，可执行性、合理性；
（3）能有效的提高系统所有功能点的覆盖率。
适用于人员：用于测试人员阅读和执行。它们也可能会被开发人员、产品经理、项目经理等阅读审查或执行，也让新员工作为业务学习、测试执行的参照。
适用于公司对项目的业务流程、功能（功能点）测试的测试用例编写。
测试用例（Test Case）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
（1）指导测试工作有序进行，使实施测试的数据有据可依
（2）确保所实现的功能与客户预期的需求相符合
（3）跟踪测试进度，确定测试重点
（4）评估测试结果的度量标准
（5）分析缺陷的标准
用例颗粒度原则：测试用例是执行的最小实体。
用例划分基本原则是以最小功能模块来划分，为保障用例的可执行性、覆盖度，规范编写用例的粒度要求如下：
（1）一个功能正常流程，编写一个测试用例；
（2）一个功能中多个异常流程，应分开编写多个测试用例；
（3）同一功能不同入口，可合并编写一个测试用例；
（4）同一功能不同数据准备，应分开编写多个测试用例；
（5）同一个功能用例的自动化用例和功能用例要匹配，若自动化用例不能完全覆盖功能用例，自动化用例和功能用例拆分两个互补测试用例；
编号 | 用例名称 | 摘要 | 前置条件 | 优先级 | 步骤编号 | 操作步骤 | 预期结果 | 测试结果 | BugID | 测试日期 |
（1）编号：用例编号，唯一标识；
（2）用例名称：测试用例的名称，体现测试要点；常用的结构“主、谓、宾”，名称简洁易懂，不要包括具体操作步骤；
（3）摘要：要测试的功能点（系统、模块功能）；
（4）前置条件：测试执行前需准备的相关操作，如测试数据、角色权限，或登入系统某页面等。
（5）优先级：测试用例的优先级别，分为高、中、低；
（6）步骤编号：操作步骤的编号，用于后期导入相应的测试用例工具。
（7）操作步骤：完成该测试点所需的操作步骤；具体有以下5点要求：
1、操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；
2、操作和结果是一一对应的，但操作中不要包含结果的检查；
3、用例描述中不允许存在连词、介词，比如：而且，和，还（这种情况可以拆分为多个点）；
4、用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
5、用例描述中不允许出现二义性语句；
（8）预期结果：执行完成操作后，程序预期表现的结果；具体有以下3点要求：
1、原则上每个用例必需要有预期结果，结果不能为空；
2、结果中只能包含结果，不能有步骤；
3、一个结果有多个检查点时，确保检查点完整；
（9）测试结果：
与预期结果是否相符，相符实际结果内显示Pass（表明用例通过）
与预期结果不一致显示Failed（表明执行有偏差/错误）
（10）BugID：提交Bug后，redmine中自动生成的ID
（11）测试日期：执行测试用例的日期
将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。从方法论上可以看出来，边界值分析是对等价类划分的补充，所以这两种测试方法经常结合起来使用。
在很大程度上是凭经验进行的，是凭人们对过去所作的测试工作结果的分析，对所揭示的缺陷的规律性作直觉的推测来发现缺陷的。
（1）应尽可能覆盖程序的各种路径。
（2）应考虑存在跨年、跨月的数据。
（3）大量数据并发测试的准备。
（1）输入界面后的数据应与测试文档所记录的数据一致；
（2）预期结果应与测试数据发生的业务吻合。
（1）测试数据应符合用户实际工作业务流程。
（2）兼顾各种业务变化的可能。
（1）对于系统业务流程要能够完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系。
（2）对于模块业务流程要能够说明清楚子系统内部功能、重要功能点以及它们之间的关系。
（1）对于系统业务流程来说，各个子系统之间是如何连接在一起，如果需要接口，各个子系统之间是否有正确的接口；如果是依靠页面链接，页面链接是否正确。
（2）对于模块业务流程来说，同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯。
人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例。
测试用例中应写清测试的操作步骤，不同的操作步骤相对应的操作结果。
从项目需求分析文档/概要设计/详细设计/原型图中，了解出项目的需求。通过测试人员自己的分析、 理解，整理成为测试需求，使测试人员能清楚被测项目包含的功能点。
分析了解被测试项目所属的行业及其业务知识。对被测项目的业务流程要全部梳理出来（可画出项目的流程图，也可用头脑风暴）。
项目的流程：主线流程、分支流程、数据流转，流转过程中关键点的判断条件以及完成操作的一些非必要条件。
主要包括功能测试、界面测试、兼容性测试、易用性测试、异常测试、性能测试、压力测试等，在设计用例时要尽量考虑录入正常、边界、异常值等系统的处理情况。
由测试用例设计者发起，参加的人员需包括测试负责人、项目经理、 开发人员及其他相关的测试人员。
测试用例编写完成后，应对测试用例进行持续的维护：
（1）新项目需求变更，应及时对测试用例进行修改；
（2）维护期项目，可根据项目组情况周期对用例进行维护；
（3）所有发现的bug和故障，基于测试用例无法发现，需转化为测试用例。
更多精彩都在洋哥视频课程学习地址：http://edu.51cto.com/lecturer/5811414.html
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
