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

测试用例编写流程和方法介绍 测试用例组 2015-8-25 项目用例编写及落地流程 确认项目新功能和卖点功能 确认用例开发计划 确认项目支持的功能列表（区分常规功能和新功能） 新功能学习调研、需求分析分解，设计新功能用例 导入常规功能用例（从分支库导入） 外部评审新功能用例 根据评审结果更新用例 根据样机再次核对用例并修改 完成项目用例库 根据执行结果反馈更新用例 根据项目实际情况实时更新用例 测试用例编写流程 需求分析 获得输入文档 开发需求文档/UI Spec 网上调研 CR变更，问题反馈分析 需求评审 需求描述是否清晰/准确，理解需求 分析和评估。列出测试点，和标明需求问题和风险。评估测试点粒度、测试策略以及需求的问题和风险 系统测试不能cover的部分，初步分析可能需要专项测试，运行商测试，场测覆盖的，需要提出来。然后一起评估各自覆盖的部分 确认问题 与开发人员确认需求问题、确认测试点和测试策略的有效性（可以邮件，也可以评审会） 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. 编写用例 按照不同的业务规则可将测试用例分为四部分：场景用例、系统用例、功能用例 场景用例： 按照用户的实际操作与业务逻辑设计用例，不必涉及很复杂的操作或逻辑，把用户最常用的、正常的操作流程作为一个场景设计测试用例。 根据画出的模块内流程图，描述用户的主要业务目标，包含完整的系统级场景和模拟用户实际操作的不同场景，几个功能点的组合也算是用户场景。 系统用例： 是用户场景的细化，包含正常场景、分支场景和异常场景，是两个或多个有关联的功能组合而成的场景。 结合画出的模块内流程图，