QClub的测试专题活动和奇遇咖啡的rails活动小记

阅读更多

昨天下午去参加了infoq组织的qclub，是百度赞助的，第一个讲座是百度的工程师讲解“自动化web测试”，我到的稍微晚了一些，没听完整，大概了解了一下的一些信息：

 

• 底层使用的是selenium框架，之上有做了一些封装，做了一个框架，还有一个ide，可以用比较接近自然语言的方式定义测试用例。比较有特色的是有一个UIMap，把一些比较可能变化的部分放入这个UIMap里，变化来了以后修改这个Map映射就可以了，一般界面上元素的id或name是基本不变化的。
• WEB自动化测试只是给基本的业务流程提供一个安全网，主要目的不是发现bug的，覆盖率不高，有些人工更方便的使用人工测试好了。从提问的环节得到的信息，其实百度各个组对于WEB自动化测试的覆盖率没有硬性的要求，好一点的可能达到20-30%的样子。
• 除了一般的断言，可以通过截屏的方式验证结果——这个没弄懂怎么自动化。

第二个讲座是ThoughtWorks的员工讲TDD，这个我了解多一点，主讲人主要是在编码演示，感觉很好，下面是我个人的一些感受：

• 首先保证代码的可读性这个很重要，虽然在讲座上没有强调这一点，不过我发现TestCase中的代码要清晰简洁且尽量接近自然语言的描述，实现的细节隐藏到其它的方法中。这就对方法的命名要求很高，在没有想好好的名字前为了表意明确方法名可能会很长。
• 上面说到要隐藏技术细节，采用的是PageObject模式，有一个navigator（webdirver）来负责导航，另外有若干个page对象，比如通过xpath寻找元素的操作都可以封装到page对象中，这样TestCase中调用这些page的方法即可。
• 最好采用自上而下的方式进行TDD，可以强迫你从需求和接口的角度考虑问题。
• 尽管TDD强调在编写任何功能代码前都要先写测试，不过对于WEB测试来说由于运行一次的代价比较大，所以可以先在TestCase里列出场景，而不写任何测试代码，这样先让这个TestCase作为一个文档的作用存在。——其实我比较怀疑Web层做TDD的必要性，最后我觉得作为和BA沟通的文档比测试本身更重要。讲师也强调了和QA以及BA沟通讨论的必要性，有些不是很重要的小功能可以不写TestCase。
• 演示用的是Java环境，主要是spring mvc，当然理论上tdd和具体的语言无关。
• 我很喜欢现场编码演示的方式，讲座的核心目的是要证明TDD不是玩具，现场演示一下觉的说服力比较强。IntelliJ IDEA和mac用的很溜儿，是水平高还是工具好？应该是二者都有吧，流畅编码才不会影响思维，这也是我一直在努力提高的。
• 到场的一半儿多是测试人员，对TDD不了解，但是对TDD的热情很高。

两场讲座完了以后是一个交流环节，参会人员分为十组，选出一个组长讨论一个话题。我有幸和六个女生凑成了一组，只有我一个男童鞋所以我做了组长。她们基本上都是做测试的，只有我是做开发的。我们组没确定什么主题，我是想让大家每个人聊一下自己的经验和工作中测试已经TDD的情况。

• 我没有预料到的一点是现在很多公司的测试自动化和覆盖率比我想象的要高的多，现在大家对测试和产品质量都很重视，对好的工具和方法都表现出极大的热情。——当然，因为主题是测试，那些只有开发人员没有（或很少）测试人员的公司可能没人参加这个活动。另外，我们公司的架构部门、项目管理部门和测试部门 要吸取经验了，测试计划不自动化的情况应该做一些改进了，还有即使不能TDD，也尽量考虑一下架构的可测试性，UnitTest总要多写一些吧。
• 在微软测试的一位童鞋告诉我他们有的项目组最高可以达到2:1的测试人员/开发人员的配置比，我一直以为我们将近1:1已经很高了，当然这也和微软以及他们做的软件的特殊性有关系。
• 后来我们组加入了一个ThoughtWorks的员工，然后大家开始轮番请教问题（ThoughtWorks的人到哪里都会成为焦点，无比嫉妒羡慕佩服……）。有人问道需求变动太累害是不是不适合TDD，其实TDD本来是应对变化的，理论上更应采用TDD，我理解提问者的意思是那种面目全非的需求变化，你的TestCase都一点用处没有了，还怎么保障你功能的重构——ThoughtWorks的童鞋说出现这种情况应该考虑是不是在需求或BA那里出了问题了，应该不是TDD本身的问题，虽然这个答案有点含糊，不过确实如此，为什么会出现翻天覆地的需求改变呢？——业务没理解透或没搞定客户？我问了一个问题是非常简单的功能是不是可以不写TestCase，答案是可以不写，我又问如果可以不写，那测试覆盖率低了以后我怎么知道是不是核心业务开发人员也没有写TestCase呢？答案是这样的：应该雇佣好的开发人员。我在最后总结发言的时候开了个玩笑：需求变化太大不适合用TDD，是BA的问题，不能或不用写单测试人和团队的问题，反正TDD是没有问题的——其实我想说的是TDD做为敏捷中的一个实践环节，它必须有其它方面的配合，不能对一个实践给予太高的超出他能承受范围的期望，从上面两个问题可以看出它至少需要一个好的需求和业务人员的管理配合，需要一个水平不错观念统一的团队，需要雇佣那些对自己该写而没写TestCase的行为有非常强烈恶心感的人。（TDD和单元测试不是一回事儿，我发现我开始模糊这两个概念了，不过连单元测试都不会的人就不用提TDD了）。
• 最后各个组长发言总结，大概都是两个意思——测试很重要；TDD很好不过用起来还是有些难。我也代表小组总结了一下，得了一个百度发的U盘，感谢一下。这次活动组织的比以前的好很多，感谢一下infoq（小霍童鞋对自己这次的组织也很满意，笑的肚子都疼了）。

============================================================

结束后我和活动上认识的两位朋友去了奇遇咖啡馆（IT界据说挺出名的一个咖啡馆，不过用户体验做的有一个缺点，我们半天没找到门）参加一个关于rails的沙龙，主题是怎么把一个大的rails应用分解成多个小的应用，实践来源于 Idapted 的EQ英语 。用一幅图概括一下：

 

我感觉主要是将应用模块化，关键是各个应用之间的通讯：

• 通过只读数据库。一个应用只能读另外一个应用中model对应的表，不能写。
• 不同应用需要写可以通过webservice。
• 页面集成，可以在页面通过rails的ajax fragment嵌入其它应用提供的页面片段。通过修改nginx的配置，所有应用处于同一域名下也就解决了ajax跨域的问题。（各个片段有点像portalet？不过不能通讯，只是显示）

session是保存在一个数据库里共享的，这就实现了SSO。有一个Core应用负责通用的功能，比如保存一些metadata，比如基于角色的权限控制也是在Core中管理（Core中保存有各个应用Controller的元数据，然后把各个Controller和角色对应起来）。最大的好处是：

• 模块化使得开发变的容易了，开发一个应用可以独立的配置管理。现在他们已经有20多个应用了。当然，讲座中提到，粒度的划分很重要，要尽可能少的在应用间通讯。
• 模块化有助于提高部署和伸缩性。那个应用访问量大的时候就可以给它多分配资源，主要是现在内存等资源很便宜。我个人觉的可能还有一个好处，比如我可以将个别应用升级到rails3而不影响其它应用

总之都是模块化的好处。

我对rails知识略知皮毛，大体上看到了这个架构，我的脑子里突然冒出很多东西——SOA、云计算、ESB、OSGI（Spring DM）……当然这是一个公司的私有架构。

我提了一点想法，如果各个应用（或叫模块）的依赖关系在配置一下，那可以给开发和部署带来一些便利……oh,my god，这不是maven的想法吗？

晚上10点才到家，又热又累，不过还是蛮有收获的。

PS：两场活动除了人之外，看到最多的就是Mac Book pro……还看到好几个iPad，无比嫉妒羡慕佩服流口水……

 

• 
• 大小: 26.7 KB

• 查看图片附件