前言
今天难得休假，闲的我可以发发帖子写写邮件了，也可以静下来好好想想接下来要做的事情。我们的项目 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 并没有功能性的问题，不会影响联调。
总结
我总是想在流程上，开发那边就增加质量保证的机制，可惜不是那么好推的，现在才知道沟通能力的重要性，能说服别人的重要性。
希望领导和开发会采纳吧~~~
#1 楼 @lamianxiaodian 到现在还没回邮件呢 哈哈哈，估计不想理我了吧
内容太多，可能领导还没看出你重点想说啥？
团队大的话，沟通能力确实很重要。要想开发增加质量保证机制，我觉得得让他们尝到甜头，例如覆盖率高有小礼物之类的，或者及时给些报告说明增加了这个机制后质量提升的情况。要不他们只会觉得增加了工作量，看不到产出。
#3 楼 @chenhengjie123 额，这个给小礼物的方式我是没想到。。。行得通么。。。 我也是在来了这个公司后才负责流程性的东西。不是很有经验。一切方式都在摸索
#5 楼 @chenhengjie123 我觉得我现在的职位比较尴尬，其实没啥权利，凭什么对人家开发指手画脚呢。开发的同学们应该会这么想吧
说真的，要理你就怪了。。。
任何增加别人工作量的事情又不是领导开口的，呵呵哒。
真要做好，必须从上而下。
有空写这么一段，你自己能改多少改多少好了。。。。。。
#8 楼 @chenhengjie123 嗯，明天上班以后，尽量跟开发的同学们沟通吧。希望能说服他们。
你列举的事情太多, 不够聚焦. 广而不精. 你得明确不同的阶段的不同目标. 然后才能制定合适的策略.
一般是前期重效率, 中期重 feature, 后期重集成. 每个阶段需要定义好最值得投入的事情, 发散太多容易导致投入过大.
前期 sonar 代码静态分析 + 单测用例 + 单测覆盖率
中期 接口测试 +Trace 技术 + 集成测试覆盖率 +Code Review
后期 人工测试 + 部分主流程的 UI 自动化 + 代码 diff 分析
至于 bug 定位, 你研究下对应的 trace 技术即可. 比如 java 里面的 byteman 或者 jacoco 就足够了. 基本可以保证能快速定位问题了.
我觉得还是找准自己的位置吧。
项目整体的分析不要过于笼统，问题是出在谁那里，向领导汇报的时候就点谁名，当然私下里该说也要说。
找到问题，给解决办法，QA 这边重点做的是什么，能不能或者怎么就可以解决这个问题。（领导想 “不需要你告诉我哪儿有问题，有问题落地解决呀，给我要我来解决么）
尽量不要给一些放之四海皆可的建议，这样的建议等于没有建议。
还有个很关键的问题，你说的这三条大建议，都很难落地执行，或者要投入很多的时间和人力。简单直接才是解决问题的王道，key 一个最重要的点，做出效果，再推进其他点
我觉得楼主在与人沟通方面有点问题，首先我看了你的文章以后，我真的不觉得有你这样的同事在公司会是一件愉快的事，我想你的老大你的同事也有大部分这么想。
作为测试在创业公司碰到问题我觉得很正常，如何正常的沟通显然是解决问题的捷径，像你这样去指挥开发做点事情，看似是善意的建议，实则会招来反感。
@ycwdaaaa 支持你。人天生有惰性，工作时间久了，混日子也就慢慢培养出来。像你这样的负责和热心很少了，很多评论可能都是仅仅针对你的内容，换个角度看，可能更容易理解你的想法！
#10 楼 @seveniruby 我现在还担心发这么个邮件是不是得罪开发同学了哈哈
关于用分支测试 feature 这个建议不敢苟同:
- 多分支策略一般用于本地，codebase 的过多分支会造成 merge 的隐患并且多个环境的迭代版本并不好管理
- 退一步讲即使 feature owner 愿意 local build 给测试 test，假设碰到多个 feature 的情况 owner 大概也只愿意 build 一个 local，不然以 java BE build 的 memory usage 会把你的机器卡死
- 既然有 code review，那可以在某个 API finalize 的提交上 cc 给测试用来跟踪，假设贵司有 hourly build 那么测试就会知道这个 API 会进下一个小时迭代版本 (可测)
关于在持续集成中提高自动化测试的覆盖率, 对于 java 的项目而言其实有一个效率问题。一个功能一般会有数次提交 (毕竟一个提交最好只做一件事情)，如果对每一次提交都要重新 build 来跑自动化，会花费大量时间在 build 和测试上，使得提交迟迟进不了 codebase。
#10 楼 @seveniruby 请教一下，我们现在项目刚开始，开发那边已经有 CR 流程了。 开发的老大觉得这可以保证质量。规定严格的执行。顺便说一下我们是 toB 的模式。 这样在早期就引入 CR 是会影响效率么？
#21 楼 @seveniruby 嗯，是的，我应该多跟他们沟通，尤其发邮件之前。
了解
#21 楼 @seveniruby 确实这样，有的时候邮件是沟通后的产物。
楼主是一个优秀的员工,赞赏,考虑公司利益的员工一个定是个好员工.
但是,公司的邮件,最好是不要这样直接 post 出来.
本人可以理解作为一个 employee 的尴尬.你想解决现有的问题,你不可以决定什么,你可以建议,但是建议是不会听的.
楼上有位兄弟说的很对,先找准自己的位置.
找自己的位置前,先确定自己的性格特质.不同性格特质的人,决定了他的职业发展.
如果只是抱怨,没有作为的 tester 也有很多,我觉得他们说的都很对,但是都没办法改变现实.
个人见解:
- 测试这个部门其实可以权利很大,因为他们要为质量负责 (虽然不是全部责任),不过这要看测试主管.我之前见过有跟老板对着干的.
- 单个 tester 也可以权利很大,他们的专业性是整个公司最强的,我经常对他们说,你们一对你测试的产品一票否决,但是确从来没人执行过这样的权利.
- 还有一般老板都是结果导向的,如果你能先把你的方案换算成钱之后.可能老板会喜欢看
- 书面正式沟通不如口头非正式沟通来得效果好,真的,不信你试试.
