功能测试(「unctiona!Test)通常使用黑盒测试的方法—将程序视为一个不能打开的黑盒，在完全不考虑程序内部结构和内部特征的情况下，从软件产品的界面、架构、接口出发，输入预定的数据，在预期结果和实际结果之间进行评测，并判断软件产品是否符合用户需求。

　　使用黑盒测试方法的功能测试流程简述如下:

　　1.确定参照体系，参照体系是软件测试的判断依据。对于不同的实现，需要参照体系明确正确的实现方式。功能测试中，参照体系的角色通常由需求规格说明书来担当。在更为细致深入的测试中，还可引入系统设计文档等。

　　2.用例编写，测试用例是有条理、有组织的，对于测试行为的描述。测试用例描述了测试执行时，执行者所应进行的具体操作。测试用例应严格按照需求文档进行编写。

　　3.测试执行，测试者执行测试时，应按照测试用例所描述的内容进行操作，并将产出的结果与测试用例中的描述进行对比，并判断测试结果。若测试未通过，测试者应将该步骤的测试结果判定为失败，并提交缺陷给相应的开发人员，并在后续的测试中，追踪该缺陷的修复情况，直至该缺陷被修复。

　　4.测试用例维护，测试用例不是一次性产品，应不断进行调整与更新。一份维护良好的测试用例，不但可以大大加快后续回归测试的速度，更可让新入职的员工—不论测试还是开发，能够更快、更方便的熟悉业务。

　　比起需求文档的错综复杂、面面俱到，经过编写人员的理解、提炼而成的测试用例，是一份需求文档的精华摘要，阅读的有效性更高。测试用例对于项目而言，是一份非常宝贵的资料。整个黑盒测试过程看似简单，但由于大部分程序难以做到与需求文档严格一致，而需求文档也无法做到对于程序的每个细节都进行详细说明。

　　测试过程中，测试人员应当依据经验、常识等进行判断，某个和测试用例描述的期望结果不完全一致的实际结果应判定为通过还是失败。

　　在测试执行过程中，测试人员对于测试用例的态度应尊重但不迷信。虽然测试用例是经过仔细编写和详细评审的，但错误依旧难免。因此，作为测试执行者，不应进行机械测试，而应多动脑，能够站在用户、设计人员的角度看问题，这样不但可以发现一些测试用例中可能存在的问题，还能发现更多测试用例中没有涵盖到的缺陷。

　　继续深入阐述几个测试用例编写中需要遵循的原则，总结为如下五点:

　　1.正确性，正确性是测试用例编写中的最基本原则。测试执行时，测试者的操作是基于测试用例的。因此，一旦测试用例存在错误，将对测试者产生误导，影响测试判断的准确性，从而产生缺陷误报或缺陷遗漏。

　　2.可读性，前文对于这点已进行较为详细的阐述。由于测试用例面对的读者众多，因此，一个优秀的测试用例的最基本要求是能够让他人理解，不会因为表述上的问题产生歧义。

　　3.完整性，完整性是对正确性的补充。完整性要求测试用例能够覆盖到整个软件项目的每个模块、每个功能、每个细节。完整性缺失的测试用例，后果或比缺复杂工作流软件自动化测试方法的研究第二章件测试理论，J技术基础失正确性的测试用例更为严重。正确性的缺失影响的通常是一个功能点，而完整性的缺失则会影响整个模块。

　　4.可执行性，可执行性是指用户能够按照测试用例中的测试步骤描述，进行测试的执行。为此，步骤描述必须清晰完整，测试用例的拆分设计也必须思路清晰，结构合理。

　　5.一致性，一致性指依据测试用例的描述执行测试时，操作与产出结果应是一致的。测试用例应减少操作者的主观性，增加操作的确定性。这样才‘能让功能测试的结果更为客观，让后续的回归测试结果更为精确。避免因为测试者的变更，导致测试结果的改变。

　　一个设计良好的测试用例应当符合以上五点。前两点更多针对编写者的编写技术与细心程度，而后三点则更多与用例的设计方法有关，因此，后文对测试用例设计方法的论述中，将着重以后三点作为评定标准，比较设计方法的优劣。

  本文由职坐标整理并发布，希望对同学们有所帮助。了解更多详情请关注职坐标软件测试之测试技术频道！