测试用例评审的旁观记录
发布于 2024-10-01
1376
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
测试用例评审会摘要
日期与参与者: 2022年5月24日下午,测试用例评审会召开,会议参与者包括项目经理、研发经理、技术架构师、效能经理、前端技术负责人、业务架构师、测试人员、开发人员以及外部咨询顾问,共11人。
会议时长与问题: 评审会持续了70分钟,期间发现了11个需要修改的问题。
评审现象: 观察到的主要现象包括:
- 测试用例按照状态-事件-系统响应的三段论方式描述。
- 讨论需求含义占用了超过一半的会议时间。
- 测试中常常遗漏异常场景。
- 参会人员积极发言,勇于表达重要观点。
- 区分了成熟功能无需重复测试的需求与本期不实现的需求。
- 测试用例使用了思维导图进行描述。
- 部分问题在会议中即时得到了修正。
顾问建议: 顾问对测试用例评审提出了几点建议:
- 评审应以需求为主线,先解释需求再审查测试用例,确保所有需求都被测试用例覆盖。
- 建议使用不同颜色标注正向和反向测试用例,快速识别可能遗漏的异常场景。
- 分析各角色发现问题的数量,评估是否需要这么多角色参与,以提高评审效率。
- 将发现的问题分类分析,并制作评审检查清单以供参考。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1070.9K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
需求控制组的构成
在软件项目中常见如下的现象: 用户提出了需求变更,市场人员答应了,开发人员认为工作量太大,不好实现; 软件项目签订了合同,规定了价格,在后期的开发过程中,需求变更很多,变更的成本都是乙方承担,项目结束后发现项目做亏了; 用户提出了需求的变更,开发人员直接修改软件,没有通知相关人员; 用户张三提出了需求变更,开发人员修改了软件后,张三又认为不妥
如何理解别人写的需求规格说明书?
在开发过程中,开发人员、测试人员都需要阅读其他人写的需求规格说明书,当阅读别人的需求文档时,我们需要关注什么呢?参见下图的要点: 首先需要了解关于该系统的总体信息,主要包含2条: 1 明确出该软件与其他系统、人、设备的交互关系。可以通过环境图,帮我们梳理清楚该软件与周边环境的关系,从宏观上对软件所处的位置有所理解。如下图所示: 2 系统的目标是什么,即解决了客
如何保证日志的准确性?
(1)开发一套WEB版的日志系统,只要有网络就可以填写日志,无论是否出差在外。 (2)日志系统要操作最简单,员工天天用,操作烦琐了,就没有员工愿意用了。 (3)日志系统能自动提醒没有按时提交日志的人员,如果靠QA人员或者PM天天去检查,容易遗漏,也太累啊。 (4)日志系统能自动检查有错误倾向的日志,定义几条启发规则,比如1天工作超过了12小时的,低于4小时的等等。 (5) 在日志系统中,需要填写的
需求评审会议亲历记
最近参加了一次需求评审,整理了整个过程如下: 评审组构成: 由EPG的组长担任评审会议主持人,评审组成员有12个人,6个开发人员,包括项目经理,都是项目组内部的人员,1个测试人员,4个EPG成员,1个外部咨询顾问。 准备工作: (1)提前1天发了会议通知,没有为评审组成员准备检查单。 (2)有2个人提前进行了准备,阅读了被审查文档,但是只找出了2-5个问题 (3)QA提前进行了文档与标准符合性的检
系统测试成功的关键点
(1)系统测试人员参与需求评审 (2)定义明确的测试需求 (3)测试人员要在需求阶段介入项目组 (4)系统测试用例要覆盖所有的场景 (5)建立产品需求与测试用例的跟踪矩阵 (6)评审测试用例 (7)利用回归测试工具 (8)
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线