(appstorecasebug规范.docxVIP

测试用例规范此规范定义了测试用例的属性、级别、撰写以及执行等规范。用例级别属性（Keywords）此字段主要是用来标识用例的级别，通过对用例的级别定义，可以使整个测试过程分级式管理，从而指导测试流程的顺序、突出重点问题、选择性测试，节约了测试成本，同时也便于更好的表述和分析测试结果。也是我们定义开始测试标准、停止测试标准以及回归测试标准的一个依据。所有的用例将被定义的状态如下：1、Base（基础，可测用例）此级别为基础型，表述了能保证系统可以运行的基本条件，同时也定义了此安装包可以进行下一步测试的标准。如：是否有遗漏功能、安装测试、基本功能点是否没有问题、各项服务是否都是正常运行、提交制品是否相符等等。2、Important （重要，可测用例）此级别为重要型，在完全通过了Base类型用例的测试后，首先要测试的用例，这些用例表述了系统能正常运行的条件和此版本发布必需要满足的条件。此类型的用例将符合以下标准之一：涉及整个功能模块的用例，如果此用例不通过，将导致功能模块不可使用或功能不正常的用例。如：注册用户、注册服务等等。能表明某项功能基本满足需求的用例。涉及到共性问题的用例，如：发送消息等。在release Note声明解决的bug。用户在正常使用中，出现频繁情况的用例。3、Normal（普通用例）此级别为普通型，测试用例的主体。该类型的用例主要针对在保证系统正常运行的前提下，对功能行用例进行完善，对功能性用例进行扩展。另外还有测试系统对特殊情况、异常情况、异常操作情况的处理能力，从细微找出系统漏洞，从而更加完善系统的抗压性和稳定性。4、Extend（扩展用例）此级别为建议型，该类型用例针对不影响系统正常运行的建议，力图完善系统现有功能或提出对系统功能的展望。如：界面显示信息明确、系统退信的语言规范等用例书写规范1、Test Case Title命名规则用例命名时用例应该能够描述出用例的测试目的。2、Summary详细信息Summary标签，概述了用例的基本情况，应包含以下信息：测试目的。概述此用例的测试重点和容易出现问题的地方（必写项）。前提条件。描述此用例能够执行的基本条件（必写项）。测试数据。描述此用例使用的测试素材，包括：输入字符串、大小等数据。备注。选择填写，可在此项描述用例的测试历史，曾经出现的bug等需要表述给测试人员的信息。3、Steps设计步骤此标签为执行用例的主要步骤标签，详细的描述了用例执行的方法步骤和应有的结果。对此标签的撰写做以下规范：每一步操作都对应唯一的功能点。避免没有对应功能点的无用步骤，同时也避免一个步骤对应多个功能点的情况每一操作步骤的Expected Result必须填写。且只能出现描述结果的语言，不能出现描述操作的语言4、Attachments附件此标签为已有的用户添加附件。通过附件可以更加清楚或方便的表述用例内容，如：通过Excel文件批量添加用户、上传本地数据库文件等。测试用例的执行1、严格按照用例的操作步骤执行测试过程中，必须严格按照用例设计的步骤进行操作，每个步骤都要记录测试结果并标记结果状态，不可以自行增删步骤，不可私自跳过用例不执行。2、比较每步操作的结果测试过程中，每执行一步，就应该记录此步骤所产生的结果并与预期结果进行比较。3、无法执行的用例应该做出标记并尽量找到解决方法测试过程中，遇到无法执行的用例时，比如缺少测试数据、测试环境等，必须对该用例做出相应的标记并积极寻求解决的方法。测试用例的执行的结果状态说明No Run用例没有执行（用例的最初状态）Failed用例执行失败Passed用例执行成功Blocked由于环境原因，无法执行的用例Bug的提交和管理规范BUG的属性ColumnDescriptionVersionBug被发现时的软件版本号Component提交bug时，bug对应的模块选择列表Platform测试时使用的硬件平台，可根据bug的实际情况选择OS测试时使用的操作系统版本，可根据bug的实际情况选择SeverityBug的严重级别，根据计算出的RPN值来确定bug严重度PriorityBug解决的优先级别，P1至P5逐渐减弱，根据Bug的严重度来确定Initial State初始状态，测试人员此处为可选状态Unconfirmed和NewAssigned to确定bug指派的开发人员，这里统一要用被指派人员登陆bugzilla用的邮箱CC可抄送给多人，将该bug的状态通知给相关人员，可自行指定Estimated Hours解决此bug需要的时间长度Deadline为此bug预设的解决期限URLBug的定位（可选）Re-producibleBug的复现率，即bug的出现频率SummaryBug概述，简要描述bugDescriptionBug的详述，包括测试环境