1、在做软件测试过程当中，我们会经常性地和开发人员打交道。常见的情况是针对软件BUG上的认知分歧，也就是我认为是BUG，但开发却认为不是该怎么办？其实，最好的解决办法是，一切基立于可依据需求文档来决定。当然在前期我们一定要和开发好好沟通，在认真讨论后，如果确实认为是bug就给开发修复，不是就关闭这个bug。在讨论完后如果依旧存在分歧的话 ，则需要将问题报备给开发经理和测试经理一起讨论，再做决定。
2、还有种情况就是项目上线后才发现有BUG的情况，虽然碰到很少，但也不是绝对没有。针对这种情况，我们首先要做的是重现这个问题并反馈给研发人员，尽快出patch或者解决方案。 如果BUG解决完毕且上线没有问题之后，我们会进行后续的处理。
3、在后续处理过程中，首先是要追查原因然后给出具体的应对方法：1）测试环境无法重现：可能是线上的环境造成的BUG或者是测试环境无法模拟 的情况。 解决方法：尽量完善测试方法、尽量模拟测试环境、增加线上测试。2）漏测：a.测试用例裁剪过度：错误预估优先级或者时间过于紧迫裁剪了用例。解决方法：在后续版本或者其他项目启动时重新评估测试时间，要求专家介入 对优先级进行评估，避免此类事件再次发生。
4、第三种原因是由于测试用例覆盖不全而导致由于用例评审的合格！解决方法：找到原因，并进行记录，在以后的项目或者下一版本重点关注。 最最重要的一点是，要将所有的测试用例进行补测。
5、在做测试实际项目过程中，经常会碰到用户需求临时变更的情况，面对这种情况都是要区别对待：如果是小的需求变更，合理的话，能改的，经理会让开发直接改，然后测试再测一下就好了。如果是涉及到比较大的改动的话，我们会开会讨论一下会影响到的模块，经理会计算一下修改的成本，一般会建议放到下一个版本再修改，如果必须要改的话，开发就会改的，测试也会重新修改一下测试用例，把可能会影响到的模块再测一遍。
6、对于原始测试数据从哪获取的问题，一般可以通过三种途径获取：测试数据从其他模板中进行导入的，有时也会自己设置测试数据，对于已经上线的项目，可以从生产环境中导入测试数据.
