软件测试（一）--概念

软件测试的定义：

验证软件是否符合用户需求，是一个过程，测试对象是软件。

测试方法：黑盒测试，白盒测试，ui测试，接口测试，性能测试...

优秀的测试人员应该具备的素质：

1.非技术方向

沟通能力，学习能力，团队合作，文字表达能力，抗压力，责任感

2.技术方向

1）编程方向：自动化，测试工具提高效率

2）编写测试用例

需求：

用户需求、软件需求（软件规格说明书prd）

需求是开发人员的标准，测试人员编写测试用例的依据。

测试用例：

为了实施测试而向被测系统提供的一组集合，包含：测试环境，操作步骤，测试数据，预期结果

测试用例是测试人员执行测试的依据，可以降低工作的冗余度，执行自动化的依据。

软件错误（bug）：

程序与规格说明之间的不匹配；程序没有实现用户的合理预期的功能要求。

软件的生命周期：

从设想开始到不再使用结束，可分层6个阶段：需求分析、计划、设计、编码、测试、运行维护。

1.需求分析：需求内容，需求是否正确，产品经理产出需求文档。

2.计划：开发开始结束时间，测试开始结束时间，开发测试人员...

3.设计：

  1）UI/UE设计师将需求转换为图，UI视觉稿

  2）技术人员产出设计文档

4.编码：写代码，实现软件

5.测试：执行测试用例，验收BUG，产出测试报告

6.运行维护：上线，解决bug

瀑布模型（Waterfall Model）：

需求分析->计划->设计->编码->测试

1.特点：线性

2.优点：明确每个阶段的任务

3.缺点：发现问题时间太晚，浪费时间，人力资源

4.适用：较小项目

螺旋模型（Spiral Model）：

1.特点：没进入到下一个阶段，都进行风险分析

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

3.缺点：风险分析错误，会把问题暴露在线上

4.适用：大型项目，风险较多的项目

迭代，增量模型：

迭代：不断完善，先大概开发每个模块，再添加细节

增量：先开发其中一个模块，在开发后面的模块

敏捷模型：

1.敏捷宣言（思想）：

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

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

客户协作终于合同谈判

响应变化重于遵循计划

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

2.scrum：

1）重要角色：产品经理，项目经理，研发团队/product owner，scrum master，team

team：前端，后端，测试，设计

product owner：整理user story（需求），排序，制定发布计划

scrum master：开会，协调项目

2）流程

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

测试模型：

v模型

1.用户需求：产品经理收集，形成软件规格说明书。

2.需求分析与系统设计：需求能不能做，需求对不对

3.概要设计：大概设计

4.详细设计：每个模块如何实现

5.编码

6.单元测试：每个class，方法

7.集成测试：模块之间，方法之间的调用

8.系统测试：项目全部运行起来，黑盒测试，功能测试

9.验收测试：产品经理，运营验收

特点：左开发右测试，测试被划分为许多类型

缺点：测试接入需求太晚

w模型

1.用户需求  用户需求，验收测试准备

2.需求分析与系统设计  系统测试准备

3.概要设计  集成测试准备

4.详细设计  单元测试准备

5.编码  单元测试

6.集成  继承测试

7.实施  系统测试

8.交付  验收测试

特点：测试人员构造介入了需求

缺点：不能拥抱变化，不能运用敏捷