我们为什么要写好一份测试用例呢？测试同学应该都知道测试用例的重要性，测试用例就是我们测试的依据，也是测试过程中不能缺少的测试文档。
一、用例编写规范目的：
1、提高测试用例的可读性，可执行性、合理性。
2、测试用例，会被开发、产品等阅读审查或执行；也更可能被其他测试人员或者新员工作为熟悉当前产品的可靠依据，是可以不看需求不看交互最直接的、最快速的了解产品的文档。
二、设计用例过程：
1、参加需求评审会议：即产品讲解需求，需求中包含需要实现的功能。
a、需求评审前要大致看一遍需求文档，对于有疑惑不明白的语句做好标记；
b、参加需求文档评审会议时，紧跟产品思路，了解需求背景，需求内容等。并且一边听一边在脑海中形成产品形态，发现不合理和有疑问的地方及时提出并督促产品解决；
c、会议当场确定测试范围、确定各需求的测试优先级、确定测试的通过标准。
2、逐字逐句解读需求文档，熟悉业务需求（组织或客户高层次的目标）、功能需求（规定开发人员必须在产品中实现的软件功能）、用户需求（从客户角度出发，用户的目标，或用户要求系统必须能完成的任务）
a、拆分需求点，梳理功能模块：
- 业务功能：与用户实际业务直接相关的功能
- 数据约束：数据的显示范围、数据之间的关系
- 权限约束：不同角色权限对功能的处理
- 编辑约束：对数据输入项的要求限制
- 辅助功能：辅助完成业务功能的一些功能或者是细节
- 易用性需求：易于使用的功能细节
- 性能约束：执行功能时必须满足的性能需求
3、书写测试用例
一、设计原则：
a、测试用例应全部覆盖需求文档里面的各项功能。
b、真实场景的需求及模拟：测试点在编写的过程中，一定要考虑真实使用场景
c、测试用例设计应关注新增需求对原有各项功能的影响
d、测试用例设计应关注关联/复用模块，功能相互影响模块
e、测试用例的设计应包括各种类型的测试用例。在设计测试用例的时候，除了满足系统基本功能需求外，还应该考虑各种异常情况、边界情况和承受压力的能力
f、划分系统/功能模块，按模块分类进行编写
g、测试用例对测试功能点、测试条件、测试步骤、输入值和预期结果应该有准确的定义。在什么页面，点击什么按钮、输入什么数据
二、编写内容
a、用例名称：1）常用的结构“主、谓、宾”；2）名称简洁易懂，不要包括具体操作步骤；
b、前置条件：1）执行用例测试步骤前需要做的所有必备条件，原则上所有用例都有前置条件；2）完整清楚，包括入口、帐号类型、账号权限、数据准备等
c、操作步骤：1）操作步骤描述清晰。如：在什么页面，点击什么链接或按钮；页面入口、链接、按钮名称都要写清楚；2）操作和结果是一一对应的，但操作中不要包含结果的检查；3）用例描述中不允许出现假设性词汇，比如：假如，或许，可能，…的时候等；
d、预期结果：1）原则上每个用例必须要有预期结果，结果不能为空；2）结果中只能包含结果，不能有步骤；3）一个结果有多个检查点时，确保检查点完整；
最后，测试用例的维护也是不可缺少的，我们当前项目结束后要及时归档，上传的svn或者qc，以便后续查看。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取