我的文集

• 第243贴【2005－06－15】：录制回放并非自动化测试

  2005-06-15 11:03:11   /   [每日一贴]

  很多工具提供录制回放功能，能够把手工测试的过程捕获下来，形成为脚本，但这并不是自动化测试。录制的脚本阅读起来可能会有一定困难，因为脚本中不存在测试目的、注释等信息，测试者不得不录制完后自己添加，否则今后维护这些脚本会非常困难。另外录制的脚本中存在许多冗余信息，例如删除错误的输入，也会被录制下来。录制的脚本与所录制的对象紧密相关。通过工具，脚本可能与屏幕的对象、特定字符串甚至是位图位置相关。当软件发生变化时，与脚本相关内容的任何变化都会使原来的脚本不能正常工作。修改脚本往往比再次进.

  查看(3074) 评论(1)

• 第242贴【2005－06－14】：有详尽测试文档时的测试执行

  2005-06-14 22:16:00   /   [每日一贴]

  在详细的测试文档中，包含了准确的测试输入及相应的测试输出。所有测试执行人员需要严格按照用例执行。这样一方面降低了测试执行人员的能力要求，另一方面也使得测试执行工作变得枯燥和繁琐，没有发挥创造性的余地。这种情况下的测试有一些优点：1、不同执行者执行同样用例将会得到同样结果；2、软件缺陷一般可再现；3、由于给出了具体的输入和期望输出的信息，容易实现自动化这种情况下测试的缺点是1、设计开销较大；2、冗余文本较多；3、公共操作的复用性较差；4、运行枯燥，不能发.

  查看(3125) 评论(6)

• 第241贴【2005－06－07】：测试文档不详细时的测试执行

  2005-06-07 19:19:02   /   [每日一贴]

  测试文档不详细时，测试用例只含有测试步骤的描述，没有对输入和结果比较进行详细说明。例如，一些用例可能这样描述：“输入一些无效参数”或“在列表中增加某些项”。这里描述的输入不是显示的说明，如明确的指出数据的内容，或数据的错误格式。这种类型的测试用例通常只包含期望结果的模糊描述，它和无测试文档的测试执行相比有很多优点：。不同测试者可以根据用例发现类似的缺陷；。可以发现在模糊条件范围内所有的问题；。执行测试的有效性和效率都比无测试文档好当然这种测试也有许多不足：　 。.

  查看(4208) 评论(8)

• 第240贴【2005－06－06】：无测试文档的测试执行

  2005-06-06 11:23:17   /   [每日一贴]

  目前常见有以下一些测试过程：1、没有设计用例或设计用例没有文档化；2、有文档化的测试用例但不详细；3、有详细的测试用例，说明了每个输入及比较目前用户的测试或多或少属于这些测试过程的一种或多种。在第一种情况中，测试者没有周密的测试计划或测试用例，测试者边测试边想测试什么，测试者的想法或操作没有留下记录或文档化，因此所有的测试就不能准确地重复。通常这类软件开发项目时间紧、规模小，没有规格说明，需求不断变化，测试人员没有时间写文档，直接测试。对于这种情况，不要试图开.

  查看(7332) 评论(13)

• 第239贴【2005－06－02】：基于规格说明的测试生成

  2005-06-02 17:35:45   /   [每日一贴]

  在规格可以被形式化说明并可被工具分析的前提下，基于规格说明的测试工具可以生成测试输入及期望输出。规格说明可以包括结构化的自然语言，如商业规则，也可以包含技术数据。如果面向对象规格说明足够严格的话，这种工具还可以进行面向对象规格说明的测试。例如，如果一个输入域的允许范围被严格定义，那么工具就可以产生边界值以及有效等价类和无效等价类的样值。基于规格说明的测试生成能测试检查软件应该做什么，而不是它做了什么。从规格说明中推导测试用例越枯燥，使用这类工具的潜力就越大。如果期望输出也可以表达.

  查看(3047) 评论(2)

• 第238贴【2005－06－01】：基于界面的测试生成

  2005-06-01 10:19:42   /   [每日一贴]

  基于界面测试生成工具可以用在某些定义好的界面，如在GUI或WEB应用方面生成测试。例如如果界面含有各种菜单、按钮、检察框，则工具生成访问每个控件的测试用例。例如，工具可以测试检查框被选中时有个交叉符号，没被选中时为空，对于其他图形控件也可以自动进行类似的基本测试。类似的测试也可以在WEB页面上进行，工具可以激活WWW页面的每个链接，然后对每页循环地做相同的测试。基于界面的测试生成方法对于发现某类缺陷是有效的，例如，可以测试发现不正常的WEB页链接，但不能判断链接是否在正确的位置。因此，这种方法可以用来.

  查看(3175) 评论(4)

• 第237贴【2005－05－30】：基于代码的测试输入生成

  2005-05-30 14:26:40   /   [每日一贴]

  基于代码的测试输入生成工具，可以通过检测软件代码结构生成测试输入。通过对代码的路径分析其逻辑条件，标识出测试输入，达到一定的逻辑覆盖。这种方法只能产生测试输入，但测试还需要对测试输出进行比较。基于代码测试用例设计不能判断软件产生的输出是否正确，只是说明代码应该做什么，因此这种方法是不全面，它不能产生期望输出。对代码进行测试不仅仅是测试“代码做了什么”，而是要测试“代码是否做了应该做的”。而这种方法的一个问题是只能测试存在的代码而不能发现丢失的代码，不能发现规格中的问题和规格未实现.

  查看(2899) 评论(1)

• 第236贴【2005－05－29】：测试用例设计自动化

  2005-05-29 18:17:14   /   [每日一贴]

  一般来说,用例设计属于重复次数少的智能活动,不太适合自动化。但也有一些场合可以进行一定程度的自动化，提高设计效率，但不能指望能完全取代智力的测试活动。实现这种目的的工具有时称为测试输入生成工具。所有的测试输入生成工具都存在一个问题，即工具可能产生大量的测试用例，但它不能区分哪些测试是最重要的，这些要求创造力的智力活动只能由测试人员完成。工具永远不能回答如何在合理的时间里挑选适当的用例来执行。工具生成测试用例依赖于规格描述的形式化，如果不能做到形式化描述，是无法按照一定算法实现用例设.

  查看(6635) 评论(2)

• 第235贴【2005－05－26】：适合自动化的测试活动

  2005-05-27 18:56:01   /   [每日一贴]

  一个测试过程一般包括以下测试活动：标识、设计、建立、执行、比较。其中：标识：标识测试条件（确定测什么）和测试优先级；设计：设计测试方案和用例（确定）怎么测；建立：建立测试环境，包含物理连接、数据配置等等；执行：按照测试设计的方案和用例进行测试步骤的操作；比较：将测试执行输出结果和用例期望结果进行比较，得到测试结果。在上面5个活动中，前面两个测试活动，即标识和设计主要为抽象的智力活动，并且在整个测试过程中一般也只进行少量的次数，所以一般不适合采用自动化；而建.

  查看(2812) 评论(1)

• 第234贴【2005－05－25】：测试用例设计的时机

  2005-05-25 13:58:26   /   [每日一贴]

  通常认为测试是在软件已经编写完成后进行的，因为不能测试不存在的东西。这种观点仅仅将测试局限在测试执行上，但其实测试并不仅仅包含测试执行。在软件开发V模型中，每个开发活动都有相应的测试活动。每一层的测试检验都对应于相应的开发活动。应用V模型的关键是要把握测试用例设计的时机。无论在哪个测试阶段的测试设计的目标都是发现缺陷。例如，设计系统测试用例可以发现需求的缺陷，设计集成测试用例可以发现概要设计的缺陷，设计单元测试用例可以发现详细设计的缺陷。如果测试设计等到最后时刻才进行，缺陷只有在运.

  查看(3742) 评论(2)