IFrame带来的Session问题

客户原来有个Web App系统A,我们要基于A开发一个系统B,但不希望B对A依赖太重,所以B被实现为一个独立的Web App(war)。A和B部署在同一个Weblogic server上,在A中可以导航到B,两个系统看起来像是一个系统。

有个小需求是,在B中希望显示一个页面,根据参数能展示出不同的信息。这个页面在A中已经存在,所以自然而然最快的方法就是在B中创建一个iframe来指向那个A中的页面,配以不同的参数,多快好省!

问题很快出来了,QA发现那个iframe中的A页面很快就会session timeout,然后会提示用户输入登陆用户名和密码,而iframe外的B session并未过期的。

问题在于A和B实际上还是两个Web App,各自有各自的session。因为不能简单地修改A的页面,让它保持session不会timeout,所以剩下的办法只好是控制B的session timeout时间要早于A了。还有什么更优雅的方法呢?

如果给我一次重新实现的机会,我宁愿自己画一个属于B的页面,而扔掉iframe。

另外一个需求是,A和B是各自独立的Web App对于用户是透明的,用A的用户登陆进来可以直接进入B,反之则不可以。解决办法有点tricky,A的contextRoot设为/,B的contextRoot设为/XXX,这样二者的servletContext为同一个,即可实现A把自己的loginToken放到servletContext中后由B访问到,从而在请求B页面时,检查是否能取到servletContext中的loginToken,如果不能则转向到A的登陆页面,这点由Filter来实现。

Share
 

事关挪卡(Moving Story)

最近我的team频繁遇到关于挪卡与否的事情。

可能会包括下面其中一种情况:

  1. 一个Story在前一个迭代做完了,但是客户没有及时sign-off,导致后一迭代中客户发现Sotry实现有问题,不是自己想要的东西,需要重新实现。
  2. 一个Story在前一个迭代做完了,客户已经sign-off,但在后一迭代中我们发现实现中设计有问题,会引发其他的bug。
  3. 一个Story在迭代中实现完毕,进入In QA,但发现有重要的AC没有事先提出来,导致需要补充实现。

可能还会包括其他可能的情况,不一一列举了。

我们team的对策分别是:

  1. 新开一个Story卡,对有问题的部分重新实现。这里的问题在于没有及时从客户那里取得反馈,原因自然有多种,你懂的。
  2. 新开Defect卡,对发现的问题进行修复。
  3. 直接在当前迭代中,把Story卡挪回In Dev,补充实现。但不会修改点数。
Share
 

Pair的节奏

这篇只想说说我对Pair节奏的理解。

Pair是需要节奏的,为什么?最简单的回答是,没有节奏,两个人都会很累。我有体会,跟team另一个新TWer一起pair,两个人会不由自主地坐在屏幕前,切分任务,你写测试我写实现,一动不动坐了整个下午,除了上厕所的时间。可想而知,离开办公室的时候那个疲惫。

不是说Pair就会比一个人“裸奔”轻松,恰恰相反,Pair就会比较累,这是无数人经验证明的。但是我们仍然需要在Pair时控制一定的节奏,不仅仅是为了减轻疲劳。

最直觉的反应是,疲劳会影响对问题的考虑,测试的覆盖度,代码的质量,这在一对Pair都疲劳的状态下,也不能免俗。当疲劳把Pair能带来的那些个好处统统赶跑后,Pair还有何存在的意义?

一般来说,对Pair经验比较少的人,节奏可以由Pair经验多的人来控制,如何划分任务,粒度以及驱动测试开发的频度如何,都可以依据Pair的双方的能力和经验对比进行安排。在划分任务和思考时,可以以提问的形式,互相提问回答,推动进度。实现代码时,可以以乒乓的形式,由一方来编写测试,另一方编写实现,并跨任务轮换,让双方都感觉到Story的实现在有条不紊地前进,充满自信。双方可以约定在一个小时左右的时间,进行一次短暂的休息,切换context,以确保有持续的精力投入后续的Pair。

因为Pair是两个人的事情,当一方因为某种原因感觉到疲劳,或者被第三方事情打扰,不能集中精力在pair中时,可以主动跟对方提出中断,以换取集中的注意力在Pair上。

如果Pair对于某个问题或技术都不熟悉,并且在可遇见的时间内无法解决,应该立即寻求有经验同事的帮助,或者暂时放下留待后期解决,坚持钻牛角尖无疑是破快Pair节奏的杀手之一。就我的经验看,Pair时钻牛角尖的几率很小,在一方出现端倪时,对方会明显感觉到并主动提出来跳出这个圈子,这应该时Pair时一个小小的好处吧。

至于可能破坏Pair节奏的另外一个杀手——两人就问题或技术有争执,一般会发上在没有较多Pair经验的人身上,这会是另外一个话题,涉及到Simple Design,徐叉教导我们,要用代码证明自己的观点,要反过来关注问题本身。

Share
 

Pair时的心态

为什么我们需要pair programming,以及pair有什么好处,不是这篇文章要说的内容,关于这些方面,网上能找到的太多太多。这篇只是想说说对于pair中心态的问题,我在pair时的体会。

对于有过开发经验的人来说,离开几年来一直专属自己的那个格子间,坐到一张开放会议桌边写代码,旁边还坐着自己的pair,度过半天甚至一天的开发旅程,并不见得都是一帆风顺的过程。

每个人有自己的开发经验、背景和知识,成为pair就要为Story的代码质量负责。怎样合力以解决问题产生代码,是需要彼此Open心态,针对问题解决问题,而不是:

  1. 妄自尊大,容纳不下对方的观点
  2. 对对方不闻不问自顾自操作机器
  3. 炫耀自己的知识面而鄙视对方
  4. 甚至出言不逊,伤了对方还浑然不知

这是一个成长的过程,也是一个自我剖析让自己更open的过程。所以我们一般会安排由具有丰富pair经验的老同事带着新同事一块来pair,还会有乒乓和keyboard-mouse方式来控制pair的节奏。在知识传递的同时,逐渐打开每个人闭锁自我的心态,逐步提高pair的效率从而提高team的velocity。

从小处看,这是个人心态改变的过程,从大处看,这是开发文化不同导致的诉求。

Share
 

Automation Training For TW QA

今天作为酱油党之一(徐X语,还有小刀和LeoShi同行)参加了徐X为TW QA开的Automation Training。

对于Ruby小白的我,跟着QA一起学了一把。

  • Ruby的包机制,应用的配置环境
  • Selenium RC的原理,包的四个变种。
  • 在07年就提到过的Page Object

自动化测试具备怎样的特质,才能最大限度的减少QA手工测试的工作量?

  1. Effective
  2. QA manageable

最后,徐X介绍了几个月前他研究出的Data Flow大法。简言之,测试不是要去测试事情本身,而是要测试事情结果的确发生。听着象废话,但那张精美手绘图却惊艳得不行。用以作为切分并归纳测试案例的依据。很受用,争取撺掇一篇文章出来。

Share
 

OO训练营第二三课

这两节课徐X给出的问题是,用代码表达在停车场停车的模型和逻辑。

首先,还是任务分解。分解出任务列表的样子,取决于对程序架构的理解。理解不同,导致划分出来的任务列表也不一致。但要保证每个任务能够衍生出1-2条可以测试的子任务,变成代码。对于测试任务的设计,既可以从状态变化上来考虑,也可以从行为上来考虑。而且,由分解出来的任务列表,可以反推出需求是什么。

课上有一对pair最后没有完成测试及实现代码,原因在于双方对各自的实现方案争执不下,被徐X拿来教导我们:在这种情况下,要放下争执,去还原真实的业务场景和需求是什么,来解决实际的问题。

总会有分别都是正确观点的双方在争执,就像民主之于正义。这个时候我们要evidence over opinion,通过代码来表达自己的观点。

最后,徐X再度施展重构神技。

Share
 

OO训练营第一课

今天下班前,开始第三届OO训练营的第一课。

本来觉得应该没什么,结果课堂上大家窘态尽出,会写代码不代表面向对象代码写的好,事先不写测试,直接上实现,情何以堪呐。

一些重点:

  • 代码是写给人看的,不是给机器的。代码是用来表达和传递知识的。
  • 对于可度量的对象,有几个属性(比如相等性和可描述性),可以作为分解任务的依据,并据此编写测试。比如长度(Lenght)的Equality,如何判定是同一个长度对象,如何比较不同的长度对象。
  • 测试优先开发,划分出可测的任务是关键,即所谓Testability Driven Tasking。
  • 模块化最重要的是封装实现的细节,对类细节的访问要封装在类上下文中,这是最最容易忽视的bad smell。
Share