从0到1开展软件测试——实践篇
1、极狐 GitLab 持续测试最佳实践图 6 主要表达的思想是要把软件测试融入到整个软件开发的工作流当中，具体分成两个重要的部分：第一个就是要通过极狐 GitLab 的 CI/CD（或者其他平台也可以）把自动化测试工具集成起来。将 CI/CD 和自动化测试工具集成的目的是要实现的是全面的自动化。这样开发人员代码提交或者测试脚本更新之后，就可以通过 CI/CD 立刻触发一次全面的测试，才能彻底解决效率问题。CI/CD 集成自动化测试工具，这一点类似于我们所说的空间站的概念，极狐 GitLab 或者各公司采用的 DevOps 平台，本质上就是一个核心仓，测试工具可以通过模块化的方式与其进行对接，最后拼接成一个完整的空间站。
第二个重要的内容就是测试左移、测试右移和质量门禁，测试左移就是测试前置，测试人员参与到需求的评审环节中，解决大家对于需求的理解问题。而测试右移就是在程序发布到线上之后，需要 Ops 监控，遇到问题之后发出报警。这两部分很重要，但都没有中间代码评审部分那么重要，因为很多公司都在创建所谓的质量门禁。这里会遇到两种问题：第一个问题就是如何管理这么多测试工具的报告，很多团队直接把报告发到邮件或者聊天工具中，但是这样代码、版本怎么跟报告匹配呢？另一个问题就是时机问题，就是怎么关联测试跟代码的评审，如果评审通过了，代码也合到主干分支中了，但是测试报告不通过，也是不行的，这相当于测试跟代码评审没有形成关联。测试门禁就失去了它的意义和价值。
2、极狐 GitLab 软件测试基座
对于 极狐GitLab 来说，我们要解决的问题，就是将测试跟代码的评审结合起来，传统的测试报告都是离散的，现在需要对这些数据进行整理，将所有测试工具的报告集成到代码评审的页面中，这样在评审的时候就能够第一时间清晰地看到这些报告，并且确保是跟这一次提到的代码关联的报告。代码评审人员参考这些报告后，只需要签字即可。
对于极狐 GitLab 来说，我们一直认为一定是要把这些数据统一地汇总起来去做代码审核，这对落实代码门禁和代码质量是非常重要的。
3、准备工作
接下来将介绍企业内部，尤其是初创性企业，如何在什么都没有的情况下开展测试工作？如图 7 所示，首先是关于前置条件，这里我列了三点，最主要的就是你先得有版本控制，意味着有代码管理的平台，这是测试的前提。然后就是 CI/CD，它主要解决效率的问题，并且它可以作为刚才所说的集成平台，也就是核心舱，跟测试工具来做对接。第三点就是，在企业内部没有专业的测试人员或者规模还没完成的情况下，如果我们仍想做一些基本的测试（简单的测试大多数也是以手动为主），那么可以采用代码的扫描工具，比如代码质量的扫描、代码安全的扫描来一定程度地弥补手工测试的不足，比如变量名称命名、注释不全这类的问题。
在满足这些条件之后，如果有能力开展自动化测试，结合刚才所说的测试金字塔理论，一般认为最底下的最重要，正常来说应该是单元测试最重要，但实际上这里我把单元测试排在第二位了，把接口测试放到了前面。这是因为对于国内的企业和开发人员来说，大家普遍没有做单元测试的文化，大部分开发人员都是处于工作饱和的状态，此时如果再去写单元测试，会引起更大的抵触情绪。而做接口测试的话，可以使用到一些可视化工具，这些工具不需要编程能力，就可以去实现接口的自动化测试。
4、接口测试
图 8 展示了接口测试的优势，最主要的是第 4 点和第 5 点，第 4 点是说，接口测试可以通过可视化工具来进行，此时门槛是比较低的，测试人员比较容易掌握，不需要增加太多的负担。第 5 点说的是，接口相对来说会比 UI 层面更稳定一些，那么你自动化后他的价值是可以更多的体现出来。流程上来说，一般是测试人员利用这些可视化工具编写测试用例，然后导出为测试脚本，再用这些工具的无 UI 的实现（如 Docker 容器）把脚本加载进去，就可以实现自动化接口测试。这两点在实操层面（落地层面）是比较容易实施的，所以说接口测试对初创性的企业来说，是应该最早被推行的。
对于怎么做接口测试，这里没有讲得那么具体，我在图的下方简单概括了一下，接口测试涉及的工具很多，比如接口文档的管理、接口测试的工具、mock 工具、性能测试工具等，对于初创性企业来说，我推荐大家用一体化工具，其实国内现在有很多一体化工具，它可以去帮我们管理接口文档，也可以做接口测试，甚至可以做性能测试等。对于初创企业来说简化了工作，进而提升了效率。
5、性能测试
接下来就可以开展性能测试，因为大部分的性能测试几乎都是基于接口的，所以在做完接口测试之后，可以顺带进行性能测试。性能测试的类型如图 9 所示，比如负载、压力、浸泡、冲击测试等了。在开展性能测试之前，一定要明确到底要做什么类型的性能测试。性能测试不是强需求，而是非功能性的需求，不同类型决定了目的不同，所以要带着明确的目的去做。图9 中间是微软给出的性能测试的核心流程，可以参考它去做。
6、单元测试
下面就可以做单元测试了，其实也可以把它提前到第一个阶段去做，我没把它放到最前面是因为，国内关于单元测试分成两派，有的人支持，有的人反对，对于企业来说，只要重视产品的质量，并且人员的能力是满足的，就可以先尝试去做。可以从三个方面考虑，如图 10 所示，就是“谁做、咋测、效果”。
“谁做”这一点毋庸置疑，单元测试不是测试人员去做，一定是开发人员自己来做，国外开展敏捷测试，比如极限编程中提到的结对编程、结对开发，是大家相互做单元测试，但是在国内较难推行。“咋测”就是要验证单个程序、单个函数方法的变量、条件、路径、资源是否正确。实际上在正常的开发过程中，开发人员都会做自测，这个自测可能是开发人员自己打好包，从 API 层面或者 UI 层面调用到所写的程序方法的步骤（从外侧调用到内侧），查看是否正确，这样效率比较低。也可能是开发人员写一些马甲程序来实现函数正确性的验证。从某种意义上来说，这是在做单元测试的工作，只是不够专业，不妨将其按照单元测试的正规流程来写。“效果”主要包含两个方面，直接指标包括单元测试的通过率、覆盖率、用例的情况，间接指标是单元测试之后 bug 的总体趋势，以及 bug 率是否降低。国内企业非常看重指标，甚至到了一种畸形的地步，特别申明一下。如果要做单元测试，千万不要把单元测试的覆盖率当作最重要的指标，或者要求单元测试的覆盖率一定要达到 80% 或者90%，这绝对不行。这么做单元测试就成了一个走流程、走形式的过场了。另外单元测试目的是验证功能模块的正确性。尤其是对于复杂功能验证，特别简单的功能没有必要去覆盖，所以不要去追求高覆盖率。
7、UI 测试
最后是 UI 测试，它分为如图 11 所示的几个平台，从平台上来说，分为 App 平台、web（比如 BS 架构的 web 平台）、桌面平台（不光包括 PC 机，硬件终端、上位机其实都属于桌面端）。另外的，UI 测试在类别上主要分为两类，一类是逻辑，指的就是界面上的操作流程顺序和功能是否正确。这一类建议大家一定要自动化大于手动，因为很多传统企业在没有开展自动化测试工具的时候都是靠手工，那么自动化就可以发挥它的优势，代替大量的重复操作。另一个类别就是视觉，很多企业在验证这类 UI 的时候会去看字体、字号、文案、效果等，我反而觉得这部分最好手动，不用大张旗鼓地自动化，因为自动化的成本较大，收益比较低。我认为完全没必要做 OCR 、抠文字、识别、判断文案，扫一眼即可。把 UI 测试放在最后也是因为它的条件，这里我列举了十个条件，这也是业内广泛认可的条件，在这十个条件满足的情况下，就可以开展 UI 测试，如果这十个条件不是特别满足，就没有必要做了。
从这个流程上来说，UI 测试跟其他的测试其实没有大的区别，运行的时候会有两种模式：第一种是以 GUI 模式运行，就是带 UI 的模式去做自动化测试。这种情况要专机专用，比如有一个上位机，将这个上位机带着硬件一起搬过来作为测试的专用机，然后自动化测试脚本在这台专用的机器上运行，这样运行的时候就不可以做其他的操作，因为 GUI 独占了。大部分 app 和桌面平台的自动化UI 测试可能都是采用这样的方式。
另一种模式就是 headless，headless 是通过无 UI 的模式运行软件的测试，它主要是在 web 的 UI 测试中使用，比如基于 Chrome 浏览器的能力。像 selenium，它可以实现 headless 的无 UI 的模式，在容器运行，优点是可以并发，并且效率、性能都比专机专用要高得多。UI 测试的流程方式与刚才提到的接口测试、性能测试都差不多。
页:
[1]
