人人都是测试架构师

系统架构师是大家耳熟能详的一个高端职位，但似乎由来属于研发人员奋斗的目标。然随着软件测试行业的兴起，随着测试职位从业人员的增多，测试架构师，这个光辉的职位也应运而生。

测试架构师，向一座灯塔，指引着我们前进的方向，像隐形的翅膀给我们前进的动力。然而这条伟大的“修仙之路”，是近在咫尺or远在天涯？下边的一些感悟，似乎会给我们启示。

        起源：

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

核心能力：

        准确的商业理解力。 商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的，如果测试架构师识别错误了，那么有可能在需要重点保障的领域，测试技术和测试资源投入不足，导致最后产品的商业竞争力得不到支撑，得不到质量保障。例如：某产品对外宣传是业界可靠性最高的产品，可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中，对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中，该产品的可靠性得分却并不是第一，虽然性能是第一，但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。

        区分测试重点和测试难点因为资源和时间是有限的，而完美工作的追求是无限的。因此，我们如何在有限的资源和时间下，保障基本的质量目标，并尽可能提升质量目标。就需要在分清测试重点后，优先针对测试重点目标进行系统地测试技术研究，测试技术攻关，测试资源主要投入。对于非测试重点的测试难点部分就要降低优先级，放在最后考虑。测试架构师不是团队中专门解决测试难点的专家，而是识别测试重点，并支撑测试重点工作的专家。“区分测试重点和难点的能力”不是测试架构师独有，系统测试工程师和测试工程师一样可以具有。与第一篇“准确的商业理解力”一样，第二篇要做的是：做正确的事。

 

     测试架构师的“成魔之路”

      我始终觉得万丈高楼平地起，一切的看似遥远都始于并不遥远的每一小步。没有比脚更长的路，没有比人更高的山。在我们前进的征程中，要历经哪些风景呢？

  

    

We have a common dream——测试架构师，一个有点陌生却不太遥远的职位。敏锐的洞察力，观察力。良好的细心耐心责任心。有了这些内功。其实你已经离着测试架构师很近，很近。人人都可以成为测试架构师，只要你愿意。

       从今天起，让我们优化我们思维方式。

       从今天起，让我们加固我们的理论基础。

       从今天起，让我们看清明确的目标，fighting！

      其实成功离我们很近，属于熟悉的你，我，他……