需求分析&用例编写

一、需求分析？

1.什么是需求

软件产品必须完成的是以及必须具备的品质。

功能性需求：产品必须完成的那些事，要求一定的功能和品质。

例子：淘宝的用户名登录。

非功能性需求：产品必须具备的属性和品质。诸如观感、可用性、安全性和法律限制等。

例子：平台用户数为5万人，每天登录用户数为10000左右，网络的宽带为100M宽带。在工作时间根据资料名称条件进行搜索，可以在3秒内得到搜索结果。

一旦知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。

限制条件：是全局性的需求。他们可以是对项目本身的限制，或是对产品最终设计的限制。

2.如何进行软件测试需求分析

 测试需求分析的主要目的：根据需求文档提取测试点（测试执行的要点）---我都是用测试点做用例标题，根据测试点来编写测试用例

测试需求分析的步骤：

1.熟悉需求背景及商业目标：

a)了解清楚项目发起的原因，是为了解决用户的什么问题。

b)当前的解决方案是不是最优的，为什么会这样做？

2.业务模型法：

a）考虑本项目与外部系统的交互、划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。

b）确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

3.业务场景法：

a)考虑用例的调用者；考虑每一个用例提供的服务时供哪些外部用例或者时系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例输出的概率比较大，需要重点关注）

b)考虑系统内部各个用例之间的交互，形成内部业务流程图。需求分析每个用例之间的约束关系、执行条件、组织出各种业务流程图。

4 、功能分解法

a). 业务功能：与用户实际业务直接相关的功能 或细节。

b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。

c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

d). 易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。

e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。

g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据不同的权限进行不同处理，不包括直接限制某个功能的权限

测试点分析：

1. 通过分析需求描述的输入、输出、处理、限制、约束等，给出对应的验证内容；（功能测试）
2. 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）
3. 考虑到分析的完整性，要充分覆盖软件需求的各种特征，包含隐形需求的验证。比如界面的验证，注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）

在另一个博主哪里看到了一篇需求分析，推荐给大家。

https://www.cnblogs.com/spring_net/archive/2008/09/10/1288100.html

二、用例编写

用例：通过操作步骤来验证某个需求是否符合预期的结果。

1.测试 用例的重要性

1. 测试用例是软件测试的核心。
2. 评估测试结果的基准。
3. 保证测试的时候不遗漏测试功能点，可以在测试人员疲惫的时候起到一个牵引的作用。
4. 在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入的了解。
5. 好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试的用例的写作和设计一样，也是非常重要的。

2.测试用例的八大要素

a.用例编号：产品名—测试阶段（st  it ut）--测试项-xxx

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

c.测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复，也就是分析需求的测试点

d.重要级别：高/中/低

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

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

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

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

i.实际结果

测试用例变更一定要把之前的用例备份

个人建议

1. 如果公司只有你一个Tester，就没必要写测试用例了，写测试点把，用思维导图（如Xmind）。

2. 如果需求老是频繁变化，测试用例的更新速度跟不上需求的变化速度，每天都在改用例。这样无太多意义和价值，还是写测试点把。

3. 如果项目比较赶，完全没时间严格按照测试用例执行，写测试点吧，提取关键要素，不过空闲时间的把用例补上。

4. 如果测试点已经能够保证充分覆盖了，测试用例的意义不大 。

5. 如何用更少的测试点，尽可能的充分考虑各种可能性呢？与用例设计方法、经验、需求理解等等有关。我们要综合运用等价类、边界值、错误推测、场景法、因果图等测试用例的设计方法。

写测试用例从产品需求开始，先把需求转为测试点，再根据测试点+用例设计方法+个人经验+测试用例的八大要素去写详细用例。

3.测试用例评审

用例评审的流程

1. 评审材料准备好（主要是测试用例、评审检查清单）。
2. 提前（2天）发布评审通知（OA通知、邮件、或者讨论组发布信息），同时将评审材料发送给评审组成员，以节约沟通成本。 主要的参与评审人员：项目经理、测试负责人、测试人员、产品经理、开发人员、UI。
3. 召开会议评审；针对评审用例检查清单，评审过程中收集相关人员的反馈信息（既问题记录清单），并在此基础上进行测试用例更新，直到评审通过。
4. 评审结束后，修改测试用例，并将修改后发送项目组人员查看，确认没问题，存档。

会议主持人：测试用例编写人——测试人员讲解用例+记录（用例修改意见）