如何修炼为测试架构师[2] 软件测试
我们大部分的测试架构师都是写过自动化测试脚本或程序的，只是现在的工作由于需要我们去思考太多的东西，所以没有一丁点精力来编码。特别是负责一个产品线的测试架构师，由于负责多个产品，还要抽取产品间的共性测试技术，要建立起产品线的测试架构图，统一产品间的测试技术，统一测试方案的设计质量标准，需要具备更强的抽取共性的能力。同时，还需要能在短期内快速了解和识别影响产品成败的关键测试技术，因为并不是所有产品都是性能压力测试就是最重要的。例如：某产品线有9个产品，有的产品最需要保障的是可靠性(性能，可用性不是关键);有的产品最需要保障的却是可用性，而不是可靠性;有的产品最需要保障的是安全性，而不是性能;有的产品最需要保障的是可移植能力和可集成能力，而不是性能。那么相应的每个产品测试用例设计就会有所侧重，例如：对于重视可移植能力和可集成能力的产品，测试架构师就应该帮助测试人员系统地做好这2个领域的测试用例。
因此，测试架构师必须具备的第一个能力就是：“准确的商业理解力。”商业成功的核心竞争力是什么?测试技术和测试资源是否能真正地保障或支撑商业成功的核心竞争力?这些都是测试架构师需要准确识别的，如果测试架构师识别错误了，那么有可能在需要重点保障的领域，测试技术和测试资源投入不足，导致最后产品的商业竞争力得不到支撑，得不到质量保障。例如：某产品对外宣传是业界可靠性最高的产品，可是测试人员在测试活动中惯性地把主要精力都花在了性能测试中，对各种异常的测试验证并不是业界最丰富的。结果在与业内其他产品比较的第三方测试报告中，该产品的可靠性得分却并不是第一，虽然性能是第一，但该产品在特定的重视可靠性的市场中基本失去了商业竞争力。
某美国公司的一款产品在传统行业中主要功能基本雷同，如何才能与类似产品拉开距离，突出竞争力。后发现产品的用户在使用产品时普通操作时间都较长，因此为了缩短用户的操作时间，该公司决定在产品的可用性领域重点投入设计，核心竞争力是解决用户的可用性问题。其测试团队把大部分的测试设计精力也放在了可用性的测试活动中，构建了业界非常丰富的可用性测试用例，这些测试用例的场景超过了产品设计考虑的原有场景，并最终通过测试驱动设计，与产品设计师一起不断改进产品的可用性。最后不但提供了业界可用性最强的产品，而且其可用性功能的稳定性质量也非常高。测试活动从效率和质量角度支撑了产品的商业成功。
文章来源于领测软件测试网 https://www.ltesting.net/