songwj0806 日志(3) - 君子兰 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园

我是一支君子兰，离开生我养我的土壤，就会慢慢枯萎！

美丽心灵-----观后感

2008-01-28 13:43:42

我是在网上搜索纳什均衡时，看到以纳什为原形拍摄的影片，并且该片获得了奥斯卡金奖。

    影片《美丽心灵》是一部以约翰·纳什的生平经历为基础而创作的人物传记片。它以形象、生动的方式向我们展示了一个天才数学家、常年患有精神分裂症的诺贝尔经济学奖获得者约翰·纳什教授的内心世界。

    主人翁纳什教授早年沉溺于对数学的热爱和研究中，虽然缺乏社交技能、远离社交生活，但在学术上十分顺利，22岁时就通过论文答辩获得数学博士学位，奠定了自己博弈大师的地位。正当他学有所成时，精神分裂症却在不知不觉中降临在他身上。

    当疾病来临时，一些相关的听幻觉和视幻觉就经常出现在纳什的左右，与他讨论一些事情、命令他做一些危险的事情；等到疾病严重时，他几乎失去控制，伤害自己的亲人。这些幻觉在别人看来，是奇怪和不真实的，而对患者来讲，正如我们在现实中看到、听到的事情一样真实可信。幻想是一种个人所独有的、与自身密切相关且重要的思维方式，病后纳什深信自己正从事着机密而危险的工作，决定着美国的命运、并与世界的前途命运息息相关，不象其他的人平庸、无所作为；整日忙于整理和传递“重要资料”，妻子开始还信以为真，直至看到那些散乱无用的报纸碎片时才恍然大悟，纳什却对此仍坚信不已，苦心劝解妻子，让妻子不要受到敌对势力的蒙蔽，帮助自己从医院逃脱。随着病情的发展，纳什不断在现实生活和虚妄世界之间游移。病情严重时，全然受幻象的影响；病情轻微时，则能克制病态的想法，生活在现实之中。当纳什在疾病严重时、别人的嘲笑排斥时，总想回到虚妄的世界来感受自己的重要，回避现实的困难。在这种情况下，他的妻子更是无微不至的关心他，用自己的实际行动去感化他，告诉他什么是真的，什么才是假的。并且鼓励他多去与人交流，特别是自己以前的同学。在妻子的帮助下，他变得有勇气去面对别人的嘲笑排斥，慢慢地，他能克制自己，不再受虚幻中人物的影响。

    在患病期间，他的妻子表现出钢铁一般的意志：她挺过了丈夫被禁闭治疗、孤立无援的日子，走过了惟一的儿子同样罹患精神分裂症的震惊与哀伤……漫长的半个世纪之后，她的耐心和毅力终于创下了了不起的奇迹：和她的儿子一样，纳什渐渐康复，并重新开始科学研究，并在1994年获得诺贝尔奖经济学奖。约翰·纳什在诺贝尔奖颁奖典礼上对她妻子说：“我一直相信数学，方程式，逻辑推理，一定有它的道理。但是当我回过头想，我问我自己，什么是正确的逻辑推理，谁决定的?我探索这个问题，从肉体上，到精神上，到幻觉上再回来，然后我发现，我生涯最重要的事，这是我一生最重大的事，就是爱是一种特殊的感觉，是没有办法靠正常逻辑推理去判断的，然后我清醒了，这都是你的功劳。你是我活下去的理由，你是我的全部，谢谢！”
    影片中，妻子用她特殊的爱感染了纳什，使他从虚幻中苏醒。爱的感觉很特殊，爱可以创造奇迹。

查看(526) 评论(1) 收藏分享管理
根据数据库生成XML二法

2008-01-22 13:37:10

SqlConnection conn = new SqlConnection();
conn.ConnectionString = "Server=127.0.0.1;
User ID=sa;
Password=fdahgdrethj31313210212121;
Database=northwind;
Persist Security Info=True";
conn.Open();
SqlDataAdapter da = new SqlDataAdapter("select * from 表", conn);
SqlCommandBuilder thisBulder = new SqlCommandBuilder(da);
      DataSet ds = new DataSet();
      da.Fill(ds);
      ds.WriteXml(@"C:\temp.xml");
==============================================================================
private void WriteXmlToFile(DataSet thisDataSet) {
    if (thisDataSet == null) { return; }
    // Create a file name to write to.
    string filename = "myXmlDoc.xml";
    // Create the FileStream to write with.
    System.IO.FileStream myFileStream = new System.IO.FileStream (filename, System.IO.FileMode.Create);
    // Create an XmlTextWriter with the fileStream.
    System.Xml.XmlTextWriter myXmlWriter = new System.Xml.XmlTextWriter(myFileStream,System.Text.Encoding.Unicode);
    // Write to the file with the WriteXml method.
    thisDataSet.WriteXml(myXmlWriter);
    myXmlWriter.Close();
}

查看(593) 评论(0) 收藏分享管理
一分钟清除系统垃圾------制作垃圾清除器

2008-01-17 12:07:45

一分钟清除系统垃圾

在Windows在安装和使用过程中都会产生相当多的垃圾文件，包括临时文件（如：*.tmp、*._mp）日志文件（*.log）、临时帮助文件（*.gid）、磁盘检查文件（*.chk）、临时备份文件（如：*.old、*.bak）以及其他临时文件。特别是如果一段时间不清理IE的临时文件夹“Temporary Internet Files”，其中的缓存文件有时会占用上百MB的磁盘空间。这些LJ文件不仅仅浪费了宝贵的磁盘空间，严重时还会使系统运行慢如蜗牛。

下面是步骤很简单就两步：

在桌面上点鼠标右键，选择新建一个“文本文档”，把下面的双虚线之间的字复制进去，点“另存为”，把文件名定为“清除系统LJ.bat”就完成，记住后缀名一定要是.bat，文件类型为所有类型，好ok了！你的垃圾清除器就这样制作成功了！

==========================================================

@echo off

echo 正在清除系统垃圾文件，请稍等……

del /f /s /q %systemdrive%\*.tmp

del /f /s /q %systemdrive%\*._mp

del /f /s /q %systemdrive%\*.log

del /f /s /q %systemdrive%\*.gid

del /f /s /q %systemdrive%\*.chk

del /f /s /q %systemdrive%\*.old

del /f /s /q %systemdrive%\recycled\*.*

del /f /s /q %windir%\*.bak

del /f /s /q %windir%\prefetch\*.*

rd /s /q %windir%\temp & md %windir%\temp

del /f /q %userprofile%\cookies\*.*

del /f /q %userprofile%\recent\*.*

del /f /s /q “%userprofile%\Local Settings\TemporaryInternetFiles\*.*”

del /f /s /q “%userprofile%\Local Settings\Temp\*.*”

del /f /s /q “%userprofile%\recent\*.*”

echo 清除系统LJ完成！

echo. & pause

===========================================================

以后只要双击运行该文件，当屏幕提示“清除系统LJ完成！就还你一个“苗条”的系统了！

查看(360) 评论(0) 收藏分享管理
IT业

2008-01-17 11:53:10

IT战士英雄无畏，西装革履貌似高贵。

为了生计吃苦受累，为了存款几乎陪睡。

客户一叫立马到位，一年到头不离岗位。

劳动法规通通作废，逢年过节家人难会。

开发客户经常喝醉，不伤感情只好伤胃。

工资不高还装富贵，五毒俱全就差报废。

稍不留神就得犯罪，舍家为业亏对长辈。

身在其中方知其味，不敢奢望社会地位。

全靠傻傻自我陶醉..................

这是我在网上看到的,呵呵……

查看(395) 评论(1) 收藏分享管理
学习NAS与RAID

2008-01-16 20:13:22

NAS与RAID的对比

随着IT产品作为当前重要的信息工具大量的应用在我们日常生活、工作当中后，导致从个人到企业拥有电子数据成几何级增长，数据量的膨胀增长直接刺激各种形态的存储设备市场的蓬勃发展。近几年各存储设备生产厂商针对ＩＴ产品的消费大户之一的中小型企业对存储设备的需求研制生产出各式各样的存储设备，其中代表当前主流的两种存储设备NAS及磁盘阵列柜在各行各业得到大量的应用，近期在存储界针对NAS与磁盘阵列柜哪一种存储设备更适合在中小型企业当中应用成了他们的热门话题。事实又是如何呢？让我们一起来对这两种设备进行具体分析。

一、NAS与磁盘阵列柜的概念介绍

NAS英文全称为Network Attached Storage，可译为网络附加存储，是一种专用网络数据存储\备份器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。NAS能够满足那些希望降低存储成本但又无法承受SAN昂贵价格的中小企业的需求，具有相当好的性价比。

磁盘阵列柜

磁盘阵列简称RAID(Redundant Arrays of Inexpensive Disks)，有”价格便宜且多余的磁盘阵列”之意。其原理是利用数组方式来做磁盘组，配合数据分散排列的设计，提升数据的安全性。磁盘阵列主要针对硬盘，在容量及速度上，无法跟上CPU及内存的发展，提出改善方法。磁盘阵列是由很多便宜、容量较小、稳定性较高、速度较慢磁盘，组合成一个大型的磁盘组，利用个别磁盘提供数据所产生的加成效果来提升整个磁盘系统的效能。同时，在储存数据时，利用这项技术，将数据切割成许多区段，分别存放在各个硬盘上。磁盘阵列还能利用同位检查(Parity Check)的观念，在数组中任一颗硬盘故障时，仍可读出数据，在数据重构时，将故障硬盘内的数据，经计算后重新置入新硬盘中。而磁盘阵列柜就是装配了众多硬盘的外置的RAID。

二、NAS与磁盘阵列柜的特点比较：

１）成本比较：

磁盘阵列柜是一种很成熟的数据存储设备，对磁盘阵列应用的发展经历了纯软件、内置板卡和独立外设三个阶段，对现有的应用有两大类型：ａ、低成本的纯软件和内置板卡方式；ｂ、高成本的独立外设方式。

ａ、纯软件和内置板卡RAID成本较低，但占用主机资源，性能受限且难于优化，尤其是与应用系统没有解耦，当主机环境损毁时，若不能保证完全恢复配置，可能导致盘阵中的数据无法恢复。而NAS其本身就是一台独立的、外设的、功能强大的RAID，成本虽比纯软件和内置板卡方式略高，但不管从占用主机资源还是数据安全的角度来说，都是值得选择的。

ｂ、高成本的独立外设方式相对NAS而言，其成本差异就非常大，稳定性高磁盘阵列柜从几十万元到过百万元都有，磁盘阵列柜比较适合大型企业（集团）作为大、中型网络的中央存储、备份设备使用，NAS比较适合小型企业或个人工作室作为储存备份设备使用。

２）设置和使用方便性比较：

RAID的设置和与服务器之间的配合需要对计算机网络非常熟悉的专业人员进行管理，但NAS的使用和操作界面（如加拿大著名存储设备生产厂商自由遁为开拓中国市场专门开发出带简体中文界面的控制管理软件，大大方便国内用户的使用习惯）都很容易，不需要专业性很强的人员就能很好地管理，因此网络日常管理的成本也有很大的差异；

3）控制系统损坏后，恢复方式的比较：

RAID卡损坏后，对该存储系统可以说是灾难性的，这时你需要将硬盘取出来，交给专业的数据恢复公司进行数据恢复。而NAS硬件损坏，你可以将硬盘安按原来的排列方式装到另一台同型号的NAS上，数据就可以正常使用。

４）对操作系统的支持方面，磁盘阵列柜在异构平台的支持方面较弱，目前市面上大多数磁盘阵列柜产品通常仅仅只能支持一种操作系统，若企业内部存在两种操作系统时，如设计部门使用ＭＡＣ的操作系统，而财务部门使用WINDOWS的操作系统，当发生这种状况磁盘阵列柜在存储两个部门的数据时较麻烦；而NAS在对于处理异构操作平台方面相对于磁盘阵列柜来说具有绝对的优势，因为它能支持当前绝大部分主流操作系统的同时在一种网络下的使用即你可以同时将WINDOW、LINUX、ＭＡＣ的数据存储在NAS里面，而不需要对相关的数据作特别的处理；

５）数据备份功能方面，由于磁盘阵列柜一般采用台式机的CPU作为处理器，相对于NAS采用的嵌入式、低功耗的专用CPU来说，磁盘阵列柜在数据存储速度比NAS更快，而在数据备份方面，由于NAS采取的是专用的备份软件，数据备份采取的是更可靠、更精准的磁轨式的备份方式，这一点相对于磁盘阵列柜更具优势，同时由于NAS采取的是专门设计的备份软件，在功能方面相对于磁盘阵列柜采取的通用软件来说更为可靠，如自由遁NAS随机附带的备份软件具有易用、高效、可靠的特点；

６）从数据安全的角度来看，在正常的数据存储备份的状况下，两者均能达到较高的数据安全度，NAS是一台完全独立的设备，而磁盘阵列柜则是一台依赖服务器的设备。这意味着如果一旦服务器损坏，NAS中的数据依然可以通过其它计算机进行读取，而磁盘阵列柜中的数据则只可以在服务器修复以后才能读取。在数据安全的另一重点数据容灾方面，NAS由于不受地域的限制，更容易构建数据容灾系统，同时在灾后数据危机处理方面，NAS的应对能力更胜一筹，这也是为什么NAS在国外的中小型企业的数据容灾系统中得到大量应用的主要原因。

三、NAS与磁盘阵列柜的适用场合

１、磁盘阵列柜

由于磁盘阵列柜具有数据存储速度快、存储容量大等优点，所以磁盘阵列柜通常比较适合在企业内部的中小型中央集群网存储区域进行海量数据存储；

２、NAS

由于NAS具有不受地域限制、高扩展性、低功耗、高度自动化、高可用性群集、数据备份安全精确等特点，因此NAS企业内部更适合用于重要部门如财务、人事、客户等部门的数据存储备份的场合因为这些部门的数据通常数据量不大但不宜公开，所以保密系数相对于其他部门来说更高，在数据容灾方面，也是NAS的一个重要施展的平台。

四、小结

通过以上对NAS与磁盘阵列柜的综合对比及应用场合的细分，相信各位对于NAS与磁盘阵列柜这两种在中小型企业中得到大量应用的存储设备会有一个清晰的认识，对于它们在企业内部的正式应用，笔者建议，可将两者结合在一起使用，这样可有效提升企业内外部的数据安全，如可将磁备阵列柜用于常规性大流量的数据存储，而将NAS用于重要部门的数据备份，也可将NAS采取异地放置的方式构成企业内部的数据容灾。

查看(643) 评论(0) 收藏分享管理
有关进化实验------"Tit for Tat"

2008-01-14 14:58:32

在博弈论和组合优化理论中有一个经典的问题 ----“囚徒困境”问题（Prisoner＇s Dilemma），非常耐人回味。即选择互相合作还是互相背叛的博弈问题。

罗伯特·爱克斯罗德为了进行关于合作的研究，组织了一场计算机竞赛。这个竞赛的思路非常简单：任何想参加这个计算机竞赛的人都扮演“囚徒困境”案例中一个囚犯的角色。他们把自己的策略编入计算机程序，然后他们的程序会被成双成对地融入不同的组合。分好组以后，参与者就开始玩“囚徒困境”的游戏。他们每个人都要在合作与背叛之间做出选择。但这里与博弈论的“囚徒困境”案例中有个不同之处：他们不只玩一遍这个游戏，而是一遍一遍地玩上200次。这就是博弈论专家所谓的“重复的囚徒困境”，它更逼真地反映了具有经常而长期性的人际关系。而且，这种重复的游戏允许程序在做出合作或背叛的抉择时参考对手程序前几次的选择。

这次竞赛的桂冠属于其中最简单的策略——“一报还一报”(Tit for Tat)。它的策略是这样的：它总是以合作开局，但从此以后就采取以其人之道还治其人之身的策略。这个程序的特点是，第一次对局采用合作的策略，以后每一步都跟随对方上一步的策略，你上一次合作，我这一次就合作，你上一次不合作，我这一次就不合作。艾克斯罗德还发现，得分排在前面的程序有三个特点：第一，从不首先背叛，即“善良的”；第二，对于对方的背叛行为一定要报复，不能总是合作，即“可激怒的”；第三，不能人家一次背叛，你就没完没了的报复，以后人家只要改为合作，你也要合作，即“宽容性”。

我们一方面感慨于---The Simple is the best!这一千古不变的古训，另一方面也应总结出Tit for Tat算法胜出的几个必然因素，这些因素也是任何一个开放的网络（包括人际网络、社会网络、尤其是互联网）的固有属性：

善意（Kindness）接而强硬（Directness and Toughness）

简明（Simpleness and clearness）宽容（Openness）

好人，或更确切地说，具备以下特点的人，将总会是赢家：1．善意的； 2．宽容的； 3．强硬的； 4．简单明了的。人之出，性本善！TIT FOR TAT算法的痕迹可以被广泛发现于自然界的智能生物和非智能生物群体行为之间。

另外在进化实验中有一个值得研究的程序，即原来前15名中唯一的那个“不善良的”哈灵顿程序，它的对策方案是，首先合作，当发现对方一直在合作，它就突然来个不合作，如果对方立刻报复它，它就恢复合作，如果对方仍然合作，它就继续背叛。这个程序一开始发展很快，但等到除了“一报还一报”之外的其它程序开始消失时，它就开始下降了。因此，以合作系数来测量，群体是越来越合作的。

进化实验揭示了一个哲理：一个策略的成功应该以对方的成功为基础。“一报还一报”在两个人对策时，得分不可能超过对方，最多打个平手，但它的总分最高。它赖以生存的基础是很牢固的，因为它让对方得到了高分。哈灵顿程序就不是这样，它得到高分时，对方必然得到低分。它的成功是建立在别人失败的基础上的，而失败者总是要被淘汰的，当失败者被淘汰之后，这个好占别人便宜的成功者也要被淘汰。

那么，在一个极端自私者所组成的不合作者的群体中，“一报还一报”能否生存呢？艾氏发现，在得分矩阵和未来的折现系数一定的情况下，可以算出，只要群体的 5%或更多成员是“一报还一报”的，这些合作者就能生存，而且，只要他们的得分超过群体的总平均分，这个合作的群体就会越来越大，最后蔓延到整个群体。反之，无论不合作者在一个合作者占多数的群体中有多大比例，不合作者都是不可能自下而上的。这就说明，社会向合作进化的棘轮是不可逆转的，群体的合作性越来越大。艾克斯罗德正是以这样一个鼓舞人心的结论，突破了“囚犯困境”的研究困境。

在研究中发现，合作的必要条件是：第一、关系要持续，一次性的或有限次的博弈中，对策者是没有合作动机的；第二、对对方的行为要做出回报，一个永远合作的对策者是不会有人跟他合作的。

那么，如何提高合作性呢？首先，要建立持久的关系，即使是爱情也需要建立婚姻契约以维持双方的合作。（火车站的小贩为什么要骗人？为什么工作中要形成小组制度？换防的时候一方总是要小小地进攻一下的，在中越前线就是这样）第二、要增强识别对方行动的能力，如果不清楚对方是合作还是不合作，就没法回报他了。第三、要维持声誉，说要报复就一定要做到，人家才知道你是不好欺负的，才不敢不与你合作。第四、能够分步完成的对局不要一次完成，以维持长久关系，比如，贸易、谈判都要分步进行，以促使对方采取合作态度。第五、不要嫉妒人家的成功，“一报还一报”正是这样的典范。第六、不要首先背叛，以免担上罪魁祸首的道德压力。第七、不仅对背叛要回报，对合作也要做出回报。第八、不要耍小聪明，占人家便宜。

艾克斯罗德的一些结论在中国古典文化道德传统中可以很容易地找到对应，“投桃报李”、“人不犯我，我不犯人”都体现了“Tit for Tat”的思想。但这些东西并不是最优的，因为“一报还一报”在充满了随机性的现实社会生活里是有缺陷的。对此，孔子在几千年前就说出了“以德报德，以直报怨”这样精彩的修正策略，所谓“直”，就是公正，以公正来回报对方的背叛，是一种修正了的“一报还一报”，修正的是报复的程度，本来会让你损失5分，现在只让你损失3分，从而以一种公正审判来结束代代相续的报复，形成文明。

但艾氏对博弈者的一些假设和结论使其研究不可避免地与现实脱节。首先，《合作的进化》一书暗含着一个重要的假定，即个体之间的博弈是完全无差异的。现实的博弈中，对策者之间绝对的平等是不可能达到的。因此，程序还可以在此基础上进一步改进。其次，艾氏认为合作不需预期和信任。信任可能是对局双方达成合作的必不可少的环节。但预期与信任如何在计算机的程序中体现出来，仍是需要研究的。最后，重复博弈在现实中是很难完全实现的。

查看(1211) 评论(0) 收藏分享管理
有关遗传算法的疑问

2008-01-13 23:25:33

大家好！

我在看周明、孙树栋编写《遗传算法原理及应用》一书中有如下疑问：

一、Hollstien提出了二倍体与显性操作的双基因座显性影射方法，但我对书中的映射关系表格搞不懂（下表中红色标记）或者说我不知道它们是怎么来的。

0M

0m

1M

1m

0M

0

0

0

0

0m

0

0

0

1

1M

0

0

1

1

1m

0

1

1

1

注：每个二进制基因用两个基因来描述，一个称为函数基因，取通常含义的0或1值；另一个称为修饰基因，取值为M或m，其中M表示显性基因，m表示隐性基因。对于函数基因取值为0的基因，当两个同源染色体中至少有一个修饰基因M时，则该基因呈显性。

二、书中提到变长度染色体，在初始化时是将它的长度全定为K。这样对于缺省指定和过剩指定的，它的解码处理是怎么做的？

三、对于混合遗传算法，时模拟退火遗传算法适合解博弈论Nash均衡解，还是小生镜遗传算法适合解博弈论Nash均衡解；

四、我的论文是将改进后的遗传算法用来解求解多步博弈的NASH均衡解。今天看了遗传算法,脑海里突然冒出一个想法:遗传算法的三个算子对原有群体中个体的组织结构的改变(特别是后两个),而博弈论中的Nash均衡是在原有的策略中选优(逐步剔除非优)。这样的话，怎么能保证经过遗传算法运行后，群体中的个体就使原有中“优”的个体呢？

哪位高手能指点一二？感激不尽！

查看(795) 评论(0) 收藏分享管理
有关项目管理

2008-01-10 16:21:15

项目管理

软件项目管理是为了使软件项目能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动，从而以最合理、最有效、最经济的手段保证软件开发项目的成功完成。在软件开发中，项目管理起着重要的作用，一方面是提高质量，降低成本，另一方面，也是更重要的一点，它是软件工程化开发的前提。进行软件项目管理有利于将开发人员的个人开发能力转化成企业的开发能力，企业的软件开发能力越高，表明这个企业的软件生产越趋向于成熟，企业越能够稳定发展（即降低开发风险）。项目管理的质量与软件产品的质量有着直接的对应关系。因此，提高项目管理的能力对于软件组织软件生产力的提高是最为重要的。对软件开发的各个阶段进行管理，增强对软件开发的控制能力，提高软件开发质量，这是软件项目管理的根本目的。软件的质量高低取决于其是否符合包括功能性、可靠性、易用性、效率、可维护性、可移植性等在内的六个方面的要求。而要达到这六个方面质量要求，就必须对软件开发过程中各个环节进行全过程的项目管理，从需求分析、设计、编码、测试到上线验收进行控制。根据软件工程的生命周期，软件项目可分为项目立项、启动、需求分析、系统设计、系统开发、系统测试、系统上线、项目验收和上线后评估等9个阶段进行。加强软件项目管理，就是以软件工程的各个环节为管理主线，将动态项目管理贯穿其中，通过对软件开发的项目范围、项目进度、项目质量、项目沟通、人力资源、项目成本六大核心要素的集成管理，实现软件开发管理效能的最大化，从而大大提高软件的开发质量。

一、项目管理的组织

项目管理的组织主要对一个项目的研发队伍的确立，主要是项目经理和研发组成员的确定。项目经理作为项目工程建设的总指挥，肩负着保证工程项目质量的重任，必须要以质量立信誉，以管理求效益，强化施工现场管理。为此，项目经理的要求不光能够使小组每个成员都能发挥能力、有一定的组织能力、有提出解决问题方案的能力、对问题的理解有一定的深度、要能让成员知道软件质量的重要性，还要能对本项目有相当的经验和熟练程度，能够对本项目进行系统分析、系统设计、系统实施，制定项目的计划和管理制度，有效控制项目的实施，降低项目研发周期，提高项目产品质量的能力。小组成员要求具有团队协作精神，与本项目相关的技能和开发经验。合理的配置人员，根据项目的工作量、所需要的专业技能，再参考各个人员的能力、性格、经验，组织一个高效、和谐的开发小组，是影响对软件项目质量的决定性因素。

二、项目计划

软件项目计划是一个软件项目进入系统实施的启动阶段,主要进行的工作包括:确定详细的项目实施范围、定义递交的工作成果、评估实施过程中主要的风险、制定项目实施的时间计划、成本和预算计划、人力资源计划等。对于一个项目管理者（项目经理），他要根据系统工程的方法并结合项目的总进度要求，为系统开发制定一份工作计划，即制定出具体的工作内容与要求，落实到具体人员，限定完成时间的行动方案，并对计划的落实进行组织、监督与控制。为此，项目管理者必须制定一个足够详细的进度表，以便监督项目进度并控制整个项目。常用的制定进度计划的工具主要有甘特图（Gantt）和工程网络计划法两种。Gantt图具有悠久历史、直观简明、容易学习、容易绘制等优点，但是，它不能明显地表示各项任务彼此间的依赖关系，也不能明显地表示关键路径和关键任务，进度计划中的关键部分不明确。因此，在管理大型软件项目时，仅用Gantt图是不够的，不仅难于做出既节省资源又保证进度的计划，而且还容易发生差错。工程网络计划法不仅能描绘任务分解情况及每项作业的开始时间和结束时间，而且还能清楚地表示各个作业彼此间的依赖关系。从工程网络图中容易识别出关键路径和关键任务。因此，工程网络图是制定进度计划的强有力的工具。通常，联合使用Gantt图和工程网络计划法这两种工具来制定和管理进度计划，使它们互相补充、取长补短。

三、项目控制

对于软件开发项目而言，控制是十分重要的管理活动，是项目能够按时完成、软件产品的质量保证（SQA）的重要环节。在实际开发过程中，有一些特殊原因，导致项目开发不能如期按照项目计划进度完成，主要原因由：

1.各项开发活动的工作量是任经验估计的，实际工作量与预计数发生较大的差别。
2.开发过程中产生不少事先未估计到的活动，使工作量增加。
3.由于需求或其他情况发生变化，使已完成的成果要作局部修改，造成返工。
4.突发事性导致人员变动或环境变化。

上述导致计划不能如期进行的原因往往是不可避免的，任何一个原因发生都将造成项目开发的延误，甚至影响产品的质量。针对的不同的原因，可能采取的解决措施有：

1．对开发中的不确定性问题，事先在工作计划中留有一定的宽裕度，工作步骤的工作量取上限，预设机动时间。
    2．开发过程中经常性地与用户交换意见，随时掌握企业的发展动向，及时地明确遗留的不确定的问题，以减少返工现象。
    3．当关键路线上的活动延误时，及时调配现有开发人员，或增加开发人员或加班加点，或集中人力予以重点解决。
    4．在上述措施难以有效解决延误问题时，对原定计划作适当的调整。

四、运行管理

运行管理是使项目系统在其生命周期内保持良好的可运行状态，保证其功能的发挥。主要围绕以下三个方面的任务展开：

1．系统测试

系统测试是对系统进行全面的测试，应在测试环境中进行，以确保系统的功能和技术设计满足企业的业务需求，并能正常运行。在测试环境中，项目组根据需要进行单元测试、集成测试、系统测试和验收测试等，记录测试结果并由相关测试人签字确认，编制相应的测试报告。对于未通过测试的内容，项目组应查找失败的原因，并修改相应程序或设置，重新进行测试。除了进行充分的系统功能测试，测试应包含与内部控制相关的测试内容，如系统认证和授权、交易完整性及数据真实、完整性的有关功能。提交测试报告、用户确认签字。项目组撰写测试报告，将测试报告提交给各相关用户，用户应在测试报告上签字确认。

2．日常运行管理

日常运行的管理是系统投运后最主要的与最频繁的工作，其目的是使系统能始终保持良好的可运行状态。系统的日常运行管理具体有系统运行情况的记录、系统运行的日常维护及系统的适应性维护。系统运行情况记录主要是记录系统的运行过程中的功能使用情况。系统运行的日常维护主要是对一个故障的诊断与排除以及对突发事件的解决。系统的适应性维护是对系统在运行过程中所暴露出的问题给予及时解决，同时为适应环境的变化及克服本身存在的不足对系统作调整、修改与扩充。系统的适应性维护是一项长期的有计划的工作，并以系统运行情况记录与日常维护记录为基础，其主要内容有：系统发展规划的研究、制定与调整，系统缺陷的记录、分析与解决方案的设计，系统结构的调整、更新与扩充，系统功能的增设、修改，系统数据结构的调整与添置，系统维护的记录及维护手册的修订等。

3．系统文档的管理

软件系统实际上由系统实体与此对应的文档两大部分组成，系统的开发要以文档的描述为依据，系统实体的运行与维护更需要文档来支持。没有系统文档，系统的开发、运行和维护将处于一种混沌状态，严重影响系统的质量，甚至导致系统开发或运行的失败，特别当系统开发人员发生变动时，系统文档显的尤为重要。

具体文档要视公司视项目而定。有些公司嫌文档管理费时费力耗财而不做这方面的工作,是不可取的。

工程进度表

从软件工程的角度讲，软件开发主要分为六个阶段：需求分析阶段、概要设计阶段、详细设计阶段、编码阶段、测试阶段、安装及维护阶段，并在各个阶段都有相关书面的文档输出。不论是作坊式开发，还是团队协作开发，这六个阶段都是不可缺少的。可以根据公司实际情况，公司在进行软件项目管理时，可以有重点进行管理或加入、删除一些不必要的内容。

查看(443) 评论(0) 收藏分享管理
实现Office 2007免序列号安装

2008-01-09 18:14:50

手动修改方法，现将安装程序中的Config.xml解压出来，如果使用了虚拟光驱，直接复制出来便可，专业版和企业版路径有所不同：

专业版是ProPlus.WW\Config.xml

企业版是Enterprise.WW\Config.xml

以下表示为XXXX.WW\Config.xml

可以参考官方网页

我们用记事本打开Config.xml，找到以下一行



PS多出来的空格不用理会因为网页无法显示

使用正确有效的序号取代上述"BCDFGHJKMPQRTVWXY2346789B"引号内部分，并去除后变成以下格式：

<PIDKEYValue="XXXXXXXXXXXXXXXXXXXXXXXXX"/>

其他文件不做修改，仅仅修改Config.xml即可。

然后使用UltraISO等编辑光盘映像的工具将修改后的Config.xml替换掉原来的Config.xml，保存或者刻盘后便可达到免输序列号！

查看(281) 评论(0) 收藏分享管理
转载：工作习惯

2008-01-08 18:02:27

有许多方法可以帮助我们明确工作思路提高工作效率，例如个人的工作习惯、团队力量、企业中有一套完整软件等，首先要明白，效率的关键在于良好的工作习惯，而不是学会一两个方法，这决非一日之功.

1.每天提前15分钟上班，推迟15分钟下班
提前15分钟上班，把今天的工作做个列表式的计划
推迟15分钟下班，总结一下今天的不足，计划明天的工作

2.选择好自已办公的工具，熟悉其性能——电脑、办公软件、电话等,结合工作重心，发挥自已办公工具的最大作用。

要分清你大多时间做些什么工作。顿挫的工具会使你事倍功半，锋利的工具会使你事半功倍。

3.让自已的办工桌面变清爽

文件归类，常用的东西放一定的位置等公司桌面上最难找到的是什么？（笔+记事本）
    如：一客户打电话来，希望你记录些东西，但你一时半刻找不到笔或记事本。还让他“你稍等下，等下噢…”接下来就是四处寻找……是不是你也遇到这样的问题呢？如果让客户知道你对自已办公工具都遗失，那他又能指望你能帮到他什么呢？

4.永远坐在前排

不管是开会还是培训，都在要坐在最前排。
20世纪30年代，在英国一个不出名的小镇里，有一个叫玛格丽特的小姑娘。玛格丽特自小父亲经常向她灌输这样一个观点：无论做什么事情都要力争一流，永远在别人前面，而不落后于人，“即使坐公共汽车时，你也要永远坐在前排”。父亲从来不允许她说“我不能”或者“太困难”之类的话。对于年幼的孩子来说，父亲的要求可能太高了，但他的教育在以后的年月里证明是非常宝贵的。这种“残酷”的教育，培养了玛格丽特积极向上的决心和信心。无论是学习、生活、工作，她时时牢记父亲的教导，总是抱着一往无前的精神和必胜的信念，克服一切困难，做好每一件事。
     ——玛格丽特40年后，她连续四年当选英国保守党领袖，成为英国第一位女首相，雄踞英国政坛11年之久，被世界誉为“铁娘子”，她就是我们非常熟悉的玛格丽特.撒切尔夫人。

5.随时记录

随时记录下自已的工作想法,对事的观念,把它贴在自已最易看到的地方,时常提醒自已。

6.克制抱怨

克制抱怨是把造成自己处境的责任推到别人身上从而减轻自己心理压力的一种倾向。

为什么我们那么顽固地坚持这样一种习惯，总是寻找别人的缺点而看不到别人优点呢？看一件事情为什么只看到负面的东西呢？儿童时代我们还不太会想到抱怨和批评别人，因为我们觉得自己做的不好，认为父母大人不可能有错; 可是到了成人阶段，我们知识进步的结果就学会了发现别人有错，而自己不可能有错了。人们之所以喜欢抱怨，因为这样做可以潜在给我们带来道德上的优越感，我们通过抱怨别人可以比通过做好我们自己的工作能够更快更直接地带来心理上优越感的满足。

如果我们想更积极更有效地实现自己的价值，就应该训练自己克制从抱怨别人行为中寻找满足的冲动。从这样的行为中得到的满足只能是虚幻的满足，而且由于容易得罪人，对我们个人的发展会带来更大的障碍。训练自己做到停止抱怨并不容易，需要克服人性弱点。人们喜欢快乐积极的人并愿意花时间与之相处。如果你让人害怕，别人不愿意见到你，你也会很郁闷。所以我们要学会选择积极状态，从所遇到的人和事上寻找好的一面，发现优点，发现机会。为什么要这样做？因为你寻找什么，你就会得到什么。你关注什么，你就会吸引它们到你自己身上。虽然思想上知道抱怨的行为不健康，但根深蒂固的行为习惯是需要下决心花时间克服的。当我们一旦觉察到抱怨别人的行为就要并立即停止。当我们养成了自我警惕的习惯，就可以有效地克制这种人性弱点。

7.克服人类的天敌——惰性

“这件事我一定要做了，真的要做了，现在太累了，休息下，再等一会儿再做”
   “先听下音乐放松下，聊下QQ”
   “唉！这件事还是明天再做吧”（人的一生只有今天，明天不会来）

我们每个人都会有这样的经验，一些事情需要我们完成，而惰性往往占了上风。如何能克服惰性去完成任务：

肯定辛苦的过程，更看重的是愉快的结果,如同我们喜欢吃到美食而不愿去洗碗筷一样。渴望成果却不愿意忍受痛苦的过程。

提高对辛苦的承受能力,如举重锻炼一样,开始是举起自已能承受的重量,之后每天加一点,每月增至几公斤,久而久之, 被举的重量就上来了.

大事化小,把复杂的事情简单化,大的事情最小化,找到事情的突破口,（意志是克服惰性的一种力量）。

8.勇于承认错误不找借口

当同事或领导指出你某件事做的不理想、不正确时，

你总会说：
“我认为….”
“我以为……”
“我想应该是这样…..”

其实回想起来，错就是错了。“认为、以为、我想应该是这样”，这些都是在找理由找辩解！错就是错了，勇于承认错误，负起自已责任。

凡事第一反应：找方法，而不是找借口,借口与成功永远不会同住一屋檐下。

9.不要出口伤人（打击别人）

打击他人其实也是个人心里不平衡的一种释放：在某种程度上，对方的想法（做法）超过或者是突破了你个人的思维方式，但为了体现自已的实力或重要性，人有一种“否认对方的同时，来肯定自我的价值的表现”。

说话之前，先考虑一下对方的感受,即使你平常与同事相处很好，但一句打击的话，通常可产生两种效果：
    一、他会对你产生反感，因为你不尊重他个人的思路或成果，无条件地否定了他。
    二、如果你一直是他工作中的偶像，那你可能会使他丧失信心。

我们换种方式：你的方案确实不错，尤其第5条非常切合实际。。。。。（让他接受你的同时）如果把第2条改成***样，这样即人性化，又能很好地体现我们工作热情度。你觉得这样效果怎么样呢？

学会肯定的同时再指出不足

10.换位思考

一只小猪、一只绵羊和一头乳牛，被关在同一个畜栏里。有一次，牧人捉住小猪，牠大声嚎叫，猛烈地抗拒。绵羊和乳牛讨厌牠的嚎叫，便说：“他常常捉我们，我们并不大呼小叫。”小猪听了回答道：“捉你们和捉我完全是两回事，他捉你们，只是要你们的毛和乳汁，但是捉住我，却是要我的命呢! ”
    立场不同、所处环境不同的人，很难了解对方的感受；

对别人的失意、挫折、伤痛，不宜幸灾乐祸，而应要有关怀、了解的心情。要有宽容的心！

11.懂得谦虚

谦虚是一切伟大灵魂共有的品质

美国著名政治家、科学家富兰克林拜访一位前辈，当他从小门进入时，由于门框低矮，他被狠狠地撞了一下。出来迎接的前辈笑着对他说：“很疼吧，可是，这应该是你今天最大的收获。你要记住，要想平安地活在世上，你就必须时时记住学会低头。”什么时候应该低头？那就是犯错误时、有求于人时，有成绩时。

古人云：山外有山，天外有天，当你傲视同事或上级时，你已经被某些人孤立了，得不到同事的欢迎？海之所以大，在于它是所有河流的最低处

12.善于倾听

卡耐基曾说过:如果你希望成为一个善于谈话的人,那就先做一个注意静听的人，要使人对你感兴趣:那就先使人感兴趣.问别人喜欢回答的问题,鼓励他谈论自已及他所取得的成就.

不要忘记在与你谈话的人,对他自已、他的需要、他的问题，比对你及你的问题要感兴趣100倍。他注意他颈上的小痣比注意非洲的40次地震还要多！

在与同事交谈时，要注意倾听他的讲话，并给予适当的反馈。聚神聆听代表着理解和接受，是连接心灵的桥梁。在表达自己思想时，要讲究含蓄、幽默、简洁、生动。含蓄既表现了您的高雅和修养，同时也起到了避免分歧、说明观点、不伤关系的作用，提意见、指出别人的错误，要注意场合，措词要平和，以免伤人自尊心，产生反抗心理。幽默是语言的调味品，它可使交谈变得生动有趣。简洁要求在与人谈话时掌握该说的说，不该说的不说。与人谈话时要有自我感情的投入，这样才会以情动人。此谓之生动。当然要掌握好表达自己的技巧，需要不断的实践，并不断的增加自己的文化紊养，拓宽自己的视野。

13.好的工作方法一定要懂得用方法与同事分享

互相交流信息、切磋自己的体会都可融洽人际关系

如果你直接把自已好的工作方法与他人分享，在一定程度你就变为重要的人物了，他人不一定能完全接受你，因为人天性有个爱好，就是喜欢别人重视自已，所以分享的前提，我们要找对办法。

巧妙地把重要人物设为第三方

如：发现她花了很长的时间从一张表格中提取数据，但你有个更好的公式时。你可礼貌对他说“朋友教给我一个不错的数据提取公式，不防你也试试”相信他巴不得马上学会，因为他现在这种工作方式累的够呛了，出自人的惰性，当然要找个更简单的办法，重要的是你把重要人物设为第三方，而不是你们之间的对比！

一个苹果交换一个苹果，还是一个平果，一个经验交换一个经验，就成了两个经验！

14.保持工作焦点和热情

每天早晨先确立今天的目标，让工作焦点清晰，然后以最大的热情地去做。学会调整工作状态，用积极的意识去激发热情；想办法避免干扰。各种兴趣爱好很影响工作状态，把它们放到合适的孤立的时间段，例如午餐之后午休之前，或者重要工作完成之后，不要放在重要时间段之前。

15.工作前要建立框架意识

工作前要在脑海中建立“框架”意识，凡事问题要简单化；

每项工作前有3件事要做：沟通、预案、检查是否有遗漏；

一、工作前你将要做好哪些沟通事项？

二、从不同层面来考虑某一个具体问题，提前做出预案。如：哪些会给他人带来不便？

三、再次回想，有什么事情还没有想到，但必需要去做？

16.建立工作列表
随时记下要做的工作，所有事情一目了然。
注意：区分轻重缓急，先做重要的事情，注重效率更注重效果。
设置并重视完成期限，就像对自己的承诺。
具体明确，如果太大就分解成简单的工作。

这一方法比较容易，大多数人都可以使用。既减少记忆，又避免遗忘。能快速着手工作。有效利用琐碎时间。

17.利用日程安排

当工作列表上的工作很多，让你感到烦乱的时候，就要考虑使用日程安排了。

日程安排与工作列表的不同在于，工作列表只是说明要做什么，而日程还确定了按什么顺序去做，什么时间去做。养成制定日程的习惯有些难度。我们可以：
     先从时间已确定的事务开始，例如会议、会面等。

逐渐培养日程安排能力，根据个人习惯，将事务安排在合适的时间。不要安排得太满，留下必要的缓冲时间。相似的工作在一起，尽量减少角色的变化。特别要养成习惯，随时利用琐碎时间做一些琐碎的小事。

18.怎样做好与客户的沟通：（首先要做的是：分析客户心里，他想要的是什么？）

答应客户的事情及时做到，即使不能完成，也要提前通知顾客，不能保证完成的不要轻易答应。

每天上班前适当时间给客户一个电话，对今天的工作提示如：要补些什么货品等？

下班前给客户一个电话，问是否还有哪些地方没有做好的等

此外还要对你所服务的客户做些了解；比如生日，家里老人、孩子等情况，当生日时给予祝福，过节时给老人一声问候（学会关心他人，他人才会来关心你）

切记，不要忘记说些客套话，肯定与赞美他人，不要吝啬自已的微笑负起自已的责任，建立好在客户心中的诚信感

19.不要害怕浪费时间

工作中有个难题,想去花时间搞清楚吧？又怕浪费时间！

切记，只要开始做就不可能是完全的浪费，哪怕失败多次也是有价值的，每次从失败中我们都可以获得很多经验。最为重要的是：在尝试中，我们除了获得失败，还能获得很多经验。

20.勤于观察

理清楚哪些是自已工作重点

重心工作自已能否胜任，为什么不能胜任？是自已方法不对，还是工作的“工具”本身存在欠缺。如果方法不对，你可借鉴同事的方法，因为他生活在你的身边，他的方法你当然易学会，学会观察优秀的同事，他一天中所做的事情，比如：行动，与客户对话中的言语，面部表情与肢体语言等，对一个突发事情的处理…..如果这些你都作到了，你不仅是学会了“观察他人”更为重要的是你学会了处理事情的另一种方法-----借鉴。

21.改良自已的工作方式

不要把自已搞的太忙一样，如果自已是个大忙人，可见你要更新自已的工作方法了----提高工作效率。一个大忙人，连与别人说句话的时间都好像没有，想必工作上会让你非常烦恼。

我们来找下原因：

是你所管辖的客户太多而烦忙？还是相比之下客户太难搞定呢？还是自已的工具不实用？可能你会说“我的客户确实太难搞定”如果有这样观念，就是分别的客户给你，也会是这样的。

犹如“汽车”的发展史一样，如果人类不去大胆多次尝试改进，可能还是坐着卡尔.本茨造出的第一辆三轮汽车以每小时18公里的速度，跑到现在。对工作方法，要改进、改进、再改进



22、独立思考，学会自已想办法解决

学会与同事之间的相处时刻要记得：助人是一种美德！同时才能得取他的信任感配合好同事的工作做好一项工作，经常要与别人合作，在取得成绩之后，要求共同分享，切忌处处表现自己，将大家的成果占为己有。提供给他人机会、帮助其实现生活目标，对于处理好人际关系是至关重要的。



23.怎样减轻自已的压力

印度有一个师傅对于徒弟不停地抱怨这抱怨那感到非常厌烦，于是有一天早上派徒弟去取一些盐回来。当徒弟很不情愿地把盐取回来后，师傅让徒弟把盐倒进水杯里喝下去，然后问他味道如何。徒弟吐了出来，说：“很苦。”师傅笑着让徒弟带着一些盐和自己一起去湖边。　　他们一路上没有说话。来到湖边后，师傅让徒弟把盐撒进湖水里，然后对徒弟说：“现在你喝点湖水。”徒弟喝了口湖水。师傅问：“有什么味道？”徒弟回答：“很清凉。”师傅问：“尝到咸味了吗？”徒弟说：“没有。”然后，师傅坐在这个总爱怨天尤人的徒弟身边，握着他的手说：“人生的苦痛如同这些盐有一定数量，既不会多也不会少。我们承受痛苦的容积的大小决定痛苦的程度。所以当你感到痛苦的时候，就把你的承受的容积放大些，不是一杯水，而是一个湖。”

压力的反应在于我们自己的意识，而责怪环境或公司肯定无济于事。所以，面对压力最好暗示自己，激发积极兴奋的心态。如果公司采用了任务管理制度，使工作更透明，责任更明确，完成期限也作了明确规定，这会给人一种压力。应该适当利用这种压力，而不是消极抵制。养成高效的工作习惯于己于人都有利。

启示：工作中的压力同这些盐有一定数量，既不会多也不会少。我们承受压力的容积的大小决定压力的程度。所以当你感到压力的时候，就把你的承受的容积放大些，不是一杯水，而是一个湖。

24.立即行动,速度第一

科学家们曾做过这样一个实验。在只有窗户打开的半密闭的房间里，将6只蜜蜂和同样数目的苍蝇装进一个玻璃瓶中，把瓶子放平在桌上，瓶底朝着窗户。然后，观察蜜蜂和苍蝇会有什么样的举动。科学家们发现，蜜蜂们会不紧不慢地在瓶底徘徊，认为能找到出口，直到它们力竭倒毙或饿死；而苍蝇们则会不停地在瓶中“横冲直撞”，在瓶中的飞行速度明显高于蜜蜂，不到两分钟之内，他们穿过另一端的瓶颈逃逸一空。蜜蜂们以为，囚室的出口必然在光线最明亮的地方，一定会找到出口。于是，它们不紧不慢地行动着，等待它们的结果是死亡。而苍蝇们却成功地逃离了，这并不在于它们有什么特长，也不在于它们懂得快速行动、求得生存。

不要花太多时间整理和规划，不要觉得没把所有事情安排好就无法开始一样。只着眼于整体会让你看到做这件事多难多辛苦，你应该找出可以付诸行动的小的突破点，马上开始行动

25.脑海计划

史蒂芬・柯维曾提到：所有的事情都经过两次的创造：先是在脑海里酝酿，其次才是实质性的创造。

一提到工作计划，大家一定想到的是纸上写某某时间要以什么方法做什么事情将达到什么样效果……

我们的工作计划首先可尝试不用写在纸上，我们要把它印在脑海中，这样会时刻明确工作方向与方法，多次酝酿,当主管问起你的工作计划时，可回答道：我的工作计划是……如果他自已记不下来，就让他用笔去记去吧…….

计划：明确自已计划的核心所在，用多长时间完成什么项目达到什么样的预期效果，计划开始不易过多，比如本第一次2条，下一次3条…..这样锻炼下去，你做什么事情前，脑海中会自动产生一个计划（将计划的细节与你的领导做个汇报，让他提出几点意见，毕竟，人家比你经历的多，同时能让上级了解你的工作状况）

26.纸张计划：

工作计划是为提高工作效益减轻自已工作量而做，并不是为了应付他人拿来写写常见的有日计划周计划、月计划、季度计划、年度计划等。

我们采取最简洁明了的方法，列下计划框架，当然可以用口途的方法与领导叙述一翻。翻翻你的以前所做的计划，看看达成没有，为什么没有达成，在笔记中分析原因没有。

没完成计划：在笔记中再写出上周工作计划，列出当初的方案，回故失败的地方。

找出三个以上别的可行方法，把每个方案再明细化，你可把每天想到的，遇到的与方案相关的写在“明细表”中，不久，发现明细不少时，你再回顾，期初在错误在哪了吧？

虽然方案一样，但执行的细节不一样，结果当然也是不一样。细节决定成败。

27.每天下班前用5分钟做一天的整理工作

把今天未完成的工作、完成的工作、明天将要做的工作做整理，把今天的单据、表格、数据等做个归类存放，舍去不要的。

方法：先实行淘汰再归类整理

比如：先淘汰对工作不起作用的东西：（学会舍弃）

　　1.桌面上很久没用过的表格等，简直快忘了它的存在。
　　    2.有些表格与数据根本不合理，用起来费时没效率。
　　    3.去除那些难以理解复杂的工式，寻找简单实用的。
　　    4.重复的东西，去除。
　　

28.时常总结分析

“以心情变化为期段的非纸张总结”

在这，没有提到每天、每周等总结？

“时常总结”并不是要写在纸上，哪天纸不见了，总结也随之不见，我所倡导的是“以心情变化为期段的非纸张总结”因为心情变化，那一定有与平常不一样的事情发生。

方法：一杯咖啡或一杯茶+一个宁静的地方（比如自已的床上）+一个易思考的姿势。这样让你学会放松自我的同时做分析，此环境中大脑才能清楚地回忆每一个已发生故事的片段。

步骤：首先进行回忆工作中哪些问题出现？

           其次当时我采取了什么工作方法？（脑海中画个叉，因为是错误的）。试用返推法，如果想不出来，可追忆曾经那时的成功：请回想当初同事或领导称赞你的情形,为什么称赞你,而不是别人,对！因为你某事做的很棒,得到大家的肯定与信任.你帮他们修好了电脑、打印机、你帮他们解决了一个公式运用上的问题等等，后来同事都很配合你的工作，发现那时候的问题很好地迎刃而解了。那么你就试用着以前对待事情的办法与态度，对待现在的事情。或者采取换位思考，换位思考其实就是换个立场去看待问题,正所谓"横看成岭侧成峰,远近高低各不同，换位思考可以让我们明白主管的辛酸与不易，让我们体会同事的关爱．．．．．．让我们多一些理解，少一分抱怨．把方便留给别人，困难留给自己，我们的工作开展起来也就会更加得心应手。打破现在的思维方式，找到曾经对待事的办法可能对你有所帮助。

29.适当了解其它部门工作细节

不仅了解本部门的细节，也要适当了解其它部门工作细节

工作见过很多同事,时常会指着别的部门说“那些鬼,不知在忙些什么？………..”如果这样，你又怎能做好接口部门工作呢？

往往这样，看特事情不全面，也会做出错误的评价

30.坚持不懈

坚持不懈与充分的自信一样，都是取得成功的必备素质,当工作一半遇到挫折就止步不前,怎么又会达到成功呢?

有一个士兵，要经过一个大沙漠到另一边去。他带着食品朝他的方向走去，他在沙漠里走了七天七夜，眼看就只乘下一天的食品啦，他就想反正也走不出去了，倒不如干脆把乘下的最后一天的食品吃掉，也省得去累，于是他坐在那里把最后一天的食品吃完了。后来，他的战友经过此地找到了他的尸体，发现其实他只要再走一天的时间就可以到达他的目地地了，因为从他那到绿洲只有几十里路。

如果你想与众不同，如果你想工作中取得成就，那么你要拥有的最重要的素质就是你能够比任何其他人坚持得更久的能力。这正如有人挖井找人，很多人挖了深浅不一的井，没有找到水就放弃了，只有一人坚持往下挖，挖的比别人都深，最后出水了。只要坚持才能见到效果，只有坚持才能走向成功。

31.懂得付出的人你才是最大的赢家

每当同事调休或因事请假，您是否做到主动要把他担当一天的工作呢？

要替他人着想还表现在当他人遭到困难、挫折时，伸出援助之手，给予帮助。良好的人际关系往往是双向互利的。您给别人的种种关心和帮助，当您自己遇到困难的时候也会得到回报。只有懂得帮助他人的人，别人才会同样帮助你！

查看(326) 评论(0) 收藏分享管理
软件测试执行中的策略

2008-01-08 16:11:53

对于大型项目，软件测试的执行，除了需要很好的测试范围分析、测试计划制定和测试资源的分配与组织之外，还有就是测试策略问题。

我们都知道软件测试是为了找出那些不能正常工作、不一致性的问题，即测试的一般工作就是发现缺陷 (detect bug)，当然这些缺陷包括需求分析、设计等的缺陷，不仅仅是程序中的运行。测试的启动和项目启动是同时发生的，测试的重要工作是在测试用例的设计，这是随后测试执行的基础。同时，我们应该承认，测试的主要工作是在测试的执行，当自动化测试工具在功能测试中发挥作用比较困难时，测试执行的工作量还是很大的。

如何更早地发现缺陷又不增加风险？测试的本质是什么，发现缺陷还是风险评估？如何引导大家向着一个目标——产品及时高质量发布努力？

1. 首先就要向测试人员灌输一个概念——“测试的一般工作就是发现缺陷 (detect bug)”，达成共识，这是很重要。这样，测试人员，就知道什么是自己真正的工作。这一点，不仅在测试执行时发挥作用，而且在设计测试用例时更能发挥作用。

2. 测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家就是找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍——使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，要不顾风险，就是发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。

3. 在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率以极大降低风险、获得更高质量的收益。

4. 在前一阶段，测试用例的执行速度要低一些，测试人员多思考，多做些ad-hoc 测试，这样又帮助提高测试用例的质量，从而对随后的回归测试提供了更有力的保障。

5. 测试执行要进行有效监控，包括测试执行效率（缺陷数/KTC, KTC = 1000 test cases）、Bug历史情况和发展趋势等。根据获得的数据，必要时对测试范围、测试重点等进行调整，包括对测试人员的调整、互换模块等手段，提高测试覆盖度，降低风险

6. 测试总是是有风险的，正是始终存在的风险，使之测试更具有艺术性。

查看(422) 评论(0) 收藏分享管理
软件测试策略基础

2008-01-08 16:06:44

软件测试策略基础

1、策略与软件测试策略

1）策略：在一定的政治路线指导下，根据具体条件而规定的斗争原则、方式和方法。
    2）软件测试策略：在一定的软件测试标准、测试规范的指导下，依据测试项目的特定环境约束而规定的软件测试的原则、方式、方法的集合。

2、软件测试策略的重要性

1)任何一个完全测试或穷举测试的工作量都是巨大的，在实践上是行不通的，因此任何实际测试都不能保证被测程序中不遗漏错误或缺陷；
    2)为了最大程度较少这种遗漏，同时最大限度发现可能存在的错误，在实施测试前必须确定合适的测试方法和测试策略，并以此为依据制定详细的测试案例。

3、软件测试策略的目的

不是所有软件测试都要运用现有软件测试方法去测试。依据软件本身性质、规模和应用场合的不同，我们将选择不同测试方案，以最少的软硬件、人力资源投入得到最佳的测试效果，这就是测试策略的目标所在。

4、软件测试策略的影响因素

软件测试策略随着软件生命周期的变化、软件测试方法、技术与工具的不同发生的变化。这就要求我们在制定测试策略时候，应该综合考虑测试策略的影响因素及其依赖关系。这些影响因素可能包括：测试项目资源因素、项目的约束和测试项目的特殊需要等。

5、软件测试策略的制定过程

1）输入:
需要的软硬件资源的详细说明；
针对测试和进度约束而需要的人力资源的角色和职责；
测试方法、测试标准和完成标准；
目标系统的功能性和技术性需求；
系统局限（即系统不能够提供的需求）等等。

2）输出:
已批准和签署的测试策略文档、测试用例、测试计划；
需要解决方案的测试项目；

3）过程:

①确定测试的需求¤
测试需求所确定的是测试内容，即测试的具体对象。在分析测试需求时，可应用以下几条一般规则：
    测试需求必须是可观测、可测评的行为。如果不能观测或测评测试需求，就无法对其进行评估，以确定需求是否已经满足。
    在每个用例或系统的补充需求与测试需求之间不存在一对一的关系。用例通常具有多个测试需求；有些补充需求将派生一个或多个测试需求，而其他补充需求（如市场需求或包装需求）将不派生任何测试需求。
     测试需求可能有许多来源，其中包括用例模型、补充需求、设计需求、业务用例、与最终用户的访谈和软件构架文档等。应该对所有这些来源进行检查，以收集可用于确定测试需求的信息。

②评估风险并确定测试优先级¤
成功的测试需要在测试工作中成功地权衡资源约束和风险等因素。为此，应该确定测试工作的优先级，以便先测试最重要、最有意义或风险最高的用例或构件。为了确定测试工作的优先级，需执行风险评估和实施概要，并将其作为确定测试优先级的基础。④⑤⑥⑦

③确定测试策略¤
一个好的测试策略应该包括：实施的测试类型和测试的目标、实施测试的阶段、技术、用于评估测试结果和测试是否完成的评测和标准、对测试策略所述的测试工作存在影响的特殊事项等内容。
    如何才能确定一个好的测试策略呢？我们可以从基于测试技术的测试策略、基于测试方案的测试策略两个方面来回答这个问题。

a.基于测试技术的测试策略的要点:
著名测试专家给出了使用各种测试方法的综合策略：
任何情况下都必须使用边界值测试方法；
必要时使用等价类划分方法补充一定数量的测试用例；
对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，看是否达到了要求；
如果程序功能规格说明中含有输入条的组合情况，则已开始可以选择因果图方法。

b.基于测试方案的测试策略:
对于基于测试方法的测试策略，一般来说应该考虑如下方面：
    根据程序的重要性和一旦发生故障将造成的损失来确定它的测试等级和测试重点；
    认真研究，使用尽可能少的测试用例发现尽可能多的程序错误，避免测试过度和测试不足!

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

遗传算法查找资料集合

2008-01-08 09:38:13

遗传算法简介
遗传算法是一类模拟生物进化的智能优化算法，它是由J.H.Holland于六十年代提出的。目前，遗传算法已成为进化计算研究的一个重要分支。
与传统优化方法相比，遗传算法的优点是：
·群体搜索
·不需要目标函数的导数
·概率转移准则
遗传算法研究热点
·收敛性证明
·新型高效的遗传算子设计
·遗传算法与局部优化算法的结合
·遗传算法在各领域的应用研究
·软计算与计算智能中的遗传算法
遗传算法著作
1.陈国良等，遗传算法及其应用，国防出版社
2.J.H.Holland,Adaptation in Natural and Artificial Systems, Ann Arbor: Univ. of Michigan Press, 1975
3.D.E.Goldberg,Genetic Algorithms in Search, Optimization and Machine Learning. Reading, MA: Addison-Wesley, 1989
4.L.D.Davis, Handbook of Genetic Algorithms, Van Nostrand Reinhold
5.Z.Michalewicz, Genetic Algorithms + Data Structures=Evolution Programs, Spinger Press,1996
6.M.Gen,R.Cheng,Genetic Algorithms & Engineering Design, 1997
7.Wiely,Genetic Algorithms in Engineering and Computer Science,1995
8.M.Mitchell,An Introducion to Genetic Algorithms,1996
9.Davis,Genetic Algorithms and Simulated Annealing,1987
10.Davidor,Genetic Algorithms and Robotics,1991
11.Koza,Genetic Programming,1992
12.Bauer,Genetic Algorithms and Investiment Strategies,1994
遗传算法站点
1.The Genetic Algorithms Archive http://www.aic.nrl.mil/galist/
2.Genetic Adaptive Systems LAB (GASLAB) GASLAB is hosted by the Computer Science Department of the University of Nevada-Reno. http://www.cs.unr.edu/~sushil/papers/conference/conf.html http://gaslab.cs.unr.edu/
3.http://www.mat.sbg.ac.at/~uhl/GA.html
4.http://www.cs.gmu.edu/research/gag/ email:kdejong@gmu.edu publications: (downloading website) http://www.cs.gmu.edu/research/gas/pubs.html
5.Illinois Genetic Algorithms Laboratory Prof. David E. Goldberg, Director http://gal4.ge.uiuc.edu./illigal.home.html
6.Michigan State University Genetic Algorithms Research and Applications Group (GARAGE) Bill Punch (punch@cps.msu.edu,517-353-3541) Erik Goodman (goodman@egr.msu.edu,517-355-6453) http://garage.cs.msu.edu/
7.ftp://ftp.egr.msu.edu/pub/EC/GA/
遗传算法应用的参考文章
1.用遗传算法求解最短路径问题	下载
2.用遗传算法进行路径规划	下载
3.最短路问题的简便算法	下载
4.带多重选择的最短路问题	下载
5.用原始－对偶算法求解过指定顶点的最短路	下载
6.给定限制期条件下最小风险路径的选取算法	下载
7.带有e约束的网络最短路算法	下载
8.无线网络中最短路径的标记与减少计算量的方法	下载
9.遗传算法用于从EM雷达数据提取地下古墓遗迹定位信息	下载
10.对FLOYD算法的两点注记	下载
11.应用单亲遗传算法进行树状管网优化布置	下载

这是我从网上搜索来的，仅供参考。呵呵……

查看(599) 评论(2) 收藏分享管理

系统测试

2008-01-07 18:04:41

系统测试（System Test, ST）是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。

       系统测试的目的是对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

      系统测试过程域是SPP模型的重要组成部分。本规范阐述了系统测试的规程，该规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

一、介绍

      系统测试流程如图1所示。由于系统测试的目的是验证最终软件系统满足产品需求并且遵循系统设计，所以当产品需求和系统设计文档完成之后，系统测试小组就可以提前开始制定测试计划和设计测试用例，而不必等到“实现与测试”阶段结束。这样可以提高系统测试的效率。

      系统测试过程中发现的所有缺陷必须用统一的缺陷管理工具来管理，开发人员应当及时消除缺陷（改错）。

图1 系统测试流程图

      项目经理设法组建富有成效的系统测试小组。系统测试小组的成员主要来源于：
      ·机构独立的测试小组（如果存在的话）。
      ·邀请其它项目的开发人员参与系统测试。
      ·本项目的部分开发人员。
      ·机构的质量保证人员。

      系统测试小组应当根据项目的特征确定测试内容。一般地，系统测试的主要内容包括：
      ·功能测试。即测试软件系统的功能是否正确，其依据是需求文档，如《产品需求规格说明书》。由于正确性是软件最重要的质量因素，所以功能测试必不可少。
      ·健壮性测试。即测试软件系统在异常情况下能否正常运行的能力。健壮性有两层含义：一是容错能力，二是恢复能力。
      ·性能测试。即测试软件系统处理事务的速度，一是为了检验性能是否符合需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。
      ·用户界面测试。重点是测试软件系统的易用性和视觉效果等。
      ·安全性（security）测试。是指测试软件系统防止非法入侵的能力。“安全”是相对而言的，一般地，如果黑客为非法入侵花费的代价（考虑时间、费用、危险等因素）高于得到的好处，那么这样的系统可以认为是安全的。
      ·安装与反安装测试。

      系统测试过程域产生的主要文档有：
      ·《系统测试计划》;
      ·《系统测试用例》;
      ·《系统测试报告》;
      ·《缺陷管理报告》。

二、系统测试规程

      1、目的
      对最终软件系统进行全面的测试，确保最终软件系统满足产品需求并且遵循系统设计。

      2、角色与职责
      项目经理组建系统测试小组，并指定一名成员任测试组长。
      系统测试小组各成员共同制定测试计划、设计测试用例、执行测试，并撰写相应的文档。测试组长管理上述事务。
      开发人员及时消除测试人员发现的缺陷。

      3、启动准则
      产品需求和系统设计文档完成之后。

      4、输入
      产品需求和系统设计文档

      5、主要步骤
      [Step1] 制定系统测试计划

      系统测试小组各成员共同协商测试计划。测试组长按照指定的模板起草《系统测试计划》。该计划主要包括：
      ·测试范围（内容）
      ·测试方法
      ·测试环境与辅助工具
      ·测试完成准则
      ·人员与任务表

      项目经理审批《系统测试计划》。该计划被批准后，转向[Step2]。

      [Step2] 设计系统测试用例
      ·系统测试小组各成员依据《系统测试计划》和指定的模板，设计（撰写）《系统测试用例》。
      ·测试组长邀请开发人员和同行专家，对《系统测试用例》进行技术评审。该测试用例通过技术评审后，转向[Step3]。

      [Step3] 执行系统测试
      ·系统测试小组各成员依据《系统测试计划》和《系统测试用例》执行系统测试。
      ·将测试结果记录在《系统测试报告》中，用“缺陷管理工具”来管理所发现的缺陷，并及时通报给开发人员。

      [Step4] 缺陷管理与改错
      ·从[Step1]至[Step3]，任何人发现软件系统中的缺陷时都必须使用指定的“缺陷管理工具”。该工具将记录所有缺陷的状态信息，并可以自动产生《缺陷管理报告》。
      ·开发人员及时消除已经发现的缺陷。
      ·开发人员消除缺陷之后应当马上进行回归测试，以确保不会引入新的缺陷。

      6、输出
      ·消除了缺陷的最终软件系统
      ·系统测试用例
      ·系统测试报告
      ·缺陷管理报告

      7、结束准则

      对于非严格系统可以采用“基于测试用例”的准则：
      ·功能性测试用例通过率达到100％；
      ·非功能性测试用例通过率达到80％时。

      对于严格系统，应当补充“基于缺陷密度”的规则：
      ·相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m。例如n大于10，m小于等于1。

      本规程所有文档已经完成。

      8、度量
      测试人员和开发人员统计测试和改错的工作量，文档的规模，以及缺陷的个数与类型，并将此度量数据汇报给项目经理。

三、实施建议

      对系统测试人员进行必要的培训，提高他们的测试效率。
      项目经理和测试小组根据项目的资源、时间等限制因素，设法合理地减少测试的工作量，例如减少“冗余或无效”的测试。
      系统测试小组根据产品的特征，可以适当地修改本规范的各种文档模板。
      对系统测试过程中产生的所有代码和有价值的文档进行配置管理。
      为了调动测试者的积极性，建议企业或项目设立奖励机制，例如：根据缺陷的危害程度把奖金分等级，每个新缺陷对应一份奖金，把奖金发给第一个发现该缺陷的人。

四、系统测试的目标

      1、确保系统测试的活动是按计划进行的；
      2、验证软件产品是否与系统需求用例不相符合或与之矛盾；
      3、建立完善的系统测试缺陷记录跟踪库；
      4、确保软件系统测试活动及其结果及时通知相关小组和个人；

五、系统测试的方针

      1、为项目指定一个测试工程师负责贯彻和执行系统测试活动；
      2、测试组向各事业部总经理/项目经理报告系统测试的执行状况；
      3、系统测试活动遵循文档化的标准和过程；
      4、向外部用户提供经系统测试验收通过的预部署及技术支持；
      5、建立相应项目的（BUG）缺陷库，用于系统测试阶段项目不同生命周期的缺陷记录和缺陷状态跟踪；
      6、定期的对系统测试活动及结果进行评估，向各事业部经理/项目办总监/项目经理汇报/提供项目的产品质量信息及数据；

六、系统测试的过程

      1、软件项目立项，软件项目负责人将项目启动情况通报给测试组长，测试组长指定测试工程师对该项目进行系统测试跟进和执行。
      2、测试工程师首先参与前期的需求分析活动、前景评审、业务培训、SRS评审。目的是了解系统业务及范围、了解软件需求及范围，验证需求可测性。并将所有收集到的测试需求汇总并输出到《测试需求管理表》中。
      3、测试工程师根据测试需求定义测试策略，并进行工作量估计。
      4、测试工程师根据测试需求制定测试策略和方法；系统测试工程师参与项目计划和SDP评审，依据项目计划（或周计划）,编制《系统测试计划》。
      5、测试组长周期性地根据事业部项目的测试情况，进行总体测试工作量估计并进行测试任务分派。
      6、测试工程师组织《系统测试计划》评审，测试组长根据评审意见审批《系统测试计划》。
      7、测试工程师根据《系统测试计划》中的测试环境要求搭建测试环境。特别技术要求的需要项目组及其它相关职能部门的配合。
      8、测试工程师检查测试设计入口条件；根据《用例规约》、《补充规约》、《界面原型》、《词汇表》进行测试用例设计。
      9、测试工程师组织《系统测试用例》评审，测试组长根据评审意见审批《系统测试用例》。
      10、测试工程师定义系统测试用例执行过程，并更新《系统测试用例》。
      11、测试工程师检查测试执行入口条件，从受控库获取测试版本，执行系统测试并记录测试结果。
      12、系统测试进入产品稳定期，由测试工程师召开缺陷评审会议；测试工程师对整个系统测试过程进行总结和评价，形成《软件缺陷清单》、《系统测试评估摘要》《系统测试总结报告》，并将系统测试过程的文档报送给项目组和测试组长。测试组长每月初或（事件驱动）汇总、整编上月的《产品质量简报》，报送给事业部总经理和项目办。
      13、如果根据系统测试结果，产品得以批准通过，系统测试工程师卸载被测软件，进行环境初始化，系统测试结束，转入验收测试阶段；否则视批示意见进行。

查看(367) 评论(0) 收藏分享管理
关于测试用例

2008-01-07 18:02:16

Use Case（用例）是一个UML中非常重要的概念，在使用UML的整个软件开发过程中，Use Case处于一个中心地位。

      那么，到底什么是Use Case呢？在UML的文档中，Use Case的定义是：在不展现一个系统或子系统内部结构的情况下，对系统或子系统的某个连贯的功能单元的定义和描述。有点拗口，对吧？其实Use Case就是对系统功能的描述而已，不过一个Use Case描述的是整个系统功能的一部分，这一部分一定要是在逻辑上相对完整的功能流程。（唔？Use Case也没什么特别的嘛！怎么这玩意儿会在开发中处于一个中心地位呢？）在使用UML的开发过程中，需求是用Use Case来表达的，界面是在Use Case的辅助下设计的，很多类是根据Use Case来发现的，测试实例是根据Use Case来生成的，包括整个开发的管理和任务分配，也是依据Use Case来组织的。啊，Use Case，简直太重要了！好了，Use Case就吹到这儿，具体的使用还要在实践中去体会，“运用之妙，存乎一心” 也！

      对于每个Actor来说，他都要使用系统的某项功能，所以我们识别和分析Use Case是，要对于每个Actor来逐个进行。对于ToDo User，我们可以轻易的识别出两个Use Case：Add Task 和 Remove Task。ToDo User主动使用这两个Use Case所描述的系统功能，所以在我们的Use Case图上，ToDo User和这两个Use Case的关系是用从ToDo User发出的箭来表示的。对于FileSystem，我们识别出的也是同样的两个Use Case，不过这次箭头从Use Case指向FileSystem，表示FileSystem是被动的。

      Use Case可以用很多方式来描述，我们可以用自然语言（英语，汉语，随您的便），可以用形式化语言（哇！太酷了吧！），也可以用各种图示。在UML中，通常用两种图来描述Use Case，它们就是顺序图（Sequence Diagram）和协作图（Collaboration Diagram）

      Use Case 由以下元素组成：
　　　　名称
　　　　简单描述
　　　　事件流
　　　　关系
　　　　活动图和状态图
　　　　Use Case 图
　　　　特殊需求
　　　　前条件
　　　　后条件

一、谈谈对use case有关术语翻译的看法。

      笔者认为“用例”是目前较好的译法，这个词可能来源于大家熟知的“测试用例”。有人认为把use case翻译成“用例”是错误的，理由是：“‘例’是被列举出来以说明某种情况的个别事物，use case是对一项系统功能使用情况的普遍适应的描述，而不是对个别actor或者在个别条件下使用这项功能才适应，它也不是通过举例的方式来描述的”，所以不能叫作“用例”。此种说法不尽全面,而且有些牵强（先不管它正确与否），其实use case到底是个别的，还是群体的（普遍适应），取决于我们的视点。虽然对于单个的scenario来说，use case是多个情节的叠加，是一个整体的复合概念，但是我们知道，一个系统的功能必定是可数的、有限的，而每一个功能都可以表示为一个use case，所以在观察系统提供的所有功能需求的集合这个层面上，use case又是一个一个可数的个体（“椭圆”），每一个都代表了不同的用户目标，适用于个别的actor和个别特定的前置条件。同一个事物既是个体的又是整体的，这种现象并不足怪，例如在UML对象-类-类元关系中，通常对象是类的实例，而类又是类元的实例，对类元来说，类、接口、子系统、use case等等就是一个个个体的概念，类既是其对象实例的集合又是其类元集合的个别元素。可见，把use case的“case”译成“例”并没有错。

      有的地方把use case翻译成“用况”，即“使用的情况”之意，意思的确不错（use case的另一种说法是“使用的方式”）！可我总感觉这个词比较突兀、拗口，类似的还有“用案”，把scenario叫作“案况”，大概这些词读起来不太符合大家的习惯（类似地，既然可以叫“用况”，为什么不能叫“用情”呢？），所以现在“用例”的叫法还是越来越多了。

      其实“用例”这个译法还有个附带的好处，通过它我们很容易把原本就存在紧密联系的use case和test case（test case来自于对scenario的分析，而scenario是用例的一次执行）从中文名称上也方便地统一起来。不过，这里我们需要做一个小小的改进。中文的“测试用例”到底是指test case（带定语的名词词组）呢，还是指对用例进行测试（testing the use cases，动宾词组）呢？显然这两者不易分辨，而且若“用例”和“测试用例”两个词同时出现在一啰个句子或一段话中，常常会让人感觉嗦和便扭。为了消除歧义，干脆以后把test case都叫做“测例”，这样不但比以前的叫法更加简洁明了，而且无论字面上还是语义上都很贴切。当然，用例和测例是不同层面的“例”。

      现在市面上Actor也有多种译法，常见的包括“参与者、执行者、主角”等等。“参与者、执行者”的问题主要是不准确。首先，“参与者” 通常让大家马上想到的词是participant，而且请注意，一个用例的真正参与者决不是只有外部的Actor，它们必然还包括系统本身及其内部的各种元素。“执行者”的问题与此类似：一个用例的真正执行者应该是系统本身！因此严格地讲这样译是错误的，兴许叫作“外部参与者”、“外部执行者”才更为恰当。“主角”的译法同样存在着矛盾。如果把Actor叫作“主角”，那么Primary Actor就应该叫作“主主角”了。看来Actor的译法中是不能含有“主”的，那么就剩下“角”了，而UML已经有了一个专门术语role（角色），我们又不能把Actor直接叫作“角色”。
目前看来，把Actor意译成“使用者”是比较妥当的。在大多数情况下Actor的的确确就是用户（确切地说是系统用户所扮演的一种角色），所以我们可以用“使用者”这个词从字面上与“用户”（user）进行区分，但同时又保持两者语义上的联系。我们还可以把为系统服务的Supporting/Secondary Actor（见下文）叫做“被使用者”（为了简化可以省略“被”字）或“辅使用者”。除了指系统的用户之外，“使用者”还有另一层含义，即Actor是use case的使用者（或被使用者），这种关系在UML用例图上应该可视化地表示为它们之间的连线（关联）。这样解释不但说的通，而且更便于不熟悉软件技术的业务人员理解。
当然，我们也不排除将来会找到“use case”、“actor”等术语更好的译法。

二、USE CASE的来历

       Ivar Jacobson在1967年定义爱立信AXE系统的够架时开始书写使用场境usage scenarios。

      二十世纪八十年代中期Jacobson花了很多精力来思考过去十多年的工作方法。他造了一个术语anvendningsfall，大意是“使用情况”（situation of usage）或用况（usage case）。但当用英文出版的时候，他发现“useage case”在英语里说不通，所以写作用例“use case”

三、创建USE CASE的原则

      用例是短文
      用例可以是一个场景，包括动作和互交。
      用例可以是一组场景，描述不同场景下的行为。这种书写格式可以在任何时候描述有变体的行为，例如黑盒需求，业务流程，系统设计说明。
      用例里不要有系统设计
      用例里不要有界面设计
      用例里不要有特性列表
      用例里不要有测试
      用例应该描述行为需求
      用例的主场景不要超过九步。可以在适当的层次上得到子目标和移除设计说明。
      用例的最大价值不在于主场景，而是在于备选行为。主场景可能只占用例长度的四分之一到十分之一。

四、Use Case 事件流

　　Use Case具有一个基本事件流（可称为"理想路径"）、多个例外流，包括：
　　　　基本变化
　　　　特殊情况
　　　　处理错误情况的异常事件流

五、Use Case 说明书

　　Use Case 说明书应包括以下内容：
　　　　功能描述
　　　　可用性
　　　　可靠性
　　　　性能
　　　　可支持性
　　　　设计约束

六、Use Cases将做成多大？

　　试图决定Use Case的大小是一个很有趣的话题，处理这件事的一个方法是将Use Case的大小跟它的意图和范围关联起来，对于一个真正大的范围来说，一个Use Case并不要在一个系统中处理那么多，但这些系统都用于同一商业领域，称为Business Use Case，它把整个公司看作一个黑盒和Actor关于公司目标的说明。这些Business Use Case的场景不允许假定任何公司内部的结构，一个客户将向公司下一个定单而不是客户服务部门。

　　对于系统发展而言，Use Case的范围限制一个单一的系统，这是Use Cases最通常的形式，我们称之为System Use Case，它把整个系统看作是一个黑盒，它不指定任何内部结构并且仅受限于问题域的语言描述。

　　Use Cases的另一范围是设计子系统和系统内部组件的，称为Implementation Use Cases，它把组件看作一个黑盒，并且这些Actors是区分它的成员。例如：可能会用Implementation Use Cases去说明应用系统中email组件的需求。

　　给出了这些分类，关于Use Case的大小话题变得容易了，设计这些项的范围来调整整个大小。帮助系统设计者，每个Use Case只描述没有大的分支的行为的单个线索。违背这个规定，Use Case看起来通常是不准确的或含糊的，作为测试说明的资源和参考，它也是很难使用的。

七、Use Cases的说明

      Use Cases的好处是一些情节能用不同程度的正规化的文字说明。每个情节涉及Use Cases中单一的途径，细节是条件组。

      不正规的文本描述也能使用，不过当条件较多和可能失败的情况下它们很难跟随下去。开始试图理解需求时，不正规的叙述风格也是非常有用的，然而随着Use Cases的进展，使用更加正规的机制去说明Use Cases才是有用的。

      下面是客户对Use Case“下定单”的粗略概略：

      “确定客户，找出需要的并且仓库里还有的物品并检查客户信用额是否够用”

      结构化叙述的格式已经被证明是非常有效的。这个格式所做的事是描述每一个情节的行为者：目标语句对顺序的叙述。在这个顺序中，每一个行为者：目标的语句对都假设前一个的目标是成功的，右面是一个简单的范例：

      Use Cases认为我们正在设计的系统是一个单一的黑盒，根本没有任何内部结构被记录下来，并且它被认为是一个情节产生的目的及对应单一的行为者（Actor）。这些Use Cases没有表示任何关于系统内部的东东，只是表示系统将达到什么样的目标及由什么（人或其它系统）操作和负责。

八、Use Cases使需求有利于回顾

　　Use Cases已经得到越来越广泛的应用，它与其它需求捕获技术相比，它成功的原因在于：
　　　　1 　Use Cases把系统当作一个黑盒
　　　　2 　Use Case 使在需求中看到实现的决定变得更加容易

　　最后一点源于第一点的补充，一个Use Case没有指定任何这些需求相关的系统的内部结构，所以说，如果这个Use Case中陈述了"提交改变到定单数据库"、"显示结果到Web页面"等的话，那么内部结构是显而易见的，并造成对设计的潜在约束。

　　为什么这些需求不指定内部结构的原因是，说明的内部结构给设计者带来了额外的约束，没有这些约束设计者们能更自由地建立一个正确实现客观可见行为的系统，并存在出现突破方案的可能性。

九、Use Cases的图形符号

　　这里是Use Cases的图形符号描述，UML中一个单一的"Stick-Man"符号标示角色（Actor），用椭圆标示Use Cases，如

（图一）所示。这些图对于你想看到Use Cases之间如何关联的"大图"和获得系统上下文的大体描述来说是非常重要的。

　　Use Cases图没有显示不同的场景，它们的意图是显示角色和Use Cases之间的关系。所以Use Cases图需求用结构化叙述文本来补充。UML提供一些可供选择的图来显示不同的场景，这些常规的图形有交互图、活动图、顺序图、状态图等（本文暂不讨论这些图）。使用这些图的主要缺点是它们不象文本一样是紧密的，但它们能用于给出Use Case的整体感觉。

十、Use Case 的评价标准

　　是否每个Use Case 都包括至少一个actor？
　　是否每个Use Case 都独立于其他Use Case？
　　是否每个Use Case 都有一个简单的行为或事件流？
　　是否每个Use Case 都有一个唯一的、直观的、可扩展的名称，使它不至于在后期被混淆。
　　用户是否容易理解Use Case 的名称和描述。

十一、Use Case 模型的评价标准

　　Use Case模型显示系统中的Use Case与Actor 及其相互关系。其评价标准有：
　　　　Use Case 模型是可理解的吗？
　　　　通过对Use Case 模型的研究是否能对系统功能有一个清晰的概念。
　　　　所有的actor都定义了吗？所有的功能需求都满足了吗？
　　　　Use Case 模型是否存在多余的行为。
　　　　从模型到Use Case包的划分是否是恰当的。

十二、使用Use Case 的误区

　　由于具有简单的图形符号、易理解的自然语言说明书，Use Case在文档系统和软件需求领域成为一项越来越受欢迎的技术。Use Case对开发小组极具吸引力，即使小组成员对正式的需求文档没有经验，但这些简单性却具有欺骗性，即使项目小组在开始使用Use Case 时没有任何麻烦，当他们将其应用于大项目时常常会遇到许多同样的问题。

     1 使用 use case 十大误区

　　1．系统的boundary 没有定义或经常改变；
　　2．从系统观点而不是actor观点来定义Use Case；
　　3． Actor的名称不一致；
　　4． Use Case 定义过多；
　　5． Use Case 和actor之间的关系象蜘蛛网一样错综复杂；
　　6． Use Case的说明太长；
　　7． Use Case的说明不清楚；
　　8． Use Case没有正确的描述功能需求；
　　9．用户无法理解Use Case；
　　10． Use Case 无法正常结束。

       2 如何避免以上问题

      清楚的确定系统的boundary.
　　简单来说，系统的boundary就像一个加了标签的盒子，actor在盒子外，而Use Case在盒子内。我们称之为系统的这个盒子究竟是什么呢？一个计算机系统？一个应用系统？或一个完整的企业？…Use Case 可以用来合理地描述任意系统。但一次只能用来描述一个系统，在一个系统中恰当定义的actor和Use Case用于另一个不同的系统中就会出现错误。

      使用标准模板书写Use Case 说明书
　　Use Case 图形符号已经被标准化并作为对象管理小组UML的一部分，但自然语言的Use Case 说明书还没有被标准化。为了成功书写Use Case 说明书，我们需要一个标准模板来保证Use Case 的一致性。

      关注actor的真正目的，从actor的观点而不是系统观点来命名Use Case
　　面向Use Case 的需求与传统的功能性系统需求之间最显著的区别在于actor ，以面向Use Case的观点，系统存在是由于actors 要通过该系统实现某些目标，actor与系统进行交互来实现其目标，我们将这些交互行为定义为Use Case 。

      不要将Use Case 说明书与用户接口设计相混淆
　　现在有一种很流行的观点：由于Use Case 是actors 与系统之间的交互，所以将所有的用户接口设计图放在Use Case说明书中是一个好办法。初看时，这的确很有用，因为它将在说明书中描述的actor/系统之间的交互行为以图的形式表示出来，非常直观。但是这样做的负面影响却远远大于其好处，用户接口设计可能会随着时间而改变，我们不应该让系统需求依赖于用户接口设计，相反地，用户接口设计应该满足Use Case 需求。如果我们将用户接口设计置于Use Case 说明书中，当需求需要被认可和定为基线时，很自然地，这些设计元素可能仍然在改变，这就使得用户接口设计成为不完整的、不正确的和/或不一致的。

　　将用户接口设计置于Use Case 说明书还会出现另一个问题，为了在Use Case 之间和接口之间建立一对一的通信，我们会选择反映用户接口的Use Case块而不是反映用户目标的Use Case 块，这样，为了表达一个完整的用户目标，我们使用交互Use Case 关系，将不同的、基于用户接口的Use Case 联接起来，结果在Use Case 模型中，我们得到了一幅类似蜘蛛网的关系图。实际上，这副图是用户接口说明图，虽然它在系统文档中是很重要的一部分，但他属于用户接口设计文档，而不是Use Case 需求文档。

      实现用户接口和Use Case 交互之间的松散耦合
　　松散耦合是比较合适的，低逼真度的用户接口图有助于理解Use Case ，但要注意不要过度的将基本交互与用户界面机制相连，用户界面很有可能会改变。在功能说明书中，要注意actor做些什么（如"提交请求"）而不是交互是怎样完成的(如"双击提交按钮")。

查看(389) 评论(0) 收藏分享管理
构建"复用"软件测试环境

2008-01-07 17:46:44

软件测试环境是进行软件测试所必需的工作平台和前提条件，包括硬件环境和软件环境，硬件环境指进行测试所必需的服务器、客户端、网络连接设备，以及打印机/扫描仪等辅助硬件设备所构成的环境；软件环境则指被测软件运行时的操作系统、数据库及其他应用软件等构成的环境。本文主要阐述在构建测试的软件环境中所用到的一些“复用”技术。

　　软件测试环境就象是一个舞台，可让所有的被测软件在这个舞台上各显其能，尽情“表演”，而我们的测试工程师们就像是一个个评委，对每个被测软件的“表演”打分、评判。因而，软件测试环境构建的是否合理、稳定和具有代表性，将直接影响到软件测试结果的真实性、可靠性和正确性，所以千万不可小窥了软件测试环境的搭建工作，它是测试实施的一个重要阶段和环节，其重要性是不言而喻的；另一方面，不同（版本）的操作系统、不同（版本）的数据库，不同（版本）的网络服务器、应用服务器，再加上不同的系统架构等的组合，使得要构建的软件测试环境多种多样、不胜枚举；而且现在随着软件运行环境的多样性、配置各种相关参数的“浩大工程”和测试软件的兼容性等方面的需要，使得构建软件测试环境的工作变得较为复杂和频繁，如果我们再按照以前那种按部就班地来搭建测试环境的方法，可真有点落伍了，不仅效率低下，而且灵活性、可复用性也较差。那么出路何在呢？

　　在软件的开发过程中，创建可复用的软件构件库的技术，是软件开发人员所追求的一种高级技术；“它山之石，可以攻玉”，我们何不通过构建软件测试环境库的方式来实现软件测试环境的复用呢，因而，笔者一直以来就尝试着用应用软件来构建可“复用”的测试环境，利用这种方法可节省大约90％的时间，效果还真不错。

　　构建可“复用”的测试环境，往往要用到如ghost、drive image等磁盘备份工具软件；这些工具软件，主要实现对磁盘文件的备份和恢复（或称还原）功能；在应用这些工具软件之前，我们首先要做好以下几件十分必要的准备工作：

　　1. 确保所使用的磁盘备份工具软件本身的质量可靠性，建议使用正版软件；

　　2. 利用有效的正版杀毒软件检测要备份的磁盘，保证测试环境中没有病毒，并确保测试环境中所运行的系统软件、数据库、应用软件等已经安装调试好，并全部正确无误；

　　3. 为减少镜像文件的体积，要删除掉temp文件夹下的所有文件，要删除掉win386.swp文件或_restore文件夹；选择采用压缩方式进行镜像文件的创建；在安装大型应用软件时，如office xp、photoshop 6.0等时，最好把它们安装到d盘，这样c盘就不至于过分膨胀，可使要备份的数据量大大减小；

　　4. 最后，再进行一次彻底的磁盘碎片整理，将c盘调整到最优状态。

　　完成了这些准备工作，我们就可以用备份工具逐个逐个的来创建各种组合类型的软件测试环境的磁盘镜像文件了。对已经创建好的各种镜像文件，要将它们设成系统、隐含、只读属性，这样一方面可以防止意外删除、感染病毒；另一方面可以避免在对磁盘进行碎片整理时，频繁移动镜像文件的位置，从而可节约整理磁盘的时间；同时还要记录好每个镜像文件的适用范围，所备份的文件的信息等内容，最后，还要将每个镜像文件提交到专用的软件测试环境库中（一般存放在网络文件服务器上），软件测试环境库要存放在单独的硬盘分区上，不要和其他经常需要读写的文件放在一起，并尽量不要对软件测试环境库所在的硬盘分区进行磁盘整理，以免对镜像文件造成破坏。还有，软件测试环境库存放在网络文件服务器上安全性并不太高，最好同时又将它们制作成可自启动的光盘，由专人进行统一管理；一旦需要搭建测试环境时，就可通过网络、自启动的光盘或硬盘等方式，由专人负责将镜像文件恢复到指定的目录中去，这项工作一旦完成后，被还原的硬盘上的原有信息将完全丢失，所以请慎重使用，可先把硬盘上的原有的重要的文件资料提前备份，以防不测。

　　软件测试环境库构建成功后，并不意味着万事大吉、一劳永逸了，还要经常性借助ghost explorer等软件对镜像文件加以维护和更新；对改变了重要硬件配置的计算机的镜像文件有时还要利用如sysprep等分发工具来更新......

　　“养兵千日，用兵一时”，现在软件测试环境库中的镜像文件就是你的兵了，一旦有配置软件测试环境的任务，只要你一声令下，他们立马会“奔赴前线”，倒下了、牺牲了，他们又能再生，再能上战场，当真是世界上最强大的一支部队了。

　　本文只是笔者在从事测试工作中的一些经验和体会，恐怕会贻笑大方，如果能为大家起到抛砖引玉的作用，那就甚感欣慰了，文中如有不妥之处，敬请指正。

查看(349) 评论(1) 收藏分享管理
软件测试流程

2008-01-07 16:40:11

　　

流程规范

　　

整体过程流图

　　

测试项目确认流图

　　

测试执行流图

　　

测试策划流图

　　

问题跟踪与测试关闭流图

查看(712) 评论(0) 收藏分享管理
软件测试109贴

2008-01-06 13:26:54

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