软件测试二：测试基础2之检查代码、带上X光眼镜测试软件

1、检查代码

军队、金融、医药类软件，或者在组织严格的开发模式下工作，在代码的级别验证产品就是例行公事。如果测试软件的安全问题，那么这是必须进行的。

1、静态白盒测试：检查设计和代码

静态白盒测试是在不执行软件的条件下有条理地仔细审查软件设计、体系结构和代码，从而找出软件缺陷的过程，有时称为结构化分析。

进行静态白盒测试的首要原因是尽早发现缺陷，以找出动态黑盒测试难以发现或隔离的缺陷。在开发过程初期让测试小组集中精力进行软件设计的审查非常有价值。

另一个好处：为黑盒测试员再接受软件进行测试时设计和应用测试用例提供思路。他们不必了解代码的细节，但是通过听审查评论，可以确定有问题或容易产生缺陷的特性范围。

注意：开发小组负责静态白盒测试的人员不是固定的。某些小组中，程序员就是组织和执行审查的人员，测试员被邀请作为独立的观察者。还有一些小组中，测试员是该任务的执行人，要求编写代码的程序员和其他同事帮助审查。这些方式都可以，取决于项目小组的情况。

对于静态白盒测试最不幸的是常常不能善始善终。许多小组错误的认为这样耗时太多、费用太高、没有产出。这些都不对-与产品接近完工时的有选择性的测试，找出甚至找不出缺陷相比。问题在于一般认为程序员的任务是编写代码，而任何破坏代码编写效率的事情都会减缓开发过程。所幸，目前很多公司意识到早期测试的好处，并招聘和培训程序员和测试员进行白盒测试。

2、正式审查

正式审查进士进行静态白盒测试的过程。正式审查的含义很广，从两个程序员之间的简单交谈，到软件设计和代码的详细、严格检查均属于此过程。

正式审查有4个基本要素：

• 确定问题。审查的目的是找出软件的问题-不仅是出错的项目，还包括遗漏项目。全部的批评应该直指代码和或设计，而不是其设计实现者。
• 遵守规则。审查要遵守一套固定的规则，规则可能设定要审查的代码量、花费多少时间、哪些内容要做评价。其重要性在于参与者了解自己的角色、目标是什么。
• 准备。根据审查的类型，参与者可能扮演不同的角色。他们需要了解自己的责任和义务，并积极参与审查。在审查过程中找出的问题大部分是在准备期间发现的。而不是在实际审查期间。
• 编写报告。审查小组必须做出审查结果的书面总结报告，并使报告便于开发小组成员使用。审查会议结果必须尽快告诉别人，如发现了多少问题、在哪里发现的。

进行正式审查要按照已建立起来的过程执行。随意聚在一起复查代码是不够的，还会造成危害，会遗漏缺陷，参与者会感到浪费时间。

正确地进行审查，就可以证明这是早期发现缺陷的好办法。除了发现问题，坚持正式审查还有一些间接效果：

• 交流。正式报告中未包含的信息得以交流。如：黑盒测试员可以洞察问题所在。缺少经验的程序员可以向有经验的程序员学习技术。管理员对于项目如何跟上进度更加心中有数。
• 质量。程序员的代码经过逐个功能、逐行代码仔细复查，常常会使程序员变得更加仔细，会多花一些心思保证正确性。
• 小组同志化。审查正确进行，就会建立测试员和程序员对双方的技艺互相尊重，并且更好地了解相互的工作及需求。
• 解决方案。是否讨论解决方案取决于审查的规则，但解决方案应该用于处理严重问题。

1、同事审查

召集小组进行初次审查最简单的方法是通过同事审查的方式。这是要求最低的正式方法。这种方法类似于‘如果你给我看你的，我也给你看我的’类型的讨论。

同事审查常常仅在编写代码或设计体系结构的程序员，以及充当审查者的其他一两个程序员和测试员之间进行。因为同事审查是非正式的，正式审查的4个要素常常大打折扣。即便如此，聚集起来讨论代码也能找出缺陷。

2、走查

走查是比同事审查更正规化的下一步。走查中，编写代码的程序员向 5人小组或其他程序员和测试组成小组(至少有以为资深程序员) 做正式陈述。审查人员应该在审查之前接到软件拷贝，以便检查并编写备注和问题，在审查中提问。

陈述者逐行或逐个功能的通读代码，解释代码为什么且如何工作。审查人员聆听叙述，提出有疑义的问题。公开陈述的参与人要多于同时审查，因此，为审查做好准备和遵守规则是非常重要的。同样重要的是审查之后，表述者编写报告说明发现了哪些问题，计划如何解决发现的缺陷。

3、检验

检验是最正式的审查类型，具有高度组织化，要求每个参与者都接受训练。它的不同之处在于表述代码的人，不是原来的程序员，就迫使表述者学习和了解要表达的材料，从而有可能在检验会议上提出不同的看法和解释。

其余的参与者称为检验员，其职责是从不同的角度，如用户、测试员、产品的角度审查代码。检验员还有负责确保材料的彻底和完整。有的还会被委任为会议记录者和会议协调员，以保证检验过程遵守规则及审查有效进行。

检验会议之后，检验员可能再次碰头讨论他们发现的不足之处，并与会议协调员共同准备一份书面报告，明确解决问题所必须重做的工作。然后程序员进行修改，有会议协调员验证修改结果。根据修改的范围和规模以及软件的关键程度，可能还需要重新检验，以便找到其余的缺陷。

检验经证实是所有软件交付内容中，特别是设计文档和代码中发现缺陷非常有效的方法，随着公司和产品开发小组发现其好处多多而日趋流行。

3、编码标准和规范

标准是建立起来的、经过修补和必须遵守的规则-做什么和不做什么。规范是建议最佳做法、推荐更好的方式。标准没有例外情况，缺少结构化的放弃步骤。规范就要松一些。

可以运行甚至在测试中也表现稳定的一些软件，因为不符合某项标准而仍然被认为有问题，真实令人感到奇怪。然而，有三个重要的原因要坚持标准或规范：

• 可靠性。事实证明按照某种标准或规范编写的代码更加可靠和安全。
• 可读性/维护性。符合设备标准和规范的代码已于阅读、理解和维护。
• 移植性。代码经常需要在不同的硬件中运行，或者使用不同的编译器编译。如果代码符合设备标准，迁移到另一个平台就会轻而易举，甚至完全没有障碍。

有标准、规范，就有风格。从软件质量和测试的角度看，风格不是问题。每个程序员都有自己的风格。在编程中，风格可能是注释的冗长程度和变量命名习惯，还可能是循环结构选择哪一种缩排的方式。风格是代码的外表和感觉。

测试员注意，在对软件进行正式审查时，测试和注解的对象仅限于错误和缺漏，而不管是否坚持标准或者规范。仔细想一下要报告的内容确实是问题，还是仅仅是不同的意见、风格。后者不是软件缺陷。

4、通用代码审查清单

数据引用错误、数据申明错误、计算错误、比较错误、控制流错误、子程序参数错误、输入/输出错误、其他检查

5、测验

1、说出进行静态白盒测试的几个好处

静态白盒测试在开发早期发现缺陷，使修复的时间和费用大幅降低。测试员可以得到软件如何运作的信息，存在哪些弱点和危险，而且可以与程序员建立良好的伙伴关系。项目状态可以传达给参与测试的所有小组成员。

2、判断：静态白盒测试可以找出遗漏之处和问题。

对。遗漏的问题比普通问题更重要，通过静态白盒测试可以发现。当根据公布的标准和规范检查代码，在正式审查中仔细分析是，遗漏的问题就显而易见了。

3、正式审查由哪些关键要素组成？

过程。按照过程进行是正式检查和两个程序员之间互查代码的区别。

4、除了更正式之外，检验与其他审查类型有什么重大差别？

主要区别是，检验时在场的不是代码的原创者。这迫使另一个人完全理解要检查的软件。这比让其他人只是审查软件寻找缺陷更有效。

5、如果要求程序员在命名变量时只能使用8个字符，并且首字母必须采用大写的形式，那么这是标准还是规范？

这应该算标准，如果程序员被告知要用超过8个字符命名，那么，这就是规范了。

6、你会采用本章的代码审查清单作为项目小组验证代码的标准吗？

不会。这只是用作一个通用的示例。其中虽然有一些好的测试用例，应该在测试代码时考虑，但是，应该研读其他公开的标准之后在采用自己的标准。

7、缓冲区溢出错误作为一个常见的安全问题属于哪一级错误？是由什么原因引起的？

数据引用。他们是由于使用了未正确声明或未进行初始化的变量、常量、数组、字符串或记录。

2、带上X光眼镜测试软件

1、动态白盒测试(结构化测试)

动态：测试运行中的程序；白盒：洞察盒子里面，检查代码并观察运行状况。动态白盒测试是指利用查看代码的功能（做什么）和实现方式（怎么做）得到的信息，来确定哪些需要测试、哪些不要测试、如何开展测试。

了解盒子内部情况和软件工作方式的好处，如执行加减乘除基本运算操作的两个盒子，如果知道盒子包含一台计算机，而另一个盒子是人用纸笔计算，就会选择不同的测试用例。这说明了了解软件的运作方式对测试手段的影响。

动态白盒测试不仅是查看代码的运行情况，还包括直接测试和控制软件。动态白盒测试包括以下4个部分：

• 直接测试底层函数、过程、子程序和库。
• 以完整程序的方式从顶层测试软件，但根据对软件运行的了解调整测试用例。
• 从软件获得读取变量和状态信息的访问权，以便确定测试与预期结果是否相符，同时，强制软件以正常测试难以实现的方式运行。
• 估算执行测试时‘命中’的代码量和具体代码，然后调整测试，去掉多余的测试用例，补充遗漏的用例。

2、动态白盒测试和调试

动态白盒测试的目标是寻找软件缺陷，调试的目标是修复缺陷。这两项技术看似相似，但目标不同。他们在隔离缺陷的位置和原因上存在交叉现象，都包括处理软件缺陷和查看代码的过程。

执行这些底层的测试，会用到很多和程序员使用的相同的工具。如果程序编译过，可能会使用相同的编译器，但设置上可能不一样，以更好地检查缺陷为目标。可能会使用代码级的调试器来单步跟踪程序，观察变量，设置断点等。也可能自己编写程序来分别测试需要检查的模块代码。

3、分段测试

大爆炸模式开发的产品，最多可以进行动态黑盒测试，且这种测试的费用很高，缺陷往往都是在最后关头才发现的。如果独立代码段分别建立和测试，然后集成并再测试，那么产品无疑会衔接在一起。

1、单元测试和集成测试

在底层进行的测试称为单元测试。单元经过测试，底层软件却此案被找出并修复之后，就集成在一起，对模块的组合进行集成测试。这个不断增加的测试过程继续进行，加入更多的软件片段，直至整个产品在系统测试的过程中一起测试。

这种测试策略很容易隔离软件缺陷。单元级发现的问题，就在该单元中；多个单元集成时发现的问题，就跟模块之间的交互有关。当然也有例外，但总的来说，测试和调试比一起测试所有内容要有效得多。

这种递增测试有两条途径：自底向上和自顶向下。

自底向上的测试中，要编写称为测试驱动得模块调用正在测试的模块。测试驱动模块以和将来真正模块同样的方式挂接，向处于测试的模块发送测试用例数据，接受返回结果，验证结果是否正确。这种方式，可以对整个软件进行非常全面的测试，为它提供全部类型和数量的数据，甚至高层难以发送的数据。

测试驱动，用来代替高级软件，更有效地运行低级模块的测试代码。

自顶向下测试，编写一小段称为测试桩的代码，用来替换低级模块。其对于要测试的高级代码，外表和行为就像低级模块一样。

2、单元测试示例

对“把ASCII字符转换为整数”的函数进行动态白盒测试。

首先可以确定该模块属于程序中的底层模块，可以有高层模块调用，但自己不能调用其他模块。通过查看内部代码可以确认这一点。所以合理的做法是编写一个测试驱动以独立于程序其他部分的形式测验该模块。

测试驱动将向该函数发送创建好的测试字符串，读取这些字符串的返回值，与预期结果相比较。

测试驱动可以有多种形式，可以是由用户驱动的对话输入框（可以用来进行黑盒测试），也可以是从文件读取数据和预期结果的独立程序（可以机器快速地直接从文件读写测试用例）。

下一步是分析说明书，确定应该采用的黑盒测试用例，运用等价类划分技术减少测试用例集合。

最后，研究代码看函数是如何实现的，利用模块的白盒知识增减测试用例。

注意：在进行白盒测试之前，一定要根据说明书建立黑盒测试用例。用这种方式可以真正测试模块的功能和作用。如果先从模块的白盒角度建立测试用例，检查代码，就会偏向于以模块工作方式建立测试用例。程序员或许会误解说明，于是用例就会不对。

根据白盒知识增减用例其实是根据程序内部的信息对等价划分的进一步提炼。黑盒测试用例可能认为内部ASCII表会把a123和z123当做不同且重要的等价类。但经过检查软件后，发现程序员不管ASCII表，而只检查数字、正负号和空格。基于此，应该决定删除其中一些用例，因为这两类属于同一个等价类。

4、数据覆盖

1、数据流

数据流覆盖主要指在软件中完全跟踪一批数据。在单元测试级，数据仅仅通过了一个模块或者函数，同样的跟踪方式可以用于多个集成模块，甚至整个软件产品（尽管非常耗时）。

在底层测试函数，会使用调试器观察变量在程序运行时的数据。通过黑盒测试，只能知道变量开始和结束的值。通过动态白盒测试，可以在程序运行期间检查变量的中间值。根据观察结果可以决定更改某些测试用例，保证变量取得感兴趣、甚至具有风险的中间值。

2、次边界

软件的各个部分都有自己独特的次边界，如：计算税收的模块在某些财务结算处可能从使用数据表转向使用公式；在RAM底端运行的操作系统也许开始把数据移到硬盘上的临时存储区。这种次边界甚至无法确定，它随着磁盘上剩余空间的数量而发生改变。

如果进行白盒测试，就需要仔细检查代码，找到次边界条件，并建立能测试它们的测试用例。询问编写代码的程序员是否知道这些条件，并对内部数据表给与特别的注意，因为这里聚集了大量次边界条件。

3、公式和等式

公式和等式通常深藏于代码中，从外部看，其形式和影响不是非常明显。

计算复利的财务程序中一定包含以下公式：A=P(1+r/n)的nt次方。（P-本金，r-年利率，n-每年复加的利率次数，t-年数，A-t年后的本息总和）

优秀的黑盒测试员可能选择n=0的测试用例，但白盒测试员看到代码中的公式后，就知道这样做将导致除零错，而使公式乱套。

如果n时另一项计算的结果，会怎样？也许软件根据用户输入来设置n的值，或者为了找出最低赔付金额而从算法角度试验各种n值。测试员需要考虑有没有n值为零的情形出现，指什么样的程序输入会导致它出现。

4、错误强制

如果执行在调试器中测试的程序，不仅能够观察到变量的值，还可以强制改变变量的值。

在进行复利计算时，如果找不到将复加数设置为零的直接方法，就可以利用调试器来强制赋值。于是软件不得不处理这种情况，或者报告处理不了。

注意：使用错误强制时，小心不要设置现实世界中不可能出现的情况。如：在函数开头检查n值必须大于0，而且n仅用于该公式中，那么将n设为0，使程序失败的用例就是非法。

如果仔细选择了错误强制情况，并和程序员一起反复检查以确认它们是合法的，错误强制就是一个有效的工具。借此可以执行其他方式难以实现的测试用例。

迫使软件中的所有错误提示信息显示出来，而许多错误情况难以建立，最有效的查看方法是使用错误强制。

5、代码覆盖

测试数据只是一半工作，为了全面地覆盖，还必须测试程序的状态及程序流程，必须设法进入和退出每一个模块，执行每一行代码，进入每一条逻辑和决策分支。这种类型的测试叫做代码覆盖测试。

代码覆盖测试最简单的形式是利用编译环境的调试器通过单步执行程序查看代码。

对大多数程序进行代码覆盖测试要用到 代码覆盖率分析器 的专用工具。

代码覆盖率测试器挂接在正在测试软件中，当执行测试用例时在后台执行。每当执行一个函数、一行代码或一个逻辑决策分支时，分析器就记录相应的信息。从中可以获得指示软件哪些部分被执行，哪些部分未被执行的统计结果。利用该数据可以得到：

• 测试用例没有覆盖软件的哪些部分。某个模块中的代码从未执行，需要补充该模块函数的用例。
• 哪些测试用例是多余的。执行一系列用例后，未增加代码覆盖率的百分比，这些用例可能处于同一个等价划分。
• 为使覆盖率更好，需要建立什么样的新测试用例。观察覆盖率低的代码，看他如何工作、做了什么，从而建立可以更彻底地测试它的新测试用例。

还可以得到软件质量的大致情况。如果测试用例覆盖了软件的90%而未发现任何软件缺陷，就说明软件质量非常号。如果只覆盖了软件的50%仍发现了一些软件缺陷，说明软件还要大加改进。

注意：杀虫剂现象-软件测试得越多，它对测试的免疫能力越强。如果用例覆盖了软件的90%而未发现任何软件缺陷，可能是软件对测试具有了免疫能力。增加新用例可能会暴露余下的10%具有非常多的缺陷。

1、程序语句和代码行覆盖

代码覆盖最直接的形式是语句覆盖或者代码行覆盖。如果在测试软件的同时监视语句覆盖，目标就是保证程序中每一条语句最少执行一次。

注意：即使全部语句都被执行了，但不能说走遍了软件的所有路径。

2、分支覆盖

路径覆盖：试图覆盖软件中所有的路径。路径测试最简单的形式称为分支覆盖测试。（if的是和否）

大多数代码覆盖率分析器将根据代码分支，分别报告语句覆盖和分支覆盖的结果，使测试员更加清楚测试的效果。

3、条件覆盖

条件覆盖测试将分支语句的条件考虑在内。

与分支覆盖一样，代码覆盖率分析器可以被设置为在报告结果时将条件考虑在内。如果测试条件覆盖，就能达到分支覆盖，顺带也能达到语句覆盖。

注意：即使想方设法测试所有语句、分支和条件，也还没有做到完全测试软件。数据错误仍然可能出现，程序流程和数据共同构成了软件的操作。

6、测验

1、为什么了解了软件的工作方法会影响测试的方式和内容？

如果仅从黑盒子的角度测试软件，就无法知道测试用例是否足以覆盖软件的各个部分，以及测试用例是否多余。有经验的黑盒测试员能够为程序设计相当有效的测试用例，但没有白盒测试知识，他就不知道这一套测试好坏程度。

2、动态白盒测试和调试有何区别？

这两个过程存在交叉。当时动态白盒测试的目的是为了发现缺陷，而调试的目的是修复缺陷。在分离和查找缺陷原因时发生交叉。

3、在大爆炸软件开发模式下几乎不可能进行测试的两个原因是什么？如何解决？

一股脑交付软件，即使能够找出软件出现缺陷的原因，也非常困难，这是大海捞针的问题。第二个原因是软件缺陷总舵、相互隐藏。故此失彼，即使发现了缺陷，还是会发现软件仍然不行。

像构建软件时那样有步骤和条理地集成、测试模块，可以在软件缺陷相互重叠、隐藏前将其找出。

4、判断：如果匆忙开发产品，就可以跳过模块测试而直接进行集成测试。

错。测试员可以这样做，但不应该这样做。这样做的结果是会遗漏应该早期发现的软件缺陷。跳过或推迟测试一般都会是项目完成时间延长、费用增加。

5、测试桩和测试驱动有何差别？

测试桩用于自顶向下的测试。他用自己替换低级模块。其对于要测试的高级代码，外表和行为就像低级模块一样。

测试驱动和测试桩相反，用于自底向上的测试。它是代替高级软件，更有效地运行低级模块的测试代码。

6、判断：总是首先设计黑盒测试用例。

对。基于对软件行为操作的认识程度来设计测试用例，然后利用白盒测试技术进行检查使其更加有效。

7、在本章描叙的三种代码覆盖中，哪一种最好？为什么？

条件覆盖是最好的。因为它综合了分支覆盖和语句覆盖，它保证决策逻辑中的所有条件（如if-else），以及来自这些语句的所有分支和代码行都得到验证。

8、静态和动态白盒测试最大的问题是什么？

很容易形成偏见。看到代码可能会想：这个代码处理是对的，不用测试这个案例。实际上是被表面蒙蔽了，去掉了必要的测试用例，一定要小心。