2012年7月31日星期二

命令行方式使用FTP实战练习


简单上传下载实例(/*....*/为注释):
先假设有一FTP服务器,FTP服务器:qint.ithot.net,用户名:username   密码:user1234。在本地电脑D:盘创建一个文件夹"qint"。将要上传的文件复制到d:\qint里。通过FTP命令将文件从本地上传,从服务器下载的步骤如下:
1.“开始”-“运行”-输入“FTP”
2.open qint.ithot.net
/*这一步可以与第一步合并,在“运行”里直接输入"ftp qint.ithot.net"。如果你的FTP服务器不是用的21默认端口,假如端口是2121,那么此步的命令应在后面空格加2121,即“open qint.ithot.net 2121”*/
3.username
/*提示你输入用户名*/
4.user1234
/*提示你输入密码,密码不回显,打完密码后回车即可。如果你的密码输入错误,将不会提示你重新输入,这时你要键入“user”命令,将会出现第三步,你可以重新输入用户名和密码。*/
5.dir
/*你成功登陆后就可以用dir查看命令查看FTP服务器中的文件及目录,用ls命令只可以查看文件。*/
6.mkdir qint
/*在FTP服务器上根目录下建立qint目录。*/
7.cd qint
/*进入目录qint,用“cd 你的目录名”可以进入当前目录的下一级目录,这跟DOS一样。*/
8.bin
/*采用二进制传输。如果你要上传下载,这一步很重要,不先执行这个命令,上传下载会很慢。*/
9.lcd d:\qint
/*定位本地默认文件夹,在前面我事先在D:盘创建的。*/
10.!dir
/*查看本地文件夹中的文件及目录*/
11.put i001.jpg
/*将当前目录(d:\qint)中的文件i001.jpg上传到FTP服务器默认目录。可以用"mput *.*"将所有文件上传到FTP服务器上。*/
12.get d123.jpg
/*将FTP服务器默认目录中的文件d123.jpg下载到当前目录下(d:\qint)。可以用"mget *.*"将所有文件下载到d:\qint*/
13.delete *.*
/*删除目录qint中的所有文件。*/
14.cd ..
/*返回至上一级目录,即根目录。返回上一级目录用“cd ..”要注意,中间有空格。返回根目录用“cd \”。*/
15.mrdir qint
/*删除目录qint。删除目录,在此目录下不能有文件及目录,不然将无法删除。*/
16.bye
/*退出FTP服务器*/
上传下载时特别要注意服务器及本地电脑的当前目录,文件是从哪里到哪里的问题。查看FTP服务器的当前目录命令为pwd,可以用cd命令定位服务器的目录。可以用lcd命令定位本地电脑的目录。以上实例应用到了采用FTP命令行方式上传下载的最常用命令,你还可以用命令“?”查看更多的命令。

2012年7月23日星期一

(完美安装)康熙字典破解及优化安装


gougou的下载地址已经被屏蔽,不能下载。
一、运行环境 
1、硬件要求:推荐使用奔腾II或更高、32MB以上内存、以及光驱。 
2、操作系统要求:Microsoft公司的Windows98/NT/2000简体中文操作平台。 
3、浏览器要求:Microsoft公司的IE4.0以上版本。 
二、安装使用说明 
A:将光盘1放入电脑光盘驱动后,会自动弹出安装界面,请依据提示进行安装。 
B:安装完成后,请将光盘2放入电脑光盘驱动器中,然后运行开始菜单上的“康熙字典”即可使用该软件。 
注:详细安装方法请参照使用说明手册。 
三、使用说明 
详细使用方法以及汉字相关知识请参照使用说明手册或软件中的帮助

用户名:personal
序列号:773C240E14251A02
按照官方的文档,使用过程非常不便,每次需要启动光驱,非常不便。
据本人实践,完全可以去掉频繁的放置disk2步骤,让一切的不方便去死吧。
修改安装目录下的配置文件,把disk2拷贝到硬盘即可。
具体步骤如下:
1:将disk2的文件Second.udb(有500多M)拷贝到安装目录
2:用记事本打开安装目录的config.ini文件
3:找到这几行
[DATABASE3]
NAME = SECONDIMAGE
FILENAME = Second
POSITION =CD
CD = 2
4:将配置文件的POSITION =CD改为POSITION =HD
5:保存并关闭配置文件
6:重启eKangXi.exe,试试吧

2012年7月18日星期三

飞信帐号批量注册协议


飞信帐号分为两种,一种是手机号码注册的,另外一种是邮箱注册
下边就分析下邮箱注册,邮箱注册需要激活,这里我们采用临时邮箱激活的方式去做

注册地址:https://feixin.10086.cn/account/registermail/
提交内容:mail={0}&nickname={1}&password={2}&repeatpassword={2}&code={3}
其中 {0}为帐号
       {1}昵称
       {2}密码
        {3}重复密码
        {4}验证码
提交方式:post

验证码地址:https://feixin.10086.cn/ValidateNumberPicture.aspx

因为注册成功后需要去邮箱激活,所以需要找个临时邮箱去激活,我用的是nowmymail。国外的临时邮箱,不是很好使,很多情况下接收不到邮件
进入nowmymail邮箱:
地址:http://www.nowmymail.com/mailbox.php
提交参数:mailbox={0}&=Check+Mail
{0}为email帐号
提交方式 post

创建nowmymail临时邮箱:
 地址:http://www.nowmymail.com/create.php
提交参数:action=create&AdvancedButton1=submit
提交方式:post
返回结果中可截取到 分配的用户名,用此用户名去注册飞信!

2012年7月12日星期四

windows下Emacs的安装与配置


最近在学习windows下的Emacs,遇到不少问题,比如什么home目录啦,.emacs配置文件啦,.el文件啦,通过几天的反复琢磨,终于有所感悟。我想不仅是我,很多人都遇到过这些问题,现在就总结如下,以供有需要的朋友参考。
1、下载
到这个网址可以下载到Emacs的windows版本:http://ftp.gnu.org/pub/gnu/emacs/windows/
只需要一个压缩文档,如emacs-22.3-bin-i386.zip
2、安装
在D盘根目录下新建一个文件夹,取名Emacs22.2(也可以是其他路径,随个人喜好而定),将emacs-22.2-bin-i386.zip里的文件解压到这个目录下,这样在d:/Emacs22.2/下就有bin, tec, info, leim, lisp, site-lisp等目录。
双击bin文件夹里的addpm.exe进行安装,安装后将在开始菜单生成Gnu Emacs/Emacs链接,点击这个链接便可启动Emacs。也可以双击bin文件夹里的runemacs.exe启动。注意到bin目录里还有个文件是emacs.exe,双击它也可以启动,但是会出现一个控制台窗口
3、修改注册表
打开注册表,找到HKEY_LOCAL_MACHINE/SOFTWARE/GNU/Emacs(如果没有则手动添加项),在此项下添加字符串值,名称为HOME,值为D:/Emacs22.2。这样做的目的是让D:/Emacs22.2成为Emacs的home路径(传说中的home path,以后你将会经常看到“home目录”、“home directory”等等)。
4、创建.emacs.d目录和.emacs文件
相信.emacs.d目录和.emacs文件是困扰大家很久的问题了,其实有个简单的办法可以解决此问题。启动emacs,用鼠标点击Options菜单,随便点击一两个选项,比如点击一下Active Region Highlighting,然后点击Save Options。先不要担心你会破坏了什么东西,这样做的目的是让emacs自动创建.emacs.d目录以及.emacs文件!观察你的Emacs窗口最后一行,是否显示“Wrote d:/Emacs22.2/.emacs”?如果是的话就对了,当你选择Save Options的时候,Emacs会在home路径下产生.emacs文件,并把配置信息写进这个文件。现在看看你的d:/Emacs22.2/目录下是否产生了这两个东西?
5、加载.el文件
lisp目录下存放着lisp源文件(*.el)和已编译的lisp文件(*.elc),以后你也可以将自己的.el文件放在这个目录下,然后还要在.emacs文件插入相关语句。比如你有一个文件叫做abcd.el,将它复制到lisp目录下,然后打开.emacs文件插入一句(require 'abcd)就可以了(包括圆括号,不需要扩展名.el)。
如果你不喜欢lisp文件夹,也可以自己新建一个,比如在home目录下建一个文件夹叫做xyz,然后把abcd.el放在xyz目录下,在.emacs文件插入以下两句:
(setq load-path (cons "~/xyz" load-path))
(require 'abcd)
第一句告诉emacs先加载你的xyz目录,第二句再加载abcd.el。注意“~/”是linux系统的用法,表示home目录。
如果你和我一样在学习《Sams Teach Yourself Emacs in 24 Hours》这本书的话,我想你一定需要sams-lib.el这个文件!可以到这个网址下载:
http://www.cs.virginia.edu/~wh5a/personal/Emacs/
找到sams-lib.el之后右键点击“目标另存为”就可以了!
最后,在下有一事不解,除了lisp还有一个site-lisp目录,我把sams-lib.el分别放在这两个目录下,发现效果是一样的,不知道这两个目录有何不同之处?

2012年2月23日星期四

测试各阶段的主要内容、职责分工、技术要求

http://www.yd-itedu.com/  添加日期:07-06-08 10:56:55  来源:    进入论坛

测试各阶段的主要内容、职责分工、技术要求

1 、代码走查:

2 、单元测试

单元测试的主要内容 功能测试、容错测试、边界测试、约束测试、界面测试、重要的执行路径测试,单元内的业务流程和数据流程等。

        单元测试的职责分工: 由各项目组的开发人员完成测试工作,并详细记录测试结果和修改过程,质量部进行抽检。

单元测试的输入: 《源代码》、《详细设计报告》

单元测试的技术要求

        测试要求:

 a)   每个被测单元中每条可执行的脚本都被一个测试用例或异常操作所覆盖,即脚本覆盖率达 80% 

 b)   每个被测单元中分支语句取真和取假时,各分支至少执行一次,即分支覆盖率达到 80%

  c)   每个被测单元中的业务流程和数据流程,必须被一个测试用例、一个异常数据、一次异常操作所覆盖,即异常处理能力达 80% 

        单元测试通过准则

    a)   单元功能同设计需求一致;

    b)   单元接口同设计需求一致;

    c)   能正确处理输入和异常运行中的错误;

    单元发现问题进行修改后,进行回归测试,且回归测试通过后,才能进行下一阶段。

        单元测试的输出 《单元测试记录》、《测试计划》

        单元测试的测试质量责任人是项目经理。

3 、集成测试阶段

        集成测试的主要内容: 系统性的初始化测试、功能测试、用户需求确认  业务处理或数据处理测试、 性能测试、安全性测试、 安装性测试 

        集成测试的职责分工: 由软件部的测试人员组织进行并完成该阶段的测试工作,对测试结果进行详细的记录。

        集成测试的输入: 《测试计划》、《用户需求分析报告》、《用户操作手册》、 《安装手册》

        集成测试的技术要求:

测试技术要求:

a)             用户需求的确认:进一步验证被测系统是否满 足用户的需求。即根据用户的需求分析报告中全部功能和性能要求,测试整个软件系统,验证其是否达到用户的要求。

b)             通过数据处理的测试用例对被测系统的输入、输出、处理进行测试,使其达到设计要求;

c)             通过业务处理的测试用例对被测系统的业务处理过程进行测试,使其达到用户需求的要求;

c)            测试软件正确处理能力和容错能力;

d)            确认单元间无错误连接;

e)              测试软件对正常数据的处理,对接口错误、数据错误、协议错误的识别及处理。

f)         测试其进行数据处理时的响应时间是否满足用户要求;

g)        安装性测试是验证  按照《安装手册》是否能够正常配置和安装;

h)          安全性测试是测试其对非法用户的抵御能力, 非法用户无法登录本系统。

  通过准则

 a)   各单元间无错误连接;

 b)   满足软件需求的各项功能、性能要求;

 c)   对错误输入有正确的处理能力;

d)       对测试中的异常有合理的提示;

e)         人机界面友好。

f)           用户操作手册易读、易懂、易操作。

        集成测试的输出: 《集成测试记录》。《测试分析报告》集成测试的测试质量由公司级的技术人员负责。

 

软件测试是一种特殊的软件系统的设计和实现,即执行另一个以发现错误(或缺陷)为目标的软件系统。测试就是分析被测系统,判定怎样可能是错误的,同时,测试设计也是为测试的自动化提供了需求。

软件测试的核心工作就是通过规范性的测试手段按软件可能遇到的应用场合全面充分地对软件进行测试,软件测试能够充分地发现软件中的缺陷和问题,确定软件当前的技术状态,提高软件的质量,使软件项目和软件产品满足用户需求。

微软的软件测试人员工作职责

http://www.yd-itedu.com/  添加日期:07-09-08 10:59:15  来源:    进入论坛

    微软的软件测试人员分为两类 :测试工具软件开发工程师( Software Development Engineer in Test,简称 SDE/T)和软件测试工程师 (Software Test Engineer,简称 STE)

测试工具软件开发工程师 : 负责写测试工具代码,并利用测试工具对软件进行测试;或者开发测试工具为软件测试工程师服务。产品开发后的性能测试 (Performance Test)、提交测试 (Check-in Test)等过程,都有可能要用到 SDE/T开发的测试工具。由于 SDE/T和 SDE的工作都是写代码,具有相通的地方,所以两者之间互相转换的情况比较多。但需要注意的是,两者写出来的代码用途是不一样的, SDE写的是产品的代码,而 SDE/T写的代码只用于测试产品。

软件测试工程师 : 负责理解产品的功能要求,然后对其进行测试,检查软件有没有错误 (Bug),决定软件是否具有稳定性 (Robustness),并写出相应的测试规范和测试案例。

除此之外,在一个软件产品的研发和销售过程中,还会需要负责给产品打补丁 (Service Pack)的快速修正工程师比( Quick Fix Engineer),通常曲 SDE来担任,通过电话方式向用户提供售后技术支持的支持工程师 (Support Engineer),销售和市场 (Sales and Marketing)人员,研究员和研究工程师 (Researchers & Research SDE)

在进行产品开发的时候,主要是由前面三类人员 (项目经理、开发人员及测试人员 )组成产品开发团队来进行的。在微软内部,软件测试人员与软件开发人员的比率一般为 1.5-2.5左右,这可能远远超出了大家对测试人员的理解,但微软软件开发的实践过程已经证明了这种人员结构的合理性

   测试时应考虑的几个问题

(1) 测试最重要的一件事就是要考虑到所有的出错可能性。同时,还要做一些不是按常规做的、非常奇怪的事。

说起来可能不太好听,测试的过程就像黑客 (Hacker)的攻击过程那样。可以这么说,像黑客这样的人是最好的软件安全测试员。他们专门找软件的漏洞,从而破坏这个软件,这样就可以修复这些漏洞保证软件的性能。如果找不到这种漏洞,那就说明该软件质量己经很好了。

(2) 除了漏洞之外,测试还应该考虑性能 (Performance)问题,也就是一定要保证软件运行得很好,非常快,没有内存泄漏,不会出现那种越来越慢的情况。

我们可以在不关机的情况下,与其他软件一起持续运行一个多月,看看是否会出现越来越慢的情况 (当然必须保证其他软件是没有问题的 )。我们在做 IE的时候,就是让它 72小时连续不停地打开不同的网页,处理几万个不同的网页,而且速度不能减慢。有许多软件,当只有一两个人用的时候,可能感觉不到什么问题,而当几百个用户一起用的时候,有的网站就出现各种各样的异常,这就是测试工作还比较欠缺的原故。

(3) 另外,测试还要考虑软件的兼容性 (Compatibility)

一般来说,一个软件是由许多小软件构成的,如果其中一个小软件与它的前一版本不兼容,那么这个软件就会出现错误。这种错误需要通过测试来发现和解决。

许多人认为写代码的人一定能找出错误来。其实开发人员在写代码的时候,如果有错误,他可以意识到了,可是写出来的错误,他不一定能想得到。我自己也编过程序,在编程序的时候很自信,觉得不会有错,可事实上,即使是我编的小程序也有错误,但要自己找出来,却要费很大劲。因为我一直认为自己不应该出错,但常常错误就出现在我认为最有把握的地方。我是学数学的,是一个很细心的人,可是 --样还是会出错,但要找出自己的错误却要花费很长的时间。后来我写的代码让我的师弟帮我看,结果他很快就找到许多问题,可是我自己花一个月时间可能都找不到。所以,开发人员和测试人员完全不一样,开发人员确实可以找到一些 Bug,但是有更多的 Bug是他意识不到的。

在一般的开发团队中,并不需要测试人员定位 Bug的具体位置,所以,对测试人员的要求并不高。只要你愿意学,测试工作是非常容易做的。但是,我当年所在的 IE团队 (IE 4.0)就不同,因为当时正在与另一个公司的产品竞争,所以微软就要求尽量找到一流的开发人员和一流的测试人员,尽快开发出新产品,打败对手。所以,当时对我们测试人员的要求非常严格,不仅要找出 Bug,而且要定位引起此 Bug的代码行。然后将这些信息交给开发人员,后者就可以很快更正,省去了他们找错误出处的时间。因此,当时 IE的开发速度非常快,一年之内就发布了一个新版本,而且几乎役有任何大 Bug,大大超越了竞争对手。

   Bug

Bug 的定义很广泛,在软件使用过程中所出现的任何一个可疑问题,或者导致软件不能符合设计要求或满足消费者需要的问题部是 Bug,即使这个 Bug在实践中是可行的。

有时候, Bug并不是程序错误。例如,软件没有按照一般用户的使用习惯来运行,此时也可以把这个问题看成是该软件的一个 Bug

首先,测试人员根据测试结果来报告他发现的所有 Bug。通常,这项工作还需要用户的参与。微软在正式发布一个软件之前,经常要依次发布 Alpha测试版、 Beta测试版让用户试用,以便用户能够反馈出相关Bug的信息。但是,现在随着微软测试队伍的扩大及测试水平的提高,越来越多的 Bug都是我们内部的测试人员自己发现的,很少出现外部用户所反馈的 Bug没有被测试人员发现的情况。

然后,开发经理根据这些 Bug的危害性对它们进行排序,确定 Bug的优先级,并安排给相关的开发工程师。

接着,开发人员根据 Bug的轻重缓急依次修复各个 Bug

最后,测试人员再对开发人员已经修复的 Bug 进行验证, 确认 Bug是否已经被彻底更正。

微软开发一个产品经常会遇到几十万条 Bug。随着测试人员越来越多,测试工作也越来越完善。但是,如何快速有效地追踪并修复 Bug,仍然是摆在软件测试人员面前的一个主要困难。测试产品和追踪 Bug时最重要的是问题的定义,要清楚需要解决什么样问题,确定 Bug的主次关系,挑选出最主要的问题,并先解决它们。例如,有些 Bug可能会导致死机或程序崩溃,这时就要先修复它们,而另一些 Bug可能对软件的运行影响不大,或者出现的机会很少,就可以考虑以后再修复。

可以说,没有任何一个产品没有 Bug,也永远不可能找井修复所有的 Bug。在修复了旧的 Bug的同时,往往又会生新的 Bug

这个过程就类似于数学中的"极限"的定义,尽管我们知道某个极限值为 0,但是它永远也不可能达到0。这也就产品的 Bug永远也修复不完的原因。因此,我们在修复 Bug时要注意,一定要记住用户最需要的是什么,然后优先尽力修复那些影响用户使用的 Bug;而对于大部分对用户影很少、甚至根本不影响的 Bug,则可以推迟修复,甚至不修复。

  软件测试阶段及其职责
   ① 单元测试 (Unit Test): 按照代码的单元组成逐个进行测试。

② 功能测试 (Function Test)或特性测试 (Feature Test): 按照软件的功能或特性逐个进行测试。例如,在 Exchange中,发送邮件和接收邮件就是两个不同的功能或特性,在测试时就分别对它们进行检查,看是否工作正常。

③ 提交测试 (Check-in Test): 在开发人员对代码做了任何修改,或者修复了某个 Bug时,需要重新 Check-in代码 (即将修改后的代码放大到整个大的系统中 )。这时,开发人员往往也要进行测试,看代码是否工作正常。为了保险起见,开发人员往往要找测试人员帮着一起进行测试 (我们把这种情况称做 Buddy    Test)。测试人员和开发人员之间搞好关系是非常重要的,稍后我会专门讲述这一点。

④ 基本验证测试 (Build Verification Test,简称 BVT): 对完成的代码进行编译和连接,产生一个构造,以检查程序的主要功能是否会像预期一样进行工作。这是最简单而又最省时的一种测试方法。每产生一个新的构造时都要进行测试。如果连 BVT部通不过,表明问题很严重,开发人员需要尽快修复出现的问题,测试人员也就不用浪费时间做其他测试了。

⑤ 回归测试 (Regression Test): 过一段时间以后,再回过头来对以前修复过的 Bug重新进行测试,看该 Bug是否会重新出现。

(2) 使用测试 (Usage Testing)

使用测试是从用户的角度 (即外部 )出发的测试方法。它也包括许多类型。

① 配置测试 (Configuration Test): 从用户的使用出发进行多方面的测试。例如,保证软件不仅能够在 Windows 9X下运行,也能够在 Windows ME下运行,还能够在 Windows NT/200O/XP下运行 ;或者软件不仅能够在配置高的计算机上运行,也能够在配置很低的计算机上正确地运行。总之,要考虑到用户的多种情况,用多种配置对软件进行测试。

② 兼容性侧试 (Compatibility Test): 主要考虑兼容性问题,比如同一个产品的不同版本 (Office 2O00和 Office XP)之间的兼容问题,不同厂家的同一个产品 (如 IE和 Netscape)之间的兼容问题,不同类型软件 (如 IE和 Office)之间的兼容问题等。最难测试的往往就是软件的兼容性问题,往往要投人巨大的人力和物力。一些厂商开发出来的产品在兼容性上做得很不好,就是因为没有足够的人力和物力进行测试。

我在做 SQL Server的 XML测试的时候,为了解决 XML的兼容性问题,用了 6个测试人员和 100台计算机进行测试。正因如此,微软产品的兼容性都非常好。而不像市场上的一些产品,安装以后就导致计算机上的许多其他软件无法使用,或者出现各种各样的问题,这样不仅伤害了其他软件,也伤害了用户。

③ 强力测试 (StressTest): 在各种极限情况下对产品进行测试 (如很多人同时使用该软件,或者反复运行该软件 ),以检查产品的长期稳定性。例如,我们在开发 IE 4.0的时候,由于当时有一个非常强的竞争对手,因此我们必须保证 1E4.0要做得非常好。当时,为了测试 IE4.0的长期稳定性,我们专门设计了一套自动测试程序,它一分钟可以下载上千个页面。我们使用这个测试程序对 IE4.0进行了连续 72小时的测试,也没有出现任何问题,如内存泄漏、程序崩溃等。

本项测试可以帮助找到一些大型的问题,如死机、崩损、内存泄漏等,因为有些存在内存泄漏问题的程序,在运行一两次时可能不会出现问题,但是如果运行了成千上万次,内存泄漏得越来越多,就会导致系统崩滑。

④ 性能测试 (Performance Test): 本项测试是保证程序具有良好的性能。如果别人的产品只需5秒钟就能得出结果,而你的产品需要 10秒钟才能得出结果,就说明你的产品性能不好。如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。因此在产品开发的开始阶段,就要考虑到软件的性能问题。

⑤ 文档和帮助文件测试 (Documentation and help file Test ): 因为用户通常是通过文档和帮助文件来学习使用产品的,如果文档和帮助文件存在错误,就可能会导致用户无法正常使用产品。这项工作通常在产品即将 Ship(即准备包装发布 )时进行,以避免在修复 Bug的过程中需要反复修改文档,或者忘记修改文档,导致文档与产品的特性不相符。

⑥ Alpha和 Beta测试 (Alpha and Beta Test): 在正式发布产品之前往往要先发布一些测试版,让用户能够反馈出相关信息,或者找到存在的 Bug,以便在正式版中得到解决。

 

还有一种分类方法将测试方法分为如下几种。

(1) 白盒测试 (White Box Testing)

又叫做玻璃盒测试 (Glass Box Testing)。在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主,有时候 SDE/T也会辅助开发人员进行测试。

(2) 黑盒测试 (Black Box Testing)

黑盒测试的内容主要有以下几个方面。

① 接受性测试 (Acceptance Testing):类似于 BVT测试。

② Alpha/Beta测试 (Alpha/Beta Testing): 在此过程中,产品特征不断地修改。当发现 Bug后,在开发人员修改的同时,项目经理也会对产品计划做出相应的调整,产品计划不是一成不变的

 菜单 / 帮助测试 (Menu/Help Testing) :大家千万不要以为这一项测试不值得进行。其实,在软件产品开发的最后阶段,文档里发现的问题往往是最多的。因为在软件测试过程中,开发人员会修复侧试人员发现的 Bug ,而且可能会对软件的有些功能进行修改,同时项目经理也会根据情况调整软件的特性,因而在软件开发和测试的过程中,所有的功能都不是固定不变的,都会进行调整。所以,一般来说,直到软件Ship 时才编写软件的帮助文档,这样才能保证帮助文件的内容与软件功能相符,我在做帮助文件测试的时候,总是假装什么都不懂,就按照帮助文件提供的步骤去做,看看该文件是否正确。在实际测试中,我经常能发现帮助文件中的 Bug 

 发行测试  Release Testing ):在正式发行前,产品要经过非常仔细的测试。除了专门的测试人员外,还需要几千个甚至几十万其他用户与合作者通过亲自使用来对产品进行测试,然后将错误信息反馈给我们。到了发行测试这一步,如果出现非改不可的 Bug ,就必须推迟软件的发行,有的时候一推就是几个月,期间需要重新对软件产品进行全面的测试,耗费大量的时间和人力物力。

 回归测试  Regression Testing ):回归测试的目的就是保证以前已经修复的 Bug 在软件 Ship 以前不会再出现。实际上,许多 Bug 都是在回归测试时发现的,在此阶段,我们首先要检查以前找到的 Bug是否已经更正了。值得注意的是,已经更正的 Bug 也可能有回来了,有的 Bug 经过修改之后可能又产生了新的 Bug 。所以,回归测试可保证已更正的 Bug 不再重现,不产生新的 Bug 

 RTM 测试( Release To Manufacture Testing ):为产品真正的 Ship 做好准备所进行的测试。事实上,在这一测试阶段,对每一个 Bug 都需要经过很高职务的人同意才能更正。因为这时候修改软件非常容易产生其他的错误,所以只有那种非修复不可的 Bug 才会被允许进行修改。如果在发行阶段软件还有许多严重的 Bug 的话,恐怕就不能按时发布了。记得有一次一个微软核心产品刚刚完成,准备 Ship 时,我对其进行 RTM 测试时就发现一个 Bug :只要用该产品打印中文就会导致程序错误。这是一个很严重的 Bug ,浴室开发人员马上修复了该 Bug ,重新 Ship 该产品。

 

功能及系统测试( Function  System Testing ):这一点是最重要的,他包括了非常多的内容。

Ø          规范验证 (Specification Verification 

Ø          正确性 (Correctness 

Ø          可用性 (Usability 

Ø          边界条件 (Boundary Condition 

Ø          性能 (Performance)

Ø          强力测试 (Stress)

Ø          错误恢复 (Error Recovery)

Ø          安全性 (Security)

Ø          兼容性 (Compatibility)

Ø          软件配置 (Configuration)

Ø          软件安装 (Installation)