发布新日志

  • QTP中的测试对象和运行时对象

    xiaonan 发布于 2006-12-15 17:32:11

         相信大家在QTP中肯定都看到过这些方法,GetROPropertyGetTOPropertySetTOProperty .

    GetROProperty:可以取到运行时对象属性的值.

    GetTOProperty:可以取到测试对象属性的值.

    SetTOProperty:可以修改测试对象的属性值

        那这里的运行时对象和测试对象又是什么呢?他们之间又存在着什么样的关系呢?

    测试对象(TO):是QTP在脚本中创建的用于描述应用程序实际对象的对象.QTP存储这些信息用来在运行时识别和检查对象.简单的说,我们就可以把对象库中所保存的对象就看做为测试对象.

    运行时对象(RO):是应用程序中的实际对象,对象的方法将在运行时被执行.

    两者之间的关系:测试对象是为了识别运行时对象而存在的.在《QTP的录制回放过程》中,我也阐述了QTP的整个工作原理。所以这里我也就简单的再提一下。QTP在录制的时候会把所操作的对象的一组属性及属性值,保存到对象库中,就是所谓的测试对象。在回放的时候,QTP 就会根据对象库里的该对象的属性及属性值去匹配实际在应用程序中的运行时对象。一但完全匹配正确就执行相应的操作。否则就会报“找不到该对象”的错。

  • (转)vbs之createobject大全收藏

    shuishixingyu 发布于 2009-01-19 17:12:19

    ADO对象
    Connection
    Command
    RecordSet
    Record
    Stream


    Server.CreateObject("scrīpting.FileSystemObject")
    Server.CreateObject("scrīpting.Dictionary")   HashTable
    Server.CreateXObject("Word.Application")    //Server
    ActiveXObject("Word.Application")    //Client
    Server.CreateObject("Excel.Application")   //Server
    ActiveXObject("Excel.Application")    //Client
    CreateObject("PowerPoint.Application")
    Server.CreateObject("Microsoft.XMLHTTP")
    Server.CreateObject("Microsoft.XMLDOM")
    Server.CreateObject("MSXML2.XMLHTTP.4.0")
    Server.CreateObject("Wscrīpt.Shell")
    Server.CreateObject("wscrīpt.network") 
    Server.CreateObject("MSWC.AdRotator")
    CreateObject("Excel.Sheet")
    MS FrontPage: oFP = CreateObject("FrontPage.Application")
    MS Access: oAccess = CreateObject("Access.Application")
    MS Graph: oGraph = CreateObject("MSGraph.Application")


    CreateObject("PhotoShop.Application")

    CreateObject("SQLDMO.SQLServer")
    CreateObject("SQLDMO.Login")
    CreateObject("SQLDMO.Backup")
    CreateObject("SQLDMO.User")
    Server.CreateObject("SQLDMO.BackupDevice")
    Server.CreateObject("SQLDMO.Database")
    Server.CreateObject("SQLDMO.Restore")

    Server.CreateObject("MSMQ.MSMQQueueInfo")
    CreateObject("MSMQ.MSMQQuery")
    Server.CreateObject("ixsso.Query")
    Server.CreateObject("ixsso.Util")

    AccPac Advantage Corporate: 
    oAccPac=CreateObject("ACCPAC.xapiSession")

    AccPac Report Master for Windows: 
    oImpApp=CreateObject("Impromptu.Application.30")

    BarTender: 
    oBarTender = CreateObject("BarTender.Application")

    CrystalReports: 
    oCRApplication = createobject ("CrystalRuntime.Application") 
    This doesn't invoke an IDE actually.

    EUDORA: 
    oEud = CreateObject("Eudora.EuApplication.1")

    FaxMaker: 
    oFax = CREATEOBJECT("fmfaxapi.application")

    GroupWise:
    oGroupWise = CreateObject("NovellGroupWareSession")

    LotusNotes: 
    oNotes = CreateObject("Notes.NotesSession")
    oNotes = CreateObject("Notes.NotesUIWorkspace")
    oNotes = CreateObject("Lotus.Notessession") (Domino 5.0.3)

    MS Common Dialog: 
    oCommmonDialog = CreateObject("MSComDlg.CommonDialog") && !!! You can't directly create this object without a development licence, so for dynamically doing it on another machine, see below. -- PeterCrabtree

    MS Internet Explorer: 
    oIE = CreateObject("InternetExplorer.Application") 
    IEAutomationExample

    MS MapPoint:
    oMapPoint = CreateObject("MapPoint.Application")

    MSN Messenger:
    oMessenger = CREATEOBJECT("MSNMessenger.MessengerApp")

    MS NetMeeting:
    oNetMeeting=CREATEOBJECT("netmeeting.app.1")

    MS Outlook: 
    oOutlook = CreateObject("Outlook.Application")

    MS Outlook Express: None - It is not a COM server!

    MS PowerPoint: 
    oPP = CreateObject("PowerPoint.Application")

    MS Project: 
    oProj = CreateObject("msProject.Application")

    MS SourceSafe: 
    oVSS = CreateObject("SourceSafe.0")

    MS Word: 
    oWord = CreateObject("Word.Application")

    MS Visio: 
    oVisio = CreateObject("Visio.Application")


    MS VisualCPlusPlus: (VC++)
    oCpp = CreateObject("MSDev.Application")

    MS VisualFoxpro: 
    oVFP = CreateObject("VisualFoxPro.Application")

    MS WindowsscrīptingHost: 
    oWSH = CreateObject("Wscrīpt.Shell") 

    Novell GroupWise: 
    oGroupWise = CreateObject("NovellGroupWareSession")

    PCAnywhere (host): 
    oPCAHost = CreateObject("WinAWSvr.BeHostDataManager")

    PCAnywhere (remote): 
    oPCARem = CreateObject("WinAWSvr.RemoteDataManager")

    QuickBooks: 
    QBSessionManager = CreateObject("QBFC2.QBSessionManager")

    RationalRose: 
    oRose = CreateObject("Rose.Application")

    TAPIFax: 
    oTAPIFax = CreateObject('FaxServer.FaxServer')

    WindowsShell: 
    oWSH = CreateObject("Shell.Application")

    Windows Media Player: 

    oWMP = CREATEOBJECT("WMPlayer.OCX")
    oPlayList = oWmp.PlaylistCollection.GetAll()
    oWmp.currentPlaylist = oPlayList.Item(0) && Zero based array
    *!* Music starts!

    Windows Messenger: 
    oMessenger = CREATEOBJECT("Messenger.MessengerApp")

    WinFax: 
    oWinFax = CreateObject("WinFax.SDKSend") 

    WinPrint : 
    oWinPrint = CreateObject("WinPrint.WinPrintX")

    SQL-DMO object: 
    loSQL = CREATEOBJECT("SQLDMO.Application")

    Others:

    scrīpting Shell: 
    oShell = CreateObject("Wscrīpt.Shell")

    scrīpting Network Object: 
    oNet = CreateObject("Wscrīpt.Network")

    scrīpting Regular Expression Parser: 
    oReg = CreateObject("VBscrīpt.RegExp")

    SQL DMO SQL Server: 
    CreateObject("SQLDMO.SQLServer")

  • 面试试题(转)

    zhoulihua 发布于 2007-05-04 09:33:42

    面试题目:
    01. 为什么要在一个团队中开展软件测试工作?
    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。
    02. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?
    我曾经做过web测试,后台测试,客户端软件,其中包括功能测试性能测试,用户体验测试。最擅长的是功能测试
    03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)
    测试类型有:功能测试,性能测试,界面测试。
    功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。
    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。
    界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。
    区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试
    05.  请试着比较一下黑盒测试白盒测试单元测试集成测试系统测试、的区别与联系。
    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。
    白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。
      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:
    1、是否有不正确或遗漏的功能?
    2、在接口上,输入是否能正确的接受?能否输出正确的结果?
    3、是否有数据结构错误或外部信息(例如数据文件)访问错误?
    4、性能上是否能够满足要求?
    5、是否有初始化或终止性错误?
      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:
    1、对程序模块的所有独立的执行路径至少测试一遍。
    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。
    3、在循环的边界和运行的界限内执行循环体。
    4、测试内部数据结构的有效性,等等。
    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。
          单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。
    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。
    系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)
           系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。
    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。
    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。
    06. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?
    软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。
    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)
    07. 您认为做好测试计划工作的关键是什么?
    1. 明确测试的目标,增强测试计划的实用性
    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确
    2.坚持“5W”规则,明确内容与过程
    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。
    3.采用评审和更新机制,保证测试计划满足实际需求
    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。
    4. 分别创建测试计划与测试详细规格、测试用例
    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。
    08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
    1.等价类划分
    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
    2.边界值分析法
      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
    3.错误推测法
      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
    4.因果图方法
      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 
    08.您认为做好测试用例设计工作的关键是什么?
    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果
    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题
    09. 请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。
    就说最近的这次网站功能的测试吧
    首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。
    第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。
    第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat,所以只要有tomcat即可
    第四步:执行测试
    11. 您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。
    是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。
    性能测试类型包括负载测试,强度测试,容量测试等
          负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。
          强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。
          容量测试:确定系统可处理同时在线的最大用户数  
    在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),
    Web服务器指标指标:
    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数;
    * Successful Rounds:成功的请求;
    * Failed Rounds :失败的请求;
    * Successful Hits :成功的点击次数;
    * Failed Hits :失败的点击次数;
    * Hits Per Second :每秒点击次数;
    * Successful Hits Per Second :每秒成功的点击次数;
    * Failed Hits Per Second :每秒失败的点击次数;
    * Attempted Connections :尝试链接数;

    13. 您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。
    17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?
    18. 在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?
    20. 您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。
    23. 您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?
    27. 在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?
    31. 在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)
    33.     你对测试最大的兴趣在哪里?为什么?
    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。
    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。
    不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。
    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。
    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。
    34. 你的测试职业发展是什么?
    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。
    35. 你自认为测试的优势在哪里?
    优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。
    36. 你以前工作时的测试流程是什么?
    公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。
    37. 当开发人员说不38. 是BUG时,39. 你如何应付?
    开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。
    23.你为什么想离开目前的职务?
    因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。
      24:你对我们公司了解有多少?

      25:你找工作时,最重要的考虑因素为何?
    工作的性质和内容是否能让我发挥所长,并不断成长。
    26:为什么我们应该录取你?
    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。
      27:请谈谈你个人的最大特色。
    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。
    28.白箱测试和黑箱测试是什么?什么是回归测试?
        29。单元测试、集成测试、系统测试的侧重点是什么?
        30。设计用例的方法、依据有那些?
        31。一个测试工程师应具备那些素质和技能?
        32.集成测试通常都有那些策略?
        33.你用过的测试工具的主要功能、性能及其他?
        34.一个缺陷测试报告的组成
        35.基于WEB信息管理系统测试时应考虑的因素有哪些?
    36.软件测试项目从什么时候开始,?为什么?
         37.需求测试注意事项有哪些?
         38.简述一下缺陷的生命周期
         39.测试分析测试用例注意(事项)?
    你在你所在的公司是怎么开展测试工作的?是如何组织的?
    你认为理想的测试流程是什么样子?
    你是怎样工作的?
    软件测试活动的生命周期是什么?
    请画出软件测试活动的流程图?
    针对缺陷采取怎样管理措施?
    什么是测试评估?测试评估的范围是什么?
    如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?
    测试结束的标准是什么?
    软件验收测试除了alpha,beta测试以外,还有哪一种?
    做测试多久了?
    以前做过哪些项目?
    你们以前测试的流程是怎样的?
    <答:测试计划-测试用例设计-测试执行-测试分析报告>
    用过哪些测试工具?
    为什么选择测试这行?
    <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>
    为什么值得他们公司雇用?
    如果我雇用你,你能给部门带来什么贡献?
    如何从工作中看出你是个自动自觉的人
    你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
    通常你对于别人批评你会有什么样的反应
    如果明知这样做不对,你还会依主管的指过去做吗
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
    你觉得什么样的人最难相处
    为什么值得他们公司雇用?
          帮助公司提高软件质量和测试部门的技术水平
    如果我雇用你,你能给部门带来什么贡献?
          分享我的测试经验和测试技能,提高测试部门技术水平
    如何从工作中看出你是个自动自觉的人
         自动自觉范围太广
          1. 工作成果
          2. 工作质量  
    你的工作通常能在时限内完成吗.(我想问一下就是她问这个问题的动机是什么)
          在有足够的资源和合理的工作量的情况下,完全可以按时完成,并能比一般人做的更好
    通常你对于别人批评你会有什么样的反应
      有错即改,无措勉之
    如果明知这样做不对,你还会依主管的指过去做吗
         在公司内部下级是否有申诉渠道?
    如果你接到一个客户抱怨的电话,你确知无法解决他的问题,你会怎么处理
        为什么抱怨?是怎么样的问题?
         如果是客服问题,提交客服部门解决
        如果是质量问题,分析原因,下一版本改进
    你觉得什么样的人最难相处
         自以为是的人
    什么叫单元测试?
    请就软件测试人员应该具备什么样的基本素质说说你的看法。
    请就如何在开发中进行软件质量控制说说你的看法
     简述软件测试的意义,以及软件测试的分类

    1、功能测试,性能测试,界面测试,安全测试(可以简单点,比如只涉及到COOKIES里的内容),压力测试(商业性质的网站) 等等,B/S软件也要根据其具体功能采用不同的测试策略。
    2、态度、责任心、自信、敏锐的观察力、良好的发散思维
    3、先设计后开发模式,加强单元测试,加强代码走查,有一套完整的白盒测试方法。关键是加强开发人员的质量意识,增进程序员向工程师水平发展。
    4、意义嘛,就自己想吧。软件测试的分类,这个很多人都按各种方法去分。无明确答案给你。

    对测试的理解——基本的测试知识,对测试是否认可? 75。
       3、谈一谈过去自己的工作——了解经历、提供进一步提问的素材,表达能力  
    测试技能
    测试设计的方法并举例说明——测试技术的使用
    测试工具——熟悉程度,能否与当前工作匹配?
    如何做计划?如何跟踪计划?——日常工作能力
    如果开发人员提供的版本不满足测试的条件,如何做?——与开发人员协作的能力
    熟悉unix系统、oracle数据库吗?——是否具备系统知识
    做过开发吗?写过哪些代码?——开发技能
    阅读英语文章,给出理解说明?——部分英语能力
    文档的意义——是否善于思考?(最简单的概念,不同层次的理解)
    假如进入我们公司,对我们哪些方面会有帮助?——讲讲自己的特长
    随便找一件物品,让其测试——测试的实际操作能力
    软件测试的方法有?
    软件测试的过程?
    有一个新的软件,假如你是测试工程师,该如何做?
    软件测试分哪两种方法?分别适合什么情况?
    2。一套完整的测试应该由哪些阶段组成?分别阐述一下各个阶段。
    3。软件测试的类型有那些?分别比较这些不同的测试类型的区别与联系。
    4。测试用例通常包括那些内容?着重阐述编制测试用例的具体做法
    5。在分别测试winform的C/S结构与测试WEB结构的软件是,应该采取什么样的方法分别测试?他们存在什么样的区别与联系?
    6。在测试winform的C/S结构软件时,发现这个软件的运行速度很慢,您会认为是什么原因?您会采取哪些方法去检查这个原因?
    7。描述使用bugzilla缺陷管理工具对软件缺陷(BUG)跟踪的管理的流程
    你在五年内的个人目标和职业目标分别是什么?
      分析这个问题是用来了解你的计划能力的,通过这个问题,面试人同时还可以知道你的目标是否符合企业对你的安排。
      错误回答我想在将来的某个时候考虑这个问题。如今企业的领导者更换频繁,我认为做太多的个人计划是荒谬可笑的,不是吗?
      评论这种回答属于令人反感的一类。首先,当有人想了解你的目标时,"将来的某个时候"这种通俗说法并不奏效。其次,认为企业很脆弱,领导者更换频繁,这种说法毫无疑问会令人反感,而且也是不合理的。最后,认为做计划可笑,看不起这个问题,而且反问面试人,这些都注定了这样的求职者最终会失败。
      正确回答从现在起的五年之内,我希望能够在一个很好的职位上待几年,而且最好有一次晋升,然后就期待着下一步。不管是向上提升,还是在企业内横向调动,对我个人来说,我希望找到一家企业——一家愿意做相互投入的企业——待上一段时间。
      评论这个问题没有回答得过分具体(那样可能会产生漏洞),而且它表明你有雄心,并且思考过在企业中的成长方式。通过表达横向调动和向上提升的愿望,表明你是一个有灵活性的人。
     问题23 你怎样做出自己的职业选择?
      分析 面试人提出这个问题是为了了解求职者的动机,看看他(她)应聘这份工作是否有什么历史渊源,是否有职业规划,是不是仅仅在漫无目的地申请很多工作。
      错误回答 我一直都想在企业界工作。自孩提时代起,我就梦想自己至少也要成为大企业的副总裁。
      评论 除了难以令人相信之外,这种回答还存在一个问题:它表明求职者会对副总裁以下的职位不感兴趣。
      正确回答 在上大学四年级前的那个夏天,我决定集中精力在某一领域谋求发展。尽管我是学商业的,但是我不知道自己最终会从事哪一行业的工作。我花了一定的时间考虑自己的目标,想清楚了自己擅长做的事情以及想从工作中得到的东西,最后我得出了一个坚定的结论,那就是这个行业是最适合我的。
      评论 这种回答表明,求职者认真地做过一些计划,缩小了自己的关注点,而且也认准了前进的方向。这种回答还表明,求职者理解个人职业规划的重要性,并且有能力做出认真的个人决策。
    1. 你都用什么测试方法
    2.怎么编写案例
    3.怎么才能够全面的测试到每一个点
    1. 你都用什么测试方法
    针对不同的产品或者系统或者模块,有不同的测试方法。总体而言有白盒测试和黑盒测试。
    2.怎么编写案例
    案例的编写与测试阶段的定义有很大的关系。系统测试和unit测试的案例可能不同。总体而言测试案例根据系统的需求而定。
    3.怎么才能够全面的测试到每一个点
    测试的全面性主要需要在设计测试计划的时候考虑,从测试策略,产品需求等等多个角度考虑从而定义全部的测试点。
    1、谈谈软件测试技术,以及如何提高
    2、谈谈软件测试职业发展,以及个人的打算
    3、谈谈软件测试在企业的地位,也可以结合软件生命周期来谈
    有可能清晰的思路比确切的答案更重要
    在这里,主要说下笔试和面试的问题,希望大家共同参考。
        1,一般公司里实际的软件测试流程是什么样的?你们公司又是怎样的?
        2,软件工程师要具有那些素质?
        3,你会哪些测试工具?怎么操作?
        4,你能不能说下你的3到5年的职业计划(规划)
        5,你觉得你来应聘有那些优势?
    其余的还好说,但就第4个问题,我感到不好说哦!希望大家给个意见
    第一关:首先要自我介绍,自己的性格怎么样,目前的工作经历积累了一些什么经验取得了些什么值得一说的成果。然后要说说对软件测试怎么看?还有对于软件测试有什么自己的想法。为什么会想到要做这行(因为我的简历上的工作经历没有关于测试方面的)。哦,还有期望薪资。
    第二关:认为软件测试人员所要具备的基本素质,如果遇到问题会怎样处理,如果得不到研发人员的配合(就是研发说这个不是问题)你又会怎么处理?然后就是一些基本概念,比如软件测试的流程有哪些?如果我上任了,首先会怎么开始自己的工作计划。
    (前两关通过了后面这个就好过多了)
    第三关:像我介绍了一下公司的情况,告诉我主要针对什么内容的测试,会不会使用数据库。告诉我大概要做哪些内容,详细的可以上岗以后慢慢熟悉。
    大概就这么多了,这对没有经过这一关的不知道有没有帮助,仅供参考吧
    我觉得就像李波说的,关键是要给对方留下好印象:)

    面试官最后会问你有什么问题要问吗。作为应聘者的你一般不要说没问题问,这会给面试官留下你不太重视这份工作的坏印象。所以如果你想得到这份工作的话应该抓住这最后的表现自己的机会:
    你可以问:
    1.        贵公司近期和远期的发展目标是什么?
    2.        贵公司的主要竞争对手有哪些?
    3.        贵公司有多少开发人员有多少测试人员?
    4.        贵公司又进一步扩充测试人员的计划吗?
    5.        如果我有幸能进入贵公司的话,我有怎么样的发展?
    6.        测试人员的沟通能力很重要,贵公司有规范的沟通渠道吗?
    7.        请介绍一下贵公司的福利情况。
    8.        请问我什么时候能知道结果?


  • 软件测试类型知多少?

    sanwong823 发布于 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

  • [转] 软件测试常识

    sanwong823 发布于 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博客,转载请注明出处

  • 常见测试术语(合集 1-20)

    海之梦 发布于 2007-04-27 17:52:59

    Acceptance Testing--可接受性测试
    一般由用户/客户进行的确认是否可以接受一个产品的验证性测试。

    actual outcome--实际结果       
    被测对象在特定的条件下实际产生的结果。

    Ad Hoc Testing--随机测试       
    测试人员通过随机的尝试系统的功能,试图使系统中断。

    algorithm--算法       
    (1)一个定义好的有限规则集,用于在有限步骤内解决一个问题;(2)执行一个特定任务的任何操作序列。

    algorithm analysis--算法分析       
    一个软件的验证确认任务,用于保证选择的算法是正确的、合适的和稳定的,并且满足所有精确性、规模和时间方面的要求。

    Alpha Testing--Alpha测试       
    由选定的用户进行的产品早期性测试。这个测试一般在可控制的环境下进行的。

    analysis--分析       
    (1)分解到一些原子部分或基本原则,以便确定整体的特性;(2)一个推理的过程,显示一个特定的结果是假设前提的结果;(3)一个问题的方法研究,并且问题被分解为一些小的相关单元作进一步详细研究。

    anomaly--异常       
    在文档或软件操作中观察到的任何与期望违背的结果。

    application software--应用软件       
    满足特定需要的软件。

    architecture--构架       
    一个系统或组件的组织结构。

    ASQ--自动化软件质量(Automated Software Quality)
    使用软件工具来提高软件的质量。

    assertion--断言       
    指定一个程序必须已经存在的状态的一个逻辑表达式,或者一组程序变量在程序执行期间的某个点上必须满足的条件。

    assertion checking--断言检查       
    用户在程序中嵌入的断言的检查。

    audit--审计       
    一个或一组工作产品的独立检查以评价与规格、标准、契约或其它准则的符合程度。

    audit trail--审计跟踪       
    系统审计活动的一个时间记录。

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

    Backus-Naur Form--BNF范式       
    一种分析语言,用于形式化描述语言的语法

    baseline--基线       
    一个已经被正式评审和批准的规格或产品,它作为进一步开发的一个基础,并且必须通过正式的变更流程来变更。

    Basic Block--基本块       
    一个或多个顺序的可执行语句块,不包含任何分支语句。

    basis test set--基本测试集       
    根据代码逻辑引出来的一个测试用例集合,它保证能获得100%的分支覆盖。

    behaviour--行为       
    对于一个系统的一个函数的输入和预置条件组合以及需要的反应。一个函数的所有规格包含一个或多个行为。

    benchmark--标杆/指标/基准       
    一个标准,根据该标准可以进行度量或比较。

    Beta Testing--Beta测试       
    在客户场地,由客户进行的对产品预发布版本的测试。这个测试一般是不可控的。

    big-bang testing--大锤测试/一次性集成测试       
    非渐增式集成测试的一种策略,测试的时候把所有系统的组件一次性组合成系统进行测试。

    Black Box Testing--黑盒测试       
    根据软件的规格对软件进行的测试,这类测试不考虑软件内部的运作原理,因此软件对用户来说就像一个黑盒子。

    bottom-up testing--由低向上测试       
    渐增式集成测试的一种,其策略是先测试底层的组件,然后逐步加入较高层次的组件进行测试,直到系统所有组件都加入到系统。

    boundary value--边界值       
    一个输入或输出值,它处在等价类的边界上。

    boundary value coverage--边界值覆盖       
    通过测试用例,测试组件等价类的所有边界值。

    boundary value testing--边界值测试       
    通过边界值分析方法来生成测试用例的一种测试策略。

    Boundry Value Analysis--边界值分析       
    该分析一般与等价类一起使用。经验认为软件的错误经常在输入的边界上产生,因此边界值分析就是分析软件输入边界的一种方法。

    branch--分支       
    在组件中,控制从任何语句到其它任何非直接后续语句的一个条件转换,或者是一个无条件转换。

    branch condition--分支条件       

    branch condition combination coverage--分支条件组合覆盖       
    在每个判定中所有分支条件结果组合被测试用例覆盖到的百分比。

    branch condition combination testing--分支条件组合测试       
    通过执行分支条件结果组合来设计测试用例的一种方法。

    branch condition coverage--分支条件覆盖       
    每个判定中分支条件结果被测试用例覆盖到的百分比。

    branch condition testing--分支条件测试
    通过执行分支条件结果来设计测试用例的一种方法。

    branch coverage--分支覆盖       
    通过测试执行到的分支的百分比。

    branch outcome--分支结果       
    见判定结果(decision outcome)

    branch point--分支点       
    见判定(decision)

    branch testing--分支测试       
    通过执行分支结果来设计测试用例的一种方法。

    Breadth Testing--广度测试       
    在测试中测试一个产品的所有功能,但是不测试更细节的特性。

    bug--缺陷

    第121贴【2004-10-14】:常见测试术语三

    capture/playback tool--捕获/回放工具       
    参考capture/replay tool

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

    CASE--计算机辅助软件工程(computer aided software engineering)
    用于支持软件开发的一个自动化系统。

    CAST--计算机辅助测试       
    在测试过程中使用计算机软件工具进行辅助的测试。

    cause-effect graph--因果图       
    一个图形,用来表示输入(原因)与结果之间的关系,可以被用来设计测试用例。

    certification        --证明       
    一个过程,用于确定一个系统或组件与特定的需求相一致。

    change control--变更控制       
    一个用于计算机系统或系统数据修改的过程,该过程是质量保证程序的一个关键子集,需要被明确的描述。

    code audit        --代码审计       
    由一个人、组或工具对源代码进行的一个独立的评审,以验证其与设计规格、程序标准的一致性。正确性和有效性也会被评价。

    Code Coverage--代码覆盖率       
    一种分析方法,用于确定在一个测试套执行后,软件的哪些部分被执行到了,哪些部分没有被执行到。

    Code Inspection--代码检视       
    一个正式的同行评审手段,在该评审中,作者的同行根据检查表对程序的逻辑进行提问,并检查其与编码规范的一致性。

    Code Walkthrough--代码走读       
    一个非正式的同行评审手段,在该评审中,代码被使用一些简单的测试用例进行人工执行,程序变量的状态被手工分析,以分析程序的逻辑和假设。

    code-based testing--基于代码的测试       
    根据从实现中引出的目标设计测试用例。

    coding standards--编程规范       
    一些编程方面需要遵循的标准,包括命名方式、排版格式等内容。

    Compatibility Testing--兼容性测试       
    测试软件是否和系统的其它与之交互的元素之间兼容,如:浏览器、操作系统、硬件等。

    complete path testing        --完全路径测试       
    参考穷尽测试(exhaustive testing)

    completeness--完整性       
    实体的所有必须部分必须被包含的属性。

    complexity        --复杂性       
    系统或组件难于理解或验证的程度。

    Component--组件       
    一个最小的软件单元,有着独立的规格

    Component Testing--组件测试       
    参考单元测试

    computation data use--计算数据使用       
    一个不在条件中的数据使用。

    computer system security--计算机系统安全性       
    计算机软件和硬件对偶然的或故意的访问、使用、修改或破坏的一种保护机制。

    condition--条件       
    一个不包含布尔操作的布尔表达式,例如:A
    condition coverage--条件覆盖       
    通过测试执行到的条件的百分比。

    condition outcome--条件结果       
    条件为真为假的评价。

    configuration control--配置控制       
    配置管理的一个方面,包括评价、协调、批准、和实现配置项的变更。

    configuration management--配置管理       
    一套技术和管理方面的原则用于确定和文档化一个配置项的功能和物理属性、控制对这些属性的变更、记录和报告变更处理和实现的状态、以及验证与指定需求的一致性。

    conformance criterion-- 一致性标准       
    判断组件在一个特定输入值上的行为是否符合规格的一种方法。

    Conformance Testing-- 一致性测试       
    测试一个系统的实现是否和其基于的规格相一致的测试。

    consistency        -- 一致性       
    在系统或组件的各组成部分和文档之间没有矛盾,一致的程度。

    consistency checker-- 一致性检查器       
    一个软件工具,用于测试设计规格中需求的一致性和完整性。

    control flow--控制流       
    程序执行中所有可能的事件顺序的一个抽象表示。

    control flow graph--控制流图       
    通过一个组件的可能替换控制流路径的一个图形表示。

    conversion testing--转换测试       
    用于测试已有系统的数据是否能够转换到替代系统上的一种测试。

    corrective maintenance--故障检修       
    用于纠正硬件或软件中故障的维护。

    correctness        --正确性       
    软件遵从其规格的程度。

    correctness        --正确性       
    软件在其规格、设计和编码中没有故障的程度。软件、文档和其它项满足需求的程度。软件、文档和其它项满足用户明显的和隐含的需求的程度。

    coverage        --覆盖率       
    用于确定测试所执行到的覆盖项的百分比。

    coverage item--覆盖项       
    作为测试基础的一个入口或属性:如语句、分支、条件等。

    crash--崩溃       
    计算机系统或组件突然并完全的丧失功能。

    criticality--关键性       
    需求、模块、错误、故障、失效或其它项对一个系统的操作或开发影响的程度。

    criticality analysis--关键性分析       
    需求的一种分析,它根据需求的风险情况给每个需求项分配一个关键级别。

    cyclomatic complexity--循环复杂度       
    一个程序中独立路径的数量。
    data corruption--数据污染       
    违背数据一致性的情况。

    data definition--数据定义       
    一个可执行语句,在该语句上一个变量被赋予了一个值。

    data definition C-use coverage--数据定义C-use覆盖       
    在组件中被测试执行到的数据定义C-use使用对的百分比。

    data definition C-use pair--数据定义C-use使用对       
    一个数据定义和一个计算数据使用,数据使用的值是数据定义的值。

    data definition P-use coverage--数据定义P-use覆盖       
    在组件中被测试执行到的数据定义P-use使用对的百分比。

    data definition P-use pair--数据定义P-use使用对       
    一个数据定义和一个条件数据使用,数据使用的值是数据定义的值。

    data definition-use coverage--数据定义使用覆盖       
    在组件中被测试执行到的数据定义使用对的百分比。

    data definition-use pair        --数据定义使用对       
    一个数据定义和一个数据使用,数据使用的值是数据定义的值。

    data definition-use testing--数据定义使用测试       
    以执行数据定义使用对为目标进行测试用例设计的一种技术。

    data dictionary--数据字典       
    (1)一个软件系统中使用的所有数据项名称,以及这些项相关属性的集合。(2)数据流、数据元素、文件、数据基础、和相关处理的一个集合。

    data flow analysis--数据流分析       
    一个软件验证和确认过程,用于保证输入和输出数据和它们的格式是被适当定义的,并且数据流是正确的。

    data flow coverage--数据流覆盖       
    测试覆盖率的度量是根据变量在代码中的使用情况。

    data flow diagram--数据流图       
    把数据源、数据接受、数据存储和数据处理作为节点描述的一个图形,数据之间的逻辑体现为节点之间的边。

    data flow testing--数据流测试       
    根据代码中变量的使用情况进行的测试。

    data integrity--数据完整性       
    一个数据集合完全、正确和一致的程度。

    data use--数据使用       
    一个可执行的语句,在该语句中,变量的值被访问。

    data validation--数据确认       
    用于确认数据不正确、不完整和不合理的过程。

    dead code--死代码       
    在程序操作过程中永远不可能被执行到的代码。

    Debugging--调试       
    发现和去除软件失效根源的过程。

    decision--判定       
    一个程序控制点,在该控制点上,控制流有两个或多个可替换路由。

    Decision condition--判定条件       
    判定内的一个条件。

    decision coverage--判定覆盖       
    在组件中被测试执行到的判定结果的百分比。

    decision outcome--判定结果       
    一个判定的结果,决定控制流走哪条路径。

    decision table--判定表       
    一个表格,用于显示条件和条件导致动作的集合。

    Depth Testing--深度测试       
    执行一个产品的一个特性的所有细节,但不测试所有特性。比较广度测试。

    design of experiments--实验设计       
    一种计划实验的方法,这样适合分析的数据可以被收集。

    design-based testing--基于设计的测试       
    根据软件的构架或详细设计引出测试用例的一种方法。

    desk checking--桌面检查       
    通过手工模拟软件执行的方式进行测试的一种方式。

    diagnostic--诊断       
    检测和隔离故障或失效的过程。

    dirty testing--肮脏测试       
    参考负面测试(negative testing)

    disaster recovery--灾难恢复       
    一个灾难的恢复和重建过程或能力。

    documentation testing        --文档测试       
    测试关注于文档的正确性。

    domain--域       
    值被选择的一个集合。

    domain testing--域测试       
    参考等价划分测试(equivalence partition testing)

    dynamic analysis--动态分析       
    根据执行的行为评价一个系统或组件的过程。

    Dynamic Testing--动态测试       
    通过执行软件的手段来测试软件。
    embedded software--嵌入式软件       
    软件运行在特定硬件设备中,不能独立于硬件存在。这类系统一般要求实时性较高。

    emulator--仿真       
    一个模仿另一个系统的系统或设备,它接受相同的输入并产生相同的输出。

    End-to-End testing--端到端测试       
    在一个模拟现实使用的场景下测试一个完整的应用环境,例如和数据库交互,使用网络通信等。

    entity relationship diagram--实体关系图       
    描述现实世界中实体及它们关系的图形。

    entry point        --入口点       
    一个组件的第一个可执行语句。

    Equivalence Class--等价类       
    组件输入或输出域的一个部分,在该部分中,组件的行为从组件的规格上来看认为是相同的。

    equivalence partition coverage--等价划分覆盖       
    在组件中被测试执行到的等价类的百分比。

    equivalence partition testing--等价划分测试       
    根据等价类设计测试用例的一种技术。

    Equivalence Partitioning--等价划分       
    组件的一个测试用例设计技术,该技术从组件的等价类中选取典型的点进行测试。

    error--错误       
    IEEE的定义是:一个人为产生不正确结果的行为。

    error guessing--错误猜测       
    根据测试人员以往的经验猜测可能出现问题的地方来进行用例设计的一种技术。

    error seeding--错误播种/错误插值       
    故意插入一些已知故障(fault)到一个系统中去的过程,目的是为了根据错误检测和跟踪的效率并估计系统中遗留缺陷的数量。

    exception--异常/例外       
    一个引起正常程序执行挂起的事件。

    executable statement--可执行语句       
    一个语句在被编译后会转换成目标代码,当程序运行是会被执行,并且可能对程序数据产生动作。

    Exhaustive Testing--穷尽测试       
    测试覆盖软件的所有输入和条件组合。

    exit point--出口点       
    一个组件的最后一个可执行语句。

    expected outcome--期望结果       
    参考预期结果(predicted outcome)。
    failure--失效       
    软件的行为与其期望的服务相背离。

    fault--故障       
    在软件中一个错误的表现。

    feasible path--可达路径       
    可以通过一组输入值和条件执行到的一条路径。

    feature testing--特性测试       
    参考功能测试(Functional Testing)

    FMEA--失效模型效果分析(Failure Modes and Effects Analysis)
    可靠性分析中的一种方法,用于在基本组件级别上确认对系统性能有重大影响的失效。

    FMECA--失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)
    FMEA的一个扩展,它分析了失效结果的严重性。

    FTA--故障树分析(Fault Tree Analysis)
    引起一个不需要事件产生的条件和因素的确认和分析,通常是严重影响系统性能、经济性、安全性或其它需要特性。

    functional decomposition--功能分解       
    参考模块分解(modular decomposition)

    Functional Specification        --功能规格说明书       
    一个详细描述产品特性的文档。

    Functional Testing--功能测试       
    测试一个产品的特性和可操作行为以确定它们满足规格。
    glass box testing--玻璃盒测试       
    参考白盒测试(White Box Testing)

    IEEE--美国电子与电器工程师学会(Institute of Electrical and Electronic Engineers)

    incremental testing--渐增测试       
    集成测试的一种,组件逐渐被增加到系统中直到整个系统被集成。

    infeasible path--不可达路径       
    不能够通过任何可能的输入值集合执行到的路径。

    input domain--输入域       
    所有可能输入的集合。

    inspection--检视       
    对文档进行的一种评审形式。

    installability testing--可安装性测试       
    确定系统的安装程序是否正确的测试。

    instrumentation--插装       
    在程序中插入额外的代码以获得程序在执行时行为的信息。

    instrumenter--插装器       
    执行插装的工具

    Integration Testing--集成测试       
    测试一个应用组合后的部分以确保它们的功能在组合之后正确。该测试一般在单元测试之后进行。

    interface--接口       
    两个功能单元的共享边界。

    interface analysis--接口分析       
    分析软件与硬件、用户和其它软件之间接口的需求规格。

    interface testing--接口测试       
    测试系统组件间接口的一种测试。

    invalid inputs--无效输入       
    在程序功能输入域之外的测试数据。

    isolation testing--孤立测试       
    组件测试(单元测试)策略中的一种,把被测组件从其上下文组件之中孤立出来,通过设计驱动和桩进行测试的一种方法。

    Job--工作       
    一个用户定义的要计算机完成的工作单元。

    job control language--工作控制语言       
    用于确定工作顺序,描述它们对操作系统要求并控制它们执行的语言。

    LCSAJ--线性代码顺序和跳转(Linear Code Sequence And Jump)
    包含三个部分:可执行语句线性顺序的起始,线性顺序的结束,在线性顺序结束处控制流跳转的目标语句。

    LCSAJ coverage--LCSAJ覆盖       
    在组件中被测试执行到的LCSAJ的百分比。

    LCSAJ testing--LCSAJ测试       
    根据LCSAJ设计测试用例的一种技术。

    Load Testing--负载测试       
    通过测试系统在资源超负荷情况下的表现,以发现设计上的错误或验证系统的负载能力。

    logic analysis--逻辑分析       
    (1)评价软件设计的关键安全方程式、算法和控制逻辑的方法。(2)评价程序操作的顺序并且检测可能导致灾难的错误。

    logic-coverage testing--逻辑覆盖测试       
    参考结构化测试用例设计(structural test case design)

    maintainability--可维护性       
    一个软件系统或组件可以被修改的容易程度,这个修改一般是因为缺陷纠正、性能改进或特性增加引起的。

    maintainability testing--可维护性测试       
    测试系统是否满足可维护性目标。

    modified condition/decision coverage--修改条件/判定覆盖       
    在组件中被测试执行到的修改条件/判定的百分比。

    modified condition/decision testing        --修改条件/判定测试       
    根据MC/DC设计测试用例的一种技术。

    Monkey Testing--跳跃式测试       
    随机性,跳跃式的测试一个系统,以确定一个系统是否会崩溃。

    MTBF--平均失效间隔实际(mean time between failures)
    两次失效之间的平均操作时间。

    MTTF--平均失效时间        (mean time to failure)
    第一次失效之前的平均时间

    MTTR--平均修复时间(mean time to repair)
    两次修复之间的平均时间

    multiple condition coverage--多条件覆盖       
    参考分支条件组合覆盖(branch condition combination coverage)

    mutation analysis--变体分析       
    一种确定测试用例套完整性的方法,该方法通过判断测试用例套能够区别程序与其变体之间的程度。
    Negative Testing--逆向测试/反向测试/负面测试       
    测试瞄准于使系统不能工作。

    non-functional requirements testing--非功能性需求测试       
    与功能不相关的需求测试,如:性能测试、可用性测试等。

    N-switch coverage--N切换覆盖       
    在组件中被测试执行到的N转换顺序的百分比。

    N-switch testing--N切换测试       
    根据N转换顺序设计测试用例的一种技术,经常用于状态转换测试中。

    N-transitions--N转换       
    N+1转换顺序

    operational testing--可操作性测试       
    在系统或组件操作的环境中评价它们的表现。

    output domain--输出域       
    所有可能输出的集合。
    partition testing--分类测试       
    参考等价划分测试(equivalence partition testing)

    path--路径       
    一个组件从入口到出口的一条可执行语句顺序。

    path coverage--路径覆盖       
    在组件中被测试执行到的路径的百分比。

    path sensitizing--路径敏感性       
    选择一组输入值强制组件走一个给定的路径。

    path testing--路径测试       
    根据路径设计测试用例的一种技术,经常用于状态转换测试中。

    performance testing--性能测试       
    评价一个产品或组件与性能需求是否符合的测试。

    portability testing--可移植性       
    测试瞄准于证明软件可以被移植到指定的硬件或软件平台上。

    Positive Testing--正向测试       
    测试瞄准于显示系统能够正常工作。

    precondition--预置条件       
    环境或状态条件,组件执行之前必须被填充一个特定的输入值。

    predicate--谓词       
    一个逻辑表达式,结果为‘真’或‘假’。

    predicate data use--谓词数据使用       
    在谓词中的一个数据使用。

    program instrumenter--程序插装       
    参考插装(instrumenter)

    progressive testing--递进测试       
    在先前特性回归测试之后对新特性进行测试的一种策略。

    pseudo-random--伪随机       
    看似随机的,实际上是根据预先安排的顺序进行的。
    QA--质量保证(quality assurance)
    (1)已计划的系统性活动,用于保证一个组件、模块或系统遵从已确立的需求。(2)采取的所有活动以保证一个开发组织交付的产品满足性能需求和已确立的标准和过程。

    QC--质量控制(quality control)
    用于获得质量需求的操作技术和过程,如测试活动。

    Race Condition--竞争状态       
    并行问题的根源。对一个共享资源的多个访问,至少包含了一个写操作,但是没有一个机制来协调同时发生的访问。

    recovery testing--恢复性测试       
    验证系统从失效中恢复能力的测试。

    regression analysis and testing--回归分析和测试       
    一个软件验证和确认任务以确定在修改后需要重复测试和分析的范围。

    Regression Testing--回归测试       
    在发生修改之后重新测试先前的测试以保证修改的正确性。

    release--发布       
    一个批准版本的正式通知和分发。

    reliability--可靠性       
    一个系统或组件在规定的条件下在指定的时间内执行其需要功能的能力。

    reliability assessment--可靠性评价       
    确定一个已有系统或组件的可靠性级别的过程。

    requirements-based testing--基于需求的测试       
    根据软件组件的需求导出测试用例的一种设计方法。

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

    risk--风险       
    不期望效果的可能性和严重性的一个度量。

    risk assessment--风险评估       
    对风险和风险影响的一个完整的评价。
    safety--(生命)安全性       
    不会引起人员伤亡、产生疾病、毁坏或损失设备和财产、或者破坏环境。

    safety critical--严格的安全性       
    一个条件、事件、操作、过程或项,它的认识、控制或执行对生命安全性的系统来说是非常关键的。

    Sanity Testing--理智测试       
    软件主要功能成分的简单测试以保证它是否能进行基本的测试。参考冒烟测试

    SDP--软件开发计划(software development plan)
    用于一个软件产品开发的项目计划。

    security testing--安全性测试       
    验证系统是否符合安全性目标的一种测试。

    security.--(信息)安全性       
    参考计算机系统安全性(computer system security)

    serviceability testing--可服务性测试       
    参考可维护性测试(maintainability testing)

    simple subpath--简单子路径       
    控制流的一个子路径,其中没有不必要的部分被执行。

    simulation--模拟       
    使用另一个系统来表示一个物理的或抽象的系统的选定行为特性。

    simulation--模拟       
    使用一个可执行模型来表示一个对象的行为。

    simulator--模拟器       
    软件验证期间的一个设备、软件程序、或系统,当它给定一个控制的输入时,表现的与一个给定的系统类似。

    SLA--服务级别协议(service level agreement)
    服务提供商与客户之间的一个协议,用于规定服务提供商应当提供什么服务。

    Smoke Testing--冒烟测试       
    对软件主要功能进行快餐式测试。最早来自于硬件测试实践,以确定新的硬件在第一次使用的时候不会着火。

    software development process--软件开发过程       
    一个把用户需求转换为软件产品的开发过程。

    software diversity--软件多样性       
    一种软件开发技术,其中,由不同的程序员或开发组开发的相同规格的不同程序,目的是为了检测错误、增加可靠性。

    software element--软件元素       
    软件开发或维护期间产生或获得的一个可交付的或过程内的文档。

    software engineering--软件工程       
    一个应用于软件开发、操作和维护的系统性的、有纪律的、可量化的方法。

    software engineering environment--软件工程环境       
    执行一个软件工程工作的硬件、软件和固件。

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

    SOP--标准操作过程(standard operating procedures)
    书面的步骤,这对保证生产和处理的控制是必须的。

    source code--源代码       
    用一种适合于输入到汇编器、编译器或其它转换设备的计算机指令和数据定义。

    source statement--源语句       
    参考语句(statement)
    specification--规格       
    组件功能的一个描述,格式是:对指定的输入在指定的条件下的输出。

    specified input--指定的输入       
    一个输入,根据规格能预知其输出。

    spiral model        --螺旋模型       
    软件开发过程的一个模型,其中的组成活动,典型的包括需求分析,概要设计,详细设计,编码,集成和测试等活动被迭代的执行直到软件被完成。

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

    state--状态       
    一个系统、组件或模拟可能存在其中的一个条件或模式。

    state diagram--状态图       
    一个图形,描绘一个系统或组件可能假设的状态,并且显示引起或导致一个状态切换到另一个状态的事件或环境。

    state transition--状态转换       
    一个系统或组件的两个允许状态之间的切换。

    state transition testing        --状态转换测试       
    根据状态转换来设计测试用例的一种方法。

    statement--语句       
    程序语言的一个实体,是典型的最小可执行单元。

    statement coverage--语句覆盖       
    在一个组件中,通过执行一定的测试用例所能达到的语句覆盖百分比。

    statement testing--语句测试       
    根据语句覆盖来设计测试用例的一种方法。

    Static Analysis--静态分析       
    分析一个程序的执行,但是并不实际执行这个程序。

    Static Analyzer--静态分析器       
    进行静态分析的工具。

    Static Testing--静态测试       
    不通过执行来测试一个系统。

    statistical testing--统计测试       
    通过使用对输入统计分布进行分析来构造测试用例的一种测试设计方法。

    stepwise refinement--逐步优化       
    一个结构化软件设计技术,数据和处理步骤首先被广泛的定义,然后被逐步的进行了细化。

    storage testing--存储测试       
    验证系统是否满足指定存储目标的测试。

    Stress Testing--压力测试       
    在规定的规格条件或者超过规定的规格条件下,测试一个系统,以评价其行为。类似负载测试,通常是性能测试的一部分。

    structural coverage--结构化覆盖       
    根据组件内部的结构度量覆盖率。

    structural test case design--结构化测试用例设计       
    根据组件内部结构的分析来设计测试用例的一种方法。

    structural testing--结构化测试       
    参考结构化测试用例设计(structural test case design)

    structured basis testing--结构化的基础测试       
    根据代码逻辑设计测试用例来获得100%分支覆盖的一种测试用例设计技术。

    structured design--结构化设计       
    软件设计的任何遵循一定纪律的方法,它按照特定的规则,例如:模块化,有顶向下设计,数据逐步优化,系统结构和处理步骤。

    structured programming--结构化编程       
    在结构化程序开发中的任何包含结构化设计和结果的软件开发技术。

    structured walkthrough--结构化走读       
    参考走读(walkthrough)

    stub--桩       
    一个软件模块的框架或特殊目标实现,主要用于开发和测试一个组件,该组件调用或依赖这个模块。

    symbolic evaluation--符号评价       
    参考符号执行(symbolic execution)

    symbolic execution--符号执行       
    通过符号表达式来执行程序路径的一种静态分析设计技术。其中,程序的执行被用符号来模拟,例如,使用变量名而不是实际值,程序的输出被表示成包含这些符号的逻辑或数学表达式。

    symbolic trace--符号轨迹       
    一个计算机程序通过符号执行是经过的语句分支结果的一个记录。

    syntax testing--语法分析       
    根据输入语法来验证一个系统或组件的测试用例设计技术。

    system analysis--系统分析       
    对一个计划的或现实的系统进行的一个系统性调查以确定系统的功能以及系统与其它系统之间的交互。

    system design--系统设计       
    一个定义硬件和软件构架、组件、模块、接口和数据的过程以满足指定的规格。

    system integration--系统集成       
    一个系统组件的渐增的连接和测试,直到一个完整的系统。

    System Testing--系统测试       
    从一个系统的整体而不是个体上来测试一个系统,并且该测试关注的是规格,而不是系统内部的逻辑。

    technical requirements testing--技术需求测试       
    参考非功能需求测试(non-functional requirements testing)

    test automation--测试自动化       
    使用工具来控制测试的执行、结果的比较、测试预置条件的设置、和其它测试控制和报告功能。

    test case--测试用例       
    用于特定目标而开发的一组输入、预置条件和预期结果。

    test case design technique--测试用例设计技术       
    选择和导出测试用例的技术。

    test case suite--测试用例套       
    对被测软件的一个或多个测试用例的集合。

    test comparator--测试比较器       
    一个测试工具用于比较软件实际测试产生的结果与测试用例预期的结果。

    test completion criterion--测试完成标准       
    一个标准用于确定被计划的测试何时完成。

    test coverage--测试覆盖       
    参考覆盖率(Coverage)

    test driver--测试驱动       
    一个程序或测试工具用于根据测试套执行软件。

    test environment--测试环境       
    测试运行其上的软件和硬件环境的描述,以及任何其它与被测软件交互的软件,包括驱动和桩。


    test execution--测试执行       
    一个测试用例被被测软件执行,并得到一个结果。

    test execution technique--测试执行技术       
    执行测试用例的技术,包括手工、自动化等。

    test generator--测试生成器       
    根据特定的测试用例产生测试用例的工具。

    test harness--测试用具       
    包含测试驱动和测试比较器的测试工具。

    test log--测试日志       
    一个关于测试执行所有相关细节的时间记录。

    test measurement technique--测试度量技术       
    度量测试覆盖率的技术。

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

    test procedure--测试规程       
    一个文档,提供详细的测试用例执行指令。

    test records--测试记录       
    对每个测试,明确的记录被测组件的标识、版本,测试规格,和实际结果

    test report--测试报告       
    一个描述系统或组件执行的测试和结果的文档。

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

    Test Specification--测试规格       
    一个文档,用于指定一个软件特性、特性组合或所有特性的测试方法、输入、预期结果和执行条件。

    test strategy--测试策略       
    一个简单的高层文档,用于描述测试的大致方法,目标和方向。

    test suite--测试套       
    测试用例和/或测试脚本的一个集合,与一个应用的特定功能或特性相关。

    test target--测试目标       
    一组测试完成标准。

    testability--可测试性       
    一个系统或组件有利于测试标准建立和确定这些标准是否被满足的测试执行的程度。

    Testing--测试       
    IEEE给出的定义是:1)一个执行软件的过程,以验证其满足指定的需求并检测错误。2)一个软件项的分析过程以检测已有条件之间的不同,并评价软件项的特性。

    thread testing--线程测试       
    自顶向下测试的一个变化版本,其中,递增的组件集成遵循需求子集的实现。

    time sharing--时间共享       
    一种操作方式,允许两个或多个用户在相同的计算机系统上同时执行计算机程序。其实现可能通过时间片轮转、优先级中断等。

    top-down design--由顶向下设计       
    一种设计策略,首先设计最高层的抽象和处理,然后逐步向更低级别进行设计。

    top-down testing--自顶向下测试       
    集成测试的一种策略,首先测试最顶层的组件,其它组件使用桩,然后逐步加入较低层的组件进行测试,直到所有组件被集成到系统中。

    traceability--可跟踪性       
    开发过程的两个或多个产品之间关系可以被建立起来的程度,尤其是产品彼此之间有一个前后处理关系。

    traceability analysis--跟踪性分析       
    (1)跟踪概念文档中的软件需求到系统需求;(2)跟踪软件设计描述到软件需求规格,以及软件需求规格到软件设计描述;(3)跟踪源代码对应到设计规格,以及设计规格对应到源代码。分析确定它们之间正确性、一致性、完整性、精确性的关系。

    traceability matrix--跟踪矩阵       
    一个用于记录两个或多个产品之间关系的矩阵。例如,需求跟踪矩阵是跟踪从需求到设计再到编码的实现。

    transaction--事务/处理       
    (1)一个命令、消息或输入记录,它明确或隐含的调用了一个处理活动,例如更新一个文件。(2)用户和系统之间的一次交互。(3)在一个数据库管理系统中,完成一个特定目的的处理单元,如恢复、更新、修改或删除一个或多个数据元素。

    transform analysis--事务分析       
    系统的结构是根据分析系统需要处理的事务获得的一种分析技术。
    trojan horse--特洛伊木马       
    一种攻击计算机系统的方法,典型的方法是提供一个包含具有攻击性隐含代码的有用程序给用户,在用户执行该程序的时候,其隐含的代码对系统进行非法访问,并可能产生破坏。

    truth table--真值表       
    用于逻辑操作的一个操作表格。

    Unit Testing--单元测试       
    测试单个的软件组件,属于白盒测试范畴,其测试基础是软件内部的逻辑。

    Usability Testing--可用性测试       
    测试用户使用和学习产品的容易程度。

    validation--确认       
    根据用户需要确认软件开发的产品的正确性。

    verification--验证       
    评价一个组件或系统以确认给定开发阶段的产品是否满足该阶段开始时设定的标准。

    version--版本       
    一个软件项或软件元素的一个初始发布或一个完整的再发布。

    volume testing--容量测试       
    使用大容量数据测试系统的一种策略。

    Walkthrough--走读       
    一个针对需求、设计或代码的非正式的同行评审,一般由作者发起,由作者的同行参与进行的评审过程。

    waterfall model--瀑布模型       
    软件开发过程模型的一种,包括概念阶段、需求阶段、设计阶段、实现阶段、测试阶段、安装和检查阶段、操作和维护阶段,这些阶段按次序进行,可能有部分重叠,但很少会迭代。

    White Box Testing--白盒测试       
    根据软件内部的工作原理分析来进行测试。

数据统计

  • 访问量: 12248
  • 日志数: 8
  • 书签数: 13
  • 建立时间: 2007-04-28
  • 更新时间: 2008-03-12

RSS订阅

Open Toolbar