软件测试常用术语
测试专业术语
软件测试术语表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、性能等测试中用得较多。
测试术语及名词
测试任务描述在软件的开发过程中每个版本都会经历四次测试任务，分别为：单元测试、集成测试、系统测试、验收测试，在这四次测试任务中，每次测试都有不同的测试方向和重点。
一、单元测试单元测试是软件开发过程中要进行的最基本的测试，属于白盒测试范围，一般情况下是在开发人员完成了某个单独模块的编码之后做的测试。
它的目的是检查软件编码的正确性以及一些规范性测试，站在开发人员的角度上来查找软件所存在的 BUG 并记录下产生BUG 的原因，以便开发人员进行修改。
这样可以在很大程度上减少集成以后而出现的BUG。
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。
这在外表上看来是一项明显的进步，而象单元测试会推迟对整个系统进行合并这种真正有意思的工作启动的时间。
这种开发步骤中，真实意义上的进步被软件合并后的外表上的进步取代了。
系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的 Bug。
现实的开发中，没有单元测试的软件常常会导致这样的结果，软件甚至无法运行。
更进一步的结果是大量的时间将被花费在本应该在单元测试里就完成的简单Bug 上面，在个别情况下，这些Bug 也许是琐碎和微不足道的，但是总的来说，他们会延长软件集成为一个系统的时间，而且当这个系统投入使用时也无法确保它能够可靠运行。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试应该是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。
因此，所有的测试都必须在整个软件系统的生命周期中进行，也就是说每个版本的开发都需要经过单元测试，这样可以在以后的开发阶段减少很多不必要的麻烦。
单元测试的重点测试内容包括：源代码测试、命名规范测试、需求完整性测试、页面完整性测试、提示文本测试、页面脚本测试等。
二、集成测试集成测试也属于白盒测试范围，是在单元测试的基础上将软件的多个模块或者系统前后台合并之后进行的测试，也可以算是对单元测试修改进行的复审测试。
软件测试专业术语
软件测试专业术语嘿，你要是想踏入软件测试这个奇妙的领域呀，那可就得先了解一些专业术语啦。
就像你要去一个陌生的国度旅游，你得先知道当地的一些特殊用语一样。
咱先来说说“Bug”这个词吧。
这可算是软件测试里最常见的词儿了。
你想啊，软件就像一个精密的机器，Bug就像是机器里的小沙子，会让这机器运转不灵呢。
比如说你正在用一个手机APP，点某个按钮的时候突然闪退了，哎呀，这十有八九就是Bug在捣乱啦。
还有“测试用例”。
这是什么呢？简单来讲，就像是厨师做菜的菜谱。
厨师按照菜谱做菜，我们测试人员就按照测试用例来测试软件。
比如测试一个购物APP，测试用例可能就会写“点击商品图片，查看商品详情是否完整显示”，就这么清晰明了。
“缺陷密度”呢？这就好比是一块蛋糕里坏果子的比例。
如果缺陷密度太高，那就说明这个软件啊，就像那个满是坏果子的蛋糕，质量堪忧啊。
比如说一个小程序，总共就没几个功能，结果一测试发现好多问题，这缺陷密度肯定就大得吓人啦。
“回归测试”也很重要。
这就像是你修好一扇破窗户之后，再检查一遍房子其他地方有没有受到影响。
比如说我们给一个软件的登录功能修复了一个Bug，那我们就得再重新测试一下其他功能，像注册功能、找回密码功能啥的，确保它们还能正常工作。
“冒烟测试”听起来挺怪的吧？其实就像是你刚打开一个新的电器，先看看它能不能正常通电，有没有冒烟啥的，初步检查一下软件的主要功能是否能正常运行。
就像测试一款新的游戏软件，先看看能不能正常进入游戏界面，这就是冒烟测试。
在软件测试的世界里，这些术语就像一个个小密码，只有掌握了它们，你才能真正理解这个领域的奥秘。
我觉得啊，这些术语虽然乍一听有点复杂，但只要你把它们和生活中的东西类比起来，就会发现其实也没那么难理解啦。
就像交朋友一样，刚开始觉得陌生，相处久了就熟悉得很呢。
所以呀，别害怕这些软件测试专业术语，大胆地去探索这个有趣的世界吧。
软件测试常用术语 (新手必看)
在软件测试中会遇到一些专有名词，英文缩写，涉及到网络、软件、测试各个层面,软件测试需要跨平台，所以在技术拓展上要留意多方面的积累与总结！ADO: ActiveX Data Object，ActiveX 数据对象。
是ASP语言访问数据库的中间件。
BAT: Build Acceptance Testing，工作版本可接受测试。
新工作版本正式测试前进行的一项快速测试过程，目的是保证软件的基本功能和内容正确完整，具有可测试性，经过BAT 测试后，就进入了正轨测试阶段。
BRC: Bug Review Council，缺陷复查委员会。
负责 Adobe 软件缺陷的成员，负责复查报告的新缺陷是否正确，并且修正处理。
CCJK : Chinese Simplified，Chinese Traditional, Japanese，Korean，简体中文，繁体中文，日文和朝鲜语。
本地化测试中的四种典型东亚语言。
CMM : Capability Maturity Model，能力成熟度模型。
美国卡内基·梅隆大学的软件工程研究院(SEI)开发的用于软件开发过程的管理及工程能力的提高与评估的方法，共五个级别。
C/S : Client/Server，客户机/服务器。
来源：深圳软件测试局域网软件的一种模式。
DBCS : Double Bytes Character Set，双字节字符集。
用两个字节长度表示一个字符的字符编码系统。
中文，日文和朝鲜文都用双字节字符集表示。
DLL : Dynamic Link Library，动态链接库。
大型软件常用的一种软件开发方法，按照功能模块将不同功能分别集成在不同的动态链接库中。
国际化软件开发中通常将可以本地化的软件界面资源文件放在单独的动态链接库中，便于本地化处理。
DTS : Defect Tracking System，缺陷跟踪系统。
软件测试中集中管理软件缺陷（bug）的数据库，完成缺陷报告、修改、查询、统计等功能。
软件测试专业术语中英文对照
软件测试专业术语中英文对照AAcceptance testing : 验收测试Acceptance Testing：可接受性测试Accessibility test : 软体适用性测试actual outcome：实际结果Ad hoc testing : 随机测试Algorithm analysis : 算法分析algorithm：算法Alpha testing : α测试analysis：分析anomaly：异常application software：应用软件Application under test (AUT) : 所测试的应用程序Architecture : 构架Artifact : 工件ASQ：自动化软件质量（Automated Software Quality）Assertion checking : 断言检查Association : 关联Audit : 审计audit trail：审计跟踪Automated Testing：自动化测试BBackus-Naur Form：BNF范式baseline：基线Basic Block：基本块basis test set：基本测试集Behaviour : 行为Bench test : 基准测试benchmark：标杆/指标/基准Best practise : 最佳实践Beta testing : β测试Black Box Testing：黑盒测试Blocking bug : 阻碍性错误Bottom-up testing : 自底向上测试boundary value coverage：边界值覆盖boundary value testing：边界值测试Boundary values : 边界值Boundry Value Analysis：边界值分析branch condition combination coverage：分支条件组合覆盖branch condition combination testing：分支条件组合测试branch condition coverage：分支条件覆盖branch condition testing：分支条件测试branch condition：分支条件Branch coverage : 分支覆盖branch outcome：分支结果branch point：分支点branch testing：分支测试branch：分支Breadth Testing：广度测试Brute force testing: 强力测试Buddy test : 合伙测试Buffer : 缓冲Bug : 错误Bug bash : 错误大扫除bug fix : 错误修正Bug report : 错误报告Bug tracking system: 错误跟踪系统bug：缺陷Build : 工作版本（内部小版本）Build Verfication tests(BVTs): 版本验证测试Build-in : 内置CCapability Maturity Model (CMM): 能力成熟度模型Capability Maturity Model Integration (CMMI): 能力成熟度模型整合capture/playback tool：捕获/回放工具Capture/Replay Tool：捕获/回放工具CASE：计算机辅助软件工程（computer aided software engineering）CAST：计算机辅助测试cause-effect graph：因果图certification ：证明change control：变更控制Change Management :变更管理Change Request :变更请求Character Set : 字符集Check In :检入Check Out :检出Closeout : 收尾code audit ：代码审计Code coverage : 代码覆盖Code Inspection：代码检视Code page : 代码页Code rule : 编码规范Code sytle : 编码风格Code Walkthrough：代码走读code-based testing：基于代码的测试coding standards：编程规范Common sense : 常识Compatibility Testing：兼容性测试complete path testing ：完全路径测试completeness：完整性complexity ：复杂性Component testing : 组件测试Component：组件computation data use：计算数据使用computer system security：计算机系统安全性Concurrency user : 并发用户Condition coverage : 条件覆盖condition coverage：条件覆盖condition outcome：条件结果condition：条件configuration control：配置控制Configuration item : 配置项configuration management：配置管理Configuration testing : 配置测试conformance criterion：一致性标准Conformance Testing：一致性测试consistency ：一致性consistency checker：一致性检查器Control flow graph : 控制流程图control flow graph：控制流图control flow：控制流conversion testing：转换测试Core team : 核心小组corrective maintenance：故障检修correctness ：正确性coverage ：覆盖率coverage item：覆盖项crash：崩溃criticality analysis：关键性分析criticality：关键性CRM(change request management): 变更需求管理Customer-focused mindset : 客户为中心的理念体系Cyclomatic complexity : 圈复杂度Ddata corruption：数据污染data definition C-use pair：数据定义C-use使用对data definition P-use coverage：数据定义P-use覆盖data definition P-use pair：数据定义P-use使用对data definition：数据定义data definition-use coverage：数据定义使用覆盖data definition-use pair ：数据定义使用对data definition-use testing：数据定义使用测试data dictionary：数据字典Data Flow Analysis : 数据流分析data flow analysis：数据流分析data flow coverage：数据流覆盖data flow diagram：数据流图data flow testing：数据流测试data integrity：数据完整性data use：数据使用data validation：数据确认dead code：死代码Debug : 调试Debugging：调试Decision condition：判定条件Decision coverage : 判定覆盖decision coverage：判定覆盖decision outcome：判定结果decision table：判定表decision：判定Defect : 缺陷defect density : 缺陷密度Defect Tracking :缺陷跟踪Deployment : 部署Depth Testing：深度测试design for sustainability :可延续性的设计design of experiments：实验设计design-based testing：基于设计的测试Desk checking : 桌前检查desk checking：桌面检查Determine Usage Model : 确定应用模型Determine Potential Risks : 确定潜在风险diagnostic：诊断DIF(decimation in frequency) : 按频率抽取dirty testing：肮脏测试disaster recovery：灾难恢复DIT （decimation in time）: 按时间抽取documentation testing ：文档测试domain testing：域测试domain：域DTP DETAIL TEST PLAN详细确认测试计划Dynamic analysis : 动态分析dynamic analysis：动态分析Dynamic Testing：动态测试Eembedded software：嵌入式软件emulator：仿真End-to-End testing：端到端测试Enhanced Request :增强请求entity relationship diagram：实体关系图Encryption Source Code Base：加密算法源代码库Entry criteria : 准入条件entry point ：入口点Envisioning Phase : 构想阶段Equivalence class : 等价类Equivalence Class：等价类equivalence partition coverage：等价划分覆盖Equivalence partition testing : 等价划分测试equivalence partition testing:参考等价划分测试equivalence partition testing：等价划分测试Equivalence Partitioning：等价划分Error : 错误Error guessing : 错误猜测error seeding：错误播种/错误插值error：错误Event-driven : 事件驱动Exception handlers : 异常处理器exception：异常/例外executable statement：可执行语句Exhaustive Testing：穷尽测试exit point：出口点expected outcome：期望结果FExploratory testing : 探索性测试Failure : 失效Fault : 故障fault：故障feasible path：可达路径feature testing：特性测试Field testing : 现场测试FMEA：失效模型效果分析（Failure Modes and Effects Analysis）FMECA：失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)Framework : 框架FTA：故障树分析(Fault Tree Analysis)functional decomposition：功能分解Functional Specification ：功能规格说明书Functional testing : 功能测试Functional Testing：功能测试GG11N(Globalization) : 全球化Gap analysis : 差距分析Garbage characters : 乱码字符glass box testing：玻璃盒测试Glass-box testing : 白箱测试或白盒测试Glossary : 术语表GUI(Graphical User Interface): 图形用户界面HHard-coding : 硬编码Hotfix : 热补丁II18N(Internationalization): 国际化Identify Exploratory Tests –识别探索性测试IEEE：美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）Incident 事故Incremental testing : 渐增测试incremental testing：渐增测试infeasible path：不可达路径input domain：输入域Inspection : 审查inspection：检视installability testing：可安装性测试Installing testing : 安装测试instrumentation：插装instrumenter：插装器Integration :集成Integration testing : 集成测试interface : 接口interface analysis：接口分析interface testing：接口测试interface：接口invalid inputs：无效输入isolation testing：孤立测试Issue : 问题Iteration : 迭代Iterative development: 迭代开发Jjob control language：工作控制语言Job：工作KKey concepts : 关键概念Key Process Area : 关键过程区域Keyword driven testing : 关键字驱动测试Kick-off meeting : 动会议LL10N(Localization) : 本地化Lag time : 延迟时间LCSAJ：线性代码顺序和跳转（Linear Code Sequence And Jump）LCSAJ coverage：LCSAJ覆盖LCSAJ testing：LCSAJ测试Lead time : 前置时间Load testing : 负载测试Load Testing：负载测试Localizability testing: 本地化能力测试Localization testing : 本地化测试logic analysis：逻辑分析logic-coverage testing：逻辑覆盖测试MMaintainability : 可维护性maintainability testing：可维护性测试Maintenance : 维护Master project schedule :总体项目方案Measurement : 度量Memory leak : 内存泄漏Migration testing : 迁移测试Milestone : 里程碑Mock up : 模型，原型modified condition/decision coverage：修改条件/判定覆盖modified condition/decision testing ：修改条件/判定测试modular decomposition:参考模块分解Module testing : 模块测试Monkey testing : 跳跃式测试Monkey Testing：跳跃式测试mouse over：鼠标在对象之上mouse leave：鼠标离开对象MTBF：平均失效间隔实际（mean time between failures）MTP MAIN TEST PLAN主确认计划MTTF：平均失效时间（mean time to failure）MTTR：平均修复时间（mean time to repair）multiple condition coverage：多条件覆盖mutation analysis：变体分析NN/A(Not applicable) : 不适用的Negative Testing : 逆向测试, 反向测试, 负面测试negative testing:参考负面测试Negative Testing：逆向测试/反向测试/负面测试off by one：缓冲溢出错误non-functional requirements testing:非功能需求测试nominal load:额定负载N-switch coverage：N切换覆盖N-switch testing：N切换测试N-transitions：N转换OOff-the-shelf software : 套装软件operational testing：可操作性测试output domain：输出域Ppaper audit:书面审计Pair Programming : 成对编程partition testing：分类测试Path coverage : 路径覆盖path coverage：路径覆盖path sensitizing：路径敏感性path testing：路径测试path：路径Peer review : 同行评审Performance : 性能Performance indicator: 性能（绩效）指标Performance testing : 性能测试Pilot : 试验Pilot testing : 引导测试Portability : 可移植性portability testing：可移植性测试Positive testing : 正向测试Postcondition : 后置条件Precondition : 前提条件precondition：预置条件predicate data use：谓词数据使用predicate：谓词Priority : 优先权program instrumenter：程序插装progressive testing：递进测试Prototype : 原型Pseudo code : 伪代码pseudo-localization testing：伪本地化测试pseudo-random：伪随机QQC：质量控制（quality control）Quality assurance(QA): 质量保证Quality Control(QC) : 质量控制RRace Condition：竞争状态Rational Unified Process(以下简称RUP):瑞理统一工艺Recovery testing : 恢复测试recovery testing：恢复性测试Refactoring : 重构regression analysis and testing：回归分析和测试Regression testing : 回归测试Release : 发布Release note : 版本说明release：发布Reliability : 可靠性reliability assessment：可靠性评价reliability：可靠性Requirements management tool: 需求管理工具Requirements-based testing : 基于需求的测试Return of Investment（ROI）: 投资回报率review：评审Risk assessment : 风险评估risk：风险Robustness : 强健性Root Cause Analysis(RCA): 根本原因分析Ssafety critical：严格的安全性safety：（生命）安全性Sanity testing : 健全测试Sanity Testing：理智测试Schema Repository : 模式库Screen shot : 抓屏、截图SDP：软件开发计划（software development plan）Security testing : 安全性测试security testing：安全性测试security.：（信息）安全性serviceability testing：可服务性测试Severity : 严重性Shipment : 发布simple subpath：简单子路径Simulation : 模拟Simulator : 模拟器SLA(Service level agreement): 服务级别协议SLA：服务级别协议（service level agreement）Smoke testing : 冒烟测试Software development plan(SDP): 软件开发计划Software development process: 软件开发过程software development process：软件开发过程software diversity：软件多样性software element：软件元素software engineering environment：软件工程环境software engineering：软件工程Software life cycle : 软件生命周期source code：源代码source statement：源语句Specification : 规格说明书specified input：指定的输入spiral model ：螺旋模型SQAP SOFTWARE QUALITY ASSURENCE PLAN 软件质量保证计划SQL：结构化查询语句（structured query language）Staged Delivery：分布交付方法state diagram：状态图state transition testing ：状态转换测试state transition：状态转换state：状态Statement coverage : 语句覆盖statement testing：语句测试statement：语句Static Analysis：静态分析Static Analyzer：静态分析器Static Testing：静态测试statistical testing：统计测试Stepwise refinement : 逐步优化storage testing：存储测试Stress Testing : 压力测试structural coverage：结构化覆盖structural test case design：结构化测试用例设计structural testing：结构化测试structured basis testing：结构化的基础测试structured design：结构化设计structured programming：结构化编程structured walkthrough：结构化走读stub：桩sub-area：子域Summary：总结SVVP SOFTWARE Vevification&Validation PLAN：软件验证和确认计划symbolic evaluation：符号评价symbolic execution:参考符号执行symbolic execution：符号执行symbolic trace：符号轨迹Synchronization : 同步Syntax testing : 语法分析system analysis：系统分析System design : 系统设计system integration：系统集成System Testing : 系统测试TTC TEST CASE 测试用例TCS TEST CASE SPECIFICATION 测试用例规格说明TDS TEST DESIGN SPECIFICATION 测试设计规格说明书technical requirements testing：技术需求测试Test : 测试test automation：测试自动化Test case : 测试用例test case design technique：测试用例设计技术test case suite：测试用例套test comparator：测试比较器test completion criterion：测试完成标准test coverage:测试覆盖Test design : 测试设计Test driver : 测试驱动test environment:测试环境test execution technique:测试执行技术test execution:测试执行test generator:测试生成器test harness:测试用具Test infrastructure : 测试基础建设test log:测试日志test measurement technique:测试度量技术Test Metrics :测试度量test procedure:测试规程test records:测试记录test report:测试报告Test scenario : 测试场景Test Script:测试脚本Test Specification:测试规格Test strategy : 测试策略test suite:测试套Test target : 测试目标Test ware : 测试工具Testability : 可测试性testability:可测试性Testing bed : 测试平台Testing coverage : 测试覆盖Testing environment : 测试环境Testing item : 测试项Testing plan : 测试计划Testing procedure : 测试过程Thread testing : 线程测试time sharing:时间共享time-boxed : 固定时间TIR test incident report 测试事故报告ToolTip:控件提示或说明top-down testing:自顶向下测试TPS TEST PEOCESS SPECIFICATION 测试步骤规格说明Traceability : 可跟踪性traceability analysis:跟踪性分析traceability matrix:跟踪矩阵Trade-off : 平衡transaction:事务/处理transaction volume：交易量transform analysis:事务分析trojan horse:特洛伊木马truth table:真值表TST TEST SUMMARY REPORT 测试总结报告Tune System : 调试系统TW TEST WARE :测试件UUsability Testing:可用性测试Usage scenario : 使用场景User acceptance Test : 用户验收测试User database :用户数据库User interface(UI) : 用户界面User profile : 用户信息User scenario : 用户场景VV&V (Verification & Validation) : 验证&确认validation :确认verification :验证version :版本Virtual user : 虚拟用户volume testing:容量测试VSS（visual source safe）：VTP Verification TEST PLAN验证测试计划VTR Verification TEST REPORT验证测试报告WWalkthrough : 走读Waterfall model : 瀑布模型White box testing : 白盒测试Work breakdown structure (WBS) : 任务分解结构ZZero bug bounce (ZBB) : 零错误反弹。
软件测试常见术语英文缩写
软件测试常见术语-英文缩写ADO，ActiveX Data Object，ActiveX 数据对象。
是ASP语言访问数据库的中间件。
BA T，Build Aclearcase/" target="_blank" >cceptance Testing，工作版本可接受测试。
新工作版本正式测试前进行的一项快速测试过程，目的是保证软件的基本功能和内容正确完整，具有可测试性，经过BAT测试后，就进入了正轨测试阶段。
BRC，Bug Review Council，缺陷复查委员会。
负责Adobe 软件缺陷的成员，负责复查报告的新缺陷是否正确，并且修正处理。
CCJK，Chinese Simplified，Chinese Traditional, Japanese，Korean，简体中文，繁体中文，日文和朝鲜语。
本地化测试中的四种典型东亚语言。
CMM，Capability Maturity Model，能力成熟度模型。
美国卡内基·梅隆大学的软件工程研究院(SEI)开发的用于软件开发过程的管理及工程能力的提高与评估的方法，共五个级别。
C/S，Client/Server，客户机/服务器。
局域网软件的一种模式。
DBCS，Double Bytes Character Set，双字节字符集。
用两个字节长度表示一个字符的字符编码系统。
中文，日文和朝鲜文都用双字节字符集表示。
DLL，Dynamic Link Library，动态链接库。
大型软件常用的一种软件开发方法，按照功能模块将不同功能分别集成在不同的动态链接库中。
国际化软件开发中通常将可以本地化的软件界面资源文件放在单独的动态链接库中，便于本地化处理。
DTS，Defect Tracking System，缺陷跟踪系统。
软件测试中集中管理软件缺陷(bug)的数据库，完成缺陷报告、修改、查询、统计等功能。
EOF，End Of File，文件结尾。
软件测试标准专业术语对照表
软件测试专业术语对照表此术语表为国际软件测试认证委员会（ISTQB）发布的标准术语表。
此国际软件测试认证委员会（ISTQB）发布的标准术语表即是以最新版的BS 7925-1标准为基础制定的国际化软件测试标准术语。
1 简介行业界、商业界、政府及学术机构曾经花费大量精力和时间以解释和区分一些常见的软件测试专业术语以期在各社会部门或机构之间达成交流，例如：语句覆盖(statement coverage) 和条件覆盖(decision overage)；测试套件(test suite)、测试规格说明书(test specification)和测试计划(test plan)等。
上述机构与专职机构定义的同名术语在含义上又往往有很大偏差。
2 范畴本文档旨在提供概念、条款、和定义为软件测试及相关从业人员进行有效交流的平台。
3 结构术语表中的词汇按字母顺序排列。
术语如有同义词汇，本术语表解释最通用的词汇，其同义词汇会的仅被列出，不予重复解释。
例如结构测试(structural testing) 和白盒测试(white box testing)。
此类同义词在术语表中用“参见”列出，以便读者检索。
“参见”往往连接着广义和狭义词或含义重叠的词汇。
4 标准参考至截稿日期，此标准有效版本为1.2。
如所有其他标准一样，本术语表仍需根据以下相关标准的最新版本不断修正。
此标准由IEC 和ISO 成员根据目前有效的国际相关标准进行更新。
- BS 7925-2:1998. Software Component Testing.- DO-178B:1992. Software Considerations in Airborne Systems and Equipment Certification, Requirements and Technical Concepts for Aviation (RTCA SC167).- IEEE 610.12:1990. Standard Glossary of Software Engineering Terminology.- IEEE 829:1998. Standard for Software Test Documentation.- IEEE 1008:1993. Standard for Software Unit Testing.- IEEE 1012:1986. Standard for Verification and Validation Plans- IEEE 1028:1997. Standard for Software Reviews and Audits.- IEEE 1044:1993. Standard Classification for Software Anomalies.- IEEE 1219:1998. Software Maintenance.- ISO/IEC 2382-1:1993. Data processing - Vocabulary - Part 1: Fundamental terms.- ISO 9000:2000. Quality Management Systems – Fundamentals and Vocabulary.- ISO/IEC 9126-1:2001. Software Engineering – Software Product Quality – Part 1: Quality characteristis and sub-characteristics.- ISO/IEC 12207:1995. Information Technology – Software Life Cycle Processes.- ISO/IEC 14598-1:1996. Information Technology – Software Product Evaluation - Part 1: General Overview.Aabstract test case 抽象测试用例参见high level test case.acceptance 验收参见acceptance testing.acceptance criteria 验收准则为了满足组件或系统使用者、客户或其他授权实体的需要，组件或系统必须达到的准则。
软件评测师测试术语及名词解释汇总
软件评测师测试术语及名词解释汇总测试⽤例⼀、定义测试⽤例( Test Case )是指对⼀项特定的软件产品进⾏测试任务的描述，体现测试⽅案、⽅法、技术和策略。
内容包括测试⽬标、测试环境、输⼊数据、测试步骤、预期结果、测试脚本等，并形成⽂档。
⼆、测试⽤例的分类根据测试过程中具体涉及到问题类型及测试需求，可将测试⽤例分为如下：·功能性测试⽤例·界⾯测试⽤例：适⽤于所有测试阶段中的界⾯测试·数据处理测试⽤例：适⽤于所有测试阶段中的数据处理测试·操作流程测试⽤例：适⽤于所有流程性的测试·安装测试⽤例：适⽤于所有安装测试三、测试⽤例管理·编写⽤例：测试⼯程师根据需求规约、概要设计、详细设计等⽂档编写测试⽤例。
·⽤例评审：原则上⽤例象程序⼀样，要经过多次的修改才可以通过，实际⼯作中通常进⾏⼀次。
·⽤例修改：评审结束后，您需要根据评审意见进⾏修改，修改后通常不再进⾏评审。
·使⽤⽤例：执⾏测试⽤例，并记录到测试⽤例执⾏报告中。
·⽤例升级/ 维护：随着软件产品不断修改、升级，对应的⽤例也需要升级维护。
针对同⼀个项⽬，可以根据需求的变更不断进⾏维护;如果是产品，⽤例的维护更加重要，要达到⽤例和产品的版本⼀⼀对应。
四、测试⽤例的编制及使⽤1.设计测试⽤例每个具体测试⽤例都将包括下列详细信息：编制⼈、审定⼈、编制⽇期、版本、⽤例类型、设计说明书编号、⽤例编号、⽤例名称、输⼊说明、期望结果(含判断标准)、环境要求、备注等。
· “测试⽤例名称”可以是不涉及到具体模块的功能描述，如“⽇期格式”，“⾮空检验”等。
· “输⼊说明”是功能模块接受的数据或各种操作描述，如“输⼊⾮法的⽇期格式”等。
· “期望结果”是模块接受输⼊后应有的正常输出描述，如“提⽰⽤户修改”等，期望结果应与输⼊说明⼀⼀对应。
·测试⽤例⽤于指导执⾏操作，但某些意外操作也可导致程序错误，这些操作称为⾮预期性操作，可以先有执⾏报告，再后补⽤例。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
软件【Software】：软件（software）是计算机中与硬件（hardware）相结合的一部分，包括程序（program）和文档（document）。
用一个等式表示为：软件＝程序＋文档。
其中，“程序”指的是能够实现某种功能的指令的集合，如C语言程序，Java程序等；“文档”指的是在软件开发、使用和维护过程中产生的图文集合，如《系统需求规格说明书》、《用户手册》、readme，甚至是一些软件市场宣传资料，包装文字和图形等。
【备注：软件测试绝不等同于程序测试，文档测试也是软件测试的一个重要组成部分。
通常，程序测试主要包括程序逻辑功能、界面、性能、易用性、兼容性、安装等的测试；文档测试主要包括文档内容和截图的校验，排版风格的检查，错别字的校验等】客户端/服务器【C/S】：C指的是客户端（Client），S指的是服务器端（Server）,这种软件是基于局域网或互联网的，需要一台服务器来安装服务器端软件，每台客户端都需要安装客户端软件。
比如我们经常用的QQ、MSN和各种网络游戏就属于C/S结构的软件。
【备注：C/S结构的软件过去比较流行，但是不便于升级和维护，现在逐渐被B/S结构软件所取代】浏览器/服务器【B/S】：B指的是浏览器（Browser），S指的是服务器（Server），这种软件同样是基于局域网或互联网的，它与结C/S构软件的区别就在于，不需要安装客户端（client），只需要有IE 等浏览器，就可以直接使用。
比如搜狐、新浪等门户网站及163邮箱都属于B/S结构的软件。
【备注：B/S结构软件是现在软件的主流，与C/S结构软件相比，便于升级和维护，是测试的重点】缺陷【Bug/Defect】：软件的Bug指的是软件中（包括程序和文档）不符合用户需求的问题。
【备注：这个定义是判断一个软件问题是否是Bug个唯一标准】软件测试【Software Testing】：使用人工或自动手段，来运行或测试某个系统的过程。
其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别（1983，IEEE软件工程标准术语）。
测试环境【Testing Environment(TE)】：软件测试环境就是软件运行的平台，包括软件、硬件和网络的集合。
用一个等式来表示：测试环境＝软件＋硬件＋网络。
其中，“硬件”主要包括PC机（包括品牌机和兼容机）、笔记本、服务器、各种PDA终端等；“软件”主要指软件运行的操作系统；“网络”主要针对的是C/S结构和B/S结构的软件。
【备注：作为一个合格的软件测试工程师，不仅要熟悉软件的知识，也要了解硬件和网络的相关知识】测试用例【Test Case(TC)】：指的是在测试执行之前设计的一套详细的测试方案，包括测试环境、测试步骤、测试数据和预期结果。
用一个等式来简单表示：测试用例＝输入＋输出＋测试环境。
其中，“输入”包括测试数据和操作步骤；“输出”指的是期望结果；测试环境指的是系统环境设置。
黑盒测试【Black-Box Testing】：指的是把被测软件看作是一个黑盒子，我们不去关心盒子里面的结构是什么样子的，只关心软件的输入数据和输出结果。
备注：黑盒测试既包括功能测试，也包括性能测试。
白盒测试【White-Box Testing】：指的是把盒子盖打开，去研究里面的源代码和程序结构。
灰盒测试【Gray-Box Testing】：可以把它看作是黑盒测试和白盒测试的一种结合。
静态测试【Static Testing】：是指不实际运行被测软件，而只是静态地检查程序代码、界面或文档中可能存在的错误的过程。
代码走查【Walkthrough】：静态测试的一种方法，由开发组内部进行，采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
代码审查【Inspection】：静态测试的一种方法，由开发组内部进行，采用讲解、提问并使用编码模板进行的查找错误的活动。
一般有正式的计划、流程和结果报告。
技术评审【Review】：静态测试的一种方法，由开发组、测试组和相关人员（QA、产品经理等）联合进行，采用讲解、提问并使用编码模板进行的查找错误的活动。
一般有正式的计划、流程和结果报告。
动态测试【Dynamic Testing】：是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
单元测试【Unit Testing】：是指对软件中的最小可测试单元进行检查和验证。
例如，在C语言中，单元一般指1个函数；Java里，单元一般指1个类；在图形化的软件中，单元也可以指1个窗口、1个菜单等。
桩模块【Stub】：是指模拟被测模块所调用的模块。
驱动模块【Driver】：是指模拟被测模块的上级模块，驱动模块用来接收测试数据，启动被测模块，并输出结果。
集成测试【Integration Testing】：是指将通过测试的单元模块组装成系统或子系统，在进行测试，重点测试不同模块的接口部分。
系统测试【System Testing】：指的是将整个软件系统看作是一个整体测试，包括对功能、性能的测试，以及对软件所运行的软、硬件环境的测试。
验收测试【Acceptance Testing】：指的是在系统测试的后期，以用户测试为主，或有测试人员等质量保障人员共同参与的测试，它也是软件正式交给用户使用的最后一道工序。
α测试：验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试。
β测试：验收测试的一种，指的是内测后的公测，即完全交给最终用户测试。
功能测试【Function Testing】：是黑盒测试的一种，它检查实际软件的功能是否符合用户的需求。
界面测试【UI Testing】：UI是User Interface，即用户界面的缩写。
一般情况下，都把软件的界面测试用例同软件的逻辑功能测试用例分开去写。
易用性测试【Usability Testing】：是指从软件使用的合理性和方便性等角度对软件系统进行检查，来发现软件中不方便用户使用的地方。
安装测试【Installation Testing】：这里的安装测试是指广义上的，包括安装、卸载。
兼容性测试【Compatibility Testing】：兼容性测试包括硬件兼容性测试和软件兼容性测试；硬件兼容性主要是指软件运行的不同硬件平台的兼容性，如PC机、笔记本、服务器等；软件兼容性主要是指软件运行在不同操作系统等软件平台上的兼容性。
性能测试【Performance Testing】：是指对软件的运行反馈速度、所消耗系统资源等各种性能指标的测试。
可靠性测试【Reliability Testing】：也叫稳定性测试，是指连续运行被测系统，检查系统运行时的稳定程度。
人们通常用MTBF （Mean Time Between Failure）来衡量系统的稳定性，MTBF越大，系统的稳定性越强。
负载测试【Load Testing】：是性能测试的一种，通常是指被测系统在其能忍受的压力<极限范围之内连续运行>，来测试系统的稳定性。
压力测试【Stress Testing】：是性能测试的一种，通常是指持续<不断地>给被测系统增加压力，直到将被测系统<压跨为止>，用来测试系统所能承受的最大压力。
回归测试【Regression Testing】：是指对软件的新版本测试时，重复执行上一个版本测试时的用例。
冒烟测试【Smoke Testing】：又名：ad-hoc是指在对一个新版本进行系统大规模地测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
随机测试【Random Testing】：是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。
软件质量保障【Software Quality Assurance(SQA)】：为了确保软件<开发过程和结果符合预期的要求>，而建立的一系列规程，以及依照规程和计划采取的一系列活动及其结果评价。
软件能力成熟度模型【Capability Maturity Model(CMM)】：CMM就是SQA用来监督项目的一个标准质量模型，是由卡耐基－梅隆大学于20实际80年代制定的，最初只是应用于本校的软件项目开发，后来逐渐推广为主流的行业标准。
CMM共为5级：初始级、可重复级、已定义级、已管理级和优化级。
有效等价类【Valid Equivalence Class】：是指符合《需求规格说明书》，合理地输入数据集合。
无效等价类【Invalid Equivalence Class】：是指不符合《需求规格说明书》，无意义地输入数据集合。
软件生命周期【Software Life Cycle】：是指软件开发和测试全部过程、活动和任务的结构框架，是从可行性研究到需求分析、软件设计、编码、测试、软件发布维护的过程。
黑盒测试工具【Black-Box Testing Tools】：是指测试功能或性能的工具，主要用于系统测试和验收测试；其又可分为功能测试工具和性能测试工具。
白盒测试工具【White-Box Testing tools】：是指测试软件的源代码的工具，可以实现代码的静态分析、动态测试、评审等功能，主要用于单元测试。
测试管理工具【Testing Management Tools】：是指管理整个测试流程的工具，主要功能有测试计划的管理、测试用例的管理、缺陷跟踪、测试报告管理等，一般贯穿于整个软件生命周期。
测试工作的正确四步曲What to do 第一步, 确立测试范围和对象, 如果这一步漏了,后面的质量全打折扣--测试计划How to do 第二步, 决定用什么测试技术或手段来测试这些测试对象 --测试方案When to do 第三步, 决定先测试哪些测试对象和先应用哪些测试技术 --测试策略Automation 第四步, 尽可能把how to do的工作都自动化,从而提升执行效率(仅仅是执行效率) --测试效率产品所有的架构和设计缺陷：异常处理；功能组合处理；算法选取考虑不周全；以及非功能属性的设计需求。
需求的质量也是有维度的：二义性、可测性、完整性、前后一致性、可实现性、必要性。