别人的测试微博，被我拔过来自己看的：
软实力（1 级为必备实力，2 级为上升的实力，3 级为加分的实力）
1级：有责任心、有条理性2级：善于沟通、协调能力、情绪控制；3级：主观能动性、分析能力、业务理解能力
首先针对级别的分层，先来聊聊一级分类，一级分类我觉得是每个测试工程师该具备的，或者说，是初级测试工程师就该具备的，相信大家常听过，招测试，就是要招有 “责任心” 和 “细心” 的人，这里我先把细心归类为条理性，我们先来讲讲有关 “责任心” 这东西；
责任心：
大家都有疑问，如何判断一个人有责任心，这里给大家一句话，责任的反面是风险，规避风险就是负责，而放任风险是不负责；举个经常例子：
员工同事，每天都是最后一个离开，离开时，通常会花 15 分钟检查好公司的门窗，把门锁上，老板每次说起时，都会夸这个员工有责任心；
这里的 “责任心” 就是，关闭者，规避了 “公司因未锁大门而发生偷窃的风险”，而不关闭者则放任 “公司因未锁大门而发生偷窃的风险” 发生；
如果你们对责任心有一定的认知之后，其实招聘要问的题目就很简单了，可以定几个方向，一是对风险的认知，二是对交叉事项的判断，三就是做事的方式是否有规划性；
面试可以这么问：
现实场景的提问：产品经理评审结束之后，已经进入开发阶段，在一次用例编写中，你发现了产品设计里面有个小问题，但是并不影响现有的功能，这时候你怎么做（交叉事项）？
变换场景的提问：除了你们部门的工作之外，你有觉得日常工作中，你的上一家公司有哪些安全的问题需要改善的吗？
接着我们再来说说条理性：
条理性
条理性指的是，有顺序、有条不紊，除了日常的工作习惯之外，通常还体现在测试用例的编写上（个人认为，测试用例是功能测试的核心），条理性强的人，能有效的保证测试用例的覆盖面；
说到这我们可以用设计方法里的的场景法来举例，场景法跟等价和边界还是有所不同的（后面可以给大家也说一下），通常用在业务流程的测试上，所以在利用场景法去做用例设计的时候，整个用例的覆盖程度取决于你备选流和异常流梳理，并且要注意每个关键节点的操作，假如你一开始并不能很好的分析出来，并且做组合，那就将会导致很多场景不会被你的用例覆盖到，所以说条理性很重要；
在这一块的面试考核上，我不知道其他面试官是否会纳入考核，我对条理性进行考核，通常是给个场景，做场景的用例分析，在分析及步骤的拆解中，就能比较容易的看出来了；
聊完一级分类，我们简单的说下二、三级分类，二级分类很简单，相信大家套一套基本了解是什么，除非是非常流程化的公司，否则绝对少不了沟通协调这两个方面，项目本身讲的就是一个团队协助，至于情绪控制这一点，大家可以去总结归纳下，产品经理与测试，开发与测试，三方之间在一些矛盾点上会有什么问题，这里就不细讲了；
三级分类无论在哪个岗位里，都是我比较喜欢的人的一些特性（包括开发），只是在测试的垂直领域里，我觉得具备这 3 个特点，已经可以算是比较优秀的测试工程师了；
硬实力（相对于软实力，我分为四级）
1级：功能测试、接口测试、测试基础理论；2级：数据库、抓包；3级：自动化测试、python、性能测试；4级：Linux、版本控制；
通常，对技能的考核，大小型公司都会包含 3 级以上；
以下对一些工具和内容做一些说明和解答：
缺陷管理：TAPD、Gitee、JIRA、禅道等等
说明：缺陷管理工具视团队而选择，基本都很成熟，基本都用过，个人喜好禅道多点
用例编写：XMIND、excel；
说明：这里强调一下1、现在越来越多的人喜欢使用 XMIND (或其他脑图工具)来编写测试用例，但很多人在执行时会犯下一个较为严重的错误，表面上像取代掉了excel了，担实际上编写的不是测试用例，而是“测试思路”，这种行为，会使您的测试覆盖率大大降低，所以要特别注意；2、用例还是推荐使用 excel格式，不过可以与 xmind相结合，首先定好格式，再通过 xmind编写，接着以表格形式导出，最后加上数字导入禅道即可；
用例编写方法
场景法：https://testerhome.com/topics/28051
接口测试：Postman、Jmeter、Swagger、Charles、Apizza
说明：1、现在我们用的是Apizza，一个加强版的Postman，除了前后端联调接口使用之外，做接口测试以及接口说明非常便利，而且还可以组合接口测试，唯一不足点就是付费，哈哈；2、可能有一部分的测试工程师，对接口测试可能不是很在意，觉得这是开发做的事情，其实不然，学会接口测试，能解决很多问题，后面有关在测试优化的环节，我会给大家一些方法和案例，教大家去规避测试组经常面临的一些典型的问题，其中就包括“冒泡通过率”低下的问题，这里给大家提一嘴，是不是有很多测试工程师，提BUG的时候不知道是前端的问题还是后端的问题，这里有个判断的标准：如果前端传输的数据没问题，后端返回的结果有问题，那么就是后端问题；如果前端传输的数据有问题，或者是后端返回给前端正确的数据，而前端展示的数据有问题，那么就是前端问题；而懂这一些内容，除了要学会监控接口数据和状态，你首先也要学会接口测试吧。
数据库类型：Mysql、Oracle、Redis（下面第三点划重点）
说明：1、测试工程师最好能掌握公司的主要用的数据库的操作，一般都是mysql或oracle，也有用nosql的，这个因公司而异；2、会的sql操作其实不用太复杂，简单的增、删、查、改外加联表查询；3、重点来了，敲黑板，有人经常问，测试工程师会数据库有什么用，我送给大家一句话：你会的越多，你能把控的东西就越多，你依赖别人就变少；你会的很少，那么意味着你依赖别人会很多，你所做的事情就会变得更被动。你们是否有一个场景，本来改个状态你们就可以重新走流程了，结果开发半天才给你处理，是否有一个场景，状态是开启的，实际数据状态是关闭的，导致发布到线上才有问题，所以你们细品，好好细品，我就不多说了，有空后面单独拎出来说；4、续上面3点，给大家一个告诫，测试过程中，不要过度地依赖数据库，因为某些BUG不是因数据引起，而是因流程引起，大多数开发工程师在测试时，为了方便也是通过修改数据来测试，所以当你的方法和他一致时，他们无法发现的问题，也意味着你也无法发现问题；5、造假数据、模拟数据的工具很多，利用sql制造假数据进行测试就是其中的一个方法；
抓包工具：Fiddler、Badboy
说明：1、现在抓包的工具大家用的比较少，不是因为没用，是因为现在请求大多数谷歌浏览器一个F12就可以搞定了，什么Network啊，Disablecache啊，Online模拟弱网环境啊，Lighthouse分析啊，功能都很强大了，所以在web测试里用的比较少；2、至于小程序和公众号，有对应的工具了，大家都知道；3、啥用的比较多，APP；
自动化类型：接口自动化、UI 自动化
说明：我相信很多测试管理者和执行者都会有这样的一个问题，UI/接口自动化该不该做，怎么做才是合理的，我跟很多个面试者和行业的测试管理者有过多次的沟通，我发现一个问题，大家对自动化，特别是UI自动化，在认知上会有一定的偏差，很多人都在尝试着做出初步的判断，觉得 UI自动化可以提高效率，然后就大手大脚地去做，并要求每个项目的自动化覆盖率达到多少，接着越执行越发现不对，工时比较长，于是又开始加班，最后累死累活得整出来，产品经理迭代了一个新的版本，UI发生了变动，然后脚本直接GG；想骂人的心都有了；那么，为什么会有以上的现象呢？其实：1、现在互联网讲的就是敏捷开发，快速迭代，而UI自动化测试是要确保流程稳定，UI上不要出现大的变动，否则XPATH节点要重新获取或者是新增修改删除；2、UI自动化测试，编写成本较高，维护成本往往随着版本的迭代次数增加而增加；3、UI自动化要明确，主要解决的是回归测试的问题，而不是取代功能测试；
较优方案：（敲黑板）结合以上三点，个人建议，UI 自动化测试，应侧重于对主要流程的测试，针对性的编写自动化脚本，确保主要的流程在任何功能的迭代下都能得到快速的回归测试，而且这种形式应该是投入最少收益最高的，即使 UI 发生了变化，从价值上来说，进行维护也是值得的；
python(编程能力及思想)： 待编写 ing......（）；
性能测试（教程不多说，网上一搜一大把）：
说明：问大家一个问题，大家在什么时候接触性能测试比较多，答曰：面试的时候；我还听过一个调侃，国内的大部分公司都高估了自己的用户量（笑）；但实际上也不一定要用到性能测试才会在面试中出现，大多数都是为了观察面试者是否具备相关知识和经验，以及掌握的测试的知识面如何，好了，下面进入正题；其实绝大部分公司有这种情况很正常，据我观察，大部分的性能测试需求都是来自技术端，技术端开发出了一个系统/功能，然后给了测试端，然后说我要达到某一指标，你们帮我测试验证，接着测试人员利用测试工具开测，所以，一旦技术端没有需求就等于没有性能测试（是不是冥冥之中感受到了什么），大多数情况下，测试端仍然过于依赖技术端的驱动。要打破这个僵局，还需测试端转换下思路，当有一个需求进入分析阶段时，或者进入测试阶段时，测试人员应该思考，该需求是否需是否需要性能测试，测什么，怎么测（3H/5H大法），从而提供该系统/功能性能测试方案。那测试人员怎么进行性能测试，我觉得分2大块：
linux： 待编写 ing......（）；
版本控制： 待编写 ing......（）；
工作中的规范化文档：
测试工程师 BUG 编写规范和要点（自家公司的，只供参考）
https://docs.qq.com/doc/DUGdPaE9yT1lWZFVU
测试工程师 BUG 评级规范和要点（自家公司的，只供参考）
https://docs.qq.com/sheet/DUElZWnpQUUxBcHhm
测试流程的疑难杂症：
典型问题 1：冒泡测试通过率低下的问题
解决方案 1（常规操作）：建立规范化的测试流程，在开发转交给测试团队时，可以审查功能是否符合要求（验收流程），如果没有通过，则驳回给开发团队，由修改完成再继续提交；
解决方案 2（进阶操作）：提前向开发成员提供冒泡测试用例，并在开发成员完成冒泡测试后将其转交给测试；
解决方案 3（砖石操作）：建立产品演示的验收流程。当开发成员完成开发阶段后，由开发主管（或开发主要负责人）发起，同项目组各成员一起进行产品演示，由测试人员现场验收产品，若冒泡测试无法走通，或者出现 1 级 BUG，记录并在当天进行修正，如果问题比较严重，则由各组的负责人一同拍板，是否顺延项目周期来处理问题，顺延的后果，由开发组承担；
先分析下冒泡测试通过率低的问题，找出问题的本质，其实该问题不是来自测试端，而是来自开发端，这样的话，你会发现，单纯优化测试的流程，通常指标不治本。也许有人会说，这是开发人员要做的事情，关测试什么事，出的问题也是开发的问题，你们可以往下拉去看测试工程师的第六段位的描述，里面就有说到，“走向前端做缺陷预防” 并 “固化测试流程”，你们应该学会打破你们的圈子思维，这样才能从本质上去解决你们遇到的难题，所以我们先来简单看下技术侧到底有哪些现象：
1、有部分后端工程师会进行测试接口，但是比较少去核对数据准确性，更少的去做组合测试（冒泡一定是组合测试）；
2、有部分前端工程师大多都是模拟数据（有些公司不提前出接口文档的，是在联调阶段直接对接），在真实的接口输出之后，直接验证数据类型和接口是否有问题就结束了；
3、有部分的开发工程师，会因为项目周期较短，将部分的功能遗留到测试阶段进行开发（特别需要注意的一个点）；
4、有部分的后端工程师，不做接口测试；
5、有部分的开发工程师，认为应该有测试工程师去暴露问题；
那么，怎样让他们按照我们的要求，有效地进行冒泡测试呢？很简单，找一个动因，化被动为主动，让开发人员自动去暴露问题，从而避免出现问题，当然，绩效也是一种手段，但是绩效相对是一个硬性的手段，而上面提到的第三种方法，是我个人觉得非常好的一个措施，而且也得到了有效的验证，自实行这一过程以来，我们冒泡的通过率是 100% 的，而且 BUG 也呈现出下降的趋势，至于为何效果比较明显，其实也很简单，应该没有一个开发工程师，愿意在大庭广众之下频繁的暴露自己的 BUG，从而让他们懂得去规避这样的问题（风险）；
PS：可能有些开发人员，会因此感到不爽，对这种行为感到厌恶，但别忘了，开发本来就应该为其代码质量负责；另外，有些 BUG 的问题是因为历史原因所导致的，例如耦合度较高，改一发动全身，这些并不在此次说的范围内，这个是技术问题；
