软件测试Ⅰ--- 初识

软件测试

验证软件是否满足用户的需求（有标准）

不运行系统或程序可以进行软件测试嘛？

• 可以
• 动态测试、静态测试

软件测试和调试的区别

1. 目的不同
2. 人员不同
3. 阶段不同
4. 难易程度不同

-	测试	调试
目的	检查软件质量（以用户需求为标准）	检查程序是否实现了功能（以开发人员需求为标准）
人员	测试人员	开发人员
阶段	贯穿整个软件开发的生命周期	开发阶段
难易程度	广度大、专业度低	广度小、专业度高

补充：软件开发的生命周期
需求分析–>计划–>设计–>开发–>测试–>运行

选择软件测试

1. 兴趣
2. 技能
3. 责任感
4. 压力
5. 思维
6. 为什么学开发：更好的完成软件测试工作，更好的和开发人员沟通

测试左移、右移

• 测试左移：需求前调研阶段和需求阶段，测试人员参加
• 测试右移：产品上线后，系统监控、日志记录和分析

需求

需求就是满足用户期望或合同规定的标准、规范、文档所需的条件和权限

用户需求

用户想要软件实现的功能（没有细节）

软件需求

用户需求的具体细化，是用户需求具体的实现细节

软件需求就是用户需求转化而来的

bug

当软件需求规格存在并且合理，如果软件功能和软件需求规格不相符合，我们就说是软件错误（bug）

当软件需求规格不存在时，即需求存在且合理，软件功能和用户需求不相等，就是软件错误（bug）

测试用例

向被测试系统发起的一组集合，包括测试数据、测试步骤、测试平台、预期结果（重要性、测试方式、功能模块、优先级）

开发模型

1. 瀑布模型
   优点：各个阶段比较独立，看重需求分析和软件测试
   缺点：无法适应需求的变化，测试到编码后才介入，导致前期缺陷无法及时发现和修正
   适用于：需求稳定的项目
2. 螺旋模型
   优点：强调软件质量，进行严格风险分析（每一次迭代），提供讨论项目是否有必要进行下去的机会
   缺点：引入风险管理，会投入大量的人力物力
   适用于：前期需求不是很明确，并且有风险，项目较庞大的系统开发
3. 迭代模型、增量模型
   例如：一个系统四个功能A、B、C、D模块，两周完成
   迭代：第一周：完成A、B、C、D基础功能，第二周：细化，完善
   增量：第一周：完成A、B模块，第二周：完成C、D模块
   迭代模型抗风险能力强
4. 敏捷模型
   轻文档、轻流程、重目标、重质量
   目标：交付一个高质量可用的软件
   可以适应需求的变化

scrum（敏捷开发）流程

PO（product owner）：产品经理，把客户需求整理成user story（ 用户故事），课表的代表方
SM（scrum master）：项目经理，负责保证整个敏捷流程的顺利实施
ST（scrum team）：研发团队，目标是交付一个高质量的可用软件

1. 发布计划会议
   PO负责讲解user story，根据user story的紧急程度排出本期要迭代的user story，形成sprint backlog（任务列表）
2. 迭代计划会议
   细化user story，分配任务，以及每个人完成的时间点
3. 开发过程中，每日站会
   昨天做了什么、遇到什么安排、今天的计划
4. 产品演示评审会
   给用户演示完成的产品，用户提出意见，产品经理整理成新的user story，放到下一次的迭代中
5. 回顾会议
   对本期迭代进行总结

软件测试模型

1. 软件测试V模型
   优点：左边开发的每个阶段和右边测试的每个阶段一一对应，是右边测试的每一个阶段的依据
   缺点：测试介入晚，前期的错误和风险后期才发现，失去及时纠正的机会
2. 软件测试W模型
   优点：测试阶段和开发阶段是在两个独立的V模型中，测试介入比较早，在项目初期介入，前期风险可以及时被发现
   缺点：W模型每一个阶段仍然是一个串行的过程，不能适应需求变化的项目，所以无法应用到敏捷开发