不可重现的BUG的应对策略
发布于 2024-10-03
1728
版权声明
我们非常重视原创文章,为尊重知识产权并避免潜在的版权问题,我们在此提供文章的摘要供您初步了解。如果您想要查阅更为详尽的内容,访问作者的公众号页面获取完整文章。
麦哲思科技任甲林
扫码关注公众号
扫码阅读
手机扫码阅读
摘要
在软件测试过程中,一些难以重现的BUG可能导致几种不理想的处理情况:被开发人员拒绝、长期未解决或被错误地标记为已解决。正确处理这些问题需要遵循一系列策略。
1. 缺陷的描述
- 提交Bug时,应详细记录重现频率、现象、软件版本、数据以及软件出错时的环境。
2. 缺陷的重现
- 测试人员应负责重现缺陷,并尝试多达300次以验证问题的可重现性。
- 如果在紧急市场需求下,领导批准发布,应持续测试并在后续版本中解决问题。
- 无法重现的问题应由项目经理延迟处理,并跟踪一个月,若仍未重现则关闭,直至再次出现。
3. 不可重现的缺陷的处理方法
- 进行人工代码走查和工具静态检查,以发现潜在问题。
- 在必要时,考虑更换人员重新开发相关模块。
4. 缺陷的记录
- 开发人员在解决缺陷时,需记录修订号和bug原因,以便于追踪和质量提升。
- 将问题根据紧急程度列入跟踪列表,并在会议中定期审视解决状态。
5. 行政管理
- 不允许开发人员未解决问题就标记为已解决,必要时应重新打开问题。
- 在绩效考核中应排除因重现难度导致的问题,以防止作假。
- 加强开发人员的质量意识培养。
通过这些策略,团队可以更有效地处理难以重现的BUG,确保软件质量并提高工作效率。
麦哲思科技任甲林
麦哲思科技任甲林
扫码关注公众号
麦哲思科技(北京)有限公司总经理 敏捷性能合弄模型评估师 认证的Scrum Master 认证的大规模敏捷顾问SPC CMMI高成熟度主任评估师 COSMIC MPC,IAC 成员,中国分部主席
471 篇文章
浏览 1101.4K
还在用多套工具管项目?
一个平台搞定产品、项目、质量与效能,告别整合之苦,实现全流程闭环。
查看方案
麦哲思科技任甲林的其他文章
需求管理过程域的要点
今天在客户处,看到客户拿了一份从网上下载的对CMMI2级、3级的实践的注释,随手翻了一翻,刚读了第1个PA需求管理的5条特定实践,就发现基本上每条实践都有大大小小的误解,我想该材料很容易对CMMI的实施造成负面的影响。因此,特地根据我的咨询经验与体会,对该过程域的理解与实施要点进行了整理。在下表中:(1)没有翻译模型的原文;(2)包含了模型的要点;(3)扩展了模型的要求;(4)列出了客户的某些好的
需求分析核心五要素法
本文提出了"核心五要素法"需求分析框架,旨在解决用户需求表达与实际系统构建之间的鸿沟问题。
正式评估时被访谈人员应该注意什么?
在进行CMMI的正式评估时,被访谈的人员应该快速、准确、条理清楚回答评估组成员的问题,这样才能在比较短的时间内让评估组成员做出正确的判断。根据我的访谈经验,被访谈人员应注意如下的问题: (1) 听清楚问题,再回答问题。 有的被访谈人员可能是由于紧张,没有听清楚评估组的成员问的是什么问题,就答非所问,浪费时间。当你不能确定提问者的问题的含义时,可以要求评估组的成员对问题做出进一步的解释
时间箱管理
时间箱管理是敏捷方法中的一条实践,其含义是在项目中的某些活动的完成时间必须在规定的时间内完成。该实践有助于提高整个项目的工作效率,避免帕金森现象。
在敏捷方法里时间箱管理的具体体现包括:
(1) 每次迭代必须在固定的时间内完成,比如2周或1个月等,本次迭代必须交付一个质量得到充分检验的、可以运行的软件版本,如果有些需求不能在本次迭代内完成,则推迟到下一个迭代中完成。
(2) 项目的策划会议必须在4个小时内完成,某次迭代的策划会议必须在4个
要言不繁的DoD指南
DoD(The definition of done:DoD)完成的定义、完成的标准或完成的准则是敏捷开发方法中的一个重要概念,一个重要实践。本文对DoD如何理解、如何定义DoD及其作用给了简明扼要的论述,供各位实践者参考。 1 DoD的定义 可以从不同的维度理解DoD的定义: 1)DoD就是完成准则,完成就是不需要再做其他任何事情,可以直接交付了...
加入社区微信群
与行业大咖零距离交流学习
PMO实践白皮书
白皮书上线
白皮书上线