• 软件测试的基础知识


    目录

    前言

    软件测试的生命周期

    如何描述一个bug

    如何定位bug的级别

    bug的生命周期

    和开发人员产生争执怎么办

    设计一个测试用例


    前言

    上篇文章主要写了软件测试的一些基本概念以及软件测试的前置知识,这篇文章主要带大家了解在进行软件测试之前要准备的工作.

    软件测试的生命周期

    在上篇文章中我们提到了软件开发的生命周期,软件的生命周期是:

    需求阶段->计划阶段->设计阶段->编码阶段->测试阶段->运行维护

    可以看出测试阶段是在整个软件的生命周期的后面才开始进行介入的.

    在测试介入之后,软件测试的生命周期:

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

    1. 需求分析:主要是分析需求是否正确,是否完整
    2. 测试计划:主要是谁测试,怎样进行测试,什么时候开始测试.
    3. 测试设计:设计测试用例.
    4. 测试开发:开发测试工具,开发自动化测试用例.
    5. 测试执行:提高bug,验收.
    6. 测试评估:产出测试报告.

    如何描述一个bug

    当我们在测试的过程中,如果发现了bug,那么我们应该正确的描述一个bug呢?

    首先一个完整的bug有以下及部分组成:

    • 发现问题的版本
    • 问题出现的环境
    • 错误出现的步骤
    • 预期行为的描述
    • 错误行为的描述
    • 其他

    出现问题的版本:开发人员需要知道出现问题的版本,才会获取到对应版本的代码来复现bug,并且版本的标识也有利于统计和分析每个版本的质量。

    问题出现的环境:环境分为硬件环境和软件环境,如果是web项目,需要描述浏览器的版本,客户机操作系统版本等,如果是App项目,需要描述机型,分辨率,操作系统版本等。

    错误出现的步骤:描述问题出现的最短步骤.

    预期行为的描述:要让开发人员指导怎么样才是正确的,尤其是以用户的角度来描述程序的行为是咋样的.

    错误行为的描述:描述错误出现的现象。

    如何定位bug的级别

    当我们找到了一个bug,并且成功的将这个bug进行描述之后,那么这个bug对应的级别应该如何设置呢?

    bug的级别主要有以下几种:

    • 崩溃
    • 严重
    • 一般
    • 次要

    1、Blocker(崩溃): 阻碍开发或测试工作的问题;造成系统崩溃、死机、死循环,导致数据库数据丢失,与数据库连接错误,主要功能丧失,基本模块缺失等问题。如:代码错误、死循环、数据库发生死锁、重要的一级菜单 功能不能使用等(该问题在测试中较少出现,一旦出现应立即中止当前版本测试)。

    2、Critical(严重):系统主要功能部分丧失、数据库保存调用错误、用户数据丢失,一级功能菜单不能使用但是不影响其他功能的测试。功能设计与需求严重不符,模块无法启动或调用,程序重启、自动退出,关联程序间调用冲突,安全问题、稳定性等。如:软件中数据保存后数据库中显示错误,用户所要求的功能缺失,程序 接口错误,数值计算统计错误等(该等级问题出现在不影响其他功能测试的情况下可以继续该版本测 试)。

    3、Major(一般): 功能没有完全实现但是不影响使用,功能菜单存在缺陷但不会影响系统稳定性。如:操作时间长、查询 时间长、格式错误、边界条件错误,删除没有确认框、数据库表中字段过多等(该问题实际测试中存在最 多).

    4、Minor(次要): 界面、性能缺陷,建议类问题,不影响操作功能的执行,可以优化性能的方案等。如:错别字、界面格式不规范,页面显示重叠、不该显示的要隐藏,描述不清楚,提示语丢失,文字排列不整齐,光标位置 不正确,用户体验感受不好,可以优化性能的方案等(此类问题在测试初期较多,优先程度较低;在测 试后期出现较少,应及时处理).

    bug的生命周期

    当我们发现了bug并且定位了bug的级别之后,需要注意的是,bug也是有生命周期的,也就是bug从发现开始到彻底的修复的过程.

    以下就是一个bug的生命周期流程图:

    Start 开始

    New 发现了一个bug

    Open 指定了开发,打开这个bug

    Fixed 修复完成

    Closed 关闭

    Reopen 重新打开

    Rejected 拒绝

    Delay bug延期修复(在未来的某一刻要修复)

     可以通过上述图片来完整的理解一个bug从发现到修复的整个过程,

    和开发人员产生争执怎么办

    排除自身的原因:排除自己的误操作,对需求了解有误

    排除自己的工作方式问题:提交的bug不详细

    提供给开发解决方案和思路

    站在用户的角度去考虑问题

    如果上述策略都不能完全的解决问题,可以采用下面这个方案:

    第三方会议:一定要描述清楚bug,bug如何解决要有自己的思路,拿到一个结果:bug到底要不要修复。

    设计一个测试用例

    以微信付款设计一个简单的测试用例:

    基本测试点:

    (1)零钱支付功能(零钱充足时)

    (2)零钱不足时,支付

    (3)支付的钱数为为整数,小数

    (4)首次使用微信零钱功能(必须要绑定银行卡)

    (5)没有钱时支付

    (6)扫微信收款码付款

    (7)扫非微信付款二维码支付

    (8)零钱支付上限(有上限)

    (9)零钱可支付的最小金额(下线)

    (10)收到转账或者红包零钱金额是否正确

    (11)每次消费零钱,都有消息提醒

    (12)可以将零钱提取到银行卡(收手续费,到账时间)

    (13)可以向微信零钱充钱(从银行卡)

    兼容性:

    (1)测试不同的微信版本

    (2)测试不同的手机系统(iOS,Android,包括不同安卓机不同品牌的机型)

    性能:

    支付零钱,给零钱充值,提取零钱的速度(单条,全部,清空)

  • 相关阅读:
    LeetCode-热题100-笔记-day29
    简单理解精确率(Precision),召回率(Recall),准确率(Accuracy),TP,TN,FP,FN
    从零开始配置vim(19)——终端配置
    WPF上位机通信组件与Modbus协议
    从 160 万到 1.5 亿美元 ,开源软件迎来融资热潮
    国内外传输大文件有哪些好用又便宜的文件传输工具?
    React +ts + babel+webpack
    后缀数组 学习笔记
    149. 直线上最多的点数-并查集做法
    XSS攻击及防御(简单易懂)
  • 原文地址:https://blog.csdn.net/qq_63525426/article/details/132942587