浏览器随想

//
关于开发流程

问题描述：一般的开发流程，开发人员做出正常功能很快，大量（几乎在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，即使不编译源码，也可以方便的调试）。

综上所述，平台型产品一定要有插件系统，而插件系统的成败在于是否开放、是否友好。