如何确定测试的重点?
发布于 2024-10-04
1506
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
软件测试质量等级与测试用例完备度框架摘要
由于软件测试无法覆盖所有可能性,测试工作的重点在于在有限的时间内提升软件的可靠性。本文提出了一个框架,帮助项目组确定测试重点,从而有效地分配测试资源。
质量等级的划分
首先,需要对被测对象的功能进行质量等级划分,其中考量的维度包括功能的重要性、使用频率和失效的严重性,每个维度分别赋值为3(高)、2(中)或1(低)。根据这三个维度的评分,功能的质量等级分为:
- 高质量等级:任一指标为3
- 中质量等级:三个指标均不超过3,且至少两个为2
- 低质量等级:最多一个指标为2
此规则可以根据不同公司的实际情况进行调整,且确定质量等级时应由需求人员、运维人员和测试人员共同参与,客户的参与更佳。
测试用例的完备程度
其次,基于不同质量等级,定义测试用例的完备程度。考虑的方面包括外部输入、正常场景、异常场景和内部逻辑,以及是否覆盖了边界值。测试用例应根据质量等级覆盖以下内容:
- 高质量等级:正常与异常场景的中间值、上下边界和边界值,及内部逻辑覆盖
- 中质量等级:正常与异常场景的中间值、上下边界和边界值
- 低质量等级:正常与异常场景的中间值及边界值
不同的公司和产品可以根据此框架定制适合自己的测试策略。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
440 篇文章
浏览 710.8K
用例,Bug一团乱麻?
用统一平台打通用例、缺陷与测试执行,告别碎片化管理。
查看测试管理方案
麦哲思科技任甲林的其他文章
同行评审培训练习点评结果
2008年3月3日做同行评审的培训,讲解同行评审方法花费了3小时,练习时间为1小时,点评时间为45分钟。参加培训的人员为20人,19人参与了练习,划分成了3个小组练习。3个小组对同一个需求进行了同行评审,该需求为一个实际项目需求的一部分,仅有1页纸,但是质量比较差。 这3个小组的练习结果如下表所示: 第1组 第2组 第3组
已发布接口与公共接口
已发布接口(published interface)与公共接口(public interface) 表弟在读《重构》一书,对已发布接口的概念有些迷惑,我对其进行通俗的解释如下: 已发布接口是指已经发布出去为其他系统的构件所使用的接口,有多少接口的调用者是无法知道的,已发布接口必须保持稳定,否则一旦修改,将引起其调用者的失败,而又不可能穷举出其调用者对他们进行修改,因为接口的作者不知道有多少调用者,
结论简单,教训深刻:一个大型项目关于需求工程的反思
某公司承担一个大型软件项目的开发,该项目的计划工期为2年,实际工期为2.5年。该项目为本公司新进入的一个行业,公司在其他行业里有相近软件的开发经验,但是对进入的这个行业并不熟悉。本项目采用了瀑布模型,高峰期70多人参与,最少时也有30多人参与。投入了接近100人年的工作量,而浪费的工作量大概在25人年,需求返工的比例占了40-50%。项目结束后做了复盘,我作为外部咨询顾问参与了项目回顾...
莫要混淆控制限与规格限
有的软件企业实施SPC时,在画控制用控制图时不但在同一张控制图上画了上下的1sigma、2sigma、3sigma线,还画了规格线,其实是画蛇添足,因为规格限如果在上下3sigma内,就失去了控制用控制图的意义。控制限是指通过对历史数据采用控制图(如XbarS图、XMR图)分析得到的,其值与均值偏离上下3sigma,规格限是由客户或者公司指定的,是对过程的能力要求,一般要比控制限宽,否则无
好书没废话:《看板和Scrum相得益彰》读书笔记
今天花了大概90分钟读了《看板和Scrum相得益彰》一书,让我击节赞叹,确实是一本好书! 1 本书很薄。薄的书能让人有耐心读完。 2 本书言简意赅,观点明确。能让人产生共鸣,能解惑。 3 充满了干货,读后让人有收获,可实际操作。对于我的收获整理如下: CH1-1 Scrum方法:团队拆小,任务拆小,时间拆小;看板:可视化、WIP、...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线