影响测试效率的因素:
* 没有正式需求的测试用例:找产品确认。
* 用例编写进度跟不上项目进度:优先处理优先级高的用例
* 用例的评审只是走形式:参照标准一条条过
* 需求变更后未及时通知测试人员 :定期主动找产品,自己多问
* 测试人员后期加入项目,对需求了解不透彻:测试人员需要画测试组织架构图,明确整个测试团队现有的项目以及相应的负责人
* 执行用例结果模糊:结果实事求是(通过或者未通过)(明明测试出来了问题,却听开发说线上不会有这样的问题,用户不会有这样的问题, 实际情况不会出现这样的问题...这样的测试结果写未通过,最终统计下这些有多少,放到测试报告最后的风险预测里面)
* 执行用例不彻底:每条用例执行后签字确认,记录测试时间
用例评审标准:
1. 完整性:考虑尽可能多的对象以及对应状态,比如注册模块:
对像有:用户类型,手机号,验证码,界面倒计时控件;
状态有:用户类型状态(选择过/未选择)手机号状态(是/否被注册;是/否被封号,是/否被警告),验证码状态(已发送/未发送/发送次数超限制),计时器状态(计时中/计时结束)
2. 准确性:每一条测试用例都可以找到产品需求文档,编写用例的时候,附带产品需求文档或者截图
3. 可读性:描述清晰无歧义:谁在**预置条件下**对A进行**操作,然后**会得到**结果,who/ when /where /what/ result简单的就是一个新来的测试能毫无歧义的理解谁在什么条件下,进行什么操作,得到什么结果(结果会影响谁的什么东西,是怎么样的影响)
4. 精简,不冗余
和维护开发代码一样,维护的工作就是去除冗余,测试人员在平时维护用例其实就是去冗余提升可复用
5. 可复用
有些流程中特有的功能性测试可以单独成单元用例,单元用例具有可复用性,在不同的流程中只写一份即可.
比如:用户未登录预置条件下,程序中点击(1,2,3,4,5,6,7,8,9,10....100)按钮的地方都需要跳转到登录页面,登录之后,回来的还是之前的页面
示例:用户未登录点击相关按钮(*****)跳转到登录页面,登录成功或者失败回到之前页面(这样写以后新加需求的时候,再增加按钮也只需要改动括号里面文字即可)
网友评论