为啥要写这篇文章呢？因为我之前工作的半年就是就是作为一名测试的。国内某不知名国企的一名测试。但是经过自己的不懈斗争我又成为了一名dev。

首先我们来看一下QA的定义哈，有两层含义，一是quality analyst，二是他的主要职责是quality assurance（质量保障）。主要职责是： A QA engineer focuses on improving software development processes and preventing defects in production. 主要的职责使是加粗和斜体部分。

具体任务：

1.检查产品是否符合要求，这里的主要工作就是验收产品，聚焦在功能的实现上自己用户的交互，不会关注太多的细节上。

2.评估风险，这个一般发生在功能开始研发的前期，测试人员一般都会比较了解业务，能够盘点出本次修改的影响范围。如果影响的范围过大的话，可能需要将功能进行拆解划分更为独立的功能开发，这样就可以尽可能降低功能上线之后的风险。

3.提高产品质量的策划思路，

4.规划测试，按照测试金字塔划定项目中测试的内容占比，

5.分析测试结果，根据我现在经验，需要分析的测试一般是journey test（又称为integration test）和load test的结果。前者主要注重的是从用户角度出发模拟用户的操作行为，这里的结果主要是接口的contractor发生了变化导致前端没有适配而发生的问题，这里可以比较准确的定位到是哪个接口出现了问题。后者主要是分析api调用链路上的接口反应时间，也就是接口的性能。之前呆的公司中有有过一个叫做Xsea工具，该工具可以具体分析到每一行代码的耗时，这样如果有问题的代码块就会在结果中一目了然。

QA的主要承担的角色：1.测试分析师从事需求的静态测试，并检查它们的完整性和一致性（通俗的来说就是手工按照测试样例测试或者者编写对应的测试脚本）。2.测试设计师根据需求创建一组测试，并计划测试所需的配置（根据需求设计测试场景，可能不需要本人来测试）。3.Test Executor执行预先计划的测试，描述并记录发现的错误，以及复制(或修复)这些错误的步骤。4.测试经理计划并监控与测试相关的工作，如遵守截止日期、遵循时间表、控制测试需求、为团队成员设置任务，以及与涉众沟通（写得很清楚了吧，就是站的角度更高了吧）。more details

然后，我来说说我自己的测试经历吧。

大家都说测试是什么呢，最懂业务的技术。所以一开始呢就是了解各种业务，目前中国的互联网呢就是用户量大，业务复杂，系统庞大。业务驱动测试吧，为什么这么说呢，只会考虑业务，因为测试是产品上线前的最后一到关卡，只要业务流通了。那么你这个功能就算是完成了，主要以业务为导向的各个场景的测试，这样的测试模式可以更好的了解产品对于一个刚开始的新人来说。

工作模式是怎么样的呢，每两个礼拜一次迭代，一次上线。提前了解需求，然后串讲，反串讲，编写测试样例，与开发和需求一起过样例，开发完成功能，jenkins测试环境部署，uat环境测试，预生产环境测试，生产测试。

痛点有什么呢，

1.代码质量编写的水平不高，导致问题的bug需要测试走查代码才能检查出问题，这些问题可能会出现在接口的rps时间较长，中间件被资源锁死，队列消息丢失等等。原因是没有单元测试去保护代码的主要逻辑，大家也不重视单元测试的重要性。

2.未能够有自动化的工具，或者流水线来构建新的版本和测试老的版本代码，经过开发的简单测试就推上codebase。那么这会导致什么问题呢，测试人员在测试新功能的同时还要回归大量的已有功能，这无非是增加了一系列的测试成本和有可能导致系统上线的不稳定。这要主要原因就是缺乏有效的基础设施，大量的重复工作需要实施。

3.测试人员没有编码的意识的误区，也让大家对测试人员的工作内容产生了误解。觉得测试就是在产品上点来点去。做一些很枯燥的工作，实则不然，我在一本书上《软件测试的艺术》看到过，测试其实是一件非常耗费脑细胞和想象力的一分工作，为什么这么说呢？一位好的测试，远比多位开发重要。因为在工作中，测试需要设计好各种level的测试在整体项目中的占比，然后在选出合适的实践方式。搭好架子后，开发就可以自由的玩耍了。有了这些基础设施的保障，代码的健壮性又有了一层附加的保护。

4.测试人员和开发人员总是站在对立面，在很多公司里，这两个角色总是争锋相对的。原因是什么呢，开发觉得我自己开发的功能没有问题，为什么要被你测出问题呢。而测试觉得，你这里不符合需求或者实现出来的方式不对就是有问题。尤其还有一点测试出来的缺陷很有可能和他们的绩效挂钩。但是在一些有好的理念的公司中，这两者的关系是相辅相成的，你来设计出优秀的实践，我来帮你想象可能漏掉的场景（edge case）。这样的思想一旦建立起来之后，团队的工作效率就会发生质变，而不是想着出了问题相互甩锅。

现在的dev工作让我对QA的工作有一些其他的理解

1.QA不是单纯的测试人员，QA应该是质量分析师，在业务的基础上合理的分配各种测试的比重，以此来保证系统的稳定性。所以这样的就对测试有了更高的要求，需要使用多种类型的测试框架和技术栈。因此测试人员在一个团队中的占比不需要很大，少而精。

2.Dev也有测试责任，dev除了日常的开发，还有一些测试编写的编码工作。类似于一些集成测试，用于测试接口的稳定性。ui测试，主要集中在前端开发者上，模拟用户的主要操作流程。一旦这样的代码测试样例有一定的规模之后，对于系统来说，这就是一本活的测试样例。

3.两个角色是唇齿相依的关系。在tw我看到一个团队中的两个角色不再是矛与盾的关系，而是相辅相成的关系。都是为了feature的稳定上线而努力的在一块工作，QA帮助dev更好的理解开发功能的场景，dev帮助QA解决一些技术上的难点。

以上只代表个人观点，如有不正确，请大佬指教。