关于测试流程的一些总结

做了将近一年的功能测试，现在转入到了自动化测试来。

功能测试自己做的算不上很精，但基本的流程还算清楚。

功能测试给我的感觉就是－－不受重视。最起码测试人员没有受到重视。

听到最多的就是，产品都会做，产品都能取代你们。

说这话肯定是不懂测试的人。至少肯定不是我一人碰到这种不受重视的待遇。

痛定思痛，行，我学代码去，学自动化去，学更多的技术去。只要工作闲下来，俺就去学，报培训班，自学两者兼有，看测试理论书籍，学测试工具，

总而言之，言而总之，不虚度光阴，不混日子。更不能被人看不起，为未来，为安全感 ，为可观的收入，自己不能停止学习的脚步。

上述这些话并没有抱怨，测试人员自身的技术水平决定了自己是否能得到重视。其实测试这个岗位，说得再重要都不为过。不是因为自己做这个，而是岗位决定的。（如果没有中纪委，官员就会不自觉。如果没有廉政公署，警员就敢明目张胆的勒索。如果没有测试，开发就敢不按规范来，反正自己觉得自己开发出来的肯定没有什么大问题，是按照需求来的。哈哈。一个优秀的 开发人员是在测试人员的督促下，慢慢提高自己的规范，提升自己的技能。这话真不假。当然他想成为优秀的开发人员，不然，就会和测试人员扯犊子了。）

多话不说了，自己总结一下一年多来，对测试流程的概述。

首先，产品立项（会有聚会活动的。通常大吃一次）

等产品人员出文档。（测试这个时候可以先想一下测试计划，测试需要的硬件资源登记，软件工具准备。等准备工作要做起来）

产品人员文档出出来后，先进行评审，也就是通常说的需求澄清。（需求文档也是一个不断完善的过程，这也是为什么后期需求会变更，开发要骂人的原因，有时也是客户的原因，临时变更）

一个系统的成败，产品需求的采集能影响至少50%，我做过一个失败的系统，就是因为产品需求采集的原因，导致项目最后失败，当然，产品也被除名了。）

其次，需求澄清时，产品，开发，测试，运营，客户等全部到场。评审产品规格书。这个时候，测试要小心，要逐字逐句的揣摩，要理解。配合需求说明书的还有产品原型。这是个好东西，根据它

测试非常容易就画出思维导图。这个过程，是讨论，修改，再讨论，再修改的过程。直到大家都接受为止。现实大部分是客户能接受，不管研发的死活，只要能开发出来，不管难易。理论与现实总有差距。

再次：需求澄清了，都开始干活了。开发出计划，出时间表，测试出计划，出方案。

测试这时，要画思维导图，要写测试大纲，测试方案，接着就是测试用例。当然，先分工。具体到每个测试人员到系统的某个具体模块。

测试经理收到各个测试人员的方案，导图，用例后，接着就是经常性的评审，分工，再评审，再修改。直到OK为止。

再接着：测试人员的用例 评审通过后，就等着开发人员出模块了。出一个测试一个。直到下一个模块的出现。

此时的开发改BUG的积极性不高。开发大部分喜欢在全部模块或大部分模块出来后，系统出现了雏形后，开发 再统一改BUG，前提是不要有一，二级BUG。

如果这时开发非常配合，改了BUG后，测试人员就回归测试，跑个小集成之类的。发现一个提一个。（这时不要找到一个BUG就大声叫出来，表现的兴高采烈的样子，估计开发听到后，一定会横眉冷对你的。这个时候的开发人员重心放在开发新模块上，根本不愿意来配合你改BUG，一听到自己开发的模块出现了BUG，心里都是不爽的。）

随着新模块开发出来越来越多，测试人员的工作量就直线上升了。重复提BUG，每天就是“点，点，点”，心里也是很枯燥的。（这个时候如果会自动化，就体现了工具的 价值）

最后：开 发人员开发完了全部的模块，测试人员就要进行大规模的集成测试（公司测试人员多的话，活还能 及时干完，如果人少，测试就要苦逼了。），刚开发出来的系统，刚做前几次集成测试时，每 天不提十几个BUG，好像都不正常了。只有经过了多轮测试，每天发现的BUG数才能下降。如果经过了多轮测试，每天发现的BUG数还没有下降，或者原来没有的模块也出现了BUG，或者，改过的BUG回归通过了，又出现了。这个时候，就要反思开发人员的开发水平了，或者开发人员版本管理方面是不是出现 了问题，或者测试环境是不是有问题了。

不去反思的话，BUG是测试不完的。或者还要考虑业务流程是否符合设计的需求了。（如果是这样，问题就大了。）

再最后：BUG也改的差不多了，没有一，二级BUG了，至少是没有发现，3，4级BUG也控制在BUG总数的5%以内了，（当然BUG等级定义要清晰，这样才不会提高，降低BUG的严重程度）。

再做最后上线前回归测试吧。加班，加班，再加班，这个时候的项目组要加班到很晚，而且要持续一周左右。

等客户来验收了，有需求文档，合同，用例 来验收吧。来付款吧。

一切顺利的话，大家都好。开庆功会。否则，挨屌是少不了的。（我以前公司开发同事的口头禅－－不求有功，但求不被屌。哈哈，太没自信了。）

上述的流程是概述，也有时不按这样的规范来。实际中，改了又改，测了又测。再改，再测。例如敏捷开发，真的很类似于边做边改的。哪有什么需求文档给你来参照。完全就是产品嘴上得来的信息。一周一两个功能模块的开发。以这样的进度。没有时间，毕竟时间就是生命。当然，测试的时间就更少了。

测试前要搭建测试环境，测试结束后要写测试报告。这俩步不能漏了。