了解软件测试的概念

        本文我们来了解软件测试 的一些基本概念。同时需要记住衡量软件测试结果的依据—需求；

1. 需求的概念

        满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求。（其实就是客户想要软件完成的一些功能指标）

        IEEE定义软件需求是：

         (1)用户解决问题或达到目标所需条件或权能(Capability)。

        (2)系统或系统部件要 满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。 一种反映上面(1)或(2)所述条件或 权能的文档说明。它包括功能性需求及非功能性需求，非功能性需求对设计和实现提出了限制，比如性 能要求，质量标准，或者设计限制。

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

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

        软件需求：或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能。 大多数公司在进行软件开发的时候会把用户需求转化为软件需求，开发人员和测试人员工作的直接依据就是软件需求；

2. 从软件测试人员角度看需求

        软件需求是测试人员进行测试工作的基本依据。即需求是开发人员的标准，也是测试人员编写测试用例的一个依据；

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

        过程如下，业务需求—>软件功能需求点—>测试需求点—>测试用例

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

3. 测试用例的概念 

3.1 测试用例

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

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

3.2 为什么要有测试用例

        测试用例是测试人员用来执行执行测试的依据；

        测试用例降低测试工作的冗余度；

        测试用例也是执行自动化的依据；

3.3 软件错误（BUG）的概念

        当且仅当规格说明（软件需求）是存在的并且正确，程序与规格说明（软件需求）之间的不匹配才是错误。即当程序没有实现其最终用户合理预期的 功能要求时，就是软件错误。

4. 软件的生命周期

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

4.1 瀑布模型（Waterfall Model）

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

        1、特点：线性的

        2、优点：在每一个阶段应该干什么都非常明确；

        3、缺点：发现问题的时机太晚，太晚的话就会导致一些时间

人力等资源浪费；

        4、比较适用于比较小的项目；

4.2 螺旋模型（Spiral Model）

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

        特点：软件每进入到下一个新的阶段的时候都会进行风险分析；

        优点：风险分析可以避免一些问题出现在线上

        缺点：如果风险分析错误，就会将问题直接暴露在线上，故此风险分析需要具备一定的知识；

        适用项目：适用于大型项目，以及风险较多的项目；

4.3 增量、迭代 

        下图来简单粗暴的了解一下这两种模型：

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

4.4 敏捷

        敏捷的价值观：

        个体与交互重于过程和工具

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

        客户协作重于合同谈判

        响应变化重于遵循计划

        在每对比对中，后者并非全无价值，但我们更看重前者。

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

4.5 scrum 

        scrum里面的角色 ：scrum由product owner(产品经理)、scrum master(项目经理)和team(研发团队)组成。

        其中product owner负责整理用户需求，定义其商业价值，对其进行排序（指定所有需求的优先级和先后顺序），制定发布 计划，对产品负责。

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

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

        scrum的基本流程：

        产品负责人负责整理user story，形成左侧的product backlog。

        发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出 就是制定出这一期迭代要完成的story列表，sprint backlog

         迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每 个任务都有明确的负责人，并完成工时的初估计。

        每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什 么问题。

        演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取 得的成果。期间大家的反馈记录下来，由po整理，形成新的story。

         回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达 到持续改进的效果。 

 4.6 软件测试v模型

4.7  软件测试W模型

ps：本文就写到这里了，谢谢观看