单元测试专业知识讲座省公共课一等奖全国赛课获奖课件.pptx

第六章第六章 单元测试单元测试单元测试对象是软件设计中最小单位模块。第1页本章内容提要 单元测试目标与内容单元测试目标与内容 单元测试环境单元测试环境 单元测试策略单元测试策略 单元测试过程单元测试过程第2页6.1 单元测试目标与内容单元测试目标 单元测试目标是检验每个模块是否正确地实现了设计说中功效、性单元测试目标是检验每个模块是否正确地实现了设计说中功效、性能、接口和其它设计约束要求，确保每个元都被正确地编码。能、接口和其它设计约束要求，确保每个元都被正确地编码。单元测试需要到达以下一些详细目标。信息能否正确地流入和流出单元；单元工作过程中，其内部数据能否保持完整性，包含 内部数据形式、内容及相互关系不发生错误，全局变量在单元中处理和影响；控制数据处理边界能否正确工作；单元运行能否做到满足特定逻辑覆盖；对于单元中发生错误，其犯错处理办法是否有效。第3页6.1 单元测试目标与内容单元测试内容 单元测试内容是对单元功效、性能、接 口、局部数据结构、独立路径、错误处理、边界条件和内存使用情况进行测试。对软件单元接口测试通常是先于其它内容测试进行。第4页6.1 单元测试目标与内容 对软件单元接口测试通常是先于其它内容测试进行，单元测试详细内容以下。（1）接口测试 对接口测试通常包含以下内容。被测单元调用子模块时，传递给子模块实参个数、类型、量纲和次序与其形参是否一致；测试单元被调用时，传递给被测单元实参加形参 个数、类型、量纲和次序与其形参是否一致；调用内部函数参数个数、类型、量纲、次序是否正确；被测单元对全局变量使用是否与其定义一致；作为输入值形式参数是否被修改；第5页6.1 单元测试目标与内容 被测单元有多个入口时，是否传递了与当前入口无关参数；输入/输出语句是否与输入/输出格式说明一致；输入/输出文件属性正确性；是否对输入/输犯错误进行了检验并进行了正确处理；是否将常量当变量来传递；打开和关闭语句是否正确使用；文件是否先打开后使用；文件结束条件判断和处理是否正确；缓存区容量与统计长度是否匹配。第6页6.1 单元测试目标与内容（2）局部数据结构测试 测试单元内部数据内容、格式及相互关系以及它们完整性。设计测试用例以检验以下错误。数据类型说明不正确或不一致；检测是否存在变量名拼写错误情况；是否存在未赋值默认值；是否存在指针越界访问；是否存在上溢、下溢或地址访问错误；检验全局数据对软件单元影响。第7页6.1 单元测试目标与内容（3）独立路径测试 最少包含一条新处理语句或一个新条件程序路径叫独立路径。在程序流图中，独立路径最少包含一条其它独立路径中没有边。基本路径是经过对程序流图中环路复杂度进行分析而导出基本、可执行独立路径集合。应该设定适当测试用例对软件单元中独立路径进行测试，尤其是对独立路径中基本路径进行测试。（4）边界条件测试 边界条件测试检验软件单元在边界处工作是否正 常，主要检验以下情况。检验n重循环第0次。第1次和第n次是否有错；检验n维数组第1个和第n个元素是否有错;第8页6.1 单元测试目标与内容 在运算或判断中最大取值与最小取值是否有错；数据流、控制流或判断条件中刚好小于、等于、大于比较值时是否有错。（5）错误处理测试 错误处理测试主要检验软件单元对执行过程中发生错误是否进行了有效处理。优异程序设计要求开发人员能够预见到程序运行后可能发生错误，并作出适当处理。对错误处理应该成为单元功效一部分。假如检验出现以下情况，说明错误处理存在缺点。对执行中发生意外情况没有进行处理或处理不妥；对错误条件判定不妥；对错误发生描述难以了解；对联机条件处理不正确；错误提醒与实际错误不匹配；对错误处理意见对用户没有帮助；第9页6.1 单元测试目标与内容 对错误描述信息不足以确定产生错误位置或原因；在对错误进行处理前，系统已经对错误进行了干预。（6）功效测试 功效测试要求对设计文档中罗列软件单元功效进行逐项测试。（7）性能测试 按照设计文档要求对软件单元性能（如精度、时间、容量等）进行测试。（8）内存使用测试 主要检验内存使用情况，重点检验动态申请内存是否存在错误（包含指针使用越界，对空指针赋值，内存泄漏等）。第10页6.2 单元测试环境6.2.1 驱动模块和桩模块定义 驱动模块（driver）是一个用于模拟被测试模块上一级模块，相当于被测模块主程序。它接收数据，将相关数据传送给被测试模块，并调用被测试模块，打印执行结果。设计驱动模块目标就是为了访问类库属性和方法，检测类库功效是否正确。第11页6.2 单元测试环境 桩模块（Stub）是模拟被测试模块所调用模块，它不是软件产品组成部分。在集成测试前要为被测模块编制一些模拟其下级模块功效“替身”模块，以代替被测模块接口，接收或传递被测模块数据，这些专供测试用“假”模块称为被测试模块桩模块。假如被测试单元模块需要调用其它模块中功效或者函数（method），就应设计一个和被调用模块名称相同桩模块来模拟被调用模块。这个桩模块本身不执行任何功效，仅在被调用时返回静态值来模拟被调用模块行为。第12页6.2 单元测试环境6.2.2 驱动模块和桩模块使用条件驱动模块使用条件以下。（1）必须要驱动被测试模块执行；（2）必须能够正确接收要传递给被测试模块各项参数；（3）能够对接收到参数正确性进行判断；（4）能够将接收到数据传递给被测模块；（5）必须接收到被测试模块执行结果，并对结果正确性进行判断；（6）必须能够将判断结果作为用例执行结果输出测试汇报。第13页6.2 单元测试环境桩模块使用条件以下。（1）被测试模块必须要调用桩模块；（2）必须能够正确接收来自被测试模块传递各项参数；（3）桩模块要能够对接收到参数正确性进行判断；（4）桩模块对外接口定义必须要符合被测试模块调用说明；（5）桩模块必须要向被测试模块返回一个结果。第14页6.2 单元测试环境6.2.3 驱动模块和桩模块设计 在进行单元测试时，单元模块本身无法组成一个完整且切实可行程序系统，所以我们需要为单元测试设计桩模块和驱动模块，从而到达单元测试目标。为了了解桩模块和驱动模块，首先必须解释渐增式和非渐增式联调。将若干个模块连接成一个可运行系统通常有两种方式：一个是“非渐增式”，即先独立地测试每一模块，然后将全部这些模块连接到一起运行；另一个是“渐增式”，即在已测试过N个模块基础上再增加一个模块，实现对第N+1个模块测试。第15页6.2 单元测试环境 图6-1所表示为一个模块实例结构图。采取非渐增式测试会先分别测试A、B、C、D、E、F、G七个模块，然后再将这七个模块连接到一起再进行测试。若用这种方式，在测试某个模块X时，需要为它设计一个驱动模块和若干个桩模块（图6-2）。驱动模块作用是模拟X上层模块，桩模块作用是模拟X下层模块。比如测试图6-1模块D时，要为它设计一个驱动模块，其作用是将测试数据传送给模块D，并显示D产生结果，另外，因为模块D要调用模块F和G，所以还需设计两个名字分别为F和G桩模块，它们将接收D控制并模拟F和G功效。第16页6.2 单元测试环境 图6-1 模块实例结构图 图6-2 驱动模块与桩模块示例图第17页6.2 单元测试环境 另一个方式是渐增式，若用渐增方式，模块测试和联合测试这两步是结合起来进行。渐增式又有“由顶向下”、“由底向上”两种。对图6-1程序若采取“由底向上”方式，则是先次序地或并行地测试模块B、E、F、G，此时需为B和E模块各准备一个驱动模块，为F、G模块共同准备一个驱动模块，但无须为它们准备桩模块，然后为C准备一个驱动模块将C与E连接起来测试，又为D准备一个驱动模块将D和F、G连接起来测试，这个过程将连续到测试最终一个模块A。第18页6.2 单元测试环境渐增式与非渐增式比较以下。（1）非渐增式需要较多人工参加，以图6-1为例，采取非渐增式共需准备6个驱动模块和6个桩模块（假定A不需要驱动模块，B、E、F、G不需要桩模块）。而用渐增式，假如是“由顶向下”则可利用前面已测试过上层模块，而无须另外准备驱动模块，假如是“由底向上”，也可利用已测式过下层模块，无须再准备桩模块。对图6-1来说，如用“由顶向下”方式则只需要6个桩模块而不要驱动模块，如用“由底向上”方式则只要6个驱动模块而不需要桩模块。（2）渐增式能够较早地发觉模块界面之间错误，非渐增式则要到最终将全部模块连接起来时才能发觉这类错误。第19页6.2 单元测试环境（3）当模块界面间有错时，采取非渐增式测试，这类错误要到最终联合测试时才能发觉，此时极难判断错误发生在程序哪一部分；但假如用渐增式，这类错误就较轻易定位，它通常与最新加上去那个模块相关。（4）渐增式比较全方面。对图6-1采取渐增式测试例子中，在测试模块C时，模块A（由顶向下方式）或模块E（由底向上方式）也要再次执行，即使A或E前面已测试过，但与模块C连接起来可能又会产生新条件，而这些条件在分别测试 A或 E时可能是被遗漏。换句话说，渐增式以前面测试过模块作为驱动模块或桩模块，所以这些模块将得到深入检验。第20页6.2 单元测试环境（5）渐增式测试需要花费较多机器时间。以图6-1为例，如采取自底向上渐增式测试，在检测模块A时，模块B、C、D、E、F、G也要执行，若用非渐增式，在测试模块A时，只需执行模拟B、C、D桩模块。类似地，如采取自顶向下渐增式测试，在检测模块F时，模块A、B、C、D、E可能都要执行，而用非渐增式，则只需执行模块F本身以及它驱动模块。所以整个测试过程中，渐增式所花费机器时间比非渐增式多。（6）使用非渐增方式测试，在开始时允许几个测试并行工作，这对大型系统来说，是很有意义。总体来说，第（1）（4）点是渐增式测试优点，第（5）、（6）点是渐增式测试短处。自顶向下渐增式测试首先测试顶模块（主模块），下一步再测试哪个模块则有各种选择，唯一限制是：该模块调用模块中最少有一个已测试过了。自底向上渐增式测试首先测试最底层模块，下一步再测试哪个模块则有各种选择，唯一限制是：该模块全部下层模块都已测试过了。第21页6.2 单元测试环境自顶向下与自底向上渐增式测试比较以下。（1）用自底向上渐增式测试时，需要为每个模块准备一个驱动模块，它作用是调用被测试模块，包含设置输入参数、显示输出结果（或将实际输出与预期输出做比较）。普通说来，驱动模块作用是比较标准，编写驱动模块比编写桩模块轻易，能够用自开工具来实现。而自顶向下渐增式测试需要为每个测试模块准备桩模块作用很多，与被测试模块接口经常比较复杂，经常需要人工参加。（2）进行自底向上渐增式测试所写驱动模块直接与被测试模块联络，所以不用担心有其它模块介入问题；进行自顶向下渐增式测试所写桩模块轻易受到其它桩模块作用影响，如其它桩模块修改与当前桩模块共用全局变量、数据库内容等。所以必须全方面考虑各个桩模块之间关系。第22页6.2 单元测试环境（3）自底向上测试方式不能像由顶向下测试方式那样，在测试中途取得一个程序框架，因为由底向上方式程序框架要到测试最终一个模块（顶模块）时才能形成，到程序框架形成时测试实际上就是对整个程序测试。决定测试次序基本标准有两条。（1）尽早测试关键模块。所谓关键模块是指较为复杂、较可能犯错或含有较新算法模块。（2）尽早测试包含输入/输出操作模块。因为这些模块被测试后，向程序送入测试数据以及检验输出结果就方便了。下面分别就驱动模块与桩模块编写举两个实际例子。第23页6.2 单元测试环境下面是驱动模块例子。C:UsersNalaDesktop新建文件夹新建文本文档.txt那么经过TCL进行扩展指令编写时，针对该被测函数，能够编写驱动模块以下：C:UsersNalaDesktop新建文件夹新建文本文档(2).txt下面是桩模块例子：创建一个Buffer文件管理表。C:UsersNalaDesktop新建文件夹新建文本文档(3).txt我们现在为HashTable_Create()函数编写桩模块，模拟HashTable_Create()函数失败情况，能够编写下面这个简单桩模块。C:UsersNalaDesktop新建文件夹新建文本文档(4).txt第24页 6.3 单元测试策略6.3.1 静态与动态结合测试 单元测试是早期测试，最好在代码编译经过后就开始做单元测试。单元测试与静态分析并不冲突，能够同时进行。实际上，单元测试本身就应包含静态分析内容，单元测试多项内容使用静态分析比使用动态测试更轻易也更充分，所以不能将单元测试简单地等同于动态测试。单元测试是一个静态测试与动态测试相互配合白盒测试其中用到了代码规则检验、代码 第25页6.3 单元测试策略6.3.2 单元测试覆盖率 在实际单元测试中，不一样软件对覆盖率有不一样要求，单纯追求测试用例覆盖率方法并不可取，而是应该按照分类推理法、元素分析法、规格导出法、边界值法、等价类分法和随机数法等来设计测试用例。1语句覆盖 语句覆盖指是代码中全部语句都最少执行一遍，用于检验测试用例是否有遗漏，假如检验出存在没有执行到语句时，就需要增加测试用例来将全部语句覆盖到。语句覆盖能够经过测试覆盖率工具，如TrueCoverage、PureCoverage等来检验。语句覆盖率是指被执行语句数占总语句数百分比。标准上讲，单元测试中语句覆盖率必须到达100%，尤其是对一些对质量要求较高软件，如电信设备软件、航天软件、医用设备软件等，就要求软件中全部语句都必须执行到；对质量要求不高软件，依据实际项目情况，语句覆盖率也应到达90%以上，不然单元测试效果会大打折扣。第26页6.3 单元测试策略2判断覆盖判断覆盖是指对被测试模块中每一个判断要分别取真和假各一次进行测试。判断覆盖是单元测试中很惯用一类覆盖，利用判断覆盖能够检验测试用例设计是否完整，判断覆盖标准普通都要到达。3条件覆盖条件覆盖是指程序中每个判断中每个条件全部可能取值全部组合情况最少都执行一次，是一个比判断覆盖更严格覆盖。4路径覆盖路径覆盖是指测试用例中执行到路径数量占被测试模块全部可能执行路径比率。在路径覆盖中，我们只考虑全部可能执行路径，对于不可能执行路径，我们是不需要考虑。而且对于一些大型程序，其包含路径总量是非常庞大，假如要把全部路径都找出来去覆盖也是不现实。所以我们可借助以下一些方法来寻找程序中路径。第27页6.3 单元测试策略（1）单个判断语句路径计算单个判断语句中，路径只有两条，一条是判断条件为真，另一条是判断条件为假。在不考虑判断分支中路径分支时，路径数与判断分支数相等。（2）单个循环语句中路径计算在循环语句中，通常循环每次迭代都可看做是一条路径，但这么计算出路径测试工作量太大，所以经过以下方式简化循环中路径计算。当循环中条件一定会满足，循环内语句一定会执行时，循环语句中可能执行路径可看做一条。如以下循环语句。int i,j,sum=0;for(i=1;j=10;i700&x800)sum=sum+x;x+;上面循环中，当x700时，循环不执行，所以可能执行路径有两条。第29页6.3 单元测试策略 当循环过程中有可能中止时情况。如以下循环语句。int sum(int maxnum)int sum=0;for(i=0;i maxnum)Break;return sum;第30页6.3 单元测试策略 上面这段程序，在循环每次迭代都有两种可能，一个是满足判断条件，一个是不满足判断条件，由参数maxnum决定，所以可将路径数量简化到61条，其中60条是for循环中每个迭代中判断条件都满足情况，1条是for循环内语句没有被执行情况。实际上，程序中可能执行路径总数小于等于输入参数等价类全部组合数量，上例中sum()函数输入参数实际上有61个等价类，可能执行路径数量也是61条。第31页6.3 单元测试策略（3）有嵌套判断或循环时路径计算下面是有嵌套判断语句例子。if(a 6)if(b 23)return b;return a;else return c;对以上程序路径统计，先计算出if中路径2条，再计算else中路径。第32页6.3 单元测试策略5函数覆盖函数覆盖主要是评定在进行测试时函数执行比率，函数覆盖率用下面公式计算：函数覆盖率=最少执行到一次函数数量/被测试系统中函数总数量从公式能够看出函数覆盖率是一个比语句覆盖率更简单覆盖，主要是用来检验哪些单元没被执行，预防遗漏对一些单元测试。6Z路径覆盖Z路径覆盖是路径覆盖一个变种，对路径进行了简化，主要是针对循环而言，按Z路径覆盖观点，一个循环不论其循环了多少次，只有执行和未执行循环两种情况，也就是说一个循环被看成最多只有两条路径。第33页6.3 单元测试策略按此方法简化循环后，整个程序中路径数目将大大降低，能够将整个程序路径画成路径树，然后依据树上叶子节点来得到程序路径，从根节点到叶子节点进行遍历，当全部叶子节点被遍历完成后，就能得到全部路径。这些路径被称为Z路径，然后为全部路径生成测试用例进行测试，就做到了Z路径覆盖测试。7ESTCA覆盖ESTCA覆盖是K.A.Foster受硬件领域测试方法启发而提出一个经验测试覆盖准则，其最关键部分是一套错误敏感测试用例分析规则ESTCA（Error Sensitive Test Cases Analysis）。规则1：对于A rel B（rel能够是）型分支谓词，应适当选择A与B值，使测试执行到该分支语句时，A B情况分别出现一次。这条规则能够有效地检测逻辑符号是否写错，比如将大于号“”错写成小于号“”.第34页6.3 单元测试策略规则2：对于A rell C（rell能够是，A是变量，C是常量）型分支谓词，当rell为“”时，应适当地选择A，使A=C+M。这条规则主要用于检验程序中差1型错误。规则3：对外部输入变量赋值，使其在每一个测试用例中都有不一样值与符号，并与同一组测试用例中其它变量值与符号不一致。这条规则主要用于检测变量赋值错误情况，比如将一个变量值错误地赋给另外一个变量，能有效地发觉软件变量初始化时错误。满足这几个规则测试用例设计主要能够采取等价类分法和边界值法，各个等价类中取值只要不重复即可满足规则3要求。第35页6.3 单元测试策略8线形代码序列与跳转（LCSAJ）覆盖 LCSAJ覆盖（Linear Code Sequence and Jump Coverage）是Woodward等人提出来一套覆盖率准则，实际上可看做是路径覆盖一个变型。一个LCSAJ其实是一组次序执行代码，它以控制流跳转作为其结束点。它起点是由程序本身决定。起点能够是程序第一行（入口）或转移语句入口点，也能够是控制流可跳转点。一个LCSAJ可能结束于程序出口，也可能结束于一个造成控制流跳转点。假如有几个LCSAJ首尾相接，且第一个LCSAJ起点为程序起点，最终一个LCSAJ终点为程序终点，这些LCSAJ串就组成了程序一条路径（LCSAJ路径）。一条LCSAJ路径可能是由2个、3个或多个LCSAJ组成。第36页6.3 单元测试策略 LCSAJ覆盖准则是一个分层覆盖准则，详细介绍以下。第一层：语句覆盖。第二层：分支覆盖。第三层：LCSAJ覆盖。即程序中每一个LCSAJ最少都在测试中经历过一次。第四层：两两LCSAJ覆盖。程序中每两个首尾相连LCSAJ组合起来在测试中都要经历一次。.第n层：每n个首尾相连LCSAJ组合在测试中都经历一次。LCSAJ覆盖显然比判断覆盖复杂得多，但LCSAJ自动化相对来说比较轻易。LCSAJ覆盖缺点在于当模块发生改变时，维护工作量非常大。优点在于LCSAJ覆盖强度比判断覆盖强度要高，所以到达LCSAJ100%覆盖标准要比到达100%判断覆盖发觉更多问题。第37页6.3 单元测试策略 编写完测试用例进行测试时，假如发觉其覆盖率不能到达100%，如只能到达85%，此时测试人员和开发人员就应该共同对测试用例代码进行审查，经过审查确认剩下15%未覆盖代码终究是因为测试用例不充分还是因为其是不可达代码，以至不能被测试。假如是前者，就需要测试人员重新编制测试用例，实现对测试代码全覆盖，假如是后者，就需要开发人员将不可达代码删除。近年来，很多测试大型项目验收将MC/DC（Modified Condition/Decision Coverage）覆盖作为了其一项主要指标。MC/DC（Modified Condition/Decision Coverage）修改条件/判定覆盖是DO-178B（美军标）中首次提出，最初是为了提升航空软件测试中覆盖率水平而提出。其基本思想是对于关键性实时程序，超出半数可执行代码可能都与布尔运算表示式相关，所以经过使用MC/DC覆盖，能够使用尽可能少测试用例覆盖尽可能多代码运行轨迹，尽可能全方面地检测代码中每个可能布尔运算表示式组合。第38页6.3 单元测试策略在DO-178B标准中，对MC/DC有以下要求。（1）在判定中，每个条件全部可能结果最少出现一次；此处判定是指包含逻辑操作符布尔表示式。（2）每个判定本身全部可能结果也最少出现一次。（3）每个入口点和出口点最少要执行一次。（4）每个条件都能单独影响判定结果，此处所指条件是指不含逻辑操作符布尔表示式由关系操作符组成，假如同一个布尔表示式在一个判定中出现了屡次，那么该表示式应算做多个条件。如（X AND Y）OR（X AND Z）中有4个条件。条件X能单独影响判定结果是指判定中其它条件取值不变时，条件X取值改变会引发判定结果改变。第39页6.3 单元测试策略 在实际测试中，采取MC/DC覆盖可能得到两种截然不一样结果。一个是测试人员首先要对条件语句进行详细分析，然后再确定MC/DC所需真值对，最终才能针对这些真值对设计测试用例，假如运行后发觉变量数值与预期不合，还要再次修改用例，再次测试，此过程不停重复，直至测试结果到达预期数值。这种情况下，到达MC/DC覆盖要求工作量可能超出分支覆盖工作量总和，且效果不好。如将A AND B条件写成了A OR B，使用MC/DC覆盖虽能发觉错误，不过假如在测试过程中，对需求不了解，按照需求文档设计功效测试用例不足，短期内可能无法及时发觉这个逻辑符错误，所以必须努力防止此结果。另一个结果是在完成MC/DC（Modified Condition/Decision Coverage）覆盖要求过程中，测试人员设计了各种输入情况下测试用例，在到达MC/DC覆盖要求过程中，实现了非常充分测试，应尽力争取到达结果。第40页6.3 单元测试策略单元测试中代码覆盖率主要存在以下几个问题。（1）绝大多数情况下，不能把代码覆盖率作为衡量单元测试唯一指标，更不能使其成为单元测试结束唯一指标。（2）当代码覆盖率到达某个程度（大约70%以上）时，其测试用例和桩维护就变得异常困难，为了到达很高覆盖率，测试人员不得不设计一些极端测试数据以覆盖那些特殊代码。比如测试人员必须有意设计一些错误数据来覆盖异常处理函数，而这些“变态”测试数据对于代码改变非常敏感，一旦代码被修改，这些测试用例就变得无效，对应回归测试工作量就将大大增加，假如测试人员花费巨大精力所写测试用例只用一两次就作废了，就极难说服他们再次花费巨大精力专门针对修改后代码去完成下一次很快会作废极端测试用例编写。第41页6.3 单元测试策略6.3.3 单元测试自动化意义 单元测试要求设置实际而有效测试套件.因为单元测试属于早期测试，开发人员在完成软件代码编译和基本调试工作后，将单元测试交由代码开发人员自己完成效果最好。而将创建单元测试环境这个辛劳技术工作全交由开发人员又不现实，所以需要借助自动化测试工具来帮助开发者自动搭建测试框架，自动生成桩函数和测试用例，这能在一定程度上减轻开发者工作。单元测试通常将静态分析与动态测试相结合，首先利用自动化测试工具或人脑来完成代码静态分析或代码审查，然后再采取动态测试方法进行补充性测试。在对每个单元进行动态测试时，不能完全忽略测试单元与周围单元关系，被测试单元动态执行需要周围单元支持，为了模拟这些关系，在进行单元测试时，需仿真出这些辅助测试单元。依据与被测试单元层次关系，这些仿真单元分为驱动单元和桩单元，驱动单元用于接收测试数据，并将相关数据传递给被测试单元，调用被测试单元，并输出结果。第42页6.3 单元测试策略 桩单元仿真被测试单元调用，只进行少数数据处理。被测试单元以及和之相关驱动单元和桩单元共同组成了一个“测试环境”，在结构单元测试环境时，驱动单元和桩单元开发属于额外测试开销，尤其是在软件规模庞大时，结构被测试单元测试环境是一项复杂工作，在软件交付时，驱动单元与桩单元不作为产品一部分一同交付。驱动单元和桩单元与真实单元相仿程度在很大程度上影响着单元测试质量，尤其是桩单元编写，不能只反馈“曾被调用信息”，而是应该仿真实际子模块功效。假如对驱动单元和桩单元仿真得过于简单，就无法进行符合要求单元测试，单元间接口全方面检验更是要延迟到集成测试时才能进行。第43页6.3 单元测试策略 在设计测试用例时，假如初始条件设置不正确，那单元测试结果将不能很好地反应程序实际运行情况，对开发者改进程序质量没有帮助。因为在编写测试用例过程中，设计各种输入条件过程有可能会发觉主要需求错误。假如设计测试用例仅关注运行代码和所要到达覆盖率，则单元测试结果除证实代码都能够运行外，对开发者和用户没有什么实际价值。所以即使严格地创建初始化条件工作难度和工作量会很大，但只有在早期开展单元测试，其测试环境才更轻易搭建，应该将单元测试作为质量控制伎俩给予实施。第44页6.3 单元测试策略6.3.4 单元测试与项目开发 单元测试一大独特优势是，能够对错误快速地定位。不论是使用静态分析还是动态测试，单元测试总是针对代码进行。经过测试用例能够快速而直接地发当代码缺点或错误，只需重新编写代码就能纠正错误，其修改成本极低；相反，系统测试发觉则是错误现象，依据错误现象找到最终引发此现象错误代码，可能需要很长时间。因为当前软件系统日趋复杂，尤其是FPGA技术逐步普及，高集成系统对单元测试要求会更严格。只有对组成复杂系统每一个单元都进行充分测试，系统整体可靠性才能得到保障。所以单元测试对于复杂项目标开发与集成含有主要意义。第45页6.3 单元测试策略6.3.5 单元测试中功效测试 单元测试一项主要内容就是功效测试，测试人员需要依据软件详细设计文档，设计足够设计用例来对程序正常功效和异常功效进行测试。按照国家惯用文档分类，需求可分为低级需求和高级需求。低级需求就是详细设计文档，设计人员依据此文档进行编码；高级需求就是需求分析完成时所写需求规格说明书。从高级需求到低级需求转化过程，可能发生翻译错误。比如需求要求对两个逻辑数据进行逻辑或运算，但在编写详细设计文档时，因为设计人员疏忽，将逻辑或写成了逻辑与。而编码人员依据详细设计文档编写代码，就会将此错误带到代码中。第46页6.3 单元测试策略 测试人员依据代码进行静态分析之后，按照详细设计文档功效需求设计功效测试用例，测试不论怎样充分，都是不能发觉将高级需求翻译成低级需求时所引入错误。而从我国当前实际软件项目开发情况看，对于项目文档编写不规范，需求规格说明书非常粗略，开发人员一拿到需求后就开始编码，几乎没有详细设计阶段，这就为项目标缺点甚至失败埋下了极大隐患。为了消除隐患，在进行功效测试时，除了对代码进行逻辑测试之外，一定要参考需求规格说明书，进行基于高级需求功效测试，这么才能预防高级需求翻译成低级需求时引入错误。第47页6.3 单元测试策略6.3.6 单元测试中问题 消费类软件产品对错误处理可靠性需求不一样，使得系统测试情景变得愈加复杂。因为不能准确地预测这类产品使用环境与使用情况，所以系统设计和测试都不能基于某个特定情况进行，而是应该将这些系统经过广泛错误验证和非预期输入验证，以确保这些输入能够被正确地处理。为了简化错误测试过程，能够使用含有桩模块单元测试。因为要基于应用程序这一层级上测试错误条件是一件相当费时事，因为要把程序设置到“可控错误状态”需要完成相对复杂数据输入。同时要求子程序在其大量可能状态中处于对应状态，这个过程非常难把握。与之形成鲜明对比是，使用桩模块来对错误进行模拟，以此测试一些函数对特定错误处理要简单得多。第48页6.3 单元测试策略比如：要测试一个含有输入数据错误机制测试相当简单。int swap(int a,int b)Handle_bad_data();cout Demonstration:call by value endl;cout Before swapped,a=a ,b=b endl;swap(a,b);cout After swapped,i=i ,j=j endl;第49页6.3 单元测试策略 在这种情况下，在测试程序中对handle_bad_data()函数进行调用是很简单，因为测试该函数是否受程序输入数据控制是很简单。但在很多情况下，控制语句并不直接收控于函数接口，而是取决于系统处于特定状态，将系统置于该错误状态会很复杂，甚至可能牵扯到让设备接口处于一些特定状态，此时，测试用例中此条件需要经过模拟来实现。使用支持“智能桩函数”（smart stubs）高级测试工具，对复杂错误条件测试比其它方法简单得多。“智能桩函数”经过原始函数桩函数或经过实现一些特定功效方法来执行代码。也就是说，当被测试程序没有处于错误状态时，其对应待测试函数将被调用以模拟错误实际发生情况，这就是“错误模拟”意义。第50页6.4 单元测试过程6.4.1 计划阶段 测试分析人员应依据软件测试任务书（协议或项目计划）和被测试软件设计文档对被测试软件单元进行分析，并确定以下内容。（1）确定测试充分性要求；即依据软件单元主要性、单元测试目标和约束条件，确定测试用例应覆盖范围及每个范围所要求覆盖程度（如语句覆盖率、功效覆盖率以及分支覆盖率，单元每一个软件特征都最少被一个正常测试用例和一个异常测试用例分别覆盖一次）。（2）确定测试终止要求。设定测试过程正常终止条件（如测试充分性是否到达要求）。确定造成测试过程异常终止可能情况（如代码逻辑错误）。（3）确定用于测试资源要求，包含软件（如所需操作系统、数据库、网络服务、编译环境、静态分析软件、测试数据产生软件、测试结果获取和处理软件和测试驱动软件等），硬件（如计算机、服务器、设备接口、网络联接设备等），人员配置以及技能素质要求等。第51页6.4 单元测试过程（4）确定需要测试软件特征。依据软件设计文档描述确定软件单元功效、性能、接口、状态、设计约束以及数据结构等内容和要求，并进行标识、分类，从中确定需要进行测试软件特征。（5）确定测试需要技术和方法。测试数据输入/输出技术，测试数据生成与验证技术，测试结果获取技术等。（6）依据测试任务书（协议或项目计划）要求和被测试软件特征，确定测试结束条件。（7）确定由资源和被测试软件单元所决定单元测试活动进度。第52页6.4 单元测试过程 以上在测试策划阶段完成工作最终以软件单元测试计划文档形式统计下来。另外，应对软件单元测试计划进行评审。审查测试范围、内容、进度、资源、各方责任等是否明确，测试方法是否合理、有效和可行，测试文档是否符合规范，测试活动是否独立。只有经过软件单元测试计划评审，才能进行下一步工作，不然就只能重新进行单元测试策划。第53页6.4 单元测试过程单元测试计划模板以下。1标识（1）标识（2）标题（3）缩略语（4）本文档适用软件2背景3系统概述4文档概述5引用文档6软件测试内容分析6.1 测试类型及标识6.2 测试内容详细要求 第54页6.4 单元测试过程 6.3 单元动态测试策略 6.4 测试充分性要求 6.5 测试任务结束条件7测试资源要求7.1 软件项7.2 硬件项8软件测试需求9项目管理9.1 组织与职责9.2 软件单元测试人员配置10风险分析第55页6.4 单元测试过程6.4.2 设计实现阶段软件单元测试设计和实现工作由测试设计人员和测试程序员共同完成，普通依据软件单元测试计划完成以下一些工作。（1）测试用例设计，将需测试软件特征分解，针对分解后每种情况设计测试用例。（2）获取测试数据，有两种方式可得到测试数据，一个是取得现有测试数据，另一个是生成新测试数据，并按要求对所取得数据进行验证。（3）确定测试次序，考虑资源约束、风险管理以及测试用例失效造成影响或后果等几个方面原因。（4）获取测试资源，对于测试所需用到软件和硬件，有可从现有工具中选择，有则需要另外研制。第56页6.4 单元测试过程（5）编写测试程序，包含开发测试支持工具，单元测试驱动模块与桩模块。（6）建立和校准测试环境。（7）编写软件单元测试说明文档。应该对软件单元测试说明进行评审。审查测试用例是否正确、可行和充分，测试环境是否合理、正确，测试文档是否符合规范。在软件单元测试说明经过评审后，才能进入下一步工作，不然就要重新进行测试设计与实现了。第57页6.4 单元测试过程单元测试设计文档模板以下。1范围1.1 标识（1）标识（2）标题（3）缩略语（4）本文档适用软件1.2 系统概述1.3 文档概述2引用文档3单元动态测试准备3.1 硬件要求3.2 软件准备3.3 测试环境操作步骤第58页6.4 单元测试过程4测试用例生成4.1 测试用例编写4.2 测试用例统计依据测试用例类型统计测试用例。5测试用例执行5.1 测试规程策略测试用例执行次序依据标准，除下面标准外，能够依据实际情况增加标准。5.2 编写测试规程第59页6.4 单元测试过程6.4.3 执行评定阶段测试人员和测试分析人员要共同对测试进行执行。其中测试人员主要工作是按照软件单元测试计划和软件单元测试说明内容以及要求执行测试。在执行过程中，测试人员应仔细观察并如实统计测试过程、测试结果并努力发觉其中错误，认真填写测试统计。测试分析人员主要完成两方面工作。第一项工作是依据每个测试用例期望测试结果，实际测试结果和评价准则判定该测试是否能经过，并将结果统计在软件测试统计中。假如测试用例不经过时，测试分析人员应认真分析其原因，并依据以下原因采取对应办法：（1）因为软件单元测试说明和测试数据错误造成测试用例不经过时，需要更正错误，将被更正错误信息详细统计，并重新运行该测试。（2）因为执行测试步骤错误造成测试用例不经过时，需要重新运行未正确执行测试步骤。第60页6.4 单元测试过程（3）因为测试环境（包含软件环境与硬件环境）错误造成测试用例不经过时，需要修改测试环境，将环境更正信息详细统计下来，重新运行该测试；假如不能修正环境，要统计相关原因，并查对终止测试。（4）因为软件单元实现错误造成测试用例不能经过时，要填写软件问题汇报单，提出软件修改提议，然后继续进行测试；或是比较错误与异常终止情况，查对终止测试，待软件更新完成后，视情况进行回归测试。（5）因为软件单元设计错误造成测试用例不能经过时，一样要填写软件问题汇报单，提出软件修改提议，然后继续进行测试；或是比较错误与异常终止情况，查对终止测试，待软件更新完成后，视情况进行回归测试，并修改对应测试设计与测试数据。第61页6.4 单元测试过程测试人员第二项工作是当全部测试用例执行完成后，测试分析人员要依据测试充分性要求和失效统计，确定测试工作是否足够，是否应添加新测试。假如发觉测试工作存在不足，应对软件单元进行补充测试，直到测试到达预期，并将测试内容统计在软件单元测试汇报中；假如不需要补充测试，则将正常终止情况统计在软件单元测试汇报中，当测试过程异常终止时，应统计终止条件、未完成测试和未修改错误。在对单元测试结果进行评定时，测试分析人员应依据被测试设计文档、软件单元测试说明、测试统计和软件问题汇报单等，对测试工作进行总结。主要包含以下内容：（1）总结软件单元测试计划和软件单元测试说明改变情况以及原因，统计在软件单元测试汇报中。第62页6.4 单元测试过程（2）依据测试异常终止情况，确定测试用例未覆盖到范围，并将其理由统计在测试汇报中。（3）确定不能处理测试事件以及不能处理理由，并将理由统计在测试汇报中。（4）总结测试所反应软件单元与软件设计文档，对软件单元设计与实现进行评定，并提出改进意见，将其统计在测试汇报中。（5）编写软件单元测试汇报，内容包含测试结果分析、软件单元评定以及对软件单元改进意见。（6）依据测试统计和软件问题汇报单编写测试问题汇报。