我希望有很多很多的爱,如果没有很多的爱,我希望有很多很多的钱;没有很多的钱,我希望拥有健康! I am like the road in the night listening to the footfalls of its memories in silence.

发布新日志

  • [转] 无忧测试论坛《每日一帖》

    2007-05-10 22:19:11

    无忧测试论坛《每日一帖》5月份精华

    http://www.51testing.com/Integ/20041227_1.htm

     

    来自 http://www.51testing.com 这是论坛版主天网每天提供给测试网友的精神食粮,感谢天网

    1 帖【 2004 5 10 】:软件测试的理想模式是什么?

    Brian Marick :我不认为存在什么理想模式。我觉得让开发人员承担某些测试也许会更加有效,而其他测试则由独立测试组来进行。因为如果你把所有测试都交给独立测试组,他们不可能有时间把所有测试都做好。所以,最佳的方式是让开发人员承担一定量的测试,独立测试组给予他们支持。独立测试组主要承担整个系统的测试,去寻找开发人员还没有发现的缺陷,如子系统间的交互、运行条件、内存使用等。

    如何更有效地开展系统测试呢?让测试人员在项目初期就参与进去,让他们看到第一版的系统需求、用户手册和系统原型,在系统实现前就对需求进行捕获和跟踪。在该过程中,他们从这些文档构造最初的测试设计。这也可以通过检视或评审的形式进行,并且在该过程中会发现一些缺陷。大家都知道,这个阶段,问题发现是非常 “ 便宜 ” 的。

    这样,系统测试工程师在项目早期就介入,产生测试设计及基本的需要测试的项目列表。这时不可能产生一个绝对完备的测试设计,因为书写完整测试的条件还不成熟,但这却是构建完整测试的基础。

    注: Brian Marick 是 Reliability Software 公司的专职测试技术顾问。

    2 帖【 2004 5 11 】:测试经理角色定位

    Johanna Rothman :测试经理服务于两种完全不同的客户:测试工程师和高层管理者。对于测试工程师,测试经理帮助他们开发产品测试策略,积累产品测试经验并在测试组内充分共享。对于高层管理者,测试经理搜集尽可能全面的产品信息,供其就产品是否可以发布进行决策。但是有一点是相同的:无论是对于测试工程师还是高层管理者,测试经理将帮助其定义和校验产品发布标准。

    产品发布标准的定义和校验:作为一个测试经理,应该找机会与市场、开发人员商讨产品发布标准,并根据客户的反馈对该标准进行修正和校验。开发部门的工作是如何达到公司对产品的期望,要用客户需求为开发人员勾画出客户眼中的产品以及产品应如何工作。一旦产品被清楚地定义,就可以通过测试去验证产品在多大程度上满足了客户需求。

    对于测试工程师而言有一点非常重要:将测试任务按优先级划分,使产品发布标准得以满足。由于只有极少数的项目有充足的时间去完成所有事情,所以告诉测试工程师关于 “ 测什么和何时测 ” 测试经理的一个重要职责。

    高层管理者需要充分理解产品发布标准,以决定产品是否可以按时发布。我不认为测试组有权利裁决产品是否应该被发布,该权利在组织高层管理者那里。在有了一个通过讨论、达成一致的产品发布标准后,项目组也可以更清楚地了解和认识产品质量。

    3 贴【 2004 5 12 】:测试的基本原则

    (美) Roger S. Pressman
    在设计有效测试用例之前,测试工程师必需理解软件测试的基本原则。这里有一组测试原则:
    1 、所有的测试都应追溯到用户需求。正如我们所知:软件测试的目标在于揭示错误。而最严重的错误(从用户角度来看)是那些导致程序无法满足需求的错误。
    2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求模型一完成就开始,详细的测试用例定义可以在设计模型被确定后立即开始。因此,所有测试应该在任何代码被产生前就进行计划和设计。
    3 、 Pareto 原则应用于软件测试。简单地讲, Pareto 原则暗示着测试发现的错误中的 80 %很可能起源于程序模块中的 20 %。当然,问题在于如何孤立这些有疑点的模块并进行彻底的测试。
    4 、测试应从 “ 小规模 ” 开始,逐步转向 “ 大规模 ” 。最初的测试通常把焦点放在单个程序模块上,进一步测试的焦点则转向在集成的模块簇中寻找错误,最后在整个系统中寻找错误。
    5 、穷举测试是不可能的。即使是一个大小适度的程序,其路径排列的数量也非常大。因此,在测试中不可能运行路径的每一种组合。然而,充分覆盖程序逻辑,并确保程序设计中使用的所有条件是有可能的。
    6 、为了达到最佳效果,应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试(测试的主要目标),所以创建系统的软件工程师并不是构造软件测试的最佳人选。

    4 贴【 2004 5 13 】:什么是 的测试?

    什么是 “ 好 ” 的测试? Kaner , Falk & Nguyen
    1 、一个好的测试发现错误的可能性很高
    为了达到这个目标,测试者必需理解软件、并尝试设想软件如何才能失败,例如:在 GUI (图形用户界面)中有一种潜在的错误,即错误识别鼠标位置,那么就应该设计一个测试集来验证是否存在鼠标位置识别的错误。
    2 、一个好的测试并不冗余
    测试的时间和资源是有限的,没有必要构造一个与其他测试用例完全相同的测试,每一个测试都应该有不同的用途〔哪怕是细微的差异〕。例如,软件 SafeHome 中有一个模块被用来识别用户密码以决定是否启动系统,为了测试密码输入的错误,测试者设计了一系列的输入密码。在不同的测试中输入有效与无效密码( 4 个数字),然而,每一个有效 / 无效密码将只检测一种不同错误模式,例如一个将 8080 作为有效密码的系统将不会接受非法密码 1234 ,如果接受 1234 ,将产生错误,另一个测试输入 1235 ,与 1234 的测试意图相同,因此是冗余的,然而,非法输入 8081 或 8180 就有些细微的差异,即对与有效密码相近但并不相同的密码应该进行测试。
    3 、一个好的测试应该是 “ 最佳品种 ”
    在一组目的相似的测试中,时间和资源的限制可能只影响其某个子集的执行,此时,应该使用最可能找到所有错误的测试。
    4 、一个好的测试既不会太简单,也不会太复杂
    虽然有时会将一组测试组合到一个测试用例中,其副作用可能屏蔽错误,通常每一个测试应该独立执行。

    5 贴【 2004 5 14 】:软件可测试性

    Roger S. Pressman
    理想情况下,软件工程师在设计计算机程序、系统或产品时应该考虑可测试性,这就使得测试工程师能够更容易地设计有效的测试用例。

    什么是 “ 可测试性 ” ?软件的可测试性是指软件发现故障并隔离、定位其故障的能力特性,以及在一定的时间和成本前提下,进行测试设计、测试执行的能力。 James Bach 这样描述可测试性:软件可测试性就是一个计算机程序能够被测试的容易程度。

    以下是一个常见的软件可测试性检查表:
    · 可操作性- “ 运行地越好,被测试的效率越高。 ”
    · 可观察性- “ 所看见的,就是所测试的。 ”
    · 可控制性- “ 对软件的控制越好,测试越能够被自动执行与优化。 ”
    · 可分解性- “ 通过控制测试范围,能够更好地分解问题,执行更灵巧的再测试。 ”
    · 简单性- “ 需要测试的内容越少,测试的速度越快。 ”
    · 稳定性- “ 改变越少,对测试的破坏越小。 ”
    · 易理解性- “ 得到的信息越多,进行的测试越灵巧。 ”

    6 贴【 2004 5 15 】:实时系统测试

    Roger S. Pressman

    很多实时系统的时间依赖性和异步性给测试带来新的困难--时间!测试用例的设计者考虑的不仅是白盒和黑盒测试用例,而且包括事件处理(如中断处理)、数据的时间序列以及处理数据的任务(进程)的并发性。很多情况下,提供的测试数据有时使得实时系统在某状态下可以正常运行,而同样的数据在系统处于不同状态时有时又会导致错误。

    另外,实时系统的软件和硬件之间的密切关系也会导致测试问题,软件测试必须考虑硬件故障对软件处理的影响,这种故障很难实时仿真。由于实时系统的特殊性和复杂性,还没有一个完善的综合性的测试用例设计方法,但是,大致可以分为以下四个步骤:

    1 、任务测试。测试实时系统的第一步是独立的测试各个任务。对每一个任务设计白盒和黑盒测试用例,并在测试时执行每个任务。任务测试能够发现逻辑和功能错误,但是不能发现时间和行为错误。

    2 、行为测试。利用 CASE 工具创建软件模型,就可能仿真实时系统,并按照外部事件的序列检查其行为,这些分析活动可作为创建实时系统时设计测试用例的基础。

    3 、任务间测试。在隔离了任务内部和系统行为错误以后,测试就要转向时间相关的错误。用不同的数据率和处理负载来测试与其他任务通讯的异步任务,看任务间的同步是否会产生错误。另外,测试通过消息队列和数据存储进行通讯的任务,以发现这些数据存储区区域大小方面的错误。

    4 、系统测试。集成软件和硬件,并进行大范围的系统测试,以发现软件 / 硬件接口间的错误。

    7 贴【 2004 5 16 】:单元测试、集成测试、系统测试、验收测试、回归测试

    Software Research
    单元测试:单元测试是对软件中的基本组成单位进行的测试,如一个模块、一个过程等等。它是软件动态测试的最基本的部分,也是最重要的部分之一,其目的是检验软件基本组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的。因此,单元测试以被测试单位的规约为基准。单元测试的主要方法有控制流测试、数据流测试、排错测试、分域测试等等。

    集成测试:集成测试是在软件系统集成过程中所进行的测试,其主要目的是检查软件单位之间的接口是否正确。它根据集成测试计划,一边将模块或其他软件单位组合成越来越大的系统,一边运行该系统,以分析所组成的系统是否正确,各组成部分是否合拍。集成测试的策略主要有自顶向下和自底向上两种。

    系统测试:系统测试是对已经集成好的软件系统进行彻底的测试,以验证软件系统的正确性和性能等满足其规约所指定的要求,检查软件的行为和输出是否正确并非一项简单的任务,它被称为测试的 “ 先知者问题 ” 。因此,系统测试应该按照测试计划进行,其输入、输出和其他动态运行行为应该与软件规约进行对比。软件系统测试方法很多,主要有功能测试、性能测试、随机测试等等。

    验收测试:验收测试旨在向软件的购买者展示该软件系统满足其用户的需求。它的测试数据通常是系统测试的测试数据的子集。所不同的是,验收测试常常有软件系统的购买者代表在现场,甚至是在软件安装使用的现场。这是软件在投入使用之前的最后测试。

    回归测试:回归测试是在软件维护阶段,对软件进行修改之后进行的测试。其目的是检验对软件进行的修改是否正确。这里,修改的正确性有两重含义:一是所作的修改达到了预定目的,如错误得到改正,能够适应新的运行环境等等;二是不影响软件的其他功能的正确性。

    8 贴【 2004 5 17 】:软件测试策略

    Roger S. Pressman
    测试是一系列可以事先计划并且可以系统地进行管理的活动。正是由于这个原因,应当为软件工程过程定义一个软件测试的模板-我们可以把特定的测试用例方法放置进去的一系列步骤。

    人们已经提出了许多软件测试策略,所有这些策略都为如开发人员提供了一个供测试用的模板,而且它们都包含下列的类属特征:
    · 测试开始于模块层,然后 “ 延伸 ” 到整个基于计算机的系统集合中。
    · 不同的测试技术适用于不同的时间点。
    · 测试是由软件的开发人员和(对于大型系统而言)独立的测试组来管理的。
    · 测试和调试是不同的活动,但是调试必须能够适应任何的测试策略。

    软件测试策略必须提供可以用来检验一小段源代码是否得以正确实现的低层测试,同时也要提供能够验证整个系统的功能是否符合用户需求的高层测试。一种策略必须为使用者提供指南,并且为管理者提供一系列的重要的里程碑。因为测试策略的步骤是在软件完成的最终期限的压力已经开始出现的时候才开始进行的,所以测试的进度必须是可测量的,而且问题要尽可能早的暴露出来。

    9 贴【 2004 5 18 】:白盒测试

    Rex Black
    白盒测试,也称为结构化测试、基于代码的测试,是一种测试用例设计方法,它从程序的控制结构导出测试用例。用白盒测试产生的测试用例能够:
    1 )保证一个模块中的所有独立路径至少被使用一次;
    2 )对所有逻辑值均需测试 true 和 false ;
    3 )在上下边界及可操作范围内运行所有循环;
    4 )检查内部数据结构以确保其有效性。

    “ 我们应该更注重于保证程序需求的实现,为什么要花费时间和精力来担心(和测试)逻辑细节? ” 答案在于软件自身的缺陷:
    1 、逻辑错误和不正确假设与一条程序路径被运行的可能性成反比。当我们设计和实现主流之外的功能、条件或控制时,错误往往开始出现在我们工作中。日常处理往往被很好地了解,而 “ 特殊情况 ” 的处理则难于发现。
    2 、我们经常相信某逻辑路径不可能被执行,而事实上,它可能在正常的基础上被执行。程序的逻辑流有时是违反直觉的,这意味着我们关于控制流和数据流的一些无意识的假设可能导致设计错误,只有路径测试才能发现这些错误。
    3 、笔误是随机的。当一个程序被翻译为程序设计语言源代码时,有可能产生某些笔误,很多将被语法检查机制发现,但是,其他的会在测试开始时才会被发现。笔误出现在主流上和不明显的逻辑路径上的机率是一样的。

    正如 Beizer 所说的: “ 错误潜伏在角落里,聚集在边界上 ” ,而白盒测试更可能发现它。

    10 贴【 2004 5 19 】:黑盒测试

    黑盒测试注重于测试软件的功能性需求,也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品,而是用于辅助白盒测试发现其他类型的错误。黑盒测试试图发现以下类型的错误:
    1 )功能错误或遗漏;
    2 )界面错误;
    3 )数据结构或外部数据库访问错误;
    4 )性能错误;
    5 )初始化和终止错误。

    白盒测试在测试的早期采用,而黑盒测试主要用于测试的后期。黑盒测试故意不考虑控制结构,而是注意信息域。黑盒测试用于回答以下问题:
    1 )如何测试功能的有效性?
    2 )何种类型的输入会产生好的测试用例?
    3 )系统是否对特定的输入值尤其敏感?
    4 )如何分隔数据类的边界?
    5 )系统能够承受何种数据率和数据量?
    6 )特定类型的数据组合会对系统产生何种影响?

    运用黑盒测试方法,可以导出满足以下标准的测试用例集:
    1 )所设计的测试用例能够减少达到合理测试所需的附加测试用例数;
    2 )所设计的测试用例能够告知某些类型错误的存在或不存在,而不是仅仅与特定测试相关的错误。

    11 贴【 2004 5 20 】:软件测试充分性准则

    ( 1 )空测试对任何软件都是不充分的。
    ( 2 )对任何软件都存在有限的充分测试集合。
    ( 3 )如果一个软件系统在一个测试数据集合上的测试是充分的,那么再多测试一些数据也应该是充分的。这一特性称为单调性。
    ( 4 )即使对软件所有成分都进行了充分的测试,也并不意味着整个软件的测试已经充分了。这一特性称为非复合性。
    ( 5 )即使对一个软件系统整体的测试是充分的,也并不意味着软件系统中各个成分都已经充分地得到了测试。这个特性称为非分解性。
    ( 6 )软件测试的充分性应该与软件的需求和软件的实现都相关。
    ( 7 )软件越复杂,需要的测试数据就越多。这一特性称为复杂性。
    ( 8 )测试得越多,进一步测试所能得到的充分性增长就越少。这一特性称为回报递减率。

    12 贴【 2004 5 21 】:静态测试

    在软件开发过程中,每产生一个文档,都必须对它进行测试,以确定它的质量是否满足要求。这样的检查工作与全面质量管理的思想是一致的,也与项目管理过程相一致。每当一个文档通过了静态测试,就标志着一项开发工作的总结,标志着项目取得了一定的进展,进入了一个新的阶段。

    静态测试的基本特征是在对软件进行分析、检查和测试时不实际运行被测试的程序。它可以用于对各种软件文档进行测试,是软件开发中十分有效的质量控制方法之一。在软件开发过程中的早期阶段,由于可运行的代码尚未产生,不可能进行动态测试,而这些阶段的中间产品的质量直接关系到软件开发的成败与开销的大小,因此,在这些阶段,静态测试的作用尤为重要。在软件开发多年的生产实践经验和教训的基础上,人们总结出了一些行之有效的静态测试技术和方法,如结构化走通、正规检视等等。这些方法和测试技术可以与软件质量的定量度量技术相结合,对软件开发过程进行监视、控制,从而保障软件质量。

    13 贴【 2004 5 22 】:什么是测试需求?

    Brian Marick
    测试需求的概念比较简单。例如,比方说一个计算平方根的程序,如果输入一个大于或等于零的数,程序可以给出一个结果;如果输入一个小于零的数,程序将指出输入错误。读过《软件测试的艺术》一书的工程师都会立即联想到边界值。对数值零进行测试;对零非常接近的负数进行测试,这就是两个具体的测试需求。

    在一个更加复杂的程序中,你可以将打算测试的项目做成一个列表。但是,这些测试需求都不会确定具体的测试数据。例如,一个银行交易程序,一个测试需求是试图支付客户的金额为负数,另一个测试需求是交易中的客户并不存在,等等。你有一系列这样的测试需求,它们并没有指出具体的数值或数据,如客户的姓名。

    测试的下一步是选择满足这些测试需求的输入值 / 测试数据。一个简单的测试用例可能会同时满足好几个测试需求。一个用例能同时满足好几个测试需求,当然是最理想的情况,但是这样做的代价较高。另外一种方法是为每一个测试需求设计一个单独的测试用例,就可以不必考虑那些复杂的测试用例,但是这些相对简单的测试用例发现缺陷的能力就会有所下降。

    这里有一个测试需求的实例:对一个哈希表的插入操作进行测试,有以下这些测试需求:
    1 )插入一个新的条目
    2 )插入失败-条目已经存在
    3 )插入失败-表已满
    4 )哈希表在插入前为空
    这些就是测试需求,而非测试用例,因为它们没有对被插入元素进行描述。另外你也不能马上就着手书写用例,就好象软件需求完成后不能立即进行编码一样。还需要对测试需求进行评审,确保正确和没有需求遗漏。

    14 贴【 2004 5 30 】: GUI 测试

    Roger S. Pressman

    图形用户界面( GUI )对软件测试提出了有趣的挑战,因为 GUI 开发环境有可复用的构件,开发用户界面更加省时而且更加精确。同时, GUI 的复杂性也增加了,从而加大了设计和执行测试用例的难度。因为现在 GUI 设计和实现有了越来越多的类似,所以也就产生了一系列的测试标准。下列问题可以作为常见 GUI 测试的指南:

    窗口:
    · 窗口是否基于相关的输入和菜单命令适当地打开?
    · 窗口能否改变大小、移动和滚动?
    · 窗口中的数据内容能否用鼠标、功能键、方向键和键盘访问?
    · 当被覆盖并重新调用后,窗口能否正确地再生?
    · 需要时能否使用所有窗口相关的功能?
    · 所有窗口相关的功能是可操作的吗?
    · 是否有相关的下拉式菜单、工具条、滚动条、对话框、按钮、图标和其他控制可为窗口使用,并适当地显示?
    · 显示多个窗口时,窗口的名称是否被适当地表示?
    · 活动窗口是否被适当地加亮?
    · 如果使用多任务,是否所有的窗口被实时更新?
    · 多次或不正确按鼠标是否会导致无法预料的副作用?
    · 窗口的声音和颜色提示和窗口的操作顺序是否符合需求?
    · 窗口是否正确地被关闭?

    下拉式菜单和鼠标操作:
    · 菜单条是否显示在合适的语境中?
    · 应用程序的菜单条是否显示系统相关的特性(如时钟显示)?
    · 下拉式操作能正确工作吗?
    · 菜单、调色板和工具条是否工作正确?
    · 是否适当地列出了所有的菜单功能和下拉式子功能?
    · 是否可以通过鼠标访问所有的菜单功能?
    · 文本字体、大小和格式是否正确?
    · 是否能够用其他的文本命令激活每个菜单功能?
    · 菜单功能是否随当前的窗口操作加亮或变灰?
    · 菜单功能是否正确执行?
    · 菜单功能的名字是否具有自解释性?
    · 菜单项是否有帮助,是否语境相关?
    · 在整个交互式语境中,是否可以识别鼠标操作?
    · 如果要求多次点击鼠标,是否能够在语境中正确识别?
    · 光标、处理指示器和识别指针是否随操作恰当地改变?

    数据项:
    · 字母数字数据项是否能够正确回显,并输入到系统中?
    · 图形模式的数据项(如滚动条)是否正常工作?
    · 是否能够识别非法数据?
    · 数据输入消息是否可理解?

    15 贴【 2004 5 31 】: Client/Server 测试

    Roger S. Pressman

    通常,客户 / 服务器软件的测试发生在三个不同的层次:
    ( 1 )个体的客户端应用以 “ 分离的 ” 模式被测试 —— 不考虑服务器和底层网络的运行;
    ( 2 )客户端软件和关联的服务器端应用被一起测试,但网络运行不被明显的考虑;
    ( 3 )完整的 C/S 体系结构,包括网络运行和性能,被测试。

    下面的测试方法是 C/S 应用中经常用到的:
    应用功能测试 —— 客户端应用被独立地执行,以揭示在其运行中的错误。
    服务器测试 —— 测试服务器的协调和数据管理功能,也考虑服务器性能(整体反映时间和数据吞吐量)。
    数据库测试 —— 测试服务器存储的数据的精确性和完整性,检查客户端应用提交的事务,以保证数据被正确地存储、更新和检索。
    事务测试 —— 创建一系列的测试以保证每类事务被按照需求处理。测试着重于处理的正确性,也关注性能问题。
    网络通信测试 —— 这些测试验证网络节点间的通信正常地发生,并且消息传递、事务和相关的网络交通无错的发生。

  • [转] 软件测试常识

    2007-05-06 12:02:44

    [转]软件测试常识

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。

    Acceptance testing(验收测试),系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。

    Ad hoc testing (随机测试),没有书面测试用例、记录期望结果、检查列表、脚本或指令的测试。主要是根据测试者的经验对软件进行功能和性能抽查。随机测试是根据测试说明书执行用例测试的重要补充手段,是保证测试覆盖完整性的有效方式和过程。

    Alpha testing (α测试),是由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的受控测试,Alpha测试不能由程序员或测试员完成。

    Automated Testing(自动化测试),使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI、性能等测试中用得较多。

    Beta testing(β测试),测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场,Beta测试不能由程序员或测试员完成。

    Black box testing(黑盒测试),指测试人员不关心程序具体如何实现的一种测试方法。根据软件的规格对软件进行各种输入和观察软件的各种输出结果来发现软件的缺陷的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    Bug (错误),有时称作defect(缺陷)或error(错误),软件程序中存在的编程错误,可能会带来不必要的副作用,软件的功能和特性与设计规格说明书或用户需求不一致的方面。软件缺陷表现特征为:软件未达到产品说明书标明的功能;软件出现产品说明书指明不会出现的错误;软件功能超出产品说明书指明的范围;虽然产品说明书未指出但是软件应达到的目标;软件测试人员或用户认为软件难以理解,不易使用,运行速度缓慢等问题。

    Bug report(错误报告),也称为“Bug record(错误记录)”,记录发现的软件错误信息的文档,通常包括错误描述、复现步骤、抓取的错误图像和注释等。

    Bug tracking system(错误跟踪系统,BTS),也称为“Defect tracking system,DTS”,管理软件测试缺陷的专用数据库系统,可以高效率地完成软件缺陷的报告、验证、修改、查询、统计、存储等任务。尤其适用于大型多语言软件的测试管理。

    Build(工作版本),软件开发过程中用于内部测试的功能和性能等不完善的软件版本。工作版本既可以是系统的可操作版本,也可以是展示要在最终产品中提供的部分功能的部分系统。

    Compatibility Testing(兼容性测试),也称“Configuration testing(配置测试)”,测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。验证测试对象在不同的软件和硬件配置中的运行情况。

    Capture/Replay Tool (捕获/回放工具),一种测试工具,能够捕获在测试过程中传递给软件的输入,并且能够在以后的时间中,重复这个执行的过程。这类工具一般在GUI测试中用的较多。

    Crash(崩溃),计算机系统或组件突然并完全的丧失功能,例如软件或系统突然退出或没有任何反应(死机)。

    Debug(调试),开发人员确定引起错误的根本原因和确定可能的修复措施的过程。一般发生在子系统或单元模块编码完成时,或者根据测试错误报告指出错误以后,开发人员需要执行调试过程来解决已存在的错误。

    Deployment(部署),也称为shipment(发布),对内部IT系统而言,指它的第一个版本通过彻底的测试、形成产品、交付给付款客户的阶段。

    Dynamic testing(动态测试),通过执行软件的手段来测试软件。

    Exception(异常/例外),一个引起正常程序执行挂起的事件。

    Functional testing (功能测试),也称为behavīoral testing(行为测试),根据产品特征、操作描述和用户方案,测试一个产品的特性和可操作行为以确定它们满足设计需求。本地化软件的功能测试,用于验证应用程序或网站对目标用户能正确工作。使用适当的平台、浏览器和测试脚本,以保证目标用户的体验将足够好,就像应用程序是专门为该市场开发的一样。

    Garbage characters(乱码字符),程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。

    GB 18030 testing(GB 18030测试),软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

    Installing testing(安装测试),确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装、升级、完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    Integration testing(集成测试),被测试系统的所有组件都集成在一起,找出被测试系统组件之间关系和接口中的错误。该测试一般在单元测试之后进行。

    International testing(国际化测试),国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。

    Localizability testing(本地化能力测试),本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力侧是通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。

    Load testing(负载测试),通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

    Localization testing(本地化测试),本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

    Performance testing(性能测试),评价一个产品或组件与性能需求是否符合的测试。包括负载测试、强度测试、数据库容量测试、基准测试等类型。

    Pilot testing(引导测试),软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。

    Portability testing(可移植性测试),测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。
    Priority(优先权),从商业角度出发是指错误的重要性,尤其是从客户和用户的角度出发,是指错误对于系统的可行性和可接受性的影响。与“Severity(严重性)”相对照。

    Quality assurance(质量保证QA),采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    Regression testing(回归测试),在发生修改之后重新测试先前的测试以保证修改的正确性。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修复的错误是否在新软件版本上再现。

    Review(评审),在产品开发过程中,把产品提交给项目成员、用户、管理者或其它相关人员评价或批准的过程。

    Sanity testing(健全测试),软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考“Smoke testing(冒烟测试)”。

    Screen shot(抓屏、截图),软件测试中,将软件界面中的错误(窗口、菜单、对话框等)的全部或一部分,使用专用工具存储成图像文件,以便于后续处理。

    Severity(严重性),错误对被测系统的影响程度,在终端用户条件下发生的可能性,软件错误妨碍系统使用的程度。与“Priority(优先权)”相对照。

    Smoke testing(冒烟测试),冒烟测试的对象是每一个新编译的需要正式测试的软件版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity testing(健全测试)”。

    Software life cycle(软件生命周期),开始于一个软件产品的构思,结束于该产品不再被使用的这段期间。

    Static testing(静态测试),不通过执行来测试一个系统。如代码检查,文档检查和评审等。

    Structured query language(结构化查询语句,SQL),在一个关系数据库中查询和处理数据的一种语言。

    TBD(To be determined,待定),在测试文档中标是一项进行中的尚未最终确定的工作。

    Test(测试),执行软件以验证其满足指定的需求并检测错误的过程。检测已有条件之间的不同,并评价软件项的特性软件项的分析过程。软件工程过程的一个活动,它将软件在预定的条件下运行以判断软件是否符合预期结果。

    Test case(测试用例),为特定目标而开发的一组测试输入、执行条件和预期结果,其目标可以是测试某个程序路径或核实是否满足某个特定的需求。

    Testing coverage(测试覆盖),指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。

    Testing environment(测试环境),进行测试的环境,包括测试平台、测试基础设施、测试实验室和其他设施。

    Testing item(测试项),作为测试对象的工作版本。

    Testing plan(测试计划),描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务,并且任何风险都要冲突计划。

    Testing procedure(测试过程),指设置、执行给定测试用例并对测试结果进行评估的一系列详细步骤。

    Testing scrīpt(测试脚本),一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。

    Testing suite(测试包),一组测试用里的执行框架;一种组织测试用例的方法。在测试包里,测试用例可以组合起来创造出独特的测试条件。

    Unit testing(单元测试),指一段代码的基本测试,其实际大小是未定的,通常是一个函数或子程序,一般由开发者执行。

    User interface(用户界面,UI),广义是指使用户可以和计算机进行交互的硬件和/或软件。狭义是指软件中的可见外观及其底层与用户交互的部分(菜单、对话框、窗口和其它控件)。

    User interface testing (用户界面测试),指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。

    White box testing(白盒测试),根据软件内部的工作原理分析来进行测试,基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。
     
    此文来源于51testing博客,转载请注明出处

  • [转] 软件测试的14种类型

    2007-04-14 18:12:18

     

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

    1 数据和数据库完整性测试

    数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。
    数据库完整性原即:
    主码完整性:主码不能为空;
    外码完整性:外码必须等于对应的主码或者为空。
    数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。
    在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统 (DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

    比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。
    员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。


    2 白盒测试

    白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试
    2.1 静态白盒测试
    利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:
    Function NameGet(){
    ….
    }
    这是属于不符合开发规范的错误。
    有这样一段代码:
    if (i<0) & (i>=0)

    这段代码交集为整个数轴,IF语句没有必要
    I=0;
    while(I>100){
    J=J+100;
    T=J*PI;
    }
    在循环体内没有I的增加,bug产生。

    2.2 动态白盒测试
    利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。
    看一段代码
    if(I<0){
    P1
    }else{
    P2
    }
    在调试中输入I=-1,P1程序段通过, P2程序段未通过,属于动态黑盒测试的缺陷

    3.功能测试

    功能测试指测试软件各个功能模块是否正确,逻辑是否正确。
    对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面 (GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。
    比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

    4.UI测试

    UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等
    用户界面 (UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保 UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关
    比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

    5.性能测试

    性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试
    5.1负载测试
    负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
    在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。
    比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?
    5.2强度测试
    强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。
    实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。
    比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。
    5.3数据库容量测试
    数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。
    数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。
    比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。
    5.4基准测试
    基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。
    如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。
    5.5竞争测试
    软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行?

    6. 安全性和访问控制测试

    安全性和访问控制测试侧重于安全性的两个关键方面:
    应用程序级别的安全性,包括对数据或业务功能的访问
    系统级别的安全性,包括对系统的登录或远程访问。
    6.1应用程序级别的安全性
    可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。
    比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?
    6.2系统级别的安全性
    可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。
    比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

    7.故障转移和恢复测试

    故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。
    故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。
    故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。
    恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出 (I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意主备定时备份
    比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?

    8.配置测试

    又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)
    下面列出主要配置测试
    8.1浏览器兼容性
    测试软件在不同产商的浏览器下是否能够正确显示与运行;
    比如测试IE,Natscape浏览器下是否可以运行这套软件?
    8.2操作系统兼容性
    测试软件在不同操作系统下是否能够正确显示与运行;
    比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?
    8.3硬件兼容性
    测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.
    比如在INTER,舒龙CPU芯片下系统是否能够正常运行?
    这样的测试必须建立测试实验室,在各种环境下进行测试。

    9.安装测试

    安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。
    安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

    10.多语种测试

    又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。
    本地化测试还要考虑:
    l 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为 “View advertisement”可能影响页面的美观程度
    l 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。
    l 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

    11.文字测试

    文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。
    比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

    12.分辨率测试

    测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

    13发布测试

    主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

    13.1说明书测试
    主要为语言检查,功能检查,图片检查
    语言检查:检查说明书语言是否正确,用词是否易于理解;
    功能检查:功能是否描述完全,或者描述了并没有的功能等;
    图片检查::检查图片是否正确
    13.2宣传材料测试
    主要测试产品中的附带的宣传材料中的语言,描述功能,图片
    13.3帮助文件测试
    帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。
    13.4广告用语
    产品出公司前的广告材料文字,功能,图片,人性化的检查

    14 文档审核测试

    文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

    文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

    14.1需求文档测试

    主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

    14.2设计文档测试

    测试设计是否符合全部需求以及设计是否合理。

    总结

    据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。
  • 软件测试类型知多少?

    2007-04-14 13:11:16

    软件测试类型知多少?

    软件测试的类型多种多样,测试类型与被测软件的测试需求相关。对于初学者,需要了解最常见的测试类型,也有必要了解其他的测试类型,作为进一步提高的目标。 

    以下转载了比较齐全的测试类型,请那位朋友帮助把全文翻译一下。

    • 黑盒测试(Black box testing)
      • not based on any knowledge of internal design or code. Tests are based on requirements and functionality.
    • 白盒测试(White box testing)
      • based on knowledge of the internal logic of an application's code. Tests are based on coverage of code statements, branches, paths, conditions.
    • 单元测试(unit testing)
        
      • the most 'micro' scale of testing; to test particular functions or code modules. Typically done by the programmer and not by testers, as it requires detailed knowledge of the internal program design and code. Not always easily done unless the application has a well-designed architecture with tight code; may require developing test driver modules or test harnesses.
    • 增量集成测试(incremental integration testing)
      • continuous testing of an application as new functionality is added; requires that various aspects of an application's functionality be independent enough to work separately before all parts of the program are completed, or that test drivers be developed as needed; done by programmers or by testers.
    • 集成测试(integration testing)
      • testing of combined parts of an application to determine if they function together correctly. The 'parts' can be code modules, individual applications, client and server applications on a network, etc. This type of testing is especially relevant to client/server and distributed systems.
    • 功能测试(functional testing)
      • black-box type testing geared to functional requirements of an application; this type of testing should be done by testers. This doesn't mean that the programmers shouldn't check that their code works before releasing it (which of course applies to any stage of testing.)
    • 系统测试(system testing)
      • black-box type testing that is based on overall requirements specifications; covers all combined parts of a system.
    • 端到端测试(end-to-end testing)
      • similar to system testing; the 'macro' end of the test scale; involves testing of a complete application environment in a situation that mimics real-world use, such as interacting with a database, using network communications, or interacting with other hardware, applications, or systems if appropriate.
    • 健全测试或冒烟测试(sanity testing or smoke testing)
      • typically an initial testing effort to determine if a new software version is performing well enough to accept it for a major testing effort. For example, if the new software is crashing systems every 5 minutes, bogging down systems to a crawl, or corrupting databases, the software may not be in a 'sane' enough condition to warrant further testing in its current state.
    • 回归测试(regression testing)
      • re-testing after fixes or modifications of the software or its environment. It can be difficult to determine how much re-testing is needed, especially near the end of the development cycle. Automated testing tools can be especially useful for this type of testing.
    • 验收测试(acceptance testing)
      • final testing based on specifications of the end-user or customer, or based on use by end-users/customers over some limited period of time.
    • 负载测试(load testing)
      • testing an application under heavy loads, such as testing of a web site under a range of loads to determine at what point the system's response time degrades or fails.
    • 压力测试(stress testing)
      • term often used interchangeably with 'load' and 'performance' testing. Also used to describe such tests as system functional testing while under unusually heavy loads, heavy repetition of certain actions or inputs, input of large numerical values, large complex queries to a database system, etc.
    • 性能测试(performance testing)
      • term often used interchangeably with 'stress' and 'load' testing. Ideally 'performance' testing (and any other 'type' of testing) is defined in requirements documentation or QA or Test Plans.
    • 易用性测试(usability testing)
      • testing for 'user-friendliness'. Clearly this is subjective, and will depend on the targeted end-user or customer. User interviews, surveys, video recording of user sessions, and other techniques can be used. Programmers and testers are usually not appropriate as usability testers.
    • 安装/卸载测试(install/uninstall testing)
      • testing of full, partial, or upgrade install/uninstall processes.
    • 恢复测试(recovery testing)
      • testing how well a system recovers from crashes, hardware failures, or other catastrophic problems.
    • 故障复原测试(failover testing)
      • typically used interchangeably with 'recovery testing'
    • 安全性测试(security testing)
      • testing how well the system protects against unauthorized internal or external access, willful damage, etc; may require sophisticated testing techniques.
    • 兼容性测试(compatability testing)
      • testing how well software performs in a particular hardware/software/operating system/network/etc. environment.
    • 探索性测试(exploratory testing)
      • often taken to mean a creative, informal software test that is not based on formal test plans or test cases; testers may be learning the software as they test it.
    • 随机测试(ad-hoc testing)
      • similar to exploratory testing, but often taken to mean that the testers have significant understanding of the software before testing it.
    • 上下文驱动测试(context-driven testing)
      • testing driven by an understanding of the environment, culture, and intended use of software. For example, the testing approach for life-critical medical equipment software would be completely different than that for a low-cost computer game.
    • 用户验收测试(user acceptance testing)
      • determining if software is satisfactory to an end-user or customer.
    • 对比测试(comparison testing)
      • comparing software weaknesses and strengths to competing products.
    • Alpha 测试(alpha testing)
      • testing of an application when development is nearing completion; minor design changes may still be made as a result of such testing. Typically done by end-users or others, not by programmers or testers.
    • Beta测试(beta testing)
      • testing when development and testing are essentially completed and final bugs and problems need to be found before final release. Typically done by end-users or others, not by programmers or testers.
    • 植入测试(mutation testing)
      • a method for determining if a set of test data or test cases is useful, by deliberately introducing various code changes ('bugs') and retesting with the original test data/cases to determine if the 'bugs' are detected. Proper implementation requires large computational resources.

    原始出处:http://www.softwareqatest.com/qatfaq1.html

Open Toolbar