根据个人情况,制定如下知识地图,参照学习

数据库:1)Oracle 10g-----工作中使用,需要熟练

      2)Sql2005-----工作中使用,需要熟练

      3)DB2-----目前未接触,需要了解

编程语言:1)C#---满足目前工作需要

        2)VBS---满足自动化测试需要

        3)C---满足性能测试需要

测试工具:1)QTP自动化测试----只能在工作中简单使用,需要提高

        2)LR性能测试----只能在工作中简单使用,需要提高

外语:1)英语

    2)日语

我给自己一年的时间,希望一年后我每一项都可以打80分

  对于测试，我是追求完美的，我的眼里几乎容不下UI上的瑕疵，更不用说是功能上的bug了，可能这与我的第一份工作有很大关系。

  来到现在的公司，我依然以自己的标准来测试，把自己认为要修改的内容都提交给开发的修改。事实证明，这么做是不可行的，首先来自的是开发人员的反对，接着是我们测试组内的委婉说明。当时我也觉得特别委屈，不是说测试就是发现尽可能多的BUG吗，为什么发现了又不改呢？

  在这样的疑问中，不知不觉已经过去大半年了，现在才真正想通这个问题。当然，像我那么做能够更好的保证我们产品的质量。但是如果以这样的标准来测试的话，首先是测试成本的提高，其次是开发成本的提高，而这两部分的提高又主要体现在人力上，这样的话，我们发布一个新的版本的周期变长，而在现在这样竞争激烈的市场中，一个新产品的发布时间是其能否引领市场的关键。

  当然，并不是说我们要把标准降得如何低，而使我们的产品不堪入目，我们需要把握一个度，在产品质量和人力成本中保持一个平衡，毕竟说得坦白一点，做产品不是做艺术品，我们要追求完美，但是，更要能够盈利，在这个基础上，对产品不断改善，我相信，这将是一个良性循环。

    来到这个公司已经有四个多月了，开始的时候只是先熟悉一些这里的工作，但渐渐的，发现这个公司给员工提供了比较广阔的发展空间，而且我的性格比较好强，不愿落后于其他人，因为总认为自己是优秀的。

    既然认为自己是优秀的，那么别人会的东西我也应该会啊，而且应该做得比别人好，但是几个月来，我真切的感觉到自己和同事之间的差距，和整个测试行业的差距，不会的东西实在太多，尤其是在测试网上看到同行们的文章，更是自惭形愧，不知道自己有什么值得骄傲的理由，甚至有点自卑了。

    我想一下子把自己不会的东西补上来，而且不仅仅是补上来，更想做得出色，于是我给自己安排了很多需要自学的内容，QTP，ORACLE，VBS，C#......同时我还不愿意放弃日语的学习，又想补习英语,日常的工作还不能松懈......

    这段时间，真的很累，最近更是莫名的浮躁，无法静下心来工作和学习,突然觉得自己堕落了......再这样下去怎么去提升自己呢,只会被别人前进的步伐远远抛弃在后面.

    今天魔海跟我讲的一席话让我受益匪浅,"一样一样来,不然什么都学不到,一定要打好基础",真的很适合现在我的情况,我最大的缺点就是心太野,却不能脚踏实地去实践,所以收获很小.

    以后,我会加倍努力的工作学习,不能因为工作的单调繁琐而厌倦,因为正是在这些看似重复的劳动中,我们可以学到很多有价值的东西.公司给了我们成长的舞台,最重要的还是要靠自己的努力.脚踏实地地去做好每一件事情,才会有收获.

  由于工作的需要，6月中旬我开始接触了QTP，开始真是觉得自动化测试深不可测。

  日常的工作依旧繁忙，我只能在工作的间隙或者晚上的一点时间来接触它。因为以前没有接触过,而且没有人教,只能靠自己自学了.

  从网上下载了一个QTP8.2装了,并且下了一本简单的教程,《MERCURY QUICKTEST PROFESSIONAL》VERSION 8.0,这本教程很简单，讲的很详细，主要是一个入门。我因为什么都不会，所以我就照着这本教程一步一步做，录制脚本、创建检查点、参数化测试...虽然我当时并不知道为什么这么做，尤其是录制脚本的时候，我不知道录制了脚本究竟有什么用，但我还是照做了。

  我把这本教程陆续跑完后，对它的原理才有了一定的了解。在这种状态下。我就开始了我负责模块的自动化测试，当把理论付诸于行动的时候，才发现事情没有我想得那么简单。

  一，并不是所有录制的东西都可以回放，有的步骤没有被录制进去。为了使步骤完整并且可以回放成功，对于没有被录制进去的地方，我采取了对象驱动的方式。

  二，我们所需要查入的检查点没有教程中形容得那么简单，而且我们要了解测试的进展情况，必须插入写日志的脚本。

  三，在系统中不得不考虑这样一种情况：有些输入值是不可以重复的，所以脚本第二次跑就会出现问题。我的想法是使它参数化，每次都从列表中读取。但这样还是有问题的，因为参数化是使它一下子跑多次。我现在还没有想到更好的办法。

  四，当我有对象驱动的方式写脚本时，发现不是每次都可以回放的，有时不可以识别对象或者父对象，到现在还没有解决。

持续学习中。。。希望同学者交流。。。

   最近我们开始了一轮新的测试，重新建立了一个空的数据库，而且这轮测试的重点是在UI上，所以就没有急着往数据库内造数据。结果发现有几个页面居然是报错的，而且这几个页面在前几轮测试中都确定是好的。

   我于是就拿了以前的环境来测，结果是好的，我就猜测可能是后期更改BUG时导致的。在开发人员的调查下才知道，这个问题一直就存在，只要有数据，页面就都能打开，主要是由于这几个页面都调用了一个类，而这个类必需要取到数据才可以往下执行，否则自然会报错。

   当初测的时候为什么没有发现呢？我想大多数人在功能测试的时候可能会按照一定的功能顺序，这样可以保证测的时候比较节约时间，等我们测到有问题的页面时，已经录入了部分数据，所以想我上面说到的类似的BUG还是不容易发现的。

   今天的这个情况让我觉得对于空库情况下还是要稍微走过一遍，再仔细进行功能测试，这样可能会发现一些类似的问题

   最近看数据挖掘方面的资料比较多,我觉得在我们软件的质量保证上也可以运用这项技术.

   首先,就从数据挖掘的定义说起:数据挖掘是从大量的、不完全的、有噪声的、模糊的、随机的数据集中识别有效的、新颖的、潜在有用的，以及最终可理解的模式的非平凡过程。

   这么说,可能没有接触过数据挖掘的人看得不是很明白,这里引用一下Hand et al. (2000) 的说法"数据挖掘是一种在大型数据库中寻找你感兴趣或是有价值信息的过程",这样可能更容易被理解.接触过数据挖掘的人可能都知道啤酒和尿布的故事,我认为这可以说是数据挖掘中的经典案例了,很多人都认为啤酒和尿布根本是不搭界的两个事物,但是商场通过对两者销量的分析居然巧妙的发现了两者的关系,年轻的爸爸们在买尿布的时候往往会顺便买上啤酒,所以商场就把两种商品的柜台放在一起了,结果两者的销量都大大提升.

    那么数据挖掘技术对我们的软件测试又有什么可以利用的地方呢?就我们当前的项目来说,我们会利用TD对测试的缺陷做一些统计和分析,从而判断哪种类型的缺陷比较多等等.如果我们想把分析的层次更深入一点,得到一些让我们意想不到的有价值的数据的时候,我们可以尝试着引入数据挖掘的技术.

    你们可能会问,采用了数据挖掘技术后,我们究竟可以挖掘出什么样的有价值数据呢?这么说吧,我们至少可以知道缺陷之间互相影响的情况,比如缺陷甲增长的同时带动缺陷乙的增长,缺陷丙消亡的同时又使缺陷丁增长了.有了这样的数据,我们可以利用它来解决一些世界的问题,既然缺陷甲增长的同时带动缺陷乙的增长, 那它们之间存在某种共性或联系的可能性比较大,即使它们看起来是那么的无亲无故,当我们发现它们的共性的时候,我相信大家都应该想到很好的避免或者减少这种情况发生的方法,因为我们烦恼的并不是解决问题,而是发现问题.同样的,如果一个缺陷的消亡带动了另一个缺陷的增长,我们应该引起注意了,代码之间的相互作用的能力我们实在不能小看,在了解清楚根源后,我们可以通过改变一下修改缺陷的办法来避免新缺陷产生的频率.

    这些只是我所能想到的一些,我相信数据挖掘在软件测试或者开发中可以发挥更大的作用,只要我们去用心去发现,去探索.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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