一测试妹子的总结和心得

从5月底进入项目，在项目经理的帮助下开始学着一期B020测试用例，到熟悉测试流程，编写测试计划、测试报告，回溯分析，再到现在iBS重构，重新准备测试数据，整理测试用例，已经整整7个半月了，学到了不少东西，进行一下总结。
目前已经提单302个，编写测试用例约480个。在这302个BUG的提交和回归以及测试用例编写过程中，在测试文档的写作及修订中，我对整个项目的逻辑及功能架构逐步清晰，对项目之间所需的交互的认识也越发深入，对项目功能逻辑上的测试如何进行也更加明晰。
下面我简单谈谈对项目的认识、经验和教训，以及对未来改进的一些建议！

一、 对项目的认识
进入这个项目是在今年五月底，当时还没有IBS，只有一个被用户直接否定了的IDE工具。那时候项目组内没有测试人员，没有明确需求，没有明确的迭代流程，也就更谈不上测试流程了。
而我也没有直接开始测试工作，进入到了另外一个项目组——MBB熟悉业务。当时项目经理交给我两个任务：第一，尽快熟悉整个工具的作用和大背景，第二，从用户层次挖掘新需求（当时需求不明确确实是一个很严重的问题）。这两个任务，第一个任务通过在MBB拆分脚本和相应的配置文件，在业务上熟悉的很快，完成的较好，第二个，限于当时的确没有明确和规范的需求来源，而没有完成。
在MBB看到他们的项目相当流畅规范，比如充分利用白板和晨会让PM和项目组之间的成员了解彼此的进度和风险、奖惩措施激励组内成员斗志等等。
因为我们项目也是不断成长起来的，所以初期的时候比较迷茫，两方面的问题，一是业务的学习是要靠自己学习和领悟的，二是项目的流程没有规范起来之前工作比较凌乱，没有头绪，也没有信心。总结这两个问题的解决方法：
1、 主动沟通。问题汇总，集中解决；
2、 与项目经理反映目前的真实想法；
3、 通过周报制定工作和学习的计划；
测试人员进入项目初期，项目经理有必要指派专门人员与测试人员沟通，帮助其理清整个项目的顺序逻辑。
开始进入项目团队的测试人员，可以定期输出对项目结构、功能模块、测试点的理解为主要内容的总结文档，这样做有两个好处：
1、 可以帮助自己尽快清理逻辑和脉络，熟悉功能点，测试点
2、 总结的文档对后期进入的测试人员是一份重要的学习资料，待测试人员进入项目初期，可以节省专门人员与测试人员的沟通的人力和时间资源。
最开始的测试用例是我一个人完成的，这样会导致测试人员会先入为主地觉得自己不需要按部就班地照着文档进行测试（因为文档就是自己写的）。还有一个很大的问题就是，倘若测试人员在文档撰写上存在严重漏洞的话，他在测试时仍然不可能发现自己的漏洞所在。所以我建议测试文档撰写人员与测试人员最好不要是同一个人，这样有助于发现测试文档构建的漏洞。
项目中的测试人员可能因为各种原因，例如，对CBB语法，脚本配置文件含义，运行机制不了解，个人思维差异等，导致用例考虑场景覆盖不足，建议：进行完一轮迭代后，对用例进行刷新。定期强制性的刷新具有几个好处：
1、 对功能点、逻辑结构，使用场景能够常记常新
2、 覆盖场景、功能点日趋完善
3、 用例完善，对测试新人是一份有力的指导
一期项目结束后，对项目流程和测试流程已经有了深刻的理解了。接下来就是如何优化的问题。目前项目组分工明确，各司其职，运行流畅，再加上经验能力都很出众的古mm加入后，从她那里学到了更多的东西。
1、测试的立场，不是与开发对立，也不是同流合污，是尽早尽多发现问题，确保产品及时交付。
2、眼光不仅停留在测试技术，要善于发现流程上的问题，提出自己的改进意见。

重构阶段：没有新的功能点，工作重心在梳理重点功能，包括重构牵动的功能模块、性能提升点。脚本的写法变化较多，场景应进一步细化。多挖掘开发人员的设计逻辑，挖掘潜在的Bug。

在验证过去修正过的BUG时，仍然可以发现不少问题，有些是BUG本身的问题，有些是BUG附带问题，还有很多验证时联想到的问题。这一验证过程效果非常明显，所以我建议在项目末期有必要将过去修正的BUG重新认真验证一遍，可以在短时间内收到较好的效果。
二、 经验和教训
这个项目是我接手的第一个项目，也是一个理论联系实际的过程，回想起来，收获颇丰。
经验主要如下：
1、学会如何将书中的理论与实践相结合；
2、学会如何根据项目需求文档撰写测试文档；
3、学会如何根据项目变更修改测试文档；
4、 学会如何撰写文档，提交，验证问题；
 5、学会如何理清项目逻辑，如何更深入地撰写文档并进行测试；
6、学会如何与编程人员沟通交流，获得解答，以便正确提交BUG；
7、学会对每轮测试结束后对一些超标数据进行分析，优化下轮流程
8、总结规范和模板，提高工作规范性和效率：例如适用于自己项目的测试用例提交、用例编写规范，测试计划、报告等
9、学习是多方面的，向人请教，资料搜索能力，总结能力，通过问题改进的能力等对测试工作都具有很大的帮助

教训如下：
1、撰写测试文档前没有总结业务逻辑，导致前期测试深度不够；
2、撰写测试用例后每一轮没有及时更新，导致后期难以维护和修改；
3、 测试前人为工具比较简单，没有特别准备测试数据，导致测试速度比较慢，过程中心态有些浮躁，有些急于求成；
4、还没有形成测试思维，测试过程思维显得有些混乱；
5、一期对BUG轻重缓急界定不够，导致有时测试对重点功能的测试力度不够；

三、对未来改进的一些建议经过这次完整的项目测试，学到了很多，也发现了很多问题。对于未来项目的测试，我如下几个不太成熟的建议：
1、 在测试之前项目经理有必要对测试人员进行项目培训，不一定时专人专时的培训，比如看一些测试计划、测试报告、用例编写规范，输出一些理解性的东西等。让测试人员对整个项目心中有数，在撰写测试文档时有的放矢；
2、在测试文档撰写之前需要定义一个撰写规范和标准，大家按照同一个标准撰写，有利于日后文档的维护；
3、同一个项目功能测试至少应有两人，可以交叉编写模块测试文档，交叉检查文档，交叉进行回归测试，交叉验证BUG，这样有利于避免单人测试考虑不足的漏洞，也能产生更多新的想法，还能相互督促完善文档，提高测试进度；
4、项目后期，所有解决的BUG可以全部验证一遍，会发现不少难以预见的BUG；