• 空间首页
• 空间管理
• 51Testing软件测试网
• 站点论坛
• 添加我的日志

我的最新日志

• (转载)关于文档的测试清单

  2008-11-10

  产品说明书属性检查清单

  　　1.完整：是否有遗漏和丢失？完全吗？单独使用是否包含全部内容？

  　　2. 准确：既定解决方案正确吗？目标明确吗？有没有错误？

  　　3. 精确：不含糊，清晰。描述是否一清二楚？还是自说自话？容易看懂和理解吗？

  　　4. 一致：产品功能描述是否自相矛盾？与其他功能有没有冲突 ?

  　　5. 贴切：描述功能的陈述是否必要 ? 有没有多余信息 ? 功能是否满足的客户要求 ?

  　　6. 合理：在特定的预算和进度下，以现有人力，物力和资源能否实现 ?

  　　7. 代码无关：是否坚持定义产品，而不是定义其所信赖的软件设计，架构和代码 ?

  　　8. 可测试性：特性能否测试 ? 测试员建立验证操作的测试程序是否提供足够的信息 ?

  　　产品说明书用语检查清单

  　　说明：对问题的描述通常表现为粉饰没有仔细考虑的功能 ---- 可归结于前文所述的属性。从产品说明书上找出这样的用语，仔细审视它们在文中是怎样使用的。产品说明书可能会为其掩饰和开脱 , 也可能含糊其词 ---- 无论是哪一种情况都可视为软件缺陷

  　　9. 总是，每一种，所有，没有，从不。如果看到此类绝对或肯定的，切实认定的叙述，软件测试员就可以着手设计针锋相对的案例

  　　10. 当然，因此，明显，显然，必然。这些话意图诱使接受假定情况，不要中了圈套。

  　　11. 某些，有时，常常，通常，惯常，经常，大多，几乎。这些话太过模糊， " 有时 " 发生作用的功能无法测试。

  　　12. 等等，诸如此类，依此类推。以这样的词结束的功能清单无法测试，功能清单要绝对或者解释明确，以免让人迷惑，不知如何推论。

  　　13. 良好，迅速，廉价，高效，小，稳定。这些是不确定的说法，不可测试。如果在产品说明书中出现，就必须进一步指明含义。

  　　14. 已处理，已拒绝，已忽略，已消除。这些廉洁可能会隐藏大量需要说明的功能。

  　　15. 如果 ... 那么 ...( 没有否则 ) 。找出有 " 如果 ... 那么 ..." 而缺少配套的 " 否则 " 结构的陈述，想一想 " 如果 " 没有发生会怎样。

  　　简明性、明确性：在软件开发各个阶段所编写的各种文档的语言表达清晰、准确、简练，适合各种文档的特定读者即提供的用户手册要对系统中每部分的在各个阶段的功能有明确。

  　　描述，对于工作流程也有明确叙述，让用户很清楚的知道自己处于流程中的什么位置，在做什么，接下来该做什么或者应该怎么做。

  　　内容完整性：按照软件开发流程编制相应的文档，提供用户操作手册及在线帮助。

  　　用户操作手册要全面、细致的每个模块操作步骤以及每步所要达到的目标。

  　　在线帮助要详细列出用户在工作中可能遇到的问题，并针对每个问题提出详细的解决方案，要充分起到“实时”给予帮助的目的。

  　　准确规范性、可读性：用户手册、用户操作手册以及在线帮助要做到用语规范，准确，可读性，符合客户要求的编写规范标准，使用户操作起来简单明了，例如在某环节出现了问题，用户能够利用在线帮助很快且顺利的找到相应的帮助文档，最终达到解决的目的 。

  　　可追踪性：指在不同文档的相关内容之间或则同一文档某一内容在本文档中的涉及范围可追踪性。

  　　自说明性：各个阶段中的文档能独立、清楚的表达出对应于该文档所处的阶段而开发出的软件产品所具有的功能。

  查看(20) 评论(0)

• (转载)自定义QTP保留对象的神话

  2008-11-10

  摘要：QTP包含了很多保留对象，其实我们可以将所有使用的方法封装成DLL文件，然后通过COM机制注册到系统中，注册自定义保留对象机制来完成对象的定义。

  　　关键字：QTP保留对象，COM机制

  　　大家在使用QTP的过程中经常会用到函数或过程，一般情况下大家将这些函数写到一个文件中如：xxx.vbs中，或者直接封装成DLL文件，通过QTP的函数(ExecuteFile)来载入这些已经声明的函数和过程，然后进行具体调用。这样对于大家的使用并不方便和快捷，所以本人就展开了对于自定义QTP保留对象的研究。

  　　一、在VB环境下新建一个DLL文件

  　　1、打开VB6.0环境，新建如下工程
  

  

  图1.1

  　　2、简单设计一个函数和一个过程，代码如下：

  ‘***************************** ‘函数功能：比较两个数是否相等‘输入参数：Para1、Para2 ‘输出参数：弹出提示 ‘***************************** Public Function CompareValue(Para1, Para2) If Para1 = Para2 Then MsgBox "输入的两个参数相等", vbInformation + vbOKOnly, "提示" Else MsgBox "输入的两个参数不相等", vbInformation + vbOKOnly, "提示" End If End Function

  3、设置工程属性

  　　

  

  　　图中1.3

  　　上图所示：

  　　红色标注1、表示类名，设置为：ClassName，注册自定义保留对象用到。

  　　红色标注2、表示工程名，设置为：PrjName，注册自定义保留对象用到。

  　　4、生成文件：PrjName.dll

  　　点击文件——>生成 PrjName.dll

  　　二、 注册DLL文件为标准的COM组件

  　　如果文件放到F盘下，那运行：regsvr32 f:\PrjName.dll就可以完成注册，撤销注册运行：regsvr32 /u f:\PrjName.dll。注册完成后，注册表HKEY_CLASSES_ROOT中查询PrjName.ClassName如下：

  　　

  

  　　

  

  　　 你可以点击每一个文件夹查询选项的值。

  注册自定义QTP保留对象

  　　将自己的所自定义的保留对象注册到注册表中，这个并不是QTP所包含的保留对象，而是自己设计的保留对象，用VB写的类和函数是可注册的COM对象。操作如下：

  　　打开注册表，定位注册项：

  

  
  图3.1

  　　添加一个名为“MyObject”的注册项；

  　　添加两个“REG_SZ”类型的注册项，分别为：

  　　ProgID：准备创建的COM 对象的ID，在这里就是Dictionary 对象所对应的COM 对 象名“PrjName.ClassName”。这个就是前面提到的VB中的工程名、类名。 UIName：QTP指向保留对象的名字，在这里输入“MyObject”

  　　添加一个类型为“REG_DWORD”的注册项；

  　　VisibleMode：设置DWORD 值为2，用于控制自动完成（auto-complete）和代码智能感知（intelligence）。

  　　使用自定义QTP保留对象

  　　做完以上设置后，重新启动QTP，然后分为两种使用方式

  　　在关键字视图中调用

  　　在Insert菜单中选择Step Generator，然后选择Utility Objects，你可以在Object中看到我们定义的保留对象，如下显示：
  

  

  图4.1

  　　选中后，你可以在Opertion中看到我们定义的方法，你可以选择某个方法使用。

  在专家视图中调用

  

  图4.2

  　　便捷的控制自动完成（auto-complete）和代码智能感知功能，我们可以大声的说，QTP的功能我们也可以实现了。

  

  图4.3

  　　方便的参数说明提示，使你更容易理解参数说明的意义，使用起来一目了然，你不用了解函数库里面封装的具体内容和死记函数名称，你只需输入”.”，QTP就会自动给出你友好的提示。

  

  图4.4

  　　小结

  　　通过以上图示我们完成了自己封装的DLL函数的自动显示和调用，这样不仅减少了我们设计代码的时间，更大的好处是给开发测试代码人员提示功能，往往一个项目中，公用函数库都是由一个到两个工程师来开发完成的，如果做成VBS或者DLL文件，那我们每次调用的时候都需要加入如下语句来完成库的加载：

  ExecuteFile "F:\xxx.vbs" ‘装载VBS文件 Extern.Declare micLong, "Beep", "kernel32.dll", "Beep", micLong   ‘装载dll文件 Extern.Beep 500

  　　以上两条语句不仅费时，而且点击“.” 后也不能控制自动完成（auto-complete）和代码智能感知，并且开发脚本人员必须特别熟悉库中的函数和过程的具体含义才能使用，库函数多了，开发脚本人员使用某个函数时，都需要进行查找，这样既不方便也不快捷，而且会大大增加了项目的工作量，所以通过我们的研究方法，完全可以按照自定义QTP保留对象来完成函数库的整合，这样开发脚本人员在使用的时候只需要知道我们的保留对象名称即可。

  　　总之，本文介绍了自定义QTP保留对象和注册COM对象对象的方法，其实QTP所支持的方法不仅仅如此，还有很多东西值得我们探索和研究，在自动化测试的道路上，只要我们大家为了一个共同的目的，提高自动化测试规范和流程，实现代码更高的效率，那我们会创造一个又一个神话！！！

  查看(28) 评论(0)

• （转载）如何编写更好的测试用例（四）

  2008-11-07

  用例学习

  　　这是一个故事，即五个软件质量分析师如何学会好的测试用例达到一个可测量的区别。他们经验丰富，自成管理小组，对于测试用例看起来应该像什么，每一个人都有不同的想法。一个用例罗列成从几十个杂乱、冗长的指导，到一个根本没有指导的一个矩阵。测试者是对软件几乎没有信心的商业用户。他们渴望测试，但经过一个星期后，花费的更多的时间是在试图找出做什么，而不是在实际测试中，他们非常无奈。他们的经理最后告诉分析师，他们已投入了他们议定的大量的时间，再没有更多的时间给他们了。在该点上不到一半测试才被执行。就这些，许多结果还只是个问号。一个测试者甚至在测试中写下愤怒的言辞。分析师表现出的测试者只是抱怨者，而不是很聪明的。

  　　在这痛苦的周期中，分析师遇到新的测试经理。她看着测试用例，并开始了一个培训和辅导方案。她展示了好的测试用例的模样，给了他们一份核查表，并让小组在下一个软件模块中用它来写用例。该用例将在两个月后安排测试。她一个接一个接触了他们每个人并在如何改善方面给了他们具体的帮助。每一个编写者开始产出达到标准的用例。第一个星期的编写进展很慢，但在两个月期间的最后，他们都达到生产率的目标。在下一个测试周期，用例就较短，每一个都有明确的目的和准确的通过或失败的标准。尽管如此，分析者仍担心测试将又一次是棘手的。

  　　测试者开始预期另一个负面的经历，但很快改变了他们的态度。他们发现，他们可以很容易地完成每一个用例，无需拨打电话或来到编写者的小隔间。他们的信心增长，而且有些人说，他们已害怕这个软件的改动，但现在他们可以看到它明显好于他们所使用的。这个话传到了销售人员，使他已经迫切地希望了解该软件。他们的经理来了，问是否他们也可以测试。测试经理在该周期并不需要更多的测试者，但和他们签约了下一个周期。技术编写者问是否他们也可以拥有用例的复件。

  　　测试经理保持着一些指标的提高。当她最初到来时，分析师一天花费2到3个小时和测试者排查不好的用例。他们安排的测试时间是每个测试用20分钟，而事实上他们平均用时约45分钟。除了与测试者花费的时间外，在当前的周期中，一些分析师还花费一个小时或两个天时尝试修改用例，而不是进行他们安排的工作 – 为下一个模块写用例。

  　　在培训和标准确定后，下一个测试周期的指标看上去更好。没有分析师再一天花费超过一小时来帮助测试者。即使有更多的测试，因为简短的测试用例的标准，测试者可以在20分钟内完成测试，而测试往往提前一天完成。在项目结束时，分析师和测试者已确信会加快发表一个月。

  附录A

   测试用例核查表

   质量属性

   ● 精确的 - 只测试描述中所说的将测试的内容。

   ● 经济的 - 只有对于它的目标所需要的步骤

   ● 可重用的、自立的 - 不管是谁测试它都是相同的结果。

   ● 适合的 – 不仅对当前而且对今后的测试者

   ● 可追溯的 – 对应到一个需求

   ● 可自我清理的 - 返回测试环境到未使用状态

   结构和可测试性

   ● 有一个名称和编号

   ● 有一个明确的目标，其中包括什么需求将被测试

   ● 有一个测试方法的描述

   ● 指定设置信息 - 环境、数据、前提测试、安全访问

   ● 进行的活动和预期结果

   ● 陈述需要被保存的任何证据，如报告或抓屏

   ● 留下干净的测试环境

   ● 使用生动的用例语言

   ● 不超过15个步骤

   ● 矩阵不需要超过20分钟的时间来测试

   ● 自动脚本用目标、输入、预期结果来注释

   ● 如果可能的话，设置提供前提测试的替代品

   ● 与其他测试处于正确的商业场景顺序中

   配置管理

   ● 使用命名和编号协定

   ● 以指定的格式、文件类型保存

   ● 对应版本和受测软件相匹配

   ● 包括用例需要的测试对象，如资料库

   ● 存储为可读取形式

   ● 以受控访问的形式存储

   ● 存储在网络备份操作处

   ● 现场外存档

  附录B

  附录C

  　矩阵模

  查看(27) 评论(0)

• （转载）如何编写更好的测试用例（三）

  2008-11-07

  用克隆提高生产率

  　　克隆测试用例的意思是用一个测试用例塑造另一个测试用例。如果一个测试用例适合一个分步用例的需要，同时有很容易被取代的变量，那么该用例是一个很好的克隆候选者。例如，您可能有一个维护一个供应商数据库的测试。很多，但并非所有的步骤，也将适用于托运人数据库。当你通过需求或原型、策划知道该软件的功能以相同的方式工作，您可以克隆测试用例。用克隆方式编写它们并不意味着它们需要一起被测试。您可以象克隆测试用例一样克隆步骤。

  　　文字处理和测试创作软件支持克隆功能，如“Save As”、“Copy”和“Replace。”校对这些用例非常重要，以确保所有原有的提述在克隆中被取代。您还可以在储存的文字和宏上节省时间，但不要试图以牺牲精度为代价使一个尺寸适合所有情况。环顾你的项目以获得克隆的机会，如其他人的用例、用户手册或桌面帮助教程。它们可能正在寻求和你交换测试用例。如果您是管理一个编写组，保持编写者目前的测试资料库，使他们能输送和分享用例。

  　　矩阵也可以克隆，特别是如果组织安排一节是相同的。变量将在字段的名称和数值方面改变。再次，请务必校对新版本。

  　　用测试管理软件提高生产率

  　　软件设计成支持测试创作对编写测试用例是单纯的最大生产率的推进者。它在文字处理、数据库或电子表格软件方面具有这些优势：

  　　● 使编写和概述更容易

  　　● 帮助用例和步骤的克隆

  　　● 易于添加、移动、删除用例和步骤

  　　● 自动编号和重编号

  　　● 易于遵循模板来打印测试

  　　测试创作通常包含在现有的测试管理软件中，也可以定制编写。测试管理软件通常包含更多的功能，而不仅仅是测试创作。当您作为它们的代理而购买时，它们提供了大量的价格优惠。如果您正选购测试管理软件，它应该具有上面所列出的一切可用优点，同时附加了额外的功能：

  　　● 以相同的格式输出测试

  　　● 多用户

  　　● 跟踪测试编写进展、测试进展

  　　● 跟踪测试结果，或转向数据库或缺陷跟踪器

  　　● 连接需求和/或创建覆盖矩阵

  　　● 建立由用例组成的测试集

  　　● 允许灵活的安全性

  错误和挑战

  　　七个最常见的测试用例的错误

  　　在每一个编写者的工作中，测试用例缺陷将集中围绕在某些编写错误。如果您正在编写用例或管理编写者，不要等到找到这些错误集前所有用例都已做出。应该每隔一两天就审查用例，寻找使用例难以测试和维护的故障。你将发现的可能是，提高的机会集中在最常见的七个测试用例错误之一：

  　　1. 制作用例太长

  　　2. 不完整的、不正确、或不连贯的组织安排

  　　3. 遗漏某一步

  　　4. 命名的字段已改变或不再存在

  　　5. 不清楚测试者或系统是否做出某活动

  　　6. 不清楚通过或失败的结果是什么

  　　7. 清理失败

  　　为好的测试用例对应挑战

  　　即使您使用最好的技术和标准，面对每一个测试编写工作，你还必须克服同样的挑战。让我们看看对于测试编写面临的共同挑战，并看到它们如何才能通过响应被管理，挽回了更好的质量。典型的挑战通常是强加于项目一级，而且必须在测试管理一级响应。如果它们强加于测试管理一级的编写者，编写者应做出响应。

  　　挑战：需求变化

  　　响应：

  　　1. 最好的防范是被通知到。在编写用例前，在每一个状态上，找出需求变化最大的风险所在。战略上何种用例会和不会受变化的影响。首先写下那些不会的。

  　　2. 建立以后你会返回来并填写的变量或“决定”。

  　　3. 请务必使预算人知道修改已经写好的测试用例的成本。量化每个用例花费多少。

  　　4. 让项目管理设定优先事项，哪些用例应当编写或修订。让他们看到你不能做所有的用例，并请他们来决定他们在哪里有最大的风险。

  　　5. 发表未经修改的不完全正确的测试用例。让测试者标出什么已改变。安排更多的时间来测试每一个用例，加上维护测试时间。

  　　挑战：安排变化

  　　响应：

  　　1. 如果测试的日期提前，让管理方参与测试用例将如何受到影响的选择。在不断变化的需求的挑战中，让他们选择他们想要什么风险。

  　　2. 在工作人员必须作为生产力前，只有时间允许一至二周的训练，才能增加人员，同时只能是您有某人来指导和审查他们的工作。

  　　3. 改变编写用例的顺序，使您首先写那些将优先被测试的。尽量保持用例领先于测试者。

  　　4. 在只有一个目标和组织安排下，即需求正在被测试时，您可以减少测试用例。这不是象临时测试一样糟糕，但管理方应该知道结果并不如用例完成后那么可靠。安排更多的时间来测试这种测试用例，同时安排时间在测试后完成用例。

  　　5. 提议让编写者做测试，并在他们测试时编写。安排更多的时间来测试和测试后完成编写。

  　　挑战：人员更替

  　　响应：

  　　1. 新的人员需要了解目前测试项目的目标、时间安排和组织，如果可能的话，这些应该以书面形式表示。口头介绍会失于混乱。

  　　2. 新的人员应集中于了解软件的业务使用，然后集中于需求和原型。他们可能会写更少的用例，但用例将是正确的。

  　　3. 新的人员应参加有关标准的操作培训，用许多如何应用标准的实际例子。他们的工作首先应被仔细检查。

  　　4. 尽量安排新的人员在一个良好的技术领域，该领域适合他们将要编写的用例。
  测试用例资产

  　　保护测试用例资产

  　　保护测试用例价值的最重要的活动是维护它们，使它们可测试。它们应该在每一测试周期后被维护，因为测试者会象发现软件缺陷一样，发现用例的问题。当测试安排被建立时，时间应分配给测试分析员或编写者来修复用例，此时程序员在修复应用程序缺陷。如果它们没有被修复，测试者和编写者将浪费时间在下一周期，来搞清楚是测试用例还是软件的错误。

  　　防止测试用例因缺少的版本和储存失败而丢失或损坏，整个的目的是使这些用例可重复使用。用例的配置管理（CM）应当由组织或项目来处理，而不是测试管理。如果组织不具备这种水平的过程成熟度，测试经理或测试的编写者需要提供这方面支持。无论是项目或测试经理都应该用下面的配置管理标准，来保护宝贵的测试用例资产：

  　　● 命名和编号约定

  　　● 格式，文件类型

  　　● 版本

  　　● 用例需要的测试对象，如资料库

  　　● 只读存储

  　　● 存取控制

  　　● 异地备份

  　　测试管理需要有一个所有测试用例的索引。如果CM不提供，就创建自己的索引。资料库可以对关键项目、软件、测试名称、编号、和需求检索。有一个全文检索功能将更好。

  　　利用测试用例

  　　测试用例作为开发资产已具有超越测试的生命。他们表示出用平白的英语编写软件如何工作的一个完整的图画。即使重点是破坏性的，他们也必须证明所有业务场景按需要工作。通常用例是写给测试者的，测试者是商业用户，所以用例使用真实的世界语言和条目。一套用例对于正在努力学习或出售软件的其他人具有巨大的价值：

  　　● 商业用户

  　　● 技术编写者

  　　● 桌面帮助技术员

  　　● 培训师

  　　● 销售和市场人员

  　　● 网站管理员

  　　所有这些人看到软件取得成功会获得利益，所以也是潜在的测试人员。依靠组织，在测试编写者和这些组之间良好的意愿和开放的沟通下可以大大加快出品和发表的时间。

  　　综述

  　　教授良好的编写技术和建立测试用例标准的过程本身就是一个资产。这从来不是静态的，而必须是动态的教授、运用、审查、测量和改进。本文简要涵盖测试用例质量的过程和标准是什么，如何将其应用到各种测试用例中，如何利用它们来改善可测试性和生产率，如何解决对于测试用例质量的共同面临的挑战，以及如何保护测试用例资产。

  查看(18) 评论(0)

• （转载）如何编写更好的测试用例（二）

  2008-11-07

  选择一个测试类型

  　　对一种类型的测试用例的偏好超过另一个，多起因于机构的文化和观念，而不是什么最适合于软件和测试计划。“我们一直这样做”已和一些难改的谬论相结合：

  　　谬论之一。分步测试用例要花太长的时间来编写。我们负担不起。

  　　事实：他们可能会或不会需要较长的时间来编写，粒度小使他们健壮和易于维护。他们是唯一充分测试一些功能的方法。

  　　谬论之二。矩阵始终是最好的选择。选用它吧。

  　　事实：一个长期存在的问题是如何把一个矩阵和适当的组织安排信息放在一起。这一组织安排信息往往被忽略，或更糟糕的是，如果输入的不同的组织安排或分类不能强加成一个带有类似组的矩阵，他们根本就不能被测试。

  　　谬论之三。高技术是最好的。如果您可以自动化测试用例，就去做它。

  　　事实：使用自动化测试的决定应基于许多因素。

  　　谬论之四。我们没有时间编写手工测试用例。让我们自动化测试用例吧。

  　　事实：自动化测试用例的创建需要比其他两种类型更长的时间。

  　　如果一个有支配权力的人不懂装懂的说出这些谬论，一个不成熟的组织（一个更多地依靠杰出人士而不是过程的组织）是最容易认为这些谬论是正确的。他们的质量之路将是一个漫长的道路。他们会继续误解测试用例，直到他们经受打乱的时间表或经费损失为止，显然他们经受的这些起因于不良的测试。

  　　为工作使用最佳的测试用例类型的另一个约束是在文字和数字表达之间的接近状况。如果你擅长于一个或另一个，你可能更喜欢你可以直观地去做的测试用例类型。分步用例倾向于更多的文字，而矩阵倾向于更多的数字。良好的培训应建立起对于使用所有类型的用例的了解和信心，对于每一处它都是最有成效的。然而，个人偏好是一个不可忽视的因素。如果你是一个经理，你需要通过教育和范例克服困难。

  　　往往最有成效的途径是使用所有三种类型的用例。前两个用于单元、集成和系统测试；而自动化脚本用于回归测试。

  提升测试用例

  　　提高测试用例的可测试性

  　　准确的说，可测试性的定义是指易于测试。易于测量执行测试需要多久，在测试过程中测试者是否需要获得说明。准确意味着，如果测试者遵循指导，那么通过或失败的结果将会是正确的。

  　　用语言提高可测试性

  　　测试步骤应该编写在生动的用例中。告诉测试者做什么。例如：

  　　● 做这个。做那个。

  　　● 浏览购物车页面。

  　　● 对比车中物品和屏幕捕获的物品。

  　　● 点击<OK>。

  　　应始终明确的是，是测试者做一些事，还是系统做它。如果一个测试者读到， “按钮被按下，”这意味着他或她应该按下按钮呢，还是它意味着已经按下后验证系统显示它？搞乱测试者最好的一种办法是混淆活动和结果。比如，活动总是在左侧，结果在右侧。测试者做什么总是一个活动。系统显示什么或者做什么始终是一个结果。

  　　如果我们知道一个对象的内外，养成一个简单的习惯，就是以不同的方式提及相同的事情。测试语言要一丝不苟地命名显屏、字段、服务器、Web网页、或其他测试对象。在一个开发团队，我们习惯于在某些对象甚至是原型以前，一般就提到它，如“电子邮件答复屏幕，”而它的标签实际将指：“订单确认。”或者我们可能用数字指一个显屏，无论测试者在哪儿看它，数字都不会出现。测试必须有精确的参考来指导测试者。

  　　如果您为了测试者注意以后将核实的输入，建立了结构化的字段，测试可能加速。例如，如果你正在测试一个审核日志，你事先不能知道测试者将完成一个审核活动的确切分钟。如果你告诉他们注意它，它可能被胡乱地写在测试中，纸片上，或加进一个临时文件。他们可能不会找麻烦来标明什么是什么，并可能不得不到处搜寻来找到它。最好是在测试中留下一个标记的空格，在这里，他们可以写下输入，示例：

  　　删除条目日期：________时间： _______

  　　条目编号：________

  　　测试者登录ID ：________

  通过控制长度来提高可测试性

  　　一个测试用例应该多长？一个好的分步用例长度是10-15步，除非测试者不节省他们的工作。保持测试这么简短有几个好处：

  　　● 简短的用例用更少的时间来测试每一个步骤

  　　● 测试者不太可能受迷惑，犯错误，或需要帮助。

  　　● 测试经理可以准确估计需要多少时间来测试

  　　● 结果更容易追踪

  　　不要试图在10-15个步骤的标准上作弊，把很多活动填满一个步骤。

  　　一个步骤应该是一个明确的输入或测试任务。您总可以在相同的步骤中添加一个简单的完成标志，如单击<OK>或按<Enter>。同样，一个步骤可以包括一套逻辑相关的输入。您不必对每个步骤都有结果，如果系统不响应某一步的话就不需用。

  　　保持单个测试简短的目标并不是不符合用最少数量的测试来测试应用系统的传统的目标。传统目标标准的目的是要精巧，当合理的测试业务场景或用例（use case）和需求一样多时，会工作到10-15步。该标准的目的还在于避免重复，即在一些测试中测试相同的需求。你可能不想通过使每一个测试都很长，来创建最低数量的测试，因为对于测试或维护来说，这将是一个恶梦。看老的“最低数量的测试，”的更好的方法是，衡量是否是一个“最低数量的步骤。”那么通过将50个步骤放入一个中以创造较少的测试是感觉不到好处的。

  　　对于一个矩阵，一个好的长度是可以测试约20分钟。

  　　自动化脚本的长度不是一个测试执行问题，因为测试通常是几秒钟。相反，问题是内容、维护和缺陷跟踪的管理。每个脚本一个业务场景或用例是足够的。它可以根据需要循环多次来加载数据或执行变量组合。

  累积用例的优点和缺点

  　　累积用例是那些依赖于以前的用例来运行的用例 — 在你测试＃6以前，你得先运行测试 1-5。您的目标是让测试尽可能的独立。这给了安排测试最大的灵活性，并减少了维护时间。可惜的是，它落后的一面是，该标准可能会不符合其他标准，如保持每个测试用例简短和不重复覆盖。你如何达到这一点呢？

  　　● 问问自己，是否你真正需要从另一个测试输入数据？如果是这样，测试必须是具有累积性的。

  　　● 只要有可能，提供一个以前的测试的替代品。这意味着它们可以使用在以前的测试中建立的数据，同时它们也可以使用其他数据。例如：“你需要两个处于90天拖欠状况的帐户，如为逾期帐户的测试用例所创建的账户。”

  　　● 提及其他测试时要象共有的一样尽可能在精确性上保持一致。不要只用编号提及一些测试。测试重编号后。如果您使用一个编号，还包括标题或说明。这可避免维护时的恶梦。

  　　改善可用性或可测试性的另一个问题是测试用例的顺序，它们应该根据业务使用排序。什么是最终用户通常首先做得，不是他们首先不得不做的，象在累积用例中一样？如果测试者是一个商业用户，他们将有一个他们希望完成软件任务的心理模式。通过复制其模式来适应他们，增加了他们的测试生产率。

  　　用模板提高生产率

  　　测试用例模板是一个带有标签字段的表单。附加的附录B是一个分步测试用例的模板。这是开始提高测试用例的一个重要的方式。它加快开始编写过程，并提供一个好用例的各个内容。这里是使用模板的一些其他的好处：

  　　● 防止空白页的恐慌

  　　● 对混乱现象给于帮助

  　　● 用标准创建

  　　● 打印好看的测试

  　　● 协助测试者找到信息

  　　● 可以包括与测试过程相关的其他字段

  查看(22) 评论(0)

• (转载)如何编写更好的测试用例（一）

  2008-11-07

  投资于测试用例

  　　为了改进测试用例什么是值得做的？什么风险会促使你投资于更好地测试用例？在他们覆盖软件需求时，还不是足够的好吗？对这些问题的答案是，粗劣的测试用例的确会将你暴露于相当大的风险之下。他们在理论上可能覆盖了需要，但很难用来执行测试，并会获得含糊不清的结果。好的测试会获得更可靠的结果，而且会在以下三个范畴降低成本：

  　　1.生产率 - 更短的时间撰写和维护用例

  　　2.可测试性 - 更短的时间来执行他们

  　　3.计划的可靠性 – 估算时有更好的可靠性

  　　本文介绍如何避免因为粗劣的测试案例必然带来的损失。将让我们看到罩盖下各种不同的测试用例，并展示在控制风险的质量中，在何处以及如何建立测试用例。对如何提高生产率、可用性、计划的可靠性和资产管理，将给出切实可行的建议。一旦你了解测试用例是什么和为什么的问题，您可以使用一个标准的核查表，像附录A一样的一个附件，来确定风险领域并改善您当前的和未来的测试用例。

  　　在准备测试软件的过程中，最繁杂的工作是编写测试用例。建立健壮的测试用例的动机是由可能性来激励的，测试用例将被重用于维护版本。超过所有软件开发工作的半数的工作是维护项目。你怎么才能编写良好的测试用例，它将提供经济的测试，首次测试后，在回归测试时将再次使用？让我们通过掀起测试用例的罩盖，看看里面是什么，来开始我们的答案吧。

  　　● 看测试用例内部

  　　● 测试用例的内容（element）

  　　● 针对我们的目标，一个测试用例是一套基于系统需求的，带有预期结果的活动。用例包括这些内容：

  　　● 测试的目标或将被测试的需求的描述

  　　● 它将被如何测试的方法

  　　● 测试的设置：接受测试的应用程序的版本、硬件、软件、操作系统、数据文件、安全访问、时间、逻辑的或物理的起止日期、先决条件（如其他测试），以及对于被测需求（一个或多个）的任何其他有关的设置信息

  　　● 活动和预期的结果，或输入和输出

  　　● 任何校样或附件（可选）

  　　这些同样的内容必需被用在每一级测试——单元、集成、系统、或验收测试的测试用例中。对于功能、性能和可用性测试，它们同样有效。“预期结果”的标准并不适用于一个探索性质的诊断测试或其他测试。实际上诊断测试在其用例中需要其他内容。然而，如果测试是测量性能，那性能应属于一个范围，这个范围就是一个预期结果。

  　　测试用例的另一种描述是，说明、目标和组织安排是用例或规格说明。完成它的步骤被称为脚本。而另一种观点认为目标或说明是一个场景（scenario）或功能用例（use case）。这些观点都符合本文提议的质量评估和改进。

  测试用例的质量

  　　有一种误解，以为编写质量是主观的，就像看一幅画，哪里美丽只在观看者的眼睛里。

  　　事实上，编写质量是客观的和可测量的。就像附录A一样，建立一个测试用例的构成内容（目标、方法、组织安排、输入和输出等）的客观核查表，这是很简单的。然后走查每个用例。内容是有或者没有？除了其构成，用例也必须符合这些质量标准：

  　　精确的。它们只测试它们描述中所说的它们将测试的内容。

  　　经济的。它们只有对于它们的目标所需要的步骤或信息。它们不给出软件导航。

  　　可重用的，自立的。一个测试用例是一个对照试验。每一次不管是谁测试它，它都应当得到相同的结果。如果只有作者可以测试它并获得结果，或如果不同的测试者测试，得到不同的结果，那该测试用例就需要在组织或活动上做更多的工作。

  　　适合的。一个测试用例必须适合测试者和环境。如果它在理论上是合理的，但需要所有的测试者都没有的技能，那它将会被束之高阁。即使你知道谁在测试第一次，你也需要考虑维护和回归时的情况。

  　　可追溯的。你必须知道此用例测试的是什么需求。它可能满足所有的其他标准，但如果其结果是，通过或失败都无关紧要，那为什么还要费心做它呢？

  　　可自我清理的。运行后自动收起。它返回测试环境到预测试状态。例如，它不会留下测试系统设置在错误的日期。自动脚本可调用其他脚本来做到这一点。不要把这一标准与破坏性混淆。测试应该是破坏性的，包括试图通过可控制和可重复的方式打破一个模拟生产环境。

  　　这些标准也是客观的和可测量的。它们也可以被添加到您的核查表。

  　　如果谁知道需求和受测应用程序，那他应该填写该核查表作为一个同行审查的一部分。

  　　遵循多少标准只有测试后才能知道，但它们都是可测量的。对于新的测试编写者，这是一种特别有用练习，看看他们在哪块始终没有达到某一要素，或不符合某一标准。

  测试用例的格式

  　　一个测试用例看起来像什么呢？它们似乎分为三个主要群组：分步、矩阵和自动化脚本。当然自动化脚本将作为一个在线文件来运行，毫无疑问，其他两个必须是基于纸张的。他们也可以是在线的。让我们来看看每一个的格式：

  　　分步。图1显示了这个基本的格式模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录B来显示。

  步骤	活动	预期结果
  1	输入新的名称和地址。按<OK> 。	显示屏幕008新名称的详细信息。
  2	用自然的数据填充所有空格。抓屏。按<OK> 。	显示屏幕005维护。
  3	点击<Inquiry>按钮。	显示屏幕009查询的详细信息。
  4	从抓屏上输入名字。按<OK> 。	显示屏幕010记录详细信息。
  5	比较记录细节和抓屏。	所有详细信息完全匹配。

  图1 - 分步测试用例详细信息

  　　矩阵或表格。图2显示了这个格式的基本模样。这个格式的一个完整的视图，在一个带有其他测试内容的模板中，作为附录C来显示。

  日期	1/96后受雇	401K	生命险	付款数
  10/25/99	Y	1	3	$24.50
  1/4/98	Y	3	1	$34.00
  3/6/96	N	2	5	$48.00
  8/15/96	Y	2	5	$86.25
  8/15/96	N	2	5	$105.00

  图2 - 矩阵测试用例详细信息

  　　自动化脚本。图3显示了这种格式的模样。
  

  # Open the Fax Form menu_select_item ("File;Fax Order..."); set_window("Fax Order"); # Retrieve the Fax Order information and compare it to data from the main window edit_get_text ("Arrival:", text); if(main_data["arr_time"] != text) { failure_msg = arrival_fr_mismatch; result = FAIL;

  图3 - 自动化脚本测试用例详细信息

     使用测试类型

  　　每种类型用例的最佳用途

  　　● 分步用例多用于：

  　　● 分步

  　　● 一次性测试用例，每一个都不同

  　　● 从一屏到另一屏展开的业务场景

  　　● 许多处理规则

  　　● GUI 界面

  　　● 在矩阵中难以表示的输入与输出

  　　分步用例不一定需要如图1所示的有一个按键水平的详述。活动步骤可以在一个更高的水平，如：打开“my account”页面，寻找一个日期范围内的事务，注意该范围:______   ，打印报告，转送报告，等等。
  矩阵。矩阵用例多用于：

  　　● 填写表格有许多变化，同一字段，不同的值、输入文件

  　　● 相同的输入，不同的平台、浏览器、配置

  　　● 基于显屏的字符

  　　● 用矩阵表示出来最好的输入与输出

  　　几乎任何测试都可以表示成一个矩阵，但要裁定的问题是，对于测试，是否矩阵是最好的方式。最重要的是，矩阵要辅之以测试的一个描述、组织安排，以及如何记录结果。如何测试矩阵，对于编写者可能是显而易见的，但没有更多的指导时，测试者可能会做错。

  　　矩阵的一个变化是输入列表。它可以被插入一个分步测试或作为一个带有关于测试的解释性内容的矩阵。

  　　自动化脚本。使用自动化测试软件的决定，更多的与进行测试的规划和组织相关，而与将要测试什么关系不大。工具改变时，一些技术问题必然会遇到，但大多数应用程序都可以找到适合的技术。项目管理必须明白，编写自动化用例比手工测试需要花费较长的时间，因为手工测试必然首先是写成静态的。当界面稳定时，测试可以被录制。真正的自动化测试的回放是在软件生命周期的维护阶段。此时，脚本可以被反复执行，甚至无人值守，极大节省了测试时间。

  　　管理部门必须配备人员，用工具语言，如C++或Visual Basic 等来编程。简单的脚本可以用大多数测试分析工具录制，但功能更强大的脚本，往往使用自定义函数和对象，必须由程序员编写。一个组可以一起安排，几个人做普通的录制/回放脚本，一个人编程。

  　　和其他类型的测试用例相比，该用例适用于录制和回放，或数据驱动脚本。除了录制/回放脚本，自动化工具也用于性能和负载测试。他们可能会使用手工分步用例或矩阵，详细说明自动化工具将如何被用来创建虚拟用户，给出事务脚本，监控性能，和其他活动。

  查看(49) 评论(0)

• <转载>我的软件测试职业之路

  2008-11-05

  原文地址：http://www.51testing.com/?action_viewnews_itemid_96678.html

  工作

  　　2003年毕业，作为第一届高校扩招后的毕业生，就业形势出现了新的转变。而作为计算机科班出身的我，当时也曾经像大部分其他同学一样，考虑过报考公务员、找银行、电信这些被认为是铁饭碗的工作。而考研则始终不在我的计划内，原因主要是付不起学费，为了大学4年，家里已经不堪负重了；另外，由于在大学跟着几位老师和教授搞工程，也接触了不少的研究生师兄和师姐，给我的感觉不是很实在。

  　　于是，在与铁饭碗无缘之后，我开始踏踏实实地找软件相关的工作，第一家公司是广东金中华通讯服务有限公司，是新太集团旗下的子公司之一，当年和我一起进去的有不少同学，包括和我同班同宿舍的哥们。在这家公司，我待了整整一年后被辞退了，原因是所谓的“架构调整”，当然，在我走后的不足一年，这家公司倒闭了，新太也开始走下坡路。

  　　在金中华的日子是值得怀念的，学到了不少的东西。像很多当年学计算机的人一样，我从来没想过要做软件测试，应聘金中华的时候也是以软件开发工程师的角色进去的，但是上班的第一天，我被安排到了做软件测试。当时公司除了我的主管，就我和另外一位女生是做测试的，其他都做开发。

  　　也曾经怀疑过是不是自己的水平不如其他同学，所以被安排做测试，但是后来发现软件测试、QA并不是想象中的那样，至少我的主管给我的印象是：他的能力绝对不在任何一位项目经理或开发工程师之下。这点对于我在后面的工作中起到了很关键的作用，让我始终能正确定位好自己。

  　　成长

  　　像大部分软件测试人员一样，我们从手工的黑盒测试开始，并且这始终是我们的主要测试手段和方法。

  　　在开始的一段时间，我能发现的BUG很有限，主要是因为我的思维还没有转变到测试中来，仍然停留在大学时跟老师做工程的那种境地，很多BUG在我的眼里不是问题，我仍然习惯以开发者的角度去思考软件。

  　　后来我的主管通过ICQ给我发了个信息：好像你发现的BUG不多啊？！

  　　当我看到这句话的时候，当时的心情很复杂，有点愤怒，有点诧异，有点惊恐，最后是觉醒，我被提醒了：软件测试是一个独立的角色，它的最直接和最主要任务就是找BUG！

  　　从那以后，我在缺陷库中的BUG记录数直线上升，我把找到一个别人找不到、想不到的BUG当成我寻找下一个BUG的动力，我把自己训练成一匹能嗅到BUG这种独特的“猎物”的狼。

  　　不久，我们QA也要承接一些开发的任务了，例如手机应用、游戏、短信应用的开发等，这对于在学校就参与了工程项目实践的我来说难度不大，它们让我接触到了大量的技术：Java、JSP、J2ME、Brew、Linux、Oracle等。

  　　在03年左右的时间，国内的软件测试行业刚刚起步，国内专门讨论软件测试的地方很少，记得当时我的主管告诉我们可以去参加一个软件测试的讲座时，我的心情是非常兴奋的。

  　　在金中华，我没有太多的时间去思考软件测试、质量管理，也许是身不在其位，需要考虑到仅仅是如何把测试和开发工作做好而已。真正让我开始思考质量和软件测试的是在第二家公司。 转变

  　　第二家公司的几位老板是微软顾问出身，他们似乎比较看重我的技术底蕴，以及我在金中华积累的经验，我也因此得以顺利地进入这家公司。现在想起来，老板们也许早有打算利用我的这些经验来把这个刚刚成立不久的公司的软件测试做得更加规范。

  　　而且，他们是有意识地给我不少这方面的机会。刘老板一句“Show一下你的power”，让我得以在一次Team Building上展现我的技术能力，让我可以把平时积累的一些关于软件测试、工具应用方面的东西介绍给大家。这让我的地位一下子提高了不少，至少在仅有的几名测试人员之间，我好像得到的关注更多了一些。

  　　不久，我升任项目测试组长，这似乎来得有点突然，但是仔细想想也在情理之中。因为我知道我在金中华的测试经验和技术只能带过来一部分，还有比较重要的一块是业务知识，因为这家公司的项目和产品都是之前没有接触过的。通过平时的加倍努力和一段时间的出差接触用户，让我对这些业务知识的理解更加全面了。

  　　另外，我对代码的理解能力也为我加分不少，我曾经从每日构建的失败信息中直接定位到出错的源代码，找出代码错误的原因，然后直接让开发人员修改。

  　　我非常注意与开发人员的交流，我对于找出的BUG，都会找时间与开发人员直接沟通，而且是基于业务、设计架构的沟通，这一方面让我更全面地了解相关的业务知识，而且让我对系统的架构设计和代码有更深入的了解。这让我赢得不错的群众基础，尤其是开发人员和项目经理的认可。

  　　后来，随着公司架构从项目型到职能型的转变，我开始总管整个公司的软件测试，包括各个项目组的软件测试，这个转变让我有点不大适应，因为之前作为软件测试人员，或者是一个项目组的测试组长，我需要的管理方面的能力并不突出，但是现在，我需要重新考虑一下自己的角色定位了，幸好我能及时地调整过来。

  　　我开始花更多的时间与每个项目的测试组长交流，我制定了测试项目例会制，我制定了测试管理规范，更重要的是我开始让培训走入测试组。04年的时候，我请了51testing的王威老师来我们公司做了一次为期3天的培训，虽然培训的内容相对的基础，但是我想更多的收获是让每个测试人员实实在在地感觉到自己是一个测试团队中的人，有了更多的归属感。

  　我们的培训分为外训和内训两大类，考虑到成本，外训主要由我一个人到北京或上海参加，然后回来“布道”，内训则通过制定选题，让每个测试人员把自己擅长的、工作中积累的经验通过交流会的形式共享出来。

  　　培训不仅让我自己的测试能力得以增强，也让我们的测试人员更加有归属感。

  　　有一次，某个项目的开发进度严重的Delay了，测试人员被压得有点喘不过气来，但是项目经理似乎缺乏质量和软件测试方面的意识，一位测试人员找我聊的时候眼泪都流出来了。我开始意识到公司需要的不仅仅是我以及一个软件测试组织，我们需要一个质量体系。

  　　跨越

  　　不久，公司需要通过GJB 9001A认证，根据咨询老师的意见，我们需要一个独立的质量管理部门，因此我顺理成章地成为了软件质量保障部的经理。也许很多人会羡慕我，从一名普通的测试人员到一名质量部的经理，这也许要花上5、6年甚至10多年的时间，而我只用了3年左右的时间。

  　　我们开始办一份内部的月刊，作为质量和软件测试的交流平台，同时也是质量意识的宣传平台，公司领导对于这件事情非常支持，因此我们虽然做得比较辛苦，也坚持做了下来。同时，我设立了一个名为“质量之星”的奖项，用于奖励那些在平时工作中认真细致，追求尽善尽美的人，包括开发的和测试的。

  　　这一时期，我受克劳士比的“零缺陷”质量管理思想影响比较深，我拜读了他写的《质量免费》、《削减质量成本》等著作，受益匪浅。但是也活得比较累，因为现实和理想的差距太大了。

  　　经过半年多的准备，我带领几名内审员迎接了认证机构3天地审查，顺利通过了认证。

  　　认证通过后，我开始把测试管理的工作转移给各位质保组长。我开始“沉迷”于测试技术、测试工具、自动化测试的研究，我把自己定位成测试研究员和架构师的角色，我开始尝试把各种测试技术和工具应用到各测试组。为了实践自动化测试，我“怂恿”老板购买了比较便宜的自动化测试工具TestComplete。

  　　追求

  　　经过一段时间的实践和积累，我有点不吐不快的感觉，我开始在51testing、CSDN等论坛上“泡”，就像武林高手希望通过寻找对手切磋来证明自己的能力一样。我开始写博客，发表文章，写书，兼职为某个公司做自动化测试顾问，一方面是为了名利，一方面也为了证明自己的能力。

  在公司推行质量管理碰到很多的阻力，软件测试团队的地位需要提高，我所做的这些“不正经”的事情也许或多或少地给大家带来某些讯息，至少让测试人员们的信心得到了加强。

  　　但是另一方面，我自己也开始迷茫了，我发现作为一名质量管理者的成就感开始缺失，随着底下培养的人员的能力的提高，我开始觉得我要给他们更多锻炼的机会。兼职为某公司做顾问给我一种全新的感觉，我得到很多新的成就感，我隐约觉得这是我将来的一个发展方向。

  　　机遇

  　　也许冥冥中已经有了一些安排，正当我在迷茫中不知所措时，李老板找我聊天，他说最近公司碰到一些困难了，我问是不是要考虑裁员，他说是，我说那就先把我干掉吧，干掉我一个人可以顶两个人。老板们都很尊重我的决定。

  　　离开公司，我的选择是不少的，也有不少的猎头找测试主管的候选人。但是我最终选择了加入51testing。因为我感觉这是我通往专业软件测试顾问的一条必经之路。

  　　加入51testing做培训讲师，不仅可以锻炼我的表达能力，而且能让我的知识体系更加完善，也能为将来的工作做好大量的铺垫。

  　　说到51testing，我觉得我和51testing的缘分还真不浅：

  　　2004年，51testing成立，这年我请了王威老师来公司做培训；

  　　2006年12月，我到上海参加了朴老师的LoadRunner性能测试课程；

  　　2007年10月，周峰老师来广州探索华南就业培训市场，有缘见面并深入探讨软件测试行业；

  　　2008年9月，加入深圳博为峰。

  　　“这是个最好的时代，这是个最坏的时代”。而我有幸身处这个时代，我有幸见证国内软件测试的发展过程，我有幸没有白费了6年。加入51testing，会给我更多的挑战，让我在软件测试的道路上继续走下去，也许还会有新的十字路口，但是我相信自己的选择。

  查看(36) 评论(1)

• 北京工作随感

  2008-11-04

      时间过的真是快啊，转眼来北京工作都半年多了。很长时间也没整理过自己的空间，今天上来写写半年多的工作感想。

      自己也慢慢的适应了北京的这种快节奏的生活，生活习惯方面因为我的老家离北京很近，所有大体上也能适应，感觉来了这有种回家的感觉，不像在别的城市心里老是觉着自己是漂泊在面的人。

      随着对北京测试行业发展的慢慢了解，越来越发现自己需要学习的东西实在是太多了，为了今后能找个好的单位，也是为了自己能在测试的道路上走的更远，不得不硬着头皮拿起书本学习自动化方面的知识，边学习边实践了。

      最近这几个月一直从事的是电子政务方面的系统，比如政府办公系统、电子公文传输系统，期间也测试了政府门户网站。总体感觉目前所在公司的测试流程混乱，很多时候都是在之前完全都不知道系统任何情况下就突然提交一个系统要求来测试，而且还是在短时间内完成，这样的日子长了感觉自己像是在混日子，心里不是滋味，跟上面领导也提出几次修改流程的事情，可是总是不能引起重视，另一方面，开发那边从编写代码上也不是很规范，都是自己觉着怎么合适怎么来，根本就不考虑系统的易用性、界面的美观等方面，哎！有的时候看到开发提交过来的系统感觉自己心里很疲惫，很厌倦，甚至有想吐的感觉。

      现状是无法改变的，看来我也就只能选择离开了，希望通过自己的学习，在来年能换个有正规测试流程的单位，我的明天更美好！加油！

  查看(12) 评论(0)

• <转载>版本更新时软件测试工作内容

  2008-7-04

   对于一个存在生命周期的软件来说，它的开发和测试往往是循环的多次的，因为随着新的需求的出现，以及对原有版本的改进，新的版本会不断的发布（即使对于一些以客户定制方式运作的项目，在开发过程中以及发布后的维护期内，也会产生众多的内部版本）。随着版本的迭代更新，我们的软件测试工作也会一直继续下去。而在每一次迭代时，可能在整个工作阶段的开始就受到一些因素的影响，比如市场需求、既定的发布时间、并发的工作导致的资源紧张等等，使我们不得不考虑对软件质量要求的适度，最终使得我们在每个阶段的测试工作的要求或者说所涉及到的内容有可能是不同的。这种变化，最终将会影响到测试需求的确定。

          那么到底该如何确定每次迭代是测试工作的范围呢？通常把测试工作范围的确定，等价的认为是软件需求的确定。

          不过现在有一个很实际的问题是这样：软件需求在开发过程中不断发生变化，有时候到了后期还会有新的需求添加进来，还有些需求在交付内部测试版本之后又发现原来的需求本身就存在缺陷，之后再次返工，在软件最终发布之前，怎么可能确定的下来呢。

          啊，这些都是让我们的开发人员和测试人员极其头痛的事情。到底应该怎样在频繁变更的需求中确定哪些部分是我们在某个阶段要测试的内容呢？或者说通过什么样的方法可以改善我们上面提到的那些问题呢？一个实际的做法就是实现软件需求的版本化控制。既然说到了这里，就不免要说些题外话。

          笔者一直都认为软件需求是开发工作和测试工作在制定计划、开展工作时所共同参照的源头和依据，而我们只有在源头上控制好，才能保证下面工作的平稳开展。如果希望某个阶段工作的进度和内容可以明确的定义下来，就必须要考虑软件需求的版本化控制。这里所提到的“软件需求的版本化控制”，是指在一个软件产品的生命周期中，当要进行一个新版本的迭代时，要尽早的确定这个版本中将要实现的需求，并同上个版本做出比较，哪些内容是新增的，哪些内容是被调整过的。

          在该阶段工作开始之初的工作会议上，明确的向所有需要了解软件需求的涉众传达这部分信息。而如果在该版本的开发过程中不断的出现需求变更的情况，则应该根据市场策略、已公布的发布时间、客户需求、实现的代价、难易程度以及对现有工作的影响等方面，对需求进行适度划分，严格定义当前版本中需要实现的需求，而其他部分，则作为未来版本的软件需求进行考虑。如果有的朋友认为上面的内容还是太理论化，需要一个更实际的、可操作的方法。那么只能说，对于需求的变更，以及因为需求变更而引起的设计的变更，必须要早发现，早讨论，早决定，早调整。

          这可能更多的要依靠一个团队中相关负责人员的主动工作来保证，而不是依靠一个明确的方法。注意，这里的一个关键是，对于软件需求，同样需要严格按照版本进行管理，或者说使用“基线”进行管理。

  查看(27) 评论(2)

• 日志空间开通

  2008-7-04

  我的日志空间开通了！

  从来没有想过要写日志，但是最近却突然想写点大小了，记录下自己每天的工作、心情等，也是对自己的一个鼓励吧。

  本人做测试2年的时间，1年的开发，做测试到现在技术呢觉得没有太大的长进，只能说是那些个理论掌握的更熟练了，测试的理念已经渗透到思想里了。研究的方向：集成测试、系统测试、自动化功能测试以及性能测试，希望和广大的测试同仁们多多交流！

  查看(12) 评论(0)

我的主题

• 三个处女结婚后的反映
• 求QTP9.2中文帮助
• 不知道这样的公司面试该不该去呢？
• 奥运各项赛事电视转播表
• 小兔子的故事