【小小干货助你成长】欢迎来到干货课堂之测试方法与软件测试模型（二）

【小小干货助你成长】欢迎来到干货课堂之测试方法与软件测试模型（二）

声明：以下内容为个人理解，有误请指正

一、软件测试方法

1.1 等价类划分法：把所有可能的输入数据划分为若干个子集，选取有效与无效的代表性内容作为测试用例；

• 有效等价类：
  • 以密码输入框为例：限制条件6到18位数字或者字母或特殊字符组成；
  • 6到18位之间且由数字或者字母或特殊字符组成为有效等价类；
• 无效等价类：
  • 以密码输入框为例：限制条件6到18位数字或者字母或特殊字符组成；
  • 小于6位或大于18位且不由数字或者字母或特殊字符组成为无效等价类；

1.2 边界值分析法：选取上点、内点、离点作为测试数据；

• 以密码输入框为例：限制条件6到18位数字或者字母或特殊字符组成；
  • 选取七种密码作为测试数据
  • 上点：6位密码、18位密码
  • 内点：15位密码
  • 离点：5位密码、7位密码、18位密码、19位密码

1.3 因果图（也称为判定表）：描述输入条件的组合以及每种组合对应的输出的图形化工具；

注：在因果图中Ci表原因Ei表示结果，原因与结果都可取值为0或1；

①恒等：若原因出现结果就出现，若原因不出现结果就不出现；

​ 例子：以a和b为例，a为原因，b为结果

​ a=1,b也就等于1，否则b为0。

②非：若原因出现结果不出现，若原因不出现，结果就出现；

​ 例子：以a和b为例，a为原因，b为结果

​ a=1,b也就等于0，否则b为1。

③或：若几个原因中有一个出现，结果就出现，若原因不出现结果就不出现；

​ 例子：以a、b、c、d为例，a、b、c为原因，d为结果

​ a || b || c = 1,d也就等于1，否则d为0。

④与：几个原因同时出现，结果才出现，否则结果不出现；

​ 例子：以a、b、c、d为例，a、b、c为原因，d为结果

​ a && b && c = 1,d也就等于1，否则d为0。

从原因方面考虑有四种约束条件：

⑤E（互斥、异）：a、b两个原因不能同时出现，最多只能出现一个；

⑥I（或）：a、b、c三个原因至少出现一个；

⑦O（唯一）：a、b两个原因必须出现一个，且仅有一个出现；

⑧R（要求、需求）：a出现时b必须出现；

例子：在一个功能中需求是成功添加内容需以下条件：

​ 1.在第一行输入A或B，第二行输入数字，便提示添加成功；
​ 2.在第一行非A或B，提示None；
​ 3.在第二行非数字提示Error

提取因果图要素：

原因：
C1.在第一行（C1）输入A或B，第二行（C3）输入数字；
C2.在第一行输入非A或B；
C3.在第二行输入非数字；
结果:
E1:成功添加文件（C1操作结果）；
E2:提示None;（C2操作结果）
E3:提示Error;（C3操作结果）

在因果图中的表示方法：

转化为判定表（Y表示成功修改，0代表填入违规内容或为空，1代表填入正确内容）：

序号		A	B	C	D
1	A/B	1	0	1	0
2	0~9	1	1	0	0
3	Y	1
4	None		1		1
5	Error			1	1
用例		第一行：填入A或B 第二行：填入0到9任意数	第一行：填入非A或B 第二行：填入0到9任意数	第一行：填入A或B 第二行：填入非数字	第一列：为空/违规 第二列：为空/违规

1.4 场景法：场景法分为两个流（基本流&备选流）

基本流：软件功能按照正确的事件流，中间无任何差错，从开始直接执行到结束的一条正确流程

备选流：软件功能在执行过程中，除了基本流之外可能遇到的各种情况，是包含可能存在问题的各支流

例:打折促销，满100减50，满200减80。

​ 基本流：满100减50，满200减80；

​ 备选流：未满100或200；

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

二、 软件测试模型

2.1 瀑布模型：

​
瀑布模型的优点：

• 此模型易于实现, 并且所需的资源数量也很少。
• 要求很简单, 并明确声明；在整个项目开发过程中, 它们保持不变。
• 每个阶段的起点和终点都是固定的, 因此很容易涵盖进度。
• 完整产品的发布日期及其最终成本可以在开发之前确定。
• 由于采用了严格的报告系统, 因此可以轻松控制客户并使其清晰。

瀑布模型的缺点：

• 在此模型中, 风险因素较高, 因此该模型不适用于更重要和更复杂的项目。
• 该模型不能接受开发过程中需求的变化。
• 回到阶段变得困难。例如, 如果应用程序现在已经转换到编码阶段, 并且需求有所变化, 那么回头更改它就变得很困难。
• 由于测试是在后期进行的, 因此无法在早期阶段识别挑战和风险, 因此难以制定降低风险的策略。

2.2 V模型：

​
V模型优点：

• 成功率高：项目需求一写就开始测试。计划、组件检查和设计等测试活动是在编码之前进行的，以便在早期阶段检测错误。这提高了产品的成功率，也节省了大量的时间。
• 易于管理：模型开发简单，使用方便。每个开发阶段都有明确的目标。
• 缺陷跟踪：它使用主动缺陷跟踪来确保在产品的早期开发阶段发现任何缺陷。它最大限度地减少了产品代码中未来潜在的缺陷，并确保缺陷不会向下流动。
• 对小型项目有效：V模型生命周期适用于系统需求众所周知且预计不会改变的小型项目。
• 循序渐进的过程：V模型开发是一个系统的过程，在进入下一阶段之前完成一个阶段。
• 特定的可交付成果：产品开发生命周期的每个阶段都有明确定义的特定可交付成果，并准备了测试计划来测试该阶段的产品。
• 时间更短：与瀑布模型相比，V 模型在开发周期的每个阶段开发和提出可交付成果所需的时间更少。
• 高效用资源：V型软件开发过程严重依赖效用资源来开发项目范围的每个阶段。
• 成本效益：由于测试在开发过程的早期就开始了，项目花费的时间和成本更少。
• 功能领域：它涵盖所有功能领域，以确保提供指导建议并详细解释所涉及的问题。

V模型缺点：

• 流程僵化：V型顺序流程僵化，要求不一致时不适用。
• 最终产品：客户只能看到最终产品，看不到正在设计的产品的中间模块。
• 不适合复杂的项目：这种软件开发模式不适合大型复杂的项目。如果您有一个大型项目，项目需求经常变化，您必须选择另一种开发模式。
• 不需要原型：在开发过程之前不需要早期原型。软件产品是在实施阶段开发的。
• 不灵活：V模型不灵活，鼓励软件开发的线性视图，没有响应任何软件变化的内在能力。调整项目范围是非常昂贵的。
• 虚假的安全感：V模型生命周期过于简单，无法准确反映软件开发过程，可能导致虚假的安全感。
• 没有精度：V模型缺乏连贯性和精度。
• 鼓励刚性链接：各相等效级别之间存在刚性链接。它不鼓励测试人员选择最有效的方式来规划产品和执行测试。
• 更新频繁：如果产品有变化，需要更新测试文档、需求文档。
• 满足客户期望的风险：由于没有设计原型作为项目的工作模型，有时可能很难满足客户的期望。

2.3 W模型：

​
W模型优点：

• 将测试贯穿到整个软件的生命周期中，且除了代码要测试，需求、设计等都要测试。

• 更早的介入到软件开发中，能尽早的发现缺陷进行修复。

• 测试与开发独立起来，并与开发并行。

W模型缺点：

• 对有些项目，开发过程中根本没有文档产生，故W模型无法使用。
• 对于需求和设计的测试技术要求很高，实践起来很困难。

2.4 快速原型模型：

​
快速原型模型优点：

• 服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险。
• 这种模型适合预先不能确切定义需求的软件系统的开发。

快速原型模型缺点：

• 所选用的开发技术和工具不一定符合主流的发展。

• 快速建立起来的系统结构加上连续的修改可能会导致产品质量低下。

• 使用这个模型的前提是要有一个展示性的产品原型，因此在一定程度上可能会限制开发人员的创新。

2.5 增量模型：

​
增量模型优点：

• 整个项目的资金不会被提前消耗，因为首先开发和交付了主要功能和高风险功能。
• 每个增量交付一个可操作的产品。
• 每次增量交付过程中获取的经验，有利于后面的改进，客户也有机会对建立好的模型作出反应。
• 采用连续增量的方式，可把用户经验融入到细化的产品，这比完全重新开发要便宜得多。
• “分而治之”的策略，使问题分解成可管理的小部分，避免开发团队由于长时间的需求任务而感到泪丧。
• 通过同一个团队的工作来交付每个增量，保持所有团队处于工作状态，减少了员工的工作量，工作分布曲线通过项目中的时间阶段被拉平。
• 每次增量交付的结为，可以重新修订成本和进度的风险。
• 便于根据市场作出反应。
• 降低了失败和更改需求的风险。
• 更易于控制用户需求，因为每次曾两开发的时间很短。
• 由于不是一步跳到未来，所以用户能逐步适应新技术。
• 切实的项目进展，有利于进度控制。
• 风险分布到几个更小的增量中，而不是集中于一个大型开发中。
• 由于用户能够从早期的增量中了解系统，所以更加理解后面增量中的需求。

增量模型缺点：

• 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构.
• 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
• 如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

2.6 螺旋模型：

螺旋模型优点：

• 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标

• 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险

• 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别

螺旋模型缺点：

• 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标

• 减少了过多测试（浪费资金）或测试不足（产品故障多）所带来的风险

• 在螺旋模型中维护只是模型的另一个周期，在维护和开发之间并没有本质区别

2.7 敏捷开发模型：

敏捷开发优点：

• 敏捷开发的高适应性，以人为本的特性。

• 更加的灵活并且更加充分的利用了每个开发者的优势，调动了每个人的工作热情。

敏捷开发缺点：

• 由于其项目周期很长，所以很难保证开发的人员不更换，而没有文档就会造成在交接的过程中出现很大的困难。

三、寄语

3.1 上述所讲的测试方法与软件开发/测试模型主要是为了让各位读者对整体的架构有清晰的认识；
3.2 在日常测试中大多数都是进行的敏捷测试，现在主要讲究的就是一个‘短频快（开发周期短，迭代频繁，快速发布）’；
3.3 感谢各位读者的阅读，喜欢还请多多关注、点赞、转发、收藏！！！