一个测试人员如何变成测试架构师

测试架构师必须具备的第一个能力：“准确的商业理解力。”

了解自己所在公司测试架构师团队的运作和工作内容，虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大，业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责，其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师，系统测试工程师再往上应该叫什么呢?最后参考软件开发的title，就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责，例如：领导负责一个产品线或一个大产品的测试技术规划，early testing，系统测试工程师的培养，与开发架构师一起设计和改进架构的设计质量，测试执行活动质量的审查保障，亲自指导重点测试方案的设计，为了不断降低公司研发成本而进行新测试技术研究实践和推广，基于风险的测试，基于模型的测试，安全性测试，兼容性自动化测试，分布式自动化测试，性能压力测试，需求测试等专项测试技术领域的研究，并支撑新领域重点市场项目活动等等。

与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本，不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架，针对具体的产品特点，思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率，让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型，能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动：如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求)，然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式，主要是亲自实践各种新测试技术后，再带着测试人员在实战中掌握相关的方法。

我们大部分的测试架构师都是写过自动化测试脚本或程序的，只是现在的工作由于需要我们去思考太多的东西，所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师，由于负责多个产品，还要抽取产品间的共性测试技术，要建立起产品线的测试架构图，统一产品间的测试技术，统一测试方案的设计质量标准，需要具备更强的抽取共性的能力。同时，还需要能在短期内快速了解和识别影响产品成败的关键测试技术，因为并不是所有产品都是性能压力测试就是最重要的。例如：某产品线有9个产品，有的产品最需要保障的是可靠性(性能，可用性不是关键);有的产品最需要保障的却是可用性，而不是可靠性;有的产品最需要保障的是安全性，而不是性能;有的产品最需要保障的是可移植能力和可集成能力，而不是性能。那么相应的每个产品测试用例设计就会有所侧重，例如：对于重视可移植能力和可集成能力的产品，测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。

因此，测试架构师必须具备的第一个能力就是：“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的，如果测试架构师识别错误了，那么有可能在需要重点保障的领域，测试技术和测试资源投入不足，导致最后产品的商业竞争力得不到支撑，得不到质量保障。例如：某产品对外宣传是业界可靠性最高的产品