测试用例-评审标准

* 没有正式需求的测试用例：找产品确认。

* 用例编写进度跟不上项目进度：优先处理优先级高的用例

* 用例的评审只是走形式：参照标准一条条过

* 需求变更后未及时通知测试人员：定期主动找产品，自己多问

* 测试人员后期加入项目，对需求了解不透彻：测试人员需要画测试组织架构图，明确整个测试团队现有的项目以及相应的负责人

* 执行用例结果模糊：结果实事求是（通过或者未通过）（明明测试出来了问题，却听开发说线上不会有这样的问题，用户不会有这样的问题，实际情况不会出现这样的问题...这样的测试结果写未通过，最终统计下这些有多少，放到测试报告最后的风险预测里面）

* 执行用例不彻底：每条用例执行后签字确认，记录测试时间

1. 完整性：考虑尽可能多的对象以及对应状态，比如注册模块：

对像有：用户类型，手机号，验证码，界面倒计时控件;

状态有：用户类型状态（选择过/未选择）手机号状态(是/否被注册；是/否被封号，是/否被警告)，验证码状态（已发送/未发送/发送次数超限制），计时器状态（计时中/计时结束）

2. 准确性：每一条测试用例都可以找到产品需求文档，编写用例的时候，附带产品需求文档或者截图

3. 可读性：描述清晰无歧义:谁在**预置条件下**对A进行**操作,然后**会得到**结果,who/ when /where /what/ result简单的就是一个新来的测试能毫无歧义的理解谁在什么条件下,进行什么操作,得到什么结果(结果会影响谁的什么东西,是怎么样的影响)

4. 精简,不冗余

和维护开发代码一样,维护的工作就是去除冗余,测试人员在平时维护用例其实就是去冗余提升可复用

5. 可复用

有些流程中特有的功能性测试可以单独成单元用例,单元用例具有可复用性,在不同的流程中只写一份即可.

比如:用户未登录预置条件下,程序中点击(1,2,3,4,5,6,7,8,9,10....100)按钮的地方都需要跳转到登录页面,登录之后,回来的还是之前的页面

示例:用户未登录点击相关按钮（*****）跳转到登录页面，登录成功或者失败回到之前页面（这样写以后新加需求的时候，再增加按钮也只需要改动括号里面文字即可）