//
关于开发流程
问题描述:一般的开发流程,开发人员做出正常功能很快,大量(几乎在3倍以上)时间花在解决相关问题上。假设过程如下(都是相对时间),3天开发结束,给测试,由于部门
或人员协调上的成本,1天后才开始测试,2天后答复开发问题何在。这个报告错误、修复错误的过程平均每个功能点要迭代3次以上。其中基本问题(即通过简单培训,可消灭在开
发阶段的问题)花掉的时间占绝大多数。因为开发往往同时兼顾多个项目,而且写程序是个完整的思维过程,当时发现问题,环境和思绪都集中在上面,可以很快解决。如果过段
时间再提出来,要重现当时的环境,脑子转换回去,费时费力,劳心劳神。相信很多开发人员都有过如此经历。
在这个场景中,如果提高初次交付质量,降低测试和修复迭代时间,一可节约成本,二可提高质量(由别人在第二时间指出错误,和自己在第一时间发现错误,修复结果显然不同
),三可改善测试与开发的合作情绪。以个人所见,不成熟的开发与测试之间的关系一般算不上融洽。开发有时会瞧不起测试,或命令测试。感觉他们做的都是没有技术含量的,
只会找一些明显的问题,而不能找到甚或定位深层次bug。从测试角度讲,当初次交付的软件质量不高时,理所当然是先找明显的bug,几次报告修复的迭代过去后(每次迭代都有
额外成本,也就是人员之间的沟通成本,如果跨部门,成本还会显著增加),时间无多。通常最后的情况是,迫于计划里程碑,只能牺牲质量或功能之一了,我看更多是牺牲质量
,因为功能显而易见,而质量则是公说公有理,婆说婆有理,一时半会儿显不出来。发布之后,大量隐蔽的问题由网友发现,产品部门觉得开发水平不行,研发部门觉得是测试部
门没发现问题,责任不在己。久而久之,恶性循环产生了。
我想针对这个问题,能够改变的是,减少迭代中的基本问题(即由开发人员把基本问题消灭在萌芽中,提高初次交付质量,我称之为完整性开发),给测试留更多时间发觉隐蔽问
题。把用户的测试工作转移给测试部门。测试提的问题水平高了,研发主观上不轻视。提的少了,研发压力也变小,毕竟天天被一堆bug追着谁都不好受。合作水平和效率也会相应
提高。那么如何提高初次交付质量?即完整性开发?我的方法是,开发也用Test Case,为了减少开发人员的抵触(毕竟国内技术界总有种轻视测试的氛围),也可称作Develop
Case。内容包含两方面,一是功能点,而是健壮性。举例来说,一个自动更新的客户端模块的Develop Case是:
/
功能点:
1.程序启动后每两小时检查一次有否新版本。
2.如果有,则下载。下载完毕后,提示用户已下载,需要更新请重启。
3.重启后更新到最新版
健壮性:
1.改为每1秒中更新一次,多次打开关闭进程,有否问题。实现时用了锁保证更新唯一实例,因此需要检测。
2.下载到一半时,进程崩溃、网络断开、服务器当机,有否问题。
3.第二条发生后,再次启动程序,更新是否能够继续正常工作。
4.用新版文件覆盖旧版文件失败时,能否正常处理,例如回滚到之前版本。由于木马和流氓泛滥,此事不得不防。
5.配置文件中的斜杠缺失、反向时是否正常。例如http://xxx/ver2/,http://xxx/ver2/,http://xxx/ver2。因为文件由人编辑,这些情况均可能出现。
............
/
开发人员的产出应该是产品 + Develop Case。系统复杂了之后,一个小问题可能隐藏的非常深。相信很多人都有过类似经历,出现一个问题,花绝大数时间重现、定位,最后发现
原来是没有判断空指针,中文处理不对,等等让人拍完额头拍大腿的问题。其实,这些问题大多可以扼杀在萌芽中,方法就是针对小模块小组件的边界、极限、异常测试。当每个
组件都是健壮的,整个系统才不会变的千疮百孔。
Develop Case还有另一个好处,重复利用,让人更轻松。修复老bug之后引入新bug是不可避免的。在没有Develop Case的情况下,让开发人员修复完问题后自己检查有没有引入新
问题,很难。把所有功能点和健壮性涉及到得点都回忆一遍,实在是件批量死脑细胞的事儿。通常修复之后引入的问题,只有测试才能发现,但这会再次带来迭代成本。如果有
Develop Case,问题会简单不少。因为已经用过一次Develop Case,做一件熟悉和无需动脑子的事情,谁都不会太抵触。如果开发人员自己发现新引入的问题,就整体上而言,效
率一定是提高了。
个人对两个项目实施过完整性开发,效果非常好。测试发现的都是深层次问题。开发人员一开始有点抵触,当感受到好处之后(那么多bug追在屁股后面,谁会开心呢),态度改观
。
有人会说开发做了这些工作,测试做什么?问的好,测试的工作确实减轻了,但他们减去的是劳动价值较低、简单重复的工作。留更多时间给他们发现深层次问题,给他们加上本
由我国网友做的稳定性、健壮性测试工作不是更好? 而且健壮性测试,没有开发参与不行。同一个功能,不同的实现方法遇到的健壮性问题差异很大。如果一线研发不做,没有人
能替代他。
具体实施时,因为我的小组实行结对编程,一个人会聆听另一人的设计,review他的实现,写Develop Case时,由一人主写,另一人补充。对于星型小组(一个leader,多个组员
),我想由leader帮助审核Develop Case也是不错的方案。
再说一下测试如何才能发觉隐蔽问题。个人认为,这种能力需要培养,有经验的测试人员更容易发现隐蔽问题。谈一下个人经验,一般情况下稳定性、健壮性是隐蔽问题多发地带
。但稳定性、健壮性不是那么容易测试的。比如连续开1万个网页,凭人的力量显然无法做到,一上午专心致志也就百十来个。这时巧妙 利用自动化工具是很好的,比如模拟精灵
可以模拟键鼠操作,我曾经用它连续测试上万次重复发送邮件的过程,从而轻松复现测试很难定位的问题。LoadRunner测试Web压力很合适,这里不提。如果没有现成的工具,开发
人员应主动或配合测试开发测试工具,比如连续切换Tab签的小工具。类似这类工具都是可复用的,产生之后可以不断地使用,对于一款目标存活2年以上的产品,我认为是物美价
廉,可以批量选购。
执行流程。
由测试牵头和开发、产品一起给出测试单(其中的功能点、健壮性即为Develop Case)
1.功能点。
没什么解释的
2.稳定性。
海量数据、长时间运行。开发新模块新功能时,测试人员牵头,开发人员辅助,给出稳定性指标。比如广告拦截功能。其稳定性在于拦截超大页面(如51job首页)时是否依然正常
,连续拦截(1万)网页是否依然正常。
3.健壮性。当某部件出现问题时保证整体健壮。
这由开发人员在开发过程中逐步补充,因为实现方式不同,其涉及的点也有很大不同。 如断网、某进程崩溃、某COM组件无法加载、某DLL缺失、网络时断时续、网页本身语法错误
等等。开发新模块新功能时时,由开发人员给出边界条件。举例来说,翻墙功能,1) 当服务器当掉,取不回代理列表时 2) 代理列表超大或为零时 3) 数据库存在中文 4) 某代理
无法连通,等等。
/
//
用户细分:高端(10%),普通(90%)。但话语权在高端手中,而国人从众心理很强,所以产品策略上可以适当着重高端。列觉几个我认为符合高端的功能,
1) 翻墙,一些人喜欢去国外溜达,看看财经,政治之类。如果Sogou因为ZF原因不能做,可以透过插件系统瞒天过海。
2) 网络收藏夹。两头办公的塔尖不少。
3) 安全。比如反钓鱼、反XSS,这是应用层面的。虚拟机,这是本地系统层面的。
4) 稳定、健壮。怎样做到?这里保留藏私了。有兴趣的话请访问我的blog或当面交流。
另一种细分,老年用户,普通用户,儿童用户(13岁以下)。
1)老年用户,我认为应该以45岁而不是一般的60岁来划分,对于互联网,45岁以上的人和60岁以上的人一样,都是网盲。中国已经进入老年社会,2010年将达到12%。如果以45岁划
分,比例更惊人。现在的社会45岁以下是生产消费主力,他们想孝敬老人,但不知道该如何做。上网很有趣,老年人听着很热闹,但限于水平,条件,难以上手。如果能够针对这
部分人群做产品,市场容量会很大。另外百度做了老年搜索,也是另一种印证。
2)儿童用户,个人认为最需要同时也是最被忽略的用户是儿童用户。美国的儿童游戏网站,企鹅,其使用人数比魔兽世界还多。我想保证他们的身心不受无所不知的互联网侵害,
也是一条不错的思路。具体到产品,实时监控(父母随时可得知孩子上网情况,实现细节为只允许搜狗浏览器+登陆+远程控制软件+P2P),不良网站过滤,浏览记录等,延伸开来
,请专家讲解如何应付孩子接触黄色文化,引导小孩,进而可形成一个有粘性的父母社区。
用户种类多种多样,Sogou的独立播放视频就很好,迎合了大量上视频网站看电影、连续剧的网民。
产品策略上,Sogou比IE、FF和其他原装浏览器有优势,更能捕捉本地用户特征。像Foxmail一样,做好用户体验,应该能跟IE、FF一搏。
对于开发人员,具体实现应该借助插件系统。将各个功能独立、相互之间透明。以个人经验,功能之间越扁平、越独立,用户理解、使用成本越低,其维护成本越少;功能越复杂
、交叉越多,用户理解、使用成本越高,维护成本越高,而且是指数级增长。相较一锅粥的实现方式,插件系统灵活,用户教育、使用成本更低、研发维护成本更小。
/
//
关于Firefox:目前PC市场上的浏览器,综合易用性、稳定性、性能,以FF居首,而且国内高端用户用FF的很多,也经常表达他们自己的观点。但FF的占用率始终无法提高,也就在
2%上下徘徊。究其原因,我想是FF与IE使用习惯差异过大,心理学上讲一般人有稳定效应,反正IE不是太差,还能用,我就用这个吧。另一个原因是,FF不支持ActiveX,而大多数
普通用户需要这个功能,网银、淘宝、支付宝都使用ActiveX。但对于无内核浏览器,则可以集中两者的优势,充分利用优质FF内核,IE上的ActiveX。日本有一款浏览器,实现了
IE、FF、Opera内核的无缝切换。因此在利用多核心的技术实现上,应该是可行的。从另一个角度讲,如果依赖IE核心,容易头重脚轻,万一哪一天IE不允许商业化集成WebBrower
,或市场情况突变,IE核心系口碑很差,就不好处理了。我想九城算一个反面例子,暴雪收回了代理权,九城瞬间风雨飘摇。这个例子并不完全合适,但把鸡蛋放到一个篮子里,
我想还是能避免就避免。
个人认为Firefox内核非常好,我用满一年,没有发生一次死锁,崩溃。一些社区(比如cnbeta)里也有大量类似观点。
其插件系统是其他浏览器追赶的对象,个人认为Chrome的产品设计做非常好,简洁好用,性能也不错。但现在google也意识到缺失插件系统的损失如此之大,已经在着手插件系统
。遍观目前的平台型产品(冒昧地认为Sogou的战略也是做平台型产品),老牌的Windows就不说了,iPhone有AppStore,Android有Market,Facebook的F8。我想他们的选择很有道
理,互联网时代,网民个性可以得到极度满足,我认同长尾理论,累加起来的小众需求远超大众需求。任何一个公司靠自己的实力,让一个平台满足如此庞大的小众需求,都是心
有余而力不足的。插件系统正是满足小众需求的倚天剑。
对比IE和FF的插件系统,优劣立判。IE主要是BHO、MIME Filter、ActiveX。BHO其可以改变浏览器操作流程,但界面表现单一,只有固定位置的按钮、菜单。另外一个是MIME
Filter,即对网络内容的过滤。但除特种应用,比如广告拦截、流氓插件外少有应用。ActiveX不错,增强了网站功能。但他们的劣势是,三者均只支持C++等复杂语言,开发难度
和成本很高。想必在这段时间的招聘过程中有体会。因此只有少数大公司、特殊公司为其开发插件。比如Adobe的Flash,银行网银ActiveX、Web迅雷。
反观Firefox,其插件系统更为开放和友好。
1.插件界面
界面框架是XUL。可在任何地点插入、修改界面元素,而无须改动原文件,界面描绘用xml,动作响应采用javascript。开放,因为可在任何地点插入;友好,因为javascript +
xml,其开发难度相较C++等降低了一个档次。
2.插件功能
插件功能大多由javascript完成,比如按钮点击响应,DocumentComplete事件响应,操作浏览器(如切换标签,触发事件)等。Javascript不好做到的事情,XPCOM(C++实现)可
以代为出手。
Firefox包含几个子系统,均为开源:
1.XUL ———— 用XML描述界面,提供常见界面元素,比如按钮、下拉框、菜单、工具栏等等。
2.SpiderMonkey ———— Javascript库,实现Javascript语言元素。不包括document, frame, window之类,它们由Firefox框架实现。
3.XPCOM ———— 类似COM的架构,优势是可用Javascript实现一个XPCOM组件。提供了不少基础类,线程、同步、网络、Document、DOM等。
4.主框架 ———— 骨架,组合使用了上述三个子系统。
Firefox的插件非常多,包括功能强大的Firebug,普通用户喜欢的换肤插件,广告拦截,等等。其开发团队都不超过4人,多数插件是一人独立完成。我想FF插件系统成功的原因主
要是,界面表现丰富,开发成本低,还有杀手锏,开源,一旦有问题难以理解,阅读源码,调试都很方便(Firefox公开了私有pdb,即使不编译源码,也可以方便的调试)。
综上所述,平台型产品一定要有插件系统,而插件系统的成败在于是否开放、是否友好。
浏览器随想
最新推荐文章于 2024-08-14 23:30:00 发布