QA测试人员面试或述职的时候该怎么讲解自己的项目

        因为大部分QA的工作是跟进业务测试，所以在向面试官或述职评委等非项目相关人员讲解测试工作时总会有如下困惑或误区：

1. 业务逻辑不知道该介绍到什么程度

“说多了对方也不懂”，“不属于测试工作范畴对方可能不感兴趣”。

2. 介绍测试思路时，感觉说来说去还是业务逻辑

为啥这么测？因为产品想要这个，需求就是这么写的

3. 追求技术含量，是不是自动化或接口测试才更高级？

感觉业务测试没啥说的；抱着“自动化”等技术工作不放。

4. 测试工作大同小异，也说不出来什么特别的

        造成以上几点的主要原因是对测试工作认识不够，以及QA在技术团队中的“弱势”地位导致的代码崇拜。

        总结起来，业务测试工作都可以套用到上面框架示意图里。测试平时的工作就是消化和理解业务逻辑（需重点关注数据逻辑），做测试数据准备、构造测试场景，操作执行，验收执行结果，并用技术或流程手段解决中间测试阶段的问题或效率瓶颈。

        那么是不是说既然流程类似，介绍起来也就类似呢？并不是。

        首先，不同的业务有不同的业务逻辑，能深入浅出的把业务从产品定位、面向的用户、业务逻辑、自己负责测试的部分在整个产品中处在什么位置这些讲清楚，就充分的考验讲述者的业务能力。这也就回答了上面提到的第一个困惑，介绍业务的时候该介绍的什么程度：对于不了解你业务的面试官，通俗易懂、逻辑清楚是关键；而对于内部述职的评审，产品在公司的定位及核心产出则比较重要，并可以作为后面介绍测试工作的铺垫。

        其次，业务特性和产品形态不同，其数据诉求也不一样，就会有不同的测试数据及测试场景构造，或者有不同的侧重点，例如视频等多媒体要关心流畅度、直播要关注实时性、社群产品要注重不同的用户身份、运营项目服务性能是考验等等。在介绍这一部分的时候，就体现了测试设计思路，围绕着测试工作讲，就不会浮在业务逻辑上绕来绕去。

        以上针对业务的测试设计思路是根本，而为了施行这个测试设计，才会有了接口测试、前端测试等不同的测试方式，以及针对不同的测试方式所采用的各类测试工具，如自动化等。

        概括起来，讲解的思路就是

        1. 把业务介绍清楚（问题：什么样的业务，要测试哪些内容）

        2. 针对这个业务的测试设计是什么（解决思路：要什么样的测试构造、如何执行和验收）

        3. 跟测试设计配套的手段是什么（具体方案：用什么样的技术或流程手段解决什么样的效率问题）

        有了上面这些内容，即不用担心没有内容可说，也不用千篇一律的去讲需求评审、用例编写、测试执行、接口的异常参数校验等完全体现不出来工作差异的内容。哪怕是自动化，尽管是代码工作，但是从框架、工具的角度都是十多年的成熟技术，真的没必要一头扎进去讲，而是要围绕测试工作的核心诉求，介绍为什么要做自动化，解决什么问题，针对这个自动化主要需要处理什么技术难点等，这样才不会本末倒置。

        另外，从同事那里学到的一个测试工作深入度的三个层次：Test测试执行、QC质量控制、QA质量保证。第一层Test只做需求验收，达到质量标准后上线；第二层QC则能通过对需求和技术的深入了解、多层次多角度的质量把控；第三层QA则能通过制定项目全流程的准入标准，监督项目执行，必要时通过技术手段保证标准的严格执行，以保证最后的项目输出质量。

        归根结底还是要有不同的测试层次和测试理解，讲解出来的测试项目也会有不同的深度。共勉～