关于软件测试你必须知道的名词

关于软件测试的基本概念

• 什么是软件测试
  软件测试其实就是一个找Bug的过程，它来验证软件能否正常运行

• 为什么要做软件测试
  对于一个产品来说，测试是至关重要的，研发造就了产品，测试保障了产品，同时通过分析错误产生的原因，阶段及错误发生的趋势来帮助项目管理者或者研发人员了解当前软件开发中的缺陷以便及时纠错，改正。

• 什么是需求
  需求是 满足用户期望或正式文档规定的条件，它分为用户需求和软件需求，举例来说，如果用户想实现某平台支持邮箱注册，那么：
  用户需求：实现平台支持邮箱注册
  软件需求：注册账 ，功能概述…具体实现步骤
  通俗来讲，需求就是将用户需求转换成可以指导研发和测试人员工作的文档

例如现在要安装一个声控灯，那么声控灯的需求都有哪些呢p>

1. 亮灯的时间段
2. 每次亮多久
3. 对声音分贝的敏感度
4. 辨别人的声音
5. …

• 什么是Bug
  Bug就是所测的功能和需求不一样
  这时又分为两种情况：
  （1）程序没有实现其最终用户合理预期功能要求，就是软件错误
  （2）当且仅当规格说明书存在且正确，程序与规格说明书之间不匹 配才是错误
  因此，当一个软件有Bug时，可能是程序没有实现预期功能造成的软件错误，也有可能是规格说明书有问题，它并没有正确的表达客户的需求，导致最终结果与客户预期要求不符合。

• 测试用例
  是为了实施测试而向被测试的系统提供的一组集合
  其中包含多个要素，其中的核心要素包括：测试环境，操作步骤，测试数据和预期结果

例如：

“拨打电话”的测试用例
我第一遍写时，主要侧重了一些异常的特殊情况：

1.手机欠费时拨打是否成功
2.遇到紧急情况时电话的响应时间
3.欠费时拨打紧急求救电话
4.拨打的电话为被大量投诉的危险 码
5.跨国拨打电话
6…

和朋友交流了一下后，我发现我对手机拨打电话时本身的硬件环境考虑的很少，例如电话的听筒，页面，按键是否都正常
另外我在写这个测试用例时思路逻辑都有点乱，这样就会导致测试用例不全面，真正实施起来也很乱，因此我对之前所想的改进了一下：

一.正常情况下：
1.关于手机
（1）手机 长度是否符合规定
（2）手机 类型是否符合规定
（3）手机 是否可以设置快捷拨
（4）手机 类型 段属于哪个运营商
（5）手机 为空是否可以拨打
…
2.关于地域
（1）手机 为同一地域
（2）手机 为跨省不同地域
（3）跨国
…
二.异常情况下：
1.手机硬件
（1）手机没电，没 ，开飞行模式，静音模式
（2）手机欠费，手机 拉黑，手机 销
…
2.关于 络信
（1）信 弱时是否可以成功拨通
（2）信 弱时通话质量，是否有杂音
…
三.其他特殊情况下：
1.拨打的电话为大量被投诉的危险 码
2.拨打电话未连通时是否能正确提示原因
…
这样有条理有逻辑的写测试用例不仅能够思考的更全面，而且可以更好的扩展思维，并且写出来的也很直观

• 软件的生命周期
  需求分析—->计划—->设计—->编码—->测试—->运行维护

开发模型

瀑布模型：

特点：串行
优点：步骤清晰，有独立的测试步骤
缺点：测试比较晚，发现缺陷的时间晚，项目结束后才能够总结改正适合：需求变更少的项目

螺旋模型：

特点：渐进式，强调风险
优点：每一步都很谨慎缺：风险分析占用时间，项目完成时间长
适合：庞大，复杂项目

增量，迭代：

增量：一部分一部分增加，功能之间没有关联关系
迭代：先总体再局部，共能之间相互受影响

敏捷：

以轻量级scrum为例：
包含三大角色：

1. po（product owner）： 产品负责人（产品经理）
2. sm（scrum master）：敏捷教练（项目经理）
3. team：研发团队

特点：
有三个角色
周期为一周到四周，传统的大于三个月
每一天都要开晨例会（三句话），不超过15分钟人员不超过15人

流程：
1.产品经理整理user story，放入product backlog
2.计划会议，对user story 进行评估和排序，制定出本次迭代要完成的，放入sprint backlog
3.迭代会议，对每个story进行任务分解
4.to do 开发中 开发完成 测试中 测试完成 待上线 上线

敏捷中的测试：
注意以下三个点：
心态，重复工作借助自动化，团队合作沟通

传统开发模型与敏捷的区别：
敏捷12种宣言中阐述了几点关于敏捷的重要思想：

1. 个体与交互重于过程和工具：人与人之间的沟通
2. 可用的软件重于完备的文档：轻文档（但核心文档是必要的）
3. 客户协作重于合同谈判：客户参与度高
4. 响应变化重于遵循计划：在规定时间内拥抱变化

测试模型

v模型:

特点：串行
优点：每个阶段划分更详细
缺点：测试时间晚，发现问题晚，修改成本大系统测试时间晚，给人误解 测试不重要

测试参与阶段：
用户需求：了解需求
需求分析与系统：了解需求范围，并制定测试计划
编码阶段：编写测试用例，
系统测试（核心）：数据分析,环境搭建,测试执行,缺陷管理,测试 告输出 验收测试：培训客户进行测试，收集反馈

w模型（双v模型）：

特点：测试研发并行
优点：解决了v模型的问题
缺点：串行，不能适应敏捷开发的频繁需求变更

测试参与阶段：
用户需求：了解需求，为验收测试做准备
需求分析与系统测试：编写测试计划，为系统测试做准备
概要设计：为集成测试做准备
详细设计：为写测试用例做准备，为单元测试做准备
编码/单元测试：写测试用例，白盒工程师编码测编码
集成：即测功能又测代码
实施：系统测试交付：验收测试

• 配置管理和软件测试配置管理：
  类似于图书管理员对代码，文档。工具等的管理