一、需求分析？
1.什么是需求
软件产品必须完成的，以及必须具备的品质。
功能性需求：产品必须完成的那些事，要求一定的功能和品质。
例子：淘宝的用户名登录。
非功能性需求：产品必须具备的属性和品质。诸如观感、可用性、安全性和法律限制等。
例子：平台用户数为5万人，每天登录用户数为10000左右，网络的宽带为100M宽带。在工作时间根据资料名称条件进行搜索，可以在3秒内得到搜索结果。
一旦知道了产品要做的事情，就可以确定它的行为方式，它需要具备什么品质以及它的响应速度、可用性、可读性和安全性。
限制条件：是全局性的需求。他们可以是对项目本身的限制，或是对产品最终设计的限制。
2.如何进行软件测试需求分析
测试需求分析的主要目的：根据需求文档提取测试点（测试执行的要点）---我都是用测试点做用例标题，根据测试点来编写测试用例
测试需求分析的步骤：
1.熟悉需求背景及商业目标：
a)了解清楚项目发起的原因，是为了解决用户的什么问题。
b)当前的解决方案是不是最优的，为什么会这样做？
2.业务模型法：
a）考虑本项目与外部系统的交互、划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），可以参考系统分析说明书。
b）确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。
3.业务场景法：
a)考虑用例的调用者；考虑每一个用例提供的服务时供哪些外部用例或者时系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例输出的概率比较大，需要重点关注）
b)考虑系统内部各个用例之间的交互，形成内部业务流程图。需求分析每个用例之间的约束关系、执行条件、组织出各种业务流程图。
4 、功能分解法
a). 业务功能：与用户实际业务直接相关的功能 或细节。
b). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。
c). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。
d). 易用性需求：功能的细节，产品中必须提供，便于功能操作使用的一些细节，比如快捷键就是典型的易用性需求。
e). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。
f). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。
g). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据不同的权限进行不同处理，不包括直接限制某个功能的权限
测试点分析：
- 通过分析需求描述的输入、输出、处理、限制、约束等，给出对应的验证内容；（功能测试）
- 通过分析各个功能模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容（功能交互测试）
- 考虑到分析的完整性，要充分覆盖软件需求的各种特征，包含隐形需求的验证。比如界面的验证，注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）
在另一个博主哪里看到了一篇需求分析，推荐给大家。
https://www.cnblogs.com/spring_net/archive/2008/09/10/1288100.html
二、用例编写
用例：通过操作步骤来验证某个需求是否符合预期的结果。
1.测试 用例的重要性
- 测试用例是软件测试的核心。
- 评估测试结果的基准。
- 保证测试的时候不遗漏测试功能点，可以在测试人员疲惫的时候起到一个牵引的作用。
- 在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入的了解。
- 好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试的用例的写作和设计一样，也是非常重要的。
2.测试用例的八大要素
a.用例编号：产品名—测试阶段（st it ut）--测试项-xxx
b.测试项目：对应一个功能模块（细分功能）
c.测试标题：直接对测试点进行细化得出，输入内容+结果，同一功能模块标题不能重复，也就是分析需求的测试点
d.重要级别：高/中/低
e.预置条件：需要满足一些前提条件，否则用例无法执行
f.测试输入：需要加工得到输入信息，根据具体情况来设计（跟步骤结合起来一定要具体指导性意义）
g.输入步骤：明确给出每个步骤的描述，执行人员可以根据该步骤完成执行工作
h.预期结果：根据预期输出比实际结果，来判断被测对象是否符合需求。（预期结果唯一，不能出现“是、否、或者“）
i.实际结果
测试用例变更一定要把之前的用例备份
个人建议
1. 如果公司只有你一个Tester，就没必要写测试用例了，写测试点把，用思维导图（如Xmind）。
2. 如果需求老是频繁变化，测试用例的更新速度跟不上需求的变化速度，每天都在改用例。这样无太多意义和价值，还是写测试点把。
3. 如果项目比较赶，完全没时间严格按照测试用例执行，写测试点吧，提取关键要素，不过空闲时间的把用例补上。
4. 如果测试点已经能够保证充分覆盖了，测试用例的意义不大 。
5. 如何用更少的测试点，尽可能的充分考虑各种可能性呢？与用例设计方法、经验、需求理解等等有关。我们要综合运用等价类、边界值、错误推测、场景法、因果图等测试用例的设计方法。
写测试用例从产品需求开始，先把需求转为测试点，再根据测试点+用例设计方法+个人经验+测试用例的八大要素去写详细用例。
3.测试用例评审
用例评审的流程
- 评审材料准备好（主要是测试用例、评审检查清单）。
- 提前（2天）发布评审通知（OA通知、邮件、或者讨论组发布信息），同时将评审材料发送给评审组成员，以节约沟通成本。 主要的参与评审人员：项目经理、测试负责人、测试人员、产品经理、开发人员、UI。
- 召开会议评审；针对评审用例检查清单，评审过程中收集相关人员的反馈信息（既问题记录清单），并在此基础上进行测试用例更新，直到评审通过。
- 评审结束后，修改测试用例，并将修改后发送项目组人员查看，确认没问题，存档。
会议主持人：测试用例编写人——测试人员讲解用例+记录（用例修改意见）