在linux下一些常用的关机/重启命令有shutdown、halt、reboot、及init，它们都可以达到重启系统的目的，但每个命令的内部工作过程是不同的，通过本文的介绍，希望你可以更加灵活的运用各种关机命令。

1.shutdown

shutdown命令安全地将系统关机。 有些用户会使用直接断掉电源的方式来关闭linux，这是十分危险的。因为linux与windows不同，其后台运行着许多进程，所以强制关机可能会导致进程的数据丢失﹐使系统处于不稳定的状态﹐甚至在有的系统中会损坏硬件设备。而在系统关机前使用shutdown命令﹐系统管理员会通知所有登录的用户系统将要关闭。并且login指令会被冻结﹐即新的用户不能再登录。直接关机或者延迟一定的时间才关机都是可能的﹐还可能重启。这是由所有进程〔process〕都会收到系统所送达的信号〔signal决定的。这让像vi之类的程序有时间储存目前正在编辑的文档﹐而像处理邮件〔mail〕和新闻〔news〕的程序则可以正常地离开等等。

shutdown执行它的工作是送信号〔signal〕给init程序﹐要求它改变runlevel。Runlevel 0被用来停机〔halt〕﹐runlevel 6是用来重新激活〔reboot〕系统﹐而runlevel 1则是被用来让系统进入管理工作可以进行的状态﹔这是预设的﹐假定没有-h也没有-r参数给shutdown。要想了解在停机〔halt〕或者重新开机〔reboot〕过程中做了哪些动作﹐你可以在这个文件/etc/inittab里看到这些runlevels相关的资料。

shutdown 参数说明:

　　 [-t] 在改变到其它runlevel之前﹐告诉init多久以后关机。

　　 [-r] 重启计算器。

　　 [-k] 并不真正关机﹐只是送警告信号给每位登录者〔login〕。

　　 [-h] 关机后关闭电源〔halt〕。

　　 [-n] 不用init﹐而是自己来关机。不鼓励使用这个选项﹐而且该选项所产生的后果往往不总是你所预期得到的。

　　 [-c] cancel current process取消目前正在执行的关机程序。所以这个选项当然没有时间参数﹐但是可以输入一个用来解释的讯息﹐而这信息将会送到每位使用者。

　　 [-f] 在重启计算器〔reboot〕时忽略fsck。

[-F] 在重启计算器〔reboot〕时强迫fsck。

　　 [-time] 设定关机〔shutdown〕前的时间。 　 　　

2.halt----最简单的关机命令

其实halt就是调用shutdown -h。halt执行时﹐杀死应用进程﹐执行sync系统调用﹐文件系统写操作完成后就会停止内核。

参数说明:

　　 [-n] 防止sync系统调用﹐它用在用fsck修补根分区之后﹐以阻止内核用老版本的超级块〔superblock〕覆盖修补过的超级块。

　　 [-w] 并不是真正的重启或关机﹐只是写wtmp〔/var/log/wtmp〕纪录。

　　 [-d] 不写wtmp纪录〔已包含在选项[-n]中〕。

　　 [-f] 没有调用shutdown而强制关机或重启。

　　 [-i] 关机〔或重启〕前﹐关掉所有的网络接口。

　　 [-p] 该选项为缺省选项。就是关机时调用poweroff。 　

3.reboot

4.init
转自：小毛驴的个人空间
http://www.51testing.com/?46301/action_viewspace_itemid_94284.html

--找出表中91-100之间的记录条数
select top 10 StartDate from QY_ZpInfo where StartDate in(select top 100 StartDate from QY_ZpInfo order by StartDate asc)order by StartDate Desc

//求13的13次方的后三位数(比较简单了,总结下而已,路过的不要笑)

#include "iostream.h"
void main()
{
 long i=13,x,y,a,b,c,sum1=1,sum2=1,sum3=1;
 int j;
 for(j=0;j<=6;j++)
 {
  sum1=sum1*i;
 }
 x=sum1%1000;//考虑到会有数据溢出,所以先做7次13
 for(j=0;j<=5;j++)
 {
  sum2=sum2*i;
 }
 y=sum2%1000;//再做6次13
 sum3=x*y;//取后3位相乘
 a=sum3%10;
 b=(sum3%100-a)/10;
 c=(sum3%1000-10*b-a)/100;
 cout<<c<<b<<a<<endl;
}

等价类划分法

测试用例

先讲创建邮箱的规则
要判定邮箱地址，那我们必须先设定我们邮箱命名的规则
这里我们以Gmail为例,创建邮箱时候只写用户名，后缀会直接加上@gmail.com

only letters (a-z), numbers (0-9), and periods (.)  is allowed，
the first character of your username must be an ascii letter (a-z) or number (0-9)
username must be between 6 and 30 characters long
无效等价类如下
(1)邮箱名组成有"a-z","0-9", ".'以外的字符   eg.#!12#,ewewe
(2)邮箱名长度 小于6，大于30个字符   eg. werw, wew...
(3)邮箱名以以"."号开始    eg. .test

---------------
我们的应用程序填写表单时判定邮箱是否为有效邮箱，一般判定规则为
(1)@(2).(3)

(1)为任意字符串，长度5～100 
        (邮箱名没有太严格的限制，比如说一般不会以"_"做开始符，结束符;有的邮箱还不能用特殊符号等等。是因为各种邮箱都有不同的命名规则，所以我们不做限制)
(2)为任意字符串，长度1～30
(3)为任意字符串，长度2～67
        [(2),(3)就是域名，其实域名是有要求的,可以看看这里http://www.39idc.com/help/hlp_dtl.asp?nid=10000022
        国际域名可使用英文26个字母,10个阿拉伯数字以及横杠("-")，横杠不能作为开始符和结束符，这里并不做太多限制，太多了...]
(4)必须要有@符号
(5)必须要有.
(6)@后面没有以*.*结束(*为任意字符串)
(7)域名不能使用"_"作为了开始符，结束符

无效等价类:
不符合(1)/(2)/(3)/(4)/(5)/(6)/(7)
不符合(1)(2)/(1)(3)/(1)(4)/(1)(5)/(1)(6)/(1)(7)
不符合(2)(3)/(2)(4)/(2)(5)/(2)(6)/(2)(7)
。。。。 以上各个任意组合， eg. 就没写了，太多了
所以说繁琐的测试工作我们需要工具来做....

--------------------------------------------------------
邮箱文本框测试用例
1) 有@和.符号
1。 @和.之间没有字符串
2。 字符串的第一位是@或.
3。 字符串的最后一位是@或.
4。 有@和.符号，并有特殊字符
2) 没有@和.符号
3) @/.符号中只有一个
4) 有@@符号重复
5) 有..符号重复
------

压力测试实例

利用现代的设计技术和正式的技术复审可以减少代码中存在的初始错误，但是错误总是存在的，如果开发者找不到错误，那么，客户就会找到它们。越来越多的软件组织认识到软件测试是软件质量保证的重要元素之一，很多软件开发组织将30%—40%甚至更多的项目资源用在测试上，软件测试技术和软件测试策略受到了高度的重视和广泛的应用。

本文不想就软件测试技术和软件测试策略作深入的理论分析，而是列举一个在软件系统测试阶段进行的压力测试实例，希望能通过这个实例与从事软件测试相关工作的朋友进行交流。

首先介绍一下实例中软件的项目背景，该软件是一个典型的三层C/S架构的MIS系统（客户端/应用服务器/数据库管），中间层是业务逻辑层，应用服务器处理所有的业务逻辑，但应用服务器本身不提供负载均衡的能力，而是利用开发工具提供的ORB（对象请求代理）软件保证多个应用服务器间的负载均衡。本次测试的目的是：进行单个应用服务器的压力测试，找出单个应用服务器能够支持的最大客户端数。测试压力估算的依据是：假定在实际环中，用户只启用一个应用服务器进行所有的业务处理。方法是：按照正常业务压力估算值的1~10倍进行测试，考察应用服务器的运行情况。

压力测试的详细计划如下：

压力测试计划

1、测试计划名称

河北省公安交通管理信息系统压力测试计划。

2、测试内容

2.1背景

本次测试中的压力测试是指模拟实际应用的软硬件环境及用户使用过程的系统负荷，长时间运行测试软件来测试被测系统的可靠性，同时还要测试被测系统的响应时间。

用户的实际使用环境：

◇由两台IBM XSeries250 PC Server组成的Microsoft Cluster；

◇数据库管理系统采用Oracle8.1.6；

◇应用服务器程序和数据库管理系统同时运行在Microsoft Cluster上。

◇有200个用户使用客户端软件进行业务处理，每年通过软件进行处理的总业务量为：150万笔业务/年。

2.2测试项

应用服务器的压力测试；

2.3不被测试的特性

◇系统的客户端应用程序的内部功能；

◇数据库中的数据量对程序性能的影响。

3、测试计划

3.1测试强度估算

测试压力估算时采用如下原则：

◇全年的业务量集中在8个月完成，每个月20个工作日，每个工作日8个小时；

◇采用80—20原理，每个工作日中80%的业务在20%的时间内完成，即每天80%的业务在1.6小时内完成；

测试压力的估算结果：

去年全年处理业务约100万笔，其中15%的业务处理每笔业务需对应用服务器提交7次请求；

70%的业务处理每笔业务需对应用服务器提交5次请求；其余15%的业务每笔业务向应用服务器

提交3次请求。根据以往统计结果，每年的业务增量为15%，考虑到今后三年业务发展的需

要，测试需按现有业务量的2倍进行。

每年总的请求数量为：（100*15%*7+100*70%*5+100*15%*3）*2=300万次/年。

每天的请求数量为：300/160=1.875万次/天。

每秒的请求数量为：（18750*80%）/（8*20%*3600）=2.60次/秒。

正常情况下，应用服务器处理请求的能力应达到：3次/秒。

3.2测试环境准备

3.2.1基本硬件及软件环境的准备

1)网络环境：公司内部的以太网，与服务器的连接速率为100M，与客户端的连接速率为10/100M自适应。

2)使用两台IBM XSeries250（1G内存）PC Server作Microsoft Cluster，安装系统软件 Windows 2000 Advance Server及Microsoft Cluster Server（MSCS）。

3)数据库管理系统的安装及配置：在测试用的IBM XSeries服务器上安装Oracle8.1.6，数据库采用Oracle Fail Safe（ofs）的Active/Passive配置。 安装数据库管理系统及支撑软件（包括VisiBroker和BDE Administrator）。

4)安装被测的应用服务器程序。

5)客户端的PC机：10台（PⅢ600/128M RAM）。

3.2.2系统客户端测试程序的编写系统客户端测试程序使用Delphi编写，要求测试程序实现如下功能：

1)模拟一个主要的向应用服务器发送请求并接收响应信息的功能。要求交替模拟两种情况：第一种，发送的请求至少包括10个参数，参数类型涵盖字符、日期、数字种类型；接收的响应信息不少于1个参数；第二种，发送的请求不少于1个参数；接收的响应信息至少包括10个参数，参数类型涵盖字符、日期、数字种类型。

2)必须能够通过参数设定在每台PC机上运行的客户端测试程序个数、请求的时间间隔（单位：毫秒）、运行时间（单位：小时）。

3)在数据库中建立测试记录表，生成测试记录，向数据库写入测试记录的功能不通过被测的应用服务器实现。日志内容包括：发送测试请求的机器名、客户端测试程序序号、发出请求时间、收到响应时间、处理是否成功。表名：TEST_LOG，字段名：MACHINE、ID、START_TIME、END_TIME、FLAG。

3.2.3系统本底数据的准备

为考察系统运行一段时间后系统的响应性能，参照实际运行情况及发展进行系统的本底数据准备。业务处理中涉及到的业务表中都要求按设计规模进行本底数据的准备。要求准备的数据记录的有效性符合系统要求，数据有效性的具体要求参见数据库设计及系统设计文档。

3.3破坏性测试

按照设计连接的客户端连接数量进行测试，把应用服务器处理请求的设计频度增加1－10倍，分别测试出现错误的状态和和出现错误的比率，考察是否出现不可恢复错误，系统设计要考虑出现严重错误情况下负荷减轻错误自动恢复的实现方法。

计划时间：2天；这个时间包括破坏性的修复和自动恢复的实现需要的时间。

在测试过程中每10分钟记录一次IBM Xseries PC Server的内存及CPU使用情况，包括被测程序的内存占用百分比、数据库管理系统的内存占用百分比、操作系统的内存占用百分比。

3.4强度稳定性测试

选择一种负荷比设计负荷重的情况（应用服务器处理请求的频度为应用服务器处理请求的

设计频度的1.5倍），进行24小时稳定性测试。

3.5测试方法和工具

黑盒测试

测试工具：无外购的测试工具，自己编制的测试工具。

3.6测试时间计划

3.6.1环境准备：2天。

其中：基本硬件、软件环境及系统本底数据的准备：1天，

系统客户端测试程序的编写及测试：1天。

3.6.2破环性测试：2天。

3.6.3强度稳定性测试：1天。

3.7测试中的问题及处理

3.7.1暂停标准和再启动要求

暂停标准：被测试软件在强度稳定性测试中频繁出现异常（每小时出现1次以上）时。用户或公司要求暂停测试时。

再启动要求：通过调试后，预计被测试软件的可靠性有所提高时，可再次启动测试。

3.7.2不可预见问题

不可预见问题包括：

◇测试环境被破坏而导致测试无法进行；

◇当出现上述不可预见问题时，测试终止，就已完成的测试内容编制测试总结报告，并在报告中说明测试终止的原因。

3.8测试报告 2002.06.21

测试总结报告提交日期：2002.06.21。

3.8.1应生成的测试文件

测试记录（测试负责人和参与测试的人员签字）；

测试总结报告。

3.8.2测试总结报告中必须包含的内容

被测试软件名称、测试项、测试环境；

被测试软件的压力测试结论：响应时间、最大/最小并发数、失败的次数、正常连续运行的最长/最短时间，并发数与失败的关系。

4、人员和职责

4.1职责

测试工程师：负责编写测试计划，组织测试，对测试过程进行记录，收集、整理测试记录数据，对测试结果进行分析，编写测试总结报告。

软件工程师：负责编写、调试客户端测试软件；数据库管理系统的安装、ofs配置及系统的本底数据准备。

系统工程师：负责测试用的硬件维护及操作系统安装、MSCS配置。

总工程师：负责对测试计划及测试总结报告进行批准。

用户：必要时可参加测试，并提出具体的测试要求；可要求暂停测试。

4.2人员和训练要求

本次测试无特别的人员及培训要求。

5、批准

本测试计划必须经过总工程师批准后才能开始实施。

　　一天中午，丈夫在外给家里打电话：“亲爱的老婆，晚上我想带几个同事回家吃饭可以吗？” (订货意向)

　　妻子：“当然可以，来几个人，几点来，想吃什么菜？”

　　丈夫：“6个人，我们7点左右回来，准备些酒、烤鸭、番茄炒蛋、凉菜、蛋花汤……。你看可吗？” (商务沟通)

　　妻子：“没问题，我会准备好的。” (订单确认)

　　妻子记录下需要做的菜单 (MPS计划) ，具体要准备的东西：鸭、酒、番茄、鸡蛋、调料…… (BOM物料清单) ，发现需要：1只鸭蛋，5瓶酒，4个鸡蛋…… (BOM展开) ，炒蛋需要6个鸡蛋，蛋花汤需要4个鸡蛋 (共用物料) 。

　　打开冰箱一看 (库房) ，只剩下2个鸡蛋 (缺料) 。

　　来到自由市场，妻子：“请问鸡蛋怎么卖？” (采购询价)

　　小贩：“1个1元，半打5元，1打9.5元。”

　　妻子：“我只需要8个，但这次买1打。” (经济批量采购)

　　妻子：“这有一个坏的，换一个。” (验收、退料、换料)

　　回到家中，准备洗采、切菜、炒菜…… (工艺线路) ，厨房中有燃气灶、微波炉、电饭煲…… (工作中心) 。

　　妻子发现拨鸭毛最费时间 (瓶颈工序，关键工艺路线) ，用微波炉自己做烤鸭可能来不及 (产能不足) ，于是阅览室在楼下的餐厅里买现成的 (产品委外) 。

　　下午4点，接到儿子的电话：“妈妈，晚上几个同学想来家里吃饭，你帮忙准备一下。” (紧急订单)

　　“好的，你们想吃什么，爸爸晚上也有客人，你愿意和他们一起吃吗？”

　　“菜你看着办吧，但一定要有番茄炒鸡蛋，我们不和大人一起吃，6：30左右回来。” (不能并单处理)

　　“好的，肯定让你们满意。” (订单确定)

　　“鸡蛋又不购了，打电话叫小店送来。” (紧急采购)

　　6：30，一切准备就绪，可烤鸭还没送来，急忙打电话询问：“我是李太，怎么订的烤鸭还不送来？” (采购委外单跟催)

　　“不好意思，送货的人已经走了，可能是堵车吧，马上就会到的。”

　　门铃响了。

　　“李太太，这是您要的烤鸭。请在单上签一个字。” (验收、入库、转应付账款)

　　6：45，女儿的电话：“妈妈，我想现在带几个朋友回家吃饭可以吗？” (呵呵，又是紧急订购意向，要求现货)

　　“不行呀，女儿，今天妈已经需要准备两桌饭了，时间实在是来不及，真的非常抱歉，下次早点说，一定给你们准备好。” (哈哈，这就是ERP的使用局限，要有稳定的外部环境，要有一个起码的提前期) 。

　　…… ……

　　送走了所有客人，疲惫的妻子坐在沙发上对丈夫说：“亲爱的，现在咱们家请客的频率非常高，应该要买些厨房用品了 (设备采购) ，最好能再雇个小保姆 (连人力资源系统也有缺口了) 。

　　丈夫：“家里你做主，需要什么你就去办吧。” (通过审核)

　　妻子：“还有，最近家里花销太大，用你的私房钱来补贴一下，好吗？” (最后就是应收货款的催要)

　　现在还有人不理解ERP吗？记住，每一个合格的家庭主妇都是生产厂长的有力竞争者。

本文转自：我在这里个人博客

http://www.51testing.com/?action/viewspace/itemid/84586.html

   有一天我老大开完会就对我说:公司要我们帮开发人员培训一下,主题是:软件中常出现错误的地方.我听了这句话后就觉得很模糊,不能理解它的意思,因为我不知道他是要我针对某个软件或程序来说还是针对所有软件来说,如果是针对某个软件或程序来说的话这也没有什么问题,但如果针对所有软件来说的话,那我真是不知道怎么说了.不同的软件有不同的功能和特性,也有不同的操作方式,而且业务性质也不尽相同,所以要让我说出这些软件容易出现问题的地方那真是难透了，再说我才刚毕业，经验还没到家啊。

    就在这时候，我想了一想，虽然每个软件有不同的功能，特性和操作方式，但它们彼此之间也有一些共同点，不过我理解的是，这些共同不是在一些细节上面，如输入框，按钮之类的，而是一种比较概念化的理解上，而要理解透也是很简单，那就是：业务，性能，边界值和等价类。（声明：下面我所说的是我自已的个人观点而已，不代表所有人的立场。）

业务我想所有人都应该很容易理解了，如果软件的业务功能达不到需求上所规定的要求那样的话，这根本就不能再继续执行测试，只能打回给开发部再进行修改，我想这个缺陷毫无疑问是最严重的吧，如果这个软件已开发到后期的时候，不知道已经浪费了多少人力资源了。能够发现业务问题的可以使用因果图法。

然后就是性能，每个软件都有它的性能，特别是对于C/S和B/S结构的软件来说，它的服务端的性能就是我们要测试的重点了，当然也不能把客户端的忽略掉。所以从这点看出，性能也是所有软件中所出现问题的共同点，不过性能问题有时也让人摸不着头脑的，例如：如果有一个服务端程序分别安装在两个配置不一样的服务器上面，可能得出的结果不尽相同，配置低一点的服务器响应的时间会比较长，而配置高一些的服务器的响应时间可能会很短从而达到需求所规定的时间；又或者在不同网络的情况下来对服务端进行性能测试，得到的结果也不一样（网络堵塞或者网络畅通的情况下）；这样我们可能就会这样问：那系统到底达到要求没有啊？其实我说这个东西啊，就要看当初需求上所对服务器的配置和不同因络的情况下所规定下来所决定的，如果在规定配置的服务器上达不到所规定的响应时间的话，那毫无疑问这个程序是存在性能问题了，而如果所发现的性能问题是难以修改或会耗费比较大的资源的话，那就可以和用户沟通来提高服务器的硬件配置来解决性能上的问题。还有就是网络吞吐量的问题，这个一定要在需求上有所规定，如在网络畅通的情况下最大的响应时间是多少，而在网络堵塞的情况下系统最大的响应时间又是多少，或者在大量用户并发的情况下系统的响应最大时间又是多少，如果在当初的需求上没有作出相应的规定话，那到问题出现时就可能会争论不休了。

最后就是边界值和等界类了，每个软件都有一定的输入边界和输入范围，而有时程序员可能因为其他原因而会忽略这两点，所以一些教程上经常会说边界值和等价类是最容易发现问题的测试方法，我在工作中也用这两种方法发现过不少问题，这个我就不多说了，因为我想每个测试人员都会知道这一知识点的。

说到这里，我也觉得自已很烦，不知道为什么要对这个问题写一篇这样的文章，其实这个问题是不重要的，对于我们来说，最重要的说要发现问题，而且要找出所出现问题的原因。

本文转自：bossy的个人空间

http://www.51testing.com/index.php?uid/92053/action/viewspace/itemid/70443/php/1

测试经理：

通常书写Test Case时需要考虑的检查点

对于屏幕显示来说包括：
检查显示的布局；
检查域和按钮的顺序；
检查域的尺寸；
检查字体的大小和风格；
检查文本的含义；
检查拼写错误；
检查屏蔽域；
检查只读域；
检查图片；
检查按钮的状态；
检查按钮的尺寸；
检查按钮的图标和名字；
检查是否有重复的图标；
检查指针是否在第一个可输入域；
检查TAB键的次序；

对于域来说包括：
检查可编辑性；
检查域间的移动；
检查分界条件；
检查有效分界符；
检查无效分界符；
检查连续多个有效分界符；
检查仅一个分界符输入；
检查多余空格的截取；
检查只读域和屏蔽域在TAB时的状态；

对于数字域来说包括：
检查正数值；
检查负数值；
检查零值；
检查小数点；
检查特殊字符加数字；
检查字母加数字；
检查ASCII值；
检查重复值；
检查空值；

对于字符域来说包括：
检查仅有字母；
检查仅有数字；
检查字母数字；
检查允许的特殊字符；
检查禁止的特殊字符；
检查包含特殊字符的字母数字；
检查ASCII值；

对于字母域来说包括：
检查字母；
检查数字值；
检查字母数字值；
检查特殊字符；
检查ASCII值；

对于时间域来说包括：
检查字符?和/；
检查其他特殊字符；
检查字母数字值；
检查正确的格式；
检查错误的格式；
检查错误的日期数字；
检查正确的日期数字；
检查日历表；

对于错误信息和警告信息来说：
检查错误信息和警告信息的含义；
检查错误信息和警告信息的一致性；
检查确定位置的错误信息；
检查错误信息后的光标位置；
检查所有异常对应的错误信息；
检查错误信息的格式；

对于普通的检查来说：
检查文本域和字符域输入是否左对齐；
检查数字域输入是否右对齐；
检查标签的切换；
检查重复的名字；
检查可删除的表格；
检查表格的多选；
检查过滤器的逻辑性；
检查多个过滤器的逻辑性；
检查重复的序列号；
检查显示切换；
检查快捷键；
检查工具栏提示；
检查日期域是否居中；
检查选择项的高显；
检查选择符；
检查显示窗口的风格统一性；

对于按键的功能包括：
New button：
检查包含next和cancel按键的子窗口的显示；
检查子窗口显示的内容；
Add button：
检查包含save和cancel按键的子窗口的显示；
Edit button：
检查在未选择项目情况下点击后的警告信息；
检查包update和cancel按键的子窗口的显示；
检查选择的项目是否显示在制定的位置；
Copy button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查插入后的复制数据；
Delete button：
检查在未选择项目情况下点击后的警告信息；
检查点击后的确认信息；
检查删除后的数据；
Run button：
检测运行时的参数窗口；
检查执行结果；
检查未选择项目情况下点击后的警告信息；
Back button：
检查是否回到上一屏幕；
Next button：
检查是否显示下一屏幕；
Finish button：
检查数据是否进入数据库；
检查完成屏幕的显示；
Cancel button：
检查确认信息；
检查是否有其他键执行同样功能；
检测是否能能够正确处理； 

============卸载测试==============
文件－－－－安装目录里的文件及文件夹（如：程序安装在几处的)
　　　　　　非安装目录（向系统其它地方添加的文件及文件夹)它们包括（exe,dll,配置文件等)

快捷方式－（桌面，菜单，任务栏，系统栏,控件面板，系统服务列表等）

复原方面－卸载后，系统能否恢复到软件安装前的状态（包含目录结构、动态库,注册表，系统配置文件,驱动程序,关联情况等）

卸载方式－－程序自带卸载程序/系统的控件面板卸载/其它自动卸载工具（如:优化大师)

卸载状态－－程序在运行/暂停/终止等状态时的卸载

非正常卸载情况－卸载软件过程中，取消卸载进程，然后，观察软件能否继续正常使用

冲击卸载－－在卸载的过程中，中断电源，然后，启动计算机后，重新卸载软件，如果软件无法卸载，则重新安装软件，安装之后再重新卸载。

卸载环境－－不同的(操作系统，硬件环境，网络环境等)下进行卸载

卸载后,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)

==========安装测试============
一：基本目标
1.安装程序能正确运行
2.程序安装正确
3.程序安装后能正确运行
4.完善性安装后程序能正确运行

二：一些方面
0、安装手册给的所有步骤得到验证；
1、安装过程中所有缺省选项得到验证；
2、安装过程中典型选项得到验证；
3、测试各种不同的安装组合，并验证各种不同组合的正确性(包括参数组合，控件执行顺序组合，产品安装组件组合，产品组件安装顺序组合(如b/s)等)
4、安装过程中异常配置或状态（非法和不合理配置）情况进行了测试(如：断电；数据库终止，网络终止等)
5、安装后是否能产生正确的目录结构和文件，文件属性正确；
6、安装后动态库是否正确；
6、安装后软件能否正确运行；
7、安装后没有生成多余的目录结构,文件，注册表信息，快捷方式等；
9、安装测试应该在所有的运行环境上进行验证(手册上指定如：操作系统，数据库，硬件环境，网络环境等)；
10、自动安装还是手工配置安装
11、至少要在一台笔记本上进行安装/卸载测试，因为有很多产品在笔记本中会出现问题，尤其是系统级的产品
13、安装,该系统是否对其他的应用程序造成不正常影响（如操作系统,应用软件等)