获取经验，初步推断是由于内存溢出而产生的

core

（

3

）

将这些文章转发给开发负责人，并讨论可能导致的原因，开发 从文章中获取灵感，

写测试程序对推断进行测试

（

4

）

同时测试人员详细分析程序运行日志，发现出现

core

之前，

短信编码为平时少

见的

245

，而短信的长度则是一个临界值

140

字节

（

5

）

测试人员从程序运行日志中得到启发，

发送一条短信编码为

245

且短信长度为

140

字节的短信，果然出现了相类似

core

（

6

）

开发人员分析根据测试结果分析导致

core

的原因：

调用

sprintf

打印短信内

容的时候导致了内存溢出，而这样溢出会覆盖它后面的内存块的内存管理区

域，在紧接着的

malloc

操作 中就会发生段错误，从而导致了

core

的出现。

这个问题的原因，因为多人 的参与，得到了准确的定位和解决，虽然原因是我最先发现的，

但问题的准确定位和解决 并不是归公到某个人，而是大家一起努力的结果，团队的结晶。

二、

暂时无法解决的问题

在测试的过程中，开发可能会在

bug

回复的时候告诉你暂时无法解决该问题，这个时候作为 测

试的负责人，应该怎样处理呢？

1

、

首先，确实问题是否真的无法解决，解决需要付出的成本有多大。

2

、

其次，确认问题的严重性，如果此类问题不解决，是否会导致严重的后果。

< br>

3

、

对于会导致严重后果的问题，一定要坚持让开发解决，并且想 办法帮助开发解决问题。测

试人员应该主动协助开发人员找到问题的原因和解决方法，< /p>

并充分利用团队的资源，

请教对

这个领域 比较有经验的工程师，大家一起讨论问题的解决方法。

4

、

对于对系统不会造成危害的问题或虽然有微小的危害但修改成本过高而又可以人为避免，

则可以将问题遗留到下一版本解决或关闭这个

bug

，并在

bug

报告中说明原因和注意事

项。

5

、

这个时候，测试人员的态度非常重要，在告诉开发这个问题一定需要解决的时候态度是温

和的坚定，

并让他意识到问题的严重性。

试 想想，

如果你板着脸孔冷冰冰地丢给开发一句“这

个问题一定要 解决！

”扭头就走，

他会是怎样的反应呢？可以笑的时候就笑吧 ，

大家都是工

作，不要将工作的氛围搞得太僵，大家在一个和谐 的环境中工作才会保持愉悦的心情。

6

、

发现问题之后测试人员可能心里会嘀咕“反正这是开发的问题就让开发去折腾吧”，如果

你一不小心这样想了，那就偷偷的想几秒钟好了，这个念头闪过之后，作为

< br>

bug

负责人的

你怎么忍心 看着开发一个人手忙脚乱呢？测试和开发其实是一个整体，

在这个整体中的每个

人都有责任去解决问题。

三、

测试工程师和开发工程师的意见不一致

1

、

首先，客观地比较自己的建议和开发的意见哪个更好。

2

、

如果开发的方法的确是比较优化，那就应该接受开发的意见；如果经过对比之后还是觉得

自己的建议更好，

那就坚持自己的建议，

并 详细给开发解释你的建议，

通过对比两者之间的

差别婉转地告诉 开发你的建议值得采纳。

3

、

如果双方还是对各自的意见相持不下，可以跟项目经理一起讨论，由项目经理衡量应该采

取哪种处理方法。不过，有时候，项目经理也不一定站在你这边，你可能还需要花脑筋说服< /p>

项目经理或被项目经理说服。

4

、

当然，这个问题的讨论前提是问题值得花时间和精力去研究讨论，如果是一些比较简单或

次要的问题，

就没必要花那么长的时间去计较了，

< br>放过开发吧，

也许他真的觉得这个问题没

必要这样修改或 者是他也修改到很累很烦了，这么简单的一个问题何不让开发轻松一下？

四、

开发工程师不配合工作

1

、

先进行一个自我检讨：

我的态度有问题吗？我报的

< br>

bug

是否都描述清楚了？我所发现的问

那么自己先改正了，

开发会看大到你的改变，

也会调整自己的态度的。

2

、

在一个团队中有一、两个不合作的开发工程师是正常的，不可能每个人都那么配合那么好

态度，也没必要自己觉得很难受，因为问题在于他的身上，你做对了自己该做的就行了。

3

、

不要去逃避，双方之间换一种有效的沟通方法。比如，在

MSN

上交流不清楚，就换成电

话或 面对面，

听到你愉快的声音或看到亲切的面孔，

对双方之间的互 动更加有帮助。

但不要

说着说着就火冒三仗，

< br>面红耳赤了哦！

如果你也是火暴的脾气，

面对面交流双方 很容易争执

起来，那么就通过

MSN

或邮件来交换意见吧！总之，交流的方式是很多的，选择双方更能

有效沟通的交流渠道会 达到事半功倍的效果。

4

、

尽量避免与对方直接冲撞。人的自尊心都是很强的，学历越高或能力越强的人，通常自尊

心也是越强，你尊重他他才会尊重你，说得通俗点，你给了他面子、给了他台阶，他才会给< /p>

你面子给你台阶。即使双方之间发生了争执，也不要太过介怀，只是工作而已，大方点继续

对他真诚的微笑。

5

、

如果他实在不配合，必要的时候，可以适当表达你的立场，或者委婉地向他的领导反映或

者将你们之间的交互邮件抄送给他的领导。

这是一个有效的方法，< /p>

但同时也是一个容易引发

新的矛盾的方法，

记住这样做是为了有效解决问题，

而不是在别人背后“打小报告”。

< br>这是

在工作，对事不对人。

在我的

team

< br>中，有一个开发的态度非常不配合，不管是对我还是其它的测试人员。

五、

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

对于一些不能迅速定位的工程故障，开发很自然

寄望于测试环境能将问题重现，如果能够轻易

在测试环境重现，那肯定是一件 好事，不过通常如果是一些简单的容易出现的问题，在测试的时候肯

定就已经发现问题了 ；

正是因为问题的复杂或者是一些测试时没有考虑过的问题，

才 遗留到工程上导

致出现故障。

1

、

查看工程环境程序日志，如果没有查询的权限，请工程实施人员帮忙查找，分析日志查找

到问题的原因或相关线索。

2

、

如果日志的提示信息足够，可以根据日志定位原因，则在测试环境中按照日志提示构造条

件相同的测试案例测试，尝试在测试环境中将问题重现。

3

、

如果不能从日志中获取足够的信息，而且测试环境中也无法把问题重现，那么先跳出思维

定势，

想想为什么会出现这样的故障，

可能 导致的原因有那些，

自己还有哪些测试点或异常

没有考虑到，测 试环境和配置与实际的工程环境和配置有哪些差异等等。同时主动

与开发

负责人、工程实施人员以及有经验的项目经理讨论，分析可能导致的原因。< /p>

4

、

请工程实施人员将工程环境的配置文件和执行程序帮忙

ftp

到本地测试环境，在测试环境

中使用实 际工程环境的配置文件和执行程序，并尽量模拟实际环境搭建测试环境。

5

、

在模拟实际环境的测试环境中，根据分析的可能原因构造测试案例测试，尝试在测试环境

中将问题重现。

6

、

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

7

、

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

8

、

总结出现故障的原因并作记录，如果是配置的问题需要提醒工程人员在实施的时候注意，

如果是测试疏忽的测试点要在测试报告中记录并在案例库中增加相应的案例，

如果是某些异

常开发没有考虑全面要总结类似的问题并提示所有开发注意。

下面是一个非常难定位的工程故障的实例，

希望这个工程故障的解决方法和态度能够给你一些启

示。

1

、

问题描述：在某省某短信业务高峰期，实际处理的短信比接受到的短信少，也就是在系统

处理某环节丢失了部分短信。

2

、

问题进展：

A

、

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

B

、

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

C

、

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

3

、

问题解决：

A

、

登录实际的工程环境，查看所有相关的程序日志，但程序的日志都正常，不能从中得