测试用例设计原则可以划分为：基于需求、场景化、描述精准、可判定、原子化、可回归、独立、正交。

1. 基于需求

测试用例是为了验证需求而设计的，应避免过度设计。

• 从需求出发，设计能有效验证需求的测试用例

• 明确不在需求范围内的功能，不设计测试用例

• 在需求范围内的功能，不过度设计

• 一些没有明确提出、但属于共识或隐含的需求，应设计测试用例

举例：全黑盒的方式来编写用例，仅看页面是否展示数据并未深究数据是否取值正确；以需求文档来编写测试用例，照搬照抄需求文档的编写，完全不考虑系统的设计和实现逻辑，会导致对系统交互、异常和分支的考虑不足。如需要涉及到筛选条件的话，默认值/是否具备二次记住逻辑/切换时筛选条件是否保存/进入到内部页面再次返回筛选条件不清空

2. 场景化

测试用例设计尽可能贴近真实用户的使用场景。

• 应全覆盖真实用户的使用场景

• 围绕场景进行更多的探索

• 以第一人称的主观视角描述用例，从客户使用的角度构建思维导图

• 按照用户使用的自然顺序设计用例

举例：用例设计过程是对自己思路的整理，完成后需是条理清晰的，系统性的，如在编写页面列表相关的测试用例时，列表的操作按钮具备哪些功能是需要跟随在其后编写的；用例的组织与表述，不仅要自己能懂，也要保证其它人易于阅读理解，如不能只写同线上，若未改动内容则简要的写出其原有的功能，若有改动的话需要描述影响到的范围。

3. 描述精准

描述测试用例的语言要尽量精准，避免歧义，保证不同的人对用例都有一致的理解。

• 语言准确，没有歧义，尽量具体不空泛

• 描述精练，保留必要信息，去掉无关信息

• 避免大段描述，对大量信息进行分层和结构化设计

• 描述角度关注给用户带来的价值，而非详细的操作步骤

举例：描述不要仅粘贴需求文档中所描述的一句话，其实一句话中有很多要素要进行验证，如点击取消按钮后的结果是什么，会影响到什么，是页面的展示还是底层的数据要物理删除？

4. 原子化

每个测试用例应有单独的测试点，确保一个用例只测一点。

• 每个测试用例，只针对一个验证点进行设计

• 如发现验证点多于一个，可拆分

• 用例的颗粒度要适宜

举例：界面比较复杂，元素很多，为了满足原子化，是不是每个点都得写一个测试用例？

不必，可以思考测试点是什么，并不是UI元素里的每一个点，而是UI的实现满足UI设计，从这个角度看，整体算是一个测试点。在描述时也不用啰嗦很多，直接贴个图就很直观，执行测试用例时直接观察图片对比缺少的细节即可。

5. 可判定

应给出可判定的期望执行结果，在没有缺陷的情况下，多次执行应保持结果一致性。

• 判定准则应明确可判，避免模糊或笼统的描述

• 除非业务规则变化，否则判定准则应不变

• 同一条件下，多次执行结果判定应一致

举例：编写思维导图时，与前方写的操作步骤区别开来，可标注成“结果：XXXX”，方便自己与他人执行用例时更好的得知进行了该操作应该得出何种的结果。

6. 可回归

测试用例的存在就是为了验证和回归，因此可回归是用例的必要条件。

• 同一条件下，不同人回归的结果应一致

• 在不同时间内，回归结果应一致

• 使用满足条件的任何数据，回归结果应一致

举例：编写的用例在灰度环境进行交互回归时要实时更新保证用例基于需求文档是最新的，保证他人回归时执行用例时不提出已改动的需求点，以及保证用例在此处的功能未进行迭代更换时是可以复用于其他项目中进行二次使用。

7. 独立

测试用例彼此之间应尽量保持独立。

举例：测试用例都必须独立运行，不能依靠其他测试用例，或者不能按照什么顺序运行才可以，即对于测试需求R1和R2，测试用例集分别为cl和c2，c1和c2的交集为空，并且每个可复用测试用例能够独立运行。

8. 正交

测试用例的设计应尽量全面，无重复，确保测试设计有效且低成本。

• 多个用例之间应彼此正交

• 不重复验证同一个测试点

一、常见的web界面测试点考虑
1、填写区域是否为空的检查
	a、只填写一处   b、填写部分、空白部分  c、填写剩一处  d、填写所有
2、针对单个填写框
	a、考虑长度（最长、最短）
	b、考虑字符（数字、字母、特殊字符、组合） 举例：特殊字符 <> 在绩效模块中展示成&lt &gt
	c、考虑全角半角字符
3、考虑不同功能模块的入口，可以从菜单选择进入，也可从导航栏进入，不同入口的要验证
4、页面数据的展示
	a、数据显示宽度的自适应或自动换行
	b、有数据展现的界面（如统计、查询、编辑录入，打印等）测试数据的记录数超过一屏/一页，验证满屏/页
时其窗体是否有横向、纵向滚动条或换页打印
5、页面内容的准确性
	a、对于无意义的字段值，不应该显示空，应显示“-”或“/”代表该字段值无意义
6、页面对客户的友好性（绩效模块学习到的）
	a、对于统计的数据应按用户习惯进行分类、排序
  b、某些重要信息在输入、修改、删除时应有“确认”提示信息
  c、界面内容更新后系统应提供刷新功能
  d、用户在退出系统后重新登陆时应考虑是否需要自动返回到上次退出系统时的界面
7、界面提示信息的指引性
	a、在多个业务功能组成的一个业务流程中，如果各个功能之间的执行顺序有一定的制约时间，应通过界面
  提示用户，如招聘定社保需求
  b、在界面存在正在进行关键业务的处理，应加上loading加载进行提醒，在处理结束后再提醒用户处理完毕
  如：上传文件、数据量过多
  c、在某些数据输入界面，如果要求输入的数据符合某项规则，应在输入界面提供相应的规则描述；当输入
  数据不符合规则时应提示用户是否继续
  如：输入框的沉底文字、不符合规则的输入框下标红或toast提示
  d、在对信息修改后，在用户退出界面时提示用户保存（如果用户没有主动保存）
 8、界面显示内容的合理性
 	a、界面按钮先后使用的顺序问题，如查询成功后显示执行按钮
  b、窗口与窗口之间、字段与字段之间的浏览顺序是否正确
 9、界面处理的正确性
 	a、验证各种对象访问方法（Tab键、鼠标移动和快捷键）是否正常使用与何时禁用
  如：招聘的门户搜索字段时搜索敲回车后整个页面被重新加载，原因前端没有禁用快捷键
  b、键盘输入评论内容，考虑拷贝粘贴输入
  如：评论区的光标提示、粘贴内容的光标位置
  c、统计查询功能的查询结果应验证其是否只能通过界面上的查询或刷新按键人工触发
10、界面数据显示的规范性
	a、数据精度显示的统一性
  b、时间及日期显示格式的统一，如2022年01-07还是2022年01~07
  

二、存在关联关系的测试点考虑
1、当前业务正常走通，其他相关模块是否能正常显示对应数据
2、当前业务执行过程出现异常情况，对自身及其子模块数据的影响是否正常
3、几个模块共同作用，发生数据变更，查看彼此间的影响是否正常，数据处理是否正确