1.为何第一轮测试已经修改的问题，咱们预发环境测试的时候还会出现sql
初步解决方案：调整测试战略从原来的测试过程测试
{冒烟测试-全用例-bug回归-自由测试-预发主流程回归-上线}视频
修改成开发
{冒烟测试-全用例测试-bug回归-自由测试-预发p1p2用例回归-线上主流程回归}产品
2.测试工程师做为软件从业人员为何必定要懂业务？验证码
1.理解业务有助于程序开发人员更新准确有效的开发出符合用户要求的功能效率
2.业务是一个企业的生命线，是灵魂软件
3.懂业务才能作出好的产品表单
4.测试用例=场景+方法，场景是基于对行业业务的熟悉，方法是基于对测试理论、测试方法的掌握。因此这至关于两条腿都不能缺bug
三、关于如何进行老数据兼容和数据迁移相关的有效测试~？？
四、关于一旦tms录入错误的数据A后wms的库管没法在收到B的状况下反推的问题？？
五、关于什么样的须要能够开发自测，以及对于开发自测上线后持续修修补补的相关问题
六、关于上线时已知问题的后续修复问题
七、关于平常消防群中的问题解决和记录
八、关于上线前的业务方试用以及产品的公告和demo视频问题
九、关于产品后期统一更新prd的问题
十、写用例的出发点，根据流程来仍是根据功能来
十一、尴尬的状况：写的需求是A，最终提测的时候是B，测试人员须要临时改TC
十二、关于验证码：
若是页面正在获取验证码倒计时阶段，而后再次刷新或者退出再次进入页面，页面不支持再次获取验证码~防止别人恶意频繁请求
1三、关于准备了好久的测试数据和场景后，验证出来问题，开发告诉你那是在脏数据~我应该如何操做~
1四、业务to C和to B的区别
1五、 对于缺陷须要三方确认的，比较难汇集你们一致的时间，且时间比较零散会打扰三方的工做计划。致使问题不能及时确认或者遗漏确认，不出问题则以，出问题就会出现三方事故责任的争执。
方案：为方便测试、开发、产品三方对于缺陷信息确认，将这个确认过程作到缺陷管理的流程中。对于不肯定是否为问题的数据，是否能够遗留的问题数据要通过开发、产品、测试三个环节的流转，保证三方均知晓。也许你会问，这个流程变复杂了效率不会反而低了吗，一个环节停滞了就影响以后的流程。这点彻底不用担忧，缺陷的统计实时可查，邮件通知，瓶颈在谁身上一目了然，天然会尽快处理。
1六、开发修改完问题后不自测，问题并未修改完毕就指派给了测试验证，耽误双方时间。
方案：针对此问题，在缺陷表单中增长自测版本项，为空时缺陷不能够提交到下一步。以前还包含缺陷缘由，测试范围建议等，培养团队全部角色关注产品质量，在团队的配合方式不断改进，你们的意识习惯造成后可逐渐缩减限制。
1七、 随着项目进展会发现缺陷的状态多种多样，已有的缺陷处理方法不够用了。
灵活增长处理动做，包括问题不可重现、技术不支持等，每一步可限定可操做的角色，不可指派给其余角色的人进行处理，保证流程的严密性。