2 篇博文 含有标签「质量保障」

为什么要谈这个 topic？​

实践中，质量保障体系的建设，主要针对两个目标: 一是不断提高目标业务测试覆盖率，保障面向客户的产品质量；二就是尽可能的提高人效，增强迭代效率。而构建全链路质量卡点就是整个体系建设的核心手段。笔者用下图来描述这整个链路:

可以看到，虽然保障业务迭代的方向性正确排在最前面，但在具体操作上，这一步需要的是强化流程规范和构建企业文化，同时对各负责人技能培训，可以说多数是软技能。而保障基础代码质量环节发力于自动化建设链路之始，是可以通过技术手段来消灭潜在的质量问题，所以构建好的话能极大的降低心智负担，非常值得关注。

我们都知道，代码的好坏会直接影响到业务质量，团队协作，以及后期技术债等。有一个经典的图来描述代码质量的好坏，当能深切表达程序员的内心:

而同时我们相信，绝大部分程序员都有追求卓越的初心，且会尽可能的在自己能力范围内编写高质量的代码。

但是，保障基础代码质量光靠程序员的个人素质一定是不全面，是人就会犯错，可能会疏忽。我们最需要的是一种自动化的机制来持续确保不出问题。这也是自动化的魅力，一次构建，持续收获价值。

此类工具在业界一般叫 linter，不同的语言有不同的实现。本文主要探究 Go 语言相关的。 在介绍相关工具之前，我们先看看几个经典的代码坏味道: 这段代码常规运行不会有问题，但是在一些场景下循环执行，那可能就会有问题了, 我们来看看: (注:ex2 是上述代码编译出的可执行文件名字)

很明显，有句柄泄露。原因也很简单，http response 的 body 没有关闭。但这个关闭语句，一不注意也容易写错：

这时候如果百度挂了，上述程序程序就会因为空指针引用，造成非预期的 panic，非常的不优雅。所以正确的做法应该是在 err 判断之后再行关闭 body(关于 Client.Do 具体的各种限制，大家可以参考这里: https://golang.org/pkg/net/http/#Client.Do)

如此种种，此类小问题在实际编码活动中非常常见，且不容易一眼看出问题。甚至常规的测试可能也难检测出来，可谓非常棘手。好在 Go 语言的开发者们为我们想到了这一点，内置工具链中的 vet 命令，就能方便的检测到很多类似的问题。

还比如下面的代码场景，我在实际的测试用例和业务代码都看到过：

go vet 可以很容易检测出这个问题(其他 vet 功能，可以参考这里: https://golang.org/cmd/vet/)。

go 的工具链中，还有一个不得不提，那就是大名鼎鼎的 go fmt，其了却了其他语言经常陷入的代码风格之争，是 Go 语言生态构建非常巧妙的地方。另外 golint 也是 google 主推的 go 语言代码代码风格工具，虽非强制，但强烈建议新项目适用。

Go linters 业界现状​

上面主要说到 Go 工具链的内置工具，还有一些非官方的工具也比较有名，比如 staticcheck, errcheck在 github 上 Star 都较多。此类工具有个专门的的 github 库，收集的比较全，参见 awesone-static-analysis

同时还有些项目旨在聚合此类工具，提供更方便的使用方式，以及一些酷炫的产品化。比如golangci-lint, 其衍生的商业化项目，可以自动针对 github PR 做代码审核，对有问题的地方自动 comments，比较有意思。

如何才能优雅的落地 linter 检查？​

linter 工具必须为产品质量服务，不然就是做无用功。实践中，我们应该思考的是如何才能优雅的落地 linter 检查，如何才能建立有效的质量卡点。

推荐针对 PR，做代码检查，保障入库代码质量。基于 PR 做事情是我比较看好的，因为这是调动所有研发力量，天然契合的地方。且进一步讲，这也是测试基础设施更能体现价值的地方。

目前 Github 上有很多这方面的集成系统做的都比较好，能够快速的帮我们落地 PR 测的检查，比如 Travis, Circle CI 等。另外就是著名的 Kubernetes 社区，也自行构建了强大的 Prow 系统，其不光是基于 CICD 系统，还构建了 chat ops 模式，为参与 Kubernetes 的社区的贡献者提供了方便。

细看 Kubernetes 库，会发现，其会针对每个 PR 都做如下静态检查:

• gofmt： https://github.com/kubernetes/kubernetes/blob/master/hack/verify-gofmt.sh
• govet: https://github.com/kubernetes/kubernetes/blob/master/hack/make-rules/vet.sh
• golint: https://github.com/kubernetes/kubernetes/blob/master/hack/verify-golint.sh 因为 golint 只是纠正代码风格，并不是强制，所以 k8s 官方就弄了比较软的方案，对于当前已经存在的代码如果有问题，先排除掉(如下)。对于新生代码，如果检查失败，ci 就挂掉。 https://github.com/kubernetes/kubernetes/blob/master/hack/.golint_failures

Kubernetes 只利用了官方的几款工具, 在检测准确性上比较有保障。有了这些检查点，也能倒逼研发人员关注提交代码的质量，会迫使其在本地或者 IDE 上就配置好检查，确保每次提交的 PR 都能通过检查，不浪费 CI 资源。这也是合格工程师的基本要求。

总结​

高质量的代码是业务质量保障的基础。而编写高质量的代码是技术问题，同时也应该是企业文化问题。因为当大家都开始注重技术，注重代码质量时，自然会朝着精益求精的路上行进，视糟糕的代码为仇寇。

我的一位老板跟我说过，要做就做 Number One。而在没达到第一的时候，那就要向业界标杆看齐，比如 Netflix，Google，Facebook 等。当大家都非常注重自己代码质量时，工程师才有时间去关注解决更加系统性的问题，而不用一直在 Low Level 徘徊。笔者深以为然。

问题​

通常，我在面试测试相关候选人时，除了技术等硬性标准外，我还非常希望候选人回答这么一个问题 ——如果让你负责一个项目的质量保证工作，你会怎么做？

之所以问这么个问题，主要是想考察候选人在过往的经历中，有没有全局性的思考如何把控一个项目的质量状况；有没有对自己日常的工作有个清晰的认识，甚或者有没有观察过你的 leader 或经理，他们是如何带项目的。这是个开放性的问题，不同行业，不同公司背景下的 QA 人员，得出的认识，可能会有不同。这里，我将谈谈我的理解。

从项目的一般生命周期说起​

很多候选人听到我这个问题，一般会从项目的生命周期说起，将焦点聚焦在测试人员及其工作本身上。

比如会谈到测试人员要参与需求评定，充分理解需求。之后还要设计测试用例以及用例评审。最后就是基于用例做最后的验收测试。基于此，部分同学还会提到，需要做的测试种类，比如功能测试，性能测试。做移动端的同学还会提到各版本，各机型的兼容性测试等等。

这种说法确实没错，测试人员做好了这些工作，很大程度上会保障好项目质量。但通常这种模式，比较倾向于传统 QA，容易变成研发的下游。且实际表明，这种模式对 QA 人力有一定的要求。太少了，工作就开展不起来。按我观察到的现象来看，这种模式下，开发测试比，一般可以达到 2:1 甚或者 1.5:1.

很明显这种比例对创业公司来说太高了，创业公司一般追求的是极致的投入，以及更加极致的产出。而传统意义上，测试的产出却并不是那么明显。所以在追求质量保证的道路上，我们需要考虑是否还有其他道路呢？

影响项目的质量因素​

仔细思考上面的描述，你会发现候选人默认将项目质量聚焦在测试人员身上， 而非项目本身。但做项目是个系统工程，涉及到的是方方面面。所以这里，我们不妨放大关注点，先不把目光局限在测试人员身上，而是考虑下这个问题的实质——影响项目的质量因素到底有哪些？

正所谓，过程决定结果。所以我认为做好过程质量，会让我们在追求项目质量的道路上事半功倍！

从过程质量出发，我将质量保证工作，简要的划分为下面几个环节，如图：

研发质量​

研发阶段是项目最重要的时期，代表着一个项目从无到有，从 1 到 100 的研发及逐渐迭代的过程。做好这个阶段的质量保证工作，其正面意义毋庸置疑。

我推荐将这个阶段的工作按分层模式来搞，从最初的代码检查，到最终的 e2e 测试，性能测试等，全方位，立体化来逐渐保卫产品质量。这里的每一项工作都不是独立的。而应该按照持续集成，流水线的模式，对每一次的代码改动进行筛查和测试。

测试同学这阶段的目标应该是保证这条流水线的畅通，以及部分测试工作的完善，比如测试框架，e2e 等。但不是说这里的每一项工作都要有测试同学来搞。而应该尽可能的发动开发和测试一起来协作。这样才会得到更高效率。

上线质量​

也就是发布环节的产品质量保证。之所以把这个单拎出来，主要是面向服务端程序来说。因为这个过程是产品代码从研发到线上，真正面对用户的分水岭。这个环节处理不好，就很容易出问题。这里我将这个阶段，影响质量的因素，主要归结为版本控制，配置控制，以及上线流程三个方面，需要测试人员着重关注。当然，有同学会说，在我们公司，几个因素主要是运维部门在负责，但是测试作为质量监察者，和布道师，同样应时刻关注，且针对其中的问题或薄弱环节，着力推动和解决相关事宜。总之，项目质量相关的问题，QA 都应该有义务关注。

特别的，QA 在这个阶段最好能产出，或者协助产出，线上功能的冒烟测试集，以方便做发布后的及时验证。

线上质量​

产品上线或者交付了，并不代表质量工作的完结，我们还应该时刻关注用户对产品的反馈。

应该定期组织线上 bug 分析，研究如何做才能避免这类 bug 的遗漏。对于线上事故，更要慎重对待，最好能对每一粒事故都给出测试端的改进。

还有一点可能大家比较忽视的就是，产品使用姿势分析。这一方面，虽然通常有专门部分来分析，但是如果有可能，我们同样应该关注，用户是如何使用我们产品的。这对我们在测试策略的制定上，非常具有指导意义。

对 QA 同学的技能要求​

通过上面的分析，你会发现，要想做好这些工作，需要对 QA 同学提出更高的要求。

首先，技术要过关。在七牛，我们要求测试同学在技术上与开发并无二致。只有这样，你在质量布道和流程改进时，才会与开发同学产生更多的共鸣。同时，你还需要有一定的沟通技巧，和项目管理能力。测试同学面对是整个团队，要能适应每一位人员。在平时的技术沟通，需求讨论时，高效应对，维护好良好的人际关系，以方便后续工作的开展。但同时也要有全局意识，坚守质量底线，把控各个环节，防止出现质量漏洞。对质量工作的如何开展要有清晰的认识，不能被带偏。

篇后语​

很多次，候选人都会问我，你们是手动测试多还是自动化测试多。我都会给他们强调，测试是对质量负责，不管是手动还是自动，都只是一种手段，依赖于测试人员的技术水平。我们希望所有的测试同学，都应该是以测试开发为标准，以质量布道为方向。用 owner 精神，做好整个项目的质量保证工作。