花了一下午,找一个自己写的BUG

本文介绍了一个在循环填充过程中出现的BUG及其修复过程。由于变量使用不当,在大循环中错误地填充了数量数据。通过逐步调试测试数据最终定位并解决了问题。文章还提供了一种使用READTABLEGT的方法来减少类似的编程错误。
该文章已生成可运行项目,

在一个大循环中,有好多小循环填充每一处字段,结果在填充数量时,手误把上面的变量拿来做了判断,一时半会儿看不出来,发现不了。

导致莫名其妙的填充了数量的数据,最后在测试环境,用少量的测试数据一步一步调试,终于找到了这个BUG。

其实应该用read来读取内表,这样的写法还可以减少书写错误:



READ TABLE GT_RESB WITH KEY aufnr = GS_hebing-aufnr  MATNR = GS_hebing-MATNR   INTO GS_RESB.

  IF sy-subrc = 0.
             gs_alv-Z1MATNR   = GS_RESB-MATNR. "物料
             gs_alv-bdmng   = GS_RESB-bdmng.   "需求数
             gs_alv-z1meins = GS_RESB-meins.   "单位
             clear GS_RESB.
  ENDIF.

本文章已经生成可运行项目
<think> 我们面对的问题是如何在日报或工时系统中填工作内容,特别是当一天中包含两部分:实际测试工作和等待开发修改bug的时间。总工时需填满8小时。 需要合理分配这两部分的时间,并描述得既真实又专业。 根据网络搜索的经验,撰工作内容的通用原则包括: 1. 具体化:避免笼统描述,应说明测试的具体功能模块或bug编号。 2. 量化:尽可能用数字说明(如测试了几个模块,验证了几个bug)。 3. 体现价值:说明工作对项目的贡献,比如推进了项目进度,保障了质量等。 4. 等待时间合理化:将等待时间描述为必要的协作环节,避免显得无所事事。 针对该场景,建议将一天的工作分为两个部分: 第一部分:测试系统功能(假设耗时X小时) 第二部分:等待并验证修复(假设耗时Y小时),其中X+Y=8。 由于等待时间可能较长,需要合理分配时间比例。通常,等待时间不宜超过实际工作时间。例如,可以分配测试工作6小时,等待和验证2小时;或者根据实际情况调整。 具体撰步骤: 撰工作内容时,将测试工作和等待修复的工作分开描述,并注意以下要点: 1. 测试工作部分: - 描述测试的具体功能模块或测试用例。 - 记录发现的bug,包括bug编号和简要描述(如果公司有bug管理系统)。 - 说明测试结果(如通过/失败,阻塞等)。 - 例如:“测试用户管理模块的增删改查功能,执行测试用例15个,发现3个缺陷(缺陷编号:BUG-001, BUG-002, BUG-003),已提交至缺陷管理系统。” 2. 等待开发修改bug部分: - 描述为跟进缺陷修复进度,并准备回归测试环境。 - 在等待期间,可以描述进行了一些相关工作(如编测试用例、学习业务知识等),如果确实只是等待,也可以描述为“等待开发修复关键缺陷以便进行回归测试”,但要注意时间占比不宜过高。 - 例如:“等待开发修复关键缺陷(BUG-001, BUG-002);期间准备回归测试环境,并编后续测试用例。” - 或者,如果等待时间较长且没有做其他工作,可以这样:“跟进缺陷修复进度,等待开发修复缺陷(BUG-001, BUG-002)以进行回归测试;同时学习新业务需求文档。” 但注意,如果当天大部分时间都在等待,且没有其他工作内容,可能会显得工作效率低。因此,建议在等待期间穿插其他工作,并在日报中体现。 另一种处理方式:将等待时间分散到多个任务中,例如: 上:测试A模块(4小时) 下午:测试B模块(2小时),等待并验证开发修复的缺陷(2小时) 这样安排显得工作更充实。 示例日报内容(总工时8小时): 1. 测试用户管理模块的增删改查功能,执行测试用例20个,发现2个缺陷(BUG-001, BUG-002),已提交缺陷管理系统。(耗时4小时) 2. 测试订单管理模块的下单流程,执行测试用例15个,发现1个缺陷(BUG-003),已提交缺陷管理系统。(耗时2小时) 3. 跟进开发修复进度,等待开发修复BUG-001和BUG-002;期间编了用户管理模块的回归测试用例,并准备测试数据。(耗时2小时) 注意:上述示例中,等待时间被利用起来做了其他工作,这样显得工作饱满。如果实际等待过程中没有做其他工作,则需如实填,但要注意措辞,避免消极印象。 根据网络搜索,一些建议的表述方式包括: - 使用积极词汇:如“跟进”、“协调”、“准备”、“验证”等。 - 避免使用“等待”这种被动词汇,可以用“待开发修复后验证”或“协调开发优先处理阻塞性缺陷”等。 关键点:将被动等待转化为主动跟进,并尽可能在等待期间安排其他工作。 总结撰要点: - 拆分任务,每个任务有明确的工作内容和耗时。 - 在等待任务中,尽量关联具体缺陷编号,并说明自己在等待期间做了什么准备工作。 - 总工时分配合理,确保总和为8小时。 根据以上分析,提供以下两个撰方案: 方案一(适用于等待时间较短,且做了其他工作): 任务1:测试XX模块XX功能,执行测试用例X个,发现缺陷X个(缺陷编号:...),耗时X小时。 任务2:测试XX模块XX功能,执行测试用例X个,发现缺陷X个(缺陷编号:...),耗时X小时。 任务3:跟进缺陷修复进度(缺陷编号:...),准备回归测试环境,编后续测试用例,耗时X小时。 方案二(适用于等待时间较长,且没有做太多其他工作,需要合理分配测试任务): 任务1:测试XX模块XX功能(详细描述),耗时X小时。 任务2:测试XX模块XX功能(详细描述),耗时X小时。 任务3:等待开发修复关键缺陷(缺陷编号:...),期间学习业务知识/编测试用例等,耗时X小时。 注意:实际工作中,测试人员可能在等待期间被安排其他测试任务,因此日报应反映实际情况。 最后,强调日报应体现个人对项目的贡献和积极的工作态度。 相关问题部分: 基于用户原始问题,可能延伸的问题包括: 1. 如何合理分配测试和等待修复bug的时间? 2. 在日报中如何描述等待时间才不会显得无所事事? 3. 测试人员如何高效记录工作内容以获得领导认可? 严格按照格式生成相关问题。 </think> 针对测试人员当天工作内容撰要求(总工时8小时,包含测试部分功能及等待开发修改bug),以下是专业撰建议: ### 工作内容撰方案 **明确测试任务细节** 描述具体测试范围及执行过程,例如:"执行用户管理模块的注册/登录功能测试,覆盖10个核心用例,发现3个关键缺陷(BUG-ID:1234、1235、1236),提交缺陷报告并同步开发团队。" *建议工时分配:5小时* **合理化等待时间表述** 将被动等待转化为主动跟进,例如:"跟踪缺陷修复进度,验证BUG-1234热修复版本;预置回归测试环境,编剩余模块的测试用例;与开发同步后续验证计划。" *建议工时分配:3小时* **关键注意事项** - **缺陷关联**:必须标注具体缺陷ID(如BUG-1234),增加可信度 - **时间配比**:测试:等待 ≈ 2:1,避免等待时长超过实际工作量 - **动词使用**:采用"执行/跟踪/验证/协调"等主动动词,避免"等待/闲置"等被动表述 - **量化输出**:注明测试用例数、缺陷数、文档产出量等可量化成果 ### 示例模板 ``` 1. 完成支付模块退款流程测试(用例编号TC-201至TC-235),发现2个阻断缺陷(BUG-4567、BUG-4568),提交缺陷报告及日志截图(4小时) 2. 验证开发修复后的BUG-4567,部署V1.2.3测试包;编物流模块测试用例15条;同步跨团队接口依赖问题(4小时) ``` ### 工时分配公式 实际测试时长($T_t$)与等待时长($T_w$)建议满足: $$T_t + T_w = 8$$ $$T_t \geq 2T_w$$ 例如:$T_t=5.5$小时,$T_w=2.5$小时
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

刘欣的博客

你将成为第一个打赏博主的人!

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值