用最简单的方法,做最复杂的测试。

软件测试相关专业术语

上一篇 / 下一篇  2010-09-07 11:00:13 / 个人分类:基础知识

  • Software Development Life Cycle(软件生命周期):SDLC是软件的产生直到报废的生命周期,周期内有问题定义,可行性分析,总体描述,系统设计,编码,调试和测试,验收与运行,维护升级到废弃等阶段,这种按时间分程的思想方法是软件工程中的一种思想原则,即按部就班,逐步推进,每个阶段都要有定义,工作,审查,形成文档以供交流或备查,以提高软件的质量。但随着新的面向对象的设计方法和技术的成熟,软件生命周期设计方法的指导意义正在逐步减少。

 

  • Software Quality Assurance软件质量保证):SQA介入于整个软件开发过程——监督和改进过程,确认达成的标准和过程被正确的遵循,保证问题被发现和解决。它以预防为主。
  • Software Testing软件测试:软件测试是在一定控制的条件下,围绕一个系统或应用的操作并评价其结果(一个最简单的例子:如果用户使用硬件A,在应用接口B上做了操作C,那么结果D应当出现),控制的条件应当包括正常和异常的条件。测试企图使事情变得很糟糕,从而来检测出一些应当发生而没有发生,或者不应当发生而发生的事情。测试以检测为主。

 

  • Black Box Testing黑盒测试:又称功能测试或数据驱动测试。它是通过测试来检测每个功能是否都能正常使用。在测试中,把程序看作一个不能打开的黑盒子,在完全不考虑程序内部和内部特性的情况下,在程序接口进行测试,它只检查程序功能是否按照需求规格说明书的规定正常使用,程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构,不考虑内部逻辑结构,主要针对软件界面和软件功能进行测试。(ISTQB/CSTQB)不考虑组件和系统内部结构的功能或非功能测试。
  • White Box Testing白盒测试:又称结构测试或逻辑驱动测试。它是按照程序内部的结构测试程序,通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行,检验程序中的每条通路是否都能按预定要求正确工作。这一方法是把测试对象看作一个打开的盒子,测试人员依据程序内部逻辑结构相关信息,设计或选择测试用例,对程序所有逻辑路径进行测试,通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。(ISTQB/CSTQB)通过分析组件/系统内部结构进行的测试。

 

  • Functional Test(功能测试):是一种黑盒测试,同应用程序的功能需求紧密相关,对各功能进行验证。这类测试应当由测试人员来完成。这并不意味着开发人员在发布版本之前就不需要检查他们的代码。(ISTQB/CSTQB)通过对组件/系统功能规格说明的分析而进行的测试。
  • Performance Test性能测试:该术语通常同负载测试和压力测试是可交换的。理想的性能测试是定义在需求文档或QA测试计划中的。性能测试是通过自动化工具模拟多种正常,峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。
    • Load Testing(负载测试):通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力,在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特性,当负载逐渐增加时,系统各项性能指标的变化情况,例如,响应时间,事务处理速度和其他与时间相关的方面。
    • Stress Testing(压力测试):压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。通俗地讲,压力测试是为了发现在什么条件下您的应用程序的性能会变得不可接受。

 

  • Unit Testing单元测试:单元测试是在软件开发过程中要进行的最低级别的活动,在单元测试活动中,软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用,单元测试必须是可重复的,无论是在软件修复,或是移植到新的运行环境的过程中。因此,所有的测试都必须在整个软件系统的生命周期中进行维护。该测试一般由开发者完成而不是由测试人员完成。该测试的容易程度同代码设计的好坏直接相关。
    • Code Review(代码走读):
    • Static Analysis(静态分析):对软件的源代码进行研读,查找错误或收集一些度量数据,并不需要对代码进行编译和执行。
    • Dynamic Analysis(动态分析):通过观察软件运行时的动作,来提供执行跟踪,时间分析,以及测试覆盖度方面的信息。
  • Integration Testing(集成测试):又称组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求(如根据结构图)组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。这类型测试典型的是与客户/服务器和分布式系统相关。
    • (非增量式集成测试):有些设计人员习惯于把所有模块按设计要求一次性全部组装起来,然后进行整体测试。这种方法容易出现混乱。因为测试时可能发现一大堆错误,为每个错误定位和纠正非常困难,并且在改正一个错误的同时又可能引入新的错误,新旧错误混杂,更难断定出错的原因和位置。
    • (增量式集成测试):程序一段一段地扩展,测试范围一步一步地增大,错误易于定位和纠正,界面的测试亦可做到完全彻底。
  • System Testing系统测试:

 

  • Acceptance Testing(验收测试):系统开发生命周期方法论的一个阶段,这时相关的用户和/或独立测试人员根据测试计划和结果对系统进行测试和接收。它让系统用户决定是否接收系统。它是一项确定产品是否能够满足合同或用户所规定需求的测试。这是管理性和防御性控制。
    • (正式验收测试):正式验收测试是一项管理严格的过程,它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向,这一点很重要。在很多组织中,正式验收测试是完全自动执行的。
    • (非正式验收测试)/Alpha Testingα测试):由一个用户在开发环境下进行的测试,也可以是公司内部的用户在模拟实际操作环境下进行的测试。目的是评价软件产品的FLURPS(即功能,局域化,可使用性,可靠性,性能和支持)。尤其注重产品的界面和特色。α测试可以从软件产品编码结束之时开始,或在模块(子系统)测试完成之后开始,也可以在确认测试过程中产品达到一定的稳定和可靠程度之后再开始。它是一种受控测试。α测试不能由程序人员或测试人员完成。
    • Beta Testingβ测试):软件开发公司组织各方面的典型用户在日常工作中实际使用β版本,并要求用户报告异常情况,提出批评意见,然后软件开发公司再对β版本进行改错和完善。β测试也是黑盒测试。黑盒测试也称功能测试,它是通过测试来检测每个功能是否都能正常使用。它是一种不受控测试。β测试不能由程序人员或测试人员完成。开发者通常不在现场。

 

  • Regression Testing(回归测试):在软件或环境被修改后进行的测试。理论上,对软件的任何新版本,都需要进行回归测试,验证以前发现和修改的错误是否在新软件版本上再现。可能很难确定我们需要进行多少次的再测试,尤其接近到开发过程的末期。因此,通过选择正确的回归测试策略来改进回归测试的效率和有效性是非常有意义的。自动测试工具可能会油很大的帮助。
  • Ad-Hoc Testing(随机测试):软件测试中除了根据测试样例和测试说明书进行测试外,还需要进行随机测试,是根据测试说明书执行样例测试的重要补充手段,使保证测试覆盖完整性的有效方式和过程。主要是根据测试者的经验对软件进行重要功能和性能抽查。(ISTQB/CSTQB)非正式的测试执行。即没有正式的测试准备,规格设计和技术应用,也没有期望结果和必须遵循的测试执行指南。

 

  • International Testing(国际化测试):国际化测试的目的是测试软件的国际化支持能力,发现软件的国际化的潜在问题,保证软件在世界不同区域中都能正常运行。国际化测试使用每种可能的国际输入类型,针对任何区域性或区域设置检查产品的功能是否正常,软件国际化测试的重点在于执行国际字符串的输入/输出功能。国际化测试数据必须包含东亚语言、德语、复杂脚本字符和英语(可选)的混合字符。
  • Localizability Testing(本地化能力测试):本地化能力是指不需要重新设计或修改代码,将程序的用户界面翻译成任何目标语言的能力。为了降低本地化能力测试的成本,提高测试效率,本地化能力测试通常在软件的伪本地化版本上进行。本地化能力测试中发现的典型错误包括:字符的硬编码(即软件中需要本地化的字符写在了代码内部),对需要本地化的字符长度设置了国定值,在软件运行时以控件位置定位,图标和位图中包含了需要本地化的文本,软件的用户界面与文档术语不一致等。
  • Localization Testing(本地化测试):本地化测试的对象是软件的本地化版本。本地化测试的目的是测试特定目标区域设置的软件本地化质量。本地化测试的环境是在本地化的操作系统上安装本地化的软件。从测试方法上可以分为基本功能测试,安装/卸载测试,当地区域的软硬件兼容性测试。测试的内容主要包括软件本地化后的界面布局和软件翻译的语言质量,包含软件、文档和联机帮助等部分。

 

  • Pilot Testing(引导测试):软件开发中,验证系统在真实硬件和客户基础上处理典型操作的能力。在软件外包测试中,引导测试通常是客户检查软件测试公司测试能力的一种形式,只有通过了客户特定的引导测试,软件测试公司才能接受客户真实软件项目的软件测试。
  • End to End Testing(端到端测试):同系统测试类似,包括模拟现实世界对一个完整的应用环境进行测试。例如同数据库进行交互,使用网络通信,或者其他的软件,硬件和系统进行交互。
  • Rational Testing(理智测试):这是一种典型的原始测试,其目的是要确定一个新的软件版本在一些主要的测试努力下表现得足够好并且可以接受。例如:如果一个新软件每五分钟当机一次,使系统执行速度极其缓慢,或者破坏系统数据,那么该软件就处于不够理智状态,必须保证在当前状态下进行进一步测试。
  • Smoke Testing(冒烟测试):冒烟测试的对象是每一个新编译的需要正式测试的版本,目的是确认软件基本功能正常,可以进行后续的正式测试工作。冒烟测试的执行者是版本编译人员。参考“Sanity Testing(健全测试)
  • Sanity Testing(健全测试):软件主要功能成份的简单测试以确认它是否能进行基本的测试。
  • Recovery Testing(恢复测试):又称Recoverability Testing(可恢复性测试)或Reliability Testing(可靠性测试)。测试当出现崩溃,硬件错误或其他灾难性问题时,系统的表现情况。
  • Safety Testing(安全性测试)测试系统对于内部和外部非法入侵,故意损坏时的表现情况。可能需要复杂的测试技术
  • Compatibility Testing(兼容性测试):又称Configuration Testing(配置测试)或Portability Testing(可移植性测试)。
    • 测试软件是否和系统中其它与之交互的元素之间兼容,如:浏览器,操作系统,硬件等。验证测试对象在不同软件和硬件配置中的运行情况。
    • 测试软件是否可以被成功移植到指定的硬件或软件平台上。
  • Installability Testing(安装和反安装测试):测试软件可安装性的过程。确保该软件在正常情况和异常情况的不同条件下,例如,进行首次安装,升级,完整的或自定义的安装都能进行安装。异常情况包括磁盘空间不足,缺少目录创建权限等。核实软件在安装后可立即正常运行。安装测试包括安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。
  • User Interface Testing(用户界面测):指测试用户界面的风格是否满足客户要求,文字是否正确,页面是否美观,文字,图片组合是否完美,操作是否友好等等。UI测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。确保用户界面符合公司或行业的标准。包括用户友好性、人性化、易操作性测试。 

 

  • Automated Testing自动化测试一般是指软件测试的自动化,把以人为驱动的测试行为转化为机器执行的一种过程。为了节省人力,时间或硬件资源,提高测试效率,便引入了自动化测试。使用自动化测试工具来进行测试,这类测试一般不需要人干预,通常在GUI,性能等测试中用得比较多。
  • Testing Coverage(测试覆盖):指测试系统覆盖被测试系统的程度,一项给定测试或一组测试对某个给定系统或构件的所有指定测试用例进行处理所达到的程度。
  • Garbage characters(乱码字符):程序界面中显示的无意义的字符,例如,程序对双字节字符集的字符不支持时,这些字符不能正确显示。
  • GB 18030 testingGB 18030测试):软件支持GB 18030字符集标准能力的测试,包括GB 18030字符的输入、输出、显示、存储的支持程度。

 

  • Testing Plan(测试计划):描述了要进行的测试活动的范围,方法,资源和进度的文档。它确定测试项,被测特性,测试任务,谁执行任务,各种可能的风险。测试计划可以有效预防计划的风险,保障计划的顺利实施。
  • Testing Environment(测试环境):进行测试的环境,包括测试平台,测试基础设施,测试实验室和其他设施。
  • Testing Script(测试脚本):一般指的是一个特定测试的一系列指令,这些指令可以被自动化测试工具执行。为了提高测试脚本的可维护性和可复用性,必须在执行测试脚本之前对它们进行构建。测试脚本可以被创建(记录)或使用测试自动化工具自动生成,或用编程语言来完成,也可综合前三种方法来完成。
  • Test Case(测试用例):是为了某个特殊目标而编制的一组测试输入,执行条件以及与其结果,以便测试某个程序路径或核实

TAG:

ericzhou2009的个人空间 引用 删除 ericzhou2009   /   2010-09-08 12:21:27
谢谢楼主!
 

评分:0

我来说两句

日历

« 2024-05-01  
   1234
567891011
12131415161718
19202122232425
262728293031 

数据统计

  • 访问量: 18418
  • 日志数: 46
  • 建立时间: 2010-08-18
  • 更新时间: 2010-10-11

RSS订阅

Open Toolbar