应用Microsoft Visual SourceSafe组织软件开发项目

应用Microsoft Visual SourceSafe组织软件开发项目

版本管理器Visual SourceSafe 6.0实用指南

对规划下一个项目的建议

用户需要什么-软件的工程可用性

测试、测试、测试--软件测试的理论和实践

软件复用为软件开发提速

可用性：软件贴近用户的重要标准

软件工程标准初探

软件的性能设计

面向对象方法在HTML编码中的应用

程序文档合一与动态文档

需求工程研究现状

软件开发全过程检测及软件测试自动化

软件工程的若干探讨

关于发展我国软件产业的几点思考 　

中国与印度软件开发之比较

IEEE指南：开发系统需求规格
如何编写高质量需求


	应用Microsoft Visual SourceSafe 组织软件开发项目（Organizing Software Development by Project Using Microsoft Visual SourceSafe） ----微软公司　　摘要专业的软件开发需要对在开发过程中每一应用程序的源代码修改的管理进行流水线处理。Microsoft_ Visual SourceSafe?记录了系统、项目和文件级修改的历史记录，允许你安全的在多个程序员之间分配开发工作，跟踪修改信息，并恢复个别文件或整个应用程序的早期版本。简介代码是宝贵的资源。为了保护它，很多开发者应用一些版本控制系统以保护文件避免未授权的修改和意外的错误。这些系统有很多种，从有关程序注释的更改和存储旧版本的君子协定到自动跟踪修改和历史记录的复杂的软件系统都有。大多数来源控制系统对于单独的源文件是有效的。但是，它们几乎全部不能在文件间建立关系。这在Microsoft Windows的环境中将引起问题，因为在该环境中，一个应用程序可以包含多个可执行文件和由许多不同的源文件建立的动态连接库，它们有可能在很多其它应用程序中重复使用。当今，管理源文件间的关系和保护源文件的内容本身同样重要。 Microsoft Visual SourceSafe 版本控制软件通过将项目管理的任务和源代码的控制结合起来，解决了这个问题。以注重在管理源文件的同时管理项目，Visual SourceSafe提供了对该问题的优秀的解决方案，是用标准的、面向文件的来源控制系统不易实现的。软件开发流水线为了理解面向项目的来源控制的优点，仅需将它和面向文件的系统进行一下比较。一个标准的版本控制系统（例如，UNIX工具RCS）必然是一组用于操作独立的文件、控制文件访问和更新并与早期版本比较的工具的集合。为了操作一组文件，你需要编写一个批文件或在命令行指定通配符。 Microsoft Visual SourceSafe将文件存储在网络的中心数据库中，而不是在一个普通的DOS目录中。在系统级，该数据库表现为一个“黑盒”。但是，当以Visual SourceSafe为视图时，可以看到该数据库中包含了你的组织到项目分层结构中的所有源文件和历史记录。当你检索一个文件时，Visual SourceSafe将在数据库中标记该文件为签出，然后允许你在你的机器上对该文件进行修改。当你将该文件放回时，Visual SourceSafe更新它的数据库并重新修改你的机器对文件的访问权限为只读。然而，这和面向文件的来源控制有什么不同呢？对于每一个改变，Visual SourceSafe数据库记录并追踪那些对于面向文件的系统不可用的项目信息。每当文件被加入，修改，共享，移动，或从项目中删除，Visual SourceSafe将同时更新文件和项目的历史记录。你可以应用项目历史记录来简化这些工作： ? 在连编前浏览指定项目及其全部子项目中所有文件的状态。 ? 缩小那些由于在某一日期联编可能引起错误的指定文件的改变信息。 ? 重新生成所有应用程序的前一版本。 ? 维护被许多不同应用程序共享的源文件。 ? 确定哪一个项目将由于改变被多个不同应用程序共享的文件而受到影响。 ? 管理通用应用程序的特定客户版本。对于软件开发人员来说，试图通过面向文件的系统来完成这些工作，将是令人难以忍受的琐碎且无益的。正如下述的方案所阐述的那样，Visual SourceSafe面向项目的版本控制通过直接进行这些工作，将开发过程流水线化了。为连编做准备假定你将连编一个包含了很多独立的部件的主应用程序。在你开始连编之前，你希望确认没有人在最后的时刻修改代码，并且在版本控制过程中，整个系统没有文件被签出。一个标准的版本控制系统提供给你一个确定文件是否签出的工具。你的工作是对将用来连编的每一个目录中的每一个文件运行该工具。尽管引入批处理文件和通配符将使任务简单些，但面对一个复杂的系统时，仍然是非常繁琐的。正如其它系统一样，Visual SourceSafe可以确定一个文件是否被签出。但它还可以创建一个高层的报告：一个项目中所有签出文件的列表。这一特性应用在当前项目中循环包含所有子项目时功能尤其强大。Visual SourceSafe检查每个相关项目中的每一个文件并生成签出文件的列表。你可以立即知道是否可以进行连编（或如果你不能时该找谁）。仅需在项目文件中执行一个命令，Visual SourceSafe就可以自动完成以前冗长的需手工完成的工作。精确回归包括Visual SourceSafe在内的所有版本控制系统都有文件历史记录报告。文件历史记录报告中列出了从最新的到最旧的每一个文件版本，包含诸如对文件进行了什么操作，谁做的，什么时候完成的和进行了什么备注说明等信息。尽管文件历史记录非常有用，但它们也有一些缺陷。例如，假定一个特性在上个星期还可以正常工作，但在这个星期连编你的应用程序时出了问题。显然，最近有人引入了这个错误，但是在哪一个文件中呢？在标准的版本控制系统中解决这个问题，你需要为一个象是有错误的文件生成一个历史记录报告，看是否它最近被修改过，并浏览修改情况。如果你没有找到错误，你就要选取另一个文件进行检查，如此类推。你可能用这种方法查遍了系统中的所有文件但没有找到关键的修改──因为事实上这个修改是增加或删除文件，而标准的版本控制系统根本不追踪这样的操作！在Visual SourceSafe中，你通过项目本身生成报告。例如，它可能报告COMMON.BAS刚被修改；在此之前，OPENALL.FRM被修改过；此前，FILESUPP.BAS被增加到项目中；诸如此类。Visual SourceSafe整理这些否则你将手工完成检索的修改信息，允许你浏览上个星期的全部修改的顺序。这将节省你很多的时间并帮助你避免陷入困境。重新创建前一项目版本通过检索项目的历史记录，Visual SourceSafe允许你快速重新创建整个应用程序的前一版本。这将帮助你解决在前一版本中报告的错误，并确认它们在当前开发的新版本中已解决。例如，假定一个用户报告应用程序版本2.03中有一个打印问题。应用程序的该版本可能包含一个文件版本为10，另一个文件版本为15，诸如此类；但你不必担心这些。从Visual SourceSafe中请求一个指定的项目版本，你便可以还原一个完全的、用于连编2.03版本的应用程序源文件的本地的副本。若应用标准的版本控制系统完成这些工作，你或者必须将应用程序的每一个发行版本的来源独立存档或者需对每一个版本搜索指定的文件。这两种方法中，为前一次连编恢复正确的源文件都是一件烦人的手工的过程─ 一项可能被取消或推迟的工作。维护可重用代码大多数应用程序是在一个公共的核心代码的基础上开发的。这些文件在很多不同的应用程序中一次又一次的被使用并随着时间不断完善，得到错误修复，性能提高，和新的特性。应用现存的代码的好处是巨大的，但在处理组织问题时仍然是件另人头疼的事。你必须记住文件被哪些应用程序使用，并将每一个修改信息传送到所有恰当的地方。当有五个应用程序重用一个文件时，这还只是小麻烦，当有二十个应用程序混合在一起并与五十个不同的重用文件相配时，麻烦就大了。一个标准的版本控制系统在这个问题上根本帮不上忙，因为一个源文件可同时存在于多个不同的项目中。但Visual SourceSafe可以自动完成这一切。在它的数据库中，Visual SourceSafe对每一个文件只存储一次。每个项目文件包含了一个拥有指向数据库中文件位置的指针的文件。对于每一个项目，所有版本的文件都是可用的；同时一个项目可以“冻结”一个文件的版本，以避免当其它开发工作组在可重用代码上工作时引入错误。举一个普遍的例子，假定你有一个包含了多个不同打印报告进程的源文件。在Visual SourceSafe中，每个需要打印报告的应用程序均需要共享该文件。如果你发现了一个错误，你可以从任何一个项目中更新文件─这一改变信息将立即传送到每一个共享该文件的项目中。Visual SourceSafe可以报告哪些项目共享了该文件，于是你就知道哪些应用程序受到了影响并需要重新连编。创建特定用户版本另一个普遍的来源控制问题是关于用户的，他们期望定制应用程序以满足他们特定的需要。本来，你有很多不同的应用程序，他们共享几乎全部的相同的源文件。应用标准来源控制工具，追踪错误并保持连编的连续性的时间将比编程所花费的时间还多。应用Visual SourceSafe，你为每个新用户创建一个项目，指明哪些文件是共享的和哪些文件是独享的。当你在一个项目中工作时，对于特定用户的改变信息将保留在当前的项目中，而对于共享文件的修改将传送到所有用户版本。

	主页论坛留言打印联系


	版本管理器Visual SourceSafe 6.0实用指南胡杰　　一、版本管理的必要性　　如果说70年代的软件危机导致了软件工程思想的诞生和理论体系的发展，那么80～90年代尤其是90年代软件产业的迅猛发展导致了另一种新思想的产生和实现，这就是软件的版本管理。　　只要参加过软件开发的人都清楚，现在的软件项目完全由一个人来完成是难以想象而且也是不可能的，通常是有一个研发小组来共同分析、设计、编码和维护，并有专门的测试小组对已完成编码调试的软件进行全面的测试。在软件开发这个庞大而复杂的过程中，需要涉及到各个方面的人员，信息的交流反馈不仅仅是在研发小组的成员之间及各个研发小组之间，还存在于客户和研发者之间。所有的这些交流反馈意见信息都有可能导致对软件的修改，小的可能只是对某个源文件中的某个变量的定义改动，大到重新设计程序模块甚至可能是整个需求分析变动。在这个工程中，由于软件开发所固有的特征，可能会形成众多的软件版本，而且我们并不能保证不出现错误的修改，而这样的一个困难局面却又非常现实地摆在项目开发管理者的面前，他/她该如何有效地解决这些问题，具体地说就是如下一些问题：　　1. 怎样对研发项目进行整体管理；　　2. 项目开发小组的成员之间如何以一种有效的机制进行协调；　　3. 如何进行对小组成员各自承担的子项目的统一管理；　　4. 如何对研发小组各成员所作的修改进行统一汇总；　　5. 如何保留修改的轨迹，以便撤销错误的改动；　　6. 对在研发过程中形成的软件的各个版本如何进行标识，管理及差异识辨等等。　　一个非常直接的反应，我们必须要引进一种管理机制，一个版本管理机制，而且是广义上的版本管理，它不仅需要对源代码的版本进行管理，而且还要对整个项目进行管理。以往的那种被誉为具有良好编程风格的做法，诸如在对他人的源程序进行修改时注释修改原因，修改人和日期，如果是多个成员同时进行了修改，那么需要进行及时的人工的差异比较和综合以便形成一个统一的新版本。这种做法在当前的大型软件的开发中已经越来越没有空间了，可以说是一种以小作坊的形式来面对软件的社会化大生产，再也不可能行得通了。　　其实，版本管理的思想很早就存在于软件开发者的头脑之中，只是以往的认识没有现在人们所意识到的那样迫切。UNIX的程序开发系统较早就提供了能够进行开发小组中源代码版本管理的工具，现在的Linux更是提供功能强大的能够跨平台的版本管理器，国外公司的基于Windows的版本管理器也已经有了比较成熟的产品，国内的研究单位如北京大学计算机系CASE实验室也在致力于这方面的工作。在众多的成熟产品和试验产品中，这里只将对使用比较广泛，有较大用户前景且又能较易获得的版本管理器产品Microsoft公司的Visual SourceSafe 6.0进行详细的介绍，针对普通的研发小组的解决方案，及具体的实现。　　二、Visual SourceSafe 6.0(VSS 6.0)简介　　VSS 6.0现在是作为Microsoft Visual Studio 6.0这个开发产品家族的一员，如Visual C++ 6.0和Visual J++ 6.0一样。　　1. VSS的简单工作原理　　Microsoft的VSS 6.0解决了软件开发小组长期所面临的版本管理问题，它可能有效地帮助项目开发组的负责人对项目程序进行管理，将所有的项目源文件（包括各种文件类型）以特有的方式存入数据库。开发组的成员不能对该数据库中的文件进行直接的修改，而是由该版本管理器将该项目的源程序或是子项目的源程序拷贝到各个成员自己的工作目录下进行调试和修改，然后将修改后的项目文件作Checkin提交给VSS，由它进行综合更新。VSS也支持多个项目之间文件的快速高效的共享。当某个成员向VSS中添加文件时，该文件将会被备份到数据库中，以便所有的成员都能共享该文件。而且每个成员对所有的项目文件所作的修改都将被记录到数据库中，从而使得修改的恢复和撤销在任何时刻，任何位置都成为可能。小组的成员可能得到该项目的最新版本，对它进行修改，并保存一个新的版本。　　VSS的项目组织管理使得开发小组的协调变得简单容易且很直观，当一个和一组文件发放给另一个成员，小组，Web站点或是任何其他的地址，VSS确保他们之间的真正共享及所选的一组文件的不同版本的安全性。现在，越来越多的开发者可以通过他们的开发环境来访问VSS的功能。而且VSS可以很容易地于Microsoft Access、 Visual Basic、 Visual C++、Visual FoxPro和其他的开发工具集成在一起，一旦VSS集成到开发环境中，就可以象控件一样使用，能够很好地体现出VSS的易用性和强大功能。　　2.VSS中的几个重要概念　　为了更好的了解VSS，有必要对如下一些概念给予说明。　　首先是项目的概念，所谓的项目是一组存在VSS中的文件（任何类型），可以在项目中或是项目之间进行文件的添加、删除、编辑和共享。一个项目与操作系统的文件夹有很多的相似之处，但它更好地支持文件合并、历史和版本控制。所有的文件存在VSS数据库的项目中，开发组成员不能在VSS中的主备份文件上工作（除了检查和版本比对等特殊情况外）而是VSS为每个成员在各自的工作目录下提供一个拷贝以供工作。尽管在没有工作目录的情况下也可以查看某个文件，但如要真正在VSS管理下工作，就必须要创建一个工作目录。　　VSS能够维护一个文件的多个版本，包括一个从不同版本之间进行修改的记录。版本控制包括如下方面：　　组内协调—在一般情况下，确保在任何时刻都只有一个成员对某个特定的文件进行修改，这样可以防止文件被其他成员的修改意外更新。当然，VSS管理员可以改变此缺省设置以允许对单个文件同时有多个Checkout，并且仍禁止对他人的修改进行覆盖。　　版本跟踪—对老版本的源代码和其他文件进行归档和跟踪，而且这些版本能够被重新得到以便进行bug跟踪或其他目的。　　跨平台开发—支持同一代码在跨多个开发平台时的版本控制。　　重用或面向对象代码—跟踪哪些程序使用了哪些代码可被重用的模块。　　版本控制的涵义在以后的章节中将会得到更进一步的论述。　　我们已经知道，VSS 提供版本控制和历史服务，以保证一个文件的每个版本都是可恢复的。VSS用日期/时间戳来记录文件是何时被Checkout或是何时被修改的，它主要有三种方法来跟踪文件和项目的版本：　　版本号：这是由VSS维护的内部数码，用户对它没有控制权。每个文件和项目的每个版本都有一个版本号，这些版本号总是一个整数且是递增的。　　标签：这些是用户赋给某个项目或文件的某个版本的一个字符串，可以是任何格式的长度不超过31字符的字符串。　　日期/时间戳：它给出了一个文件何时最后被修改的信息，或者是一个文件何时被Checkin。VSS同时支持12小时和24小时的时间格式。　　工作目录是用户真正对项目文件进行调试修改的地方，当用户Checkout 或提取一个文件时，VSS将该项拷贝到用户的工作目录下，当用户修改了该文件并将其Checkin或提交时，VSS再将它从用户的工作目录拷回到VSS的数据库中。在用户作Checkout时，VSS将会自动管理他的工作目录，诸如创建必要的子目录。而且工作目录可以随时创建或修改。　　3. VSS 6.0的一些新增的特征和功能　　归档和恢复—在VSS 6.0中这两个操作是在一个用户界面友好的VSS管理员wizard中进行的，而在以前的版本中，它们只能通过命令行来实现。　　移动文件—当用户移动文件时，VSS 6.0自动将该文件共享到一个新的项目中，并在原项目中将其删除。在新项目中，该文件的属性是共享的。　　多个项目之间的差异比较—该功能允许用户在不同的项目之间进行差异比较。　　单个文件的展开—在以前的版本中，VSS只能展开一个目录（文件夹），在VSS 6.0中，同时可以展开一个文件。　　快速提取—由于VSS 6.0在性能上的提高，现在的文件提取速度比以往VSS版本的快两倍左右。　　历史信息过滤—VSS 6.0 支持查看那些没有标签的文件和项目的历史。　　清除临时文件夹选项—该新功能可使用户很方便地清除临时文件夹。　　检查外部的超连接—在VSS 的较早的版本中，只有内部的超连接和项目内的跳转才得到检查，VSS 6.0允许用户检查项目之外的超连接和跳转。　　创建打开VSS数据库的快捷键—用户可以使用VSS Explorer中该新功能创建一个打开某个特定VSS数据库的桌面快捷键。　　HTML格式的帮助—VSS的以往版本使用的是WinHelp格式。　　三、VSS 6.0的解决方案　　在对VSS 6.0的工作原理，功能和新增特征有了一个较全面的了解后，我们开始进入到本节，即如何运用VSS 6.0来实际解决软件开发工程中的版本管理和控制问题，怎样有效地构架一个系统的解决方案。　　首先看一下我们的开发小组所处于的实际情况，最一般的情况是整个项目使用的就是微机环境，每个开发者在各自的Windows微机下利用Microsoft的VC、VB、VJ等等来开发项目中各个子项目或子模块，通常这个小组是局域网的一部分或者是一个较为独立的子网，可能配有专门的服务器。这样的一个开发环境对于实现用VSS 6.0来进行版本控制和管理是非常有利而且是比较直观的，因为VSS 6.0也需要这个网络环境。　　其次是对于项目本身来说的，一个项目经过分析设计后一般都会分成若干个子项目由若干个开发小组各自负责编码调试，但软件开发的实际情况决定了各个小组之间并不是完全独立的，他们在很多情况下都需要协调交互和信息反馈，开发过程中的每一步都有可能会导致对前一阶段工作的修正，因为软件开发很大程度上是一个螺旋式的过程，更不用说小组之内的相互交流了。在这个不断交互改动的过程中，将可能形成的项目的阶段版本、部分版本和完整版本的数量是可想而知的，而以往的通常的版本人工管理方法已是不能胜任了。而且还有一个非常重要的方面不可忽略，这对系统软件的开发尤为明显，即软件的层次结构。一般的做法是在通用的系统软件之上为多个应用开发相应的应用程序，与此相对照的项目开发组也一般分为系统开发组和各个应用开发组，应用软件的开发和使用过程中将会反馈回无数的应用本身和系统软件的问题，如果只是针对每个应用来单独修改更新系统软件版本，这样就不可避免地导致多个系统版本的不一致，这样对于真正解决系统所存在的问题就显得力不从心了。而VSS 6.0正适合于这种软件的开发体系结构，可以为各个小组创建自己的项目，而这些项目又从属于一个总的项目，所有的修改都将被汇总处理以形成一个统一的最新版本。　　针对这样最为普通的一个软件开发环境和组织结构，运用VSS 6.0进行版本控制管理的非常有效而且代价较小的解决方案是：　　在一台Windows NT服务器或者是一台较为独立的Windows 98/95 PC上安装VSS 6.0的服务器端软件，创建一个为该整个项目存放用的数据库，然后在该数据库中创建各个项目和子项目，并由VSS管理员为小组的每个成员创建一个帐号及他们各自的权限；　　在开发小组其他成员的PC上安装VSS的客户端软件，并创建自己的工作目录，这样在软件的开发过程中，他们只要通过该客户端软件登录到VSS服务器上，Checkout当前要进行工作的项目或文件，如有修改的在工作结束时将其Checkin提交给VSS服务器进行统一更新。　　解决方案如图1所示。　　图1 　　四、VSS6.0服务器的安装　　在我们给出整个解决方案后，现在来看一下如何安装VSS服务器。VSS 6.0是Microsoft Visual Studio 6.0 套件的成员，我们就以这个版本为例进行说明。　　第一步，将Visual Studio 6.0 的CD1放入CD-ROM，自动进入安装程序，选择第二项“Server Applications and Tools(Add Only)”，如图2所示；　　图2 　　第二步，然后在“Server Setups”的“Server Components”中选择“Visual Source Safe Server”,按“Install”按钮后，根据提示放入CD2，如图3所示；　　图3 　　第三步，根据Installation Wizard的提示，继续安装过程，选择安装路径，按图4左上角的按钮，系统继续进行安装，直至提示你重启以使新安装的程序生效，重启计算机。　　图4 　　VSS 6.0服务器的安装比较简单，它既可以安装在Windows NT下，也可以安装在Windows 9x下。　　五、VSS 6.0客户端的安装　　在VSS 6.0服务器安装完毕后，就可以在VSS管理员的指导下安装客户端的软件。由于我们是在一个Windows环境的子网内，每台PC客户机均可通过网上邻居来访问VSS服务器。在VSS管理员为用户指明VSS客户端软件的安装程序“Netsetup.exe”的位置后，用户可以直接通过资源管理器“Explorer”在网上邻居中找到该程序，并双击以运行它，如图5所示。　　图5 　　Netsetup.exe被启动后进入VSS客户端的安装，在如下提示框中输入用户名和工作组名，如图6所示。　　图6 　　选择VSS的安装路径后，在图7中点击安装图标，进入实际安装步骤，以后的工作将由系统自动完成。　　图7 　　当系统提示你，VSS已成功安装，到此所有的安装工作已经完成。　　六、VSS6.0服务器的配置和管理　　在VSS 6.0服务器安装完毕后，就可以针对开发项目进行VSS服务器的配置和管理，这些工作均需由VSS管理员来完成。　　首先，为整个项目创建一个VSS数据库（在VSS服务器安装时，系统已经创建了一个缺省数据库Common），启动Visual SourceSafe 6.0 Admin（Start /Programs/Microsoft Visual Studio 6.0/Microsoft Visual SourceSafe/Visual SourceSafe 6.0 Admin），跳出如图8的窗口，点击下拉菜单Tools中的Create Database...菜单项，将出现如图9的窗口，选择新数据库的路径，例如创建MyApp数据库，然后点击OK按钮，系统将完成创建工作。　　图8 　　图9 　　第二步，为新创建的数据库（例如MyApp）建立用户，首先需要打开该数据库，点击下拉菜单Users/Open SourceSafe Database...，然后选择数据库MyApp，打开它，如图10所示。再选择菜单项Add User...，输入用户名和口令，如图11所示。然后依次创建其他的用户。　　图10 　　图11 　　第三步，在该新建的数据库中创建项目Project。启动Microsoft Visual SourceSafe 6.0 （Start/Programs/Microsoft Visual Studio 6.0/Microsoft Visual SourceSafe/Microsoft Visual SourceSafe 6.0），出现如图12的窗口，点击下拉菜单File中Open SourceSafe Database...,跳出如图13的对话框，选择一个数据库（例如MyApp），双击它或按Open按钮一打开该数据库；一个项目Project是一组相关的文档或者是一个文件的集合，VSS允许你以任何的层次结构来存贮和组织你的项目。在VSS数据库中，你可以创建一个或者多个项目。点击菜单File中的命令Create Project...，创建一个项目，例如MyProject，如图14所示；创建完项目MyProject后，需要向MyProject中添加文件，点击File中Add Files命令，将跳出对话框，选择相应文件或目录，点击Add按钮，将它们添加到MyProject中去，如图15所示。　　图12 　　图13 　　图14 　　图15 　　VSS服务器的配置到此基本上已经完成了，创建了数据库和项目，并为它们建立了相应的用户，这样用户在客户端的VC等集成开发环境中就可以直接登录到VSS服务器上，进行在VSS控制管理下的开发工作。　　七、在客户端的VC中使用Source Code Control 　　当VSS服务器端的安装配置工作全部完成，并在客户端也完成了VSS的安装，这样就可启用VSS来管理控制整个开发小组的源代码和文档的版本管理。本节我们以应用比较广泛的VC++ 6.0为例来说明如何坐在客户端运用VSS，以实现所有的开发工作均处于VSS的有效的控制管理之下。　　启动Microsoft Visual C++ 6.0，在VC的集成开发环境中，点击File菜单的Open Workspace 命令，跳出的对话框如图16所示，与没有安装VSS客户端软件的VC有一个明显的区别：在对话框的底部增加了一项“Open a project from source code control source control”。　　图16 　　点击source control 按钮，将跳出如图17的登录对话框，输入你的用户名和口令，通过Browse...按钮选择你要登录的数据库。选择一个项目Project，在文本区输入它在本地的工作目录，VSS服务器将在该工作目录下拷贝一份源代码以供用户开发调试和修改，如图18所示。其他的操作就如同在本地开发一样，将鼠标移至VC窗口的边框，按右键选上Source Control，就会出现Source Control工具条，如图19所示。选择Source Control工具条中的相应按钮，可以完成诸如获取某项目文件的最新版本，向VSS数据库中添加新文件，将修改后的文件Checkin提交给VSS数据库，查看某个项目文件的历史信息，进行不同版本文件及不同项目之间文件的差异比对，还有共享某个项目或文件。这样操作起来是不是很轻松呢？！　　图17 　　图18 　　图19 　 (the end)

	主页论坛留言打印联系


	对规划下一个项目的建议 Scott W. Ambler 总裁，Ronin International 2000 年 12 月 14 日文章来源：IBM developerWorks 中国网站项目计划技巧对于现今的软件开发人员来说是必需的。这里有一些帮助您有效地计划下一个项目的建议。认识到信心来自规划过程，而不是计划本身创建项目计划会迫使您早在编写一行代码之前就考虑如何构建您的系统——减少项目的风险，因为您已经考虑了各种策略和方法并且已经选择了最有意义的一项。您的目的不应该只是不花气力产生一个计划；它应该一个实际可行的计划，您可以根据它来成功管理您的项目。软件过程推动计划的开发每个软件过程都有一个不同的集合，它包括组织团队的活动方法以及规划项目常用的技术。由于这个原因，基于 Rational Unified Process (RUP) 的项目规划不同于 OOSP 项目的规划，而 OOSP 项目的规划也不同于 eXtreme Programming (XP) 项目的规划。不同的过程有不同的计划。从粗粒度的计划开始在项目将要开始时，应该制定一个粗粒度的、确定项目高级活动和预期里程碑的计划。粗粒度的计划将组织成迭代——根据项目的大小和性质，每次迭代通常在三周到八周之间发生（四周到六周为更佳）。其中一些迭代将集中在项目初期，而很多迭代将集中在整个应用的功能部分开发，还有一些迭代集中在将您的系统转变成产品。实施者应该是计划人员创建项目计划的最佳人员是负责实施该计划的人员。当规划由一个人创建而由另一个人实施时，如果项目不能按时完成或超出预算，他们不太会相信计划，而很有可能会责备它。也就是说，参与项目的每个人都应该投入到项目计划的开发和进展中。不要忘记“不该忘记的事。” 计划不仅要反映需求设计、建模、编程和测试的“真实”工作，而且还应该反映辅助活动（然而仍是重要的），它包括： 1 休假和法定假日 2 培训和教育 3 项目管理活动，如规划和人员管理 4 开销，如系统当机时间、会议和回复电子邮件 5 体系结构定义 6 测试之后的系统返工 7 系统交付 8 与重用相关的活动，如普遍化将任何设想和约束编入文档规划时您总要作一些假设，如能够及时获得应用程序服务器的新发行版，或可以得到熟悉您正在应用的技术和技巧的开发人员。同时，您将在一些约束下工作，如影响计划的强制截止期限或资源限制。将这些假设和约束编入文档，这样，当您实施项目的任何时候更新计划时，都可以记起您先前做出的一些“不寻常”决定。认识到不同的资源意味着不同的计划。十名有经验的开发人员组成的团队创造出的成效要远远多于十名初学者组成的团队所创造的成效。要想更加实际的话，您的计划必须反映项目可使用的资源的真实情况。创建现实的计划项目组必须相信其项目的目的、估价和时间表。要做到这点，您必须真实地规划，避免规划超出您能理解的范围。仅当您打算研究未知事项时，才能容忍无知。只规划有价值的事 IBM DeveloperWorks 网站提供了许多可应用于您项目的最佳实践。然而，根据项目的性质，不是所有这些技术都将适合于您的独特情况。要将这些最佳实践简单地看作是您放置在“项目管理工具箱”中的工具，您可以根据需要适当使用这些工具。适当使用项目管理工具一些项目管理工具，如 Microsoft Project，提供了重要功能，如 Gantt 图表（活动时间表）的开发、规划与实际结果的比较、PERT 图表（网络图表）的开发、任务的定义、任务之间相关性的定义、对任务的资源分配和资源平衡。所有这些事情似乎象是一个好主意，并且它们通常是好主意——但它们还需要许多精力来创建和维护，而且很少为项目组提供实际价值。的确，它让一些项目管理人员感到富有成效。的确，高级管理喜欢看见您有一个计划。但是，没有一行代码是由所有这个活动产生的。规划是有价值的活动；但投入大量的时间来创建规划图表通常不是有价值的活动。

	主页论坛留言打印联系


	用户需要什么-软件的工程可用性（第一部分） Larry L. Constantine著，Huang Yin(yin.huang@ssmc.siemens.com.cn) 译 “究竟用户的需要是什么？”如果Fred作为一个程序员而不是一个心理学家时他可能会提出这样一个问题。用户们通常需要更多，而开发人员似乎看上去并不能很好的领会并更好的满足他们。对于我们而言，写出可靠的代码以及为系统加载一些功能看上去似乎是不够的。那么，他们需要什么呢？用户真正需要的是一个好的工具。所有的软件系统，从操作系统和语言到数据输入和决策支持应用程序，都是正确的工具。终端用户希望能从我们为其设计的工具当中获取得更多，这与我们希望从我们所使用的工具所获取得更多是一样的。他们希望系统易学易用而且能有助于他们的工作。他们希望软件不要使他们的工作放慢，不能欺骗或是迷惑他们，更不能容易出错或是难以完成任务。标准操作过程用户界面标准和可用性方针常由于对最好的用户界面的过高期望而造成极大负担。Microsoft，Sun，IBM以及Apple都已经公布了他们的用户界面标准，而且很多公司也纷纷制定出公司自己的内部使用手册来支持已发布的标准。那么这样起了多大作用呢？位于Massachusetts的用户界面工程学会的Jerrold Spool的发现，现有的标准和方针仅能覆盖现实项目中的10％的问题，定制的内部手册也仅解决了另外的10％。尽管如此，在这些标准不能够解答开发者所面临的大多数难题。有一些标准甚至是与可用性相抵触的。假设获悉男性中有十二分之一是具有不同程度的色盲，那么由此简单的规定要所有的用户界面不能有颜色。这样简单的规定有效地使有操作障碍的人得到平等对待，但也限定了用户界面是难辨认且是灰蒙蒙的。一些过去的错误中的遗留物永存于标准中，因而促成了一些构想笨拙的控件，例如滚动栏（见1994年8月的Windows Tech Journal中的“图形导航”）。或在Win3.X中想出10种关闭标准应用程序的方法。和标准一致固然好，但是武断的一致或是错误的一致并不能制造出更有用的软件。这不是个容易的任务。你知道这是很难的，主要的商务软件包经常由于一些显而易见的可用性上的不足而变得费解。甚至最大的软件开发商看上去也是更多地把精力投放在艰难的实现快速变化的特性而不是交付一份有简明的可用性的产品。并不是行业中认为可用性不重要。新的用户界面窗口小部件和GUI开发工具的广告充斥了商业杂志。关于用户界面设计的书在书店里的书柜中排列成行。所有的软件公司都详细地描述他们在昂贵的可用性试验支持下的用户界面测试程序。我们过多的关注用户界面设计--对于一些项目而言几乎是预算的三分之二--但仍然与项目的目标谬之千里。肯定在某些地方出了问题。我们可能已经论证过我们生产肥件(fat ware)的能力，但不是我们生产出更有价值产品的能力。我们在项目重压之下作出的很多好的程序代码也许会因为大多数用户今后仅使用我们费尽心思做出的产品的极小一部份而宣告浪费。奇怪的是很多这样的功能在一堆控件，菜单，对话框之中根本不可能找得到。我们结束对那些将来没有用的特性的咒骂，并且留下有用的部分。我们也由于将简单的任务复杂化而遭到谩骂。我们的一些为改进这种状况的所作的努力可能仅仅是使事情更糟。我们急切的使用最新的3D直观模型，却只得到不领情的用户的埋怨。他们读不懂我们的一个个灰色的对话框。我们用密密麻麻的带图标的工具条来告诉他们这里有很多功能，但是他们觉得这很难理解。可能当我们在第一步做了一个简单的界面之后我们会设计出改进了的界面向导来使复杂的界面易于使用。一个不漂亮的事实是可用性并不是基于这些吸引人的图形、改进了的可视化控件或是活动的Agent(译注：可能是指MS-Office里的Agent)之上。你不能从3D直观图，彩色图标或是浮动工具条中获取可用性。这不仅仅涉及你使用了什么窗体控件，还包括你如何使用这些控件，以及这些控件如何整合在一起工作。最终，可用性来自于用户界面的体系结构迎合了用户所希望的实现。这意味着你不得不通过了解用户的工作来使你的软件迎合要求。这也意味着你必须设计出整个用户界面的体系结构。这包括了用于支持这个工作的所有的结构细节以及动态行为。为了做到这些，为了在软件中设计可用性，你需要工具。你需要工具来弄清用户需要做什么和他们需要什么来支持他们工作的进行，你还需要工具来组织复杂的用户界面的体系结构而不遗漏掉任何细枝末节。或者说，你正准备好去竭尽全力制作出一起被提交的程序，你需要能够集中你的注意力，有效的利用你的时间，因为当用户抱怨时，老板会逼着你在规定期限内交付新程序。所以，你也需要一个简单的灵活的工具来组织你的工作。这篇文章介绍了一些用于制作更好的（用户用的）工具的工具――简单的用于制作出能很好的满足用户需要的小而简单的系统的方法。这当然不可能是一个完整的故事，也不能使你变成一个可用性的专家。但是这可以给你一些比较前卫的想法而使你的下一个项目有真正的改观，帮助你一开始就能制定出可用性而不是中途应要求突然改变或是最后的时候再将它加进去。围绕可用性的设计用户和用户界面的问题并不总是发生在现在。在一开始，并不存在用户，只有操作员以及只是疯狂操作电脑的程序员，他们反复操作开关并观察着操作台上的灯，并不存在给用户的真实界面。有打孔卡片，打孔带，还有打印机。你把卡片或带打上孔并不断送至读卡机，并将打印机里打印的每一页存储起来，终端用户就获得有一行行记录的报告。其中的一些内容被格式化，还被排列成多少有点可读性的序列。技术人员更注重的是技术而不是人，因此程序常在发觉用户的存在之前就形成用户界面。这样注意力被集中在技术问题上，如屏幕的绘制和域长，数据确认以及退出键的设计。偶尔也曾意识到用户，就是真正的人，正坐在系统另一端注视着屏幕，而且敲击着功能键。也许轻视和忽视用户的症状由来已久，专业通行了一种有友好的用户界面，却有平淡无味的交互的主流，往往就形成了覆盖在同样陈旧的狭隘和顽固的编程方式上的一层薄纱。为什么要问“为什么”？围绕可用性的设计是软件开发的一个相关的新的走向，它始于一个简单的问题：为什么？为什么这是必要的？为什么用户要与这个系统交互？他们想要做到什么？为何要问“为什么”？因为只有询问了用户为什么要用这个系统之类的问题才能帮助我们关注那些有关系统可用性的基本要点。为什么有人要用在线的电话目录。因为他们要联系那些他们不知道或是忘了联系方式的人。关键的设计要点是在不完全或是不精确的信息的基础上有效的设定一个系统入口。一个好的用户界面将以此作为焦点，减少操作步骤来找到号码。为什么用户要把银行卡插入自动取款机？是为了鉴别身份。带有磁性条纹码的卡是送到终端的一种方式，另外还有声波调用辨别或是红外线扫描也能达到这个目的。为什么在文档中用户要调用一个对话框用于输入一些特定的字符？因为一些符号或是字符在键盘上不存在。这个对话框会显示一些用户希望得到的字符，而不是在键盘上存在的字符。以可用性需求和被标识出的焦点事件来开始一个项目将可以节省开发时间。用户界面的体系结构将根据这些要点组织起来。开发人员可以避免在调整对可用性影响极小的特性上浪费时间，而关注更为重要的事件。转自《非程序员》第一期

	主页论坛留言打印联系


	测试、测试、测试 --软件测试的理论和实践　　题记：测试是交付成功的优质的产品的保证　我们每个人，不会都是软件测试人员，但都是某些软件的用户。缺省或默认情况下，用户都会觉得买到的软件是没有问题的，一般不会去想这样的软件可能会有问题，用户只要使用这些软件来解决他们需要解决的问题就可以了。当他们发现问题的时候，甚至会感到震惊。存在的问题很多都和测试的成效有关系，一般的软件产品存在的问题确实比较少，但我觉得即使是以前买的正版的金山快译2000都有着一些显而易见的bug。如果测试不充分，那么这些问题会潜伏在软件中，等到用户发现以后，再有开发人员进行维护，改正错误的费用一般是开发阶段的40倍到60倍。人们对测试存在着一些误区，例如： 1 测试是想象到可能出现的问题，然后试图验证这些问题。实际上能想象到的只是一部分的情况，随意性太大，还要取决于开发人员的经验，对业务的熟悉程度和他想象到的程度。 2 让时间有富裕的员工去做一些测试表面上看这体现了管理的效率和灵活性，但实际上也体现了管理者对测试的轻视。测试和测试的人有很大关系。测试工作人员应该是勤奋并富有耐心，善于学习、思考和发现问题，细心有条理，总结问题，如果具备这样的优点，做其它工作同样也会很出色，因此这里还有一个要求，就是要喜欢测试这项工作。如果他是专职的，那么肯定更有经验和信心。国内的小伙子好象都喜欢做程序员，两者工作性质不同，待遇不同，地位不同，对自我实现的价值的认识也不同，这是行业的一个需要改善的问题。如果只是为了完成任务而完成任务，或者发现了几个问题就觉得满意了，这在任何其它工作中都是不行的。 3 测试是相对简单的工作。实际上并非如此，要真正做好一件事都不容易。测试也有很多相关技术和工具。而对测试的轻视问题，也许要通过痛苦的经历和结果才可能确切体会到。很多专家都在对测试的理论进行深入的探讨和研究。测试的基本知识让我们一起快速过一遍：什么是软件测试：在软件投入运行前，对软件需求分析、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。测试的目标：以较少的用例、时间和人力找出软件中潜在的各种错误和缺陷，以确保系统的质量。从测试的类型来看，测试分为2种：黑盒测试和白盒测试。黑盒测试又称为功能测试或数据驱动测试，把系统看成一个黑盒子，不考虑程序的内在逻辑，只根据需求规格说明书的要求来检查程序的功能是否符合它的功能说明。白盒测试又称为结构测试和逻辑驱动测试，允许测试人员对程序内部逻辑结构及有关信息来设计和选择测试用例，对程序的逻辑路径进行测试。测试用例由测试输入数据以及与之对应的输出结果组成。测试用例设计的好坏直接决定了测试的效果和结果。从测试实际的前后过程来看，软件测试上是由一系列的不同测试所组成，这些软件测试的步骤分为：单元测试、组装测试（集成测试）、确认测试和系统测试。软件开发的过程是自顶向下的，测试则正好相反，以上这些过程就是自底向上，逐步集成的。单元测试（模块测试）：针对每个模块进行的测试，可从程序的内部结构出发设计测试用例，多个模块可以平行地对立地测试。通常在编码阶段进行，必要的时候要制作驱动模块和桩模块。集成测试：在单元测试的基础上，将所有模块按照设计要求组装成为系统，必须精心计划，应提交集成测试计划、集成测试规格说明和集成测试分析报告。确认测试：验证软件的功能和性能及其它特性是否与用户的要求一致。系统测试：将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试。测试工作的文档主要有：测试计划、测试模型和用例设计或规格说明、测试分析报告等。从软件工程上说，这是属于软件配置的一部分。（我不知道，如果什么报告都没有，只是不断地摆弄执行程序，看到错误和问题就记下来，算不算真正的测试？）测试需要一定的技术和工具在用例设计过程中，可以考虑到很多方面，并且也有很多的指导方法和技术。黑盒测试用例设计包括：等价类划分：划分等价类--确立测试用例--设计用例边界值分析：通过分析，考虑如何确立边界情况错误推测法：靠经验和直觉来推测程序中可能存在的各种错误，从而有针对性地编写用例。可以列举出可能的错误和可能发生错误的地方，然后选择用例。因果图：通过画因果图，在图上标明约束和限制，转换成判定表，然后设计测试用例。这适合于检查程序输入条件的各种组合情况。功能图FD：通过形式化地表示程序的功能说明，并机械地生成功能图的测试用例。白盒测试用例设计包括： 1 逻辑覆盖，以程序内在逻辑结构为基础的测试，包括以下5种类型： 1.1 语句覆盖：每一条可执行语句至少覆盖一次； 1.2 判定覆盖（分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次； 1.3 条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次； 1.4 判定-条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次； 1.5 条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值至少执行一次； 1.6 路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。 2 基本路径测试在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例。包括以下5个方面： 2.1 程序的控制流图：描述程序控制流的一种图示方法。 2.2 程序环境复杂性：McCabe复杂性度量。从程序的环路复杂性可导出程序基本路径集合中的独立路径条数，这是确定程序中每个可执行语句至少执行依次所必须的测试用例数目的上界。 2.3 导出测试用例 2.4 准备测试用例，确保基本路径集中的每一条路径的执行 2.5 图形矩阵：是在基本路径测试中起辅助作用的软件工具，利用它可以实现自动地确定一个基本路径集。程序的静态分析方法： 1 生成各种引用表、静态错误分析 2 人工测试：桌前检查、代码评审等 3 软件测试工具：包括静态分析工具、动态测试工具、测试数据自动化生成工具、模块测试台、测试合成环境 3.1 静态分析工具：语言程序的预处理器、数据库工具、错误分析器和报告生成器。直接扫描所测试的正文，对程序的数据流和控制流进行分析，然后送出测试报告。 3.2 动态测试工具：通过选择适当的测试用例，实际运行所测程序，比较实际运行结果和预期结果，发现错误。 3.3 测试数据自动化生成工具：包括路径测试数据生成程序、随机测试数据生成程序以及根据数据规格说明生成测试数据 3.4 模块测试台是一种专门的测试用例描述语言，负责将输入数据传送到所测试模块中，然后将实际输出结果与在描述测试用例的语言中所表述的期望结果进行比较，发现错误。另外，也包括其它的功能：语句跟踪、动态断句、覆盖度量、用户自定义符号表、内容表和输出格式。 3.5 测试合成环境：包括环境模拟程序，代码检查程序，测试文档生成程序，测试执行严整程序，输出比较程序，程序正确性证明程序等，以及各种调试工具。而且还有集成系统，集成了多种工具，如SADAT、Microsoft Test for Windows和PureArtria等。　 ********************************************************* 　测试的管理作为项目或产品开发的一个必要的组成部分，需要良好的组织和管理。使用软件质量规范，编写和实现测试用例和模型，可以有效地组织测试。一般的测试工作过程也可以是：计划-->配置（必要的软硬件资源下）-->开发（构造或配置测试工具、创建测试套件和测试方案库、准备适当的报告工具并记录测试系统如何运转）-->测试执行（进行测试、记录测试条件和问题，报告结果）。测试管理也可以从测试经理和测试小组2个方面去看：测试经理要管理好团队，很多人认为测试是枯燥乏味的事情，而且似乎低级的事情，所以测试经理应该不断地激励小组成员，为他们争取利益。在时间进度上保证稳步前进。就象赛跑，一开始就加班加点，只会导致极限的过早到来。作为测试经理，应该有足够的质量意识。评价质量风险的方法是“失败模式和效果分析”(Failure Mode and Effect Analysis, FMEA)。这种方法可以允许您在特定的质量风险和结果上映射需求、规范，以及项目小组假设。然后，按照风险级别进行分类，并按序排列。实际上如果能得到充分的资源已是很困难的了，能用好临时的测试人员也已经不错了。一般企业的主管和技术经理都并不怎么真正重视测试工作的意义和价值。也许他们认为临时的投入一次性的强力测试足以发现绝大部分问题，而实际上这对产品的长远发展，以及质量改进都没有太大好处。测试过程中软件功能可能进行调整和变化，测试发现问题也会导致变化，需要重新的测试。对这些变更也需要进行管理。另外，由于上层管理部门的不重视，必须想办法与之进行清楚而有效的沟通；同开发部门的沟通也非常重要，因为开发和测试在性质上是有些对立的，很容易在相互之间产生一些不必要的矛盾。和开发部门不同的是，一般质量或测试部门和市场或销售部门的立场倒是比较一致的，如果双方都认为高质量的产品是市场战略中重要的品牌战略，彻底的测试对于达到这样的目标来说意义重大。因此，有必要和市场部门保持协作和交流。测试经理可以经常问自己一些问题：计划做哪些测试？实际完成了哪些测试？使用了多少用例？其中多少没有通过？管理部门是否有足够的支持？他们是否向你要过测试报告？开发部门的联络是否及时？等等。如果你是测试管理人员，应该可以想到更多的问题。测试小组：测试小组有多大的规模，一般取决于项目规模、测试人员与开发人员的比例、项目经理对质量保证的认识和期望等，也取决于你的准确的测试计划。对一些项目来说，最好是在开始阶段就有测试人员有所介入。如本文一开始所提到的，在测试小组中测试人员必须具备的素质包括：有效的坦率真诚的交流的能力、清晰简明的表达能力、一定的好奇心（但不至于太强，以至于花太多精力去探究一个微小的问题），不应害怕提出尖锐问题引起麻烦，一定的责任心，注意力能够高度集中，是职业悲观主义者（但不是抱怨和憎恶）。以下是一些测试的方法和基本工具：测试方案、测试模型和测试用例测试就象是做实验一样，实验对于象我这样的理工科毕业生来说真是太熟悉不过了。做实验之前必然有实验的方案、内容和步骤，测试似乎也是同样的。另外，基于测试用例的测试和常见的随机性的测来测去也是完全不同的，尽管习惯于随机性测试的人，如果注意力集中的话，他的头脑里也是有一些测试用例的。关于测试实验室，进行测试工作首先要争取到尽可能好的环境。如果可能，应该建立测试实验室，实验室包括必要的装备、工具软件（包括测试工具）和各种操作系统平台，保持实验室的实用、整洁，避免他人干扰甚至破坏测试环境。关于测试跟踪软件，制作一个简单的测试问题跟踪软件，记录测试的结果，将测试发现的问题分类，并对测试发现的问题和模块、开发人员进行关联，有助于分析问题，并可有效记录测试的结果，形成测试报告，并从中找出一些规律性的东西来。因此测试问题跟踪软件还是有一定的价值的。关于测试自动化，有一定的风险。对一个稳定的系统，甚至可以自己开发自动化软件，而对于正处于快速变形中的软件开发过程，接口、主要功能和支持环境在发展变化中。为测试配置环境也要付出很多的时间。以下是关于测试的一些技巧和经验：** 在制定测试计划的时候，就要考虑到测试的风险，并抉择要执行哪些测试，并放弃哪些测试；测试计划的评审应该让开发人员参与；测试模型的制作应该尽可能贴近用户，或者站在用户的使用立场上来观测软件，此时应该能发现更多的问题。由于测试发现问题，在解决问题后还要重新测试，因此测试的时间可能会比实际更长一些识别和注意少数重要的方面，而忽略多数次要的方面，有时候少数的问题足以致命，这些问题将是软件测试结果中重要性最高的错误。错误的定位有时是很难的，要找出必然发生的前因后果，而不至于因为描述错误而误导开发人员。有时候确实存在错误不能重建的问题。解决办法之一是在错误报告中给予说明。对错误的描述，应该是准确、完整而简练。因为描述的问题或者不完整的描述会引起开发人员的误解，其后果是可以想见的。有时有经验的测试人员凭借直觉就可以发现一些问题，这可称为“错误猜测”。测试人员容易犯2种错误：一是测试人员发生判断错误，将本没有错误的系统行为报告为错误，或者将错误指定了过高的严重级别，或者过高估计了问题的严重性，这样会引起开发人员的不信任，产生一种象“狼来了”一样的效果；二是测试人员将错误的严重性或优先级定得过低，从而产生“测试逃逸”，这样会造成产品质量的风险。以上两种错误应该尽量避免。　最后，我忽然想，测试实际上可以覆盖到硬件，甚至非计算机产品的测试，也许可以相互借鉴。还有一种很奇特的感想，这种感想使我反而有些困惑不清了。我发现对测试来说，理论和实践的距离好象非常遥远，我先看了一本软件工程的书，然后写下了前面的一半内容，然后我又匆匆翻看了一本美国人的书，叫做《测试流程管理》，然后整理出了本文后一半的内容，该书中有着比本文多得多的各方面的实践经验。歌德说过，理论是苍白的，生命之树常青。我稍稍改变一下，就变成了：理论是苍白的，实践之树常青。也许测试是一种实践性很强的工作，大学教授们一般也不可能热衷于参加测试工作吧。　 Blueski 2001-9-12

	主页论坛留言打印联系


	软件复用为软件开发提速四木 (摘自《计算机世界报》) -------------------------------------------------------------------------------- 随着社会信息化程度的提高，IT技术已经深入到社会生活的方方面面，而软件作为IT技术应用的核心，其重要性也日渐突出。无论是生产制造、电子商务，还是服务咨询领域，软件都已成为担当重任的核心力量，互联网和软件已成为推动新经济发展的重要基础。那么，在新经济环境下，企业对软件的应用提出了哪些新的要求呢？“高质量、高速度和无处不在”，这是Rational公司副总裁Jim Cluchey先生的回答。他认为，在传统经济下，企业对软件的要求主要是全功能和高质量；而现在，随着竞争的加剧和客户需求的多样化，企业对软件的更新速度提出了更高的要求，过去一年更新一次的软件，现在可能是半年、三个月、甚至一个月就必须更新。另一方面，软件从过去主要用于提高生产效率、加强内部管理逐渐成为帮助企业获得更大效益的工具，也成为人们工作和生活中不可或缺的元素。无论是e-Infrastructure、e-Device还是e-Business，都离不开软件。这种变化使软件开发面临新的挑战：如何快速且高质量地开发出满足不同需求的软件？传统的软件开发方法在这时已显得无能为力了，建立更好的软件开发环境，开发和采用可复用的软件组件成为解决这一问题的最佳方法。什么是一个好的软件开发环境呢？按照Jim Cluchey先生的解释，一个优良的软件开发环境应该包括三方面的内容：采用统一的软件开发语言，特别是采用统一的建模语言；采用经过证明的软件工程管理方法；采用适当的软件开发和管理工具。首先，统一的建模语言是软件复用的基础，Rational公司提出的统一建模语言（Unified Modeling Language，UML）已经被对象管理组织（OMG）采纳并成为业界标准，利用它和其推荐的统一建模过程（Rational Unified Process，RUP），软件开发人员可以把复杂的软件系统模型化，并以此为基础完成各组件的开发；其次，大型软件的开发需要工程化的管理，源代码、版本、文档、测试等都必须进行严格的管理才能保证软件的质量；第三，目标的实现有赖于得心应手的工具，目前提供软件测试、管理工具的厂商很多，著名的国外厂商有Rational、Compuware等，国内有北大青鸟。特别是Rational公司推出的软件测试、配置管理、软件生命周期管理等工具，已经得到业界的公认，并且被IBM、Microsoft、Sun、HP和Oracle等业界巨头们广泛采用。 Jim Cluchey先生认为，软件的构件化开发和软件复用已经成为互联网时代软件开发的大趋势，同样也会被中国软件开发商和大型企业采用。因此，Rational除了为中国用户提供产品和服务外，还将寻找本地战略合作伙伴，对其系列工具进行本地化，并且通过举办讲座、发放演示软件等方式培育市场，推动中国软件开发的工程化进展。

	主页论坛留言打印联系


	可用性：软件贴近用户的重要标准计算机世界报肖春江 01-6-20 -------------------------------------------------------------------------------- 近日在各大网站上不断看到这样一条消息：金山公司软件可用性实验室落成，即将推出的影音播放软件“金山影霸”成为第一个接受严格的可用性标准测试的软件。这也是国内软件公司首次进行的绝对以用户为中心的“可用性”测试。金山公司的可用性测试是如何进行的？“可用性”测试在软件开发中所起的作用是什么？这些都是大家所关心的问题，为此，记者走访了金山公司可用性实验室。这个颇具神秘色彩的实验室建在蓝田市场研究公司内，在整个测试过程中，研究人员全程跟踪用户的一举一动。在现场可以看出，尽管用户在进入实验室以及对软件进行操作时看似轻松平常，但在与其相连的另一间观察室却是另一番景象：研究人员屏气凝神地通过屏幕观察用户的每一步操作，不断记录着掌握关键功能所花费的时间、碰壁试验的次数、发现功能的情况等测试指标。除现场观测外，所有被测试用户的使用感受及相关数据还将在市场研究公司内通过其他辅助研究方法加以验证。所有这些测试都是以一套完整而严谨的可用性体系为基础的。那么究竟什么是可用性呢？简单地说，可用性是用来衡量使用某种产品执行指定任务的难易程度的指标，它与实用性和受欢迎度等相关概念是有差异的。决定产品可接受程度的主要因素是其有用性，它用于评价产品在实际使用时是否能达到设计人员期望的目标。有用性的概念可以进一步细分为实用性和可用性。虽然这些术语之间有联系，但它们却不能相互替代。国外一些著名软件公司早就开始了对可用性的研究。IBM早在1970年就引入了可用性测试，微软公司也从1988年开始进行可用性测试。据说Windows 95在推向市场前就经过了大量的可用性测试，从而保证了该产品除了具有强大的功能和稳定的性能外，还具有很强的可用性，能够为多数人所接受，这也是Windows为什么能在短时间内风靡全球的原因之一。国内企业对可用性的研究才刚刚起步，但随着以用户为中心的开发思路越来越被认同，软件可用性概念也逐渐被大家了解和接受。据金山公司负责产品研发的经理介绍，金山影霸的可用性测试将按以下步骤进行： ● 任务观察重点是观察用户使用产品时的状况，这种方式非常简单但却有效。 ● 竞争性测试把同类产品放到一起，给测试者安排特定任务，让其用不同的产品完成。在测试过程中设置量化的指标，利用这些指标进行评估。在这里，竞争性产品不仅指同类产品，也包括一些替代品。 ● 任务分析主要分析任务的重要程度，深入探讨哪些任务是用户最经常执行的？用户的使用习惯是什么？任务的重要程度决定用户界面和常用功能的摆放位置。可用性测试常常采用启发式评估方式，它要求参加可用性测试的人员与研发人员一起回顾现场使用软件的过程并提出意见。还要评定认知的遍历性：仔细检查界面、观测用户执行了多少步骤以及何种步骤后才能完成某项任务。总的来说，可用性测试有助于增加用户对产品的接受程度。对于零售产品，用户的接受程度又往往直接影响着对产品的重复购买或对产品的忠诚度。除此之外，提高可用性还可以将产品与竞争对手的产品区分开来，如果两个产品在实用性方面相似，那么人们也会认为可用性更好的产品高出一筹。

	主页论坛留言打印联系

软件工程标准初探

冯惠王宝艾罗锋盈

计算机世界报

--------------------------------------------------------------------------------

为推动我国软件产业和集成电路产业的发展，增强信息产业创新能力和国际竞争力，带动传统产业改造和产品升级换代，进一步促进国民经济持续、快速、健康发展。国务院于 2000年7月出台了“鼓励软件产业和集成电路产业发展的若干政策”的文件。文件明确指出：“信息产业部、国家质量技术监督局负责拟定软件产品国家标准。”为了提高软件产品的质量，迅速研究并制定软件工程和软件质量体系的标准规范已成为当务之急。

1999年底，ISO/IECJTC1已制定出近40项软件工程国际标准。为了描绘软件工程领域标准之间的关系，ISO/IEC JTC1/SC7最近提出了如下两种软件工程标准体系的讨论框架，了解与研究这两种框架，对提出我国自己的软件工程标准体系是非常有益的。

1、软件工程�