测试常用方法及应用场景

最新推荐文章于 2025-02-25 11:13:39 发布

努力。。。

最新推荐文章于 2025-02-25 11:13:39 发布

阅读量4k

点赞数 2

本文链接：https://blog.csdn.net/weixin_56394378/article/details/116461475

版权

1、你在编写测试用例使用哪些方法？

1：等价类划分法(重点)
应用场景：多用于输入框
等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。
等价类：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。
一般可分为有效等价类和无效等价类

有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

2：边界值法(重点)
一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。
2.1确定边界值的方法（重点）
选取正好等于、刚刚大于或刚刚小于边界值作为测试数据
注明:边界值不是从每个等价类中挑一个作为代表，而是把每个等价类的边界都进行测试。

3.因果图法（了解）
概念:
因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出

因果图基本图形符号
恒等：若原因出现，则结果出现；若原因不出现，则结果不出现。
非（～）：若原因出现，则结果不出现；若原因不出现，则结果出现。
或（∨）：若几个原因中有一个出现，则结果出现；若几个原因都不出现，则结果不出现。
与（∧）：若几个原因都出现，结果才出现；若其中有一个原因不出现，则结果不出现。

因果图的约束符号
E（互斥）：表示两个原因不会同时成立，两个中最多有一个可能成立
I（包含）：表示三个原因中至少有一个必须成立
O（惟一）：表示两个原因中必须有一个，且仅有一个成立
R（要求）：表示两个原因，a出现时，b也必须出现，a出现时，b不可能不出现
M（屏蔽）：两个结果，a为1时，b必须是0，当a为0时，b值不定

4：判定表法（了解）

5：场景法（重点）
测试用例设计的思想
现在的软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。这种在软件设计方面的思想也可以引入到软件测试中，可以比较生动地描绘出事件触发时的情景，有利于测试设计者设计测试用例，同时使测试用例更容易理解和执行。

用例场景是通过描述流经用例的路径来确定的过程，
这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

6：错误推测法（了解）
定义：
错误推测法：根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的黑盒测试方法

技巧：
最重要的是要思考和分析测试对象的各个方面，多参考以前发现的bug的相关数据，总结的经验，个人多考虑异常的情况、反面的情况、特殊的输入，以一个攻击者的态度对待程序，就能设计出比较完善的测试用例来。

7：正交表法（知道）
正交表能够在因素变化范围内均衡抽样，使每次试验都具有较强的代表性，由于正交表具备均衡分散的特点，保证了全面实验的某些要求，这些试验往往能够较好或更好的达到实验的目的。正交实验设计包括两部分内容：第一，是怎样安排实验；第二，是怎样分析实验结果。

应用场景：
在一个界面中有多个控件，每个控件有多个取值，控件之间可以相互组合，不可能（也没有必要）为每一种组合编写一条用例，如何使用最少最优的组合进行测试。——正交排列法

正交表测试用例设计方法的特点是什么？
1、用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
2、对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
3、体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

2、测试用例模板/ 测试报告模板 / 测试计划模板

1. 测试用例模板
用例编号、所属模拟、测试模块、用例标题、用例级别、前置条件、测试输入、执行操作、预期结果,实际结果….

2.测试报告模板
测试目标,测试依据,测试范围,测试环境,测试进度,执行结果,缺陷分布,遗留缺陷,测试结论,建议,附录等

3.测试计划模板包含
确定测试范围，制定测试策略，测试资源安排人员的分配，时间安排，风险分析等

3、需求变动应该如何

1.前期需求调研工作没有做到位，在需求调研时没有真正深入了解用户需要什么东西？用户做这个东西的目的是什么？为什么要这么做？

2.项目经理对项目掌控力度够，如果一个项目的需求一定情况向，尽可能避免在短时间里频繁变更，可以采用集中变更或者分阶段变更

3.客户在最开始时自己也没搞清楚要做出什么样子？随着系统的成型上线，提出一些新想法等导致需求变更。

4.客户就是上帝，所以有些变更时必须的

测试人员如何面对变更？

1．协调制定变更规范，比如说每次需求人员都会发出变更申请书，这样可以作为开发人员和测试人员工作的依据。如果这点也做不到的话，建议把发给开发人员的变更信息同时抄送给测试人员，使测试人员和开发人员保持信息基本一致

2．在每次测试前，一个比较详细的测试测试任务列表单，同时注明本次测试的侧重点【变更哪些需求、新增了哪些需求】，找相关人员确认【可以抄送多人】

3．良好的团队合作。对新的改动及时通知对方，短时间内开展最有效的团队协作及时沟通，需求相关人员和开发人员、测试人员做好即时沟通，第一时间知道需求的变更，及时做好测试策略更新。知道的越早对我们的影响越小，需要的测试成本也越低。

4．及时整理并记录测试需求变更，在每次不论通过何种方式得到需求变更信息，都要及时记录，以便以后测试

5．每天保持记录测试工作日志，主要包括【1.测试中遇到的问题及其解决方式（可以形成测试知识库）、2.记录测试任务及其工作成果（主要是记录今天做了什么？成果是什么？以便以后总结）、3.记录测试进度（记录个人或者团队的工作进度情况；这样时间长了就基本可以评估测试那个模块，那个流程，哪一类问题需要多长时间，以便对日后工作做一个计划）、4。记录测试问题总结等（对问题归类总结，时间长知识库、日后需要加强学习和注意的地方）】

6．测试人员应该把需求变化当作是一种项目常态，平常心应对。任何项目要想安装预期规划发展那几基本上是做不到的，所以变更将是我们工作中的一个常态。