在经过了漫长而又乏味的测试和郁闷之后,接下来就是应该让我们自己轻松下的时候了,为了让我们的精力更好,精神更充沛,信心饱满的去面对下一次的测试,我们也该享受下的.

在这里谈到享受大家可能想不就是物质(吃的喝的),外再加几个漂亮MM的(想这方面的就是色狼 呵呵).

其实对于我们测试人员而言上面谈到的都是其次的,而其主要的享受的还是对项目对我们自身的价值体现,测试完成后难免会和开发人员对自己测试的结果进行讨论:包括程序的错误而造成的缺陷;作为出色的测试人员对功能在实现上的意见(怎么样对系统会有更好的?怎么样会对系统更好的运行).

当开发人员或技术经理或项目经理对自己提出的意见面带笑容而且不停的点头的时候,自己的心里不知道是多么的高兴,这就是对我们测试人员的回报---------精神享受,技术允可!(其实这也是要成为一名优秀的测试人员应该必须友好有的技术素质之一!)

当然反过来我们也可以了解开发,开发也是博大精深的!了解开发人员在功能上是怎么实现的,怎么考虑的.我们也可以知道和学习开发人员在该功能上的思维方式,从而对照需求,或自己是否漏测.

从”鸡蛋碰石头”,想到的

在正常理论下,大家肯定有2种观点:

1.         是鸡蛋不如石头硬

2.         是鸡蛋碰向石头的同时给了石头太大的外力而使鸡蛋被砸坏

 

这2种观点从表面上看没有啥区别,因为导致最后的结果都一样:鸡蛋被砸坏了.

我们大家再仔细分析下,同意第一种观点的人,肯定是站在石头的角度去想问题,石头本来就比鸡蛋硬(而且硬很多),所以就理所当然的认为使石头硬(这是事实);同意第二种观点的人,肯定是这样想的:当鸡蛋砸向石头的时候,同时给石头很大的力,这样石头同时也会给鸡蛋一个同样大小的力,从而导致鸡蛋被砸坏.

其实我们只用知道一个不变的事实就可以了:最后坏的肯定是鸡蛋!

当我们站在测试的角度看这个问题的时候,那肯定是不一样的:虽然结果都是一样的,但是其中的过程是不一样的.(作为测试人员过程和结果都一样很重要,有时候过程还会更重要)

 现在我们以测试人员的身份来分析下这个现实:

同意第一种观点的人,就和开发人员的思维一样的,顺着需求把待测试的功能对比着测试一下就OK了.因为这时测试人员和开发人员走的同一条路,所以在之间就找不到他们的碰撞点或思维的交叉点,这样很多的错误(可能不是BUG)就被溜走了.

同意第二种观点的人,我觉得只是比比第一种稍微高了一点.如果我们事事都以一种相反的想法去看待每个待测试的功能点,这就脱离了我们在开发之前必须要写需求的目的.这种人能为客户着想,但是也得为项目着想,毕竟项目得进度也事很重要的.

 

所以,我们作为测试人员应该从2方面去考虑鸡蛋被砸坏的原因.既要为公司为项目的质量把关,也得从客户的角度去思考软件的功能点,怎样才是客户最最需要的!我们想问题就得从导致问题的双方面去考虑,这样才使我们被测试的软件更适合客户!

LoadRunner 脚本中做关联 (Correlation)

 <P>如何在 LoadRunner 脚本中做关联 (Correlation)<BR>当录制脚本时，VuGen会拦截client端（浏览器）与server端（网站服务器）之间的对话，并且通通记录下来，产生脚本。在VuGen的Recording Log中，您可以找到浏览器与服务器之间所有的对话，包含通讯内容、日期、时间、浏览器的请求、服务器的响应内容等等。脚本和Recording Log最大的差别在于，脚本只记录了client端要对server端所说的话，而Recording Log则是完整纪录二者的对话。<BR>&nbsp;<BR>当执行脚本时，您可以把VuGen想象成是一个演员，它伪装成浏览器，然后根据脚本，把当初真的浏览器所说过的话，再对网站伺服器重新说一遍，VuGen企图骗过服务器，让服务器以为它就是当初的浏览器，然后把网站内容传送给VuGen。<BR>所以纪录在脚本中要跟服务器所说的话，完全与当初录制时所说的一样，是写死的（hard-coded）。这样的作法在遇到有些比较聪明的服务器时，还是会失效。这时就需要透过「关联（correlation）」的做法来让VuGen可以再次成功地骗过服务器。<BR>何谓关联（correlation）？<BR>所谓的关联（correlation）就是把脚本中某些写死的（hard-coded）数据，转变成是撷取自服务器所送的、动态的、每次都不一样的数据。<BR>举一个常见的例子，刚刚提到有些比较聪明的服务器，这些服务器在每个浏览器第一次跟它要数据时，都会在数据中夹带一个唯一的辨识码，接下来就会利用这个辨识码来辨识跟它要数据的是不是同一个浏览器。一般称这个辨识码为Session ID。对于每个新的交易，服务器都会产生新的Session ID给浏览器。这也就是为什么执行脚本会失败的原因，因为VuGen还是用旧的Session ID向服务器要数据，服务器会发现这个Session ID是失效的或是它根本不认识这个Session ID，当然就不会传送正确的网页数据给VuGen了。<BR>下面的图示说明了这样的情形：<BR>当录制脚本时，浏览器送出网页A的请求，服务器将网页A的内容传送给浏览器，并且夹带了一个ID=123的数据，当浏览器再送出网页B的情求时，这时就要用到ID=123的数据，服务器才会认为这是合法的请求，并且把网页B的内容送回给浏览器。<BR>在执行脚本时会发生什么状况？浏览器再送出网页B的请求时，用的还是当初录制的ID=123的数据，而不是用服务器新给的ID=456，整个脚本的执行就会失败。<BR>&nbsp;<BR>要对付这种服务器，我们必须想办法找出这个Session ID到底是什么、位于何处，然后把它撷取下来，放到某个参数中，并且取代掉脚本中有用到Session ID的部份，这样就可以成功骗过服务器，正确地完成整个交易了。<BR>哪些错误代表着我应该做关联（correlation）？<BR>假如脚本需要关联（correlation），在还没做之前是不会执行通过的，也就是说会有错误讯息发生。不过，很不幸地，并没有任何特定的错误讯息是和关联（correlation）有关系的。会出现什么错误讯息，与系统实做的错误处理机制有关。错误讯息有可能会提醒您要重新登入，但是也有可能直接就显示HTTP 404的错误讯息。<BR>要如何做关联（correlation）？<BR>关联（correlation）函数<BR>关联（correlation）会用到下列的函数：<BR>?&nbsp;web_reg_save_param：这是最新版，也是最常用来做关联（correlation）的函数。<BR>语法：<BR>web_reg_save_param ( “Parameter Name” , &lt; list of Attributes &gt;, LAST ); <BR>?&nbsp;web_create_html_param、web_create_html_param_ex：这二个函数主要是保留作为向前兼容的目的的。建议使用 web_reg_save_param 函数。 <BR>详细用法请参考使用手册。在VuGen中点选【Help】&gt;【Function reference】&gt;【Contexts】&gt;【Web and Wireless Vuser Functions】&gt;【Correlation Functions】。<BR>如何找出要关联（correlation）数据<BR>简单的说，每一次执行时都会变动的值，就有可能需要做关联（correlation）。<BR>VuGen提供二种方式帮助您找出需要做关联（correlation）的值：<BR>1.&nbsp;自动关联 <BR>2.&nbsp;手动关联 <BR>自动关联<BR>VuGen内建自动关联引擎（auto-correlation engine），可以自动找出需要关联的值，并且自动使用关联函数建立关联。<BR>自动关联提供下列二种机制：<BR>?&nbsp;Rules Correlation：在录制过程中VuGen会根据订定的规则，实时自动找出要关联的值。规则来源有两种： <BR>o&nbsp;内建（Built-in Correlation）：<BR>VuGen已经针对常用的一些应用系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，内建关联规则，这些应用系统可能会有一种以上的关联规则。您可以在【Recording Options】&gt;【Internet Protocol】&gt;【Correlation】中启用关联规则，则当录制这些应用系统的脚本时，VuGen会在脚本中自动建立关联。<BR>您也可以在【Recording Options】&gt;【Internet Protocol】&gt;【Correlation】检视每个关联规则的定义。 <BR>o&nbsp;使用者自订（User-defined Rules Correlation）：<BR>除了内建的关联规则之外，使用者也可以自订关联规则。您可以在【Recording Options】&gt;【Internet Protocol】&gt;【Correlation】建立新的关联规则。 <BR>?&nbsp;Correlation Studio：有别于Rules Correlation，Correlation Studio则是在执行脚本后才会建立关联，也就是说当录制完脚本后，脚本至少须被执行过一次，Correlation Studio才会作用。Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。 <BR>Rule Correlation<BR>请依照以下步骤使用Rule Correlation：<BR>1.&nbsp;启用auto-correlation <BR>1.&nbsp;点选VuGen的【Tools】&gt;【Recording Options】，开启【Recording Options】对话窗口，选取【Internet Protocol】&gt;【Correlation】，勾选【Enable correlation during recording】，以启用自动关联。 <BR>2.&nbsp;假如录制的应用系统属于内建关联规则的系统，如AribaBuyer、BlueMartini、BroadVision、InterStage、mySAP、NetDynamics、Oracle、PeopleSoft、Siebel、SilverJRunner等，请勾选相对应的应用系统。 <BR>3.&nbsp;或者也可以针对录制的应用系统加入新的关联规则，此即为使用者自订的关联规则。 <BR>4.&nbsp;设定当VuGen侦测到符合关联规则的数据时，要如何处理： <BR>?&nbsp;【Issue a pop-up message and let me decide online】：跳出一个讯息对话窗口，询问您是否要建立关联。 <BR>?&nbsp;【Perform correlation in sceipt】：直接自动建立关联 <BR>2.&nbsp;录制脚本<BR>开始录制脚本，在录制过程中，当VuGen侦测到符合关联规则的数据时，会依照设定建立关联，您会在脚本中看到类似以下的脚本，此为BroadVision应用系统建立关联的例子，在脚本批注部分可以看到关联前的数据为何。 <BR>&nbsp;<BR>3.&nbsp;执行脚本验证关联是OK的。<BR>Correlation Studio<BR>当录制的应用系统不属于VuGen预设支持的应用系统时，Rule Correlation可能既无法发挥作用，这时可以利用Correlation Studio来做关联。<BR>Correlation Studio会尝试找出录制时与执行时，服务器响应内容的差异部分，藉以找出需要关联的数据，并建立关联。<BR>使用Correlation Studio的步骤如下：<BR>1.&nbsp;录制脚本并执行 <BR>2.&nbsp;执行完毕后，VuGen会跳出下面的【Scan Action for Correlation】窗口，询问您是否要扫描脚本并建立关联，按下【Yes】按钮。<BR>&nbsp;<BR>3.&nbsp;扫描完后，可以在脚本下方的【Correlation Results】中看到扫描的结果。<BR>&nbsp;<BR>4.&nbsp;检查一下扫瞄的结果后，选择要做关联的数据，然后按下【Correlate】按钮，一笔一笔做，或是按下【Correlate All】让VuGen一次就对所有的数据建立关联。<BR>注意：由于Correlation Studio会找出所有有变动的数据，但是并不是所有的数据都需要做关联，所以不建议您直接用【Correlate All】。 <BR>5.&nbsp;一般来说，您必须一直重复步骤1~4直到所有需要做关联的数据都找出来为止。因为有时前面的关联还没做好之前，将无法执行到后面需要做关联的部份。 <BR>有可能有些需要做关联的动态数据，连Correlation Studio都无法侦测出来，这时您就需要自行做手动关联了。<BR>手动关联<BR>手动关联的执行过程大致如下：<BR>1.&nbsp;使用相同的业务流程与数据，录制二份脚本 <BR>2.&nbsp;使用WinDiff工具协助找出需要关联的数据 <BR>3.&nbsp;使用web_reg_save_param函数手动建立关联 <BR>4.&nbsp;将脚本中有用到关联的数据，以参数取代 <BR>接下来将详细的说明如何执行每个步骤<BR>使用相同的业务流程与数据，录制二份脚本<BR>1.&nbsp;先录制一份脚本并存档。 <BR>2.&nbsp;依照相同的操作步骤与数据录制第二份脚本并存盘。注意，所有的步骤和输入的数据一定都要一样，这样才能找出由服务器端产生的动态数据。 <BR>有时候会遇到真的无法使用相同的输入数据，那您也要记住您使用的输入数据，到时才能判断是您输入的数据，还是变动的数据。<BR>使用WinDiff工具协助找出需要关联的数据<BR>1.&nbsp;在第二份脚本中，点选VuGen的【Tools】&gt;【Compare with Vuser…】，并选择第一份脚本。 <BR>2.&nbsp;接着WinDiff会开启，同时显示二份脚本，并显示有差异的地方。WinDiff会以一整行黄色标示有差异的脚本，并且以红色的字体显示真正差异的文字。（假如没看到红色字体，请点选【Options】&gt;【View】&gt;【Show Inline Differences】）。 <BR>3.&nbsp;逐一检视二份脚本中差异的部份，每一个差异都可能是需要做关联的地方。选取差异的脚本，然后复制。<BR>在复制时，有时并不需要取整行脚本，可能只会选取脚本中的一部分。<BR>注意：请忽略lr_thik_time的差异部份，因为lr_thik_time是用来模拟每个步骤之间使用者思考延迟的时间。<BR>&nbsp;<BR>4.&nbsp;接着要在Recording Log（单一protocol）或是Generation Log（多重protocol）中找这个值。将鼠标光标点到Recording Log的第一行开头，按下Ctrl+F，开启【Find】窗口，贴上刚刚复制的脚本，找出在Recording Log第一次出现的位置。<BR>&nbsp;<BR>结果会有二种： <BR>o&nbsp;在Recording Log中找不到要找的数据，这时请先确认您找对了脚本，毕竟现在开启了二个几乎一样的脚本，很容易弄错。 <BR>o&nbsp;在Recording Log中找到了要找的数据，这时要确认数据是从服务器端传送过来的。首先可以先检查数据的标头，从标头的Receiving response可以知道数据是从服务器端传送到client端的。假如此数据第一次出现是在Sending request中，则表示此数据是由client端产生，不需要做关联，但是有可能需要做参数化（parameterized）。<BR>您要找的标头格式如下：<BR>*** [tid=b9 Action1 2] Receiving response from host astra.merc-int.com:80 ( 25/11/2002 12:04:00 )<BR>&nbsp;<BR>5.&nbsp;现在您已经找到录制二次都不一样，而且是由服务器所产生的动态数据了，而此数据极有可能需要做关联。<BR>使用web_reg_save_param函数手动建立关联<BR>在找到是由服务器所产生的动态数据之后，接下来要做的就是找出适当的位置，使用web_reg_save_param函数，将这个动态数据撷取到某个参数中。<BR>1.&nbsp;要在哪里使用web_reg_save_param函数？<BR>在之前的步骤，我们已经在Execution Log找到可能需要关联的动态数据。在Execution Log中选取动态数据前的文字然后复制，我们将会利用这段文字，来帮助我们找出要关联的动态数据。<BR>&nbsp;<BR>不过在这之前我们要先找出使用web_reg_save_param函数的正确位置，所以我们要再重新执行一遍脚本，而且这次会开启所有的Log。 <BR>1.&nbsp;在VuGen中点选【Vuser】&gt;【Run-Time Settings】。 <BR>2.&nbsp;点选【General】&gt;【Log】。 <BR>3.&nbsp;勾选【Enable logging】、【Always sends messages】、【Extended log】，以及【Extended log】下的所有选项。 <BR>4.&nbsp;按下【OK】就可以执行脚本了。 <BR>执行完脚本之后，在Execution Log中搜寻刚刚复制的字符串。找到字符串后，在字符串前面会有A.tion1.c(7)，这个7就是到时候要插入web_reg_save_param函数的位置，也就是要插入到脚本的第7行。<BR>在脚本的第7行前插入一行空白行，然后输入<BR>web_reg_save_param(“UserSession”, <BR>“UserSession” 这个 “UserSession” 就是到时要使用的参数名称，建议给个有意义的名字。<BR>注意：到这里整个web_reg_save_param函数还没完成。<BR>&nbsp;<BR>2.&nbsp;找出web_reg_save_param中要用到的边界<BR>web_reg_save_param函数主要是透过动态数据的前面和后面的固定字符串，来辨识要撷取的动态数据的，所以我们还需要找出动态数据的边界字符串。 <BR>找出左边界字符串<BR>再回到Execution Log中，选取动态数据前的字符串并且复制它。<BR>这时会有个问题，到底要选取多少字符串才足以唯一识别要找的动态数据呢？建议是越多越好，但是尽量不要包含到特殊字符。<BR>在这边我们选取「input type=hidden value=」字符串。选好之后，还要再确认一次这段字符串真的是可以唯一识别的，所以我们在Execution Log中透过Ctrl+F的搜寻，找找看这段字符串是否可以找到要找的动态数据。假如找不到，web_reg_save_param函数还有个ORD参数可以使用，ORD参数可以设定出现在第几次的字符串才是要找的字符串。<BR>将这个边界字符串加到未完成的web_reg_save_param函数中：<BR>web_reg_save_param(“UserSession”, “LB= input type=hidden value=”,<BR>找出右边界字符串<BR>接下来要找出动态数据的右边界字符串，这个字符串就比较好找了，从动态数据的最后一个字符开始，通常就是我们要找的右边界字符串了。<BR>以这个例子来看，就是「&gt;」，所以再把右边界字符串加入，web_reg_save_param函数中，这时web_reg_save_param函数已经快完成了。最后再加上「LAST);」就完成整个web_reg_save_param函数了。<BR>web_reg_save_param(“UserSession”, “LB= input type=hidden value=”, “RB=&gt;”, LAST);<BR>&nbsp;<BR>将脚本中有用到关联的数据，以参数取代<BR>当使用web_reg_save_param建立参数后，接下来就是用“UserSession”参数去取代脚本中写死的（hard-coded）资料。<BR>范例：<BR>将<BR>“Name=userSession”, “Value=75893.0884568651DQADHfApHDHfcDtccpfAttcf”, ENDITEM,<BR>换成<BR>“Name=userSession”, “Value={UserSession}”, ENDITEM,<BR>&nbsp;<BR>到这里您已经完成了一个关联了，接下来就是执行脚本，是否能成功运行，假如还是有问题，就要检查看看是否还需要再做另一个关联。<BR>关于 web_reg_save_param 函数<BR>对于关联(correlation)来说，web_reg_save_param是最重要的一个函数，其功能是在下载的网页内容中，透过设定的边界字符串，找出特定的数据并将其储存在一个参数中，以供后续脚本使用。<BR>接下来将针对web_reg_save_param做比较详细的说明。<BR>Service and registration type function<BR>web_reg_save_param是一个Service function。service function主要是用来完成一些特殊的工作的，如关联、设定proxy、提供认证信息等，当其作用时，不会对网页的内容做任何的修改。<BR>web_reg_save_param同时也是一个registration type function (只要函数名称中包含_reg_的字眼，表示其为registration type function)。registration type function意味着其真正作用的时机是在下一个action function完成时执行的。举例来说，当某个web_url执行时所接收到的网页内容中包含了要做关联的动态数据，则必须将web_reg_save_param放在此web_url之前，则web_reg_save_param会在web_url执行完毕后，也就是网页内容都下载完后，再执行web_reg_save_param找寻要做关联的动态数据并建立参数。<BR>所以要记住一点，要使用registration type function时，要注意其放置的位置必须在要作用的action function之前。<BR>语法<BR>int web_reg_save_param(const char *ParamName, &lt;list of Attributes&gt;, LAST);<BR>参数说明<BR>ParamName:存放动态数据的参数名称<BR>list of Attributes:其它属性，包含 Notfound, LB, RB, RelFrameID, Search, ORD, SaveOffset, Convert, 以及 SaveLen。属性值不分大小写，例如 Search=all。以下将详细说明每个属性值的意义:<BR>?&nbsp;Notfound:指定当找不到要找的动态数据时该怎么处置。 <BR>o&nbsp;Notfound=error:当找不到动态数据时，发出一个错误讯息。假如没设定此属性，此为LoadRunner的默认值。 <BR>o&nbsp;Notfound=warning:当找不到动态数据时，不发出错误讯息，只发出警告，脚本也会继续执行下去不会中断。在对角本除错时，可以使用此属性值。 <BR>?&nbsp;LB:动态数据的左边界字符串。此属性质是必须要有的，而且区分大小写。 <BR>?&nbsp;RB:动态数据的右边界字符串。此属性质是必须要有的，而且区分大小写。 <BR>?&nbsp;RelFrameID:相对于URL而言，欲搜寻的网页的Frame。此属性质可以是All或是数字，而且可有可无。 <BR>?&nbsp;Search:搜寻的范围。可以是Headers(只搜寻headers)、Body(只搜寻body部分，不搜寻header)、Noresource(只搜寻body部分，不搜寻header与resource)或是All(搜寻全部范围，此为默认值)。此属性质可有可无。 <BR>?&nbsp;ORD:指明从第几次出现的左边界开始才是要撷取的数据。此属性质可有可无，默认值是1。假如值为All，则所有找到符合的数据会储存在数组中。 <BR>?&nbsp;SaveOffset:当找到符合的动态数据时，从第几个字符开始才开始储存到参数中。此属性质不可为负数，其默认值为0。 <BR>?&nbsp;Convert:可能的值有二种: <BR>o&nbsp;HTML_TO_URL: 将HTML-encoded数据转成URL-encoded数据格式 <BR>o&nbsp;HTML_TO_TEXT:将HTML-encoded数据转成纯文字数据格式 <BR>?&nbsp;SaveLen:从offect开始算起，到指定的长度内的字符串，才储存到参数中。此参数可有可无，默认值是-1，表示储存到结尾整个字符串。<BR>范例<BR>web_reg_save_param("A", "LB/ic=&lt;a href=", "RB='&gt;", "Ord=All", LAST);nner会搜寻网页中所有以 「&lt;a href=」 开头，且以 「’&gt;」结束，当中包含的字符串，并且储存在「A」参数中。 <BR>Tips and Tricks<BR>以下提供一些关联的常见问题：<BR>?&nbsp;如何打印出参数值？<BR>lr_output_message这二个函数来做到。例如： <BR>lr_output_message(“Value Captured = %s”, lr_eval_string(“{ParameterName}”));<BR>lr_eval_string与lr_output_message函数的使用说明请参考LoadRunner Online Function Reference。<BR>?&nbsp;在脚本的data目录下找不到路制时的快照（snapshot）<BR>造成在脚本的data目录下找不到路制时的快照（snapshot）的可能原因如下： <BR>o&nbsp;脚本是由VuGen 6.02或更早的版本所录制的 <BR>o&nbsp;汇入的Action不会包含快照（snapshot）的档案 <BR>o&nbsp;脚本是储存在只读的目录下，早成VuGen无法储存执行时撷取的快照（snapshot） <BR>o&nbsp;某些步骤并不会产生快照（snapshot），如浏览某个资源 <BR>o&nbsp;快照（snapshot）功能被取消<BR>【Tools】&gt;【General options】&gt;【Correlation】tab &gt;【Save correlation information during replay】 <BR>?&nbsp;开启WinDiff时出现「File no longer available」的错误讯息<BR>WinDiff这个工具有些限制，无法开启包含空格符的目录或是脚本，所以建议命名时不要使用空格符，并且尽可能将名称取短一点。 <BR>?&nbsp;录制时突然跳出【Correlation warning】对话窗口<BR>当你有勾选自动关联的【Issue a popup message and let me decide online】选项，当VuGen发现有可能要做关联的数据时，就会跳出【Correlation warning】的窗口，询问你要做关联（Correlation in scrīpt）还是要忽略（Ignore）。<BR>另外你也可以勾选【Perform correlation in scrīpt】，让VuGen自动作关联，不会再跳出询问窗口。<BR>或是勾选【Disable correlation engine】，关闭自动关联的功能。<BR>&nbsp;<BR>?&nbsp;如何手动启动「Scan action for correlation」的功能<BR>要手动启动「Scan action for correlation」的功能，请先执行脚本一次后，点选【Vuser】&gt;【Scan Action for Correlation】。<BR>&nbsp;<BR>?&nbsp;执行完脚本后并未出现【Scan Action for Correlation】窗口<BR>要启用【Scan Action for Correlation】功能，请点选【Tools】&gt;【General options】&gt;【Correlation】tab，勾选【Show Scan for correlation popup after replay of Vuser】选项。</P>

如何设计编制软件测试用例（Test Case）

1 . 测试用例是软件测试的核心

      软件测试的重要性是毋庸置疑的。但如何以最少的人力、资源投入，在最短的时间内完成测试，发现软件系统的缺陷，保证软件的优良品质，则是软件公司探索和追求的目标。每个软件产品或软件开发项目都需要有一套优秀的测试方案和测试方法。

      影响软件测试的因素很多，例如软件本身的复杂程度、开发人员（包括分析、设计、编程和测试的人）的素质、测试方法和技术的运用等等。因为有些因素是客观存在的，无法避免。有些因素则是波动的、不稳定的，例如开发队伍是流动的，有经验的走了，新人不断补充进来；一个具体的人工作也受情绪等影响，等等。如何保障软件测试质量的稳定？有了测试用例，无论是谁来测试，参照测试用例实施，都能保障测试的质量。可以把人为因素的影响减少到最小。即便最初的测试用例考虑不周全，随着测试的进行和软件版本更新，也将日趋完善。因此测试用例的设计和编制是软件测试活动中最重要的。测试用例是测试工作的指导，是软件测试的必须遵守的准则。更是软件测试质量稳定的根本保障。

2 . 什么叫测试用例

      测试用例（Test Case）目前没有经典的定义。比较通常的说法是：指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。不同类别的软件，测试用例是不同的。不同于诸如系统、工具、控制、游戏软件，管理软件的用户需求更加不统一，变化更大、更快。笔者主要从事企业管理软件的测试。因此我们的做法是把测试数据和测试脚本从测试用例中划分出来。测试用例更趋于是针对软件产品的功能、业务规则和业务处理所设计的测试方案。对软件的每个特定功能或运行操作路径的测试构成了一个个测试用例。

3. 编制测试用例

      下面着重介绍一些编制测试用例的具体做法。

3.1、测试用例文档
      编写测试用例文档应有文档模板，须符合内部的规范要求。测试用例文档将受制于测试用例管理软件的约束。

      软件产品或软件开发项目的测试用例一般以该产品的软件模块或子系统为单位，形成一个测试用例文档，但并不是绝对的。

      测试用例文档由简介和测试用例两部分组成。简介部分编制了测试目的、测试范围、定义术语、参考文档、概述等。测试用例部分逐一列示各测试用例。每个具体测试用例都将包括下列详细信息：用例编号、用例名称、测试等级、入口准则、验证步骤、期望结果（含判断标准）、出口准则、注释等。以上内容涵盖了测试用例的基本元素：测试索引，测试环境，测试输入，测试操作，预期结果，评价标准。

3.2、测试用例的设计

      我们早期的测试用例是按功能设计用例。后来引进了路径分析法，按路径设计用例。目前演变为按功能、路径混合模式设计用例。

      按功能测试是最简捷的，按用例规约遍历测试每一功能。

      对于复杂操作的程序模块，其各功能的实施是相互影响、紧密相关、环环相扣的，可以演变出数量繁多的变化。没有严密的逻辑分析，产生遗漏是在所难免。路径分析是一个很好的方法，其最大的优点是在于可以避免漏测试。

      但路径分析法也有局限性。在一个非常简单字典维护模块就存在十余条路径。一个复杂的模块会有几十到上百条路径是不足为奇的。笔者以为这是路径分析比较合适的使用规模。若一个子系统有十余个或更多的模块，这些模块相互有关联。再采用路径分析法，其路径数量成几何级增长，达5 位数或更多，就无法使用了。那么子系统模块间的测试路径或测试用例还是要*传统方法来解决。这是按功能、路径混合模式设计用例的由来。

3.3、设计测试用例

      测试用例可以分为基本事件、备选事件和异常事件。设计基本事件的用例，应该参照用例规约（或设计规格说明书），根据关联的功能、操作按路径分析法设计测试用例。而对孤立的功能则直接按功能设计测试用例。基本事件的测试用例应包含所有需要实现的需求功能，覆盖率达100%。

      设计备选事件和异常事件的用例，则要复杂和困难得多。例如，字典的代码是唯一的，不允许重复。测试需要验证：字典新增程序中已存在有关字典代码的约束，若出现代码重复必须报错，并且报错文字正确。往往在设计编码阶段形成的文档对备选事件和异常事件分析描述不够详尽。而测试本身则要求验证全部非基本事件，并同时尽量发现其中的软件缺陷。

      可以采用软件测试常用的基本方法：等价类划分法、边界值分析法、错误推测法、因果图法、逻辑覆盖法等设计测试用例。视软件的不同性质采用不同的方法。如何灵活运用各种基本方法来设计完整的测试用例，并最终实现暴露隐藏的缺陷，全凭测试设计人员的丰富经验和精心设计。

4.测试用例在软件测试中的作用

4.1、指导测试的实施

      测试用例主要适用于集成测试、系统测试和回归测试。在实施测试时测试用例作为测试的标准，测试人员一定要按照测试用例严格按用例项目和测试步骤逐一实施测试。并对测试情况记录在测试用例管理软件中，以便自动生成测试结果文档。

      根据测试用例的测试等级，集成测试应测试那些用例，系统测试和回归测试又该测试那些用例，在设计测试用例时都已作明确规定，实施测试时测试人员不能随意作变动。

4.2、规划测试数据的准备

      在我们的实践中测试数据是与测试用例分离的。按照测试用例配套准备一组或若干组测试原始数据，以及标准测试结果。尤其象测试报表之类数据集的正确性，按照测试用例规划准备测试数据是十分必须的。
除正常数据之外，还必须根据测试用例设计大量边缘数据和错误数据。

4.3、编写测试脚本的"设计规格说明书"

      为提高测试效率，软件测试已大力发展自动测试。自动测试的中心任务是编写测试脚本。如果说软件工程中软件编程必须有设计规格说明书，那么测试脚本的设计规格说明书就是测试用例。

4.4、评估测试结果的度量基准

      完成测试实施后需要对测试结果进行评估，并且编制测试报告。判断软件测试是否完成、衡量测试质量需要一些量化的结果。例：测试覆盖率是多少、测试合格率是多少、重要测试合格率是多少，等等。以前统计基准是软件模块或功能点，显得过于粗糙。采用测试用例作度量基准更加准确、有效。

4.5、分析缺陷的标准

      通过收集缺陷，对比测试用例和缺陷数据库，分析确证是漏测还是缺陷复现。漏测反映了测试用例的不完善，应立即补充相应测试用例，最终达到逐步完善软件质量。而已有相应测试用例，则反映实施测试或变更处理存在问题。

5.相关问题
5.1、测试用例的评审

      测试用例是软件测试的准则，但它并不是一经编制完成就成为准则。测试用例在设计编制过程中要组织同级互查。完成编制后应组织专家评审，需获得通过才可以使用。评审委员会可由项目负责人、测试、编程、分析设计等有关人员组成，也可邀请客户代表参加。

5.2、测试用例的修改更新

      测试用例在形成文档后也还需要不断完善。主要来自三方面的缘故：第一、在测试过程中发现设计测试用例时考虑不周，需要完善；第二、在软件交付使用后反馈的软件缺陷，而缺陷又是因测试用例存在漏洞造成；第三、软件自身的新增功能以及软件版本的更新，测试用例也必须配套修改更新。一般小的修改完善可在原测试用例文档上修改，但文档要有更改记录。软件的版本升级更新，测试用例一般也应随之编制升级更新版本。

5.3、测试用例的管理软件

运用测试用例还需配备测试用例管理软件。它的主要功能有三个：第一、能将测试用例文档的关键内容，如编号、名称等等自动导入管理数据库，形成与测试用例文档完全对应的记录；第二、可供测试实施时及时输入测试情况；第三、最终实现自动生成测试结果文档，包含各测试度量值，测试覆盖表和测试通过或不通过的测试用例清单列表。

      有了管理软件，测试人员无论是编写每日的测试工作日志、还是出软件测试报告，都会变得轻而易举。

关于web测试
1页面部分
（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
（5） 页面特殊效果显示是否正确

2 页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（2）素是否显示（元素是否存在）
（3）页面元素是否显示正确（主要针对文字、图形、签章）
（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6） 页面元素的容错性列表（如输入框、时间列表或日历）
（7） 页面元素的容错性是否存在
（8） 页面元素的容错性是否正确

3 功能部分
（1） 数据初始化是否执行
（2） 数据初始化是否正确
（3） 数据处理功能是否执行
（4） 数据处理功能是否正确
（5） 数据保存是否执行
（6） 数据保存是否正确
（7） 是否对其他功能有影响
（8） 如果影响其他功能，系统能否作出正确的反应
（9） 其他错误
（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加 （新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
（11）查询功能分为两种情况，验证操作结果。
一、打开页面时自动显示结果，则不特别强调；
二、需要手工操作进行查询，则每次在其他功能完成后进行。
4 提示信息
（1） 成功、失败提示
（2） 操作结果提示
（3） 确认提示
（4） 危险操作、重要操作提示
（5） 返回页面 提示后显示的页面
5 容错性
注意以下几种情况
（1） 为空、非空
（2） 唯一性
（3 ）字长、格式
（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
（5） 日期、时间
（6） 特殊字符 （对数据库）英文单、双引号，&符号
6 权限部分
功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
以合并到功能测试
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
并到功能测试
权限变化： 可以合并到功能测试

（1） 功能权限是否存在
（2 ）功能权限是否正确
（3） 数据权限是否存在
（4） 数据权限是否正确
（5）操作权限是否存在
（6） 操作权限是否正确
（7） 引起权限变化的功能列表
（8） 功能权限变化还是数据权限变化，或两者兼有
（9） 权限变化是否正确

7 键盘操作
（1） Tab键的使用
（2） 上下方向键的使用
（3） Enter键的使用
（4） 系统设定快捷键的使用（如果设置有快捷键）

8 测试中还应注意的其他事项
（6） 完整性：是否是一个整体，没有功能缺损
（7） 易用性：使用是否方便
（8） 一致性：类似的问题用类似的方法处理
（9） 提示信息：提示信息是否完整、正确、详细
（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
（12） 可扩展性：是否由升级的余地，是否保留了接口
（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
（14） 运行速度：运行的快慢，带宽占用情况

有几点：
1.功能点测试：是否满足需求所要求的功能
2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
7.界面测试：界面的正确性、一致性、友好性、易用性。

用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
1.易用性检查：确保软件易于理解，方便使用。
2.一致性检查：
a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
b.提示信息的表达方式是否一致。
c.按钮排列顺序是否一致。
d.back, cancel等按钮跳转页面处理是否一致。
e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
4.友好性检查：
a.提示信息是否友好.
b.系统应该在用户执行错误的操作之前提出警告，提示信息.
c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理。

 

OR:http://www.51testing.com/html/57/2011.html#top

www.17testing.com

http://testing.csai.cn/

www.testage.net

测试工具备查

1、 从测试功能上分
（1） 单元测试
针对不同语言，如JUNIT
（2） 功级测试
E—Test：功能强大，由于不是采用POST URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持），基本上可以应付大部分的WEB SITE。
MI公司的WINRUNNER
COMPUWARE的QARUN
RATIONAL的SQA ROBOT
（3） 压力测试
MI公司的WINLOAD
COMPUWARE的QALOAD
RATIONAL的SQA LOAD
（4） 负载测试
LOADRUNNER
RATIONAL VISUAL QUANTIFY
（5） WEB测试工具
MI公司的ASTRA系列
RSW公司的E—TEST SUITE等
（6） WEB系统测试工具
WORKBENCH
WEB APPLICATION STRESS TOOL（WAS）
（7） 数据库测试工具
TESTBYTES
（8） 回归测试工具
RATIONAL TEAM TEST
WINRUNNER
（9） 嵌入式测试工具
ATTOLTESTWARE。是ATTOLTESTWARE公司的自动生成测试代码的软件测试工具，特别适用于嵌入式实时应用软件单元和通信系统测试。
CODETEST是AppliedMicrosystemsCorp.公司的产品,是广泛应用的嵌入式软件在线测试工具。
GammaRay。GammaRay系列产品主要包括软件逻辑分析仪GammaProfiler、可靠性评测工具GammaRET等。
LogiScope是TeleLogic公司的工具套件，用于代码分析、软件测试、覆盖测试。
LynxInsure++是LynxREAL-TIMESYSTEMS公司的产品，基于LynxOS的应用代码检测与分析测试工具。
MessageMaster是ElviorLtd.公司的产品，测试嵌入式软件系统工具，向环境提供基于消息的接口。
VectorCast是VectorSoftware.Inc公司的产品。由6个集成的部件组成，自动生成测试代码，为主机和嵌入式环境构造可执行的测试架构。
（10） 系统性能测试工具
Rational Performance
（11） 页面链接测试
Link Sleuth
（12） 测试流程管理工具
Test Plan Control
（13） 测试管理工具
TestDirector
Rational公司的Test Manager
Compuware公司的QADirector
TestExpert：是Silicon Valley Networks公司产品的测试管理工具，能管理整个测试过程，从测试计划、测试例程、测试执行到测试报告。
（14） 缺陷跟踪工具
TrackRecord等
（15） 其他测试工具包
TestVectorGenerationSystem是T—VECTechnologies公司的产品。提供自动模型分析、测试生成、测试覆盖分析和测试执行的完整工具包，具有方便的用户接口和完备的文档支持。
TestQuestPro是TestQuest公司的非插入码式的自动操纵测试工具，提供一种高效的自动检测目标系统，获取其输出性能的测试方法。
TestWorks是SoftwareResearch.Inc公司的一整套软件测试工具，既可单独使用，也可捆绑销售使用。
2、 从测试的方法上分：
（1） 白盒测试工具
白盒测试工主要有：Numega、PuRe、软件纠错工具（Rational Purify）。
内存资源泄漏检查：
Numega中的BounceChecher
Rational的 Purify等
代码覆盖率检查：
Numega的TrueCoverage
Rational的PureCoverage
TeleLogic公司的LogiScope
Macabe公司的Macabe
代码性能检查：
Numega的TrueTime
Rational的Quantify等
代码静态度量分析度量检查工具：LogiScope和Macabe等
黑盒测试工具主要有：QACenter、SQATeamTest、Rational Visual Visual Test。
QACenter：QACenter帮助所有测试人员创建一个快速、可重用的测试过程。这些测试工具自动帮助管理测试过程、快速分析和调试程序，包括针对回归、强度、单元、并发、集成、移植，容量和负载建立测试用例，自动执行测试和产生文档结果。QACenter主要包括以下几个模块：
QARun：应用的功能测试工具。
QALoad：强负载下应用的性能测试工具。
QADirector：测试的组织设计和创建以及管理工具。
TrackRecord：集成的缺陷跟踪管理工具。
EcoTools：高层次的性能监测工具。

3、部分具体测试工具的介绍
（1）、性能优化工具EcoScope
EcoScope是一套定位于应用（即服务提供者本身）及其所依赖的所有网络计算资源的解决方案。EcoScope可以提供应用视图，并标出应用是如何与基础架构相关联的。这种视图是其他网络管理工具所不能提供的。EcoScope能解决在大型企业复杂环境下分析与测量应用性能的难题。通过提供应用的性能级别及其支撑架构的信息，EcoScope能帮助IT部门就如何提高应用性能提出多方面的决策方案。
EcoScope的应用主要表现在以下几个方面：
确保成功部署新应用
维护性能的服务水平
加速问题检测与纠正的高级功能
定制视图有助于高效地分析数据
（2）、数据库测试数据自动生成工具——TestBytes
在数据库开发的过程中，为了测试应用程序对数据库的访问，应当在数据库中生成测试用例数据，我们可能会发现当数据库中只有少量数据时，程序可能没有问题，但是当真正投入到运用中产生了大量数据时就出现问题了，这往往是因为程序的编写没有达到，所以一定及早地通过在数据库中生成大量数据来帮助开发人员完善这部分功能和性能。
TestBytes是一个用于自动生成测试数据的强大易用的工具，通过简单的点击式操作，就可以确定需要生成的数据类型（包括特殊字符的定制），并通过与数据库的连接来自动生成数百万行正确的测试数据，可以极大地提高数据库开发人员、QA测试人员、数据仓库开发人员、应用开发人员的工作效率。
（3）、PC—LINT
PC—LINT 主要进行更严格的语法检查功能，还完成相当程度的语义检查功能。可以这样认为：PC—LINT是一个更加智能、更加严格的编译器。PC—LINT在实现语法和某些语义规则检查时，是通过参数配置完成的，它的选项就有数百个之多，因此，在使用PC—LINT过程中，了解选项的含义也很重要。
（4）、TCL
TCL是Tool Command Language的缩写，它是一种很流行的脚本解释器，尤其在测试领域，它的最大特点是可移植性好，接口简单，方便，可以很容易地嵌入到软件中，作为自己的解释器使用。
TCL提供两种接口：编程接口和用户接口。编程接口是通过LIB或DLL形式提供的，提供了一些函数（命令）供调用，包括：分配一个解释器指针（对象）；初始化解释器（指针）；注册扩展函数等。用户接口很简单，即编写的脚本，脚本里面包含对扩展命令的调用。
（5）VB测试工具：VB Watch
（6）Java 程序的测试工具
1）Bean—Test
2）EJBQuickTest
3）JStyle
4）JTest
5）HttpUnit
6）JUnit
（7）、覆盖测试
C—Cover
C—Cover是一个测试工具软件，用来找出没有被测到的代码，并报告测试的覆盖率。C—Cover
只支持C/C++的代码覆盖率分析，其它语言不支持。但不受OS的限制。
===============================================
单元测试方面：（对开发人员比较有用） J-Unit工具。
  功能测试方面：E-test是个不错的选择，功能很强大，由于不是采用Post URL的方式回放脚本，所以可以支持多内码的测试数据（当然要程序支持）。基本上可以应付大部分的Web Site。
  如果只是利用脚本回放代替手工劳动，或者做对页面响应数的性能测试，Microsoft Web Application Stress Tool是个不错的选择。
  另外，在性能测试方面，PureLoad也是一个不错的工具，完全用Java写成，可以测试各种C/S程序， 如SMTP Server等。 这两个工具都是使用Post URL的方法测试Web Application的。对大量使用Javascrīpt的页面不太适合。 当然，如果程序在Unix，linux下面运行的话，可以直接编写Shell脚本程序，更加方便。
  另外，还有很多专门的工具，比如说Linkbot是专门作页面链接测试的。
  另外，测试流程管理工具也有不少，个人用过也一直在用的是Test Plan Control，短小精悍，不错。   至于WinRunner和LoadRunner之类，因为没有License，所以都没怎么用过，惭愧。不过我看过一篇英国人评价英国测试市场上最流行的五个软件的文章。WinRunner得分最高。
  测试工具从测试的方法上可以分为两种：白盒测试和黑盒测试   白盒测试工具主要有：
  内存资源泄漏检查：Numega中的bouncechecker,Rational的Purify等
  代码覆盖率检查：Numega中的truecoverage,Rational的Purecoverage，Telelogic公司的logiscope, Macabe公司的Macabe等   代码性能检查：Numega中的truetime,Rational的Quantify等
  代码静态度量分析质量检查工具：logiscope和Macabe等
  黑盒测试工具主要有：   客户端功能测试：MI公司的winrunner,compuware的qarun,Rational的SQA robot等等
  服务器端压力性能测试： MI公司的winload,compuware的qaload,Rational的SQA load等等
  Web测试工具：MI公司的Astra系列，rsw公司的e-test suite等等
  测试管理工具：rational的test manager,compuware的qadirector等等，此外还有缺陷跟踪工具 trackrecord等。
  数据库测试工具:TestBytes
  黑盒测试工具：QACenter、SQATeamTest，Rational Viaual Test。
  回归测试工具：Rational TeamTest，WinRunner（MI公司）
  WEB系统测试工具：TEST，Workberch，Web Appication Stress Tool（WAS）
  白盒测试工具：Numega 、PuRe、软件纠错工具（Rational Purity）。
  嵌入式测试工具：Logiscope（静态测试工具）、CodeTest。
  系统负荷测试工具：RationalPerformance
  涵盖测试工具范围评估工具
  软件性能测试工具：LoadRunner（MI产品）、Rational Visual Qantify
  测试管理工具：TestDirector（MI产品支持整个生命周期中测试流程管理）

Acceptance testing  验收测试   Accessibility test    软体适用性测试
Ad hoc testing     随机测试    Algorithm analysis  算法分析
Alpha testing      α测试      Anomaly          异常       
Artifact          工件        Automated Testing   自动化测试 
Architecture       构架        Assertion checking  断言检查  
Audit             审计       Application under test (AUT)  所测试的应用程序

Baseline         基线       Behaviour          行为
Benchmark       基准       Beta testing        β测试
Best practise      最佳实践   Black box testing    黑盒测试
Blocking bug     阻碍性错误 Bottom-up testing    自底向上测试
Branch coverage   分支覆盖   Brute force testing   强力测试
Bug             错误       Bug report         错误报告
Bug tracking system 错误跟踪系统Build          工作版本（内部小版本）
Boundary values   边界值     Buddy test        合伙测试
Buffer           缓冲       Bug bash         错误大扫除
Build-in         内置       Build Verfication tests(BVTs)   版本验证测试

Cause-effect graph 因果图     Capture/Replay Tool 捕获/回放工具
Character Set    字符集      Capability Maturity Model (CMM)   能力成熟度模型
Capability Maturity Model Integration (CMMI) 能力成熟度模型整合
Closeout        收尾        Code coverage      代码覆盖
Code page      代码页       Code rule          编码规范
Code sytle      编码风格     Common sense     常识
Compatibility Testing兼容性测试Component testing  组件测试
Condition coverage  条件覆盖  Configuration testing 配置测试
Control flow graph  控制流程图Concurrency user   并发用户
Configuration item  配置项    Core team         核心小组
Customer-focused mindset 客户为中心的理念体系
Crash         崩溃          Criticality analysis  致命度分析
Cyclomatic complexity   圈复杂度

Data Flow Analysis 数据流分析 Decision coverag   判定覆盖
Debug         调试         Defect            缺陷
defect density   缺陷密度     Deployment       部署
Desk checking  桌前检查     Dynamic analysis   动态分析

Entry criteria   准入条件     Equivalence class   等价类
Equivalence partition testing 等价划分测试Error   错误
Error guessing  错误猜测     Error seeding      错误播种
Exception     异常/例外     Exception handlers  异常处理器
Exhaustive testing 穷尽测试   Exploratory testing  探索性测试
Event-driven   事件驱动     Envisioning Phase   构想阶段

Failure        失效         Fault             故障
Field testing   现场测试     Framework        框架
Functional testing功能测试

Hard-coding      硬编码     Hotfix           热补丁

G11N(Globalization) 全球化   Gap analysis      差距分析
Garbage characters 乱码字符   Glossary         术语表
Glass-box testing  白箱测试或白盒测试
GUI(Graphical User Interface) 图形用户界面

I18N(Internationalization)国际化Incremental testing 渐增测试
Installing testing  安装测试    Integration testing  集成测试
Interface        接口        Inspection         审查
Issue           问题        Iteration          迭代
Iterative development 迭代开发

Key concepts     关键概念    Key Process Area 关键过程区域
Keyword driven testing 关键字驱动测试
Kick-off meeting  启动会议  

Lag time         延迟时间   Lead time       前置时间    
L10N(Localization) 本地化    Localizability testing本地化能力测试
Localization testing  本地化测试Load testing      负载测试

Maintenance     维护         Maintainability    可维护性
Master project schedule总体项目方案Measurement  度量
Memory leak     内存泄漏     Migration testing   迁移测试
Milestone        里程碑       Mock up         模型，原型
Monkey testing   跳跃式测试    Module testing    模块测试

Negative Testing  逆向测试, 反向测试, 负面测试
N/A(Not applicable) 不适用的

Off-the-shelf software 套装软件

Pair Programming 成对编程      Path coverage    路径覆盖
Peer review      同行评审      Performance     性能
Performance indicator 性能（绩效）指标
Performance testing   性能测试   Pilot           试验
Pilot testing      引导测试      Portability      可移植性
Positive testing   正向测试      Postcondition    后置条件
Pseudo code     伪代码        Precondition     前提条件
Priority         优先权        Prototype       原型
Quality assurance(QA) 质量保证  Quality Control(QC) 质量控制

Recovery testing  恢复测试      Refactoring     重构
Regression testing 回归测试      Release        发布
Release note     版本说明       Reliability      可靠性
Return of Investment（ROI）  投资回报率
Review         评审          Requirements-based testing 基于需求的测试
Requirements management tool   需求管理工具
Risk assessment  风险评估      Root Cause Analysis(RCA)  根本原因分析
Robustness      强健性       
Sanity testing    健全测试       Screen shot     抓屏、截图    
Severity        严重性         Security testing  安全性测试    
Shipment      发布            Smoke testing   冒烟测试      
Software life cycle  软件生命周期Software development plan(SDP) 软件开发计划
Static testing     静态测试      Simulation     模拟
Simulator       模拟器         SLA(Service level agreement)  服务级别协议
Software development process  软件开发过程
Source code     源代码         Specification   规格说明书
Spiral model    螺旋模型       Statement coverage 语句覆盖
Stepwise refinement 逐步优化    Stress Testing   压力测试
Structural coverage  结构化覆盖  Stub          桩
Synchronization 同步            Syntax testing  语法分析
System analysis 系统分析        System design  系统设计
System integration系统集成      System Testing  系统测试

Test           测试           Testing bed     测试平台
Test case       测试用例       Testing coverage 测试覆盖
Test design     测试设计       Test driver      测试驱动
Testing environment 测试环境   Test infrastructure测试基础建设
Testing item    测试项         Testing plan     测试计划
Testing procedure测试过程      Test scenario    测试场景
Test scrīpt      测试脚本      Test strategy     测试策略
Test suite       测试包        Test target       测试目标
Testability      可测试性      Testware        测试工具
Top-down testing 自顶向下测试  Thread testing   线程测试
Traceability     可跟踪性      Traceability matrix 跟踪矩阵
Trade-off       平衡

Unit testing      单元测试     User interface(UI)  用户界面
Usability testing  可用性测试   Usage scenario    使用场景
User acceptance Test用户验收测试User profile     用户信息
User scenario    用户场景     

Version         版本          Virtual user     虚拟用户     
Volume testing    容量测试     V&V (Verification & Validation) 验证&确认

Walkthrough    走读          Waterfall model   瀑布模型
White box testing白盒测试      Work breakdown structure (WBS)任务分解结构
Web testing     网站测试

Zero bug bounce (ZBB) 零错误反弹