静态分析
可以做到的一些工作：
★可能发现的程序欠缺：
◇用错的局部变量和全程变量；
◇不匹配的参数；
◇不适当的循环嵌套和分支嵌套；
◇不适当的处理顺序；
◇无终止的死循环；
◇未定义的变量；
◇不允许的递归；
◇调用并不存在的子程序；
◇遗漏了标号或代码；
◇不适当的连接。
★找到潜伏着问题的根源：
◇未使用过的变量；
◇不会执行到的代码；
◇未引用过的标号；
◇可疑的计算；
◇潜在的死循环。
★提供间接涉及程序欠缺的信息：
◇每一类型语句出现的次数；
◇所用变量和常量的交叉引用表；
◇标识符的使用方式；
◇过程的调用层次；
◇违背编码规则。
★为进一步查错作准备
★选择测试用例
★进行符号测试
又称功能测试、数据驱动测试或基于规格说明的测试。用这种方法进行测试时，被测程序被当作打不开的黑盒，因而无法了解其内部构造。在完全不考虑程序内部结构和内部特性的情况下，测试者只知道该程序输入和输出之间的关系，或是程序的功能。他必须依靠能够反映这一关系和程序功能的需求规格说明书考虑确定测试用例，和推断测试结果的正确性。即所依据的只能是程序的外部特性。因此，黑盒测试是从用户观点出发的测试。
又称结构测试、逻辑驱动测试或基于程序的测试。采用这一测试方法，测试者可以看到被测的源程序，他可用以分析程序的内部构造，并且根据其内部构造设计测试用例。这时测试者可以完全不顾程序的功能。
软件工程过程
首完，系统工程为软件开发规定了任务，从而把它与硬件要完成的任务明确地划分开。接着便是进行软件需求分析，决定被开发软件的信息域、功能、性能、限制条件并确定该软件项目完成后的确认准则。沿着螺线向内旋转，将进入软件设计和代码编写阶段。从而使得软件开发工作从抽象逐步走向具体化。
软件测试工作也可以从这一螺旋线上体现出来。在螺线的核心点针对每个单元的源代码，进行单元测试。在各单元测试完成以后，沿螺线向外前进，开始针对软件整体构造和设计的集成测试。然后是检验软件需求能否得到满足的确认测试，最后，来到螺线的最外层，把软件和系统的其它部分协调起来，当作一个媒体，完成系统测试。这样，沿着螺旋线，从内向外，逐步扩展了测试的范围。
测试的4个步骤。如下图，开始是分别完成每个单元的测试任务，以确保每个模块能正常工作。单元测试大量地采用了白盒测试方法，尽可能发现模块内部的程序差错。然后，把已测试过的模块组装起来，进行集成测试。其目的在于检验与软件设计相关的程序结构问题。这时较多地采用黑盒测试方法来设计测试用例。完成集成测试以后，要对开发工作初期制定的确认准则进行检验。确认测试是检验所开发的软件能否满足所有功能和性能需求的最后手段，通常采用黑盒测试方法。完成确认测试以后，给出的应该是合格的软件产品，但为检验它能否与系统的其它部分（如硬件、数据库及操作人员）协调工作，需要进行系统测试。严格地说，系统测试已超出了软件工程的范围。
单元测试要解决的问题
单元测试是要针对每个模块的程序，解决以下5个方面的问题
模块接口――对被测的模块，信息能否正常无误地流入和流出。
局部数据结构――在模块工作过程中，其内部的数据能否保持其完整性，包括内部数据的内容、形式及相互关系不发生错误。
边界条件――在为限制数据加工而设置的边界处，模块是否能够正常工作。
覆盖条件――模块的运行能否作到满足特定的逻辑覆盖。
出错处理――模块工作中发生了错误，其中的出错处理设施是否有效。
模块与其设置环境的接口有无差错应首先得到检验，否则其内部的各种测试工作也将是徒劳的。Myers提供的模块接口检查表是很有用的，以下简要地引出：
1.模块接受的输入参数个数与模块的变元个数是否一致？
2.参数与变元的属性是否匹配？
3.参数与变元所使用的单位是否一致？
4.传送给另一被调用模块的变元个数与参数个数是否相同？
5.传送给另一被调用模块的变元属性与参数属性是否匹配？
6.传送给另一被调用模块的变元，其单位是否与参数的单位一致？
7.调用内部函数时，变元的个数、属性和次序是否正确？
8.在模块有多少入口的情况下，是否有引用与当前入口无关的参数？
9.是否会修改只是作为输入值的变元？
10.出现全程变量时，这些变量是否在所有引用它们的模块中都有相同的定义？
11.有没有把常数当作变量来传送？
当模块执行了外部的输入、输出时，Myers提出还需要考虑：
1.文件属性是否正确？
2.OPEN语句是否正确？
3.格式说明与输入、输出语句给出的信息是否一致？
4.缓冲区的大小是否与记录的大小匹配？
5.是否所有的文件在使用前均已打开？
6.对文件结束条件的判断和处理是否正确？
7.对输入、输出错误的处理是否正确？
8.有没有输出信息的正文错误？
对于局部数据结构应该在单元测试中注意发现以下几类错误：
1.不正确的或不相容的说明。
2.不正确的初始化或省缺值。
3.错误的变量名，如拼写错或缩写错。
4.不相容的数据类型。
5.下溢、上溢或是地址错误。
除局部数据结构外，在单元测试中还应弄清楚全程数据（如Fortran的Common）对模块的影响。
如何设计测试用例，使得模块测试能够高效率地发现其中的错误，这是非常关键的问题。无论考虑何种逻辑覆盖都应注意发现以下一些典型的计算错误：
1.对运算优先性的错误理解，或是错误的处理。
2.运算方式未加区分，发生了混合运算的情况。例如，实型量和复型量混淆。
3.初始化错误。
4.计算精度不够。
5.表达式中符号表示的错误。比较和控制流常常是彼此密切相关的，比较的错误势必导致控制流的错误。
需要特别注意发现的错误包括：
1.不同数据类型的数据进行比较。
2.逻辑运算符或其优先级用错。
3.本应相等的数据，由于精确度原因而不相等。
4.变量本身或是比较有错。
5.循环终止不正确，或循环不已。
6.在遇到发散的循环时，不能摆脱出来。
7.循环控制变量修改有错。
程序运行中出现了异常现象并不奇怪，良好的设计应该预先估计到投入运行后可能发生的错误，并给出相应的处理措施，使得用户不至于束手无策。检验程序中出错处理这一问题解决得怎样，可能出现的情况有：
1.对运行发生的错误描述得难以理解。
2.指明的错误并非实际遇到的错误。
3.出错后，尚未进行出错处理便引入系统干预。
4.意外的处理不当。
5.提供的错误信息不足，以致无法找到出错的原因。
边界测试是单元测试的最后一步，是不容忽视的。实践表明，软件常常在边界地区发生问题。例如，处理n维数组的第n个元素时很容易出错，循环执行到最后一次执行循环体时也可能出错。这可按前面讨论的，利用边值分析方法来设计测试用例，以便发现这类程序错误。
在对每个模块进行单元测试时，也不能完全忽视它们和周围模块的相互联系。需设置若干辅助模块。有二种，一种是驱动模块，用以模拟被测模块的上级模块（driver）。另一种是桩模块（stub），用以模拟被测模块工作过程中调用的模块。
集成测试
确认测试
1.确认测试准则
2.配置审查
系统测试
1.恢复测试
恢复测试是要采取各种人工干预方式使软件出错，而不能正常工作，进而检验系统的恢复能力。如果系统本身能够自动进行恢复，则应检验：重新初始化，检验点设置机构、数据恢复以及重新启动是否正确。如果这一恢复需要人为干预，则应考虑平均修复时间是否在限定的范围以内。
2.安全测试
安全测试的目的在于验证安装在系统内的保护机构确实能够对系统进行保护，使之不受各种非常的干扰。系统的安全测试要设置一些测试用例试图突破系统的安全保密措施，检验系统是否有安全保密的漏洞。
3.强度测试
检验系统的能力最高实际限度。进行强度测试时，让系统的运行处于资源的异常数量、异常频率和异常批量的条件下。例如，如果正常的中断平均频率为每秒一到二次，强度测试设计为每秒10次中断。又如某系统正常运行可支持10个终端并行工作，强度测试则检验15个终端并行工作的情况。
4.性能测试
性能测试检验安装在系统内的软件运行性能。这种测试常常与强度测试结合起来进行。为记录性能需要在系统中安装必要的量测仪表或是为度量性能而设置的软件（或程序段）。
