等价划分测试

　　等价划分测试的英文是equivalence partition testing。

　　等价划分测试是根据等价类设计测试用例的一种技术。是黑盒测试的典型方法之一，通过把被测试程序所有可能的输入数据域划分成若干部分。从每一部分中选取少数有代表性的数据作为测试用例，可有效减少测试次数，极大提高软件测试效率，缩短软件开发周期．等价类划分测试的目的就是为了在有限的测试资源的情况下，用少量有代表性的数据得到比较好的测试效果。有效等价类盒无效等价类。有效等价类中的数据代表的是一组符合需求文档的正确的有意义数据。无效等价类则正相反。

　　判定表

　　判定表的英文是decision table，是指一个表格，用于显示条件和条件导致动作的集合。

　　定义：判定表是分析和表达多逻辑条件下执行不同操作的情况的工具。

　　判定表的优点：能够将复杂的问题按照各种可能的情况全部列举出来，简明并避免遗漏。因此，利用判定表能够设计出完整的测试用例集合。

　　在一些数据处理问题当中，某些操作的实施依赖于多个逻辑条件的组合，即：针对不同逻辑条件的组合值，分别执行不同的操作。判定表很适合于处理这类问题

　　深度测试

　　深度测试的英文Depth test ，是指执行一个产品的一个特性的所有细节，但不测试所有特性。

　　当比较函数返回真的时候才显示出效果来。必须启用“#深度测试”，才能执行测试。不使用的时候需要关闭。

　　基于设计的测试

　　基于设计的测试的英文是design-based testing，是根据软件的构架或详细设计引出测试用例的一种方法。

　　一种基于设计模型的测试方法(Model Based  TestIng System,MATIS).该方法利用用户界面自动生成方法,把设计模型中的类属性定义和实现中的控件属性组织在一起,构建描述界面的逻辑对照表,辅助测试脚本引擎执行自动测试脚本.借助设计模型中扩展的类定义,MATIS方法可以自动生成测试用例和测试数据。

　　文档测试

　　文档测试的英文是documentation testing，测试关注于文档的正确性。

　　文档测试有三大类分别是开发文件、用户文件、管理文件。

　　1. 开发文件：可行性研究报告、软件需求说明书、数据要求说明书、概要设计说明书、详细设计说明书、数据库设计说明书、模块开发卷宗。

　　2.用户文件：用户手册、操作手册。

　　3.管理文件：项目开发计划、测试计划、测试分析报告、开发进度月报、项目开发总结报告。

　　软件测试中的文档测试主要是对相关的设计报告和用户使用说明进行测试，对于设计报告主要是测试程序与设计报告中的设计思想是否一致；对于用户使用说明进行测试时，主要是测试用户使用说明书中对程序操作方法的描述是否正确，重点是用户使用说明中提到的操作例子要进行测试，保证采用的例子能够在程序中正确完成操作。

　　域测试

　　域测试的英文是domain testing，定义参考等价划分测试（equivalence partition testing）；

　　一般分为单域测试和多域测试，其中单域测试包括设备测试和业务测试，设备测试包括测试某个系统的软交换设备、中继媒体网关设备、信令网关设备、接入媒体网关和IAD等设备。

　　等价类划分有两种不同的情况：有效等价类和无效等价类。设计时要同时考虑这两种等价类，因为软件不仅要能接收合理的数据，也要能经受意外的考验。

　　一有效等价类：是指对于程序的规格说明来说是合理的、有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能。

　　二无效等价类：与有效等价类的定义恰巧相反。

　　接口测试

　　接口测试的英文是interface testing，接口测试测试系统组件间接口的一种测试。

　　接口测试的好处：

　　由于接口测试代码本身就是用junit（当然接口的类型不同，不一定是Junit来实现）来实现的，是属于自动化测试的范畴，因此必定也包含自动化测试所固有的优势。

　　1） 提高测试质量

　　软件开发的过程是一个持续集成和改进的过程，而每一次的改进都可能引进新bug,因此当软件的一部，或者全部修改时，都需要对软件产品重新进行测试。其目的是要验证修改后的产品是符合需求的，而当没有自动化测试代码时，往往会由于各种各样的原因，回归不充分，导致bug遗漏。

　　2） 提高测试效率

　　软件系统的规模越来越大，功能点越来越多，开发人员的自测或者测试人员的人工测试非常耗时和繁琐，势必导致测试效率的低下，而自动化测试正好解决这些耗时繁琐的任务，在对外接口功能不变的情况下，达到了一次编写，永久使用的效果。

　　3） 提高测试覆盖

　　通过手工测试很难测试到一些更深层次的异常和安全的问题，通过一些辅助的一些测试工具，能分析出代码的覆盖率，通过覆盖率的提高来提高测试的深度。

　　4） 更好地重现软件缺陷

　　由于每次执行都是相同的代码，一旦代码出错，必定回归出错

　　5） 更好定位错误

　　由于接口测试是一种自下向上的测试，因此一量出错，非常容易定位出错，不向系统测试那样了，一旦有Bug，需要几层验证之后才能确定出错位置

　　6） 降低修改bug的成本接口测试基本和开发人员的编码平行工作，因此发现问题会比系统测试早很多，因此减少了修改bug的成本。

　　7） 增进测试人员和开发人员之间的合作关系，测试工程师为了更好地开展工作，需要对开发技术有深入的理解和实践，有了与开发工程师更多的交流。

　　8） 降低了项目不能按时发布的风险由于接口测试很早就介入，在提交给系统测试前对项目代码的核心模块已经做了详尽的测试，必定加速系统测试的时间，由此来保证项目的按时发布。

　　9）提升测试人员的技能。做接口测试必须了解开发人员的开发流程和一些开发技能，也需要了解测试工具的一些使用方法和一些测试思想，提升了测试人员的技术附加值，提高了自身的竟争力。

　　10）促使项目开发过程的规范化

　　要进行接口，需要完善的文档进行保障，没有测试文档，接口测试将寸步难行，接口测试将增加开发过程规范化产出，而规范化产出也保证了项目质量。

　　逆向测试，反向测试，负面测试

　　逆向测试/反向测试/负面测试的英文是Negative Testing，测试瞄准于使系统不能工作。

　　负面测试与正面测试的比较：

　　负面测试（Negative testing）是相对于正面测试（Positive testing）而言的。它们也是测试设计时的两个非常重要的划分。简单点说，正面测试就是测试系统是否完成了它应该完成的工作；而负面测试就是测试系统是否不执行它不应该完成的操作。形象一点，正面测试就象一个毕恭毕敬的小学生，老师叫我做什么，我就做什么；而负面测试就象一个调皮捣蛋的孩子，你叫我这样做，我偏不这样做，而且和你对着干。开发人员也是最讨厌修改此类bug的。

　　非功能性需求测试

　　非功能性需求测试的英文是non-functional requirements testing ，是与功能不相关的需求测试，如：性能测试、可用性测试等。

　　为什么非功能性需求很重要？

　　在您设计解决方案的过程中满足功能性需求当然是很重要的。但是，如果没有考虑非功能性需求，您的解决方案则很难取得实效。

　　非功能性需求特点：1.不要脱离实际环境；2.可靠性；3.可用性；4.有效性；5.可维护性；6.可移植性。