学习并了解业务,分析需求点
测试需求分析的目的:
- 把用户需求转化为功能需求
- 对测试范围进度量
- 对处理分支进行度量
- 对需求业务的场景进行度量
- 明确其功能对应的输入、处理和输出
- 把隐式需求转变为明确。
- 明确测试活动的五个要素
- 测试需求是什么
- 决定怎么测试
- 明确测试时间
- 确定测试人员
- 确定测试环境
- 测试中需要的技能,工具以及相应的背景知识,测试过程中可能遇到的风险等等
怎么进行需求分析:
- 确认功能(业务功能、辅助功能、数据约束、易用性需求、编辑约束、参数需求、权限需求、性能约束):
-
业务功能:与用户实际业务直接相关的功能或者细节
-
辅助功能:辅助完成业务功能的一些功能或者细节,例如:设置过滤条件
-
数据约束:功能的细节,主要是用于控制在执行功能时,数据的显示范围,数据之间的关系等
-
易用性需求:功能的细节,产品中必须提供,便于功能操作使用的一些细节,例如:快捷键等
-
编辑约束:功能的细节,在功能执行时,对输入数据项目的一些约束条件,例如:只能输入数字等
-
参数需求:功能的细节,在功能执行时,需要根据参数设置不同,进行不同处理的细节
-
权限需求:功能的细节,在功能执行的过程,根据不同的权限进行不同的处理,不包括直接限制某个功能的权限
-
性能约束:功能的细节,执行功能时,必须满足的性能需求
-
- 场景分析
-
考虑场景的调用者:考虑每一个场景提供的服务是供哪些外部模块或者系统调用的,找出所有调用者。调用前提,约束都要考虑。每一个调用都可以考虑成一个大的业务流程(一般和外部有交互的业务出错率比较大,需要重点关注)
-
考虑系统内部各个场景之间的:形成内部业务流程,需要分析每个场景之间的约束关系,执行条件,组织出各种业务流程图
-
- 挖掘隐性需求
- 常用的或者规定的业务流程
- 各个业务流程分支的遍历
- 明确规定不可使用的业务流程
- 没有明确规定但是应该不可使用的业务流程
- 其他异常或者不符合规定的操作
测试用例设计
测试工作的最核心的模块,在执行任何测试之前,首先必须完成测试用例的编写。测试用例是指导你执行测试,帮助证明软件功能或发现软件缺陷的一种说明。
进行用例设计,需要对项目的需求有清晰的了解,对要测试什么,按照什么顺序测试,覆盖哪些需求做到心中有数,作为测试用例的编写者不仅了解要有常见的测试用例编写方法,同时需要了解被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构。
-
测试需求分析:从项目部拿到软件的需求规格说明书后,开始对项目的需求进行分析,通过自己的分析、理解,整理成为测试需求, 清楚分析出被测试对象具有哪些功能。 明确测试用例中的测试集用例与需求的关系,即一个或多个测试用例集对应一个测试需求。
-
业务流程分析:分析完需求后,明确每一个功能的业务处理流程,不同的功能点作业务的组合,以及项目的隐式需求。如遇复杂的测试用例设计前,先画出软件的业务流程。从业务流程上,应得到以下信息:
A、 主流程是什么?
B、 条件备选流程是什么?
C、 数据流向是什么?
D、 关键的判断条件是什么?
-
测试用例设计
完成以上两步则可进行测试用例设计,功能测试用例,应尽量考虑边界、异常、性能的情况,以便发现更多的隐藏问题。
设计测试用例的常见方法:1)等价类 2)边界值 3)因果图 4) 判定表 5)数据迁移 6) 正交实验 7) 场景法 8) 错误推断(注意:编写测试用例时,我们尽可能取的不应该是有效等价类而应该是无效等价类)
-
编写完成后自我检查以及部门内部评审:
-
测试用例本身的描述是否清晰,语言准确;是否存在二义性;
-
测试用例内容是否完整,是否清晰的包含输入和预期输出的结果;测试步骤是否清晰;
-
测试用例中使用的测试数据是否恰当,准确;
-
测试用例是否具有指导性,是否能灵活的指导软件测试工程师通过测试用例发现更多的缺陷,而不是限制他们的思维;
-
是否考虑到测试用例执行的效率。对于不断重复执行的步骤,是否保证了验证点相同;或者测试用例的设计是否存在冗余性等。这些都可能导致测试用例执行效率低下;
-
画出软件需求跟踪矩阵,验证测试用例是否完全覆盖了需求,验证测试用例的覆盖性;
-
测试用例是否完全遵守了软件需求的规定。这一点其实有一些难做到。考虑到时间/成本的关系,应该视具体情况而定。
-
-
测试用例更新完善
测试用例编写完成之后需要不断完善,如遇需求更改或功能新增时,测试用例必须配套修改更新,同时在测试过程中发现设计测试用例时考虑不周,需要对测试用例进行修改完善;在软件交付使用后客户反馈的软件缺陷,而缺陷又是因测试用例存在漏洞造成,也需要对测试用例进行完善。
测试用例执行过程
首先搭建测试环境,准备好测试数据,进行预测,预测通过之后,按照测试用例进入正式测试,有效的测试执行可以将测试用例发挥最大的价值。因此,测试用例规范执行有助于更好的发现代码中存在的缺陷。好的测试执行应该包含如下内容:
1、测试执行中评估测试执行时间不足,需及时上报风险。满足质量优先,进度其次原则。
2、测试用例按优先级顺序执行,通常是基本、详细和异常顺序执行。
3、未执行用例、标志为删除或者无效的用例,需注明原因。
4、执行过程中有疑问的测试用例(场景、操作步骤、检查点等)需找测试设计人员澄清。
5、测试执行需对用例描述的检查点逐一检查,避免遗漏。
6、重视不易重现的缺陷场景,可能是一个bug。
7、执行过程中发现有前期设计遗漏用例需补充到用例文档并执行验证。
8、建议测试人员交叉执行重复测试用例,用例执行对相同测试人员有免疫性。避免可能的缺陷一直遗漏到现网。
9、如有需要,建议保留测试结果,结果可视。也便于不同版本间的测试结果对比。
10、已确认问题需及时按照问题单提单要求(规范和缺陷定级)提单。
11、跟踪问题单修复情况并回归验证问题单。
12、每轮次测试结束,find一下是否有core文件产生。
13、测试结束,将最终测试用例文档上传到归档目录,实现用例重用。
在测试用例执行过程中,包含了:功能测试阶段、缺陷跟踪阶段(bug tracking)、回归测试阶段、系统测试阶段、验收测试阶段等(系统已满足测试条件(开发完成),按照已经评审过的测试用例依次执行,执行过程中及时记录问题,将问题及时提交到QC上,要跟踪缺陷。等开发修复后进行回归测试,确认修复后关闭缺陷,如果说该问题要更新而生产上未进行验证,就把缺陷状态改为生产未验证。对有异议的缺陷经甲方、开发和测试三方进行沟通讨论,由甲方最终确定处理方式。在测试过程中也会碰到对需求有异议,会反馈给经理,由经理与甲方沟通来对该需求提出一些可行性建议,最终还是由甲方来确定具体根据各个公司的业务流程而不一样)。
测试报告
测试报告是指把测试的过程和结果写成文档,对发现的问题和缺陷进行分析,为纠正软件的存在的质量问题提供依据,同时为软件验收和交付打下基础。测试报告是测试阶段最后的文档产出物。优秀的测试经理或测试人员应该具备良好的文档编写能力,一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。
测试报告的内容可以总结为以下目录:
首页
引言(目的、背景、缩略语、参考文献)
测试概要(测试方法、范围、测试环境、工具)
测试结果与缺陷分析(功能、性能)
测试结论与建议(项目概况、测试时间 测试情况、结论性能汇总)
附录(缺陷统计)
软件测试还包含了线上功能检查、当前版本问题反馈以及改进建议等。
标签:需求,功能,缺陷,测试用例,内容,测试,执行,软件测试 From: https://www.cnblogs.com/celestially98/p/16623263.html