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

目录

  • 什么是软件测试
  • 软件测试的目的
  • 软件缺陷(Bug)的概念
  • 软件开发的生命周期
  • 软件开发的5个模型
  • 软件测试的2个模型
  • 软件测试的生命周期(流程)
  • 描述软件缺陷(Bug)的要素
  • 软件缺陷的级别
  • 软件缺陷的生命周期

什么是软件测试

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

软件测试的目的

(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,开发人员重新修改

你可能感兴趣的:(软件测试,测试用例)