bitixiaoshu的博客

第一张：出生一天之后

脸上的胎毛清晰可见，呵呵

第二张：

一脸疑惑的看着这个世界……

第三张：换尿布中的一幕

可爱的小肚脐儿

第四张：宝宝会游泳喽！

第五张：游泳的时候投拍了他的小屁屁

第六张：宝宝的大眼睛

第七张：宝宝打喷嚏，河东狮吼啊

最后一张：宝宝喝奶，妈妈营养之外还得再来点

1.问：是否带有镭射防伪标签？
答：部分镭射防伪标签，部分外销款式无防伪标签

--------------------------------------------------------------------------------
 
2.问：地垫是否有浓厚的刺激性气味？
答：包装拆开时候会有一点气味，但不会很浓，而且一会就散，原因是密封包装，出厂时候没有完全散味导致。其次迪斯尼地垫均为EVA发泡形成，原则上做到完全无味实现不了！但绝对是无毒环保型。

--------------------------------------------------------------------------------
 
3.问：什么样款式可以拼一起？
答：同规格的可以拼一起，规格可以分31.5*31.5*1 30.5*30.5*1 60*60*1 30.5*30.5*1规格不可以和其他2个规格拼一起，60*60可以和31.5*31.5拼一起，60*60一边拼2片31.5*31.5的。也就是说一片60*60相当于4片31.5*31.5规格的地垫

--------------------------------------------------------------------------------
 
4.问：地垫为何有点的厚有点薄？
答：地垫全部为机器全自动生产，会有误差，并且地垫是类似泡沫重压以后会有点扁，厚薄相差不大均为正常！

一、企业介绍

嘉宝日用制品有限公司是专业的压克力（有机玻璃）产品生产厂家，有着10多年的压克力生产经验及专业的技术研发人员，有自己的模具生产车间，开发能力十分强大。所采用的进口原材料获FDA美国药物食品卫生认证。所生产的产品透明度高，折射性强，不易破碎，有仿水晶的效果。产品通过国际质量认证机构SGS的质量认证。
　　 主要生产项目有餐台系列、厨房系列、卫浴系列、礼品系列，现又推出一新系列--高雅透亮的压克力双面镜。
　　 由于开模技术精良，设计新颖及一直以“顾客至上，品质第一”作为嘉宝日用的服务宗旨。我厂产品远销日韩、欧美 及中东各地并赢得顾客的一致认同。二、材料介绍

① 材料名称：进口压克力（俗称有机玻璃） 化学名：PMMA

② 材料原产地：日本进口

③ 材料耐高温80℃ 耐低温﹣20℃

④ 特性：不易破碎，不易刮花，透明度高，折射性强，有水晶的效果，折射有七彩光，用旧后可越洗越亮。

⑤ 卫生认证：有美国FDA，欧州SGS最高卫生权威机构认证，对人体绝对无害，是现代国外最流行的日用产品材料。

FDA——美国药物卫生检验局。

SGS——欧州最高权威卫生，质量检验机构。

三、使用方法

① 清洗：用温和的洗洁剂，加较软的清洁用具（如：海绵），加水轻轻擦洗即亮丽如新，忌用硬物（如：钢丝刷）来刷洗。

② 不建议长期放在冰箱内使用。

③ 不建议长期放在离明火1米内使用。

④ 不能放在洗碗机及烤炉内使用。

⑤ 如使用时用80℃以上的热水接触产品，产品会出现裂纹，出现裂纹后对人体仍无害。

核心提示：【新民网·独家稿件】一篇名为“公布乐扣乐扣的真实价值”的帖子在网上被频繁转载，网友自称从事外贸行业，某日偶然看到乐扣乐扣商品的进口报关单，其中600ML的乐扣乐扣杯子在超市里卖26元人民币，然而该产品的进口到岸价只有0.61美元(按美元兑人民币1:7.86折合约3.22元人民币)。

【新民网·独家稿件】近来一篇名为“公布乐扣乐扣的真实价值”的帖子在网上被频繁转载，发布该贴的网友自称从事外贸行业，某日偶然看到乐扣乐扣商品的进口报关单，其中600ML的乐扣乐扣杯子在超市里卖26元人民币，然而该产品的进口到岸价只有0.61美元(按美元兑人民币1:7.86折合约3.22元人民币)。另外，该网友还指出乐扣乐扣的产品材料是聚丙烯塑料加上硅胶密封条，这些都不是高档材料。

　　上海乐扣乐扣贸易有限公司就网友提出的疑问专程向新民网发来了声明(如下图)。

　　乐扣乐扣:产品定价不以进口报关单为基础

　　名为“公布乐扣乐扣的真实价值”的帖子中还写到“在超市里标价26元的600ML的乐扣乐扣被子，进口到岸价只有0.61美元，加上关税增值税，最多成本不超过8元人民币”，针对网友依据乐扣乐扣的进口报关单而对乐扣乐扣销售价偏高的质疑，乐扣乐扣的公关公司上海伟达公关的许小姐表示，乐扣乐扣的进口报关价是商业机密，不方便透露。另一方面，许小姐认为，网上针对商品价格偏高的质疑贴很多，不排除竞争对手在背后进行操作。

　　上海乐扣乐扣贸易有限公司向新民网提供了长达5页的报告中称，“乐扣乐扣保鲜盒是由韩国海纳开碧公司制造的，作为韩国的第一高档品牌，05年乐扣乐扣在韩国的市场占有率达到71%，在韩国排名第一。”据伟达公关的许小姐介绍，乐扣乐扣在中国销售的产品全部系韩国生产的全进口产品，虽然在山东威海有一家生产基地，但所生产的产品全部用于出口。

　　至于乐扣乐扣保鲜盒的产品定价，许小姐表示乐扣乐扣保鲜盒的销售价格主要依据两个因素，一个是依据国家相关部门的定价指导标准；另一方面是依据消费者的接受程度。许小姐认为，网友帖子中提到的产品进口报关单上的价格，并不能作为该产品定价的依据。

　　乐扣乐扣材料低廉遭质疑

　　该网友还在帖子中指出“乐扣乐扣就是聚丙烯(PP)塑料加上硅胶密封条，这些都不是高档材料。”在上海乐扣乐扣贸易有限公司提供的“乐扣乐扣品牌简介”中显示，“乐扣乐扣从0.1升到12升容量，共有200多种大小不同的保鲜盒产品：包括普通型、高档型SM系列(色拉盒系列)、水壶系列、一键式保鲜盒等产品。”其中高档型使用的是聚碳酸酯材料，盒盖和盒身之间有一圈“中空型硅胶条”填塞，而其他类型的乐扣乐扣保鲜盒材料均未指出。

　　聚丙烯无毒、无味，可在100度左右使用.低温时易变脆、不耐磨、易老化.常见的酸、碱有机溶剂对它几乎不起作用，可用于食具。根据网上，最新报价每吨约10000元人民币。

　　聚碳酸酯是一种无色透明的无定性热塑性材料。耐酸，耐油。由於聚碳酸酯的清晰和韧性，食物贮存喜欢使用聚碳酸酯纤维。聚碳酸酯多为进口原料，每吨约3500美元，折合人民币约27510元。

　　韩国乐扣乐扣售价高于中国地区

　　根据上海乐扣乐扣贸易有限公司提供给新民网的信息显示，600毫升水杯在韩国的价格是2600韩元。依照1元人民币兑换110元韩元的汇率，水杯在韩国的售价为23.6元人民币。上海乐扣乐扣贸易有限公司认为，相比中国市场24.1元的售价，韩国市场的价格与中国市场的价格差距不大。而韩国乐扣乐扣水杯的售价之所以会与中国售价稍有差距，上海乐扣乐扣贸易有限公司认为，是包含了众多的进出口费用，比如进口税等，但中国乐扣乐扣水杯的售价其实比韩国的售价更低，这样的优惠主要是因为上海的乐扣乐扣贸易有限公司是韩国海纳开碧公司全资拥有并运营的，所以在价格方面可以给出优惠。在中国的主要销售渠道有六类：电视购物、大型超市、专卖店、直营店、网上商城、百货商城。

　　新民网采访了一位已在韩国留学4年的中国留学生对乐扣乐扣保鲜盒在韩国的销售情况，该留学生表示，在韩国韩国，每个超市、便利店和网上的价格都不一样，一般来说便利店里的售价相对较高，而韩国年轻人一般会选择在网上消费，家庭主妇则会选择在超市购物。据该留学生所知道，乐扣乐扣保鲜盒最小容量的一个产品至少5000韩元(约人民币45元)，稍大点的20000多韩元(约人民币181元),一个600ML的乐扣乐扣水杯在网上和超市购买一般在3000韩元左右(约人民币27元)，便利店则在5000~8000韩元(约人民币45~72元)。该名留学生认为，在中国购买乐扣乐扣保鲜盒比较合算，在中国的售价比韩国要便宜不少。

　　物价部门称乐扣乐扣产品定价不在指导范围

　　在网友对“公布乐扣乐扣的真实价值”的热烈回贴中，有较为冷静的的网友指出，“外国货不等同于高档货，它们有些东西也只是一般的放在超市里，只是市场推广做的比较好，并借助了它们本国的经济实力背景。”曾经有树立起“奢华冰淇淋”形象的美国冰淇淋品牌哈根达斯，后被媒体爆出在美国市场，其品牌形象只不过是一般的冰淇淋产品，价格远没有在国内如此“高不可攀”。

　　为了更好地了解进口商品在我国的相关定价准则，新民网专门走访了上海发改委的价格监督部门，该部门相关工作人员表示，02年12月1日起执行的《上海市定价目录》包括15种(类)46项商品和服务价格，以及国家行政机关收费。但对进口商品的定价目前还没有明确指导意见，类似乐扣乐扣的保鲜盒也不在这46项商品名单之列。(新民网　王弘)

什么是每个人都必不可少的日常用品？如同每个人都需要自己的个人空间，个人物品也需要一个“安全”的空间来储藏。“乐扣乐扣”可以满足家里各种年龄阶段人们的不同需求。不管是装食品，文件或是装衣服和玩具，任何人都能在“乐扣乐扣”几百款不同的产品中找到适合自己的那一款。不但如此，“乐扣乐扣”还可保证储藏物品的绝对安全。因为使用了独特的“四面锁扣”系统和先进的密封材料，“乐扣乐扣”可以保证100%密封，确保连一丝空气都不会“窜”出去。所以，不管是高精密仪器或是新鲜的食物，放进“乐扣乐扣”后，你就放心吧！

“乐扣乐扣”老少咸宜呢？这全是因为产品的人性化和细节化设计。专业的设计队伍在认真学习了不同年龄段人群的使用需求和习惯后，通过最灵感的触动将之溶入到设计方案中，这样才诞生了崭新的“乐扣乐扣”保鲜盒。就连礼品套装的产品选择和搭配也经过了最合理的精心考虑。下面，让我们来看看各个不同年龄段的人们是怎样利用“乐扣乐扣”来方便生活的吧！

孩子们：“乐扣乐扣”是我的好伙伴

还记得从前自己带的午餐不小心漏了，弄脏了书包？“乐扣乐扣”饭盒套装就是为了使学生们安全方便的携带午餐而设计的。套装中包括两个长型盒子和一个水壶。一个长型盒子可以用来放主食，另一个被分成为三个食物栏，可以分开放不同风味的菜而不会串味。水壶也是密封的，水壶盖还可以当杯子使用。而所有的盒子都放在一个包装袋内，携带非常方便。

另外搅拌杯这一款产品也非常适合“上学一族”使用。“乐扣乐扣”搅拌杯的特殊点在于其独特的螺旋状搅拌片。清晨泡速溶咖啡，谷物粉，果汁等饮品的时候将搅拌片放入杯中，其螺旋状的设计使得搅拌非常快速便捷。如果在冲好饮品后孩子需要拿着在路上喝或者带到学校，将盖子扣好后随便装在包里就好。而在不需要搅拌的时候，只用将搅拌片拿出来又可当正常的水杯使用。

爸爸妈妈：“乐扣乐扣”是我的好帮手

忙忙忙，是爸爸妈妈们的口头禅，因此他们最需要一个生活的好帮手。因为工作生活的缘故，他们只有周末才去超市大采购，东西都买整盒整箱的，厨房变的乱七八糟。这时候，让“乐扣乐扣”来帮忙。许多“乐扣乐扣”的产品在设计初始就结合了节省空间的考虑，因此正确使用和搭配不同型号的产品可以大大节省冰箱空间将近一倍。

如储存意大利面的长型保鲜盒，可以保存大约4-6包普通包装的面条，而占据空间只用其1/2。而且，这种盒子中间有一块分隔板，如果装不同宽度的面条还可以很清楚的分开。另外如面包盒，因为“乐扣乐扣”的绝佳密封性，面包的保鲜时间可以延长至一般产品的三倍以上，长远来说可以节省时间和金钱。

另外，“乐扣乐扣”还是爸爸妈妈们赠送亲朋好友的好礼物。“乐扣乐扣”的新婚套装和家庭聚会套装会给朋友们一个惊喜。新婚套装包装精美浪漫，内含的保鲜盒从数量上和款式上基本可以满足两人世界的所有需要，这样一份实用的礼物让新婚燕尔的朋友生活多了一份便利。而家庭聚会套装则包括放薯片的大型盒子，放沙拉、水果的中型盒子，以及放小吃的小型盒子等，非常实用。

爷爷奶奶：“乐扣乐扣”让我放心

爷爷奶奶退休在家，闲暇的时间多了起来：下下厨，整理整理过去的东西，同样，“乐扣乐扣”还是如同以前一样的“好用”。就下厨来说，“乐扣乐扣”有多种装蔬菜和食品的特制款式和尺寸。如装豆腐的方型盒子，盒内有一个带手柄的篥水板。有了这个装置，就可以在盒内装上水，让豆腐保持新鲜更长的时间。而在需要食用的时候，将手柄一提，又可以将豆腐轻松的拿出来。而且还能方便的在蓠水板上切豆腐。

另外，“乐扣乐扣”手提型特别适合收纳各种琐碎杂物。老照片，老文件，和电器说明书，零配件以及发票等等，都可以分类储藏在“乐扣乐扣”手提型内，不但房间整洁干净，东西安全保险，找起来还很方便。除此之外，“乐扣乐扣”医药品保管箱适合装各类常备药，因为其100%密封性能，药品的储藏质量可以保证。

 “乐扣乐扣”是全家人的好朋友。不管是小孩子们，还是爸爸妈妈，爷爷奶奶，“乐扣乐扣”都会让你在“一开一扣”中体会到乐趣和方便无穷！

 

在网上一直看到有一些手机买家在网上发表的资料，那么现在也让我们从手机卖家的角度上，对手机市场做一下综合评述。

一、手机价格   
这也是买家最为关心的问题，同一款手机为什么会有这么大的区别？其实，这个问题非常简单，每一件商品都有其特有的价钱，如果低于市场均价的30%，那我可以肯定，这就是骗子的行为！可能是部分买家，不了解手机批发市场的进货渠道，同一款手机，只要差50元，就可能出现卖疯了的场面，如果真有低于30%的价钱的机器，这机器只要拿到批发市场，不到一天的时间就可以发光货，哪还用流到网络上，一台一台的卖？

二、大陆行和港行 
在我们手机卖家的眼里，这世界的手机，只有二种，一种是大陆行货，这个最硬，最过关。一种是水货。说什么港行机器，90%都是骗人的。大陆行货到哪都可以检测，相信如果卖家在网络上敢于这样介绍手机的，80%都可能是确有其事。但我们也知道，大陆行货价钱是透明的，最多也比国美、永乐出售的手机，便宜个200-500元。如果有更便宜的货，无非就两种情况，一种是有内部渠道的卖家，从二手市场收来旧机器到NOKIA等行货公司，通过内部漏洞，换出的新机。这种机器，价钱的确要便宜一些，质量也和全新没有什么区别。但这类手机的数量，的确非常的有限。第二种情况，那就是大陆行货的翻新机。其实，只要不是维修机，并且主板没动过，同时又配上原装外壳、部件，这类机器的质量也应该是有保障的。比如，是NOKIA，索爱的机器，还可以享受正轨大陆行货的保修服务。但网络上手机卖家良莠不齐，如果碰到黑心商人,更换了组装壳及配件，那个质量嘛，买家自己也可想而知。

港行？网络上真有这种机器吗？我们就说，最简单的一个道理，买家你自己去查查，香港同一型号手机，在卖多少价钱。最多比大陆的国美、永乐便宜个200-500元，你们以为走私水货不要冒风险，就为了这点利润，还要从香港大批的运到大陆，还要从中分出走私，批发，零售的一道道利润。买家自己算算，这可能吗？？？所以，网络上，如果有人说卖的是港行的手机，作为买家，你们就问二点，1.有香港发票吗？（因为没发票，这手机就不能在大陆联保，这港行和水货有什么区别？）2.可以去品牌客服检测吗？（如果真的是香港的行货机器，NOKIA、索爱都可以做免费的检测，这也就是最保险的方法）

三、水货
现在网络上卖的最多的，也就是这类的商品。从中可以细分为五种。1.全新港版 2.全新欧版 3.欧版14天机 4..翻新机（有欧版、港版）5.板机

相信网络上也有很多区别以上机型的资料，我们在这只是想告诉买家几个常识。
1.如果你真的买到的是全新的水货手机，从质量上来说，和大陆行货没有什么区别。软件上，大家也知道，现在的手机，都可以刷新大陆行货的软件版本，所以这点上也没什么差别。
2.怎么去区别全新机器和翻新机呢？手机是一个专业的市场，不要以为买家们在网上看看资料，看看图片，就可以很快的区分机器之间的差别。就我来说，天天在手机市场里转，也用了差不多近一年的时间，才会懂得区分。你如果不是同时，看到相同机型的二款机器，你肯定是没办法分别其中的奥妙！本店铺建议，在购买水货手机前，先去正规商店看看大陆行货机器是什么样子，以及功能，再去店铺实际购买，这样做一下比较，应该比你在网络上看看资料，更有帮助。还有一个比较简单的方法，为什么你们去国美、永乐买机器的时候，不会去想到翻新机呢？这也就说明，销售手机的公司所给你的品牌承诺!相信销售手机店铺的品牌，就是相信你所买到的手机。

四、配件
其中的核心，就是电池。网络上，有很多介绍各款机器的电池照片。希望各位买家，在购买前面最好，多看看其中的资料。但本店铺在实际销售过程，也碰到过这种事情。一天，一个男的和二个女的学生模样的来本店铺购买三星D508，标准配置中有一原电一组电，那个男的可能在购买前，网上看过点资料，一知半解和本店铺就二块电池，哪块是原装的，哪块是组装的，讨论一番，最后得出的结论，就是原装的那块是组装，组装的那块是原装，本店主也只能在一旁苦笑不语。在这里，本店铺介绍一些基本的常识。NOKIA、索爱、MOTO的电池，如果是原装的，正常情况可以用3-4天，三星机器，向来费电一般情况只能用2-3天。如果是组装的电池，基本的通病就是只能使用一天的时间。一般3-6个月，电池也就报废了。在区分电池的过程中，应该注意电池的接口光泽、标贴的细节程度、以及电池外壳的光洁度。

五、软件
在实际销售过程中，本店铺经常会被问到该机器的软件版本。发现这也是网络买家的通病，因为软件版本是最容易检测的。但你们是否知道，水货机器的质量问题，大多数情况是因为购买了翻新机器，而不是因为软件的问题。翻新的机器就算是用最新的软件版本，也一样的经常死机，出问题。就本店铺所销售的机型来说，一位买家随便的在网上咨询本店铺出售的手机的软件版本，本店铺销售近200款手机如果我们能背出销售手机的软件版本，我们还在这卖手机？早就去卖原子弹了！

六、售后服务
网上所作的承诺，都是虚幻的。做为买家，一定要找有实体店铺的，如果这个卖家连店铺也没有，就算给你终身保修，有什么用呢？

七、怎么区别网络手机卖家的真实性
1.做为本地买家的您，第一次最好去购买手机的实体店铺，现场试机购买，毕竟手机都是上千元的事情，就算花个二三十元打车费，也是值得的。因为目前网上有很多卖家，留的地址都是假的，要么是借其它零售商的门面,你如果不到现场确认，很有可能，2-3天以后，手机坏了，连人都找不到，这时候哭都来不及。对于那里只在网页上留手机号码而没有店铺地址的卖家，买家们也要多留个心，做为卖家来说，在网上留下店铺地址，固定电话，这是最基本的事情，难道开个手机店，还见不了光，一定要你买家打电话才给你店铺的地址？本店铺认为，送货上门的手机，只限于你已经购买过该店铺的手机，那时可以直接通过电话定货，货到付款。
2.做为外地买家的您，千万记住用支付宝，一句话，在网上不敢用支付宝卖东西的，不管是什么借口，一律是骗子!千万不要相信，网络上绝对不可能有比市场均价低30%以上的商品。大家也都知道，如果是用淘宝发货，有3天到10天的期限，只要你的手机没收到，一定要在规定时限内，在淘宝上申请退款，不然时间一到，就算卖家给你寄个机器模型过来，你也只能自认倒霉！就算你报了案，要找到你给骗的钱，也不知道猴年马月了
3.千万不要只相信淘宝网上的好评，那些钻石、红心都可以通过卖家自己的抄作制造出虚假的泡沫，就算在淘宝上，还有专人出售钻石级ID，也就二三百块钱的事情。你如果再去看看这些卖家的好评，你会发现，如果真的有一个客户连续购买超过3个以上的商品，那明显就是这个卖家在刻意的抄作好评。这就是好评的实情，如果有100个上门的顾客，最多只有5位会在网上给你评价，太多的买家，买到手机后就忘了网上购买的这个事情，所以网上的评价只是一个参考的部分。最好的方法，就是看照片，去实地现场购买，常言说的好，眼见为实耳听为虚。
4.请大家一定要注意店铺建立的时间，如果只有短短的半年，就我们专业卖手机的进货方来说，都不能完全分清全新机，翻新机以及配件的奥秘，那么就算卖家给你说是全新的港行机器，那又有什么意义呢？

如果你看完了，以上的资料相信你也对网络手机市场有了个基本的了解，请帮忙顶顶，因为好帖子也需要大家一起顶，才能让更多的人知道。

如果你在买手机的过程中，碰到的手机卖家，对本店铺所发的贴子有任何的疑问或不同解释，你也可以直接打电话过来，本店铺会为您做出专业的咨询。电话，店铺地址，本人的网络店铺上都标的清清楚楚，真金不怕火炼！

六里桥长途客运站

　　谘询电话：63861262，63861264


　　地址：丰台区六里桥南里甲1号

　　乘车：6，50，323，324，300在六里桥南里下车

　　发车方向：

　　保定，廊坊，邢台，邯郸，离石，仙游，林州，郑州，新乡，鹤壁，开封，洛阳，许昌，柳林，安阳石家庄

　　赵公口长途汽车站

　　预售票问讯电话：67229491；67237328

　　洽谈包车业务电话：67242446；67223111--3068

　　地址：永外南三环中路34号

　　乘车：17、300、927、368路赵公口站下车

　　发车方向：

　　河间、涿州、阳泉、曲阜、富镇、保定、太泉、临沂、衡水、望都、定兴、长治、新沂、威县、高平、沭阳、馆陶、邢台、晋城、淮阴、南宫、邯郸、淮安、南乐、安阳、宝应、清丰、新乡、高邮、濮阳、郑州、江都、滑县、禹州、方城、许昌、扬州、桑村、南阳、南京、黄骅、德州、庆云、盐山、济南、沧州、无棣、泰安、沾化、徐州、广饶、东营、滨州、费县、嘉山、宜兴、小营、寿光、博兴、响水、郯城、杭州、潍坊、曹玉、滨海、长兴、绍兴、索镇、阜宁、天台、淄博、建湖、盐城、淮阴、临海、淄川、黄岩、泽国、乐清、永嘉、白溪、温州、镇江、瑞安、龙港、三河、滦县、德州、玉田、昌黎、小站、夏津、沧州、丰润、唐山、绥中、绍兴、兴城、盘锦、锦西、台安、锦州、辽中、梁山、荏平、商丘、郓城、周口、杞县、东阿、太康、鹿邑、巨野、商水、平阴、成武、淮阳、浚县、项城、鹤壁、郸城、沈丘、虞城、永城、霸县、静海、陵县、莱州、建桥、西五、郭桥、吴桥、明化、冠县、淮镇、西留、尚村、东谈、肃宁、韩村、泊头、东光、寨子、束城、南召、郑口、安平、子文、深县、合立、薛庄、桑树、柏芽、乐陵、丰宁、军庄、饶阳、留楚、南善、临西、袁庄、街头、冀县、文安、枣强、呼和浩特、石家庄、平顶山、天津外、连云港、咸水沽、察素旗、秦皇岛、大港区、沙拉旗、沟邦子、黄河桥、平店、赵官寺、西南王、北司徒、米格庄、留古寺、土路口、南王庄、饶阳店、清凉店、卧佛堂、黎民居

　　东直门长途汽车站

　　调度室电话：64671346，67237328

　　地址：东直门外斜街45号

　　乘车：地铁、44、22、18、、359、401、404、413、418、823、107路东直门下车　　发车方向：

　　密云、北房、河槽、李桥、沿河、木林、王庄、榆林、华山、罗营、关上、马坊、北庄、湾平、兴洲、凤山、长馈、丰宁、三沟、六沟、七沟、平泉、兴隆、湾平、东营、承德、赤峰、南乐、清丰、濮阳、陈垣、淮阴、宝应、江都、秦兴、沧州、盐山、旧县、乐陵、孙河、杨镇、平谷、庙城、李遂、北适、河庄、寺上、桥梓、塔河、城乡、统军庄、富各庄、南庄头、北小营、焦庄户、打铁庄、庄头峪、白龙潭、大师屯、老营盘、东沟门、金台子、厢黄旗、黑山嘴、四道河、墙子路、六道河、前苇塘、古北口、火斗山、拉海沟、两间房、红石粒、陈栅子、八汗、火神营、南法信、牛栏山、家务、孙各庄、吴维寺、河防口、琉璃庙、高力营、下西市、北石槽、龙山村、万庄道口、巴克什营、官庄道口、平谷医院、喇叭沟门、天竺花园、石园小区

　　西直门长途汽车站

　　谘询处电话：62183454

　　地址：北京北站附近北下关2号

　　乘车：16、16支路北下关下车

　　发车方向：

　　沈阳、铁岭、长春、锦州、鞍山、银川、包头、临河、应县、蔚县、绥、神木、榆林、济南、博山、乐陵、惠民、滨州、赤峰、集宁、平泉、平庄、锡林、宝昌、宁城、林东、乌丹、大阪、选营、凤山、宽城、滦平、唐山、沙城、山海关、秦皇岛、哈尔滨、石嘴山、张家口、大仗子、呼和浩特、兴垄承德、围尝隆化

　　木樨园长途汽车站

　　谘询处电话：67267149

　　地址：丰台区海户屯199号

　　乘车：17、2、300、377、926、324、341、366、40路木樨园下车

　　发车方向：清苑、晋州、安国、深泽、辛集、无极、高阳、何桥、旧城、留史、　　县、丰宁、怀柔、帽山、辛庄、西陵、易县、定兴、埠城、姚村、涞水、涿州、娄村、容城、白沟、安新、徐水、雄县、固定、新城、顺平、安阳、顺平、大城、北魏、完县、大城、北魏、曲阳、固定、保定、廊坊、霸坊、文安、永清、白沟、南乐、馆陶、衡水、河间、清河、献县、南宫、乐清、济南、南京、杭州、温州、淄博、滨州、博山、阳、台前、郓城、清河、文登、平度、莱阳、梁山、德州、东阿、庆云、滨州、寿光、坊、莱州、徐州、青田、汤河口、石家庄、高碑店、白洋淀

　　丽泽桥长途汽车站

　　问讯处电话：63403408，63475092

　　调度室电话：63470828

　　地址：西三环丽泽桥东

　　乘车：811、901、541、50、300、323、324路丽泽桥、东管头下车

　　发车方向：

　　巨鹿、河涧、武邑、沧州、天津、青县、广宗、灵寿、定州、行唐、东光、廊坊、安国、徐水、无极、定兴、黄骅、海兴、晋州、淮阳、清丰、濮阳、沈丘、德州、梁山、巨野、鹿邑、太原、上蔡、安阳、郑州、商丘、景县、柘城、东明、新蔡、项城、夏邑、邯郸、大营、范县、莘县、新乡、台前、枣强、清河、临青、庆云、济南、济阳、盐城、东营、文安、海州、高青、廊坊、惠民、宁津、堰、泰安、宝应、高邮、?东、滨海、南通、海安、南京、洪泽、临沂、通州、新浦、界首、安阳、泗阳、宿迁、阳泉、兴化、海安、东台、郓城、河泽、东阿、成武、费县、朝阳、济宁、高塘、邹城、腰州、榆林、汾阳、缓德、米脂、巴中、西安、汉中、甫江、郾城、盘锦、通县、丰润、高碑店、石家庄、连云港、白城子、大年陈、海兴县辛集、古云三厂、呼和浩特.

　　莲花池长途汽车站

　　电话：63464027

　　地址：丰台区六里桥

　　乘车：6、50、309、340六里桥下、323、324六里桥北里下、300、901六里桥南里下　　发车方向：

　　信阳、新乡、郑州、邢台、邯郸、安阳、内黄、衡水、南宫、馆陶、南乐、清丰、淮阳、长垣、太康、鹿邑、梁山、菏泽、曹县、商丘、兰考、沙市、南阳、襄樊、武汉、孝感、涿州、保定、新乐、固始、漯河、许昌、成武、东阿、郓城、巨野、项城、永城、单县、泉林、泰安、费县、周口、开封、东明、金乡、汶上、济宁、鱼台、林县、滑县、淮阳、鹤壁、焦作、沈丘、鹿邑、长治、阳泉、榆次、东观、沁县、沭阳、临沂、新蔡、嘉祥、泉林、漯河、上蔡、平山、望都、新乐、行唐、灵寿、洛阳、郸城、鄄城、睢县、温县、商水、周口、原阳、黄陵、东平、浚县、内黄、民权、镇平、唐河、方城、邓州、沈丘、通许、尉氏、无为、合肥、徐州、宁陵、宁晋、武安、禹县、富镇、固安、磁窖、德州、蒙阴、西华、何庄、静海、青县、铂镇、东光、威海、滨州、维坊、文登、淮阴、石家庄、驻马店、平顶山、梁宝寺、三门峡、张家港

　　北京南站长途汽车站

　　谘询电话：63034307

　　地址：北京南站(永定门火车站)

　　乘车：20、54、102、106、122、381、特2、特5路北京南站下

　　发车方向：

　　东营、坝县、盐山、庆云、无、富国、垦利、任丘、景县、恩城、莘县、朝城、临西、河间、武邑、衡水、冀县、南宫、垂扬、聊城、献县、临清、堠崮、清河、阳、威县、馆陶、冠县、商河、沧州、盐山、旧县、乐陵、郑店、伊巷、东阿、高唐、南镇、荏平、宝昌、赤城、沽源、肥城、富镇、德州、济南、泰安、龙华、阜城、杜林、盛棠、韩庄、大营、肖张、杜朋、枣强、济阳、大城、沧县、滨州、滨县、柏芽、深县、芦园、杜庄、西王、濮阳、章台、南乐、清丰、郑口、方庄、青龙、蓟县、三河、遵化、莱阳、大王、小苑、榆科、记池、雄到、彭村、独流、马庄、后狄、板东、岗、仙河、孤岛、辛集、定兴、安国、固罗、深泽、位泊、垒头、冠县、临清、连寨、店子、河、平原、禹城、邹平、尚堂、青城、苏正、饶阳、五公里、小堤、惠民、苏争、临邑、南皮、长宫、后位、宁津、德平、宁阳、汶上、东述、莱州、维坊、沙河、武城、单侨、宁茜、保定、徐水、望都、定州、新乐、林庄、黄桥、阳信、无国、合肥、巢湖、乐陵、林沭、响水、天台、滨海、阜宁、夏津、腰站、正定、诸城、博兴、广饶、寿光、稻田、临沂、墩尚、枣庄、邹县、腾州、曲阜、杜桥、徐州、南京、宜兴、杭州、绍兴、天台、临海、张北、宝昌、太原、阳泉、长治、邢台、涉县、黎城、潞城、新汶、陵县、范缜、莱芜、新泰、柳桥、淄博、索镇、范县、韩屯、侯营、毛湾、州城、高唐、平阴、东平、寿张、店、沾城、下洼、陈庄、石臼、安丘、日照、金寨、宿县、蒙城、六安、砀山、济宁、鱼台、丰县、邺城、马站、招远、昌邑、朱桥、李庄、固安、南通、东台、海安、如皋、魏屯、栖霞、福山、海阳、寿光、平度、发城、青岛、邮黑、沧口、蓬莱、无地、黄县、平阳、乐清、温州、瑞安、苍山、新泰、蒙阴、涿鹿、矾山、野场、岔道、温岭、黄岩、泽国、临朐、青州、杨村、天津、漫河、寒亭、桑根达莱、哈巴嘎、樱桃园、石门口、柿子园、北杏园、教场谱、李东庄、急流口、降河流、段芦头、代官屯、斗虎屯、独石口、北圈、石家庄、高山堡、连云港、流坡坞、铁门关、小步村、小榆林、八道河、前磨头、码头、官道、王御史、三河屯、高官庄、智军庄、二十里铺、锡林浩特、

　　九龙山长途汽车站

　　谘询处电话：67762443

　　地址：朝阳区西大望路

　　乘车：31路东郊火车站下

　　发车方向：

　　天津、茶淀、武清、大厂、沈阳、鞍山、盘锦、朝阳、锦西、阜阳、阜宁、德州、济南、临沂、滨海、响水、怀阳、怀安、涟水、包头、烟台、龙口、遵化、唐山、滦南、玉田、丰润、迁安、丰南、承德、滦平、隆化、尉县、赤城、通县、园、缓中、徐州、沙城、东营、无、三河、迁西、怀柔、顺义、张家口、山海关、秦皇岛、北古口、九龙山、红石粒、呼和浩特、

　　广渠门(马圈)长途汽车站

　　调度室电话：67717620

　　地址：广渠门外大街22号

　　乘车：23、24、822、907路马圈下

　　发车方向：

　　抚顺、大连、辽阳、丹东、鞍山、海城、蚰盐、源、长春、唐山、承德、兴城、锦西、营口、盘锦、沈阳、丰润、遵化、三河、丰宁、怀柔、临泉、玉田、郑州、平泉、宝坻、通县、香河、杨村、黄骅、天津、密云、桃园、庆云、乐亭、迁西、海城、　马仲桥、汤河口、石家庄、河西务、古北口、大口屯、

　　怀柔长途汽车站

　　电话：69623028

　　发车方向：

　　丰宁、帽山、梁根、洞台、沙峪、碾子、虎什哈、道德坑、北辛店、孙栅子、琉璃庙、慕田峪、黄花城、杏树台、河防口、汤河口、奇峰茶、杨木栅子、嗽叭沟门等地

　　通州区长途汽车站

　　电话：69542313

　　发车方向：

　　顺义、慕郊、郎府、香河、平町、小务、海子、后伏、郭县、次渠、渠头、马驹桥、永乐店、在杜社、小甸屯、半截河、永定门火车站、觅子让、徐辛店、柒厂屯、张各庄、南各庄等地。

　　北郊长途汽车站

　　电话：62018335

　　发车方向：

　　延庆、永宁，北口、沽源、赤城、宝昌、白草、涿鹿、秦城、阳坊、大庄南口、老峪沟、九渡河，小汤山、古城水库、高丽营等地

　　延庆长途汽车站

　　电话：69103266

　　发车方向：

　　北郊、后城、赤城、永宁、康庄、下营、东坊、小川、花盆、四海、沙梁子、红旗店、大庄科、刘斌堡、千家店、等地

　　永定门火车站

　　电话：63034307

　　发车方向：

　　永清、文安、大城、安国、雄县、容城、安新、肃宁、交河、献县、束城、束鹿、安平、柏芽、深县、饶阳、建国、大营、郑口、枣强、龙华、翼县、衡水、街关、南宫、清河、临西、威县、天津、聊城、阳谷、东阿、范县、商河、北镇、东营、招远、留各庄、清凉店等地

　　永定门桥头

　　电话：67224641

　　发车方向：#DBDBE3

　　固安、旧州、宫村、凤河营、三小营、大杜社、马驹桥、东田阳等地

　　天桥长途汽车站

　　电话：3033940

　　发车方向：

　　房山、向阳、胜利、韩营、码头、白沟等地

　　黄村长途汽车站

　　电话：69244392

　　发车方向：

　　大礼、向阳、固安、赵村、石佛寺、南各庄、半壁店、凤河营、长子营、庞各庄、六合庄等地

　　河滩长途汽车站

　　电话：69842714

　　发车方向：

　　南窑、黄塔、大村、于白、北岭、应县、杨索、斋堂、潭柘寺、里家庄、燕家台、沿河城、上苇店、木城涧、王平村、大安山、苛罗店、辛庄等地

 对于软件的需求调研活动，虽然曾经写过三篇相关的需求管理文章，出发角度是从整体的需求管理过程考虑；在引入CMM（二）需求管理KPA活动的基础上，列举了如何进行需求调研前的需求管理计划活动；在失败的项目中，找出规范和管理软件需求过程的关健点及需求关联的模型架构（这些可以参考以前写过的《CMM需求管理实践经验记录谈》、《从CMM角度考虑需求管理计划》、《如何用CRC模型来确定需求》）。一直以来，感觉自己在经过几个项目试验的基础上对于软件的需求管理应该是有一定的基础和经验了，然而在最近参与的一个大型项目过程中，在新加坡项目经理的引导与帮助下，对于软件需求调研又有了更深一层的体会和认识；总结出需求调研中的5W+1H定律，在此把自己的一些过程和经验描述出来，希望能与各同仁一起分享与讨论。

项目背景：
一个中型的企业信息化项目，其中乙方的项目经理是一个拥有PMP证书的资深项目管理人员。甲方的项目经理是一个有着丰富项目实施和管理经验的新加坡项目管理人员。（在这里需要补充的时，在调研产生冲突过程中，外籍人员如何用自己的经验和技巧，让乙方完全可以接收）

项目成员：
甲方：外包项目经理、外包项目管理人员
乙方：项目经理、系统分析员、界面制作人员

工作内容：
项目需求阶段的活动，对于系统的需求，甲乙双方与最终用户能达成一致，甲方作为外包管理者，主要是对乙方项目组的项目进度、项目阶段成果进行跟踪与验收，以保证项目在预期的时间内完成预期的工作任务。

过程描述：
项目启动后，乙方的项目经理列了一份详细的需求调研时间表、调研阶段成果目录清单、界面成果等的计划内容，可以用一个 “赞” 字来形容；从计划上看，乙方的项目经理计划真的是完美无缺；在与用户进行业务需求调研的活动中，乙方不仅记录下目前用户现有的业务流程，包括目前流程的局限性，流程的执行性等方面，还为用户进行了将来系统流程的规划，的确是一个不错的开始。可是在乙方提交其阶段的需求分析文档和界面时，却发现二者存在了种种的冲突和矛盾，我们无法将需求分析文档与界面结合在一起。此时，乙方的项目经理解释是因为文档比界面细，所以二者存在一些理解上的差异。而我们甲方却总觉得有些不太对劲，但因为同样存在着对用户流程细节的不熟悉，所以我们也提不出具体的问题，直到有一天，跟着乙方一起做用户的需求活动后，从乙方项目经理的提问方面，我们终于明白为什么他们会做出这样的文档和界面。

首先，乙方项目经理对用户的提问是没有序列的，我们所谓的序列就是项目经理的逻辑是否清晰，除了问及目前的流程外，最重要的引入项目（即新的软件系统）的目的，所需达到的效果，可以对用户辅助的东东，而这些乙方的项目经理一字未提与问，只记录用户所说的过程、局限和要求。这样，乙方项目经理在分析与规划系统的需求时，就没有一个明确的目的性和方向性，这里就要引入第一个W定律---WHY定律。WHY就是为什么用户要引入系统，引入新的信息系统对用户有什么帮助，在总体工作效能上如何实现一个最终的结果？WHY定律是要求在需求开始时，项目经理就应该明确的，这个项目是为了改进用户工作效率；提高部门间的协作机制；加快对客户反应的体系服务；提升企业的竞争力等等。有了这么一个WHY引入思想，项目经理就可以理清用户最终要的是可以提供给他们什么样的系统，在系统的定位和建立上，就有一个明确地最终目标。

其次，有了一个总体的目标性，从各业务流程的要求入手，引入第二个W定律---WHAT定律，WHAT则是这个系统要做什么？实现什么？就是乙方项目经理提出的各业务流程问题、流程局限性问题、系统要解决的问题等，在这个WHAT的基础上，把系统划分成各功能模块，逐步弄清模块流程需求、功能需求、结构需求。引入WHAT定律可以让我们了解到系统的初步需求。

再次，引入第三、四、五个定律---WHO、WHEN、WHERE定律，这个阶段其实就是需求细化阶段，在WHAT定律的基础上，细分系统的用户需求：分析什么人，在什么时间，什么阶段可以或必须操作这个功能，结合前面的WHAT定律，理清系统的流程阶段划分，记录并分析系统功能实现的细节，在这个阶段就可以产生系统需求的用例图（Use Case），作为下阶段设计的依据。

最后，就是所谓的1H定律---HOW定律，就是怎样实现系统了，在前面的WHY、WHAT、WHO、WHEN、WHERE基础上，我们已经搭建了一个非常好的系统需求基础框架，如何在这些用户需求的基础上，分析系统的需求，如何进行需求规格的分析与下阶段的设计、实现工作，就是HOW TO ACCOMPLISH THE SYSTEM了。

在需求阶段引入这5W+1H的定律，在一定程度上保证了系统需求的准确性，也使得项目经理或需求分析人员可以非常有序的有条理的开展需求挖掘和调研活动，这样的安排用户在配合上也非常清晰，知道如何与项目人员配合。其后，在我们的建议下，乙方改进了工作方式，理清了一些工作序列，不过在最终文档的提交上，乙方的项目经理为了迎合我们的需求，一直对需求文档的格式与内容进行修改，没有保持需求分析中应该有的从粗到细的阶层分析，也导致其需求分析中的不确定性因素较多，后期的设计工作展开不顺，这些算后话，希望能在以后的外包管理方面，就存在的这些问题进行其它的分析和讨论。

【摘要】
    本文讨论《企业人事信息系统》项目的需求分析方法与工具的选用。该系统的建设目标是帮助该企业管理好企业内部的人员和人员的活动，人事信息管理指的是企业员工从招聘面试到离职退休的全过程，涉及的主要活动包括面试、报到、培训、升职、离职或其他的人事变动，也包括电子化考勤、工资性收入的计算与分发、使用其他公司资源的有关记录（如宿舍、保险、证件办理等等）。此外，本系统也涉及到企业在全国各地的人事信息管理，企业的组织架构的设置，级别与职务管理，人力申请直至人力需求报表，从而形成一个对企业真正有用的人事信息管理应用系统。在本文中首先讨论了选用面向对象方法与工具的主要理由与策略，进一步通过一个简例说明该方法与工具使用的效果，也讨论了使用多种工具与方法在需求分析中的必要性，最后简要小结了选用正确工具与方法的意义和作用。
    在项目开展期间，我担任了系统分析、系统设计与数据库管理等大量工作。
【正文】
    人事信息管理系统是一个有着广泛应用面的实用性系统，但是，我国各个企业有着自身的体制、机制、特点与不同的要求；在开发这类系统时，系统需求分析是极为重要的一环。在整个分析过程中，我们都采用了面向对象的分析方法，这是因为我们在近几年的实践中已坚信这种方法能够更加有效地表达和描述现实世界。软件要具有适用性和扩展性，就必须更接近于现实世界本身的发展规律。
    以一个简单的例子来看，假设要求设计关于引进人才评估的一个系统，按我们过去的做法，先会要求提供给我们一份相关的引进人才评估表，然后依葫芦画瓢地设计相应的表单与界面。在短期来说，这样做是简便而实用的，但并不能够符合现实世界的长远目标，这套设计方法不具有扩展性，因为任何一份评估表的结构都会有可能发生许多改变的。采用面向对象的方法，可以从中提取出表类型、表结构、评分方法以及能考虑继承等各方面的要素，这样就可以保证软件的通用性，可配置性与可维护性。
    在工具的选择过程中，我们选择了现在已十分流行的Rational系列，包括Rational Rose、RUP、SoDA等，为什么选取这个系列工具呢？这是基于我们对软件需求分析目标的看法，我们认为需求分析应当能正确地回答如下的几个关键性问题：
   （1）用户的需求是否已详尽地被考虑到了？
   （2）用户能理解或明白我们所描述的内容吗？
   （3）分析是否会和设计相脱节，
   （4）序员能明白我们的分析与设计要求吗？等等。
    以下对上述几个问题逐一简要地加以说明：
   （1）详尽地获取用户的需求。
    用户的需求可分为显式的需求与隐性的需求，用户的倾向往往只顾及到当前的与明显的需求。要达到对需求理解的全面性，不仅仅只是依靠有效的用户谈话和调查，因为我们所面对的用户需求往往会有些片面的，采用Rational Rose（基于UML）提供的用例，以及多种图的联合使用，可以使我们发现其中的遗漏。
   （2）使用户能充分地理解我们的表示方法，能够真正明白我们描述的内容。
    软件需求分析规格说明书通常会是冗长而枯燥的，一般的用户不容易深入理解，这样就削弱了分析的正确性。通过支持面向对象及UML语言的Rational Rose可以更好地和用户交流，让用户了解系统的运作方式甚至细节的操作。
   （3）使分析和设计两个阶段互相联系与贯通。
    这是我们选择面向对象的方法及Rational Rose工具的重要原因，系统分析要向用户描述的不仅仅是用户的需求，而且包括解决方法，解决方法当然应包括设计（程序）、数据库与系统配置，我们当然不希望用户得到的是一个与需求规格说明不相同的软件，也不可能要求程序员完成一个不可胜任的任务。然而我们在以前的多项工作中经常发现这类情节，因为系统分析与设计相互脱节，导致一头扎在分析中不顾设计有关的事宜。
    分析与设计的脱节，还不利于设计现格说明的评估，因为分析往往会脱离现实，导致缺乏评估的依据。
    因为不可能成功地完成设计而使分析需要重来，就会造成巨大的浪费与损失。一个好的工具可以使分析与设计更紧密地连结起来，甚至于—一对应。面向对象的分析方法使对象之间相对而言有独立性，减少了任何影响到全局的改动，能避免因需求变化而导致全盘皆动的被动局面。
   （4）使程序员明白我们的设计。
    一个好的设计应该让程序员感到清晰明白，更少疑问。一个疑问很多的设计加上沟通不畅，绝对会出现在应用环境下所不需要的另一个软件，所以设计规格说明书务必清楚、形象与明确，当然，Rational Rose具有足够的图形与其他形式，能使程序员更加明确，甚至能细微到每一个语句（事实上如果使用VB，程序架构都有可能直接生成了）。
   （5）选择UML可能会有更多的理由。
    比如用户文档的编写、数据库设计，我们都需要做到有延续性，有自动化支持和具有质量上的保证。
    所以，我们选用了以上的方法和工具。
    在分析中，面对考勤班次的问题时，由于过去一直使用纸卡方式考勤，使用户对班次形成了固定的概念，而现在的许多考勤软件也采用多次刷卡的方法来形成一天的记录。经过面向对象的分析可以发现，事实上每天的上班记录是由多个时段所形成的，时段的多少在各个公司，各个工种与部门都不尽相同，每个时段可能有不同的属性，时段与时段组合可形成为班次，这更适合于现实的情况，使之能更加灵活与更有扩展性。其实，在天与天之间也都有相互之间的关系。在这一点上，我们又发现必须在考勤与薪金工资中加入与MRP中相似的期段（Periods）的基本概念，比如可以称之为考勤期段，允许为用户更加方便地设置考勤期段，可能使之不一定与自然年月日相同等等。
    Rational Rose使我们更方便地把上面的想法在类上去实现，更进一步地设计好我们的高效率的数据库。
    当然，使用单一的一个工具去完成一个中大型的应用系统的需求分析，是不可能成功的。因为社会在发展，用户的需求也在改变，如何把握住用户的需求是需要时间的，面向对象的方法有时也会忽略外在的与表层的要求，不仅仅是要获得关键的需求，其他更多的需求往往要等到用户在使用后才知道，然而等到用户使用是不现实的，作为原型开发模型中的原型也是收集用户需求，描述与解释需求的一类相当有效的方法与工具。
    在我们的开发过程中，为了更好地让用户了解我们的系统和我们的设计方案，让用户在见面会上更有方向性与针对性，我们首先用Access开发出原型，让用户先试用。这样，我们在真正的分析与设计时就能更加符合用户的要求。
    总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远的，选用高效能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、可扩展性和可维护性；降低了软件项目的风险。
评注：（1）写得有些特色，观点鲜明。（2）摘要写得不错，既反映了项目内容，也小结了本文的写作要点。（3）文中所举的例子虽然简单，但很实际。（4）多种方法与工具的使用，叙述得简明扼要。（5）内容可更丰富一些，更深入的例子也可再增多一些，则会更有说服力。（6）对需求分析的全过程的描述太少。（本文主要参考了广东延国庆等人的论文）

【摘要】
    本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。
【正文】
    我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1～2分钟左右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，客户端采用Windows 98，程序架构采用的是传统的C/S结构。
    鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得第（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第（2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。下面按上述三步分别加以论述。
    第一步是实施逆向工程，获取原有系统的基本需求。
    由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采用的主要工具是PB自带的Power Designer和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。在使用Power Designer分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。这里指出，使用Power Designer的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。
    第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充。
    通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro、Clear Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Pro进行需求管理，在类型划分，属性值的确定上，部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想办法增加一些示意图，将大的流程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。对第二个问题，则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的需求库，定出了基本需求规格说明。
    第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交流修改相应的需求。
    在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，也在Requisite Pro需求数据库中记录下修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不同的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无需再作争论，同时利用Requisite Pro，我们还发现了一些需求相互之间有矛盾。经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细设计的基线需求。
    在这个项目中，我们利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那些通过CMM二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，我们仅仅利用了Requisite Pro功能的一些小方面，已经体会到该工具对于项目管理的诸多好处。如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，项目的质量也会得到相应的提高。目前国内由于CMM热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用上国产的需求分析工具，那时我们的软件产业也许会真正地腾飞了。
评注；采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。写作有条理，也很实际。合理地界定了需求分析的现实水平。所采用的需求分析的方法与工具相对较合理科学。能在对项目讨论的同时抒发议论、使用体会、爱国心和事业心。深度还可以提高，例子宜更加丰富一些。（本文主要参考了广东刘小波等人的论文）

【摘要】
    本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程的进行以及最终的产品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了开发系统时所选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多种开发方法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法的不足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。
【正文】
    我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发本公司的业务报表系统，我担任系统的需求分析、总体设计和部分代码的编写工作。
    我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级公司之间都有数据报表的要求。但是，每一个地市分公司因所处的地方不同，经营环境不同，所面临的问题也不一样，因此形成了各具特色的数据报表（除地市分公司向省公司汇报的之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。
    在调研的过程中，我选用了一种工具叫Play CASE，可以从网上免费下载，有很强的功能。下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。
    第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账革统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中．构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建模的方法，即把业务系统中的各个组织转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。
    第二步，了解各个业务部门中的业务流程，使之通过Play CASE转换成软件的运行过程，这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到Play CASE中，并以形式化的语言描述各过程。对于复杂的过程，该工具还提供了进一步细化的方法，并且形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业部门的业务相结合比较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。
    第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。分析各部门需要的数据都有哪些；以及数据是如何转换的，这可以归入“功能建模”的范畴。将这些相应数据录入到Play CASE中，选定所属的部门。这时就自动地建立了DFD图（数据流程图），数据字典，省去了人工建立时的很大麻烦。
    第四步，将业务上的数据关系转变成软件中的数据关系。这里采用了面向对象的方法，把业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营部门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系。Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将用户构件与账单构件用相连关系表示。这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。
    经历了上述四个步骤以后，利用Play CASE工具自动生成了软件需求规格说明书、初步的DFD图和业务流程图，为下一步的总体设计打好了基础。
    使用Play CASE工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。
    通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。
    使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多结果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学计算机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轻松了很多。
    当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的部门或者组织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预留了好多个虚拟的部门，以备将来进一步的扩充或者变动。
评注：（1）具体项目有些体会，完成情况似乎不错。（2）条理较清晰，比较系统地描述了使用Play CASE的过程和体会。（3）偏重于工具的讨论，对需求分析的方法分析还嫌不够。（4）项目相对较小，仅涉及报表系统，对更为复杂的业务流程应举例分析，才能更充分地体现方法与工具的作用。（本文主要参考了广东魏福建等人的论文）

你的工程应该有个好的起点。一个小组要带领客户进入需求启发阶段而且你要写软件需求说明书。这份说明有些大，但客户会很重视，所以说明必须得到赞同。

　　现在你正在设计其中的一个特性，已经发现了需求的一些问题。你可以用多种不同的方式解释需求15；需求9 的说明正好与需求21相反，你因该相信哪一个？需求24非常含糊，你根本不明白它的意思；你不得不花上一个小时与2位开发人员讨论需求30，只因为你们对其各有各的理解；并且，唯一能够澄清这些问题的客户没有给你们答复。你被迫破解众多需求的含义，并且你能预料到，如果你错了，你要做大量的重复工作。

　　许多软件需求说明书（SRS）写得非常糟糕。任何产品的质量需要其原始材料的质量保证，糟糕的软件需求说明书不可能产出优秀的软件。不幸的是，几乎没有开发人员受过与需求的抽象、分析、文档、质检有关的教育。而且，没有非常多的好需求可以借鉴学习，部分原因是很少有工程可以找到一个好的借鉴，其他原因是公司不愿意将其产品说明书放在公共区域。

　　这篇文章描述了高质量需求叙述和说明的几个特性（特点）。我们将用这些观点检查一些有缺陷的需求，带着痛楚重新编写。而且我会谈一些如何编写好的需求的提示。你也许想通过这些质量标准评估你的工程需求。对于修订，也许迟了，但你会学到一些有用的东西，并帮助你的小组在下次编写出更好的需求。

　　不要期望能够编写出一份能体现需求应具备的所有特性的SRS。无论你怎么细化、分析、评论和优化需求，都不可能达到完美。但是，如果你牢记这些特性，你就会编写出更好的需求，生产出更好的产品。

　　高质量需求叙述的特性

　　我们如何从一些有问题的需求中分辨出好的软件需求？这一节将分别介绍需求叙述应体现的6个特性，下一节将从整体上介绍SRS文档应具备的特性。判断每个需求是否具备应有的特性的一种方式是由持有不同观点的工程资金管理人所作的正规检查。另一种有力的方法是在编写代码前依据需求编写测试例子。测试例子能够明确显现在需求中描述的产品行为（特性），能够显现缺陷、冗余和含糊之处。

　　正确：每个需求必须精确描述要交付的功能。正确性依据于需求的来源，如真实的客户或高级别的系统需求说明书。一个软件需求与其对应的系统需求说明书相抵触是不正确的（当然，系统需求说明书本身可能不正确）。

　　只有用户的代表能够决定用户需求的正确性，这就是为什么在检查需求时，要包括他们或他们的代理的关键所在。不包括用户的需求检查就会导致开发人员的：“这是没意义的”，“这可能是他们的意思”等众所周知的猜测。

　　可行性：在已知的能力、有限的系统及其环境中每个需求必须是可实现的。为了避免需求的不可行性，在需求分析阶段应该有一个开发人员参与，在抽象阶段应该有市场人员参与。这个开发人员应能检查在技术上什么能做什么不能做，哪些需要需要额外的付出或者和其他的权衡。

　　必要性：每个需求应载明什么是客户确实需要的，什么要顺应于外部的需求，接口或标准。每个需求源于你认可、具有权说明需求的原始资料，这是考虑必需的另外情形（译注，此句翻译不顺，请参照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟踪每个需求回溯到出处，如用例，系统需求，规章，或来自其他用户的意见。如果你不能标识出处，可能需求只是个镀金的例子，没有真正的必须。

　　优先权：为了表明在一个详细的产品版本中应包含哪些要点，需要为每个需求，特征，或用例分配实现的优先权。客户或其代理都应有强烈的责任建立优先权。如果所有的需求都被视为同等重要，那么由于在开发中，预算削减，计划超时或组员的离开导致新的需求时， 项目经理将不能起到作用。优先权的作用是提供给客户的价值，实现的相关费用，实现相关联的有关技术风险。

　　我是用3种级别的优先权：高优先权表明需求必须体现在下一个产品版本中，中优先权表明需求是必须的，但是如果需要可以推迟到晚一些的产品版本中，低优先权表明有它很好，但我们必须认识到如果没有充足的时间或资源，它可以被放弃掉。

　　明确：需求叙述的读者应只能从其得到唯一的解说明，同样，一个需求的多个读者也应达成共识。自然语言极易导致含糊。要避免使用一些对于SRS作者很清楚但对于读者不清楚的主观词汇，如：用户友好性，容易，简单，快速，有效，几个，艺术级，改善的，最大，最小等等。每写一个需要都应简洁，简单，直观的采用用户熟知的语言，不要采用计算机术语。检查需求模糊的有效方式包括需求说明书的正规检查，根据需求写测试，建立用户的假想来说明产品某个特定部分预期的特性。

　　可证实：看你是否能够做出测试计划或其他验证方式，如检查和实证，来决定在产品中每个需求是否正确的实现。如果需求是不可验证的，决定需求是不是正确的实现就成了判断的事。需求之间不一致，不可行，不明确也能导致不可证实。任何需求如果说产品将要支持什么也是不可证实的。

高质量需求说明的特征

　　一个完整的SRS不仅是包括长长的功能性需求列表，还包括外部接口描述和一些诸如质量属性，期望性能的非功能性需求。下面描述了高质量的SRS的一些特性。

　　完整：不应该遗漏要求和必需的信息。完整性也是一个需求应具备的。发现缺少的信息很难，因为根本不存在。在SRS中将需求以分层目录方式组织，将帮助评审人员理解功能性描述的结构，使他们很容易指出遗失的东西。

　　在需求抽象时，相对于系统功能，你过多的注意用户的业务，将导致在需求的全局观和引进不是真正必需的需求上显得不足。在需求抽象上，应用用例方法会发挥很好的作用。能够从不同角度察看需求的图形分析模型也可以检查出不完整性。

　　如果你知道已缺少一些信息，使用TBD（to be determined）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。

　　一致性：一致性需求就是不要于其他的软件需求或高级别的系统（商业）需求发生冲突。需求中的不一致必须在开发开始前得到解决。只有经过调研才能确定哪些是正确的。修改需求时一定要谨慎，如果只审定修改的部分，没有审定于修改相关的部分，就可能导致不一致性。

　　可修改性：当每个需求的要求修改了或维护其历史更改时，你必须能够审定SRS。也就是说每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（照）。

　　可追踪：你应能将一个软件与其原始材料相对应，如高级系统需求，用例，用户的提议等。也能够将软件需求与设计元素，源代码，用于构造实现和验证需求的测试相对应。可追踪的需求应该具有独立标示，细密和结构化的编写，不应过大，不应是叙述性的文字和公告式的列表。

　　需求质量的评审

　　这些有关需求质量的特性的描述在理论上都是非常好的，但一个好的需求到底是个什么样子的呢？为了体现得更切合实际，我们做个小练习。下面有几个从实际的工程选出的需求，依据上面的质量标准，评估每个需求，看看有什么问题，然后用更好的方式重写。我将对每个例子都提出自己的分析和改进的建议。也欢迎你提出不同的见解。我所占优的只是我知道每个需求的出处。因为你我都不是真正的客户，我们只能猜测每个需求的意图。

　　例1．“产品应在不少于每60秒的正常周期内提供状态信息”

　　这个需求是不完整的：状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

　　弥补缺陷，重写需求的一种方法：

　　1、状态信息
　　1．1后台任务管理器因该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息
　　1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比
　　1．3任务完成时，应显示相关的信息
　　1．4后台任务出错应该显示错误信息

　　为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

　　例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

　　计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符合隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

　　象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

　　例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。单词“快速”使其模糊，没　　有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

　　试试这个：“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

　　例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。这是修改后的：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

　　在理解各个已完成的糟糕需求上，开发人员将会遇到的难题是：开发人员与客户将会在审核需求，未达成共识前发生激烈的争论。详细检查大的需求文档不是一件轻松的事情。我清楚有人做过，而且他们花在检查上的每一分钟都是值得的。相对于开发阶段和用户的抱怨电话，在这个阶段修补缺陷是便宜的，

　　编写质量需求的方针

　　编写优秀的需求是没有公式化的方法的。这需要大量的经验，要从你在过去的文档中发现的问题学习。请在组织软件需求文档时，严格遵从这些方针。

　　句子和段落要短。采用主动语气。使用正确的语法，拼写，标点。使用术语，要保持一致性，并在术语表或数据字典中定义它们

　　要看需求是否被有效的定义，可以以开发人员的观点看看。在内心将“当你们做完了找我”这句加到文档尾部，看看能不能是你紧张起来。换句话说，你是否需要SRS的编写者的额外解释帮助开发人员很好的理解需求，以便于设计和实现？如果是的话，在继续工作前，需求还需要细化。

　　需求编写者还要努力正确地把握细化程度。要避免包含多个需求的长的叙述段落。有帮助的提示是编写独立的可测试的需求。如果你认为一小部分测试可以验证一个需求的正确，那么它已经正确的细化了。如果你预想到多种不同类的测试，几个需求可能已挤到了一起，需要拆分开。

　　密切关注多个需求合成了单个需求。一个需求中的连接词“和”/“或”建议几个需求合并。不要在一个需求中使用“和”/“或”。

　　通篇文档细节上要保持一致。我曾看见过多个需求说明书前后不一致。如：“对于红色合法的颜色代码应是R”及“对于绿色合法的颜色代码应是G”就有可以以分散的需求分离开，而“产品应能对来自语音编辑指示做出反应”应作为一个子系统，不应作为单个的功能性需求。

　　避免在SRS中过多的申述需求。在多处包含相同的需求可以使文档更易于阅读，但也会给文档的维护增加困难。文档的多份文本要在同一时间内全部更新，避免不一致性。

　　如果你遵从了这些方针，你能够尽早地经常正式或非正式的审查需求，这些需求对于产品的构造，系统测试以及最后的客户满意，都会成为好的奠基石。并且要记住，没有高质量的需求，软件就象一盒巧克力，你永远不知道你会得到什么。

设计的过程就是将事务处理抽象成计算机模型的过程。
1. 首先要明白设计远比编程重要。
2. 平时注重训练自己的思维严谨性和从全局考虑问题的能力。建立冷静思考问题的处事态度。
3. 设计时（尤其是数据库设计时）不要完全被规矩约束，设计好比作诗，懂得韵律是对的，但完全被韵 律所束缚，就作不出好诗了。
4. 多做设计，经常总结自己的不足之处和成功之处，向他人请教。
5. 专门去找别人设计的漏洞和不足，也是提高自己设计水平的重要手段。
（记住：这个好方法不要顺便外传，自己知道就行了，嘻嘻-:）
6. 经验是重要的，但如果观念老化而不善于总结提高，所谓的经验就成为束缚自己进步的枷锁。
7. 学好数学特别是理论数学如数学分析、运筹学、数学模型等。多玩策略性经营游戏也是有益的。推荐 《帝国时代》和《模拟首都3000》以及《大富翁4》。（但不要沉陷在里面）
8. 根据项目情况和开发平台工具的特点确定最佳的设计方法。模块化设计方法和面向对象设计。两种设 计方法的结合使用。
9. 将复杂无序的过程用模块化的方法进行分解，但要注重事务间的联系，并且用开放的眼光去设计。
10. 设计时对严谨性、灵活性、开发效率、客户要求四个方面做衡量取舍。
11. 设计时还要根据整个工程的进度安排和客户对软件的要求而决定是否设计得足够灵活和严谨。
12. 复杂而无条理是最糟的设计，简单实用并不一定是最好的，但一定不是最坏的。（不要说我偷懒哟）
13. 训练自己良好的表达能力，能用清晰明确而且简单的描述表达出自己的基本思路。
14. 在一个项目中建立统一的系统分析模式和文档模板，同时，一个项目中必须至少有一个人对整个系统 设计进行检查和进行全局的考虑。
再谈如何成为一个好的系统分析员？

bylsfboy

系统分析员基本功：

好的系统分析员都是从优秀的程序员中产生的，坚实的编程功底、丰富的经验是今后做系统分析的基础。
没有对系统本身进行过透彻剖析过，很难领会到其中一些难以言述的精华。但并不等于好的程序员就能够 成为好的系统分析员。

合理的知识结构。语言能力、文字表达能力、技术的全面性等是对系统分析员的基本要求。比如说c/s和3 层开发，如果仅仅对netscape公司的产品熟悉还不够，还需要了解比如微软等产品，并且要了解他们中产 生历史,发展思路，技术优劣，以应付各种穷追猛打的提问。但更重要的是，这是你为应用定制技术要求 的前提。

系统分析员思想：

全局观念是系统分析员必须具备的观念。如果系统分析员设计时太注重细节，往往会陷入在某个问题上纠 缠不清的泥潭。（93年，我论文指导老师的一席话影响了我随后几年对软件开发的理解----今后计算机会 越来越快，多写几行代码少写代码无关紧要，最重要的是整体；一开始就错了，某个部份编得再好，也是 没有用的）

任务难度的预测能力

系统分析员要具备快速的任务难度预测能力以及具备快速确定开发小组人员构成和任务划分的能力。（我 将这条归为思想，而不是能力）昆虫自然会长出翅膀，而思想却需要长期的浸润。要做到这点，需要大量 的思考、学习。设计远比编程重要。当今软件业的发展，各种开发工具的出现，编程已经不是什么问题， 程序员的工作某种程度上讲是将别人现成的东西拼凑堆砌起来。系统分析员要清楚的认识到，现在大多数 程序员没有学会怎么去整体的了解一个系统，有些甚至不了解编程（这不是说他们不会写代码）。可视化 的开发工具加五花八门的控件，程序员可以偷点懒了。（这可不是夸大，我好几年的管理工作，接触过大 量的程序员）基于技术，跳出框架。基于现有技术结合用户需求思考问题，设计时跳出框架。

系统分析员思想：

系统分析员要有面向用户的思想。系统分析员应当有能力将自己扮演成用户，来了解要交付的项目看起来 想什么样式，感觉想什么，从而了解用户的想法并挑选出合理部份去开发。从这个意义上说，系统分析员 才能获得有意义的见解去引导他的开发组成员。系统分析员头脑中要对项目结局有一个清楚的认识，并保 证项目不偏离方向。系统分析员要有根植于技术，高于技术思考问题的思想。纯粹的程序员通常对最终结 果考虑的不是很多，当一种新的技术在市场上出现时，他们对能否按时交付的考虑就比较少，而强烈希望 他们的计划能够建立在新的技术之上。因此，系统分析员的想法和行动要象一个用户，又要能够站在技术 的高度，成为真正的用户、程序员之间的代言人。

系统分析员的关键

获得信任。系统分析员最重要的素质是获得信任，这是成为优秀系统分析员的关键。成熟最为关键。成熟 可以为整个项目组提供正确的支持,能够理解技术怎样才能解决用户的需求。

系统分析员的准备工作

统一的各种文档模式，这其中包括今后软件变量、字段命名规则。我推荐用pb制定的规则做基础，通过改 造成为适合自身实用的标准。统一的文档管理。统一的分析软件。比如说rose（uml太规范，国内的软件 管理水平根本用不上，只不过尽量应用，你自己对系统分析的理解有好处） 方法是思想的放映，在具体方法上就不多说了。我托人从u$a弄到几本书，用于面向对象系统开发的使 用》、《面向对象的分析》、《项目管理》等都是很不错的，推荐大家看看。

我在拙作"在中国没有人懂计算机"里发了点牢骚，听说挨了部份人（习惯性的）骂。其实，bbs本来就是 发泄的地方，在这里从来就罕有有内容的文章。

自从"维纳斯"登陆深圳后，大家更着眼于从宏观看中国的it业了。中国it这棵小树，说实在的，长到今天 实在是不容易。一些人提出了"反对微软霸权"的口号，不少人呼唤中国"硅谷"的出现。微软的成功不是技 术的成功，更多的是商业运作的成功。中国it这棵树能长多高，取决于他所植根于的土壤。而现在的事实是，这片土壤实在是太贫瘠了！如果按我们现在的思路和搞法，是长不成大树，更别指望能结出"微 软"，"硅谷"这样丰硕的果实。如果说，我们的软件技术落后美国十年，我们的硬件制造技术则落后美国 二十年，我们的管理水平落后美国至少三十年。而最终决定发展速率的恰恰是我们的死穴──低劣的管理 水平。低劣的管理水平的形成的原因有着深厚的背景和多方面的原因。

系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中 复杂就复杂在实际的面太多.在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有 帮助.

1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。

2）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们 会采取什么样的态度？你对他们有多少影响力？

3）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。

4）你的系统设计思想是什么？是否能够得到各方面的认可。

5）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有 足够的影响力吗？

6）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一 阶段完成的情况进行评价？

7）你对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？

8）你所完成的系统是否有原型？计算机的或者物理的。

以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。

系统分析工作是解决一个问题的工作,目标是将一个对计算机应用系统的需求转化成实际的物理实现,其中 复杂就复杂在实际的面太多.在系统分析过程之中注意问以下的问题,可能会所进行的系统分析设计工作有帮助

1)您所完成的系统目的是什么?注意不是功能要求,而是目的.也就是为什么要建设、为什么要现代建设。在考虑系统目的时，我更多的侧重于系统的最终目标考虑，因为一个系统不可能一下子完美，为系统留些 余地。

2）您所完成的系统有哪些方面参与，各方面的初衷是什么？那些人可能在系统建设中起重要作用，他们 会采取什么样的态度？你对他们有多少影响力？中国it行业的失败之一就是人"太年轻"，一定要有领导的 支持，否则完蛋。不要认为自己对他们会有多少影响力，即便有，也要尽可能的认为是决策者再影响他 们。在中国，一个技术员，你算老几？说到这里我很悲哀。哪些人在系统中起重要作用并弄清楚他们的态 度，这点十分关键。

3）您的系统是否有一个明确的评价标准？最好从参与的各方面都进行考虑。不知道这样说对不对，在系 统建设之前，对你的程序员、对你的领导要有至少不同的两种评价。

4）你的系统设计思想是什么？是否能够得到各方面的认可。如果高明，对领导、对程序员都采用引导， 得到认可的最好办法，就是让他们认可他们自己的想法。（我力图这样做，但做得不好，系统分析员有一 点要学会韬光养晦，忍）

5）你对参与系统设计开发的人员了解吗？他们的特长在哪里，是否愿意与你合作，为什么？你对他们有 足够的影响力吗？软件发展到一定的程度，不是编程，不是数学，而是管理。

6）你的系统开发计划是否完善？你的计划表有明确的阶段吗？任何一阶段都应该怎样完成？如何对这一 阶段完成的情况进行评价？

7）对所采用的系统开发方法以及工具是否熟悉？你的夥伴是否熟悉？事实上，不是每种好的工具都要 使用，也并不一定都要他们熟练掌握。提醒诸位一句，当你将方案做得可以不依赖某个程序员，你在程序 员面前就无信任可言，因为从此程序员将受到更大的生存压力。我坚决不在公司使用rose。

8）你所完成的系统是否有原型？计算机的或者物理的。

以上的几个问题都是在系统分析以及系统规划时涉及到的，供各位参考。

这文章很好，我的话是："需求分析实际应该是问题分析"。含义是系统要解决的是问题。而不是用户提出 的需求。经常发现系统完成后，客户说"我的问题还没有解决"。可是，需求分析稿上的目标都搞定了。

既然是问题分析，所以，熟悉目标系统的知识就是必要的。甚至，可以说，一个好的系统分析员也应该是 好的业务专家。

我很高兴在这里遇到许多分析高手，可以交流分析中的问题。我赞同从来的观点。在中国作分析重要的是 人气，因为中国的企业级信息系统的建设在很大程度上可以说并非确有需求，而是迫于某种压力。用户在 很多时候考虑的不是系统的长远发展，而只是短期的成果，要求开发单位在很短的时间内完成一个很大的 系统的开发，没有时间对系统进行周密的分析，在这种情况下，很多开发商就会粗分析，粗设计，尽快进 入编码阶段，这样的系统的生命周期肯定不会很长。说了这么多，只是想说，系统分析员确实应是业务和 管理专家，并且需要有很好的语言组织能力，他需要根据问题域中存在的问题去尽力说服用户，引导用户 需求，毕竟，我们是专家，如果让用户牵着鼻子走，系统不会是成功的系统。（当然了，这要建立在用户 是可引导的前提下）本人拙见。

在理解和分析用户的需求时，应说服用户明白：建立计算机应用系统并不是简单地用计算机代替手工劳
作，它更应该是管理思想的一次革命，是现用户模式的一次升华和提高。如果系统不能高于现实，开发的系统将长期陷入需求的反复修改，其软件的生命周期也短了。

针对我对您的问题的理解,试着作如下一般性/理论性的回复:

需求分析(您可以采用usecasedriven的方法进行需求分析)在明确需求分析的基础上,确定需要采用的系统分析方法(结构化/面向对象/构件式)应用您的开发团队所确定采用的分析/设计方法,进行系统分析.根据您所采用的分析方法,依次或反复进行系统设计/建模.

笔者的工作与Oracle数据库"息息相关",从事Oracle开发及管理已经１０余年，在实践中学习和摸索了一些小经验,在此与大家共同探讨. ---- 1.having 子句的用法 ---- having 子句对 group by 子句所确定的行组进行控制,having 子句条件中只允许涉及常量,聚组函数或group by 子句中的列. ---- 2.外部联接"+"的用法 ---- 外部联接"+"按其在"="的左边或右边分左联接和右联接.若不带"+"运算符的表中的一个行不直接匹配于带"+"预算符的表中的任何行,则前者的行与后者中的一个空行相匹配并被返回.若二者均不带′+′,则二者中无法匹配的均被返回.利用外部联接"+",可以替代效率十分低下的 not in 运算,大大提高运行速度.例如,下面这条命令执行起来很慢 select　a.empno from emp a where a.empno not in 　(select empno from emp1 where job=′SALE′); ---- 倘若利用外部联接,改写命令如下: select a.empno from emp a ,emp1 b 　where a.empno=b.empno(+) 　and b.empno is null 　and b.job=′SALE′; ---- 可以发现,运行速度明显提高. ---- 3.删除表内重复记录的方法 ---- 可以利用这样的命令来删除表内重复记录: delete from table_name a 　where rowid< (select max(rowid) from table_name 　where column1=a.column1 and column2=a.column2 　and colum3=a.colum3 and ...); ---- 不过,当表比较大(例如50万条以上)时,这个方法的效率之差令人无法忍受,需要另想办法. ---- 4.set transaction 命令的用法 ---- 在执行大事务时,有时oracle会报出如下的错误: ORA-01555:snapshot too old (rollback segment too small) ---- 这说明oracle给此事务随机分配的回滚段太小了,这时可以为它指定一个足够大的回滚段,以确保这个事务的成功执行.例如 set transaction use rollback segment roll_abc; 　delete from table_name where ... 　commit; ---- 回滚段roll_abc被指定给这个delete事务,commit命令则在事务结束之后取消了回滚段的指定. ---- 5.使用索引的注意事项 ---- select,update,delete 语句中的子查询应当有规律地查找少于20%的表行.如果一个语句查找的行数超过总行数的20%,它将不能通过使用索引获得性能上的提高. ---- 索引可能产生碎片,因为记录从表中删除时,相应也从表的索引中删除.表释放的空间可以再用,而索引释放的空间却不能再用.频繁进行删除操作的被索引的表,应当阶段性地重建索引,以避免在索引中造成空间碎片,影响性能.在许可的条件下,也可以阶段性地truncate表,truncate命令删除表中所有记录,也删除索引碎片. ---- 6.数据库重建应注意的问题 ---- 在利用import进行数据库重建过程中,有些视图可能会带来问题,因为结构输入的顺序可能造成视图的输入先于它低层次表的输入,这样建立视图就会失败.要解决这一问题,可采取分两步走的方法:首先输入结构,然后输入数据.命令举例如下 (uesrname:jfcl,password:hfjf,host sting:ora1,数据文件:expdata.dmp): imp jfcl/hfjf@ora1 file=empdata.dmp rows=N 　imp jfcl/hfjf@ora1 file=empdata.dmp full=Y buffer=64000 　commit=Y ignore=Y ---- 第一条命令输入所有数据库结构,但无记录.第二次输入结构和数据,64000字节提交一次.ignore=Y选项保证第二次输入既使对象存在的情况下也能成功.

一、英语重结构，汉语重义
　　我国著名语言学家王力先生曾经说过：“就句子的结构而论，西洋语言是法治的，中国语言是人治的。”(《中国语法理论》，《王力文集》第一卷，第35页，山东教育出版社，1984年)
　　我们看一看下面的例子：
　　Children will play with dolls equipped with personality chips, computers with inbuilt （成为固定装置的，嵌入墙内的；内在的，固有的）personalities will be regarded as workmates rather than tools, relaxation will be in front of smell television, and digital age will have arrived。
　　译文：儿童将与装有个性芯片的玩具娃娃玩耍，具有个性内置的计算机将被视为工作伙伴而不是工具，人们将在气味电视前休闲，到这时数字时代就来到了。
　　这句英语是由四个独立句构成的并列句，前三个句子都用简单将来时，最后一个句子用的是将来完成时，句子之间的关系通过时态、逗号和并列连词and表示得一清二楚。而汉语译文明显就是简单的叙述，至于句子之间的关系完全通过句子的语义表现出来：前三个句子可以看成是并列关系，最后一个句子则表示结果。
　　
二、英语多长句，汉语多短句
　　由于英语是"法治"的语言，只要结构上没有出现错误，许多意思往往可以放在一个长句中表达；汉语则正好相反，由于是"人治"，语义通过字词直接表达，不同的意思往往通过不同的短句表达出来。正是由于这个原因，考研英译汉试题几乎百分之百都是长而复杂的句子，而翻译成中文经常就成了许多短小的句子。
　　例如：Interest in historical methods had arisen less through external challenge to the validity of history as an intellectual discipline （身心的锻炼，训练；纪律，风纪，命令服从；惩戒，惩罚；学科，科目）and more from internal quarrels among historians themselves.
　　译文：人们对历史研究方法产生了兴趣，这与其说是因为外部对历史作为一门知识学科的有效性提出了挑战，还不如说是因为历史学家内部发生了争吵。
　　英文原句是个典型的长句，由27个词组成，中间没有使用任何标点符号，完全靠语法结构使整个句子的意思化零为整：less through...and more from构成一个复杂的状语修饰动词arisen。在中文翻译中，"产生兴趣"这一重要内容通过一个独立的句子表达，两个不同的原因则分别由不同的句子表达，整个句子被化整为零。
　　
三、英语多从句，汉语多分句
　　英语句子不仅可以在简单句中使用很长的修饰语使句子变长，同时也可以用从句使句子变复杂，而这些从句往往通过从句引导词与主句或其它从句连接，整个句子尽管表面上看错综复杂却是一个整体。汉语本来就喜欢用短句，加上表达结构相对松散，英语句子中的从句翻成汉语时往往成了一些分句。
　　例如：On the whole such a conclusion can be drawn with a certain degree of confidence but only if the child can be assumed to have had the same attitude towards the test as the other with whom he is compared, and only if he was not punished by lack of relevant information which they possessed.
　　译文：总的来说，得出这样一个结论是有一定程度把握的，但是必须具备两个条件：能够假定这个孩子对测试的态度和与他相比的另一个孩子的态度相同；他也没有因缺乏别的孩子已掌握的有关知识而被扣分。
　　原文中两个only if引导的从句显然使整个句子变得很复杂，可是由于有并列连词but和and，整句话的逻辑关系十分清楚：…能够得出结论…但是只要…而且只要…。从上面的译文我们可以看出，为了使中文表达更加清楚，but only if...and only if...首先提纲挈领：但是必须具备两个条件……，这种做法给我们的感觉是译文中没有从句，有的只是一些不同的分句。
　　
四、主语，宾语等名词成分“英语多代词，汉语多名词”
　　　　在句子中，英语多用名词和介词，汉语多用动词。
　　英语不仅有we、you、he、they等人称代词，而且还有that、which之类的关系代词，在长而复杂的句子，为了使句子结构正确、语义清楚，同时避免表达上的重复，英语往往使用很多代词。汉语虽然也有代词，但由于结构相对松散、句子相对较短，汉语里不能使用太多的代词，使用名词往往使语义更加清楚。请看下面的例句：
　　There will be television chat shows hosted by robots, and cars with pollution monitors that will disable them when they offend.
　　译文：届时，将出现由机器人主持的电视访谈节目及装有污染监测器的汽车，一旦这些汽车污染超标(或违规)，监测器就会使其停驶。
　　
五、英语多被动，汉语多主动
　　英语比较喜欢用被动语态，科技英语尤其如此。汉语虽然也有"被"、"由"之类的词表示动作是被动的，但这种表达远没有英语的被动语态那么常见，因此，英语中的被动在汉译中往往成了主动。下面我们先看一组常用被动句型的汉译：
　　It must be pointed out that...必须指出……
　　It must be admitted that...必须承认……
　　It is imagined that...人们认为……
　　It can not be denied that...不可否认……
　　It will be seen from this that...由此可知……
　　It should be realized that...必须认识到……
　　It is (always) stressed that...人们(总是)强调……
　　It may be said without fear of exaggeration that...可以毫不夸张地说……
　　这些常用被动句型属于习惯表达法，在科技英语中出现频率很高，考生不仅要熟悉这些句型的固定翻译，同时要认识到许多英语中的被动从习惯上来讲要译成汉语的主动。我们再看一个典型的例子：
　　And it is imagined by many that the operations of the common mind can by no means be compared with these processes, and that they have to be required by a sort of special training.
　　译文：许多人认为，普通人的思维活动根本无法与科学家的思维活动相比，认为这些思维活动必须经过某种专门训练才能掌握。
原文中有三个被动语态is imagined, be compared和be required，译成汉语都变成了主动表达：认为、相比和掌握。
有些英语被动需要把主语译成汉语的宾语，这样才能更加符合中文的表达习惯。
　　例如：New sources of energy must be found, and this will take time, but it is not likely to result in any situation that will ever restore （归还；恢复，复兴；恢复健康，复原）that sense of cheap and plentiful energy we have had in the past time.
　　译文：必须找到新的能源，这需要时间；而过去我们感觉到的那种能源价廉而充足的情况将不大可能再出现了。
　　
六、英语多变化，汉语多重复
　　熟悉英语的人都知道，英语表达相同的意思时往往变换表达方式。第一次说"我认为"可以用"I think"，第二次再用"I think"显然就很乏味，应该换成"I believe"或"I imagine"之类的表达。相比之下，汉语对变换表达方式的要求没有英语那么高，很多英语中的变化表达译成重复表达就行了。请看下面的例子：
　　The m<I>onkey</I>'s most extraordinary accomplishment was learning to operate a tractor. By the age of nine, the m<I>onkey</I> had learned to solo on the vehicle.
　　译文：这只猴子最了不起的成就是学会驾驶拖拉机。到九岁的时候，这只猴子已经学会了单独表演驾驶拖拉机了。tractor和vehicle在句中显然都表示"拖拉机"，英语表达上有变化，而译成汉语时使用了重复表达法。
　　
七、英语多抽象，汉语多具体
　　做翻译实践较多的人都有这样的体会：英文句子难译主要难在结构复杂和表达抽象上。通过分析句子的结构，把长句变短句、从句变分句，结构上的难题往往迎刃而解。表达抽象则要求译者吃透原文的意思、用具体的中文进行表达，这对考生往往具有更大的挑战性。
　　下面我们先看一组例子：
　　disintegration 土崩瓦解
　　ardent （热心的；热情的）loyalty 赤胆忠心
　　total exhaustion 筋疲力尽
　　far-sightedness 远见卓识
　　careful consideration 深思熟虑
　　perfect harmony （和声；和睦）水乳交融
　　feed on fancies 画饼充饥
　　with great eagerness 如饥似渴
　　lack of perseverance 三天打鱼，两天晒网
　　make a little contribution （捐款；捐助）添砖加瓦
　　on the verge of destruction 危在旦夕
　　从上面的例子不难看出，英语表达往往比较抽象，汉语则喜欢比较具体。我们再看一个翻译：
　　Until such time as mankind has the sense to lower its population to the points whereas the planet can provide a comfortable support for all, people will have to accept more "unnatural food."
　　译文：除非人类终于意识到要把人口减少到这样的程度：使地球能为所有人提供足够的饮食，否则人们将不得不接受更多的“人造食品”。
　　原文中有三个抽象的名词：sense, point和support和两个抽象的形容词comfortable和unnatural。根据大纲中词汇表提供的解释，sense可指“感觉”、“判断力”，point的意思是“点”，support的意思是“支撑(物)”、“支持(物)”，comfortable是“舒适的”，unnatural是“非自然的”，都是意思十分抽象的词，如果不进行具体化处理，译文就可能是这样：除非人类有这样的感觉，把人口减少到这样的，使地球能为大家提供舒适的支持，否则人们将不得不接受更多的"非自然的食物"。
　　
八、英语多引申，汉语多推理
　　英语有两句俗话：一是You know a word by the company it keeps.(要知义如何，关键看伙)，二是Words do not have meaning, but people have meaning for them.(词本无义，义随人生)。这说明词典对词的定义和解释是死的，而实际运用中的语言是活的。从原文角度来说，这种活用是词义和用法的引申，翻译的时候要准确理解这种引申，译者就需要进行推理。
　　例如：While there are almost as many definitions of history as there are historians, modern practice most closely conforms to one that sees history as the attempt to recreate and explain the significant events of the past.
　　译文：尽管关于历史的定义几乎和历史学家一样多，现代实践最符合这样一种定义，即把历史看作是对过去重大历史事件的再现和解释。
　　"recreate"根据构词法和一般词典上解释都是“重新创造”，而考研英语大纲词汇表中只有名词"recreation"，所给词义为"娱乐、消遣"，在这种情况下，考生很容易把recreate译成“重新创造”或者“娱乐”。仔细观察recreate不难发现它带有宾语the significant events of the part，从逻辑上来讲，"过去的重大历史事件"是不能"重新创造"的，作者显然对recreate一词的词义进行了引申。做翻译的人经常会有这样一种感受：某个词明明认识，可就是不知道该怎样表达。这其实就是词的引申和推理在起作用。
　　
九、英语多省略，汉语多补充
　　英语一方面十分注重句子结构，另一方面又喜欢使用省略。英语省略的类型很多，有名词的省略，动词的省略，有句法方面的省略，也有情景方面的省略。在并列结构中，英语往往省略前面已出现过的词语，而汉语则往往重复这些省略了的词。
　　例如：①Ambition is the mother of destruction as well as of evil.
　　野心不仅是罪恶的根源，同时也是毁灭的根源。
　　②Reading exercises one's eyes; Speaking, one's tongue; while writing, one's mind.
　　阅读训练人的眼睛，说话训练人的口齿，写作训练人的思维。
　　④One boy is a boy, two boys half a boy, three boys no boy.
　　在考研英译汉中，省略是一种很常见现象。例如：
　　Whether to use tests, other kinds of information, or both in a particular situation depends, therefore, upon the evidence from experience concerning comparative validity and upon such factors as cost and availability.
　　译文：因此，究竟是使用测试，其它种类的信息，还是在特定的情况下两者都使用，取决于关于相对效度的来自经验的证据，同时还取决于成本和可获得性这样的因素。
whether...or...是并列连词，or前面省略了不定式to use, and upon中间省了动词depends。
　　
十、英语多前重心，汉语多后重心
　　在表达多逻辑思维时，英语往往是判断或结论等在前，事实或描写等在后，即重心在前；汉语则是由因到果、由假设到推论、由事实到结论，即重心在后。
　　比较：I was all the more delighted when, as a result of the initiative of your Government it proved possible to reinstate the visit so quickly.
　　译文：由于贵国政府的提议，才得以这样快地重新实现访问。这使我感到特别高兴。
　　The assertion that it was difficult, if not impossible, for a people to enjoy its basic rights unless it was able to determine freely its political status and to ensure freely its economic, social and cultural development was now scarcely （不足地，不充分地；一定不，绝不）contested （斗争；比赛）.
　　译文：如果一个民族不能自由地决定其政治地位，不能自由地保证其经济、社会和文化的发展，要享受其基本权利，即使不是不可能，也是不容易的。这一论断几乎是无可置辩的了。

来自Sawin系统分析之窗

一个故事 :

我在很多软件公司工作过，公司规模有大有小，也和来自其他公司的人员交流，因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事，以便各位了解自动化测试会出现哪些问题。

以前，我们有一个软件项目，开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具，最后选择了一种，并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作，还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候，遇到了问题。这个测试工具太复杂，难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后， Jerry 认识到，他需要测试工具的技术支持人员到现场帮助安装测试工具，并找出其中的问题。在打过几个电话后，测试工具厂商派过来一位技术专家。技术专家到达后，找出问题所在，测试工具可以正常工作了。这还算是顺利了。但是，几个月后，他们还是没有真正实现测试自动化， Jerry 拒绝继续从事这个项目的工作，他害怕自动化测试会一事无成，只是浪费时间而已。

项目经理 Anita 把项目重新指派给 Kevin Shorttimer ，一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位，希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训，避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧，导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试，有点令人讨厌，因此，他非常愿意采用自动化测试。一个主要的版本发布后， Kevin 准备开始全天的自动化测试，他非常渴望得到一个机会证明自己可以写非常复杂的，有难度的代码。他建立了一个测试库，使用了一些技巧的方法，可以支持大部分的测试，这比原计划多花费了很多时间，不过， Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本，并且确实发现了 bug 。接下来， Kevin 得到一个从事软件开发职位的机会，离开了自动化的岗位。

Ahmed Hardluck 接手 Kevin 的工作，从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少，并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中， Ahmed 经历了很多失败，并且不能确信测试执行的方法是否正确。测试执行中，执行失败后的错误的提示信息也没有太多的参考价值，他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求，他更新测试环境搭建文档，坚持不懈地工作。后来，在自动化测试执行中，它发现几个执行失败的结果，经过分析，是回归测试的软件版本中有 BUG ，导致测试执行失败，发现产品的 BUG 后，每个人都很高兴。接下来，他仔细分析测试套中的内容，希望通过优化测试套使测试变得更可靠，但是，这个工作一直没有完成，预期的优化结果也没有达到。按照计划，产品的下一个发布版本有几个主要的改动， Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来，在测试产品的新版本中，绝大多数测试用例执行失败了， Ahmed 对执行失败的测试研究了很长时间，然后，从其他人那里寻求帮助。经过商讨，自动化测试应该根据产品的新接口做修改，自动化测试才能运转起来。最后，大家根据新接口修改自动化测试，测试都通过了。产品发布到了市场上。接下来，用户立刻打来投诉电话，投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本，导致一些错误提示信息被忽略了。虽然，实际上测试执行是失败的，但是，由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。

这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过，我希望你没有这样的相似结局。本文将给出一些建议，避免出现这样的结局。

问题

这个故事阐明了几个使自动化测试项目陷入困境的原因：

自动化测试时间不充足：根据项目计划的安排，测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间，无法得到真正的关注。

缺乏清晰的目标：有很多好的理由去开展自动化测试工作，诸如自动化测试可以节省时间，使测试更加简单，提高测试的覆盖率，可以让测试人员保持更好的测试主动性。但是，自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望，这些希望应该提出来，否则很可能面对的是失望。

缺乏经验：尝试测试自己的程序的初级程序员经常采用自动化自动化测试。由于缺乏经验，很难保证自动化测试的顺利开展。

更新换代频繁（ High turnover ）：测试自动化往往需要花费很多时间学习的，当自动化测试更新换代频繁的时候，你就丧失了刚刚学习到的自动化测试经验。

对于绝望的反应：在测试还远没有开始的时候，问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言，测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时，测试人员变得疲劳起来。测试什么时候后结束？当按照计划的安排，软件应该交付的时候，测试人员的绝望变得尤其强烈。如果不需要测试，那该有多好呀！在这种环境中，自动化测试可能是个可以选择的解决方法。但是，自动化测试却未必是最好的选择，他不是一个现实的解决方法，更像是一个希望。

不愿思考软件测试：很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况，自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂，导致很多自动化对软件测试并没有太大的帮助。

关注于技术：如何实现软件的自动化测试是一个很吸引人的技术问题。不过，过多的关注如何实现自动化测试，导致忽略了自动化测试方案是否符合测试需要。

遵守软件开发的规则

你可能了解 SEI （软件工程研究所）提出的 CMM （能力成熟度模型）。 CMM 分为 5 个界别，该模型用来对软件开发组织划分等级。 Jerry Weinberg （美国著名软件工程专家）也创建了自己的一套软件组织模型，在他的组织模型中增加了一个额外的级别，他称之为零级别。很显然，一个零模式的组织实际上也是开发软件；零模式组织中，在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中，经常采用自动化测试方法。因此，把资源用于自动化测试，并且把自动化测试当作一个软件开发活动对待，把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。

像其他软件开发项目一样，我们需要软件开发人员专注于测试自动化的开发任务；像其他软件开发项目一样，自动化测试可以自动完成具体的测试任务，对于具体的测试任务来说，自动化开发人员可能不是这方面的专家，因此，软件测试专家应该提供具体测试任务相关的咨询，并且提供测试自动化的需求；像其他软件开发项目一样，如果在开发编码之前，对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样，自动化测试代码需要跟踪和维护，因此，需要采用源代码管理。像其他软件开发项目一样，测试自动化也会出现 BUG ，因此，需要有计划的跟踪 BUG ，并且对修改后的 BUG 进行测试。像其他软件开发项目一样，用户需要知道如何使用软件，因此，需要提供用户使用手册。

本文中不对软件开发做过多讲述。我假定您属于某个软件组织，该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的，重点关注测试自动化相关的事宜和挑战。

•  改进软件测试过程

•  定义需求

•  验证概念

•  支持产品的可测试性

•  可延续性的设计（ design for sustainability ）

•  有计划的部署

•  面对成功的挑战

步骤一：改进软件测试过程

如果你负责提高一个商业交易操作的效率，首先，你应该确认已经很好的定义了这个操作的具体过程。然后，在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前，你想知道是否可以采用更简单、成本更低的的方法。同样的，上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率，使测试过程更为快捷，没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

例如，很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行，再执行，去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行，并且单调乏味。怎样才能做好回归测试文档化的工作呢？通常的做法是采用列有产品特性的列表，然后对照列表检查。这是个很好的开始，回归测试检查列表可以告诉你应该测试哪些方面。不过，回归测试检查列表只是合于那些了解产品，并且知道需要采用哪种测试方法的人。

在你开始测试自动化之前，你需要完善上面提到的回归测试检查表，并且，确保你已经采用了确定的的测试方法，指明测试中需要什么样的数据，并给出设计数据的完整方法。如果测试掌握了基本的产品知识，这会更好。确认可以提供上面提到的文档后，需要明确测试设计的细节描述，还应该描述测试的预期结果，这些通常被忽略，建议测试人员知道。太多的测试人员没有意识到他们缺少什么，并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果，因为，现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前，必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过，这时候千万不要走极端去过分细致地说明测试执行的每一个步骤，只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是，不要假定他们理解那些存留在你头脑中的软件测试执行的想法，把这些测试设计的思路描述清楚就可以了。

我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后，决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷，针对每个缺陷，我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表，这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后，我没有机会完成测试自动化的实现工作。不过，当我们需要对这个模块做完整回归测试的时候，我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导，几乎不需要任何指导的情况下，各自完成了回归测试，并且发现了 BUG 。从某种角度看，这实际上是一次很成功的自动化测试。在这个项目中，我们与其开发自动化测试脚本，还不如把测试执行步骤文档化。后来，在其它项目中，我们开发了自动化测试脚本，发现相关人员只有接受相关培训才能理解并执行自动化测试脚本，如果测试自动化设计的很好，可能会好一些。不过，经过实践我们总结出完成一份设计的比较好的测试文档，比完成一份设计良好的测试脚本简单的多。

另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机，这一点显而易见。我之所以强调采用更多的计算机是因为，我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作，这种情况下由于错误的使用了测试设备、测试环境，导致测试没有效果。因此，自动化测试需要集中考虑所需要的支撑设备。

针对改进软件测试过程，我的最后一个建议是改进被测试的产品，使它更容易被测试，有很多改进措施既可以帮助用户更好的使用产品，也可以帮助测试人员更好的测试产品。稍后，我将讨论自动化测试的可测试需求。这里，我只是建议给出产品的改进点，这样对手工测试大有帮助。

一些产品非常难安装，测试人员在安装和卸载软件上花费大量的时间。这种情况下，与其实现产品安装的自动化测试，还不如改进产品的安装功能。采用这种解决办法，最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序，该程序可以和产品一同发布。事实上，现在有很多专门制作安装程序的商用工具。

另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法，在日志中一页一页的查询报错信息很容易会让人感到乏味。那么，赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式，写出一个错误扫描程序是很容易的事情。如果，你不能确定日志中的错误信息格式，就开始动手写错误扫描程序，很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式，使其适合日志扫描程序，便于扫描工具能够准确的扫描到所有的错误信息。这样，在测试中就可以使用扫描工具了。

通过改进产品的性能对测试也是大有帮助的。很显然的，如果产品的性能影响了测试速度，鉴别出性能比较差的产品功能，并度量该产品功能的性能，把它作为影响测试进度的缺陷，提交缺陷报告。

上面所述的几个方面可以在无需构建自动化测试系统的情况下，大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间，不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。

步骤二：定义需求

在前面的故事中，自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况，需要在自动化测试需求上保持一致。应该有一份自动化测试需求，用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来，自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情，但是，他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因：

•  加快测试进度从而加快产品发布进度

•  更多的测试

•  通过减少手工测试降低测试成本

•  提高测试覆盖率

•  保证一致性

•  提高测试的可靠性

•  测试工作可以由技术能力不强测试人员完成

•  定义测试过，避免过分依赖个人

•  测试变得更加有趣

•  提高了编程技能

开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致，否则很难定义什么是成功的自动化测试。

当然，不同的情况下，有的自动化测试目标比较容易达到，有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高，测试人员必须能理解充分的理解自动化测试，从而通过自动化测试不断发现软件的缺陷。不过，自动化测试不利于测试人员不断的积累测试经验。不管怎么样，在开始自动化测试之前应该确定自动化测试成功的标准。

手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源，建立测试环境，执行测试用例。测试过程中，如果有什么异常的情况发生，手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果，记录测试结果，复位被测试的软件系统，准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况，研究测试过程可疑的现象，寻找测试用例执行失败的过程，设计并执行其他的测试用例帮助定位软件缺陷。接下来，他们写作缺陷报告单，保证缺陷被修改，并且总结所有的缺陷报告单，以便其他人能够了解测试的执行情况。

千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分，部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择，或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲，除非测试的各个环节都采用自动化方式，否则不是真正意义上的自动化测试，这真是胡言乱语。如果仅仅是为了寻找挑战，可以尝试在测试的每个环节都采用自动化方法。但是，如果寻找成功测试的方法，请关注那些可以快速建立的，可以反复利用的自动化测试。

定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况，然后给出权衡后的需求，并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求，距离成功的自动化测试近了一步。

步骤三：验证概念

在前面的故事当中，那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过，在项目的进行中，他得到了来自各个方面的支持。

你可能还没有认识到这一点，不过，你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长，并且需要来自你身边的各种人的帮助。

很多年前，我从事一个测试自动化项目的工作，参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统，并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度，甚至演示已经完成的部分功能。但是，我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后，整个项目被取消了，此后，我再也没有犯这个错误。

你需要尽可能快地验证你采用的测试工具和测试方法的可行性，站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的，需要尽快地找出可行性问题的答案，需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性，从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。

对于很多人来说，自动化测试意味着 GUI 自动化测试，我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试，并惊奇的发现这两类测试的测试计划有很大的互补性。不过， GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的，因为，如果没有选择合适的测试工具，你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中，找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期，你可能打算现在购买一份测试工具，然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前，找出工具存在的问题。这样，你可以从测试工具供应商得到更好的帮助，当你打算更换工具的时候，你不会感觉很为难。

下面是一些候选的验证概念的试验：

回归测试：你准备在每个版本运行同样的测试用例吗？回归测试是最宜采用自动化测试的环节。

配置测试：你的软件支持多少种不同的平台？你打算在所有支持的平台上测试执行所有的测试用例吗？如果是的，那么采用自动化测试是有帮助的。

测试环境建立：对于大量不同的测试用例，可能需要相同的测试环境搭建过程。在开展自动化测试执行之前，先把测试环境搭建实现自动化。

非 GUI 测试：实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。

无论采用什么测试方法，定义一个看得见的目标，然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

步骤四：支持产品的可测试性

软件产品一般会用到下面三种不同类别的接口：命令行接口（ command line interfaces ，缩写 CLIs) 、应用程序接口（ API ）、图形用户接口（ GUI ）。有些产品会用到所有三类接口，有些产品只用到一类或者两类接口，这些是测试中所需要的接口。从本质上看， API 接口和命令行接口比 GUI 接口容易实现自动化，去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候，这两类接口隐藏在产品的内部，如果确实没有，需要鼓励开发人员在产品中提供命令行接口或者 API 接口，从而支持产品的可测试性。

下面，更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能，这确实是个很好的方法。可以手工执行测试用例，测试工具在后台记住你的所有操作，然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法，但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本，但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果， GUI 测试还是主要由手工完成。

第二个原因，把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难，解决方法总是有的，可以采用修改产品源代码的方式，也可以从测试工具供应商处升级测试工具。另外，还需要分析测试工具中的 BUG ，并且给工具打补丁。也可能测试工具需要做相当的定制，以便能有效地测试产品界面上的定制控件。 GUI 测试中，困难总是意外出现，让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

第三个原因， GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中，图形界面经常被修改或者完全重设计，这是出了名的事情。一般来讲，第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候，就开展 GUI 自动化测试是不会有任何进展的，你只能花费大量的时间修改测试脚本，以适应图形界面的变更。不管怎样，即便界面的修改会导致测试修改脚本，你也不应该反对开发人员改进图形界面。一旦原始的设计完成后，图形界面接口下面的编程接口就固定下来了。

上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试，可以考虑实现 GUI 测试自动化。不过，你也应该考虑采用其他方法测试产品的核心功能，并且这些测试不会因为图形界面发生变化而被中断，这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试，因为，他们不打算修改被测试产品，但是，最终他们认识到必须对产品做修改，以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法，自动化都需要对被测试的产品做修改。因此，采用可编程的接口是最可靠的。

为了让 API 接口测试更为容易，应该把接口与某种解释程序，例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能，并且可以缩短自动化测试的开发周期。采用 API 接口的方式，还可以实现独立的产品模块的单元测试自动化。

一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项，采用这种选项可以实现非 GUI 方式的安装盘，采用这种方式，从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。

另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的，所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口，完成这类的自动化测试。采用高级接口技术，譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是，如果在合适的环境中采用这种方式，你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。

我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试，该产品也提供命令行接口，不过，他们已经实现了 GUI 的自动化测试。经过一段时间的研究，我发现找到图形界面中的 BUG 并不困难，不过，用户并不关注图形界面，他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能（这些功能即可通过 GUI 的方式，也可以通过命令行的方式使用）实现自动化测试。我决定推迟 GUI 自动化测试，扩展命令行测试套，测试新增的产品功能。现在过头看这个决定，我没有选择 GUI 自动化测试是最大的成功之处，如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了，并且已经购买了一套测试工具和其他需要的东西，但我知道在开展具体的 GUI 自动化测试活动中，会遇到各种各样的困难和障碍。

无论你需要支持图形界面接口、命令行接口还是 API 接口，如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求，未来的测试工作中，你很可能成功。尽可能早的启动自动化测试项目，提出可测试性需求，会使您走向自动化测试成功之路。

步骤五：具有可延续性的设计

在开篇的故事中，我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来，导致测试自动化达不到预期的效果。自动化测试是一个长期的过程，为了与产品新版本的功能和其他相关修改保持一致，自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的，不过，自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过，测试人员应该相信得到的结果，测试执行的实际结果也应该是通过了。其实，有很多存在问题的测试用例表面上执行通过了，实际上却执行失败了，并且没有记录任何错误日志，这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果，而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误，都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

性能： 提高代码的性能往往增加了代码的复杂性，因此，会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析，很多测试套都是花费大量的时间等候产品的运行。因此，在不提高产品运行性能的前提下，无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能，而并没有实际的操作经验。如果测试套的性能问题无法改变，那么应该考虑提高硬件的性能；测试套中经常会出现冗余，也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务，都是很好的办法。

便于分析： 测试自动化执行失败后应该分析失败的结果，这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情，需要从多方面着手，测试上报的告警信息是真的还是假的？是不是因为测试套中存在缺陷导致测试执行失败？是不是在搭建测试环境中出现了错误导致测试执行失败？是不是产品中确实存在缺陷导致测试执行失败？有几个方法可以帮助测试执行失败的结果分析，某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题，从而提高测试套的可靠性；通过改进错误输出报告，从而提高测试自动化的错误输出的可分析性；此外，还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试，然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外，有一种错误的测试结果分析方法，那就是采用测试结果后处理程序对测试结果自动分析和过滤，尽管也可以采用这种测试结果分析方法，不过这种方法会使自动化测试系统复杂化，更重要的是，后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常，那该怎么办？我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本，并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣，他们排斥采用隐藏测试复杂度的方法。

综上所述，应该集中精力关注可以延续使用的测试套，从以下几方面考虑，测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

可读性： 很多情况下，在测试人员开始测试项目之前，公司已经有了一套测试脚本，并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它，但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性，在具体应用中，那些脚本常常没有多大的实用价值，越来越让人迷惑。因此，测试人员很难确定他们实际在测试什么，反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本，并且理解测试脚本究竟测试了什么，这是很关键的。好的文档是解决问题的手段之一，对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法，我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩，把所有执行的产品相关的命令记录到日志里。这样，当分析日志确定执行了哪些产品命令，命令采用了何种参数配置时，可以提供一个非常好的测试记录，里面记录了自动化测试执行了什么，没有执行什么。如果测试脚本可读性不好，很容易变得过分依赖并没有完全理解的测试脚本，很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后，可以更容易的开展同行评审活动。

可维护性： 在工作中，我曾经使用过一个测试套，它把所有的程序输出保存到文件中。然后，通过对比输出文件内容和一个已有的输出文件内容的差别，可以称已有的输出文件为 “ 标准文件 ” （ “gold file” ）。在回归测试中，用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了，它会产生很多错误的警告。随着时间的推移，软件开发人员会根据需要修改产品的很多输出信息，这会导致很多自动化测试失败。很明显，为了保证自动化测试的顺利进行，应该在对 “ 标准文件 ” 仔细分析的基础上，根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是，每次只检查选定的产品的某些特定输出，而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试，这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改，并研究使测试修改量最小的方法，测试中采用库是解决问题的方法。当产品发生变化的时候，只需要修改相关的库，保证测试与产品的变动同步修改即可。

完整性： 当自动化测试执行后，报告测试执行通过，可以断定这是真的吗？这就是我称之为测试套的完整性。在前面的故事中，当没有对自动化测试完整性给予应有的关注的时候，发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果？自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败，但是，对于自动化测试误报告警的情况，大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效，当测试发现异常的时候，能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法，分类包括 PASS ， FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果，它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分，另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ，这个 BUG 引起测试队列中部分测试用例被跳过，没有执行。当测试队列运行完毕后，没有上报任何错误，我不得不通过走读代码的方式发现了这个 BUG 。如果，我没有关注到这个 BUG ，那么可能在认识到自动化测试已经出现问题之前，还在长时间运行部分测试用例。

独立性： 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候，通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化，测试执行是由一台不会说话的计算机完成的，你必须告诉计算机什么样的情况下测试执行是失败的，并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境，因此，保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档，以便一个接着一个有序地完成测试执行，每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误，这个错误源于 “ 多米诺骨牌 ” 测试套，当一个测试执行失败，会导致后续一系列测试失败。更糟糕的是，所有的测试关联紧密，无法独立的运行。并且，这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后，人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式，不过，重要的是在不牺牲测试的可靠性的前提下保证测试的独立性，如果测试可以在无需人看守情况下运行，那么测试的执行效率就不是大问题了。

可重复性： 自动化测试有时能够发现问题，有时候又无法发现问题，对这种情况实在没有什么好的的处理办法。因此，需要保证每次测试执行的时候，测试是以同样的方式工作。这意味着不要采用随机数据，在通用语言库中构造的随机数据经常隐藏初始化过程，使用这些数据会导致测试每次都以不同的方式执行，这样，对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试，需要在可预测，并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据，然后在测试过程中使用这些数据。这样做看起来似乎很好，但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候，往往匆匆忙忙整文件名和测试数据记录。当对这些测试采用自动化测试方法，该做哪些工作呢？办法之一是，可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用，那么就需要制定命名规则，避免在不同的测试中命名冲突，采用命名规则是一种很好的方法。然而，我曾经看到有些测试只是随机的命名数据记录，很不幸，事实证明采用这种随机命名的方式不可避免的导致命名冲突，并且影响测试的可重复性。很显然，自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次，测试数据记录的名字中包含四个随机产生的数字，经过简单的推算如果我们采用这种命名方式的时候，如果测试使用了 46 条记录，会存在 10% 冲突的可能性，如果使用 118 条记录，冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录，这样引入了问题，损害了测试的可靠性和测试的完整性。

测试库： 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库，自己也写了一些。当要求测试不受被测试产品接口变动影响的时候，采用测试库方法是非常有效的。不过，根据我的观察测试库已经使用的太多了，已经被滥用了，并且测试库往往设计的不好，没有相关的文档支撑，因此，使用测试库的测试往往很难开展。当发现问题的时候，往往不知道是测试库自身的问题，还是测试库的使用问题。由于测试库往往很复杂，即便在发现测试库存在问题，相关的维护人员也很不愿意去修改问题。通过前文中的论述，可以得出结论，在一开始就应该保证测试库设计良好。但是，实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致，即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复，我发现微小的变化可能仍然存在，很难与测试库功能协调。你可能打算对测试用例作修改，采用源代码的方式比采用库的方式更容易修改。如果有几个测试，他们有某些共同的操作，我使用剪切和粘贴的方式去复制代码，有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码，我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的，因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试，并且很方便扩展测试套。在开发软件测试项目的时候，大多数程序员找到与他们打算实现功能类似的源代码，并对源代码做修改，而不是从头开始写代码。同样，在写测试套的过程中可以采用上述方法，这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库，这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义，并且文档化，从始至终都应该保持。我会对测试库作充分的测试后，才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库，不要希望有朝一日测试人员会利用你的测试库完成大量的测试，这一天恐怕永远不会到来。

数据驱动测试： 把测试数据写入到简单表格中，这种测试技术得到了越来越广泛的应用，这种方法被称为表驱动（ table-driven ），数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试（ "third generation" automation ）。这需要写一个解析器，用来解释表格中的数据，并执行测试。该测试架构的最主要的好处是，它允许把测试内容写在具有一定格式的表格中，这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试，采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的，所以，上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作，还存在各种困难。代码所采用的编程语言是不断发展的。也许，测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入，这样，加入了新的变量。接下来，也许有人需要让测试中的某个环节运行一百次，这样加入一个循环。你可以采用其他语言，不过，如果你预料到会面临上述情况的时候，那么做好采用一些能够通过公开的渠道获取的编程语言，比如 Perl,Python 或者 TCL ，这样比设计你自己的语言要快的多。

启发式确认： 我曾经看到很多测试自动化没有真正意义上的结果校验，其原因有两个，一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的，另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过，采用手工校验测试结果的方法是真正意义上的测试校验。标准文件（ Gold file ）是另外一中校验测试结果的方法。首先，捕获被测试程序的输出，并检视程序的输出，然后，把输出信息文档化，并归档，作为标准文件。以后，自动化测试结果与标准文件作比较，从而达到结果校验的目的。采用标准文件的方法，也有弊端。当产品发生变化，自动化测试的环境配置发生变化，产品的输出发生变化的时候，采用标准文方法，会上报大量的误报告警。做好的测试结果校验方法是，对输出结果的特定内容作分析，并作合理的比较。有时候，很难知道正确的输出结果是什么样的，但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法，是因为担心如果结果校验漏掉了任何信息，可能导致自动化测试自身出现错误。不过，我们在测试过程中往往采用折衷的做法，没有采用大而全的测试结果校验方法，这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法，那么他必须找相关人员咨询，寻找一种合适的测试结果校验策略，这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下，找到被测试产品的缺陷。

把注意力放在通过设计保证测试的可延续性上，选择一个合适的测试体系架构，你将进一步迈向成功的自动化测试。

步骤六：有计划的部署

在前面的故事中，当自动化工程师没有提供打包后的自动化测试程序给测试执行人员，会影响到测试执行，测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

作为自动化工程师，你知道如何利用自动化方法执行测试和分析执行失败的结果。不过，测试执行人员却未必知道如何使用自动化测试。因此，需要提供自动化测试程序的安装文档和使用文档，保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配，出现安装错误的时候，能够给出有价值的提示信息，便于定位安装问题。

能够把自动化测试程序和测试套作为产品对待，那真是太好了。你应该对自动化测试程序和测试套开展测试，保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作；保证自动化测试是符合一般测试执行人员的思维习惯的；保证测试执行人员能够理解测试结果，并能够正确分析失败的测试执行结果；这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

作为测试管理者，你希望在自动化工程师离开前，能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的，如果你没有及时的把测试套中的问题提出来，就会面临废弃已有的测试套的决定。

良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试；良好的测试套在新的软件平台上可以很方便的验证产品的功能；良好的测试套支持每天晚上开始的软件每日构造过程；甚至开发人员在代码 check in 之前，用良好的测试套验证代码的正确性。

测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此，尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上，这是个很好的办法。这样，大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美，而没有拿出来与人分享，这种做法一定要改变，共享出来的测试套不一定非常完美，共享才是关键。

有计划的自动化测试部署，保证你的测试套能够被产品相关人员获取到，你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

步骤七：面对成功的挑战

当你完成了所有的事情，测试套已经文档化了，并且文档已经交付了。测试执行人员能够理解要开展的测试，并知道如何完成测试执行。随着你所负责产品的进一步开发和维护，测试被反复重用。虽然，在自动化使测试变简单的同时，也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况，如果不这样做，测试执行人员会认为执行失败的情况是由自动化引起，然后，自动化工程师被叫过来帮助诊断每一个执行失败的情况，开发人员往往也会认为执行失败是由于自动化测试自身引起的问题，这样，测试执行人员就不得不学习通过手工的方式，或者通过采用少量脚本的方式重现自动化测试发现的问题，以证明他们确实发现了产品当中的 BUG 。

测试套的相关工作还没有结束，为了提高测试覆盖率或者测试新的产品特性，需要增加更多的测试。如果已有的测试不能正常工作，那么需要对之修改；如果已有的测试是冗余的，那么需要删除这部分测试。

随着时间的推移，开发人员也会研究你设计的测试，改进产品的设计并且通过模拟你的测试过程对产品做初步测试，研究如何使产品在第一次测试就通过，这样，你设计的测试很可能无法继续发现新的问题，这种现象被称为一种杀虫剂悖论。这时候，会有人对你的测试有效性提出质疑，那么，你必须考虑是否应该挖掘更严格的测试，以便能够发现开发人员优化之后的产品中的缺陷。

以前，我提到过一个基本上无法实现的设想，设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的，手工测试是永远无法完全替代的。

p>有些测试受测试环境的影响很大，往往需要采用人工方法获取测试结果，分析测试结果。因此，很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题，因此，千万不要陷入到一切测试都采用自动化方法的错误观念中。

我曾经主张保证给与测试自动化持续不断的投入。但是，在开展自动化测试的时候，一个问题摆在面前，测试自动化应该及时的提供给测试执行人员，这个不成问题，但是如何保证需求变更后，能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步，那么自动化测试的效果就无法保证了，测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期，然后把这个日期作为里程碑，并计划达到这个里程碑。当达到这个里程碑后，自动化工程师应该做什么呢？如果自动化工程师关注当前产品版本的发布，他需要为测试执行人员提供帮助和咨询，但是，一旦测试执行人员知道如何使用自动化测试，自动化测试工程师可以考虑下一个版本的测试自动化工作，包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候，如果考虑了自动化测试需求，那么自动化测试师的设计工作就很好开展了，采用这种方法，自动化测试工程师可以保持与开发周期同步，而不是与测试周期同步。如果不采用这种方式，在产品版本升级的过程中，自动化测试无法得到进一步的改进。

持续在在自动化投入，你会面临成功的挑战，当自动化测试成为测试过程可靠的基础后，自动化测试的道路将会越来越平坦。

1、引言

软件界面是人与计算机之间的媒介。用户通过软件界面来与计算机进行信息交换。因此，软件界面的质量，直接关系到应用系统的性能能否充分发挥，能否使用户准确、高效、轻松、愉快地工作，所以软件的友好性、易用性对于软件系统至关重要。目前国内软件开发者在设计过程中很注重软件的开发技术及其具有的业务功能，而忽略了用户对软件界面的需求，影响软件的易用性、友好性；对界面设计的研究也集中在界面设计技术、设计手段上面。软件开发人员在设计时以经验为参考依据，缺乏对实际用户需求的了解。而软件的友好性、易用性同用户特征紧密相联，同样的软件界面，不同用户可能有绝然相反的评价。因此分析用户特征、了解用户需求和操作习惯，是开发软件界面的必有步骤，必须引起足够重视。

本文讨论了一种界面需求分析的方法，意在探讨研究如何完成针对系统所有用户的界面需求定义,从而开发为用户所接受的界面。讨论该方法的目的在于帮助设计人员快速明确用户的界面需求，让用户充分参与到界面需求分析中，从而在最终界面需求说明中体现用户的思想，满足用户要求。

2、界面需求分析过程

2．1界面元素

通常一个软件界面的元素包括界面主颜色、字体颜色、字体大小、界面布局、界面交互方式、界面功能分布、界面输入输出模式。其中，对用户工作效率有显著影响的元素包括：输入输出方式、交互方式、功能分布，在使用命令式交互方式的系统中，命令名称、参数也是界面元素的内容，如何设计命令及参数也很重要。影响用户对系统友好性评价的元素则有：颜色、字体大小、界面布局等，这种划分不是绝对的，软件界面作为一个整体，其中任何一个元素不符合用户习惯、不满足用户要求都将降低用户对软件系统的认可度，甚至影响用户的工作效率，而使用户最终放弃使用系统。围绕界面元素所要达到的设计目的是让最终用户能够获得美感、提高工作效率、易于操作使用系统。

目前在界面元素的选择、布局设计等方面的研究进行得较多,内容涵盖了人机工程学、认知心理学、、美学、色彩理论等方面的探讨。

2．2用户角色

界面需求分析必须围绕用户为中心，不同于客观功能需求分析，具有很大的主观性。虽然，界面设计人员可以按照通行的原则来设计，但是用户个体的文化背景、知识水平、个人喜好等是千差百异的，其界面需求也是相差很大。不同的用户，对软件界面有不同的要求，表达自己要求的方式也尽不相同。而且用户的界面要求通常不象业务功能需求那样容易明确、有据可查、可以利用专门工具进行分析。多数用户往往并不能提出明确的、全局的界面需求，其需求同自身主观因素联系紧密，是模糊、变化的。调查用户的界面需求，必须先从调查用户自身特征开始，将不同特征用户群体的要求进行综合处理，再有针对性地分析其界面需求。因此这里引出用户角色这个概念模型。

用户角色是指按照一定参考体系划分的用户类型，是能够代表某种用户特征、便于统一描述的众多用户个体的集合。用户调查的目标是通过调查分析用户特征，将每个不能建立模型的单一用户归纳为集合，将用户集合定义为角色模型，同时赋予不同的优先级别，了解记录其界面需求。用户的需求调查和其特征调查即用户角色定义，往往同时进行。调查的方法有很多种，如直接交流、资料统计、表格调查等。用户角色定义的原则是有代表性、同系统功能有关并有利界面的需求分析。一个用户角色可能包括大量的用户个体，他们对于界面的要求可以按照一定的界面模型进行定义。在一个软件系统中，用户角色定义时所依据体系可以多种多样，一个单一用户可以属于不同参考体系下的不同用户角色，但是一个用户角色要求能够代表一种界面需求类型。如收银员就是按照用户工作职位划分出来一个用户角色，如果按照操作计算机的熟练程度，属于收银员角色中的系统用户又可以分为：熟练用户、生疏用户。

用户角色定义就是人机工程学理论在软件开发过程中的一种应用。用户角色的确定可以根据系统需求方提供的用户资料和行业经验，如美学观念、用户计算机水平、用户工作内容等对用户进行初始角色定义，然后在需求调查过程中进行修正扩充。

之所以要定义用户角色，是因为不同的用户角色在需求分析过程中的需求目标不同，侧重点也不同，甚至互相矛盾。在一个大型系统中,需求分析人员面对的用户只能是众多单一的用户个体，他们的需求千奇百怪。只有明确了用户角色，需求分析人员才能在纷乱复杂而又不甚明了的用户要求中理出脉络，依据用户角色不同的优先级别，平衡众多用户需求中的矛盾，抽象出完整的GUI界面模型。

2．3需求变化

我们知道用户对于界面通常只能提出基本的要求，而且提出的要求也不一定科学，因此如何诱导用户在项目进行中尽早明确自己的需求，是任何需求分析人员都会面临的问题。

用户对目标系统的认识和需求的变化过程如下图所示：

对比修改

理想系统

目标系统

评审

设计实现

分析开发人员

用户要求

用户根据自己想象中的理想系统向分析开发人员提出自己的要求。开发方实现目标后交给用户，在系统实施运行后，用户将实际目标系统同自己想象中的理想系统对比，同时目标系统的使用会刺激用户修正想象中的理想系统，然后提出新的需求。由于软件界面的评审因素同用户的心理状况、认识水平有很大关系，所以对于软件界面，用户只有在使用过之后才能知道是否符合自己的操作习惯，颜色、字体等界面元素是否满足自己的要求，从而提出更明确的要求。

2．4界面原型

由于在软件开发前期，用户的界面需求很模糊，甚至没有自己的理想模型，用户提出的要求就很难量化，结果很容易被需求分析人员忽略。因此在用户角色定义完成后应用快速原型法来设计用户界面，可以帮助用户尽快完善自己的理想模型。

利用界面原型可以将界面需求调查的周期尽量缩短，并尽可能满足用户的要求。快速原型法是迅速地根据软件系统的需求产生出软件系统的一个原型的过程，其主要好处是可尽早获得更完整、更正确地需求和设计。利用界面原型，用户可以很感性地认识到未来系统的界面风格以及操作方式，从而迅速作出判断：系统是否符合自己的感官期望，是否满足自己的操作习惯，是否能够满足自己工作的需要。需求分析人员可以利用界面原型，诱导用户修正自己的理想系统，提出新的界面要求。

因此，界面需求分析的步骤可为：确定所涉及的界面元素，分析用户特征并定义用户角色，依据用户角色的界面需求设计界面原型并不断进完善。

3需求分析结果

3．1面向用户的分析结果

用户角色的优先等级是将不同用户的要求进行综合处理的重要参考依据。不同用户角色对界面的要求体现在界面元素的属性上，界面元素构成用户界面。界面元素的属性不同，最终的界面风格就不同。同一个系统中的不同用户角色，面对界面原型，提出的要求可能产生冲突，需求分析时依据用户角色优先级别的不同，对界面原型作出对应修改。

不同用户角色的需求在目标系统中实现方法也有不同。用户需求是否目标系统中得到体现，取决于实现用户需求所带来的成本、效益，并不是所有的用户界面需求都会体现在系统界面中。界面同用户联系紧密，在特定情况下，可以利用培训用户的方式使用户满足系统的要求。

友好的目标系统应该是同用户的理想模型接近甚至一致的，因此需求分析最终应该充分明确用户的潜在需求，并将用户需求在目标系统中实现。在需求分析过程中用户面对的始终是感性的可视化的实际运行界面，因此界面需求的结果就是满足自己要求的目标系统界面。

3．2面向设计人员

由于应用快速原型法后可以直接通过改进原型得到目标系统，而不必从头做起，所以一般可结合表格法一起进行分析，以利于形成准确的需求说明书。表格法就是将软件界面的构成元素分解为不同类别的最小单位并加以描述，按照划分后的元素单位拟定不同的设计方案，列出详细表格，用户可以按照描述说明作出自己的选择。如以下表格：

字体及大小
标题文字
小四
宋体加粗

输入框文字
五号
宋体

菜单文字
五号
宋体

命令文字
小四
宋体

帮助文字
五号
仿宋

表格的设计原则为以界面元素为基本内容，依据用户角色和系统功能进行合理分割，能够全面、准确描述界面风格。其内容可以固定为三个部分：平面设计、交互方式定义、功能模型定义。平面设计包括视觉设计、听觉设计等，通常是用户直接可以感受到的界面元素，能让用户从心理上获得舒适感、愉悦感。交互方式定义指计算机系统及软件系统同用户交流信息的方式，包括鼠标、键盘等的使用，是否有命令模式，是否有语音输出，信息显示方式等内容。功能模型定义是指根据每个用户角色要完成的一系列工作和任务，将对应系统功能按照一定的优先级建立成特定的模型，按照这种模型来来组织界面布局，方便用户完成一系列工作。实际上，大家用得很多的菜单和导航功能就同用户角色的工作系列有关。

利用表格形成文档，目的在于方便交流，并在设计人员和用户之间建立一座沟通的桥梁。

4结束语

界面需求分析的结果应该是清晰、准确、符合用户习惯、满足人机工程学要求的界面设计方案，能够形成清晰的开发文档。该文介绍了将模糊却又时时存在的用户需求转化为清晰、准确的需求定义文档的一种方法。该方法可以作为进行需求分析的基本思路在实际项目中扩充发展、灵活应用。

目前该方法在多个项目中得到实践应用，对提高软件系统友好性、降低系统实施成本方面颇有意义。

论软件产品设计中的需求分析

【摘要】优秀的产品设计可能是软件企业发展的重要契机。本文从功能设计角度论述怎样通过对技术、业务的分析和把握来设计具有良好适应性和可重用性的软件产品。

　　软件产品是指软件开发商根据市场需要开发的、具有一定适用性和潜在客户的、可销售的软件成品。它区别于应特定客户需求或根据订单开发的软件商品，通常应具有更高的通用性和适应性。但它的通用性和适应性不是轻而易举就能达到的。要实现软件的产品化，就必须在软件产品的设计上下一番功夫。
本文结合一个"多媒体远程教学系统"实例，探讨软件产品设计中的一些经验与看法。
一、软件产品设计的重要意义

　　所谓软件产品设计，在本文中指对软件产品的功能与架构进行设计。用传统的软件工程术语来说，它覆盖软件工程的可行性研究、需求分析、系统设计几个阶段。用RUP（Rational Unified Process－统一软件过程）术语来说，它是需求定义与软件构架设计的结果。

　　软件产品设计包括了需求分析、功能定义、技术方案以及需求管理的策略。

　　我们可以看见很多这样的例子：企业做完一个产品后，便不得不长期甚至永久地投入几个人（通常还是曾参与研发的技术骨干）对产品进行维护、跟踪和服务；企业在做同类项目时，还不得不投入几乎相等的资源；系统集成企业或以管理类项目为主的研发企业长期为工程所困，良好的市场需求并不能带来利润回报的规模增加，等等。造成以上现象，一是由于企业的软件过程成熟度不高，另一个原因，就是缺乏清晰、深入的软件产品设计。优秀的产品设计可能是软件企业发展的重要契机。好的产品设计可能使企业走向产品系列化、服务规范化、内部管理规范化的良性发展之路；而差的产品设计不仅将造成现实的资源浪费，甚至有可能使产品从此成为软件企业的一个枷锁。

　　其实，产品设计的来源最终都是市场。设计的好与不好，反映了设计者对技术、业务、以及用户需求诸方面的现状以及变化规律把握的结果。下面从功能定位入手，探讨怎样进行产品设计。我们所举的例子的主体假设是一个典型的系统集成企业，在多媒体系统集成项目上有较多的工程经验，在软件研发上也小有积累，市场研究认为多媒体技术在培训、教学领域将大有可为。

二、软件产品的分类及定位

　　与一般的针对用户明确需求的软件项目的需求分析稍有不同，软件产品的功能定义更多的是一种"定义"，而不象面向特定用户的系统，其需求定义是一种记录、归纳和分析的过程。它看起来的自由度比较大。正是这种自由度可以带来产品的升华，使工程产品化。即使对于特定用户的软件需求，我们也有必要在满足特定用户的特定需求的同时，对相关技术和业务进行适当的分析和预期，使得项目的成果具有更好的适用性和重用价值。

　　软件产品可以分为两种：面向最终用户的和面向软件开发或集成商的。第一种主要指面向不限于计算机技术人员、完成一定应用功能的系统；后者指供专业的软件开发人员使用、用于构造第一种产品的"中间"产品，它可能是一个完整的系统平台，也可能是一个开发包或一个小的程序工具。不同种类的产品具有不同的特性要求：面向集成商/开发商的产品要求可靠、可扩充、有详尽的技术说明、有一定的技术适应性；面向最终用户的产品则要求功能完整、可靠、可维护、有较好的应用适应性。

　　其实，设计人员还可以根据市场形式开发介于以上二者之间的"半产品"，即通过简单定制可以"生产"出应用系统的"半成品"，但又不同于严格意义上的开发平台或是零散的开发工具包。这种"半成品"很实用，不仅可以提高本企业的生产率，为产品系列化打好伏笔，还可以在适当的市场时机作为商品提供给系统集成商，为企业带来额外的利益。
到底要开发什么类型的产品，是软件产品设计的第一个重要决策。

　　我们假设的"多媒体远程教学系统"定位在"半成品"上，希望开发出能直接用于某种应用场合（如企业培训），但可以根据应用需要进行定制、扩充，广泛应用于其他相关应用，如专业培训机构、网络化学校教育等。

三、软件产品的非功能性需求定义

　　软件产品的需求可以分为功能性需求和非功能性需求。其中软件产品的非功能性需求是常常被轻视、甚至被忽视的一个重要方面。其实，软件产品非功能性定义不仅决定产品的质量，还在很大程度上影响产品的功能需求定义。如果事先缺乏很好的非功能性需求定义，结果往往是使产品在非功能性需求面前捉襟见肘，甚至淹没功能性需求给用户带来的价值。

　　所谓非功能性需求，是指软件产品为满足用户业务需求而必须具有的、除功能需求以外的特性。软件产品的非能性需求包括系统的性能、可靠性、可维护性、可扩充性、对技术和对业务的适应性，等等。下面对其中的某些指标加以说明。

1、系统的完整性

　　指为完成业务需求和系统正常运行本身要求而必须具有的功能，这些功能往往是用户不能提出的。典型的功能有：联机帮助、数据管理、用户管理、软件发布管理、在线升级，等等。

　　并不是所有的系统都必须包括以上所有的功能，而是可以根据产品的使用环境和企业的产品发展决策进行挑选。例如，在线升级、软件发布管理适用于具有因特网或内网环境的软件产品；而数据管理对于产生数据存储的产品则是必须的，设计人员不应假设用户同时是一个合格的DBA，而且系统所产生信息的分布、关系，也不是DBA所应该了解的内容。因此，完整的系统应该包括数据备份、恢复、日志管理、垃圾数据清除等基本功能，哪怕这些功能的核心只是一条语句或命令。用户管理功能是另一项必不可少的功能，它定义哪些用户可以以什么样的功能使用系统。好的用户管理功能不仅可以有效控制用户对系统的使用，使系统处于一个安全、负载合理的运行状况，还能提高系统的应用适应性。

2、系统的可扩充性与可维护性

　　指系统对技术和业务需求变化的支持能力。当技术变化或业务变化时，不可避免将带来系统的改变―不仅要进行设计实现的修改，甚至要进行产品定义的修改。好的软件设计应在系统构架上考虑能以尽量少的代价适应这种变化。常用的技术方法有面向对象的分析与设计以及设计模式。

3、技术适应性与应用适应性

　　系统的适应性与系统的可扩充性和可维护性的概念相似，也表现产品的一种应变能力，但适应性强调的是在不进行系统设计的修改的前提下对技术与应用需求的适应能力。软件产品的适应性通常表现为产品的可配置能力。好的产品设计可能要考虑到运行条件的变化，包括技术条件（网络条件、硬件条件、软件系统平台条件等）的变化和应用方式的变化，如在具体应用中界面的变化、功能的剪裁、不同用户的职责分配和组合等。

　　对以上重要的非功能性需求进行逐一分析后，就可以开始进行产品功能设计了。实际上，非功能性需求定义将反映到系统的功能设计中，表现为系统的架构。下一节中将会描述怎样实现系统的适应性。

四、软件产品的功能设计要点

1、产品核心功能的选取

　　软件产品的设计，一定有一个明确的目标：或是为了解决某个或某类具体的应用问题，或是为解决问题提供一个或一组工具。产品的目标决定了产品的核心功能，产品的其他功能都是对这一功能的补充或围绕这一功能提供的相关服务。

　　适当选取核心功能，有几点原则：

　　（1）规模适当，不贪大求全，坚持"有所不为"。具体来说，在一个产品中，非核心功能尽量的简化和弱化。以"多媒体远程教学系统"为例，核心功能应该是基于网络的多媒体远程教学，包括同步教学和非同步教学。与教学相关的学籍管理、教务管理、答疑考试、收费管理等辅助功能则采取最小化原则进行设计。这样既可以突出产品的技术特点，又可以避免以己之短搏人之长，显得产品在培训教育方面不够专业。等到核心功能稳定在产品中以后，再专门针对不同的应用要求研制不同的产品系列，如"网校版"、"中学版"、"企业版"等等。

　　（2）了应用要求以外，还可以根据关键技术进行版本规划。由于不同的技术对设备会有不同要求、并产生不同的应用效果，因此可以在相同的业务框架下构造基于不同技术的不同产品。例如，微软与多媒体相关的技术有流媒体技术、DirectShow、DirectPlay、TAPI等，RealNetworks也有完整的流媒体技术开发平台。这些技术分别具有一定的功能和性能特点，同时也各有其局限。利用它们的组合可以形成面向不同细分市场的产品。例如，针对以"灌输"为主、对交互性和实时性没有要求的单向式培训，设计以流媒体为主要技术的产品版本；针对实时性和交互性要求很高的教学和培训，设计以DirectShow和DirectPlay为核心技术的产品版本。

　　（3）尽量遵从标准协议和行业标准。除了计算机系统有多种技术标准和协议外，各行各业还有自己的行业标准。例如，对于"多媒体远程教学系统"而言，牵涉的标准和协议有媒体格式MPEG标准、流媒体传输和控制协议等；在应用领域有国家教委颁布的关于远程教育的建议标准。这些都应该充分考虑。有时不参照标准或自定义一些协议处理解决方案带来一时的快捷，但往往生命力和可靠性经不起时间的考验，在系统与其他相关系统联合使用时就会带来问题。

2、多重可重用性的分析与设计

　　可重用性是现在软件设计较为重视的一个特性。可重用性不仅应该在系统设计中考虑，还应该在系统分析时就加以考虑，使系统达到多重可重用性。这就要求我们不仅要采用面向对象的思想来进行系统分析，用对象概念构造系统行为，还要求我们在更高层次上对系统的操作模式或应用模式进行抽象，发现更高级的可重用性。

　　仍旧以"多媒体远程教学系统"为例。如果仅在系统设计时考虑可重用性，则产品可能达到部件级的可重用，即系统的某些核心特性可以在反复用于相关产品的设计之中；而如果我们加入对应用操作模式的抽象，对于"直播"、"流媒体与课件同步"、"现场控制"等构成应用的操作环节进行面向对象的分析，就可以获得更好的可重用性。―如果设计得当，一个产品可以同时满足直播教学、培训、股评、案例研讨等含有相同应用模式的多种不同应用环境，甚至连一行代码也不用重写。

　　多重的可重用性实际上就实现了非功能性需求中的应用适应性。无论我们设计面向哪些用户（最终用户/系统集成商/软件开发商）的产品，进行一些多重可重用性的分析都是有益无害的。

3、辅助功能的设计

　　这里提到的"设计得当"，就包括辅助功能的设计这一重要因素。前面所述的非功能性需求有一些就反映在辅助功能的设计中。在我们把最终业务用户作为产品的唯一用户时，我们把全部注意力放在产品的主要功能设计上；当我们把产品的用户范围扩大到系统管理人员、数据维护人员以及系统集成商/软件开发商时，我们就必须对产品的辅助功能给予足够的关注。

　　对于应用软件产品，重要的辅助功能至少有以下这些：

　　（1）在线帮助功能：这仍然是面向业务用户（当然也要面向其他用户）的一项功能，用于使系统更为友好。在线帮助功能通常设计成能独立运行的文档形式，如html格式。

　　（2）数据管理：面向数据维护人员。虽然数据库管理系统都有现成的数据管理功能，但专门设计的数据管理可以更简便、易于使用，而且可以完成数据库管理系统本身所不能完成的工作。

　　（3）日志管理：面向系统管理人员。良好设计的日志功能可以作为系统管理人员或产品设计人员监视系统状态、追踪系统问题，以及作为用户使用系统的审计依据。

　　（4）用户管理：面向系统管理人员。用户管理与下面的两项功能一起使用，可以使系统适应不同的用户功能分配需求。系统管理人员可以最大限度地灵活指定不同用户所能执行的不同功能项，消除通常造成软件产品在用户手中"水土不服"的最主要的因素。

　　（5）功能定义及功能表的自动生成：面向系统管理人员，定义系统的所有可操作功能项，并在用户进入系统时自动生成由管理员为之分配的功能表作为其"主菜单"。这一功能对于含有数据库和Web界面的系统特别适用，它使得系统具有"自动演化"的能力――即系统在运行时即可替换其部分功能，并且所有的功能权限在统一的控制之下。这正是系统可维护性的"最高境界"。

　　（6）系统配置：面向高级用户或专职的IT人员，根据实际需求定义系统的技术参数和应用模式。经过系统配置后，系统不再是有着各种技术和应用可行性的"中间系统"，而成为真正面向最终用户的产品。

五、软件产品工程－方法和规范

　　软件产品设计同样也是一项软件工程，适用软件工程管理的规律，只是在功能设计上有更大的自主性――进行产品设计时可能不必完全遵从某个用户的需求。但这一自主性是为了以更高的质量满足更多用户的需求。从这一点来说，软件产品工程并无更大的自由度。所有的软件工程规范都适用于软件产品的开发。由于软件产品往往对质量有更高的要求，且在设计中有更多的不确定性，因此特别要做好需求管理、配置管理与质量管理。

　　关于软件工程规范，本文不作专门论述，请参照有关标准和文档。