目录
目录
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（持续测试）。持续测试的概念介绍在图中左上角。
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 测试的流程方式与刚才提到的接口测试、性能测试都差不多。
5403
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
