l        用例的补充。
1.        测试执行阶段产生新的测试思路或者发现的BUG，没有用例覆盖到的，在项目发布后一周内，把用例全部补充上。让每一个BUG都有对应的用例覆盖。由产品线负责人监督

l        公共用例库。
2.       公共用例库的目录结构规划要合理，方便后面的项目更新进来，这个最好由产品线负责人先统一规划好。
3.       项目发布后一周内，把用例更新到公共用例库，由产品线负责人监督
4.       小需求发布后半个月内，更新到公共用例库（考虑到小需求变术太多），由产品线负责人监督。
5.        更新公共用例库时，如果需要覆盖以前的内容，请先把以前的内容做好备份。
6.        不要因为更新时从无下手，而不去更新，这样公共用例库永远也得不到积累利用，更新总比不更新好，你可以和产品线负责人一起讨论一下，怎么更好地更新进去。
7.      学会使用公共用例库，接到一个写用例的任务，不要从头到尾都自己来写，可以从公共用例库里去找用例来参考，特别是一些公共的功能点。
8.       更新用例库时，需要有一个日志记录在每个大模块的分析里，以下格式可以参考。（后续可能会采用QC的版本管理功能来代替手工日志，待评估）
     最新修改：
    修改01_XXX模块
    增加02_XXX模块
    删除03_XXX模块
   来源：
   XXX项目或者XXX小需求
   修改人/时间：
   XXX/xx年xx月xx日

l        模板用例：
9.       什么是模板用例：最小颗粒度的，完整的功能点，可被用例反复调用的，可提取出来写成模板用例。
10.    什么类型的用例可以写成模板用例：页面检查，入口检查，字段校验，字段查询检查，共用的功能点，数据库检查等
11.    模板用例也是需要有测试分析的，主要讲这个模板用例的检查点，如果这个模板用例会被参数化的，那把参数化的几个情况在分析里罗列一下，到被调用的测试用例里，那些共性的检查点就不用被重复再写了。
12.    我们要求模板用例颗粒度要细，但是也是一个完整的功能点，不需要把功能点里的每一步都拆成一个模块用例
13.    不要在调用模板用例那个步骤里写expected result， 这样执行用例时是看不到的。
14.    模板用例要写在模板用例的文件夹里，不要和执行用例混在一起。
15.    不要出现模板再调用模板的情况，结构太复杂，不便于理解。
16.    同一个项目内的模板用例，可以被本项目的测试用例不断调用
17.    想使用其它项目里的模板用例，请尽量把该模板用例拷贝到本项目里来使用；

l        测试实验室：
18.    用例划分原则基本是以功能模块来划分，但是测试实验室可以从用例执行方便性的角度或者按业务流程的顺序来调整用例的先后顺序,也可以把数据准备可以一起做的用例放在一个测试集里。

l        数据准备
19.    用例里的数据准备不能只写数据字段值，也要写出业务流程上处于什么条件
20.    数据准备里除了要写满足XX条件，也要写同时要不满足XX条件，否则造出来的数据有可能不精确：
21.    为验证某一功能点，需要准备一批数据，有同学会只写数据，而不写为什么要选择这批数据，选择的原因也是要加上的。
22.    对于复杂的数据准备，最好把SQL或存储过程也写上，这样方便重复使用

l        数据库相关：
23.    对于数据值的检查不止是页面显示和数据库是否一致，还包括数据库的值是否计算正确。
24.    所有引起数据新增，修改，删除的功能点，需要检查到数据库

l        页面检查相关：
25.    页面检查时，每一个元素的不同情况按等价类划分法都要有用例覆盖到。
26.    页面检查时经常会写见DEMO，请把DEMO作为步骤附件附上。在用例执行时，可以看到。

l        功能检查相关：
27.    功能用例尽量从操作成功，操作失败两方面去考虑。再对成功及
28.    对于接口类的用例，数据的传入传出是否一致，是否正确，每一个字段数据最长，最短，各种类型，数据处理的规则都要检查到。
29.    用例划分原则基本是以功能模块来划分，但是对于整个业务流程，一定要有一个完整的用例来支持。

l        增加用例的覆盖率：
30.    对于一个功能模块里的一个小功能点做了修改，或者在一个功能模块里增加了一个小功能点,需要确认下回归范围，而不是只是测试这个小功能点就行了。
31.    对于一个功能有很多的入口，需要在用例里覆盖这些入口的。
32.    对于一个功能有很多适用，不适用的角色，需要在用例里覆盖这些角色的
33.    当一个功能有分角色时，要考虑一个用户有多个角色的情况。
34.    表单的默认值的检查，不要漏掉。
35.    需要检查与需求上的功能点相对立的情况，如：付费会员拥有功能A，也要检查免费会员不拥有功能A。
36.    对于一系列的系统任务,除了单个任务检查,还需要按照线上的执行顺序,来做检查
37.    用例需要覆盖输入正确数据并且产生正确（预期）的输出， 也要覆盖输入非法数据（非法类型、不符合要求的数据、溢出数据等），能否给出提示，并进行相应处理。
38.    对于有权限限止的功能，需要测试系统对权限的控制是否起作用了。

l        增加用例的可读性：
39.    一级一级自上而下的分析文件夹，经常会出现内容重复的现象，请尽量避免重复，否则会给以后带来很大的维护工作量。上一级文件夹的分析，主要是写为何要划分下级文件夹的思路，以及下级文件夹的共同检查点。
40.    前台页面有出错文案,一定要把具体的文案内容体现在用例里,这也是检查点；后台页面有出错文案的，因为是面向内部用户的，只要文案正确无歧义即可，除非需求中特别要求。
41.    用例的操作步骤和期望结果要区分清楚。不能在步骤里写期望结果，不能在期望结果里写步骤，但是一个步骤引起多个期望结果，那多个期望结果可以写在一起，多个步骤引起一个期望结果，那多个步骤也是可以写在一起的。
42.    用例里的检查方式需要具体可操作的
43.    很多人认为用例的测试步骤里写得很详细了，不需要在用例的测试分析里再写东西，但是这两者是有区别的，用例的测试分析是体现你的检查点，而步骤是要涉及到更具体的操作步骤的。
44.    用例步骤的整个流程需要完整，可执行的，比如：build操作，后台审核，都要写到步骤里去
45.    用例的颗粒度要细,不要在一条用例里混合多个功能点，也不要混合一个功能点里的多种情况，比如增加记录这种功能点通常会分成很多种情况，每一种情况就是一条用例，而不是把每种情况混在一条用例里。
46.    异常检查，如网络传输异常，接口调用失效，需要在用例里写出怎样才能达到这种异常情况，这个需要在写用例时，就和开发需分达成共识。
47.    用例划分的目录结构要清晰，取的名称要能概括该目录或用例，常用的结构是：角色+动作+可以区分用例的标识，如果其中某个元素不存在或者重复了，可以去掉。
48.    测试分析，测试步骤的每一字每一句都是要经过反复推敲，要精准无歧义的，以下字眼不要出现在用例里：
       正确的数据；错误的数据；如果；或者；系统不处理；按规则匹配；"最多XX个，不足XX个有多少显示多少"

l        其它注意事项：
49.    测试分析请按照统一的模板格式写，美观统一，无形中为用例加了分。
50.    当两个人共同写一个项目的用例，并且分配的模块是有交互的时，要先做好充分沟通，公共的内容谁来写，每个人写的范围确定好，再下手。
51.    不会在用例里出现待确认的问题，碰到这样的问题就先和需分开发沟通好，不要等到TC评审时再去确认。
52.    有一些点不在测试范围内，有一些点无法测试，这个在测试分析里也要写明，着重告诉相关人员，这些点我们不会测试。
53.    对于调用已有框架的功能点，如后台页面的翻页，至顶至底等功能，可以不作为测试重点，前提是要相关人员确认好是不是调用已有框架的，当然，用例也是要覆盖到的