前言
今天难得休假，闲的我可以发发帖子写写邮件了，也可以静下来好好想想接下来要做的事情。我们的项目 2.0 开始迭代了。一切从头开始，之前的产品要在 2.0 完成后抛弃掉，最近一直在想从头开始后，我们该怎么保证项目的质量。刚才给领导发了邮件说了一下我初步的想法。我贴上来跟大家讨论一下吧。
给领导的邮件内容
hi all，
这些日子有一些对我们产品质量的想法。前些日子分别跟薇薇，博海，大大都商量了一下。列一些我目前要推进的事情。
我觉得我们可以从几个角度去考虑提升我们的效率。
- 测试前置，避免把风险都放在迭代的后期。
首先将产品进行分层测试。产品并行开发的同时，也进行并行的测试。在一开始我们测试工具并不成熟的情况下，可能比较难以测试的模块。 暂时由开发的同学帮助我们提供 client 进行手工测试。目前 TM，Spark domain 是这样手工测试的，API 这边由于有测试框架，可以很方便的测试并自动化起来。同时开发过程中把细粒度化每个 feature，增量式的提供给测试人员测试。这样可以保证联调前就对产品做过一轮测试。我这边开始学习 thrift 框架，这样以后可以使用代码驱动 TM 进行自动化测试。同时调研 spark 和 yarn 的 API，保证测试中验证 spark domain 的 application 的状态。 - 快速的 bug 定位
以前我们在定位一个 bug 上花的时间比修改 bug 本身都要长数倍。针对这个问题，我想到以下几点
a. 提高单元测试的覆盖率，单元测试是最容易定位 bug 的方式
b. 自动化测试中减少流程性测试，将被测功能隔离。每个用例只测试一个功能。
c. 测试人熟悉产品代码，有自己 debug 的能力。主动定位 bug 位置 - 建立高覆盖率的持续集成流程
测试与开发共同努力提高自动化测试的覆盖率并加入到持续集成中，成为我们保证质量的重要关卡。之后可以建立一个流程，并引入代码覆盖率工具，新的功能要通过所有的自动化测试后才可以 release。 - 开发自测
由于我们测试人手紧缺，所以希望开发的同学可以通过各种方式自身做一道质量检测的工作。例如单测，例如流程性测试。QA 在项目稳定后会提供一些测试用例帮助测试。同时提供一些开源的测试方案帮助开发的同学进行自测。
给开发同学的邮件
hi all，
最近我一直在做 API 的测试，我们明天站会结束后讨论一下之后我们配合的流程吧。方便以后更顺利的测试。我先列一下我的想法。
- 基于 develop 分支的测试
像镇江说的之后把 feature 分支更细粒度化。每个 feature 分支只有一个 API 或者是一天能够完成的 API 的量。测试人员可以及时的测试 API，而不是所有 API 都开发完成后才测试。这样测试人员可以保证联调之前能测试大部分的场景，以防联调的时候出现什么问题。影响效率 - 关于 CR
最好不要积攒很多 API 一起做 code review，跟第一点一样，增量式的做 CR 可以保证流程的速度。最好当天就能够完成当天开发出的 API 的 CR 流程。第二天早上测试人员就可以测试 CR 完的 API 了。 - 关于 bug 定位
我设计测试用例的时候，会将所有 API 隔离。暂不做流程性测试。也就是说我会直接在数据库和 hdfs 上插入数据和文件伪造测试数据。这样脚本失败的时候我可以定位到具体哪个 API 的错误。并且我也会尽量自己 debug API 的代码找出 bug 的位置。 我这样想是为了提升效率，减少沟通成本。能我自己解决的问题尽量不占用开发的时间。 - 关于 bug 管理流程
关于这点我是这么想的，快速开发阶段，为了提升效率我们简化这个流程。像第三点描述的，测试人员尽量定位出 bug 的准确位置，然后口头与开发人员沟通，开发人员迅速修复 bug。这中间弱化 jira 的作用。也许不在 jira 上提交 bug，或者也只是提交一个简单的描述来跟踪。 - 关于自动化测试
模块稳定前不会做大量的自动化测试，只执行主要的功能自动化。防止变化带来的维护自动化脚本的成本。 - 关于变化的沟通
为了减少沟通成本，如有重要的变动，最好拉上测试人员一起讨论。了解设计原理与变化有助于测试人员及时更新用例和设计测试计划。同时测试人员也密切关注 git 中代码的变化。代码是测试人员最好的文档。 - 关于持续集成
测试人员会在模块稳定后搭建持续集成流程，每日定时触发两次自动化测试。 我们通过单元测试，UI 自动化测试和接口测试组建一个产品质量保证体系。在覆盖率达到一定程度后，持续集成就是我们的质量保证体系最重要的一环。所有在持续集成中的 case 都通过的状态下，才准许我们的产品被发布出去。 - 关于单测
为了效率，暂时精简单测。数据库的验证可以不用那么精准。由我在测试的时候保证数据的正确性。 单测以后主要关注在覆盖率上，可以使用 mock 机制增加覆盖率。 - 关于开发自测
所有 API 的主流程要走通。不需要异常测试，极限测试等。我在想要不要和薇薇商量出一些 smoke 的 case 来执行。 - 关于代码规范
测试人员在测试中也会 review API 的 code。 提出一些自己的建议。增加可测试性的保证。
目前对 API 的建议如下：
a. 建立成体系的错误反馈，方便调用方调试代码。
b. 取消返回值中的冗余信息。目前的情况是调用方只需要 project 的 id 和 name 的信息，而 API 中返回了所有的字段，并且不需要的字段被赋值为 null
c. 统一返回值的格式与标准
d. delete 操作的时候，删除完全。例如 delete project 的时候，最好现在就把 project_data，plan 也删除掉。防止对测试数据库中的数据造成污染。
e. 尽量使用 mybatis 的级联查询功能。避免多次执行 sql，这样比较容易出错
f. 尽量建立完善标准的 log 机制。方便之后 track 和监控
以上都属于建设性意见~，目前 API 并没有功能性的问题，不会影响联调。
总结
我总是想在流程上，开发那边就增加质量保证的机制，可惜不是那么好推的，现在才知道沟通能力的重要性，能说服别人的重要性。
