实战体验报告

从我进入测试小组开始至今，可以说，我完整地参与了35这个版本的测试。从第一次迭代测试开始到回归测试完成，学到了不少的东西。

第一次迭代测试的时候，我还刚过来没几天，什么都不懂，TD都不怎么会用，而且就做了测试实施，没有涉及到需求分析和用例的设计，现在想想挺简单的，可是当时还是花了不少时间，因为对系统不熟悉，即使用例很详细，也不怎么会做。

到第二次迭代测试的时候，逐渐尝试自己看需求文档，写测试用例，参加需求评审，第一次去听需求评审的时候，说实话，不知道他们在干什么，反正听不大明白。这次回归测试是我第一次自己设计测试用例，着实给大家找了不少麻烦，尤其是RD，几乎把所有的东西给我重新讲了一遍，甚至把我需要重点测哪些地方，怎么测都给我讲了。

到第三次迭代测试的时候，情况已经好很多了，基本可以看懂需求，可以参考TD上前辈们写的用例自己设计了，参加需求评审也能有一些收获了，虽然不会的东西还是很多，但至少已经可以按部就班地去做点事情，学点东西了。可以说，从这个时候开始，才真正进入工作学习的状态了。

还没有来得及喘一口气的时候，35的回归测试紧锣密鼓地展开了，每个人负责几个模块。可能开始的时候把情况想得太乐观了。我第一个测的是考勤，我以为只要根据测试用例来，一个用例一个用例跑下来，应该花不了多少时间。

考勤预估时间是三天，在测试开始之前，我甚至觉得时间非常充裕。不过等真正开始测试之后才发现和我想象的差距太大了。考勤的测试我就DELAY了三天。

首先，我虽然学习了考勤系统，但是离实战水平还是有一段距离的，系统的不熟悉，让我的速度慢了不少；

其次，所有的用例并不是像我想象的那样照着就可以跑下来的，因为系统已经改变了很多，很多用例对现在的系统已经不适用了，而且考勤以前不是我负责的，我不清楚现在的逻辑和以前有什么不同，有的地方要找以前的版本再确认一下，而且一些内容RD也已经不是很清楚了，就存在了一个问题，要去确定究竟是以前的用例不适应现在的系统了，还是现在的系统存在BUG，在这个上面也花了不少的精力；

第三，由于初次参与回归测试，没有事先把需要的数据准备好，所以就出现了一种状况，在测试过程中，发现少什么数据，就赶着去造什么数据，这个浪费了不少时间，有时候等终于造好数据的时候，已经不记得当时想测什么东西了。

第四，我把回归测试想象的比较单纯了，以为只要抓紧时间好好测就可以了，直到真正测起来才知道除了埋头测是不行的，还要和RD好好沟通，确认BUG等，而且很多BUG会影响测试进度，如果不改好，有些地方是没有办法测的。

第五，我花在确认一个问题是不是BUG上的时间是比较多的，最主要的还是对系统不熟悉，导致发现问题时不够自信，总觉得是自己操作上的问题，而且害怕一旦把不是问题的东西当成BUG录到TD上去，会浪费RD的时间，所以每确认一个BUG，我都要找以前的版本去看看，到别人机子上去看看，确定不是自己机器的问题，还要问一下别人这种问题是不是因为我操作上的失误，等等，诸如此类的，浪费了不少时间；

第六，开始测试过细，导致后面时间不足，以后应该改变战略，分清主次，由粗到细，这样才能更好地保证软件的质量。

等回归测试第一轮结束的时候，还是有一小部分的用例没有跑完，就进入第二轮测试了，然后就是第三轮测试，总的来说，给我的感觉是第二轮和第三轮都在补第一轮的漏洞，也就是前面测试过程中没仔细测的，由于BUG没能测的，由于时间问题暂且搁下的，等等，对于我来说，不能算是完成了三轮完整测试。

我想象中理想的三轮测试是这样的：每一轮测试都能把系统完整的跑一遍，因为改了BUG之后对系统还是会有影响的，就算你第一轮测试的时候，那个功能点是好的，等过了几天，改了好多BUG后，真的很难保证功能点依然是好的，即使这个功能点没有被改动过，但是代码之间往往会互相影响的，改好一个BUG的同时可能附带产生了其他的甚至更多的BUG，所以第二轮第三轮测试如果人力和时间允许的话，能够都完整的跑一遍应该是比较保险一点的；第二，相同的模块每轮测试让不同的人来测试，就像我们以前工作时一样，我们同一个部分的测试也会测三轮左右，但是每轮都会安排不同的人来测，并且后面测的人要写一个DR报告书，可以很好地进行问题分析，而且对于以后的测试也是一个积累。

总的来说，这样的一次完整的实战体验，让我学到了不少的东西，不是从资料中就能学到的。不管什么样的知识，运用到实际中去，还是会有更多深刻的体会的。以后要在工作中逐渐积累，这样才能既保证软件质量，又缓解测试压力，人力和时间才能得到很好的利用，真正达到降低成本，提高质量的目的。