本文主要介绍软件测试相关的一些基础概念.

主要内容包括 :

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

一 : 什么是需求

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求.

在这里插入图片描述
用户需求为什么不可以直接作为测试/开发工作的依据呢 ? 因为用户需求未必是合理的 . 我看过一个段子 , 有用户提出这样一个需求 : 能不能根据周围环境的颜色变化 , 动态地改变手机屏幕的颜色 ? 这好吗 ? 这不好 ! 当然 , 如果用户需求是合理的 , 并且有开发的必要 , 那么产品经理就会将用户需求转变为软件需求文档 .

在这里插入图片描述

二 : 从软件测试人员角度看需求

需求是测试人员开展软件测试工作的依据.

在具体设计测试用例的时候，首先需要搞清楚每一个业务需求对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，然后针对每个测试需求点设计测试用例 .

以“用户登陆”为例，来阐述下整个过程：

在这里插入图片描述

Q : 如何才可以深入理解被测试软件的需求 ?

A : 测试工程师在需求分析和设计阶段就开始介入，因为这个阶段是理解和掌握软件的原始业务需求的最好时机 .
只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确，从终端用户的使用场景到端到端的覆盖率较高的测试用例集 .

三 : 什么是测试用例

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

在进行软件测试,尤其是软件功能比较复杂时,仅仅通过想一个测一个的方法来进行测试肯定是不可取的.

测试用例的存在是为了提高测试覆盖率 , 如果不设计测试用例 , 很可能造成漏测的风险 , 虽然在测试中有句话叫做"不可能做到完全的测试" , 但测试人员还是要尽可能的去避免漏测 , 保证线上不会出现明显的问题 !

测试用例解决了两大问题：测什么，怎么测 .

例如 , 我们要测试在百度的输入框中输入空格 , 会出现什么 ? 可以这样设计测试用例 :

在这里插入图片描述

假如针对某个功能,测试人员需要设计几十个甚至上百个用例 , 这样去编写测试用例是很麻烦的 ;

现在的互联网企业 , 测试人员在工作中不再需要借助这么繁琐的编写测试用例的方式 , 企业中主要使用思维导图(脑图)的方式来编写测试用例 !

顺便提一句 , 将来在笔试时 , 如果要求我们去编写测试用例 , 仍然要按照测试用例的要素来编写测试用例 !

四 : 什么是BUG

Bug是一个英文单词，本意是指昆虫、小虫子。

那为什么测试就是在找Bug呢？

这需要我们去追溯历史，当时人们还在使用第一代真空计算机（马克二型），这种计算机是依靠控制电流来改变开关，从而实现控制，但是它会发出大量的热和光。1949年9月9日，天气非常炎热，有一只娥死在了70号继电器里面，造成电路不通，机器死机，经过近一天的检查，Grace Hopper（格蕾斯哈珀）终于找到了真凶，原来正是被光吸引过来的娥造成了机器宕机，在这儿之后，在计算机科学中，Bug就从虫子变成了程序的缺陷，一只虫子就这样被载入了计算机史册。

第一份缺陷报告也由此诞生啦 !

在这里插入图片描述

准确来说：当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误 .

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

五 : 开发模型

可以理解为开发流程/项目推进流程,即软件的生命周期.

软件生命周期是指从软件产品的设想开始到软件不再使用而结束的时间 . 如果把软件看成是有生命的事物，那么软件的生命周期可以分成6个阶段，即需求分析、计划、设计、编码、测试、运行维护 .

在这里插入图片描述

假如我们现在要建造一所房子 , 那么房子的生命周期是什么 ?

在这里插入图片描述

通过类比 , 理解软件的生命周期 :

在这里插入图片描述

六：八大模型

6.1 瀑布模型

在这里插入图片描述
瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。

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

缺点：线性结构意味着前一个阶段结束后一个阶段才能开，导致风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。测试被后置，需要保留足够的时间给测试，否则导致测试不充分，缺陷直接暴露给用户。一个最大缺陷在于，可以运行的产品很迟才能被看到。总而言之，瀑布模型是不能够很好的迎接变化。

适用场景:需求固定的小型项目~~

6.2 螺旋模型

在这里插入图片描述

在瀑布模型的基础上增加了风险分析，生成新的原型。瀑布模型增加了风险分析阶段，所以团队一般需要耗费一定的资金和时间去招聘风险分析人才。

适用场景：需求不确定，变化的可能性很大的大型项目。

6.3 增量模型

在这里插入图片描述

增量模型：将项目进行模块化，使其每个模块都能进行独立的开发和上线。

优点：产品能够在较短时间内尽快地交付给用户使用。

6.4迭代模型

假如说有一个产品包含五个功能A B C D E，迭代模型会先完成这五个功能的基础版本，会再经历一次一次的迭代优化，直到这五个功能非常的优秀。

增量通常和迭代混为一谈，但是其实两者是有区别的。增量是逐块建造的概念，例如画一幅人物画，我们可以先画人的头部，再画身体，再画手脚……而迭代是反复求精的概念，同样是画人物画，我们可以采用先画整体轮廓，再勾勒出基本雏形，再细化、着色。

6.5 敏捷模型

2001年，以Kent Beck、Alistair Cockbum、Ward Cunningham、Martin Fowler等人为首的“轻量”过程派聚集在犹他州的Snowbird，决定把“敏捷作为新的过程家族的名称。
在会议上，他们提出了《敏捷宣言》：我们通过身体力行和帮助他人来揭示更好的软件开发方式。经由这项工怍，我们形成了如下价值观：

在这里插入图片描述
敏捷宣言的解读：强调团队内部人员尽可能的进行高效的沟通敏捷模型最终的标准就是：可交付的软件。