3.                断言：

断言允许你断言从被测的服务器端接收到的响应的事实。使用断言，你能“根本上测试”你的应用返回的你预期的结果。例如，你可以断言一个查询将返回包括一些特定文本的记录。这个文本可能是PERL格式的正态表达式，并且你可以指明这个返回将包括文本或它应该可能匹配整个反应。

你可以添加断言到任意一个取样器里，例如，你可以添加断言到一个HTTP请求来检查文本“</HTML>”。JMeter会检查这个文本是否在HTTP响应里，如果JMeter找不到，它将把这个请求标记为“失败的请求”。

要查看断言结果，添加断言监听器到这个线程组。

如果想让JMeter在请求的回复上做基本的验证，添加一个断言到请求控制器。例如，在对WEB应用做压力测试时，服务器会返回一个成功的“HTTP回复”代码，但页面可能会有错误或缺少内容。你可以添加断言来检查某些特定的HTML标签，一般的错误字符串，等等。JMeter允许你使用正则表达式创建这些断言。

4.                监听器

当JMeter运行时，监听器可以提供访问JMeter所收集的关于测试用例的信息。图像结果监听器在一个图表里绘制响应时间。查看结果树监听器具体的显示取样器的请求和响应，然后以HTML和XML格式显示出来。其它的监听器提供汇总或组合信息。

此外，监听器能处理一个为日后所用，收集到一个文件里的数据。在JMeter里的每个监听器都可以指定一个文件，用来存储数据。

你可以在测试的任何地方添加监听器。它们只会收集从这个元件开始到这一层最低层的数据。

5.                定时器

默任， JMeter线程发送出的每个请求是不间断的。我们建意你通过添加一个可用的定时器到你的线程组里来指定延迟时间。如果你不添加延时，JMeter可能在较短的时间内发送大量的请求致使你的服务器瘫痪。定时器将可以让JMeter在线程组里，在每个请求间，延迟一定时间。

如果你想在一个线程组里添加一个以上的定时器，JMeter会在执行你所应用的那个取样器之前累加所有的计时器，然后以那累加后的时间来做停顿。

6.                 配置元件

配置元件工作和取样器很接近，尽管它不能发送请求（HTTP代理服务器除外），它可以补充或修改请求。

只有在你放置元件的树分枝里面，才能访问配置元件。例如，如果你把HTTP Cookie管理器放在某个线程组里，那么只有你放在该线程组里的HTTP请求控制器才能访问这个Cookie管理器如下图所示：

 

 “地区查询”和可以访问这个http Cookie1管理器，“商圈添加”和“商圈管理”可以访问http Cookie2管理器，商圈查询不能访问任何的Cookie管理器。并且，在树分枝里的配置元件比在父级分枝同样的元素有更高的优先权。例如，我们定义两个http请求默认值，“请求默认值1”和“请求默认值2”。因为我们把“请求默认值1”放在商圈查询这个子节点中，所以这个线程组里，只有“商圈查询”可以访问它而商圈添加和商圈修改则可以访问请求默认值2。因为我们把它放在商圈这个线程组里。

7.                 前置处理器

前置处理器在取样器请求前执行一些操作。如果前置处理器附有取样器元件，那么它将先于这个取样器元件执行。前置处理器常用于在取样器元件运行前修改它的设置，或是更新从响应文本里投取不出来的变量。当执行前置处理器时，再具体参看作用范围规则。

8.                 后置处理器

后置处理器在取样器请求后执行一些操作。如果后置处理器附有取样器元件，它将在那个取样器元件运行之后运行。后置处理器多用于处理响应数据，从里面抽取出有价值的东西。当执行后置处理器时，再具体参看作用范围规则。

 

要使用Jmeter，必须要熟悉Jmeter里面相关的内容，Jmeter的应用主要体现在测试计划里面，所以，首先要认识Jmeter测试计划里面的元件

1. 线程组

线程组元件是任何一个测试计划的开始点。在一个测试计划中的所有元件都必须在某个线程组下。顾名思义，线程组元件控制JMeter执行你的测试计划时候使用的线程数量。右键点击测试计划，选择添加，在弹出的菜单中，选择线程组，则会添加一个线程组，如下图所示：

对线程组的控制允许你：

设置线程组名称，注释

在取样器错误后要执行的动作：如果是继续，表示某个线程错误后，后面的线程继续运行，如果是停止线程，则表示后面的线程都停止运行，返回出错之前的测试结果如果是停止测试，则停止测试，不返回测试结果

设置线程数：此处设置的线程数表示同时运行多少个线程，发送多少个请求

设置ramp-up period：ramp-up period指示JMeter用于达到全部选择的线程的时间。如果选择了10个线程，并且ramp-up period是2秒，那么JMeter将使用2秒使10个线程启动并运行。每个线程将在前一个线程启动后0.2（2/10）秒后启动。如果将此设置为0，则表示并发，也就是所有线程在统一时间启动。Ramp-up需要足够长的时间来避免在开始测试时产生太大的负荷，并且有足够短的时间使最后一个线程在第一个线程结束之前运行。（除非你想那样做）

 

开始的Ramp-up = 线程数+必须的调节数

循环的次数：线程循环的次数，如果次数设置为1，那么JMeter在停止前只执行测试计划一次。

调度器：在1.9以后的版本中多了调度器这个功能，通过这个功能，你可以设置什么时候开始测试，什么时候结束测试，如果你设置了开始测试时间，就算是你在Jmeter上运行了测试，如果没有到你设置的开始时间，jmeter是不会执行测试的，直到到了你设置的开始时间，才会开始执行测试，同样的，如果你设置了结束时间，一旦到了结束时间，不管当前执行的循环有没有结束，jmeter都会停止执行。而启动延迟可开始时间差不多，你可以设置开始测试时多长时间才开始真正执行测试，而持续时间，则设置当前线程组总共执行多长时间，通过调度器的设置，你可以更加灵活的对你的测试计划进行设置，使得测试计划可以符合更复杂的场景。

 

2. 控制器

JMeter有两种类型的控制器：取样器和逻辑控制器。

取样器：指示JMeter向一个服务器发送请求。例如，如果你想让JMeter发送HTTP请求，那么添加一个HTTP请求器，添加方法为右键点击线程组，选择添加，在弹出的菜单中，选择samper，然后选择http请求。你可以向一个取样器中添加一个或多个配置元件来定制请求。

Jmeter有多个取样器可以使用，每种取样器表示一种请求，每个取样器有几个可以设置的属性。你可以向取样器添加一个或多个配置元件来进一步的控制取样器，比如添加断言，添加监听器等。如果你在一个线程组中添加了多个取样器，JMeter以你向树中添加取样器的顺序发送请求。

如果你想向一个服务器发送同种类型（例如：HTTP请求）的多个请求。考虑使用缺省配置元件（Defaults Configuration Element）。每个控制器有一个或多个缺省元件。

逻辑控制器：逻辑控制器允许你定制JMeter何时发送请求。逻辑控制器可能包话如下的子元件：取样器（请求），配置元件，其它的逻辑控制器。逻辑控制器能够更改它的子元件中的请求的顺序。他们可以自己修改请求，使JMeter重复请求，例如，你可以添加交替（Interleave）逻辑控制器来在两个HTTP请求取样器之间轮流。

要理解逻辑控制器对测试计划的影响，假设如下的测试树：

l                    测试计划

n                                  线程组

u                                               仅一次控制器

²                                                             登录请求

u                                               加载搜索页

u                                               交替控制器

²                                                             搜索‘A’

²                                                             搜索‘B’

²                                                             默任HTTP请求

u                                               默任HTTP请求

u                                               Cookie管理器

 

这个测试首先是执行登录请求，它在整个测试过程中只执行一次。后面的反复执行将跳过它。这是由于使用了仅一次控制器。

 

登录后，取样器接着会加载搜索页（想像一个用户登录进去，然后打开搜索页来搜索信息这样一个WEB应用。）这只是一个简单的取样器请求，没有用任何逻辑控制器过滤。

 

加载完搜索页后，我们想搜索一下，事实上，我们想做两种不同的搜索。然而，我们想在每个搜索之间重新加载搜索页面。我们可以通过使用四个简单的HTTP请求元件（加载搜索页面，搜索‘A’，加载搜索页面，搜索‘B’）。或者使用交替控制器，它一次传递一个子请求到这个测试。按子元件的排列顺序。交替2个子请求可能有点大材小用，但是如果有8或是20个子请求，那么它使用它将很简单。

 

注意HTTP默任请求是在交替控制器里。设想一下，“搜索A”和“搜索B”共享相同的目录信息（一个规范的HTTP请求包括域，端口，方法，协议，路经，参数和一些其它可选选项）两个搜索请求，都使用相同的后台搜索引擎（我们可以暂说它是一个servlet或是cgi脚本）。胜于配置两个使用相同路经信息的HTTP取样器，我们能够把信息提取到单独的一个配置元件。当交替控制器把请求从“搜索A”传递到“搜索B”时，它会把HTTP默任请求配置元件值填在空白值里。因此我们把那些请求的路经信息置空，把那些信息放在配置元件里。在这个例子里，只利用一点它的优势，以后还来会再论述它。

 

这个树的下一个元件是另一个HTTP默任请求，这次单独把它放在线程组里。线程组有一个内置的逻辑控制器，因些，它可以向上面说的那样，精确的使用配置元件。它会填上空白处来传递任何一个请求。它在网站测试时，置空你所有的HTTP取样器的域值，把那些信息放在HTTP默任请求元件里，然后加到线程组时特别有用。通过这样做，你可以在不同的服务器上通过简单的改变你的测试计划里的一个值来测试你的应用。否则，你不得不在每个取样器，每个值修改一次。

 

最后一个元件是HTTP Cookie管理器。你因该在所有的网站测试里添加一个Cookie管理器，否则JMeter会忽略Cookie。通过添加它到线程组这一层，我们可以确保所有的HTTP请求可以共享相同的Cookie。典型的 web 应用一般都会：(1)有一个登录页，它是整个应用的入口。当用户登录之后，应用会将用户相关的安全信息放到 session 中。(2)有一个 filter，它拦截请求，检查每个请求相关的 session 中是否包含有用户安全信息。如果没有，那么请求被重定向到登录页，要求用户提供安全信息。如果你不添加Cookie管理器，在这种配置下应用上面的测试计划，那么除了登录页之外的其它请求都将因为缺少用户安全信息，而使请求实际定位到登录页。如果不加断言，那么在监听器看来所有的请求都是成功。而实际上，这些请求最终都没有到达它们应该去的地方。显然，这种测试结果不是我们所期望的。

 

Jmeter还有其他一些逻辑控制器，你可以添加多个逻辑控制器来达到各种不同的结果。

 

1. 前言

    JMeter 是Apache组织的开放源代码项目，是一个100%纯Java桌面应用，主要用于压力测试和性能测量。它最初被设计用于Web应用测试但后来扩展到其它测试领域。

    现在网络上的资料主要介绍了用Jmeter怎么做性能测试，主要方法是利用Jmeter模拟大量的服务器负载、网络负载、软件对象负载，在不同压力类别下测试软件的强度，然后使用JMeter提供的图形化界面，分析性能指标或者在高负载情况下被测试的服务器/脚本/对象的性能以及软件的整体性能。

利用JMete也可以做web的功能测试，主要是将客户端提交的请求通过jmeter的http请求向服务器发送请求，然后查看返回结果，如果http发送成功，服务器会做出相应，并且将请求数据存储。

    本文主要介绍如何使用JMeter，从熟悉Jmeter的开始，逐步讲解Jmeter的各个部分，已经如何用jmeter做性能和功能测试，因为对jmeter使用不是完全熟悉，对有些内容不理解的，当作待解决问题。

 

2 安装Jmeter

 

官方网址 ：http://jakarta.apache.org/jmeter/在这里，可以查看Jmeter的相关资料。

下载地址：http://jakarta.apache.org/site/downloads/downloads_jmeter.cgi

       Jmeter的最新版本是2.3.1，下载页面有两种类型的下载包，如果是使用，则选择Binary，然后选择zip格式的下载包进行下载。Jmeter不需要安装，所以，解压的时候选择好你要解压的地址就可以。

    运行Jmeter程序需要先安装JDK(1.4以上)，如果你的电脑上没有安装JDK，要先安装JDD, 把JDK文件安装到C盘的\Program Files\Java目录下面。安装完JDK后，需要配置环境变量。具体的环境配置方法请参考网络相关的资料。

安装好JDK后，在命令行中输入javac，如果返回一些信息内容，则表示jdk安装成功，则可以运行Jmeter程序，具体方法如下：

    假如将下载的.zip文件解压缩到D:/JMeter目录下。进入Jmeter的解压目录，点击D:/JMeter/bin下面的jmeter.bat批处理文件来启动JMeter的可视化界面，如下图所示：

 

    启动Jmeter后，在Jmete界面上，会有测试计划和工作台两个菜单，测试计划描述了执行测试过程中JMeter的执行过程和步骤，一个完整的测试计划包括一个或者多个线程组(Thread Groups)、逻辑控制器（Logic Controller）、配置元件（Sample Generating Controllers）、监听器(Listener)、定时器（Timer）、断言（Assertions）、配置元素（Config Elements）。打开JMeter时，它已经建立一个默认的测试计划,一个JMeter应用的实例只能建立或者打开一个测试计划。而工作台主要是用来录制脚本的，在录制脚本的时候，通过工作台设置HTTP代理服务器。

 

 

利用JMeter进行负载测试的时候，使用单台机器模拟测试超过1000个行程的并发就有些力不从心，在执行的过程中，JMeter自身会自动关闭，要解决这个问题，可以使用分布式测试，运行多台机器运行所谓的 Agent 来分担 JMeter自身的压力，并借此来获取更大的并发用户数,但是需要进行相关的一些修改，具体如下：

1.     在所有期望运行 JMeter 作为 Load Generator 的机器上安装 JMeter，并确定其中一台机器作为 Controller，其他的机器作为 Agent。然后运行所有 Agent 机器上的JMeter-server.bat文件——假定我们使用两台机器 192.168.0.1 和 192.168.0.2 作为 Agent；

2.     在Controller 机器的 JMeter 安装目录下找到 bin 目录，再找到 JMeter.properties 这个文件，使用记事本或者其他文字编辑工具打开它；

3.     在打开的文件中查找“remote_hosts=”这个字符串，你可以找到这样一行“remote_hosts=127.0.0.1”。其中的 127.0..0.1 表示运行 JMeter Agent 的机器，这里需要修改为“remote_hosts=192.168.0.1:1099,192.168.0.2:1099”——其中的 1099 为 JMeter 的 Controller 和 Agent 之间进行通讯的默认 RMI 端口号；

4.      保存文件，并重新启动 Controller 机器上的 JMeter.bat，并进入 Run -> Remote Start 菜单项，在这里可以看到远程启动菜单下面有192.168.0.1 ，192.168.0.1两个IP地址

5    如果要让某个电脑执行，可以点击改电脑的IP地址就可以，如果两个都要执行，可以点击Run 菜单下的“远程运行全部”菜单

6   有时候用作代理的机器太少，仍不能满足需要，则需要将作为Controller的电脑也当作Agent，则同样需要修改JMeter.properties文件，将Controller的IP地址写入。同时，这个时候，需要打先打开Controller 电脑中JMeter下bin目录下的jmeter-server.bat，然后再打开JMeter.bat，此时，进入Run -> Remote Start菜单，可以看到Controller也作为远程机器进行运行。

一、项目目前具备能力

基于我们前期的测试，项目具备单用户常规流程的增删改查基本操作能力

二、目前存在的隐患

根据测试总结出系统目前可能存在的隐患，以确定解决问题的办法和下一步行动计划

1、 数据校验

数据校验，存在三类问题，即：

l          在某些子程序块中，没有对访问对象进行检验，通常情况下，不会产生问题，而在一

些未预料到的路径上，存在访问数据库中不存在或无法查询到的对象的现象（如异步

并发或数据关联时），从而产生NullPointerException的问题；

l          本项目使用了MySQL XML提取技术和iBatis框架组SQL语句，使用XPath查询字段中

XML 节点值时，由于XPath 为前台传入，当传入值为不规范的语言标识（即非zh-CN

和en 又含有<>的标识），在组成XPath 时，可能产生SQL 语句异常；并且，在多语言

内容中，传入值为带<>之类的数据时，则解析出的值与期望不相符合；

l          页面中未限制长度时，因数据长度过长，而出错；

2、数据关联

l          某些子程序块中，会因异步并发，而未做判断就引用了查询不到的对象属性，导致

NullPointerException；

l          在页面中，多个ID 查询选择组串时，在取消选择的情况下，有可能会误取消掉其他ID 的

对象；

3、多语言

界面上传入语言标识并组成SQL语句，问题同1中描述，并且，当界面上为“请选择语言”，

而忽略了判断需选择语言时，会出现XPath非法的问题；

4、文件操作

文件操作，在继误删除图片Bug 修改之后，还存在两类隐患：

l          删除文件：前台可以通过暴力猜测提交假上传请求的方式，将后台图片文件全部删除；

l          并发问题：由于是取300 的模确定酒店图片目录，时间确定文件名，当酒店相同或模

后ID相同时，同一时间同一类型提交，可能会出现，两个线程写同一个文件名文件的现象；

5、数据导入

导入的数据可能需要经过检查和测试才能保证正确性；

6、性能

正常操作及常规业务数据但数据量较大时，系统可能会崩溃；压力测试结果：20 家酒店300

线程无限次循环请求查询酒店，系统在几分钟后崩溃；

系统在持续产生异常的压力情况下，有待测试；

1         利用Jmeter的“函数助手”选择“_Random”函数

步骤：点击Jmeter的“选项”，选择“函数助手对话框”（或者使用快捷键“Ctrl＋F”），在“选择一个功能”的下拉框中选择“_Random”，然后在“函数参赛”中会出现三个参数有用户来设置，第一个参数是“一个范围内的最小值”，即所要取的随机数的最小值，我们设置成1；第二个参数是“一个范围内的最大值”，即所要取的随机数的最大值，我们设置成100；第三个参数是“函数名称”，即用于存储在测试计划中其他的方式使用的值，我们设置成Random。设置好上面的三个参数后，点击“生成”按钮，这样就会在对话框的最下面生成一个字符串“${__Random(1,100,Random)}”，在我们编写的脚本中，找到要替换的参数，把它的值换成前面生成的字符串就可以了，然后每次运行的时候，这个参数会变成一个1到100之间的随机数。

 

说明：这个功能可以利用在测试需要添加多条数据记录而且某些字段需要唯一性的测试脚本中，随机生成的参数是数字，如果需要字母或者其他字符，则不能利用该功能实现，请看第二种方法

2         利用Jmeter的“函数助手”选择“_ StringFromFile”函数

功能：这个函数是从一个文件中取到一个字符串

步骤：

首先需要一个文本文件，可以手工生成，也可以通过数据库查询工具查出结果，然后拷贝到一个文本文件中。

点击Jmeter的“选项”，选择“函数助手对话框”（或者使用快捷键“Ctrl＋F”），在“选择一个功能”的下拉框中选择“_ StringFromFile”。生成文本文件后就可以设置这个函数的参数了，参数分别是“输入文件的全路径”，“函数名称”，“Start file sequence number”，Final file sequence number”。第一个参数就是咱们前面生成的文件的完整路径，即文件路径＋文件名.扩展名（文件路径可以写成相对路径或绝对路径）。第二个参数是用于存储在测试计划中其他的方式使用的值（其实我也一直不明白这个参数的用处，不设置有些函数也能正常使用，不过最好还是随便设置一下吧，因为还有一些函数不能缺省）。第三个参数是文件开始的序号，也就是文件读取的其起始行数。第四个参数是文件的结束序号，也就是要读取文件的最后行。假如咱们生成的文本文件有200行，如果开始序号设置成50,结束行设置成150，那么这个函数会按顺序从第50行，一直读取到150行，如果测试的循环次数超过了文件行数，比如循环了102次，那么最后一次循环读取的文件内容和第一次的一样，函数会自动循环读取。文件的起始序号和结束序号也可以不用设置，这样函数会从第一行读取到最后一行，然后再循环读取。

3         利用Jmeter的CSV Data Set Config

步骤：右键点击Jmeter中需要参数化的某个请求，选择添加——配置原件——CSV Data Set Config，会添加一个CSV Data Set Config，需要设置相关的一些内容，具体如下：

Filename：指定文件及所在路径(如：D:\test.txt)，说明，在txt文件中，每一行只能有一条数据，也就是类似于QTP的数据池中的数据，如果每一行是多条数据，则只能添加第一条数据，我实验用EXCEL，但是不成功，只能txt文件才可以。

   Variable Names：参数名称(如：ceshi)

Delimitet：在脚本中输入的参数（如：${ceshi}）

Recycle on EOF：某前没有明白什么意思，不过选择True就可以

添加后，可以通过 “添加－监视器－查看结果树(请求部分)”, 来检验参数化是否成

 

 

    利用一天时间,终于写完了Testlink1.7R3的使用说明书,通过写测试说明书,对testlink有了更深的理解,但是依旧存在一些理解错误和困难,这里,现把我对testlink的一些理解写下来.希望能够和朋友们一起探讨,学习.

 

实现的功能：

1 根据不同的项目管理不同的测试计划，测试用例，测试构建相互之间独立

2 根据树状的项目，组件，分类，测试用例，设计测试用例

3 可以基于关键字搜索测试用例。

4  可以将现有测试用例简单修改后复用，

5  同一项目可以制定不同的测试计划，然后将相同的测试用例分配给改测试计划（可以实现测试用例的复用，筛选）

6可以设定执行测试的状态（通过，失败，锁定，尚未执行），失败的测试用例可以和bugzilla中的bug关联，每个测试用例执行的时候，可以填写相关说明。

7 测试结果分析（可以实现按照需求，按照测试计划，按照测试用例状态，按照版本，统计测试结果）

8 自定义角色，通过角色控制用户权限

9 测试结果可以导出为excel表格

10 测试用例可以导出为csv，html格式

11 通过超连接，可以将文本格式的需求，计划关联

12 可以将测试用例和测试需求对应。测试可以根据优先级指派给测试员，定义里程碑

缺陷

1         不能根据优先级筛选用例，如果需要优先级，必须通过关键字来实现，比较麻烦

2         不能设定测试用例的种类，如果需要必须通过关键字来实现，更麻烦，也不太现实

3          如果测试用例需要大量的数据，创建测试用例时不方便

 

说明书下载地址:

 

首先，不要假设说明书上的所有内容都是正确的，也不要等到程序发布以后再根据程序去理解需求说明书，然后去设计测试。你手上有需求说明书，你就要努力的去理解他，因为这是你这个时候的工作，如果你在理解需求说明书的时候有困难，你可以寻找相关的人来帮助你，可能是需求说明书的作者，也可能是项目经理，或者是相关的程序员，只要你在这个时候寻求帮助，他们肯定会乐意帮助你的。在这个时候，你就要首先弄明白需求说明书的内容，因为，你后面的测试工作的展开，比如测试需求，测试用例，测试计划都是依照需求说明书的，如果你不理解测试用例，你就不能准确估算你的测试工作量，你也不能详细的设计你的测试策略，还有你的测试用例。

其次，努力获得和你要测试的项目相似的已经成型的系统，然后认真去研究它。可能你的项目没有详细的需求规格说明书，但是这个项目可能是以前系统的升级，或者只是做了很好的改动，或者，这个项目是根据现有市场上的已有产品的优化，无论怎么样，都可能会找到和现有系统类似的项目或者产品，这些可能项目经理可能会准备好，那么询问项目经理，得到它们然后，仔细研究它们。

当你得到了和你将要测试的系统类似的已经成熟的产品，就对她进行详细的检查，不是说让你去测试它，而是检查已有系统，然后确定你的产品会以一个什么样的形式组织，会怎样设计整个框架，彼此会有哪些联系。通过检查熟悉后，你进可以确定你将要测试的系统有哪些功能，以此来正确估算你测试需要花费的时间。同时，通过检查熟悉，你可以通过对比，确定你现有的关于你产品的信息是否对测试是足够的，如果缺少，怎么去获取，以次来确定你测试需要的资源。通过检查，你也可以确定产品质量相关的内容，确定哪些质量问题是测试的重点，哪些是bug高发区，以次来确定测试重点。检查还有利于你组织测试用例，针对系统的特点设计有效的，高覆盖率的测试用例

以上就是关于理解测试需求的一些讨论和方法，欢迎朋友们提出你们的看法和意见。

说明：本文是关于测试基础知识的一些拓展。

摘要：很多时候，我们没有完全理解需求说明书就匆忙开始了我们的测试工作，本文主要说明了如果对需求说明书不理解会导致的严重后果，以及如何有效的理解需求说明书。

 

现在你开始进入一个项目进行你的测试工作了，你参加了需求评审会议，知道了些项目的背景，得到了项目的需求说明书，从需求说明书开始你的测试工作。

或许你觉得你手上的需求说明书很差，你不想去看，你觉得你可以在系统真正出来以后，根据系统，你可以很容易的设计出测试用例，或者，你可以不用测试用例就能进行测试。如果你这么想，那么你肯定不会去设法理解需求说明书，也不会对你将要测试的需求说明书描述的系统有完整的，清晰的认识，或许你依旧可以根据模板做出测试计划，设计出测试用例，你的这些测试准备工作，可能也会通过评审，因为公司的评审并不严格或者其他的原因。好了，你这样做了，你知道这样做会有什么后果吗？

你也知道的，需求说明书是产生bug的主要原因，很多缺陷都可以追踪到需求说明书的不完整，不正确，变动多上面，那么你对需求说明书没有认真的检查，你肯定会遗漏很多的缺陷，你大概也知道如果在项目后期修改bug的费用比修改在需求说明书中的缺陷要高多少吧。

你没有理解需求说明书，对程序很多功能都没有详细的考虑，你能保证你看着系统就可以完全理解整个系统，大概不能吧，很多细节的内容，你还是需要对照需求说明书去理解，可是，你在检查需求说明书的时候都不去认真看它，现在，要测试了，测试任务可能很紧，你还会去看它吗，你看它的时候能够理解吗？肯定不能，那么你就要有人来明确告诉你系统是怎么回事。

好了，这个时候，你可能会求助产品经理，可能会求助项目经理，可能会求助程序员，但是，你要知道，如果你有很多的问题去问，你没有这么多时间，他们也没有这么多时间，你的问题能全部解决么？就算你的问题不多，可是你在这个时候去问他们关于需求的问题，你觉得他们会乐意解答吗？他们会认为，你没有做好你本来应该做好的事情，他们会对你敷衍，因为这不是他们这个是要的工作，他们这个时候的工作是编码或者是解决bug或者是其他，但绝对不是回答你关于需求的问题。

你的问题很大程度上不会被完整，准确的解决，可是你还是要测试，因为这是你的工作。因为你对整个系统的理解存在问题，你肯定会遗漏很多的测试点，你也会报告很多的无效bug，你还会无法判断你测试到的现象是系统特色还是bug，你知道这个时候你会有哪些问题么？

你遗漏了bug，会导致系统的不稳定，或许严重的，会导致整个系统的崩溃，你的工作没有做好，领导会找你的责任。你报告了许多无效的bug，开发人员对你的能力开始怀疑，对你的信任开始降低，你报告的bug他们不再关注，你会有很多未解决的bug等着你去跟踪。你无法判断你测试到的现象是系统特色还是bug同样会导致前面的两个问题。现在，你知道你的问题的严重性了吧。

以上所有的问题，仅仅是你在本来应该做事情的时候想当然的认为在以后可以解决而没有做，测试没有任何的假设，该你做什么你就应该做什么。

那么，如果你对需求说明书不了解，或者说明书不够详细，或者你认为需求说明书很差，你该做什么。

首先，不要假设说明书上的所有内容都是正确的，也不要等到程序发布以后再根据程序去理解需求说明书，然后去设计测试。你手上有需求说明书，你就要努力的去理解他，因为这是你这个时候的工作，如果你在理解需求说明书的时候有困难，你可以寻找相关的人来帮助你，可能是需求说明书的作者，也可能是项目经理，或者是相关的程序员，只要你在这个时候寻求帮助，他们肯定会乐意帮助你的。在这个时候，你就要首先弄明白需求说明书的内容，因为，你后面的测试工作的展开，比如测试需求，测试用例，测试计划都是依照需求说明书的，如果你不理解测试用例，你就不能准确估算你的测试工作量，你也不能详细的设计你的测试策略，还有你的测试用例。

其次，努力获得和你要测试的项目相似的已经成型的系统，然后认真去研究它。（待续）

一、功能测试

　　1、链接测试

　　链接是Web应用系统的一个主要特征，它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问。

　　链接测试可以自动进行，现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有页面开发完成之后进行链接测试。

　　2、表单测试

　　当用户给Web应用系统管理员提交信息时，就需要使用表单操作，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只能接受指定的某些值，则也要进行测试。例如：只能接受某些字符，测试时可以跳过这些字符，看系统是否会报错。

　　3、Cookies测试

　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。

　　如果Web应用系统使用了Cookies，就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间进行保存，刷新对Cookies有什么影响等。

　　4、设计语言测试

　　Web设计语言版本的差异可以引起客户端或服务器端严重的问题，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外，不同的脚本语言，例如Java、Javascrīpt、 ActiveX、VBscrīpt或Perl等也要进行验证。

　　5、数据库测试

　　在Web应用技术中，数据库起着重要的作用，数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL对信息进行处理。

在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度或程序设计问题等引起的，针对这两种情况，可分别进行测试。

二、可用性测试

　　1、导航测试

　　导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决定一个Web应用系统是否易于导航：导航是否直观？Web系统的主要部分是否可通过主页存取？Web系统是否需要站点地图、搜索引擎或其他的导航帮助？

　　在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动，很快地扫描一个Web应用系统，看是否有满足自己需要的信息，如果没有，就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构，因此，Web应用系统导航帮助要尽可能地准确。

　　导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容，内容在什么地方。

　　Web应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。

　　2、图形测试

　　在Web应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有：

　　（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链接到某个具体的页面。

　　（2）验证所有页面字体的风格是否一致。

　　（3）背景颜色应该与字体颜色和前景颜色相搭配。

　　（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。

　　3、内容测试

　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

　　信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文章列表"。

　　4、整体界面测试

　　整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个Web应用系统的设计风格是否一致？



　　对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。

　　对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户的参与。

　　三、客户端兼容性测试

　　1、平台测试

　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。

　　因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

　　2、浏览器测试

　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的产品，是为Internet Explorer而设计的，Javascrīpt是Netscape的产品，Java是Sun的产品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。

　　四、安全性测试

　　Web应用系统的安全性测试区域主要有：

　　（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

　　（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

　　（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

　　（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

　　（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

 

软件质量介绍

   软件质量定义：

      软件产品满足规定的和隐含的需求的能力

      与计算机软件优秀程度的特性相关的内容

      软件产品满足给定需求的性质和特性

软件质量特性：

     功能性   可靠性   易用性   效率  易维护性  可移植性

软件缺陷和错误的分类：（待完善）

缺陷类 型编号	缺陷类型	描述
10	F-功能	如逻辑,指针,循环,递归,功能等缺陷
20	G-语法	拼写、标点符号、打字
30	A-赋值	如声明、重复命名，作用域
40	I-接口	与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表相互影响的缺陷
50	B-联编打包	由于配置库、变更管理或版本控制引起的错误
60	D-文档	需求、设计类文档
70	U-用户接口	人机交互特性：屏幕格式，确认用户输入，功能有效性
80	P-性能	不满足系统可测量的属性值，如：执行时间，事务处理速率等
90	N-标准	不符合各种标准的要求，如编码标准、设计符号等
100	E-环境	设计、编译、其他支持系统问题

错误和缺陷产生的原因：（待完善）

隐藏错误的估计方法：

撒播模型：N=（n / m）*M

回归模型：

 配置管理

   配置项：配置管理的基本,包括软件过程中产生的程序，描述计算机程序的文档和数据

   基  线：可以提供给其他软件项目人员查看的一组相关的SCI的集合，基线的建立标志着一组开发活动完成

   版本管理：目的是为软件项目中的文档更新留下记录，供相关人员查看。通过为每一次更新标记一个版本来达到这个目的

   基线管理

       产品基线：产品达到一定功能后，与之相应版本的软件产品、用户手册以及提供给用户和其他开发组织的文件的一种集合。

       开发基线：完成某个开发过程以后，将改过程定义为一个基线。开发基线的内容即开发活动所完成的工作产品

系统测试和确认测试的区别：以前总是认为是在系统测试的时候进行确认测试，通过看文档了解到，确认测试主要是测试软件的功能是否正确，系统测试是在特定系统环境下进行软件测试，是系统的确认测试的一部分。也就是说，确认测试主要是测试软件的功能及其他特性是否正确，即是否满足需求规格。而系统测试是将通过确认测试的软件置于特定的运行环境下进行软件功能和性能的测试，是系统的确认测试的一部分。

软件质量定义：

    软件产品满足规定的和隐含的需求的能力

    与计算机软件优秀程度的特性相关的内容

    软件产品满足给定需求的性质和特性

正交试验设计法

      从大量的实验点中挑选出适量的、有代表性的点，应用依据伽罗瓦理论导出的“正交表”，合理地安排实验的一种科学的实验设计方法。

     试验指标：判断试验结果优劣的标准

     因    子： 有可能影响到试验条件的指标

而影响实验因子的，叫做因子的水平（或状态）。

测试方法

功能测试：

针对需求规格的功能测试属于高级测试，通常采用黑盒测试方法，包括即等价类划分，边界值分析，因果图分析、错误猜测等。

针对设计文档的功能测试属于低级测试，通常采用白盒测试方法，包括语句覆盖、条件/判定覆盖、路径覆盖等。

  WEB测试

   表示层测试：

l                内容测试。包括整体审美、字体、色彩、拼写、内容准确性和默认值

l          Web站点结构。包括无效的链接或图形。

l          用户环境。包括web浏览器版本和操作系统配置

业务层测试：

Ø         性能测试。测试的目的在于检查应用系统是否满足书面的性能规格说明（通常定义为响应时间和吞吐率）

Ø         数据有效性测试。测试的目的在于发现从客户那里采集到的数据的错误。

Ø         事务测试。测试的目的在于发现事务处理过程中的错误，事务测试必须有据可依，即具备书面文档详细定义事务的构成。

数据层测试：

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

1．         决定BUG严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，可以设定1－10分，每两分为一个层次可以依照如下划分：

ü          Blocker：阻碍开发和/或测试工作

ü          Critical：逻辑错误，丢失数据，内存溢出

ü          Major： 主要的功能缺陷？

ü          Minor： 次要的功能缺陷？

ü          Trivial：产品外观上的问题或一些不影响使用的小毛病，如菜单或对话框中的文字拼写或字体问题等等，页面交互性问题

2．         决定BUG优先级的时候，可以先假设不修复该Bug，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定bug的优先性。

3．         容易产生Bug的情况

ü          虽然在开发过程中，软件需求通常都会发生改动，但是，如果某一部分的软件需求频繁发生变动，那么就会导致和这部分软件需求相关的编码和设计频繁变动，那么在测试中，这部分编码设计实现的产品出现bug的可能性就很大。

ü          如果根据测试需求设计的某个测试用例描述的业务非常复杂，并且和其他的业务之间也有非常复杂的关系，那么可以判定设计和编码实现也会非常复杂，那么该部分出现bug的可能性也非常大

ü          如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现bug的可能性就很大，尤其是这些第三方组件使用者很少而且没有通过严格的认证的情况下。

4．         于测试的工作用时间的估算，可以参照公司过去的经验，根据公司以前的测试计划或测试报告，查看和目前从事的测试对象相仿的产品，查看测试该产品的参与者有多少，工作用时多少，单位效率如何，根据这些可以大致的估算出工作用时来，但是，并不是说估计的工作用时就能保证完全正确，因为在实际的工作当中会出现很多意外的情况，而且，工作用时的估计也需要有丰富的工作经验，所以，如果工作用时估计不精确，也是可以接受的。

5．         功能性测试需求表述的是对于系统中描述的功能性行为有哪些地方需要测试，这部分内容可以在项目早期就通过对软件需求规约和用例的分析获得，一般来说，一个明确要求的功能性特性可以生成一条测试需求，用例中基本流或基本流通某些备选流的组合也可以生成一条测试需求，另外，如果用例之间有相关性和依赖性，这多个用例间的不同联系也可以分别生成一条测试需求。

6．         如何根据频频变更的软件需求确定测试需求

        采用的是软件需求的版本化管理，指在一个软件产品进行新版本的迭代时，尽早确定这个版本中所包含的需求。 就自己某前测试的项目ODD，来说，这个项目没有软件需求，因为这个项目是对现有产品的升级，是基于现有产品进行开发的，因为Mymiles方面的新要求，或者房源查询数据接口的变化，这个项目的软件需求发生了很大的变动，在已经测试的B9，B10版本中有包含的某些功能可能在新版本中会取消，在新版本中又会添加新的功能。在这种情况下，作为这个项目的测试人员，就应该尽早确定这次新版本中包含的需求，然后和上次测试的版本进行比较，哪些内容是新增的，哪些内容是被调整过的，哪些内容是在新版本中取消的等等，当确定了这些内容以后，也就获得了新的软件需求，然后再确定测试需求。

7．         测试需求的整理

        测试需求的整理是明确现在要“测什么”，软件需求确定以后，根据软件需求规约，软件需求用例，从文档对软件特性和软件业务流程的描述中获得软件所设涉及的业务的一个基本认识，比如用户的实际业务是怎么进行的？实现这些业务需要什么约束条件，这些约束条件对实现业务的影响是什么？多个业务之间是否存在相互的关系，如果存在相互的关系，这些相互关系对处于这些关系中的业务又什么影响等。通过这些业务的分析，可以获得最初的一些测试需求。等开发部门的架构设计文档和详细设计文档出来以后，可以根据这些文档，对已有的测试需求进行增补，在执行测试的时候，如果发现在测试需求中没有包含的内容，则对这部分内容，也要整理添加到测试需求当中。

8．         测试需求的可测试性

测试需求的可测试性指的是，对于一条软件需求或者一个需要实现的特性，必须存在一个可以明确预知的结果，并且可以通过设计一个可以重复的过程来对这个明确的结果进行验证，即，要保证所有的需要实现的需求在最终实现后，都可以用某中方法来明确的判断是否符合需求文档中的要求。

9．         测试用例设计的有效功能

有效功能是指在被测应用所设计的实际业务中，当用户在原始状态下进行工作时，整个业务流程对用户来说具有实际意义的功能，当把这个功能单独从计算机软件还原到用户的原始手工状态时，它的完成可以作为用户实际业务的一个阶段性结束的标志，而不是一旦从这个业务流程中独立出来就没有了意义。而在该业务完成以后，可以为其他用户或业务提供所需要的信息。比如，财务软件中，用户填写一张会计凭证的是，它利用软件的功能，从备选会计科目中选择一个会计科目，这个功能就不是一个有效功能，因为在原始状态下，这个功能对用户来说没有什么实际的意义。但是，添加会计凭证这个功能就是一个有效功能。

对于相互之间存在数据或状态依赖的有效功能，要注意将他们剥离到不同的测试用例中。

10．  试用例常用设计方法

Ø         填写操作列表：将在软件上操作的步骤记录下来，包括所有被操作的项目和相应的值，这种方法的又是在于可以清晰的表达对于一条确定的测试用例的测试思路。比如可以利用操作步骤设计测试用例，测试常见的用户登录框用户正常登录功能、

Ø         填写测试数据矩阵：将被操作项作为矩阵的一个字段，而矩阵中的一条条记录，则是这些字段的值，利用这个方法，可以存放测试数据，特别是操作步骤相同，知识赋予属性的值不同的情况，比如可以利用测试数据矩阵，编写测试用例，将用户不能输入错误用户名和密码的情况以数据记录的形式存放在测试矩阵中。

11．  测试用例的设计并不是简单的把在应用程序上具体的操作的繁琐的步骤记录下来，因为通过这样的方式设计的测试用例，维护起来是十分庞大和复杂的，当需求中软件的某个特性发生变动时，为这个特性每个可能的值设计的测试用例都要进行修改，可以想象，修改这样的测试用例是多么的困难。所以，在测试用例设计的时候，要关注测试思想，而不是关注测试步骤，将测试者应该遵循的操作过程单独描述，然后，将针对这个测试用例的输入数据和输出数据单独写出来，这样，就不用再对原本多个用例中重复出现的操作步骤过程再次描述，可以把更多的精力放在测试数据的设计和准备上。当软件需求发生变更时，只需要对操作过程维护一次，再添加或调整测试数据就可以了

12．  准备有效的测试数据

        准备有效的测试数据，要从这个业务流程中最下游的业务开始考虑，找到实现它的所有输出所需要的所有输入，包括那些它所不能接受或无法处理的输入。当然，这些输入都来自于它的之间的上游业务。继续这种方法向上迭代，找出实现它的直接上游业务的所有输出所需要的所有输入。直至到达整个业务流程的最上游，也就是启动整个业务流程的第一个业务。

        对于测试用例的执行顺序的安排，同样是充分利用了多个业务之间的相关性和依赖性，再执行测试用例时，尽可能的将存在相互对照意义或者直接联系的内容安排再一个顺序中执行，并尽量在执行一个测试用例的时候检查更多的内容。

13．    描述bug主题时，应当根据实际情况，简要的描述出自己的操作和希望被重视的现象，不应该包含自己对异常表现出现的原因的推测和猜想。

14．  不能假设开发人员对他们开发的程序都十分熟悉，在提交bug的是，一定要说明白是哪个模块的哪个功能，出现了哪种类型的错误，并且，如果需要，应该把需求种关于该部分的描述写出来。

SQL语句先前写的时候，很容易把一些特殊的用法忘记，我特此整理了一下SQL语句操作。
一、基础
1、说明：创建数据库
CREATE DATABASE database-name
2、说明：删除数据库
drop database dbname
3、说明：备份sql server
--- 创建 备份数据的 device
USE master
EXEC sp_addumpdevice 'disk', 'testBack', 'c:\mssql7backup\MyNwind_1.dat'
--- 开始 备份
BACKUP DATABASE pubs TO testBack
4、说明：创建新表
create table tabname(col1 type1 [not null] [primary key],col2 type2 [not null],..)
根据已有的表创建新表：
A：create table tab_new like tab_old (使用旧表创建新表)
B：create table tab_new as select col1,col2... from tab_old definition only
5、说明：删除新表
drop table tabname
6、说明：增加一个列
Alter table tabname add column col type
注：列增加后将不能删除。DB2中列加上后数据类型也不能改变，唯一能改变的是增加varchar类型的长度。
7、说明：添加主键： Alter table tabname add primary key(col)
说明：删除主键： Alter table tabname drop primary key(col)
8、说明：创建索引：create [unique] index idxname on tabname(col....)
删除索引：drop index idxname
注：索引是不可更改的，想更改必须删除重新建。
9、说明：创建视图：create view viewname as select statement
删除视图：drop view viewname
10、说明：几个简单的基本的sql语句
选择：select * from table1 where 范围
插入：insert into table1(field1,field2) values(value1,value2)
删除：delete from table1 where 范围
更新：update table1 set field1=value1 where 范围
查找：select * from table1 where field1 like '%value1%' ---like的语法很精妙，查资料!
排序：select * from table1 order by field1,field2 [desc]
总数：select count as totalcount from table1
求和：select sum(field1) as sumvalue from table1
平均：select avg(field1) as avgvalue from table1
最大：select max(field1) as maxvalue from table1
最小：select min(field1) as minvalue from table1
11、说明：几个高级查询运算词
A： UNION 运算符
UNION 运算符通过组合其他两个结果表（例如 TABLE1 和 TABLE2）并消去表中任何重复行而派生出一个结果表。当 ALL 随 UNION 一起使用时（即 UNION ALL），不消除重复行。两种情况下，派生表的每一行不是来自 TABLE1 就是来自 TABLE2。
B： EXCEPT 运算符
EXCEPT 运算符通过包括所有在 TABLE1 中但不在 TABLE2 中的行并消除所有重复行而派生出一个结果表。当 ALL 随 EXCEPT 一起使用时 (EXCEPT ALL)，不消除重复行。
C： INTERSECT 运算符
INTERSECT 运算符通过只包括 TABLE1 和 TABLE2 中都有的行并消除所有重复行而派生出一个结果表。当 ALL 随 INTERSECT 一起使用时 (INTERSECT ALL)，不消除重复行。
注：使用运算词的几个查询结果行必须是一致的。
12、说明：使用外连接
A、left outer join：
左外连接（左连接）：结果集几包括连接表的匹配行，也包括左连接表的所有行。
SQL: select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
B：right outer join:
右外连接(右连接)：结果集既包括连接表的匹配连接行，也包括右连接表的所有行。
C：full outer join：
全外连接：不仅包括符号连接表的匹配行，还包括两个连接表中的所有记录。
二、提升
1、说明：复制表(只复制结构,源表名：a 新表名：b) (Access可用)
法一：select * into b from a where 1<>1
法二：select top 0 * into b from a
2、说明：拷贝表(拷贝数据,源表名：a 目标表名：b) (Access可用)
insert into b(a, b, c) select d,e,f from b;
3、说明：跨数据库之间表的拷贝(具体数据使用绝对路径) (Access可用)
insert into b(a, b, c) select d,e,f from b in '具体数据库' where 条件
例子：..from b in '"&Server.MapPath(".")&"\data.mdb" &"' where..
4、说明：子查询(表名1：a 表名2：b)
select a,b,c from a where a IN (select d from b ) 或者: select a,b,c from a where a IN (1,2,3)
5、说明：显示文章、提交人和最后回复时间
select a.title,a.username,b.adddate from table a,(select max(adddate) adddate from table where table.title=a.title) b
6、说明：外连接查询(表名1：a 表名2：b)
select a.a, a.b, a.c, b.c, b.d, b.f from a LEFT OUT JOIN b ON a.a = b.c
7、说明：在线视图查询(表名1：a )
select * from (SELECT a,b,c FROM a) T where t.a > 1;
8、说明：between的用法,between限制查询数据范围时包括了边界值,not between不包括
select * from table1 where time between time1 and time2
select a,b,c, from table1 where a not between 数值1 and 数值2
9、说明：in 的使用方法
select * from table1 where a [not] in ('值1','值2','值4','值6')
10、说明：两张关联表，删除主表中已经在副表中没有的信息
delete from table1 where not exists ( select * from table2 where table1.field1=table2.field1 )
11、说明：四表联查问题：
select * from a left inner join b on a.a=b.b right inner join c on a.a=c.c inner join d on a.a=d.d where .....
12、说明：日程安排提前五分钟提醒
SQL: select * from 日程安排 where datediff('minute',f开始时间,getdate())>5
13、说明：一条sql 语句搞定数据库分页
select top 10 b.* from (select top 20 主键字段,排序字段 from 表名 order by 排序字段 desc) a,表名 b where b.主键字段 = a.主键字段 order by a.排序字段
14、说明：前10条记录
select top 10 * form table1 where 范围
15、说明：选择在每一组b值相同的数据中对应的a最大的记录的所有信息(类似这样的用法可以用于论坛每月排行榜,每月热销产品分析,按科目成绩排名,等等.)
select a,b,c from tablename ta where a=(select max(a) from tablename tb where tb.b=ta.b)
16、说明：包括所有在 TableA 中但不在 TableB和TableC 中的行并消除所有重复行而派生出一个结果表
(select a from tableA ) except (select a from tableB) except (select a from tableC)
17、说明：随机取出10条数据
select top 10 * from tablename order by newid()
18、说明：随机选择记录
select newid()
19、说明：删除重复记录
Delete from tablename where id not in (select max(id) from tablename group by col1,col2,...)
20、说明：列出数据库里所有的表名
select name from sysobjects where type='U'
21、说明：列出表里的所有的
select name from syscolumns where id=object_id('TableName')
22、说明：列示type、vender、pcs字段，以type字段排列，case可以方便地实现多重选择，类似select 中的case。
select type,sum(case vender when 'A' then pcs else 0 end),sum(case vender when 'C' then pcs else 0 end),sum(case vender when 'B' then pcs else 0 end) FROM tablename group by type
显示结果：
type vender pcs
电脑 A 1
电脑 A 1
光盘 B 2
光盘 A 2
手机 B 3
手机 C 3
23、说明：初始化表table1
TRUNCATE TABLE table1
24、说明：选择从10到15的记录
select top 5 * from (select top 15 * from table order by id asc) table_别名 order by id desc
三、技巧
1、1=1，1=2的使用，在SQL语句组合时用的较多
"where 1=1" 是表示选择全部   "where 1=2"全部不选，
如：
if @strWhere !=''
begin
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where ' + @strWhere
end
else
begin
set @strSQL = 'select count(*) as Total from [' + @tblName + ']'
end
我们可以直接写成
set @strSQL = 'select count(*) as Total from [' + @tblName + '] where 1=1 安定 '+ @strWhere
2、收缩数据库
--重建索引
DBCC REINDEX
DBCC INDEXDEFRAG
--收缩数据和日志
DBCC SHRINKDB
DBCC SHRINKFILE
3、压缩数据库
dbcc shrinkdatabase(dbname)
4、转移数据库给新用户以已存在用户权限
exec sp_change_users_login 'update_one','newname','oldname'
go
5、检查备份集
RESTORE VERIFYONLY from disk='E:\dvbbs.bak'
6、修复数据库
ALTER DATABASE [dvbbs] SET SINGLE_USER
GO
DBCC CHECKDB('dvbbs',repair_allow_data_loss) WITH TABLOCK
GO
ALTER DATABASE [dvbbs] SET MULTI_USER
GO
7、日志清除
SET NOCOUNT ON
DECLARE @LogicalFileName sysname,
        @MaxMinutes INT,
        @NewSize INT

USE     tablename             -- 要操作的数据库名
SELECT  @LogicalFileName = 'tablename_log',  -- 日志文件名
@MaxMinutes = 10,               -- Limit on time allowed to wrap log.
        @NewSize = 1                  -- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size
  FROM sysfiles
  WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' +
        CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' +
        CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
  FROM sysfiles
  WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
  (DummyColumn char (8000) not null)

DECLARE @Counter   INT,
        @StartTime DATETIME,
        @TruncLog  VARCHAR(255)
SELECT  @StartTime = GETDATE(),
        @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time has not expired
      AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = @LogicalFileName) 
      AND (@OriginalSize * 8 /1024) > @NewSize 
  BEGIN -- Outer loop.
    SELECT @Counter = 0
    WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
      BEGIN -- update
        INSERT DummyTrans VALUES ('Fill Log') 
        DELETE DummyTrans
        SELECT @Counter = @Counter + 1
      END  
    EXEC (@TruncLog) 
  END  
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
        CONVERT(VARCHAR(30),size) + ' 8K pages or ' +
        CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
  FROM sysfiles
  WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
8、说明：更改某个表
exec sp_changeobjectowner 'tablename','dbo'
9、存储更改全部表
CREATE PROCEDURE dbo.User_ChangeObjectOwnerBatch
 @OldOwner as NVARCHAR(128),
 @NewOwner as NVARCHAR(128)
AS
DECLARE @Name   as NVARCHAR(128)
DECLARE @Owner  as NVARCHAR(128)
DECLARE @OwnerName  as NVARCHAR(128)
DECLARE curObject CURSOR FOR
 select 'Name'   = name,
  'Owner'   = user_name(uid)
 from sysobjects
 where user_name(uid)=@OldOwner
 order by name
OPEN  curObject
FETCH NEXT FROM curObject INTO @Name, @Owner
WHILE(@@FETCH_STATUS=0)
BEGIN    
 if @Owner=@OldOwner
 begin
  set @OwnerName = @OldOwner + '.' + rtrim(@Name)
  exec sp_changeobjectowner @OwnerName, @NewOwner
 end
-- select @name,@NewOwner,@OldOwner
 FETCH NEXT FROM curObject INTO @Name, @Owner
END
close curObject
deallocate curObject
GO

10、SQL SERVER中直接循环写入数据
declare @i int
set @i=1
while @i<30
begin
   insert into test (userid) values(@i)
   set @i=@i+1
end
小记存储过程中经常用到的本周，本月，本年函数
Dateadd(wk,datediff(wk,0,getdate()),-1)
Dateadd(wk,datediff(wk,0,getdate()),6)
Dateadd(mm,datediff(mm,0,getdate()),0)
Dateadd(ms,-3,dateadd(mm,datediff(m,0,getdate())+1,0))
Dateadd(yy,datediff(yy,0,getdate()),0)
Dateadd(ms,-3,DATEADD(yy, DATEDIFF(yy,0,getdate())+1, 0))
上面的SQL代码只是一个时间段
Dateadd(wk,datediff(wk,0,getdate()),-1)
Dateadd(wk,datediff(wk,0,getdate()),6)
就是表示本周时间段.
下面的SQL的条件部分,就是查询时间段在本周范围内的:
Where Time BETWEEN Dateadd(wk,datediff(wk,0,getdate()),-1) AND Dateadd(wk,datediff(wk,0,getdate()),6)
而在存储过程中
select @begintime = Dateadd(wk,datediff(wk,0,getdate()),-1)
select @endtime = Dateadd(wk,datediff(wk,0,getdate()),6)

5．优化配置

通过以上步骤，可以成功进入testlink页面，首先需要创建一个产品，才可以进入testlink主页。进入testlink主页后，页面为英文，需要在菜单栏中的Personal中更改admin默认的语言，选择“Chinese silmpified”

此时，testlink界面部分内容依旧为英文，原因是汉化文件不完整，需要重新汉化，

汉化方法：

下载utf8版本的strings.txt替换testlink\locale\zh_CN目录下的strings.txt即可完成汉化

下载网址：http://testlink.5d6d.com/thread-1-1-1.html

此时，testlink里面日期会有乱码，需要修改testlink下cfg文件夹下的testlinkconst.inc.php文件，修改方法如下：

打开 testlinkconst.inc.php文件

查找'zh_CN' => "%Y锟斤拷%m锟斤拷%d锟斤拷 %H时%M锟斤拷%S锟斤拷"

修改为：'zh_CN' => "%Y-%m-%d %H:%M:%S"

6．和bugzilla集成

前提条件：

1．     Bugzilla安装完成

2．     如果是bugzilla和testlink不在同一服务器，需要远程访问bugzilla数据库的帐户

集成配置：

1．    打开testlink下config.inc.php文件

查找$g_interface_bugs='NO';

修改为$g_interface_bugs='BUGZILLA';

注意：一定要大写BUGZILL

2．    打开testlink下cfg文件夹下的bugzilla.cfg.php文件夹，做如下修改

 

//Set the bug tracking system Interface

/** The DB host to use when connecting to the Bugzilla db */

define('BUG_TRACK_DB_HOST', '192.168.0.77');

说明：安装bugzilla的服务器地址

/** The name of the database that contains the Bugzilla tables */

define('BUG_TRACK_DB_NAME', 'bug');

说明：bugzilla的数据库名称

/** The DB type being used by Bugzilla */

define('BUG_TRACK_DB_USER', 'mysql');

说明：访问bugzilla数据库的帐户

/** The DB password to use for connecting to the Bugzilla db */

define('BUG_TRACK_DB_PASS', '123456');

说明：访问bugzilla数据库的密码

/** The DB type to use for connecting to the bugtracking db */

define('BUG_TRACK_DB_TYPE', 'mysql');

/** link of the web server */

define('BUG_TRACK_HREF', "http://192.168.0.77/cgi-bin/index.cgi/show_bug.cgi?id=");

说明：bugzilla访问地址＋/show_bug.cgi?id=

/** link to the bugtracking system, for entering new bugs */

define('BUG_TRACK_ENTER_BUG_HREF',"http://192.168.0.77/cgi-bin/index.cgi/");

说明：bugzilla访问地址

?>

注意：以上标记为“说明”的是我自己增加的说明性文字。

修改完成后，如果bugzilla可以访问到，则在testlink下，执行测试的时候，每个执行结果记录后，都会有一个小虫子标记，如果某个测试用例执行失败，在bugzilla提交相关bug后，在testlink中点击该小虫子标记，可以填写bugzilla中的bug号。然后，会在执行结果中显示该bug号，点击bug号，则可以直接链接到bugzilla中提交的bug。

注意：testlink使用方法不在这里说明。

 

说明：

1． 修改内容用红色标记。

2． 次文档参考部分网络资源，但是无法确认原作者，没有在此处说明，请作者原谅

3． 此文档是在windows下安装配置

1. 安装Apache 2.2.3

  运行安装文件，注意仿照下面的例子填写网站信息：

  域名：3322.org

  网站名：tonyhook.3322.org

  管理员信箱：tonyhook@3322.org

  选择自定义安装，安装完成后，访问http://127.0.0.1/

  出现“It works!”的默认主页。

 注意：安装完毕后，访问http://127.0.0.1/，可能不会出现“It works!”的默认主页，主要原因是没有将Apache 2.2.3启动，重新启动Apache 2.2.3，就可以了。

 

2. 安装MySQL 5.0.27

  运行安装文件，选择完全安装，跳过创建MySQL.com帐户，最后选择立刻配置MySQL服务器。

  配置过程：

（1）选择标准配置，下一步；

（2）安装为Windows服务，服务名称MySQL，下一步

（3）更改管理员密码（例如设为12345678），下一步

（4）执行配置

 3. 安装PHP 5.2.0

  运行安装文件，无需改变默认安装位置（C:\Program Files\PHP），选择添加Apache 2.2.x服务器模块。

  选择Apache配置文件位置：C:\Program Files\Apache Software Foundation\Apache2.2\conf\

  一定添加扩展中的MySQL扩展！

  允许安装程序配置Apache。然后配置PHP：

（1）编辑C:\Program Files\PHP\php.ini文件

（2）查找如下两行：

        upload_tmp_dir="C:\DOCUME~1\Administrator\LOCALS~1\Temp\php\session"
        session.save_path="C:\DOCUME~1\Administrator\LOCALS~1\Temp\php\upload"

      更改为：

        upload_tmp_dir="C:\Windows\TEMP"

        session.save_path="C:\Windows\TEMP"

 

        ;extension=php_mysql.dll

      去掉前面的分号，更改为：

        extension=php_mysql.dll

（3）编辑文件test.php，共3行，存放在C:\Program Files\Apache Software Foundation\Apache2.2\htdocs，内容如下：

<?php

phpinfo();

?>

（4）重新启动Apache，访问http://127.0.0.1/test.php，可以查看PHP的安装情况

 注意：Apache一定要重新启动，不然只显示步骤3配置的文件test.php的内容。

4. 安装TestLink 1.7R3

（1）将TestLink解压缩到C:\Program Files\Apache Software Foundation\Apache2.2\htdocs，重新命名为testlink

（3）访问http://127.0.0.1/testlink/install/index.php

（4）点击New Installation

（5）数据库管理员填写root及root的密码（先前的设定为12345678），数据库用户名填写tl，密码填写123456

（6）点击安装按钮，然后同意许可协议，继续

（7）安装完成，点击最后一行的(Please Click Me!)

（8）使用admin登录，密码：admin

（9）在菜单栏中的Personal中更改admin的密码，更改成功后在右上角点击注销

（10）删除C:\Program Files\Apache Software Foundation\Apache2.2\htdocs\testlink\install目录

（11）访问http://127.0.0.1/testlink/index.php即可使用出现TestLink登陆界面，此时登陆界面为英文，如果需要修改为中文则按以下步骤操作

打开testlink下cfg文件夹下的config.inc.php文件

查找$g_default_language = 'en_GB';

修改为

$g_default_language = 'zh_CN';

则可以解决登陆界面汉化的问题

注意：如果在步骤8之前出现错误提示信息，则需要重新启动电脑。

 

3．      修改

 (1) 修改按钮可用，测试点击修改按钮，能够进入相应的修改页面。

可能存在的bug：

ü          点击“修改”按钮，程序无反应，无法进行修改操作。

ü          点击“修改”按钮，程序跳转到其他页面

(2) 进入修改页面，验证信息内容和添加时输入一致

        可能存在的bug：

ü          修改页面，信息内容丢失部分数据信息

(3) 执行相关修改操作，验证方式同添加，因为一般修改和添加内容基本类似

(4) 保存修改内容，

可能存在的bug：

ü          保存按钮无反应，修改操作不可操作

ü          程序无是否保存确认提示信息

ü          程序无是否保存成功提示信息

     （5）重新查询修改后的内容

ü          程序提示保存成功，但是重新查询，依旧显示修改之前的内容

ü          程序将修改结果保存为另外的数据记录

4．      删除

      删除操作应该验证删除一条数据记录，删除多条数据记录，删除全部数据记录，查看删除是否成功，删除后，在数据库中是否也删除了，删除后，是否可以添加同样的数据记录。

可能存在的bug：

ü          删除按钮无反应，删除操作不可操作

ü          删除无是否删除确认信息

ü          删除是否成功无提示信息

ü          无法删除数据

ü          可以删除其他地方调用的数据记录

关于数据的查询，添加，修改，删除操作，测试工作当中经常会出现，如何高效的执行这几个功能模块的测试是每一个测试人员需要考虑的问题，也许不同的测试员有不同的测试方法，以下为我个人总结的关于查询，添加，修改，删除操作的测试方法。

测试过程以序号标识！

1．      添加

(1) 添加按钮可用，测试点击添加按钮，能够进入相应的添加页面。

可能存在的bug：

ü          点击“添加”按钮，程序无反应，无法进行添加操作。

ü          点击“添加”按钮，程序跳转到其他页面

     (2) 进入添加页面，验证输入字段和需求描述一致

               可能存在的bug：

ü          输入字段出现错别字

ü          输入字段丢失或者多于，程序丢失需求规约的输入字段或者程序出现需求没有规约的输入字段

ü          输入字段输入方式和需求描述不一致，比如，需求规约为下拉列表，程序为文本框

     (3) 所有输入字段输入合法数据，点击保存按钮，系统应该有保存成功提示信息，在数据库中有新保存的数据，通过查询页面，也可以查询到添加的数据。

               可能存在的bug：

ü          程序把合法数据当作非法数据处理

ü          点击保存，没有保存是否成功提示信息

ü          数据库中没有新添加的数据记录

ü          数据库中有添加的数据，但是通过程序查询操作，无法查询到新添加的数据记录

     (4) 重新进入添加页面，所有字段输入有效数据，然后从第一个字段开始，依次验证每个输入字段如下内容。之所以是从第一个输入字段开始依次验证每个输入字段，是因为这样可以保证不遗漏任意一个字段，同时也可以节省测试时间，每次只需改变两个输入字段的输入内容，不用每一次都要将每个输入字段都输入。

l          非法数据，根据测试用例中的设计的非法测试数据，验证对每个非法测试数据程序都能控制

可能存在的bug：

ü          程序对非法数据没有控制，输入非法数据可以通过验证

ü          程序对非法数据的提示信息错误（包括是否缺少，准确性，可理解性，一致性）

l          编辑数据，根据测试用例中的设计的编辑测试数据，验证对每个编辑测试数据程序都能控制

可能存在的bug：

ü          程序不能处理编辑数据，比如粘贴一个数据，程序认为数据没有输入

ü        程序对编辑数据处理错误，比如，按back键删除部分数据，程序依旧保存全部数据

ü          程序对编辑数据的提示信息错误（包括是否缺少，准确性，可理解性，一致性）

l          空数据，如果需求规定输入字段不能为空，验证程序对非空数据有明显标识或说明，对非空输入字段输入空数据有控制

可能存在的bug：

ü          程序对非空输入字段无明显标识或说明

ü          程序对非空输入字段无限制，非空输入字段输入空数据，程序可以通过验证

ü          程序对空数据的提示信息错误（包括是否缺少，准确性，可理解性，一致性）

l          重复数据，如果需求规定输入字段不能输入重复数据，验证程序对重复数据有控制

可能存在的bug：

ü          程序对重复数据无控制，可以输入重复数据，并有可能引发程序崩溃

ü          程序对重复数据的提示信息错误（包括是否缺少，准确性，可理解性，一致性）

2．      查询

(1) 进入查询页面，验证输入字段和需求描述一致

        可能存在的bug：

ü          查询条件输入，查询结果输出字段出现错别字

ü          查询条件输入，查询结果输出字段丢失或者多于，程序丢失需求规约的查询条件输入，查询结果输出字段或者程序出现需求没有规约的查询条件输入，查询结果输出字段。

ü          查询条件输入输入方式和需求描述不一致，比如，需求规约为下拉列表，程序为文本框，查询结果输出方式和需求规约的不一致

(2)     查询功能验证，通过查询全部数据，根据单条查询条件查询，组合查询，模糊查询，错误的查询，验证程序查询功能正确。

l          查询全部数据记录，除非特殊要求，系统应该有查询全部数据记录的查询方式，验证通过查询全部查询的结果和数据库中全部的数据记录相同

可能存在的bug：

ü          无法通过程序设计的查询条件查询到全部的数据记录

ü          点击查询按钮后查询不到任何的数据

ü          通过查询功能查询到的数据记录个数和通过数据库查询的数据记录个数不符合

l          根据单条查询条件查询，根据每个查询条件，可以查询到符合查询条件的数据记录

可能存在的bug：

ü          点击查询按钮后查询不到任何的数据

ü          查询结果返回数据和查询条件不符合

ü          通过查询功能查询到的数据记录个数和通过数据库查询的数据记录个数不符合

l          组合查询，组合不同的查询条件，查询数据记录

可能存在的bug：

ü          点击查询按钮后查询不到任何的数据

ü          查询结果返回数据和查询条件不符合

ü          通过查询功能查询到的数据记录个数和通过数据库查询的数据记录个数不符合

l          模糊查询，有些查询条件，程序提供了模糊匹配的功能，验证模糊查询正确

可能存在的bug：

ü          点击查询按钮后查询不到任何的数据

ü          程序没有实现模糊匹配的查询功能

l          错误的查询条件，输入错误的查询条件，验证系统是否能够正确处理

可能存在的bug：

ü          点击查询按钮后程序无任何反应

ü          程序刷新页面，不返回查询结果，但是无任何明确的说明信息

(3) 对查询条件的输入进行验证，验证方式同添加操作验证方式相同，但是要注意以下几个方面。

l          需求对所有查询条件输入都有明确限制条件。根据需求规约的限制，验证程序对所有输入限制都做了相应处理。

可能存在的bug（验证相关bug和添加验证类似，在这里不做说明）：

ü          对同一字段，添加限制和查询限制不一致，添加可以输入的数据，查询不可以输入，无法查询到添加的数据记录

l          需求对部分输入条件没有限制，应该和开发人员协调，获得没有限制字段的限制条件，如果最终对输入条件无限制，则应该对特殊字符进行验证。

可能存在的bug

ü          对有限制条件的同一字段，添加限制和查询限制不一致，添加可以输入的数据，查询不可以输入，无法查询到添加的数据记录

ü          输入特殊字符，点击查询按钮，程序报错

ü          输入特殊字符，点击查询按钮，查询页面显示乱码

ü          输入特殊字符“_”，程序返回所有查询记录

l          需求对所有输入条件没有限制，应该和开发人员协调，获得没有限制字段的限制条件，如果最终对输入条件无限制，则应该对特殊字符进行验证。

可能存在的bug（同上）

利用两周时间，阅读了Ron Patton著的《软件测试》，这是一本讲解软件测试的入门书籍，本书借助Windows95/98和windowsNT/2000附带的计算器、记事本和写字板等常用的小应用程序介绍了软件测试的通用方法。本书内容，包括了软件测试的基础知识，软件测试的基本和高级的技术，自动化测试，外国语言测试，计划和编制测试目标，报告发现的问题，评估测试目标和产品进度，以及测试和质量认证的区别。可以说涵盖了测试的各个方面，虽然对每部分内容都是很少的篇幅，但是，本书却用浅显易懂的概念定义，简单实用的例子，将软件测试看似深奥的知识体系清晰明了的讲解出来，就算是对软件测试一点概念也没有的人，读过此书以后，也会对软件测试是什么，软件测试需要哪些技能，软件测试有哪些方法，软件测试流程，软件测试相关的文档等知识体系有一个系统的，感性的认识。

读过此书，使自己更清晰的认识到软件测试的理论体系，而在阅读的过程中，通过思考，能更透彻的理解软件测试知识，或者说，能够形成自己的一些理解，思考过后，还能知道自己需要延伸阅读的内容，这就是阅读此书的收获。这样说，似乎有点简单，分层次详细叙述如下。

    本书讲解的软件测试的知识都比较简单，很容易理解，但是，却涵盖了整个软件相关的知识体系，而且，本书对软件相关的概念定义清晰明白，而且比较权威，通过阅读本书，自己以前不能够理解的，或者理解偏差的关于软件测试的概念，都有了完整的认知，关于这个方面可以简单的举一个例子。

此书关于软件缺陷的定义认为，符合下边5个规则的才能叫做软件缺陷。

1.软件未达到产品说明书标明的功能。

2.软件出现了产品说明书指明不会出现的错误。

3.软件功能超出产品说明书指明范围。

4.软件未达到产品说明书虽未指出但应达到的目标。

5.软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。

     关于软件测试，很多书籍都是从软件质量的角度去阐述的，认为，软件如果正确实现了它所要求的功能，并且用户对该软件是满意的，那么该软件就是满足质量要求的，然后根据这个延伸来定义软件缺陷的。但在，在这里，关于软件缺陷的定义，却能够详细的将每一种情况都考虑到，无论怎么定义软件质量，只要软件当中出现了以上规则中的任意一条，则可以认为该软件是有缺陷的，如此，测试人员对软件缺陷就会有一个清晰的认知，而不会因为对软件缺陷的定义不同而出现不是缺陷的缺陷，或者遗留缺陷。

     本书解决了自己认知模糊，或者说，认知不清晰的关于软件测试的知识，主要有如下内容。

1．     软件测试原则

以前对软件测试原则没有概念，但是，通过阅读该书，知道了软件测试的一些原则。

1. 完全测试是不可能的。因为：A.输入量太大；B.输出结果太多；C.软件实现途径太多；D.软件说明书没有客观标准。从不同角度看，软件缺陷标准不同。

2. 软件测试是有风险行为。

3. 测试无法显示潜伏的软件缺陷。

4. 找到的软件缺陷越多，就说明软件缺陷越多。

5. 用一种药，害虫都有抵抗力，程序也如此，如在螺旋开发模式中，每一个轮回都会对软件进行测试，几回合后，该发现的都发现了，找不到什么错误了。这要求我们必须不断编写不同的新测试程序，对程序的不同部分进行测试，以找到更多的缺陷。

6. 并非所有的软件缺陷都能修复：A.没有足够的时间；B.不算真正的缺陷；C.修复风险太大；D.不值得修复

7. 难以说清的软件缺陷

8. 产品说明书不断变化：软件测试员必须想到产品说明书可能改变。

9. 测试员做的工作不受欢迎，因为工作就是挑错！所以我们要懂得怎么和开发的相处：A.早点找出缺陷；B.控制情绪；C.多交流，不要总是报告坏消息。

10. 软件测试是一项讲究条理的技术专业。

在以上关于软件测试的原则当中，有些内容，我是知道的，比如不能完全测试，测试员做的工作不受欢迎等，但是，对这些原则的认识却不是在软件测试实质这个内容体系当中认知的，而是在阅读与软件测试相关文章的时候，孤立的认识的，这样孤立的认识，对软件测试并没有什么实质的内容，因为，就算不是从事软件测试的人，也大概知道这些内容。在本书中，作者以单独的一章详细的介绍了软件测试的实质，说明了测试的原则，可以说是对软件测试员的一个提纲性的指导，明确了软件测试人员在测试的时候需要注意的内容，也使得软件测试人员知道了软件测试中哪些能测，哪些不能测，哪些重点测，哪些不用测，这是很多关于软件测试的书中无法企及的。

2．     数据测试

本书在关于黑盒测试方法的讲解中，并没有单独去讲解每一种测试方法，而是将这些测试方法结合到以前讲解，因为在实际的测试当中，也不是孤立的去使用一种测试方法，而是多种测试方法结合使用。

本书以软件测试中的数据测试为讲解对象，讲解了数据测试中，关于边界值如何确定的很多方法，其中的很多细节都是我通过该书，才了解的，叙述如下。

测试边界线  次边界条件  2的乘方  ASCLL   默认、空白、空值、零值和无

         非法、错误、不正确的和垃圾数据

         这些关于边界值划分的细节当中，2的乘方  ASCLL，这两个内容在阅读书之前完全没有概念，但是通过此书的讲解，可以明白的理解，虽然这两个方法涉及到了程序相关的内容，但是，作为一个黑盒测试方法细节，能够开拓测试用例的设计方式。

3．     检查代码

检查代码是白盒测试的一个方法，自己虽然知道该方法，但是，检查代码的时候具体检查什么？作者给出来详细的列表，如下:

1.数据引用错误数据引用错误是指使用未经正确地初始化的变量、常量、数组、字符串或记录。

2.数据声明错误

数据声明错误是指不正确地声明或使用变量和常量。

3.计算错误

计算错误是指基本的数学逻辑问题。

4.比较错误

小于、大于、等于、不等于、真、假、比较和判断错误很可能是边界条件问题。

5.控制流程错误

控制流程错误是指编程语言中循环等控制结构未按预期方式工作，通常由计算或者比较错误直接或间接造成。

6.子程序参数错误

子程序参数错误的来源是软件子程序不正确地传递数据。

7.输入/输出错误

输入/输出错误包括文件读取、接受键盘或鼠标输入以及向输出设备写入错误等。

8.其他错误

这里仅仅列出了标题，作者对每个清单都有详细的描述，结合这个清单，测试员可以很明白的知道，在代码审查的时候该做什么。

4．     外国语言测试

关于外国语言测试，在以前的阅读当中并没有接触到，自己的理解单单就是翻译的问题，但是在本文中，作者不但给出了外国语言测试中，关于翻译应该测试的问题，还给出了本地化问题，配置和兼容问题的介绍，使得自己对外国语言测试有了了解，而且，可以在当前的工作当中，有意识的向这个方面考虑

5．     易用性测试

对于易用性测试每个人都有自己的理解，不能说是谁对谁错，作者却从细节问题上去描述，以清单的方式对关于易用性测试涉及到的内容进行描述，使得看过此书的人知道如何测试易用性，进行易用性测试要找什么，虽然很简单，但是，如果没有作者的描述，测试员对易用性的测试可能就完全按照自己想的去进行，错误和遗漏就在所难免了。

6．     文档测试

    包括文档测试的类型，文档测试的要点，文档测试的实质

7．     网站测试

       包括网站测试的方法，网站的配置和兼容性测试，网站的易用性测试

以上内容都是自己通过本书学习到的新知识，本书描述的其他知识，自己在以前的学习当中都有过了解和掌握，但是，在学习过程中，本书的学习缺十分的轻松，并不需要如何去思考，如何去理解，只要你看了作者的描述，那么你就可以理解作者所写的内容了。总结一下，作者能够如此简单明了的讲述知识体系，主要有以下几个独特的方法。

1．     提问

每章开始都有关于本章内容的重点介绍，重点内容介绍中很多并不是叙述而是提问，通过提问，引导读者思考，通过提问，读者就知道本章要解决哪些问题，而且，这样的提问方式，也是读者想要问的问题，作者把读者问的问题列出来，然后，在正文中，又以回答问题的方式回答，这样的一问一答式，却能使读者很好的理解文章。

2．     清单

软件测试的每个主题会细分为多个小主题，而每个小主题可能又会包含多个方面，而作者在讲解的时候，层层描述，结合前面讲解的提问方式，将各个主题所包含的所有内容都一一讲解，最重要的是，作者以清单的方式列出测试的每个方面，比如，关于网站易用性测试，作者将网站易用性测试涉及的各个方面以清单的方式列出，而阅读此书，就会发现几乎每一章都有这样的清单，通过清单，读者很容易知道对于这个主题，该做什么，不该做什么，重点做什么，一目了然。

     作者写书以这样的方式去写，那么在测试的时候我们也可以按照这样的方式去测，应该要测什么，测试的时候用什么方法，这些方法有什么优缺点，使用这些方法的时候有什么限制等等，然后给出这些问题的答案，通过这样的一问一答式，关于测试的各个方面都能够详细的考虑，然后，对每个测试的方面，都给出需要测试的清单，如此测试就是一个有条理的工作，就不会遗漏什么或者浪费什么。

     这只是我根据本书而对测试做的一些思考，在实际的时候，当然还是需要按照测试的流程来进行，其实，如果按照以上的方式来，也就是按照测试流程进行了。

当然，如果我需要写一些工作心得，写一些工作经验相关的文章，我也会借鉴作者的写作方式，将所描述的内容条理化，简单化。让读者愿意读，容易理解。

就实际来说，本书讲解的内容，对于没有从事过测试工作的人来说，是十分实用的，读过本书后，可以知道软件测试的概念，知道怎么去进行测试，知道测试的时候应该测试哪些内容，知道测试完以后还有哪些工作要去做。这本书相当于是一本指导书，指导你如何快速的进入软件测试这个工作当中，并能够完成测试工作。

但是，本书讲解的内容也有缺陷，通过本书的学习，你可以开始实际的测试工作了，这个测试工作是别人告诉你测试哪个软件，你可以利用本书讲解的内容去测试，如果没有人告诉你测试哪个软件，也就是说，如果没有具体的工作内容，也许你就不知道应该怎么去做了，我认为这就是本书的一个缺陷。

本书没有讲解风险评估的内容，而对于测试计划和测试用例讲解并没有明确告诉读者怎么去做，或许这不是本书的内容，因为这些都属于资深测试人员或者测试组长了解的内容。本书作为一个入门书，就是指导新手进入测试，完成测试，如果从这个方面来书，本书是成功的。

读过本书，知道了应该知道的内容，清晰了已经模糊的内容，了解了还需要加强的内容。做个总结，梳理一下，以后的工作当中就会有更明确的方向。

    在每次做测试之前，都应该对将要进行的测试进行说明，下面是一个迭代开发版本的测试说明。希望可以和大家探讨一下。

1． 版本：Build1（此处可以对测试版本进行一些简单的说明）

2． 测试对象：

Ø         机场模型 

Ø         航空公司模型

Ø         退签改模型

Ø         机型模型

主要功能：查询，添加，修改，删除，停启用

3． 测试策略

A 功能测试

Ø         查询：单独查询，组后查询，格式验证

Ø         添加：有效数据，无效数据，必填项验证，唯一性验证

Ø         修改：修改信息保存成功，修改信息不影响其他数据

Ø         删除：单条记录删除，多条记录删除

Ø         停启用：单条记录停启用，多条记录停启用

Ø         数据关联验证（数据字典的下拉列表，停用）

B 易用性测试

Ø         操作提示信息（是否缺少，准确性，可理解性,一致性）

Ø         输入限制提示信息（是否缺少，准确性，可理解性，一致性）

Ø         输入错误提示信息（是否缺少，准确性，可理解性，一致性）

Ø         页面一致性（中英文，字段排列，栏目名和页面名）

Ø         界面美观（输入超长字符变形）

C 权限测试

Ø         新建用户具有相应权限

Ø         权限控制按钮正确

4． 资源占用

     3个人日（如果有其他资源占用情况，可以在这里说明）

 

 

         测试进度安排是根据项目进度安排进行制定，要保证在项目进度安排允许的时间内完成测试任务，就需要详细的估算测试工作量，如果估算的测试工作量在项目进度规定时间内大于现有测试人员能够完成的限度，则应该向项目管理组反应，调整测试进度，或者增加测试人员，如果估算的测试工作量在项目进度规定时间内能够完成，则应该详细的安排测试任务，根据测试成员的特定安排测试任务。

        针对黑盒测试，估算工作量可以根据以下过程展开

 A．  将测试项目分解成不同的任务，结合EDS测试项目，可以将整个测试项目划分为三个任务，测试准备，测试执行，测试报告。

 B．  将每个阶段划分不同的子任务

 ü         测试准备：需求评审，测试计划编写，测试用例设计，测试脚本开发，测试环境搭键

ü         功能确认：bug验证，回归测试，新功能测试，

ü         测试报告：bug分析阶段，测试报告编写阶段，测试总结编写阶段

 C．  细化不同子任务的工作量，确定不同子任务之间的依赖关系

       考虑每个子任务完成需要的输入，输出，结合现有的测试资源，和测试人员沟通，为不同的测试人员分配不同的测试任务，并估算完成的时间。

       测试工作量估算完成后，输出如下表格，