软件测试.ppt

软件测试北京中科江南软件有限公司目录CH1概述CH2软件测试基础CH3软件测试技术CH4软件测试工具CH1概述信息技术的飞速发展，使软件产品应用到社会的各个领域，软件产品的质量自然成为人们共同关注的焦点。不论软件的生产者还是软件的使用者，均生存在竞争的环境中，软件开发商为了占有市场，必须把产品质量作为企业的重要目标之一，以免在激烈的竞争中被淘汰出局。用户为了保证自己业务的顺利完成，当然希望选用优质的软件。质量不佳的软件产品不仅会使开发商的维护费用和用户的使用成本大幅增加，还可能产生其他的责任风险，造成公司信誉下降，继而冲击股票市场。在一些关键应用(如民航订票系统、银行结算系统、证券交易系统、自动飞行控制软件、军事防御和核电站安全控制系统等)中使用质量有问题的软件，还可能造成灾难性的后果。CH1概述软件危机曾经是软件界甚至整个计算机界最热门的话题。为了解决这场危机，软件从业人员、专家和学者做出了大量的努力。现在人们已经逐步认识到所谓的软件危机实际上仅是一种状况，那就是软件中有错误，正是这些错误导致了软件开发在成本、进度和质量上的失控。有错是软件的属性，而且是无法改变的，因为软件是由人来完成的，所有由人做的工作都不会是完美无缺的。问题在于我们如何去避免错误的产生和消除已经产生的错误，使程序中的错误密度达到尽可能低的程度。给软件带来错误的原因很多，具体地说，主要有如下几点：、交流不够、交流上有误解或者根本不进行交流在应用应该做什么或不应该做什么的细节(应用的需求)不清晰的情况下进行开发。、软件复杂性图形用户界面(GUI)，客户/服务器结构，分布式应用，数据通信，超大型关系型数据库以及庞大的系统规模，使得软件及系统的复杂性呈指数增长，没有现代软件开发经验的人很难理解它。、程序设计错误象所有的人一样，程序员也会出错。、需求变化需求变化的影响是多方面的，客户可能不了解需求变化带来的影响，也可能知道但又不得不那么做。需求变化的后果可能是造成系统的重新设计，设计人员的日程的重新安排，已经完成的工作可能要重做或者完全抛弃，对其他项目产生影响，硬件需求可能要因此改变，等等。如果有许多小的改变或者一次大的变化，项目各部分之间已知或未知的依赖性可能会相互影响而导致更多问题的出现，需求改变带来的复杂性可能导致错误，还可能影响工程参与者的积极性。、时间压力软件项目的日程表很难做到准确，很多时候需要预计和猜测。当最终期限迫近和关键时刻到来之际，错误也就跟着来了。、自负大意的态度：没问题这事情很容易几个小时我就能拿出来太多不切实际的没问题，结果只能是引入错误。、代码文档贫乏贫乏或者差劲的文档使得代码维护和修改变的异常艰辛，其结果是带来许多错误。事实上，在许多机构并不鼓励其程序员为代码编写文档，也不鼓励程序员将代码写得清晰和容易理解，相反他们认为少写文档可以更快的进行编码，无法理解的代码更易于工作的保密(“写得艰难必定读的痛苦”)。、软件开发工具可视化工具，类库，编译器，脚本工具，等等，它们常常会将自身的错误带到应用软件中。就象我们所知道的，没有良好的工程化作为基础，使用面向对象的技术只会使项目变得更复杂。为了更好地解决这些问题，软件界做出了各种各样的努力。人们曾经认为更好的程序语言可以使我们摆脱这些困扰，这推动了程序设计语言的发展，更多的语言开始流行，为了使程序更易于理解开发了结构化程序设计语言，如PL/1,PASCAL等；为了解决实时多任务需求开发了结构化多任务程序设计语言，如Modula，Ada等；为了提高重用性开发了面向对象的程序设计语言，如Simlasa等；为了避免产生不正确的需求理解，开发形式化描述语言，如HAL/S等，这使得建立基于自然语言的描述成为可能，人们以形式化语言来描述需求；为了支持大型数据库应用，开发了可视化工具，如VisualStudio、PowerBuilder等。程序语言对提高软件生产效率起到了一定的积极作用，但它对整个软件质量尤其是可靠性的影响，与其他因素相比作用较小。事实上，对于软件来讲，还没有象银弹那样的东西。不论采用什么技术和什么方法，软件中仍然会有错。采用新的语言、先进的开发方式、完善的开发过程，可以减少错误的引入，但是不可能完全杜绝软件中的错误，这些引入的错误需要测试来找出，软件中的错误密度也需要测试来进行估计。测试是所有工程学科的基本组成单元，是软件开发的重要部分。自有程序设计的那天起测试就一直伴随着。统计表明，在典型的软件开发项目中，软件测试工作量往往占软件开发总工作量的40以上。而在软件开发的总成本中，用在测试上的开销要占30到50。如果把维护阶段也考虑在内，讨论整个软件生存期时，测试的成本比例也许会有所降低，但实际上维护工作相当于二次开发，乃至多次开发，其中必定还包含有许多测试工作。因此，测试对于软件生产来说是必需的，问题是我们应该思考“采用什么方法、如何安排测试?”返回主目录CH2软件测试基础软件测试与软件质量软件测试目的软件测试原则软件测试分类软件测试方法软件测试模型软件测试生命周期测试策略软件失效分类与管理2.1软件测试与软件质量软件测试的经典定义是：在规定的条件下对程序进行操作，以发现错误，对软件质量进行评估的过程。软件测试对象：软件是由文档、数据以及程序组成的，那么软件测试应该是对软件形成过程中的文档、数据以及程序进行的测试，而不仅仅是对程序进行的测试2.1软件测试与软件质量1991年软件产品质量评价国际标准ISO9126中定义软件质量如下：软件满足规定或潜在用户需求特性的总和1999年软件产品评价国际标准ISO14598中软件质量定义为：软件特性的总和、软件满足规定或潜在用户需求特性的能力2001年软件产品质量国际标准ISO9126定义的软件质量包括“内部质量”、“外部质量”和“使用质量”三部分。即：软件满足规定或潜在用户的能力要从软件在内部、外部和使用中的表现来衡量2.1软件测试与软件质量质量保证(QA)：质量保证的主要工作是采用“全面质量管理”和“过程改进”的原理开展工作，进行软件周期管理以及验证软件是否满足规定的质量和用户的需求；所关注的是软件质量的检查和测量。主要着眼于开发活动中的过程、步骤和产物。软件测试：主要工作是执行软件，对过程中的产物-文档和源代码进行走查，运行软件，找出问题，报告质量。关心的不是过程的活动，而是对过程中的产物及开发出的软件进行剖析，找出问题并进行评估。软件测试人员的一项重要任务是提高软件质量，但不等于说软件测试人员就是软件质量保证人员，软件质量保证和软件测试是软件质量工程的两个不同层面的工作，测试是质量保证中的一个重要环节2.2软件测试目的早期定义：软件测试的目的就是为了寻找错误。以最少的人力、物力和时间，找出软件中潜在的各种错误和缺陷，通过修正错误和缺陷来提高软件质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患所带来的商业风险软件测试是以评价一个程序或系统属性为目标的活动，测试是对软件质量的度量与评估，以验证软件的质量满足用户的需求的程度为用户选择与接受软件提供有力的证据通过分析错误产生的原因可以帮助发现当前开发工作所采用的软件国产的缺陷，帮助进行软件过程改进；通过对测试结果的分析整理，可以修正软件开发规则，为软件可靠性分析提供依据通过最终的验收测试，可以证明软件满足了用户的需求，树立人们使用软件的信心2.3软件测试原则所有的软件测试都应追溯到用户需求应当把“尽早地和不断地进行软件测试”作为软件测试者的座右铭完全测试是不可能的，测试需要终止测试无法显示软件潜在的缺陷充分注意测试中的群集现象程序员应避免检查自己的程序尽量避免测试的随意性2.4软件测试分类按开发阶段划分：单元测试、集成测试、系统测试、确认测试和验收测试单元测试：又称模块测试，是针对软件设计的最小单位程序模块进行正确性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种错误。集成测试：又叫组装测试。通常在单元测试的基础上，将所有的程序模块进行有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成为符合概要设计要求的程序部件或整个系统确认测试：是通过检验和提供客观证据，证实软件是否满足特定预期用途的需求。确认测试是检测与证实软件是否满足软件需求规格说明书中规定的要求。系统测试：是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程序系统能否和系统正确配置、连接，并满足用户需求。验收测试：按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的测试与评审，决定是否接收或拒收系统。2.4软件测试分类按照测试实施组织划分：可分为开发方测试、用户测试、第三方测试。开发方测试：通常也叫验证测试或测试。开发方在软件开发完成以后，通过自我检测和验证来提供客观证据，证实软件的实现是否满足规定的需求。用户测试（测试）：在用户的应用环境下，用户通过运行和使用软件，检测与核实软件实现是否符合自己预期的要求。通常情况用户测试不是指用户的验收测试，而是指用户的使用性测试，由用户找出软件的应用过程中发现的软件的缺陷与问题，并对使用质量进行评价第三方测试：介于软件开发方和用户方之间的测试组织的测试。第三方测试也称独立测试。软件质量工程强调开展独立验证和确认（IV&V）活动。IV&V是由在技术、管理和财务上与开发组织具有规定程度独立的组织执行验证和确认过程。故第三方测试是由在技术、管理和财务上与开发方和用户方相对独立的组织进行的软件测试。一般情况下是在模拟用户真实应用环境下，进行软件确认测试。2.4软件测试分类按照测试技术划分：白盒测试、黑盒测试、灰盒测试。白盒测试：也称结构测试或逻辑驱动测试，它是按照程序内部的结构测试，检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条通路是否都能按照预定要求正确工作。黑盒测试：也称功能测试，它是通过测试来检测每个功能是否都能正常使用。黑盒测试不考虑程序内部结构与内部特性，着眼于外部结构，针对软件界面和软件功能进行测试，考察程序是否能适当地接收输入数据而产生正确的输出信息，确认程序功能满足需求。灰盒测试：介于白盒和黑盒之间的测试，结合了白盒测试和黑盒测试的要素，灰盒测试关注输出对于输入的正确性；同时也关注内部表现，但不会像白盒测试这样详细和完整，只是通过一些表征性的现象、事件和标志来判断内部的运行状态。灰盒测试考虑了用户端、特定的系统知识和操作环境。在系统组件的协同性环境中评价应用软件的设计。2.5软件测试方法静态测试：是指不运行程序，通过人工对程序和文档进行分析和检查；包括：代码走查、符号执行、需求确认等。动态测试：是指通过人工或使用工具运行程序进行检查、分析程序的执行状态和程序的外部表现。2.6软件测试过程模型V模型W模型H模型X模型前置模型测试模型的使用用户需求需求分析与系统设计详细设计验收测试概要设计编码确认测试与系统测试集成测试单元测试软件测试V模型V模型是最广为人知的模型，尽管很多富有实际经验的测试人员还是不太熟悉V模型，或者其它其它的模型。V模型已存在了很长时间，和瀑布开发模型有着一些共同的特性，由此也和瀑布模型一样地受到了批评和质疑。V模型中的过程从左到右，描述了基本的开发 过程和测试行为。V模型的价值在于它非常明确地标明了测试过程中存在的不同级别，并且清楚地描述了这些测试阶段和开发过程期间各阶段的对应关系。局限性：把测试作为编码之后的最后一个活动，需求分析等前期产生的错误直到后期的验收测试才能发现.V模型的局限性在于没有明确地说明早期的测试,无法体现“尽早地和不断地进行软件测试”的原则。在V模型中增加软件各开发阶段应同步进行的测试，演化为W 模型（如下图）。在模型中不难看出，开发是“V”，测试是与此并行的“V”。基于“尽早地和不断地进行软件测试”的原则，在软件的需求和设计阶段的测试活 动应遵循IEEE1012-1998软件验证与确认（V&V）的原则。W模型由Evolutif公司提出，相对于V模型，W模型更科学。W模型是V模型的发展，强调的是测试伴随着整个软件开发周期，而且测试的对象不仅仅是程序，需求、功能和设计同样要测试。测试与开发是同步进行的，从而有利于尽早地发现问题。W模型也有局限性。W模型和V模型都把软件的开发视为需求、设计、编码等一系列串行的活动，无法支持迭代、自发性以及变更调整。程序片段1测试设计工具配置执行测试编码完成执行测试执行测试执行测试工具配置测试设计程序片段n测试设计工具配置集成1n探索性测试封版软件测试X模型X模型也是对V模型的改进,X模型提出针对单独的程序片段进行相互分离的编码和测试,此后通过频繁的交接,通过集成最终合成为可执行的程序。X模型的左边描述的是针对单独程序片段所进行的相互分离的编码和测试，此后将进行频繁的交接，通过集成最终成为可执行的程序，然后再对这些可执 行程序进行测试。己通过集成测试的成品可以进行封装并提交给用户，也可以作为更大规模和范围内集成的一部分。多根并行的曲线表示变更可以在各个部分发生。由图中可见，X模型还定位了探索性测试，这是不进行事先计划的特殊类型的测试，这一方式往往能帮助有经验的测试人员在测试计划之外发现更多的软件错误。但 这样可能对测试造成人力、物力和财力的浪费，对测试员的熟练程度要求比较高。测试准备测试执行测试就绪点测试流程其他流程（如设计流程）软件测试H模型H模型中,软件测试过程活动完全独立,贯穿于整个产品的周期,与其他流程并发地进行,某个测试点准备就绪时,就可以从测试准备阶段进行到测试执行阶段。软件测试可以尽早的进行,并且可以根据被测物的不同而分层次进行。这个示意图演示了在整个生产周期中某个层次上的一次测试“微循环”。图中标注的其它流程可以是任意的开发流程,例如设计流程或者编码流程。也就是说,只要测试条件成熟了,测试准备活动完成了,测试执行活动就可以进行了。H模型揭示了一个原理:软件测试是一个独立的流程,贯穿产品整个生命周期,与其他流程并发地进行。H模型指出软件测试要尽早准备,尽早执行。不同的测试活动可以是按照某个次序先后进行的,但也可能是反复的,只要某个测试达到准备就绪点,测试执行活动就可以开展可行性分析可行性报告业务需求说明系统分析基于测试的需求验收标准验收测试计划执行验收测试运行与维护系统设计设计文档技术测试计划正式走查黑/白盒单元测试集成测试系统测试专项测试独立（QA）测试开发编码调试非正式走查前置测试模型2.7软件测试生命周期测试策略开发与测试软件测试策略需求分析概要设计详细设计编码单元测试确认测试系统测试需求规格说明书概要设计说明书详细设计说明书源程序代码单元测试集成测试确认测试软件测试与软件开发过程的关系被测模块单元测试通过测试的模块被测模块单元测试被测模块单元测试集成测试系统测试确认测试设计信息系统其他元素软件需求已集成的软件软件测试的过程软件配置测试工具测试配置测试结果分析排错可靠性分析回归测试测试结果预期结果出错率数据改正后的软件预测可靠性测试信息流错误2.8软件失效分类与管理软件失效分类缺陷与错误分布缺陷与错误严重性和优先级软件错误跟踪管理软件失效分类软件错误：在软件生存期间内的不希望或不可接受的人为错误，其结果是导致软件缺陷的产生。软件缺陷：软件缺陷是存在于软件之中的那些不希望或不可接受的偏差（如少一个标点符号，多一个语句等）。其结果是软件运行于某一特定条件时出现软件故障，这时称软件缺陷被激活。软件故障：软件故障是软件运行过程中出现的一种不希望或不可接受的内部状态。此时若无适当措施加以及时处理，便产生软件失效。软件失效：软件失效是指软件运行时产生的一种不希望或不可接受的外部行为结果。缺陷与错误严重性和优先级严重性：表示软件缺陷所造成的危害的恶劣程度1.致命：系统崩溃、数据丢失、数据毁坏2.严重：操作性错误、错误结果、遗漏功能3.一般：小问题、错别字、UI布局、罕见故障4.建议：不影响使用的瑕疵或更好的实现缺陷与错误严重性和优先级优先级：表示修复缺陷的重要程度与次序1.最高优先级：立即修复，停止进一步测试。2.次高优先级：在产品发布之前必须修复。3.中等优先级：如果时间允许，应该修复。4.最低优先级：可能会修复，但是不修复也能发布。软件错误跟踪管理错误跟踪管理：为了正确地跟踪每个软件错误的处理过程，通常将软件测试发现的每个错误作为一条记录输入指定的错误跟踪管理系统常用错误跟踪管理软件：TrackRecord、Bugzilla、Bugfree、BMS等BUG记录信息：应包括测试软件名称、测试版本号、测试人名称、测试事件、测试软件和硬件配置环境、发现软件错误的类型、错误的严重等级、详细步骤、必要的附图及测试注释。BUG处理信息：主要包括4项：处理者姓名、处理时间、处理步骤、错误记录的当前状态。错误管理流程跟踪管理过程参考BUGFREE2.0使用帮助http:/ 的边界上，而不是在内部。因此，针对各种边界情况设计用例，通常会取得很好的测试效果。怎样用边界值分析法设计测试用例？1.首先确定边界情况。通常输入或输出等价类的边界就是应该着重于测试的边界状况。2.选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值。常见的边界值对16bit的整数而言32767和-32768是边界屏幕上光标在最左上、最右下位置报表的第一行和最后一行数组元素的第一个和最后一个循环的第0次、第1次和倒数第2次、倒数第1次边界值分析ABCDAX B，C Y Dyx确立边界值的原则如果输入条件或输出条件规定了值的范围并且有效条件包括了值的边界，可分别对边界和略超出边界取值。例如：数据范围是1 X 50 正整数 边界值则取：1，50，0，51。如果输入条件或输出条件规定了值的范围并且有效条件不包括值的边界，可分别对边界和略处于边界内取值 例如：数据范围是1X50 正整数 边界值取：1，50，2，49。如果输入或输出域是个有序的集合（如顺序文件、表格等），应选取有序集的第一个和最后一个元素以及集合外但靠近集合的元素作为边界，例如：输入文件名介于file101file120之间 边界值取：file100，file101，file120，file121。边界值分析边界值分析使用与等价类划分法相同的划分，只是边界值分析假定错误更多地存在于划分的边界上，因此在等价类的边界上以及两侧的情况设计测试用例例：测试计算平方根的函数 输入：实数 输出：实数 规格说明：当输入一个0或比0大的数的时候，返回其正平方根；当输入一个小于0的数的时候，显示错误信息：“平方根非法-输入值小于0”并返回0；边界值分析等价类划分：可以考虑做如下划分：输入：(a)：=0；输出：(A)：=0，(B)：error。测试用例有两个：输入4，输出2。对应a和A；输入-10，输出error。对应b和B；边界值分析 划分b的边界为0和最大正实数；划分a的边界为最小负实数和0。由此得到如下测试用例：输入最小负实数；输入绝对值很小的负数；输入0；输入绝对值很小的正数；输入最大正实数；边界值分析测试用例设计方法采用边界值分析测试的基本思想是：故障往往出现在输入变量的边界值附近。因此边界值分析法利用输入变量的最小值、略大于最小值、输入值域的任意值、略小于最大值和最大值来设计测试用例。在边界值分析法中获取测试用例的方法是：1.每次保留程序中一个变量，让其余的变量取正常值，被保留的变量依次取最小值、略大于最小值、输入值域的任意值、略小于最大值和最大值。2.对每个变量执行步骤1。对于健壮型边界值分析，还要加入略小于最小值和略大于最小值的情况边界值分析设计测试用例有二元函数f(x,y)，其中x1,12，y 1,31。则采用边界值分析法设计的测试用例是：,有函数f(x,y,z)，其中x10,20,y40,50,z80,90写出该函数采用边界值分析法设计的测试用例。因果图法产生背景：等价类划分法和边界值分析法都是着重考虑输入条件，但没有考虑输入条件的各种组合、输入条件之间的相互制约关系。这样虽然各种输入条件可能出错的情况已经测试到了，但多个输入条件组合起来可能出错的情况却被忽视了。因果图法能够帮助测试人员按照一定步骤，高效率的开发测试用例，以检测程序输入条件的各种组合情况，它是将自然语言转化为形式语言规格说明的一种严格方法，可以指出规格说明存在的不完整性和二义性。因果图法因果图法是一种利用图解法分析输入的各种组合情况，从而设计测试用例的方法。它适合于检查程序输入条件的各种组合情况。因果图法步骤：分析需求规格说明书描述中的因果关系。找出原因与结果、原因与原因之间的对应关系，画出因果图 在因果图上标记约束或限制条件 把因果图转化为判定表 将判定表中的每一列拿出来设计测试用例因果关系表示法因果图中使用4种因果关系符号来表达因果关系：c1e1c2e1c1e1c3c2c1e1c1恒等非或与因果图中的4种基本关系：在因果图的基本符号中，图中的左结点ci表示输入状态（原因），右结点ei表示输出状态（结果）。Ci与ei取值0或1，0表示某状态不出现，1表示某状态出现。恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。c1为1，则e1也为1；否则e1为0。非：若原因出现则结果不出现；若原因不出现，则结果出现。若c1为1，则e1为0；否则e1为1。或：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。若c1或c2或c3为1，e1为1；否则e1为0。与：若几个原因都出现，则结果出现；若其中有一个原因不出现，则结果不出现。若c1和c2均为1，e1为1；否则e1为0。因果图中的约束：EabaaaabbbbcRIOM输入状态之间、输出状态之间可能存在某些依赖关系，称为“约束”。对于输入条件之间的约束有E、I、O、R四种；对于输出条件的约束只有M一种。E约束（互斥）：输入状态a,b最多有一个成立，不能同时成立。I约束（包含）：输入状态a,b,c至少有一个必须成立。O约束（唯一）：输入状态a,b必须有一个且仅有一个成立。R约束（要求）：当输入状态a成立时，输入状态b也必须成立。M约束（屏蔽）：当输入状态a成立时，输出结果b一定不成立；a不成立时，b的结果不定。因果图法生成测试用例的步骤：1.分析规格说明中哪些是原因，哪些是结果，并给每个原因和结果赋予一个标识符。2.分析规格说明中的语义，找出原因与结果之间、原因与原因之间的关系，根据这些关系画出因果图。3.由于语法或环境限制，有些原因与原因之间、原因与结果之间的组合情况不可能出现。在因果图上用记号表明约束限制条件。4.把因果图转换为判定表。5.根据判定表中的每一个列设计测试用例。判定表在一些数据处理问题中，某些操作依赖多个逻辑条件的取值。处理这类问题的一个非常有力的分析和表达工具是判定表。一些软件的功能需求可用判定表表达的非常清楚，在检验程序的功能时判定表也就成为一个非常有力的工具判定表通常由4部分组成：条件桩：列出了问题的所有条件。通常认为列出的条件的次序无关紧要。条件项：列出针对它所列条件的取值，在所有可能情况下的真假值。动作桩：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。动作项：列出在条件项的各种取值情况下应该采取的动作规则：任何一个条件组合的特定取值极其相应要执行的操作，在判定表中贯穿条件项的一列就是一条规则。判定表中列出多少组条件取值，也就有多少条规则，条件项和动作项既有多少列。判定表建立步骤判定表的建立应该依据软件规格说明，步骤如下：1.确定规则的个数。假如有N个条件，每个条件有两个取值，固有2n种规则。2.列出所有的条件桩和动作桩。3.填入条件项。4.填入动作项。5.简化。合并相似规则或者相同动作案例案例1：第一列字符必须是#或*，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。解题步骤：1.原因：c1第一列字符是#；c2第一列字符是*；c3第二列字符是一个数字；10第一列字符是#或者是*。场景法现在的软件几乎都是用是事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可引用到测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。用例场景用来描述流经用例的路径，从用例开始到结束遍历这条路径上所有基本流和备选流。根据左图所示，可以确定以下不同的用例场景：场景1：基本流；场景2：基本流，备选流1；场景3：基本流，备选流1，备选流2；场景4：基本流，备选流3；场景5：基本流，备选流3，备选流1；场景6：基本流，备选流3，备选流1，备选流2；场景7：基本流，备选流4；场景8：基本流，备选流3，备选流4.ATM例子基本流：前提：ATM处于准备就绪状态 步骤1：准备提款，插入银行卡；步骤2：验证银行卡：ATM读取银行卡中的账户代码，并验证是否有效；步骤3：输入密码：ATM要求输入密码，验证账户和密码；步骤4：ATM选项：选择提款服务；步骤5：输入金额：选择提取的金额；步骤6：出钞；步骤7：打印收据；步骤8：退出银行卡；备选流1：银行卡无效；备选流2：ATM内没有现金；备选流3：ATM内现金不足；备选流4：密码有误；备选流5：账户不存在/类型错误；备选流6：账面金额不足。对于7个场景中的每一个场景确定测试用例测试用例包含测试用例ID，场景/条件，测试用例中设计的所有数据元素和预期结果等项目。首先确定执行用例场景所需的数据元素，然后构建矩阵，最后要确定包含执行场景所需的适当条件的测试用例。在右侧矩阵中：V表示这个条件必须是有效的才可以执行的基本流；I表示这种条件下将激活所需备选流；n/a表示这个条件不适用于测试用例。错误推测法错误推测法是基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性地设计测试用例错误推测法基本思想列举出程序中所有可能有的错误和容易发生错误的特殊情况来设计测试用例例如：以前测试曾出现过错误的地方，包括单元测试、集成测试、系统测试、前几次回归测试 输入数据的问题；如是否可以为空，是否可以有特殊字符，是否可以小于0，等于0等。一些问题的范围或边界。测试用例设计方法的选择综合策略：1.首先进行等价类划分，包括输入条件和输出条件的等价划分，将无限测试变成有限测试，这是减少工作量和提高测试效率最有效的方法；2.在任何情况下都必须使用边界值分析法。经验表明，用这种方法设计出来的测试用例发现程序错误的能力最强；3.可以用错误推测法追加一些测试用例，这需要测试工程师的智慧和经验4.对照软件逻辑检查已设计出的测试用例的逻辑覆盖程度。如果没有达到要求的覆盖标准，应当适当增补测试用例5.如果程序的功能说明中含有输入条件的组合情况，则一开始就可选用因果图法和判定表驱动法6.对于业务流清晰的系统，可以利用场景法贯穿整个测试案例过程，在案例中综合使用各种测试方法。非功能性测试测试要点易用性测试文档测试易用性测试安装测试 安装测试的易用性是安装测试的主要内容。安装测试测试事项：1.安装手册：需要对安装平台、安装过程和配置部分进行详细说明；2.安装的自动化程度：软件的安装程序尽量做到全自动化，尽可能的减少手动配置操作；3.安装选项和设置：对安装包不同的选项和设置进行测试，验证各种方案是否都能安装成功；4.安装过程的中断测试：安装程序应具备记忆安装的功能，当安装过程被异常中断，恢复安装时支持从“断点”继续安装；5.安装顺序测试：安装软件的不同组成部分的先后顺序不同是否会导致安装失败；如果安装手册上未提及安装顺序，则需进行测试；6.多环境安装测试：标准配置，最低配置和笔记本电脑（高集成度特性）中。7.安装的正确性：进行简单的使用以验证安装的正确性；8.修复安装测试与卸载测试易用性测试功能易用性测试1.业务符合性：软件必须符合所服务的领域的业务逻辑。软件的界面风格、表格设计、业务流程、数据加密机制等必须符合相关的法律法规、业界标准规范以及使用人员的习惯；2.功能定制性：为了适应用户需求的不断变化软件功能应当能够灵活定制。例如工资软件中部门结构和人员归属可以灵活调整。3.业务模块的集成度：一个系统之中业务模块之间有可能存在较紧密的关联。4.数据共享能力：一次输入，多处应用。5.约束性：软件需以向导或屏蔽无关操作的形式来限制用户的不合理操作。6.交互性：包括用户操作的可见性和系统对用户的反馈。7.错误提示：关键操作或数据删除前给出明确提示。易用性测试用户界面测试1.软件界面要尽量符合现行规范和标准并在应用软件中保持一致。2.界面中元素的文字、颜色等信息是否与功能不一致；3.前景与背景色搭配是否合理协调，反差是不是太大；4.界面中的元素大小和布局是否协调；5.窗口的比例是否合适；6.标签信息的措辞是否一致；7.操作方法是否一致；8.快捷键在不同模块上的语义是否保持一致；9.界面元素、工具栏、统计检索和报表的可定制性；10.菜单项是否符合需求，菜单项的顺序和措辞是否合理；文档测试文档测试针对用户手册的测试1.准确地按照手册的描述使用程序。2.尝试每一条建议。3.检查每条陈述。4.查找容易误导用户的内容。返回主目录CH4软件测试工具配置过程管理工具-TD功能测试工具-WINRUNNER性能测试工具-LOADRUNNER数据库装载工具-DATAFACTOR返回主目录