软件架构引入的问题也很多。有经验的软件架构师知道如何优化系统，如何减少模块和模块之间的影响，接口如何定义清晰并具有可扩展性，数据如何共享和保护，消息如何传递，如何在减少系统开销的同时增加系统的容量，内存如何分配，垃圾如何回收，在满足这些条件的基础上如何选择简单的架构。这些说说容易，做起来很难。很多时候，糟糕的系统架构本身会引入瓶颈。在了解系统架构的情况下，测试人员很容易知道如何找出系统严重的问题。我记得我到一个部门去做测试架构师的时候，测试人员经常向我提及这个系统的问题，他们已经在测试过程中有了很强烈的感受，可是软件架构师们却一直不知道，他们似乎听不到测试人员的声音。当我设计了几个简单的性能测试case，把直接的测试结果摆在他们面前的时候，他们似乎是如梦初醒。但那个时候，已经进入系统测试阶段，修改软件架构是不可能的了。到了开发第二个版本的时候，架构师想修改软件架构，可是要付出的代价实在太大，只好做一些有限的调整了。如果在软件架构时让有经验的测试人员加入，让测试人员帮助检查系统的架构问题，而不是等到测试的时候才知道犯了错误，可以极大地提高软件的质量。

　　也许大家会很奇怪，为什么开发人员不知道自己的产品有什么问题？这个道理很简单，因为开发人员是制造者，而不是使用者。很多软件人员除了编译自己的软件外，从来不使用自己写的软件。这样，他们根本不知道自己写出来的东西究竟好不好。我记得我刚开始做开发人员的时候，写用户界面。一开始我做得很花哨，功能很多，有些自鸣得意。但我喜欢做好了让旁边的人来用用看，听听他们的意见。结果他们觉得我做得太花哨了，一点也不好用。我只好忍痛割爱，简化设计。我不停地修改，不停地让他们使用，反反复复很多次，后在他们的抱怨声中我把所有没用的花哨的东西都去掉了，界面又清晰又好用，连自己都喜欢上了后的风格。这也是为什么软件人员无法同时做自己产品的测试人员的原因。生产者很难客观地审查和评价自己辛苦创造的东西，所以他们对自己的产品不如使用者了解。测试人员在长时间的测试过程中，逐渐了解了软件和系统存在的各种问题，对可能出现的问题更加敏锐。那些架构师们也许只需要花上半天时间，找测试人员聊聊，知道自己设计出来的东西有多么大的问题了。可惜的是，他们常常高高在上，不屑于去聆听使用者的声音。

　　说了这么多，是想强调，提高测试人员的责任感和素质，对于提升产品质量是很重要的。测试人员越早加入软件开发流程，越是能提高软件的质量。测试人员不仅仅是测试的执行者，更是理解需求，审查需求分析，讨论软件架构，寻找系统瓶颈的重要参与者，更是用户的代言人。对于测试人员的要求是很高的，也应该更加重视测试人员的反馈和意见。

　　在很多公司，测试往往是薄弱的一环。我们可以看到国内很多产品，花哨的功能很多，可是用起来很不爽，质量也不过关，这都是只重视开发，不重视测试的结果。一个公司要想长远地发展，必须重视测试，培养的测试人员，给予测试人员更多的责任和权利，才能让自己的产品更稳定，更好用，更加符合客户的需求。