维护工作的总结

      这个项目并不是我所预期的那种，它跟一般的项目不一样，没有需求，设计和实现。我们所要做的就是解决Bug。可以这样讲，直接进入测试和维护阶段。
      我们的工作是很痛苦的，因为解决Bug本来就很痛苦，特别是当Bug数量较多，而时间又很紧迫的情况下。我们所处理的Bug也让人感觉到什么是郁闷和纠结。因为Android是一个开源的系统，我们所拿到的东西就是达到几个G的源码。没有文档，没有需求说明，没有设计，就连代码中的注释都少的可怜。项目经理，开发人员，测试人员都面临着一大堆不确定的东西。由于没有需求说明，所以对于一个特征的正确行为或期望行为到底是什么样的，没人能给出正确答案。由于所有的人都不知道正确的行为究竟是什么样的，所以在相互沟通上浪费了大量的时间另外，由于缺少对系统的理解，所以对于本不应该修改而做的修改，就引发了大量的其他Bug。
     后来的总结与分析证明，系统中真的由于代码缺陷所引起的Bug数量是很少的。开始的一小部分Bug是由于测试对特征不理解，造成的，理论上来讲这并不是Bug。但开发人员在修改这些Bug的时候，由于缺少对系统的理解，因此虽然看上去修复了Bug，但是引入了大量的其他Bug。后来的大部分Bug都是由于前期的修改造成的。
     本来这种不确定不足以引发这么大的问题，但由于对方公司的制度问题，也引发了大量的不是Bug的Bug。而且其中的很大部分还做了修改。试想，给没有缺陷的代码做修改去修复本不是Bug的Bug，结果会是多么的悲哀。对方公司的测试都是自由测试人员，以用户的身份来测试，他们只要每天找到三个Bug就算合格。他们只有Bug数量上的要求，但对于Bug的质量却从不过问，而且对方公司还按测试人员所提的Bug数量作为他们业绩的主要参考。这就造成了，他们在找Bug的时候，带着功利心理，不是以提高系统角度来测试，而是以找到问题（甚至故意制造问题），或是让系统出错为目的。因此，有此Bug让人非常的无奈，这也浪费了项目组成员的大量时间。最悲情的是为了修改某些本不要修改的Bug而做的修改又会引入大量新的Bug。