一文带你走进软件测试的大门

目录

前言

需求

用户需求

软件需求

从测试人员的角度看需求

测试用例

测试环境

测试数据

预期结果

操作步骤 

为什么要有测试用例

 Bug的概念

世界上的第一个bug

bug的定义

开发模型和测试模型

软件的生命周期

开发模型

瀑布模型

螺旋模型

增量、迭代

敏捷

敏捷中的测试

V模型

W模型

---

前言

在正式开始进行软件测试之前,我们需要进行前置知识的储备,这篇文章主要是软件测试的基础知识,为了以后正式测试打下坚实的基础.

需求

满足用户期望或正式文档所规定的标准,规范.所具有的条件或者权能,包含用户需求和软件需求.

用户需求

用户需求可以简单的理解为是甲方提出的需求.如果要是没有甲方,就是用户提出的需求

软件需求

把用户的需求转为详细的文档,就是软件需求.软件需求是测试人员进行测试工作的基本依据.

从测试人员的角度看需求

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

 需求对测试人员的重要性

• 从软件功能的需求出发,无遗漏的找出测试用例是至关重要的,这将直接关系到测试用例的覆盖率.
• 对于识别出的每个测试需求点,都要采用具体的设计测试用例的方法,来进行测试用例的设计.

 上面我们对此的提到测试用例,那么我们下面将详细的介绍测试用例.

测试用例

测试用例是为了实施测试为给被测试系统提供的一组集合,包括了测试环境,测试数据,预期结果,操作步骤等.

测试用例主要是为了解决测试什么,怎么测试的问题,

测试环境

例如:LeetCode提供的测试环境,可以在浏览器中打开,浏览器就是测试环境.

测试数据

例如:牛客上面,可以自定义测试数据,后台也提供了一组测试环境.

预期结果

当前测试数据通过100%

操作步骤 

写完代码,点击提交

为什么要有测试用例

测试用例可以提高测试人员的工作效率,减低测试用重复测试的问题.

测试用例是我们建立自动化测试的基础.

接下来我们写一个手机打电话的测试用例:

 Bug的概念

世界上的第一个bug

1945年9月的某天，在一间老式建筑里，从窗外飞进来一只飞蛾，此时Hopper正埋头工作在一台名为 Mark Il的计算机前，并没有注意到这只即将造就历史事件的飞蛾。这台计算机使用了大量的继电器（电 子机械装置，那时还没有使用晶体管）。突然，Mark II死机了。Hopper试了很多次还是不能启动，他 开始用各种方法查找问题，最后定位到了某个电路板的继电器上。Hopper观察这个继电器，惊奇地发 现一只飞蛾已经被继电器打死。Hopper小心地用镊子将飞蛾夹出来，用透明胶布贴到“事件记录本”中， 写上“第一个发现虫子的实例”。Hopper的事件记录本，连同那只飞蛾，现在都陈列在美国历史博物馆 中。 软件错误的一般定义： 程序与规格说明之前不匹配 。

bug的定义

我们在理解bug的过程中需要注意一点,上面的理解并不适用于我们现在的体系结构.

当程序没有实现与最终用户合理预期的功能要求时,就是软件错误(bug).

程序与软件需求不匹配

预期结果与执行结果不符合

开发模型和测试模型

软件的生命周期

软件的生命周期是指一个软件从诞生到消亡的整个过程.

注意:所有互联网软件的诞生都是基于需求诞生的.

软件的生命周期总的来说分为6个部分:

• 需求分析
• 计划
• 设计
• 编码
• 测试
• 运行
• 维护

开发模型

瀑布模型

 瀑布模型在软件工程中占有重要的地位,是其他模型的基础框架,瀑布模型每一个阶段都只执行一次,因此是线性的进行软件开发的模式.

优点:每个阶段需要做什么,产出什么,都是非常清楚的.

缺点:风险往往都是在后期再显现出来,后期进行纠错的成本是比较高的.

特点:适用于比较小的项目,开发周期短的项目.

螺旋模型

一般在软件开发初期阶段需求不是很明确的时候,采用渐进的开发方式进行开发,螺旋模型是渐进式开发模型的代表之一.

但是这种开发模型,给测试也带来了新的要求,就是测试必须跟着开发的迭代也进行迭代.

优点:强调严格的全过程风险管理。 强调各开发阶段的质量。 提供机会检讨项目是否有价值继续下去.

缺点:引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入.

特点:这个模型一般适用那种大型的,规模大的项目,开发周期长的项目.

增量、迭代

例如开发一个软件，增量就是逐次开发，先开发模块1，然后开发模块2，在开发模块3……

迭代就是先开发模块1一部分，然后开发模块2一部分……

敏捷

轻流程,重交互,拥抱变化.

敏捷宣言:

• 个体与交互重与过程与工具

• 可用的软件重于完备的文档

• 客户的协作重于合同谈判

• 相应变化重于遵循计划

敏捷中的测试

V模型

  特点：线性的，左边是开发，右边是测试

  优点：每个阶段要干什么事情区分的非常清晰，测试被分为许多类型

  缺点：测试人员介入太晚，测试和开发是串行的。

W模型

  特点：开发一个V测试一个V

  优点：测试人员尽早介入了解需求 测试和开发是并行的。

  缺点：不能拥抱变化，也就是意味着不能适用于敏捷开发。 测试和开发在一定程度上也是串行的。