软件测试知识帖(41-60)

软件测试知识帖(41-60)

第41帖【2004－6－27】：测试自动化的限制

测试自动化可以带来非常明显的收益，但也有其限制，主要有：

1.不能取代手工测试

2.手工测试比自动测试发现的缺陷更多

3.对测试质量的依赖性极大

4.测试自动化不能提高有效性

5.测试自动化可能会制约软件开发。由于自动测试比手动测试更脆弱，所以维护会受到限制，从而制约软件的开发。

6.工具本身并无想像力　

另外，人工测试比测试工具更优越的另一个方面是可以处理意外事件。虽然工具也能处理部分异常事件，但是对真正的突发事件和不能由软件解决的问题就无能为力。

第42帖【2004－6－28】：什么是应首先被自动化的测试？

软件测试的自动化过程是一个渐进的过程，并不需要一开始就对所有的测试进行自动化，这通常也是不现实的。如何选择首先被自动化的测试成了最先遇到的问题。

有些测试，完全没有必要进行自动化，因为自动化它们所需的时间比手工运行它们全部的次数所需的时间总和还长。例如，手工运行一个测试要10分钟，而且一般每个月运行1次，那么一年需要120分钟。但如果自动化这测试需要10小时，那么这个测试需要连续不断运行5年才能收回成本。

有些测试，虽然执行的时间不长，但过程繁琐，需要执行的动作非常多。比如，一个运行10分钟的测试，可能需要击键150次，打开4～5个窗口，切换操作。如果将其自动化，可以提高可靠性，也是值得的。

对软件进行的功能性测试，是测试软件系统在做什么。这些测试可以明确的知道应该在什么情况下输入什么，会有什么样的输出。这样的测试是非常容易被自动化的，也能从自动化中获得较大的收益。

对软件进行的性能测试，包括在不同的系统负载下进行的测试。这些测试需要采用工具辅助完成，非常适合进行自动化。

如果在测试中，运行10%的测试需要花费90%的时间，那么将这10%的测试自动化是值得的。

以下列出了选择首先进行自动化时要考虑的因素：

非常重要的测试

涉及范围很广的测试

对主要功能的测试

容易自动化的测试

很快有回报的测试

运行最频繁的测试　

应该注意避免一口气自动化太多的测试。太多的工作导致参与人员工作积极性下降，可维护性下降，增加工作的风险。寻找可快速制胜的测试，尽快让大家看到工作成果，有助于获得更多的工作支持。

第43帖【2004－6－29】：工具的选择：创建还是购买

在评估了商业市场后，你可能会发现在你的限制之内没有符合你需求的工具。这时需要考虑是否自行开发自己的工具，还是等待市场上出现满足要求的新工具。

自行开发新工具有以下特点：

1、它将是最合适你的需求的
2、可以在工具中补偿被测软件缺乏的可测试性
3、工具可以假设很了解被测程序，因而减少了实现测试自动化所需的工作
4、在文档、帮助和培训方面可以不用提供很好的支持
5、工具可能具有某些典型的问题，如结构、可扩展性等
6、用户界面不友好

商业工具有以下特点：

1、获得一个指定功能和性能标准的工具的费用可能比自行开发一个工具的成本要低
2、在文档、帮助和培训方面必须提供良好的支持
3、工具通常应该很有吸引力
4、即使使用一个商业工具，可能无法完全避免建立自己的工具

但即使决定自行开发测试工具，也不要试图生产一个可以广泛使用的商业工具。

第44帖【2004－6－30】：自动化脚本之线性脚本

线性脚本是录制手工执行的测试用例得到的脚本。这种脚本包含所有用户的键盘和鼠标输入。如果仅使用线性脚本技术，每个测试用例可以通过脚本完整地被回放。线性脚本中也可能包括比较，比如检查某个窗口是否弹出。

手工运行10分钟的测试用例，可能需要20分钟到2个小时才能完成测试自动化的工作。因为录制的脚本需要维护，尤其是增加部分内容后的维护和测试需要花费很多时间。而且自动化以后的测试执行的时间会大于10分钟。

线性脚本有以下的优点：

1、不需要深入的工作或计划
2、可以加快开始自动化
3、对实际执行操作可以审计跟踪
4、用户不必是编程人员
5、提供良好的（软件或工具）的演示

线性脚本适用于以下情况：

1、演示或培训
2、执行量较少，且环境变化小的测试
3、数据转换，如将数据从Notes数据库中转换到EXCEL表格中

线性脚本有以下缺点：

1、过程繁琐
2、一切依赖于每次捕获的内容
3、测试输入和比较是“捆绑”在脚本中的
4、无共享或重用脚本
5、线性脚本容易受软件变化的影响
6、线性脚本修改代价大，维护成本高
7、非常容易受意外事件的影响，引起整个测试失败

第45帖【2004－7－1】：自动化脚本之结构化脚本

结构化脚本类似于结构化程序设计，含有控制脚本执行的指令。这些指令或为控制结构，或为调用结构。控制结构中包括“顺序”、“循环”和“分支”，和结构化程序设计中的概念相同。调用结构是在一个脚本中调用另外脚本，当子脚本执行完成后再继续运行父脚本。

结构化脚本的优点是健壮性好。也可以通过循环和调用减少工作量。

结构化脚本的缺点是脚本更复杂，而且测试数据仍然“捆绑”在脚本中。

结构化脚本侧重于描述脚本中控制流程的结构化特性。

第46帖【2004－7－3】：自动化脚本之共享脚本

共享脚本是指脚本可以被多个测试用例使用，一个脚本可以被另外一个脚本调用。这样可以节省生成脚本的时间；当重复任务发生变化时，只需修改一个脚本。

建立共享脚本的时间可能更长，因为需要建立更多的脚本，且每个脚本需要进行适当的修改，达到脚本共享的目的。

共享脚本可以是在不同主机、不同系统之间共享脚本，也可以是在同一主机、同一系统之间共享脚本。

共享脚本的优点有：

1、以较少的开销实现类似的测试
2、维护开销低于线性脚本
3、删除明显的重复
4、可以在脚本中增加更智能的功能

共享脚本的缺点有：

1、需要跟踪更多的脚本，给配置管理带来一定的困难
2、对于每个测试，仍然需要特定的测试脚本，因此维护费用比较高
3、共享脚本通常是针对被测软件的某部分，存在部分脚本不能直接运行

要获得高质量的共享脚本，需要接受一定的训练。在开始编写脚本时，多花些时间进行设计是值得的。通过共享脚本技术，还可以建立脚本库，达到最大程度的共享。由于共享脚本需要被多次使用，所以与脚本相配套的文档更应该引起注意。

共享脚本侧重描述脚本中共享的特性。

第47帖【2004－7－4】：自动化脚本之数据驱动脚本

数据驱动脚本技术将测试输入存储在独立的数据文件中，而不是绑定在脚本中。执行时是从数据文件而不是从脚本中读入数据。这种方法最大的好处是可以用同一个脚本允许不同的测试。对数据进行修改，也不必修改执行的脚本。

使用数据驱动脚本，可以以较小的开销实现较多的测试用例，这可以通过为一个测试脚本指定不同的测试数据文件达到。将数据文件单独列出，选择合适的数据格式和形式，可将用户的注意力集中到数据的维护和测试上。达到简化数据，减少出错的概率的目的。

数据驱动脚本的优点有：

1、可以快速增加类似的测试
2、测试者增加新测试不必掌握工具脚本语言的技术
3、对第二个及以后类似的测试无额外的维护开销

数据驱动脚本的缺点有：

1、初始建立的开销较大
2、需要专业（编程）支持
3、必须易于管理

第48帖【2004－7－5】：自动化脚本之关键字驱动脚本

关键字驱动实际上是比较复杂的数据驱动技术的逻辑扩展。将数据文件变成测试用例的描述，用一系列关键字指定要执行的任务。在关键字驱动技术中，假设测试者具有某些被测系统的知识，所以不必告诉测试者如何进行详细的动作，只是说明测试用例做什么，而不是如何做。这样在脚本中使用的是说明性方法和描述性方法。描述性方法将被测软件的知识建立在测试自动化环境中，这种知识包含在支持脚本中。

例如，为完成在网页浏览时输入网址，一般的脚本需要说明在某某窗口的某某控件中输入什么字符；而在关键字驱动脚本中，可以直接是在地址栏中输入网址什么什么；甚至更简单，仅说明输入网址什么什么。

关键字驱动脚本的数量不随测试用例的数量变化，而仅随软件规模而增加。这种脚本还可以实现跨平台的用例共享，只需要更改支持脚本即可。

第49帖【2004－7－6】：脚本预处理

预处理是一种或多种预编译功能，包括美化器、静态分析和一般替换。脚本的预处理是指脚本在被工具执行前必须进行编译。预处理功能通常需要工具支持，在脚本执行前自动处理。

美化器是一种对脚本格式进行检查的工具，必要时将脚本转换成符合编程规范的要求。可以让脚本编写者更专注于技术性的工作。

静态分析对脚本或表格执行更重要的检查功能，检查脚本中出现的和可能出现的缺陷。测试工具通常可以发现一些如拼写错误或不完整指令等脚本缺陷，这些功能非常有效。静态分析可以检查所有的缺陷和不当之处。类似于程序设计中的PC-Lint和LogiScope的功能。

一般替换也就是宏替换。可以让脚本更明确，易于维护。使用替换时应注意不要执行不必要的替换。在进行调试时，应该注意缺陷可能是存在被替换的部分中，而不是原来的脚本中。

第50帖【2004－7－7】：自动比较技术

测试验证是检验软件是否产生了正确输出的过程，是通过在测试的实际输出与预期输出（例如，当软件正确执行时的输出）之间完成一次或多次比较来实现的。进行测试自动化工作时，自动比较就成为一个必须的环节。有计划的进行比较会比随意的比较有更高的效率和发现问题的能力。

自动比较的内容可以是多方面的，包括基于磁盘输出的比较，如对数据文件的比较；基于界面输出的比较，如对显示位图的比较；基于多媒体输出的比较，如对声音的比较；还包括其它输出的内容的比较。

比较器可以检测两组数据是否相同，功能较齐全的比较器还可以标识有差异的内容。但比较器并不能告诉用户测试是否通过或失败，需要用户自行判断。

比较可以是简单的比较，仅匹配实际输出与预期输出是否完全相同，这是自动化比较的基础。智能比较是允许用已知的差异来比较实际输出和预期输出。比如，要求比较包含日期信息的输出报表的内容。如果使用简单比较，显然是不行的，因为每次生成报表的日期信息肯定是不同的。这时就需要智能比较，忽略日期的差别，比较其它内容，甚至还可以忽略日期的具体内容，比较日期的格式，要求日期按特定格式输出。智能比较需要使用到较为复杂的比较手段，包括正则表达式的搜索技术、屏蔽的搜索技术等。

第51帖【2004－7－8】：测试的敏感性和健壮性

敏感的测试是指测试过程能发现微小的，甚至是不起眼的错误。敏感的测试能发现较多的问题，但任何一点微不足道的改动都将导致测试用例及执行过程的更改。健壮的测试是指测试过程能够容忍较多的差别，不会影响测试用例的失败。在自动化测试时，健壮的测试可以较容易通过执行，也就减少了意外情况对测试过程的影响，但会导致发现问题的能力下降，甚至放过应该发现的问题。

应当在测试的敏感性和测试的健壮性之间进行权衡。对大量的自动测试用例而言，过多的敏感性比缺少敏感性更会反面影响失败分析工作。如果运行一组敏感的测试用例，那么有可能其中多数的测试用例由于相同的原因而失败。在这种情况下，每个失败的测试用例都指示相同的错误，但测试人员只是希望获得不同的错误及错误的差异，并不需要重复相同的错误报告。

敏感性和健壮性的测试应当是：

1、无论软件何时发生了变化，主要在高层次，即在作为明智的检验运行测试事例的地方，使用敏感比较
2、考虑多组测试用例，其中的一两组使用敏感比较，而其他组使用健壮比较
3、好的测试自动化策略应该是规划敏感测试和健壮测试的混合体

第52帖【2004－7－9】：TMM2级目标

TMM Level 2 - 阶段定义级目标：

1、区分调试和测试的的各自目标

为了区分调试和测试，需要成立为测试和调试负责的组织，该组织需要建立测试目标和策略，另外该组织还要建立调试目标和策略，这些目标和策略要文字化并确保知会到所有的项目经理和开发人员。

2、引进测试计划过程

完成这个目标，要建立组织范围内的测试计划组织、建立测试计划策略及计划模板、建立把用户需求引入测试计划的正规途径、测试目标作为测试计划基线、对项目管理者进行测试计划培训、对软件工程师进行测试设计和用例设计培训、计划工具必须被评估、推荐和申购，使用要得到管理层的支持。

3、基本的测试技术和方法被制度化

必须明确制定何时、如何应用那些测试技术。为此要成立组织范围内的测试技术研究组，进行学习、评估、推荐基本的测试技术、方法和相应的工具支持，管理者要在政策上保证推荐的技术和方法在组织范围内坚持使用。

第53帖【2004－7－11】：TMM3级目标

TMM Level 3 -集成级目标：

1、建立软件测试的专门组织

建立组织范围内的测试组织，取得高层支持，并且有资金保证；组织范围内明确定义了测试部门的角色和职责，将受过良好培训和激励的员工分配到测试部，测试部员工协助SQA工作，以提高测试效率和软件质量；测试部门能与用户建立沟通渠道，把用户需求引入测试过程。

2、建立技术培训流程

管理层必须建立组织范围内的测试培训体制，提供支持和资金，必须建立培训的目标和计划，建立内部培训组织，提供必要的工具、设备和资料。

3、测试和软件周期集成

将测试分成若干阶段，以集成到开发过程中；建立并采用 V模型，制定与测试相关的工作标准，为了使集成容易实现，必须建立测试人员和开发人员的工作机制。

4、监督和控制软件测试过程

建立相应机构和策略以监控测试过程，建立测试相关活动的度量机制，为测试计划执行过程中的突发事件制定应急措施。

第54帖【2004－7－11】：TMM4级目标

TMMLevel 4 -管理和度量级目标

1、建立组织范围内的评审流程

评审能尽早、有效地识别、分类和消除缺陷，高层管理者必须制定评审的政策，支持评审过程，并把评审集成在组织文化中；测试组和SQA必须制定整个生命周期内的评审目标，计划和过程，并文档化，必须指定要评审的项目；参加评审者要接受培训，包括评审的政策，实践和程序。

2、建立测试度量流程

建立组织范围内的测试度量政策和目标，必须建立面向数据收集、分析和应用的测试度量计划，根据度量分析结果，制定并记录相应的行动计划以改进测试过程。

3、进行软件质量评估

管理者、测试和SQA组织必须定义与软件质量相关的质量政策，质量目标和质量属性（例如可以参照ISO9126制订质量度量模型）；测试过程必须是结构化的，可度量和可评估的，以保证软件质量目标的可达性。

第55帖【2004－7－12】：TMM5级目标

TMM Level 5 - 优化级目标

1、进行过程的数据进行缺陷预防

对组织内的所有项目采用缺陷预防策略，在管理者的支持下建立缺陷预防的团队；软件生命周期每个阶段发现的缺陷必须标识和记录；建立分析的机制，保证能弄清楚导致缺陷的根本原因；建立行动计划，采取措施，避免管理人员、开发人员和测试人员工作中重现已发现的缺陷。

2、质量控制，测试过程优化

软件测试和SQA组必须建立软件产品的目标，如产品单元缺陷率(product unit defectiveness)，自信级别(confidence levels)和可信性 (trustworthiness )，测试经理必须把这些质量目标分解到测试计划中，必须对测试组进行统计方法培训。

收集用户的输入操作，建立使用模型。

3、测试过程优化
建立测试过程改进组织，监控测试过程，寻找优化点，持续对测试相关的、需要采用的工具和技术进行评估，测试过程效率要持续进行评估，停止测试的决策必须参考质量目标，并以可度量和优化的方式来制定。

第56帖【2004－7－13】：正规检视需要哪些阶段？

检视过程包括七个阶段：

1、计划

用于确定工作产品是否满足正规检视的进入标准，计划检视，召集成立检视小组并分配相应任务、安排正规检视会议，准备和发放正规检视的资料。确定是否有必要举行产品介绍会议。

2、介绍会议

这是可选择阶段。本阶段向正规检视小组介绍产品的背景信息。如果每个检视小组的成员对被检视的对象很熟悉，可不用召开产品介绍会议。

3、会议准备

这是关键阶段。本阶段检视小组的成员单独准备检视会议，检查和发现检视对象中的错误。错误将在正规检视会议期间进行讨论。在检视会议前以问题登记表形式提交给组织者。

4、检视会议

正规检视的小组一起审查产品。

(这里说到正规检视有七个阶段，在网上查了一下，没找到答案，有知道朋友的可以提醒一下，我把这里补全。)

第57帖【2004－7－14】：正规检视介绍会议

正规检视介绍会议：

介绍会议阶段是评审流程可选择的阶段。如果检视小组成员不熟悉检视对象以及相关的背景，那么这个会议就应当安排举行。在介绍会议上，作者介绍产品的理论基础，产品同被开发的系统其余部分的关系，产品的功能和产品的主要应用，以及在产品开发过程中采用的开发方式。所有的检视者必须参加介绍会议。

召开介绍会议的主要原因如下：

1、正规检视小组不熟悉检视对象

2、检视对象是新开发的或者是首次进行正规检视

3、正规检视工作在检视对象的项目中被首次采用

第58帖【2004－7－15】：软件配置管理介绍

1、软件配置管理概念：

软件配置管理是通过在软件生命周期的不同时间点上对软件配置进行标识并对这些标识的软件配置项的更改进行系统控制，从而达到保证软件产品的完整性和可溯性的过程。

配置：软件系统的功能属性。

配置项：软件系统的逻辑组成，即与某功能属性相对应的文档或代码等。

2、软件配置管理的四个基本过程：

配置标识： 标识组成软件产品的各组成部分并定义其属性，制定基线计划。

配置控制： 控制对配置项的修改。

配置状态发布： 向受影响的组织和个人报告变更申请的处理过程，通过的变更及他们的实现情况等。

配置评审： 确认受控软件配置项满足需求并就绪。

3、配置库：对各基线内容的存储和管理的数据库

开发库：程序员工作空间，始于某一基线，为某一目的开发服务，开发完成后，经过评审回归到基线库。

基线库：包括通过评审的各类基线，各类变更申请的记录和统计数据。

产品库：是某一基线的静态拷贝，基线库进入发布阶段形成产品库。

4、检视对象中应用了最新的技术

第59帖【2004－7－16】：利用PC－LINT进行代码排错

PC-LINT是GIMPEL SOFTWARE公司的产品，是一种软件质量保证工具，用于程序排错，可对windows、unix平台下的C、C++代码进行最仔细的语法检查，可检查一些在普通编译器不易发现的句法、一般逻辑错误等，是程序员不可多得的排错工具。

如果给 PC-LINT工具下一个形象点的定义，那就是：一种更加严格的编译器。它不仅可以象普通编译器那样检查出一般的语法错误，还可以检查出那些虽然完全合乎语法要求，但很可能是潜在的、不易发现的错误。

许多国外的大型专业软件公司，如微软公司，都把它作为程序检查工具，在程序合入正试版本或交付测试之前一定要保证通过了LINT检查，他们要求软件工程师在使用LINT时要打开所有的编译开关，如果一定要关闭某些开关，那么要给出关闭这些开关的正当理由。

在开发、测试过程中，除了正规检视、代码走读、代码审查等活动可以有效的帮助获得正确的代码，运用PC-LINT、LOGISCOPE等工具也是很好的排错手段，尤其是PC-LINT，以其方便、准确、严格的特点在排除程序一般性错误方面有着明显的优势，其付出的工作量比正规检视、代码走读的要少很多。

可想而知，如果从编码后第一次编译程序时就使用LINT来检查程序，并且保证消除所有的LINT告警，程序质量的提高是不言而喻的。

第60帖【2004－7－17】：LOGISCOPE介绍

LOGISCOPE是为软件的全面质量控制而开发的强大工具，可以用在编程、测试和维护阶段。LOGISCOPE五个模块的功能：

(1) 阅读器(Viewer)：以文件调用图(各部件文件之间的关系)及组件调用图(函数和程序间的调用关系)的形式进行可视化应用软件设计。可以在各种各样的抽象级别上分析应用程序，在不同级别上的引导有助于整个应用程序的理解。

(2) 效果检查器(ImpactChecker)：允许用户检查使用的资源(文件、函数、用户定义类型、全局变量、结构成员常量)。它有助于我们理解函数间的信息流(参数传递)，以及数据和其它应用程序资源间的关系。

(3)规则检查器(RuleChecker)：所有关心无质量风险地开发软件的公司(比如航天公司)定义了编程规则和质量目标。这样做的好处是公司编程行为的一致性、确保易于维护、提高可靠性、易于移植到其它机器上，等等。我们可以用规则检查器(RuleChecker)确立编程标准，保证质量控制。

(4) 测试检查器(TestChecker)：实时度量测试覆盖率、显示未覆盖路径原始数据、生成测试报告、帮助管理测试实例。测试检查器(TestChecker)和动态分析器 (Dynamic Analyzer)通过阅读器产生用于应用程序分析的数据。

(5) 代码检查器(CodeChecker)：验证应用程序与质量模型的一致性。代码检查器和静态分析器(Static Analyzer)通过阅读器(Viewer)产生用于应用程序分析的数据。代码检查器(CodeChecker)可以使我们尽早发现和修改质量缺陷。这对质量控制尤为重要。