软件测试需求分析与用例设计详解-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_42792477/article/details/94559708

本文详细介绍了软件测试需求分析的重要性，强调测试需求应覆盖所有业务流程和功能需求。接着阐述了如何进行需求分析，提取测试点并编写测试用例。探讨了测试用例设计方法，包括等价类划分、边界值分析、场景法、错误推测法和因果图法，并提出了测试用例选择的策略。此外，还详细解释了测试用例的八大要素和评审流程，以及bug的等级划分和生命周期管理。

软件测试需求分析:
1:什么是软件需求
测试需求主要解决"测什么"的问题,一般来自需求规格说明书中原始需求
测试需求应全部覆盖已定义的业务流程,以及功能和非功能方面的需求
2:软件需求的必要性
简而言之:只有明确了测试需求,才知道怎么去测试?什么时候开始测试,要多少人测试,在什么环境上测试?
3:如何进行软件测试需求
测试需求分析的主要目的:依据需求文档提取测试点,根据测试点来编写测试用例
测试点分析:(正面,反面)
—通过分析需求描述中的输入,输出,处理,限制,约束等,给出对应的验证内容:(功能测试)
—通过分析各个功能模块之间的业务顺序,和各个功能模块之间传递的信息和数据,对存在功能交互的功能项,给出对应的验证内容;(功能交互测试)
—考虑到需求的完整性,要充分覆盖软件需求的各种特征,包含隐形需求的验证,比如界面的验证,注册账号的唯一性验证(界面,易用性,兼容性,安全性,性能压力)

什么叫软件测试用例
定义:测试用例(testcase)是为项目需求而编制的一组测试输入,执行条件以及预期结果,以便测试某个程序是否满足客户需求
可以总结为:每个测试点的数据设计和步骤设计
测

试用例的设计方法：
软件测试的核心编写测试用例
基本原则：
准确性：明确测试的目标
经济性：避免一些重复的或者是负责的步骤，资源占用
可复用性：尽可能的在类似的情况下重复使用
可追踪性：必须追溯到需求
恰当性：对测试环境测试人员的要求恰当
完整性：考虑到各种情况
不依赖性：要求测试用例与测试人员无关

黑盒测试方法：
**1、等价类划分法：**等价类划分法是一种典型的、重要的黑盒方法，是指某个输入域的子集合，在该子集合中所有的输入数据对于揭露软件中的错误都是等效的。
等价类划分为有效等价和无效等价

**2、边界值划分法：**是对等价类划分法的一个补充，边界值一般都是从等价类的边缘值去寻找，边界值分析的基本思想：正好等于，刚刚大于，刚刚小于边界的值作为测试数据。0.01、200.01
注意：0是一个特殊值，我们在考虑边界值的时候同时也要考虑这个特殊值。负数
边界值的作用：人们从长期的测试工作经验得知，大量的错误是发生在输入或者输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误！

**3.场景法：**通过场景描述的业务流程（业务逻辑），也包括代码实现逻辑，设计用例来遍历场景（路径），验证软件系统功能的正确性
注意：场景法的重点是测试流程，因此每个流程一个用例验证即可，流程测试没有问题并不能说明系统功能没有问题了，还需要针对单步的功能进行测试，只有单个功能点和流程测试，才算是充分的测试。

**4.错误推测法:**在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法。

**5.因果图法:**分析程序规范的描述中哪些是原因,哪些是结果,原因常常是输入条件或是输入条件的等价类,结果是输出条件

测试用例方法的选择
使用各种测试方法的综合策略:
首先进行等价类划分,主要输输入条件的划分,这是提高测试效率最有效的方法;
在任何情况下都必须使用边界值分析法,这种方法设计出的测试用例发现程序错误的能力最强切记不要穷举测试;
用错误推测法追加测试用例,这需要测试工程师的经验总结;
对照程序逻辑,检查已设计出的测试用例的逻辑覆盖程度,如果没有大袋覆盖标准,应当再补充足够的测试用例(场景法)

测试用例的八大要素:
1.用例编号:
2.测试项目:
3.测试标题:
4.重要级别:
5.预置条件:
6.测试输入(数据):
7.操作步骤:
8.预期结果:
9.实际结果:

测试用例评审的流程:
1.评审材料准备好(主要是测试用例,评审检查清单)
2.提前(2天)发布评审通知(OA通知,邮件,或者讨论组发布信息).同样将评审材料发送给评审成员,以节约沟通成本
主要的参与评审人员:项目经理,测试负责人,测试人员,产品经理,开发人员;
3.召开会议评审:针对评审用例检查清单,评审过程中收集相关人员的反馈信息(即问题记录清单),并在此基础上进行测试用例更新.直到评审通过
4.评审结束后,测试负责人处测试用例评审报告给到相关人员,评审结果经项目经理同意确认

bug等级:
可以划分为三四五级别
（1）致命错误
1、常规操作引起的系统奔溃、死机、死循环
2、造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱计算
4、阻断性测试，所有测试工作进行不下去
（2）严重错误
1、重要功能不能实现
2、错误的波及面广，影响到其它重要功能正常实现；功能交互
3、非常规操作导致的程序奔溃,死机,死循环
4、外观(界面)难以接受的缺陷
5、密码明文显示(界面+数据库)
（3）一般错误
不影响产品的运行,不会成为故障起因,但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现
2、操作界面错误(包括数据窗口内列名定义,含义不一致)
3、查询错误,数据错误显示
4、简单的输入限制未放在前端进行控制(格式限制)长度
5、删除操作未给出提示
（4）细微错误
程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误
1、界面不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误
改进建议:可以提高产品质量的建议,包括新需求和对需求的改进

bug的生命周期:
新建–指派(开发,测试老大,开发经理)–待修复–已解决–待验–关闭
如果待验的bug在验证时没有解决好,我们需要重新打开(激活)–指派–待修复–已解决–待验,循环这个过程
中间其他状态:拒绝,延期等

如何提交bug:
**bug标题:**标题要清晰简洁,写明bug描述;如果没有选择功能模块,最好在标题中标注功能模块,让查看bug的人员清楚知道你所表达的意思.bug的功能模块+bug的操作+bug的结果
**重现步骤:**详细写下发现bug的测试过程.能指导开发重现这个bug,附上测试数据
实际结果出现bug的结果,粘贴bug截图,日志截图
bug等级:
可以划分为三四五级别
（1）致命错误
1、常规操作引起的系统奔溃、死机、死循环
2、造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
3、涉及金钱计算
4、阻断性测试，所有测试工作进行不下去
（2）严重错误
1、重要功能不能实现
2、错误的波及面广，影响到其它重要功能正常实现；功能交互
3、非常规操作导致的程序奔溃,死机,死循环
4、外观(界面)难以接受的缺陷
5、密码明文显示(界面+数据库)
（3）一般错误
不影响产品的运行,不会成为故障起因,但对产品外观和下道工序影响较大的缺陷
1、次要功能不能正常实现
2、操作界面错误(包括数据窗口内列名定义,含义不一致)
3、查询错误,数据错误显示
4、简单的输入限制未放在前端进行控制(格式限制)长度
5、删除操作未给出提示
（4）细微错误
程序在一些显示上不美观,不符合用户习惯,或者是一些文字的错误
1、界面不规范
2、辅助说明描述不清楚
3、提示窗口文字未采用行业术语
4、界面存在文字错误
改进建议:可以提高产品质量的建议,包括新需求和对需求的改进