搜索
第一章软件测试流程与规范目录•软件测试理论•软件测试模型•软件测试计划•软件测试环境•软件测试方法•软件测试阶段•软件测试用例•软件配置管理•软件缺陷管理•软件文档管理软件测试理论-基本概念•软件系统的重要性视频：新闻报道(软件缺陷引起的生产事故）软件测试理论-基本概念•引起软件缺陷的原因ErrorMistakeDefectFaultBugFailure）人类历史上第一个程序BUG软件测试理论-基本概念•测试目的–检查产品需求是否全部实现–检查产品完整性（包括相关的组件）–确保软件产品在发布前软件缺陷均定位并解决–一个成功的测试是发现了至今尚未发现的错误找错测试目标：发现缺陷；增加对质量的信心；为决策提供信息；预防缺陷。软件测试理论-基本概念•软件测试的定义–软件测试是为发现缺陷而执行程序的一组过程。–软件测试，通常是按软件需求规格说明和程序的内部结果而精心设计一组测试用例，并依据测试用例执行测试并发现错误。软件测试理论-基本概念•质量的定义–软件质量是软件特性的总和，软件满足规定或潜大的用户需求。–软件产品质量是所生产的软件产品的质量，包括软件系统以及组成它们的所有元素。–过程质量是指为保证产品质量而采用的实现过程（包括措施和标准）的质量。软件测试理论-基本概念•软件测试的类型–按开发阶段划分–按测试实施的组织划分–按测试技术划分软件测试理论-基本概念•测试与调试的区别–测试：找错–调试：排错（定位、修改）瀑布模型需求分析需求评审概要设计概要设计评审详细设计编码走查单元测试集成测试系统测试测试计划用例设计测试流程测试评审各子模块省略迭代开发与测试软件测试模型•V模型客户需求需求分析概要设计详细设计编码单元测试集成测试系统测试验收测试软件测试模型•V模型–特点：V模型是瀑布模型的延伸，其开发各阶段结构清晰，软件开发与测试分离–作用：早期的软件开发模型，能够明确软件开发的各个阶段，适用于小型软件项目的开发。–局限：测试在编码后，软件缺陷发现的较晚，修复成本较高。软件测试模型•W模型客户需求需求分析概要设计详细设计编码单元测试集成测试系统测试验收测试验收测试设计系统测试设计集成测试设计单元测试设计集成实施交付软件测试模型•W模型–特点：W模型是V模型的延伸，加强了V模型中各个阶段的测试，并将开发与测试同步。–作用：针对各个阶段进行监控，能够较早的发现软件中的缺陷。–局限：同V模型一样，仍将需求至编码阶段作为串行实施，前后依赖较强，不利于变更。软件测试模型•H模型测试准备测试就绪点测试执行其他流程测试流程软件测试模型•H模型–特点：较早发现软件中的缺陷，能够适应软件项目的动态变更。–作用：将软件测试过程贯穿于整个项目周期，各阶段测试按层次进行，并且测试过程可循环实施。–局限：前期投入较大，各阶段交互时间较长，变更频繁也对软件产品质量构成威胁。软件测试模型•X模型软件测试模型•X模型–特点：该模型左半部分是针对程序片段进行相互分离后进行频繁的交接，最后合成可执行程序；右半部分即对生成的可执行程序进行测试，同时有针对性进行各种测试。–作用：能够节约时间，较早发现软件产品的缺陷–局限：前期的拆分过多，对测试人员要求较高，实施较难。计划•什么是计划？第一：应当具有明确的目标；第二：计划工作必须先于其它各项管理活动而展开；第三：计划必须是准备付诸实施、切实可行的方案，不允许任何为了计划而计划的活动；第四：计划必须有益于在总体上提高管理的效益，虽然制定计划所造成的消耗也属于组织活动的成本，但这种消耗必须获得高额的回报。计划•计划的特征–计划应具有明确性–计划必须具有全面性–计划必须具有协调性–计划必须具有弹性–计划必须具有功利性计划的目的是用来识别任务、分析风险、规划资源和确定进度软件测试计划•测试计划的目的–使软件测试工作进行更顺利–促进项目参加人员彼此的沟通–使软件测试工作更易于管理任何测试计划都是保证软件质量，提高工作效率。软件测试计划•测试计划的原则–制定测试计划应尽早开始–保持测试计划的灵活性–保持测试计划简洁和易读–尽量争取多渠道评审测试计划–计算测试计划的投入软件测试计划•《测试计划》文档应该包括如下内容–目标–概述、术语–组织形式–角色及职责–测试对象–测试通过/失败的标准–测试挂起的标准及恢复的必要条件–测试任务安排–应交付的测试工作产品–工作量估计软件测试计划-1•目标–表示该测试计划所应该达到的目标•概述–项目背景：如项目的主要功能特征，体系结构，简要历史等–范围：指明该计划的使用对象，范围–术语：项目中的特定名称•组织形式–表示测试计划执行过程中的组织结构及之间的关系，以及所需要的组织的独立程度。–同时指出测试过程与其他过程（开发，管理，…）之间的关系。–还包括沟通渠道等软件测试计划-2•角色与职责定义角色及其职责，在每个角色与测试任务之间建立关联。•测试对象列出所有将被作为测试目标的测试项（功能需求，非功能需求…)软件测试计划-3•测试通过/失败的标准指明了判断/确认测试何时结束，以及所测试的应用程序的质量。可以直接陈述，也可以引用其他的文档。至少应该说明：•什么将被测试？•度量尺度是如何建立的?•使用了哪些标准对度量进行评价?•测试挂起的标准以及恢复的必要条件指明挂起全部或部分测试项的标准,并指明恢复测试的标准及其必须重复的测试活动。软件测试计划-4•测试任务安排明确测试任务。对于每个任务说明：•各阶段任务•方法和标准•输入/输出•时间安排•资源•风险和假设•角色和职责软件测试计划-5•应交付的测试工作产品指明应该交付的文档，测试代码及测试工具，一般包括测试计划，测试方案，测试用例，测试规程，测试日志，测试事故报告，测试总结报告，测试输入以及测试输出，测试工具。•工作量估计给出前面定义任务的人力需求及总计。测试计划的变更软件测试环境•软件测试环境组成软件测试环境硬件环境网络环境软件环境软件测试环境•硬件环境–服务器、客户端、网络设备、硬盘、CPU、内存以及打印机、扫描仪等辅助硬件设备所构成的环境–硬件环境的最低配置软件测试环境•软件环境–操作系统–数据库–软件开发平台–浏览器–应用软件–杀毒软件–………软件测试环境•网络环境–网络设备–网络结构–网络系统软件测试环境•配置测试环境主要遵循以下原则：–被测试软件运行的是低配置要求，即测试环境首先要保证支撑软件正常运行；–测试环境应量简单、独立，避免不相关的软件影响测试的实施；–软件版本保持最新，同时避免安装多个版本；–保证测试平台没有病毒；–保证环境前后一致；–兼容性检查等软件测试环境•通用测试环境的要求–尽可能真实的环境–符合软件运行的最低要求–选用比较普及的操作系统和软件平台–营造纯净、独立的测试环境–无毒的环境软件测试环境•测试环境与测试阶段的关系测试环境的真实性测试环境的完整性软件测试环境影响软件测试环境的因素因素测试级别UnitIntegrationSystemAcceptance测试者DevelopersDevelopers&TestersTestersTesters&Users硬件平台Programmers'WorkbenchProgrammers'WorkbenchSystemTestMachineorRegionMirrorofProduction操作系统中的共存软件NoneNoneNone/ActualActual接口NoneInternalSimulated&RealProduction测试数据来源ManuallyCreatedManuallyCreatedProduction&ManuallyCreatedProduction测试数据量SmallSmallLargeLarge策略UnitGroupsofUnits/BuildsEntireSystemSimulatedProduction软件测试环境•测试环境的备份–测试过程中会遇到多种不可预测的事情发生，一但造成系统崩溃，则会造成测试数据丢失、测试过程中断或者测试环境的重新搭建–经常对测试环境进行多次必要的备份是一个必备的预防措施和一个比较好的习惯–对测试环境的备份可以挽回不必要的损失、节省测试的时间、保持测试的连续性软件测试环境•测试环境的恢复–一旦测试环境遭到破坏，可以还原最近备份的系统，实现测试环境的恢复–目的•维持测试环境的一致性•恢复测试数据•恢复测试环境的当前状态软件测试环境•测试环境备份和恢复工具–Ghost–Partimage–还原精灵等软件测试环境•测试环境对结果的影响–测试数据信息不准确–软件测试不充分–软件运行速度–软件的兼容性–………软件测试方法•白盒测试方法•灰盒测试方法•黑盒测试方法软件测试方法•什么是白盒测试（white-boxtesting）–白盒测试是依据被测试软件，分析程序内部构造，并根据内部构造设计用例后进行测试。软件测试方法•白盒测试一般会用到静态分析和动态分析两类技术，常用的有：–静态分析：控制流分析，数据流分析，信息流分析等–动态分析：逻辑覆盖测试（分支测试，路径测试等），程序插装．测试用例设计方法•白盒测试用例设计方法–语句覆盖–判定覆盖–条件覆盖–判定/条件覆盖–组合覆盖–路径覆盖白盒测试用例设计方法•语句覆盖–指设计若干个测试用例，运行被测程序，使得每一可执行语句至少执行一次。这种覆盖又称为点覆盖，它使得程序中每个可执行语句都得到执行，但它是最弱的逻辑覆盖准，效果有限，必须与其它方法交互使用语句覆盖示例例:IFCONDITIONTHENDO_SOMETHING;ELSEDO_SOMETHING_ELSE;ENDIF;语句覆盖优缺点•优点：–可以很直观地从源代码得到测试用例，无须细分每条判定表达式•缺点：–由于这种测试方法仅仅针对程序逻辑中显式存在的语句，但对于隐藏的条件和可能到达的隐式逻辑分支，是无法测试的白盒测试用例设计方法•判定覆盖–指设计若干个测试用例，运行被测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖判定覆盖示例例:IFCONDITIONTHENDO_SOMETHING;ELSEDO_SOMETHING_ELSE;ENDIF;TEST:CONDITION1TRUE2FALSE判定覆盖优缺点•优点：–判定覆盖比语句覆盖要多几乎一倍的测试路径，当然也就具有比语句覆盖更强的测试能力。同样判定覆盖也具有和语句覆盖一样的简单性，无须细分每个判定就可以得到测试用例•缺点：–大部分的判定语句是由多个逻辑条件组合而成（如，判定语句中包含AND、OR、CASE），若仅仅判断其整个最终结果，而忽略每个条件的取值情况，必然会遗漏部分测试路径。白盒测试用例设计方法•条件覆盖–指设计若干个测试用例，运行被测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖示例例:IF(A1)AND(B=0)THENX=X/A①IF(A=2)OR(X1)THENX=X+1②条件①中判定条件②中判定A1，为真时，记：T1A=1，为假时，记：F1B=0，为真时，记：T2B不等于0，为假时，记：F2A=2，为真时，记：T3A不等于2，为假时，记：F3X1，为真时，记：T4X=1，为假时，记：F4•满足覆盖条件的测试例测试用例ABX覆盖条件Case1103F1、T2、F3、T4Case2211T1、F2、T3、F4条件覆盖优缺点•优点：–条件覆盖比判定覆盖，增加了对符合判定情况的测试，增加了测试路径•缺点：–要达到条件覆盖，需要足够多的测试用例，但条件覆盖并不能保证判定覆盖。条件覆盖只能保证每个条件至少有一次为真，而不考虑所有的判定结果白盒测试用例设计方法•判定-条件覆盖–指设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断本身的所有可能判断结果至少执行一次。示例X、Y取值如下表TestCaseXY覆盖路径case19090OAEcase25050OBDEcase39070OBCEcase47090OBCE判定-条件覆盖优缺点•优点：–判定/条件覆盖满足判定覆盖准则和条件