软件测试中常见问题与解决办法
1 描述缺陷
软件测试人员对提交的缺陷往往需要向开发人员进行解释或者演示后，才能让人明白他真正要表达的意思。实际上，是否能够清晰地描述软件缺陷，体现着一个测试人员能力的高低。
除了极个别的不能重现的缺陷外，一个软件缺陷至少应该描述清楚三方面的内容：缺陷概述、详细内容、重现步骤。
缺陷概述-用一到两句话描述缺陷的症状，使管理人员一目了然大概是什么问题。详细内容-详细地描述缺陷的症状，可以发表自己对该缺陷的一些意见，主要供程序员进行分析。重现步骤-详细描述如何在系统中重现缺陷，这是非常重要的一项内容，如果重现步骤清晰，将大大加快开发人员修改缺陷的速度。
通常情况下，很多缺陷管理软件把”详细内容”与”重现步骤”进行了合并，即只有一个文本输入框供测试人员录入信息，这就导致很多测试人员疏忽了去描述”重现步骤”。此外，诸如测试版本、测试环境、发现日期等辅助信息也应该认真录入。

2 处理不能重现的缺陷
缺陷应该可重现，问题重现才可以让开发者快速定位原因并解决问题。在测试的过程中偶尔会碰到一些不能重现的问题，对于这类的问题：
（1） 应该将缺陷产生的条件和出现的问题做一个记录，建议开发者根据问题的描述进行原因定位。当然，即使开发者解决了问题，如果不能重现，也不能有效地验证。
（2） 根据经验，一般的问题的产生都可以找到重现的规律，只是看所花费的时间和成本。严重的缺陷一定要想办法找到原因，而优先级别低的问题因考虑成本可先将缺陷搁置，以后重现的时候再让开发者解决。通常，不能很快找到规律的问题都是一些比较重要且奇怪的问题，开发者一般不能根据描述进行定位，此时测试工程师应该有很强的责任心和信心想办法重现问题。
（3) 开发人员与测试人员应很好地配合，缺陷的重现效率才会更高，测试人员切忌一个人冥思苦想，而应该及时把问题和看法与开发人员交流，大家一起探讨可以有效地促进问题的解决，要懂得利用团队的力量。
（4) 注意缺陷出现时候的日志，通常程序日志都包含着很重要的信息，从那些信息中分析出现问题的条件，并尝试重现。
（5 ）遇到问题时，应该尽量将出错信息作为关键字在互联网搜索，可以帮助你获取灵感。
（6） 必要时，写一些简单的测试程序以帮助重现问题。

3 面对暂时无法解决的问题
在测试过程中，开发者可能会在缺陷回复的时候告诉你暂时无法解决该问题，这个时候作为测试人员应该：
（1 ）确定问题是否真的无法解决，解决需要付出的成本有多大。
（2 ）确认问题的严重性，如果此类问题不解决，是否会导致严重的后果。
（3 ）对于会导致严重后果的问题，要坚持让开发者解决并想办法帮助开发者解决问题。测试人员应该主动协助开发人员找到问题的原因和解决方法，充分利用团队的资源，请教这个领域比较有经验的工程师一起讨论问题的解决方法。
（4 ）对于对系统不会造成危害或虽然有微小的危害但修改成本过高而又可以人为避免的问题，则可以将问题留到下一版本解决或关闭这个缺陷，并在缺陷报告中说明原因和注意事项。
（5 ）测试人员的态度非常重要。在告诉开发者这个问题一定需要解决时态度要温和而坚定，让他意识到问题的严重性。

4 测试工程师和开发者的意见不一致
（1 ）客观地比较自己的建议和开发者的意见哪个更好。
（2 ）如果开发者的方法的确具有优势，那就应该接受开发者的意见；否则就坚持自己的建议并详细给开发者解释你的建议，使开发者认为你的建议值得采纳。
（3 ）如果双方还是对各自的意见相持不下，可以跟项目经理一起讨论，由项目经理衡量应该采取哪种处理方法，应尽量说服项目经理。
5 开发者不配合工作时的对策
（1 ）先进行一个自我检讨：我的态度有问题吗？我报的缺陷是否都描述清楚了？我所发现的问题是否有价值？如果这些问题的答案是否定的，那么自己先改正了，开发者看到你的改变，也会调整自己的态度。
（2) 在一个团队中有一、两个不合作的开发者是正常的，不可能每个人都那么配合、态度良好，坚持自己该做的就行了。
（3 ) 不要去逃避，双方之间换一种有效的沟通方法。比如，在邮件上交流不清楚，就换成电话或面对面，总之，交流的方式是很多的，选择双方更能有效沟通的交流渠道会达到事半功倍的效果。
（4 ）尽量避免与对方直接冲撞，即使双方之间发生了争执，也不要太介意。
（5）如果开发者实在不配合，必要的时候，可以适当表达你的立场，或者委婉地向开发者的领导反映或者将你们之间的交互邮件抄送给开发者的领导。这是一个有效的方法，同时也容易引发新矛盾，但这样做是为了有效解决问题。

6 处理不能迅速定位的工程故障
对于一些不能迅速定位的工程故障，开发者很自然寄望于测试环境能将问题重现，但正是因为问题复杂或者是在测试时没有考虑过的问题，才会遗留到工程上而导致出现故障。
（1）查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找到问题的原因或相关线索。
a . 如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条件相同的测试案例测试，尝试在测试环境中将问题重现；
b . 如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维定势，想想为什么会出现这样的故障，可能导致的原因有哪些，自己还有哪些测试点或异常没有考虑到，测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。
（2 ）在测试环境中使用实际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。
（3 ）在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境中将问题重现。
（4 ）问题重现后协助开发者解决问题。
（5 ）验证解决后的程序是否仍然会出现类似故障。
（6 ）总结出现故障的原因并作记录：如果是配置的问题需要提醒工程人员在实施时注意；如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例；如果某些异常是开发者没有考虑全面，要总结类似的问题并提示所有开发者注意。