今天难得休假，闲的我可以发发帖子写写邮件了，也可以静下来好好想想接下来要做的事情。我们的项目 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 并没有功能性的问题，不会影响联调。
我总是想在流程上，开发那边就增加质量保证的机制，可惜不是那么好推的，现在才知道沟通能力的重要性，能说服别人的重要性。