软件工程-第3章复习总结

3-1 代码评审分析与优化

A. 为什么要进行代码评审?

1. 代码 Review,是被主流行业普遍认同的,提高代码质量的有效途径之

2. 随着人们对软件质量要求的不断提高,软件开发的每一个环节都应该得到十足的重视

3. 代码评审最主要的目的是确保代码库一直保持「健康」的状

B. 如何选择最合适的编程语言

1. 主要考虑的因素

a) 编程语言本身的效率与生产率

b) 掌握该编程语言的人数

c) 该语言的受欢迎度

d) 团队里掌握该语言人员的比例

e) 学习难度

f) 工具支持和第三方库支持

g) 与待开发项目的吻合度

C. 代码评审的主要内容

1. 设计:

2. 功能性

3. 复杂度

4. 测试

5. 命名

6. 评论

7. 文档

D. 代码规范

1. 形式规范:使代码“看起来很美”
   面向代码的可读性、可维护性、可移植性

a) 标准:简明,易读,无二义性。

b) グマ

c) 空格

d) 分行

e) 命名规则

f) 明

g) 语句结构

h) 注释

2. 内容规范:使代码“运行起来很美”
   面向代码的正确性、可靠性、运行效率

a) 类的编码规范

E. 代码复审:静态程序分析

1. 代码复审:代码是否在“代码规范”的框架内正确地解决了问题

2. 代码复审的目的

a) 找出代码的错误

b) 发现逻辑错误

c) 发现算法错误

d) 发现潜在的错误和回归性错误

e) 发现可能改进的地方。

f) 教育(互相教育)开发人员,传授经验,让更多的成员熟悉项目各部分的代码,同时熟悉和应用领域相关的实际知识

g) 代码复审中的提问与回应能帮助团队成员互相了解,就像练武之人互相观摩点评一样。在一个新成员加入一个团队的时候,代码复审能非常有效地帮助新成员了解团队的开发策略、编程风格及工作流程

3. 代码复审的步骤

a) 在复审前代码必须成功地编译程序员必须测试过代码。

4. 代码复审的核査表:以子程序为例

a) 总体问题

b) 参数传递问题

c) 防错性编程

F. 走査( Walkthrough)

1. 由设计人员或编程人员组成一个走査小组,通过阅读一段文档或代码,并进行提问和讨论,从而发现可能存在的缺陷遗漏和矛盾的地方

2. 类型:设计走査、代码走查。

3. 走査过程

a) 与评审过程类似,即先把材料先发给走査小组每个成员,让他们认真研究程序,然后再开会;

b) 与评审的区别:评审通常是简单地读程序或对照错误检查表进行检查;走查则是按照所提交的测试用例,人工模仿计算机运行一遍,并记录跟踪情况。

4. 会议的目的是查明问题,而不是干扰开发者

5. 会议的思想是确认问题的存在,甚至不必去谋求问题的解决

a) 会后:将问题分发给相应人员进行解决

G. 使用静态代码分析发现潜在bug

1. 无需运行被测代码,仅通过分析或检查源程序的语法、结构、过程、接口等来检査程序的正确性,找出代码隐藏的错误和缺陷,如参数不匹配,有歧义的嵌套语句,错误的递归,非法计算,可能出现的空指针引用等等

2. 静态代码分析( static code analysis):在代码构建过程中帮助开发人员快速、有效的定位代码缺陷

3. 主要技术:缺陷模式匹配、类型推断、模型检査、数据流分析等

4. “30~70%的代码逻辑设计和编码缺陷是可以通过静态代码分析来发现和修复的”。

5. 常用的Java静态代码分析工具

H. 程序性能分析

1. 以收集程序运行时信息为手段研究程序行为的分析方法,是种动态程序分析的方法。

2. 这种方法与静态代码分析相对,主要测量程序的空间或时间复杂度、特定指令的使用情形、函数调用的频率及运行时间等。

3. 性能分析的目的在于:决定程序的哪个部分应该被优化,从而提高程序的速度或者内存使用效率。

4. 性能分析可以由程序的源代码或是可执行文件进行,一般会使用性能分析工具( profiler))进行。

5. 程序性能分析的两种方法

a) 抽样( Sampling

(1) Summary
一般的做法是,先用抽样的方法找到效能瓶颈所在,然后对特定的模块用代码注入的方法进行详细分析
缺点是程序的运行时间会大大加长,还会产生很大的数据文件,数据分析的时间也相应增加。同时,注入的代码也影响了程序真实的运行情况。
这种方法的优点是不需要改动程序,运行较快,可以很快地找到瓶颈。缺点是不能得出精确的数据,代码中的调用关系( Calltree)也不能准确表示。

(2) 这种方法的优点是不需要改动程序,运行较快,可以很快地找到瓶颈。缺点是不能得出精确的数据,代码中的调用关系( Calltree)也不能准确表示。

(3) 缺点是程序的运行时间会大大加长,还会产生很大的数据文件,数据分析的时间也相应增加。同时,注入的代码也影响了程序真实的运行情况。

b) 代码注入( Instrumentation)

6. 关于性能分析

a) 是否会用性能分析工具来提高程序质量是一个优秀程序员的标志之

b) 性能测试一>分析→改进→性能测试

c) 先 Debug,再性能分析

d) 先保证正确性,再提高效能

e) 最高效的代码评审方式是结对编程,不过如果 Github的PR( Pull Request)适用于你的团队,那么PR同样可行。

3-2 软件测试

A. 软件测试基础

1. 为什么要进行测试?

a) 产品测试
是将产品原型或产品成品提供给消费者,由消费者根据自己的想法对产品属性进行评价,从中系统地获得消费者的意见和建议。

2. 软件测试
   使用人工或自动的手段来运行或测定某个软件系统的过程,其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

a) 软件测试的目的
帮助识别开发完成(中间或最终的版本)的计算机软件(整体或部分)的正确度( correctness)、完全度( completeness)和质量(quality

b) 用 Venn Diagram(韦恩图)来理解测试

(1)

c) 软件测试的目标

(1) 测试是为了发现错误而执行程序的过程

(2) 测试是为了证明“程序有错”,而无法证明“程序正确

(3) 个好的测试用例在于能够发现至今未发现的错误

(4) 一个成功的测试是发现了至今未发现的错误的测试

d) 软件测试的原则

(1) 应当把“尽早的和不断的测试”作为软件开发者的座右铭,最好在需求阶段就开始介入

(2) 程序员应避免检査自己的程序

(3) 测试从小规模开始,逐渐扩到大规模

(4) 设计测试用例时,应包括合理的输入和不合理的输入,以及各种边界条件,特殊情况下要制造极端状态和意外状态

(5) 充分注意测试中的聚集现象:测试中发现的80%0的错误,可能由程序的20%功能所造成的(2/8法则)

(6) 对测试错误结果一定要有一个确认过程

(7) 制定严格的测试计划,排除测试的随意性

(8) 注意回归测试的关联性,往往修改一个错误会引起更多错误

(9) 妥善保存一切测试过程文档,测试重现往往要靠测试文档

3. 测试用例的定义与特征

a) 测试用例( ( testing case)

(1) 测试用例是为特定的目的而设计的一组测试输入、执行条件和预期的结果。包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等,并形成文档

(2) 测试用例是执行的最小测试实体

(3) 测试用例就是设计一个场景,使软件程序在这种场景下,必须能够正常运行并且达到程序所设计的执行结果。

b) 测试用例的特征

(1) 最有可能抓住错误的;

(2) 不是重复的、多余的

(3) 组相似测试用例中最有效的

(4) 既不是太简单,也不是太复杂

4. 测试用例的设计原贝

a) 测试用例的代表性

b) 测试结果的可判定性

c) 测试结果的可再现性

5. 软件测试人员

a) 软件测试人员的素质要求

B. 软件测试过程

1. 软件测试的经典模型

a) 传统的瀑布模型

(1) 优点:强调需求,设计的作用:前一阶段完成后只需关注后续阶段:为项目提供按阶段划分的检查点,里程碑清晰

(2) 缺点:线性研发过程难以适应需求的频繁变化;项目周期后段才可看到成果,用户要到末期才能看到开发结果,增加了开发的风险;强制的里程碑,对于开发过程中出现的变化,适应能力较差:文档工作量较大,测试在项目的后期,文档的开发带来很大的工作量。

b) 软件测试的V模型

(1) 基于瀑布模型,缺点是将测试放在整个开发的最后阶段,没有让测试尽早介入开发,没有在需求阶段就进入测试

c) 软件测试的W(双V)模型

(1) 优点:测试与开发并行,让测试尽早介入开发环节,使测试尽早发现问题今早解决。

(2) 局限性:虽然开发与测试并行了,但是在整个开发阶段,仍然是串行的,上一阶段未完全完成无法进入下一阶段,不支持敏捷模式的开发。

d) 软件测试的X模型

(1) 解决交接和频繁集成周期的问题。

e) 软件测试的H模型

2. 软件测试过程

C. 软件测试方法的分类

1. 软件测试方法分类

a) 接实施步骤分

(1) 单元测试( Unit Testing)

i) 单元测试是对软件基本组成单元进行的测试,有时也称“组件测试”

ii) 单元测试一般由编写该单元代码的开发人员执行,该人员负责设计和运行一系列的测试以确保该单元符合需求

iii) 单元测试的目的

(a) 验证开发人员所书写的代码是否可以按照其所设想的方式执行而产出符合预期值的结果,确保产生符合需求的可靠程序单元。

iv) 单元测试环境

(a) 驱动模块( driver):模拟被测模块的上一级模块,接收测试数据,把这些数据传送给所测模块,最后再输出实际测试结果:

(b) 桩模块(Stub):模拟被測单元需调用的其他函数接口,模拟实现子函数的某些功能。

(2) 集成测试

i) 在单元测试的基础上,将所有模块按照总体设计的要求组装成为子系统或系统进行的测试。

ii) 集成测试的对象是模块间的接口,其目的是找出在模块接口上和系统体系结构上的问题。

iii) 集成测试策略

(a) 基于层次的集成:自顶上下与自底向上

(b) 基于功能的集成:按照功能的优先级逐步将模块加入系统中

© 基于进度的集成:把最早可获得的代码进行集成

(d) 基于使用的集成:通过类的使用关系进行集成

iv) 集成测试的方法

(a) 整体集成方式(非增量式集成)
把所有模块按设计要求一次全部组装起来,然后进行整体测试

i) 优点

(A) 效率高,所需人力资源少

(B) 测试用例数目少,工作量低

© 简单,易行

ii) 缺点

(A) 可能发现大量的错误,难以进行错误定位和修改

(B) 即使测试通过,也会遗漏很多错误

© 测试和修改过程中,新旧错误混杂,帯来调试困难

(b) 增量式集成
逐步将新模块加入并测试

i) 自顶向下的集成测试
从主控模块开始,按软件的控制层次结构, 以深度优先或广度优先的策略,逐步把各个模块集成在一起

(A) 具体步骤：
– 以主控模块作为测试驱动模块，把对主控模块进行单元测试时所 引入的所有桩模块用实际模块代替；
– 依据所选的集成策略(深度优先、广度优先)，每次只替代一个桩 模块；
– 每集成一个模块立即测试一遍；
– 只有每组测试完成后，才着手替换下一个桩模块； – 为避免引入新错误，不断进行回归测试。

(B) 优点:能尽早地对程序的主要控制和决策机制进行检验, 因此较早地发现错误:较少需要驱动模块

© 缺点:所需的桩模块数量巨大:在测试较高层模块时,低层处理采用桩模块替代,不能反映真实情况,重要数据不能及时回送到上层模块,因此测试并不充分

ii) 自底向上的集成测试:
从软件结构最底层的模块开始组装测试。

(A) 具体步骤
– 把底层模块组织成实现某个子功能的模块群(cluster)；
– 开发一个测试驱动模块，控制测试数据的输入和测试结果的输出；
– 对每个模块群进行测试；
– 删除测试使用的驱动模块，用较高层模块把模块去组织成为完成 更大功能的新模块；
– 循环，直到整个程序测试完毕
(B) 优点:不用桩模块,测试用例的设计亦相对简单

© 缺点:程序最后一个模块加入时才具有整体形象,难以尽早建立信心

iii) 三明治集成
也称之为“混杂的测试”,是一种混合增量式集成策略,综合了自顶向下和自底向上两种方法的优点

(A) 步骤
–确定以哪一层为界来决定使用三明治集成策略；
–对该层次及其下面的所有各层使用自底向上的集成策略；
–对该层次之上的所有各层使用自顶向下的集成策略； –把该层次各模块同相应的下层集成；
–对系统进行整体测试
(3) 确认测试( alidation T’esting)
检查软件能否按合同要求进行工作,即是否满足软件需求说明书中的确认标准

(4) 系统测试( System Testing)
系统测试是将已经集成好的软件系统作为一个元素,与计算机硬件、外设、某些支持软件、数据和人员等其他元素结合在一起,在实际运行环境下进行的一系列测试。

i) 系统测试方法

(a) 功能测试、协议一致性测试

i) 功能测试( Functional Testing)
功能测试是系统测试中最基本的测试，它不管软件内部的实 现逻辑，主要根据软件需求规格说明和测试需求列表，验证 产品的功能实现是否符合需求规格。
(b) 性能测试、压力测试、容量测试、安全性测试、恢复性测试

i) 压力测试( Press Testing)
–压力测试是检查系统在资源超负荷情况下的表现，特别是 对系统的处理时间有什么影响。
ii) 安全性测试( Security Testing)

iii) 恢复测试( Recovery Testing
–恢复测试是检验系统从软件或者硬件失败中恢复的能力， 即采用各种人工干预方式使软件出错，而不能正常工作， 从而检验系统的恢复能力
© 备份测试、GUI测试、健壮性测试、兼容性测试、可用性

i) GUI测试( Graphic User Interface Testing)
–GUI测试一是检查用户界面实现与设计的符合情况，二是确 认用户界面处理的正确性。
(d) 可安装性测试、文档测试、在线帮助测试、数据转换测试

i) 安装测试( Installation ’ esting)
系统验收之后，需要在目标环境中进行安装，其目的是保证 应用程序能够被成功地安装
(5) 验收测试( Acceptance Testing))
验收测试是以用户为主的测试,一般使用用户环境中的实际数据进行测试
在测试过程中,除了考虑软件的功能和性能外,还应对软件的兼容性、可维护性、错误的恢复功能等进行确认

i) o测试与β测试
测试与β测试是产品在正式发布前经常进行的两种測试

(a) Q测试是由用户在开发环境下进行的测试

(b) β测试是由软件的多个用户在实际使用环境下进行的测试

(6) 回归测试( Regression Testing)
回归测试是验证对系统的变更没有影响以前的功能,并且保证当前功能的变更是正确的。
回归测试可以发生在软件测试的任何阶段,包括单元测试、集成测试和系统测试,其令人烦恼的原因在于频繁的重复性劳动

i) 回归测试应考虑的因素

(a) 范围:有选择地执行以前的测试用例

(b) 自动化:测试程序的自动执行和自动配置、测试用例的管理和自动输入、测试结果的自动采集和比较、测试结论的自动输出

b) 按使用的测试技术分

(1) 静态测试:走查/评审

(2) 动态测试:白盒/黑盒

i) 白盒测试:又称“结构测试”或“逻辑驱动测试”

ii) 黑盒测试:又称“功能测试”或“数据驱动测试

c) 按软件组裝策略分

(1) 非增量测试:整体集成

(2) 增量测试:自顶向下、自底向上、三明治

D. 白盒测试概述

1. 是啥
   白盒测试的概念

a) 把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试

2. 为了啥
   白盒测试的目的

a) 代码评审:靠人发现代码中不符合规范的地方、潜在的错误;

b) 代码性能分析:发现代码中的性能缺陷

c) 白盒测试:发现代码中的错误!

3. 干了啥
   白盒测试主要对程序模块进行如下的检查

a) 对模块的每一个独立的执行路径至少测试一次

b) 对所有的逻辑判定的每一个分支(真与假)都至少测试一次

c) 在循环的边界和运行界限内执行循环体

d) 测试内部数据结构的有效性

e) 白盒测试用例中的输入数据从程序结构导出, 但期望输出务必从需求规格中导出。

4. 白盒测试覆盖标准

a) 白盒测试的特点

(1) 以程序的内部逻辑为基础设计测试用例,又称逻辑覆盖法

(2) 应用白盒法时,手头必须有程序的规格说明以及程序清单

b) 白盒测试考虑测试用例对程序内部逻辑的覆盖程度:

c) 对一个具有多重选择和循环嵌套的程序,不同的路径数目可能是天文数字。

d) 常用的一些覆盖标准从低到高分别是

(1) 逻辑覆盖

(2) 控制结构覆盖:

E. 黑盒测试概述

1. 黑盒测试( black< box testing)

a) 又称“功能测试”、“数据驱动测试”或“基于规格说明书的测试”,是一种从用户观点出发的测试

b) 将测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检査程序的功能是否符合它的功能说明

c) 原理:任何程序都可以看作是将输入定义域取值映射到输出值或的函数

d) 通常在软件接口处进行

2. 黑盒测试能发现的错误

3. 黑盒测试的几种类型

a) 接受性测试:从软件的接口接受测试输出结果。

b) aβ测试:项目组内/组外成员对被测软件进行的测试。当测试发现错误后在开发人员修改的同时,项目经理也会对产品计划做出相应的调整,产品特征不断地被修改。

c) )菜单帮助测试:在软件测试过程中,开发人员将修复测试人员发现的错误,而且对软件的有些功能进行修改,同时项目经理也将根据情况调整软件的特性,因而在软件开发和测试的过程中,所有的功能都可以进行调整。因此,在软件产品开发的最后阶段,文档里发现的问题往往最多

d) 发行测试:在正式发行前除了专门的测试人员外,还需要几千个甚至几十万其他用户与合作者通过使用产品进行的体验测试。如果出现非改不可的错误,必须推迟软件的发行,在推迟时间内需要重新对软件产品进行全面的测试,将耗费大量的时间、人力和物力。

e) 回归测试:检査以前找到的错误是否更正,使已修改的错误不再重现,并且不会产生新的错误。

f) RTM测试:RTM测试是指在产品发行阶段所进行的测试。该阶段每个错误都需要经过高端人员同意才能更正。因为这时候修改软件非常容易产生其他的错误,所以只有那种非修复不可的错误才将允许进行修改。如果在发行阶段软件还有许多严重错误的话,就不能按时发布

4. 黑盒测试中的“穷举”

a) 用黑盒测试发现程序中的错误,必须在所有可能的输入条件和输出条件中确定测试数据,来检查程序是否都能产生正确的输出,但这是也不可能的。

b) 因为穷举测试数量太大,无法完成

5. 黑盒测试的实施过程

a) 测试设计阶段
依据程序需求规格说明书或用户手册,按照一定规范化的方法进行软件功能划分和设计测试用例。输入数据和期望输出均从需求规格中导出。

b) 测试执行阶段

c) 测试总结阶段

6. 测试用例的设计技术

a) 等价类划分

(1) 等价类
输入数据的某个子集,在该子集合中的各个输入数据对于揭露程序中的错误都是等效的,并合理地假定“测试某等价类的代表值就等于对这一类其它值的测试”。

(2) 关键步骤:确定等价类和选择测试用例

(3) 基本原则

i) 每个可能的输入属于某一个等价类

ii) 任何输入都不会属于多个等价类

iii) 用等价类的某个成员作为输入时,如果证明执行存在误差,那么用该类的任何其他成员作为输入,也能检查到同样的误差

(4) 有效/无效等价类

i) 有效等价类
对于程序的规格说明来说是合理的、有意义的输入数据构成 的集合。
–利用有效等价类可检验程序是否实现了规格说明中所规定的 功能和性能
ii) 无效等价类
–对程序的规格说明是不合理的或无意义的输入数据所构成的 集合。
–无效等价类至少应有一个，也可能有多个
iii) 设计测试用例时,要同时考虑这两种等价类

(5) 划分等价类的标准

i) 完备测试、避免冗余

(6) 确定等价类的六大原则

i) 原则1:在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类。

ii) 原则2:在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类。

iii) 原则6:在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类。

iv) 原则3:在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类。

v) 原则4:在规定了输入数据的一组值(假定n个)、并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和个无效等价类。

vi) 原则5:在规定了输入数据必须遵守的规则的情况下,可确立个有效等价类(符合规则)和若干个无效等价类(从不同角度违反规则)。

b) 边界值分析

(1) 边界值分析是等价类测试的特例,主要是考虑等价类的边界条件,在等价类的“边缘”选择元素

(2) 长期的测试经验表明:大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。

(3) 确定边界

i) 选取正好等于、刚刚大于、刚刚小于边界的值作为测试数据,

ii) 而不是选取等价类中的典型值或任意值作为测试数据。

(4) 根据边界确定测试用例

(5) 常见的边界值

(6) 边界值分析的原则

i) 原则1:如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据。

ii) 原则2:如果输入条件规定了值的个数,则用最大个数、最小个数、比最小个数少1,比最大个数多1的数据作为测试数据。

iii) 原则3:将原则1和原则2应用于输出条件,即设计测试用例使输出值达到边界值及其左右的值。

iv) 原则4:如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例

v) 原则5:如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例。

vi) 原则6:分析规格说明,找出其它可能的边界条件。

c) 错误推测法

d) 因果图法

e) 随机测试

f) 决策树方法

g) 判定表驱动分析方法

h) 正交实验设计方法

i) 功能图分析方法

7. 设计测试用例

a) 测试用例={测试数据+期望结果}

b) 测试结果=测试数据+期望结果十实际结果}

c)

d) 为每一个等价类规定一个唯一的编号

e) 设计一个新的测试用例,使其尽可能多的覆盖尚未被覆盖的有效等价类;重复这一步,直到所有的有效等价类都被覆盖为止

f) 设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类;重复这一步,直到所有的无效等价类都被覆盖为止

F. 黑盒测试vs白盒测试

1. 白盒测试的优缺点

a) 优点

(1) 迫使测试人员去仔细思考软件的实现

(2) 可以检测代码中的每条分支和路径

(3) 揭示隐藏在代码中的错误

(4) 对代码的测试比较彻底

(5) 最优化

b) 缺点

(1) 昂贵

(2) 不验证规格的正确性

(3) 无法检测代码中遗漏的路径和数据敏感性错误

2. 黑盒测试的优缺点

a) 黑盒测试的优点

(1) 对于较大的代码单元来说(子系统甚至系统级),黑盒测试比白盒测试效率要高;

(2) 测试人员不需要了解实现的细节,包括特定的编程语言

(3) 测试人员和编码人员是彼此独立的

(4) 从用户的视角进行测试,很容易被理解和接受

(5) 有助于暴露任何规格不一致或有歧义的问题

(6) 测试用例可以在规格说明完成之后马上进行

b) 黑盒测试的缺点

(1) 只有一小部分可能的输入被测试到,要测试每个可能的输入流几乎是不可能的

(2) 没有清晰的和简明的规格,测试用例是很难设计的

(3) 如果测试人员不被告知开发人员已经执行过的用例,在测试数据上会存在不必要的重复;

(4) 会有很多程序路径没有被测试到;

(5) 不能直接针对特定程序段测试,这些程序段可能很复杂(因此可能隐癒更多的问题)

(6) 大部分和研究相关的测试都是直接针对白盒测试的

3. 有了白盒测试为何还需要黑盒测试
   通过了白盒测试只能说明程序代码符合设计需求,并不能说明程序的功能符合用户的需求。如果程序的系统设计偏离了用户需求,即使100%0正确编码的程序也不是用户所要的

4. 有了黑盒测试为何还需要白盒测试
   黑盒测试只能观察软件的外部表现,即使软件的输入输出都是正确的,却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果,例如“负负得正, 错错得对”,只有白盒测试才能发现真正的原因。
   白盒测试能发现程序里的隐患,例如内存泄漏、误差累计问题。在这方面,黑盒测试存在严重的不足

5. 

a) 白盒测试只考虑测试软件产品,它不保证完整的需求规格是否被满足。

b) 黑盒测试只考虑测试需求规格,它不保证实现的所有部分是否被测试到。

c) 黑盒测试会发现遗漏的缺陷,指出规格的哪些部分没有被完成。而白盒测试会发现代理方面缺陷,指出哪些实现部分是错误的。

d) 白盒测试比黑盒测试成本要高得多。它需要在测试可被计划前产生源代码,并且在确定合适的数据和决定软件是否正确方面需要花费更多的工作量

e) 个白盒测试的失败会导致一次修改,这需要所有的黑盒测试被重复执行并且重新决定白盒测试路径。