测试心得—— Bug and Requirement Review Report

这两天有点忙，在忙着学习如何Review Bug和Requirement， 并运用到项目中，截止到今天下班前终于将report文档发给了组长和头，还不知道质量怎么样，第一次做这种工作，昨晚忙到夜里两点，不过精神相当旺盛，因为好奇，呵呵……

从Review的结果来看，我们项目中所形成的需求文档由于缺乏维护，导致了最终上交的文档与实际设计好的系统相差很大，需求文档一般在项目sprint的初期由开发人员形成，但是在项目进入到真正的编码阶段后，会发现初期的设计存在很多问题，于是就出现了需求的变更，设计的变更，而项目组内很少有人记得去同步更新需求文档，项目的编码阶段，测试人员需要对项目的进度和质量进行关注，同时也需要编写Test Case，在编写用例的过程中也会发现很多需求不明确的地方（在这里也说明了一点，就是我们在项目需求阶段的工作没有做到位，QA没有真正的明确需求），于是需求又在不停的更新，而很少有人去记得更新文档，最终在模块送测后，测试人员发现一些问题，大家才开始说起需求，而此时的需求是项目设计刚刚开始时形成的，很多变更都只是口头的，并没有任何书面说明，最终的结果是，需求文档作废，没有可用价值。

从BUG Review的结果来看，由于测试人员的经验不足，水平不够，或者对问题的分析不够深入，导致很多BUG只描述了一种现象，而无法体现bug的价值，尤其是一个bug的summary，描述很重要，所以此时对测试人员的语言组织能力有一定的要求，更甚者是按照bug的steps下来后并没有任何问题发生，相关的结果描述没有，截图没有，只是简单的一句"After the step, there is an exception error", 究竟这个error的现象是什么？内容是什么？或者描述，或者截图，这样才能让开发人员或者其他人员看懂并能根据step重现bug，此外还有对bug的严重程度的设置，无法按照严格的标准来提交，还存在部分基本语法错误，等等很多的问题都使我们所提交的bug的质量得不到保障。

这两天对之前参与过的两个项目的需求文档以及所有测试人员所提交的bug进行检查后，发现了我们在工作过程中存在很多的不足，测试越早介入项目越好，这一点我们已经基本能做到，但是在项目进行的过程中，对项目所有相关文档的维护也至关重要（包括requirement and Test Case）,以免最终的文档价值降低，同时在测试过程中测试人员发现问题不要急于报BUG，需要对问题进行分析，有必要时可以邀请开发人员帮助，将问题分析透彻，这样报出的bug才有真正意义上的价值将，也能帮助开发人员去修复bug，总之凡事三思而后行一定没错。

以上是这两天工作的一个总结和心得，写成文档，第一能记录下自己的收获，第二希望可以分享给看到这篇文章的人，Thanks！