测试管理新项目的质量保障流程探讨

孙高飞 · 2016年06月13日 · 最后由 John 回复于 2016年07月25日 · 4038 次阅读

前言

今天难得休假，闲的我可以发发帖子写写邮件了，也可以静下来好好想想接下来要做的事情。我们的项目 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 并没有功能性的问题，不会影响联调。

总结

我总是想在流程上，开发那边就增加质量保证的机制，可惜不是那么好推的，现在才知道沟通能力的重要性，能说服别人的重要性。

11 个赞

如果觉得我的文章对您有用，请随意打赏。您的支持将鼓励我继续创作！

打赏支持

共收到 26 条回复时间点赞

王国锋 #1 · 2016年06月13日 1 个赞

希望领导和开发会采纳吧~~~

孙高飞 #2 · 2016年06月13日 Author

#1 楼 @lamianxiaodian 到现在还没回邮件呢哈哈哈，估计不想理我了吧

陈恒捷 #3 · 2016年06月13日 2 个赞

内容太多，可能领导还没看出你重点想说啥？

团队大的话，沟通能力确实很重要。要想开发增加质量保证机制，我觉得得让他们尝到甜头，例如覆盖率高有小礼物之类的，或者及时给些报告说明增加了这个机制后质量提升的情况。要不他们只会觉得增加了工作量，看不到产出。

孙高飞 #23 · 2016年06月13日 Author

#3 楼 @chenhengjie123 额，这个给小礼物的方式我是没想到。。。行得通么。。。我也是在来了这个公司后才负责流程性的东西。不是很有经验。一切方式都在摸索

陈恒捷 #5 · 2016年06月13日

#4 楼 @ycwdaaaa 我也没试过，不过有奖励机制推起来应该容易一些。这些东西你可能请教一些 HR 或者管理岗的同学比较靠谱。

孙高飞 #6 · 2016年06月13日 Author

#5 楼 @chenhengjie123 我觉得我现在的职位比较尴尬，其实没啥权利，凭什么对人家开发指手画脚呢。开发的同学们应该会这么想吧

magicyang #7 · 2016年06月13日

说真的，要理你就怪了。。。
任何增加别人工作量的事情又不是领导开口的，呵呵哒。
真要做好，必须从上而下。
有空写这么一段，你自己能改多少改多少好了。。。。。。

陈恒捷 #8 · 2016年06月13日 3 个赞

#6 楼 @ycwdaaaa 那就找老大要权利，或者让老大来帮忙推。开头总是比较难的，后面尝到甜头就顺了。

举个例子，开发有一段代码进行了重构或者优化，但他又不敢随便 commit ，怕有严重的 bug 。这个时候有单测就简单多了。不管三七二十一把单测跑过就至少保证不会有很严重的 bug 了。

站在他们角度来想问题，和他们说清楚这么做了之后对他们有什么好处（例如节省了时间，不用因为担心出问题而不敢优化代码），这样他们更容易认同。毕竟谁都不希望产品质量差。否则他们会觉得这事纯粹就是给你减负，给他们加负，自然不好推。

孙高飞 #19 · 2016年06月13日 Author

#8 楼 @chenhengjie123 嗯，明天上班以后，尽量跟开发的同学们沟通吧。希望能说服他们。

思寒_seveniruby #10 · 2016年06月13日 3 个赞

你列举的事情太多, 不够聚焦. 广而不精. 你得明确不同的阶段的不同目标. 然后才能制定合适的策略.
一般是前期重效率, 中期重 feature, 后期重集成. 每个阶段需要定义好最值得投入的事情, 发散太多容易导致投入过大.
前期 sonar 代码静态分析 + 单测用例 + 单测覆盖率
中期接口测试 +Trace 技术 + 集成测试覆盖率 +Code Review
后期人工测试 + 部分主流程的 UI 自动化 + 代码 diff 分析

至于 bug 定位, 你研究下对应的 trace 技术即可. 比如 java 里面的 byteman 或者 jacoco 就足够了. 基本可以保证能快速定位问题了.

王攀 #11 · 2016年06月14日 1 个赞

我觉得还是找准自己的位置吧。
项目整体的分析不要过于笼统，问题是出在谁那里，向领导汇报的时候就点谁名，当然私下里该说也要说。
找到问题，给解决办法，QA 这边重点做的是什么，能不能或者怎么就可以解决这个问题。（领导想 “不需要你告诉我哪儿有问题，有问题落地解决呀，给我要我来解决么）
尽量不要给一些放之四海皆可的建议，这样的建议等于没有建议。
还有个很关键的问题，你说的这三条大建议，都很难落地执行，或者要投入很多的时间和人力。简单直接才是解决问题的王道，key 一个最重要的点，做出效果，再推进其他点

Nico #12 · 2016年06月14日 1 个赞

我觉得楼主在与人沟通方面有点问题，首先我看了你的文章以后，我真的不觉得有你这样的同事在公司会是一件愉快的事，我想你的老大你的同事也有大部分这么想。
作为测试在创业公司碰到问题我觉得很正常，如何正常的沟通显然是解决问题的捷径，像你这样去指挥开发做点事情，看似是善意的建议，实则会招来反感。

0x7C00 #13 · 2016年06月14日

@ycwdaaaa 支持你。人天生有惰性，工作时间久了，混日子也就慢慢培养出来。像你这样的负责和热心很少了，很多评论可能都是仅仅针对你的内容，换个角度看，可能更容易理解你的想法！

孙高飞 #9 · 2016年06月14日 Author

#12 楼 @nicoc 恩。我承认我沟通有问题。昨天没怎么想就发邮件了

孙高飞 #15 · 2016年06月14日 Author

#10 楼 @seveniruby 我现在还担心发这么个邮件是不是得罪开发同学了哈哈

andward_xu #12 · 2016年06月14日

关于用分支测试 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 会进下一个小时迭代版本 (可测)

孙高飞 #17 · 2016年06月14日 Author

#16 楼 @andward 额。这个是我没说清楚。因为是我发给开发同学的邮件。默认我们都熟悉分支策略了。其实我们的开发是在 feature 分支上开发完后 merge 回 develep 分支。然后我只测试这个分支的。而且环境也不是开发搭建。我自己可以在本地 debug 的，我都有 git 权限

andward_xu #18 · 2016年06月14日

关于在持续集成中提高自动化测试的覆盖率, 对于 java 的项目而言其实有一个效率问题。一个功能一般会有数次提交 (毕竟一个提交最好只做一件事情)，如果对每一次提交都要重新 build 来跑自动化，会花费大量时间在 build 和测试上，使得提交迟迟进不了 codebase。

孙高飞 #19 · 2016年06月14日 Author

#18 楼 @andward 嗯，我觉得还好吧。毕竟 UI 和接口都不是监控 git 分支变化驱动的。是定时驱动的，一天就跑那么几次。慢一点就慢一点吧。单元测试那，为了提升速度我是建议他们用 mock 把持久化层 mock 掉。这样就能快一点

孙高飞 #20 · 2016年06月14日 Author

#10 楼 @seveniruby 请教一下，我们现在项目刚开始，开发那边已经有 CR 流程了。开发的老大觉得这可以保证质量。规定严格的执行。顺便说一下我们是 toB 的模式。这样在早期就引入 CR 是会影响效率么？

思寒_seveniruby #21 · 2016年06月14日 2 个赞

#15 楼 @ycwdaaaa 不会, 只有那种办公室政治过多的公司才会有这种情绪. 研发是乐于看到测试同学积极的. 在发邮件之前, 你可以多跟研发的同学沟通下想法. 确认没有问题再发邮件. 这样可以了解到他们的想法, 从而提出更合理的建议. 不然研发同学看到你的部分观点不合适, 他一般不太好意思在邮件里面提, 就会留下一个沟通隔阂.