测试用例评审.docx

测试计划 1.1测试计划编写条件 测试计划（Testing plan），描述了要进行的测试活动的范围、方法、资源和进度的文档。它确定测试项、被测特性、测试任务、谁执行任务、各种可能的风险。测试计划可以有效预防计划的风险，保障计划的顺利实施。 在测试项目之初就要制定相应的测试计划。接下来谈下如何编写测试计划问题。 1． 为什么要编写测试计划？ 1）领导能够根据测试计划做宏观调空，进行相应 资源配置等； 2）测试人员能够了解整个项目测试情况以及项目测试不同阶段的所要进行的工作等； 3）便于其他人员了解测试人员的工作内容，进行有关配合工作 2． 什么时间开始编写测试计划？ （测试需求分析前总体测试计划书／测试需求分析后详细测试计划书） 3． 由谁来编写测试计划？ 具有丰富经验的项目测试负责人 4． 测试计划编写6要素？（5W1H） 1）why——为什么要进行这些测试； 2) what—测试哪些方面，不同阶段的工作内容； 3) when—测试不同阶段的起止时间； 4) where—相应文档，缺陷的存放位置，测试环境等； 5) who—项目有关人员组成，安排哪些测试人员进行测试 6) how—如何去做，使用哪些测试工具以及测试方法进行测试。 注意事项： 　1．测试计划不一定要尽善尽美，但一定要切合实际，要根据项目特点、公司实际情况来编制，不能脱离实际情况； 　2．测试计划一旦制定下来，并不就是一层不变的，世界万事万物时时刻刻都在变化，软件需求、软件开发、人员流动等都在时刻发生着变化，测试计划也要根据实际情况的变化而不断进行调整，以满足实际测试要求． 3．测试计划要能从宏观上反映项目的测试任务、测试阶段、资源需求等，不一定要太过详细． 评审总结 　　1.计划评审 　　测试计划编写完成后，一般要对测试计划的正确性、全面性以及可行性等进行评审，评审人员的组成包括软件开发人、营销人员、测试负责人以及其他有关项目负责人。 　　2.计划总结 项目完成后，应该对计划的执行情况进行评审，看有哪些不合理的地方，以便为编写下一个项目测试计划做经验积累。 测试用例评审 2.1测试用例 测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 定义 　　测试需求收集完毕后，开始测试设计。设计测试用例需要考虑以下问题： 编辑本段 测试用例的基本格式 　　 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 用例编号 　　测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题 　　对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。 重要级别 　　定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级 别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然， 测试输入 　　提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 操作步骤 　　提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果 　　提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。 2.2测试用例评审 首先要清楚内部评审的定义，是测试组内部的评审，还是项目组内部的评审。评审的定义不同，内容也不会相同。 如果是测试组内部的评审，应该着重于： 1. 测试用例本身的描述是否清晰，是否存在二义性 2.是否考虑到测试用例的执行效率.往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下 3.是否针对需求跟踪矩阵，覆盖了所有的软件需求， 4.是否完全遵守了软件需求的规定。这并不一定的，因为即使再严格的评审，也会出现错误，应具体情况具体对待。 测试用例评审如何去做呢？ 测试用例的评审能够使用例的结构更清晰，覆盖的用户场景更全面；对于测试工程师来说也是一个快速提高用例设计能力的过程。 评审的内容有以下几个方面： 　　1) 用例设计的结构安排是否清晰、合理，是否利于高效对需求进行覆盖。 　　2)