目录
本章开始我们来开始了解测试。
简单介绍测试
我们先简单的介绍一下测试工程师
测试工程师，软件质量的把关者，工作起点高，发展空间大。我国的软件测试职业还处于一个发展的阶段，所以测试工程师具有较大发展前景。
传统的软件行业还是以软件测试工程师为主，但是在新兴的互联网行业大多还是以QA来命名这个职位，也就是质量保证。 ----百度百科
测试工程师其主要职责就是确保程序不会出粗（检测程序质量）。
简单来看看测试和开发的区别
难易程度 开发广度小，专业度高。测试广度大，专业度低
工作环境 基本类似
薪水中小企业总体比研发低，自动化等专业测试领域和研发基本无差距。大厂研发测试基本无差别
发展前景 自动化测试、安全测试等领域发展前景和研发基本一致。
繁忙程度 敏捷模式下差距不大，产品发布前压力比较大
技能要求 测试要求更广泛：业务能力，设计和架构分析能力，测试手段和工具使用，用户模型分
析和理解，编程能力
总之呢，二者差别不大。
软件测试与调试的区别：
目的不同：
- 调试(Debug)：确保程序做了程序员想它做的事情
- 测试(Testing)：确保程序解决了它该解决的问题
参与角色不同：
- 测试由测试人员和开发人员来执行，黑盒测试主要由测试人员完成、单元/集成测试主要是由开发人员执行。
- 调试由开发人员完成。
执行的阶段不同：
- 测试贯穿整个软件开发生命周期
- 调试一般在开发阶段
ok，测试先介绍到这里，其余的可以上网查查，我这里也是上网去查的。
我们本章的重点在于，认识测试的基本概念，有助于我们更快的融入测试这个团队中去。
测试的基本概念
什么是需求
需求的概念：
满足用户期望或正式规定文档（合同、标准、规范）所具有的条件和权能，包含用户需求和软件需求
在绝大多数公司，需求分为两部分：
- 用户需求
- 软件需求
用户需求
可以简单理解为甲方提出的需求，如果没有甲方，那么就是终端用户使用产品时必须要完成
的任务。该需求一般比较简略
软件需求
或者叫功能需求，该需求会详细描述开发人员必须实现的软件功能
大部分公司在进行软件开发的时候会把用户需求转化为软件需求。开发人员和测试人员工作的直接依据就是软件需求。
软件需求规格说明书：
BUG 的概念
bug 的英译为：虫子；bug的由来：bug的由来 (baidu.com)
软件错误的定义：
- 当且仅当规格说明是存在的并且正确，程序与规格说明之间的不匹配才是错误。
- 当需求规格说明书没有提到的功能，判断标准以最终用户为准：当程序没有实现其最终用户合理预期的功能要求时，就是软件错误
测试用例
什么是测试用例？
测试用例就是一组集合：测试环境，测试数据，预期结果，操作步骤，等等
比如在 chrome 浏览器测试Leetcode 题：
测试环境：chrome 浏览器
测试数据：Leetcode 出题数据
预期结果：通过率 100%
操作步骤：写代码，提交
等等.......
为什么有测试用例
- 测试用例提高了测试人员的工作效率（降低了工作人员的重复性问题）
- 测试用例是建立自动化测试的基础
测试周期
人有生命周期，软件有生命周期，测试也有生命周期。
人的生命周期就是：出生 ~ 死亡
测试的生命周期：需求分析 -> 计划 设计 ->编码 ->测试->运行维护
我们来一一分析：
- 需求分析：需求分析是否合理，需求是否完善
- 计划：交给谁完成开发，谁测试，什么时候开始，什么时候结束
- 编码：写代码
- 测试：进行测试，并提交测试报告
- 如果产品上线后，出现问题，测试人员要协助开发人员定位问题，解决问题。
开发模型
来简单介绍几个测试模型
瀑布模型：
制定周密计划。1970年，温斯顿·罗伊斯（WinstonRoyce）提出，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。
采用瀑布模式的项目从最初的构思到最终产品要经过一系列步骤。每一个步骤结束时，项目小组组织审查，并决定是否进入下一步。如果项目未准备好进入下一步，就停滞下来直到准备好。
如图：
特点
从测试的角度看来，瀑布模式比截至到目前为止的其他模式更有优势。
瀑布模式所有一切都有完整细致的说明。当软件提交到测试小组时，所有细节都已确定并有文档记录，而且实现在软件之中。由此，测试小组得以制定精确的计划和进度。
测试对象非常明确，在分辨是功能还是缺陷上也没有一点问题。
在瀑布模型中，测试被认为是在软件开发过程的后期阶段进行的“一次性”活动，这带来一个巨大的缺点，因为测试仅在最后进行，所以一些根本性问题可能出现在早期，但是直到准备发布产品时才可能发现。
螺旋模型：
如图：
特点
该模式发现问题早、成本低的特点，可以算做相当好的开发模式。
软件测试员喜欢该模式。因为通过参与最初设计的设计阶段，可以尽早地影响到产品，可以把产品的来龙去脉弄得很清楚；并且在项目末期，不至于最后一分钟还在匆匆忙忙地进行全面测试。软件测试员的测试一直都在进行，所以最后一步只是一个验证表面所有部分都没有问题。
敏捷软件开发
2001年初，在犹他州的Snowbird，由于看到很多软件开发团队陷入了不断增长的过程的泥潭，一批业界专家聚集在一起概括出了一些可以让软件开发团队具有轻量化、快速工作、响应变化能力的价值观和原则，他们称自己为“敏捷联盟”。
敏捷联盟在随后几个月，他们创建了一份价值观声明，也就是敏捷联盟宣言。这不是一份抽象的方法论集合，并没有提供任何死板僵化的开发方法和复杂的技术结构层次，而更像是一份针对客户和开发个体的箴言警句集。
敏捷宣言：
敏捷开发的核心思想是：以人为本，适应变化。
敏捷开发提倡迭代式和增量式的开发模式，并强调测试在其中的重要作用。
绿色部分很重要，但是敏捷软件中，更加注重前面部分。
V 模型
如图：
优点
- V模型明确地将测试分为不同的级别或阶段。
- 每个阶段都与开发的各阶段相对应。
- V模型的测试策略包括低层测试和高层测试，低层测试是为了源代码的正确性，高层测试是为了整个系统满足用户的需求。
缺点
- 测试是开发之后的一个阶段。实际应用中容易导致需求阶段的错误一直到最后系统测试阶段才被发现。
- 测试的对象就是程序本身。忽视了测试活动对需求分析，系统设计等活动的验证和确认的功能，直到后期的验收测试才被发现。
W 模型（双V 模型）
如图：
优点
- W模型从V模型演化过来，实际上开发是V，测试是并行的V，测试与开发同步进行，有利于尽早地全面的发现问题。
- 测试伴随整个软件开发周期。
- 测试的对象不仅仅是程序，需求、设计等同样要测试。
缺点
- W模型中，需求、设计、编码等活动被视为串行的，同时，测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。这样就无法支持迭代的开发模型。