今日与一友人聊起，测试架构师与产品架构师对产品的最终的贡献有什么区别？是不是测试架构师就只是识别出产品设计需求和架构设计中的缺陷而已？

　　我带着这个问题思考许久后得到如下想法：当一个测试人员经过多个产品的历练后。应该能成为一个设计高质量产品，而非仅满足基本应用的“山寨”产品的设计师，成为产品实现架构师的顾问，告诉产品实现架构师在考虑实现基本数据流和业务流之外，做一个真正质量周全的产品还需要增加哪些设计内容？

　　传统意义上的产品架构师更多考虑产品内部实现。弊端是：投入太多的思考在主业务处理流程的实现上，难免会对质量属性考虑投入少，导致设计出的产品只有基本功能和性能和不够全面的可靠性。这样的现象是完全可以理解的，因为人的时间和精力毕竟是有限的，一个高质量的产品除了主业务流程实现外，还需要把很多质量属性（性能，可靠性，可测试性，可用性，可扩展性，可集成性，可移植性，可维护性，安全性等）和容错处理能力的功能进行完善，才是一个可以适用大面积推广使用的产品。否则就只能在限定范围内进行使用，因为产品只实现了限定的有限功能。

　　在SEI的架构设计质量中，明确说明：产品的质量属性决定产品的架构设计。只不过在中国基本没有对质量属性有深刻认识的老板，产品经理，开发工程师或测试工程师，导致大部分的项目中，架构设计工作只是一个主业务流完成的实现思考过程，什么是质量属性，大家并没有系统的了解和认识？甚至很可能就没思考过，或听说过。

　　曾见过有网友提问：如何测试架构？我的建议是：最好自己去SEI搜索关于架构的一些资料。先明白一个好的架构应该包含的哪些内容？然后自己再把这些内容做成checklist，看看自己项目的架构是否有遗漏。

　　因此我们在评审架构时，应该先知道决定产品竞争力的质量属性是什么？然后以这些质量属性为树顶，从上往下细化这项质量属性需要有哪些功能，产品架构初稿是否有考虑实现这些功能？如果没有考虑，测试人员就可以帮助产品架构师来补充相关的功能。

　　如果我是一个公司的老板，我会让来自开发人员的架构师专注思考主业务流的实现架构和技术，并兼顾要负责思考可重用性，可移植性，可扩展性的质量属性。来自测试人员的架构师专注于：性能，可靠性，可用性，可服务性，可测试性，安全性的质量设计需求。两者合作优势互补相加后的成果，至少最后不是一个仅有基本功能产品架构。依据我的经验和思考，测试人员应该依托自己在系统测试活动中多年积累的经验，特别是多年只做一种系统产品的测试经验积累的基础上，自己注意反思总结【要牢记一个人的提升70％来自实践之后的“反思”】哪些bug是属于产品设计不佳导致的，并针对设计不佳的bug按质量属性进行分类，然后自己再学习一些架构设计的知识，这样以后成长为高级测试人员后，是能够成为有质量产品架构设计的顾问，从正向反馈的方向上帮助产品架构做好高质量设计。

　　测试人员未来亲自参与产品早期设计工作时，应该是做有质量属性的高质量产品，如果还是只做基本的产品设计，你就浪费了你这一段测试经历所获得的特有的技能和经验，这些经验有可能是一般开发人员可以需要十年以上摔跤，教训的经验才能获得的。

　　想到这里，明天我就在自己所负责的产品线执行上面的想法：把已发现的设计bug按质量属性进行分类。不但可加强测试人员的质量属性意识，学会用质量属性来思考产品质量，思考测试活动的目的，同时还可以为测试架构师团队更高质量的评估产品架构提供更多的“炮弹”。

（以上言论仅代表作者的个人观点，不代表51Testing观点）

版权声明：本文出自架构师Jack的51Testing软件测试博客：http://www.51testing.com/?293557

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。