2008年度工作经验总结之BUG提交

上一篇 / 下一篇 2009-03-31 11:56:44 / 不允许评论 / 个人分类：提交BUG

查看( 611 ) / 评论( 0 ) / 评分( 0 / 0 )

2008年度工作经验总结之BUG提交

一．发现问题

之所以是“发现问题”而不是“发现BUG”，是因为在确认是BUG之前，测试人员发现不正常的现象不可以武断的认为一定是BUG，因为很有可能是环境问题或自己对需求或设计有误解。51Testing软件测试网?z-LF2V mDO

1.发现问题的心态51Testing软件测试网#`/et3D^3DX

测试过程中，如果有问题（可能是BUG）产生，我第一个想到的是为什么会这样，单靠我自己实在是解决不了这个问题的情况下，我这才去问开发人员，而且不是提交BUG的方式，而是抱着一种学习的心态的去请教他（请教问题比直接提出BUG要委婉的多，即使我能明确一定是BUG，而且连BUG产生原因都已经知道，但在我和开发人员沟通时，都尽量让开发人员自己发现原来这是个BUG，需要修改，而不是我提出来的。）。总之，在测试过程中，发现BUG反而不像是我的目的了，测试目的更像是去探索一个陌生的事物，因为我始终认为开发人员身上有很多值得学习的地方。

2.静态测试发现，动态测试确认

使用静态白盒测试发现了一个BUG，然后用动态测试的方法暴露出这个BUG，这个是否可以称为错误推断？和黄某讨论之后得出结论，应该不属于，用动态的方法去显示，只是更具有说服力（实际上，是因为静态的方式让我更有把握认为这是个BUG），让开发人员清楚的看到的确是BUG。错误推断，只是一种经验，凭经验认为某个位置或某段代码可能产生问题，然后用某种手段去试。

那么如何提交这种BUG呢？首先向开发人员描述问题的现象，等他理解错误现象之后，再以猜测的方式告诉他错误可能出现的代码位置和原因（这样他就知道你在看代码进行测试，增加对你的信任度），这样就非常快的定位到BUG原因了，当然不排除自己推断错误的情况，所以是以猜测的方式告诉他BUG的出处，这样即使错误了，也会被原谅。

二．定位问题

1.定位问题的好处

发现问题之后，帮开发人员定位问题原因的好处多多，这是肯定的，1.提高自己的能力；2.对被测系统的实现更了解；3.不会因为环境问题而提交不是BUG的“BUG”；4.开发人员修改BUG的效率变高；5.满足了测试人员的好奇心（既然看到了程序中奇怪的地方，即使认为肯定不是程序的BUG，但是还是要去寻找奇怪现象的原因。这也是我个人认为测试过程中最兴奋最有成就感的地方）。

举个例子，查询报表时数据出不来，寻找为什么会显示不出数据，以及如何才能显示数据的角度出发，从代码中理解该功能的实现原理，然后想办法让报表有数据产生，也许这的确是个BUG，等到你发现是BUG的时候，很有可能已经知道了BUG产生的原因，向开发人员提出时将非常具有说服力，即使不是BUG，也锻炼了你的学习能力和逻辑思维能力，对该功能设计也更了解了，搞不好还能设计出其他有效的测试用例和数据，何乐而不为呢？所以，当发现问题时，首先想到为什么会出现问题，然后去寻找答案，这样比单单提交BUG要有意义的多。还有，如果发现的问题的确对程序影响并不大，又理解为什么，这样更能理解开发人不修复该问题的理由，相互理解是良好合作的前提。

但是即使自己的编程技术超过了开发人员，也最好不要给开放人员如何修改BUG的建议，这样会局限开发人员自己的思路，而且如果修改的不好，反而是测试人员的错。这里有两篇不错的帖子和一篇blog文章，推荐！

http://www.itpub.net/viewthread.php?tid=81411751Testing软件测试网+m Atbk#N*T

http://bbs.51testing.com/viewthread.php?tid=5226

http://hi.baidu.com/smallfrogs/blog/item/893bfd030b3f258cd53f7c21.html

2.DEBUG技术

当程序出现问题的时候，以我以往的解决这种问题的经验来看，单凭表面现象的提示信息是很难定位到问题原因的，因为可能程序中很多处的错误码返回都是这个提示信息，那怎么从这个相同提示信息定位到其中某个具体代码的位置呢？所以开发人员在自测的时候，会使用DEBUG来进行问题的定位，比如说写日志、标准错误输出、打印错误信息等等，其中有个很好定位的方法是输出问题所在源文件名和代码位置（在UNIX下的C编程中使用宏__FILE__和__LINE__），这样比提示信息要详细的多，

据我了解，UNIX下的C编程的程序，调试代码的方式无非就是2个，1个是写（fwrite)日志文件中，另1个是printf出来，方法都是在程序运行时，将一些中间过程和中间变量实时的输出，根据具体的情况来增加新的输出语句，这样遇到问题时，能根据这些输出语句得到运行时经过的代码。

3.后台问题定位

当后台返回错误时，如何定位错误？下面是我的经验总结：51Testing软件测试网&UV%H}+~ Yv

a.想办法让后台打印出调试信息，因为调试信息比错误日志更详细，开发人员可以从调试信息入手，我们也可以充分利用调试信息来帮忙定位问题。

b.从调试信息中，定位到具体的源文件

c.如果调试信息中有错误所在的行数，则直接定位到该行去检查，如果只有错误码，则根据错误码找出所有可能返回这个错误的多处

d.如果错误码出现的地方太多，而无法确定是哪一个，则加入printf代码到返回各个错误码语句的前面，要有所区别，使得可以得出程序运行时，执行了哪些语句，是返回了哪一行的错误码

e.如果能确定是哪一行返回的错误，则顺藤摸瓜，根据函数调用的关系，找到返回错误的最原始语句（很有可能是个判断条件），这个时候还可以加printf语句来帮忙定位（打印出其中一些重要变量的值），试着去理解出错处代码的功能意义，然后得出错误产生的原因。如果重要变量的值来自与共享内存或二进制文件，则去寻找是哪个程序同步到了共享内存或文件，追踪到该程序的同步代码或者是数据库中某表的某个字段。

4.没有定位问题？

有的时候定位问题，不需要定位到具体位置，只要能确定你所测试的模块没有问题，而是其他关联模块的问题就达到测试目的了，那么可以使用版本比较测试的方式来解决，比如说旧版本的关联模块＋新版本的测试模块、新版本的关联模块＋旧版本的测试模块，两者的输出数据进行比较就可以知道问题到底是出现在关联模块还是测试模块了。当然这是实在是定位不到那个模块后的一个笨办法。

在执行测试的过程中，如果发现疑似BUG但还没能定位的情况下，还是可以把问题记录到TD中，但是缺陷状态可以写成“待确认或疑问”，然后等到自己定位到代码处时可以将状态修改为“new”，如果最后自己发现不是BUG，可以修改状态为“确认不是BUG”，开发人员只要关注“new”状态的BUG即可。

三．提交BUG

1.在确认是BUG之前先不记录到TD中

在提交BUG的时候，我不会立刻就写进TD中，因为我还不能确定是不是BUG，但是等待已经确认BUG之后再写进去，可能会因为没有现场环境了，又会让BUG描述的不够清楚，所以想了一个办法，在确认是BUG之前，先记录在其他的文档中（我是记录在测试流程文档里），写成表格状，选项有：序列号功能特性问题描述日志记录产生原因问题状态，其中的问题状态包括“待确认、已确认、不是BUG、已录入TD、已回归”，这些状态的变化就是从发现BUG到确认BUG到回归BUG整个过程，所以在录入TD之前，将前3个状态的问题先记录在这里，这样等待可以录入TD的时候，也能够描述清楚了。

测试用例没有通过，不一定就要提交BUG，因为也许这个问题开发人员早就通知过你，这部分暂时未修改完或为了方便测试而故意设计的，所以测试用例状态可以修改为未通过，并写明测试结果，但不用提交BUG。毕竟BUG是提供给开发人员看的，如果提交一些别人已经明白告诉你的问题，这样会让人感觉不好，要提供一些对他们确实有帮助的东西，而不是展示自己有多么厉害，发现了多少问题。

2.确认是BUG就要提交

不管BUG的严重级别有低，也不管开发人员最后修不修改，一定要把BUG放进TD中，这样的话，如果出了问题，也好有话说。我已经提出来了，只是开发人员不修改而已。还有，在模块测试时，有些小问题可以不记录，开发人员也可以不修改，但是最后上线之前的系统测试中，一定要测仔细了（包括每一句话每一个字），同时提示开发人员进行修改，因为这些小问题也许在客户看来可能是大问题。51Testing软件测试网o9L6S.~)@6w

51Testing软件测试网(xk,^3\N#A

3.BUG提交的要求51Testing软件测试网ul:uC[ T"e

我对自己测试提交BUG的要求是，开发人员心服口服的修改了我发现的严重级别不低的BUG，而且BUG产生的原因（无论是自己发现的还是开发人员自己发现的）我能理解。如果最后发现我提交的问题确认不是BUG，或者严重级别太低的BUG，或者开发人员看到了我提的BUG但不是时间问题而不修改的，都会让我觉得我的测试能力有问题。

51Testing软件测试网J3`!pxm9t

4.BUG如何描述

为了让描述BUG的语言更专业更清楚些，需要用到某些特定的专业名词，比如说“××终端”“××界面”“××窗口”等，这些如果只是从系统界面上看是无法描述的正确的，所以有些“东西”的名称在一些文档中进行了定义，比如说“需求文档”和“设计文档”，这样，描述BUG的时候，尽量使用文档中的“名称”来进行描述，开发人员更清楚，BUG描述更规范。

在提交BUG的时候，一定要先描述过程，然后描述问题，最后再附加上自己的推断和根据。我发现有的时候，我描述问题的语言太直接了，只想表述自己的推断和根据，忘了应该先好好的描述过程。

5.提交开发人员已知的BUG51Testing软件测试网LaL:d(q

有点郁闷的情况是，在测试某个版本的时候，发现了很多严重的BUG，而且经过了反复的检验确认，可能连BUG原因的找出来了，可是一提交到开发人员那，结果他说早就在新版本中修改好了，他自己发现并且修改好的，虽然测试的那个版本的确有BUG，但是毕竟没有对开发人员起到什么大的帮助，这种结果是令测试人员很沮丧的。还有一种可能是他心里清楚提交给你的版本有些问题，但提交给你的时候不告诉你，然后在新版本中自己把所有问题解决掉。从这个角度看，测试人员发现BUG多不等于测试的成果就大。提交BUG不是测试的最根本的目的，而是辅助开发人员去发现忽略或不清楚的问题，所以在提交BUG之前，要去了解开发人员所知道的和所忽略的有哪些。

四．修复BUG

有的时候遇到BUG使得测试无法进行下去，但是这个BUG很简单，你自己就可以修改好，然后继续往下测试（和之前的BUG修改关联性不大），因为不能干等着开发人员修改，最重要的是尽量执行完成更多的测试用例。但是需要大改动的，就不要自己去修复了。51Testing软件测试网[;O f*J.\

当开发人员修复了某个BUG后，如果你有这个能力的话，最好是要比较修改之前之后的代码，查看BUG是怎么修改的，而且很有可能测试用例也需要同步更新，如果在修复的时候还修改了或加了一个功能需求，那么同样也要修改测试需求，所以BUG的回归测试没有想象中的简单，同时要检查测试需求和测试用例是否需要修改。实际上，我这么做的原因还有一个，就是你怎么修改代码的，我不想只是听你说，我要自己去看去理解去探索。也许是我的好奇心太重，不明白的东西一定要探个究竟，不能让我模模糊糊的知道一点，如果这样会让我很没自信很被动。

收藏举报

TAG:

查看全部评论