发布新日志

  • 【转帖】手机自动测试方案

    2007-06-23 16:29:05

    TestQuest CountDown手机自动测试方案

    2007-05-08 15:28:36 / 个人分类：手机测试

    一、全球无线和移动设备制造商所面临的挑战

    随着GSM、CDMA、WCDMA、CDMA2000及中国自主研发的TD-SCDMA等手机新技术的不断涌现，基于业务应用层面开发和测试比重的增加，复杂度的不断提高以及手机和传统上基于PC的应用服务的快速融合,使得手机测试的难度和工作量大大增加。同时,由于市场的竞争越来越激烈,每款手机的生命周期越来越短,手机厂商都希望领先于竞争对手将自己的新款手机投放市场以获得更多的利润,这就意味着留给手机研发和测试的时间将大大的减少. 在全球化市场中，设备制造商除按照地域性要求对终端功能进行定制外，还要满足国际移动运营商的入网测试需求，这对于国内终端设备制造商来说又是一个挑战。因此,如何在最短的时间内,最大限度地测试手机的各项功能和应用,有效的面对手机测试过程中日益增加的复杂性，并满国际移动运营商的需要，同时大幅降低手机测试的成本就成了摆在每一个手机厂商面前的一个重大课题。

    二、全球无线和移动设备制造商的测试需求

    为了提高最终用户体验，增加用户的忠诚度，移动运营商及移动设备制造商随着用户要求的不断提高以及通过不断的积累，都要求对移动设备在推向市场之前进行以下的测试：

    功能性测试、压力测试、性能测试和回归测试

    不同操作系统和硬件平台之间的兼容性测试

    不同网络环境下的交互性测试

    与其它厂商制造的设备之间的一致性测试

    应用程序之间并发性测试

    其它Non-UI测试

    从此可以看出，测试工作非常复杂，并且工作量巨大。而现在很多国内的移动设备制造商还在采用手工测试，而手工测试是存在着很大的局限性的：

    可靠性低：测试工程师在很小的手机屏幕上操作太久则容易疲倦，造成测试可靠性下降。比如，测试工程师可能会混淆‘O’和‘o’，或无意中跳过测试规范中的一页。
    准确性差：比如，测试工程师难以发现包含100个字符的文本信息中的一个错误，或由于一步操作失误而不得不重新开始一个测试用例。

    覆盖率小：手工测试难以发现出现概率较小的错误，或难以重现之前发现的错误。

    一致性差：当测试并发事件时，需要同时操作多个终端或同时运行多个应用程序。手工操作很难控制。

    测试过程的不可重现性。

    测试速度较慢，无法进行7*24的工作。

    因此，采用手工测试是不可能很好的在产品投向市场前的最后一关保证优良的产品质量的。

    三、现有的自动化测试工具已难以适应无线和移动行业日益增长的测试需求

    由于手工测试的一些弊端，很多移动终端制造商大都早已开始了自动化测试工具的开发及使用，然而传统的自动化测试工具对人员要求很高，而且还存在着操作系统，手机型号不同而导致测试用例的不可重用性。

    需要用户具有很强的编程技巧，需要编写大量脚本(C/Tcl/Tk…)来创建测试用例。

    QA部门(组织)熟悉行业测试规范，但是一般没有自己的技术开发团队，难以完成大量的编程工作。

    传统的自动化测试工具大多专门为某个手机平台或操作系统设计，很难应用于其它手机平台或操作系统。

    市场上终端采用的硬件平台、操作系统以及网络制式各不相同。在传统的自动化测试工具中开发的测试用例很难在不同的终端之间进行移植。

    四、TestQuest自动化测试平台 – CountDown

    美国TestQuest公司作为在全球手机及移动应用测试领域的领先厂商,基于近10年来和Verizon等全球知名的移动运营商,Nokia、Motorola、Samsung、ZTE等手机厂商的合作过程中所积累的丰富经验,于2006年正式推出了第四代自动化测试平台CountDown,从而真正解决了对任何手机制式,任何操作系统以及任何硬件平台的手机进行自动化测试的难题.

    专门为无线和移动行业设计的自动化测试平台。集成了测试开发、测试管理与测试执行功能；支持分布式研发团队之间测试资源的开发与共享。我们提供7*24的自动化测试解决方案，以帮助无线和移动设备制造商缩短产品在市场上推出的时间。

    适用于所有类型(Windows Mobile/Symbian/Linux/Brew等开放式操作系统和专用/私有操作系统，所有硬件平台 GSM/GPRS/WCDMA/CDMA/CDMA2000/TD-SCDM等制式)的手机和手持终端设备，提供完整端到端的自动化测试解决方案。

    自动测试过程基于UI(用户接口)/MMI(人机接口)实现：通过控制终端的键盘、旋钮和触摸屏来模拟测试工程师的双手操作；通过抓取LCD屏幕显示图像进行智能OCR识别来模拟测试工程师的双眼辨识文字或图像信息。真正实现独立于任何操作系统、任何硬件平台或任何网络制式的自动测试。

    全图形化的开发环境，使得用户无需编写任何代码即可完成测试用例的开发、调试及运行。并且，开发完成的测试用例，无需改动或稍微改动，即可移植应用到其它类型的手机或手持终端设备。

    CountDown自动化平台由TestDesigner, TestManager, TestRunner and AssetManager组成：

    TestDesigner 是一个全图形化的开发环境。用户无需编写任何代码即可实现Test Case的开发、调试及运行。

    TestDesigner

    TestManager 是基于 IE 浏览器开发的测试资源管理工具。帮 助用户进行测试规划、测试执行并对测试结果进行分析。

    TestRunner / DAS(Device Access Software) 控制本地或远程终端运行测试任务，并将测试过程中产生的日志 (Log) 文件传送到TestManager 以生成测试报告。

    AssetManager 使用 MS SQL Server 数据库统一存贮和管理测试资源，以方便各个分布式开发团队之间的资源共享。

    CountDown的各个模块不但功能上相互独立，还可以根据用户的具体需求布置在不同的地理位置；真正实现了全球范围内团队间的协作开发。

    可以真正实现：

    测试任何类型的手机或手持终端设备

    同时连接多个终端设备进行端到端的系统测试

    测试资源跨平台的移植和重复使用

    实现整个移动产业链上不同测试团队之间的开发协作


    全部脚印 不留脚印 留下脚印:

    查看(722) 评论(1) 收藏 分享 管理

  • [转帖】无限通信术语介绍

    2007-06-23 16:12:58

    无线通讯名词解释

    发布时间: 2007-6-11 15:20    作者: 未知    来源: 51Testing博客转

    字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿

    OTA（Over－the－Air Technology）空中下载技术：是通过移动通信（GSM或CDMA）的空中接口对SIM卡数据及应用进行远程管理的技术。空中接口可以采用WAP、GPRS、CDMA1X及短消息技术。OTA技术的应用，使得移动通信不仅可以提供语音和数据服务，而且还能提供新业务下载。这样，应用及内容服务商可以不受平台的局限，不断开发出更具个性化的贴近用户需求的服务，如信息点播、互动娱乐、位置服务以及银行交易等。通过OTA空中下载技术，手机用户只要进行简单操作，就可以按照个人喜好把网络所提供的各种业务菜单利用OTA机制下载到手机中，并且还可以根据自己的意愿定制具体业务。

    2.5G：是基于2G与3G之间的过渡类型。代表为GPRS。比2G在速度、带宽上有所提高 。可使现有GSM网络轻易地实现与高速数据分组的简便接入。

    3G：（third generation）表示第三代移动通讯技术。面向高速、宽带数据传输。 国际电信联盟（ITU）称其为IMT-2000（International Mobile Telecom-munication）。最高可提供2Mbp/s的数据传输速率。主流技术为CDMA技术代表有WCDMA（欧，日）、CDMA2000（美）和TD－SCDMA（中）。

    GSM：（Global system for Mobile communications）全球移动通讯系统。2G的主流技术，数据速率为9.6kb/s。

    GPRS：（General Packet Radio Service）通用分组无线业务。是一种基于GSM系统的无线分组交换技术。2.5G的主流技术。理论最高数据速率为171.2kb/s 。

    WAP：（Wireless Application Protocol）无线应用协议。它是无线互联网上的一系列协议的组合。面向移动电话等小型、窄带的移动设备。WAP能够运行于各种无线网络之上，如GSM、GPRS、CDMA等。

    J2ME： Java 2 Platform micro Edition 1999年6月诞生是JAVA2的一个组成部分，一种以广泛的消费品为目标的高度优化的JAVA的运行环境。现主要应用为掌上终端（PDA、手机）、电视机顶盒。

    CLDC：Connected Limited Device Configuration 连接限制设备配置。配置的作用是决定环境所使用的JVM J2ME使用的是KVM

    MIDP：Mobile Information Devices Profile 移动信息设备简表。J2ME有两种简表MIDP和KJava 手机上的开发使用的是MIDP。

    J2ME相关词汇FAQ

    1. J2ME是Java 2 Platform micro Edition的缩写。1999年6月诞生是JAVA2的一个组成部分，一种以广泛的消费品为目标的高度优化的JAVA的运行环境。现主要应用为掌上终端（PDA、手机）、电视机顶盒。

    2. MIDP：移动信息设备简表。J2ME有两种简表MIDP和KJava 手机上的开发使用的是MIDP。

    3. CLDC：连接限制设备配置。配置的作用是决定环境所使用的JVM J2ME使用的是KVM。

    4. J2SE SDK：支持J2ME的JDK 建议使用1.3版本。

    5. Palm：Palm是Palm公司生产的掌上电脑的名称，也是其*作系统的名称。经常使用的型号如Palm M505

    6. POSE ：Palm*作系统在PC上的模拟器。

    常见的wireless名词整理
    －－－－－－－－－－－

    什么是1G/2G/2.5G/3G

    1G（first generation）表示第一代移动通讯技术。如现在以淘汰的模拟移动网。

    2G（second generation）表示第二代移动通讯技术。代表为GSM。以数字语音传 输技术为核心。

    2.5G是基于2G与3G之间的过渡类型。代表为GPRS。比2G在速度、带宽上有所提高 。可使现有GSM网络轻易地实现与高速数据分组的简便接入。

    3G（third generation）表示第三代移动通讯技术。面向高速、宽带数据传输。 国际电信联盟（ITU）称其为IMT-2000（International Mobile Telecom- munication）。最高可提供2Mbp/s的数据传输速率。主流技术为CDMA技术代表有WCDMA（欧，日）、CDMA2000（美）和TD－SCDMA（中）。

    －－－－－－－－－－－
    什么是GSM

    全球移动通讯系统（Global system for Mobile communications）的英文缩写。2G的主流技术，数据速率为9.6kb/s。

    －－－－－－－－－－－
    什么是GPRS

    通用分组无线业务（General Packet Radio Service）的英文缩写。是一种基于GSM系统的无线分组交换技术。是2.5G的主流技术。理论最高数据速率为171.2kb/s 。

    －－－－－－－－－－－
    什么是UMTS

    UMTS（Universal Mobile Telecommunication System）通用移动通信系统的英文缩写。由欧洲电信标准协会（ETSI）负责UMTS的标准化工作。并与ITU负责的IMT-2000协调一致。它是ITU IMT-2000的重要组成部分。UMTS使用ITU分配的、用于陆地和卫星无线通信的频带。它可通过移动或固定、公用或专用网络接入，与GSM和IP兼容。可支持2Mb/s的数据速率。
    －－－－－－－－－－－
    什么是CDMA（注：这里指3G的CDMA）码分多址的英文缩写，是目前公认的3G主流技术。目前存在3种3G的主流CDMA标准，分别是WCDMA、CDMA2000和TD-SCDMA。前两者分别由欧洲和美国提出，TD-SCDMA由中国提出（大唐电信），已被ITU和3GPP所接受。其中，WCDMA和CDMA2000是FDD模式，而TD－SCDMA是TDD模式（注：FDD－频分双工，需用两个频段进行收发；TDD－时分双工，采用同一个频段，但以不同的时隙进行。）

    －－－－－－－－－－－
    WAP和WML

    WAP是无线应用协议（Wireless Application Protocal）的英文缩写。它是无线互联网上的一系列协议的组合。面向移动电话等小型、窄带的移动设备。WAP能够运行于各种无线网络之上，如GSM、GPRS、CDMA等。

    WML是无线注标语言（Wireless Makeup language）的英文缩写。支持WAP技术的手

    机能浏览由WML描述的Internet内容。

    －－－－－－－－－－－
    I-mode 和 CHTML

    i-mode是日本电信（NTT）的子公司DoCoMo在日本市场推出的无线通讯服务。是目

    前世界上使用人数最多（都在日本）的无线互联网服务。I-mode 和 WAP 的主要

    区别在于：I-mode 的内容是用CHTML写成的，因此现行的大部分网络内容只要稍做修改可以使用；而WAP使用的是WML，现有的网络内容必须转化为WML才能被WAP所使用。CHTML（Compact HTML）HTML的一种变体。与HTML大部分兼容。

    －－－－－－－－－－－
    蓝牙（BlueTooth）

    蓝牙是一种支持设备短距离通信（一般是10m之内）的无线电技术。能在包括移动电话、PDA、无线耳机、笔记本电脑、相关外设等众多设备之间进行无线信息交换。它的标准是IEEE802.15。工作在 2.4GHz 频带。带宽为1Mb/s（注：蓝牙这名字很有意思，来自公元10世纪统一丹麦和瑞典的斯堪的纳维亚国王的名字。）

    －－－－－－－－－－－
    Wireless LAN

    无线局域网，是由局域网发展而来，标准是IEEE802.11、IEEE802.11b 和IEEE802.11a。其中802.11b 工作在2.4GHz频带，带宽可达11Mbps。而802.11a定义在5GHz频带，带宽有望达到54Mb/s 。但相应地，Wireless LAN成本较高，使用昂贵。

    －－－－－－－－－－－
    HomeRF

    HomeRF主要为家庭网络设计的无线射频技术，是IEEE802.11与DECT的结合，旨在降低成本。HomeRF也采用了扩频技术，工作在2.4GHz频带，目前HomeRF的带宽为1～2Mb/s，未来会增到10Mb/s。
    －－－－－－－－－－－
    SyncML

    SyncML是一种行业通用的移动数据同步化协议。利用SyncML可使移动设备上的数据与远程数据保持同步状态。由Ericsson、 IBM、 Lotus、 Matsushita、Motorola、 Nokia、 Palm、 Psion和Starfish Software等公司组成的协会所开发。


    －－－－－－－－－－－
    VoiceXML

    VoiceXML（Voice eXtensible Markup Language）是W3C定义的可扩展标记语言(XML)的一种扩展，根据播放的提示信息、口述的命令、语音或按键音输入，实现人机交互。VoiceXML的标准化将简化Web上具有语音响应服务的个性化界面的创建，使人们能够通过语音和电话访问网站上的信息和服务。

    查看(669) 评论(0) 收藏 分享 管理

  • 【转帖】我在软件公司成长的三年

    2007-06-23 15:16:56

    在论坛上看到一篇很好的帖子，初始看时觉得并没有什么价值，看到后来才真的是很受震撼。其实每个人的工作也都是这样子的，从刚开始的逐步适应到后来的重复性劳动，职业发展的道路就是这样，不同的人对待工作的态度是导致后期发展差异的主要原因。自己工作也有三年了，三年来也没有认认真真总结过自己的职业发展之路。迄今为止这是第三份工作了，前两份工作因为专业或者公司的原因，一直是虽然认真的去做，可是仅限于完成分内之事，自己并没有去积极的学习提高。现在第三份工作已经工作了尽一个月了，对工作也大概比较熟悉了，因为平时加班很多，所以晚上总是想着看看电视，看看新闻，休息一下，总是不想去学习新的东西。人都是有惰性的，不过不能因为一时的惰性而将目前学习充电、发展提高的时间而浪费过去。将这篇文章贴下来，平时看看也许能够多多督促自己，呵呵。

    【转贴】我在软件公司成长的三年

    我在软件公司成长的三年

    谨以此文与所有在琐碎、繁杂、平凡中日复一日地做着重复工作的人们共勉。
    writen by Swallow Xia，转载请注明出处。

    1前言
    写完2004年的工作总结以后，再翻了翻2002年和2003年的工作总结，真是“一年更比一年长”。看着总结，回顾着这将近三年来在SK工作的点点滴滴，感悟：原来，这就是成长的历程。于是，决定将三年的总结一起整理出来，对我在SK工作的三年作一个回顾，和大家一起分享，感谢一路上伴我走来的所有同事的关心、支持和帮助。

    2 2002年个人工作总结
    回顾2002年，难免感慨。
    在管理部从事前台文员半年多以来，工作主要可以归纳总结如下：

    2.1 例行工作
    认真做好来电的接听、访客的接待工作，做好订饭、订水工作；
    做好文具的购买计划和消耗总结工作；
    做好每月的考勤工作；
    做好长途电话的管理工作；
    将公司内的图书、杂志编号、分类整理，形成电子文档，使图书、杂志的管理规范化；
    协助做好招聘工作；
    做好办公室内务管理工作。这其间，因为排气扇导致电源跳闸多次与装修公司、物业管理处协调；注意植物的保养、更换及办公室内的清洁、保洁；注意复印机、打印机、热熔装订机等办公设备的保养。

    2.2 临时安排的工作
    组织每个月的团队活动。先后组织到暨南大学打球、天河公司游泳、天河公司烧烤、员村文化宫打球、从化温泉度假，都取得了较好的效果，加强了同事之间的交流，活跃了公司气氛。另外，9月底曾策划员工欢送大会，欢送吴涛等离职员工。

    办好公司的内刊。从七月到十二月，一共办了五期内刊。经调查，普遍认为水平尚可。但因为大多数人工作较忙或其他原因无法投稿，造成每一期内刊的都存在稿源不足的问题。未能想方设法调动员工的写稿积极性，除了自身原因之外，也与管理层等其他因素有关。

    公司网站的建设。由于没有制作网页的经验，所以存在很多技术问题不知如何实现。在不断学习的过程中，修改了主页，实现了公司产品等部分链接。因为公司形象需要重新策划，此项工作暂时告一段落。

    2.3 协助其他部门工作
    销售部成立后，曾参与销售部的销售例会，整理会议记录及销售部一些常用资料、表格；
    协助开发部制作国资、灯饰ERP等项目的部分图片；
    协助市场部进行国资宣传资料的排版、整理；
    另外还参与了公有物业产品化的测试及《授权管理》等几次幻灯片的制作。

    总的来看，2002年的工作是尽职的，但也有不少的遗憾。考勤的管理一开始并不规范；长途电话也因为疏于管理存在一些不良现象；没有投入全心的精力去办内刊；网站的建设太过于缓慢而且效果不够好；工作的确不够饱和，时有不知该干什么的感觉；个人能力的提升不够……在管理部的遗憾，可惜因为岗位的调换已无机会弥补。

    调到开发部，这是上级对我工作的肯定，对我个人而言是新的开始，也是新的挑战。除了要努力扮演好开发部“文档管理员”这一角色以外，希望我能在开发部掌握更多的技术知识，不断提升自我。

    2003年，我希望做得更好！
    2003年个人工作总结

    犹记得我的2002年工作总结是以“2003年，我希望做得更好！”为结尾的，时间如此匆匆，2003年的个人工作总结转眼间提到了案前。
    2003年，怀着这种希望做得更好的心态，我不断学习、不断追求、不断进取。

    3.1 前台文员→文档管理员→配置管理员
    年初，刚开始得知要调来开发部的时候，我是喜忧兼半。喜的是我去年的工作得到了公司的肯定，给了我一个更好地发挥自己和学习的机会；喜悦过后，更多的却是迷茫，不知道将会面临什么，能不能胜任新的岗位是个未知数。那个时候，开发部的软件过程也刚刚开始建立，还没有配置管理员这一说法，只说是把我调职过去做文档管理员，负责管理开发部的技术文档，协助部门一些内务。

    最初的学习过程是比较苦涩的，不懂软件工程；不懂VSS；不懂ROSE；不懂UML建模；更是从来没有听过配置管理……对于工作有关的一切都是问号，开会的时候更是经常当愣头鸟。工作中，学习成了首要的主题，不学习，就不可能做好工作。将近三个月的时间里，从VSS到配置管理；从ROSE建模到UML语言；从面向对象的了解到对软件过程认识……在不断地学习过程中，对工作，有了一个基本的概念。5月的时候，我的工作表现得到了领导的肯定，受到了表彰。

    虽然如此，但我并不满足于只是做文档管理员，只做简单的文档管理工作，我希望学习更多的配置管理和软件工程方面的知识，将项目中简单的版本管理融入配置管理的思想。最早的时候，公司的开发文档资料处于一片混乱之中，每个开发人员的电脑里都存有一份自己开发的工作版本，找不到哪一份是最新的。收集整理了国资一期、二期、产品化项目、南海国资升级项目、公有物业等一堆残留资料以后，也对东进ERP、财务异常警示系统项目中进行了初步的版本控制。再接着，到了企业转制与处置项目、三水项目的时候，开始制订了配置管理计划，项目的配置管理能够按照计划较为有序地进行，开发资料也能够定期进行备份，确保公司宝贵资源不会丢失。

    SAM一期项目是公司最大的一个项目，也是涉及人数最多的一个项目。能否按照以前的方法进行配置管理，是否能够考虑用其他更好的配置管理工具？这个项目该怎么管理，我思索良久。经过对另一个免费的版本管理工具CVS的一番摸索之后，对两个工具的优缺点进行了比较，最终还是选择了VSS作为项目的配置管理工具，但在目录结构、权限分配和流程方面作了不少的调整。就这样，在工作中不断学习，不断地改进，使我，使开发部的大家都对配置管理工作有了较为完整的认识。

    现在，无论是三水项目、SAM一期项目，还是接下来要做的天津项目、新疆项目、肇庆项目……无论是谁，都会深深地意识到配置管理在项目中的重要性，主动地希望用工具来进行版本管理。而公司各个系统的资料也在我的“仓库”里完好地存放着，作好了备份。回想起一年前在还没有配置管理员这一角色前开发资料混乱的管理，仿佛已是半个世纪前的事情！

    3.2 项目组成员→“自由人”→质量与进度监督小组成员
    调入开发部伊始，我被纳入财务异常警示系统项目组，并且说明，我所扮演的角色比较特殊，凡属开发项目我都需要参与其中。于是，我先后加入了财务异常警示系统项目组、东进ERP项目组、南海国有资产管理系统项目组。那段时间，让我感觉开会、作会议记录成了工作中不可缺少的一部分。开发部大大小小的会议要参加，作会议记录；项目组内部的会议要参加，了解进度；各个项目组的评审会议要参加，要准备好评审的制品，作会议记录……
         
    接着，我的岗位结构作了调整，我成了一个不属于任何项目组自由人，反而要对各个项目的制品、进度进行管理。工作的内容没有多大的改变，在结构上却开始发生了变化。

    成为“自由人”的时间并不久，开发部很快地成立了质量与进度监督小组。我成为了其中的一员，从此，我又变成了一个“有组织”的人了。我们的小组成员不断增加，队伍不断壮大，成员由一开始的两个人发展到了现在的四个人。工作范畴包括对各个项目组制品质量监督、进度监督、测试、配置管理、里程碑评审……成立了小组以后，开始想到了制订规范和制度。这段时间，我更加积极地学习软件质量管理和CMM体系的知识。经过学习，再加上对工作的不断总结，我先后在开发部制订、颁发了开发资料管理办法、服务器数据库管理规定、个人工作管理表格填写说明、测试流程；草拟了配置管理规范、里程碑评审规范、需求管理规范，规范了软件过程的各种文档的模板。

    3.3 写用户手册生手→“专家”
    第一次写用户手册是在财务异常警示系统的时候。财务异常警示系统是公司第一个完全按照软件过程规范并且运用J2EE进行开发的项目，对于公司来说，是在技术上、开发制度上的一个里程碑的飞跃。我有幸地加入了项目组，除了负责配置管理工作以外，还负责系统用户手册的编写。

    万事开头难，从来没有写过用户手册的我，接到任务的时候忐忑了好久，不知道要怎么写。财务异常警示系统面向的用户是具有丰富财务知识的财务总监，涉及了大量的财务知识，面对取数运算元、标准运算元、异常、方法……这一大堆陌生的术语，不仅要学会怎么使用它，还要写成文档，教会别人怎么使用。我只好尽量多学多问，问巫锦新，问林戈，抓住机会让他们教我怎么使用，怎么表述。终于，第一份用户手册出炉了，图文并茂，自我感觉比公司以前系统的用户手册好多了。因为如此，这份用户手册经过多次COPY，作为指导，被接下来一个又一个的项目在写用户手册时所引用。也就是在那个时候，我学会了怎样看ROSE模型了解用例，怎样通过需求规格说明书了解系统功能，怎样在什么也不懂的情况下问人……

    自始之后，写用户手册和帮助的工作似乎变成了我的专利。东进ERP系统、企业转制与资产处置系统、三水公有资产管理中心系统、SAM事项审批系统、SAM行政事业版，每一个开发项目的用户手册或帮助似乎都和我脱不了关系，虽然这期间也有派其他部门、其他人员参与协助。而我，不知什么时候起，竟然成了写用户手册的“专家”。要负责指导、教会别人怎么应该怎么写，甚至挑剔着别人写的内容过于简单不够充分，不能说明系统的功能；排版不符合规范；截图随便，没有反映真实内容……

    3.4 2003年获奖次数最多的SK员工
    2003年，对我而言，在公司可以算是光荣的一年。
    5月，因为调职开发部以后工作表现突出，我获得了公司的表彰和奖金；
    6月，我获得了财务异常警示系统项目奖；
    7月，在半年总结中，经过全体员工投票，我获得了进步奖；
    8月，我获得了企业处置与资产转制系统的项目奖；
    11月，对于工作的情况向唐总提了一些个人的看法，意外获得了合理化建议奖。
    虽然奖金微薄，但我深知这其中饱含公司对我工作的种种肯定，而这些小小的荣耀也在一步一步地激励着我前进！

    3.5 不足和遗憾
    总觉得还有太多太多的工作需要完善，有太多太多的东西需要学习。
    在配置管理方面现在只是进行了比较简单的版本控制，初步实行了需求管理，虽然写了这方面的规范，但还没有颁布执行，配置的审核、产品的发布管理……还有很多的东西需要规范，需要完善。

    质量与进度小组需要规范的制度很多，目前还没有一个质量体系指导工作；测试方面没有制度；项目的进度监督需要有制度……方方面面的规范，都来不及在2003年做好。

    个人的技术能力提高不大，不懂系统分析、不懂设计、不懂开发，在工作中时常感到力不从心。另外，到目前为止，只能熟练地运用VSS进行版本管理，对于其他版本管理工具如CVS、ClearCase的掌握不够，还没办法根据不同项目的情况自如地使用不同的版本管理工具进行管理。学习编程知识，能够看懂源代码，看懂分析设计模型，掌握更多的配置管理工具……这些都是我2004年工作所向往的。

    写用户手册是一个工作量大、时间甚长的工作，除了做好本身的配置管理、质量与进度监督的专职工作以外，其他的时间几乎都花在了 “兼职”写用户手册上。现在，SAM行政事业版用户手册的编写正在紧张地进行着。这一次，我在总结以往经验的基础上，对其风格作了不少修改，比以前更加清晰、明朗、详细。我希望写成一个模板，一个值得不断借鉴、引用的模板，这样以后的系统都不必再烦恼用户手册该怎么写，每个人只要看到这个模板，照着里面的内容、格式直接引用就可以了。能够在公司培养成更多写用户手册的专家，我也可以功成身退，分配一点时间去学习新的东西！

    3.6 完结
    写着，写着，总结，再总结……不断地回想着2003年，可以总结的东西竟然如此之多。无论如何，我想我是进步很多的。计划着2004年我该怎样秉承SK“诚信、和睦、实干”的文化，百尺竿头、更进一步提升自己；盘问着今年的努力够不够，年度的加工资会不会有我的份？憧憬着，努力着……
    革命尚未成功，同志仍须努力！迎向2004之时，我对自己如是说。

    2004年个人工作总结
    从踏入12月以后，就开始思付要写2004年的年度工作总结。一直没有动手，除了忙碌可以作为理由以外，更重要的是，不知道该怎么把这一年做过的许多零乱而繁杂的工作总结成文。

    有人把工作总结当成一种形式，作为应付上级领导的苦差，我却发自内心地想写总结，通过总结，可以清楚、明晰地知道自己一年来做过什么，欠缺什么。好的，需要继续发扬的；不好的，需要加以改进的，都会在总结中一一罗列，鞭策自己。

    2004年，我都做了哪些工作？还得从头回顾，娓娓道来。

    作为质控部一员，我的工作却囊括了质控、研发、营销三大部门，随着公司的机构调整、人员变化不断调整和变化。按照部门分类，可以把我2004年的工作总结如下：

    4.1 质控部门工作
    质控部门的主要职责是负责监督和控制研发中心内产品和项目开发的工作进度与质量，包括质量保证、软件测试、过程监督、配置管理、技术评审。我在质控部门的工作也围绕着这几项来开展。

    4.1.1 配置管理工作
    配置管理工作是我的主要职责，在这一年内，我负责了研发中心所开展的十二个项目（包括三水项目、SAM行政事业版、天津项目、南海项目、SAM经营版、新疆项目、资产运营管理系统项目、江西国资委产权管理系统项目、河北省国资委业绩考核项目、技术准备项目、茂名项目、技术支持性项目，下文所提的十二个项目均指上述十二个项目，不再重要提及）的配置管理工作。

    （1）根据项目的规模、性质、简繁，视情况针对各个项目开展常规的配置管理工作。包括：
    制定配置管理相关制度和流程（有相关文档，但未遵照执行）
    配置管理计划的制定（当项目规模较大时）
    配置库的建立（按照项目编号，每个项目建立一个配置库）
    对项目内各成员的用户帐号和权限的分配
    定期检查配置库的使用情况，督促开发人员定期提交、更新相关的代码、文档，有需要时设置Label，记录重要基线
    定期对配置库进行备份，设置对配置库进行日自动备份，每半年进行一次资料刻录。

    （2）对研发中心内所有成员的配置管理培训，使受训人员了解公司配置管理流程及VSS使用情况，从而更好地开展项目过程中的配置管理工作。
    包括：
    4月份针对软件产品与项目的配置管理过程、配置管理工具VSS的使用等方面的知识，对研发中心全体成员进行了一次总体培训。
    对4月份后研发中心新招聘的员工分别进行公司配置管理过程及配置管理工具VSS的使用培训。
    注：个人编写、准备的培训材料包括：配置管理基本知识（见附件一：配置管理培训.ppt）和VSS使用说明（见附件二：VSS使用说明.doc）。

    4.1.2 制度编写及流程改进工作
    为了更好地提高工作效率，规范部门工作、个人工作，方便部门与部门之间的交互，这一年，在工作过程中结合领导要求、个人想法、同事意见，经过思考，在工作过程中制定、颁发了一些制度、整理了一些文档，对质控和研发工作的改进提供了一些帮助。包括：

    （1）年初，研发中心设立产品、项目、质控三个部门伊始，各个部门之间独立开展工作，信息比较闭塞，而各个部门之间工作关联性大，需要不断沟通和交互。为了减少沟通成本，使部门与部门之间的信息交互、沟通能够更方便、更快捷，提议建立了项目部、产品部、质控部各个部门的部门配置库，将各个部门的制度及规范、会议、培训、计划与总结、个人周报等各种信息统一集中管理，大大方便了公司高层领导了解各个部门的工作开展情况；部门与部门之间相互了解彼此工作开展情况；部门成员之间了解彼此的工作开展情况。（见附件三：部门配置库管理办法.doc）
    注：后面由于公司机构设置，将产品部、项目部合并为研发中心，也将配置库进行了合并。

    （2）为了规范SAM行政事业版及后续产品序列号管理，编写了SAM行政事业版系统系列号管理办法（见附件四：SAM行政事业版系统系列号管理办法.doc）。
    注：因产品的销售没有如计划般覆盖全国，该办法没有产生作用，如果尘封硬盘。

    （3）为了规范公司内部产品的发布，将公司内部所有已经定版的产品、项目安装到SS服务器统一发布，并将各个系统的访问地址整理成文（见附件五：公司系统访问地址.doc）供公司内部开发人员、技术支持人员、市场人员访问系统，了解各个系统功能。
    注：因为后期SS服务器中毒瘫痪，部分系统不再采用BS浏览器访问模式，采用需要到各台机安装才能使用的CS模式，没有再将此项工作持续进行下去。目前上面公布公司的网址因为SS服务器中毒后瘫痪未恢复无法再访问，系统的发布需要另觅它处。

    （4）为了方便公司新老员工对公司所有项目情况有一个整体的了解，对公司历年来开展的项目信息进行了整理（见附件六：公司历年项目信息列表.doc）。

    （5）由于前期质控部在了解各项目进度进展时需要分别与每个项目的具体负责人交互，当涉及的项目、人员较多时比较费时，且无法及时了解每个项目的进度情况，建议由项目负责人每周填写项目进度周报（见附件七：项目进度周报.doc），再统一将每个项目的进度信息汇总到“项目进度综合报告”（见附件八：项目进度综合报告.xls），以方便公司领导、质控人员及时了解各个项目的进度，开展后续的测试等工作。
    注：后期部门合并，人员减少，质控部门纳入研发中心一起开会后，可以通过会议了解各个项目每周所开展的工作汇总项目进度信息，取消了项目进度周报。

    （6）针对开发人员在开发过程中使用VSS出现不及时提交、更新代码、使用VSS时出现的普遍错误，编写了配置库管理规范（见附件九：配置库管理规范.doc）和使用VSS常见错误（见附件十：使用VSS常见错误.doc）。

    （7）针对开发人员在项目开发过程中，对个人代码没有较好地把关，出现较多常见的低级性错误，对测试的依赖较强，造成测试人员工作量大且繁琐。部门内决定对项目测试过程中出现的Bug定期进行统计，并将统计结果公布到公告栏中（见附件十一：项目缺陷统计表.xls）。

    （8）针对各个项目发布版本混乱，经手人过多且没有对项目过程中重要的版本进行label记录，造成有些重要版本无法追溯的情况，制定了项目重要版本记录表（见附件十二：项目重要版本记录表.xls），对十二个项目可以追溯的重要版本进行了整理，记录在表中，并在研发中心部门内推广、执行。

    （9）以质控部的角度对研发中心2004年所开展的所有项目，从质量、进度、成本等各个方面进行总结、分析，为公司后续要开展的项目提供经验、指导，方便公司领导、研发中心所有成员回顾、了解2004年的项目质量情况（见附件十三：2004年项目质量总结.doc）。

    4.1.3 软件过程监督工作
    软件过程监督工作包括：
    对项目的软件过程执行情况进行监控，定期向上级反馈各个项目的软件过程执行情况。
    对项目开展的计划进度与实际进度进行跟踪，每周定期更新项目进度综合报告（见附件八：项目进度综合报告.xls）记录各个项目每周的进展。

    4.1.4 软件测试工作
    由于质控部人手少，负责测试的只有一人，测试任务繁重，在测试工作紧张的情况下有时也协助测试人员做一些简单的测试工作，包括：
    协助进行SAM经营版的简单测试工作（主要针对财务异常警示子系统和决策支持子系统）
    对北京机关事务管理局演示版本的测试
    对资本管理系统的测试（拿到新疆去的第一版）
    协助进行三水产品化项目的测试
    协助产权关系管理系统客户端的测试
    测试工作主要针对上述各个系统的功能、界面提出完善性建议及分担部分Bug的查找工作。

    4.1.5 评审工作
    评审工作也是质控部门的工作之一，在质控部门参与的评审工作包括：
    前期协助组织了SAM经营版项目各个阶段的评审工作，包括会前发布相关评审通知、评审制品；会中进行评审意见记录；会后对评审结果进行跟踪。
    中期由于公司部门机构调整、管理人员变化，取消了公司层面的评审，直接由项目内部进行评审，未参与其中工作。
    后期参加了茂名项目的评审会议。
    注：目前评审工作开展得比较薄弱，主要因为旧的软件过程制度不满足目前各个项目的需要，新的软件过程没有明确颁布，故没有明确应该以何种形式开展评审工作。这类工作参与得不多。

    4.2 研发中心工作
    4.2.1 文档编写工作   
    除了负责质控部门的工作以外，本人还担任了研发中心大部分项目的文档编写工作，一年中，写过的文档不下千页，实在是一项很考验耐心的工作。总结起来，2004年写过的文档包括：
    SAM行政事业版用户手册（包括Word文档版和CoreDraw印刷版）
    SAM经营版用户手册、安装手册
    资本管理系统用户手册（拿到新疆用的版本）
    三水项目（用户手册、安装手册）
    江西国资委产权管理系统的软件功能列表、系统功能流程图、用户手册、产品白皮书
    河北省国资委业绩考核管理系统的产品白皮书、用户手册、安装手册、演示PPT
    茂名项目用户手册（正在进行中）

    4.2.2 软件使用培训工作
    因为负责研发中心内各个项目用户手册编写工作的缘故，对各个系统的功能、操作流程、注意事项均比较熟悉，可谓除了负责测试的小曾以外最熟悉公司所有系统的人。所以也担负了部分对公司内部成员使用系统的培训工作。包括：
    在公司级内组织开展对技术支持人员、营销人员使用SAM行政事业版的培训
    在公司级内组织开展对技术支持人员、营销人员使用SAM经营版的培训
    根据需要对公司内各部门的人员单独培训单个系统的使用

    4.2.3 演示数据准备工作
    为了使公司系统在给客户演示的时候能够达到较好的效果，帮助商务攻单，先后配合进行了两次较为大型的演示数据准备工作，包括：
    江西国资委产权管理系统一千多家企业数据的整理、导入数据库，形成产权关系树；
    重庆客户业绩考核系统几百个Excel表的演示数据准备。
    另外，平常还不定时的视情况配合商务人员准备其它系统的演示数据。

    4.3 营销中心工作
    8月份，负责营销中心文职工作的小曹离职以后，我开始接替她先前的部分工作。包括：

    4.3.1 奥汀软件的管理工作
    奥汀软件的管理工作量不多，无非就是拥有管理员的权限，每次营销人员负责的区域、客户发生调整、变化的时候；有新员工入职的时候；有老员工离职的时候给相关人员重新分配权限，帮助新员工学会安装、使用该软件。就是这么一件看似简单的工作，有时却令我扼腕。在使用奥汀软件的过程中，最痛苦的事情莫过于公司调整营销人员负责的客户，需要对各地客户进行经手人变更的时候。奥汀软件的经手人变更功能没有批量选择、批量修改功能，每次只能一个客户一个客户地选中——点击右键——经手人变更——选择变更后的经手人和变更原因，有时一调整就是几百个客户，连续不断地上千次鼠标点击，点到手酸。

    由此，我深深体会到，在编程的过程中，考虑到用户操作的方便性是多么的重要，就是这样一个简单的批量选择、批量修改功能，开发人员在编码的时候花不了几个小时，但由于没有考虑到用户这方面的需求，导致成百上千个客户增加几十倍的工作量！这一点，会不会给开发人员一点启示呢？

    曾经找负责奥汀软件客服的人员抱怨过这个问题，他给我的回复是，在我们的新产品中已经增加了这个功能。换言之，要用，付钱吧。多么令人讨厌的事情，我们总不能为了那个批量功能特意再掏钱买个新版本吧？

    前段时间由于DS服务器硬盘突然无端端损坏，造成存放所有客户资料、联系记录的奥汀数据库丢失。而因为我先前不了解服务器的安装等原理，也没有人跟我交接数据库的备份工作，只找到了以前的管理员7月份的备份版本，造成7月份以后登记的全部客户资料和联系记录丢失，造成销售人员大大的不便，这其中的损失，没有估量。自此之后，我意识到备份工作的重要性，现在无论是营销方面存放客户资料的奥汀数据库还是研发方面用的项目配置库，都会作好几手的备份，保证万一有意外，也不致造成数据丢失。可见，简单的工作，如果没有人做，有时也能带来不可意料的后果。

    4.3.2 建立配置库整理资料
    一直以来，营销中心的各种资料都是放在公司的OS服务器或个人电脑上，这当中包括部门内的各种规章制度；各个产品的资料，包括宣传单页、产品白皮书；各地客户的资料，包括针对某个客户做的方案、演示用的PPT、相关客户的反馈意见表；各个产品的培训资料、公司领域知识的相关资料，零乱而分散地放在各个不同部门的目录，各个不同负责人的文件夹中。文件的命名有的以日期为后缀，有的以Vx.y版为后缀，有的以new或old为后缀，要找一份文件，真不知道哪里下手，找出来的，还不知道是不是最新的。

    目睹此情，我把整个OS服务器翻了一遍，把分布在各个角落的文档一一翻阅，有用的，拿出来，按照部门规范、部门会议、产品资料、客户资料、系统安装、培训资料、行业知识七大分类对各种资料进行整理，用VSS建立了一个配置库，像所有项目的文档、代码那样，纳入版本控制，把文档都集中管理起来。

    可惜宣传做得不够，营销人员也没有体会到这样做的好处，现在我整理出来的营销中心配置库，除了有新员工进来，我可以比较自豪地叫他通过这个配置库，系统而完整地找到很多公司以往客户、产品、行业知识的相关资料以外，平常营销人员写的方案、PPT等资料还是习惯各自放到自己电脑上，共享给别人的时候发邮件，用一个个的日期或者new、old的标记标示着版本的新旧，不习惯用配置库保存、管理自己的资料。一个人若想一下子找到另一个人负责的东西，比较难……

    4.3.3 会议记录
    在公司内，我还有另外一份兼职工作，就是整理会议记录。无论是营销部门、研发部门还是质控部门的会议，经常都会充当会议记录的角色。经常会在开完会，整理完会议记录发送到相关人员的邮箱后听到有同事对我说：“会议纪要整理得不错”之类的话语，有了这些鼓励，使我在参加每一次会议时用心聆听，不怠动笔。

    4.3.4 协助其他人员的文档工作
    小xia，帮我把这份标书排一下版吧，你排版比较熟；小xia，能不能替我整理一下各个系统的功能模块，你对各个系统的功能了解比较多…… 每当听到有人要我帮忙协助这样那样工作的时候，如果不是手头有事安排不过来，只要力所能及，我一般都来者不拒。这些工作不再一一细数，只记得某同事对我说，我要向唐总提议，年底设立“最佳协助奖”，设立了，就投你一票时，我会心一笑，其实，那都是举手之劳。

    4.4 个人收获与体会
    不知不觉中，一年的工作总结竟然写了有五页之多。看着一行行打出来的字，才知道我做的工作比我想象中还要多、还要琐碎、还要杂；不知不觉中，我也发现，在这貌似没有长进的一年中，其实也有不少的收获。

    4.4.1 关于改进工作
    这一年，我最大的收获就是，在工作过程中能够不断地发现问题，用心思考怎样采用更好的工作方法解决问题。于是，这便有了上面的“见附件一”到“见附件十三”。这些看起来很平常的文档，有的却是我困扰良久、茅塞顿开忽然想出来的办法。我想我不会忘记，当我建议项目部建立部门配置库，用VSS对部门事务进行管理，得到杨经理认可，再得到唐总好评时那种藏在内心的自豪感；也不会忘记，当我听到罗经理在研发会议上说：“小xia在工作的过程中总是能够提出很多自己的想法，给我们带来意外惊喜”时的成就感。虽然很多东西在推行、实施的时候，效果并不如自己意想中的好；有的甚至只开了个头就再也开展不下去；有的根本没有人知道、关心我在做什么……毕竟我对工作曾经那样用心良苦地思考过，我想，这会是我得益一辈子的东西。

    4.4.2 关于身兼数职
    不看内容、光看目录就知道，我做的工作横跨质控、研发、营销各个部门，各种类型都有，实在是杂、杂、杂。虽然如此，我还是很不情愿地用“打杂”两个字来形容我的工作。张瑞敏不是说了么：“把每一件简单的事做好就是不简单，把每一件平凡的事做好就是不平凡”。汪中求也有言：“对于敬业者来说，凡事无小事，简单不等于容易。大量的工作，都是一些琐碎的、繁杂的、细小的事务的重复。”我深有体会，能够把这些平凡而又简单的事情都做好，绝非易事，更会在参与这各种所谓的杂事的时候得到或多或少的收获。未来的日子，让我继续努力，达到把“简单的招式练到极致就是绝招”。

    4.4.3 关于写文档
    当我看到打印出来的行政事业版的400多页的用户手册有枕头那么高的时候，我惊叹：这些，都是我写的吗，都是我一个字一个字从键盘里敲出来的吗；
    当我看到写出来的产权管理系统用户手册印刷成册、精美包装的时候，我自豪：成就感徒然而生，我的文字竟然通过这种方式变成铅字了；
    当我看到售前人员、实施人员、营销人员看着我写的用户手册、安装手册学习系统的操作、使用、安装的时候，我高兴：我写的东西能够给别人提供帮助。

    尽管如此，现在动笔写一个庞大系统的用户手册之前，想到日复一日对着键盘敲字；对着系统界面截图；对着没有成熟稳定操作起来bug连连的功能；对着甚至没有任何文档参考的系统冥思苦想怎样表述它的功能时，再想到写完以后还要根据客户的需求发生变更，修改相应的系统功能再修改相关用户手册功能操作时，还是会禁不住汗颜。半是恐惧之中，可喜地发现，在写用户手册等文档的过程中，也能得到不少提高呢。

    经过这样一个接一个项目文档编写的千锤百炼，我的写作能力大大提高。现在，无论叫我写什么文档，不管是用户手册、安装手册、会议记录还是产品白皮书，不管是用Word、Excel、Powerpoint还是要用上Visio、Project、Photoshop，虽然谈不上信手掂来，但是以前那种“纵有千言万语不知如何下笔”的心情却不会再有。某次当我苦恼着跟罗经理说不知道某文档要怎么写的时候，他开玩笑地对我说：“还有什么文档你不会写的吗？”，禁不住一乐，对写文档的恐惧也开始淡化。

    因为对每个项目都有写用户手册的任务在身，所以不单会从宏观角度跟踪项目的进度，了解项目情况，而且会从细节着手，小到了解每一个功能、每一个按钮的作用，有意见可以及时反馈，帮助改进软件功能、优化界面。也因为这样，我比公司大多数人都了解各个系统的功能、操作，了解公司的产品。这些，何尝不是一种收获呢？

    4.4.4 关于坚持
    以前，如果别人说我：“做事只有三分钟热情，心血来潮过后就无声无息”的时候，我会无言以对，没有理据反驳。因为，在我过去二十几年的人生中，除了每天例行的吃饭睡觉，实在是没有什么东西称得上坚持过的。记得曾经兴致勃勃地想过早上要起床背单词，周末要坚持运动，每周要坚持练听力……最后都因为这样那样的理由和借口而搁浅，没有一样事情能坚持哪怕一个月。

    现在，虽然我还是有很多事情想过要做之后不能坚持，但却有一两件事情让我可以骄傲地说：我也是一个可以坚持的人。

    生活中，我坚持每天自己做饭、带饭到公司来吃，这中间的理由有很多，不过最终发现，热爱做饭、并且爱吃自己做的饭是最大的理由：）；坚持写网络日记，虽谈不上日日更新，却会隔三差五地去记录自己平凡生活的一点一滴，一年多下来也收获良多。

    工作中，我坚持写个人工作管理表格，做到对工作日计划、周计划，日总结、周总结，不管上级领导有没有要求，主动自发地坚持；每周坚持在项目进度综合报告中记录这一周哪些项目做了哪些事情，进度如何，虽然也没人要求甚至没人关心那份文档。

    因为这两样坚持，使我在一年结束的时候，可以把自己做过的工作回顾得这么清楚，把总结写得如此详细；可以有根有据地写出一份长达上万字的04年项目质量总结报告；可以有这么多的感触和收获……想起那句听过无数遍的“贵在坚持”。

    4.5 结语
    职场中很流行一句话：衡量一个人工作的好坏，不在于这个人做了多少工作；而在于你的工作有没有为公司创造价值。我没有站在销售一线冲锋陷阵签过单；也不曾轰轰烈烈地能够在短期内开发出一个软件来占领市场的能力，甚至不会写代码，不能直接解决客户的需求；更没有通霄达旦地加班加点，超乎常人地付出自己的劳动。我所做的，都是自己职责所在、力所能及的工作，这些工作，能为公司创造多少价值？不曾衡量过。

    有位前辈在给我提意见的时候这样建议道：“以后信心要强，希望你能有发展，每天提高自己，有计划的学习。建议加强：文档管理、日常事务处理能力、人际关系（表达），书写能力。培养职业女性的气质，比如：穿着，站的肢势，说话的方式，果断大方的说话风格，从细节入手。不要像小女孩，一两句打击的话就让你心里不高兴，要懂得自己控制自己的情绪……”，这些话，我一直铭记在心，在此谢谢为我如此中恳地提过意见的他。我知道，自己还有很多很多需要学习的地方，也一直在努力，希望可以“每天前进一步”。
    2005年了，前方的路要怎么走？我追求什么，希望得到什么？我轻轻地问自己的心，带着一连串的疑问，思索，再思索……

    4.6 附录说明
    附件一：配置管理培训.ppt
    附件二：VSS使用说明.doc
    附件三：部门配置库管理办法.doc
    附件四：SAM行政事业版系统系列号管理办法.doc
    附件五：公司系统访问地址.doc
    附件六：公司历年项目信息列表.doc
    附件七：项目进度周报.doc
    附件八：项目进度综合报告.xls
    附件九：配置库管理规范.doc
    附件十：使用VSS常见错误.doc
    附件十一：项目缺陷统计表.xls
    附件十二：项目重要版本记录表.xls
    附件十三：2004年项目质量总结.doc




    查看(398) 评论(1) 收藏 分享 管理

  • 【手机测试自动化实现】

    2007-05-13 20:57:57

    测试

    查看(1024) 评论(10) 收藏 分享 管理

  • 【转帖】手机相关

    2007-05-13 18:41:40

     

    查看(651) 评论(1) 收藏 分享 管理

  • 手机操作系统和平台

    2007-05-13 17:30:26

    智能手机:操作系统 开发平台一一细盘算 
     
        一、手机操作系统(OS)
        手机操作系统(OS)作为连接硬件、承载应用的关键平台，扮演着举足轻重的角色。 目前市场上的手机操作系统主要有四个：Symbian、Smartphone、Palm OS、Linux。
         由诺基亚、摩托罗拉和爱立信等几家电信巨头联手组建的Symbian平台，是智能手机市场中的实力派，安装Symbian的手机占全球智能手机出货量的70%，其得到了大多数传统手机制造厂商的支持。不过，今年8月，摩托罗拉宣布放弃 Symbian股权。
        Symbian分两个主要的智能平台，一个是适于单手操作的S60，代表产品是诺基亚7650、3650；另一个是双手操作的S80，代表产品是诺基亚的9210，主要针对商务用户。此外Symbian上还有另一个平台UIQ，以笔操作为主，代表产品是索尼爱立信的P802。
        在Symbian上的这几个平台以S60最为核心，目前，市场中已经有1000万台S60手机。诺基亚、索尼爱立信、西门子、三星等企业都在应用S60平台进行开发。相比较于其它几个智能手机平台， Symbian由于是从手机的使用特点出发，在手机用户的接受程度、手机软件的易用性、运营商的合作习惯等方面，都有优势。
    Palm则是凭借在掌上电脑市场上的优势地位进入智能手机领域的，目前的市场排名仅次于 Symbian 。
        Smartphone 是软件巨头微软针对移动智能终端基于Intel手机芯片开发的操作系统，代表机型是多普达Dopod６８６。今年微软推出了Smartphone 2003中文版。得到了越来越多手机制造商的支持，对 Symbian 和Palm产生不小的冲击。
    嵌入式 Linux 系统的典型代表是摩托罗拉在智能手机Ａ７６０。基于Linux的只能手机可能会在将来成为 Smartphone 及其他手机操作系统的强大对手。

        二、智能手机开发平台：
        目前，智能手机的开发平台主要有：JAVA、BREW和 .NET。
        １、ＪＡＶＡ
        目前在在移动领域广泛使用开发平台是Sun开发的J2ME（Java 2 Micro Edition），即用于嵌入式系统的Java。J2ME技术由一个虚拟机KVM（K Virtual Machine）和一组API组成，这组API适合于为消费和嵌入式电子设备提供经过剪裁的运行环境。
        KVM（K Virtual Machine）虚拟机本身仅仅需要40-80KB内存、20-40KB动态内存（堆），能够运行在16位25MHz处理器上。经典手机６６８８I由于支持K-JAVA，功能可以无限扩展，从而成为手机发烧友的最爱，其在友人网的手机论坛至今仍是热闹非凡。
        J2ME为移动互联引入了一种新的模型，即允许手机可以从互联网上下载各种应用程序，并在手机创造可执行环境离线运行这些程序。作为Java技术在移动电话等小型设备的版本，它针对屏幕、电能和内存等资源有限的移动设备进行了优化和定义，为了解决无线设备多样化的矛盾，Sun依照各种设备的资源特性将J2ME技术架构分为Java Virtual Machine(JVM)、配置(configuration)和说明(profile)三层，然后再进一步细分，这使J2ME能够在每一类设备的限制下工作，而同时提供最低限度的Java语言功能性。
        由于定义了可执行程序下载的标准，并在手机上创立了可执行环境和程序开发语言，由此，在移动通信业第一次为软件开发商创造了巨大的商业机会，手机用户在得到丰富应用体验的同时，也大大提高了运营商的网络流量。
        Java有句名言：“编写一次，随处运行”（Write Once，Run Anywhere），也有人戏称为"Write Once,Debug Anywhere"。从实际情况来看，二者都有一定的道理。
        缺点：目前支持J2ME的移动设备处理速度还比较慢，Java服务应用软件相对较少。
        ２、ＢＲＥＷ
        美国高通公司的BREW（Binary Runtime Environment for Wireless）平台是一种为无线设备提供开放式标准平台的瘦应用程序执行环境，是无线应用程序开发、设备配置、应用程序发布以及计费和支付的完整端到端解决方案的一部分。完整的BREW解决方案包括面向开发者的BREW SDK (tm)(软件开发包)、面向设备制造商的BREW应用程序平台和移植工具以及由运营商控制和管理的BREW分发系统(BDS)。利用该系统，他们可以轻松地将开发者开发的应用程序投入市场并协调计费和支付过程。利用运营商基于BREW的服务，用户可以通过从运营商的应用程序下载服务器上无线下载应用程序来自定义手持设备。
        BREW平台是独立于空中接口的技术，所以BREW与任何网络的结合都非常平滑。在CDMA2000 1X网络中可以充分利用其高速的数据传输速率，为最终用户带来极具冲击力的用户体验。
        到目前为止，中国联通已经有了基于BREW平台所开发的商用程序，如： Adventure(环球历险记)、Any Flash (安凯软件)、 City Online(都市在线)、 E4E Stock(股票)、 Hit Submarine(决战四大洋)、 Instant Weather(天气快报)、 Mobi Escape(莫比大逃亡)、 Suc Esc(星际生存)、Yao Ming Basketball(姚明篮球)等。
        缺点：BREW目前开发工具还不成熟，主要用c语言来开发。另外，全球有34家运营商采用了Java，而只有8家运营商采用BREW，它的应用范围相对较小。
        ３、．ＮＥＴ
        .NET 是Microsoft XML Web services平台，是一组开发工具和操作系统集，用来生成、公开和消费XML Web服务，通过智能设备实现个性化的集成Web。它由四部分组成：.NET框架和 Visual Studio.NET ，服务器结构，构造块服务，智能设备软件。
        XML Web services允许应用程序通过Internet进行通讯和共享数据，而不管所采用的是哪种操作系统、设备或编程语言。 Microsoft.NET平台提供创建XML Web services 并将这些服务集成在一起之所需。对个人用户的好处是无缝的、吸引人的体验。
        .NET框架是一个用于生成、部署和运行XML Web服务及其他应用程序的环境。它包含三个主要部分：公共语言运行库、框架类和ASP.NET。.NET框架压缩版是伴侣结构，它有一套编程接口，以供开发人员开发面向智能电话和PDA等移动设备的软件。
        从根本上讲，.NET是关于使技术为人们所用，而不是强制个人适应其计算机的限制。利用.NET，无论何时何地，您总能连接到您首选设备上的信息。利用.NET，您可以保护您的个人信息和企业数据，同时允许有您的授权的他人连接到这些信息。
        .NET的缺点：该平台的一些设计太过理想，不保证能达得到(至少短期内是如此)。

    查看(675) 评论(1) 收藏 分享 管理

  • 手机企业

    2007-05-13 10:21:59

      附：获得“最具全球竞争力深圳手机企业”名单：

    “金都奖”

    企业名称

    •  最具全球竞争力手机终端企业

    华为技术有限公司
    中兴通讯股份有限公司
    宇龙计算机通信科技（深圳）有限公司
    深圳市金立通信设备有限公司

    •  最具全球竞争力手机芯片企业

    深圳联发科技有限公司
    深圳安凯微电子技术有限公司
    深圳市中兴集成电路设计有限公司

    •  最具全球竞争力手机渠道企业

    深圳市天音通信发展有限公司

    •  最具全球竞争力手机生产企业

    深圳富士康科技集团

    •  最具全球竞争力手机集成企业

    深圳市朗杰电子有限公司

    •  最具全球竞争力手机蓝牙企业

    深圳市浦诺菲电讯有限公司

    •  最具全球竞争力手机电池企业

    比亚迪股份有限公司

    •  最具全球竞争力手机电芯企业

    深圳市比克电池有限公司

    •  最具全球竞争力手机外壳企业

    耐普罗塑胶五金制品（深圳）有限公司

    •  最具全球竞争力手机显示屏企业

    深圳天马微电子股份有限公司

    •  最具全球竞争力手机连接器企业

    安费诺东亚科技（深圳）有限公司
    深圳市商立科技有限公司

    •  最具全球竞争力手机电声企业

    AAC瑞声声学科技（深圳）有限公司

    •  最具全球竞争力手机PCB企业

    联能科技( 深圳 )有限公司

    •  最具全球竞争力手机摄像头企业

    深圳青鸟光电有限公司

    •  最具全球竞争力手机增值企业

    腾讯科技（深圳）有限公司

    •  最具全球竞争力手机工业设计企业

    深圳市嘉兰图产品设计有限公司


     

    诺基亚的S60之类的是操作系统的型号，是Symbian操作系统，不仅仅是Nokia，索爱的高端智能机P系列也用的是Symbian系统，现在最常用的是S60系统，

    Moto一般使用Linux系统，C/E/V这个东西，根本不和上面是一回事，而是手机的型号

    附表：
    摩托罗拉


    A系列：总是领先潮流的、令人期待的、外观迷人的、技术领先的款式，例如：A768、3G智能手机A1000；


    T系列：总是处于流行前沿，实用的、功能丰富的款式，例如：T720i、T750（CDMA）；


    V系列：价格公道的翻盖手机，样式比较流行，功能合理的款式，例如：V600、V171；


    C系列：样式比较酷，价格低的款式，例如：C650、C381；


    E系列：注重影音娱乐功能，面向年轻群体的款式，例如：E680、E398；


    另外，MOTO还将在今年推出两个系列的新品，它们分别是R系列和S系列：


    R系列：流行的功能，革新的设计思维，非同寻常的设计就像以前的V70一样，例如：未来的R800；


    S系列：智能手机，技术先进的手机，可能是MOTO转投微软的第一代产品的代号。

     


    诺基亚


    3开头的：有独特的外观和特别的功能的款式，比如3310、3300；


    5410：独特的运动型手机，具有三防功能；


    8开头的：时尚外观，功能新颖，例如：早期的8310、最近出现的8800；


    6开头的：商务手机，传统样式，例如：6600、6681；


    7开头的：注重图片应用功能，例如：7610、7270、早期的7650；


    9开头的：注重信息互动的高端智能手机，例如：9500。


    索爱


    索爱是目前市场上最受欢迎的品牌之一，由于这个品牌的年龄不大所以型号划分也相当好记，基本上是T、P 、S、Z四大家族。


    T系列：基本型手机，现在价格主要涉及中低端，是索爱主要的型号，例如：T290c、T628；


    P系列：智能手机，采用了先进技术的款式，例如：P910c(资料 文章 价格 评论)；


    S系列：这个系列到目前为止只发布过一款手机，那就是S700c，它是面向青年人的时尚款式；


    Z系列：流行的样式，功能时尚的翻盖手机，例如：Z608；


    K系列：娱乐机型，这个系列应该是大家最为熟悉的，例如：K700c、K508c(资料 文章 价格 评论)；


    加上05年推出的W系列和J系列，例如：W800c(资料 文章 价格 评论)、J300c。


    西门子


    虽然现在西门子手机被明基收购了，但是还是有不少用户在使用西门子的机器，西门子的型号划分也是相对


    固定的，它们最近的多款新手机的热卖也让西门子又一次成为了热点，我们非常有必要了解一下它的型号划分原则，看看究竟哪一种才是适合自己的。


    A系列：低价手机，例如：A65；


    CX系列：中端手机，例如：CX65；


    M系列：适合户外的手机，设计特别，价格中端，当然也有时尚因素加入其中，例如：M55；


    S系列：商务手机，例如：S65；


    SL系列：绝对时尚手机，例如：SL65；


    SX系列：智能手机，例如：SX1。


    C系列：C75 西门子下市的绝唱


    三星


    重点说下三星手机，三星手机在中国市场上一直都有不错的销售业绩，三星手机在中国的拥有率在各大品牌中已位居前三，在水货市场，三星手机更被人们戏称为“水货之王”，足以说明三星这一品牌在人们心目中的地位不低。三星手机无论是外观还是性能都很不错，从一开始的600C到现在最新的D608，几乎每一款手机都受到了广大消费者的青睐和认可。三星手机除早期型号用数开头外，其它都以英文字母系列划分归类。


    A系列：A188 A308等


    C系列：目前三星的低端直板机，如C218


    D系列：定位于高端娱乐影音功能，如现在最火热的D508，D608


    E系列：中高端的商务机 E728，E568，E818等


    S系列：高级商务功能系列，早期的S308，S508等


    M系列：三星早期的MP3手机系列，如SGH--M188


    T系列：早期的GSM彩屏折叠系列，也上大家最熟悉的系列，如T108、SGH--T208、SGH--T408、SGH--T508


    X系列：基于CDMA 1X网络的手机系列，也有个别的机型，如X108，X608等


    三星系列手机的型号前面都有前缀，包括SGH、SCH、SPH、STH等，它们的区别在于网络制式，带有SGH的为GSM手机，带有SCH的为CDMA手机，其它前缀的为其它网络类型，在中国没有出现

    黄页
    芯片企业
      ·英特尔   
    ·ADI
    ·飞利浦
    ·高通
    		·瑞萨科技
    ·德州仪器
    ·微控科技
    ·意法半导体
     
    配件企业
      ·KINGMAX
    ·NanoFocus
    ·仙宇电子
    ·无锡凯尔
    		·友元通訊
    ·loyal-battery
    ·澳柯玛新能源
    ·宝明光电子
     
    软件企业
      ·汉王科技
    ·南京移软
    ·Openwave
    ·凯思昊鹏
    		 ·爱可信
    ·数位红
    ·奇趣科技
    ·天津猛犸
     
    设计企业
      ·德信无线
    ·中电赛龙
    ·宇龙通信
    ·Mobicom
    		·禹华通信
    ·经纬科技
    ·上海毅仁
    ·宇梦通信
     
    手机分销商
    ·中域电讯
    ·中邮普泰
    ·协亨通讯
    ·天音通信
    		·中复电讯
    ·苏宁电器
    ·大中电器
    ·国美电器
     
    整机厂商
      ·诺基亚
    ·明基
    ·波导
    ·海尔通信
    		·多普达通讯
    ·三星电子
    ·夏新电子
    ·摩托罗拉

    查看(984) 评论(0) 收藏 分享 管理

  • 【转帖】MTK]平台相关资料

    2007-05-13 10:03:00

    MTK平台入门资料

    编译工具和辅助工具:
    ADS1.2
    ADS12_update_842.exe
    MSYS-1.0.10.exe
    MinGW-3.1.0-1.exe
    ImageMagick-6.2.5-5-Q16-windows-dll.exe
    7z313.exe

    开始编译：
    切换到项目根目录，然后在命令行下面执行命令：
    make custom=proj gprs new
    其中，命令可以为 clean,     update,    remake

    目标文件：
    生成的目标文件为.bin文件， 位于 MTK\build\proj 目录下面，build 目录为生成的一个目录。

    Log文件：
    Log文件同.bin文件一样，也是位于 build 目录下，如果编译出错，可以在命令行中看到出错的模块， 然后到build 目录下找对应的log文件。

    仿真环境：
    工程文件 PixtelMMI.dsw 位于目录     MTK\plutommi\mmi 下面，由此可进入仿真环境。

    烧写程序：
    工具  Flash_tool.exe 可烧写程序。
    该工具的主要设置是 COM口 和目标文件位置。
    Download argent 和 scatter file 用自带的就可以了，选中这两项后，会出现ROM的选择项，点击后可选择.bin文件。

    设置好上面的参数后，连接上手机，将手机断电，然后按开机键就可以烧写程序了。

    Trace 工具
    在手机上往往要做一些trace，这就要用到trace工具---Catcher.exe。
    手机上打 trace 接口为kal_prompt_trace，如同agere平台的GSMprinf.
    使用 Catcher.exe，
    要先要设置 DataBase，这个文件是在编译的时候生成的，是个没有扩展名的二进制文件，该文件位于 \MTK\tst\database_classb，例如， BPLGU..。
    在 Catcher.exe 中，设置 DataBase 的方式是 configà set database path
    其次, 要设置模式为logging，这样才能进行下面的设置。
    该设置位于  controlà modeà logging
    第三，要设置好COM口。
    第四， 打开连接开关，表示 Catcher.exe处于待命状态。
    第五， 设置filter。这个可以过滤一些自己不需要的log。有时半天不出现log, 这时候重新选择一下filter一般就会解决问题。
    Filter设置路径为  controlà set filter

    Catcher.exe 使用的连接线给烧写程序用的线是同一条。
    保存log:
    在log区域选中想要保存的log  (可用shift＋ 鼠标)，鼠标右键选save as…
    有时为了方便测试，会设置trace默认关闭， 需要的时候可以打开。
    该设置在工程模式下。
    设备à set UARTàTST Config, 设置合适的UART 口。比如，UART1是可以trace的。

    编译出错：
    有时编译会出现莫名其妙的错误，比如一刚刚可以编译通过，现在却不行，.


    以上为项目开发的基本环境和基本过程
    接下来的内容，则是具体的开发细节
    ―――――――――――――――――――――――――――――
    添加文件:
    开发过程中，少不了加减文件, 删除文件实际上是添加文件的相反过程，因此略过。
    MTK设置了很多lst 和 pth 文件供用户添加文件，这些都在make文件夹下。用户可以自己添加模块，也可利用原有的lst 和 pth 文件添加。以下以添加在 MTK\make\plutommi 为例。
    添加头文件路径：
    plutommi.inc
    添加本模块路径：
    plutommi.pth
    添加源文件路径：
    plutommi.lis
    添加完毕，这些文件就可参与编译了。

    添加开关：
    开关真是个好东西。依靠它，可以将没有价值的功能瞬间屏蔽，又可以将我们需要但又搁置的功能瞬间启用。能者上，不能者下,多么类似于社会法则。
    添加开关 在make文件夹下面的 .mak文件里面。
    注意事项：
    有人喜欢模仿MTK原做法，在 .mak文件里面使用一个开关管住另外一个开关。那么两个开关不要同名，否则开关起不了关闭的作用。

    添加string资源:
    1. GlobalDefs.h 中增加ID
    2. population.c 中将ID和 string关联
    3. plutommi\Customer\CustResource\PLUTO_MMI\ref_list.txt 中增加ID 和各种语言的文本
    有了以上3个步骤，即可使用该文本资源了。

    编译后,在 plutommi\Customer\CustResource下面 会生成新的
    CustStrMap.c 和
    CustStrRes.c
    这两个文件中就包含了新增的string资源

    添加图片：
    1. GlobalDefs.h 中增加ID
    2. population.c 中将ID和 string关联
    3. 增加图片到解压后的包里，增加完毕，应打包。plutommi\Customer\Images\PLUTO176X220
       里面的文件夹是生成的，可以在cc上看到为private。
    4. 添加进去后，要打包，如果仅添加在文件夹里面会被清除。

    如果没有找到图片文件，手机显示的时候是一个红色的*
    添加图片时，注意路径用4杠

    在NVRam中增加成员：
    需要增加ID，指出每块大小，以及总的块数 和缺省值。
    每块大小最好为偶数。
    修改下面的文件：
    Nvram_user_defs.h:  ID, 大小，个数
    NVRAMEnum.h
    Nvram_user_config.c
    custom_nvram_editor_data_item.h

    查看(1007) 评论(1) 收藏 分享 管理

  • [转帖]基于Agere平台的手机自动化测试实现

    2007-05-12 21:14:24

    基于Agere开发平台的GSM手机自动化测试解决方案

    发布时间: 2007-4-16 11:12    作者: 楚才    来源: 51testing无忧测试电子杂志第二期

     

    【摘要】本文就杰尔系统（ Agere system ）平台基础上开发的 GSM 手机自动化测试提供一些技术介绍，并结合实际例子讲解一些应用经验，来说明自动化测试在手机功能测试一级中所带来的效率。

    【关键词】手机平台，杰尔系统， Trace ， PTE 命令，手机软件功能测试，自动化测试

    •  国内手机功能测试现状：

    当前国内手机厂商和设计公司据统计已达到 300 多家，但至今所有的设计开发都是基于国外技术平台基础上的二次开发，即通常所说的 MMI 开发， 提供开发的手机平台目前主要有德州仪器（ TI ），英特尔（ Intel ），飞思卡特（ freescale ），杰尔系统（ Agere system ），英飞凌（ infineon ），瑞萨科技（ renesas ），菲利普半导体（ philips ），意法半导体（ ST ），美国博通（ broadcom ），美国模拟器件（ ADI ），微控科技（ wavecom ）。通常这些平台供应商的核心技术都不对外开放，只为购买其开发平台的用户提供一个可二次开发的环境，比如本文所要介绍的自动测试所基于的平台 ——Agere system ， 它在其软件架构的上层为开发用户做了一层 UI （ User Interface ） , 并做了最基本的 AL 开发，通常方案提供后可以直接作为国内厂商用于 FTA 测试，这即是国内众多手机厂商和 design house 开发和测试的母体。

    曾听一位从事手机功能测试的同仁说 “ 做手机功能测试只要有手就可以了 ” ，确实手机功能测试很容易给人一种是简单而重复按键操作的感觉。但手机功能众多，并且回归测试工作量大，如果单个测试工程师靠手动按键来执行所有测试用例，花费的时间少则几小时，多则需要几天的时间，这样耗费大量测试时间的同时也容易让测试工程师产生疲倦甚至是厌倦心里，很容易造成测试的遗漏。手机测试中常碰到很多重复性高的工作，如发送数条 SMS 或者 MMS 以验证其收发成功率以及稳定性、连续进行多次呼叫、多次对文件系统进行添加删除操作、多任务多进程情况下的冲突测试以及极限测试等等，都是重复性高的工作，手动执行的话费时费力，如果能有一套自动执行的机制，将能大大提高测试的效率。

    由于手机平台的特殊性，国内通常都没有自动化测试工具支持手机功能测试，纷繁复杂的功能测试大多只能通过文本化测试用例的指导，由广大测试员手工来完成。手机这种板机的 MMI 功能测试不同于基于 PC 上的 MMI 测试，后者借助 PC 平台，目前市场上已有非常多功能强大且通用的自动测试工具支持其测试，如比较典型的有 Winrunner ， Robot ， Loadrunner 等等，但这些工具通常不能兼容到象手机这种嵌入式系统中来。当然平台供应商对他们底层 lay1 ， lay2 ， lay3 的测试都有自己开发的测试工具来自动执行，但这些工具暂时都不提供给国内的开发厂家。

    为了解决上述手机测试工作中的困难，笔者所在的测试团队经过不断的总结实践，目前已在基于杰尔系统（ Agere system ）平台上建立了一套实用的自动测试机制，通过该机制的建立，不但调动了测试工程师的工作积极性和热情，同时也大大提高了测试的效率。下面将围绕 Agere 平台上自动测试机制给大家做个总体介绍。在讲述该方案前，将先对 Agere 平台的窗体和消息，以及手机同 PC 的数据交互原理做个简单介绍。

    •  手机中的窗体和消息：

    功能测试时，在手机上每按下一按键，都是在特定的窗口下完成其功能，窗口处理函数接收到窗口所用键盘中定义的按键消息后执行相应的处理，完成指定的工作。这里所谈的窗口系统本质上是一个链表，主要是响应手机中常用的三类消息：用户的按键操作、 GSM 网络消息、以及计时器消息。

    手机中窗体处理函数结构通常如下：

    static UINT32 TestWindowProc( UIWINDOW * win, UINT16 cmd, UINT16 wParam, UINT32 lParam )
    {
    switch ( wParam )
    {
    case EV_KEYSEND: /*按发送键*/
    CALL(MAOTelNumber);
    return TRUE;

    case EV_KEYEND: /*按挂机键*/
    ENDCALL(MAOTelNumber);
    return TRUE;
    ......
    default：
    break;
    }
    }

    在窗体中除了对消息的实时处理外，还有通过具体的消息传递函数对本窗口中消息进行派发和定向流动，通常有 GSM 消息的流动和键盘消息的流动，派发 GSM 消息时，依据窗口建立的逆向顺序逐层往上流动，而键盘消息只向上传递一层，即子窗口向父窗口传送。 在系统功能测试过程中，窗口中的消息执行情况是看不到摸不着的东西，但是各个窗口中这三类消息的处理以及消息的派发流动都是测试所必须了解和测试的重点，怎样才能直观的看到，跟踪并了解这些消息的执行情况呢？测试工程师可以通过在跟踪点加测试桩或者跟踪语句来实现追踪，利用杰尔系统的 trace 工具（ optitrace ）以文本的形式输出所需要了解的信息，根据这些信息的输出流程和实际数据，以达到测试跟踪和分析的目的，如上面这一简单例子中所列举的两个事件 EV_KEYSEND 和 EV_KEYEND ，最简单的跟踪是通过在这两类事件触发前增加类似于 print 跟踪语句，判断 “ 发送键 ” 按下后是否在指定的窗口里执行到 EV_KEYSEND 事件并调用呼叫函数 CALL 执行呼叫请求 , 实际运行时，根据 optitrace 工具所显示的 print 信息观察程序的运行及消息的执行情况，跟踪的手段很多，在此就不详细列举。下面介绍 PC 怎样通过 Optitrace 工具实现同手机板机的数据交互。

    •  手机与 PC 的数据交互

    通常每个平台为软件开发提供一系列的开发套件，常用的有仿真软件、 Trace 跟踪分析软件、 Download 目标代码的装载软件等等，通过这些软件实现手机同 PC 的数据交互，实现软件的开发仿真，问题的跟踪分析，以及程序的灌写等。这些软件大多采用串口通讯的方式，通过特定的数据线连接手机串口通讯端与 PC 的串口或者 USB 端（ USB 转串口）。下面将要介绍的是杰尔系统（ Agere system ）的开发套件之一 optitrace 。

    该工具可以运行于 win9X/2000/NT 系统中，是 Agere 参考设计平台的辅助诊断工具，它为软硬件开发人员提供 Protocol Stack and MMI 的跟踪分析以及模拟用户硬件如串口显示和按键，为 field Test 人员提供 Trace Logs 和 Vital signs ，为产品测试工程师提供 Product Test environment （ PTE ） 窗口和脚本的定制以及播放。

    该工具的运行界面如下： 
     

    以上运行界面中通过 optitrace 工具捕捉的用户按键消息，如 Key Code 4 ，表示用户在手机上按下数字键 4 ， key code 后面的数字是按键所定义的编码值，手机中每个按键都有唯一的按键编码值。从中可以看出，用户所有的按键动作都以 “AL got key AL_KeyDown event ， key code X” 的形式被记录下来。这些按键信息的捕捉只是该工具 trace 信息的一部分，该工具提供非常多的 trace 选项，实际应用中，可以根据所要跟踪的信息来选择显示。

    该工具一个最重要的功能是可以在 PC 端通过 PTE 命令模拟用户来操作数据线另外一端的手机，该工具本身定义了 11 类的 PTE 命令，下面重点介绍两个重要的 PTE 命令，

    •  模拟一个按键按下和释放

    输入格式： Key <INT16 Keycode>

    返 回： Key:DONE

    用户可以在 optirace 的 PTE 命令输入行中，通过输入正确的 Key 命令，往手机端写入按键事件，手机端解析后执行相应的按键操作，如用户输入 key 8 回车后，手机端 LCD 显示 8 或者执行按键 8 所对应的操作，执行后返回 key ： DONE 消息。同时 trace 中显示 AL got key AL_KeyDown event ， key code 8 。

    •  定义按键事件的发送间隔

    输入格式： Wait <INT16 wait time>

    返 回： Key:DONE

    举例：

    wait 6000 // 等待 6000Ms ，即 1 分钟

    通过该命令，可以请求一个 pause 。比如呼叫 1001 通话 1 分钟后挂断。 PTE 脚本编写如下：

    Key 1

    Wait 500 // 按键间等待 0.5 秒

    Key 10

    Wait 500

    Key 10

    Wait 500

    Key 1

    Wait 500

    Key 11 // 按呼叫键

    Wait 3000 // 等待呼叫， 3 秒

    Wait 60000 //1001 接通后等待 1 分钟

    Key 12 // 按挂机键，结束通话

    Wait 500

    •  自动测试方案及框架体系 :

    下面介绍本公司实践的一套自动化功能测试方案架构，如下图 ：

    •  方案简述 :

    自动测试主要工作流程分以下几个主要阶段：

    •  测试用例的设计和准备 , 形成一套自动测试用例脚本库

    自动测试用例的准备，如果贵公司在需求定义的同时有各功能详细具体的 menu tree 架构，那即可在此基础上手动编写 PTE 命令脚本。

    如一菜单结构如下：

    假设一手机的关机功能菜单位于主菜单中第 5 项菜单 “ 话机设置 ” 的第一子菜单中，可以用以下脚本方式实现手机执行关机。


    Key 15 // 在待机下按左键进主菜单

    Wait 500


    Key 5 // 按 5 进入住菜单的第 5 个子菜单 “ 话机设置 ”

    Wait 500


    Keyhold 1 ， 2000 // 长按 1 键关机

    Wait 500

    从中可以看出只要定义了 menu tree ，理解菜单的排列顺序，以及实际的功能操作步骤，即可以用脚本来模拟所有按键和执行步骤来定义测试的 PTE 脚本。

    另一种脚本编写方式可以通过录制加转换的方式实现，利用 optitrace 工具录制实际操作时的按键动作，存为 txt 文件，然后将该 txt 文本转换为 PTE 脚本文件。实际测试中通过在集成测试或者系统测试初级阶段录制脚本，这样不会因软件大的变更导致测试用例失效，或者需要大规模维护，降低了风险指数。这些脚本在日后的回归测试中将发挥巨大的作用。

    按键录制时测试工程师针对某一功能或者依照某一组测试用例执行一次完整连续的手工测试，通过 optitrace 捕捉本次测试过程中所有的按键事件，生成一份对应的 << 按键事件列表文档 >>.TXT （ optitrace 只能生成文本文档），然后对应将所有按键事件转换为 <<*.PTE 文本 >> 。

    •  代码桩或者跟踪语句

    测试时根据实际情况可能需要在各检测点编写用户检验的代码桩或者跟踪语句，代码测试桩有利于对本自动测试体系中软件问题作出较精确的定位和分析，同时也有利于对测试结果的快速判断与自动生成测试报告。这些代码测试桩对应按键事件所对应的程序执行路径和逻辑，主要通过白盒测试方法跟踪代码执行的路径、逻辑覆盖、信息流，数据流和控制流等。在测试执行时，测试桩将执行结果响应并通过 Trace 跟踪语句显示在 optitrace 工具中。编写该测试桩需要测试工程师具备较强的编程能力，同时对手机系统要比较熟悉和了解。各功能完整的代码测试桩的编写工作量非常大，前期可以只针对部分功能的部分特性做尝试。同时测试桩插入在相应的代码中，为了避免混乱，配置时必须将测试代码同程序代码分开，只在测试执行时打开对应的编译开关得到对应的编译版本。

    •  生成一份预期的测试报告

    运行预先录制的 PTE 脚本和对应的测试桩，通过 optitrace 工具生成一份预期的测试结果报告 ( 实际就是 optitrace 生成的一份按键事件和测试桩跟踪输出信息 ) 。这份预期的测试报告日后同实际结果比较，作为实际测试结果与预期结果是否一致的判断。

    •  生成自动测试用例库

    最终由 << 按键事件列表文档 >> 、 <<*.PTE 文本 >> 、代码测试桩、 << 预期的测试结果报告 >> 组成一份自动测试用例。所有的自动测试用例按照一定的结构组织起来形成自动测试用例库。

    •  测试用例的提取并执行

    在回归以及后期的验证测试过程中，测试工程师或者程序员对应提取由 <<*.PTE 文本 >> 和测试桩组成的测试用例，执行后生成一份 << 实际的测试运行 trace 信息 >> ，保存该信息，从而测试执行结束。

    •  测试结果分析，生成测试报告

    测试结果的分析可以自动和手动执行，手动执行可以通过 Beyond Compare 工具比较 << 预期的测试结果报告 >> 和 << 实际的测试运行 trace 信息 >> ，即可以得出一份测试的执行报告。

    自动生成测试报告比较复杂，需要在 pc 中用高级语言建立一个测试管理中心，该管理中心可用 VC 或者 C++ 等高级语言编写，在该管理中心中，用户可以选择需要执行的 PTE 脚本或者多个脚本串成的一组脚本，该测试管理中心可以指定测试用例的自动执行，自动提取对应的结果做自动比较分析，从而生成一份对应的测试报告，如果无差异，输出文件中只显示 OK ，否则输出差异信息文件。

    •  实际应用 :

    下面以待机下呼叫 1001 共 100 次来测试呼叫成功率的例子来说明上述方案的应用。下面是该例的录制，脚本编写，及实际运行的例子。

    •  录制按键事件 .

    首先运行 optitrace.exe 程序

    设置 trace 选项 , 只选择 application layer 中的 ALTraceUHMess 如图所示：

    最后手机开机，跑动 trace ，测试工程师针对某一功能或者某一组测试用例执行一次完整连续的测试，得到以下按键信息，如图所示。

    最后测试执行结束后，保存该按键 trace 信息，做好版本记录信息。生成对应事件的按键列表《呼叫 1001 共 100 次 .TXT 》文档， 该 TXT 文档内容完全同上图所示内容，在次不再重复。

    •  生成 PTE 脚本：

    因实际 optitrace 只录制按键消息，需要将这些按键消息转换为 PTE 命令并生成工 optitrace 工具运行的 *.PTE 脚本。而通常按键事件众多，手动逐一生成 PTE 脚本非常麻烦，因此需要做一个文件转换工具，逐行提取按键消息转换成 PTE 命令，并做一些相应的注释。

    将以上按键列表转换为 PTE 命令列表，生成《呼叫 1001 共 100 次 .PTE 》文件，转换后的 PTE 脚本如图所示：

    •  编写测试桩：

    编写测试代码对需要检测的路径、逻辑覆盖、信息流、数据流和控制流等做测试跟踪，在检测点输出有效的 trace 信息。

    该测试用例比较简单，在此只列举该测试任务中需要关注的呼叫是否成功，记录实际呼叫成功的次数，具体呼叫函数、以及逻辑覆盖因篇幅有限不列举，设计一计数器（ NumOfCallSuccess ），如果呼叫成功，该计数器累加 1 ，并且每次呼叫后用 printf 语句在 optitrace 工具上输出该计数器的实际值。

    在呼叫窗口的处理函数中，对网络返回的 GSM 消息进行统一处理，在返回的回铃音处理消息中检测呼叫成功即可，如下所示：

    case GSMAlerting: // 成功接收回铃消息

    if(NumOfCallSuccess < 100) GSMprintf("\n====NumOfCallSuccess=%d======\n",

    ++ NumOfCallSuccess); // 呼叫成功

    else

    {

    NumOfCallSuccess =0;

    GSMprintf("\n====== NumOfCallSuccess ＝ %d======\n", NumOfCallSuccess);

    }

    break;

    •  结合以上测试桩，运行《呼叫 1001 共 100 次 .PTE 》，生成预期的测试结果报告，《呼叫 1001 共 100 次 trace.TXT 》的 trace 跟踪记录文件，作为实际测试运行结果比较的依据。

    Trace 信息去除无用信息及文件转换后如下所示：

    •  自动运行《呼叫 1001 共 100 次 .PTE 》，测试结束后目录下共有以下文件：

    《呼叫 1001 共 100 次 .PTE 》：测试运行的脚本

    《呼叫 1001 共 100 次 trace.TXT 》：预期的测试结果文本， Txt 格式。

    《呼叫 1001 共 100 次 trace2.TXT 》：实际运行的 trace log 结果，被管理工具转换后的 TXT 文本。

    《呼叫 1001 共 100 次 .Txt 》：测试后生成的测试报告文件， TXT 格式。

    •  总结：

    本文结合杰尔系统（ Agere system ）中开发套件 optitrace 工具的使用，从 PTE 脚本的制作，到回归测试中脚本的测试运行，介绍了一个测试团队在手机功能级测试中采用的自动化方案，本团队在实际的使用中感受了该自动化测试方案所带来的乐趣和效率，在此著成本文供大家一起探讨，最后感谢本文的所有读者，如果您能从中汲取一点有用的营养，得到一些帮助，那我将感到无限的欣慰，这也是我整理这篇手机自动测试资料的初衷。

     

    查看(637) 评论(0) 收藏 分享 管理

  • 【转帖】软件测试工程师调查

    2007-05-12 20:21:00

    师

    　　 所属门派：IT业
    　　“假如存在没有任何错误的程序，那么世界也会不复存在。”
    　　 因错误而存在，因修正错误而存在，这就是软件测试工程师的存在之道。虽然测试不是解决错误的根本举措，但却是必须的手段。
            软件测试工程师（Software Testing Engineer）的主要工作职责是，理解产品的功能要求，并对其进行测试，检查软件有没有错误（Bug），决定软件是否具有稳定性（Robustness），写出相应的测试规范和测试案例。
            简而言之，软件测试工程师在一家软件企业中担当的是“质量管理”角色，及时纠错及时更正，确保产品的正常运作。据有关调查数据表明，目前国内许多软件企业内部的测试人员和开发人员之比在1：5，与国外软件业1：1的比例还相去甚远。


    　　门派技能：
    　　软件测试工程师主要职责为：
    　　1、负责项目/产品的测试工作，分析产品需求，建立测试环境和计划，保证产品质量以及测试工作的顺利进行；
    　　2、按照软件工程规范和项目管理流程，实施、管理和知道软件开发不同阶段的各种测试，并提交测试报告。测试的计划安排包括人员安排、进度、使用的软硬件环境、测试的流程等；
    　　3、提交测试报告，并撰写用户说明书；
    　　4、参与软件测试技术和规范的改进和制定。


    　　入门资质：
    　　一般需要至少专科学历，一到两年测试工作经验。要熟悉软件的测试技术、方法、流程、测试文档，若想进一步提升，还要熟悉自动化测试的流程、管理及深层开发（包括测试框架等）；了解若干主流测试工具，如功能测试工具winrunner、quicktestpro，性能测试工具LoadRunner，配置管理工具TestDirecter, Visiual Source Safe等；熟悉一些主流的软件工程方法论和思想，如RUP、CMM、CMMI、XP、PSP、TSP；了解软件工程，软件生命周期模型基础，了解软件配置管理；能够根据不同企业的产品特点，要求了解相应的开发测试方法。对于资深的软件测试人员，有些企业还要求其本身有自主开发测试工具的能力。
    　　由于需要与开发人员及时沟通，因此作为一个出色的软件测试工程师，还需要有良好的沟通技巧以及优秀的言语表达能力，具备良好的团队合作精神。


    　　入门经：
    　　缜密的逻辑思维能力为了应对软件使用者千差万别的使用习惯和软件在使用过程中出现的各种现象，软件测试工程师应该具有逆向思维能力，能够以用户的角度出发，捕获一切可能性，对细节有不同寻常的关注能力。此外，软件测试工程师还要有穷追到底的精神，并且要善于沟通和撰写各类专业报告。
    　　出色的沟通能力要成为优秀的软件测试工程师，要具备出色的沟通能力和表达能力，既能够和技术开发人员沟通无碍，又能用简洁明了的话语向客户、管理者等这些非技术人员阐述系统在哪些方面还有缺失有待改进。在同开发人员的沟通过程中，要注意沟通技巧，提高沟通效率，和开发人员保持良好的人际关系。当测试人员发现软件有问题时，不仅需要跟开发人员沟通，找到问题出在哪儿，阐述自己挑错的理由，有时候甚至要提出解决方案，直接参与前期需求和代码的修改。一个优秀的软件测试工程师能够适时地站在各自的立场上考虑、解释并解决问题，从而尽量避免冲突和对抗。
    　　全面的技术能力作为软件测试工程师，虽然无须精通各种语言各类技术，但必须全面理解被测软件系统，明白该使用何种工具进行测试。要做到这一点一般需要有一定的编程经验，这些经验可以加深对软件开发过程的理解。
    　　耐得住性子　软件测试工作是枯燥的，甚至重复性的，有时需要花费惊人的时间去分离、识别和分派一个错误，因此需要测试人员能静得下心耐得住性子。这个工作不容许有丝毫的心浮气躁。同时，逻辑严密但不乏重复成分的测试工作也容易使人倦怠，因此需要一定的自我督促能力。
    　　规范测试流程公司不正规的测试流程，不标准的测试方法，将使软件测试人员终日陷入碌碌无为的点击按钮的不良状态中。


    　　晋阶易筋经：
    　　初级测试工程师
    　　入门级，具有一些手工测试经验，开发测试脚本并开始熟悉测试生存周期和测试技术；
    　　测试工程师
    　　能够独立编写自动测试脚本程序并担任测试编程初期的领导工作，进一步拓展编程语言、操作系统、网络与数据库方面的技能；
    　　高级测试工程师
    　　帮助开发或维护测试或编程标准与过程，负责同级的评审，并能够指导初级的测试工程师；
    　　Team Leader
    　　一般具有5年左右工作经验，负责管理一个小团队。负责进度安排、工作规模/成本估算、按进度表和预算目标交付产品，负责开发项目的技术方法，能够为用户提供支持与演示；
    　　测试经理
    　　能够担当测试领域内的整个开发生存周期业务，能够为用户提供交互和大量演示，负责项目成本、进度安排、计划和人员分工；
    　　计划经理
    　　具有多年纯熟的开发与支持（测试/质量保证）活动方面的经验，管理从事若干项目的人员以及整个开发生存周期，负责把握项目方向与盈亏责任。


    　　秘传“薪”经：
    　　薪资黄金点
    　　软件测试工程师在IT行业中越来越受到重视，其薪资也节节高升。
            测试工程师的起薪从2000～5000元/月不等，若有四年工作经验的话，薪资在8000元/月左右，具体视不同地域、不同性质企业、测试工程师的不同能力而定。一般工作5～8年的软件测试工程师的薪资是刚出道时的新手的一倍，而10年以上工作经验的软件测试工程师薪资却走了下坡路，和5～8年的从业者持平甚至有些企业开出了略低的薪资，看来这行的折旧率较高。
    　　软件测试行业的从业者7成左右都拥有本科学历，本科学历的从业者的薪资约为大专学历从业者的1.33倍左右，而硕士学历的从业者薪资起点明显高于本科学历从业者，约为后者的1.49倍。一般外语能力精通者的薪资为平均薪资的1.29倍左右，熟练者为平均薪资的1.09倍，值得注意的是，深圳、杭州和大连的外语能力精通者的薪资均超出平均薪资不少，其中杭州的外语能力精通者的薪资是平均薪资的1.79倍。
    　　以3.5年左右从业工作经验的软件测试工程师的各地薪资情况来看：
    　　深圳地区的平均年薪是全国各城市最高的，超出7万元，其中外商独资欧美企业的年薪为7.8万元，国营企业的年薪紧随其后，超过了7.3万元，合资/合作非欧美企业的年薪较低，约为6万。
    　　北京地区该职位的平均年薪逾5.8万元；其中外商独资企业的年薪为全国之最，将近8.5万元，而其余各类型企业的年薪都在5～6万元左右。
    　　广州地区该职位的平均年薪约为4.5万元；其中外商独资欧美企业的年薪最高，达到了7万元；合资/合作欧美企业也能拿到6.2万元的平均年薪，合资/合作非欧美企业就较逊色，年薪不到4万元。
    　　上海地区软件测试工程师的平均年薪为6.3万元，欧美独资和欧美合资的薪资不相上下，分别为7.9万和7.7万元。国营企业略高于平均线，达到6.5万元，其余各类企业则都表现平平。
    　　杭州地区该职位的平均年薪达到了5.5万元；其中外商独资欧美企业和合资/合资欧美企业的年薪相当，均为6.9万元，国营企业的薪资也颇吸引人，超过了5.9万元，民营/私企和合资/合作非欧美企业的年薪均不到5万元。
    　　大连地区该职位的平均年薪为3.8万元；其中外商独资企业和合资/合作欧美企业的年薪均超过了4.7万元；国营企业的软件测试工程师的年薪也近4万元左右，而民营/私企和合资/合作非欧美企业的年薪则相对较低。


    　　福利
    　　上海地区的软件测试工程师享有的带薪年假是全国各地最多的，一年中平均有10天，北京、广州、大连均为8天，杭州和深圳相对较少，为6天。
    　　以上这些地区在软件测试的培训方面都做得不错，基本上均有6成以上的从业者可享受到公司提供的培训计划，但上海的软件工程师的培训比例不到5成。杭州和深圳两地的培训是全国各地区最出色的，逼近8成。
    　　深圳、上海均有2成的从业者可享受房贴或者补充住房公积金，大连和北京则有3成以上的从业者可享受公司的房贴或者补充住房公积金，广州更是达到了4成以上，而杭州此项福利的比例较低，仅为1成。

     

    TAG: 测试职业发展

    查看(490) 评论(0) 收藏 分享 管理

  • 【转帖】黑盒测试方法

    2007-04-29 20:56:39

    暂无

    查看(544) 评论(7) 收藏 分享 管理

  • 手机测试术语

    2007-04-14 22:11:34

    GPRS是通用分组无线业务 （GeneralPacketradioService）的英文简称，是一种新的分组数据承载业务。相对原来GSM的拨号方式的电路交换数据传送方式， GPRS是分组交换技术，具有“实时在线”、“按量计费”、“快捷登录”、“高速传输”、“自如切换”的优点。
    W-CDMA(宽频分码多重存取)、CDMA2000(多载波分复用扩频调制)
    CDMA英文全称“Code Division Multiple Access”就是码分多址分组数据传输技术（码分多址连接方式）
    CDNC计算机辅助设计数字控制
    GSM: GSM全名为：Global System for Mobile Communications，中文为全球移动通讯系统
    TD－SCDMA的中文含义为时分同步码分多址接入，综合了FDMA（Frequency频率），TDMA和CDMA等基本传输方法。
    J2ME：Java Micro Edition(J2ME),又称Java2微型版，主要针对嵌入式设备及消费类电器。例如智能卡、手机、PDA、电视机顶盒等。

          CLDC（Connected Limited Device Configuration）有限连接设备配置：J2ME定义中的Configuration 概念对运算功能有限、电力有限
    的嵌入式装置的简称。就CLDC 的规范来说，可以支援的核心类别函式库为java.lang.* 、java.io.*、java.util.*，而支援的扩充类别函式库
    为java.microedition.io.*。

          MIDP(Mobile Information Device Profile) ：移动信息设备描述是一套Java应用编程接口(Application Programmer's Interfaces(APIs))。它与CLDC一起向诸如蜂窝电话等移动信息设备提供了一个完整的Java应用运行环境。MIDP是向下兼容的，即 MIDP2.0的手机能玩MIDP1.0的游戏。

          MIDP 2.0 定义：MIDP 2.0 也叫MIDP_NG，它的编号是JSR 118。MIDP2.0 与1.0相比有很大提高，增加的特性包括：提供域安全模型，以允许对应用程序进行签名和论证；提供TCP、UDP网络接口；内置OTA；更好的用户界面； 基本的声音API。

          UIQ Series：UIQ Series操作平台的特性是它的多媒体性，功能全面。UIQ界面上可支持手写操作，不过切换和关闭任务比较麻烦。
    UIQ Series是Symbian OS 的系统架构上，专门为高阶的多媒体手机而设计，使用起来非常类似 PDA 操作，不过目前只有少数的机种采用 UIQ 系统。

    查看(1910) 评论(11) 收藏 分享 管理

  • 何谓ActiveX

    2007-03-20 21:53:04

    用最简洁的话说,ActiveX是一种体系结构,它让程序(即ActiveX控件)在网络(如Internet)上与其它程序互交通信。 它是一种与Java不同的技术,Java是一种全新的编程语言加上虚拟机技术规范。ActiveX体系结构均使用微软公司的组件 对象模型(COM)和分布式组件对象模型(DCOM)标准;COM允许不同的应用程序实现本地相互交谈,而DCOM提供在网络上的 (应用程序间)通信。

    　　开发人员可以利用多种流行的编程语言来编写ActiveX控件。如微软的Visual C++5.0 , Visual Basic 5.0和Delphi 3.0。 虽然Active X控件能用Visual J++来编写,但有局限性。

    　　开发人员按ActiveX的技术规范用编程语言生成ActiveX控件。ActiveX控件是某一程序内自包含的部分或独立的组件。 开发人员能在其它的程序中(甚至是用其它语言写的程序中)重复使用它们。例如,你可以把用VB写的控件插在用VC++写的程序中。

    　　这种重复使用和自包含的本质来自于微软公司更早的面向对象应用程序研究,即对象链接和嵌入(OLE)标准。ActiveX是从OLE 发展而来的,实际上,ActvieX对象基本上就是OLE对象, 增加了使它们在WWW上工作的功能。通过ActiveX从OLE发展而来,我们看到 了聪明的市场行销举措的剖析:微软公司利用它多年来已开发出来的技术在Internet的市场上插了一足。

    　　由于OLE已存在多时,开发人员已编写了很多OLE对象,这些对象现在可用作ActiveX控件。有些软件公司售出大量的OLE对象库 能够用来编制程序的预制组件。这是ActiveX最有力的强项之一:已有的大量已预制好ActiveX控件能帮助开发人员以最短的时间 和最少的争论编 制软件。

    　　ActiveX的这种可重用对象的能力使其成为编写普通的客户机/服务器程序极有用的工具。它不仅提供了现成的控制库,而且让 开发人员使用他们自己的控件。

    　　ActiveX是设计成让这些控件在Web上工作,微软的行销机器也在全力以赴使ActiveX成为编制Web控制的标准。虽然目前ActiveX 在Web上最流行的用途是给Web页面增加动画, 但它对各公司的Web站点是有用的??多数访问者喜好站点的简洁性。

    　　更重要的是,ActiveX(和Java小应用程序)能够增加页面中客户机/服务器应用程序的功能。ActiveX控件让Web站点的访问者完成 复杂的动作,接收数据库和服务器上其它应用程序甚至其它Web站点的数据。这就是微软声称ActiveX"激活"你的Web页面新包含的意 思??在一定程度上这是个好主意。设想一 在一个世界范围的局域网上,网络客户机(浏览器)能快速下载和运行任何一个Web服务 器的任何程序。梦想是美好的,但ActiveX还有很长的路要走。

    查看(350) 评论(0) 收藏 分享 管理

  • 软件需求的层次

    2007-01-29 23:36:08


    作者：本站   日期：2006-4-10

    　　软件需求包括3个不同的层次――业务需求、用户需求和功能需求。
    　　除此之外，每个系统还有各种非功能需求。
    　　业务需求（Business requirement）表 示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开 发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。
    　　用户需求（user requirement）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。
    　　功能需求（functional requirement）规 定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。
    　　系统需求（system requirement）用于描述包含多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。
    　　业务规则包 括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁 能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能 需求进行追溯时，会发现其来源正是一条特定的业务规则。
    　　功能需求记 录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电 子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。
    　　除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。
    　　质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。
    　　约束（constraint）限制了开发人员设计和构建系统时的选择范围。
    　　产品特性。所谓特性（feature）， 是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求， 也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多 项功能需求，以便用户能够执行某项任务。
    　　还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。
    　 　管理人员或市场营销人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须 符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围 内实现必需的功能，并达到规定的质量和性能指标。
    　　当一项新的特性、用例或功能需求被提出时，需 求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须 由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。

    不属于需求的内容
    　　需求规格说明中不包括（除已知约束 外的）设计和实现的细节、项目的计划信息，以及测试信息（Leffingwell 和 Widrig 2000）。把这些内容与需求分开，就可以把需求活动的注意力集中到了解开发小组需要开发的产品特性上。项目中通常还包括其他类型的需求，如开发环境需 求，进度或预算限制，帮助新用户跟上进度的培训需求，或者发布产品使其转入支持环境的需求。这些都属于项目需求而不是产品需求，因此不属于软件需求的讨论范围。

    查看(523) 评论(1) 收藏 分享 管理

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

    2007-01-29 23:35:23

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

    作者：黄以宽　来源：中国系统分析员　http://www.csai.cn  2003年07月15日

    　　

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

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

    　 　所谓软件产品设计，在本文中指对软件产品的功能与架构进行设计。用传统的软件工程术语来说，它覆盖软件工程的可行性研究、需求分析、系统设计几个阶段。 用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人员，根据实际需求定义系统的技术参数和应用模式。经过系统配置后，系统不再是有着各种技术和应用可行性的"中间系统"，而成为真正面向最终用户的产品。

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

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

    查看(564) 评论(0) 收藏 分享 管理

  • [论坛] [转贴]vsftpd.conf中文说明文档

    2007-01-09 21:56:07

    转载，出处：http://blog.sina.com.cn/u/48dd4b84010002pv
    名称
     
    vsftpd.conf - vsftpd 的配置文件  
     
    描述

    vsftpd.conf 可以用于控制 vsftpd, 以实现各种各样的功能. vsftpd 缺省到 /etc/vsftpd.conf 处查找此文件. 当然, 您也可以通过命令行参数进行指定. 这个命令行参数就是指 vsftpd 的配置文件. 对于想使用高级 inetd 管理的用户, 例如, xinetd, 则这个功能非常有用. 可以使用不同的配置文件来启动基于虚拟主机的每个服务.
     
    格式

    vsftpd.conf 的格式非常简单. 每行要么是注释, 要么是指令. 注释行以 # 开始, 将被忽略. 指令行格式如下: 选项=值
    应当注意的一点是如果在 选项, = 和 值 之间存在空格, 将会报错.(译者注: 即三者之间不允许存在空格)每项设定都有默认值, 这可以通过配置文件来修改.
     
    布尔选项
    下边是布尔选项的列表. 一个布尔选项的值可以被设为 YES 或 NO
     
    allow_anon_ssl
    只有在 ssl_enable 被激活时才有用. 如果设为 YES, 匿名用户将被允许使用安全的 SSL 联接.
    默认: NO
     
    anon_mkdir_write_enable
    如果设为 YES, 匿名用户将允许在某些情况下创建目录. 这需要激活 write_enable 选项, 并且匿名 ftp 用户需要对父目录有写权限.
    默认: NO
     
    anon_other_write_enable
    如果设为 YES, 匿名用户将拥有除 上载, 和创建目录 外更多的权限, 比如 删除和重命名. 通常不建议这么做, 但完整的配置文件是包括这一选项的.
    默认: NO
     
    anon_upload_enable
    如果设为 YES, 匿名用户在某些情况下允许上载文件. 这需要将 write_enable 选项激活, 并且匿名用户应当对对应目录有写权限.
    默认: NO
    anon_world_readable_only
    启用时, 将只允许匿名用户下载具有全球读权限的文件. 这将意味着 ftp 用户可以拥有自己的文件, 特别是前边提到的上载的文件.
    默认: YES
     
    anonymous_enable
    用于控制是否允许匿名用户登录. 如果激活, ftp 和 anonymous 都将被视为匿名用户登录.
    默认: YES
     
    ascii_download_enable
    如果被激活, 下载时将使用 ASCII 模式进行数据传输.
    默认: NO
     
    ascii_upload_enable
    如果被激活, 上载时将使用 ASCII 模式进行数据传输.
    默认: NO
     
    async_abor_enable
    如果被激活, 一个特别的 FTP 命令 "async ABOR" 将被激活. 只有某些 FTP 客户端需要使用这一特性. 另外, 这个特性并不是很好控制, 因此默认没有启用. 不幸的是, 如果没有启用这个特性, 某些 FTP 客户端在取消一个传输时就会挂起, 因此, 您可能希望启用它.
    默认: NO
     
    background
    如果被激活, 并且 vsftpd 以 "listen" 模式启动, vsftpd 将会background 监听进程. 即 control will immediately be returned to the shell which launched vsftpd.
    默认: NO
     
    check_shell
    注意! 这个选项只对构建时加入 non-PAM 参数的 vsftpd 有效. 如果令其失效, vsftpd 将不会检查有效用户的用于本地登录的 /etc/shells.
    默认: YES
     
    chmod_enable
    如果被激活, 将允许使用 SITE CHMOD 命令. 注意! 这只对本地用户有效. 匿名用户从不允许使用 SITE CHMOD.
    默认: YES
     
    chown_uploads
    如果被激活, 所有匿名上载的文件的宿主将会调整为 chown_username 中指定的用户. 这样就便于管理, 特别是从安全的角度考虑.
    默认: NO
     
    chroot_list_enable
    如果被激活, 您需要提供一个需要将其限制于其家目录中的本地用户列表. 如果将 chroot_local_user 设为 YES 则意义稍有不同. 在此情况下, 此列表变成不需将用户限制于其家目录的用户的列表. 默认情况下,这个列表文件是 /etc/vsftpd.chroot_list, 但可以通过 chroot_list_file 选项来设定.
    默认: NO
     
    chroot_local_user
    如果设为 YES, 本地用户, 在登录后将(默认)被限制在其家目录中. 警告: 此选项有安全隐患, 特别是在用户拥有上载权限, 或可以shell访问的时候. 如果您不清楚后果, 请不要启用它. 注意, 这些安全隐患并不是 vsftpd 所特有的. 所有的提供将本地用户进行目录限制的 FTP 守护进程有存在这种隐患.
    默认: NO
     
    connect_from_port_20
    用于控制在服务器端, 是否使用端口20(ftp-data)进行数据联接. 基于安全的考虑, 有些客户端需要这样做. 相反, 禁用这个选项, 可以使 vsftpd 以较少特权运行.
    默认: NO(但是在示例设置中启用了这个选项)
     
    deny_email_enable
    如果激活, 您应当提供一个禁止匿名用户用做密码的 e-mail 地址列表. 默认情况下, 这个列表文件为 /etc/vsftpd.banned_emails, 当然, 您可以通过 banned_email_file 选项指定.
    默认: NO
     
    dirlist_enable
    如果设为 NO, 所有的目录列取命令都将被禁止.
    默认: YES
     
    dirmessage_enable
    如果启用, 当用户首次进入一个新目录时, FTP 服务器将会显示欢迎信息. 默认情况下, 是扫描目录下的 .message 文件获取的, 当然, 您也可以通过 message_file 选项设定.
    默认: NO(但是在示例设置中启用了这个选项)
     
    download_enable
    如果设为 NO, 所有的下载请求都将被拒绝.
    默认: YES
     
    dual_log_enable
    如果启用, 将生成两个相似的日志文件, 默认在 /var/log/xferlog 和 /var/log/vsftpd.log 目录下. 前者是 wu-ftpd 类型的传输日志, 可以用于 标准工具分析. 后者是 vsftpd 自己类型的日志.
    默认: NO
     
    force_dot_files
    如果激活, 以 . 开始的文件和目录在目录列取的时候将会被显示, 即使客户端没有使用 "a" 标识. 这不包括 "." 和 ".." 目录
    默认: NO
     
    force_local_data_ssl
    只有在 ssl_enable 被激活时才能使用. 如果被激活, 则所有的 非匿名用户 登录时都被强制使用安全 SSL 联接来传送接收数据.
    默认: YES
     
    force_local_logins_ssl
    只有在 ssl_enable 被激活时才能使用. 如果被激活, 则所有的 非匿名用户 登录时都被强制使用安全 SSL 联接来传送密码.
    默认: YES
     
    guest_enable
    如果启用, 所有非匿名用户都将以 "guest" 身份登录. guest 通过 guest_username 设定, 来映射到一个指定用户.
    默认: NO
     
    hide_ids
    如果启用, 所有目录中的用户和组信息列取时都将显示为 "ftp".
    默认: NO
     
    listen
    如果启用, vsftpd 将以独立模式运行. 这就意味着 vsftpd 不能由类 inetd 来启动. vsftpd 应当直接执行. 由 vsftpd 自身监听和处理联接请求.
    默认: NO
     
    listen_ipv6
    如 listen 参数, 所不同的是, vsftpd 将对 IPv6 接口进行监听, 而不是 IPv4 接口. 此参数 和 listen 参数相互独立.
    默认: NO
     
    local_enable
    用于控制是否允许本地登录. 如果启用, /etc/passwd 中的普通帐号即可用于登录.
    默认: NO
     
    log_ftp_protocol
    如果启用, 假若选项 xferlog_std_format 没有启用, 所有的 FTP 请求和应答都会被记录. 此选项对将对调试很有用.
    默认: NO
     
    ls_recurse_enable
    如果启用, 此设置将允许用户使用 "ls -R". 这有点安全威胁, 因为在大型站点的根目录下进行 ls -R 将会消耗很多资源.
    默认 : NO
     
    no_anon_password
    如果启用, 匿名用户登录将不再需要密码 - 可以直接登录.
    默认: NO
     
    no_log_lock
    如果启用, 在写日志文件时, 将会阻止 vsftpd 使用文件锁定. 这个选项通常不会启用. 它的存在是为了处理操作系统的一个bug, 如 Solaris / Veritas 文件系统组合某些情况下试图锁定日志文件的现象.
    默认: NO
     
    one_process_model
    如果你使用 Linux 2.4 内核, 您就可以使用一个不同的安全模式, 它只允许每个联接使用一个进程. 这有一点小小的安全问题, 但是提高了性能. 如果您不清楚后果, 或者您的站点要承受大量的并发用户联接时, 请不要启用此选项.
    默认: NO
     
    passwd_chroot_enable
    如果启用, 同 chroot_local_user 一起使用, 就会基于每个用户创建限制目录, 每个用户限制的目录源于 /etc/passwd 中的家目录. 当家目录路径中包含 /./ 时, enotes that the jail is at that particular location in the path. pasv_enable
    如果数据传输时, 您不允许使用 PASV 模式, 则将此选项设为 NO
    默认: YES
     
    pasv_promiscuous
    如果您要禁用 PASV 安全检查, 将此选项设置为 YES. 该检查用于确保数据传输联接与控制联接源于同一 IP 地址. 如果不清楚后果, 请不要启用此选项! 此选项只有在某些使用安全隧道的方案中才能正常使用, 或者需要 FXP 的支持.
    默认: NO
     
    port_enable
    如果您不允许使用端口模式获取数据联接, 将此选项设置为 NO.
    默认: YES
     
    port_promiscuous
    如果您想禁用端口安全检查, 将此选项设置为 YES. 此检查用于确认出站的数据只流向客户端. 搞清楚后果前,不要启用此选项!
    默认: NO
     
    run_as_launching_user
    如果您希望可以由用户来启动 vsftpd, 将此选项设置为 YES. 当不能使用root登录时, 这通常很有用. 严重警告: 搞清楚后果前,不要启用此选项, 随意的启用此选项将会导致非常严重的安全问题. 特别是 vsftpd 没有/不能使用目录限制技术来限制文件访问时(甚至vsftpd是由root启动的). 一个愚蠢的替代方法是将选项 deny_file 设为 {/*,*..*}, 但是其可靠性并不能和限制目录相比, 甚至不在一个等级上. 如果启用此选项, 应当限制其它选项的使用. 例如, 非匿名登录, 上载文件宿主转换, 使用源自端口20的联接和低于 1024 的端口不会工作. 其它一些选项也可能受到影响.
    默认值: NO
     
    secure_email_list_enable
    如果您要为匿名用户指定一个做为密码的邮件地址列表, 将此选项设置为 YES. 在不需要创建虚拟用户的情况下, 构建一个低安全性访问控制很有用. 如果启用, 匿名用户只有使用在 email_password_file 中指定的邮件地址做为密码, 才能登录. 文件格式是每行一个密码, 没有空格. 默认文件名是 /etc/vsftpd.email_passwords.
    默认: NO
     
    session_support
    此选项用于控制 vsftpd 是否为登录保持会话. 如果保持会话, vsftpd 将会尝试和更新 utmp 和 wtmp. 如果使用 PAM 认证, 同时还会打开 pam_session, 直至登出. 如果不需要保持登录会话, 或许您希望禁用此选项, 以使得 vsftpd 占用更少的进程和/或更少的特权. 注意 - utmp 和 wtmp 只有在启用 PAM 的情况下才支持.
    默认: NO
     
    setproctitle_enable
    如果启用, vsftpd 将会尝试在系统进程列表中显示会话状态信息. 也就是说, 进程报告将会显示每个 vsftpd会话在做什么 (闲置, 下载 等等). 出于安全的考虑, 您可能需要将其关闭.
    默认: NO
     
    ssl_enable
    如果启用此选项, 并在编译时加入 OpenSSL 支持, vsftpd 将支持通过 SSL 进行安全联接. 此选项用于控制联接(包括登录) 以及数据联接. 您可能同时需要支持SSL的客户端. 注意!! 小心启用此选项. 仅在需要时才启用. vsftpd 对使用 OpenSSL 库的安全性不做任何担保. 启用此选项, 就意味着您相信所安装的 OpenSSL 库的安全性.
    默认: NO
     
    ssl_sslv2
    只有激活 ssl_enable 选项时才有效. 如果启用, 此选项将允许使用 SSL v2 协议进行联接. TLS v1 仍为首选联接.
    默认: NO
     
    ssl_sslv3
    只有激活 ssl_enable 选项时才有效. 如果启用, 此选项将允许使用 SSL v3 协议进行联接. TLS v1 仍为首选联接.
    默认: NO
     
    ssl_tlsv1
    只有激活 ssl_enable 选项时才有效. 如果启用, 此选项将允许使用 TLS v1 协议进行联接. TLS v1 仍为首选联接.
    默认: YES
     
    syslog_enable
    如果启用, 任何本来应该输出到 /var/log/vsftpd/vsftpd.log 的日志, 将会输出到系统日志中. 记录由 FTPD 完成.
    默认: NO
     
    tcp_wrappers
    如果启用, 并且在编译 vsftpd 时加入了对 TCP_Wrappers 的支持, 则连入请求转由 TCP_Wrappers 完成访问控制. 另外, 这是基于每个IP的配置机制. 如果 tcp_wrappers 设置了 VSFTPD_LOAD_CONF 环境变量, 则 vsftpd 会话将会试图加载在此变量中指定的 vsftpd 配置文件.
    默认: NO
     
    text_userdb_names
    默认情况下, 目录列取时在用户和组字段显示的是数字ID. 如果启用此选项,则可以得到文本名称. 基于性能的考虑, 默认情况下关闭此选项.
    默认: NO
     
    tilde_user_enable
    如果启用, vsftpd 将试图解析类似 ~chris/pics 的路径名, 即跟着用户名的波型号. 注意, vsftpd 有时会一直解析 ~ 和 ~/ (这里, ~ 被解析称为初始登录路径). ~user 则只有在可以找到包含闲置目录的 /etc/passwd 文件时才被解析.
    默认值: NO
     
    use_localtime
    如果启用, vsftpd 在列取目录时, 将显示您本地时区的时间. 默认显示为 GMT. 由 MDTM FTP 命令返回的时间同样也受此选项的影响.
    默认: NO
     
    use_sendfile
    一个内部设定，用于测试在您的平台上使用 sendfile() 系统的性能.
    默认: YES
     
    userlist_deny
    此选项只有在激活 userlist_enable 时才会有效. 如果您将此选项设置为 NO, 则只有在 userlist_file 文件中明确指定的用户才能登录系统. 当登录被拒绝时, 拒绝发生在被寻问命令之前.
    默认: YES
     
    userlist_enable
    如果启用, vsftpd 将会从 userlist_file 选项指定的文件中加载一个用户名列表. 如果用户试图使用列表中指定的名称登录, 那么他们将在寻问密码前被拒绝. 这有助于阻止明文传送密码. 详见 userlist_deny.
    默认: NO
     
    virtual_use_local_privs
    如果启用, 虚拟用户将拥有同本地用户一样的权限. 默认情况下, 虚拟用户同匿名用户权限相同, 这倾向于更多限制 (特别是在写权限上).
    默认: NO
     
    write_enable
    用于控制是否允许 FTP 命令更改文件系统. 这些命令是: STOR, DELE, RNFR, RNTO, MKD, RMD, APPE 和 SITE.
    默认: NO
     
    xferlog_enable
    如果启用, 将会维护一个日志文件, 用于详细记录上载和下载. 默认情况下, 这个日志文件是 /var/log/vsftpd.log. 但是也可以通过配置文件中的 vsftpd_log_file 选项来指定.
    默认: NO(但是在示例设置中启用了这个选项)
     
    xferlog_std_format
    如果启用, 传输日志文件将以标准 xferlog 的格式书写, 如同 wu-ftpd 一样. 这可以用于重新使用传输统计生成器. 然而, 默认格式更注重可读性. 此格式的日志文件默认为 /var/log/xferlog, 但是您也可以通过 xferlog_file 选项来设定.
    默认: NO
     
    数字选项
    下边是数字选项的列表. 数字选项必须设置一个非负的整数. 为了便于umask选项, 同样也支持八进制数字. 八进制数字首位应为 0 .
     
    accept_timeout
    超时, 以秒计, 用于远程客户端以 PASV 模式建立数据联接.
    默认: 60
     
    anon_max_rate
    允许的最大数据传输速率, 单位 b/s, 用于匿名客户端.
    默认: 0 (无限制)
    anon_umask
    用于设定匿名用户建立文件时的 umask 值. 注意! 如果您要指定一个八进制的数字, 首位应当是 "0", 否则将视作 10 进制数字.
    默认: 077
     
    connect_timeout
    超时, 单位 秒, 用于响应 PORT 方式的数据联接.
    默认: 60
     
    data_connection_timeout
    超时, 单位 秒, 用于设定空闲的数据连接所允许的最大时长. 如果触发超时, 则远程客户端将被断开.
    默认: 300
     
    file_open_mode
    用于设定创建上载文件的权限. mask 的优先级高于这个设定. 如果想允许上载的文件可以执行, 将此值修改为 0777
    默认: 0666
     
    ftp_data_port
    FTP PORT 方式的数据联接端口.(需要激活 connect_from_port_20 选项)
    默认: 20
     
    idle_session_timeout
    超时, 单位 秒, 远程客户端的最大 FTP 命令间隔. 如果超时被触发, 远程客户端将被断开.
    默认: 300
     
    listen_port
    如果 vsftpd 以独立模式启动, 此端口将会监听 FTP 连入请求.
    默认: 21
     
    local_max_rate
    允许的最大数据传输速率, 单位 b/s, 用于限制本地授权用户.
    默认: 0 (无限制)
     
    local_umask
    用于设定本地用户上载文件的 umask 值. 注意! 如果您要指定一个八进制的数字, 首位应当是 "0", 否则将视作 10 进制数字.
    默认: 077
     
    max_c lients
    如果 vsftpd 以独立模式启动, 此选项用于设定最大客户端联接数. 超过部分将获得错误信息.
    默认: 0 (无限制)
     
    max_per_ip
    如果 vsftpd 以独立模式启动, 此选项用于设定源于同一网络地址的最大联接数. 超过部分将获得错误信息.
    默认: 0 (无限制)
     
    pasv_max_port
    为 PASV 方式数据联接指派的最大端口. 基于安全性考虑, 可以把端口范围指定在一样较小的范围内.
    默认: 0 (可以使用任意端口)
     
    pasv_min_port
    为 PASV 方式数据联接指派的最小端口. 基于安全性考虑, 可以把端口范围指定在一样较小的范围内.
    默认: 0 (可以使用任意端口)
     
    trans_chunk_size
    您可能不想修改这个设置, 如果有带宽限制, 可以尝试将此值设置为 8192.
    默认: 0 (让vsftpd 自己选择一个更合理的设置)
     
    字符选项，下边是字符选项列表
     
    anon_root
    此选项声明, 匿名用户在登录后将被转向一个指定目录(译者注: 默认根目录). 失败时将被忽略.
    默认: (无)
     
    banned_email_file
    此选项用于指定包含不允许用作匿名用户登录密码的电子邮件地址列表的文件. 使用此选项需要启用 deny_email_enable 选项.
    默认: /etc/vsftpd.banned_emails
     
    banner_file
    此选项用于指定包含用户登录时显示欢迎标识的文件. 设置此选项, 将取代 ftpd_banner 选项指定的欢迎标识.
    默认: (无)
     
    chown_username
    用于指定匿名用户上载文件的宿主. 此选项只有在 chown_uploads 选项设定后才会有效.
    默认；root
     
    chroot_list_file
    此选项用于指定包含被限制在家目录中用户列表的文件. 使用此选项, 需启用 chroot_list_enable . 如果启用了 chroot_local_user 选项, 此文件所包含的则为不会被限制在家目录中的用户列表.
    默认: /etc/vsftpd.chroot_list
     
    cmds_allowed
    此选项指定允许使用的 FTP 命令(登录以后. 以及登录前的USER, PASS 和 QUIT), 以 逗号分割. 其它命令将被拒绝使用. 这对于锁定一个 FTP 服务器非常有效. 例如: mds_allowed=PASV,RETR,QUIT
    默认: (无)
     
    deny_file
    此选项用于设定拒绝访问的文件类型(和目录名等). 此设定并不是对文件进行隐藏, 但是您不能对其操作(下载, 更换目录, 以及其它操作). 此选项非常简单, 不能用于严格的访问控制--文件系统的优先级要高一些. 然而, 此选项对于某些虚拟用户的设定非常有效. 特别是在一个文件可以通过各种名称访问时(可能时通过符号联接或者硬联接), 应当注意拒绝所有的访问方法. 与 hide_file 中给出名称匹配的文件会被拒绝访问. 注意 vsftpd 只支持正则表达式匹配的部分功能. 正因为如此, 您需要尽可能的对此选项的设置进行测试. 同时基于安全性考虑, 建议您使用文件系统自身的访问控制. 例如: deny_file={*.mp3,*.mov,.private}
    默认: (无)
     
    dsa_cert_file
    此选项用于指定用于 SSL 加密联接的 DSA 证书的位置.
    默认: (无 - 使用 RSA 证书)
     
    email_password_file
    此选项用于提供启用 secure_email_list_enable 选项, 所需要的可替代文件.
    默认: /etc/vsftpd.email_passwords
     
    ftp_username
    用于处理匿名 FTP 的用户名. 此用的家目录即为匿名发 FTP 的根目录.
    默认: ftp
     
    ftpd_banner
    用于替换首次连入 vsftpd 时显示的欢迎标识字符串.
    默认: (无 - 显示默认 vsftpd 标识)
     
    guest_username
    参阅布尔选项 guest_enable . 此选项用于将 guest 用户映射到一个真实用户上.
    默认: ftp
     
    hide_file
    此选项用于设定列取目录时, 要隐藏的文件类型(以及目录等). 尽管隐藏了, 知道其宿主的客户端仍然能对文件/目录等有完全访问权限. 与名称 hide_file 中包含的字符串匹配的项都将隐藏. 注意 vsftpd 只支持正则表达式匹配的部分功能. 例如: hide_file={*.mp3,.hidden,hide*,h?}
    默认: (无)
     
    listen_address
    如果 vsftpd 以独立模式运行, 此设定用于修改默认(所有本地接口)监听地址. 格式为数字 IP 地址.
    默认: (无)
     
    listen_address6
    如 listen_address, 不过应该指定为IPv6 监听器指定默认监听地址. 格式为标准 IPv6 地址格式.
    默认: (无)
     
    local_root
    本选项用于指定本地用户(即, 非匿名用户)登录后将会转向的目录. 失败时将被忽略.
    默认: (无)
     
    message_file
    此选项用于指定进入新目录时要查询的文件名. 这个文件的内容为显示给远程用户的欢迎信息. 使用此选项, 需要启用 dirmessage_enable 选项.
    默认: .message
     
    nopriv_user
    用于指定一个用户, 当 vsftpd 要切换到无权限状态时, 使用此用户. 注意这最好是一个专用用户, 而不是用户 nobody. 在大多数机器上, 用户 nobody 被用于大量重要的事情.
    默认: nobody
     
    pam_service_name
    用于指定 PAM 服务的名称.
    默认: ftp
     
    pasv_address
    此选项为 vsftpd 指定一个 IP 地址, 用作对 PASV 命令的响应. IP 地址应该为数字模式.
    默认: (无 - 即地址从连入的联接套接字中获取)
     
    rsa_cert_file
    此选项用于指定 SSL 加密联接所用 RSA 证书的位置.
    默认: /usr/share/ssl/certs/vsftpd.pem
     
    secure_chroot_dir
    此选项用于指定一个空目录. 并且 ftp 用户不应对此目录有写权限. 当 vsftpd 不需要访问文件系统是, 此此目录做为一个限制目录, 将用户限制在此目录中.
    默认: /usr/share/empty
     
    ssl_ciphers
    此选项用于选择 vsftpd 允许使用哪些 SSL 加密算法来用于 SSL 加密联接. 更多信息参阅 ciphers 的联机手册. 注意这样可以有效的防止对某些发现漏洞的算法进行恶意的远程攻击.
    默认: DES-CBC3-SHA
     
    user_config_dir
    此选项用于定义用户个人配置文件所在的目录. 使用非常简单, 一个例子即可说明. 如果您将 user_config_dir 设置为 /etc/vsftpd_user_conf 并以用户 "chris"登录, 那么 vsftpd 将对此用户使用文件 /etc/vsftpd_user_conf/chris 中的设定. 此文件的格式在联机手册中有详细说明. 请注意, 不是每个设定都能影响用户的. 例如, 有些设定只在用户会话开始时起作用. 这包括 listen_address, banner_file, max_per_ip, max_clients, xferlog_file, 等等.
    默认: (无)
     
    user_sub_token
    此选项需要和虚拟用户联合使用. 其将依据一个模板为每个虚拟用户创建家目录. 例如, 如果真实用户的家目录由选项 guest_username 指定为 /home/virtual/$USER, 并且将 user_sub_token 设定为 $USER, 当虚拟用户 fred 登入后, 将会进入(限制)目录 /home/virtual/fred. 如果 local_root 中包含了 user_sub_token 此选项也会起作用.
    默认: (无)
     
    userlist_file
    此选项用于指定启用 userlist_enable 选项后需要加载文件的名称.
    默认: /etc/vsftpd.user_list
     
    vsftpd_log_file
    此选项用于指定写入 vsftpd 格式日志的文件. 如果启用了 xferlog_enable, 而没有设定 xferlog_std_format 的话, 日志将只会写入此文件. 另为,如果设置了 dual_log_enable 的话, 日志同样会写入此文件. 更复杂一点, 如果您设置了 syslog_enable 的话, 输出将不会写入此文件, 而是写入系统日志文件.
    默认: /var/log/vsftpd.log
     
    xferlog_file
    此选项用于指定写入 wu-ftpd 样式日志的文件名. 只有在 xferlog_enable 和 xferlog_std_format 做了相应设定, 才会记录此传输日志. 另外, 如果您设置了 dual_log_enable 选项, 也会记录此日志.
    默认: /var/log/xferlog
     

    查看(511) 评论(1) 收藏 分享 管理

  • [转贴]软件工程介绍

    2007-01-07 10:46:27

    软件工程

    中科永联高级技术培训中心（www.itisedu.com）

          软件工程(Software Engineering，简称为SE)是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。它涉及到程序设计语言，数据库，软件开发工具，系统平台，标准，设计模式等方面。

          在现代社会中，软件应用于多个方面。典型的软件比如有电子邮件，嵌入式系统，人机界面，办公套件，操作系统，编译器，数据库，游戏等。同时，各个行业几乎都有计算机软件的应用，比如工业，农业，银行，航空，政府部门等。这些应用促进了经济和社会的发展，使得人们的工作更加高效，同时提高了生活质量。

          软件工程师是对应用软件创造软件的人们的统称，软件工程师按照所处的领域不同可以分为系统分析员，软件设计师，系统架构师，程序员，测试员等等。人们也常常用程序员来泛指各种软件工程师。

         软件工程(SoftWare Engineering)的框架可概括为：目标、过程和原则。

         (1)软件工程目标：生产具有正确性、可用性以及开销合宜的产品。正确性指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用的程 度。开销合宜是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多待解决的问题，它们形成了对过程、过程 模型及工程方法选取的约束。

         (2)软件工程过程：生产一个最终能满足需求且达到工程目标的软件产品所需要的步骤。软件工程过程主要包括开发过程、运作过程、维护过程。它们覆盖了需求、设计、实现、确认以及维护等活动。需求活动包括问题分析和需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件系统结构，包括子系统、 模块以及相关层次的说明、每一模块的接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果转换为可执 行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。维护活动包括使用过程中的扩充、修改与完善。伴随以上过程， 还有管理过程、支持过程、培训过程等。

          (3)软件工程的原则是指围绕工程设计、工程支持以及工程管理在软件开发过程中必须遵循的原则。

    一、软件工程概述

          概念：应需而生

    　　软件工程是一类工程。工程是将理论和知识应用于实践的科学。就软件工程而言，它借鉴了传统工程的原则和方法，以求高效地开发高质量软件。其中应用了计算机科学、数学和管理科学。计算机科学和数学用于构造模型与算法，工程科学用于制定规范、设计范型、评估成本及确定权衡，管理科学用于计划、资源、质量和成本的管理。

          软件工程这一概念，主要是针对20世纪60年代“软件危机”而提出的。它首次出现在1968年NATO（北大西洋公约组织）会议上。自这一概念提出以来，围绕软件项目，开展了有关开发模型、方法以及支持工具的研究。其主要成果有：提出了瀑布模型，开发了一些结构化程序设计语言（例如PASCAL语言，Ada语言）、结构化方法等。并且围绕项目管理提出了费用估算、文档复审等方法和工具。综观60年代末至80年代初，其主要特征是，前期着重研究系统实现技术，后期开始强调开发管理和软件质量。

          70年代初，自“软件工厂”这一概念提出以来，主要围绕软件过程以及软件复用，开展了有关软件生产技术和软件生产管理的研究与实践。其主要成果有：提出了应用广泛的面向对象语言以及相关的面向对象方法，大力开展了计算机辅助软件工程的研究与实践。尤其是近几年来，针对软件复用及软件生产，软件构件技术以及软件质量控制技术、质量保证技术得到了广泛的应用。目前各个软件企业都十分重视资质认证，并想通过这些工作进行企业管理和技术的提升。软件工程所涉及的要素可概括如下：

          根据这一框架，可以看出：软件工程涉及了软件工程的目标、软件工程原则和软件工程活动。

          目标：我的眼里只有“产品”

          软件工程的主要目标是：生产具有正确性、可用性以及开销合宜的产品。正确性意指软件产品达到预期功能的程度。可用性指软件基本结构、实现及文档为用户可用 的程度。开销合宜性是指软件开发、运行的整个开销满足用户要求的程度。这些目标的实现不论在理论上还是在实践中均存在很多问题有待解决，它们形成了对过 程、过程模型及工程方法选取的约束。

          软件工程活动是“生产一个最终满足需求且达到工程目标的软件产品所需要的步骤”。主要包括需求、设计、实现、确认以及支持等活动。需求活动包括问题分析和 需求分析。问题分析获取需求定义，又称软件需求规约。需求分析生成功能规约。设计活动一般包括概要设计和详细设计。概要设计建立整个软件体系结构， 包括子系统、模块以及相关层次的说明、每一模块接口定义。详细设计产生程序员可用的模块说明，包括每一模块中数据结构说明及加工描述。实现活动把设计结果 转换为可执行的程序代码。确认活动贯穿于整个开发过程，实现完成后的确认，保证最终产品满足用户的要求。支持活动包括修改和完善。伴随以上活动，还有管理 过程、支持过程、培训过程等。

          框架：四项基本原则是基石

    　　软件工程围绕工程设计、工程支持以及工程管理，提出了以下四项基本原则：

          第一，选取适宜开发范型。该原则与系统设计有关。在系统设计中，软件需求、硬件需求以及其他因素之间是相互制约、相互影响的，经常需要权衡。因此，必须认识需求定义的易变性，采用适宜的开发范型予以控制，以保证软件产品满足用户的要求。

          第二，采用合适的设计方法。在软件设计中，通常要考虑软件的模块化、抽象与信息隐蔽、局部化、一致性以及适应性等特征。合适的设计方法有助于这些特征的实现，以达到软件工程的目标。

          第三，提供高质量的工程支持。“工欲善其事，必先利其器”。在软件工程中，软件工具与环境对软件过程的支持颇为重要。软件工程项目的质量与开销直接取决于对软件工程所提供的支撑质量和效用。

          第四，重视开发过程的管理。软件工程的管理，直接影响可用资源的有效利用，生产满足目标的软件产品，提高软件组织的生产能力等问题。因此，仅当软件过程得以有效管理时，才能实现有效的软件工程。

          这一软件工程框架告诉我们，软件工程的目标是可用性、正确性和合算性；实施一个软件工程要选取适宜的开发范型，要采用合适的设计方法，要提供高质量的工程 支撑，要实行开发过程的有效管理；软件工程活动主要包括需求、设计、实现、确认和支持等活动，每一活动可根据特定的软件工程，采用合适的开发范型、设计方 法、支持过程以及过程管理。根据软件工程这一框架，软件工程学科的研究内容主要包括：软件开发范型、软件开发方法、软件过程、软件工具、软件开发环境、计算机辅助软件工程(CASE) 及软件经济学等。

          作用：高效开发高质量软件

    　　自从软件工程概念提出以来，经过30多年的研究与实践,虽然“软件危机”没得到彻底解决，但在软件 开发方法和技术方面已经有了很大的进步。尤其应该指出的是，自80年代中期，美国工业界和政府部门开始认识到，在软件开发中，最关键的问题是软件开发组织 不能很好地定义和管理其软件过程，从而使一些好的开发方法和技术都起不到所期望的作用。也就是说，在没有很好定义和管理软件过程的软件开发中，开发组织不 可能在好的软件方法和工具中获益。

          根据调查，中国的现状几乎和美国10多年前的情况一样，软件开发过程没有明确规定，文档不完整，也不规范，软件项目的成功往往归功于软件开发组的一些杰出 个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础，只有通过建立全组织的过程改善，采用严格的软件工 程方法和管理，并且坚持不懈地付诸实践，才能取得全组织的软件过程能力的不断提高。

          这一事实告诉我们，只有坚持软件工程的四条基本原则，既重视软件技术的应用，又重视软件工程的支持和管理，并在实践中贯彻实施，才能高效地开发出高质量的软件。

    二、软件工程的七条基本原理

          自从1968年提出“软件工程”这一术语以来，研究软件工程的专家学者们陆续 提出了100多条关于软件工程的准则或信条。 美国著名的软件工程专家 Boehm 综合这些专家的意见，并总结了TRW公司多年的开发软件的经验，于1983年提出了软件工程的七条基本原理。

    　　Boehm 认为，着七条原理是确保软件产品质量和开发效率的原理的最小集合。
    　　它们是相互独立的，是缺一不可的最小集合；同时，它们又是相当完备的。

    　　人们当然不能用数学方法严格证明它们是一个完备的集合，但是可以证明，在此之前已经提出的100多条软件工程准则都可以有这七条原理的任意组合蕴含或派生。

    　　下面简要介绍软件工程的七条原理：

    　　1 用分阶段的生命周期计划严格管理
    　　这一条是吸取前人的教训而提出来的。统计表明，50%以上的失败项目是由于计划不周而造成的。在软件开发与维护的漫长生命周期中，需要完成许多性质各异的工作。这条原理意味着，应该把软件生命周期分成若干阶段，并相应制定出切实可行的计划，然后严格按照计划对软件的开发和维护进行管理。 Boehm 认为，在整个软件生命周期中应指定并严格执行6类计划：项目概要计划、里程碑计划、项目控制计划、产品控制计划、验证计划、运行维护计划。

    　　2 坚持进行阶段评审
    　　统计结果显示： 大部分错误是在编码之前造成的，大约占63%; <2> 错误发现的越晚，改正它要付出的代价就越大，要差2到3个数量级。 因此，软件的质量保证工作不能等到编码结束之后再进行，应坚持进行严格的阶段评审，以便尽早发现错误。

    　　3 实行严格的产品控制
    　　开发人员最痛恨的事情之一就是改动需求。但是实践告诉我们，需求的改动往往是不可避免的。这就要求我们要采用科学的产品控制技术来顺应这种要求。也就是要采用变动控制，又叫基准配置管理。当需求变动时，其它各个阶段的文档或代码随之相应变动，以保证软件的一致性。

    　　4 采纳现代程序设计技术
    　　从六、七时年代的结构化软件开发技术，到最近的面向对象技术，从第一、第二代语言，到第四代语言，人们已经充分认识到：方法大似气力。采用先进的技术即可以提高软件开发的效率，又可以减少软件维护的成本。

    　　5 结果应能清楚地审查
    　　软件是一种看不见、摸不着的逻辑产品。软件开发小组的工作进展情况可见性差，难于评价和管理。为更好地进行管理，应根据软件开发的总目标及完成期限， 尽量明确地规定开发小组的责任和产品标准，从而使所得到的标准能清楚地审查。


    　　6 开发小组的人员应少而精
    　　开发人员的素质和数量是影响软件质量和开发效率的重要因素，应该少而精。
    　　这一条基于两点原因：高素质开发人员的效率比低素质开发人员的效率要高几倍到几十倍，开发工作中犯的错误也要少的多； 当开发小组为N人时，可能的通讯信道为N(N-1)/2, 可见随着人数N的增大，通讯开销将急剧增大。

    　　7 承认不断改进软件工程实践的必要性
    　　遵从上述六条基本原理，就能够较好地实现软件 的工程化生产。但是，它们只是对现有的经验的总结和归纳，并不能保证赶上技术不断前进发展的步伐。因此，Boehm提出应把承认不断改进软件工程实践的必 要性作为软件工程的第七条原理。根据这条原理，不仅要积极采纳新的软件开发技术，还要注意不断总结经验，收集进度和消耗等数据，进行出错类型和问题报告统计。这些数据既可以用来评估新的 软件技术的效果，也可以用来指明必须着重注意的问题和应该优先进行研究的工具和技术。

          面向方面的编程（Aspect Oriented Programming，简称AOP）被认为是近年来软件工程的另外一个重要发展。这里的方面指的是完成一个功能的对象和函数的集合。在这一方面相关的内容有泛型编程（Generic Programming）和模板。

    参考
          胡崑山，《中国软件产业发展现状与人才需求》，2003年9月1日，            http://software.ccidnet.com/pub/article/c372_a62973_p1.html

    三、软件工程的目标与常用模型

          软件工程的目标是提高软件的质量与生产率，最终实现软件的工业化生产。质量是软件需求方最关心的问题，用户即使不图物美价廉，也要求个货真价实。生产率是 软件供应方最关心的问题，老板和员工都想用更少的时间挣更多的钱。质量与生产率之间有着内在的联系，高生产率必须以质量合格为前提。如果质量不合格，对供 需双方都是坏事情。从短期效益看，追求高质量会延长软件开发时间并且增大费用，似乎降低了生产率。从长期效益看，高质量将保证软件开发的全过程更加规范流 畅，大大降低了软件的维护代价，实质上是提高了生产率，同时可获得很好的信誉。质量与生产率之间不存在根本的对立，好的软件工程方法可以同时提高质量与生 产率。

          软件供需双方的代表能在餐桌上谈笑风生，归功于第一线开发人员的辛勤工作。质量与生产率的提高就指望程序员与程序经理。对开发人员而言，如果非得在质量与 生产率之间分个主次不可，那么应该是质量第一，生产率第二。这是因为：（1）质量直接体现在软件的每段程序中，高质量自然是开发人员的技术追求，也是职业 道德的要求。（2）高质量对所有的用户都有价值，而高生产率只对开发方有意义。（3）如果一开始就追求高生产率，容易使人急功近利，留下隐患。宁可进度慢 些，也要保证每个环节的质量，以图长远利益。

          软件的质量因素很多，如正确性，性能、可靠性、容错性、易用性、灵活性、可扩充性、可理解性、可维护性等等。有些因素相互重叠，有些则相抵触，真要提高质量可不容易啊！

          软件工程的主要环节有：人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试、维护等，如图1.1所示。

          软件工程模型建议用一定的流程将各个环节连接起来，并可用规范的方式操作全过程，如同工厂的生产线。常见的软件工程模型有：线性模型（图1.2），渐增式 模型（图1.3），螺旋模型，快速原型模型，形式化描述模型等等 [Pressmam 1999, Sommerville 1992]。 


     

          最早出现的软件工程模型是线性模型（又称瀑布模型）。线性模型太理想化，太单纯，已不再适合现代的软件开发模式， 几乎被业界抛弃。偶而被人提起，都属于被贬对象，未被留一丝惋惜。但我们应该认识到，“线性”是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复 杂的“非线性”问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的， 可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例 如渐增式模型实质就是分段的线性模型，如图1.3所示。螺旋模型则是接连的弯曲了的线性模型。在其它模型中都能够找到线性模型的影子。

          套用固定的模型不是程序员的聪明之举。比如“程序设计”与“测试”之间的关系，习惯上总以为程序设计在先，测试在后，如图1.4（a）所示。而对于一些复杂的程序，将测试分为同步测试与总测试更有效，如图1.4（b）所示。


          不论是什么软件工程模型，总是少不了图1.1中的各个环节。本书擗开具体的软件工程模型，顺序讲述人员管理、项目管理、可行性与需求分析、系统设计、程序设计、测试，以及维护与再生工程。其中程序设计部分以C++/C语言为例。

    四、软件体系结构和工具的选择

    　　软件体系结构表示了一个软件系统的高层结构，主要特点有：1）软件系统结构是一个高层次上的抽象，它并不涉及具体的系统结构（比如B/S还是C/S）， 也不关心具体的实现。2）软件体系结构必须支持系统所要求的功能，在设计软件体系结构的时候，必须考虑系统的动态行为。3）在设计软件体系结构的时候，必 须考虑有现有系统的兼容性、安全性和可靠性。同时还要考虑系统以后的扩展性和伸缩性。所以有时候必须在多个不同方向的目标中进行决策。

    　　当前已经有一些关于规范化软件体系结构，比如：ISO的开放系统互联模型、X Window系统等等。软件系统的结构通常被定义为两个部分：一个是计算部件。另一个就是部件之间的交互。如果把软件系统看成一幅图的话，计算部件就是其 中的节点，而部件之间的交互就是节点之间的弧线。部件之间的连接可以被认为是一种连接器，比如过程调用、事件广播、数据库查询等等。正确的体系结构设计是 软件系统成功的关键。

    　　我们理解了软件工程的重要性以后，我们没有相应的工具，我们也很难很好的完成一个系统。在需求分析和设计阶段，我们需要什么样的工具呢？

    　　当然最好是基于UML的CASE工具。当前比较流行的就是Rose，它是一个很好的分析和建立对象和对象关系的工具。在具体编码的时候，我们需要版本控制工具，MS的SourceSafe就是一个很好的版本管理工具和项目管理工具。具体的开发工具当然很多，但是如果你是一个对VC侵淫了多年的程序员，你一定会选择它，因为它会让你感到什么是真正的面向对象的编程，而你在用VB，PowerBuilder，Delphi时很少会有同样的感受。至于数据库模式构建，我一向是采用Sybase的S-Design，更好的工具就不知道了。

    　　另外需要注意的是，我们需要建立文档编写的若干模板，以便开发人员按照这个模板编写规范的技术和说明文档。帮助文档可以用微软的HTML Help Workshop(hhw.exe)制作，你也可以编译成.chm格式，它打包了文本和图形，只有一个文件，使用和分发比较方便。最后，如果开发人员不是集中在一个地方的话，最好建立一个邮件列表，开发人员可以通过邮件系统讨论开发中的各项事宜。

    五、软件开发方法综述


    　　国外大的软件公司和机构一直在研究软件开发方法这个概念性的东西，而且也提出了很多实际的开发方法，比如：生命周期法、原型化方法、面向对象方法等等。下面介绍几种流行的开发方法：

    　　1、结构化方法

    　　结构化开发方法是由E.Yourdon 和 L.L.Constantine 提出的，即所谓的SASD 方 法， 也可称为面向功能的软件开发方法或面向数据流的软件开发方法。Yourdon方法是80年代 使用最广泛的软件开发方法。它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给 出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。

    　　2、面向数据结构的软件开发方法

    　　Jackson方法是最典型的面向数据结构的软件开发方法，Jackson方法把问题分解为可由三 种基本结构形式表示的各部分的层次结构。三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的 输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业 应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。

    　　3、 面向问题的分析法

    　　PAM（Problem Analysis Method）是80年代末由日立公司提出的一种软件开发方法。 它的基本思想是考虑到输入、输出数据结构，指导系统的分解，在系统分析指导下逐步综 合。这一方法的具体步骤是：从输入、输出数据结构导出基本处理框；分析这些处理框之间的先后关系；按先后关系逐步综合处理框，直到画出整个系统的PAD 图。这一方法本质上是综合的自底向上的方法，但在逐步综合之前已进行了有目的的分解，这个目的就是充分考虑系统的输入、输出数据结构。PAM方法的另一个 优点是使用PAD图。这是一种二维树形结构图，是到目前为止最好的详细设计表示方法之一。当然由于在输入、输出数据结构与整个系统之间同样存在着鸿沟，这 一方法仍只适用于中小型问题。

    　　4、原型化方法

    　　产生原型化方法的原因很多，主要随着我们系统开发经验的增多，我们也发现并非所有的需求都能够预先 定义而且反复修改是不可避免的。当然能够采用原型化方法是因为开发工具的快速发展，比如用VB，DELPHI等工具我们可以迅速的开发出一个可以让用户看 的见、摸的着的系统框架，这样，对于计算机不是很熟悉的用户就可以根据这个样板提出自己的需求。

    　　开发原型化系统一般由以下几个阶段：
    （1） 确定用户需求
    （2） 开发原始模型
    （3） 征求用户对初始原型的改进意见
    （4） 修改原型。

    　　原型化开发比较适合于用户需求不清、业务理论不确定、需求经常变化的情况。当系统规模不是很大也不太复杂时采用该方法是比较好的。

    　5、面向对象的软件开发方法

    　　当前计算机业界最流行的几个单词就是分布式、并行和面向对象这几个术语。由此可以看到面向对象这个概念在当前计算机业界的地位。比如当前流行的两大面向对象技术DCOM和CORBA就是例子。当然我们实际用到的还是面向对象的编程语言，比如C++。不可否认，面向对象技术是软件技术的一次革命，在软件开发史上具有里程碑的意义。

    　　随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法OMT (Object Modeling Technique）。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。所以OMT彻底实现了PAM没有完全实现的目标。不仅如此，OO技术在需求分析、可维护性和可靠性这三个软件开发的关键环节和质量指标上有了实质性的突破，基本地解决了在这些方面存在的严重问题。

    　　综上所述，面向对象系统采用了自底向上的归纳、自顶向下的分解的方法，它通过对对象模型的建立，能够真正建立基于用户的需求，而且系统的可维护性大大改善。当前业界关于面向对象建模的标准是UML（Unified Modeling Language）。

    　　这里我们需要谈一下微软的MSF（Microsoft Solutions Framework） 的框架，它简单的把系统设计分成三个阶段：概念设计、逻辑设计和物理设计。概念设计阶段就是从用户的角度出发可以得到多少个对象，并且以对象为主体，画出 业务框架。逻辑设计阶段就是对概念设计阶段的对象进行再分析、细分、整合、删除。并建立各个对象的方法属性以及对象之间的关系。而物理设计实际上就是要确 定我们实际需要的组件、服务和采用的框架结构、具体的编程语言等。MCF整个结构比较清楚是基于对象开发的一个比较好的可操作的框架系统。

    　　6、可视化开发方法

    　　其实可视化开发并不能单独的作为一种开发方法，更加贴切的说可以认为它是一种辅助工具，比如用过 SYBASE的S-Design的人都知道，用这个工具可以进行显示的图形化的数据库模式的建立，并可以导入到不同的数据库中去。当然用过S- Design的人不一定很多，但用过VB，DELPHI，C++ Builder等开发工具的人一定不少，实际上你就是在使用可视化开发工具。

    　　当然，不可否认的是，你只是在编程这个环节上用了可视化，而不是在系统分析和系统设计这个高层次上用了可视化的方法。实际上，建立系统分析和系统设计的可视化工具是一个很好的卖点，国外有很多工具都致力于这方面产品的设计。比如Business Object就是一个非常好的数据库可视化分析工具。

    　　可视化开发使我们把注意力集中在业务逻辑和业务流程上，用户界面可以用可视化工具方便的构成。通过操作界面元素，诸如菜单、按钮、对话框、编辑框、单选框、复选框、 列表框和滚动条等，由可视开发工具自动生成应用软件。

    六、怎样培养软件工程的思维与方法


    　　作为软件开发人员的一个通病是在项目初期的时候，就喜欢谈论实现的细节，并且乐此不疲。我们更喜欢讨论如何用灵活而简短的代码来实现一个特定的功能，而忽略了对整个系统架构的考虑。所以作为一个开发人员，尤其是一个有经验的开发人员，应该把自己从代码中解脱出来，更多的时候在我们的脑子里甚至暂时要放弃去考虑如何实现的问题，而从项目或产品的总体去考虑一个软件产品。

    　　以下是我个人的一些经验：

    　　1．考虑整个项目或者产品的市场前景。作为一个真正的系统分析人员，不仅要从技术的角度来考虑问 题，而且还要从市场的角度去考虑问题。也就是说我们同时需要考虑我们产品的用户群是谁，当我们产品投放到市场上的时候，是否具有生命力。比如即使我们采用 最好的技术实现了一个单进程的操作系统，其市场前景也一定是不容乐观的。

    　　2．从用户的角度来考虑问题。比如一些操作对于开发人员来讲是非常显而易见的问题。但是对于一般的 用户来说可能就非常难于掌握，也就是说，有时候，我们不得不在灵活性和易用性方面进行折中。另外，在功能实现上，我们也需要进行综合考虑，尽管一些功能十 分强大，但是如果用户几乎不怎么使用它的话，就不一定在产品的第一版的时候就推出。从用户的角度考虑，也就是说用户认可的才是好的，并不是开发人员觉的好 才好。

    　　3．从技术的角度考虑问题。虽然技术绝对不是唯一重要的，但是技术一定是非常重要的，是成功的必要环节。在产品设计的时候，必须考虑采用先进的技术和先进的体系结构。比如，如果可以采用多线程进行程序中各个部分并行处理的话，就最好采用多线程处理。在Windows下开发的时候，能够把功能封装成一个单独的COM构件就不作成一个简单的DLL或者是以源代码存在的函数库或者是对象。比如能够在B/S结构下运行并且不影响系统功能的话就不一定要在C/S下实现。

    4．合理进行模块的分割。从多层模型角度来讲，一般系统可以分成用户层、业务层和数据库层三部分。当然每以部分都还可以进行细分。所以在系统实现设计的时候，尽量进行各个部分的分割并建立各个部分之间进行交互的标准。并且在实际开发的时候，确实有需要的话再进行重新调整。这样就可以保证各个部分齐头并进，开发人员也可以各施其职。

    　　5．人员的组织和调度。这里很重要的一点是到考虑人员的特长，有的人喜欢做界面，有的人喜欢做核 心。如果有可能要根据人员的具体的情况进行具体的配置。同时要保证每一个开发人员在开发的时候首先完成需要和其他人员进行交互的部分，并且对自己的项目进 度以及其他开发人员的进度有一个清晰的了解，保证不同部分的开发人员能够经常进行交流。

    　　6．开发过程中文档的编写。在开发过程中会碰到各种各样的问题和困难，当然还有各种各样的创意和新 的思路。应该把这些东西都记录下来并进行及时整理，对于困难和问题，如果不能短时间解决的，可以考虑采用其他的技术替代，并在事后做专门的研究。对于各种 创意，可以根据进度计划安排考虑是在本版本中实现还是在下一版本中实现。

    　　7．充分考虑实施时可能遇到的问题。开发是一回事情，用户真正能够使用好它又是另外一回事情。比如在MIS系统开发中，最简单的一个问题就是用户如果数据输入错误的时候，如何进行操作。在以流程方式工作的时候，如何让用户理解自己在流程中的位置和作用，如何让用户真正利用计算机进行协作也是成败的关键。

    　　以上是我个人的一点体会，实际上，作为一个软件开发人员，我也喜欢看到问题就坐在计算机前面直接编 码，但是我确实认为软件工程对于我们系统开发的指导作用是巨大的。作为软件工程的拥戴者，下面我简单结合自己的开发经历介绍基于软件工程的开发方法、编程 规范和工具使用等方面的问题。


    七、软件开发的发展变化


    　　国外很多项目的开发都是基于一些图形化的东西来做的，他们的目的是尽量少写代码甚至不写代 码。代码能够通过图形化的方式自动生成，这样的一个好处就是如果用户的需求变化或者业务逻辑发生变化，我们需要做的就是对图形表示的调整，然后重新自动生 成代码，这也就是国外开发很注重对项目的概念和逻辑分析的原因。

    　　他们的重点是把业务规则和需求用图形化的方式表现出来，然后通过CASE工具自动生成代码。所以当国人还在不停的开发一个又一个的MIS工具的时候，国外已经把很多精力放到了CASE工具的制作上。

    　　我们很多公司人员忙着写具体业务过程的相关代码，而国外很多都把精力放到对不同应用，不同行业的模型的建立和共性的提取上。所以，他们做出来的东西就相对具有很强的灵活性和扩展性，而我们是用户的需求稍微有一点变化，就要忙着改代码，甚至改体系结构。

    　　另外，因为他们注重模型的建立，所以在建立其他应用的时候，能够借鉴原先的模型，在高层次上做调整和优化，同时能够有效的提取原有系统中可以被使用的部分。所以我们应该从以代码为核心的软件开发模式转化到以模型为中心的、基于CASE的开发上来。

    　　关于协作与个人英雄主义

    　　社会进步的一个很明显的现象就是社会分工越来越细，软件的开发也不例外。为什么在软件开发的今天已经不能出现象裘伯君这样的软件英雄的原因也在这里，单凭个人之力，我们也许穷尽有生之年也开发不出象Windows这样的操作系统。
    因 为，当前软件行业的壁垒无非就是两个，一个就是以技术创新取胜，你模仿的了其中的界面，但是你没有办法实现其中的核心功能。结果是你只能购买其技术核心， 而你作一些边角工作。不举别的例子，比如VB这样的开发工具，其核心部分是它和第三方提供的COM控件或者是DLL函数库，你所做的就是一个整合的工作。

    　　第二个就是以细致取胜，也就是说功能很多而且做的很精致，即使技术本身不是很复杂，你真要想做出一个这样的东西来没有一两年的工夫是不可能的。而真等你做出来了，它的新版本也早已经推出。真正能够在市面上叫得想、经得起考验得产品都是具有这两方面的特点。

    　　这两方面的特点决定了你一个人绝对是不可能胜任的，也许你可以独立的完成技术创新，但是你绝对不可能一个人实现所有这些纷繁复杂的功能。所以，这个时代需要创新的英雄，也更需要人与人之间的协作。
    当 今的软件发展已经不是一个人可以包打天下的年代。软件开发的管理、系统体系结构的设计、模块之间的衔接、核心算法的实现、灵活界面的制定、软件再开发接口 的实现都需要专门的人来做。而把这些有效的集成显然就需要有效的利用软件工程的思想和方法。所以，真正的软件英雄绝对不再是写着别人看不懂代码的程序员， 而是整个体系结构的分析、设计、标准制定、协调人员。

    八、我们是否需要软件工程


    　　有一点大家可以达成共识的就是，如果一个象Windows这样的操作系统，不进行全面的规划，不采用软件工程的思想和方法，是绝对搞不出来的。

    　　Windows的成功不在于它在进程管理和调度，文件系统、内存管理、界面设计等方面有多少成功的创新，它的成功最大的一点就是把所有的技术能够合理的整合起来，并集中到一个Window操作系统特有的框架结构中去。

    　　更为重要的是，Windows的每一项技术创新都能够有效的整合到Windows框架中去，比如COM、XML等技术，通过ActiveX、DCOM等技术使Windows从桌面操作系统发展成为一个基于网络的操作系统。

    　　OLE2技术把整个Office中相关的软件进行了有效的整合，显然，这里我们可以把Office 的设计和WPS的设计进行比较，客观的讲，WPS对中国用户来说实在也是一个很好的产品。但是从整个系统设计概念上来讲，Office显然要比WPS高一 个层次，它能够把WORD，EXCEL，POWERPOINT，ACCESS有效的整合在一起，使我们所有办公相关的文档、图表、数据库、演示变成了一个 一体化的东西。而且通过宏调用，用户可以自己定制用户界面并编制适当的模板，单是这个二次开发功能就不是WPS现在所能及项背的，当然限于当前用户的水平 还很少有人使用二次开发的功能。

    　　从微软产品系列可以看到软件工程的作用，微软的所有产品都有一个整体的框架结构，比如Office软件，通过OLE技术进行有效的通讯和联系。比如Visual系列开发工具，提供了相似的开发界面使用户学会一种开发工具以后能够很容易的学习其他的开发工具。比如SQL SERVER和ACCESS，尽管它们适用的范围不同，但是它们表现给用户的界面，特别是在查询和分析上表现了高度的一致性。

    　　更值得一提的是，因为设计结构的合理性，因为在开发前期作了很多分析和调研，考虑了扩展性和伸缩 性，微软的系列产品能够很快的利用新的技术并采用统一的结构形式表现出来。比如当网络成为计算机发展的主流的时候，几乎微软所有的工具都能够快速的支持基 于网络的开发和应用。

     

    　　相比之下，我们国内很多公司的产品很少具有连续性，往往是新的一个产品完全重起炉灶，和老的产品没有半点关系。这就是我们在设计产品的时候，没有很好的进行抽象和概念、逻辑设计，造成的结果是从旧的产品中提取不出一些有用的、共性的东西为后来的产品所使用。

    　　当然，很多开发人员从心里也承认一个大的系统确实需要软件工程的依托，但是一个小的工程项目是否就 可以仓促上马呢？答案是否定的。所谓麻雀碎小，五脏俱全。无论是大项目、还是小项目。它们作为一个项目，都需要有一个需求分析、系统结构建立、设计、编 码、测试等阶段。这是任何一个项目都不可缺少的。

    　　往往可以看到很多大公司的IT部门的人员都在不停的作各种各样的报表，当各个部门提出一种新类型的报表的时候，就从数据库中提取相应的数据并画出业务人员所需要的样式结构，很少是提供了一个通用的模板，当然提供高层API接口进行这种操作的就更少了。这样不可避免的使开发人员陷入一些琐碎的报表编制工作。而造成这个局面的很重要的一个原因就是没有在系统开发的前期进行很好的调研、需求分析和系统体系结构的设计。

    　　这里就我们开发过的一些小型软件项目来谈一些开发的总结和体会，一般来说，小型软件项目功能比较单一，而且模块与模块之间的衔接不是很多，同时对开发周期要求比较短。

    　　小项目虽然看起来比较简单，所以很多开发人员容易犯一些错误，记得我们在开发一个基于 Internet的有偿服务系统的时候，有三个开发人员：一个负责前端界面的编写，一个负责数据通讯协议和实现（基于TCP基础上的应用协议），一个负责 对数据库数据的查询、整理和提取。我们在开发的时候没有认真地进行项目实际前途和工作量的估计。没有认真地估计项目难度，比如对于通讯中多用户并发访问时 的多线程问题和缓存处理问题，用户批量请求处理的实现复杂度问题等等。三个人之间的接口也是在开发中休息的时候，口头定义一下。结果发现有不严密的地方 (比如在通讯服务器端是用VC编写的，开发人员是通过stream来传送数据的，客户端是 用Delphi编写，在接收数据的时候发现数据不准确，后来研究发现VC利用CSocket在传送数据流的时候对数据进行了自己定义的格式化，结果服务器 端数据发送模块只好重写)，而且其中关于一个接口双方的理解不同，然后又返工重新修改。最后到系统基本完成的时候没有一份较正式的文档。然后因为有人毕业 离开这个项目，然后他编写的模块需要升级，新的接收的人不得不花很多时间去阅读他的源代码。

    所以在开发小项目的时候也必须要建立合理的模式：而所谓合理的模式就是软件工程告诉我们的在开发一个项目的时候所需要的五步曲：获取需求、需求分析、设计、编码、测试。

    　　1．理解用户真正的需求。在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。

    　　我们软件项目可以大致分为专用软件和通用软件两大类。对于专用软件，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。

    　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子，这里最好就采用原型化的方法作出一个简单的框架给用户看。

    　　对于通用软件，在开发之前必须做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在市场 有多大，一方面是从技术的角度，了解清楚潜在用户对软件的各种技术上的要求，另一方面是确定我们软件的定位，即我们软件具体是为哪一些用户群体服务的。然 后对该群体用户现有硬件配置，软件配置，网络使用情况，数据库使用情况，计算机熟悉程度做一定的调研，根据调查的统计结果决定即将开发的软件的一些技术指 标。
    　　
    　　2．需求分析。需求分析需要做的事情有：高层构思、确立系统目标、划分业务领域、现行业务分析、建立业务模型(Enterprise Model)、信息需求分析、用户视图规范化、数据元素标准化与一致性控制。

    　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，一般我们可以面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。

    　　为了讨论软件运行的流程，可以采用UML的Use Case图。在系统分析的时候需要明确应用域（application domain）的范围，然后明确我们系统需要做什么。同时我们需要决定用什么方法来完成需求的获取，这在很大程度上影响了需求分析的做法。

    　　例如可以采用Use Case来表示用户需求，那么从各种序列图中选出相互交互的各个实体，就是一个个类。另外分析需要与设计过程相衔接。分析过程的内容是用对象和对象之间的关系来表示整个系统和系统的流程的，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。这些具体实现是在设计阶段来完成的。

    　　面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区分，如何用好辅助设计(case)工具还是开发人员的事情。

    　　3．设计过程。设计阶段的工作包括对分析模型进行必要的修改，同时可能需要对某些类结构做一些修 改，确定用户表示层(也就是通俗所说的界面定义)、用户服务层、业务逻辑层、数据库服务层和具体数据库所需要做的工作。同时需要确定使用的体系结构（比如 B/S还是C/S）和开发工具（如VB，VC，VI，C++ Builder，DELPHI，PowerBuiler等等）

    　　4．编码。进入编码工作之后，依然可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。同时在编码前规定编码的风格并在开发过程中保持一致的风格。


    　　5．测试。测试是系统投入使用前最关键的一个步骤。即使是小项目也应该严格地进行测试。就实际上就是一个把错误留给自己还是留给客户的问题。

    　　最后，我们知道软件项目主要是由开发人员完成的，所以对人员的合理安排和配置也很重要，一般在开发过程中，需要有一位项目负责人，负责分析、设计和协调的工作。另外需要几个程序员完成不同层的代码（比如用户服务层、业务逻辑层、数据库服务层等等）。

    　　同时需要有一个文档整理人员随时整理系统开发过程中相关的文档。如果条件可能的话，要配置一个测试工程师，专门进行代码的测试工作，当然如果条件不允许的话，也可以由开发人员交叉测试。这里需要注意的是，对于项目负责人而言，协调几个人的工作比自己完成一段编码更重要。

    　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容 是否与要求发生偏差，进度是否滞后等等。同时必须给每个开发人员明确的任务书。具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文 档来表示。每个开发人员需要清楚自己所做的工作在整个系统中处于什么地位，这样就有可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

    九、我国软件工程发展的现状


          很多国内搞计算机的专家都认为：国内的软件研发过程，个人色彩比较浓。过分地依靠个人无法形成产业规模，而没有规模就谈不上产业化了。

    　　不管怎么样，我们大家还是先要来看一看国内软件厂商到底提供给我们多少有震撼力的软件产品，从技术 和利润的角度讲，软件系统最核心的部分还是操作系统、编译系统然后就是开发平台之类的东西，接下来就是一些应用系统，比如图形开发、游戏开发、企业应用、 网站建设、杀毒、网络工具等等。

    　　操作系统以中科院为中心，做了一个COSIX，这个本质上是一个UNIX系统，UNIX最初的源代 码是公开的，尽管COSIX是一个被称为中国的操作系统并是UNIX系列的（IX就代表UNIX系列），但是其中到底有多少独创的技术成分我们暂时还不知 道，但有一点可以肯定，它现在的市场覆盖率绝对不大，而且能否在上面运行各种各样的编译系统、数据库、群件和应用系统可能还需要进一步测试。然后就是对硬 件平台的支持也需要进一步完善。

    　　然后就是轰轰烈烈的Linux系统，Linux是遵守GNU标准的操作系统，中国有很多家公司推出 了自己的Linux并且还有汉化的Linux，这就有比较疑惑的一点，为什么不在Linux上构架一个类似UNICODE这样的东西，而只做汉化这么本地 化的产品呢？不知道是眼光还是市场的问题了。
    MIS系统、财务软件是中国软件行业的重头戏，它们彻底的暴露了中国软件开发无序和重复低效劳动的一 面。教育软件在某一种层面上看就是电子题库，当然也有优点，比如加入了多媒体教学（可视化程度不错）和所谓寓教于乐的特点，但是从本质上说还是题库。杀毒 软件据说是中国软件的骄傲，由中国权威机构评测是达到了世界领先水平，但是好象还没有得到国际权威机构的认可。游戏软件就不用提了，国内业界能够流行的游 戏软件成功的秘诀众所周知，不是技术和创意，实在是归功于我们悠久的历史。字处理软件和排版软件客观的说国内的也做的不错，但是从系统的扩展性和体系结构 上说和MS和Adobe相比，差距也放在那里。其实这种现状的原因很简单，一个是我们缺少创新的能力，另一个就是我们欠缺软件工程的概念，系统开发前期的 需求分析、设计没有做好或者做的不够好。

    　　当然，我们很少怀疑自己的技术能力，我们很多时候认为这是地理环境和经济环境的原因造成了中国软件 业现在的局面。当然中国软件开发人员绝对可以算是优秀的，但是想想我们软件行业龙头企业到底有多少有技术创新和专利技术呢？姑且不论这个，实际上把一个操 作系统分解开来，比如文件系统、进程管理和调度、IO调度等等，也许我们可以实现其中某一块的内容，但是如何把它们合理的整合起来绝对是一个涉及到软件工 程的问题。

    　　作为一个开发人员，我们已经习惯了自己那一套编程模式，而且我们的这种习惯也不自觉的影响着新的开发人员。所以在头脑中建立一个软件工程的作用，从某种角度上讲，要比会几种开发语言、几个编程技巧实在是重要的多。

    　　举一个例子来说，我们也许可以写MFC中的几个类或者是用自己的类扩展MFC，但是我们又有几个人真正去认真分析和考虑MFC架构的设计和原理呢？扪心自问，我们又有多少人能够设计出MFC这样的框架系统呢？下面就我们的题目谈一些相关的话题。

    十、我有一个梦

    　　毋庸质疑的是，计算机的发展和人类的历史相比甚至和其他很多科技产品相比都是非常短的，从第一台计 算机的研制成功到现在也没有百年的历史，但是计算机及其相关技术的发展却绝对可以说是最快的。抛开硬件的发展（硬件的发展基本上是按照摩尔定律来的，每 18个月，机器的速度性能都要提高一倍），单从软件的发展来说，从体系结构来讲，我们经历了从主机结构到文件服务器结构，从客户服务器系统到基于 Internet的服务器浏览器结构的体系结构的变化。从编码的角度来讲，我们经历了从最开始的机器代码到汇编代码，从高级程序语言到人工智能语言，从专用的程序设计语言到通用的程序设计语言。从开发工具来讲，我们经历了从分离的开发工具（有代码编辑器，中间代码生成器和连接器）到集成的开发系统，从最简单的单行命令式调试器到方便灵活的多功能的调试器。

    　　但是，今天所有的软件厂商和软件开发人员依然会想起当年的黑人人权运动领袖马丁？路德？金曾经说过 的一句名言我有一个梦想。是的，所有的开发人员依然怀着梦想，希望能够有一个万能的系统开发的框架和方法，只要我们沿着这个框架，我们将能开发出适合所有 领域的应用系统，于是，我们在念书的时候把这个希望投到了一门课上，这么课就是软件工程。但是当我们在学完这门课的时候，我们依然没有找到这么一个框架甚 至连接近这么一个框架的东西也没有碰到。

    　　不管我们认为软件工程可能是多么的虚无，但是所有学工科并且有逻辑头脑的人都坚信理论对实践的指导 意义，因为有了爱因斯坦及其许多伟大的科学家关于能量和质量方面的理论以后，我们才造出了原子弹。但是，遗憾的是软件工程并不是一个具体的理论，它更象一 门抽象的科学。软件工程是一种方法论，而不是一种具体的摸的着，看的见的产品。它告诉我们在设计一个系统的时候，我们需要进行可行性研究、计划制订、需求 分析、系统设计、编码、测试、维护等等。并且对这些过程中应该做什么提出了一个指导性的东西。但是没有任何专家和标准委员会保证只要按照这些标准，我们的 系统肯定会顺利完成。而且事实上，软件开发针对的领域是如此之多并不没有一种对所有领域适用的万能框架。
    　　不管认为软件工程已经到了非常成熟的 阶段还是认为软件工程依然是一个搞不懂的黑箱子，软件工程确实已经经历了三个不同的阶段。第一个阶段是软件结构化生产阶段，以结构化分析与设计、结构化评 审、结构化程序设计以及结构化测试为特征。从80年代中期，软件生产开始进入以过程为中心的第二阶段，以提出过程成熟模型CMM、个体软件过程PSP和群组软件过程TSP为标志。第三个阶段就是以软件过程、面向对象和构件重用三把斧头出现的软件工业化生产阶段。

    　　言归正传，我们还是回到我们的文章标题上来，我们在开发的时候是兵马未动、粮草先行还是摸着石子过河。兵马未动、粮草先行当然意味着我们在开发的时候先不忙着编写代码做程序，我们先要制订一个关于开发的方法。这点就象元数据（metadata） 的概念，元数据并不定义数据，它是对数据的说明，也就是通常所说的关于数据的数据。我们设计的时候也是这样，定义开发的标准，如何进行开发、怎样开发。摸 着石子过河就意味着我们先不管什么理论，方法，科学的问题，我们先动手做起来，如果做的也算成功的话，那就可以按照这种模式来，实际上，在任何事情的最 初，我们都是这样。从辨证唯物主义者的观点来说，就是从实践中来，然后升华到理论，再用理论来指导实践。记得一个笑话说：外国人搞软件工程是在一个黑屋子 里面抓黑猫，不过到现在还是没有抓住，而中国人是在一个黑屋子里面，而里面连猫都没有，然后有人说，我已经抓到猫了。这个笑话一方面是说明直到现在，软件 工程还是一个在继续探索、发展的过程，另一个侧面也说明中国搞软件工程摸不着边的局面。

    　　实际上，不管有没有软件工程，不管是否存在一个万能的框架系统，我们的应用系统还是要做，各种各样 的软件还是要开发。说到底，软件系统是因为有需求才存在的。有了应用域才有了软件存在的意义。很多时候，我们可以看到国外有各种各样的软件和创新，而我们 没有，我们更多的是模仿和一些重复的功能相近的软件的原因就是因为我们没有这方面的需求，这也正解释了为什么ERP系统能在国外开展的很好，而在国内失败 多于成功的原因。一方面当然是因为我们的企业按照市场经济发展的时间还不长，另一方面是我们的企业确实也没有这方面的需求。

    十一、软件工程的发展方向

          “敏捷开发”（Agile Development）被认为是软件工程的一个重要的发展。它强调软件开发应当是能够对未来可能出现的变化和不确定性作出全面反应的。

          敏捷开发被认为是一种“轻量级”的方法。在轻量级方法中最负盛名的应该是“极限编程”（Extreme Programming，简称为XP）。而与轻量级方法相对应的是“重量级方法”的存在。重量级方法强调以开发过程为中心，而不是以人为中心。重量级方法的例子比如CMM/PSP/TSP。

     

    查看(516) 评论(0) 收藏 分享 管理

  • 关于面试的一点看法

    2006-12-27 22:02:32

        开通博客已经几天了，但是总是无法提笔写点东西，不知道刚刚开始该说些什么。李波老师在讲课时曾多次提到一个“破冰”的概念，那么就以今天学习简历制作与面试的一点感想作为自己的博客破冰之举吧。
        今天又看到这句格言：“大学毕业生要找的只是一个工作，而不是职业，更不是事业”，其实我对这句话是有一定的不认同的。如果这句话所提倡的是人们要脚踏实地，摆正心态，踏踏实实的从小事做起，那么我是认同的。就如测试一样，将来我们进入公司，最开始一定是从测试员做起的，以后才会逐渐的进行测试用例和测试规程的设计，以及测试方案的制定。但是，我认为这句话是就业指导专家在当初就业形势很严峻的形式之下，为了缓解就业难的状况，并且针对很多大学生好高骛远的情况而提出的。其实今天每个毕业的大学生都明白面临的严峻形势，现实已经不容人们盲目的去追求不易实现的理想。如果还是拿这句话去教导面临找工作的学生，那么会造成人们一定程度上的误解：认为只要找到工作就OK了，而不会去好好规划自己的职业发展，从而面临经常更换工作的尴尬，经常是几年之后发现自己还是不知道自己要做什么，也不知道自己几年的工作为自己带来怎样的积累和经验。所以我认为每个面临找工作的人，首先应该仔细思考自己未来的职业发展之路，确定下来之后再踏踏实实的为了自己的目标去努力。这样未来发展会更好！
        确定自己的发展之后，就是针对相应的公司投递自己的简历了。简历的制作要注意一下几方面的内容：1、简历要有针对性，针对所应聘的岗位而设计，充分的表达自己与应聘岗位的适合程度。2、要简练大方，企业的HR不会花很多时间去浏览求职者的简历，所以简单而有层次结构的简历是最适合的。
        等到面试的环节，最重要的就是心态。要有良好的心态，这样才可以和面试官进行有效的沟通，将自己成功的推销出去。如果将自己想成在帮助那些夜不成眠的总裁们，可能每个人都会消除点紧张吧。还有一点就是要注意细节了，包括：整齐的着装、真诚的态度、对于工作的热情等等。这些细节都是个人素质以及长久的习惯的体现，所以面试时要避免因为不恰当的举止而影响自己的面试结果！
        其实，不管是简历还是面试，这些都是帮助人们成功找到工作的一种有效的手段，最重要的还是自身技术的提高，包括测试技术、相应的计算机技术、英语能力等。如果内功没有修炼好，那么简历和面试准备的再好也是枉然。所以为了将来更好的就业，现阶段还是要多注重技术的提高和修炼！也希望一起上课的朋友们，为了我们的职业理想，大家一起加油！

       

    查看(605) 评论(0) 收藏 分享 管理

数据统计

  • 访问量: 14455
  • 日志数: 18
  • 书签数: 2
  • 建立时间: 2006-12-25
  • 更新时间: 2007-06-23

RSS订阅

Open Toolbar