大家论坛

 找回密码
 注册
查看: 987|回复: 2

[原创] 功能测试用例评审

[复制链接]
发表于 2017-2-14 15:50 | 显示全部楼层 |阅读模式



用例评审主要是QA、产品人员、开发人员和测试人员针对测试用例能否用于项目的测试而做的,我在TestBird从事了多年的项目测试,APP测试中,测试用例是给测试人员执行用的,所以要求尽量的详细而不冗余,精湛而不纰漏,至于一些覆盖率的问题还是测试内部评审时要考虑的问题,与项目的用例评审没有关系。

用例评审目的:

为了减少测试人员执行阶段做无效工作;(执行无效case,提交无效问题)

为了避免三方需求理解不一致;      

为了每个测试人员的质量标准与项目要求标准达成一致;

用例评审的四个环节:

需求评审、需求实现流程图评审、测试大纲评审、测试用例检查

  • 需求评审:
           A 检查讲解的内容无丢失
           B 检查需求理解无偏差
           C 检查需求讲解思路清晰
           D 检查需求讨论会议提出需求建议、需求讨论的问题都有体现,并且记录的详细
           E 检查需求讲解时存在问题的记录,跟进结论


  • 需求实现流程图评审:
           A 检查需求以及实现逻辑内容正确
           B 检查需求以及实现逻辑内容齐全,补充流程缺失部分
           C 检查实现逻辑的深度与仔细程度
    例如:软件升级实现逻辑--什么时候获取服务器版本信息?版本信息有什么?版本信息获取失败的处理?获取的版本信息版本比对策略是什么?比对后的下载逻辑策略是什么?下载的文件保存在哪里?下载过程的失败处理?下载成功后的安装策略是什么?安装失败的处理逻辑是什么?安装成功后的数据加载时机以及加载哪些数据?等等


  • 测试大纲评审:
           A 检查用例大纲结构、思路清晰
           B 检查用例大纲内容齐全--对象齐全\影响因素齐全:
                  1.需求逻辑功能
                  2.UI(静态+动态)
                  3.用户行为(用户常用场景, 常用数据)
                  4.黑盒用例设计方法
                  5.平台系统的特点(windows,ios,android,web)
                  6.开发语言特点
                  7.发现过的历史bug
                  8.自身的版本兼容性
                  9.功能之间相互影响
                  10.开发实现逻辑和建议
           C 检查用例大纲语言描述清晰
           D 检查用例去除冗余用例
           E 检查用例进行集成,为测试执行的高效做准备
    (由于我们是面向对象的用例设计思想,会把流程拆分成几段,所以在执行的时候不够流畅,因此需要将case整合集成)


  • 测试用例检查:
    (站在正规化测试用例的角度进行用例的审核)
           A 检查大纲和用例内容一一对应,影响因素无丢失
           B 检查语言描述简洁、清晰、明了
           C 检查每条测试用例都有明确的预期结果
           D 根据正规化用例的各个字段要求对应的细节
    (测试目的、前提条件、实现说明、测试环境准备、测试步骤、优先级别、是否自动化等)
    希望对你的软件测试工作有所帮助。


回复

使用道具 举报

发表于 2017-7-17 10:23 | 显示全部楼层
谢谢楼主
回复

使用道具 举报

发表于 2017-7-17 11:13 | 显示全部楼层
谢谢分享啊!辛苦
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则



诚聘英才|移动端|Archiver|版权声明|大家论坛 ( 京ICP备06071611号,京公网安备11010802018363号 )

GMT+8, 2018-4-20 09:05 , Processed in 0.202934 second(s), 16 queries .

Powered by Discuz!

© Comsenz Inc.

快速回复 返回顶部 返回列表