[CSDN社区电子杂志--测试员杂志]第1期

° 关于测试人员的角色定位.

° 你了解白盒测试、黑盒测试、灰盒测试吗？

° 使用用例场景，设计测试用例.

° 性能测试中常注意的事项.

° 如何进行软件缺陷分析.

No.1

2004.05

&&

第 2 页

第 3 页

面，你需要了解测试的流程，你需要了解如何用一个好的测试计划来规划我们的测试时间、测试范围（有些公司把测试范围的设计归纳在测试需求里面，但是很多公司都是在测试计划里面），需要了解如何用一个好的测试用例来覆盖整个测试范围之内的测试实施。了解如何保证所测试出来的bug是开发人员的问题而不是因为自己了解不够导致出现的问题。Bug分析报告之内如何总结问题都是我们需要注意到的知识。对自己的测试时间也需要进行详细规划，尽量多地考虑进去各种可能。这样才可以尽量减少相关的风险。

测试里面的知识学习可以分为以下三个阶段来进行（这个阶段只是自己的一种个人见解）：

第一个阶段我们必须要让做测试的人明白测试在整个软件工程里面的重要性，了解测试的相关基础知识，并且在了解这些知识的过程中逐渐挖掘出他对测试的兴趣。兴趣爱好是很好的从事一项工作的一个重要条件。让一个对测试丝毫不懂而且不感兴趣的人去直接去做测试，你不觉得是在耽误别人的青春吗？ 第二个阶段我们必须对测试的流程的管理工作通过实际的软件测试有个非常明确的认识。因为很多时候工作都是在团队相互协调的情况下进行的，所以对于整个软件开发流程以及开发流程当中的测试流程都需要很熟悉，这样才可以更好的配合工作。当我们这些都很熟悉并且在工作当中应用很流畅的时候，我们就可以对测试工具进行相对应的学习。诚然，现在很多公司在招聘测试人员的时候总是要求了解自动化测试工具，实际上据了解，很多公司并不能真正用自动化测试。所以不要一进门就想着学习自动化测试工具，很多知识在你了解了其他知识之后学习效果跟用途可能会更好。在了解测试相关流程的同时我们必须扩充我们的其他相关知识，包括对我们的产品的客户的需求的了解要比开发人员了解更全面，更深入。这样才能保证我们的流程，我们的测试按照客观的正确的方向前进，而不至于被开发人员的思想所牵引。呵呵。我喜欢做事主动而不是被动的去执行。 到第三个阶段我们可以跟区分专业一样走自己喜欢的途径：一方面可以继续深入提高自己的测试的专业技能并且能够真正从事自动化测试，成为技术领域里面的专家。另一方面我们可以慢慢趋于测试管理方面。上次在交流会上，海松大哥对测试人员的发展阶段跟发展路径规划曾作出一个很形象的比喻来，我画了一个粗略的流程，大家可以看看下面的发展图：（自下向上的发展趋势）（当然并不是每个人都在这个曲线发展之内）

第 4 页

（直线的长度可以粗略的概括发展的不同时间长短）

从这个图形我们大家也可以粗略的看出，对于初级测试工程师，这是两个不同的发展方向，但是最终还是发展为一个终点（PM）。从一个初级测试工程师晋升到一个高级测试工程师比较快，但是从一个初级测试工程师发展到一个Team Leader所需要的时间相对比较长。而从一个高级测试工程师发展到一个资深测试工程师花费时间更长一点，到达资深测试工程师之后就可以很容易做到测试主管了，以后可以发展到PM。当然从初级测试人员到高级、资深测试人员在上面的图中并不是表述为“曲线发展过程”的，很多时候行业经验、行业知识的累积等都很重要。而这点只有深入发展的人才会发现其重要性的。很多随着时间的推移和经验的增长，一些沉淀下来的东西不是表现在字面上，别人就可以理解并领悟的。所以要有信心的同时我们做事还必须有耐心，罗马非一日建成。相信明天就要紧紧把握今天。

我们很多人在测试的时候感觉到不爽的另外一个比较大众化的原因，可能就是对测试不感兴趣的同时知识层次不够。（建议接触测试一年之后还对此不感兴趣的朋友找找自己的原因，实在找不出来就早点看看别的比较好发展的行业吧。）。因为自己知识层次的不够，这样往往感觉自己找出的bug在开发人员那里得不到很好的重视，感觉自己的劳动成果没有得到相应的尊重一样。一个测试人员在跟开发人员打交道的时候往往会产生这么一个现象，随着开发的进行，测试人员提交的bug越来越不被开发人员重视了，这里面除了开发人员比较忙碌的缘故之外，另外一个不容忽视的原因就是我们测试人员自身的知识不够层次，很多时候因为我们不了解需求，不了解相关专业知识而误认为正确的东西是bug。任何一个领域里面的人我想都应该有这样的想法并且比较反对这个想法：那就是外行对内行进行不正确的指点，这相当于对别人劳动成果的一种不负责任的否定。所以我们一定要加强我们自身的专业知识的学习。这个时候大家可能会问，那么一个真正的测试人员应该具备哪些知识呢？我想在除了相关专业知识之外还有一些比较共性的知识需要我们大家了解，专业知识因为行业的不同所以有很多的不同之处，这儿不详细介绍了，我从大众化的方面来阐述下面几个需要我们注意的地方，这也是作为一个测试人员应该具备的基本素质：

1、 我们需要具备很好的沟通能力：沟通是人类相互进步的一个重要标志，用在我们这个行业里面沟通也比较适用。我们的沟通往往不仅是跟开发人员的沟通，有时候也会跟我们的客户进行沟通的。这是两种不同类型的人，他们关心问题的侧重点也不同。所以我们沟通时候需要掌握一定的技巧，这样才能从客户那儿得到比较准确的需求。有时候我们的工作会被开发人员认为是“破坏”性的工作，这样就会引起我们跟开发人员的冲突，所以当我们发现一个bug之后如何跟开发人员沟通也是一门艺术。很多时候我们不仅仅是把bug写出来，也要很好地说给开发人员知道。从而达到我们彼此想要的一种结果。

2、 我们需要具备很好的自信心：很多时候开发人员会经常认为测试人员的开发相关知识不如自己，所以会有一种轻视的态度，这个时候我们除了补充我们的专业知识之外还需要有很强的自信心。呵呵。如果允许他对我们说这说那，那么我认为我们的工作还没开展就已经处在十分不利的地步了，我们将会被他们牵着鼻子走。这种现象很正常。而我却属于那种很讨厌被别人牵着鼻子走的人。所以我知道我们一定要很专业才能让别人尊重自己的劳动成果并听取自己的见解。当然这种自信心也是建立在心平气和下的沟通，不是完全对

第 5 页

立的。

3、 我们需要保持一种怀疑的精神：（这点我很擅长，我经常怀疑那些跟我擦肩而过的PLMM对我放电。所以总是。。。。。。，呵呵，结果最近医务室大夫说我患了神经质。亏大了）我们会经常碰到这样一种情况，我们往往发现的bug交给开发人员时他们总是尽他们最大的努力解释每个他们认为不是bug的bug。我们在倾听他们解释的同时必须要怀疑他们的观点直到我们自己确认过之后。

4、 我们需要耐心和很好的记忆力：有时候往往一个bug需要我们很耐心的花费时间、精力去投入在上面，而且当我们再找到有些类似的bug的时候，要能从脑子里面找出来这些bug，这就需要我们有很好的记忆力。其实如果不具备这些条件了那么相关的文档就是我们最好的查询资料。我就是属于这种类型的，很多时候总是翻阅以前的文档。但是这样也有一个好处，那就是在不断的查询过程中我们对文档的修改，使文档日臻完善，当然这种完善也是相对的。

5、 我们需要一颗安静的心：因为浮躁的人是找不出隐藏在深处的bug的，（所以我们的开发人员总是喜欢让我测试他们的东西，因为我汇报的bug很少，这样他们的绩效就表现得很好啊。所以我总是挨批啊。不过现在学乖了，呵呵。）所以当我们测试的时候我们应该保持内心的平静，这样我们才会保持很好的洞察力来找到那些隐藏很深的bug。而且也会抓到相关的重点的。这点是很重要的。否则你的测试跟流水账做也没什么区别，根据业务流程，根据用户需求，根据开发人员的思路一路跑下去，发现一些皮毛的bug。这不是一个好的测试人员应该做的。我们在平静当中才能保持自己的观点不被别人左右。

6、 我们还需要能够承受压力并排遣压力：无须质疑，我们的工作承受着一定的压力，当然这样说有点片面，不过大体上应该是这样的。所以我们经常承受着一定的压力，客户在催促，开发人员在delay，风箱里面的老鼠两头受气。所以我们要能够承受压力，包括外界的、工作上的压力。并且不要把因为压力而导致的不好的情绪带到工作当中。学会排遣这些压力，保持一颗轻松的，平静的心，然后全身心投入到我们的工作。

上面的只是根据实际的一些经验以及曾经看过的一些朋友的见解总结而来的，还有很多其他方面的知识，但是我实在没有时间了，呵呵，很抱歉。以后有时候还可以继续补充。只是想强调一点：测试在中国的发展前景是非常好的，而这点从这几年无论测试人员和测试环境的变化还是客户对产品质量的要求越来越高都可以看出的。

还是上面说的那句老话：相信明天，就要把握今天！

2.有关黑盒测试、白盒测试和灰盒测试的基本概念 [原创] 作者：Aken Ø 黑盒测试 黑盒测试也称功能测试或数据驱动测试，它是在已知产品所应具有的功能，通过测试来检测每个功能是否都能正常使用，在测试时，把程序看作一个不能打第 6 页

开的黑盆子，在完全不考虑程序内部结构和内部特性的情况下，测试者在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数锯而产生正确的输出信息，并且保持外部信息（如数据库或文件）的完整性。

黑盒测试方法主要有等价类划分、边值分析、因—果图、错误推测等，主要用于软件确认测试。“黑盒”法着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试。“黑盒”法是穷举输入测试，只有把所有可能的输入都作为测试情况使用，才能以这种方法查出程序中所有的错误。实际上测试情况有无穷多个，人们不仅要测试所有合法的输入，而且还要对那些不合法但是可能的输入进行测试。

Ø 白盒测试

白盒测试也称结构测试或逻辑驱动测试，它是知道产品内部工作过程，可通过测试来检测产品内部动作是否按照规格说明书的规定正常进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作，而不顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试等，主要用于软件验证。 “白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一，穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序。第二，穷举路径测试不可能查出程序中因遗漏路径而出错。第三，穷举路径测试可能发现不了

一些与数据相关的错误。

Ø 灰盒测试

灰盒测试，确实是介于二者之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。

灰盒测试结合了白盒测试盒黑盒测试的要素.它考虑了用户端、特定的系统知识和操作环境。它在系统组件的协同性环境中评价应用软件的设计。

灰盒测试由方法和工具组成，这些方法和工具取材于应用程序的内部知识盒与之交互的环境，能够用于黑盒测试以增强测试效率、错误发现和错误分析的效率。

灰盒测试涉及输入和输出，但使用关于代码和程序操作等通常在测试人员视野之外的信息设计测试。

----------------------------------------------------------------------------------------------------------------------

第 7 页

北京慧灵科技有限公司依托测试时代资源，推出面向实践的软件测试专业课程，由国内著名软件企业的一线技术专家主讲，为您的企业解决实践中的关键问题。如果您培训的目的不是拿一个证书，而是想学习软件测试的最佳实践，那我们会是您一个不错的选择。

详情请登陆公司网站：www.ltesting.net

1. 使用用例场景,设计测试用例 [原创] 作者：周毅

概念和定义

不完全、不彻底是软件测试的致命缺陷，何程序只能进行少量而有限的测试。测试用例此情况下产生，同时它也是软件测试系统化、程化的产物。而测试用例的设计一直是软件测工作的重点和难点，那么

什么是测试用例？

为达到最佳的测试效果或高效的揭露隐藏错误而精心设计的少量测试数据，称之为测试我们不可能进行穷举测试，为了节省时间和资源、提高测试效率，必须要从数量极大的可用测试数据中精心挑选出具有代表性或特殊性的测试数据来进行测试。

怎样的用例算是好用例？

一个好的测试用例是在于它能发现至今未发现的错误。

使用测试用例的好处

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。 测试用例的使用令软件测试的实施重点突出、目的明确。

在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。

功能模块的通用化和复用化使软件易于开发，而相对于功能模块的测试用例的通用化和复用化则会使软件测试易于开展，并随着测试用例的不断精化其效率也不断攀升。

设计测试用例的方法

黑盒测试：

等价类划分法

第 8 页

边界值分析法

错误推测法

因果图法

白盒测试：

逻辑覆盖法

基本路径测试法

测试用例的设计过程

测试设计员（分析设计员）依据不同阶段的测试计划、设计模型和实施模型来设计该阶段测试用例。

测试设计员是具有丰富测试经验或具有软件分析设计能力的高级测试工程师。如果没有测试设计员，则可用分析设计员代替。

针对白盒，还应有驱动程序和桩模块。

测试点的确定

ISO 质量体系：

在概要设计或详细设计中应明确指出每个单元模块的测试要点、指标和方法。

CMM 质量体系：

在系统的用例模型描述中应明确指出每个用例模型的优先级及用例工作流程，每一个用例模型为一个测试点，用例模型中每一个测试需求至少应有两个测试用例。

理解上的误区

测试用例应由测试设计员或分析设计员来制定，而不是普通的测试员。 测试点应由分析设计员确立，与测试人员无关。

测试工作展开于项目立项后，而不是代码开发完成之后。

测试对象不仅仅是源代码，还包括需求分析、需求规格说明书、概要设计、概要设计说明书、详细设计、详细设计说明书、使用手册等各阶段的文档。

用例场景的定义

用例场景是通过描述流经用例的路径来确定的过程，这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

为什么引入用例场景

现在的软件几乎都是由事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果形成事件流。这种在软件设计方面的思想也可被引入到软件测试中，生动的描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时测试用例也更容易的得到理解和执行。

提出这种测试思想的是Rational 公司，在RUP2000 中文版当中有其详尽的解释和应用，用例场景贯穿其中。

用例场景例子

第 9 页

下图中经过用例的每条不同路径都反映了基本流和备选流，都用箭头来表示。基本流用直黑线来表示，是经过用例的最简单的路径。每个备选流自基本流开始，之后，备选流会在某个特定条件下执行。备选流可能会重新加入基本流中（备选流 1 和 3），还可能起源于另一个备选流（备选流 2），或者终止用例而不再重新加入某个流（备选流 2 和 4）

遵循上图中每个经过用例的可能路径，可以确定不同的用例场景。从基本流开始，再将基本流和备选流结合起来，可以确定以下用例场景：

场景 1 基本流

场景 2 基本流 备选流 1

场景 3 基本流 备选流 1 备选流 2

场景 4 基本流 备选流 3

场景 5 基本流 备选流 3 备选流 1

场景 6 基本流 备选流 3 备选流 1 备选流 2 场景 7 基本流 备选流 4

场景 8 基本流 备选流 3 备选流 4

注：为方便起见，场景 5、6 和 8 只描述了备选流 3 指示的循环执行一次的情况。

测试用例

生成每个场景的测试用例是通过确定某个特定条件来完成的，这个特定条件将导致特定用例场景的执行。

测试用例例子

假定上图描述的用例对备选流 3 规定如下：

“如果在上述步骤 2‘输入提款金额’中输入的美元量超出当前帐户余额，则出现此事件流。系统将显示一则警告消息，之后重新加入基本流，再次执行上述步骤 2‘输入提款金额’，此时银行客户可以输入新的提款金额。” 据此，可以开始确定需要用来执行备选流 3 的测试用例： 测试用例场景 条件 预期结果

第 10 页

TC x

TC y

TC z 场景4 步骤2 - 提款金额> 帐户余额 场景4 步骤2 - 提款金额

实用举例

下面是一个由用例生成测试用例的更符合实际情况的示例。

示例：

一台 ATM 机器的主角和用例。

下表包含了上图中提款用例的基本流和某些备用流： 本用例的开端是ATM 处于准备就绪状态。

准备提款-客户将银行卡插入ATM 机的读卡机。

验证银行卡-ATM 机从银行卡的磁条中读取帐户代码，并检

查它是否属于可以接收的银行卡。

输入PIN - ATM 要求客户输入PIN 码（4 位） 验证帐户代

码和PIN - 验证帐户代码和PIN 以确定该帐户是否有效

以及所输入的PIN 对该帐户来说是否正确。对于此事件流，

帐户是有效的而且PIN 对此帐户来说正确无误。

ATM 选项-ATM 显示在本机上可用的各种选项。在此事件流

中，银行客户通常选择“提款”。

输入金额-要从ATM 中提取的金额。对于此事件流，客户需

选择预设的金额（10 美元、20 美元、50 美元或100 美元）。

授权-ATM 通过将卡ID、PIN 、金额以及帐户信息作为一笔

交易发送给银行系统来启动验证过程。对于此事件流，银行

系统处于联机状态，而且对授权请求给予答复，批准完成提

款过程，并且据此更新帐户余额。

出钞-提供现金。 基本流

第 11 页

返回银行卡-银行卡被返还。

收据-打印收据并提供给客户。ATM 还相应地更新内部记录。

用例结束时ATM 又回到准备就绪状态。

备选流1 - 银行卡无效 在基本流步骤2 中-验证银行卡，如果卡是无效的，则卡被

退回， 同时会通知相关消息。

备选流2 - ATM 内没有现在基本流步骤5 中- ATM 选项，选项将无法使用。如果ATM 内金 没有现金，则“提款”

选流3 - ATM 内现金不足 在基本流步骤6 中-输入金额，如果ATM 机内金额少于请求

提取的金额，则将显示一则适当的消息，并且在步骤6 -输

入金额处重新加入基本流。

选流4 - PIN 有误 在基本流步骤4 中-验证帐户和PIN，客户有三次机会输入

PIN 。如果PIN 输入有误，ATM 将显示适当的消息；如果还

存在输入机会， 则此事件流在步骤3 - 输入PIN 处重新加

入基本流。如果最后一次尝试输入的PIN 码仍然错误，则该

卡将被ATM 机保留同时ATM 返回到准备就绪状态，本用例终

止。

选流5 - 帐户不存在 在基本流步骤4 中-验证帐户和PIN，如果银行系统返回的代

码表明找不到该帐户或禁止从该帐户中提款，则ATM 显示适

当的消息并且在步骤9 - 返回银行卡处重新加入基本流。

选流6 - 帐面金额不足 在基本流步骤7 -授权中，银行系统返回代码表明帐户余额

少于在基本流步骤6 - 输入金额内输入的金额，则ATM 显示

适当的消息并且在步骤6 - 输入金额处重新加入基本流。

选流7 - 达到每日最大的在基本流步骤7- 授权中，银行系统返回的代码表明包括本提款金额 提款请求在内，客户已经或将超过在24 小时内允许提取的

最多金额，则ATM 显示适当的消息并在步骤6 - 输入金额上

重新加入基本流。

选流 x - 记录错误 如果在基本流步骤10 -收据中，记录无法更新，则ATM 进入

“安全模式”， 在此模式下所有功能都将暂停使用。同时

向银行系统发送一条适当的警报信息表明ATM 已经暂停工

作。

客户可随时决定终止交易（退出）。交易终止，银行卡随之选流 y - 退出 退出。

选流 z - “翘起” ATM 包含大量的传感器，用以监控各种功能，如电源检测器、

不同的门和出入口处的测压器以及动作检测器等。在任一时

刻，如果某个传感器被激活，则警报信号将发送给警方而且

ATM 进入“安全模式”， 在此模式下所有功能都暂停使用，

直到采取适当的重启/重新初始化的措施。

第 12 页

测试员电子期刊 www.ltesting.net

第一次迭代中，根据迭代计划， 我们需要核实提款用例已经正确地实施。此时尚未实施整个用例，只实施了下面的事件流：

基本流-提取预设金额（10 美元、20 美元、50 美元、100 美元）

备选流2 - ATM 内没有现金

备选流3 - ATM 内现金不足

备选流4 - PIN 有误

备选流5 - 帐户不存在/帐户类型有误

备选流6 - 帐面金额不足

以从这个用例生成下列场景

场景1 - 成功的提款

场景2 - ATM 内没有现金

场景3 - ATM 内现金不足 基本流 基本流 基本流 备选流2 备选流3

备选流4

备选流4

备选流 5

备选流 6 场景4 - PIN 有误（还有输入机会） 基本流 场景5 - PIN 有误（不再有输入机会） 场景 6 - 帐户不存在/帐户类型有误 场景 7 - 帐户余额不足 基本流 基本流 基本流

注：为方便起见，备选流 3 和 6（场景 3 和 7）内的循环以及循环组合未纳入上表。

对于这 7 个场景中的每一个场景都需要确定测试用例。可以采用矩阵或决策表来确定和管理测试用例。下面显示了一种通用格式，其中各行代表各个测试用例，而各列则代表测试用例的信息。本示例中，对于每个测试用例，存在一个测试用例 ID、条件（或说明）、测试用例中涉及的所有数据元素（作为输入或已经存在于数据库中）以及预期结果。

通过从确定执行用例场景所需的数据元素入手构建矩阵。然后，对于每个场景，至少要确定包含执行场景所需的适当条件的测试用例。例如，在下面的矩阵中，V（有效）用于表明这个条件必须是 VALID（有效的）才可执行基本流，而 I（无效）用于表明这种条件下将激活所需备选流。下表中使用的“n/a”（不适用）表明这个条件不适用于测试用例。

输入

的金

帐额（或PIN 号 选择

的金

额） 帐面 ATM 内金的金额 额

V V

V I TC（测试用例）ID 号 场景/条件 预期结果 CW1. CW2. 场景1 - 成功的提款 V V V 场景2 - ATM 内没有

现金 V V V 成功的提款。 提款选项不可用，

用例结束

第 13 页

CW3. 场景3 - ATM 内现金

不足

场景4 -PIN 有误（还

有不止一次输入机

会）

场景4 -PIN 有误（还

有一次输入机会）

场景4 -PIN 有误（不

再有输入机会） V V V V I 警告消息，返回基本流步骤6 -输入金额 警告消息，返回基本流步骤4，输入PIN 警告消息，返回基本流步骤4， 输入PIN 警告消息，卡予保留，用例结束 CW4. I V n/a V V CW5. I V n/a V V CW6. I V n/a V V

在上面的矩阵中，六个测试用例执行了四个场景。对于基本流，上述测试用例 CW1 称为正面测试用例。它一直沿着用例的基本流路径执行，未发生任何偏差。基本流的全面测试必须包括负面测试用例，以确保只有在符合条件的情况下才执行基本流。这些负面测试用例由 CW2 至 6 表示（阴影单元格表明这种条件下需要执行备选流）。虽然 CW2 至 6 对于基本流而言都是负面测试用例，但它们相对于备选流 2 至 4 而言是正面测试用例。而且对于这些备选流中的每一个而言，至少存在一个负面测试用例（CW1 - 基本流）。

每个场景只具有一个正面测试用例和负面测试用例是不充分的，场景 4 正是这样的一个示例。要全面地测试场景 4 - PIN 有误，至少需要三个正面测试用例（以激活场景 4）：

输入了错误的 PIN，但仍存在输入机会，此备选流重新加入基本流中的步骤 3 - 输入 PIN。

输入了错误的 PIN，而且不再有输入机会，则此备选流将保留银行卡并终止用例。

最后一次输入时输入了“正确”的 PIN。备选流在步骤 5 - 输入金额处重新加入基本流。

注：在上面的矩阵中，无需为条件（数据）输入任何实际的值。以这种方式创建测试用例矩阵的一个优点在于容易看到测试的是什么条件。由于只需要查看 V 和 I（或此处采用的阴影单元格），这种方式还易于判断是否已经确定了充足的测试用例。从上表中可发现存在几个条件不具备阴影单元格，这表明测试用例还不完全，如场景 6 - 不存在的帐户/帐户类型有误和场景 7 - 帐户余额不足就缺少测试用例。

一旦确定了所有的测试用例，则应对这些用例进行复审和验证以确保其准确且适度，并取消多余或等效的测试用例。

测试用例一经认可，就可以确定实际数据值（在测试用例实施矩阵中）并且设定测试数据。

第 14 页

输入的

金额或 帐面金

选择的额

金额 TC （ 测试用例）ID 号 场景/条件 帐PIN 号 ATM 内的

金额 预期结果

CW1. 809 成功的提款。帐户 场景1 - 成功的提款 4987 - 50.00 500.00 2,000 余额被更新为

498 450.00

场景2 - ATM 内没有

现金

场景3 - ATM 内现金

不足

场景4 - PIN 有误

（还有不止一次输

入机会）

场景4 - PIN 有误

（还有一次输入机

会） 809 提款选项不可用，4987 - 100.00 500.00 0.00 用例结束 498 809 警告消息，返回基4987 - 100.00 500.00 70.00 本流步骤6-输入金498 额 809 4978 - n/a 498 809 4978 - n/a 498 警告消息，返回基500.00 2,000 本流步骤4，输入PIN 警告消息，返回基500.00 2,000 本流步骤4，输入PIN

500.00 2,000 警告消息，卡予保

留， 用例结束 CW2. CW3. CW4. CW5. CW6. 809 场景4 - PIN 有误4978 - n/a （不再有输入机会） 498

以上测试用例只是在本次迭代中需要用来验证提款用例的一部分测试用例。需要的其他测试用例包括：

场景 6 - 帐户不存在/帐户类型有误：未找到帐户或帐户不可用

场景 6 - 帐户不存在/帐户类型有误：禁止从该帐户中提款

场景 7 - 帐户余额不足：请求的金额超出帐面金额

在将来的迭代中，当实施其他事件流时，在下列情况下将需要测试用例： 无效卡（所持卡为挂失卡、被盗卡、非承兑银行发卡、磁条损坏等）. 无法读卡（读卡机堵塞、脱机或出现故障）.

帐户已消户、冻结或由于其他方面原因而无法使用.

ATM 内的现金不足或不能提供所请求的金额（与 CW3 不同，在 CW3 中只是一种币值不足，而不是所有币值都不足）.

无法联系银行系统以获得认可.

银行网络离线或交易过程中断电.

2. 关于评价测试用例好坏的讨论

[原创] 摘自测试时代论坛

Leveret :

第 15 页

现在大家在写测试用例的时候每个人都有自己的特点，但是什么样的一个测试用例才是一个比较好的用例，这是一个比较真实的现象，有这样几个问题大家可以交流一下自己的心得（如果愿意交流的朋友）：系统测试的用例要如何设计才能验证需求？有时候不知道结果的情况下如何预测结果，测试用例应该在不同的阶段下实施的时候应该是独立的。一般在设计测试用例的时候要包括合理输入，不合理输入，预测结果，一般常用的测试用例的设计主要用到：等价类划分，边界值分析法，错误推测法，但是这些都是理论方面的概念，我们在实际设计当中往往并不是按照这些去做的。大家在设计测试用例的时候应该都有自己的心得，如果愿意，可以把自己的观点分享出来大家来讨论。

Seanhe :

我感觉测试用例没有什么好坏之分：）当初的那句话，能发现最多错误的，发现至今为止没有发现的bug的用例就是好的用例，我认为是错误的。

因为，测试不是解决问题，测试用例的好坏不是指单个的用例，而是用例的覆盖度，单个用例再好，所有用例的覆盖度不够，那测试工作还是失败的。所以测试的关键不是用例设计，而是测试范围的圈定，使用的方法，用例的设计只是自然而然的事情。

再说说一开始的用例怎么写，开始肯定有很多不清楚所以用例中很多的内容无法填写，所以我们应该默认用例的书写是个迭代的过程，不同阶段完成不同的内容，执行之前全部完成就可以了。

Leveret :

用例的覆盖率也应该是从单个开始的，而且很多时候发现用例在很多输入输出方面的设计基本都是雷同的，至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？根据测试的类别来考虑还是根据需求方面呢？不过对你所说的用例的书写的迭代过程比较赞同，我们一般测试正式开始之前会对用例有一个评审过程，明白了这个道理之后我想应该会比较轻松的。对设计测试用例的同行来说。欢迎大家分享自己的观点.

Zhybing :

测试用例的好坏，主要看本测试用例是否满足了测试内容的要求，满足了测试内容要求的测试用例就是好的，不满足测试内容要求的测试用例就是不好的. Leveret :

那测试内容是在测试计划里面反映的？按照你的说法。仅仅只是满足测试内容吗？你是这么认为的？

Jackei :

下面列举了我的一些看法：

01.对于“有时候不知道结果的情况下如何预测结果”，个人觉得这个问题比较明确，如果需求无法明确，或者说需求不够明确，则对于该需求的测试用例设计应该推迟，并及时同需求人员进行交流，尽快将需求准确的定义下来。

02.一般在系统测试阶段考虑的测试方法是黑盒测试，这时对于测试用例的设计如何使用那几种方法呢？个人认为可以先使用等价划分的方法划分出等价类，然后使用边界分析法确定下测试数据，最后通过自己以往的厕所经验或者其他的经验来进行错误推测，增补一部分用例。对于这个问题，个人对于现在市面上的很多测试书籍都有负面的看法，很多书提到的一些用例设计的例子都是用windows计算器或者其他单纯用几个数字来作为例子——比如输入域是0-100，让你设计

第 16 页

用例。很多时候我们在进行用例设计时看到的并不是很明显的数字，这些东西都是隐含在业务规则中的，感觉我们现在很多初学测试的朋友这种分析业务规则的能力还是比较欠缺，看不到深层的测试需求。当然这些方法也就应用的很有限了。 03.对于“测试用例应该在不同的阶段下实施的时候应该是独立的”，我也比较赞成。个人认为关键要搞清楚测试用例的作用。作为开发过程，是先有需求人员进行需求的收集，然后是系统分析员对需求整理分析，形成用例或者软件需求规格说明书，之后由系统架构人员进行架构设计，开发人员完成详细设计和编码工作——当然这也未必是一成不变的，但是大体的任务都是这么多。同样，我们看一下RUP中对于测试工作的流程介绍，为什么要把测试设计同测试实现以及测试执行明确的区分开来呢？因为测试工作现在同开发工作已经越来越相似，包括测试需求的整理、测试用例的设计以及测试用例的实现。我们现在很多同行所在的公司可能从人力资源或者从公司的流程上无法保证完全按照这个规范来操作，但是我们可以从RUP中明确测试用例的作用。用例本身就是用来指导实现的，用例实现的时候可以是自动化脚本也可以是手工操作的具体步骤。测试用例是可以同具体的应用程序实现完全独立的，可以不受应用程序具体实现变动的影响。至于为什么我将在下面说明。

04.对于“很多时候发现用例在很多输入输出方面的设计基本都是雷同的”，我觉得这个就可以考虑测试用例的“复用”。其实雷同也是正常的。 05.下面将阐述我个人对于测试用例设计工作的一些看法。

我很赞成 seanhe 对于测试用例迭代开发的观点，现实中我们也是这样考虑的。

测试用例不会平白无故的被设计出来，它是有目的和前提的。个人认为测试用例是用来指导具体测试实现的，包括自动化脚本的实现和手工测试步骤的实现。对于测试用例对测试需求的覆盖，个人认为不是测试用例编写的目的，而是对测试工作的要求——是要求测试用例设计人员的阶段性工作的结果必须符合一定的要求的。测试用例本身是无法保证覆盖需求的。

那么说到了测试需求，这里顺便说说测试需求的确定。leveret 也问到了这个问题——“至于测试范围的圈定，在系统设计阶段我们能考虑周全吗？考虑的出发点呢？”个人认为测试范围的圈定也就是测试需求的确定。

对于一个产品来说，它的开发和测试都不是一次性的，随着开发版本的迭代，测试工作也将继续进行下去，同时，我们对每个版本的测试范围都是不同的。注意，这里有一个关键，也就是测试范围圈定的出发点——软件需求的确定。那么怎样来明确软件的需求呢？——版本。如果希望工作的进度和内容可以明确的定义下来，就首先要考虑版本的确定——软件需求的版本确定。

通过软件需求的版本控制，可以明确每个不同版本的产品中所实现的特性，哪些特性将在以后的版本中实现。这里重点提到的是对于需求也需要使用版本的概念来进行管理。

既然某个版本的软件需求已经确定，那么接下来的开发工作就可以在这个需求版本划定的范围内开展。

测试需求是什么呢？个人认为就是需要测试的内容，它的来源有很多方面。

1.在需求阶段，软件需求规格说明书和用例中对于软件的描述、业务规则的描述就可以整理出我们最早的测试需求，这部分测试需求将完全来源于软件需求，是当前阶段测试工作的一个基础。

第 17 页

不过大家要看到，我们的测试工作从现在开始。

这个时期我们有一个非常非常重要的工作，我们将尝试着进行需求文档的检查。

这里，对于需求文档的检查主要是两个方面：

（1）检查需求文档描述的正确性，愚以为测试人员要对于真实的系统所涉及的业务非常熟悉，比如一个简单的财务软件，那么测试人员本身就要对会计工作熟悉，财务制度熟悉，在检查需求文档的时候不要迷信所谓的“都是用户真实的需求”，这里存在两个问题，一是用户是否真的能正确地描述自己的需求，二是需求人员是否真的能正确地理解需求。另外，还有一个用户的需求是否符合行业规范的问题，如果不符

合，那么是否要确认——这里存在一个隐患，用户可能会在开发的后期突然要求他们自己要走行业规范，让你的需求变动，所以要事先明确好。

（2）检查需求文档描述的准确性。主要是考虑文档中是否存在描述的模糊的地方，对于自己不清楚的问题一定要明确。这个时候是要保证需求的可测试性——我得意思是说保证需求是可以完全为测试工作服务的。再说的具体一点，要保证所有的软件需求都是可以用某种方法来明确的判断是否符合要求的。如果对于某个需求，无法获得一个明确的判断标准，则应该请需求人员对需求进行修改或补充——一个缺乏准确定义的需求，我们可以认为开发人员也无法准确的实现或者实现一个错误的需求，如果在应用程序交付测试时才发现这个问题，带来的后果就因项目而异了。

2.随着开发工作的开展，开发部门的架构设计以及详细设计也将陆续提交，这时候，我们可以根据设计文档来对原来的需求进行增补。注意，这里我们对于设计文档中提到的内容要有选择的采用，只有符合软件需求规格说明书或用例中已经定义的部分才可以用来调整我们的测试需求。而同软件需求不相符的部分，则需要同设计人员和需求人员一起讨论，确定下以哪一个为准，然后调整测试需求。这部分工作其实已经包含了对设计的检查，我们将继续努力尽早的发现缺陷出现的征兆。

3.在应用程序交付后，测试部门开始执行测试。这时很有可能通过一些我们根据测试需求设计的测试用例所没有包含的方法会找到一些缺陷，那么，这部分方法我们也应该整理到测试需求中。

OK，相信说到这里，各位看客也应该可以理解了我的观点。对于一个持续发展的公司或者持续开发的产品，它的所有东西都是要不断积累的。对于测试需求，不仅仅是在一个版本的开发过程中，在不同的阶段进行迭代，在产品的整个生命周期中的不同版本间也是不断迭代的。

既然明确了测试需求，测试用例的考虑也就变成 seanhe 所说的那种自然而然的事情了。我们可以根据不同阶段已经确定下来的那些测试需求来进行测试用例的设计，然后随着开发过程的继续，在测试需求增补或修改后不断的调整测试用例。如果我们从产品的整个生命周期来看，就会发现其实根本没有测试工作终结而测试需求和测试用例维护结束的时候，因为一个版本的结束就是下一个版本的开始。从这个大的范围来看，我们的测试需求和测试用例将永远的不断迭代下去。

啊，今天心情好，比原来那个回复又多写了很多，希望对所有的朋友多可以有些帮助。不过好像有些跑题，本来题目是“关于评价测试用例的好坏”，我还

第 18 页

。

Jackei :

我又想到了一点评价测试用例好坏的因素：

01.易用性：是否方便使用，比如是否可以随便哪个人都可以拿来简单的看看就知道如何根据用例进行测试；

02.易维护性：是否方便维护，特别是当需求或者设计发生变化的时候，是否付出较少的成本就可以完成维护工作；

03.有效性：是否可以保证一个用例在整个产品的一个相对较长的生命周期中可以反复使用，保证有效性。

抛砖引玉，望大家继续补充。

-------------------------------------------------------------------------------------------------------------------

第 19 页

第 20 页

下面，我们就剖析以上问题的同时，探讨一下如何解决这些问题。

性能测试准备

这是一个经常被测试人员忽略的环节，在接到测压任务后，基于种种其它因素的考虑，测试人员往往急于进度，立即投入到具体的测试工作去了，测试、记录、分析，忙的不亦乐乎，工作进行了一半才发现，或是硬件配置不符

合要求，或是网络环境不理想，甚至软件版本不对，一时弄得骑虎难下，这都是没有做好测试准备惹的祸。

那么我们应该如何做好性能测试的准备工作呢？

做软件项目有需求调查、需要分析，我们做测试也一样。在拿到测试任务后，我们首要的任务就是分析测试任务，在开始测试前，我们至少要弄清以下几个问题： a) 要测试什么或测试的对象是谁？

b) 要测试什么问题或我们想要弄清楚或是论证的问题？ c) 哪些因素会影响测试结果？ d) 需要怎样的测试环境？ e) 应该怎样测试？

只有在认真调查测试需求和仔细分析测试任务后，才有可能弄清以上一系例的问题，只有对测试任务非常清楚，测试目标极其明确的前提下，我们才可能制定出切实可行的测试计划。

明确测试目标,详尽测试计划

在对测试需求充分了解的基础上，制定尽可能详细的测试计划，对测试的实施是大有裨益的。测试计划的制定，大多专业的测试书籍多有详述，故本文不再鏊述。

测试技术准备

在目前的大环境下，要求测试人员在短时间撑握所有的软、硬件知识是不太现实的，但平时测试人员应抓紧对测试工具和测试理论的研究，在测试计划中，应给研究测试对象和测试工具分配充足的学习时间，只有在充分撑握测

试工具，完全了解测试对象的前提下，我们才能够实施测试。建力在错误的认识上的测试，既使你再努力，结果也是背道而驰，也很难证明问题，更不用说用这样的测试报告去说服用户。

配置测试环境

只有在充分认识测试测试对象的基础上，我们才知道每一种测试对象，需要什么样的配置，才有可能配置一种相对公平、合理的测试环境（这在性能对比测压中尤其重要）。

考虑到其它因素，如网络锁、网速、显示分辩率，数据库权限、容量等对测试结果的影响。如条件允许，我们最好能配置几组不同的测试环境。

测试数据的获取和处理

第 21 页

在所有的测试中，测试数据的收集工作都是较为困难的，GIS软件更是如此，每一种软件都有它的文件格式，有的软件还有几种格式。在这种情况下，我们只能把第三方格式的数据转换成每一种被测试软件自已的格式。同时，还应对数据作一定的处理，如处理数据冗余，处理显示风格等。如在测试时会更新数据，操作前一定要备份数据。其外，还应评估数据格式和数据量对测试的影响，如有必要，应准备多组数据。最后，一定要检查测试数据的有效性，避免损坏数据对测试结果的影响。

如何开展性能测试

测试前期的准备工作纷繁复杂，做好测试准备工作，已是完成了测试工作的一大半，但要产生一份具有说服力的测试报告，还应正确把握测试的强度，保持测试的一致性，提高测试的精度。

判断软件的好坏，要看软件解决实际应用的能力，只有在一定的测试强度下，才能测试出各种软件资源的消耗率，软件运行的速度，软件的稳定性。通过对比在不同的测试强度下，不同软件每一个功能模块解决实际问题的能力和

软件运行的效率，我们才可能判断出不同软件的每一个模块的强弱，甚至于整个软件的优劣。

性能测试开始后，所有参数的输入都应遵循统一的标准，无论是哪一个环节，哪怕是一点点偏差，都应立即纠正，觉不能心存侥幸。要特别注意外部环境对测试结果的影响，如果在整个测试过程中，外部境不一致，如网速、机器

内存使用率不一样，就有可能导制测试结果与实际情况有出入。

如何总结性能测试

对测试的终结，实际就是对测试数据的分析和处理。我们测试工作做的再好，如最终到用户手中的是一堆杂乱无章的数据，那也是美中不足。

首先，我们最好从所有的测试数据中，筛选出具有代表意义的数据，做出统计图，然后和开发人员一起，认真分析数据，找出软件存在的问题，得出测试结论。 大多数用户，真正需要的就是科学、客观的测试结论。

结论

各种软件性能测试，范围大小不同，强度高底有别，但只要本着认真、客观，科学的工作态度，遵循本文论述的方法，做好测试工作是不难的。

本篇文章主要谈的是软件性能测试方面的问题，相信对其它方面的软件测试也有一定的借鉴作用。

第 22 页

测试员电子期刊

www.ltesting.net

析分陷缺件软．1[原创] 作者：alan

通过测试和其他形式的软件质量审查活动而发现的偏差，统称为软件缺陷。我们通常说到的 bug 就是软件缺陷的一种，是隐藏于代 码中的问题，它可以通过软件测试，代码的走查形式而加以发现。在本文中，我们现就 来进行分析，为了表述方便称为缺陷分析。 这里提醒大家注意的是，缺陷的含义较广，不同类型的缺

陷需要用到不同的分析方法。

什么是缺陷分析 ？

缺陷分析本质上是对缺陷中包含的信息项进行收

集，汇总，分类之后使用统计方法（或者分析模型）得出分析结果。缺陷分析得出的结果可以用来度量（软件）开发过程中各段中工作产品的质量，了解缺陷集中的区域，明晰缺陷发展趋向。对于软件过程的改进，软件产品的发布来说具有十分重要的参考价值

缺陷数据的收集

在我们提交缺陷报告的时候，实际上就是在记录一些必要的信息项。在不同的软件生产企业中，需要记录的信息项是大相径庭的。以下是分析缺陷活动中必须收集的一些数据项目

第 23 页

缺陷提交时需要收集的信息

1 缺陷的严重等级 2 缺陷所在的模块 3 缺陷发现的时间 4 缺陷所在的版本号 5 缺陷的发现者

6 负责修改缺陷的工程师

缺陷关闭时需要收集的信息

1 缺陷关闭的时间 2 关闭缺陷的版本

3 修复缺陷而改动的代码行数

4 产生缺陷的根本原因 （例如 ：需求，分析，编码，软/硬配置）

分析点

1 缺陷的发展趋势

缺陷的发展趋势包括新发现缺陷数量增长趋势和关闭缺陷数量的增长趋势。

对于软件产品发布而言，发展趋势图是辅助决策的重要依据。一般来说，软件发布的必要条件是新缺陷的数量增加呈下降趋势，见下图。

Bugs

Opened/Closed

500

400

Bugs Found/Fixed

300

200

100

02004-4-2

2004-4-9

2004-4-16

2004-4-23

2004-4-30

Date Opened/Inactive

第 24 页

缺陷产生原因分布图

该分布图是缺陷分析中最为重要的一张图表，因为它可以直接反映出各软件工程活动的质量，为软件过程的改进提供直接的参考数据。一般来说，缺陷产生的根本原因划分的越细致，分析的结果就越精确。 见下图：

第 25 页

测试员电子期刊

Bugs

Root Cause Breakdown

Standards

www.ltesting.net

5%

但当我们发现需求中出现的缺陷比较多的时候，在未来的项目中我们可以通过需求评审，需求变更控制来减少该种缺陷的数量，以起到软件质量保证的目的。同样如果我们发现软件设计过程中产生的问题比较多，那么就可以通过加强软件设计阶段中的审查活动来保证设计的质量。

3 源代码修改趋势图和模块分布图

源代码修改数量趋势图可以为回归测试风险分析和软件发布提供参考。源代码修改的数量越多，那么代码产生的负作用的风险就越大，为了规避风险，回归测试的强度就需要相应的加强。同样的道理，如果某一个产品的源代码修改数量呈上升趋势的话，那么它是不适合现在发布的 。

----------------------------------------------------------------------------------------------------------------------

第 26 页

测试员电子期刊

www.ltesting.net

1. 信息反馈

1、 本电子期刊的封面设计、版面设置有何建议？ 2、 本电子期刊中各文章内容的质量如何？ 3、 本电子期刊中您最喜欢的文章？

4、 你最希望在本电子期刊中看到哪方面的测试内容？ 5、 读者个人信息简录：

性别：

从事测试工作年限： 测试团队人数：

最关心的那种测试类别(功能或性能或其它)： 以何种方式知道测试时代的：

感谢您花费宝贵的时间来填写对本电子期刊的建议或意见，请将您的反馈信息发至 [email protected]

。我们会认真对待每一封来信，并会衷心采

纳每一个有意义的建议。感谢大家对测试员电子期刊的支持与厚爱。

稿投迎欢 .2期刊稿件要求：

1. 稿件要求含有标题、作者姓名、联系方式及作者简介(如：单位、个人爱

好、联系地址等可根据本人要求).

2. 属于摘录或拷贝文章，请注明文章出处及原创作者。提倡大家多发表原创

性文章.

3. 文章摘要（不超过200字）. 4. 关键词（3-5个）.

5. 正文, 字体为宋体5号字.

6. 稿件格式为Microsoft Word 格式，请勿在稿件中使用标题、分页符等排版设置。

第 27 页

测试员电子期刊

3. 加入我们

www.ltesting.net

测试行业的发展需要依托测试行业的同仁共同来推动，测试时代是一个开放的

平台，在这个平台上需要更多的有志于测试行业的朋友共同来建设，在这个平台上我们已经筹建了测试时代论坛，Blog社区，测试员电子期刊，测试时代工作室，测试交流会等一系列的活动，这么多的活动急需大批的志愿者加入，共同携手推进行业的发展。

在这个大家庭里，你将会得到业内最新的测试资讯，和众多的测试精英分享成

功的喜悦，共同学习前沿的测试知识，在测试的最前沿感受行业的发展与进步。

如果你也和我们一样对测试行业充满憧憬，就请赶紧加入我们，让我们共同努

力，为测试行业添砖加瓦。

请将您的大致简历和预计参与的活动发给[email protected]

，会有专人与

您联系。

测试时代是一个以测试行业一线工作者自发的民间组织，自从成立以来一直以“普及软件测试知识，共享软件测试技术；交流软件测试经验，提高软件测试地位”为宗旨，为广大测试人员创造交流的机会，提供交流的场所，希望通过提高测试人员的技术来推动整个测试行业的发展。

测试行业在中国起步较晚，大部分测试人员都一直在独自摸索，渴望互相交流却苦于没有机会。针对这种情况，2002年7月测试时代的一位核心成员在北京自发的组织了全国第一次真正面向测试人员的交流会。为了将这种面对面的交流活动继续下去，测试时代应运而生。这次交流会在整个测试行业引起了极大的反响，随着北京地区测试交流会的不断召开，掀起了全国测试人员交流的高潮，以上海为中心的华东地区、以深圳为中心的广东地区等都相继组织了本地区的测试交流会。迄今为止，测试时代共举办了18次测试交流会，前后有近2000人次参加，其间还有从武汉专程赶来参加的同行，是全国成立最早、举办次数最多、参加人数最多、影响最广的测试交流会。

测试交流会主要采取了以主题演讲为主、问题讨论为辅的活动形式。为保

第 28 页

证测试交流会的质量，主讲人一般都是由在测试行业有一定的从业经历、对测试技术有一定的见解的同行担任，测试时代先后邀请了Rational公司（著名软件测试工具公司）技术支持、北大方正技术研究院软件工程部部长等同行来交流会与大家交流。演讲的内容有理论“软件测试流程”，有实践“rational工具全面测试方案”，有理论与实践相结合“测试流程在软件工程中的实践”。交流会是以交流为目的，在大概一个半小时的演讲后，还有历时两个半小时的问题讨论时间，大家如有问题可与主讲人继续交流，也可以根据需要与其他同行自由交流。由于演讲的内容切合实际，对于实际工作有指导性的作用，而且问题讨论也能极大限度的满足广大同行迫切需要交流的愿望，使测试交流会的影响逐渐广大，逐步被更多的同行了解和接受。

随着时间的增长，参加交流会的人数越来越多，为了更好的满足一批有丰富经验的同行更深层次的交流愿望，测试时代又率先举办了深层测试交流会并开通了全国性质的深层交流论坛。深层测试交流会聚集了一批有一定工作经验，对测试技术有一定见解的测试人员，在每次会上由一到两个同行根据自己从事的工作或感兴趣的技术提出自己的议题，阐明自己的观点，提出自己的疑问。其他同行根据自己的实际工作对此议题或观点进行讨论，由此做到真正对等的思想交流。

由于测试交流会仍有地域的限制，为了让全国同行更好的了解交流会的情况、共享交流会的成果，以更大范围内的推广测试技术，真正做到交流无限制，测试时代于2002年年底开通了测试时代网站www.ltesting.net 主要栏目有：

交流会信息，发布交流会召开信息，提供历届交流会主题演讲资料与讨论总结的下载。

测试时代工作室，介绍测试时代自主开发的WEB测试工具Web Runner、Web Valiadator、Web Validator Professional、Web Checker、Web PDT，并提供免费下载，专门进行测试方面的图书翻译与编写、测试工具的研究与开发等工作，更好的满足广大同行的学习、工作的需求。这些工具由于是测试人员自己开发的产品，许多同行在实际工作中使用后，一致反应该工具使用方便，能真正解决测试人员的一些实际问题并最大限度的将测试人员从烦琐的工作中解决出来。根据同行反馈的

第 29 页

一些建议，测试时代正在对该测试工具进行修改升级，近期将会陆续推出。 下载中心，以最快的速度提供全国测试同行的优秀原创测试文章。

测试员电子期刊，期刊根据测试技术的特点将文章分为测试基础、功能测试、性能测试、测试管理五大类，经过编辑的精心组稿、选稿、编辑，极大限度的弥补了论坛上知识不够系统、连续的缺憾，同时也满足了从测试新鲜人到测试管理者不同角色人群的学习和交流的需求。目前已经发布了四期。

测试时代论坛，各个栏目分布为：在测试技术方面有测试流程管理、自动化测试、WEB测试、 Rational工具、MI工具等分论坛，测试交流方面有深层测试交流、测试交流会—全国交流会论坛、测友红茶坊-华东地区交流会论坛等分论坛。自论坛开张以来，测试时代就立志将测试时代论坛做成一个能真正解决测试人员问题的场所，不以论坛栏目多、提供破解文件来吸引人气，摈弃一切浮华以实际、实用为主旨，得到了广大同行的赞成和支持。测试交流会分论坛除了让同行更快的了解交流会信息外，还鼓励各地同行筹办本地的见面交流会，并尽可能的提供帮助，目前西北地区的测试交流会正在积极招募中。因为测试时代论坛是测试人员自己主办的论坛，内容更贴近测试人员的需要，所以论坛现有注册成员已经达到7000多人，在国内的影响也越来越大。

测试时代在测试行业的知名度越来越大，同行对它的期望也越来越高，为了更好的“普及软件测试知识，共享软件测试技术；交流软件测试经验，提高软件测试地位”，测试时代一直在努力改进，不断推陈出新。目前测试时代网站已经进行了新的改版，推出了测试技术方面都很专业的测试网站。另外测试时代论坛开张已近一年多，积累了不少优秀的原创文章，还有很多有志于发展测试行业的同行的积极加入，测试时代已经初步具备出版电子测试期刊的能力，现在测试期刊小组已经成立，第四期期刊已经发布。

在以后的日子里，有测试时代的努力、全国同行的支持，相信测试时代的路将会越走越好！

我们的宗旨是：

第 30 页

测试员电子期刊 www.ltesting.net 普及软件测试知识

共享软件测试技术 交流软件测试经验 提高软件测试地位

第 31 页

:[email protected]箱信至请，议建和稿投迎欢期刊所登文件版权所有，抄录、转载请注明