软件测试中的专业术语

文章目录

  • 完整测试流程:

    单元测试→集成测试→系统测试→验收测试

    单元测试中主要为白盒测试,集成测试主要为黑盒测试,还有接口测试,UI 自动化测试,系统测试阶段有接口测试,兼容性测试,验收测试中存在 α 测试和 β 测试

  • 白盒测试

    又称结构测试,是在清楚盒子内部逻辑情况下,从检查程序逻辑入手,对所有逻辑路径穷举检测,如单元测试中常常使用白盒测试的思想

  • 灰盒测试

    介于白盒测试和黑盒测试之间的测试,多用于集成测试阶段,不仅关注输入输出,也同时关注程序内部情况,它没有白盒测试详细,但又比黑盒测试更关注系统逻辑

  • 黑盒测试

    又称功能测试,用来检测每个功能能否都能正常显示,思想是在完全不考虑内部结构特性前提下,检查程序是否按照需求规定正常使用。主要针对软件界面和功能进行输入输出值进行检测,单元测试之后大集成的接口测试就是黑盒测试,UI 测试也是黑盒测试

  • 等价类划分

    一种典型的黑盒测试的方法,其是解决如何选择较小集合来代替大集合的问题,降低测试输入值实现高效合理的覆盖

  • 单元测试

    指对软件中最小可测模块进行检查。经常与单元测试联系起来的开发活动包括代码走读静态分析动态分析

  • 接口测试

    是测试各个模块的交互点,重点观察数据交换,

  • 用户界面测试

    测试用户界面功能和布局问题,主要是通过手工测试

  • α 测试

    开发环境中的测试,公司内部模拟实际操作环境测试,为非正式验收测试。为第一阶段测试

  • β 测试

    已经消除了软件中大部分不完善因素,给特定群体的测试

  • 程序静态分析

    在不运行代码方式下,对程序代码进行浏览扫描,检测代码的可靠性

  • 程序动态分析

    观察程序运行时的动作,来提供执行跟踪,时间分析,以及测试覆盖度方面的信息等

  • 性能测试

    利用自动化测试工具模拟多种极端情况对系统各项指标进行的测试,负载测试压力测试都属于性能测试

  • 负载测试

    测试软件吞吐量上限,响应时间,事务处理速率等,来验证负载能力

  • 压力测试

    用来检测一个系统的瓶颈,也可叫做负载测试

  • 稳定性测试

    又称为可靠性测试,属于性能测试,对软件的运行长时间,多用户操作,内存占用率各种性能指标进行检测

  • 契约测试

    全称为消费者驱动契约测试。在微服务大行其道背景下,越来越多团队采用前后端分离的微服务架构,微服务是单一程序构成的小服务,与其他服务采用 HTTP 接口的形式进行通讯,微服务解决了单体团队协作开发成本高的问题。契约测试是对服务之间的功能进行的测试,运行速度基本与单元测试相同

  • 安全测试

    检验产品的安全性能

  • 渗透测试

    为了证明网络防御按照预期执行而提供的一种机制

  • 兼容性测试

    比如说检测软件在不同浏览器中按照期望达到软件设计中的需求

  • 探索性测试

    一种测试思维技术,没有实际工具,就是测试人员使用主观能动性凭借自我的能力和经验来测试的策略

  • 回归测试

    修改了旧代码后,重新测试全部的过程,回归测试自动化将大大提升效率

  • 测试覆盖率

    两种分别是基于需求和基于代码的

  • mock 测试

    在测试过程中对于不易构造的对象采用虚拟的对象来替代

  • 集成测试

    又称为组装测试和联合测试,单元测试的基础上将模块组装成系统进行集成测试。实践表明一些模块虽然可以单独工作但是不能保证连接起来正常运行

  • 系统测试

    对整个系统的测试。压力测试是测试系统在正常数据量或超负荷等情况是否还能正常工作

  • 验收测试

    它是测试部署软件之前的最后一个测试操作,是完成了单元测试集成测试系统测试之后,产品发布之前的测试工作,又叫做交付测试

  • 冒烟测试

    源自硬件行业,软件行业中,它表示在代码被插入到产品之前做的测试,冒烟测试是修复软件缺陷的最经济有效的办法。冒烟测试可手动可自动化执行,稳定的系统适合自动化冒烟测试,集成时候的冒烟先需要手工来测

  • 瀑布模型

    适合稳定需求产品。是一种项目开发架构,开发过程是一系列顺序展开的,系统需求分析→系统设计→软件编程→软件测试→软件维护,每个阶段都会循环反馈,某个阶段发现了问题可以返回上一阶段进行修改

  • 原型模型

    适合不确定的软件,不适合大型系统。是一种项目开发架构,实现一个原型,让用户对原型进行评价,逐步调整,使其最终满足需求

  • W 模型

    适用于大中型企业开发。其优点伴随整个开发周期,需求和测试同样也要测试,可以更早介入测试,在初期就可以发现设计缺陷,修复成本低,但是对测试成员要求比较高

    需求分析   系统测试设计                   交付         验收测试
     \          \                          /            /
      概要设计    集成测试设计             实施         系统测试
        \           \                   /            /
         详细设计     单元测试设计      集成         集成测试
           \            \            /            /
             \            \        /            /
               \            \    /            /
                 \            \/            /
                   \         /  \         /
                     \     /      \     /
                       \ /          \ /
                        编码         单元测试
    
  • 测试 V 模型

    一般开发不用,V 型图的一遍是需求分析→概要设计→详细设计→编码,另一端是单元测试→集成测试→系统测试→验收测试

    可见 W 模型中测试的 V 字

  • H 模型

    用的较少,此模型中软件测试过程完全独立,贯穿于整个产品周期,与其他流程并行执行,当某个测试点待测时,就可以开测,很像倒在地上的 H。优点是可以完全专注于软件测试,确定是容易使得测试团队难以打进团队

        测试准备             测试执行
    -------------->待测点-------------->测试流程
                     ↑
                     |
                     |
    ----------------------------------->开发设计的流程
    
  • X 模型

    用的很少,X 模型左侧描述对单独程序片段进行分离的编码测试,然后右边是频繁交接集成测试最终变成可执行程序

    程序片段                      封版
    ———————                      ———————                    
            \                  /
              测试设计        执行测试
               \            /
                 执行测试   测试设计
                  |        ↑
                  ↓        |
                  编码完成 集成(1...n)
                  ↑        ↑
                  |        ↓
                 执行测试   探索性测试
                /           \
               测试设计       执行测试
             /                 \
    ———————                      ———————         
    
  • 敏捷软件开发

    它强调的是程序员与业务员之间的紧密协作,面对面沟通,频繁交付的新的软件版本,紧凑型的团队,也更注重软件开发中人的作用

  • 敏捷管理

    敏捷管理是立足于充分利用机遇和人员还有信息,发挥机遇最优化,人员能动性

  • 测试驱动开发

    简称 TDD,它要求编写功能代码前先写测试代码,然后编写使测试通过的功能代码,通过合理的测试来推动开发进行,这有助于开发高质量代码

  • 自动化测试

    软件测试的自动化

  • A 端

    开发的界面,开发者,管理员接触的界面

  • B 端

    Business,即为满足用户的工作需求,为企业或商家自己使用的系统,如公司报销系统

  • C 端

    Customer,用户每天接触的产品,如市场上接触的各种 app

  • 服务端测试

    服务端测试有两种,一种是对 Web 或 App 的服务端进行测试,另一种是对更后端的数据库,缓存系统,中间件,文件系统的测试。

    若是第一种,会紧跟产品发布节奏来的,后端开发完成之后测试人员直接用 TestNG + HttpClient 写接口测试用例,或用现成的接口测试工具进行测试,若项目紧张会先用 jmeter,postman 等工具测试,发版完之后可以补上 TestNG + HttpClient,或者 Python 的 Nose 自动化测试用例。若遇到服务端大的重构,还需要性能测试,用 jmeter,LR 等工具进行压测。

    若是第二种,大的公司有专门团队开发后端基础服务,这些服务是通过 HTTP 接口方式提供给 Web 或者 App 后端使用,与第一种一样也是要做接口测试,但是这里还需要了解服务的技术架构设计测试用例

  • 专项测试

    如果说测试中有三大黄金职位,那么一定是安全,性能和自动化,其中安全和性能就是专项测试

  • PM

    即项目管理,负责项目进度和产品生命

  • SDET

    属于开发和测试中间,属于白盒测试范畴,要求发现代码种问题,SDET 人员需要参与产品设计计划和代码检查找出问题根源提高产品质量

  • SDE

    负责软件的研发工作

  • SIT 测试

    System Integration Testing,又叫集成测试,在单元测试之后在系统测试之前

  • UAT 测试

    User Acceptance Testing,又叫用户验收测试,之后就发布到生产环境了。uat 测试要在系统测试完成之后才开始

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

abcnull

您的打赏是我创作的动力之一

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值