从0开始学测开—认识软件测试

从0开始学测开

• 软件测试
• 1.需求---衡量测试结果的依据
• 2.bug
• • **BUG的由来**
  • **BUG的类型**
  • **BUG的生命周期**
• 3.测试用例的概念
• • 1 **等价类**
  • 2 **边界值**
  • 3 **因果图法**
• 4. **开发模型和测试模型**
• • **敏捷**
  • **W模型和V模型**

软件测试

从本节博客开始，我会用我本人的角度来带大家看一下软件测试，在开始第一次软件测试之前，我们需要先了解软件测试的一些基本概念。

分为接下几点。

• 什么是需求
• 什么是bug
• 什么是测试用例
• 开发模型和测试模型
• 配置管理和软件测试

1.需求—衡量测试结果的依据

需求的概念
软件需求是 (1)用户解决问题或达到目标所需条件或权能(Capability)。

(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。

一种反映上面(1)或(2)所述条件或的文档说明。

它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性能要求，质量标准，或者设计限制。

在多数软件公司，会有两部分需求，一部分是用户需求，一部分是软件需求

用户需求：可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成的任务。

该需求一般比较简略。

软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。

大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求。

所以我们获取测试用例就要如下 *** 作：
业务需求—>软件功能需求点—>测试需求点—>测试用例
比如客户说我需要一个账号登录系统，我们就根据需求进行分析

因此总结：
测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。

只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集。

2.bug

当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误。

（Bug）

BUG的由来

1、缺乏有效沟通

2、软件的复杂度

3、编程错误

4、不断变更的需求

5、时间的压力

了解了BUG的定义以及由来后，那就要去了解BUG的类型，只有了解了BUG的类型，才能有的放矢，才能有目的，有范围的去寻找BUG，避免盲目寻找BUG，浪费宝贵的测试时间。

BUG的类型

   要确定一个BUG的类型，需要对项目（或产品）有比较深的理解。

这个划分对于问题类型的统计就比较重要了。

划分方式一：
功能问题、设计缺陷、界面优化、性能问题、配置相关、安装部署、安全相关、标准规范、测试脚本、文档错误、兼容问题、用户体验、其它。

BUG的生命周期

发现BUG–>提交BUG–>指派BUG–>研发确认BUG–>研发去修复BUG–>回归验证BUG–>是否通过验证–>关闭BUG

3.测试用例的概念

测试用例（Test Case）是为了实施测试而向被测试的系统提供的一组集合，这组集合包含：测试环境、 *** 作步骤、测试数据、预期结果等要素。

三个常用的测试用例方法

1 等价类

等价类就是把输入划分成若干个等价类，从每一个等价类中取出一个测试用例，如果这个测试用例能够测试通过，那么我们就说这个测试用例代表的等价类测试通过。

有效等价类：符合程序规格说明的数据集合；
无效等价类：不符合软件需求规格说明的数据集合；

例子：1，3，5，6都是属于小于10的

2 边界值

针对输入和输出的边界进行测试用例的设计。

案例：

购买3000元以内的华为只能手机

价格：<=3000, 3001就不行

等价类：

有效等价类：小于3000

无效等价类：大于3000

边界值：2999 3001

3 因果图法

当输入很多，并且不同的输入组合对应这不同的输出，这个时候用因果图法来分析不同输入组合和输出之间的对应关系。

（相当于逻辑图）

逻辑关系：恒等 与 或 非
这里拿双十一红包使用举例（每个条件有两个值）2的三次方为8.但是通常设计时候，我们要注意，把不符合逻辑的删除了。

4. 开发模型和测试模型

随着软件工程学科的发展，人们对计算机软件的认识逐渐深入。

软件工作的范围不仅仅局限在程序编写，而是扩展到了整个软件生命周期，如软件基本概念的形成、需求分析、设计、实现、测试、安装部署、运行维护，直到软件被更新和替换新的版本。

软件工程还包括很多技术性的管理工作，例如过程管理、产品管理、资源管理和质量管理，在这些方面也逐步地建立起了标准或规范。

瀑布模型（Waterfall Model）
经典的模型

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。

瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

优点： –强调开发的阶段性； –强调早期计划及需求调查； –强调产品测试。

缺点： –依赖于早期进行的唯一一次需求调查，不能适应需求的变化； –由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程； –风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。

这会给项目带来很大的风险，尤其是集成的风险。

因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。

尽管瀑布模型存在很大的缺陷，
例如，
在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。

但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。

敏捷

敏捷宣言

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。

敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。

scrum
敏捷开发有很多种方式，其中scrum是比较流行的一种。

scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成

1. 其中product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责。
   

   
   

2. scrum master 负责召开各种会议，协调项目，为研发团队服务。
   

   
   

3. 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品。
   

   
   

W模型和V模型

V模型最早是由Paul Rook在２０世纪８０年代后期提出的，目的是改进软件开发的效率和效果。

是瀑布模型的变种。

明确的标注了测试过程中存在的不同类型的测试，并且清楚的描述了这些测试阶段和开发过程期间各阶段的对应关系。

V模型指出，单元和集成测试应检测程序的执行是否满足软件设计的要求；系统测试应检测系统功能、性能的质量特性是否达到系统要求的指标；验收测试确定软件的实现是否满足用户需要或合同的要求。

局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试。

W模型增加了软件各开发阶段中应同步进行的验证和确认活动。

W模型由两个V字型模型组成，分别代表测试与开发过程，图中明确表示出了测试与开发的并行关系。

W模型特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的。

**W模型优点：**有利于尽早地全面的发现问题。

例如，需求分析完成后，测试人员就应该参与到对需求的验证和确认活动中，以尽早地找出缺陷所在。

同时，对需求的测试也有利于及时了解项目难度和测试风险，及早制定应对措施，显著减少总体测试时间，加快项目进度。

局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。

无法支持敏捷开发模式。

对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。