软件测试基础理论知识—概念篇

什么是软件测试

验证软件功能是否满足用户的需求

软件测试的目的

(1）软件测试为了发现程序存在的代码或业务逻辑错误
(2）软件测试为了检验产品是否符合用户需求
(3）软件测试为了提高用户的体验

软件缺陷(Bug)的概念

用户需求：规格正确存在，若程序和规格不匹配，就是软件错误
软件需求：程序没有实现最终用户的需求

软件开发的生命周期

需求分析-计划-设计-编码-测试-运行维护

软件开发的5个模型

(1)瀑布模型：

• 优点：强调开发的阶段性； 强调早期计划及需求调查； 强调产品测试
• 缺点：依赖于早期进行的唯一一次需求调查，不能适应需求的变化

(2)螺旋模型：

• 优点： 强调严格的全过程风险管理。 强调各开发阶段的质量。 提供机会检讨项目是否有价值继续下去
• 缺点： 引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平提出了很高的要求。这需要人员、资金和时间的投入

(3)迭代模型：

• 迭代模型相比较增量模型抗击风险能力更前些

(4)增量模型：

• 增量开发能显著降低项目风险，结合软件持续构建机制

(5)敏捷开发模型：

• 敏捷宣言：个体与交互重于过程和工具，可用的软件重于完备的文档，客户协作重于合同谈判，响应变化重于遵循计划
• Scrum工作流程
  1.产品负责人负责整理user story，形成左侧的product backlog。
  2.发布计划会议：product owner负责讲解user story，对其进行估算和排序，发布计划会议的产出就是制定出这一期迭代要完成的story列表，sprint backlog。
  3.迭代计划会议：项目团队对每一个story进行任务分解，分解的标准是完成该story的所有任务，每个任务都有明确的负责人，并完成工时的初估计。
  4.每日例会：每天scrum master召集站立会议，团队成员回答昨天做了什么今天计划做什么，有什么问题。
  5.演示会议：迭代结束之后，召开演示会议，相关人员都受邀参加，团队负责向大家展示本次迭代取得的成果。期间大家的反馈记录下来，由po整理，形成新的story。
  6.回顾会议：项目团队对本期迭代进行总结，发现不足，制定改进计划，下一次迭代继续改进，已达到持续改
  进的效果。

软件测试的2个模型

V模型：

• 特点：明确的标注了测试过程中有不同类型的测试，并且清楚地描述了测试阶段和开发过程的阶段对应的关系
• 局限性:仅仅把测试作为在编码之后的一个阶段，未在需求阶段就进入测试：

W模型：

• 特点：测试的对象不仅是程序，需求、设计等同样要测试，测试与开发是同步进行的；有利于尽早地全面的发现问题
• 局限性：需求、设计、编码等活动被视为串行的；测试和开发活动也保持着一种线性的前后关系，上一阶段完全结束，才可正式开始下一个阶段工作。无法支持敏捷开发模式。对于当前软件开发复杂多变的情况，W模型并不能解除测试管理面临着困惑。

软件测试的生命周期（流程）

需求分析-测试计划-测试设计-测试开发-测试执行-测试评估

描述软件缺陷(Bug)的要素

(1) 问题出现的版本：开发人员需要知道出现问题的版本，才能够获取对应版本的代码来重现故障。并且版本的标识也有利于统计和分析每个版本的质量
(2)问题出现的环境：环境分为硬件环境和软件环境，如果是web项目，需要描述浏览器版本，客户机操作系统等，如果是app项目，需要描述机型、分辨率、操作系统版本等。详细的环境描述有利于故障的定位。
(3)操作步骤:描述问题重现的最短步骤
(4) 实际结果:描述错误的现象。crash等可以上传log，UI问题可以有截图
(5) 预期结果:要让开发人员指导怎么样才是正确的，尤其要以用户的角度来描述程序的行为是怎样的

软件缺陷的级别

(1)建议：界面、性能缺陷，建议类问题，不影响操作功能的执行，可以优化性能的方案等。
(2)一般：功能没有完全实现但是不影响使用，功能菜单存在缺陷但不会影响系统稳定性。
(3)严重：系统主要功能部分丧失、数据库保存调用错误、用户数据丢失，一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符，模块无法启动或调用，程序重启、自动退出，关联程序间调用冲突，安全问题、稳定性等
(4)崩溃：阻碍开发或测试工作的问题；造成系统崩溃、死机、死循环，导致数据库数据丢失，与数据库连接错误，主要功能丧失，基本模块缺失等问题

软件缺陷的生命周期

New:新发现的Bug，未经评审决定是否指派给开发人员进行修改
Open：确认是Bug，并且认为需要进行修改，指派给相应的开发人员
Fixed:开发人员进行修改后标识成修改状态，有待测试人员的回归测试验证
Rejected：如果认为不是Bug，则拒绝修改
Delay:如果认为暂时不需要修改或暂时不能修改，则延后修改
Closed：修改状态的Bug经测试人员的回归测斌验证通过，则关闭Bug
Reopen：如果经验证Bug仍然存在，则需要重新打开Bug，开发人员重新修改