前言
武让是极狐 (GitLab) 公司 高级解决方案架构师，具备 10 年产业互联网从业教训。先后在守业公司和上市公司负责架构师和技术总监。阿里云 MVP、AWS SAP、CSM、TOGAF 认证架构师。近几年致力于企业数字化转型。现负责极狐 (GitLab) 公司解决方案的设计与推广。
本文基于武让在「声网开发者守业讲堂 • 第三期丨守业初期如何保障产品质量 」流动中分享内容二次整顿。关注公众号「 声网开发者」，回复关键词「JT0611」即可下载流动相干 PPT 材料。
01 实践篇
1、水星打算与软件测试
说到软件测试，据说最早有记录的软件测试是在人类的第一次载人航天打算，也就是水星打算中提到的，我不确定是不是最早，然而我的确查到是有一些记录，因为载人航天波及生命安全以及政治因素（1958 年美国跟前苏联的热战太空比赛），所以美国非常重视，就引入了软件测试，所以也能够看到为什么当初十分多的企业不太重视测试，其实就是因为产品不波及生命安全或者政治，大家没有碰到这些所谓的红线，也就对这部分没有那么器重了。
2、软件测试倒退历程
图 1 展现了软件测试的发展史，初步能够分成五个阶段，最早从 20 世纪 50 年代开始，此时没有测试一说，更多的是叫作调试。到 1957 年，Charles baker 才提出了测试的概念。
所谓的测试和调试的区别是，调试的目标是使程序合乎开发人员的预期，而对于测试来说，就要确认程序是不是合乎产品性能需要的预期。第三阶段就是不光要做测试，还要对程序进行一些探索性的测试，确认有没有做不该做的事件。第四个阶段就是测试人员都比拟相熟的 V &V 实践，对应软件测试中的 V 模型，这个模型的话目前在整个工业畛域中还在宽泛地利用，它第一次提出软件测试要被利用在整个软件的生命周期当中。我认为截止到明天，整个软件测试还在第五个阶段，就是要去做一些探索性的测试、麻利测试，以及 TDD、BDD 这些新的概念的衰亡带来的所谓自动化工具继续集成这类技术的利用。所以在整个第五阶段，咱们的目标是在代码级别避免缺点，而不仅仅是局限测试。这五个阶段不是齐全独立的，更多的是继承。
■图 1
3、软件测试分类
图 2 左上角是传统的软件分类，做测试的人员可能比拟相熟，它其实就是依照不同的维度对软件测试的办法进行了分类。然而这种所谓的传统分类容易呈现概念的穿插，存在边界含糊的问题，这导致这一套分类实践会比较复杂。
■图 2
对于初创型企业来说，如果企业外部有这么一套简单的、含糊的概念体系存在，则不利于流传，也不易晋升认知上的对立，或者说间接影响到了效率。为了解决这样的问题，就有了右上角的测试金字塔，这个金字塔把各种模糊不清的测试方法全副都进行了整合，造成了三段式或者多段式的，从底往上、从大变小的过程。这里的分层包含单元层、服务层和 UI 层，越往下，独立性越高；越往上，集成性越高。所以应该在上层写更多的测试用例，在下层做更少的测试，这才是一个衰弱的测试状态。
独一无二，Google 在《Google 软件测试之道》中也对测试进行了从新的分类，它的分类办法是依照大、中、小型测试来做划分，这个划分从某种意义上来说，跟测试金字塔是相匹配的，小型测试对应金字塔测试中的单元层，就是说能够测一些独自的模块，在小型测试中能够解决独立的函数。同时它也给出了一个占比，Google 认为所谓的小型测试应该占七成，中型测试占两成（模块之间的集成性测试占两成），最初全面的系统性测试只需占 10%。图 2 下方是 Google 给出的分类。对于初创型企业来说，倡议抉择测试金字塔模型，分层的层数和名称企业能够自定义，然而对于这样的模型，首先要对立概念，否则如果测试人员和开发人员的语言不对立，那么在发展工作的时候会遇到很多的问题。
4、自动化测试工具
自动化测试随同着麻利开发、麻利测试等概念失去了蓬勃的倒退，通过图 3 大家能够看到支流的自动化测试工具，晚期次要是线性测试，就是通过录制的形式生成脚本、宏，这种是比拟常见的模式，前期测试工具有了更多的类型变动，比方反对结构化的、数据驱动的以及关键字驱动的测试。模式上来说次要有两种，一种是基于 UI，一种是基于 API，基于 API 的模式就是调用 API，更多的是在接口层面进行操作。基于 UI 的模式就是模仿用户的操作，比方在界面上挪动鼠标、点击鼠标、按键等。
■图 3
5、自动化测试发展条件
自动化测试的劣势我认为次要有两点，第一点就是它能够代替一些反复但必要的测试工作，解决重复劳动问题。第二点也很重要，因为重复性工作容易引入人为的过错，此时就应该通过工具来辅助。尽管自动化测试劣势显著，然而它的劣势同样不可小觑，很多人认为自动化测试是万金油，在任何状况下都能够发展，其实并不是，它的劣势也蕴含两点，第一点就是老本较高，尤其是短期的开销比拟大，如果要进行自动化测试，须要人才培养或者人才招聘、流程建设以及脚本编写和保护，这些都须要一个老本比拟大的开销。此外，后面说了自动化测试的劣势是能够代替做重复性劳动，绝对应的劣势就是不容易发现新的 bug，因为它只能做反复的工作，想让它发现新的 bug 是比拟难的，尽管说当初有含糊测试、混沌工程，但它始终不像人一样善于或者可能发现新的 bug。
那在什么样的状况下，初创企业能够发展自动化测试，次要有三点：第一点就是产品周期比拟长，这里指的是稳固的产品，如果是 demo 型产品，就没有必要进行自动化了。第二点是频繁的迭代，这一点是它的价值所在。第三点是产品绝对稳固，这一点其实从某种意义上来说与第一点是捆绑的，因为产品稳固，能力有稳固的收益，才能够做投入。
所以对于自动化测试来说，更多的是与传统的手动测试的互补，而不是代替。互补是两方面的，第一个方面就是如果不具备自动化测试所需的条件，就能够做手动测试；另一方面就是针对自动化测试不容易发现新 bug 的特点，须要人先做探索性测试，而后再把这部分内容转变成自动化的脚本。
6、麻利与软件测试
麻利测试与麻利开发一样，就是麻利开发的一部分，它是一个思维，而不是一种办法。那么这个思维跟传统测试的区别是什么呢？我认为次要包含以下几点：
首先最次要的是沟通，要发展麻利测试，最次要的是面向客户需要的全员测试，从产品、我的项目、开发到测试，要分明地了解用户的需要，如果依附传统的文档形式，音讯的传递效率是比拟低的，而且不及时，这是传统测试的局限所在。所以对于初创型的企业来说，即使一开始不采纳麻利测试，也能够借鉴它的思维来帮忙解决测试人员不理解需要的景象。
第二点是说麻利拥抱变动，但拥抱变动不是让大家胡作非为地频繁变更需要。因为麻利始终强调慢思考，快口头，一拍脑门就往前冲不是麻利，所以一旦把测试前置，那么又将是一笔不小的投入，此时公司管理层要思考和把控需要的变动，不能朝令夕改，否则非常容易挫伤整个团队。
7、麻利测试最佳实际
后面提到麻利是一种思维，而不是具体的实际。尽管市面上有十分多的厂商（包含资金机构）提到最佳实际，但我认为它是一种通用的模型，每个企业的状况不一样，套用对立的形式去可能会造成反向的成果。
这里有几点跟大家分享，在规范模型中提到了测试前移，测试要参加到需要的评估过程当中，如图 4 左上角所示，这里显示在迭代开始之前，测试人员就要参加迭代的测试剖析，这个剖析次要指的是需要的拆解、细化，而后编写 AC 之类的内容。图中还提到全量的回归测试，这才是麻利测试以及自动化测试的特点，就是进行全量的回归测试。每个迭代周期都要做测试，将之前测过的内容从新再测一遍，这就须要一直地欠缺和积攒自动化测试的脚本。这对于麻利和自动化测试来说，都是其充分发挥价值的中央。
■图 4
从图中下方能够看到，企业发展麻利测试肯定要按需实际，逐渐晋升。对于小的团队来说，比方团队小于五人这种初创的不稳固阶段，还是不要一开始就全副利用自动化测试，咱们的目标还是简略高效，内容太多反而会拖后腿。但还是须要具备这样的能力，因为要随时筹备做规模化、正规化的业务。
8、DevOps 与软件测试
当初很多企业在做 DevOps 转型，那么 DevOps 与软件测试又有怎么的关系呢？首先能够看图 5 左下角，这里的 DevOps 这个词用得不好，它只是把开发人员和运维人员的单词拆进去了，但实际上 DevOps 是软件开发、测试跟运维三方面的，这个词只是体现了两个方面。测试是 DevOps 中的重要一环，如图中右下角所示，其中提到 DevOps 跟麻利开发的区别，最次要的是反馈的周期更快了，如果此时依然用传统的形式做测试，那么其能力、频率都不足以满足这么快的交付频率，这对测试是一个十分大的挑战，同时也是其重要性的体现。
■图 5
在 DevOps 中的测试扮演着怎么的角色呢？它其实更多的是表演牵制和协同的角色。举一个简略的例子，咱们的软件要公布上线，这个时候应该是开发人员提交代码，而后 QA 测试无误，才容许把制品交给 Ops 做部署。如果线上出了问题，Ops 会通过监控平台第一工夫先反馈给 QA 来验证，验证通过之后再反馈给开发，而并不是间接反馈给开发。所以在这个过程中它更多的是表演牵制和协同的角色。
DevOps，这里 Dev 开发对应着 CI/CD 工具中的 CI（继续集成），Ops 对应的是 CD（继续部署）。对测试来说对应的是 CT（继续测试）。继续测试的概念介绍在图中左上角。
02 实际篇
1、极狐 GitLab 继续测试最佳实际
图 6 次要表白的思维是要把软件测试融入到整个软件开发的工作流当中，具体分成两个重要的局部：第一个就是要通过极狐 GitLab 的 CI/CD（或者其余平台也能够）把自动化测试工具集成起来。将 CI/CD 和自动化测试工具集成的目标是要实现的是全面的自动化。这样开发人员代码提交或者测试脚本更新之后，就能够通过 CI/CD 立即触发一次全面的测试，能力彻底解决效率问题。CI/CD 集成自动化测试工具，这一点相似于咱们所说的空间站的概念，极狐 GitLab 或者各公司采纳的 DevOps 平台，实质上就是一个外围仓，测试工具能够通过模块化的形式与其进行对接，最初拼接成一个残缺的空间站。
■图 6
第二个重要的内容就是测试左移、测试右移和品质门禁，测试左移就是测试前置，测试人员参加到需要的评审环节中，解决大家对于需要的了解问题。而测试右移就是在程序公布到线上之后，须要 Ops 监控，遇到问题之后发出报警。这两局部很重要，但都没有中间代码评审局部那么重要，因为很多公司都在创立所谓的品质门禁。这里会遇到两种问题：第一个问题就是如何治理这么多测试工具的报告，很多团队间接把报告发到邮件或者聊天工具中，然而这样代码、版本怎么跟报告匹配呢？另一个问题就是机会问题，就是怎么关联测试跟代码的评审，如果评审通过了，代码也合到骨干分支中了，然而测试报告不通过，也是不行的，这相当于测试跟代码评审没有造成关联。测试门禁就失去了它的意义和价值。
2、极狐 GitLab 软件测试基座
对于 极狐 GitLab 来说，咱们要解决的问题，就是将测试跟代码的评审联合起来，传统的测试报告都是离散的，当初须要对这些数据进行整顿，将所有测试工具的报告集成到代码评审的页面中，这样在评审的时候就可能第一工夫清晰地看到这些报告，并且确保是跟这一次提到的代码关联的报告。代码评审人员参考这些报告后，只须要签字即可。
对于极狐 GitLab 来说，咱们始终认为肯定是要把这些数据对立地汇总起来去做代码审核，这对落实代码门禁和代码品质是十分重要的。
3、筹备工作
接下来将介绍企业外部，尤其是初创性企业，如何在什么都没有的状况下发展测试工作？如图 7 所示，首先是对于前置条件，这里我列了三点，最次要的就是你先得有版本控制，意味着有代码治理的平台，这是测试的前提。而后就是 CI/CD，它次要解决效率的问题，并且它能够作为方才所说的集成平台，也就是外围舱，跟测试工具来做对接。第三点就是，在企业外部没有业余的测试人员或者规模还没实现的状况下，如果咱们仍想做一些根本的测试（简略的测试大多数也是以手动为主），那么能够采纳代码的扫描工具，比方代码品质的扫描、代码平安的扫描来肯定水平地补救手工测试的有余，比方变量名称命名、正文不全这类的问题。
■图 7
在满足这些条件之后，如果有能力发展自动化测试，联合方才所说的测试金字塔实践，个别认为最底下的最重要，失常来说应该是单元测试最重要，但实际上这里我把单元测试排在第二位了，把接口测试放到了后面。这是因为对于国内的企业和开发人员来说，大家广泛没有做单元测试的文化，大部分开发人员都是处于工作饱和的状态，此时如果再去写单元测试，会引起更大的抵触情绪。而做接口测试的话，能够应用到一些可视化工具，这些工具不须要编程能力，就能够去实现接口的自动化测试。
4、接口测试
图 8 展现了接口测试的劣势，最次要的是第 4 点和第 5 点，第 4 点是说，接口测试能够通过可视化工具来进行，此时门槛是比拟低的，测试人员比拟容易把握，不须要减少太多的累赘。第 5 点说的是，接口相对来说会比 UI 层面更稳固一些，那么你自动化后他的价值是能够更多的体现进去。流程上来说，个别是测试人员利用这些可视化工具编写测试用例，而后导出为测试脚本，再用这些工具的无 UI 的实现（如 Docker 容器）把脚本加载进去，就能够实现自动化接口测试。这两点在实操层面（落地层面）是比拟容易施行的，所以说接口测试对初创性的企业来说，是应该最早被推广的。
■图 8
对于怎么做接口测试，这里没有讲得那么具体，我在图的下方简略概括了一下，接口测试波及的工具很多，比方接口文档的治理、接口测试的工具、mock 工具、性能测试工具等，对于初创性企业来说，我举荐大家用一体化工具，其实国内当初有很多一体化工具，它能够去帮咱们治理接口文档，也能够做接口测试，甚至能够做性能测试等。对于初创企业来说简化了工作，进而晋升了效率。
5、性能测试
接下来就能够发展性能测试，因为大部分的性能测试简直都是基于接口的，所以在做完接口测试之后，能够顺带进行性能测试。性能测试的类型如图 9 所示，比方负载、压力、浸泡、冲击测试等了。在发展性能测试之前，肯定要明确到底要做什么类型的性能测试。性能测试不是强需要，而是非功能性的需要，不同类型决定了目标不同，所以要带着明确的目标去做。图 9 两头是微软给出的性能测试的外围流程，能够参考它去做。
■图 9
6、单元测试
上面就能够做单元测试了，其实也能够把它提前到第一个阶段去做，我没把它放到最后面是因为，国内对于单元测试分成两派，有的人反对，有的人拥护，对于企业来说，只有器重产品的品质，并且人员的能力是满足的，就能够先尝试去做。能够从三个方面思考，如图 10 所示，就是“谁做、咋测、成果”。
■图 10
“谁做”这一点毋庸置疑，单元测试不是测试人员去做，肯定是开发人员本人来做，国外发展麻利测试，比方极限编程中提到的结对编程、结对开发，是大家互相做单元测试，然而在国内较难推广。“咋测”就是要验证单个程序、单个函数办法的变量、条件、门路、资源是否正确。实际上在失常的开发过程中，开发人员都会做自测，这个自测可能是开发人员本人打好包，从 API 层面或者 UI 层面调用到所写的程序办法的步骤（从外侧调用到内侧），查看是否正确，这样效率比拟低。也可能是开发人员写一些马甲程序来实现函数正确性的验证。从某种意义上来说，这是在做单元测试的工作，只是不够业余，无妨将其依照单元测试的正规流程来写。“成果”次要蕴含两个方面，间接指标包含单元测试的通过率、覆盖率、用例的状况，间接指标是单元测试之后 bug 的总体趋势，以及 bug 率是否升高。国内企业十分看重指标，甚至到了一种畸形的境地，特地申明一下。如果要做单元测试，千万不要把单元测试的覆盖率当作最重要的指标，或者要求单元测试的覆盖率肯定要达到 80% 或者 90%，这相对不行。这么做单元测试就成了一个走流程、走模式的过场了。另外单元测试目标是验证功能模块的正确性。尤其是对于简单性能验证，特地简略的性能没有必要去笼罩，所以不要去谋求高覆盖率。
7、UI 测试
最初是 UI 测试，它分为如图 11 所示的几个平台，从平台上来说，分为 App 平台、web（比方 BS 架构的 web 平台）、桌面平台（不光包含 PC 机，硬件终端、上位机其实都属于桌面端）。另外的，UI 测试在类别上次要分为两类，一类是逻辑，指的就是界面上的操作流程程序和性能是否正确。这一类倡议大家肯定要自动化大于手动，因为很多传统企业在没有发展自动化测试工具的时候都是靠手工，那么自动化就能够施展它的劣势，代替大量的反复操作。另一个类别就是视觉，很多企业在验证这类 UI 的时候会去看字体、字号、文案、成果等，我反而感觉这部分最好手动，不必声势浩大地自动化，因为自动化的老本较大，收益比拟低。我认为齐全没必要做 OCR、抠文字、辨认、判断文案，扫一眼即可。把 UI 测试放在最初也是因为它的条件，这里我列举了十个条件，这也是业内宽泛认可的条件，在这十个条件满足的状况下，就能够发展 UI 测试，如果这十个条件不是特地满足，就没有必要做了。
■图 11
从这个流程上来说，UI 测试跟其余的测试其实没有大的区别，运行的时候会有两种模式：第一种是以 GUI 模式运行，就是带 UI 的模式去做自动化测试。这种状况要专机专用，比方有一个上位机，将这个上位机带着硬件一起搬过去作为测试的专用机，而后自动化测试脚本在这台专用的机器上运行，这样运行的时候就不能够做其余的操作，因为 GUI 独占了。大部分 app 和桌面平台的自动化 UI 测试可能都是采纳这样的形式。
另一种模式就是 headless，headless 是通过无 UI 的模式运行软件的测试，它次要是在 web 的 UI 测试中应用，比方基于 Chrome 浏览器的能力。像 selenium，它能够实现 headless 的无 UI 的模式，在容器运行，长处是能够并发，并且效率、性能都比专机专用要高得多。UI 测试的流程形式与方才提到的接口测试、性能测试都差不多。
03 问答环节
1、守业公司如何配置专门的测试团队？
首先还是看产品，在开始的孵化阶段，基本上没有业余的测试人员或者由开发人员兼职，小团队的测试基本上是以兼职为主，等我的项目做出一些头绪，能够作为长期倒退的我的项目时，就能够建设团队，一直装备人员。对于我经验过的守业团队来说，大部分状况是最后的开发测试人员配比为 4 : 1 或者 5 : 1，测试人员相对来说数量是不够的。在这样的状况下，不适宜声势浩大地去做工具、流程方面的工作，等整个团队的人数超过十个人或者产品十分稳固了，再减少测试人员，这时就能够发展麻利测试、自动化测试了。有些公司可能为了降低成本还会引入一些外包资源，就是通过外包人员来做手动测试，之后再由外围人员来做自动化，这些外围人员缓缓往测试开发的方向转。
2、逻辑常常变动的状况下保护老本很大，此时要怎么做自动化？
逻辑常常变的状况倡议就不要再做自动化了，因为变动太快，在稳固之后再补充做自动化反而适合。常常变的状况我认为还是用纯手工的形式比拟适合，因为作为初创型的企业，所有还是以简略效率为主，没有必要谋求完满和规范，这对企业来说不是坏事。
3、独自的性能测试在什么机会切入比拟适合？
在产品设计之初，产品的性能其实就是产品的一个指标，如果产品面向的是企业外部，有几十人应用，从某种意义上来说性能测试没有那么重要。而电商平台这种 2C 的产品，有数千人甚至数十万人应用，肯定要带着性能指标。这种状况则越早发展越好，能够阶段性地发展，千万不要等上线前再发展，如果上线前再发展，一旦发现了问题，再去解决性能问题的老本是十分大的。如果采纳麻利的形式，两周一个迭代，那么就两周测一轮，提前解决问题，如果是传统的开发模式，比方六个月的我的项目，那么至多每个月测一轮。
流动预报
7 月 16 日下午，声网开发者守业讲堂 • 第 4 期将以「守业团队如何保障产品业务的平安合规？」为题，邀请环信、游族、白山云三家优良企业的技术专家为大家带来精彩的分享。
心动不如口头，赶快扫描二维码或者点击 此处 报名吧！