1、软件测试基本概念目 录 软件缺陷1 1 软件测试的分类2 2 静态测试与动态测试3 3 主动测试与被动测试4 4 黑盒测试与白盒测试5 5 软件测试级别6 6 软件测试计划与用例7 7 专业测试人员的责任和要求8 81软件缺陷缺陷是质量的对立面要了解什么是缺陷(Defect)，就必须清楚“质量(Quality)”概念，因为缺陷是相对质量而存在的，违背了质量、违背了客户的意愿，不能满足客户的要求，就会引起缺陷或产生缺陷1.软件质量的内涵质量的定义质量管理专家朱兰对“质量”的定义：满足使用要求的基础是质量的特征，产品的任何特征（性质、属性等）、材料或满足使用要求的过程都是质量特征。1986年ISO
2、8492给出了质量的定义：质量是产品或服务所满足明示或暗示需求能力的固有特性和特征的集合。固有特性：某事物中本来就有的，尤其是那种永久性的特性明示的特性：理解为规定的要求，用于描述或者客户明确提出的那些要求暗示的特性：是由社会习俗约定、行为惯例所要求的一种潜规则、不言而喻的。1.软件质量的内涵IEEESTD729：软件产品满足规定的和隐含的与需求能力有关的全部特征和特性。主要包括：软件产品满足使用要求的程度软件各种属性的组合程度用户对软件产品的综合反映程度软件在使用过程中满足用户要求的程度1.软件质量的内涵高质量软件标准体系（1）软件产品的质量是人们实践产物的属性和行为，是可以认识，可以科学地
3、描述的。并且可以通过一些方法和人类活动，来改进质量（2）软件开发过程中的质量是指过程满足明确和隐含需要的能力的特性之总和（3）应用领域或者业务上的质量在商业过程中有关的质量内容:培训、成品制作、宣传、发布日起、客户、风险、成本、业务等 1.软件质量的内涵产品质量的标准功能性 Functionality可用性 Usability可靠性 Reliability 性能 Performance容量 Capacity可伸缩性 Scalability可维护性 Service manageability兼容性 Compatibility可扩展性 Extensibility1.软件质量的内涵软件质量模型Boe
4、hm质量模型McCall质量模型ISO质量模型1.软件质量的内涵阐述性阐述性数据公开性数据公开性连贯性连贯性容错性容错性执行效率执行效率/储存效率储存效率存取控制存取控制/存取检查存取检查可训练可训练沟通良好沟通良好 简单性简单性易操作的易操作的工具工具自我操作性自我操作性扩展性扩展性一般性一般性模块性模块性软件系统独立性软件系统独立性机器独立性机器独立性通讯公开性通讯公开性正确性正确性可操作性可操作性产品产品操作操作产品产品修改修改产品产品维护维护 Boehm软件质量模型1.软件质量的内涵 McCall软件质量模型1.软件质量的内涵功能性可靠性可用性效率可移植性可维护性匹配性精确性互用性安全
5、性成熟性容错能力可恢复性可理解性可学习性可操作性时间表现资源表现可分析性可变化性稳定性适应性可测试性易安装性一致性可替换性用户自定义软件产品度量标准 ISO 9126三层模型1.软件质量的内涵 内部质量、外部质量和使用质量的关系1.软件质量的内涵软件质量特征(ISO9126)功能：与一组功能及其指定性质有关的一组属性，这里的功能是满足明确或隐含的需求的那些功能。可靠：在规定的一段时间和条件下，与软件维持其性能水平的能力有关的一组属性。易用：由一组规定或潜在的用户为使用软件所需作的努力和所作的评价有关的一组属性。效率：与在规定条件下软件的性能水平与所使用资源量之间关系有关的一组属性。可维护：与进
6、行指定的修改所需的努力有关的一组属性。可移植：与软件从一个环境转移到另一个环境的能力有关的一组属性。其中每一个质量特征都分别与若干子特征相对应。1.软件质量的内涵ISQ/IEC 9126-1:2001信息技术-产品质量的第一部分质量模型ISO/IEC TR 9126-2:2003IT-产品质量的第二部分外部质量ISO/IEC TR 9126-3:2003IT-产品质量的第三部分内部质量ISO/IEC TR 9126-3:2003IT-产品质量的第四部分使用质量ISO/IEC 14598-1:1999IT-软件产品评估-第一部分：综述ISO/IEC 14598-2:2000IT-产品评估-第二部
7、分：计划和管理ISO/IEC 14598-3:2000IT-产品评估-第三部分：开发者过程ISO/IEC 14598-4:1999IT-产品评估-第四部分：购买方过程ISO/IEC 14598-5:1998IT-软件产品评估-第五部分：评估方过程ISO/IEC 14598-6:2001IT-产品评估-第六部分：评估模型文档 ISO 9126(GB/T 16260)信息技术 软件产品质量 软件质量评价方法1.软件质量的内涵 ISO软件质量模型1.软件质量的内涵 ISO软件质量模型2.缺陷 Defect,Bug缺点（defect）谬误（fault）失败（failure）矛盾（inconsisten
8、cy）毛病（incident）偏差（variance）问题（problem）错误（error）异常（anomy）2.缺陷 Defect,Bug软件错误(error)在软件生存期内的不希望或者不可接受的人为错误。软件缺陷(defect)任何程序、系统中的问题，和产品设计说明书的不一致性，不能满足用户的需求。软件故障(fault)软件运行过程中出现的一种不希望或不可接受的内部状态。此时，如果没有适当的处理措施的话，软件故障就会导致软件失效。软件失效(failure)软件运行时产生的一种不希望或不可接受的外部行为结果。比如死机就是一种严重的软件失效。软件失效是软件用户所能直接感受到的。当软件出现失效
9、时，必然说明软件中存在缺陷。2.缺陷 Defect,BugIEEE(1983)729 软件缺陷一个标准的定义：从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题；从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。2.缺陷 Defect,Bug软件缺陷的表现：功能、特性没有实现或部分实现设计不合理，存在缺陷实际结果和预期结果不一致运行出错，包括运行中断、系统崩溃、界面混乱数据结果不正确、精度不够用户不能接受的其他问题，如存取时间过长、界面不美观 2.缺陷 Defect,Bug软件缺陷被引入的时间开发阶段规格说明书设计环节编码修复缺陷时也可能产生新的缺陷修改代码后
10、一定要进行回归测试！2.缺陷 Defect,Bug软件缺陷的产生的主要因素技术问题开发人员开发经验不足对采用的新技术不熟悉程序模块复杂度高接口参数多其他2.缺陷 Defect,Bug软件本身不合理的软件开发流程文档错误没有考虑软件实际使用场景，导致出现负载问题对程序的逻辑路径或数据范围的边界考虑不周全与硬件、第三方系统软件之间存在接口或依赖性其他2.缺陷 Defect,Bug团队工作对软件质量问题不重视对客户需求未调研清楚或存在误解不同阶段开发人员理解不一致其他2.缺陷 Defect,Bug2.缺陷 Defect,Bug软件缺陷的构成规格说明书是缺陷最容易出现的地方开发人员与用户的沟通问题软件
11、产品还没有设计、开发，完全靠想象描述系统的实现结果，有些特性还不够清晰需求的频繁变动，造成不一致性对规格说明书不够重视，在设计和写作上投入的人力、时间不足沟通不充分，只有设计师或项目经理知道的信息较多2.缺陷 Defect,BugRayleigh缺陷模型在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。规格说明书的缺陷会在需求分析审查、设计、编码、测试等过程中会逐步发现，而不能在需求分析一个阶段发现2.缺陷 Defect,Bug需求设计编码测试发布 时间 缺陷数早期缺陷发现（70%-90%）测试前在真正的程序测试之前，通过审查、评审会可以发现更多的缺陷。软件缺陷在不同阶段的分布2.缺陷
12、 Defect,Bug修复软件缺陷的代价缺陷的代价是非常高昂的一项统计数据表明，大约62%的项目成本用于修复软件缺陷。据美国NIST在2002年发布的一项研究估计，美国经济每年因软件Bug会损失600亿美金，约合0.6%的国民生产总值2.缺陷 Defect,BugBoehm在其著作软件工程经济学中提到如果需求阶段纠正一个错误的代价是1设计阶段是它的36倍编程阶段是它的10倍内部测试阶段是它的2040倍外部测试阶段是它的3070倍产品发布时，这个数字是401000倍代价不是呈线性增长，而是呈指数级增长2.缺陷 Defect,Bug缺陷成本2.缺陷 Defect,Bug缺陷的生命周期软件缺陷从被测
13、试人员发现一直到被修复，要经历一个特有的生命周期，阶段包括：新建、打开、拒绝、修复、关闭、重新打开等。2.缺陷 Defect,Bug2.缺陷 Defect,Bug从上述讨论可知，软件缺陷不仅存在于可执行程序中，而且存在于需求定义和设计的文档中，所以软件测试不仅仅是“为了发现错误而执行程序的过程”，而且还包括对产品规格说明书、技术设计文档等的测试。软件测试贯穿于整个软件开发过程，是软件验证和用户需求确认的统一，和软件评审密不可分。2软件测试的分类1.软件测试的分类方法方法目标目标/特性特性单元测试单元测试系统测试系统测试验收测试验收测试性能测试性能测试强壮性测试强壮性测试功能测试功能测试白盒测试
14、白盒测试黑盒测试黑盒测试测试阶段或层次测试阶段或层次适用性测试适用性测试可靠性测试可靠性测试集成测试集成测试安全性测试安全性测试1.软件测试的分类软件执行的角度软件执行的角度测试阶段的角度测试阶段的角度测试方法的角度测试方法的角度静态测试白盒测试动态测试单元测试黑盒测试集成测试系统测试验收测试回归测试灰盒测试1.软件测试的分类测试阶段的角度测试阶段的角度单元测试集成测试系统测试验收测试回归测试功能测试性能测试随机测试1.软件测试的分类测试方法的角度测试方法的角度白盒测试黑盒测试灰盒测试逻辑驱动基路测试等价类划分边界值分析因果图错误推测1.软件测试的分类测试过程3静态测试和动态测试 1.静态测试
15、和动态测试静态测试包括对软件产品的需求和设计规格说明书的评审、对程序代码的复审等动态测试是通过真正运行程序发现错误，通过观察代码运行过程，来获取系统信息，对系统行为进行验证。1.静态测试和动态测试静态测试的方法：产品评审静态分析评审的形式/方法互为评审(Peer review)轮查(Pass-round)走查(walk-through)会议评审(Inspection)2.产品评审最不正式的最正式的临时评审轮查 走查互为评审同行评审 评审评审对象管理评审技术评审文档评审流程评审 2.产品评审软件测试评审对象需求评审设计评审代码评审文档评审需求和设计审查测试人员参与产品需求分析和系统设计，认真阅读
16、有关文档，真正理解客户的需求和技术上的设计，检查需求说明书对产品描述的准确性、一致性等，检查系统设计的合理性和可测试性等 2.产品评审静态分析的查错和分析功能是其他方法所不能替代的，可以采用人工检测和计算机辅助静态分析手段进行检测，但越来越多地采用工具进行自动化分析人工检测：人工检测偏重于编码风格、质量的检验，对设计、代码进行分析，有效地发现逻辑设计和编码错误。计算机辅助静态分析：利用静态分析工具对被测程序进行特性分析，从程序中提取一些信息，以便检查程序逻辑的各种缺陷和可疑的程序构造。3.静态分析为了把握各个环节的正确性，人们需要进行各种验证和确认工作。验证（verification）是保证软
17、件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标确认（validation）是保证软件满足用户需求的一系列的话动和过程，目的是开发完成后保证软件与用户需求相符合。4.验证和确认4主动测试和被动测试主动测试方法：测试人员主动向被测试对象发送请求、或借助数据、事件驱动被测试对象的行为，从而验证被测试对象的反应或输出结果被动测试方法：测试人员不干预产品的运行，而是被动地监控产品在实际环境中运行，通过一定的被动机制来获得系统运行的数据，包括输入、输出数据1.主动测试和被动测试5黑盒测试方法和白盒测试白盒测试通过对程序内部结构的分析、检测来寻找问
18、题。白盒测试可以把程序看成装在一个透明的盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件内部动作是否按照设计说明的规定正常进行。白盒测试又称结构测试。黑盒测试通过软件外部表现来发现其缺陷和错误。黑盒测试法把测试对象看成一个黑盒子，完全不考虑程序内部结构和处理过程。黑盒测试是在程序界面处进行测试，它只是检查样序是否按照需求说明书的规定正常实现。1.黑盒测试方法和白盒测试1.黑盒测试方法和白盒测试功能测试功能测试数据驱动测试数据驱动测试 结构测试结构测试逻辑驱动测试逻辑驱动测试 客户需求事件驱动输入输出6软件测试级别测试级别的划分单元测试集成测试验收(确认)测
19、试系统测试1.软件测试级别1.软件测试级别SRDCUTITSVTST系统工程单元测试编码软件需求分析设计集成测试验收测试系统测试2.不同测试级别的任务调试组件功能健壮性效率组件之间的接口系统功能 安全性 健壮性效率 功能及用户界面安全性 效率用户的可接受性组件测试集成测试系统测试实现（编码）验收测试测试阶段和测试重点：理想状态单元测试的对象是程序系统中的最小单元-模块或组件上，在编码阶段进行，针对每个模块进行测试，主要通过白盒测试方法，从程序的内部结构出发设计测试用例，检查程序模块或组件的已实现的功能与定义的功能是否一致、以及编码中是否存在错误。多个模块可以平行地、独立地测试，通常要编写驱动模
20、块和桩模块单元测试一般由编程人员和测试人员共同完成，而以开发人员为主单元测试包括代码评审，代码评审可以发现程序50%70%代码的缺陷。3.单元测试集成测试，也称组装测试、联合测试、子系统测试，在单元测试的基础上，将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的模块之间问题 两种集成方式：一次性集成方式和增殖式集成方式。一次性集成方式：首先对每个单元分别进行测试，然后再把所有单元组装在一起进行测试，最终达到要求的软件系统渐增式集成方式：首先对某两三个单元进行测试，然后在把剩下的单元逐步添加组装成较大的系统，一边测试，一边集成，最后构造一个完整的软件系统。4.集成测试系统非功能性
21、测试是将软件放在整个计算机环境下，包括软硬件平台、某些支持软件、数据和人员等，在实际运行环境下进行一系列的测试，包括恢复测试、安全测试、强度测试和性能测试等系统功能测试一般须在完成集成测试后进行，而且是针对应用系统进行测试。功能测试是基于产品功能说明书，是在已知产品所应具有的功能，从用户角度来进行功能验证，以确认每个功能是否都能正常使用 5.系统测试验收测试的目的是向未来的用户表明系统能够像预定要求那样工作，验证软件的功能和性能如同用户所合理期待的那样测试一种先期的用户测试，此时系统刚刚开发完成。测试一种后期的用户测试，此时系统已经通过内部测试，大部分错误已经改正，即将正式发行。安装测试是指按
22、照软件产品安装手册或相应的文档，在一个和用户使用该产品完全一样的环境中或相当于用户使用环境中，进行一步一步的安装操作性的测试 6.验收测试&安装测试7软件测试计划与用例软件测试工作的组织与管理：制定测试策略、测试计划，确认所采用的测试方法与规范，控制测试进度，管理测试资源。测试工作的实施：编制符合标准的测试文档，搭建测试环境，开发测试脚本、与开发组织协作实现各阶段的测试活动 1.软件测试的工作范畴2.测试工作流程主要有6个方面：（1）测试组织和管理（2）测试计划（3）测试用例设计（4）测试实施（5）测试结果分析（6）测试评审与报告测试计划的定义软件测试是一个有组织有计划的活动，应当对时间和资源
23、制订测试计划，才能在合理的控制下正常进行。测试计划作为测试的起始步骤，是整个软件测试过程的关键。测试计划规定了测试各个阶段所要使用的方法策略、测试环境、测试通过或失败的准则等内容。ANSI/IEEE软件测试文档标准829-1983将测试计划定义为：“一个叙述了预定的测试活动的范围、途径、资源及进度安排的文档。它确认了测试项、被测特征、测试任务、人员安排，以及任何偶发事件的风险。”3.软件测试计划测试计划的目的和作用测试计划的目的是明确测试活动的意图，规范软件测试内容、方法和过程，为有组织地完成测试任务提供保障。尽管测试的每一个步骤都是独立的，但是必须要有一个起到框架结构作用的测试计划。软件测试
24、计划是整个测试过程中最重要的部分，为实现可管理且高质量的测试过程提供基础。3.软件测试计划测试计划书测试计划文档化即是测试计划书，分为总体计划和分级计划，是可以更新改进的文档。测试计划书描述了软件测试预计达到的目标，确定测试过程所要采用的方法策略。从文档的角度看，测试计划书是最重要的测试文档。3.软件测试计划测试计划的内容测试计划包括测试目的、测试范围、测试对象、测试策略、测试任务、测试用例、资源配置、测试结果分析和度量以及测试风险评估等，测试计划应当足够完整但也不应当太详尽。实际的测试计划内容因不同的测试对象而灵活变化。3.软件测试计划测试用例定义所谓的测试用例就是将软件测试的行为活动，做一
25、个科学化的组织归纳。软件测试是有组织性、步骤性和计划性的，而设计软件测试用例的目的，就是为了能将软件测试的行为转换为可管理的模式。软件测试是软件质量管理中最实际的行动，同时也是耗时最多的一项。基于时间因素的考虑，软件测试行为必须能够加以量化，才能进一步让管理阶层掌握所需要的测试过程，而测试用例就是将测试行为具体量化的方法之一。4.测试用例测试用例要素所属模块：按照不同的模块进行测试，为测试用例分组；编号ID：测试用例的唯一性标志；用例描述：简单的语言描述所测试的内容，例如“设置广播服务器网络参数，并测试网络连通性”；重要级别：高、中、低三级；、预置条件：就是执行当前测试用例的前提描述，如果不满
26、足这些条件，则无法进行测试；测试输入：测试用例执行时，需要输入的外部信息。例如：某一个文件，数据记录等；4.测试用例操作步骤：执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行预期结果：当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。测试结果：Pass、Fail、Block4.测试用例良好测试用例的特征1.完整的2.准确3.清晰、简洁4.可维护性5.适当性6.可复用性7.其他4.测试用例测试用例设计方法4.测试用例逻辑覆盖法基本路径测试法8专业测试人员的责任与要求QA/测试经理：人员管
27、理，资源调配、测试方法改进等；实验室管理人员：设置、配置和维护实验室的测试环境内审员：审查流程，建立测试模板，跟踪缺陷测试报告的质量等；测试组长：负责项目的管理、测试计划、测试用例、任务安排等；测试设计人员/资深测试工程师，产品设计规格说明书的审查、测试用例的设计、技术难题的解决、培训和指导、实际测试任务的执行；一般（初级）测试工程师，执行测试用例和相关的测试任务。1.专业测试人员的责任与要求产品编译必须在此之前完成每日凌晨3时，测试编译自动开始如果测试编译成功，BVT测试自动开始测试工程师每早来上班，先检查Test Build与BVT结果的email如果有BVT错误，在第一时间里分析原因，隔
28、离错误代码并汇报Pri 0 Bug(0级缺陷)开发团队对于Pri 0 Bug应当于当日之内修改完毕测试工程师接着用Product Studio检查Bug情况，验证分配给自己的Bug已修改合格。2.一个微软测试工程师的一天关闭Bug并增加针对此Bug的Regression Test验证最近的Lab Run结果如果其中有新的错误，隔离并汇报新Bug开发新的测试Spec与新的测试代码使用个人Private Run来验证新开发的测试程序使用个人Private Run来验证开发伙伴新开发的产品程序没有重大错误改进与提高自动化测试系统的功能参与Spec,Test Spec Review会议，做测试同伴测试代码Review,UE帮助文件Review,回答内外Newsgroup的问题2.一个微软测试工程师的一天技术，编程能力责任感、耐力沟通能力、理解能力分析问题能力（批判性思维）项目管理能力组织能力3.对测试人员的要求高度的责任感非常好的沟通能力、幽默感技术能力、自信心、耐心怀疑一切的精神、勤奋精神洞察力、适度的好奇心反向思维和发散思维能力、记忆力自我学习能力、创新能力等4.优秀测试工程师的素质感谢观看THANKS
