一、测试需求的定义

1、测试需求主要解决‘测什么’的问题，一般来自需求规格说明书中原始需求-----项目实战；

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

二、如何进行软件测试需求分析

测试需求分析的主要目的：依据需求文档提取测试点，根据测试点来编写测试用例

测试点分析的重要点：

1、通过分析需求描述中的输入、输出、处理、限制、约束等，给出对应的验证内容；（功能测试）

2、通过分析各个功能模块之间的专业顺序，和各个功能模块之间传递的信息和数据，对存在功能交互的功能项，给出对应的验证内容；（功能交互测试）

3、考虑到需求的完整性，要充分覆盖需求的各种特征，包含隐性需求的验证，比如：界面验证、注册账号的唯一性验证（界面、易用性、兼容性、安全性、性能压力）

三、软件测试用例的定义

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

可总结为：每一个测试点的数据设计和步骤设计。

四、测试用例的重要性

1、测试用例时软件测试的核心。

解释：软件测试的重要性是毋庸置疑的，测试用例是测试工作的指导，是软件测试质量稳定的根本保障。影响软件测试的因素很多，如：软件本身的复杂程度、开发质量，测试方法和技术的应用。但有些因素是客观存在的，不可避免的，例如：IT团队的流动、环境、情绪等。

2、评估测试结果的基准。

解释：测试用例的通过率以及错误率，是测试结束的一个重要依据，用来判断该软件测试结果是否通过，能够达到上线的标准。

3、保证测试的时候不遗漏测试功能点。

4、在编写测试用例的过程，可以熟悉需求，对系统架构或者业务流程有一个整体的，深入地了解。

5、好的测试用例不仅方便自己和别人查看，而且能帮助设计的时候考虑的更周全，因此测试用例的写作和设计一样，也是非常重要的。

五、测试用例的八大要素

1、用例编号：产品名_测试阶段（st  it  uat）_测试项_0011

2、测试项目：对应一个功能模块（细分功能）例如：聊天室（发红包、转账、语音视频通话）

3、测试标题：直接对测试点进行细化得出，输入内容+炎症结果，同一功能模块标题不能重复

4、重要级别：高/中/低

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

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

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

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

9、实际结果：

六、关于写用例的一些建议

1、功能划分时，一个测试用例集（sheet）就只需要检查一个功能模块，否则，用例会混乱，降低可读性。

2、测试用例的划分也要单一，一个测试用例只检查功能点的一种情况，否则会，会导致用例的目的不清晰，且这样有利于需求覆盖率的统计。一个功能点我们测试了那些情况，以及哪些功能点我们在重点测试，一目了然。

3、测试用例要有一个简单的目的描述，有助于读者对测试用例的理解。

4、测试用例要有明确的执行前提，包括环境、数据、场景。

5、测试用例的步骤描述要简单、清晰、一步就是一步。

6、测试用例的数据要准确，特别是前提数据和要检查的数据。

七、用例评审的重要性

1、无论是初级测试工程师，还是高级的，专家的，设计出来的测试用例都需要经过评审。

2、测试用例一般分配给每个人来设计，设计用例的人并不知道用例在具体执行的时候是否有问题，不能保证自己设计的用例能覆盖完全

3、保证测试人员和开发人员对于被测试功能的理解的一致性。避免测试过程中针对bug测试人员与开发扯皮。

4、需求人员参与评审，他们能帮助你找出更多的问题，经常在测试的时候，有些细节是无法从需求文档上得知的，需要频繁和需求人员沟通

5、现在有很多人士项目外包或人员外包，那么完成每一项工作的第一件事就是提交客户评审，当然在提交给客户前自己team先评审下最好，确保提交给客户高质量的成功

6、按照用例数量来评书工作量。

八、用例评审的方式

以会议评审为主。

测试组内部评审：

1、测试用例本身的描述是否清晰，是否存在二义性；

2、是否考虑到测试用例的执行效率，往往测试用例中步骤不断重复执行，验证点却不同，而且测试设计的冗余性，都造成了效率的低下；

3、是否针对需求文档工嗯呢该点，覆盖了所有的软件需求；

/4、是否完全遵守了软件需求的规定。

项目组内部评审：

1、收集客户需求的人员注重你的业务逻辑是否正确；

2、分析软件需求规格的人注重你的用例是否跟规格要求一致；

3、开发负责人会注重你的用例中对程序的要求是否合理。

九、用例评审的流程

1、评审材料准备好（主要是测试用例、评审检查清单）

2、提前2天发布评审通知，同时将评审材料发送给评审组成员，以节约沟通成本；

3、召开会议评审：针对评审用例检查清单，评审过程中收集相关人员的反馈信息，并在此基础上进行测试用例更新，直到评审通过。

4、评审结束后，修改测试用例，并将修改后发送项目组人员查看，确认没问题，存档。

十、用例评审检查清单

1、测试用例是否按照公司定义的模块进行编写；

2、测试用例的本身描述是否清晰，是否存在二义性；

3、测试用例内容是否正确，是否与需求目标相一致；

4、测试用例的期望结果是否确定、唯一的；

5、操作步骤应与描述是否相一致；

6、测试用例包含相关的配置信息，如：测试环境、数据、前置测试用例、用户授权等；

7、测试用例是否覆盖了所有的需求；

8、测试设计是否存在冗余性；

9、测试用例是否具有可执行性；

10、是否从用户层面来设计用户使用场景和业务流程的测试用例；

11、场景测试用例是否覆盖最复杂的业务流程；

12、用例设计是否包含了正面、反面的用例；

13、对于由系统自动生成的输出项是否注明了生成规则；

14、测试用例应包含对中间和后台数据的检查。