源代码审核基本步骤及流程-整体测试

软件源代码漏洞及缺陷扫描技术源代码审核的基本步骤及流程12以借口为标准的代码审计——书写自动化测试的桩1一边编码，一边测试2边界测试3整体测试4编码、测试交叉分离5结束6目录软件源代码漏洞及缺陷扫描技术整体测试整体测试概念测试方法测试工具小结3整体测试概念整体测试概念5点击此处添加脚注信息

整体测试是在软件开发完成之后，对软件进行系统完整的测试。整体测试的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统“做得怎样？”。整体测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。

整体测试结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。

整体测试组成整体测试组成7点击此处添加脚注信息集成测试：也叫组装测试、联合测试，集成测试是在单元测试的基础上，将所有模块按照概要设计要求组装成子系统。功能测试：根据产品特性、操作描述和用户方案，测试一个产品的特性和可操作行为以确定它们满足设计需求。整体测试组成8点击此处添加脚注信息系统测试：是将经过测试的子系统装配成一个完整系统来测试。它是检测系统是否确实能提供系统方案说明书中制定功能的有效方法。

性能测试：是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试整体测试步骤9点击此处添加脚注信息验收测试：验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。集成测试集成测试11点击此处添加脚注信息考虑如下问题1.在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；2.各个子功能组合起来，能否达到预期要求的父功能；3.一个模块的功能是否会对另一个模块的功能产生不利的影响；4.全局数据结构是否有问题5.单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。要想发现并排除在模块连接中可能发生的上述问题，就需要进行集成测试。集成测试12点击此处添加脚注信息集成测试有以下不可替代的特点：1.单元测试具有不彻底性，对于模块间接口信息内容的正确性、相互调用关系是否符合设计无能为力。只能靠集成测试来进行保障。2.同系统测试相比，由于集成测试用例是从程序结构出发的，目的性、针对性更强，测试项发现问题的效率更高，定位问题的效率也较高；3.能够较容易地测试到系统测试用例难以模拟的特殊异常流程，从纯理论的角度来讲，集成测试能够模拟所有实际情况；4.定位问题较快，由于集成测试具有可重复强、对测试人员透明的特点，发现问题后容易定位，所以能够有效地加快进度，减少隐患。集成测试13点击此处添加脚注信息集成测试是：1.测试人员在开发人员的协助下，制定集成测试计划；2.集成测试主要关注的是集成模块接口上消息的覆盖、异常流程、性能指标等深入的测试，集成测试不一定依赖于物理平台的支撑（如：机架）；3.集成测试是分层次的，某模块集成测试通过后，可以按照集成方案的策划开始着手下一个（组）模块或更高级别的模块的集成，直至按照集成方案的要求将所有的部件集成完毕；集成测试14点击此处添加脚注信息常用集成方法大爆炸集成目的：尽可能缩短测试时间，使用最少的测试用例验证系统。定义：大爆炸集成也称为一次性组装或整体拼装，这种集成测试策略的做法就是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。自顶向下集成自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。集成测试15点击此处添加脚注信息常用集成方法大爆炸集成目的：尽可能缩短测试时间，使用最少的测试用例验证系统。定义：大爆炸集成也称为一次性组装或整体拼装，这种集成测试策略的做法就是把所有通过单元测试的模块一次性集成到一起进行测试，不考虑组件之间的互相依赖性及可能存在的风险。集成测试16点击此处添加脚注信息自顶向下集成目的：从顶层控制（主控模块）开始，采用同设计顺序一样的思路对被测系统进行测试，来验证系统的稳定性。定义：自顶向下的集成测试就是按照系统层次结构图，以主程序模块为中心，自上而下按照深度优先或者广度优先策略，对各个模块一边组装一边进行测试。集成测试17点击此处添加脚注信息自底向上集成目的：从依赖性最小的底层模块开始，按照层次结构图，逐层向上集成，验证系统的稳定性。定义：自底向上集成是从系统层次结构图的最底层模块开始进行组装和集成测试的方式。集成测试18点击此处添加脚注信息三明治集成目的：综合利用自顶向下和自底向上两中集成测试策略的优点。定义：三明治集成是一种混合增殖式测试策略，综合了自顶向下和自底向上两种集成方法的优点，因此也属于基于功能分解集成。集成测试19点击此处添加脚注信息分层集成目的：通过增量式集成的方法验证一个具有层次体系结构的应用系统的稳定性和可互操作性。定义：分层集成就是针对通信系统中的分层模型使用的一种集成策略。集成测试20点击此处添加脚注信息基于功能的集成目的：采用增值的方法，尽早地验证系统关键功能。定义：从功能实现的角度出发，按照模块的功能重要程度组织模块的集成顺序。功能测试功能测试22点击此处添加脚注信息功能测试中的常用方法有如下几种等价类划分:边界值分析方法错误推测方法因果图方法功能测试23点击此处添加脚注信息等价类划分

等价类划分是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.。功能测试24点击此处添加脚注信息划分等价类:等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据，取得较好的测试结果。功能测试25点击此处添加脚注信息等价类划分可有两种不同的情况:有效等价类和无效等价类。有效等价类:是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。无效等价类:与有效等价类的定义恰巧相反.功能测试26点击此处添加脚注信息边界值分析法

边界值分析方法是对等价类划分方法的补充。长期的测试工作经验告诉我们，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例,可以查出更多的错误.。功能测试27点击此处添加脚注信息

使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。功能测试28点击此处添加脚注信息错误推测法

错误推测法基于经验和直觉推测程序中所有可能存在的各种错误，从而有针对性的设计测试用例的方法。

其主要思想是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例.。例如，在单元测试时曾列出的许多在模块中常见的错误。

以前产品测试中曾经发现的错误等，

这些就是经验的总结。

还有，

输入数据和输出数据为0的情况。

输入表格为空格或输入表格只有一行。

这些都是容易发生错误的情况。

可选择这些情况下的例子作为测试用例。功能测试29点击此处添加脚注信息因果图方法

前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等。考虑输入条件之间的相互组合，可能会产生一些新的情况。

但要检查输入条件的组合不是一件容易的事情，

即使把所有输入条件划分成等价类,他们之间的组合情况也相当多。

因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例。

这就需要利用因果图（逻辑模型）。

因果图方法最终生成的就是判定表。

它适合于检查程序输入条件的各种组合情况。性能测试性能测试31点击此处添加脚注信息常见的性能测试方法有如下几种：负载测试压力测试并发测试基准测试稳定性测试可恢复测试性能测试32点击此处添加脚注信息负载测试在这里，负载测试指的是最常见的验证一般性能需求而进行的性能测试，用户最常见的性能需求就是“既要马儿跑，又要马儿少吃草”。因此负载测试主要是考察软件系统在既定负载下的性能表现。我们对负载测试可以有如下理解：（1）负载测试是站在用户的角度去观察在一定条件下软件系统的性能表现。（2）负载测试的预期结果是用户的性能需求得到满足。此指标一般体现为响应时间、交易容量、并发容量、资源使用率等。性能测试33点击此处添加脚注信息压力测试压力测试是为了考察系统在极端条件下的表现，极端条件可以是超负荷的交易量和并发用户数。注意，这个极端条件并不一定是用户的性能需求，可能要远远高于用户的性能需求。可以这样理解，压力测试和负载测试不同的是，压力测试的预期结果就是系统出现问题，而我们要考察的是系统处理问题的方式。比如说，我们期待一个系统在面临压力的情况下能够保持稳定，处理速度可以变慢，但不能系统崩溃。因此，压力测试是能让我们识别系统的弱点和在极限负载下程序将如何运行。性能测试34点击此处添加脚注信息并发测试验证系统的并发处理能力。一般是和服务器端建立大量的并发连接，通过客户端的响应时间和服务器端的性能监测情况来判断系统是否达到了既定的并发能力指标。负载测试往往就会使用并发来创造负载，之所以把并发测试单独提出来，是因为并发测试往往涉及服务器的并发容量，以及多进程/多线程协调同步可能带来的问题。这是要特别注意，必须测试的。性能测试35点击此处添加脚注信息基准测试当软件系统中增加一个新的模块的时候，需要做基准测试，以判断新模块对整个软件系统的性能影响。按照基准测试的方法，需要打开/关闭新模块至少各做一次测试。关闭模块之前的系统各个性能指标记下来作为基准（Benchmark），然后与打开模块状态下的系统性能指标作比较，以判断模块对系统性能的影响。性能测试36点击此处添加脚注信息稳定性测试“路遥知马力”，在这里我们要说的是和性能测试有关的稳定性测试，即测试系统在一定负载下运行长时间后是否会发生问题。软件系统的有些问题是不能一下子就暴露出来的，或者说是需要时间积累才能达到能够度量的程度。为什么会需要这样的测试呢？因为有些软件的问题只有在运行一天或一个星期甚至更长的时间才会暴露。这种问题一般是程序占用资源却不能及时释放而引起的。比如，内存泄漏问题就是经过一段时间积累才会慢慢变得显著，在运行初期却很难检测出来；还有客户端和服务器在负载运行一段时间后，建立了大量的连接通路，却不能有效地复用或及时释放。性能测试37点击此处添加脚注信息可恢复测试测试系统能否快速地从错误状态中恢复到正常状态。比如，在一个配有负载均衡的系统中，主机承受了压力无法正常工作后，备份机是否能够快速地接管负载。可恢复测试通常结合压力测试一起来做。提示：每种测试有其存在的空间和目的。当我们接手一个软件项目后，在有限的资源条件下，选择去做哪一种测试，这应该根据当前软件过程阶段和项目的本身特点来做选择。比如，在集成测试的时候要做基准测试，在软件产品每个发布点要做性能测试。验收测试验收测试39点击此处添加脚注信息

验收测试是部署软件之前的最后一个测试操作。在软件产品完成了单元测试、集成测试和系统测试之后，产品发布之前所进行的软件测试活动它是技术测试的最后一个阶段，也称为交付测试。验收测试的目的是确保软件准备就绪，并且可以让最终用户将其用于执行软件的既定功能和任务。验收测试40点击此处添加脚注信息实施验收测试的常用策略有三种，它们分别是：正式验收非正式验收或Alpha测试Beta测试策略的选择通常建立在合同需求、组织和公司标准以及应用领域的基础上。验收测试41点击此处添加脚注信息正式验收

正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度不亚于系统测试。选择的测试用例应该是系统测试中所执行测试用例的子集。不要偏离所选择的测试用例方向，这一点很重要。在很多组织中，正式验收测试是完全自动执行的。

对于系统测试，活动和工件是一样的。在某些组织中，开发组织（或其独立的测试小组）与最终用户组织的代表一起执行验收测试。在其他组织中，验收测试则完全由最终用户组织执行，或者由最终用户组织选择人员组成一个客观公正的小组来执行。验收测试42点击此处添加脚注信息这种测试形式的优点是要测试的功能和特性都是已知的。测试的细节是已知的并且可以对其进行评测。这种测试可以自动执行，支持回归测试。可以对测试过程进行评测和监测。可接受性标准是已知的。缺点包括要求大量的资源和计划。这些测试可能是系统测试的再次实施。可能无法发现软件中由于主观原因造成的缺陷，这是因为您只查找预期要发现的缺陷。验收测试43点击此处添加脚注信息非正式测试

在非正式验收测试中，执行测试过程的限定不象正式验收测试中那样严格。在此测试中，确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不象正式验收测试那样组织有序，而且更为主观。

大多数情况下，非正式验收测试是由最终用户组织执行的。验收测试44点击此处添加脚注信息这种测试形式的优点是要测试的功能和特性都是已知的。可以对测试过程进行评测和监测。可接受性标准是已知的。与正式验收测试相比，可以发现更多由于主观原因造成的缺陷。缺点包括要求资