质量提升(1)

到底保证质量，需要怎么做，一直很迷茫，到底测试是这个问题的最终答案吗。曾经对于自己在测试的过

程中找到非常多的BUG而感到高兴，觉得这样的行为能够提高测试的地位。其实在IT工作的人都清晰的知

道，测试在研发流程中的地位是低微的，究其原因由于对前台页面测试的难度低，在公司里面的领导，大

多是开发出身，对测试认知不够。

这样往往导致误解，测试真的很容易，测试可有可无。真的是这样吗？个人觉得并不以为然，当然测试只

不过是研发过程的一环，一个对质量进行保证的单位，而象需求人员，开发人员，项目中的关键人员，并

不能有直接的体现，不过仔细研究，这些人员并非跟质量没有关系。软件生命周期的起始与需求，无论开

发还是测试，都根据需求进行开发和测试。从另外一个方面来讲，需求是用户对于软件逻辑的真实表现。

所以如果一个对用户需求描述的含糊甚至是错误的需求，将会引起什么问题，重要性不然而喻。开发的道

理也一样。如果设计的时候，已经偏离了需求，偏离了用户的预期，那么代码写得再漂亮也是没用。测试

作为最后端工作会受到前端的影响，最简单的用户希望在月底升级一个版本，需求开始跟客户接触，按照

计划，8号必须完成需求的最终确定，但是由于种种原因，需求推迟了进度，结果12号才能完成需求的确

认，开发接收到需求后，开始进行开发，幸好开发也是按照进度，10天就完成了开发，那么测试的时间就

被压缩了4天了，虽然有可能项目经理能跟客户反馈，延迟版本发布时间，但整个版本就乱了。从一方面

说测试是比较脆弱的，前端任何的动作都有可能造成对测试的影响。

刚开始接触测试的时候，确实存在对测试误解，甚至疯狂的认为软件的质量，有测试就够的。随着时间的

推移，一个又一个的项目中，一次又一次需求确认的推迟，多次由于需求文档描述的含糊，反复的与需求

人员的确认，导致测试的周期拉长，不得不问问自己，单单测试做得好就够了。不够，确实不够，作为同

一个团队里面的人员，如果不是每个人都有质量的观念，无论测试再怎么加班，再怎么技术牛，都是徒劳

。

上面讲了一大堆话，最终只是想突出一个问题，如果要提高软件的质量，必须要一条线，如何的一条线？

即是项目中的各个人都必须要对自己的工作负责之余，还需要协助沟通好项目的其他的成员，这些东西很

难要求自发主动的去做，只能从失败中总结经验，慢慢的完善流程，这些东西涉及到的是细节问题，需要

慢慢的深化。