软件测试种类名词解释

Client/Server测试
　　Roger S. Pressman
　　通常，客户 / 服务器软件的测试发生在三个不同的层次：
　　（ 1 ）个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行；
　　（ 2 ）客户端软件和关联的服务器端应用被一起测试，但网络运行不被明显的考虑；
　　（ 3 ）完整的 C/S 体系结构，包括网络运行和性能，被测试。
　　下面的测试方法是 C/S 应用中经常用到的：
　　应用功能测试—— 客户端应用被独立地执行，以揭示在其运行中的错误。
　　服务器测试 —— 测试服务器的协调和数据管理功能，也考虑服务器性能（整体反映时间和数据吞吐量）。
　　数据库测试 —— 测试服务器存储的数据的精确性和完整性，检查客户端应用提交的事务，以保证数据被正确地存储、更新和检索。
　　事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性，也关注性能问题。
　　网络通信测试 —— 这些测试验证网络节点间的通信正常地发生，并且消息传递、事务和相关的网络交通无错的发生。
　　回归测试
　　Roger S. Pressman
　　每当一个新的模块被当作集成测试的一部分加进来的时候，软件就发生了改变。新的数据流路径建立起来，新的 I/O 操作可能也会出现，还有可能激活了新的控制逻辑。这些改变可能会使原本工作得很正常的功能产生错误。在集成测试策略的环境中，回归测试是对某些已经进行过的测试的某些子集再重新进行一遍，以保证上述改变不会传播无法预料的副作用。
　　在更广的环境里，（任何种类的）成功测试结果都是发现错误，而错误是要被修改的，每当软件被修改的时候，软件配置的某些方面（程序、文档、或者数据）也被修改了，回归测试就是用来保证（由于测试或者其他原因的）改动不会带来不可预料的行为或者另外的错误。
　　回归测试可以通过重新执行所有的测试用例的一个子集人工地进行，也可以使用自动化的捕获回放工具来进行。捕获回放工具使得软件工程师能够捕获到测试用例，然后就可以进行回放和比较。
　　回归测试集（要进行的测试的子集）包括三种不同类型的测试用例：
　　· 能够测试软件的所有功能的代表性测试用例。
　　· 专门针对可能会被修改影响的软件功能的附加测试。
　　· 针对修改过的软件成分的测试。
　　在集成测试进行的过程中，回归测试可能会变得非常庞大。因此，回归测试应当设计为只对出现错误的模块的主要功能进行测试，每当进行一个修改时，就对每一个程序功能都重新执行所有的测试是不实际的而且效率很低的。
　　α 测试
　　α 测试是由一个用户在开发环境下进行的测试，也可以是开发机构枘部的用户在模拟实际操作环境下进行的测试。软件在一个自然设置状态下使用。开发者坐在用户旁边，随时记下错误情况和使用中的问题。这是在受控制的环境下进行的测试，
　　α 测试的目的是评价软件产品的 FLURPS( 即功能、局域化、可使用性、可靠性、性能和支持 ) 。尤其注重产品的界面和特色。 α 测试人员是除开产品开发人员之外首先见到产品的人，他们提出的功能和修改意见是特别有价值的。
　　α 测试可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定的稳定和可靠程序之后再开始。有关的手册（草稿）等应事先准备好。
　　β 测试
　　β 测试是由软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签定了支持产品预发行合同的外部客户，他们要求使用该产品，并愿意返回有关错位错误信息给开发者。与 α 测试不同的是，开发者通常不在测试现场。因而， β 测试是在开发者无法控制的环境下进行的软件现场应用。在 β 测试中，由用户记下遇到的所有问题，包括真实的以及主观认定的，定期向开发者报告，开发者在综合用户的报告之后，做出修改，最将软件产品交付给全体用户使用。
　　β 测试主要衡量产品的 FLURPS 。着重于产品的支持性，包括文档、客户培训和支持产品生产能力。只有当 α 测试达到一定的可靠程度时，才能开始 β 测试。由于它处在整个测试的最后阶段，不能指望这时发现主要问题。同时，产品的所有手册文本也应该在此阶段完全定稿。 由于 β 测试的主要目标是测试可支持性，所以 β 测试应尽可能由主持产品发行的人员来管理。

单元测试：单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等等。它是软件动态测试的最基本的部分，也是最重要的部分之一，其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此，单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。
　　集成测试：集成测试是在软件系统集成过程中所进行的测试，其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划，一边将模块或其他软件单位组合成越来越大的系统，一边运行该系统，以分析所组成的系统是否正确，各组成部分是否合拍。
　　集成测试的策略主要有自顶向下和自底向上两种。
　　系统测试：系统测试是对已经集成好的软件系统进行彻底的测试，以验证软件系统的正确性和性能等满足其规约所指定的要求，检查软件的行为和输出是否正确并非一项简单的任务，它被称为测试的 “ 先知者问题 ” 。因此，系统测试应该按照测试计划进行，
　　其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多，主要有功能测试、性能测试、随机测试等等。
　　验收测试：验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是，验收测试常常有软件系统的购买者代表在现场，甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。
　　回归测试：回归测试是在软件维护阶段，对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里，修改的正确性有两重含义：
　　一是所作的修改达到了预定目的，如错误得到改正，能够适应新的运行环境等等；二是不影响软件的其他功能的正确性。
　　黑盒测试
　　黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。
　　黑盒测试试图发现以下类型的错误：
　　1 ）功能错误或遗漏；
　　2 ）界面错误；
　　3 ）数据结构或外部数据库访问错误；
　　4 ）性能错误；
　　5 ）初始化和终止错误。
　　白盒测试在测试的早期采用，而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构，而是注意信息域。黑盒测试用于回答以下问题：
　　1 ）如何测试功能的有效性？
　　2 ）何种类型的输入会产生好的测试用例？
　　3 ）系统是否对特定的输入值尤其敏感？
　　4 ）如何分隔数据类的边界？
　　5 ）系统能够承受何种数据率和数据量？
　　6 ）特定类型的数据组合会对系统产生何种影响？
　　运用黑盒测试方法，可以导出满足以下标准的测试用例集：
　　1 ）所设计的测试用例能够减少达到合理测试所需的附加测试用例数；
　　2 ）所设计的测试用例能够告知某些类型错误的存在或不存在，而不是仅仅与特定测试相关的错误。
　　白盒测试
　　Rex Black
　　白盒测试，也称为结构化测试、基于代码的测试，是一种测试用例设计方法，它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够：
　　1 ）保证一个模块中的所有独立路径至少被使用一次；
　　2 ）对所有逻辑值均需测试 true 和 false ；
　　3 ）在上下边界及可操作范围内运行所有循环；
　　4 ）检查内部数据结构以确保其有效性。
　　“ 我们应该更注重于保证程序需求的实现，为什么要花费时间和精力来担心（和测试）逻辑细节？” 答案在于软件自身的缺陷：
　　1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、
　　条件或控制时，错误往往开始出现在我们工作中。日常处理往往被很好地了解，而 “ 特殊情况 ”
　　的处理则难于发现。
　　2 、我们经常相信某逻辑路径不可能被执行，而事实上，它可能在正常的基础上被执行。程序的逻辑流
　　有时是违反直觉的，这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误，
　　只有路径测试才能发现这些错误。
　　3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时，有可能产生某些笔误，很多将被语法检查机制发现，但是，其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。 正如 Beizer 所说的： “ 错误潜伏在角落里，聚集在边界上 ” ，而白盒测试更可能发现它。
　　GUI 测试
　　Roger S. Pressman
　　图形用户界面（ GUI ）对软件测试提出了有趣的挑战，因为 GUI 开发环境有可复用的构件，开发用户界面更加省时而且更加精确。同时， GUI 的复杂性也增加了，从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似，所以也就产生了一系列的测试标准。
　　下列问题可以作为常见 GUI 测试的指南：
　　窗口：
　　· 窗口是否基于相关的输入和菜单命令适当地打开？
　　· 窗口能否改变大小、移动和滚动？
　　· 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问？
　　· 当被覆盖并重新调用后，窗口能否正确地再生？
　　· 需要时能否使用所有窗口相关的功能？
　　· 所有窗口相关的功能是可操作的吗？
　　· 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用，
　　并适当地显示？
　　· 显示多个窗口时，窗口的名称是否被适当地表示？
　　· 活动窗口是否被适当地加亮？
　　· 如果使用多任务，是否所有的窗口被实时更新？
　　· 多次或不正确按鼠标是否会导致无法预料的副作用？
　　· 窗口的声音和颜色提示和窗口的操作顺序是否符合需求？
　　· 窗口是否正确地被关闭？
　　下拉式菜单和鼠标操作：
　　· 菜单条是否显示在合适的语境中？
　　· 应用程序的菜单条是否显示系统相关的特性（如时钟显示）？
　　· 下拉式操作能正确工作吗？
　　· 菜单、调色板和工具条是否工作正确？
　　· 是否适当地列出了所有的菜单功能和下拉式子功能？
　　· 是否可以通过鼠标访问所有的菜单功能？
　　· 文本字体、大小和格式是否正确？
　　· 是否能够用其他的文本命令激活每个菜单功能？
　　· 菜单功能是否随当前的窗口操作加亮或变灰？
　　· 菜单功能是否正确执行？
　　· 菜单功能的名字是否具有自解释性？
　　· 菜单项是否有帮助，是否语境相关？
　　· 在整个交互式语境中，是否可以识别鼠标操作？
　　· 如果要求多次点击鼠标，是否能够在语境中正确识别？
　　· 光标、处理指示器和识别指针是否随操作恰当地改变？
　　数据项：
　　· 字母数字数据项是否能够正确回显，并输入到系统中？
　　· 图形模式的数据项（如滚动条）是否正常工作？
　　· 是否能够识别非法数据？
　　· 数据输入消息是否可理解？