软件测试04_软件需求分析&软件用例编写

软件需求分析&软件用例编写

1.什么是软件测试需求

1.1 测试需求是什么？

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

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

比如说一个购物网站,具备注册、登录、浏览商品、购买商品、支付等功能。那么在这个例子里面.注册、登录、浏览商品、购买商品以及支付等功能就是这个网站的需求。

对于这些软件需球.在软件需求说明书文档中,会有详细描述.像这个登录功能，会详细描述登录是否支持老用户登录，是否支持手机号码快捷登录、第三方账号登录等等。每个功能横块的业务流程、细节都会体现在软件需求求说明书里。

2.软件测试需求的必要性

2.1 为什么需要软件测试需求?

简而言之----只有明确了测试需求,才能知道：

怎么去测试?

什么时候开始测试?

要多少人测试?

在什么环境上测试?

3.如何对软件测试需求进行分析(重点)

3.1 如何进行软件测试需求?

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

这里重点讲一下测试点的分析: (正面,反面)测试思维
-通过分析需求描述中的输入，输出,处理、限制、约束等、给出对应的验证内容: (功能测试)

-通过分析各个功能模块之间的业务顺序,和各个功能模块之间的传递信息和数据，对存在的功能交互的功能项,给出相应的验证内容(功能交互测试)

-考虑到需求的完整性,要充分盖软件测试需求的各个特征,包含隐形需求的验证,比如界面的验证，注册账号唯一性验证(界面，易用性,兼容性，安全性,性能压力)

3.2 测试举例—一支笔

对于一支笔

需求： 这只笔能够在不同材质的物体上书写，在不同温度下正常使用，一只笔能用1天，耐摔，能够使用不同型号的笔芯;用力写字，不会坏

测试点：

玻璃上书写是否可以
纸上书写是否可以
木头上书写是否可以
字是否清晰
高温上书写
常温下书写
低温下书写
只用半天，第二天继续用
只用1个小时
只用1分钟，写了一个字
用锤子砸
用脚踩
用相的笔芯
用细的笔芯
用不相不细的笔芯
不用劲写字
用很大劲写字

4.什么是测试用例

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

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

5.测试用例的重要性（了解）

1.测试用例是软件测试的核心。

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

2.评估测试结果的基准

测试用例的通过率以及错误率.是测试结束的一个要依据,用来判断该软件测试结果是否通过,能否达到上线的标准

3.保证测试的时候不遗漏测试功能点。可以在测试人员疲累的时候起到一个牵引的作用。

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

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

6.测试用例的八大要素(重点)

6.1 测试用例的八大要素(重点)

1.用例编号: 产品名测式阶段(st it ut) -测试项-xx (英文)

2.测试项目: 对应一个功能模块(细分功能)

3.测试标题: 直接对测试点进行细化得出,输入内容+结果,同一功能模块标题不能重复(来自测试点)

4.重要级别 : 高/中/低

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

6.测试输入(数据): 需要加工的输入信息,根据具体情况来设计(跟步结合起来定要具有指导性意义)

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

8.预期结果: 根据预期输出比对实际结果.来判断被测对是否符合需求，(预明结果唯一,不能出现
“是否或者”)

9.实际结果:

6.2 关于写用例的一些建议(了解)

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

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

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

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

5.测试用例的步骤描述要简单、清晰，一步就是一步。比如:第一步,用户登陆第步,用户点击"用户信息"，第三步,用户修改姓名为张&三”:第四步,用户点击保存。这有利于提高用例的可操作性。

6.测试用例的数据要明确 ,特别是前提数据和要检查的数据。 比如,测试准备数据:用户:张三，李四，王二。在排序后用例的预期结果为李四，王二，张三。这样,用例在执行时,很清晰，有很高的可操作性，执行者对于执行结果是否正确也非常清楚。

7.用例评审

7.1 用例评审的重要性（了解）

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

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

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

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

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

6，按照用例数来评估工作量,用例不完整,工时给少了,实际测试的时候就等加班吐血吧

7.2 用例评审的方式(了解)

以会议评审为主。一般我们会在用例初步设计完成之后。先进行测试组内部的评审:然后测试组内部评审通过后。再进行项目组的评审。

如果是测试组内部的评审,应该于:

1.测试用例本身的描述是否清晰。是否存在二义性;

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

3.是否针对需求跟踪矩阵，覆盖了所有的软件需求;

4.是否亮全遵守了软件需求的规定。这并不一定的。因为即使再严格的评审 ,也会出现错误,应具体情况具体对待。如果是项目组内部的评审,也就需要评审委员会来做了。角度不同,评审的标准也不同。

如:

1.收集客户需求的人员注I你的业务逻辑是否正确;

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

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

7.3 用例评审的流程(重点)

1.评审材料准备好(主要是测试用例,评审检查清单)

2.提前(2天)发布评审通知(OA通知、邮件、或者讨论组发布信息) ,同时将评审材料发送给评审组成员，以节约沟通成本

主要的参与评审人员:项目经理、测试负责人。测试人员、产品经理、开发人员、开发经理;

3.召开会议评审:针对评审用例检查清单，评审过程中收集相关人员的反馈信息(即间题记录请单) ,并在此基础上进行测试用例更新，直到评审通过

4.评审结束后,测试负责人出测试用例评审报告给到相关人员;

评审结果经项目经理同意确认

7.4 附录:用例评审检查清单(了解)◎

1)测试用例是否按照公司定义的模板进行编写的
(包括正确的名称和编号:是否标注有执行的优先级:)

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

3)测试用例内容是否正确.是否与需求目标相一致

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

5)操作步骤应与描述是否科一致;

6)测试用例包含相关的配置信息:测试环境、数据、前咒测试用例、用户投权等

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

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

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

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

11)场录测试用例是否盖最集杂的业务流程

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

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

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

7.4 测试用例的变更(了解)

由于需求变更,对于业务的不断深入了解和测试用例评审.测试用例是无法一-次全部好的，所以，测试用例在完成之后是需要不断修正的。

测试用例变更通常包括:

(1)删除一些以前版本的测试用例。

(2)增加新的测试用例。

(3)更新测试用例。

(4)删除冗余的测试用例。

存档成者备份: 1.需求变动 2.用例执行—完善用例

8.笔试面试题整理

1.用例需要评审么?紧急情况用例也需要评审么?

2.如果被测项目很紧急，来不及写用例。怎么办?

3.遇到隐性需求如何写用例? (需求不明确)

4.用例有没有优先级?如果一定要有优先级 ,依据什么来确定呢?

5.如何编写测试用例? (以项目为基础来讲一个小模块用例设计,手机号)

6.面试官可能随指定生活中的一件物品,让你描述测试点,例如:

6.1.作为测试人员,电梯雨伞/杯子/笔怎么测试?