IEEE-软件测试知识体系

软件测试知识体系2/71第一部分软件测试基础3/71测试相关术语-1第一部分：软件测试基础SWEBOK2004:软件测试是指“从常用使用范围内选取有穷测试用例，以预期行为作为基准对程序实际行为进行的动态认证”–动态:根据不同（赋值）输入进行的程序测试–有穷集：完整的测试集合通常被认为是无穷的。而测试则是在测试质量和可用资源之间选取的最佳平衡点。–选取:“测试用例”的选择时基于风险分析和测试工程学–预期行为：必须明确预期行为这样才能判断程序真正的执行结果是否在可接受范围内4/71IEEE标准610.12-1990:将测试定义为“对系统或者系统原件在特定条件下运行的结果进行观察或者记录，并对系统和原件进行某些方面性能评价”描述系统错误的相关术语：–故障:计算机程序中的一个错误步骤、流程或者数据定义–错误：由实际计算、观察或测量所得到的结果和条件，与理论值之间的偏差我们称之为错误–失败:当系统无法根据性能要求执行相应的功能时我们称之为失败–失误：由人为因素导致错误结果测试相关术语-2第一部分：软件测试基础5/71是进行测试的总体方案是测试的路线图能帮助解决问题，例如：–需要进行哪些类型的测试？（人工还是自动）–实际的测试环境是什么？–测试资源是什么？还需要哪些其他测试资源？–什么时候需要进行测试？测试策略第一部分：软件测试基础6/71测试类型测试类型功能性结构性静态动态黑盒白盒-软件测试的一个方法，当测试时不需要调用软件-主要测试代码、算法、或者文档的合理性选取合适的测试用例来执行测试目标第一部分：软件测试基础7/71测试类型——黑盒测试将软件视作黑盒而不理解内部代码是如何执行的黑盒测试的目的是根据需求测试软件功能所有的软件测试用例在提交给测试者之后，测试者鉴定软件的输出（或者行为）是否符合测试用例所预期的结果?输入输出需求？劣势优势第一部分：软件测试基础8/71测试类型——白盒用以测试软件代码内部逻辑和结构测试者通过了解软件内部的结构开发测试用例在代码完成之前无法设计测试用例内部逻辑结构输入输出需求?第一部分：软件测试基础9/71测试类型——灰盒需要能够访问到测试用例的内部数据结构和算法开发测试用例而测试本身由用户执行，或者以黑盒模式进行测试例如可用于当进行对两个由不同开发人员所开发的代码进行整合测试，因为通常只有程序接口可被用于进行测试输入输出需求？第一部分：软件测试基础10/71关键问题——决策当准备一个测试计划时，测试者必须决定要测试哪些项目？测试到何种程度？测试的顺序是什么？会如何应用测试手段？测试环境必须包括什么？第一部分：软件测试基础11/71测试原理——I一个成功的测试是指发现错误的测试测试原理一个好的测试用例更有可能发现错误测试的预期测试结果是实现定义好的测试文档能够保证在今后重复使用并且包含在后续复查中独立的测试通过/失败确认代码之间有独立性测试中会同时雇佣用户和软件开发员；测试者使用程序员所提供的不同测试工具。只检验常规用例（“欢乐测试路径”）是不够的第一部分：软件测试基础12/71测试同其他活动的关系–I测试是局限于代码执行过程的，但还有其他和测试相关的技巧是静态的例如：–软件审核和检查–阅读代码–正确性验证–符号执行–程序证明–异常分析第一部分：软件测试基础13/71测试同其他活动的关系-II有些与测试相关的活动是在软件生命周期的其他阶段进行的–需求阶段：所有的软件需求都会根据完整性、连续性、标准符合性等进行检查–设计阶段:检查文档、模型和软件原型的连续性是否满足要求–构建阶段：代码由同事和技术专家进一步审核第一部分：软件测试基础14/71第二部分测试阶段15/71测试目标第二部分：测试程度•验证单元的功能正确•单元间没有交互•主要侧重于发现单元和组件之间的接口错误•侧重于寻找在单元测试中不能发现的错误•评价整个系统的行为•收集能导向软件发布的信息•发现不能归因于单个组件的错误•由供应方和消费者完成•决定是否是否满足要求回归单元整合系统接受16/71测试类型-I一致性或正确性测试–选择测试用例来验证观察到的行为符合规范–可以在单元、整合和系统级别完成可靠性评价和测试评价–测试用例是随机生成的–常用功能会有更密集的测试样本第二部分：测试程度17/71测试类型-II回归测试–进行重新测试以确保之前已经通过的测试在系统发生改变后仍然奏效性能测试–确保系统满足软件的性能要求，比如容量和响应时间第二部分：测试程度18/71测试类型-III功能测试–软件根据功能需求进行测试容量测试–性能测试通常和批处理能力有关压力测试–将系统逼近最大系统负载甚至过载来觉得系统的极限第二部分：测试程度19/71测试类型-IV读取测试–和交易处理系统相关的性能测试端端测试–在两个系统版本上进行相同的测试配置测试–当软件在一个以上的配置中使用时，必须对每个配置都进行测试第二部分：测试程度20/71测试类型-V可用性测试–评价是否易于使用–评价人机界面的人机工程学设计–用于文档的有效性恢复测试–测试软件的容灾能力Alpha测试–采用一个独立测试小组模拟真实使用情况第二部分：测试程度21/71测试类型-VIBeta测试–对特定的用户组发布早期的软件版本可接受性测试–根据系统行为测试客户需求安装测试–当所有软件和可接受性测试完成后进行第二部分：测试程度22/71测试类型-VII验证测试–确保系统在用户操作环境中满足用户的需求安全测试–被设计来用于验证系统是否有足够能力来抵抗未授权访问，计算机犯罪和恶意破坏第二部分：测试程度23/71第三部分测试技巧24/71基于标准的测试技巧–I第三部分：测试技巧等价划分–将测试用例减少到一个最小值–输入域被划分成一系列子集或者相同的类–测试用例必须至少从每个子集或者每个类中选取一个值无效等价类有效等价类1月到12月≤0≥13例：传递一个日期变量“月份”的函数25/71基于标准的测试技巧–II第三部分：测试技巧边界值分析–设计用于测试超出范围的测试用例–测试用例的选择基准是因为在极限值（边界值）上更容易发生错误例：对于月份的边界测试可以对十二月月上加上一个月，看结果是一月还是十三月If(month12)thenmonth=month–12;year=year+1;endif第三部分：测试技巧26/71基于标准的测试方法–III第三部分：测试技巧决策表–用于构建一组完整的测试用例–表反映了条件与行为间的关系–测试用例来自每一组不同的关系条件值12345678条件1Y,NYYYYNNNN条件2Y,NYYNNYYNN条件3Y,NYNYNYNYN行为行为1XXX行为2XXX规则第三部分：测试技巧27/71基于标准的测试方法–V第三部分：测试技巧–用于建立功能测试的行为模型–对于软件建模，用户/开发者沟通和测试的优秀工具–测试用例被用于对选中的状态和过渡态进行测试基于有穷状态机的测试第三部分：测试技巧28/71基于标准的测试方法–V第三部分：测试技巧–形式化方法使用数学模型和数学证明来确保得到正确的行为–先决条件和后置条件是两个形式化方法形式化方法先决条件在作出正确请求前需要满足的条件后置条件在发出成功请求后确保为真的条件(IEEE标准1320.2-1998,IEEEStandardforConceptualModelingLanguageSyntaxandSemanticsforIDEF1X97)第三部分：测试技巧29/71基于标准的测试方法–VI第三部分：测试技巧–不引用代码或者标准而直接生成数据–为分析提供数学基础并且能快速生成测试用例–不能保证能够覆盖所有问题–不一定能生成非法值和极限值随机测试第三部分：测试技巧30/71基于代码的测试技巧第三部分：测试技巧基于控制流的标准基于数据流的标准语句覆盖分支覆盖路经测试语句，分支和条件测试所有的定义和使用路径所有的定义或使用路径每个语句都至少执行一次每一个路径都至少运行一次系统图表有没有副作用？有没有分支会导致程序的异常？第三部分：测试技巧31/71基于错误的测试方法第三部分：测试技巧•最可能发生的故障•历史信息•经验•单一错误被输入到多个拷贝中•容错性？•发生错误会有什么表现？•人为错误难以根除而且有可能会带给消费者负面影响•测试不常调用的代码•定义合适的变异操作符•测试原始代码和变异代码•所有的变异代码都不能铜鼓哦测试•语法错误通常能揭露更复杂的真正故障第三部分：测试技巧32/71基于程序本身特性的测试方法第三部分：测试技巧第三部分：测试技巧33/71面向对象的测试可能有许多独立的类需要进行测试信息隐藏后难以判断一个类是否正常工作，因为程序接口可能难以访问到内部的数据程序员必须对每个类都开发出一个有效的测试程序可能结果是测试程序比要目标程序更加大型更加复杂第三部分：测试技巧第三部分：测试技巧34/71使用现成的商业组件有越来越多的软件开始使用现成的商业组件以控制设计成本每一个组件必须在新的环境中进行测试和改善因为这些商业组件通常不能进行编辑，黑盒测试成了最恰当的测试方法第三部分：测试技巧第三部分：测试技巧35/71基于网页的应用程序在测试网页应用程序中有许多难点软件需求需要在许多种不同的硬件、网络连接、操作系统、中间件、网页服务器和浏览器中进行测试可能需要动态生成应用程序和内容兼容性和可互换性成了重要的特征用户可以通过单击刷新或者返回轻易更改整个软件流程网页应用程序通常需要快速进行维护第三部分：测试技巧第三部分：测试技巧36/71图形用户界面测试（GraphicalUserInterface,GUI）GUI测试能确保GUI满足设计标准在GUI测试中三个难点：–使用规模:一个GUI可能有许多运算需要进行测试。一个小型程序通常就会有200到300个GUI运算–顺序：一些系统功能可能需要遵循特定的事件发生顺序。对于手工生成测试用例的测试者而言这变得非常重要。–回归测试：回归测试有时非常困难因为即便程序本身没有发生改变，GUI也可能在几个不同的应用程序版本中发生改变第三部分：测试技巧第三部分：测试技巧37/71并发程序-I测试并发程序会带来许多挑战–测试程序本身也需要是并发程序–并发程序的错误更加难以预测而且这些错误的重复性也很低–调试或者监视程序运行可能会带来时间和同步上的人为因素从而阻止了错误的再次产生–设计和执行并发测试比传统的顺序测试更加耗时第三部分：测试技巧第三部分：测试技巧38/71并发程序-II当测试并发程序时–寻找更多的状态空间–寻找更多的交叉点–匹配平台的线程数–防止带来时间或者同步上的人为问题第三部分：测试技巧第三部分：测试技巧39/71一致性测试一个标准的一致性测试集通常覆盖整个或者绝大部分的软件要求一致性测试集将软件要求分为许多独立的单一的测试用例可能会有几十个到几百个测试用例测试用例包含的信息有：–建立测试用例的需求–输入–测试的预期反馈第三部分：测试技巧第三部分：测试技巧40/71安全关键系统-I这类系统如果发生故障可能会导致人员伤亡这类系统对系统的正确执行有着严格要求通过测试来发现并且解决所有潜在错误并确保程序的正确执行安全关键系统的两个主要错误发生原因–物理组件错误和–设计失误第三部分：测试技巧第三部分：测试技巧41/71安全关键系统-II为了增加系统的安全性，可以采用两个手段：–设计多样性针对相同的设计需求设计多种程序版本–错误规避对于开发系统模型使用形式化方法和数学验证第三部分：测试技巧第三部分：测试技巧42/71基于软件工程学直觉和经验的测试-I第三部分：测试技巧特设测试探索性测试“我现在能进行的最佳测试手段是哪个？”依赖于–直觉–技巧和–测试者的经验对于通过常规测试方法难以捕捉到的特殊测试用例非常有效有时也被认为是探索性测试的一种指在事先确定的测试测试的有效性取决于–软件工程师的知识–测试者的经验–错误类型–风险第三部分：测试技巧43/71第三部分：测试技巧对新产品或者新特性的快速反馈能快速学习新产品在基于代码的测试完成之后再进行多样化的测试最重要的错误可能在最短的时间内发现对其他测试者工作进行简短的独立审查调查