ISTQB高级技术测试分析师大纲.doc
《ISTQB高级技术测试分析师大纲.doc》由会员分享，可在线阅读，更多相关《ISTQB高级技术测试分析师大纲.doc（25页珍藏版）》请在冰豆网上搜索。
ISTQB技术测试分析师
1.技术测试分析师在基于风险的测试中的任务-30分钟.
关键词
产品风险（productrisk）、风险分析（riskanalysis）、风险评估（riskassessment）、风险识别（risk
identification）、风险级别（risklevel）、风险缓解（riskmitigation）、基于风险的测试（risk-based
testing）
技术测试分析师在基于风险的测试中的任务相关的学习目标
1.3风险评估
TTA-1.3.1（K2）总结技术测试分析师需要考虑的、典型的风险因素
通用的学习目标
TTA-1.x.1（K2）总结在基于风险的测试方法中，技术测试分析师在测试计划和测试执行过程中的相关活动。
1.1简介
测试经理具有建立和管理基于风险的测试策略的全面责任。
测试经理往往要求技术测试分析师的介入以确保正确执行基于风险的方法。
由于其独有的技术特长，技术测试分析师与以下基于风险的测试任务密切相关：
第25页共25页
l风险识别
l风险评估
l风险缓解
为了处理出现的产品风险和变更优先级，以及定期地评估和沟通风险状态，以上任务会迭代地贯穿在整个项目中。
技术测试分析师在由测试经理为项目制定的、基于风险的测试框架中工作。
他们贡献出与项目内在密切相关的技术风险知识，比如安全相关的风险、系统可靠性和性能相关风险。
1.2风险识别
在风险识别过程中越广泛地接触各类项目干系人，能识别出最大数量的重大风险的可能性也就越大。
由于技术测试分析师掌握独特的专门技能，他们特别适合进行专家访谈，与同事头脑风暴以及分析当前和以前的工作经验来确定可能存在产品风险的区域。
特别地，技术测试分析师与其他技术同行（例如，开发人员、架构师、运维工程师）工作密切，有利于确定存在技术风险的区域。
识别的风险样本可能包括：
l性能风险（例如，在高负载条件下无法达到响应时间的要求）
l安全风险（例如，在安全攻击下泄露敏感数据）
l可靠性方面风险（例如，应用程序无法满足服务等级协议中指定的可用性）
与特定的软件质量特性相关的风险区域将在本大纲的相关章节中介绍。
1.3风险评估
风险识别致力于鉴别尽可能多的相关风险，而风险评估旨在研究这些识别的风险以便于更好地进行风险分类并确认风险的可能性和影响程度。
确认风险级别通常涉及为每个风险项评估发生的可能性及发生后带来的影响程度。
风险发生的可能性一般解释为当系统在测试条件下，一些潜在的问题真实存在的可能性。
技术测试分析师致力于发现和理解每个风险项潜在的技术风险，而测试分析师致力于理解当问题发生时带来的潜在商业影响。
通常需要考虑的因素包括：
l技术复杂度
l代码结构的复杂度
l项目干系人之间关于技术需求的冲突
l由开发组织的地理分布产生的沟通问题
l工具和技术
l时间、资源和管理压力
l缺少项目前期的质量保障
l技术需求的高变化率
l大量与技术质量特性相关的缺陷
l技术接口和集成相关问题
在风险信息已知的情况下,技术测试分析师根据由测试经理建立的指导方针来建立风险级别。
举例来说，测试经理可能决定将风险级别划分为1到10之间的值，其中值1为最高风险。
1.4风险缓解
项目期间，技术测试分析师影响着测试如何响应所识别的风险。
这个影响主要包括以下几个方面：
l通过执行最重要的测试，实施测试策略和测试计划中所述的适当的缓解和应急活动来减少风险
l在项目开展过程中，收集额外的信息，并在此基础上评估风险；而且利用该信息来实施缓解行动，旨在减少先前识别和分析的风险的可能性和影响
2.基于结构的测试-225分钟.
关键词
原子条件（atomiccondition）、条件测试（conditiontesting）、控制流测试（controlflowtesting）、判
定条件测试（decisionconditiontesting）、复合条件测试（multipleconditiontesting）、路径测试
（pathtesting）、短路/缩短（short-circuiting）、语句测试（statementtesting）、基于结构的技术
（structure-basedtechnique）
基于结构的测试学习目标
2.2条件测试
TTA-2.2.1（K2）理解如何实现条件覆盖以及为何判定覆盖比条件覆盖更严谨
2.3判定条件测试
TTA-2.3.1（K3）应用判定条件测试的测试设计技术设计测试用例以达到规定的覆盖率
2.4改进的条件/判定覆盖（MC/DC）测试
TTA-2.4.1（K3）应用改进的条件/判定覆盖（MC/DC）测试的测试设计技术设计测试用例以达到规定的
覆盖率
2.5复合条件测试
TTA-2.5.1（K3）应用复合条件测试的测试设计技术设计测试用例以达到规定的覆盖率
2.6路径测试
TTA-2.6.1（K3）应用路径测试的测试设计技术来设计测试用例
2.7API测试
TTA-2.7.1（K2）理解API测试的适用性以及它所能发现的各种缺陷
2.8选择一种基于结构的测试
TTA-2.8.1（K4）基于特定的项目状况选择一种合适的基于结构的测试技术
2.1简介
本章主要描述基于结构的测试设计技术，也被称作白盒测试或者基于代码的测试技术。
这种技术以代码、数据和架构以及/或者系统流程图作为测试设计的基础。
通过每一个具体的技术能系统化地导出测试用例，同时每个技术关注的是所考虑的结构的特定方面。
该技术提供覆盖准则，这些准则必须经过测量，而且必须与每个项目或组织所定义的目标相关联。
达到全覆盖也并不意味着整个测试集是完整的，而是正在使用的技术对在考虑中的结构不再能提出任何有用的测试。
除了条件覆盖，本大纲中所考虑的基于结构的测试设计技术比初级大纲（ISTQB®_FL_SYL）中涉及的语句和判定覆盖技术更为严谨。
以下是本大纲中涉及的技术：
l条件测试
l判定条件测试
l改进的条件/判定覆盖（MC/DC）测试
l复合条件测试
l路径测试
lAPI测试
以上列出的前四个技术都是基于判定语句（真/假），同时能大范围地找到相同类型的缺陷。
无论判定语句有多复杂，最终都能判定为真或假，从而可通过代码跟踪某一条路径。
当由于一个复杂的判定语句没有得到预期的结果，导致一条预定的路径没有被运行到，就能检测出缺陷。
总体来说，前四个技术逐次递进地体现全面性。
它们需要定义更多的测试以便达到预期的覆盖范围，同时能发现更多这种类型缺陷的例子。
2.2条件测试
在判定（分支）测试中将判定看作一个整体，测试用例分别评估真和假的结果，而条件测试考虑的是在判定中的单个简单的“原子”条件。
每个判定语句是由一个或多个简单的“原子”条件组成，而每个“原子”条件能计算出一个布尔值（真/假），这些值的逻辑组合便得出判定的最终结果。
测试用例必须评估每个原子条件的两个方向（真和假），以达到覆盖率的要求。
适用性
由于下述（局限性/难点）的难点，条件测试可能只限于在理论上的研究。
然而，理解条件测试对于建立在它基础上，达到更高级别的覆盖非常有必要。
局限性/难点
当一个判定中存在两个或两个以上的原子条件，在测试设计过程中，如果没有很好地选择测试数据，会导致只达到条件覆盖而没有达到判定覆盖。
举例来说，假定一个判定谓词，“AandB”。
A
B
AandB
测试1
假
真
假
测试2
真
假
假
为了达到100%的条件覆盖，运行以上表格中的两个测试。
当这两个测试能达到100%的条件覆盖的时候，它们并不能达到判定覆盖，因为在两种情况下，语句都是假。
当一个判定只有单个的原子条件，条件测试等同于判定测试。
2.3判定条件测试
判定条件测试明确要求测试必须达到条件覆盖（见上），同时，也要求满足判定覆盖（见初级大纲[ISTQB®
_FL_SYL]）。
在不需要增加额外的测试用例以达到条件覆盖的情况下，对原子条件的测试数据值做出的慎重的选择可以达到这一覆盖要求。
下面的例子测试了与前面相同的判定语句，“AandB”。
通过选择不同的测试值，运用相同数目的测试可以获得判定条件覆盖。
A
B
AandB
测试1
真
真
假
测试2
假
假
假
因此，这种技术可能会有效率方面的优势。
适用性
这种覆盖级别应该适用于测试比较重要的，但还不是至关重要/关键的代码。
局限性/难点
此技术由于测试过程中需要比判定覆盖更多的测试用例，当时间很紧迫时，就可能存在困难。
2.4改进的条件/判定覆盖（MC/DC）测试
这种技术提供了一个更强的控制流覆盖级别。
假设在N个单独的原子条件下，MC/DC通常可以得到N+1个单独的测试用例。
MC/DC实现了判定条件覆盖，但是需要满足以下条件：
1.至少在一个测试中，判定结果会随着原子条件X是否为真而改变
2.至少在一个测试中，判定结果会随着原子条件X是否为假而改变
3.每个不同的原子条件有满足条件1和2的测试
A
B
C
（AorB）andC
测试1
真
假
真
真
测试2
假
真
真
真
测试3
假
假
真
假
测试4
真
假
假
假
上述例子中不仅达到了判定覆盖（判定语句的结果不仅有为真，也有为假），同时也达到了条件覆盖（A，B和C可以计算得到真和假）。
在测试1中，A是真，输出是真。
如果将A改成假（如测试3中所示，保持其它值不变），结果会变成假。
在测试2中，B是真，输出是真。
如果将B改成假（如测试3中所示，保持其它值不变），结果会变成假。
在测试1中，C是真，输出是真。
如果将C改成假（如测试4中所示，保持其它值不变），结果会变成假。
适用性
这种技术广泛应用于航天和航空软件产业和其它安全关键系统中。
它通常用于测试安全关键的软件，因为在这类软件中，任何一个失效会带来巨大灾难。
局限性/难点
当一个表达式中某个特定的项多次出现时，要达到MC/DC覆盖变得较为复杂，而在这种情况中一个在表达式中多次出现的项称为“耦合”项。
根据代码中的判定语句，可能无法仅通过改变耦合项的值去改变判定的输出结果。
解决此问题的方法之一是只针对非耦合的原子条件进行MC/DC级别测试，另外一种方法是基于对每个含有耦合项的判定根据实际情况进行分析。
某些编程语言和/或解释器被设计成当它们在评估代码中一个复杂的判定语句时，它们会采用缩短的决策行为。
也就是说，如果最终的评估结果可以由部分表达式的评估结果来决定，则执行代码无需评估整个表达式。
例如，如果要计算判定结果“AandB”，假如已知A是假，那么就没有必要去计算B。
不管B是什么值都不能改变最终值，所以代码可以通过不计算B来减少执行时间。
这种缩短的决策行为可能会影响MC/DC覆盖的能力，因为一些为了满足覆盖要求的测试可能无法执行。
2.5复合条件测试
在极少数情况下，可能需要测试所有可能的判定内所包含的真/假数值组合。
这种穷尽级别的测试被称作复合条件覆盖。
所需的测试数目依赖于判定语句中的原子条件个数，同时该测试数目可以由计算2的n次方来确定，n是未耦合的原子条件个数。
运用之前提及的相同例子，需要以下测试来实现复合条件覆盖：
A
B
C
（AorB）andC
测试1
真
真
真
真
测试2
真
真
假
假
测试3
真
假
真
真
测试4
真
假
假
假
测试5
假
真
真
真
测试6
假
升级会员 