项目测试过程中我们的任务也许仅仅只是找出bug，但是对于bug产生的本身可能并不关心，因为绩效考核只关心bug的质量和数量，所以使得我们测试人员的眼光变得很狭隘，甚至可以说是肤浅。最近在接手一个项目测试任务时，发现我们的工作是如此的单调，而且不愉快，原因在哪儿呢，大家一致总结是因为没有需求，或者说有需求但是不明确，可能是由于习惯性的软件开发流程将我们套牢了，测试总是变得很被动，而且必须只能从需求入手才能开展测试，但事实证明，需求也有太多的不合理，因为当需求变得没有依据时，我们还能指望谁呢？

　　很久没有对理论性的东西进行探讨了，这次项目测试中让我深有体会，理论不只是理论，我们应该如何正确理解这些个理论和流程，习惯性被接受，还是不断地去思考，我想可以更理性一些，毕竟工作不只是为了工作，而是为了更好的工作。如何更好的开展工作，就需要我们通过各种办法来改善我们的工作。测试工作确实很枯燥，可能并是所有的人都这么认为，至少我也不这么认为，因为我总是在想办法让我的测试工作更简单，更高效，比如研究自动化，再比较多去了解学习一些测试工具，通过等等这些元素的摄入，我们也会惊叹原来工作可以这样来完成，因为这样更有技术含量，作为一个技术行业的人员，还有什么能比技术更吸引你的，除非你确实不是一个安心搞技术的人。再回到项目测试过程中，我们习惯来按照流程来工作，但是在流程不完善的情况下，我们如何开展呢，对于测试工作来讲，比较多见的就是没有需求，因为开发人员对需求很明白，不过都在他们脑子里，但最后产品上线了，用户反馈的却是这么功能是干嘛用的，为什么少了这个那的的？质问测试人员？我想我回答不了，我只能说我的需求来源于开发，因为他们说改就改，说不改就注释说这个板块可能不要，或者不重要，用户不怎么用，太多理由了，也许大家都很痛苦。但这里我只想说一点，我们的设计是怎么来的呢，我们的架构是怎么来的呢？这些个设计是合理的吗？记得有一次我问一个项目组的负责人关于项目架构设计，他反问了我一句什么架构，搞得我好像比开发还专业一样，然后我还跟人解释了半天，后来人就给我发来网络拓扑图，我也只能接受，因为追问几次人家都不耐烦了，这就是我们的项目开发负责人，就连他们都没有设计阶段的产物，还能指望下面的开发人员有设计方案吗？当然很佩服他们，最后产品也如期能提交上来，痛苦就留给测试人员来斟酌吧，毕竟各负其责，因为产品不合格，测试也是要负责任的。当然我们也有接到过一些设计实物，那就是图片，基本都是PS的，然后随便贴出在一些文档上加以说明，这就是所谓的设计方案，甚至可以说代替需求文档，我想要开始习惯这些了，因为他们准备继续这个干，更可笑的是，开发出来的产品还跟PS的方案图片不一样，我简直不能想象设计可以这样做。当然这只是描述我们实际工作中经常碰到的一些问题，以次可以想想我们的测试工作是何等被动，又岂能说有成果。

　　通过几次这种痛苦的磨练，我开始怀疑我们是否还需要如此被动的开展我们的测试流程，因为都被开发搞的焦头烂额了，更是被需求忽悠无法容忍了，不过什么样的环境我们还是得接受下去，只有通过自个卑微的努力去一点一点地去改变和完善我们的流程，毕竟产品的质量不是一天就可以抓起来的。而对于测试过程我还是吸取了不少经验，对于今后的项目管理我也有我个人的一些收获，这些都是痛苦的教训。以前我很不理解还有测试架构师这个职位，前段时间看过一篇关于软件设计师与测试架构师的PK，让我深有体会，测试架构师是什么角色，这个角色的重要性，正如我今天所碰到的这些问题，如果一个项目中有这样的角色，那测试过程将更加完美。测试架构师与软件设计师的PK就好象测试人员与开发人员的PK，但是从技术含量的角度，软件设计师和测试架构师可能更容易达成一致，因为产品在设计阶段的问题是至关重要的，一般能成为测试架构师，我想水平也肯定不是一般的，所以说如何让测试人员参与软件设计，并不只是一个形式，在没有测试架构师指导的情况下，测试人员参与软件设计是绝对有利于软件设计的，因为很多时候软件设计本身就没有依据可言，就需要测试人员扮演用户的角色来对设计进行测试，提出意见之后达成有效的共识。

本文转自一米一阳光博客园博客，原文链接： http://www.cnblogs.com/candle806/archive/2011/02/12/1952587.html   ，如需转载请自行联系原作者