项目结束到现在也有一个月的时间了，对一些具体的内容已经有些模糊了，想一想还是觉得应该做个小结什么的，不然不好交代。就跟鸟在天上飞一样，飞过了没有痕迹，直到有一天你只记得你做过某一个项目，听起来就像个谎言一样空洞无物。趁现在还记得一些的时候整理记录一下。
我参与项目的时间是从08年5月到09年7月，一年有余的时间，过的也挺快。具体项目开始的时间我不记得了，我加入的时候测试已经开始了。测试的介入应该是从一些模块成型之后吧，最开始7个测试人员，初期的工作主要是根据客户提供的需求完成测试用例的编写以及对模块的UI测试。外包的一个特点就是客户往往会提供比较明确完整的需求，这样的好处就是QA做事有据可依，省去很多争论是或否的麻烦。从文档到测试用例的模板及缺陷的格式都有比较规范的统一格式，对于没有受过专业训练的测试人员来说可以算是好事吧，不用自己去摸索测试用例应该怎么来写，测试的范围要怎么界定，这些都不用花太多的心思。我是思维比较扩散的人，这有利有弊，有时候能发现别人想不到的问题，但是同时也容易忽略掉大家都想得到的问题。所以测试用例给出一定的方向，大致要覆盖到哪几个方面，测试的时候结合用例再加上自己的思维，就可以比较完整的覆盖整个模块了。
最开始阅读相关的需求文档，这里得说到一个习惯的问题，我向来的习惯是一拿到东西就直接往细里看，这样很不好的一个地方就是你猛看了一通之后对大局还是不了解，虽然可能看懂了一块里面说了些什么，这点是需要改正的，因为每一个客户需要不一样给出来的文档格局也是不一样的，所以正确的方法是先大致了解一下整个文档涵盖一些什么内容，重点在哪里，有了大致了解之后再细细地去看，这样的认识过程才会比较合理。这两种方法最后的结果可能是一样，花了一定时间都会对文档比较熟悉，但是我觉得还是应该调整一下。一个team重要的就是分工合作，而不是每个人都必须面面俱到。我加入之后QA总共是9个，BA是一个。我没有写用例和文档手册之类的经验，记得刚接触到条条框框都很清楚的用例的时候我是有抽了一口气的感觉，觉得我是怎么也写不出这么细致这么周全的东西的，页面UI测试的用例大致分为页面UI、可编辑框、不可编辑框、按钮等等几块，功能测试用例就看这个模块要实现什么样的功能了。一看到这些我的头还是有点大的，那种感觉就像一个自由散漫惯了的人突然被要求要遵守各项规矩。所以刚开始写的时候我并不顺利，经常漏了这个漏了那个，要不就是字体不一致，格式不统一，页眉页脚忘了修改。总之每次交出去的东西总能被找出一堆的错，很受打击，那时候心里也是很郁闷的，想怎么总是找我的茬，尽力去做却总会有漏子确实是不怎么爽的事情。每一次适应的过程都会有困难，我知道这不仅是我自己的困难，让我适应的人也会有困难，所以之前我舍友向我抱怨她带的人如何如何教不会的时候，我都会想到我最开始从不会到会的时候别人是不是也这么的无可奈何。就这么跌跌撞撞的开始写测试用例，回过头的时候还是看的见那时候一步步的进步的。一直都比较浮躁，所以做的事情多少让人不太放心，这也是我需要克服的一个弱点，就算心里浮躁也不应该流于表面。
按照既有的规则来写用例其实说起来还是比较轻松的，我总在想，如果一个项目给我，从零开始，要怎么办，什么都要考虑，找bug谁都会，但是一个项目的测试不只有找bug，还要有规范的文档（包括测试计划、用例、缺陷等等的管理），用例的一个作用是保证一定的覆盖率还有一个就是可以重复使用，不至于你测试过一遍之后下一遍还要重新开始，还不知道侧重点应该放在哪里，用例和缺陷管理如果结合的好的话，就能知道哪一块容易出问题，问题多的地方往往还有更多的问题，这是测试界里的一个常理。用例在整个过程中也是不断更新的一个过程，需求变更了要更新，测试过程中发现了问题没有用例对应也应该更新用例，这样才能保证覆盖率。需求文档也很重要，这类文档往往不是一成不变的，客户通常会时不时的提出新的要求，这样你就不得不跟着改变，所以需求的管理也很重要（有BA的话，这就是BA的工作），需求没有及时更新会导致一系列的问题：测试用例没有及时更新，这样执行的时候可能就会提出一些已经不是bug的bug，浪费很多的工作量。还有就是缺陷的管理，一个bug提出来，不是交给开发就OK了，你还要负责直到close，有时候这还没完，指不定什么时候就复发了。给了开发还要他也认定是个bug然后他才会去修改，如果他认为不是那就会T回给你了，这个时候就要你跟他去沟通认定是不是个bug，对于可改可不改的问题就看你说服力了。bug应该是什么状态就要是什么状态，这样查询起来也方便，也能及时得到处理，JIRA这个工具还是挺好用的，新出了多少问题，解决了多少问题筛选出来一目了然，做到心里有数。还有一个重要的是能够对阶段的测试结果进行分析，合理地调整测试计划。对测试结果能有一个把握，是否出了状况或是正常进行。
XXXX项目是在原有的VB系统基础上做的一个Web B/S系统，所以大部分功能都还是不变，只是新增了少部分模块，有原型做对照，工作就简单了很多，只要看到不一样就是个bug，哈哈~~~ 现在想来执行用例测试系统的过程还不算太痛苦，页面上烦琐的东西用例基本能覆盖到（这时候的感觉跟写的时候的感觉是完全不一样的，呵呵。。。），再加上测试过程中想像力的发挥，基本还是能把那些东东抓个现形的，所以这个过程还能找到一些成就感的。新鲜的时候可能会是享受，但是一遍又一遍的重复有时候就让人很抓狂了，测试一个系统不是一遍就搞定的事情，单个模块测试之后还有集成后的测试，完了是一遍又一遍的回归测试，这些还只是功能测试，我们没有负责性能测试。所以一个模块的测试有可能测十遍，如果你是个有责任心的人又没有足够的耐心是会崩溃的。当然这一遍又一遍的测试不是毫无意义的，因为每一次测试总能找到不少的bug，有以前没有测到的，也有以前修复好的，也有别的地方的修改引起的，所以zero-bug是不可能的，good enough是我们所追求的。完全的手工测试没有一点的自动化可能也是这个项目的一个缺陷，至少如果把检查页面打开、页面上各个标签及基本search功能这些基本的东西做成自动化会节约一定的时间，也比较不容易出错，可能也是source或者是时间不充足的问题，自动化测试着手进行了一段时间就放弃了，并没有真正运行起来。多少都觉得有点可惜，整个框架都很清晰，对象、公共函数都有分离出来，脚本也都是可以运行的，我个人是觉得前期分析做的不够，哪一些应该用来自动化，哪些不能自动化没有确定清楚，导致自动化效率低于手工测试，完全派不上用场。
项目的一期相对比较简单，都是依照原型的二次开发，再一个就是都是offshore的人开发测试，外包方开发及测试都没有参与，就不存在协调的问题，沟通起来比较快捷，争议的东西也较少。二期的时候，有开发一些新的模块，再加上外包方参与开发，onsite参与测试，两边的矛盾就出来了，一方改了什么问题没有通知对方引起了哪些模块的问题，或者是变更了需求、更改了程序而没有出书面文档自然就没有通知到offshore，这样就造成了混乱。然后两边同时参与测试，但是缺陷没有及时同步就又引起了bug老是提重了的问题，摒着以客户为主的原则，我们就显得比较被动了，所以只好不断的加大工作量来适应客户，这是很郁闷的一个事情，没有更好的办法的时候又不得不这么做。新增的模块需求的不确定性太强，总是不断的变更，然后没有做好需求管理，导致后面修改测试用例及测试的混乱。其实我到现在也还理不太清楚到底这些问题都出在哪应该怎么解决，全局观念很重要，方方面面都要顾及。就是到了最后，7月份测试的结束我也还没有缓过劲来，只是心里轻松了一下，不会再有那么多麻烦的事情堆着你了，没有项目完美结束的那种感觉。这也是我一直没缓过来的原因吧。
归纳整理很重要，这个项目给了我东西，但是没有记录，看不到整个清晰的一个流程在那里，有些重要的东西要找的时候总会找个半天，所以会归纳会整理很重要，有些东西不只是自己知道就好，也不是一时记得就好，做过了事情要有收获。多花一点点的时间或许可以节约很多的时间。下一个项目开始吧，改变一下方式，看看效果如何。