让我们一起看下测试武功论就会明白了。（测试武功论这个说法是我自己的理解，因为我个人比较喜欢看武侠小说，所以拿武功来类比了一下软件测试。）
我认为软件测试的武功分内功和招式，像功能测试、性能测试、安全性测试、兼容性测试等等，是一种思想理念的体现，一种方法论，所以是内功心法。
其中功能测试又是一门基本功法，是一切的基础。像前面提到的LR、Jmeter、postman、selenium、appium、Robtframework、Cucumber等等都是刀枪剑戟等兵器以及配套的招式。
有人会问，那手工测试算什么？我的回答是，手工测试是拳脚招式，兵器好选、招式好练，但是内功积累就不容易了。
仅仅会招式，有兵器不行，这是花架子，遇到懂行的一碰就倒。这也是为什么学会python编程，经过测试工具或者测试开发培训也不可能轻易从0基础达到高水平的原因。
但仅仅是内功深厚也是不够的，因为你与人比武时，总不能遇到谁都不过招，上来就比拼内力吧？
这就从侧面回答了为什么内功也就是功能测试达到登峰造极，也要最好能用一些工具或者能懂自动化、有编程能力；为什么没有内功，即便有神兵利器也发挥不出威力，也就是自动化测试需要先做好测试再来谈自动化，测试开发也一样。
综上，如果想要达到武功天下：
第一，成为一代宗师，最好内外兼修，不仅内力深厚，而且招式精妙、兵器趁手。
有了上面软件测试技术和测试武功论的理解，我们再回过头看之前遗留的那个问题。
我帮大家回忆一下啊，问题是“学会了python、学会了自动化测试框架的使用，是不是就可以应聘高级软件测试工程师了？”
我回答是不一定，为什么就不用再多说了吧。我们再看最初始的问题，怎么界定初、中、高和专家级软件测试工程师呢？
难道招聘要求有误吗？并不是的，因为招聘方是通过设定的年限标准，测试工具、编程能力的技能标准来筛选简历。
其实也好理解，年限界定是为了衡量这个人内功的深厚程度，毕竟如果正常发展（修炼），内力是随着时间的增长而增长的；
技能的界定是为了衡量这个人招式熟练程度以及会使用的兵器，毕竟在招聘方的角度来看，招式越娴熟，兵器会得越多当然越好。
之所以有时候觉得经验、能力和工作年限不匹配，主要原因还是我们自己把功能测试做成了功能点的测试，把软件系统的测试做成了软件的测试。
举个例子，接口自动化测试的应聘者在面试的时候被问到：“接口测试脚本中要做哪些校验？”一般的回答：根据入参得到的回参来判断接口是否符合预期。
稍微全面些的回答：不仅要校验回参是否符合预期，还要校验数据库中落库的数据是否符合预期。但是这样就够了吗？
还不够，因为曾经就看到过这样的事故案例：
接口测试只做了回参和落库的校验，漏掉了对于调用链上关联系统MQ消息的幂等校验，结果因为订单退款流程涉及的一系列系统幂等没有做好，一个订单能够多次退款，也就是每单退款公司都多给客户返还了好几笔钱，造成了相当严重的资损。
虽然责任不全在测试，但是实际上如果测试人员多思考系统结构、上下游系统关联关系，多思考接口调用链路、数据链路，是完全有可能在线下测试的时候就发现这个bug的。
所以仅仅是掌握了一些测试工具的使用、仅仅会做些自动化脚本的开发、仅仅会做软件的测试而不懂软件系统的测试是完全不够的。
讲到这，我想特意讲一下测试架构师这个传说中的职位。
为什么说是传说，因为现在很少有人讲如何进阶到这样的段位，通过招聘信息看到的也多数都是类似于测试开发、自动化测试这样的要求，顶多是加一条具备测试框架开发能力。
所以大多数从业者对这个职位的内涵也是相对模糊的，好像编码能力强的测试工程师就是测试架构师。这样的理解是不准确的，就如同编码能力强的开发工程师并不一定是系统架构师一样。
因为系统架构师要做软件层面的模块拆分、系统分层、架构设计、框架选型、接口定义、协议规范、库表规划等等，还要做硬件层面的网络拓扑结构设计、安全防护节点设置及设备选型、硬件设备容量规划等等。
测试架构师要做的包括系统结构和调用关系梳理、业务场景所涉及的接口链路和数据流的分析、测试内容和范围的规划、测试策略和方法的选取、分层测试的维度或边界的定义、测试覆盖的评估、测试质量和有效性的评价等等。
测试架构师要有一个清晰的认识，就是测试是无法穷尽的，无法做到100%覆盖；也不是所有手段、技术都上了就一定是好的测试。
测试架构师所追求的是极限的、刚刚好的测试，是一个时间、成本、质量动态最平衡的点。
所以一定要结合产品的质量目标、时间周期、资源成本等等来考虑测试方法、手段。测试架构师不是说代码能力要有多强，而是要能针对被测物构建全面、完整的测试指标体系，所有的测试方法、手段都了然于胸，针对不同目标和需要，划定最科学、合适的测试范围，采用最合理的测试手段，达到测试结果能清晰、准确的评价产品质量。
当然我也不是说编码能力无用论啊，既懂测试又会编码的人是最好的。我只是说不能过分强调代码能力，毕竟测试架构师的基本功还得是测试。
质量保障与软件测试的关系
说了这么多的软件测试，我们再来聊聊现在我们常谈论的质量保障，也就是QA
（QualityAssurance）。
大家可以在网上搜索QA，也可以阅读ISO9000、CMMI的过程管理标准，都有详细地介绍QA的定义、过程管理规范、职责和组织结构等等。
所以以上内容就不在本文中赘述了，这里要和大家聊的是质量保障与软件测试的关系。
在互联网公司，大家都习惯把测试人员叫QA。
但其实测试只是质量保障中的一个环节，质量保障是随着产品的全生命周期而一直延续的一个过程，测试只是在产品开发出来后进行质量验证的一个步骤。
只不过这个步骤基本上已经是质量保障的最后一道检查关，因此显得尤为重要。
质量保障其实是整个产研、甚至是整个公司都要投入去做的一件事。
如果没有运营、产品、研发、测试和运维的通力合作，仅靠测试一个部门想把质量保障做好还是有一定难度的。
因此，有些公司寄希望于通过建立一个测试部门，招些软件测试工程师进行软件测试工作，就能彻底解决质量问题，这个期望是过高了。
这种举措能够达到在短时间内提升产品质量的目的，但是如果不从工作组织模式、职责分工上做改变，所有人都还认为质量保障都是测试的事，质量问题都是测试的问题，那这个公司的产品质量将很难有质的改变；
或者能有改变，但也要花费巨大的成本，测试同学也将苦不堪言。那除了进行运行时的软件测试以外，还有什么途径可以保障质量呢？