测试用例编写流程和方法介绍.pptx

测试用例编写流程和方法介绍测试用例组2015-8-25DVT开始PVT阶段EVT阶段DVT之前Kickoff阶段需求分析用例设计用例计划用例执行与更新用例评审项目用例编写及落地流程确认项目新功能和卖点功能确认用例开发计划确认项目支持的功能列表（区分常规功能和新功能）新功能学习调研、需求分析分解，设计新功能用例导入常规功能用例（从分支库导入）外部评审新功能用例根据评审结果更新用例根据样机再次核对用例并修改完成项目用例库根据执行结果反馈更新用例根据项目实际情况实时更新用例 测试用例编写流程CR用例导入及落地项目CR库状态更新CR总库CR项目CR库，执行CR用例生成CR用例测试用例设计的属性一条测试用例结构至少应包含以下属性：Case ID： 此为此用例唯一编号，无重复性， 以方便个方面快速定位用例Feature Group：定义该用例所属的功能组。Feature： 定义该用例所属的功能。 Title：简单定义该用例的测试目的，以便于有经验的测试工程师快速理解并执行测试。 新形式的用例Title即测试用例，简单便于快速执行。但如果无法表达清楚的测试项还是需要添加步骤和期望结果的，像传统用例那样。Precondition：定义该用例测试的预先设置和测试环境，如无定义，则以软件默认项为基础。Test step：使用清晰的语言描述具体的测试步骤， 不能有可能引起测试人员歧义的语句， 如“约” “大概”等容易引起混乱的用词。Expect result：清晰给出测试步骤的期望结果。 不能使用类似“无异常”“结果正常”“显示正常”等非严格判断的词语。Priority：基于用户角度的常用性定义优先级，便于项目根据其选取重要的case scope， 并且其实测试工程师报bug时的设计bug等级的重要依据。测试用例设计注意事项测试用例基本特征：最有可能抓住错误的不是重复的，多余的一组相似测试用例中最有效的颗粒度适中，既不太简单也不太复杂测试用例的基本原则：测试用例的代表性 能够代表并覆盖各种合理的和不合理的、合法的和非法的、边界的和越界的以及极限的输入数据、操作和环境设置等测试结果的可判定性 测试执行结果的正确性是可判定的，每一个测试用例都应有相应准确清晰的期望结果测试用例的可再现性 对同样的测试用例，系统的执行结果应当是相同的。测试用例覆盖范围正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。完整（安全）性测试：对不允许或禁止的一些行为的操作，可能会对数据库或设备造成损坏。接口间（交互）测试：测试各个模块相互间的协调和调研情况，数据输入输出的一致性和正确性。压力测试：对于需要测试成功率的点，或者根据以往经验容易出问题的点，设计压力测试用例。性能：完成预定的功能，系统的运行时间和各重要功能的响应时间可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。兼容性测试：在不同设备及硬件配置情况下的运行性。测试用例设计方法如何根据需求设计测试用例？ 1.整理分析需求文档仔细将需求文档阅读一遍，记录不明白的地方及关键测试点，简单画出总体流程图。然后再来一遍，仔细分析各个模块的功能，画出模块内流程图，找出所有功能，并列出主要测试点 2. 编写用例 按照不同的业务规则可将测试用例分为四部分：场景用例、系统用例、功能用例场景用例：按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例。根据画出的模块内流程图，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。系统用例：是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。结合画出的模块内流程图，将系统划分多个角色，再将每个角色分解为多个任务，每个任务就是一个系统用例。系统用例分别正常流程、异常流程，分支流程，以场景的形式描述。功能用例：用于验证各功能点的业务规则，包括界面元素和各功能的业务规则验证。主要针对单个功能点。描述单点功能的逻辑规则及页面元素，分层描述逻辑规则，对逻辑规则细化可直接作为用例的操作步骤描述。常用的测试用例设计方法等价类划分可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果。等价类划分可有两种不同的情况:有效等价类和无效等价类.举例：通话