一、单元测试
单元测试是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现每个程序模块内部可能存在的差错。
单元测试也是程序员的一项基本职责，程序员必须对自己所编写的代码保持认真负责的态度，这是也程序员的基本职业素质之一。同时单元测试能力也是程序员的一项基本能力，能力的高低直接影响到程序员的工作效率与软件的质量。
在编码的过程中作单元测试，其花费是最小的，而回报却特别优厚的。在编码的过程中考虑测试问题，得到的将是更优质的代码，因为在这时您对代码应该做些什么 了解得最清楚。如果不这样做，而是一直等到某个模块崩溃了，到那时您可能已经忘记了代码是怎样工作的。即使是在强大的工作压力下，您也还必须重新把它弄清 楚，这又要花费许多时间。进一步说，这样做出的更正往往不会那么彻底，可能更脆弱，因为您唤回的理解可能不那么完全。
通常合格的代码应该具备以下性质：正确性、清晰性、规范性、一致性、高效性等(根据优先级别排序)。
1. 正确性是指代码逻辑必须正确，能够实现预期的功能。
2. 清晰性是指代码必须简明、易懂，注释准确没有歧义。
3. 规范性是指代码必须符合企业或部门所定义的共同规范包括命名规则，代码风格等等。
4. 一致性是指代码必须在命名上(如：相同功能的变量尽量采用相同的标示符)、风格上都保持统一。
5. 高效性是指代码不但要满足以上性质，而且需要尽可能降低代码的执行时间。
单元测试的方法：
在代码编写完成后的单元测试工作主要分为两个步骤人工静态检查和动态执行跟踪。
人工静态检查是测试的第一步，这个阶段工作主要是保证代码算法的逻辑正确性(尽量通过人工检查发现代码的逻辑错误)、清晰性、规范性、一致性、算法高效性。并尽可能的发现程序中没有发现的错误。
第二步是通过设计测试用例，执行待测程序来跟踪比较实际结果与预期结果来发现错误。经验表明，使用人工静态检查法能够有效的发现30%到70%的逻辑设计 和编码错误。但是代码中仍会有大量的隐性错误无法通过视觉检查发现，必须通过跟踪调试法细心分析才能够捕捉到。所以，动态跟踪调试方法也成了单元测试的重 点与难点。
二、集成测试
集成测试是指一个应用系统的各个部件的联合测试，以决定他们能否在一起共同工作并没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般集成测试以前，单元测试需要完成。
集成测试是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。
集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。
集成测试的方法：
自下向上集成
对任何系统几乎都可以采用这一策略。该策略是从低层次的、相互之间依赖性最步的模块开始的，可以用驱动程序来测试这些模块。这种策略能用来逐步建立系统，或者首先并行地建立起子系统，然后集成为一个完整系统。这种集成可以从开发过程的早期就开始进行。当然，如果项目计划中模块提交也是采用自下而上的方式，那么采用这种方法就能够尽早检测出接口问题，而且这些接口问题也比较容易被隔离，因此解决起来成本就低。其主要缺点是需要使用许多驱动程序来执行这一策略，而且因为测试需要迭代，所以也是一种非常耗时的策略。
自上向下集成
这种策略由系统的控制结构来引导。控制结构按照自上向下的顺序开发，这也提供了从上层控制模块开始，自上而下集成模块的能力。对每一个新的层次，位于同一层次的相关模块被集成起来并得到测试。还不存在的模块角色可以用占位来实现。采用该集成策略的一个缺点是：如果需求发生了变化，变化对底层模块产生影响，从而也将导致上层模块需要更改。这可能导致需要(部分)重新开始集成以及测试过程。另一个缺点是用于测试每个集成步骤所必须用的占位数目很大。如果在早期从上层模块开始集成测试，即使采用占位来替代系统的主要部件。仍然可以观察到整个系统的概貌以及工作方式。
三、系统测试
系统测试是将已经确认的软件、计算机硬件、外设、网络等其他元素结合在一起，进行信息系统的各种组装测试和确认测试，其目的是通过与系统的需求相比较，发现所开发的系统与用户需求不符或矛盾的地方，从而提出更加完善的方案.。它的的任务是尽可能彻底地检查出程序中的错误，提高软件系统的可靠性，其目的是检验系统"做得怎样？"。这阶段又可分为三个步骤：模块测试，测试每个模块的程序是否有错误；组装测试，测试模块之间的接口是否正确；确认测试，测试整个软件系统是否满足用户功能和性能的要求。该阶段结束应交付测试报告，说明测试数据的选择，测试用例以及测试结果是否符合预期结果。测试发现问题之后要经过调试找出错误原因和位置，然后进行改正。是基于系统整体需求说明书的黑盒类测试，应覆盖系统所有联合的部件。系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求规格的定义，找出与需求规格不相符合或与之矛盾的地方。 系统测试的对象不仅仅包括需要测试的产品系统的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下来进行测试 系统测试的方法：
１、恢复测试
恢复测试主要检查系统的容错能力。当系统出错时，能否在指定时间间隔内修正错误并重新启动系统。恢复测试首先要采用各种办法强迫系统失败，然后验证系统是否能尽快恢复。对于自动恢复需验证重新初始化（reinitialization）、检查点(checkpointing mechanisms)、数据恢复(data recovery)和重新启动 (restart)等机制的正确性；对于人工干预的恢复系统，还需估测平均修复时间，确定其是否在可接受的范围内。
２、安全测试
安全测试检查系统对非法侵入的防范能力。安全测试期间，测试人员假扮非法入侵者，采用各种办法试图突破防线。例如，①想方设法截取或破译口令；②专门定做软件破坏系统的保护机制；③故意导致系统失败，企图趁恢复之机非法进入；④试图通过浏览非保密数据，推导所需信息，等等。理论上讲，只要有足够的时间和资源，没有不可进入的系统。因此系统安全设计的准则是，使非法侵入的代价超过被保护信息的价值。此时非法侵入者已无利可图。
３、强度测试
强度测试检查程序对异常情况的抵抗能力。强度测试总是迫使系统在异常的资源配置下运行。例如，①当中断的正常频率为每秒一至两个时，运行每秒产生十个中断的测试用例；②定量地增长数据输入率，检查输入子功能的反映能力；③运行需要最大存储空间（或其他资源）的测试用例；④运行可能导致虚存操作系统崩溃或磁盘数据剧烈抖动的测试用例，等等。
４、 性能测试
对于那些实时和嵌入式系统，软件部分即使满足功能要求，也未必能够满足性能要求，虽然从单元测试起，每一测试步骤都包含性能测试，领测认为只有当系统真正集成之后，在真实环境中才能全面、可靠地测试运行性能系统性能测试是为了完成这一任务。性能测试有时与强度测试相结合，经常需要其他软硬件的配套支持。