关键字：软件测试知识帖
在评估了商业市场后，你可能会发现在你的限制之内没有符合你需求的工具。这时需要考虑是否自行开发自己的工具，还是等待市场上出现满足要求的新工具。 自行开发新工具有以下特点：
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、检视会议
正规检视的小组一起审查产品，发现、分类和记录审查对象中的错误，但不讨论错误的解决方法。
5、第 3小时会议
可选择阶段。主要讨论无法确认问题的解决方法，也包括其它问题的解决方法等。
6、修改错误
修改已确认的错误。
7、问题跟踪
确定错误是否被改正，并且保证修改过程中没有引入新的错误。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
