测试架构需要具备哪些能力

转载：https://www.cnblogs.com/imyalost/p/16834322.html

这篇文章是软件工程系列知识总结的第五篇，同样我会以自己的理解来阐述软件工程中关于架构设计相关的知识。

相比于我们常见的研发架构师，测试架构师是近几年才出现的一个岗位，当然岗位title其实没有特殊的含义，在我看来测试架构师其实更像对某一类人的抽象称呼和对其复合能力的期待及认可。

在聊这篇文章的主题之前，先来看这样一个问题：为什么软件项目需要架构设计？

 

为什么软件项目需要架构设计？

如果是一个简单的软件系统，没有太多用户使用，也没有较为复杂的业务逻辑，那架构设计几乎是不需要的。为什么呢？

一般来说用户少意味着操作场景较少，没有高并发场景，也没有复杂的业务逻辑，只要功能正确实现可以正常使用即可。但在我们实际的工作场景中，我们面对的工作对象，常常具备这两个特点：

• 需求不确定性较高；
• 系统使用的技术较为复杂；

需求的复杂和不确定性大家都很熟悉，特别是做互联网To C业务的企业，需求的复杂和不确定性就更高。而技术的复杂性，主要来源于下面几点因素：

1. 需求让技术变复杂：为了满足需求的复杂和不确定性，软件系统背后的技术应用就会很复杂；
2. 人员让技术变复杂：团队里的同学来自不同背景不同企业，技术栈和工作经验各不相同，因此技术也会变复杂；
3. 技术本身就很复杂：不同的编程语言、框架、技术组件、数据库、大数据、算法、ARVR等本身就是复杂的技术；
4. 让软件稳定运行很复杂：线上服务要稳定运行会面临各种不确定性，比如峰值流量冲击、云服务不可用、网络问题；

因为技术的复杂性，会导致软件研发的过程变得很复杂，而软件工程本身就是为了摆脱软件质量危机，以软件开发为核心，对开发过程组织+对方法的运用+对工具的使用，

来让软件系统达到稳定，而架构设计正好可以解决这些复杂性带来的问题。架构设计的有点如下：

1. 降低需求变更带来的研发成本；
2. 可以更好的组织人员高效协作；
3. 架构设计本身就是对各种复杂技术的合理运用和组合；
4. 架构设计可以保障线上服务更稳定的为业务目标达成提供支撑；

 

测试架构师需要解决什么问题？

看完了上面关于架构设计的优势，其实可以快速推导出测试架构要做的事情。

研发角度的架构设计要做的是：用最小人力成本满足需求开发和响应变更，用最合适的技术架构来保障软件的平稳运行。

简单来说就是：组织人力高效协作+合理设计技术框架+保障线上服务稳定运行。

从测试的角度出发，测试的本质是质量保障和推动研发效能提升。那么测试架构要做的事情是：

1. 质量把控：从需求质量到研发过程质量以及线上质量的把控；
2. 技术设计：针对不同项目，选择合适的技术栈来快速解决问题；
3. 组织协调：组织测试团队的同学高效完成软件产品的质量保障工作；

 

测试架构师需要具备哪些能力？

大多数企业的组织架构是横向的，而测试团队在其中的定位既可能是横向的大团队，也可以是纵向跟着项目走的小团队。而测试架构师的角色，在我看来其实需要具备两点特质：

1. 纵向的业务了解和技术深耕；
2. 横向的拉通对齐和组织协调；

结合测试架构要做的事情以及在团队中的角色定位，我认为测试架构应该具备如下几点基础能力：

 

测试工程师如何培养架构能力？

与其说测试架构师是一个岗位和title，不如说他是具备某些复合能力的可以解决问题的人。

当然并不是说所有测试同学都需要变成测试架构师，这种测试架构能力在日常工作和学习中是可以培养的。

对于普通的测试工程师，想要培养测试架构能力，我建议可以先从如下几点入手：

1. 分析需求：在日常工作中仔细分析需求，做好需求评审和风险评估；
2. 技术选型：无论是自动化或者性能或者单元测试，尽可能选择成熟的技术方案并对其深入了解；
3. 逐步迭代：解决问题的过程中，避免追求完美的方案，而是先解决眼下问题，再逐步深入分析和优化；
4. 不断优化：解决问题后要不断验证其效果和效率，评估能否满足未来的变化，能否持续保障软件高质量运行；

你看，上面四点是不是和产品设计中提倡的mvp方案有类似的思路。

我在前面的文章中也提到过一个质量保障体系的总结，即：风险可识别+问题可追踪+结果可验证+数据可量化。

按照上面的几点坚持去做，迟早我们都会具备架构能力。