认识软件测试

lsekfe

一、软件测试的发展主要经历的阶段？

• 1）软件调试
• 2)独立的软件测试（1950）
• 3）软件测试的第一次进行的定义（1973——Bill Hetzel），软件测试就是对程序能够按预期的要求运行建立起一种信心。
• 4）软件成为专门的学科（1980）
• 5）开发与测试的融合（2000）
  

二、什么是软件测试？

自己刚买第一台电脑的时候，要这台电脑是否是好的，这个时候我们做的事情就是测试。
当我们买了一部手机，我们要看这部手机是否存在缺损，是否能够进行使用这就是进行测试；
当我们在考场上进行答卷的时候，发现自己的答案有错误，从而进行不停的检查，这就是测试。等等！
这就涉及到了两层含义
1）验证软件的正确性
2）找出软件中的bug
软件测试的目的
核心验证软件有或没有问题。
我们想以最少的人力，物力和时间找出软件潜在的各种错误和缺陷，通过修正错误和缺陷，提高软件的质量，回避软件发布后由于潜在的软件缺陷和错误造成的隐患带来的商业风险。

三、需求的概念

满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能。（权能：权利范围的大小）。包含了用户需求和软件需求。
用户需求：不能指导开发和测试人员下一步工作。可以简单的理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须完成的任务。该需求一般都是比较简略的。
软件需求：测试人员可以编写测试用例，开发人员针对测试用例去编写相应的代码。是测试人员进行测试的基本依据。
缺陷：需求规格说明书且正确，与需求规格说明不匹配的，如果没有规格说明书，以客户期望为主。
用户说明书有前置条件和后置条件：注册是登陆的前置模块，登陆是注册的后置模块。

四、bug

bug的概念：当且仅当规格说明书是存在的并且正确的，程序与规格说明书之间不匹配才是错误的。
测试用例（Test Case）：为了实施测试而向被测试的系统提供的一组集合，包括：测试环境、操作步骤、测试数据、期望（预期结果）等。
用例的编号是唯一的。
覆盖率简单的来说就是看我们的测试用例是否全面的测试了所有的功能。
编写测试用例的个数/功能点个数=覆盖率（类似于我们计算及格率）
例子：
我们对软件的新版本的测试很难实施（在进行测试的时候，当我们进行版本的升级测试，我们只需要针对这个新版本的部分的，例如1.1的版本为900个测试用例，则1.2版本的测试用例则在900的基础上增加新的测试用例 ）。
对大量冗余测量影响测试效率，当我们删除一个功能的时候，也就要删除掉相应的测试用例。

五、软件的生命周期

软件的生命周期：软件的生命周期指的是从软件产品的设想开始到软件不再使用而结束的时间。
分为六个阶段：需求分析、计划、设计、编码、测试、运行维护。

六、开发模型：

瀑布模型：

瀑布模型是每一个阶段都线性的执行一次。因此是一种线性顺序进行的软件开发模式。
适合需求比较稳定的项目，并且公司以前做过类似的项目。
优点：
● 强调开发的阶段性
● 强调早期计划及需求调查，
● 强调产品测试
缺点
● 依赖于早期进行唯一一次需求调查，不能适应需求的变化。
● 单一流程，开发中的经验教训反馈应用于本产品的过程；
● 风险往往到后期才显现出来，早期没有纠正的机会。

螺旋模型
适合规模比较庞大，复杂度高、风险大的项目。它要求测试必须跟随开发的迭代而迭代。
优点：
● 枪挑严格的全过程风险管理。
● 提供检讨项目是否有必要再继续进行下去
缺点
● 对风险管理的要求也就是非常高了 。一如了非常严格的风险识别、风险分析和风险控制。
● 需要资金和人员和时间进行投入
增量和迭代
增量开发模型。鼓励用户进行反馈，每一次的迭代意味着用户的需求就要进行改变了，构建出新的可执行软件版本。意味着我们测试人员要频繁的进行。
增量：逐块进行构造的理念，就是我们将每一部分进行开发好了之后，然后进行拼凑起来的。
迭代：就是反复求精的过程：先进行整体的构造，然后进行局部的修剪。

敏捷

■ 核心主要强调的是人和人之间的沟通
■ 轻文档
■ 用户要参与过来
■ 拥抱变化（在开发过程中允许项目进行变化）

scrum是敏捷的开发模式的一种
三个角色
■ product owner（类似于产品经理，简称po）对整个产品进行负责，拿到用户故事，进行分解
■ scrum master（敏捷教练）sm负责召开各种会议，协调项目、为研发团队服务
■ team（研发团队）完成每一次迭代的目标，交付产品。
迭代开发
■ scrum将产品开发分成了许多不同的小sprint（迭代），其周期从1周期到4周期不等，成员为5到9人，每一个周期要完成的user story（用户故事或用户需求）是不同的。每次迭代的时候会产生交付。
scrum的基本流程
■ 产品负责人负责整理user story
■ 发布计划会议
■ 迭代计划会议
■ 每日例会
■ 演示会议
■ 回顾会议
敏捷中的测试
▇ 轻文档（测试人员不能依赖文档，更多的是采用思维导图、探索性测试、自动化测试）
▇ 快速迭代

七、软件模型

软件测试模型V模型

◆ 描述了测试阶段和开发过程中各阶段的变种对用关系
◆ 单元和集成测试检测程序的执行是否满足软件设计的要求。系统测试应检测系统功能、新歌能质量特性是否达到了用户要求的性能指标。验收测试是主要是确定软件是否满足了用户需要和合同的要求。
◆ 局限性：测试在编码之后才进行参与，未在需求阶段进入测试。
软件测试W模型（双V模型开发与测试是并行的）

◆ 明确测试和开发的并行的过程
◆ 测试和开发同步进行的
◆ 有利于更早的发现问题
◆局限性：需求、设计、编码等活动被视为串行的，无法支持敏捷的开发模式。不能满足频繁的进行变更。

八、配置管理

配置管理：是通过对软件生命周期不同的时间点上的软件配置进行标识，并对这些被标识软件配置项的更改进行系统控制。（类似于图书管理员）
软件配置管理：（SCM）：在软件开发过程中会产生大量的软件产品（包括文档、源代码、和数据等）。同一个软件产品还会产生变更的。，从而产生许多新的版本，也需要重现原来的版本。这些都是我们需要软件配置管理进行实现的。
配置管理和软件测试
测试人员应该从配置库取源代码编译后再测试，只有看到新的构建版本不再出现那个bug，才能把缺陷库中的bug关闭。

出处：https://blog.csdn.net/daboluo521/article/details/81224464

puchonghui

* 瀑布模型诞生于1970年，一般认为瀑布模型的诞生标志着软件工程这门学科的建立。不知道这篇文章说软件学科诞生于1980年是什么出处
* 虽然没有看到当时瀑布模型的原始定义，但是既然有测试阶段，我相信1970年一定已经对测试阶段进行过定义
* 购买电脑以后确认是否好用，这个最多只能算做用户验收测试，单个用户对于某个产品的测试，仅针对单个用户个体的需求。 而对于电脑这个产品的测试，需要针对所有用户的全部需求，这完全是两个层面。
* 用户需求与软件需求的差异，类似于手机使用者的需求和手机生产方的需求，使用一个手机需要知道哪些数据，生产一个手机需要知道哪些数据。。。

误导的内容太多