测试名词解释.docx
《测试名词解释.docx》由会员分享，可在线阅读，更多相关《测试名词解释.docx（16页珍藏版）》请在冰豆网上搜索。
测试名词解释
1为什么要进行软件测试？
测试就是为了让产品在交付给最终用户以后，在产品生存周期（或提供有效服务的期限以内），不让最终用户发现其所不能接受的现象。
良好的测试，可以有效的降低维护的成本。
用户如果满意你的产品，就不会一而再、再而三的要求改进，维护的成本自然会下降。
当然，测试本身的成本也是不低的，所以为了让我们为测试付出的代价物有所值（大概还没有人会说自己的产品从未经过测试吧），我们很有必要去认真的了解一下关于测试的一些东西。
2软件产品质量特性是？
Ø功能性：
适合性、准确性、互操作性、依从性、安全性
Ø可靠性：
成熟性、容错性、易恢复性
Ø可用性：
易理解性、易学习性、易操作性
Ø可维护性：
时间特性、资源特性
Ø效率：
易分析性、易改变性、稳定性、易测试性
Ø可移植性：
适应性、易安装性、遵循性、易替换性
3什么是软件测试？
软件测试是在有限的时间内提供高软件质量的保证，是一个完整正规的软件开发过程中非常重要的一个部分。
果
使用人工或者自动手段来运行或测试某个系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结之间的差别。
它是帮助识别开发完成（中间或最终的版本）的计算机软件（整体或部分）的正确度（correctness）、完全度（completeness）和质量（quality）的软件过程；是SQA（softwarequalityassurance）的重要子域。
（1）测试并不仅仅是为了找出错误。
通过分析错误产生的原因和错误的发生趋势，可以帮助项目管理者发现当前软件开发过程中的缺陷，以便及时改进；
（2）这种分析也能帮助测试人员设计出有针对性的测试方法，改善测试的效率和有效性；
（3）没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。
4软件测试的目的？
软件测试的目的,第一是确认软件的质量，其一方面是确认软件做了你所期望做的事情（Dotherightthing），另一方面是确认软件以正确的方式来做了这个事情（Doitright）。
第二是提供信息，比如提供给开发人员或程序经理的回馈信息，为风险评估所准备的信息。
第三软件测试不仅是在测试软件软件产品本身，而且还包括软件开发的过程。
如果一个软件产品开发完成之后发现了很多问题，这说明此软件开发过程很可能是有缺陷的。
因此，软件测试的第三个目的是保证整个软件开发过程是高质量的。
5测试中的验证和确认是什么？
有什么区别？
验证——
明确用户需求是什么，一般通过《需求分析》来完成。
客户通过这个文档验证自己的需求是否得到满足。
确认——
明确如何满足用户需求，一般通过《总体设计》或《解决方案》完成。
客户确认自己要求如何被满足的同时，还会确认他要为这个满足支付的价格。
6什么是测试项？
Testingitem（测试项），作为测试对象的工作版本。
7什么是功能测试、性能测试、压力测试、容量测试、稳定测试、安全测试、GUI测试、可用性测试、兼容测试、安装测试、配置测试、导常测试、备份测试、健壮测试、文档测试、网络测试、分布测试
1功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。
2性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
3压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
现在的网络游戏中也常用到这个词汇。
4 容量测试的目的是通过测试预先分析出反映软件系统应用特征的某项指标的极限值（如最大并发用户数、数据库记录数等），系统在其极限状态下没有出现任何软件故障或还能保持主要功能正常运行。
容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。
软件容量的测试能让软件开发商或用户了解该软件系统的承载能力或提供服务的能力，如某个电子商务网站所能承受的、同时进行交易或结算的在线用户数。
知道了系统的实际容量，如是不能满足设计要求，就应该寻求新的技术解决方案，以提高系统的容量。
有了对软件负载的准确预测，不仅能对软件系统在实际使用中的性能状况充满信心，同时也可以帮助用户经济地规划应用系统，优化系统的部署。
5软件的稳定性应该和软件的可靠性是不同的。
软件的稳定性从软件开发的角度出发，强调软件架构的稳定，也就是说需求、代码等的变更对软件系统的影响尽可能地小，这也是架构设计要解决的首要任务。
6 安全测试检查系统对非法侵入的防范能力。
安全测试用来验证集成在系统内的保护机制是否能够在实际中保护系统不受到非法的侵入。
7GUI测试就是对用户界面进行测试。
8可用性测试是指，让一群有代表性的用户尝试对产品进行典型操作，同时观察员和开发人员在一旁观察，聆听，做记录。
该产品可能是一个网站，软件，或者其他任何产品，它可能尚未成型。
测试可以是早期的纸上原型测试，也可以是后期成品的测试。
9软件兼容性测试（SoftwareCompatibilityTesting）是指检查软件之间是否能够正确地进行交互和共享信息。
10 Installingtesting（安装测试），确保该软件在正常情况和异常情况的不同条件下，例如，进行首次安装、升级、完整的或自定义的安装都能进行安装。
异常情况包括磁盘空间不足、缺少目录创建权限等。
核实软件在安装后可立即正常运行。
安装测试包括测试安装代码以及安装手册。
安装手册提供如何进行安装，安装代码提供安装一些程序能够运行的基础数据。
11（ConfigurationTest）
配置测试主要是针对硬件而言，其测试过程是测试目标软件在具体硬件配置情况下，出不出现问题，韦德时发现硬件配置可能出现的问题，大体来讲硬件配置分为以下几类：
一：
PC
二：
组件：
三：
外围设备
四：
接口
五：
选项和内存
六：
设备驱动
12异常测试
13备份测试
14 健壮性测试（RobustnessTesting）又称为容错性测试（FaultToleranceTesting），用于测试系统在出现故障时，是否能够自动恢复或者忽略故障继续运行。
为了使系统具有良好的健壮性，要求设计人员在做系统设计时必须周密细致，尤其要注意妥善地进行系统异常的处理。
15文档测试的英文是documentationtesting，测试关注于文档的正确性。
文档测试有三大类分别是开发文件、用户文件、管理文件。
.开发文件：
可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。
.用户文件：
用户手册、操作手册。
.管理文件：
项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。
软件测试中的文档测试主要是对相关的设计报告和用户使用说明进行测试，对于设计报告主要是测试程序与设计报告中的设计思想是否一致；对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。
文档测试涵盖面很大，在软件的各个版本中均有所使用。
随着软件版本的变化，文档测试的测试内容也有所变化。
在需求分析以及原型架构阶段，文档测试主要目标是：
Sitemap、动作分解列表、数据库ER图、UML用例图、流程图、需求文档等文档。
文档测试主要检查文档的正确性、完整性和可理解性。
正确性是指不要把软件的功能和操作写错，也不允许文档内容前后矛盾。
完整性是指文档不可以漏掉关键性内容。
可理解性是指在文档中描述的语言要简明易懂，不能让别的开发人员拿到文档时看不懂文档的内容
16网络测试主要面向的是是交换机、路由器、防火墙等网络设备，可以通过手动测试或自动化测试来验证该设备是否能够达到既定功能。
17分布测试
8测试生命周期、测试过程分为几个阶段，以及各阶段的含义？
1.测试生命周期总的来说包括测试设计阶段和测试执行阶段，其中测试设计阶段又包括系统测试设计，集成测试设计，单元测试设计，而执行阶段包括单元测试执行，集成测试执行和系统测试执行（按时间的先后来说的）；但是测试过程却分为测试计划，测试方案（设计），用例实现，和测试执行。
2.引入测试管理只要是为了更好的保证软件质量，提高测试效率。
比如缺陷跟踪等等！
3、软件静态测试是在不运行被测试软件的情况下对软件所进行的检测和评估，他的静态分析技术包括很代码走读，同行评审等！
9软件测试实施的步骤？
单元测试、集成测试、确认测试、系统测试，发版测试。
10软件测试按阶段分为？
按照开发阶段划分，软件测试可分为单元测试、集成测试，系统测试和验收测试。
11软件测试按方向分为？
测试工程师、高级测试工程师和资深测试工程师。
测试工程师一般承担以下工作：
利用测试工具按照测试方案和流程对产品进行功能和性能测试，检查产品是否有缺陷，性能是否稳定；高级测试工程师一般的职责是：
不但能够编写测试工具，而且能够设计和维护测试系统，编写测试方案，编写测试文档、编写安装和使用手册；资深测试工程师的职责要求更高：
不但能够具有初级测试工程师和高级测试工程师的能力，而且能够对测试方案可能出现的问题能够进行分析和评估。
12软件测试按方法分为？
黑盒测试和白盒测试；静态测试和动态测试；自动化测试和人工测试。
13软件测试按状态分为静态测试和动态测试？
静态测试包括？
动态测试包括？
静态测试包括代码检查、静态结构分析、代码质量度量等
构造测试实例、执行程序、分析程序的输出结果
14黑盒测试、白盒测试和灰盒测试？
黑盒测试也称功能测试，它是通过测试来检测每个功能是否都能正常使用。
在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。
黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
白盒测试也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试程序，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按预定要求正确工作。
这一方法是把测试对象看作一个打开的盒子，测试人员依据程序内部逻辑结构相关信息，设计或选择测试用例，对程序所有逻辑路径进行测试，通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。
灰盒测试，是介于白盒测试与黑盒测试之间的，可以这样理解，灰盒测试关注输出对于输入的正确性，同时也关注内部表现，但这种关注不象白盒那样详细、完整，只是通过一些表征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但内部其实已经错误了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取这样的一种灰盒的方法。
15什么是测试用例？
测试用例等级？
测试用例（TestCase）是为某个特殊目标而编制的一组测试输入、执行条件以及预期结果，以便测试某个程序路径或核实是否满足某个特定需求。
测试用例（TestCase）目前没有经典的定义。
比较通常的说法是：
指对一项特定的软件产品进行测试任务的描述，体现测试方案、方法、技术和策略。
内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试用例等级——根据需求重要性区分测试用例等级，测试执行阶段可以根据测试用例等级安排测试任务，分为四级：
• 冒烟测试，即版本确认测试，每个测试版本需通过所有该级测试用例，否则拒绝继续测试；
• 关键路径测试，每个测试版本需执行该级测试用例，若该级测试用例均通过，意味着软件功能趋于稳定；
• 可接受级测试，该级测试用例只要执行一次通过即可，该级测试用例通过意味着可以准备发布了；
• 建议执行的用例，如果有时间，最好执行该级测试用例，但不作为发布的必要条件
什么是测试用例命中率？
公式是什么？
命中率是测试出来的Bug有多少是靠测试用例发现的
命中率为Y，发现BUG量为a，通过测试用例跑出来的BUG量为b
则Y=b/a
什么是软件BUG？
缺陷生命周期？
软件BUG就是软件出错。
Bug生命周期
首先测试发现Bug并提交bug（bug状态为new/Active），然后分配bug（bug状态为assigned），开发人员接收并修改bug（bug状态为fixed/Resolved），最后测试人员验证bug（bug状态为Closed）
此时肯定有人会发现问题，这么简单的流程图是太理想化了，无法满足实际。
这是当然，Bug是可以‘死而复生’的，也许在下个版本问题有再次出现，又或许从测试人员角度讲，问题验证不通过怎么办？
从管理及开发角度想，这不是bug又怎么办。
带着这些疑问，我们进一步完善流程图。
基本可以满足一般的使用。
但是我们忽略了一点，bug是有分类的“严重程度（Severity）和优先级别（Priority）”。
在实际的应用中，很多项目的bug都比较多，而此时由于bug只在非极端条件下产生或者修改需要牵动这个框架，会造成更多的潜在缺陷，在悲观点就是面对市场压力需要尽快发布的情况等。
Bug是否被修改？
什么时候修改？
就是需要定夺的了。
又想到一点，如果此项目是多个测试人员同时测试，那是否bug会提交重复呢？
理清楚思路后，就可以在进一步完善我们的流程图啦！
缺陷等级化分？
等级 严重程度 描述
A 致命 数据丢失，数据计算错误、数据传递错误、对数据库造成破坏，造成操作系统或其他支撑系统崩溃、非正常关闭和非正常死机。
B 严重 应用系统崩溃、非正常关闭和无响应，但没有造成数据丢失。
系统的主要功能不能正确实现或不完整。
C 一般 规定的非主要功能没有实现或不完整、影响系统的运行；设计不合理造成性能低下。
D 警告 不影响业务运行的功能问题。
E 建议 从用户角度考虑在软件设计和功能实现等不完全合理之处提出建议。
什么是缺陷发现率？
怎么计算？
单元测试、集成测试、系统测试、确认测试、验收测试？
单元测试是在软件开发过程中要进行的最低级别的测试活动，在单元测试活动中，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。
单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。
因此，所有的测试都必须在整个软件系统的生命周期中进行维护。
集成测试，也叫组装测试或联合测试。
在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。
实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。
程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案。
确认测试的目的是向未来的用户表明系统能够像预定要求那样工作。
经集成测试后，已经按照设计把所有的模块组装成一个完整的软件系统，接口错误也已经基本排除了，接着就应该进一步验证软件的有效性，这就是确认测试的任务，即软件的功能和性能如同用户所合理期待的那样。
（验收测试），系统开发生命周期方法论的一个阶段，这时相关的用户和／或独立测试人员根据测试计划和结果对系统进行测试和接收。
它让系统用户决定是否接收系统。
它是一项确定产品是否能够满足合同或用户所规定需求的测试。
这是管理性和防御性控制。
Alpha测试与beta测试的区别。
Alpha测试在系统开发接近完成时对应用系统的测试；测试后仍然会有少量的设计变更。
这种测试一般由最终用户或其它人员完成，不能由程序或测试员完成。
Beta测试当开发和测试根本完成时所做的测试，最终的错误和问题需要在最终发行前找到。
这种测试一般由最终用户或其它人员完成，不能由程序员或测试员完成。
什么是CMMI？
分哪几级？
CMMI内容分为"要求"、"期望"和"提供信息"三个级别，来衡量模型包括的质量重要性和作用。
最重要的是"要求"级别，是模型和过程改进的基础。
第二级别"期望"在过程改进中起到主要作用，但是某些情况不是必须的可能不会出现在成功的组织模型中。
"提供的信息"构成了模型的主要部分，为过程改进提供了有用的指导，在许多情况下他们对需要和期望的构件做了进一步说明。
SQA？
QC？
软件质量保证（SQA）是建立一套有计划，有系统的方法，来向管理层保证拟定出的标准、步骤、实践和方法能够正确地被所有项目所采用。
软件质量保证的目的是使软件过程对于管理人员来说是可见的。
它通过对软件产品和活动进行评审和审计来验证软件是合乎标准的。
软件质量保证组在项目开始时就一起参与建立计划、标准和过程。
这些将使软件项目满足机构方针的要求。
QC即英文QUALITYCONTROL的简称，中文意义是品质控制，其在ISO8402：
1994的定义是“为达到品质要求所采取的作业技术和活动”。
有些推行ISO9000的组织会设置这样一个部门或岗位，负责ISO9000标准所要求的有关品质控制的职能，担任这类工作的人员就叫做QC人员，相当于一般企业中的产品检验员，包括进货检验员（IQC）、制程检验员（IPQC）和最终检验员（FQC）
阶段评审？
同行评审？
有什么不同？
阶段评审可以对某个开发阶段的阶段产品进行评审，也可以对某几个开发阶段的阶段产品进行综合评审。
在每次阶段评审中，必须履行正式手续，填写必要的评审表格，以利于项目管理工作，利于产品验收时的质量检查工作。
同行评审的程序主要针对的是让作者的著作使之符合一般的科学与学科领域的标准。
在许多领域著作的出版或者研究奖金的颁发，如果没有以同行评审的方式来进行就可能比较会遭人物议。
性能测试、压力测试、负载测试、强度测试、大数据量测试、疲劳测试、强度疲劳测试？
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。
负载测试和压力测试都属于性能测试，两者可以结合进行。
通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。
压力测试是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
在软件工程中，压力测试是对系统不断施加压力的测试，是通过确定一个系统的瓶颈或者不能接收的性能点，来获得系统能提供的最大服务级别的测试。
例如测试一个Web站点在大量的负荷下，何时系统的响应会退化或失败。
现在的网络游戏中也常用到这个词汇。
Loadtesting（负载测试），通过测试系统在资源超负荷情况下的表现，以发现设计上的错误或验证系统的负载能力。
在这种测试中，将使测试对象承担不同的工作量，以评测和评估测试对象在不同工作量条件下的性能行为，以及持续正常运行的能力。
负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。
此外，负载测试还要评估性能特征，例如，响应时间、事务处理速率和其他与时间相关的方面。
强度测试：
强度测试检查程序对异常情况的抵抗能力；是检查系统在极限状态下运行的时候性能下降的幅度是否在允许的范围内。
强度测试总是迫使系统在异常的资源配置下运行。
例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
编辑本段
强度测试意义：
强度测试是一种特别重要的测试，对系统的稳定性，以及系统未来的扩展空间均具有重要的意义。
在这种异常条件进行的测试，更容易发现系统是否稳定以及性能是否容易扩展。
疲劳强度测试是一类特殊的强度测试，主要测试系统长时间运行后的性能表现，例如7x24小时的压力测试。
大数据量测试可以分为两种类型：
针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。
大数据量测试的关键是测试数据的准备，可以依靠工具准备测试数据。
疲劳测试时采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间业务，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
疲劳强度测试可以采用工具自动化的方式进行测试，也可以手工编写程序测试，其中后者占得比例较大。
一般情况下以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试，获取交易执行指标数据和系统资源监控数据。
如出现错误导致测试不能成功执行，则及时调整测试指标，例如降低用户数、缩短测试周期等。
还有一种情况的疲劳测试时对当前系统性能的评估，用系统正常业务情况下并发用户数为基础，进行一定时间的疲劳测试。
并发用户？
吞吐率？
TPS？
点击率？
•并发用户即所有的用户在同一时刻做同一件事情或者操作，这种操作一般指做同一类型的业务。
另外一种并发是广义范围的并发。
这种并发与前一种并发的区别是，尽管多个用户对系统发出了请求或者进行了操作，但是这些请求或者操作可以是相同的，也可以是不同的。
•吞吐量是指单位时间内系统处理的客户请求的数量，直接体现软件系统的性能承载能力。
一般来说，吞吐量用请求数/秒或页面数/秒来衡量，从业务的角度，吞吐量也可以用访问人数/天或处理的业务数/小时等单位来衡量。
从网络的角度来说，也可以用字节数/天等单位来考察网络流量。
TPS每秒钟系统能够处理的交易或事务的数量。
它是衡量系统处理能力的重要指标。
TPS是LoadRunner中重要的性能参数指标。
改善：
是指从现有的设备、材料、劳动力及产品的制造方法里发现浪费，运用现场的智慧来消除浪费。
现场的改善一般式指作业的改善。
•点击率:
HPS，每秒钟用户向WEB服务器提交的HTTP请求数。
WEB应用是“请求-响应”模式,用户发出一次申请,服务器就要处理一次,所以点击是WEB应用能够处理的交易的最小单位。
需要注意的是,这里的点击并非指鼠标的一次单击操作,因为在一次单击操作中,客户端可能向服务器发出多个HTTP请求。
性能测试工具有哪些？
Loadrunner
webload
RPT
性能测试用户并发数怎么计算？
性能计算公式？
并发用户数量的统计方法目前还没有准确的公式
一般的并发用户数量的经验公式为：
使用系统的用户数量×（5％～20％）。
对于这个公式，没有必要拘泥于计算出的结果，因为为了保证系统的扩展空间，测试时的并发用户数量都会稍稍大一些，除非要测试系统能承受的最大并发用户数量。
举例说明：
你的系统支持10000个用户访问，
在基本压测情况下，你在设置最大并发用户数量时最多10000*0.2=2000就可以了。
测试计划怎么写？
测试方案有什么内容？
测试用例包括什么？
测试用例组成元素
（1）用例ID；
（2）用例名称；
（3）
升级会员 