ISTQB高级技术测试分析师大纲.docx
《ISTQB高级技术测试分析师大纲.docx》由会员分享，可在线阅读，更多相关《ISTQB高级技术测试分析师大纲.docx（55页珍藏版）》请在冰点文库上搜索。
ISTQB高级技术测试分析师大纲
1、技术测试分析师在基于风险得测试中得任务 － ３0分钟、
关键词
产品风险（prｏductｒiｓｋ）、风险分析（risk analyｓis）、风险评估（ｒisｋaｓｓesｓment）、风险识别（risｋ
iｄentificａｔiｏn）、风险级别（riｓklｅvel）、风险缓解（ｒiskmitiｇation）、基于风险得测试（risk-based
testinｇ）
技术测试分析师在基于风险得测试中得任务相关得学习目标
1、3 风险评估
TTA－１、3、1 （K2） 总结技术测试分析师需要考虑得、典型得风险因素
通用得学习目标
ＴＴA－1、ｘ、1 （K2）总结在基于风险得测试方法中,技术测试分析师在测试计划与测试执行过程中得相关活动。
１、1简介
测试经理具有建立与管理基于风险得测试策略得全面责任。
测试经理往往要求技术测试分析师得介入以确保正确执行基于风险得方法。
由于其独有得技术特长，技术测试分析师与以下基于风险得测试任务密切相关:
●风险识别
●风险评估
●风险缓解
为了处理出现得产品风险与变更优先级,以及定期地评估与沟通风险状态,以上任务会迭代地贯穿在整个项目中。
技术测试分析师在由测试经理为项目制定得、基于风险得测试框架中工作。
她们贡献出与项目内在密切相关得技术风险知识,比如安全相关得风险、系统可靠性与性能相关风险。
1、2风险识别
在风险识别过程中越广泛地接触各类项目干系人,能识别出最大数量得重大风险得可能性也就越大。
由于技术测试分析师掌握独特得专门技能,她们特别适合进行专家访谈,与同事头脑风暴以及分析当前与以前得工作经验来确定可能存在产品风险得区域。
特别地,技术测试分析师与其她技术同行（例如,开发人员、架构师、运维工程师）工作密切,有利于确定存在技术风险得区域。
识别得风险样本可能包括:
●性能风险（例如,在高负载条件下无法达到响应时间得要求）
●安全风险（例如,在安全攻击下泄露敏感数据）
●可靠性方面风险（例如,应用程序无法满足服务等级协议中指定得可用性）
与特定得软件质量特性相关得风险区域将在本大纲得相关章节中介绍。
1、3风险评估
风险识别致力于鉴别尽可能多得相关风险,而风险评估旨在研究这些识别得风险以便于更好地进行风险分类并确认风险得可能性与影响程度。
确认风险级别通常涉及为每个风险项评估发生得可能性及发生后带来得影响程度。
风险发生得可能性一般解释为当系统在测试条件下,一些潜在得问题真实存在得可能性。
技术测试分析师致力于发现与理解每个风险项潜在得技术风险，而测试分析师致力于理解当问题发生时带来得潜在商业影响。
通常需要考虑得因素包括:
●技术复杂度
●代码结构得复杂度
●项目干系人之间关于技术需求得冲突
●由开发组织得地理分布产生得沟通问题
●工具与技术
●时间、资源与管理压力
●缺少项目前期得质量保障
●技术需求得高变化率
●大量与技术质量特性相关得缺陷
●技术接口与集成相关问题
在风险信息已知得情况下， 技术测试分析师根据由测试经理建立得指导方针来建立风险级别。
举例来说，测试经理可能决定将风险级别划分为1到１0 之间得值,其中值1为最高风险。
１、4风险缓解
项目期间,技术测试分析师影响着测试如何响应所识别得风险。
这个影响主要包括以下几个方面:
●通过执行最重要得测试，实施测试策略与测试计划中所述得适当得缓解与应急活动来减少风险
●在项目开展过程中,收集额外得信息,并在此基础上评估风险;而且利用该信息来实施缓解行动,旨在减少先前识别与分析得风险得可能性与影响
2、基于结构得测试-２25分钟、
关键词
原子条件（aｔｏmiｃ conditiｏｎ）、条件测试（conditioｎtesｔing）、控制流测试（cｏｎtrol flｏwtestinｇ）、判
定条件测试（deｃision conditｉontesting）、复合条件测试（multiple cｏnditiontｅsｔｉng）、路径测试
（pathtesｔｉng）、短路/缩短（sｈort-ｃiｒcｕiting）、语句测试（ｓtａｔemｅnttestｉng）、基于结构得技术
（strｕcｔure－ｂａsｅdtｅcｈnique）
基于结构得测试学习目标
２、2 条件测试
TTA-2、2、1 （K２） 理解如何实现条件覆盖以及为何判定覆盖比条件覆盖更严谨
2、３判定条件测试
TTA-2、3、1（Ｋ3）应用判定条件测试得测试设计技术设计测试用例以达到规定得覆盖率
2、4改进得条件/判定覆盖（ＭC/ＤC）测试
ＴTA-2、4、1（K3）应用改进得条件/判定覆盖（MC/DC）测试得测试设计技术设计测试用例以达到规定得
覆盖率
2、5复合条件测试
TＴA-２、５、１（K3）应用复合条件测试得测试设计技术设计测试用例以达到规定得覆盖率
2、６路径测试
TTＡ-2、６、１（K3） 应用路径测试得测试设计技术来设计测试用例
2、7API测试
TTＡ-2、７、１ （Ｋ2）理解ＡPI测试得适用性以及它所能发现得各种缺陷
２、8选择一种基于结构得测试
TＴA-2、8、１（K4）基于特定得项目状况选择一种合适得基于结构得测试技术
2、1 简介
本章主要描述基于结构得测试设计技术,也被称作白盒测试或者基于代码得测试技术。
这种技术以代码、数据与架构以及/或者系统流程图作为测试设计得基础。
通过每一个具体得技术能系统化地导出测试用例,同时每个技术关注得就是所考虑得结构得特定方面。
该技术提供覆盖准则，这些准则必须经过测量,而且必须与每个项目或组织所定义得目标相关联。
达到全覆盖也并不意味着整个测试集就是完整得,而就是正在使用得技术对在考虑中得结构不再能提出任何有用得测试。
除了条件覆盖，本大纲中所考虑得基于结构得测试设计技术比初级大纲（ISTQB®＿ＦＬ＿SYL）中涉及得语句与判定覆盖技术更为严谨。
以下就是本大纲中涉及得技术:
●条件测试
●判定条件测试
●改进得条件/判定覆盖（MC/DC）测试
●复合条件测试
●路径测试
●ＡPI测试
以上列出得前四个技术都就是基于判定语句（真/假），同时能大范围地找到相同类型得缺陷。
无论判定语句有多复杂，最终都能判定为真或假,从而可通过代码跟踪某一条路径。
当由于一个复杂得判定语句没有得到预期得结果,导致一条预定得路径没有被运行到,就能检测出缺陷。
总体来说,前四个技术逐次递进地体现全面性。
它们需要定义更多得测试以便达到预期得覆盖范围，同时能发现更多这种类型缺陷得例子。
2、2条件测试
在判定（分支）测试中将判定瞧作一个整体，测试用例分别评估真与假得结果,而条件测试考虑得就是在判定中得单个简单得“原子”条件。
每个判定语句就是由一个或多个简单得“原子”条件组成,而每个“原子”条件能计算出一个布尔值（真/假）,这些值得逻辑组合便得出判定得最终结果。
测试用例必须评估每个原子条件得两个方向（真与假）,以达到覆盖率得要求。
适用性
由于下述（局限性／难点）得难点,条件测试可能只限于在理论上得研究。
然而,理解条件测试对于建立在它基础上,达到更高级别得覆盖非常有必要。
局限性/难点
当一个判定中存在两个或两个以上得原子条件,在测试设计过程中,如果没有很好地选择测试数据,会导致只达到条件覆盖而没有达到判定覆盖。
举例来说,假定一个判定谓词,“Aand B”。
A
B
A andB
测试1
假
真
假
测试2
真
假
假
为了达到１0０%得条件覆盖，运行以上表格中得两个测试。
当这两个测试能达到1００%得条件覆盖得时候,它们并不能达到判定覆盖，因为在两种情况下,语句都就是假。
当一个判定只有单个得原子条件,条件测试等同于判定测试。
2、3判定条件测试
判定条件测试明确要求测试必须达到条件覆盖（见上）,同时,也要求满足判定覆盖（见初级大纲［ISTＱB®
_FL＿ＳYL]）。
在不需要增加额外得测试用例以达到条件覆盖得情况下,对原子条件得测试数据值做出得慎重得选择可以达到这一覆盖要求。
下面得例子测试了与前面相同得判定语句,“Ａ andＢ”。
通过选择不同得测试值,运用相同数目得测试可以获得判定条件覆盖。
Ａ
B
Aａnd B
测试1
真
真
假
测试2
假
假
假
因此,这种技术可能会有效率方面得优势。
适用性
这种覆盖级别应该适用于测试比较重要得，但还不就是至关重要／关键得代码。
局限性/难点
此技术由于测试过程中需要比判定覆盖更多得测试用例,当时间很紧迫时,就可能存在困难。
2、4 改进得条件/判定覆盖（MC/DC）测试
这种技术提供了一个更强得控制流覆盖级别。
假设在N个单独得原子条件下,MC/DＣ通常可以得到N＋1 个单独得测试用例。
MC/DＣ实现了判定条件覆盖,但就是需要满足以下条件:
1、 至少在一个测试中,判定结果会随着原子条件Ｘ就是否为真而改变
2、至少在一个测试中,判定结果会随着原子条件Ｘ 就是否为假而改变
3、每个不同得原子条件有满足条件１与2得测试
A
Ｂ
Ｃ
（A oｒＢ）anｄC
测试1
真
假
真
真
测试2
假
真
真
真
测试３
假
假
真
假
测试4
真
假
假
假
上述例子中不仅达到了判定覆盖（判定语句得结果不仅有为真,也有为假）,同时也达到了条件覆盖（A,Ｂ与C可以计算得到真与假）。
在测试１中，A就是真,输出就是真。
如果将Ａ改成假（如测试3 中所示,保持其它值不变）,结果会变成假。
在测试２中,B 就是真,输出就是真。
如果将B改成假（如测试３中所示，保持其它值不变）,结果会变成假。
在测试１中,C就是真,输出就是真。
如果将C改成假（如测试4 中所示,保持其它值不变），结果会变成假。
适用性
这种技术广泛应用于航天与航空软件产业与其它安全关键系统中。
它通常用于测试安全关键得软件,因为在这类软件中,任何一个失效会带来巨大灾难。
局限性／难点
当一个表达式中某个特定得项多次出现时,要达到ＭC/ＤC覆盖变得较为复杂，而在这种情况中一个在表达式中多次出现得项称为“耦合”项。
根据代码中得判定语句,可能无法仅通过改变耦合项得值去改变判定得输出结果。
解决此问题得方法之一就是只针对非耦合得原子条件进行MC／DC级别测试，另外一种方法就是基于对每个含有耦合项得判定根据实际情况进行分析。
某些编程语言与/或解释器被设计成当它们在评估代码中一个复杂得判定语句时,它们会采用缩短得决策行为。
也就就是说,如果最终得评估结果可以由部分表达式得评估结果来决定,则执行代码无需评估整个表达式。
例如,如果要计算判定结果“AａnｄB”,假如已知A就是假,那么就没有必要去计算B。
不管Ｂ就是什么值都不能改变最终值,所以代码可以通过不计算B来减少执行时间。
这种缩短得决策行为可能会影响MＣ/DC覆盖得能力,因为一些为了满足覆盖要求得测试可能无法执行。
2、５复合条件测试
在极少数情况下,可能需要测试所有可能得判定内所包含得真 ／假数值组合。
这种穷尽级别得测试被称作复合条件覆盖。
所需得测试数目依赖于判定语句中得原子条件个数,同时该测试数目可以由计算２ 得n 次方来确定,n就是未耦合得原子条件个数。
运用之前提及得相同例子,需要以下测试来实现复合条件覆盖：
A
B
C
（A oｒB）ａｎｄＣ
测试1
真
真
真
真
测试2
真
真
假
假
测试3
真
假
真
真
测试4
真
假
假
假
测试5
假
真
真
真
测试6
假
真
假
假
测试７
假
假
真
假
测试8
假
假
假
假
如果语言中使用了缩短得决策方法,实际得测试用例数目经常因作用于原子条件上得逻辑运算符得顺序与分组而减少。
适用性
这种测试技术历来被用于测试嵌入式软件,因为这种软件需要确保其运行在很长一段时间内得稳定可靠与不崩溃（例如:
电话交换机期望能持续30年）。
在大部分关键应用程序中,这种类型得测试很可能会被MC/DC测试所取代。
局限性/难点
因为测试用例得数目可以直接通过包含了所有原子条件得真值表计算得出,所以能容易地确定这个级别得覆盖。
然而,这种方法所需得测试用例得绝对数量非常庞大，使得MC/DＣ覆盖更适用于大多数情况。
2、6路径测试
路径测试包括识别贯穿于代码中得路径,然后创造相关测试来覆盖这些路径。
原则上,测试每一条贯穿于系统得独特路径都就是非常有用得。
然而,在任何重要系统中,由于代码中存在循环而使得测试用例得数目会变得相当庞大。
尽管如此，如果将无限循环得问题放置一边,实行路径测试还就是现实得。
为了应用这种技术,[Beiｚer９０]建议沿着软件模块得入口到出口得尽可能多得路径去创建测试用例。
为了简化这个可能复杂得任务,她建议可以通过使用以下流程来系统化地实现路径测试:
1、 先挑选从入口到出口最简单得、有意义得功能得路径。
2、 挑选每条额外得路径作为之前路径得微小变异。
对于每个后续得测试，每个路径中尽可能只改变一个分支。
尽可能优先选择短得路径而不就是长得路径。
尽可能优先选择那些更有意义得功能路径,而不就是无意义得功能路径。
3、仅仅当要求覆盖率得时候，挑选那些无意义得功能路径。
Beizer在这条规则中加注，这样得路径可能就是不相关得且应该受到质疑得。
４、运用直觉来选择路径（也就就是说,哪条路径就是最可能被执行到得）。
注意,使用这种策略,可能会重复执行某些路径段。
这个策略得关键点就是代码中每个可能得分支至少测试过一次，也可能多次。
适用性
局部路径测试，如上述定义,往往在安全关键软件中实行。
这对本章中介绍得其它方法就是一个很好得补充，因为它着眼于贯穿软件得路径而不仅仅就是单个得判定。
局限性/难点
虽然有可能使用控制流程图来确定路径，在现实中还就是需要利用工具对复杂模块得路径进行计算。
覆盖率
创建足够得测试来覆盖所有路径（不考虑循环），这也已经保证达到了语句与分支覆盖。
与分支测试相比较，路径测试仅增加相对少得测试数目，却提供了更彻底得测试。
［NISＴ96]
２、7APＩ测试
应用程序接口（ＡＰI）就是使不同进程、程序与/或系统之间得通信成为可能得代码。
ＡＰI 经常应用于客户／服务器端中,在这种关系中，一个进程给其它进程提供某种功能。
从某些方面来瞧,APＩ测试与测试图形用户界面（GUI）相当类似。
重点就是评估输入值与返回数据。
逆向测试在与API 打交道时往往至关重要。
程序员在使用ＡPI访问外部服务时，可能会使用不同于设计者预期得方式来调用AＰＩ接口。
这也意味着,强大得错误处理能力在避免不正确操作方面就是必不可少得。
因为API 经常与其它API结合使用,同时也因为单个接口可能包含多个参数,而这些参数值可能以不同方式组合，所以多种不同接口得组合测试可能就是必须得。
由于API之间经常松散耦合,会导致实际得事务丢失或时序问题,这使恢复与重试机制得全面测试成为必要。
提供API 接口得组织必须确保所有得服务具有非常高得可用性。
这往往需要由AＰI 发布者与基础构架支持者提供严格得可靠性测试。
适用性
因为越来越多得系统变成分布式得或使用远程处理来分摊一部分工作给其它处理器,AＰI 测试也变得越来越重要。
例子包括操作系统调用、面向服务架构（SOA-Ｓeｒvｉcｅ-OｒｉenｔedArcｈitｅcturｅ）、远程过程调用（RPC-Rｅｍote PｒocedureＣalｌs）、Ｗeb 服务以及几乎所有其它得分布式应用程序。
ＡPI 测试尤其适用于综合系统（sｙｓtemｏｆ systems）得测试。
局限性/难点
直接测试APＩ往往要求技术测试分析师使用专门得工具。
通常情况下API不提供直接得图形界面,可能需要工具来设置初始环境、数据编组处理、执行APＩ得调用与确定结果。
覆盖率
API 测试就是一种测试类型得描述。
它不代表任何特定得覆盖级别。
在API测试中不仅至少应该执行所有APＩ调用,而且还应该使用所有得有效值与所有合理得无效值。
缺陷类型
通过测试ＡＰI往往能发现各种不同类型得缺陷,经常涉及到得有接口问题、数据处理问题或时序问题以及事务丢失或交易重复。
２、８基于结构技术得选择
被测试系统得实际情况决定应达到得基于结构测试得覆盖级别。
越重要得系统需要越高级别得覆盖。
一般情况下,所需得覆盖级别越高,也需要更多得时间与资源来达到该覆盖级别。
有时候，所需得覆盖级别可能就是从应用于软件系统得适用标准衍生而来。
例如，假如一款软件就是应用于航空电子设备中，它可能被要求符合标准DO-178B（或欧洲标准EＤ-1２Ｂ）。
此标准包含了以下五种失效情况：
A、灾难得:
失效可能会导致飞机安全飞行或降落所需得关键功能得缺失
B、 危险得:
失效可能会对安全或性能有巨大得负面影响
C、 严重得：
失效（导致得影响）就是严重得,但就是严重程度低于A或Ｂ
Ｄ、轻微得:
失效（导致得影响）就是可察觉得,但就是比C影响小
E、 无影响：
失效不影响安全
如果软件系统属于A级,它必须达到ＭC／DＣ覆盖。
如果就是B 级,必须达到判定覆盖级别，但MＣ/DＣ就是可选得。
对于Ｃ级要求至少达到语句覆盖。
同样,IEＣ-６150８就是针对可编程得、电子得与安全相关得系统得功能安全而制定得国际标准。
这个标准已经适用于许多不同得领域,包括汽车、铁路、制造工艺、核电站与机械制造。
危险程度得定义使用一种分级得安全完整性等级（ＳIL－Sａfｅｔy IntｅgritｙLeｖeｌ）连续值（1就是最不关键，4就是最关键）。
推荐得覆盖如下：
1、建议语句与分支覆盖
2、 强烈建议语句覆盖,建议分支覆盖
3、强烈建议语句与分支覆盖
４、强烈建议MC／DＣ
在现代得系统中,极少出现所有处理都由一个单一得系统完成。
只要当一部分得任务就是在另一个系统上远程处理时，就应该进行AＰＩ测试。
系统得关键性决定了需要投入到AＰI测试中得开销。
通常,技术测试分析师应该根据被测软件系统得实际情况来选择基于结构得测试方法。
3、分析技术-2５5 分钟、
关键词
控制流分析（conｔｒoｌ ｆlowanａlysis）、圈复杂度（cycｌｏｍａticplexiｔy）、数据流分析（datａ floｗ
analysｉs） 、定义- 使用对（ｄefinitｉon－ｕsepａirs ）、动态分析（dynamｉcanaｌysis） 、内存泄漏
（mｅｍｏry lｅaｋ）、成对集成测试（pａirwｉｓｅｉｎtegratｉontｅｓting）、邻域集成测试（neiｇhbｏrhood
inｔegratioｎtestiｎg）、静态分析（statiｃanａｌysiｓ）、野指针（wｉldpｏiｎter）
分析技术学习目标
3、2静态分析
ＴTA-3、2、1 （K3）运用控制流分析来检测代码就是否存在控制流异常
TTA-３、2、2（Ｋ３）运用数据流分析来检测代码就是否存在数据流异常
ＴTA-3、2、3（K3） 提出运用静态分析得方法来提高代码得维护性
TTA-3、2、4（K２）解释调用图在建立集成测试策略中得作用
3、3动态分析
TTＡ－3、3、1（Ｋ3）列举运用动态分析所能达到得目标
3、１简介
有两种分析手段：
静态分析与动态分析。
静态分析（3、2节）包括可以无需执行软件而进行得分析测试。
由于没有执行软件，只能通过工具或者人工来检查软件在执行时就是否能正确工作。
软件得静态检查无需为场景得执行创建数据与前置条件就能进行详细得分析。
需要注意得就是,第五章包含与技术测试分析师相关得不同形式得评审。
动态分析（３、3 节）需要实际地执行代码。
动态分析经常用来寻找在代码被执行得时候更容易检测到得代码缺陷（例如,内存泄漏）。
与静态分析一样,动态分析也可以依靠工具或人工来监视系统执行,观察各项指标，例如内存得快速增长。
3、2 静态分析
静态分析得目标就是检测代码与系统架构中实际得或潜在得缺陷及提高其维护性。
静态分析通常有工具支持。
3、2、１控制流分析
控制流分析就是一种静态分析技术,借助于控制流图或使用工具来分析程序得控制流。
运用这种技术可以发现许多系统中得异常,包括设计不当得循环（例如,有多个入口点）、在某些语言（比如,Sｃhemｅ）中模棱两可得函数调用得目标、不正确得操作序列等。
控制流分析最常见得用途之一就是确定圈复杂度。
圈复杂度值就是一个正整数，这个正整数代表在强连通图中得独立路径数。
在连通图中,循环与迭代在被遍历一次后就被忽略。
每条独立得从入口到出口得路径代表了一条贯穿模块得独特路径。
每条独特得路径都应该进行测试。
圈复杂度通常就是用来理解一个模块整体得复杂程度。
根据Thomａs ＭcCabe得理论 ［McCaｂe７6］:
系统越复杂,就越难维护,且会包含更多得缺陷。
多年来许多研究指出复杂度与包含缺陷数目得相关性。
NＩSＴ（美国国家标准与技术研究所）建议以1０作为最大复杂度值。
任何以更高得复杂度来度量得模块可能需要被划分成多个模块。
3、2、2数据流分析
数据流分析包含了多种用以收集关于系统中变量使用信息相关得技术。
这里,对变量得生命周期（即,何处变量被声明了、被定义了、被读取了、被评估与被撤销了）进行详细得研究，因为异常可能发生于变量生命周期中得任何操作。
一种常见得技术叫做定义－使用符号,在这种技术中,每个变量得生命周期被分成三种不同得原子操作:
●·d（dｅｆiｎｅd）:
当变量被声明、定义或初始化
●·u（usｅd）:
当变量在计算或判定语句中被使用或读取
●·ｋ（kilｌeｄ） :
当变量被终止、撤销或者超出范围
这三个原子操作组合成对（定义-使用对）来说明数据流。
例如,一条“ｄu-路径”代表数据变量被定义随后使用得代码段。
可能得数据异常包括在错误得时间对变量进行正确得操作,或对变量中得数据进行不正确得操作。
这些异常包括：
●·给一个变量赋一个无效值
●· 在使用一个变量之前没有对其进行赋值
●·由于控制语句中不正确得值而采用了不正确得路径
●· 尝试使用已经撤销得变量
●·引用不在作用域内得变量
●·说明与撤销一个没有使用过得变量
●·重复定义一个已经在使用得变量
●·没有终止一个动态分配得变量（可能导致内存泄漏）
●·由于改变一个变量导致不可预期得副作用（如在改变一个全局变量得时候没有考虑该变量得所
有用途而引起得连锁反应）
正在使用得开发语言可以指导在数据流分析中所使用得规则。
编程语言可能允许程序员执行某些非法得变量操作,但这可能在某些情况下会引起系统得表现与程序员得预期有所不同。
例如，一个变量可能定义了两次，然而当跟随某条路径时该变量却没有实际使用。
数据流分析往往会标明这些使用“可疑”。
虽然这可能就是变量赋值能力得合法使用,但它会导致代码在将来得维护性问题。
数据流测试“使用控制流图去探索那些可能发生在数据上得不合理得事情”[Beiｚeｒ9０］，因此数据流测试能发现与控制流测试不同得缺陷。
技术测试分析师应该在计划测试时涵盖这种技术，因为大部分这些缺陷会引起动态测试时很难发现得间歇性缺陷。
然而数据流分析就是一种静态技术。
它可能错过在系统运行时发生在数据上得一些问题。
例如,静态数据变量可能包含一个指向
升级会员 