记10月20号贝塔咖啡的测试活动

lyfi2003 · 2012年10月21日 · 最后由 乔安迪 回复于 2012年10月23日 · 1346 次阅读

测试的体系建设

记 10 月 20 号贝塔咖啡的测试活动

周六, 晚上有同学聚会, 上午睡觉, 下午就计划去参加一下 sun 他们组织的测试活动, 事实上, 挺有收获, 在这里做一个总结, 分享一下我的见解.

BDD 到底如何?

作为公司推动技术改革的 MIC 同学, 为我们分享了公司的实践.

用一种新的方式肯定是发现了原有模式的问题, 我听到的 MIC 同学讲的是, 看到测试用例与需求, 与自动化之间的脱钩, 导致重复的工作, 自动化的难于实施. 而 BDD 是解决这一问题的方法.

BDD 以 cucumber为基础, 完成相关特性 (用例) 的编写, 利用二次编码进行自动化测试, 根据 MIC 的分享, 效果较为突出, 这也为我们尝试改进提供了很好的借鉴意义和相关思路.

这个过程关键环节我认为有:

  1. 如何保证 BDD 的基础上, 又让用例更为灵活.

    显然, MIC 采用了后者, 通过 Excel 的整合, 与二次编码 (想尽办法让需求人员或测试人员避免写复杂的正则) 简化这个过程, 让更懂自动化的人去完成编码细节.

  2. 如何推动测试人员在原有的习惯上完成这一转变?(其实对他们是变得稍不灵活了)

    目前的办法是强推, 习惯 3-4 天就好了.

  3. 不关开发们的事么?

MIC 分享说还没有去推动, 我认为这点会导致效果较大的打折扣. 不过就整个情况来看, 虽然没做这个, 效果还是达成的.

我的个人建议:

如果你也存在这样的问题,需要注意:

  1. 你必须能有很强的话语权, 否则难于推动.
  2. 流程规范远远比你的想法更重要, 也就是落实度要强.
  3. BDD 自动化框架要经过充足的预研和改进, 以更灵活的方式让所有人员接收这个观点.
  4. 推进到各个环节, 仅仅是测试是不够的.

QA 的下一步发展?

思寒 给我们的观点确实蛮新颖, 不过仔细想想以前也有过类似的思路点, 不过不够系统.

其主要观点是建立于 bug 容忍度高的基础上, 我们可以将更多的测试内容交给直接用户真实使用和测试. 而 QA 则向前和向后各努力一把, 将单元测试, 接口测试, 静态测试做的更出色; 向前建立有效的监控,反馈系统,甚至于自动报表系统, 让我们的工作重点更多放在容错,发散,性能等更需要思考的环节.

我的建议:

  1. 不是所有的公司都是这种方式, 尤其是 B2B 模式的公司, 我们的重点仍然在功能测试.
  2. 这个过程对 QA 开发能力要求很高, 又需要调度各种资源来实施前端的用户反馈收集, 不适用于目前大多数的 QA 团队.
  3. 如果你们的 bug 容忍度也较高, 不妨更多利用敏捷改善. 如何敏捷,这是接下来的话题.

敏捷项目的实施?

对这个话题是非常感兴趣, Tom 讲的也非常出色, 活跃了整个气氛, 讲的很带感:)

实施一个成功敏捷项目, 需要几个必备条件:

  1. 真正的持续集成自动化运转
  2. 需求可控
  3. RD 质量意识到位

所以, Tom 一开始项目的悲剧不可避免地上演了, 没有自动化的敏捷可以说是一个笑话.

没有准确的需求也就是像一个大楼从来不知道要盖成什么? 要是一不小心又成为 苏州的"裤叉", 难免被用户们批死…

我的个人建议:

  1. 这个工作不是 QA 一个人能搞定的, 想开始的时候要看好第 3 点, 选择优秀的 RD
  2. QA 的工作依然是"保姆", 不过更加主动, 控制需求 (偏测试), 实现持续集成的系统建设,推动团队的自动化建设.
  3. 你的编码能力要足够, 我更希望你会一些动态语言,比如 Ruby. 开展会快很多很多.

自动化的质量管理

SUN 今天准备的不多, 干货是较少的, 不过还是足以回想起我的公司进展, 我也有点想吐嘈两点:

  1. 总是看效果的领导不是好领导
  2. 不敢于承担风险的领导也不是好领导

这两点说起来简单做起来难. 自动化的推进是同样的道理, 过于关注 ROI 会适得其反, 浪费无谓的工作. 在自动化建设初期, 这一点更加明显. 与其关注这些, 不如:

  1. 培养合适的人才在合适的位置上
  2. 建立更加合理的激励机制, 并且根据不同时期进行调整

自底向上自发的推进, 走的弯路会更少.

其他

后来的 selenium 封装我就没有听了, 实在是时间有限, 相信这个是纯干货.

大家给我的感觉是十分的自在, 感觉是自己在这个组织很久了, 谢谢 sun, tom 等人的组织. 无以为报, 写一些听后感想留给大家回想一下吧.

对活动的建议是:

  1. 频率可以高一点点, 讲 slideshow 时间可以少安排一点
  2. 让大家多自由交流
  3. 地点其实不错, 就是不实惠, 建议固定一些, 没有水不要紧, 大家可以自备, 其他吃的也可以让大家准备.
  4. 论坛让大家用起来, 多解决一些实际问题更好

因为个人思维有限, 记忆也按自己理解了, 欢迎你路过踩踩评论.

最后也广告下我的博客吧: http://yafeilee.me, 偏技术些, 对 Ruby 有兴趣的可以多看下.
如果你是个极客, 应该从博客上可以找到我的相关信息:) 欢迎交流.

共收到 7 条回复 时间 点赞
匿名 #1 · 2012年10月21日

写的太好了。太赞了。

Mic 已经放我们好几次鸽子了,本来以为他很不靠谱,但是今天下午,他为了给大家补上测试用例。特地又折返了一次,真是敬业啊。让我彻底改变了看法,分享的内容非常的有价值。这也是业界少数能够成功而踏实的应用 BDD 并且取得不俗成绩的实践。

Tom 的讲解,激情四射,神采飞扬,勇于剖析自己曾经遇到挫折的项目,并能在后续积极的改进测试方法和测试手段,让公司的测试发展飞上一个新的台阶。tom 充满感情的分享,给我留下了深刻的印象。

John 的分享是最实在,最实用的,他介绍的 selenium 封装方法和问题场景,是现在大多数公司都遇到过的,sohu 成功的解决了这些难题,并打造成了出色的独居产品特色的 selenium 解决方案。从技术上,实践上,产品上,sohu 对测试的打磨真的是匠心独具。

这次我和 sun 的分享,只是给大家穿插一些测试发展的介绍。还有好几个非常好的资料和话题要跟大家交流,可惜时间有限,无法都展示了。

@lyfi2003
谢谢总结,写的真的很好
1、这次活动本来安排了三个环节,包括:主题交流、信息讨论和问题讨论,但确实因为主题交流的时间没把握好,导致了后两个环节并没有实施,这也是下次我们注意的地方,我们本身是一个小众交流,为的就是让各位认识测试领悟的前沿信息,领略各个大型公司的测试策略和方法,更重要的是结交朋友,所以,下次改进如下
1)会安排自我介绍环节
2)减少主题交流的时间
3)自由交流的时间会尽量安排的多一些。
2、很高兴能听到你十分自在的感觉,我们的目标就是不管是新人还是工作很长的朋友,只要你有心,很希望都能在这里找到一份大家庭的感觉。
3、这次的地点交通确实不便,也让大家破费,实在不好意思,以后的地点尽可能安排在公司的会议厅,免费而且交通较为方便
4、每次交流完后,都会根据来参加交流朋友留下的邮箱将交流名单发给各位,希望以后大家能够一起多多联系和互相帮助。
希望大家以后也关注我们后续的交流活动

另外,我分享的题目是:自动化度量分析,跟自动化质量管理还是有些区别的
我个人觉得:
我同意那说的两点,我说的那五个自动化测试过程:
1、初试
2、应用
3、定义
4、度量
5、管理
每个阶段有每个阶段的自动化测试策略,而我分享的度量分析,则是到了第 4 个阶段,在自动化初期就是先把事做好,初有成效,之后摊子大了,再回过头来关注度量和效果分析,刚开始由手工统计,后续建设一个大的管理平台去自动统计。

对于 BDD:
我由于之前接人,一直没有听得全面,但是我觉得跟我一个想法很想,就是帮助测试人员做合适的事情,他们懂业务、懂场景,就开发出一套框架和体系去帮助他们自由组装场景,而不是让他们去关注底层的语言之类。
我们要做的工作也包括基于每个人擅长的事情不同,分析如何让不同的人做自己适合的事情吧

学习了,对于新手来说,很多东西还是 “消化” 不了,逛了下 sun 和 lyfi2003 的博客,还是学到了很多东西,作为一个自动化的初学者,还是要从基础开始下手,工作中要戒骄戒躁,同时希望大牛们可以写一些初学者快速成长的文章分享下经验。

总结的很好,看来你们周六的活动有不少的干货啊,可惜我没能去……期待下次的交流

嗯,以前参加过不少沙龙,说真的感觉最舒服,最有氛围的还是这次。尤其看到大家都这么有实力,很是有干劲,虽然初涉 自动化测试,但觉得还是很有方向了,多谢 sun/seven 的组织和牛人们的分享!

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册