什么是测试架构师.doc

测试架构师必须具备的第一个能力：“准确的商业理解力。”最近看到一篇关于测试架构师介绍的文章，文章中的测试架构师原型来自微软，其描述的工作内容让不少国内的测试同业很是羡慕，但又觉得好像离我们中国人很远。不知我们中国的测试工程师能做吗?我的答案是Yes。因为，我现在就在中国带领着一个测试架构师团队。了解自己所在公司测试架构师团队的运作和工作内容(后续将陆续与大家分享)，虽然我们之前也从未接触过微软的测试架构师。但随着公司业务的扩大，业务的需要驱动了我们公司内部有一小部分人担当起了测试架构师的职责，其title来源也是有其偶然性。原本公司中测试工程师往上发展就是系统测试工程师，系统测试工程师再往上应该叫什么呢?最后参考软件开发的title，就开创性的在公司内部叫测试架构师。并开始从事了很多从公司层面而仅非单个测试经理层面所需要的新的测试工作职责，例如：领导负责一个产品线或一个大产品的测试技术规划，early testing，系统测试工程师的培养，与开发架构师一起设计和改进架构的设计质量，测试执行活动质量的审查保障，亲自指导重点测试方案的设计，为了不断降低公司研发成本而进行新测试技术研究实践和推广，基于风险的测试，基于模型的测试，安全性测试，兼容性自动化测试，分布式自动化测试，性能压力测试，需求测试等专项测试技术领域的研究，并支撑新领域重点市场项目活动等等。与微软的共性是我们的测试架构师都不再亲自写自动化测试脚本，不亲自写测试工具的代码。但我们会从项目初始即项目需求和架构设计阶段就开始考虑未来的自动化测试框架，针对具体的产品特点，思考选择最合适的自动化测试语言;在架构设计中充分考虑如何支撑未来更高的自动化测试率，让架构设计调整具备高的可测试性率;由于参与早期的设计方案讨论选型，能提前识别和规划好未来产品测试组所需要提前准备的测试实现技术。并亲自带着测试工程师提前进行测试技术储备。当然我们也常常亲自去实施一些测试活动：如设计测试工具的架构(主要考虑未来扩展性和更好满足测试需求)，然后交给专门的测试工具开发团队来实现;或亲自设计压力测试方案;亲自研究安全性测试策略和方案。推广方式，主要是亲自实践各种新测试技术后，再带着测试人员在实战中掌握相关的方法。我们大部分的测试架构师都是写过自动化测试脚本或程序的，只是现在的工作由于需要我们去思考太多的东西，所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师，由于负责多个产品，还要抽取产品间的共性测试技术，要建立起产品线的测试架构图，统一产品间的测试技术，统一测试方案的设计质量标准，需要具备更强的抽取共性的能力。同时，还需要能在短期内快速了解和识别影响产品成败的关键测试技术，因为并不是所有产品都是性能压力测试就是最重要的。例如：某产品线有9个产品，有的产品最需要保障的是可靠性(性能，可用性不是关键);有的产品最需要保障的却是可用性，而不是可靠性;有的产品最需要保障的是安全性，而不是性能;有的产品最需要保障的是可移植能力和可集成能力，而不是性能。那么相应的每个产品测试用例设计就会有所侧重，例如：对于重视可移植能力和可集成能力的产品，测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。因此，测试架构师必须具备的第一个能力就是：“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的，如果测试架构师识别错误了，那么有可能在需要重点保障的领域，测试技术和测试资源投入不足，导致最后产品的商业竞争力得不到支撑，得不到质量保障。例如：某产品对外宣传是业界可靠性最高的产品，可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中，对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中，该产品的可靠性得分却并不是第一，虽然性能是第一，但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。某美国公司的一款产品在传统行业中主要功能基本雷同，如何才能与类似产品拉开距离，突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长，因此为了缩短用户的操作时间，该公司决定在产品的可用性领域重点投入设计，核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中，构建了业界非常丰富的可用性测试用例，这些测试用例的场景超过了产品设计考虑的原有场景，并最终通过测试驱动设计，与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品，而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。所以，如果你的公司正准备招募测试架构师，请第一考评他的能力应该是他的商业理解力。具有该能力的测试工程师知道如何选择：