软件测试用例规范.docVIP

用例书写规范 测试用例是执行测试工作的依据，不仅能有效的保障知识传递和测试的管理；更重要的是能确保测试的系统性和全面性。我们写测试用例就是为了在测试中尽可能多的发现软件存在的问题，尽可能的减少缺陷的遗漏，通过事前预防保障软件的质量。 该规范的目的是为用例设计人员提供测试用例编写的指导，提高编写的测试用例的可读性、合理性，及可执行性。使测试人员可以更好的执行测试，进而提高软件的质量。用例用例编号测试用例编号是由字母和数字组合而成的，用例的编号应该具有唯一性，易识别性，比如可以采用统一的约定，产品编号_ST_系统测试项名_系统测试子项名_编号。这样看到编号就可以知道是做的什么测试，测试的对象是什么，也方便维护。例如系统中模块的功能测试用例命名为：C_ST_GN_login_001。 2、测试项目你现在这个测试用例所测的项目名，可以是测试用例所属的大类，被测需求，被测的模块，或者是被测的单元。例如：3、用例标题测试标题是对测试用例的简单描述。用概括的语言描述该测试用例的测试点。每个测试用例的标题不能够重复，因为每个测试用例的测试点事不一样的。例如：手机在没有SIM卡的情况下，拨打119.4、重要级别重要级别分为高中低三等高：保证系统基本功能、重要特性、实际使用频率比较高的用例；中：重要程度介于高和低之间的测试用例实际使用频率不高，对系统业务功能影响不大的模块或功能的测试用例。一般情况下，重要级别为高的测试用例，一个测试子项里有且仅有一个，大多数都是重要级别为中的测试用例。因为一般我们会进行一个系统测试预测试项，如果重要级别为高的太多，则就失去了预测试的实际意义。5、预置条件就是执行当前测试用例的前提描述，如果不满足这些条件，则无法进行测试6、测试输入测试用例执行时，需要输入的外部信息。例如：某一个文件，数据记录等7、操作步骤执行当前测试用例所要经过的操作步骤，需要给出每一步操作的详细描述，测试人员根据测试用例操作步骤，完成测试用例的执行8、预期结果当前测试用例的预期输出结果，用来与实际结果比较，如果相同则该测试用例通过，否则该测试用例失败。9、作者：谁写的10、创建日期：写用例的日期11、修改日期：最后一次修改用例的日期12、测试结果：执行用例后的结果Pass、Fail、Block 　、用例分类 　　用例计划分为三类：业务流程用例、单功能用例。 　　业务流程用例 　　业务流程用例是为了测试软件是否能完成用户正常的业务处理流程，及对异常业务流程的控制处理是否完善而设计的用例。 　　此类用例要求覆盖到用户所有可能的业务流程，并且需要尽可能多的设计一些实际中因为误操作或不熟悉业务而出现的异常的业务流程。梳理出流程后，为每个流程编写一个测试用例。一个业务的所有流程构成该业务的流程测试用例文档。 　　单功能用例 　　单功能用例针对某一个单独的功能编写，是为了测试功能对正常数据、异常数据、空数据的处理控制存储是否正确而设计的用例。 　　此类用例是根据等价类划分法、边界值分析法、错误推测法等方法确认出测试数据，进而设计出相对完备的测试用例的过程。此类用例的测试数据要求覆盖正常数据范围、异常数据范围、及空数据；每个单独的功能都要编写一个测试用例。一个页面所有功能构成一个单独的功能测试用例文档。 　　集成测试用例 　　集成测试用例是为了测试不同开发组提交的程序之间模块接口及数据传输处理是否正确而设计的测试用例。 　　此类用例主要用来测试维护数据的模块对被主功能模块使用的数据的维护控制是否正确，同时测试主功能模块对基础模块准备的数据的调用处理是否正确。此类用例要求覆盖所有的调用接口，及所有的基础数据状态。每个需要集成测试的功能单独构成一个集成测试用例文档。 　、用例编写原则 　　A、功能或流程划分时，一定要简单、清晰，一个测试用例只检查一个功能点或一个流程；否则测试用例会比较混乱，降低了可读性。 　　B、测试用例要有一个简单直观的名字，有助于读者对测试用例的理解。 　　C、测试用例的步骤描述要简单、清晰，一步就是一步。比如：第一步，用户登陆；第二步，用户点击“用户信息”；第三步，用户修改姓名为“张三”；第四步，用户点击保存。这有利于提高用例的可操作性。　 D、测试用例的数据要明确，特别是输入数据和期望结果。比如，测试准备数据：用户：张三，李四，王二。在排序后用例的预期结果为：李四，王二，张三。这样，用例在执行时，很清晰，有很高的可操作性，执行者对于执行结果是否正确也非常清楚。 　　E、测试用例需要保障唯一性，即功能用例之间不存在重叠，流程用例不存在包含关系。没有重复、冗余的测试用例，满足相应的行业标准。 　　F、描述要清晰、包括特定的场合、对象和术语，没有含糊的概念和一般性的描述。应尽量避免不确定的用词，如：如果、若、否则、大概、可能等。 　　G、测试