测试小白日常工作心得

1.为什么第一轮测试已经修改的问题，我们预发环境测试的时候还会出现

初步解决方案：调整测试战略从原来的测试过程

{冒烟测试-全用例-bug回归-自由测试-预发主流程回归-上线}

修改为

{冒烟测试-全用例测试-bug回归-自由测试-预发p1p2用例回归-线上主流程回归}

 

2.测试工程师作为软件从业人员为什么一定要懂业务？

1.理解业务有助于程序开发人员更新准确有效的开发出符合用户要求的功能

2.业务是一个企业的生命线，是灵魂

3.懂业务才能做出好的产品

4.测试用例=场景+方法，场景是基于对行业业务的熟悉，方法是基于对测试理论、测试方法的掌握。所以这相当于两条腿都不能缺

 

 

3、关于如何进行老数据兼容和数据迁移相关的有效测试~？？

• 保证sql正确性和业务场景的融合度
• 和开发商量什么样子的老数据备用以覆盖测试情况

 

4、关于一旦tms录入错误的数据A后wms的库管无法在收到B的情况下反推的问题？？

 

5、关于什么样的需要可以开发自测，以及对于开发自测上线后持续修修补补的相关问题

 

6、关于上线时已知问题的后续修复问题

• 让产品拉一个小版本进行一次性修复
• 或者自己

 

7、关于日常消防群中的问题解决和记录

 

 

8、关于上线前的业务方试用以及产品的公告和demo视频问题

 

 

9、关于产品后期统一更新prd的问题

 

10、写用例的出发点，根据流程来还是根据功能来

 

11、尴尬的情况：写的需求是A，最终提测的时候是B，测试人员需要临时改TC

 

12、关于验证码：

如果页面正在获取验证码倒计时阶段，然后再次刷新或者退出再次进入页面，页面不支持再次获取验证码~防止别人恶意频繁请求

 

13、关于准备了很久的测试数据和场景后，验证出来问题，开发告诉你那是在脏数据~我应该如何操作~

 

14、业务to C和to B的区别

 

15、 对于缺陷需要三方确认的，比较难聚集大家一致的时间，且时间比较零散会打扰三方的工作计划。导致问题不能及时确认或者遗漏确认，不出问题则以，出问题就会出现三方事故责任的争执。

方案：为方便测试、开发、产品三方对于缺陷信息确认，将这个确认过程做到缺陷管理的流程中。对于不确定是否为问题的数据，是否可以遗留的问题数据要经过开发、产品、测试三个环节的流转，保证三方均知晓。也许你会问，这个流程变复杂了效率不会反而低了吗，一个环节停滞了就影响之后的流程。这点完全不用担心，缺陷的统计实时可查，邮件通知，瓶颈在谁身上一目了然，自然会尽快处理。

 

16、开发修改完问题后不自测，问题并未修改完毕就指派给了测试验证，耽误双方时间。

方案：针对此问题，在缺陷表单中增加自测版本项，为空时缺陷不可以提交到下一步。之前还包含缺陷原因，测试范围建议等，培养团队所有角色关注产品质量，在团队的配合方式不断改进，大家的意识习惯形成后可逐渐缩减限制。

 

17、 随着项目进展会发现缺陷的状态多种多样，已有的缺陷处理方法不够用了。

灵活增加处理动作，包括问题不可重现、技术不支持等，每一步可限定可操作的角色，不可指派给其他角色的人进行处理，保证流程的严密性。