测试需求分析与测试用例编写

一、测试需求分析

1、测试需求是什么？

测试需求主要解决测什么问题，一半来自需求规格说明书中原始需求

即根据需求文档提取测试点

测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求

功能需求：业务流程

非功能需求：界面、文档、兼容性、易用性、性能、安全性

2、什么是测试点？

软件包含多个功能点，每个功能点包含多个子功能（测试点），测试点是软件功能细分的最小单元

3、测试需求分析的目的？

        测试需求分析是编写测试用例的依据

        有助于保证测试质量与进度（防止漏测）

        测试需求是衡量测试覆盖率的重要指标

发布上线标准：测试覆盖率（趋近于100%）（测试用例覆盖率（由测试点覆盖率决定）、测试用例执行率（100%））

                        bug遗留率（趋近于0%）

4、应该怎么做测试需求分析？

        a. 查阅需求规格说明书（原型图）--初步熟悉被测软件的核心业务流程--针对某个功能细化需求，提取测试点

        b. 依次分析每个输入项，从上到下从左到右，分析其约束规则（长度、格式）、是否是必填项、可选项、是否重复、隐形需求（比如手机号未提及格式要求，11位数字，如果需求说明书没有提及，也要考虑进行相关验证，需要常识、熟悉业务，根据成熟的同类产品从而挖掘需求）

        c . 按钮--根据业务逻辑先后顺序进行分析--按钮是否存在、（什么条件下）操作成功、（什么条件下）操作失败--验证当前按钮的操作结果（通过交互功能、关联功能来验证），比如登录功能-判断登陆是否成功要通过是否进入首页，展示个人信息来判断，比如验证注册成功-要通过验证注册的账号能否能录来验证

注：测试点不包含测试数据

测试点是可观察可核实的结果

 面试题：遇到隐性需求怎么办？

充分熟悉产品、参考成熟产品、站在用户角度去考虑，从而挖掘需求

给你一个带logo的水杯你会如何去测试？（测试思维）

功能：能否装水、能否喝水、盖子是否能拧紧、是否漏水、是否保温、是否隔热、是否有手柄、是否有刻度、刻度是否准确

界面（外观）：外观设计是否与原型图一致、logo有无错误、位置是否正确，设计是否美观，外观图案是否易脱落掉色

兼容性：能否装茶、酒精、饮料、汽油，石头，米饭

易用性：是否防烫、是否防滑、是否便携，喝水是否方便

安全性：杯子材质是什么，是否安全，是否抗菌，是否有毒，装热水是否有异味，是否有缺口，是否会对使用者造成伤害、能否放微波炉是否会爆炸

性能测试：能装多少水，是否抗摔，能用多久，能否装热水，能否装冰水

用户手册：用户手册是否对杯子的用法、限制、使用条件等做了详细的说明。

你如何去测试朋友圈、购物车、支付、优惠券、二维码？

5、需求评审

评审目的：评审是否存在漏测和错测的测试点

参与人员：测试人员、组内人员、测试主管、产品、开发

二、测试用例编写

1、测试用例的定义

测试用例是为项目需求而编制的一组测试测试输入、执行条件及预期结果，以便测试某个测试需求是否满足测试结果

即每一个测试点的数据设计和步骤设计

2、测试用例八大要素

用例编号：产品名-测试阶段（it集成测试--st系统测试--uat验收测试）-测试项-编号xxx 

用例编号必须唯一

测试项目：对应一个功能模块（细分功能）

测试标题：直接对测试点进行细化得出，输入内容+结果，同一个功能模块标题不能重复（来自测试点）

重要级别：高（冒烟用例，主要核心流程）/中（错误异常测试点）/低（兼容性，界面错误）

预置条件：需要满足一些前提条件，否则用例无法执行

测试输入（数据）：需要加工的输入信息，根据具体情况来设计（跟步骤结合起来一定要具有指导性意义）

操作步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作

预期结果：根据预期输出对比实际结果来判断被测对象是否符合需求（预期结果唯一，不能出现“是否或者”）

实际结果：通过/不通过/阻塞（无法执行）

备注：提供额外的需要注意的备注信息

注：测试用例文档命名：XXX测试项目-版本号-测试用例-作者

3、测试用例设计问题？

是不是针对每个测试点写一条用例？

不是的，避免重复测试，用最少的用例覆盖最多的测试点，具体参考用例设计方法