软件设计师综合资料..doc

从大禹治水看构件与集成 大禹治水? 　　在远古的尧、舜时代，黄河流域经常发生了大水灾，洪水横流，五谷不收，家破人亡。所以尧派鲧去治水，鲧沿用了过去的传统法子，水来土挡，用土筑堤，堵塞漏洞。但由于洪水凶猛，不断冲击土墙，结果弄得堤毁墙塌，洪水反而闹得更凶了。鲧治水九年，劳民伤财，并没有把洪水制服，是一事无成。 　　舜接替尧后，就把鲧办罪处死，随后命鲧的儿子禹继续治水。大禹领命之后，寻找到了以前治水失败的教训，最后决定用疏导的办法来治理水患。大禹带领百姓是凿了一座又一座大山，开了一条又一条河渠，把黄河的主流加深加宽，把支流疏通与主流相接。同时，把原来的高处培修得更高，把原来的低地疏濬得更深，便自然形成了陆地和湖泽。把这些大小湖泽与大小支流连结起来，洪水就能畅通无阻地流向大海了。 　　相传大禹三过家门而不入，把整个身心都用在开山挖河的事业中。大禹用疏导的办法治水终于获得了成功。大禹治水，为民造福，永受华夏子孙所称颂，永为炎黄后裔所怀念。 　　集成与构件 　　“集成”是看到了信息化建设中的一个个信息孤岛，数据不能交换，资源不能共享，业务不能协同，如同洪水泛滥一样。传统的应用集成EAI是典型的“堵”法，可以说总是在事后解决问题，是头痛医头、脚痛医脚，治标不治本的办法。碰到了集成问题，才去想办法去解决,而解决眼前问题的同时又带来更多和更复杂的其它集成问题。所以，就如同鲧治水一样，鲧没有把洪水制服，EAI当然也不可能从根本上解决信息资源共享利用的问题。 　　因此解决信息孤岛，要学大禹治水，“疏”比“堵”更重要。“堵”是一时的、眼前的，“疏”是长远的，一劳永逸的。与集成的事到临头相比，构件就是“疏”的方法，是从源头上去堵。在构件体系下，信息资源将按标准、有层次的通过构件展开，数据是构件、展现是构件、流程是构件、服务是构件，一切皆构件。好比大禹治水，开山凿渠是构件库，主流支流是大小构件，贯通无阻是统一标准。 　　所以，构件可以实现信息资源的大“治”，用计算机术语来讲，就是“同构”，标准统一，架构统一，建设统一，管理统一，开发、部署、运行与维护实现同构，信息孤岛从设计源头上被消灭。 从测试角度看用户手册在软件质量中的地位 ? ?? 对于软件，开发者往往只注意到其功能和性能，而忽略了用户手册。其实用户手册也是衡量软件好坏的一个重要标准。好的用户手册可以帮助用户快速入门，是用户正确、充分使用软件的前提。对于开发者来说，好的用户手册可以减少培训和售后服务的费用。所以在测试中，不能忽略用户手册的重要性，应从以下多个方面考察用户手册的质量。 ??? 用户手册的完整性 重点考察用户手册内容的全面性与完整性，从总体上把握用户手册的质量。这一项看似简单，但在实际测试中我们发现，很多开发商还是无法做到这一基本标准。很多软件由于开发过于仓卒，在付诸使用时，用户手册中缺少关于某些模块的说明，让用户使用起来比较困难。在测试工程师的眼里，优秀的用户手册内容应该是包括软件的所有功能模块。 ??? 用户手册的描述与软件实际功能的一致性 考察用户手册与软件实际功能的一致程度。当确认用户手册基本完整后，我们还要注意用户手册与实际功能描述是否一致。这种问题往往是由用户手册跟不上软件版本的更新速度造成的。对用户来说，容易造成对描述不一致的功能的误解和苫螅?进而影响用户对软件的使用。优秀的用户手册应该根据软件的升级而及时更新，手册描述应该与软件实际功能保持一致。??? 用户手册的易理解性 考察用户手册对关键、重要的操作有无图文说明，文字、图表，是否易于理解。对于关键、重要的操作仅仅只有文字说明肯定是不够的，应该附以图表使说明更为直观、明了。优秀的用户手册应该是图文并举，易于理解。 ??? 用户手册提供学习操作的实例 考察对主要功能和关键操作提供的应用实例是否丰富，提供的实例描述是否详细。当前大量软件的用户手册只有简单的图文说明，而无应用实例。这样的用户手册看起来就像是软件界面的简单拷贝，对于用户来说，实际上没有什么帮助。例如财务软件，用户手册就应该提供具体建帐实例及具体帐务处理的实例，这样才能使用户看完用户手册后，能够独立完成新帐套的建立并逐渐学会使用软件处理帐务信息。优秀的用户手册不仅要对主要功能和关键操作提供应用实例，而且对实例的描述应做到详细、充分，易于用户理解。 ????用户手册的印刷与包装质量 考察用户手册包装的商品化程度，印刷质量。有些用户手册是简单打印、装订而成，过于粗糙，不易于用户保存。优秀的用户手册应提供商品化包装，并且印刷精美。 软件的质量是由各个方面构成的，用户手册就是其中重要的一环。特别是在当前软件业快速增长的时期，软件开发者过于注重功能与性能而忽略用户手册，使得用户手册的质量问题尤显突出。所以对于测试人员应该充分认识到用户手册的重要性，严