请选择 进入手机版 | 继续访问电脑版

测试学习总结1

[复制链接]
广西民兵 发表于 2020-12-31 20:21:57 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
文章目次



测试开篇



  • 最近在学习测试相关知识,抽闲把笔记做个总结,希望自己在学习总结的门路上可以或许对峙下去。
目的展望

测试大抵分类



  • 嵌入式系统测试
  • 金融平台单元测试
  • 平台SDK测试
  • 轨道交通安全软件测试
  • web service测试
  • 大型电商GUI自动化
  • 性能全链路压测
技术发展



  • 自动化测试用例设计与开辟
  • 测试框架选型
  • 测试框架自行研发
  • 测试基础架构设计
  • 测试服务化(TaaS Test as a Service)
本领要求



  • 知识面
  • 测试设计本领
  • 测试开辟本领
  • 测试平台抽象化本领
自我要求



  • 不但需要从业务出发对软件举行手工测试验证,还需要掌握完整的自动化测试开辟技术来设计自动化测试用例

    • 自动化测试为主

  • 必须掌握实际开辟测试基础架构的关键技术

    • 项目周期太短,留给测试的时间有限,需要完善的高并发测试基础架构支持

  • 必须系统性思考如何将测试数据的准备工具化、服务化、最终实现平台化

    • 早期的测试数据准备的时间成本、稳定性、创建的便利性已经很难石应大规模自动化测试要求

进击门路

1,成为合格的测试工程师



  • 快速学习本领
  • 迅速掌握被测软件的业务功能和内部架构
  • 在以上基础上运用各种测试方法,尽大概多的发现潜在缺陷,进一步发现连带缺陷
  • 知识要求:盘算机基础知识,基础架构,安全攻击,软件性能,用户体验,常见缺陷
  • 技术要求:使用常见的测试框架和工具,具有一定的自动化测试脚本开辟本领
2,成为优秀的测试工程师



  • 关注更多软件整体的质量
  • 根据业务风险指定测试战略
  • 有效控制测试的时间和成本
  • 可以或许对测试框架及工具做出适合项目需求的选型
  • 熟练使用各类测试工具,清除背后实现原理,同类测试工具的优缺点和使用场景
  • 可以或许通过二次开辟管理工具和框架层面的问题,对于某些场景自行设计开辟小工具展开测试工作
  • 具备开辟知识,明确代码级测试技术
  • 由实现自动化脚本变为低落维护成本、使得自动化脚本机动组装
  • 明确自动化脚天职层设计、页面对象模子以及业务流程模子,并且能应用到测试框架中
3,成为测试架构师



  • 面对大量测试用例执行,需要高效的支持高并发的测试执行基础架构
  • 面对大量的差别性数据要求,需要统一的测试数据准备平台
  • 为了更方便和连续集成与发布系统(CI/CD)以解耦形式做集成,需要统一发起测试执行接口
  • 对前沿测试方法和技术由自己的明确,适当的运用到自己项目中
基础本领

测试用例

什么才算是好的测试用例



  • 是一个完备的聚集,覆盖所有的等价类以及各种边界值,与是否可以或许发现缺陷没有关系
  • 具备三个特征
  • 1,整体完备性 是一个完备的整体,是有效用例组成的聚集,能完全覆盖测试需求
  • 2,等价类分别的准确性 每个等价类都能包管只要此中一个输入测试通过,其他输入也一定能通过
  • 3,等价类聚集的完备性 需要包管所有大概的边界值和边界条件都已经正确识别
设计测试用例方法



  • 等价类分别法
  • 边界值分析法
  • 错误推测法
  • 因果图法
  • 判断表驱动分析法
  • 正交实验设计法
  • 功能图分析法
  • 场景设计法
  • 形式化方法
  • 扩展有限状态机方法
  • 主要是前三种
等价类法



  • 包括有效等价类和无效等价类
  • 主要思想是从每个等价类中任意选取一个值举行测试,可以用少量代表性的测试输入取得较好的测试覆盖效果
  • 不但要找出所有有效等价类,还要找出所有的’无效等价类’
边界值分析方法



  • 是对等价类分别的增补,通常选取正好等于、刚刚大于大概刚刚小于边界值作为测试数据
错误推测方法



  • 指基于被测试软件系统设计的明确、过往履历以及个人直觉,推测软件大概存在的缺陷,有针对性的设计测试用例方法
  • 主要强调对被测试软件需求的明确和设计实现的细节把握,还有个人本领
  • 在敏捷开辟下投入产出比很高,但是难以系统化,过度依赖个人本领
  • 一般企业会创建缺陷知识库,创建查抄点列表(checklist),将缺陷知识库作为数据驱动测试的输入来自动生成部分测试数据
如何设计好的测试用例



  • 差别的软件项目在研发生命周期的各个阶段都会有差别的测试范例

    • 传统软件的开辟阶段通常会有单元测试
    • 软件模块集成阶段会有代码级集成测试
    • 打包摆设后会有面向终端用户的GUI测试
    • 再比如,电商网站的测试会分为服务器端基于API的测试、中间件测试、前端GUI测试等。

  • 对于每一种差别的测试范例,设计好的测试用例的关注点和方法论大概会有很大的差别

    • 黑盒,白盒灰盒(如:微服务架构中的测试)

  • 最好是在需求分析和设计阶段就开始参与(这时是明确和掌握软件的原始需求最好时机)
  • 真正明确原始业务需求后,才大概从业务需求角度针对性、从用户使用场景思量端到端的测试用例集

    • 这时主要使用黑盒测试(验证业务需求是否被满足)

  • 在详细用例设计时,首先要搞清楚每个业务需求所对应的多个软件功能需求点,然后分析每个软件功能需求点对应的多个测试需求点,最后针对每个测试需求点设计测试用例
  • 设计注意:

    • 1,从软件功能出发,全面、无遗漏识别测试用例需求很重要,直接关系到用例测试覆盖率
    • 2,对于识别的每个测试需求点,需要综合运用等价类分别、边界值分析和错误推测方法来全面的设计测试用例

测试用例设计其他履历



  • 只有深入明确被测软件的架构,才气’有的放矢’设计测试用例集,发现系统边界和系统集成商的潜在缺陷

    • 数据库毗连方式、读写分离、消息中间件kafka设置、缓存系统层级分布、第三方系统集成等

  • 必须深入明确被测软件的设计与实现细节,深入明确软件内部的处置惩罚逻辑

    • 切记,一定要以原始需求设计测试用例,不要以开辟代码实现为依据

  • 需要引入需求覆盖率和代码覆盖率来权衡测试执行完备性,以此为依据找出遗漏测试点
单元测试

什么是单元测试



  • 单元测试是指对软件中最小的可测试单元在于步伐其他部分相隔离情况下举行查抄和验证的工作
  • 最小测试单元通常指函数大概类
  • 一般由开辟工程师完成,一般会伴随着代码提交到代码库。属于最严格的软件测试手段,最接近代码底层实现的验证手段
  • 单元测试一般以自动化的方式运行,在大量回归测试场景下更能带来高收益
如何做好单元测试



  • 弄清测试对象是代码,代码的根本特征,产生错误的原因
  • 主要技术手段:驱动代码,桩代码,Mock代码
代码的根本特征与产生错误的原因



  • 开辟/脚本:都有条件分支、循环处置惩罚、函数调用等根本逻辑控制
  • 抛开业务逻辑,所有代码都是对数据举行分类处置惩罚,每一次添加判断,嵌套条件大概循环执行
  • 要做到代码逻辑正确,必须做到分类正确并且完备无遗漏,同时每个分类的处置惩罚逻辑必须正确
  • 详细工程实践中,开辟工程师设计的代码功能点就是单元测试的等价类
单元测试详解



  • 通常,单元测试的用例是一个’输入数据’和’预计输出’的聚集
  • 在明确了代码要实现的逻辑功能基础上,什么输入,应该产生什么输出
  • 输入数据不但仅知识被测函数的输入参数,还包括:

    • 被测函数的输入参数
    • 被测函数内部需要读取的全部静态变量
    • 被测函数内部需要读取的成员变量
    • 函数内部调用字函数得到的数据
    • 函数内部调用字函数改写的数据
    • 嵌入式系统中,在中断调用时改写的数据…

  • 预计输出也不但仅只有函数返回值,还用包括函数执行完成后所改写的所有数据

    • 被测函数的返回值
    • 被测函数的输出参数
    • 被测函数所改写的成员变量
    • 被测试函数中所改写的全局变量
    • 被测函数中举行的文件更新
    • 被测函数中举行的数据库更新
    • 被测函数中举行的消息队列更新…

  • 对于预计输出值,要严格根据代码的逻辑来定,不能通过阅读代码推算预期输出
驱动代码,桩代码和Mock代码



  • 驱动代码是用来调用被测函数的
  • 桩代码和Mock代码用来取代被测函数调用的真实代码
三者之间的逻辑关系



  • 驱动代码(Driver)指调用被测函数的代码[驱动模块通常由数据准备,调用函数,验证效果三个步调]
  • 桩代码(Stub)是用来取代真实代码的暂时代码[A调用了一个尚未实现的B,那么B就是桩代码]

    • 桩代码首先起到了隔离和补齐的作用,使被测代码可以或许独立编译,毗连,运行;同时还有控制被测函数执行路径的作用
    • [桩代码要有和原函数完全相同的外形,仅仅内部实现差别,保存原函数声明,加一个空的实现]

  • Mock代码与桩代码非常类似,都是取代真实代码的暂时代码,本质区别是:承测试等候效果的验证

    • Mock代码来说,关注Mock方法有没有被调用,以及调用的参数、次数、顺序;对于效果验证通常是assert
    • 桩代码,关注被测函数的执行路径,使用Stub测试中,效果验证通常在驱动代码中

实际项目中如何开展单元测试



  • 不是所有的代码都需要单元测试,通常只有底层大概核心模块测试才会接纳单元测试
  • 单元测试框架选型,与开辟语言直接相关
  • 引入代码覆盖率工具
  • 最后需要把单元测试执行、代码覆盖率统计和连续集成流水线做集成,确保每次代码提交都能自动触发单元测试,并且在执行过程中自动统计代码覆盖率,以单元测试通过率和代码覆盖率判断提交是否能被担当
难点



  • 精密耦合的代码难以隔离
  • 隔离后编译毗连运行困难
  • 代码自己可测试性较差,规模越大余额差
  • 无法通过桩代码直接模仿系统底层函数调用
  • 代码覆盖率越往后越难提高
自动化测试

什么是自动化测试



  • 把人对软件的测试行为转化为由呆板执行测试行为的一种实践

    • 对于常见的GUI自动化测试来说,由自动化工具模仿需要人工在软件界面的各种擦欧总,并自动验证是否符合预期

  • 本质是写一段代码去测试另一段代码,需要投入大量的时间和精神,已开辟完的用例必须随着被测对象的改变而不绝更新(维护成本高)
什么项目适合自动化测试



  • 需求稳定,不会频仍变动
  • 研发和维护周期长,需要频仍执行回归测试

    • 软件产品比软件项目更适合做自动化测试
    • 软件产品生命周期一般比力长,通常会有多个版本连续发布,每次发布都需要大量的回归测试需求
    • 自动化测试用例执行比例高于5:1

  • 软件项目,要根据实际情况

    • 短期一次性项目,优先选择手工测试,以发现缺陷为第一要务
    • 中长期项目,对于比力稳定的软件功能举行自动化测试,对于变动较大大概需求不明确的举行手工测试

  • 需要在多种平台上重复运行相同测试的场景

    • 如:GUI测试,移动端测试

  • 某些测试项目手工无法实现,大概手工成本太高

    • 所有的性能和压力测试

  • 被测软件的开辟较为规范,可以或许包管系统的可测试性

    • 开辟人员在产品中预留可测试性接口,否则会影响后续自动化

  • 测试人员具备一定的编程本领

    • 不能忽略测试用例的设计

常用的自动化测试技术



  • 软件研发生命周期的各个阶段都有自动化测试技术存在,并且对提升测试效率有至关重要的作用
单元测试的自动化技术



  • 不但仅指测试用例执行自动化,还包括以下五个方面
  • 用例框架代码生成的自动化

    • TestNG框架代码应该由自动化工具生成
    • 单元测试开辟者可以把更多的精神放在测试逻辑的覆盖和测试数据的选择上

  • 部分测试输入数据的自动化生成

    • 自动化工具可以或许根据差别变量范例自动生成测试数据输入

  • 自动桩代码生成

    • 桩代码(stun code)是用来取代真实代码的暂时代码
    • 自动化代码的生成指自动化工具可以被测试代码举行扫描分析,自动为被测函数内部调用其他函数生成可编程的桩代码,并提供基于测试用例的桩代码管理机制
    • 单元测试开辟者只需要重点关注桩代码内的详细逻辑实现以及桩代码的返回值
    • ‘抽桩’,单元测试阶段使用假函数替代真函数,在代码集成测试阶段,用真实函数取代原本桩代码的利用,称为’抽桩’

  • 被测代码的自动化静态分析

    • 静态分析主要指代码的静态扫描,目的是识别出违反代码规则或代码风格的代码行
    • 常用工具又Sonar和Coverity等

  • 测试覆盖率的自动统计与分析

    • 自动化工具自动统计各种测试覆盖率,包括代码行覆盖率、分支覆盖率、MC/DC覆盖率等

代码级集成测试的自动化技术



  • 代码级集成测试就是将已经开辟完成的软件模块放在一起测试
  • 对被测函数以差别的参数组合输入举行调用并验证效果,和单元测试类似
  • 更多关注软件模块之间的接口调用和数据通报
  • 与单元测试的最大区别是,代码级集成测试中被测函数内部调用的其他函数必须是真实的,不允许使用桩代码取代
  • 代码级集成测试对测试框架要求很高,除了可以顺利装载自己的软件模块外,还可以装载其他相互依赖的模块,做到被测软件模块可运行(Runnable)
  • 现在开辟理念追求系统复杂性的解耦,会只管制止’大单体’运用,根本不会做代码级集成测试
Web Service测试自动化技术



  • 主要指SOAP API和REST API两类API测试,最范例的就是接纳SoapUI或POstman等类似工具,这类工具根本都是界面利用手动发起request验证response,难以和CI/CD集成
  • 对于基于代码的API测试用例,通常包罗三大步调
  • 1,准备API调用时需要的测试数据
  • 2,准备API调用参数并发起API调用
  • 3,验证API调用的返回效果
  • 目前最盛行的API自动测试框架是REST Assured,可以很方便发起RESTFul API调用并验证返回效果
  • web service测试自动化不但仅包罗API测试用例,还包括
测试脚手架代码的自动化生成

部分测试输入数据的自动生成

response验证的自动化



  • 核心思想是自动比力两次相同API调用的返回效果,并自动识别有差别的字段值,比力过程可以通过设置规则去掉诸如时间戳、会话ID等动态值
基于SoapUI大概Postman的自动化脚本生成



  • 开辟一个自动化代码转换生成工具,输入soapUI大概postman测试用例元数据(json文件),输出符合API测试框架规范的基于代码实现的测试用例
GUI测试自动化技术



  • 核心思想,基于页面元素识别技术,对页面元素举行自动化利用,以模仿实际终端用户的行为并验证软件功能的正确性
  • 主要分为两大方向:传统web欣赏器和移动端原生应用(Native App)的GUI自动化
  • 对于传统的web欣赏器GUI自动化测试,主楼泉源方向使用selenium,商业方案接纳UFT
  • 移动端接纳appium,它对iOS情况集成了XCUITest,对Android情况集成了UIAutomator和Espresso

来源:https://blog.csdn.net/weixin_43999171/article/details/101306390
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )