单元测试
通过采用单元测试用例或需求规格说明等作为指南，对最小的软件设计单元的进行的测试，以发现错误保证软件各组成单元正确实现，可以采用白盒测试方法和黑盒测试方法。
举例来说：新作一张单据。对单据的增加、修改、删除、查询等的测试就是单元测试。如修改的测试，测试各可输入栏目的非法字符、极限值等等，都属于单元测试。
联调测试
在单元测试完成后进行的单产品测试，包括对有接口及数据关系的产品进行组合测试，主要是测试有上下游单据关系、上下游数据关系的各项功能。
以会计凭证的相关操作为例：在会计凭证的后续节点上，比如记账，在记账前需要查询出符合条件的会计凭证，会计凭证有各种各样的，在利用较复杂、较多的会计凭证来测试“查询出符合条件的会计凭证”这一功能点时的测试，就属于联调测试。
集成测试
单产品的联调测试完成后，对本次发版所有产品进行的整合测试。这个阶段，通常模拟用户，模拟企业不同的实际运用场景进行测试。
测试工作的流程如下图所示：
四、软件测试基本原则
1、思想原则
1.1 怀疑一切：测试就是为了发现错误，交给你的产品就是有错误的产品。不管程序人员如何“信誓旦旦”，你的工作就是以发现BUG而“油然而生”自己的“成就感”。
1.2 宁可错杀一千，不能放过一个：不能“迁就”自己的感觉，不要担心自己的“无知”。理解错了很正常，但放任过去可能会“后患无穷”。即便是“帮助”中的一个标点符号，也要推敲一下。
1.3 实事求是：不要夸大错误的性质，也不要对错误“轻描淡写”。
2、技术原则
2.1 一次和三次：BUG出现一次程序肯定有错误，不要相信“以后决不会出现”的许诺；让BUG重复出现三次，才有可能摸清楚BUG出现的操作规律，记录详细的操作规律对程序员缩小查错范围十分重要。
2.2 路径覆盖：要按照软件设计的数据流程，遍历所有流程分支。不要想象程序中存在“等同状态”或“与此类推”的情况。没走到的地方肯定有BUG。
2.3 确定预期输出结果：测试之前就应明确什么是正确结果，甚至每一个操作事先都要知道正确的结果是什么。
2.4 合法输入与非法输入相结合：程序员对合法输入测试较多，他们最可能疏忽的就是“非法”输入操作。用户的使用方式“千奇百怪”，你不知道他们要如何操作，所以，你必须设计操作方式。
2.5 测试复核：找一个BUG十分不易，如果没改正你就“白费劲”了。对于测试出的错误修改后必须要验证，并且考虑到可能影响的范围。
2.6 提供信息：测试应该为排错提供必要的诊断信息，找出错误出现的规律十分必要。
2.7 尽早暴露缺陷：缺陷暴露得越早，越能降低开发和维护成本。例如，需求分析中的缺陷如果在需求评审时被暴露出来，只需要改几个字就可以了；如果在设计评审时暴露出来，产品的框架结构可能需要调整；若待编码完成后暴露出来，设计人员和程序员几个月的辛苦可能付诸东流；如果到测试完成后，发现需求错误，开发过程可能要延期，造成巨大的人员和时间浪费。最不幸的是，如果到用户现场实施阶段暴露出来，用户发现根本不是自己所要的产品，可能退货或返工，那么所有的投入都是无用功。软件寿命周期中，暴露缺陷的阶段与修改缺陷产生的开发成本之间的对应关系如下图所示：
现代测试理论认为，对软件寿命周期全过程的工作产品（包括需求文档、设计文档等）的检查和评审都是软件测试的工作范围。
版权声明：51Testing软件测试网原创出品，转载时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。
