软件测试 - 概念篇

先简单回顾上一篇的博客内容:初识软件测试

1: 我们要搞清楚什么是软件测试?
软件测试就是软件测试人员验证软件是否满足用户的需求
2: 软件测试和软件开发的区别?
1)本身:开发广度小,专业度高,测试所需技能比较广泛,但是专业度掌握比较低,难易程度还是有些区别,薪资,工作环境,压力,责任等等…
2)软件测试和软件调试的区别:
目的:
软件开发人员要确保程序做了他想要实现的功能,软件测试是测试人员确保程序实现了他应该实现的功能(用户需求)
角色:
测试: 开发人员和测试人员共同完成
开发: 开发人员
阶段:
软件测试: 贯穿整个软件的生命周期
软件开发: 开发阶段
3: 你为什么选择软件测试?
综合能力:沟通,学习,开发,文字
自动化测试技术
编写测试用例能力
探索性思维 (自动售卖机)
兴趣
责任感,压力

衡量软件测试结果的依据—需求

我们先要了解什么是需求?
用户的期望和满足合同(文档,规则,标准)的规定所需要的条件和权限,包含用户需求和软件需求
用户需求:
该需求比较粗略,直接实现会有困难,因为他没有细节,一般他是有甲方提出的需求,需要软件需求把用户需求细节实现和规范,把用户需求变成一个具体的可实现的过程性文档
软件需求:
就是用户需求转换而来的,他就是用户需求的细化,使用户需求的具体实现细节和规范

需求是软件测试的依据,要验证需求,保证需求正确可以实现,然后从需求中提炼出一个个的测试项,过程如下,就是业务需求,软件功能需求点,测试需求点,测试用例

以"用户登录"为例,来阐述这个过程:

为什么需求对软件测试人员如此重要?
从软件功能需求出发，无遗漏的识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率
对于识别出的每个测试需求点，需要采用具体的设计测试用例的方法来进行测试用例的设计

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

测试用例概念

测试用例就是向被测试系统发起的一组集合,包含测试环境,测试数据,测试步骤,预期结果(这四个一定要记住)要素,还可有(重要性,优先级,操作方式,标题等等)

例如:一个网易邮箱的登录界面:

测试用例告诉了我们要测什么,怎么测
优点:衡量需求的覆盖率;复用性;可以用于回归测试;防止遗漏测试需求

什么是软件错误(BUG)?

1: 当且仅当,程序规格说明书(软件需求)存在并且是合理的,如果软件功能和软件规格说明书不相符合,就说明是软件错误的;
2: 当软件需求不存在,用户需求存在并且合理,软件功能和用户功能不相符合,说明是软件错误的.

开发模型

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

瀑布模型(Waterfall Model)

瀑布模型在软件工程中占有重要地位，是所有其他模型的基础框架。瀑布模型的每一个阶段都只执行一次，因此是线性顺序进行的软件开发模式。
特点:
阶段性强,每一个阶段比较独立;看重前期的需求分析和后期的测试
缺点:
测试在编码后才开始介入,导致前期的问题后期才会发现,会失去错误补救的机会

瀑布模型的一个最大缺陷在于，可以运行的产品很迟才能被看到。这会给项目带来很大的风险，尤其是集成的风险。因为如果在需求引入的一个缺陷要到测试阶段甚至更后的阶段才发现，通常会导致前面阶段的工作大面积返工，业界流行的说法是：“集成之日就是爆炸之日”。尽管瀑布模型存在很大的缺陷，例如，在前期阶段未发现的错误会传递并扩散到后面的阶段，而在后面阶段发现这些错误时，可能已经很难回头再修正，从而导致项目的失败。但是目前很多软件企业还是沿用了瀑布模型的线性思想，在这个基础上做出自己的修改。例如细化了各个阶段，在某些重点关注的阶段之间掺入迭代的思想。
在瀑布模型中，测试阶段处于软件实现后，这意味着必须在代码完成后有足够的时间预留给测试活动，否则将导致测试不充分，从而把缺陷直接遗留给用户。

螺旋模型(Spiral Model)

一般在软件开发初期阶段需求不是很明确时，采用渐进式的开发模式。螺旋模型是渐进式开发模型的代表之一。
这对于那些规模庞大、复杂度高、风险大的项目尤其适合。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。因此，回归测试的重要性就不言而喻了。(他是适合于项目庞大,风险大,不是很明确的项目)

特点:
强调每一个迭代的测试质量和风险分析
缺点:
风险管控人力物力投入太多,成本比较大

增量、迭代模型

增量开发能显著降低项目风险，结合软件持续构建机制，构成了当今流行的软件工程最佳实践之一。增量开发模型，鼓励用户反馈，在每个迭代过程中，促使开发小组以一种循环的、可预测的方式驱动产品的开发。因此，在这种开发模式下，每一次的迭代都意味着可能有需求的更改、构建出新的可执行软件版本，意味着测试需要频繁进行，测试人员需要与开发人员更加紧密地协作

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

简单来说: 针对同一个系统的四个模块: A B C D 两周的时间完成
增量模型:
第一周开发A B 功能模块,第二周开发C D功能模块
迭代模型:
第一周先开发 A B C D 的基础功能,第二周在其基础上进行完善其他功能

敏捷模型

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

个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，但我们更看重前者
特点:
轻文档,轻流程,重目标,重产出,拥抱变化(能够适应需求的变化)

由敏捷宣言可以看出，敏捷其实是有关软件开发的社会工程(Social Engineering)的。敏捷的主要贡献在于他更多地思考了如何去激发开发人员的工作热情，这是在软件工程几十年的发展过程中相对被忽略的领域。
敏捷开发有很多种方式，其中scrum是比较流行的一种。

测试模型

V模型

特点:
每一个阶段独立性强:
左边每一个阶段是右边测试阶段的依据,和右边每一个测试阶段一一对应
他就是瀑布模型的变种,继承了他的缺点
缺点:
编码后才能进行测试,前期的错误到后期才会发现,会失去及时纠正的机会

W模型

也叫他双 V 模型
特点:
每一个阶段独立性强:
测试一开始就介入了,可以保证前期的问题及时发现并纠正,测试和开发是并行的
缺点:
每一个阶段都是串行的过程:
一个阶段完成后才能进入下一个阶段,不支持敏捷开发