本文目录
软件测试工程师如何掌握技术架构
我的理解你是想说测试技术架构，不是开发架构。因为两个在深度广度上有着很大的区别，而全掌握开发技术架构的测试不是一个好开发。
广义的测试技术架构包括自动化和手工测试设计等，但现在处处都要代码能力的环境下，我们提到技术架构是指自动化的架构。
技术架构很难快速掌握，这就象工程师为什么分初、中、高级，然后才架构师一样。只有不断的练习，自己发现其中的问题，有一定的积累，才敢说掌握。当然，其中还是有一些窍门。
废话有点多，转入正题。
1. 有一定的测试理论的实践的功底。这是必须的，也是测试和开发最大的区别，也正因此，你才能理解并且和设计出符合测试人员使用的架构。
2. 学习一门语言，目前java和python都是可以的。python入手更容易一些。java学习周期相对长一些。
3. 下载一个开源框架，并尝试写一两个脚本。这个和#2可以同时学习。
4. 用开源框架设计100条以上的脚本。
为什么100条？这只是一个概数，要求的是你必须设计出对应的场景，并把它自动化。事实上，只尝试性的写几个脚本，和只写个hello world没有任何区别。
这一步也是提升测试架构能力的核心。其目的有：真正理解框架中每个模块的关系；每个方法应该如何应用。
5. 拿两个框架来做对比。比如是ui自动化和api自动化，或是两种同类型的框架。
其目的是了解不同框架中设计上有什么不足的地方。一个好的框架，应该对对脚本设计、脚本管理（维护）、脚本执行、调优几个方面。你可以从这几个方面来做比较。
6. 尝试自己设计一个框架或是一个平台。
这6步都做到的话，你就掌握的不只是自动化框架设计能力，而是基本上整个测试的技术架构。
最后想说的是：不同开发架构，对测试技术的要求也相差很大，微服务、大数据、安全。所谓测试技术架构往往是针对某一种开发技术。
自动化测试团队如何去考核
追其根本，首先我们清楚测试开发角色职责是围绕产品质量，提升测试效率，通过不断的技术创新、应用，不断提高测试整体流程能力（单位时间能够提供多少服务）。这背后也有一个问题，效率提升的目的又是什么？假如一个测试团队的人数相对固定、测试时间充足，他提升效率的目的又是什么呢？从这种角度来思考，个人认为测试效率提升的根本意义在于：
- 做更多的有价值的测试（更深入的需求分析、测试设计或者对测试右移的投入）
- 实现真正的缩减成本（减少或抽调人力投入）
- 适应开发模式的转变，比如类敏捷、devops模式下的频繁迭代/持续部署。
过去，我们一直尝试通过持续性的跟踪自动化测试框架、工具的使用情况（发现缺陷数量、使用次数、实际节省（盈余）时间等），来感知其发挥的价值（效率提升、质量保障）。但没有较好的效果，总结了几点：
- 缺乏平台化的统计、反馈媒介，相关数据过多的依赖测试人员的主动反馈，所以效果并不好。
- 仅通过缺陷发现数量、实际节省时间并不能很好的体现其价值（没有体现出上述的所提的效率提升背后的意义）
因此仅通过“发现缺陷数量“、“实际节省（盈余）时间“ 并不是可靠的度量方式。
以自动化测试解决方案团队为例，着重考虑自动化覆盖率、效率提升率、效率转换三个指标，按季度或版本为周期，进行持续性的评估，以便感知落地后的测试技术服务是否持续性的发挥着原定作用。
- 自动化覆盖率 = 当前版本该项目自动化测试点/当前版本该项目所有测试点。
- 效率提升率 = 1- 单轮次自动化执行时间/单轮次手动执行时间（针对被自动化测试所覆盖的用例而言）
- 标准盈余时间 = （单轮次手工执行时间-单轮次自动化执行时间）*自动化执行次数
- 实际盈余时间 = 结合标准盈余时间估算
- 投资回报率(ROI) = （标准盈余时间/自动化测试开发投入时间）*100%
- 效率转换 = 对实际盈余时间的分配及相关产出
对应各项指标结合实际情况（如，原则上预期投入产出比小于150%，不开展或者降低优先级），进行整体评估，同时设置S/A/B/C考核级别。这样不仅可以评估当季度或版本的开展情况，也可以通过长期的考核情况（价值曲线），来评估整体产出价值。
随着测试平台（用例中心、自动化测试平台）的建设，上述统计项获取成本已远低于之前的人工统计。
最后之所以做价值度量，不仅是为了体现自身价值，更是为优化价值、提升价值提供参考方向。
更多内容，可以浏览我之前写过的一篇文章《如何度量测试开发角色的产出价值》https://www.toutiao.com/i6648483835245756936/
为什么测试工程师女生偏多
1.男性普遍更愿意做研发，不是测试岗位不想招男性
2.计算机专业的女性多数对研发不擅长，但就业领域，测试岗位对女性写代码没什么要求，这样女性就更多的前往测试岗位
3.测试岗位的事情比较琐碎和枯燥的，女性在这方面也是有相对优势，能沉得下心。
