1.       安装前环境配置

TD的WEB服务容器为IIS，必须得先安装IIS环境。

TD的后台数据库默认为Access，可以选择使用Sybase、 MS-SQL Server、 Oracle。

TD也支持邮件服务，可以选择安装邮件服务或则暂时不安装。如果需要安装则在安装前做好邮件服务器的相关配置。

2.       安装事项

在安装时，要对系统进行一些安装设置，以下对一些关键设置进行简单解释。

1）数据库连接设置


设置数据库连接时，Access为默认必选，可以选择另外一种合适的数据库做为TD的连接数据库，该数据库可以在创建TD项目时，选择作为项目的数据库。

2）虚拟目录设置


其中的虚拟目录名TDBIN下将保存TD的一些运行文件。



3.       安装注意

安装TD时，系统资源消耗比较大，容易造成安装失败或错误，所以在安装时，尽不要进行其他的系统操作，等待安装完成。

4.       安装后配置

1）  汉化

在安装目录TDBIN/Install/下存放的是一些为连接服务的客户端加载的系统文件。其中的tdclientui80.xco文件，该文件会自动加载到客户端的C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下，并生成为tdclientui80.ocx文件。

注意其中两个文件的后缀名区别。文件后缀可通过更改方式变换为OCX或XCO。

由于Mercury并为发行官方的汉化包，所以采用第三方的资源包进行汉化。汉化方式，把得到的汉化资源dclientui80.xco文件粘贴到服务器TDBIN/Install/目录下，覆盖掉原文件即可。

在之前访问过服务器的客户端，在下次连接时由于不再加载更新后的数据，所以必须得删除客户端下的C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下覆盖tdclientui80.ocx文件，使再次访问时自动加载汉化后的新组件。

也可以通过在客户端C:\Program Files\Common Files\Mercury Interactive\TD2000_80目录下覆盖tdclientui80.ocx文件达到汉化的目的。


2）  设置MS-SQL的数据库连接

对数据库的“客户端网络实用工具”进行配置。选择协议Named Pipes与TCP/IP，别名设置最好选择本机计算机名。

对数据库的安全性设置--身份验证，设置为SQL Server和WINDOWS。

设置后，在后台PING连接数据库，如果成功，则可正常创建该类数据库的项目。


3）  IE7.0兼容性

安装TD后，并不能顺利支持IE7.0的客户端浏览器。此时可以用记事本等打开服务器TDBIN/目录下的start_a.htm源文件，然后进行编辑。

查找” var fMSIE3456”

然后在该行的末尾处分号前添加一段语句”|| (ua.lastIndexOf('MSIE 7.0') != -1)”

保存即可。

或者

TD中不支持7.0版本，解决方法如下：
将虚拟目录下的首页文件如C:\Inetpub\TDBIN\start_a.htm(用记事本打开)这个页面中的
var fMSIE3456 = (ua.lastIndexOf('MSIE 3.0') != -1) || (ua.lastIndexOf('MSIE 4.0') != -1) || (ua.lastIndexOf('MSIE 5.0') != -1) || (ua.lastIndexOf('MSIE 5.5') != -1) || (ua.lastIndexOf('MSIE 6.0') != -1) 后加上|| (ua.lastIndexOf('MSIE 7.0') != -1)即可；

4）TD系统信息修改

在C:\Program Files\Common Files\Mercury Interactive\目录中的DomsInfo文件夹，该文件夹中保存TD系统的关键信息，其中有TD系统配置信息的数据库doms.mdb文件，该数据库文件已默认被加密，密码为tdtdtd。在Templates文件夹中的文件为初始化生成的项目模板文件，包括TestDir.mdb，该文件为生成项目的初始数据库表。这样的话我们，就可以在每次创建项目时初试化出我们想要的，预定好的数据库表和相关数据来。就可以避免每次创建项目时重复的手工定义字段了，我们可以定制自己的项目数据库模板。



如当遗忘ADMIN的密码时，可以通过往doms.mdb的ADMIN表中的ADMIN_PSWD字段更换写入“456711”，登陆时输入密码“test”即可进入。

1、能发现到目前为止没有发现的缺陷的用例是好的用例：
首先要申明，其实这句话是十分有道理的，但我发现很多人都曲解了这句话的原意，一心要设计出发现“难于发现的缺陷”而陷入盲目的片面中去，忘记了测试的目的所在，这是十分可怕的。我倾向于将测试用例当作一个集合来认识，对它的评价也只能对测试用例的集合来进行，测试本身是一种“V&V”的活动，测试需要保证以下两点：

    * 程序做了它应该做的事情
    * 程序没有做它不该做的事情

因此，作为测试实施依据的测试用例，必须要能完整覆盖测试需求，而不应该针对单个的测试用例去评判好坏。

2、测试用例应该详细记录所有的操作信息，使一个没有接触过系统的人员也能进行测试；
      不知道国内有没有公司真正做到这点，或者说，不知道有国内没有公司能够将每个测试用例都写得如此详细。在我的测试经历中，对测试用例描述的详细和复杂程度也曾有过很多的彷徨。写得太简单吧，除了自己没人能够执行，写得太详细吧，消耗在测试用例维护（别忘了，测试用例是动态的，一旦测试环境、需求、设计、实现发生了变化，测试用例都需要相应发生变化）上的时间实在是太惊人，在目前国内大部分软件公司的测试资源都不足的情况下，恐怕很难实现。但我偏偏就能遇到一些这样的老总或者是项目负责人，甚至是测试工程师本身，全然不顾实际的资源情况，一定要写出“没有接触过系统的人员也能进行测试”的用例。
      在讨论这个问题之前，我们可以先考虑一下测试的目的。测试的目的是尽可能发现程序中存在的缺陷，测试活动本身也可以被看作是一个Project，也需要在给定的资源条件下尽可能达成目标，根据我个人的经验，大部分的国内软件公司在测试方面配备的资源都是不足够的，因此我们必须在测试计划阶段明确测试的目标，一切围绕测试的目标进行。
      除了资源上的约束外，测试用例的详细程度也需要根据需要确定。如果测试用例的执行者、测试用例设计者、测试活动相关人对系统了解都很深刻，那测试用例就没有必要太详细了，文档的作用本来就在于沟通，只要能达到沟通的目的就OK。
      在我担任测试经理的项目中，在测试计划阶段，一般给予测试设计30% - 40%左右的时间，测试设计工程师能够根据项目的需要自行确定用例的详细程度，在测试用例的评审阶段由参与评审的相关人对其把关。

3、测试用例设计是一劳永逸的事情；
      这句话摆在这里，我想没有一个人会认可，但在实际情况中，却经常能发现这种想法的影子。我曾经参与过一个项目，软件需求和设计已经变更了多次，但测试用例却没有任何修改。导致的直接结果是新加入的测试工程师在执行测试用例时不知所措，间接的后果是测试用例成了废纸一堆，开发人员在多次被无效的缺陷报告打扰后，对测试人员不屑一顾。
      这个例子可能有些极端，但测试用例与需求和设计不同步的情况在实际开发过程中确是屡见不鲜的，测试用例文档是“活的”文档，这一点应该被测试工程师牢记。

4、测试用例不应该包含实际的数据；
      测试用例是“一组输入、执行条件、预期结果”、毫无疑问地应该包括清晰的输入数据和预期输出，没有测试数据的用例最多只具有指导性的意义，不具有可执行性。当然，测试用例中包含输入数据会带来维护、与测试环境同步之类的问题，关于这一点，《Effective Software Test》一书中提供了详细的测试用例、测试数据的维护方法，可以参考。

5、测试用例中不需要明显的验证手段；
      我见过很多测试工程师编写的测试用例中，“预期输出”仅描述为程序的可见行为，其实，“预期结果”的含义并不只是程序的可见行为。例如，对一个订货系统，输入订货数据，点击“确定”按钮后，系统提示“订货成功”，这样是不是一个完整的用例呢？是不是系统输出的“订货成功”就应该作为我们唯一的验证手段呢？显然不是。订货是否成功还需要查看相应的数据记录是否更新，因此，在这样的一个用例中，还应该包含对测试结果的显式的验证手段：在数据库中执行查询语句进行查询，看查询结果是否与预期的一致。

一：等价类划分

　　是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

　　 1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

　　无效等价类:与有效等价类的定义恰巧相反.

　　设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

　　2）划分等价类的方法:下面给出六条确定等价类的原则.

　　①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

　　②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

　　③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

　　④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

　　⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

　　⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

　　3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

　　 输入条件 有效等价类 无效等价类
　　... ... ...
　　... ... ...

　　 然后从划分出的等价类中按以下三个原则设计测试用例:

　　①为每一个等价类规定一个唯一的编号.

　　②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

　　③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

二：边界值分析法

　　边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

　　长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

　　1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

　　2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

　　3）根据规格说明的每个输出条件,使用前面的原则1）.

　　4）根据规格说明的每个输出条件,应用前面的原则2）.

　　5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

　　6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

　　7）分析规格说明,找出其它可能的边界条件.

三：错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

四：因果图方法

　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.
　　因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

　　利用因果图生成测试用例的基本步骤:

　　(1) 分析软件规格说明描述中, 哪些是原因(即输入条件或输入条件的等价类),哪些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

　　(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

　　(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

　　(4) 把因果图转换为判定表.

　　(5) 把判定表的每一列拿出来作为依据,设计测试用例.

　　从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

　　前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

　　判定表通常由四个部分组成.

　　条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出的条件的次序无关紧要.

　　动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

　　条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

　　动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

　　规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

　　判定表的建立步骤:（根据软件规格说明）

　　①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.

　　②列出所有的条件桩和动作桩.

　　③填入条件项.

　　④填入动作项.等到初始判定表.

　　⑤简化.合并相似规则（相同动作）.

　　B. Beizer 指出了适合使用判定表设计测试用例的条件:

　　①规格说明以判定表形式给出,或很容易转换成判定表.

　　②条件的排列顺序不会也不影响执行哪些操作.

　　③规则的排列顺序不会也不影响执行哪些操作.

　　④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

　　⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

边界值法举例

找零钱最佳组合

假 设 商 店 货 品 价 格 (R) 皆 不 大 於 100 元 （ 且 为 整 数 ） ， 若 顾 客 付 款 在 100 元 内 (P) ， 求 找 给 顾 客 之 最 少 货币 个（张） 数 ？ （ 货 币 面 值 50 元 (N50) ， 10 元 (N10) ， 5 元 (N5) ， 1 元 (N1) 四 种 ）

一、 分 析 输 入 的 情 形 。

R > 100

0 < R < = 100


R <= 0


P > 100


R<= P <= 100


P < R

二、 分 析 输 出 情 形 。

N50 = 1

N50 = 0


4 > N10 >= 1


N10 = 0


N5 = 1


N5 = 0


4 > N1 >= 1


N1 = 0

三、 分 析 规 格 中 每 一 决 策 点 之 情 形 ， 以 RR1, RR2, RR3 表 示 计 算 要 找 50, 10, 5 元 货 币 数 时 之 剩 余 金 额 。 R > 100R <= 0
P > 100
P < R
RR1 >= 50
RR2 >= 10
RR3 >= 5

四、 由 上 述 之 输 入 ／ 输 出 条 件 组 合 出 可 能 的 情 形 。

R > 100

R <= 0


0 < R <= 100, P > 100
0 < R <= 100, P < R
0 < R <= 100, R <= P <= 100, RR = 50
0 < R <= 100, R <= P <= 100, RR = 49
0 < R <= 100, R <= P <= 100, RR = 10
0 < R <= 100, R <= P <= 100, RR = 9
0 < R <= 100, R <= P <= 100, RR = 5
0 < R <= 100, R <= P <= 100, RR = 4
0 < R <= 100, R <= P <= 100, RR = 1
0 < R <= 100, R <= P <= 100, RR = 0

五、 为 满 足 以 上 之 各 种 情 形 ， 测 试 资 料 设 计 如 下 ：

1. 货品价格 = 101

2. 货品价格 = 0

3.货品价格 = -1

4. 货品价格 = 100, 付款金额 = 101

5. 货品价格 = 100, 付款金额 = 99

6. 货品价格 = 50, 付款金额 = 100

7. 货品价格 = 51, 付款金额 = 100

8. 货品价格 = 90, 付款金额 = 100

9. 货品价格 = 91, 付款金额 = 100

10. 货品价格 = 95, 付款金额 = 100

11. 货品价格 = 96, 付款金额 = 100

12. 货品价格 = 99, 付款金额 = 100

13. 货品价格 = 100, 付款金额 = 100

========winrunner
1　启动时选择要加载的插件
2　进行一些设置（如录制模式等）
3　识别应用程序的GUI，即创建map(就是学习被测试软件的界面）
4　建立测试脚本（录制及编写）
5　对脚本除错及调试（保证能够运行完）
6　插入各种检查点（图片，文字，控件等）
7　在新版应用程序中执行测试脚本
8　分析结果，回报缺陷
　
=========quicktestpro========
1　准备录制
打开你要对其进行测试的应用程序，并检查QuickTest中的各项设置是否适合当前的要求。
2　进行录制
打开QuickTest的录制功能，按测试用例中的描述，操作被测试应用程序。
3　编辑测试脚本
通过加入检测点、参数化测试，以及添加分支、循环等控制语句，来增强测试脚本的功能，使将来的回归测试真正能够自动化。
4　调试脚本
调试脚本，检查脚本是否存在错误。
5　在回归测试中运行测试
在对应用程序的回归测试中，通过QuickTest回放对应用程序的操作，检验软件正确性，实现测试的自动化进行。
6　分析结果，报告问题
查看QuickTest记录的运行结果，记录问题，报告测试结果。

＝＝＝＝TestDirect============
安装好后，先进入站点管理
1　创建域及工程
2　添加用户
3　编辑licenses及本服务器
4　编辑数据库
－－TD
1　选择新建的工程进行定制(列表，用户，组，版本等)
2　在require中增加需求
3　把需求转化为plan
4 在testlab中由计划新建测试具体用例与执行

5　发现bug，在defect中提交bug
（每一部分都可以相对独立地使用）

======loadrunner
1　制定负载测试计划
(分析应用程序， 确定测试目标，计划怎样执行LoadRunner）
2　开发测试脚本
（录制基本的用户脚本，完善测试脚本）
3　创建运行场景
（选择场景类型为Manual Scenario，选择场景类型，理解各种类型，场景的类型转化）
4　运行测试
5　监视场景
（MEMORY 相关，PROCESSOR相关，网络吞量以及带宽，磁盘相关，WEB应用程序 ，IIS5.0，SQL SERVER，NETWORK DELAY等)
6　分析测试结果
(分析实时监视图表,分析事务的响应时间,分解页面,确定WEBSERVER的问题,其他有用的功能)

测试人员常面临的十大挑战和应对策略

1. 测试人员被认为低人一等
2. 测试时间永远不够
3. 缺乏简单易用的测试辅助工具
4. 缺乏具体通用的测试技术
5. 很难清楚了解用户需求和期望
6. 缺乏可明确衡量测试质量达标的度量
7. 很难确定一个测试实例是否执行完毕
8. 很难找时间作自动化测试
9. 测试所需文档经常不全
10. 很多任务在身，很难保质保量

不了解软件测试做什么和它包括什么。
开发软件的公司没有标准化的开发和管理程序
没有想到要开发高水平的软件，须有高水平的测试人员

造成测试人员心理负担，影响工作热情
造成测试人员短缺和人员流失
直接影响产品质量

树立信心!大趋势：软件测试工作已越来越多地得到重视
理解原因，端正心态，正确对待
注重技术水平提高，让实践证明我们的价值
公司里建立良好的工作关系
勇于提出建设性的意见

测试工作总是不能按时完成
要测试的总是比有时间测试的工作量多得多
测试人员很难决定最佳有效测试范围
没有时间按部就班发挥测试最好水平

任务繁重
过于紧凑的时间表
压力大的工作环境
测试和开发规程管理不当

疲劳过度、精神负担
仓促交付工作，质量差
开发项目编码进度延误

个人：自我调节为主，请求帮助为辅
随时分析自己的测试任务，分清优先顺序
事先作多种准备(几套方案、不同测试范围)
风险分析和管理
及时沟通.提早向上级反映
提出建设性改进措施

没任何选择
知道测试辅助工具的重要性，但没到位
不知道所需辅助工具应有何种功能

外部购买的太贵
外部购买的多数不直接适用
公司内部没有技术资源开发
公司内部没有时间开发
技术上不直接支持

只能依赖手动测试
容易疲劳、精神负担
仓促交付工作，质量差
开发项目编码进度延误

在产品设计阶段，就应考虑到测试所需的辅助工具支持
研究最佳可用辅助工具，效益分析
分析产品特点，确定辅助工具以应有的功能
自己设计和研发
微软实践：
1.设专人开发、维护
2.不断改进自己开发的自动化测试辅助工具
3.各产品团队鼓励自己开发测试辅助工具
4.奖励和推广发明创造

1.黑箱、白箱、灰箱测试
2.安全性测试
3.性能测试
4.自动化测试

软件产品的多样性
软件总是有缺陷
没有可适用于所有软件的测试方法
测试技术没有固定的规则
测试是一项连续不断进行的实践

影响测试质量和效率
增加测试难度
需要时间尝试和确定测试方法

办公室和商业用软件(Office and Business Applications)
游戏类软件（Games）
数据库软件（Database）
互联网/网站用软件（Internet/websites）
操作系统软件（Operation system）
多媒体和动画软件（Multimedia & Animation ）
图像处理和文字出版编辑软件（Graphics and Publishing）
语音识别（Speech）
手写体识别以及拼音输入法（Handwriting, OCR and User Input Editor：IME）

1.软件本身功能的复杂性（Software complexity ）
2.源代码编译过程的系统错误（Compiling and integration error ）
3.编码时的人为程序错误（Coding/programming errors ）
4.设计规范文档本身的问题（Poorly documented spec and design ）
5.人为的的信息交流失误（Poor communication among testers, PM and programmers）
6.过于紧凑的时间表和压力大的工作环境（Tight schedule and high pressure working environment）
7.改变设计要求（Changed design requirement ）
8.在软件开发辅助工具中的缺陷（Flaws in the software development tools ）

研究和比较可用技术
提高灵活使用现有技术的能力
学习、应用和推广最佳实践
自我改进、团队互助
经常交流、研讨适合自己产品的最佳测试技术
Explosion 1: .ò..óD....·￠.1oí....￡.

希望做到想用户所想，但做不到
希望产品发行后用户满意度高，但不知怎样才能做到

没发行的新功能设计保密
缺少和用户直接接触的时间和机会
缺乏用户使用研究（Usability study）专家

有时对用户期望行为判断错误
遗漏重要用户使用场景测试
影响用户满意度

用户访问
市场调查
积极参加用户试用产品研究（usability
study）
研究用户发现的缺陷(OFFBUG)
收集用户文档
帮助产品售后服务支持
访问用户答疑网站

什么条件下可认为测试的产品和功能达到质量标准？
多是经验积累，并非科学可靠
很多数量化的度量并非全面和准确
比如：
缺陷数量变化趋势、自动化脚本代码覆盖率
测试案例100%通过也不意味着测试完毕
测试脚本运行100%通过也不等于该功能测试完毕

不定性：产品质量涉及很多不定因素，很难准确度量
难定量化性：测试功能的质量本身就难定量化
复杂性：产品本身太多功能有互动作用

缺少质量管理和决策的依据
已有的度量，如分析或使用不当，会导致错误结论和判断
测试人员必须靠经验和理解判断何时何条件下认为测试完成

找出可用质量度量，对比分析
研究适用于自己产品质量的度量
明确使用数量化度量时的注意事项
数量化度量和经验判断并用
‘Good enough’
注意：测试完成与否有很大程度上的经验判断因素，所以单
一依赖定量化的度量是不正确的
建议：参考另一讲座：“软件产品质量度量”

理解内容，但测试的深度和广度相差太多，很难确定测试范围和所需时间
举例：验证不同地区语言设定条件下，Microsoft Excel的日期函数=TODAY()随之变化
有些包括很多子案例
注意：
写出的测试案例覆盖的测试可能只是应该测试范围的一小部分！

测试案例格式不同
内容覆盖的测试范围差异很大
有些太笼统
有些包括很多子案例
测试人员理解能力不同
时间不允许测试很细

很难估计所需测试时间和所需资源
对执行完测试案例的解释可能造成误解
不同测试人员所需时间和测试范围相差甚远

事先明确执行测试案例的目的和可用时间
对外包测试项目更是要了解客户期望
原则：对产品对用户负责！
沟通！不清楚就问
充分发挥测试水平：即最大可能全面地测试
实现测试的自动化

功能稳定程度不够
自动化辅助工具没能到位
自动化辅助工具需很长时间安装和调试
手动测试都来不及
编写自动化脚本太花时间
没有认识到实现自动化测试的必要性和重要性

没有自动化脚本持续运行，很难保证已测过的功
能保持正常工作，因此很难保证总体测试质量和
产品的稳定性

原则：一定要想办法实现自动化测试！越多越好！
明确自动化测试的好处和重要性
提出你的要求！
提早计划
借用现有资源
合并有关联的测试
多选择多问
形成日常测试任务
每周一两天

缺少功能设计文档
功能设计文档不够详细或有遗漏部分
缺少测试计划
缺少测试规范和案例
现有测试文档不够详细或有遗漏部分

没有时间写详细的文档
接外包测试项目时就没有
测试的是旧功能(legacy features)

没有参照可循、等于没有标准
依赖测试人员专业水平和对产品的理解
很难判断和估计测试范围、所需时间
很难保证测试质量
对测试人员造成更大的压力

事先设立有关开发规程使测试所需文档按时到位
和项目管理、开发人员等有关人员沟通，使他们了解开发和测试所需文档的重要性
想方设法收集有关功能设计信息，存档
管理部门计划设立文档所需资源，并监督执行
测试人员尽最大努力学习和理解所测功能，列出测试计划/规范，邀请有关人员评审
测试人员事先与测试领导沟通潜在的测试质量风险

每个测试人员同时负责几个甚至几十个功能测试
每项测试都要花很多时间
每项测试都应该有测试的自动化覆盖
有时若干测试任务要同时进行

测试人手不够
测试管理考虑不周
测试计划不当
测试人员经验和技术水平欠缺

管理混乱
测试质量差
没测完就匆忙交付
耽误交付日期
测试人员精神心理压力大

测试管理负责人应事先考虑优化分配功能
有明确的责任范围，全盘考虑、权衡
测试的自动化
测试任务清单，计划、记录、追踪进度。（演示roadmap）
按照里程碑或其他产品进度考虑，分清优先次序
根据功能本身稳定状况确定优先次序
尽量考虑结合几项任务一起进行
及时汇报、沟通情况
保证重点

软件产业蒸蒸日上
亲身参加我国赶超世界先进水平的竞争
就业机会多
锻炼提高个人素质
挑战性的环境更锻炼人
需要研发适合我国实际状况的最佳测试技术、方法、管理
武装起来，迎接挑战！

我们的使命和重担
我们测试人员应怎样武装自己，迎接新时代软件
测试的需求和挑战？？
使命：为我国软件测试领域赶超世界先进水平贡
献我们的最大力量！
从现在做起：培养优秀测试技术和管理人才
行业
公司/企业
部门/团队
自己！

测量性能

要正确地调整性能，必须准确完整地记录每次测试的结果并进行维护。记录应包括：

• 精确的系统配置，尤其是与前几次测试的不同之处
• 原始数据和性能监视工具计算的结果

这些记录不仅指示应用程序是否达到性能目标，而且有助于识别未来性能问题的潜在原因。

在每遍测试中，运行一系列完全相同的性能测试；否则，无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。

其他表面上是良性的因素影响性能测试的结果，如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同，长时间运行的应用程序由于内存碎片这样的因素，其性能可能与刚启动的应用程序不同。

定义性能测试

性能测试期间，测量和记录性能目标中指定的度量标准值。达到全部性能度量标准（如思考时间、事务混合等）很重要。在这些约束下，测试应尽可能实际。例如，对应用程序进行测试，确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端，每个线程表示一个客户端。如果应用程序访问数据库，则数据库应包含实际数目的记录，并且测试应使用数据项的随机（但有效）值。如果测试数据库太小，数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况，则结果也可能不符合实际情况。例如，在主键上按字母顺序创建新数据是不太可能的。

通常，测试装置必须接受用户指定的输入参数，如事务混合、思考时间、客户端数目等。然而，测试装置本身可以规定创建实际的随机数据的规则。

创建了驱动应用程序的测试装置后，应该将所有运行测试的不变条件记入文档。最起码，这些条件应包括运行测试装置所需的输入参数。另外，应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置，因为这样设置更接近生产环境。

确定基准性能

确定了性能目标并制定了性能测试后，运行一次测试以建立基准。验证环境与生产环境越相似，应用程序部署后的性能令人满意的可能性就越大。因此，一开始有一个符合实际情况的验证环境很重要。

幸运的话，基准性能将符合性能目标，并且应用程序不需要任何调整。但更可能的情况是，基准性能不令人满意。然而，记录初始测试环境和基准结果可以为调整工作提供坚实的基础。

压力测试

压力测试是性能测试的一种专门形式，它与其他工程领域的破坏性测试相似。压力测试的目的是使应用程序产生故障，通过增加处理负载使其超过性能的降低，直到由于资源饱和或发生错误而使应用程序开始出问题。压力测试有助于揭示细微的错误，这些错误本来要到部署应用程序时才会被发现。由于此类错误通常是因设计缺陷所致，压力测试应该早在开发阶段便在应用程序的每个区域上开始进行。在其源头修复这些细微的错误，而不是忽视这些错误，直到它们可能在应用程序中的其他位置表现出症状时才修复它们。

解决性能问题

通常可将性能问题归结于不止一个因素。因此，查找性能恶化的解决方案与进行科学实验极为相似。科学实验传统上遵循一个分六步进行的过程，包括观察、初步假设、预测、测试、控制和结论。结论由该过程积累的最佳证据集合所支持的假设组成。可以遵循同样的过程来解决性能问题。

当观察到 ASP 应用程序的性能比期望的低时，您假定 ASPProcessorThreadMax 元数据库属性设置得太低。当“ASP 排队请求”性能计数器上下移动，并且处理器的运行效率低于 50% 时，可能会发生这种情况。您预测增加 ASPProcessorThreadMax 元数据库属性的数值可以提高性能。

活动线程设置现在已经变成控件。一次仅进行一个设置更改，直到观察到满意的性能改变。如果在几次调整 ASPProcessorThreadMax 元数据库属性之后获得了更令人满意的性能，则结论是某个属性设置与所有当前变量（所需内存的总量、正在运行的应用程序数、已升级的软件等）组合，可提供最佳服务器性能。变量中的任何更改就会形成进一步的实验。

CMMI5在小型项目中的成本过高，根据自己对CMMI5的实施体会与在实际项目中的应用，在项目实施的过程中精简了CMMI5的实施流程和部分文档，这个精简的流程在项目实施的过程中既可以确保流程规范与质量信赖又可以节约项目成本。以下跟大家分享一下CMMI5在项目中的精简应用：


　　 一、需求与规范的管理

　　1、 由测试负责人（或专门的需求分析负责人）统一接收来自移动总的行业网关相关规范和新需求，测试负责人浏览规范获知大意后回复邮件，将规范和新需求转发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

　　2、 测试负责人（或专门的需求分析负责人）、项目经理仔细阅读规范与需求后，对规范和新需求进行研究，并就难点和疑点进行讨论，整理出重点内容，并将重点内容发给开发经理、项目经理、相关的开发人员和测试人员，同时commit到CVS；

　　3、 开发经理、项目经理、测试负责人、需求分析负责人、相关的开发人员与测试人员开会对规范、需求和重点内容进行讨论，确定需求的具体含义以及最终实现的需求和功能点；

　　4、 项目经理根据规范、需求和开会讨论结果编写《需求规格说明书》与《功能列表》，测试负责人（或专门的需求分析负责人）对文档进行检查并修改完善，然后commit到CVS；

　　5、 测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS。

　　 二、项目计划与测试计划

　　1、 由开发经理组织项目计划讨论会，在讨论会上各开发负责人对自己所负责的模块所需要的工作量进行评估，根据工作量和工程需求初步确定总体开发计划、测试计划和发布时间；

　　2、项目经理根据估算工作量和工程需求编写项目计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的项目计划；

　　3、测试负责人根据项目计划与发布时间编写测试计划，使用CMMI5总体测试计划模板并对其进行适当的裁剪和补充，编写适合本项目的测试计划；

　　4、项目计划与测试计划编写完成后发送给开发经理、项目经理、相关的开发人员和测试人员，开发经理、项目经理、相关的开发人员和测试人员阅读项目计划、测试计划后将建议和意见以邮件的形式反馈给项目经理与测试负责人，项目经理与测试负责人收集大家的邮件分别对项目计划与测试计划进行修改完善，同时回复邮件说明项目计划与测试计划修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的项目计划、测试计划commit到CVS；

　　5、测试负责人（或专门的PPQA）确认所有相关文档经过了评审并都已经commit到CVS
   
　　三、开发设计与评审

　　1、 项目经理构思系统设计，项目组开发成员一起讨论系统的设计，对设计形成较为清晰的思路；

　　2、 项目经理负责编写概要设计文档，与开发经理、开发团队成员与测试负责人一起讨论概要设计；

　　3、 概要设计完成后，项目经理编写详细设计文档、数据库设计文档和编码规范，各模块负责人负责编写所负责的模块进行详细设计；

　　4、 设计文档编写完成后，发邮件通知开发经理、项目经理、测试负责人、相关开发人员和测试人员；

　　5、 开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的概要设计文档、详细设计文档进行审查，将建议和意见以邮件的形式反馈给模块负责人；

　　6、 模块负责人收集邮件中的修改建议并对设计文档进行修改，同时回复邮件说明详细设计修改情况，修改后的详细设计commit到CVS；

　　7、 如果对设计存在争议或出现明显不合理的设计，召开一个小型会议对异议进行讨论，有效解决设计所出现的分歧；

　　8、 测试负责人（或专门的PPQA）对开发最终修改的详细设计计划进行检查，并确认所有文档都已经commit到CVS。

　　注：在大型的项目中，必须先完成概要设计后再完成详细设计，在小项目或需求中可做适当剪裁概要设计与详细设计合在一起完成。

　　四、测试方案与评审

　　1、在项目的设计阶段，测试负责人根据规范文档、功能列表和概要文档编写总体测试方案与性能测试方案；

　　2、测试方案编写完成后，发邮件通知开发经理、项目经理、相关开发人员和测试人员；

　　3、开发经理、项目经理、测试负责人、相关开发人员和测试人员对所提交的测试方案进行审查，开发经理和项目经理对测试方案进行总体性的审查，而各模块负责人则负责相关模块或功能的测试方案的审查，将建议和意见以邮件的形式反馈给测试负责人；

　　4、测试负责人收集邮件中的修改建议并对测试方案进行修改，同时回复邮件说明测试方案修改情况，修改后的测试方案commit到CVS；

　　5、测试负责人（或专门的PPQA）对最终修改的测试方案进行检查，并确认所有文档都已经commit到CVS。

　　五、编码实现与单元测试

　　1、在产品详细设计完成后，开发工程师依据设计进行编码工作；

　　2、编码完成后，开发工程师编写单元测试案例并进行单元测试，单元测试完成后提交单元测试报告；

　　3、项目经理根据项目实际情况对开发工程师编写的代码组织Code Review，记录相关问题；
　　4、产品模块单元测试完成后，开发之间进行产品联调测试，并修改所发现问题以及提交联调测试报告；

　　5、产品初步完成后，在提交测试前进行一次产品演示，参加人员包括开发经理、项目经理、测试负责人、开发工程师、测试工程师、售前工程师与售后工程师，在演示的过程中对产品提出改进建议；

　　6、各模块负责人对Code Review以及产品展示所发现的问题进行修改，相关的代码与文档commit到CVS；

　　7、项目经理对编码完成后的系统进行确认，确保提交测试的系统是可运行的，测试负责人（或专门的PPQA）确认所有文档和代码都已经commit到CVS。

　　六、测试设计与评审

　　1、 在项目编码阶段，测试方案编写完成后，测试负责人或相关测试人员根据测试方案、规范文档、功能列表和详细设计进行测试用例设计；

　　2、 测试案例设计的类型包括功能测试，边界测试，异常测试，性能测试，压力测试等，在用例设计中，除了功能测试案例外，应尽量考虑边界、异常、性能的情况，以便发现更多的隐藏问题；

　　3、 在编写测试案例的过程中，对于存在疑问的地方或测试重点，主动与开发负责人或项目经理沟通讨论，一方面有助于设计完善的测试案例，另一方面也有助于开发进一步清晰编码思路；

　　4、 测试用例编写完成后，发邮件给开发经理、项目经理、相关开发人员和测试人员；

　　5、 开发经理、项目经理、相关开发人员和测试人员对所提交的测试案例进行审查，开发经理与项目经理对测试案例进行总体性的检查，各模块负责人则负责检查自己所负责的测试案例，将建议和意见以邮件的形式反馈给测试负责人；

　　6、 测试负责人收集大家的邮件对测试案例进行修改完善，同时回复邮件说明修改情况，如果存在争议则召开一个小型会议对异议进行讨论，修改后的测试案例commit到CVS；

　　7、 测试用例编写完成之后需要不断完善，软件产品新增功能或更新需求后，测试案例必须配套修改更新；在测试过程中发现设计测试案例时考虑不周，需要对测试案例进行修改完善；在软件交付使用后客户反馈的软件缺陷，而缺陷又是因测试案例存在漏洞造成，也需要对测试案例进行完善；

　　8、 测试负责人（或专门的PPQA）对最终修改测试案例进行检查，并确认所有文档都已经commit到CVS。
　七、测试实施

　　1、代码提交前一天准备相关的测试环境（如服务器或数据库等），代码提交后测试人员向Build Master申请打包，并搭建正式测试环境，为了不做到测试以及确保产品可以跨平台，每个测试人员各自搭建一个测试环境，每个平台至少要有一个以上的测试人员负责；
　　2、测试环境搭建好后进行烟雾测试，如果烟雾测试通过则继续详细的功能测试，否则中断测试并返回给开发；

　　3、测试人员按照预定的测试计划和测试方案逐项对测试案例进行测试，在测试过程中发现的任何与预期目标不符的现象和问题都必须详细记录下来，填写测试记录，在必要的时候协助开发追踪与修改所发现的问题；如果在测试的过程中发现重大的bug或因为某些bug导致测试不能继续，测试中断并返回给开发；

　　4、每个测试阶段测试结束后，由测试负责人总结测试情况，对测试结果进行分析和下一阶段测试测试计划与可能引进的bug数量进行预测，并提交“测试阶段分析报告”，并发送给开发经理、项目经理、相关测试人员和开发人员；

　　5、开发经理对测试阶段分析报告中存在的问题采取恰当的措施和调整相关资源，确保下一阶段的开发与测试计划顺利进行；

　　6、开发对bug进行修改；

　　7、开发对bug修改后测试人员进行回归测试，经过修改的软件可能仍然包含着错误，甚至引入了新的错误，因此，对于修改以后的程序和文档，按照修改的方法和影响的范围，必须重新进行有关的测试；

　　8、产品的功能比较完善后，进行产品的性能压力测试，并根据测试结果进行性能调优；

　　9、确认测试，在软件发布前，对产品进行确认测试；

　　10、当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，确认发布包和文档完整后进行产品发布。

　　八、产品发布



　　当测试产品达到测试计划所制定的产品质量目标和测试质量目标，整理产品发布包和编写相关文档，在发布前对照功能列表进行一次全面的确认测试，确认发布包和文档完整后进行产品发布。对于新产品来说，必要的文档必须包括：（1） 产品安装操作手册;（2） 产品白皮书;（3） 产品管理维护手册;（4） 用户操作手册;（5） 总体测试报告（6）性能测试报告。

　　九、版本控制

　　在测试过程中，软件的打包统一由Build Master完成。新版本软件发布之后，马上对代码进行质量控制：（1） Build Master给新版本的源代码打一个cvs tag，方便代码回滚check out。比如，发布版本为IAGW1.0.0，则给该软件源代码也打一个与发布版本相同名字的tag IAGW1.0.0。这样做的一个好处是，在目前的软件的基础上做了修改并发布新的版本后，如果需要check out某个版本的源代码，则可以通过这个版本的tag来check out，代码的修改可以在该版本上进行。（2） Build Master对新发布的软件源代码进行cvs lock，不允许开发人员在软件发布之后commit源代码，直到有新版本需求修改再给开发人员开放commit权限。这样做的好处是避免开发人员随意修改和commit源代码，确保源代码服务器上的源代码版本与当前最新的发布版本一致。
　　十、自动测试

　　产品稳定后，进行自动测试工具开发，对于稳定的功能使用自动测试工具进行测试，新增的功能使用手工测试，使用自动测试+手工测试的模式，可以大大提供测试效率。

　　十一、小结：应用推广思路与体会

　　整体思路是：首先对项目进行需求分析，有效的需求分析方法是需求分析人员、项目经理、开发经理与测试负责人分别阅读规范与原始需求，特别是需求分析负责人与项目经理，需要对需求进行深入的分析研究，然后开会讨论，消除对需求的误解与遗漏，讨论结束后编写功能列表说明文档与需求规格说明书并评审；对于规范中不明确的问题集中后由测试负责人（或需求分析负责人）直接与移动总规范负责人直接交流，确保不会因为规范的理解不正确导致项目实现与需求不一致。需求分析完成后，编写项目计划书与测试计划书；项目计划、测试计划编写前先开会讨论，由模块负责人估算工作量，能确定的问题和时间安排都在讨论中确定下来，然后根据工作量和工程需求制定项目计划和测试计划。开发在编码前需要进行概要设计和详细设计，开发工程师在编码前对系统的总体设计架构、各自所负责的模块有一个清晰的设计思路，经评审后确认模块的设计是否合理；开发在编码完成后在提交测试前必须进行单元测试与联调测试，提交给测试的软件是一个可运行的产品。测试工作中，在项目设计或编码阶段，测试负责人对项目进行测试设计，指导测试实施有依可循，在编写案例的过程中会遇到很多与流程和细节处理相关的问题，与开发一起讨论也有助于提前发现问题与完善代码；在测试实施阶段，测试人员记录所发现的问题，并协助开发及时解决，在测试过程中所遇到的问题，测试负责人进行记录和分析，在每个阶段完成后提交经分析后的测试阶段报告，在软件测试阶段报告中总结分析了测试过程中所发现的问题并对这些问题提出解决建议，在后续的开发与测试中进行改进与调整，确保项目能够按时保质发布。为了节约资源，计划或设计都是以邮件的形式进行评审；对于存在严整分歧的问题，组织一个小型会议进行讨论有效解决问题，小型讨论会是解决问题的一种有效途径，任何问题都可以通过face-to-face的交流达到共识。软件的管理和版本管理则由Build Master负责，确保软件得到良好的控制。在整个项目实施的过程中，需要有一个PPQA对流程进行检查与监督。
　　这个精简的实施流程，不但确保了软件的质量，而且实施成本较低，在团队实施中非常容易推广。 在整个流程中，测试负责人除了负责测试相关任务以外，同时承担了需求管理、流程跟踪、协调沟通等工作（当然，也可由项目经理或开发经理等担任），在其中由测试推动项目开发与实现，在开发成员之间、开发与测试之间搭了一座沟通的桥梁，这样的一个协调与推动促进了项目的顺利完成，适合于五至二十的小型团队。不过这种测试与开发的模式，对测试负责人的要求很高，不但要求测试负责人具有很强的责任心与沟通协调能力，而且还需要具有很高的业务分析能力和CMMI5实施经验。

有关某个命令的详细信息，请键入 HELP 命令名
ASSOC 显示或修改文件扩展名关联。
AT 计划在计算机上运行的命令和程序。
ATTRIB 显示或更改文件属性。
BREAK 设置或清除扩展式 CTRL+C 检查。
CACLS 显示或修改文件的访问控制列表(ACLs)。
CALL 从另一个批处理程序调用这一个。
CD 显示当前目录的名称或将其更改。
CHCP 显示或设置活动代码页数。
CHDIR 显示当前目录的名称或将其更改。
CHKDSK 检查磁盘并显示状态报告。
CHKNTFS 显示或修改启动时间磁盘检查。
CLS 清除屏幕。
CMD 打开另一个 Windows 命令解释程序窗口。
COLOR 设置默认控制台前景和背景颜色。
COMP 比较两个或两套文件的内容。
COMPACT 显示或更改 NTFS 分区上文件的压缩。
CONVERT 将 FAT 卷转换成 NTFS。您不能转换
当前驱动器。
COPY 将至少一个文件复制到另一个位置。
DATE 显示或设置日期。
DEL 删除至少一个文件。
DIR 显示一个目录中的文件和子目录。
DISKCOMP 比较两个软盘的内容。
DISKCOPY 将一个软盘的内容复制到另一个软盘。
DOSKEY 编辑命令行、调用 Windows 命令并创建宏。
ECHO 显示消息，或将命令回显打开或关上。
ENDLOCAL 结束批文件中环境更改的本地化。
ERASE 删除至少一个文件。
EXIT 退出 CMD.EXE 程序(命令解释程序)。
FC 比较两个或两套文件，并显示
不同处。
FIND 在文件中搜索文字字符串。
FINDSTR 在文件中搜索字符串。
FOR 为一套文件中的每个文件运行一个指定的命令。
FORMAT 格式化磁盘，以便跟 Windows 使用。
FTYPE 显示或修改用于文件扩展名关联的文件类型。
GOTO 将 Windows 命令解释程序指向批处理程序
中某个标明的行。
GRAFTABL 启用 Windows 来以图像模式显示
扩展字符集。
HELP 提供 Windows 命令的帮助信息。
IF 执行批处理程序中的条件性处理。
LABEL 创建、更改或删除磁盘的卷标。
MD 创建目录。
MKDIR 创建目录。
MODE 配置系统设备。
MORE 一次显示一个结果屏幕。
MOVE 将文件从一个目录移到另一个目录。
PATH 显示或设置可执行文件的搜索路径。
PAUSE 暂停批文件的处理并显示消息。
POPD 还原 PUSHD 保存的当前目录的上一个值。
PRINT 打印文本文件。
PROMPT 更改 Windows 命令提示符。
PUSHD 保存当前目录，然后对其进行更改。
RD 删除目录。
RECOVER 从有问题的磁盘恢复可读信息。
REM 记录批文件或 CONFIG.SYS 中的注释。
REN 重命名文件。
RENAME 重命名文件。
REPLACE 替换文件。
RMDIR 删除目录。
SET 显示、设置或删除 Windows 环境变量。
SETLOCAL 开始批文件中环境更改的本地化。
SHIFT 更换批文件中可替换参数的位置。
SORT 对输入进行分类。
START 启动另一个窗口来运行指定的程序或命令。
SUBST 将路径跟一个驱动器号关联。
TIME 显示或设置系统时间。
TITLE 设置 CMD.EXE 会话的窗口标题。
TREE 以图形模式显示驱动器或路径的目录结构。
TYPE 显示文本文件的内容。
VER 显示 Windows 版本。
VERIFY 告诉 Windows 是否验证文件是否已正确
写入磁盘。
VOL 显示磁盘卷标和序列号。
XCOPY 复制文件和目录树。


appwiz.cpl------------添加删除程序

control userpasswords2--------用户帐户设置

cleanmgr-------垃圾整理

CMD--------------命令提示符可以当作是 Windows 的一个附件，Ping，Convert 这些不能在图形环境下 使用的功能要借助它来完成。

cmd------jview察看Java虚拟机版本。


command.com------调用的则是系统内置的 NTVDM，一个 DOS虚拟机。它完全是一个类似 Virtual PC 的 虚拟环境，和系统本身联系不大。当我们在命令提示符下运行 DOS 程序时，实际上也 是自动转移到 NTVDM虚拟机下，和 CMD 本身没什么关系。


calc-----------启动计算器

chkdsk.exe-----Chkdsk磁盘检查

compmgmt.msc---计算机管理

conf-----------启动 netmeeting

control userpasswords2-----User Account 权限设置

devmgmt.msc--- 设备管理器

diskmgmt.msc---磁盘管理实用程序

dfrg.msc-------磁盘碎片整理程序

drwtsn32------ 系统医生

dvdplay--------启动Media Player

dxdiag-----------DirectX Diagnostic Tool

gpedit.msc-------组策略编辑器

gpupdate /target:computer /force 强制刷新组策略

eventvwr.exe-----事件查看器

explorer-------打开资源管理器

logoff---------注销命令

lusrmgr.msc----本机用户和组

msinfo32---------系统信息

msconfig---------系统配置实用程序

net start (servicename)----启动该服务

net stop (servicename)-----停止该服务

notepad--------打开记事本

nusrmgr.cpl-------同control userpasswords，打开用户帐户控制面板

Nslookup-------IP地址侦测器

oobe/msoobe /a----检查XP是否激活

perfmon.msc----计算机性能监测程序

progman--------程序管理器

regedit----------注册表编辑器

regedt32-------注册表编辑器

regsvr32 /u *.dll----停止dll文件运行

route print------查看路由表

rononce -p ----15秒关机

rsop.msc-------组策略结果集

rundll32.exe rundll32.exe %Systemroot%System32shimgvw.dll,ImageView_Fullscreen----启动一个空白的Windows 图片和传真查看器

secpol.msc--------本地安全策略

services.msc---本地服务设置

sfc /scannow-----启动系统文件检查器

sndrec32-------录音机

taskmgr-----任务管理器（适用于2000／xp／2003）

tsshutdn-------60秒倒计时关机命令

winchat--------XP自带局域网聊天

winmsd---------系统信息

winver-----显示About Windows 窗口

wupdmgr-----------Windows Update

     可以说，谁掌握了功能测试和性能测试的精髓，谁就能在测试外包市场中占据技术制高点。本文正是为这类软件服务型企业出谋划策、提供测试技术决策参考。
　　 虽然功能测试是绝大多数软件都无法回避的，但多数开发企业不谙其中滋味，所以，测试外包市场才会如此繁荣而且规模日益壮大。目前，功能测试已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段，正朝着自动化和智能化方向发展。自动化是指各类测试工具已经得到日益广泛的应用； 智能化是指测试人员从脚本编制、运行、调试到结果分析乃至测试方案改进，都需要有深入的了解。

　　 而性能测试的重要性是随着网络应用的发展而发展的，由于网络环境、数据库环境、应用服务器环境、系统平台和技术等的复杂性和多样性，软件性能非常难于控制。虽然，改善系统性能不是单单依靠性能测试就能完成的，但性能测试至今仍是控制性能的非常有效的手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

　　 功能测试工具的选择

　　 那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

　　 目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner.

　　 WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

　　 WinRunner的特点在于： 与传统的手工测试相比，它能快速、批量地完成功能点测试； 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差； 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成； 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用； 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

　　 WinRunner的工作流程大致可以分为以下六个步骤：

　　 1.识别应用程序的GUI

　　 在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式： Global GUI Map File和GUI Map File per Test.其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。

　　 2.建立测试脚本

　　 在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式： Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog.在录制过程中这两种模式可以通过F2键相互切换。

　　 只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

    3.对测试脚本除错（debug）

　　 在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。

　　 4.在新版应用程序执行测试脚本

　　 当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

　　 5.分析测试结果

　　 分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。

　　 6.回报缺陷（defect）

　　 在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

　　 性能测试的三大步骤

　　 第一步 准备和组织是性能测试过程的第一步，在这个阶段，需要明确性能测试的目标和需求，并组织起合适的人员，制订性能测试计划。

　　 一般来说，性能测试的应用领域分为能力验证、能力规划、性能调优和缺陷修复四个方面。其中能力验证表明测试的目的是验证系统能力是否达到预期的性能标准； 能力规划是要考察系统的可扩展性； 性能调优则是为了找到系统的性能瓶颈，为性能调优提供依据； 缺陷修复是为了找出系统中存在的并发等方面的缺陷。

　　 明确目标也就是要把性能测试的目的归到相应的应用领域，而确定需求则是要更详细地确定性能测试的基准。对产品的性能测试需求的来源是软件需求、设计文档或是用户备忘录等设计和需求相关的文档。当然，并非所有的性能测试需求都在这些文档中以明确的方式标识出来，此时就需要根据不十分明确的文档描述进行进一步的细化。我们的经验是在文档评审时高度关注所有与性能相关的描述，例如“要求操作响应时间小于……”、“要求……能够快速……”、“要求……能够支持……用户访问”、“要求……能快速稳定运行”等，然后进行进一步的细化，从而作为测试的依据。

　　 性能测试涉及的设备、环境、技术、工具较多，性能测试人员的组织也必须兼顾这些方面。一个性能测试组最好包括系统工程师（负责测试环境搭建、服务器和应用服务器的配置）、网络工程师（负责网络环境的维护和验证）、性能分析工程师（负责测试计划的拟定，对性能测试结果进行分析，给出性能测试报告）、自动化工程师（负责测试脚本的编写和测试工具实施）、数据库工程师（负责对数据库层进行性能问题定位）。在条件允许的情况下，还可以包括开发工程师和客户代表，辅助对性能测试结果进行分析和确认。

　　 性能测试计划是用来指导性能测试过程的主要文档，在测试计划中除了要写明本次测试的测试目标、测试需求外，还需要在测试计划中给出明确的测试退出条件和测试的时间和资源计划。

　　 第二步 第二步测试设计，也是性能测试的主要内容。测试设计一般基于测试场景进行，一个测试场景就是一个用户的实际使用系统的剖面。

　　 在性能测试过程中，明确每个场景的参与者人数、比例和具体行为是非常重要的，这些都是构成性能测试脚本的基础。根据经验，可以从应用服务器的日志中分析用户行为。例如，对于一个OA系统，我们从日志中分析出在上午9：00～9：30时段内有200个查看邮件页面的page view，且查看时间基本集中在前10分钟； 而在9：00～9：30时间段内对BUG显示页面的查看量是300个page view，对页面的访问基本平均分配在整个时间段，则我们可以建立两个脚本，前一个脚本模拟查看邮件操作（脚本1），后一个脚本模拟查看BUG操作（脚本2），考虑运行15分钟的测试场景，则只需在前5分钟运行脚本1，在整个过程中运行脚本2，通过调整think time使得page view达到实际的数值即可。

　　 当然，并不是每个不同的用户应用剖面都需要作为测试场景来设计，在多数情况下，可以通过对测试场景出现的几率、重要性、风险等进行分析，从而最终确定需要设计的测试场景。明确了场景之后，根据性能测试应用领域的不同，可以采用不同的性能测试方法来达到性能测试的目标。另外需要提醒的是，性能测试设计还应该包括测试环境、测试数据等的设计，因为影响系统性能的因素很多，保持测试过程中环境和数据的可控性是非常重要的。
 
　　 第三步 第三步性能测试结果分析，是性能测试过程中最困难，也是最重要的步骤。它需要分析人员对测试结果中的各项数据有准确的认识，明确各指标之间的关系。如果各项数据指标间没有明显联系，在多数情况下需要综合考虑各种因素，才能得出最终结论。

　　 根据经验，在性能测试过程中最容易发生的问题是数据库访问层问题、应用服务器配置问题以及网络问题。因此建议一般按照“从简至繁”的原则，先排除网络问题，其次对应用服务器配置进行分析，然后在数据库访问层进行性能分析，重点是索引、数据库Cache、死锁等问题的分析。在确认所有这些因素都不是性能瓶颈的情况下，才对代码进行分析和检查，找出导致性能问题的因素。

　　 只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

虽然我们都认为，有效的测试计划是指导测试用例设计、测试执行的指导性文件，是成功测试的前提和必要条件，测试用例设计是测试工作的核心，测试用例的成功设计已经完成了一半的测试任务，但是测试的执行是基础，是测试计划和测试用例实现的基础，严格的测试执行使测试工作不会半途而废。而且，测试执行的管理相对复杂些，在整个测试执行阶段中，我们需要面对一系列问题，如：如何确保测试环境满足测试用例所描述的要求？

　　- 如何保证每个测试人员清楚自己的测试任务和要达到的目标？

　　- 如何保证每个测试用例得到百分之百的执行？

　　- 如何保证所报告的软件缺陷正确、描述清楚、没有漏掉信息？

　　- 如何在验证Bug或新功能与回归测试之间寻找平衡？

　　- 如何跟踪Bug处理的进度使严重的Bug及时得到解决？

　　要实现上述目标，得到一个真实、符合要求的执行过程，需要很好地全程跟踪测试过程、过程度量和评审、借助有效的测试管理系统等来实现。主要的方法和措施有：

　　1. 执行前，动员会是必要的，如同打战，要鼓舞士气，更重要阐述策略，回答大家的问题，使测试计划、测试范围和所有测试项目的定义都十分清楚。

　　2.   严格审查测试环境，包括硬件型号、网络拓扑结构、网络协议、防火墙或代理服务器的设置、服务器的设置、应用系统的版本，包括被测系统以前发布的各种版本和不定包、以及相关的或依赖性的产品。

　　3.  将要执行的所有测试用例进行分类，基于测试策略和历史数据的统计分析，包括测试策略和缺陷的关联关系，构造有效的测试套件（Test Suite），然后在此基础上建立要执行的测试任务，这样任务的分解有助于进度和质量的有效控制，减少风险。

　　4.  所有测试用例、测试套件、测试任务和测试执行结果，都通过测试管理系统进行管理，使之测试执行的操作、过程记录在案，具有良好的可跟踪性、控制性和追溯性，容易控制好测试进度和质量。转贴于：中国项目管理资源网

　　5. 要确保每一个测试人员理解测试策略、测试目标，对测试进程进行审查（Audit），确保测试策略得到执行，可以通过一些奖励手段进行引导。测试经理、组长要用于承担风险，使之测试人员有发挥、想象的空间，但同时也要给予适当的压力，提高工作效率和责任心。

　　6. 缺陷的跟踪和管理一般由数据库系统来执行，容易对缺陷进行跟踪、统计分析和趋势预测，并设定一些有效的规则和流程来配合测试执行，如通过系统自动发出邮件给相应的开发人员和测试人员，使得任何缺陷都不会错过，并能得到及时处理。而且事先建立基于缺陷跟踪系统的缺陷报表、缺陷趋势曲线，对各模块、各测试人员、整体项目等进行实时跟踪。

　　7. 进行常规的缺陷审查，如Daily Bg review， bug scrub meeting，包括Bug的严重性、Bug的描述、Bug修正的反应速度等，及时发现问题、纠正问题，使整个测试进程在控制轨道上发展。

　　8. 对每个阶段的测试结果进行分析，保证阶段性的测试任务得到完整的执行并达到预定的目标。

　　9. 良好的沟通，不仅和测试人员保持经常的沟通，还要求和项目组的其他人员保持有效的沟通，如每周例会，可以及时发现测试中问题或不正常的现象。

1. Test early and test often.
尽早测试，经常测试
2. Integrate the application development and testing life cycles. You'll get better results and you won't have to mediate between two armed camps in your IT shop.
整合应用程序开发和软件测试生命周期，你将得到更好的结果，并且不必要在程序开发和软件测试两者之间左右为难。
3. Formalize a testing methodology; you'll test everything the same way and you'll get uniform results.
形成一套完整的测试方法；你将用同样的方法开展测试工作，并且可以得到始终如一的结果
4. Develop a comprehensive test plan; it forms the basis for the testing methodology.
开发一套完整、全面的的测试计划；作为软件测试方法论的基础部分
5. Use both static and dynamic testing.
采用静态测试和动态测试相结合的方法（可以采用静态代码检查工具作静态测试）
6. Define your expected results.
定义测试预期结果（在测试用例中，这是比不可少的项目)
7. Understand the business reason behind the application. You'll write a better application and better testing scrīpts.
理解应用背后的商业动机，找出真正的需求根源，你将写出更好的应用程序和测试脚本。
8. Use multiple levels and types of testing (regression, systems, integration, stress and load).
采用多层面和多类型的软件测试（回归测试、系统测试、集成测试、压力测试和负载测试）
9. Review and inspect the work, it will lower costs.
多工作评审和检视，可以降低成本（检视和评审可以提早发现问题，规避问题，避免造成不必要的损失，因此，可以降低成本）
10. Don't let your programmers check their own work; they'll miss their own errors.
不要让程序员检查自己的工作产品，程序员会忽略自己犯的错误。

一、 概述

在软件生命周期中的任何一个阶段，只要软件发生了改变，就可能给该软件带来问题。软件的改变可能是源于发现了错误并做了修改，也有可能是因为在集成或维护阶段加入了新的模块。当软件中所含错误被发现时，如果错误跟踪与管理系统不够完善，就可能会遗漏对这些错误的修改；而开发者对错误理解的不够透彻，也可能导致所做的修改只修正了错误的外在表现，而没有修复错误本身，从而造成修改失败；修改还有可能产生副作用从而导致软件未被修改的部分产生新的问题，使本来工作正常的功能产生错误。同样，在有新代码加入软件的时候，除了新加入的代码中有可能含有错误外，新代码还有可能对原有的代码带来影响。因此，每当软件发生变化时，我们就必须重新测试现有的功能，以便确定修改是否达到了预期的目的，检查修改是否损害了原有的正常功能。同时，还需要补充新的测试用例来测试新的或被修改了的功能。为了验证修改的正确性及其影响就需要进行回归测试。

回归测试在软件生命周期中扮演着重要的角色，因忽视回归测试而造成严重后果的例子不计其数，导致阿里亚娜5型火箭发射失败的软件缺陷就是由于复用的代码没有经过充分的回归测试造成的。

回归测试作为软件生命周期的一个组成部分，在整个软件测试过程中占有很大的工作量比重，软件开发的各个阶段都会进行多次回归测试。在渐进和快速迭代开发中，新版本的连续发布使回归测试进行的更加频繁，而在极端编程方法中，更是要求每天都进行若干次回归测试。因此，通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。

二、 回归测试策略

对于一个软件开发项目来说，项目的测试组在实施测试的过程中会将所开发的测试用例保存到“测试用例库”中，并对其进行维护和管理。当得到一个软件的基线版本时，用于基线版本测试的所有测试用例就形成了基线测试用例库。在需要进行回归测试的时候，就可以根据所选择的回归测试策略，从基线测试用例库中提取合适的测试用例组成回归测试包，通过运行回归测试包来实现回归测试。保存在基线测试用例库中的测试用例可能是自动测试脚本，也有可能是测试用例的手工实现过程。

回归测试需要时间、经费和人力来计划、实施和管理。为了在给定的预算和进度下，尽可能有效率和有效力地进行回归测试，需要对测试用例库进行维护并依据一定的策略选择相应的回归测试包。

1、测试用例库的维护

为了最大限度地满足客户的需要和适应应用的要求，软件在其生命周期中会频繁地被修改和不断推出新的版本，修改后的或者新版本的软件会添加一些新的功能或者在软件功能上产生某些变化。随着软件的改变，软件的功能和应用接口以及软件的实现发生了演变，测试用例库中的一些测试用例可能会失去针对性和有效性，而另一些测试用例可能会变得过时，还有一些测试用例将完全不能运行。为了保证测试用例库中测试用例的有效性，必须对测试用例库进行维护。同时，被修改的或新增添的软件功能，仅仅靠重新运行以前的测试用例并不足以揭示其中的问题，有必要追加新的测试用例来测试这些新的功能或特征。因此，测试用例库的维护工作还应包括开发新测试用例，这些新的测试用例用来测试软件的新特征或者覆盖现有测试用例无法覆盖的软件功能或特征。

测试用例的维护是一个不间断的过程，通常可以将软件开发的基线作为基准，维护的主要内容包括下述几个方面。

(1)、删除过时的测试用例

因为需求的改变等原因可能会使一个基线测试用例不再适合被测试系统，这些测试用例就会过时。例如，某个变量的界限发生了改变，原来针对边界值的测试就无法完成对新边界测试。所以，在软件的每次修改后都应进行相应的过时测试用例的删除。

(2)、改进不受控制的测试用例

随着软件项目的进展，测试用例库中的用例会不断增加，其中会出现一些对输入或运行状态十分敏感的测试用例。这些测试不容易重复且结果难以控制，会影响回归测试的效率，需要进行改进，使其达到可重复和可控制的要求。

(3)、删除冗余的测试用例

如果存在两个或者更多个测试用例针对一组相同的输入和输出进行测试，那么这些测试用例是冗余的。冗余测试用例的存在降低了回归测试的效率。所以需要定期的整理测试用例库，并将冗余的用例删除掉。

(4)、增添新的测试用例

如果某个程序段、构件或关键的接口在现有的测试中没有被测试，那么应该开发新测试用例重新对其进行测试。并将新开发的测试用例合并到基线测试包中。

通过对测试用例库的维护不仅改善了测试用例的可用性，而且也提高了测试库的可信性，同时还可以将一个基线测试用例库的效率和效用保持在一个较高的级别上。

2、回归测试包的选择

在软件生命周期中，即使一个得到良好维护的测试用例库也可能变得相当大，这使每次回归测试都重新运行完整的测试包变得不切实际。一个完全的回归测试包括每个基线测试用例，时间和成本约束可能阻碍运行这样一个测试，有时测试组不得不选择一个缩减的回归测试包来完成回归测试。

回归测试的价值在于它是一个能够检测到回归错误的受控实验。当测试组选择缩减的回归测试时，有可能删除了将揭示回归错误的测试用例，消除了发现回归错误的机会。然而，如果采用了代码相依性分析等安全的缩减技术，就可以决定哪些测试用例可以被删除而不会让回归测试的意图遭到破坏。

选择回归测试策略应该兼顾效率和有效性两个方面。常用的选择回归测试的方式包括：

(1)、再测试全部用例

选择基线测试用例库中的全部测试用例组成回归测试包，这是一种比较安全的方法，再测试全部用例具有最低的遗漏回归错误的风险，但测试成本最高。全部再测试几乎可以应用到任何情况下，基本上不需要进行分析和重新开发，但是，随着开发工作的进展，测试用例不断增多，重复原先所有的测试将带来很大的工作量，往往超出了我们的预算和进度。

(2)、基于风险选择测试

可以基于一定的风险标准来从基线测试用例库中选择回归测试包。首先运行最重要的、关键的和可疑的测试，而跳过那些非关键的、优先级别低的或者高稳定的测试用例，这些用例即便可能测试到缺陷，这些缺陷的严重性也仅有三级或四级。一般而言，测试从主要特征到次要特征。

(3)、基于操作剖面选择测试

如果基线测试用例库的测试用例是基于软件操作剖面开发的，测试用例的分布情况反映了系统的实际使用情况。回归测试所使用的测试用例个数可以由测试预算确定，回归测试可以优先选择那些针对最重要或最频繁使用功能的测试用例，释放和缓解最高级别的风险，有助于尽早发现那些对可靠性有最大影响的故障。这种方法可以在一个给定的预算下最有效的提高系统可靠性，但实施起来有一定的难度。

(4)、再测试修改的部分

当测试者对修改的局部化有足够的信心时，可以通过相依性分析识别软件的修改情况并分析修改的影响，将回归测试局限于被改变的模块和它的接口上。通常，一个回归错误一定涉及一个新的、修改的或删除的代码段。在允许的条件下，回归测试尽可能覆盖受到影响的部分。

再测试全部用例的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略进行缩减的回归测试。

3、回归测试的基本过程

有了测试用例库的维护方法和回归测试包的选择策略，回归测试可遵循下述基本过程进行:

(1). 识别出软件中被修改的部分；

(2). 从原基线测试用例库T中，排除所有不再适用的测试用例，确定那些对新的软件版本依然有效的测试用例，其结果是建立一个新的基线测试用例库T0。

(3). 依据一定的策略从T0中选择测试用例测试被修改的软件。

(4). 如果必要，生成新的测试用例集T1，用于测试T0无法充分测试的软件部分。

(5). 用T1执行修改后的软件。

第(2)和第(3)步测试验证修改是否破坏了现有的功能，第(4)和第(5)步测试验证 修改工作本身。

三、 回归测试实践

在实际工作中，回归测试需要反复进行，当测试者一次又一次地完成相同的测试时，这些回归测试将变得非常令人厌烦，而在大多数回归测试需要手工完成的时候尤其如此，因此，需要通过自动测试来实现重复的和一致的回归测试。通过测试自动化可以提高回归测试效率。为了支持多种回归测试策略，自动测试工具应该是通用的和灵活的，以便满足达到不同回归测试目标的要求。

在测试软件时，应用多种测试技术是常见的。当测试一个修改了的软件时，测试者也可能希望采用多于一种回归测试策略来增加对修改软件的信心。不同的测试者可能会依据自己的经验和判断选择不同的回归测试技术和策略。

回归测试并不减少对系统新功能和特征的测试需求，回归测试包应包括新功能和特征的测试。如果回归测试包不能达到所需的覆盖要求，必须补充新的测试用例使覆盖率达到规定的要求。

回归测试是重复性较多的活动，容易使测试者感到疲劳和厌倦，降低测试效率，在实际工作中可以采用一些策略减轻这些问题。例如，安排新的测试者完成手工回归测试，分配更有经验的测试者开发新的测试用例，编写和调试自动测试脚本，做一些探索性的或ad hoc测试。还可以在不影响测试目标的情况下，鼓励测试者创造性地执行测试用例，变化的输入、按键和配置能够有助于激励测试者又能揭示新的错误。

在组织回归测试时需要注意两点，首先是各测试阶段发生的修改一定要在本测试阶段内完成回归，以免将错误遗留到下一测试阶段。其次，回归测试期间应对该软件版本冻结，将回归测试发现的问题集中修改，集中回归。

在实际工作中，可以将回归测试与兼容性测试结合起来进行。在新的配置条件下运行旧的测试可以发现兼容性问题，而同时也可以揭示编码在回归方面的错误。

    软件测试到底要不要追究BUG发生的原因呢？这个问题的争议很多，有人认为寻找BUG的原因是开发的事情，软件测试只要能发现BUG就够了；还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确？我个人认为这个问题是仁者见仁，智者见智，站在一个产品不同的层面看，会有不同的看法。这里所谈到的观点，也仅代表个人看法。

由于性能测试与功能测试有很大的区别，所以讨论出的结果可能与预先的设想有一定的区别。
性能测试的目的：
为了验证系统是否达到用户提出的性能指标，同时发现系统中存在的性能瓶颈，起到优化系统的目的。

性能测试指标的来源：
用户对各项指标提出的明确需求；如果用户没有提出性能指标则根据用户需求、测试设计人员的经验来设计各项测试指标。（需求+经验）

主要的性能指标：
服务器的各项指标（CPU、内存占用率等）、后台数据库的各项指标、网络流量、响应时间。

BUG观点：
1、性能测试就象人在无风情况下跑步（正常情况下的性能指标）；
2、压力测试就象人在微风中跑步（在正常的基础上加大多少百分比压力的性能指标）；
3、负载测试就象人在强风中跑步（不断加压，直到系统崩溃）。

HTTP观点：
1、 负载测试是正常情况下持续的加压；
2、 压力测试是直接加压达到一个极限值。

大家统一的观点：
性能测试、压力测试、负载测试密不可分，可统称为性能测试。

性能测试要点：
1、 性能测试是在功能测试完成之后进行。
2、 性能测试计划、方案一般与测试用例统一在一个文档里。
3、 测试环境应尽量与用户环境保持一致。
4、 性能测试一般使用测试工具和测试人员编制测试脚本来完成，性能测试的环境应单独运行尽量避免与其他软件同时使用。
5、 性能测试的重点在于前期数据的设计与后期数据的分析。
6、 性能测试的用例主要涉及到整个系统架构的问题，所以测试用例一旦生成，改动一般不大，所以做性能测试的重复使用率一般比较高。（说明：当系统中出现的某个功能点需要修改，它一般只会影响到功能测试的设计用例，而对于性能测试，很少影响到性能测试的设计用例。但是如果某个功能有较大的修改，性能测试也应该进行重新测试。）

现在软件测试工作越来越收到企业的重视，许多人员也投入到软件测试的行列中来，软件测试工程师的队伍越来越壮大。但是如何成为一名优秀的软件测试工程师呢？这是大家比较关注的一个问题，尤其是初入这个行当的莱鸟更想了解这个问题的答案。本文根据自己多年来在IT公司从事软件测试的经验总结了一些东西给大家共享，同时也希望大家提出宝贵的意见和建议。

起码有三年以上的软件开发经验

现在许多软件企业招收一些刚刚毕业的大学生或者非计算机专业的人员作为自己公司软件测试工程师，这是非常错误的，也是对软件测试不负责任的表现。虽然他们可以发现软件中的一些错误，但是对于软件中的一些关键，致命，危险的错误他们是很难发现的。大家都知道，软件工程中有个模型叫瀑布模型，这是最基本的软件模型，这个模型又叫碗状模型，因为开发位于碗的最底部，左上方依次为建模，需求分析，设计；右上方依次为测试，部署，维护。这就是说明软件开发是一切软件活动的基础，同时也是软件测试的基础。一个人只有经历过一定年限的软件开发工作，才可以积累丰富的经验，知道在软件中哪些地方容易出错而那些地方不容易，这给以后的软件测试工作带来非常宝贵的经验。

有逆向思维的能力

我曾经接触过一些软件测试工程师，他们干了一段时间软件测试工作后返回去又开始去做开发工作了，问他们为啥？答案是软件测试工作太难了，开发是顺向思维，而测试是逆向思维，老要找一些稀奇古怪的思路去操作软件。软件的使用者千差万别，软件在使用过程中遇到的各种现象也是千差万别的，所以要求软件测试工程师需要具有一些逆向思维的能力，想别人所不想，测别人所不测，这样才可以找到更多的软件中的错误。这是作为一名优秀的软件测试工程师最基本的素质。

善于同软件开发人员沟通

沟通是当今软件项目中需要掌握的最关键技术之一。软件测试人员要善于同软件开发人员沟通，软件测试人员与开发人员搞好关系，使测试人员不成为开发人员的眼中钉，这对于提高整个软件项目质量是十分重要的。沟通主要包括：
讨论软件的需求，设计：通过这样的沟通，你可以更好的了解所测试的软件系统，以至于尽可能少的测试出软件中不是错误的“错误”，从而降低给软件开发人员带来的压力。
报告好的测试结果：作为一个测试人员，发现错误往往是测试人员最愿意而且引以自豪的结果，但是一味地给开发人员报告软件错误，会给他们造成厌恶感，降低整个软件的质量和开发进度。所以作为一名软件测试工程师，当你测试的模块没有严重的错误或者错误很少的时候，你不妨跑到开发人员那里告诉他们这个好消息，这会给你带来意想不到的结果。
讨论一些与工作无关的事情：作为一个测试人员经常和开发人员讨论一些与工作无关的事情，比如大家可以谈谈新闻，趣事，家庭…这样可以加强相互间的默契程度，许多统计表明，这样可以更好的提高软件工作质量。

善于同领导沟通

测试人员往往是领导的眼和耳，领导根据测试人员的测试结果可以了解公司的产品质量，从而调整其他的工作。领导工作一般比较繁忙，所以作为一名优秀的测试人员要学会把测试结果进行总结，最好以图表的形势给领导看。

掌握一些自动化测试工具

测试工作往往是比较繁琐，枯燥无味的工作，测试人员长期处于重复的手工工作，会降低测试效率，并且对于测试质量也往往是不利的；况且许多测试不使用测试工具是不可以进行的，比如性能测试，压力测试等等。目前市场上有许多测试工具供你使用，你可以根据自己的需要选择一些测试工具来辅助你的测试。但是要记住一点，不是说有了测试工具就不要人工测试了，测试工具不是万能的。

善于学习的能力

软件测试技术随着时间的变化也在做一些提高和改进，作为一名优秀的测试人员要善于利用书籍，网站，论坛，交流等各种途径不断提高自己的软件测试水平。

提高自己的表达能力

软件测试人员当发现软件中存在缺陷的时候，往往要书写缺陷报告，缺陷报告要写得详尽清楚，使开发人员能够尽快定位错误，修改错误，所以作为一名优秀的测试人员提高自己的写作能力是非常必要的。

了解业务知识

更好的了解你说测试软件的业务知识是非常重要的，对业务知识了解得越深入，越能够找出更深入，更关键，更隐蔽的软件错误。所以作为一名优秀的软件测试工程师，要多向该领域专家，同行学习，提高自己的业务知识水平。

软件开发过程及软件质量保证
1.软件开发过程的几个主要阶段：
1）定义。明确开发的目标，软件的需求。
2）计划。制订软件开发所涉及到的计划。
3）设计。设计、编码、编写文档等，完成要求的软件特性。
4）稳定化。主要是测试和缺陷修复，确保软件的质量。
5）安装。安装、提交完成的软件，为客户提供运行环境。
2.几种常用的软件生命周期模型：
1）瀑布模型。
2）原型模型。
3）增量模型。
4）螺旋模型。
从软件测试人员的角度来看软件开发过程，需要注意的是：测试贯穿在整个开发过程中，而不是在某个阶段集中地做一下测试而其它阶段不用理会测试工作。

一个软件之所以被认为为质量优秀，是它内在具备了这样一些特性：
满足用户的需求；
合理进度、成本、功能关系；
具备扩展性和灵活性，能够适应一定程度的需求变化；
能够有效地处理例外的情况；
保持成本和性能的平衡。

软件质量保证(Software Quality Assurance-----SQA)是为了确保软件开发过程和结果符合预期的要求而建立的系列规程，以及依照规程和计划采取的一系列活动及其结果评审。

软件质量保证的活动主机包括：
技术方法的就用；
正式技术评审的实施；
软件测试；
标准的执行；
修改的控制；
度量；
记录和记录保存。

软件错误的定义：软件错误是软件产品中存在的导致期望的运行结果和实际结果间出现差异的一系列问题，这些问题包括故障、失效、缺陷。


软件测试：
软件测试就是为了发现软件中存在的错误而分析或执行程序的过程。具体地说，软件测试是分析程序或根据软件开发各阶段的规格说明和各程序的内部结构而精心设计出一批测试用例，并利用测试用例来运行程序，以发现程序错误的过程。

软件测试有两个基本的功能：验证(Verification)和确认(Validation)。
验证指保证软件正确地实现了特写功能的一系列活动。
确认指保证最终的产品满足系统需求。
通俗的说：验证保证产品的正确性；确认保证生产了正确的产品。

软件测试人员应该至少具备以下两个关键领域方面的知识：
1）软件测试技术；
2）被测应用程序及其相关应用领域知识。

理解以下的描述：
测试能提高软件的质量，但是提高质量不能依赖测试；
测试只能证明错误存在，不能证明错误不存在；
测试的主要困难是不知道该如何进行有效地测试，也不知道什么时候能够放心的结束测试；
每个程序员都应当测试自己的程序（份内事），但不能作为程序已通过测试的依据（所以项目需要独立的测试人员）；
80-20原则：80%的错误聚集在20%的模块中，经常出错的模块改错后还是会经常出错；
测试应当循序渐进，不要企图一次性做完。"欲速则不达"。

测试人员的目标和主要工作：
目标：（1）.基本目标是发现软件错误；
（2）.要尽可能早的找出软件错误；
（3）.必需确保找出的软件错误得以关闭。

主要工作：
1）规划测试任务
2）设计测试（包括编写测试用例等等）
3）建立一个合适的测试环境
4）评估、获取、安装和配置自动测试工具
5）执行测试
6）撰写适当的测试文档

软件测试的分类
1．从是否需要执行被测试软件的角度分：有静态测试和动态测试。
2．从测试是否针对软件结构和算法的角度分类分：白盒测试和黑盒测试。
3．从测试的不同阶段分：单元测试、集成测试、系统测试和验收测试四个阶段。
其中系统测试有：功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试等等。

针对某些功能作用的测试：
回归测试：指错误被修正后或软件功能、环境发生变化后进行的重新测试。
功能测试：测试软件的功能是否符合功能性需求，通常采用黑盒测试方式。
负载测试：测试软件系统的最大负载，超出此负载软件有可能会失常。
压力测试：与负载测试差不多，叫法不同。
易用性测试：测试软件是否易用，主观性比较强。一般要根据用户的反馈信息来评价。
安装与反安装测试：测试软件在"全部、部分、升级"等状况下的安装/反安装过程。
恢复测试：测试系统从故障中恢复的能力。
安全性测试：测试系统防止非法侵入的能力。
兼容性测试：测试系统与其它软件、硬件兼容的能力。
内存泄漏测试：测试软件在运行过程中是否会造成内存泄漏。
比较测试：通过与同类产品比较，考察该产品的优点、缺点。
Alpha测试：一种先期的用户测试，此时系统刚刚开发完成。
Beta测试：一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。同Alpha测试一样都由用户进行，场地不同，Alpha测试一般是把用户请到开发方的场地来测试，Beta测试是指在一个或多个用户的场所进行测试。

测试工作的主要步骤：
1）测试计划：测试人员要首先对需求进行分析，最终定义一个测试集合。
2）测试设计与开发：根据软件需求、说明书完成测试用例设计并编写必要的测试驱动程序。
3）执行测试：需要做的工作是，建立测试环境；根据前面编写的测试计划和测试用例运行测试；记录测试结果；报告软件缺陷；跟踪软件缺陷直至其被处理；分析测试结果


PS　测试工程师职业素质
1）责任心
2）学习能力
3）怀疑精神
4）沟通能力
5）专注力
6）洞察力
7）团队精神
8）注重积累