测试

一个好的开发者，不仅要懂技术也要懂业务，更要明白你的程序的稳定性，而如何确定稳定性就是为了将业务很好的实现。此时就需要一个模块单独去测试代码。这个就是程序的测试

市面上的软件测试的岗位有很多。

1. 软件测试工程师：工程师的主要工作一般包含需求分析、编写测试计划和测试方案、设计测试用例、执行测试用例、跟踪BUG、编写测试报告等；
2. 测试开发工程师：根据项目的特点来开发一些自动化测试的脚本，或自动化测试的工具，或者是软件测试工作中用到的提高工作效率的小工具什么的，从而能够更有效地进行测试，提高软件产品的质量。 测试开发工程师工作的目的就是为了更高效，更快捷地让测试工程师进行测试工作；测试开发岗位一般要求一定的开发能力，解决问题的能力尤为重要。
3. 性能测试工程师：针对系统进行性能测试，包括使用工具和编写性能自动化测试脚本。
4. 安全测试工程师：主要分析产品可能会出现的安全问题，做各个方面的渗透测试，提高产品的安全性
5. 其它：系统测试工程师，嵌入式测试工程师，硬件测试工程师
6. AI环境下，也有数据测试工程师（这里就不涉及了）

软件测试的性质

1. 无组织性

最简单的软件测试组织形式就是没有任何组织的测试，几个人就把所有软件测试工作做完，这样做没有任何分工、没有任何层次结构。

2. 专职VS.兼职

按照测试人员的职责明确程度，可以划分成兼职测试和专职测试两大类。目前在很多软件企业，尤其是小规模的软件企业，往往没有专职的测试人员。在做测试工作的同时还要兼顾软件幵发、配置管理、技术文档编写、用户教育、系统部署实施等工作。

3. 项目性VS.职能性

项目型的测试组织是指测试人员作为项目组成员之一紧密地结合到项目中，与项目组其他人员紧密协作，一般是从头到尾跟着项目走。而职能型的测试组织是指测试人员参与到项目中是以独立的测试部门委派的方式进入的。
而这各有缺点，
前者（项目性）：因为亲密关系的情况，会有网开一面的情况。当然，作为项目的成员他能深入问题本质测试。
后者（职能型）：不存在亲密关系，也就不存在网开一面的情况，但是对于项目不够深入。

4. 综合性

尽管独立的测试部门会有一些不可避免的问题，例如参与项目的深入程度，容易导致“扔过墙”的测试。但是很多软件企业还是倾向于建立一个相对独立的软件测试组织。一个理想的软件测试组织可以是综合和兼容了几种结构方式的组织。

测试人员的基本素养

1. 开发能力（这个就是做项目，做算法）
2. 测试用例设计（理论+实践）
3. 掌握自动化测试技术（设置）
4. 探索性思维（经验）

什么是需求

用户需求：

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

软件需求：

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

业务需求—>软件功能需求点—>测试需求点—>测试用例

什么是BUG

专业来说：当且仅当规格说明（软件需求）存在且正确，程序与规格说明之间的不匹配才是错误。
俗语：运行结果与预期结果不符。

开发模型和测试模型

软件的生命周期

主要经历： 需求分析，计划，设计，编码，测试，维护。

1. 需求分析：分析现实的问题，并且合理，是否完整
2. 计划：谁开发，谁测试，开发多久，测试多久
3. 编码：写代码
4. 测试：测试报告（项目名称，开发（5w），测试，产品经理，bug，测试周期，开发周期，风险）
5. 运行维护：如果有线上问题，此时测试人员需要协助开发定位问题+解决问题

开发模型

瀑布模型

1. 需求分析：需求文档（是否合理）
2. 计划：什么时候开始等等
3. 设计：技术文档（涉及哪些接口，库表，MQ，定时任务…），设计UI视觉稿
4. 编码：代码
5. 测试：执行测试用例，提交BUG，验收

特点：线性的

优点：每个阶段做什么，产出什么非常清晰。

• 强调开发的阶段性
• 强调早期计划及需求调查
• 强调产品测试

缺点：风险往往，到后期测试阶段才能显露，因而失去了及时纠正的机会

• 依赖于早期进行的唯一一次需求调查，不能适应需求的变化
• 由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程

适用的项目：小型的项目

螺旋模型

1.需求计划–2.风险分析–3.软件需求–4.确认需求–5.开发计划–6.风险分析–7.软件产品设计–8.设计确认与验证–9.组装与测试–10.风险风险–11.详细设计（编码-》测试（单元测试，组装与测试，验收测试），实现）

优点：每个阶段都会进行风险缝隙，避免一些线上问题发生

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

缺点：开发周期长，风险分析可能会出错，需要人力财力的投入（比如聘请风险分析师）

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

适用项目：适用比较大的项目。

增加，迭代

增量：一个功能开发完成后再去开发一部分（促使开发小组以一种循环的、可预测的方式驱动产品
的开发）

• 增量是逐块建造的概念
• 增量开发能显著降低项目风险

迭代：一个功能开发一个部分，然后再去开发另一个功能的一部分。

• 勒出基本雏形，再细化、着色。

敏捷开发

敏捷宣言：

1. 个体与交互重于过程和工具（沟通）
2. 可用的软件重于完备的文档（完整的产品最好）
3. 客户协作重于合同谈判（需求变化要满足客户）
4. 响应变化重于测试计划（需求在变）
5. 在每对比对中，后者并非全无价值，但我们跟看中前者

scrume

scrum由product owner(产品经理)（PO）、scrum master(项目经理)（SM）和team(研发团队)组成。
team（后端开发，前端开发，UI设计师，测试）
三大角色：

• product owner负责整理user story(用户故事)，定义其商业价值，对其进行排序，制定发布计划，对产品负责（收集需求）
• scrum master 负责召开各种会议，协调项目，为研发团队服务（需求进行优先级的划分，什么时候开始什么时候结束，由谁去做）
• 研发团队则由不同技能的成员组成，通过紧密协同，完成每一次迭代的目标，交付产品（写代码）

项目流程：

产品经理收集用户需求–》项目经理（优先级安排）—（每日例会-----》演示会议—》总结）----》研发团队

1. 发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
2. 迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
3. 每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
4. 演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
5. 回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改进的效果。

---

测试模型

V模型

（以下是开发人员）
用户需求：产品经理收集用户需求形成软件需求
需求分析：验证需求是否正确
系统设计：确定编程语言，确定框架
概要设计：项目结构如何设计
详细设计：每个接口，涉及哪些库表，设计哪些任务
（以下是测试人员）
编码：写代码
单元测试：java中测试每个一个方法，类C语言中函数
集成测试：将许多的方法集成到一起测试
系统测试：模块和模块之间没有影响
验收测试：产品和运营

特点：左边开发，右边测试（类似于瀑布模型）
优点：测试被划分成许多类型
缺点：测试人员介入太晚，发现问题时机太晚

W模型（双V模型）

特点：开发一个V，测试一个V
优点：测试人员尽早，介入需求
缺点：测试人员和开发人员在一定程度上是串行的。测试中遇到问题，要层层变化（不能变化，不适用敏捷开发）