软件测试工作中的常见难题及对策(2)

　　1、先进行一个自我检讨：我的态度有问题吗?我报的bug是否都描述清楚了?我所发现的问题是否有价值?如果这些问题的答案是否定的，那么自己先改正了，开发会看大到你的改变，也会调整自己的态度的。

　　2、在一个团队中有一、两个不合作的开发工程师是正常的，不可能每个人都那么配合那么好态度，也没必要自己觉得很难受，因为问题在于他的身上，你做对了自己该做的就行了。

　　3、不要去逃避，双方之间换一种有效的沟通方法。比如，在MSN上交流不清楚，就换成电话或面对面，听到你愉快的声音或看到亲切的面孔，对双方之间的互动更加有帮助。但不要说着说着就火冒三仗，面红耳赤了哦!如果你也是火暴的脾气，面对面交流双方很容易争执起来，那么就通过MSN或邮件来交换意见吧!总之，交流的方式是很多的，选择双方更能有效沟通的交流渠道会达到事半功倍的效果。

　　4、尽量避免与对方直接冲撞。人的自尊心都是很强的，学历越高或能力越强的人，通常自尊心也是越强，你尊重他他才会尊重你，说得通俗点，你给了他面子、给了他台阶，他才会给你面子给你台阶。即使双方之间发生了争执，也不要太过介怀，只是工作而已，大方点继续对他真诚的微笑。

　　5、如果他实在不配合，必要的时候，可以适当表达你的立场，或者委婉地向他的领导反映或者将你们之间的交互邮件抄送给他的领导。这是一个有效的方法，但同时也是一个容易引发新的矛盾的方法，记住这样做是为了有效解决问题，而不是在别人背后“打小报告”。这是在工作，对事不对人。

　　在我的team中，有一个开发的态度非常不配合，不管是对我还是其它的测试人员。曾经有一段时间跟他的合作让我觉得非常的难受，后来在一个新的项目启动中，我作为测试负责人，而他作为开发负责人，我对新项目的工作热情一下子降到了冰点。幸运的是，我很快调整了自己的心理状态，要改变别人，首先要改变自己，首先让别人信服自己。于是，我花了很多的时间和精力去研究规范和业务需求，同时也会学习该项目相关的技术，在他的设计文档提交的时候，因为我对业务的透彻理解，指出了他在设计和业务流程处理上的不少问题，在设计上给他不少的帮助，就在这合作的过程中，我们的关系慢慢得到改善。讲这个故事，我是想说，在我们的工作开展的过程中，会遇到各种各样的人，并不是每个人都那么容易合作，但开发人员一般也不会是不讲理的人，改善相互之间的合作关系最好的方法是先让对方肯定你。

　　五、如何处理不能迅速定位的工程故障

　　对于一些不能迅速定位的工程故障，开发很自然寄望于测试环境能将问题重现，如果能够轻易在测试环境重现，那肯定是一件好事，不过通常如果是一些简单的容易出现的问题，在测试的时候肯定就已经发现问题了;正是因为问题的复杂或者是一些测试时没有考虑过的问题，才遗留到工程上导致出现故障。

　　1、查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找到问题的原因或相关线索。

　　2、如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条件相同的测试案例测试，尝试在测试环境中将问题重现。

　　3、如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维定势，想想为什么会出现这样的故障，可能导致的原因有那些，自己还有哪些测试点或异常没有考虑到，测试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动与开发负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。

　　4、请工程实施人员将工程环境的配置文件和执行程序帮忙ftp到本地测试环境，在测试环境中使用实际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。

　　5、在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境中将问题重现。

　　6、问题重现后协助开发解决问题。

　　7、验证解决后的程序是否仍然会出现类似故障。

　　8、总结出现故障的原因并作记录，如果是配置的问题需要提醒工程人员在实施的时候注意，如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例，如果是某些异常开发没有考虑全面要总结类似的问题并提示所有开发注意。

　　下面是一个非常难定位的工程故障的实例，希望这个工程故障的解决方法和态度能够给你一些启示。

　　1、问题描述：在某省某短信业务高峰期，实际处理的短信比接受到的短信少，也就是在系统处理某环节丢失了部分短信。

　　2、问题进展：

　　A、实际工程环境的日志没有任何错误提示

　　B、相关模块的负责人进行代码白盒检查，也没办法从代码中看出缺陷

　　C、测试环境没有出现工程所描述的故障

　　3、问题解决：

　　A、登录实际的工程环境，查看所有相关的程序日志，但程序的日志都正常，不能从中得到启示和帮助。

　　B、根据推测可能的原因，在测试环境中试图使用大压力测试，但也没出现工程所描述的故障。

　　C、与开发负责人、项目经理和工程人员讨论可能导致故障出现的原因，并根据讨论结果设计测试案例、测试方案。

　　D、将工程实际环境的配置和执行文件拿到测试环境，并模拟工程环境搭建测试环境，发现其中配置存放短信的配置项比实际测试环境的大两倍。也就是：

　　; queue size, in byte, 20MB

　　QueueSize=20971520

　　; max ISMG queue length, 0 means no limit

　　MaxQueueLen=50000

　　E、模拟出现故障时的业务压力，发现当发送队列MaxQueueLen超过了46807后，不会继续增大，永远不会到达50000，也就是说永远不可能出现队列满的情况，模块永远不会报队列满的错误;所以系统只要接收到信息就往队列里放(只有该模块队列满或者连接不上等异常出现的时候才会存放到短信缓存器)，而该模块共享队列最大只能存放46807条信息，多余的信息也便丢失了。

　　F、建议开发人员修改程序，当短信存放超过了实际存放长度或配置长度，就提示错误并将短信存放到短信缓存器，确保短信在高峰期得到保障。

原文转自：http://www.ltesting.net