pythonav.com
首页
知识库
内部资料
免费视频
每天20道面试题
登录
注册
## 软件测试分类 功能测试 --测试人员用鼠标去手动测试 (测试GUI),点点点测试 自动化测试 --用程序测试程序 (测试API),解放双手 性能测试 --定位系统瓶颈,保证系统良好性能与稳定性 黑盒测试 --测试应用程序的功能,验证结果是否正确 白盒测试 --测试程序内部结构,以编程语言角度设计测试案例 ## 软件测试功能分类 按测试阶段划分 - 单元测试 Unit Testing - 集成测试 Integration Testing - 系统测试 System Testing `单元测试` 什么是单元?内存条可以理解为是一个单元,一个功能小模块 单元测试是针对基本单元(软件设计最小单位)进行正确性检测工作。 单元测试目的是检测软件模块是否完成了需求设计书中的要求。  一个整块的拼图,一块小拼图就可以理解为一个单元。  `集成测试` 将内存条放进插槽,检查规格是否符合,放入内存是否机器可以工作,此称为集成测试。  集成测试是基于单元测试的基础,将所有模块按照设计组装为一个子系统,验证 `系统测试` 结合测试工作人员安排,测试环境配置,计算机硬件环境配置,整合在一起,进行测试工作。  ### 单元、集成、系统测试的区别 `测试方法不同` - 单元测试属于白盒测试范畴 - 集成测试属于灰盒测试范畴 - 系统测试属于黑盒测试范畴 `测试范围不同` - 单元测试检查单元内部数据结构、逻辑控制、异常处理等 - 集成测试检查模块之间的数据传输 - 系统测试检查整个软件是否满足了需求 ## 回归测试 `测试过程信息流` 软件环境配置:需求文档,需求设计书,测试代码等 测试环境配置:测试需求说明书,测试计划书,测试用例等  ###`回归测试定义` 软件在测试或者其他活动中发现了缺陷且经过修复之后,应该进行回归测试活动。 目的在于验证缺陷是否正确的被修复,并且是否影响到其他的功能。 ### 回归测试流程 1.制定测试策略,回归测试策略 2.确定回归测试版本 3.根据回归测试策略执行回归测试 4.回归测试通过,关闭缺陷跟踪单(禅道) 5.回归不通过,缺陷跟踪单返回给开发人员,重新修复问题,再次回归 ### 回归测试策略设计 `完全重复测试` 重新执行所有先前定义的测试用例,来确认问题修改的正确性,以及软件修改后可能造成的影响扩散。 `选择性重复测试` 有选择性的重新执行部分测试用例。 - 覆盖修改法,针对被修改的部分,重新构造测试用例验证已经没有缺陷 - 影响扩散法,再覆盖已修改的部分之上,分析其由于修改后是否间接造成了其他的额外缺陷 - 指标达成法,确定要达成的测试目标,例如测试用例覆盖率的百分比 ### 回归自动化测试 由于回归测试的特性,`是重新执行以前的成果`,且无`法预知需要回归几次`后才能够通过测试标准,因此回归测试可能由于枯燥乏味造成测试人员积极性低下,测试质量下降。 因此我们得用机器人或是`计算机程序`解决此重复且乏味的测试活动,`自动化回归测试`应运而生。 良好的回归自动化测试活动包括如下: - 程序自动运行 - 程序参数自我配置 - 测试用例自动管理 - 测试活动自动执行 - 测试信息日志自动收集 - 测试结果自动分析与输出 实现测试用例自动化且进行结果分析,此类活动适合脚本化用例开发,进行逻辑控制,结果断言等,使用Python进行脚本开发灵活性较高。 对于特定系统或者复杂测试环境下,商业测试工具难以解决问题,自主研发自动化测试工具是灵活的方法。 ## 验收测试 在软件生命周期流程上来看,软件研发阶段,测试活动包括单元测试、集成测试,系统测试等企业内部进行的测试活动。 在软件发布之前还有一个测试活动有真实用户介入,称为验收测试。 软件项目开发分为两种形式: `企业自研产品,如今日头条,王者荣耀,抖音` - 自己公司产品上线前由用户介入进行大范围内测,公测,检验软件正确性 - α测试 - β测试 `公司承接业务开发,客户要什么就开发什么` - 产品研发好后,由客户方验收,检验产品需求正确性 ### 验收测试概要 如何确定验收测试的`执行时间`、`执行人员`、`执行环境` - 在通过`内部系统测试`活动以及`软件配置审查`之后,开始执行验收测试 - 验收测试是以人为测试活动为主,由测试人员和用户群体为代表开展测试活动 - 验收测试原则上是在用户基地进行,在用户同意下,也可以在软件开发公司内部模拟测试环境 - 验收测试以`验收测试计划书`或`软件需求规格书`进行标准化测试 - 验收测试结果分两种: - 软件功能、质量、性能、界面特性与用户需求一致,用户接纳软件结果 - 反之,软件不被用户接受 ### α、β测试 α测试活动好比游戏的删档内测 - 由企业内部员工在模拟真实环境下进行的测试活动,进行结果反馈 - 员工在开发人员的接入下,通过指导进行软件使用,且随时记录下使用过程中的错误 - 由真实用户在软件内测版本,开发版本环境下进行的产品体验/测试活动,进行结果反馈 - α测试的目的是评价软件产品的FLURPS(即功能、局域化、可用性、可靠性、性能和支持)。 - α测试即为非正式验收测试,尤其注重产品的界面和特色, β测试好比游戏的不删档公测 - 由多个用户在实际操作环境下进行产品功能测试,如不同的手机型号,平台,网络环境等 - β测试不受开发者控制,自主开展测试活动,然后进行结果反馈 ### α、β版场景    ## 测试划分 测试过程分为四大阶段  ##测试分类  ## 生命周期各测试方法对比 | | 单元测试 | 冒烟测试 | 集成测试 | 系统测试 | 验收测试 | | -------- | ------------------------ | -------------------- | -------------------------- | ---------------------- | ---------------------- | | 测试阶段 | 编码后 | 提测后 | 单元测试后 | 冒烟测试通过后 | 软件发布前 | | 测试对象 | 最小模块覆盖 | 整个系统 | 模块间联调 | 整个系统 | 整个系统 | | 测试人员 | 白盒测试或开发 | 黑盒测试 | 白盒测试或开发 | 黑盒测试 | 用户或需求方 | | 测试依据 | 代码、注释、详细设计文档 | 冒烟测试用例 | 单元测试模块、概要设计文档 | 需求说明文档、测试用例 | 用户需求、验收标准文档 | | 测试方法 | 白盒测试 | 黑盒测试,自动化测试 | 黑盒与白盒结合 | 黑盒测试 | 黑盒测试 | ### 软件测试分类说明 | **名称** | **说明** | | ---------- | ------------------------------------------------------------ | | 性能测试 | 性能测试是为验证系统性能指标进行测试。 | | 负载测试 | 负载测试是通过改变系统负载方式来发现系统中所存在的性能问题,如内存泄露,性能瓶颈。 | | 压力测试 | 在高负荷且长时间的稳定性压力测试和极限负荷情况下进行测试。验证系统稳定性。 | | 恢复测试 | 检查系统的容错能力。强制性迫使系统失败,然后验证系统恢复能力重启系统。 | | 易用性测试 | 测试软件是否易用性,一般根据用户反馈信息验证。 | | 回归测试 | 指错误被修正后,软件功能发生变化后重新测试,确认不会影响其他功能。 | | Alpha测试 | 模拟实际操作环境下验收测试,如删档内侧 | | Beta测试 | 系统已经通过内部测试,大部分错误已经修复,即将正式发布,在多个真实环境下发布,如不删档公测。 |   ## 黑盒测试 - 黑盒称为功能测试,一是按顺序检测程序每个功能,二是按功能模块优先级测试。 - 对软件的界面和功能进行测试,只考虑其整体特性,不考虑其内部实现 - 需要根据说明书、用户手册进行功能测试 - 如电视遥控器,就是一个标准的黑盒测试,我们不管是液晶的还是其他方式,只需要查看遥控器是否能控制空调 - 要求多组数据,多次测试才能得到准确的报告 `黑盒测试类型` - 功能性测试,网站顺序使用的功能,手机使用功能,显示器是否正常显示... - 容量测试,海量数据的处理,如1亿人用微信,1亿人用支付宝,这个数值容量 - 负载测试,系统在短时间内处理海量数据时,系统的健康状况指标 - 恢复性测试,小米手机秒杀活动太过热火,网站挂了,不该影响用户数据  ### 黑盒经典案例   ##白盒测试 白盒测试就打开了盒子,可以看到软件的内部代码 对比黑盒测试,白盒测试更严谨,对软件的源码和架构进行测试。 需要软件源代码,流程图等设计文档。 依据被测软件分析程序内部构造,并且根据内部结构设计测试用例,针对内部控制流程进行测试。 白盒测试是基于程序结构的逻辑驱动测试。  **黑盒,白盒测试,相辅相成,白盒测试通过了,还得运行软件,查看软件的性能好坏,界面美丑,是否易用等等方面。** ###白盒测试案例     ## 软件测试方法选择 已知产品需求规格,但不知道其系统内部实现,进行黑盒测试证明需求是否实现。 已知产品内部实现,通过测试每种内部操作是否符合需求,属于白盒测试。 ### 为什么要白盒测试 只验证产品基本需求得到实现,为什么要费力去测试产品内部实现呢?所谓知其然不知其所以然,仅黑盒测试,只能够满足一定的覆盖率,不能够消除更多隐藏的缺陷。 而白盒测试能够从内部逻辑检测,测试覆盖率更高,给与软件质量更高的保证。 ### 白盒测试特点 - 理解软件需求 - 了解软件代码实现 - 检测代码逻辑 - 检测代码中文件路径 - 白盒测试成本较高 ### 白盒测试的方法 - 静态分析:控制流分析,数据流分析,信息流分析 - 动态分析:逻辑覆盖测试(分支测试、路径测试)、程序插装 `逻辑覆盖测试` - 语句覆盖 - 判定覆盖 - 条件覆盖 - 路径覆盖 逻辑覆盖率的统计通过程序插装可以体现 `程序插装` - 调试代码时,往往会在程序中添加`print()`语句,能够很方便的打印出我们想要的信息,进一步了解程序执行的一些动态信息,比如程序执行顺序,计算后的变量的具体指等。 - 程序插装技术能够按照用户的要求,获取程序部分信息,是测试工作的有效手段。 ## 黑盒测试和白盒测试的优缺点  ``` 黑盒测试的优点有: 1. 比较简单,不需要了解程序内部的代码及实现; 2. 与软件的内部实现无关; 3. 从用户角度出发,能很容易的知道用户会用到哪些功能,会遇到哪些问题; 4. 基于软件开发文档,所以也能知道软件实现了文档中的哪些功能; 5. 在做软件自动化测试时较为方便。 黑盒测试的缺点有: 1. 没有清晰的测试规格说明,测试用例难以设计 2. 自动化测试的复用性较低。 3. 无法控制程序内部路径,可能缺少较多测试点 白盒测试的优点有: 1. 帮助软件测试人员增大代码的覆盖率,提高代码的质量,发现代码中隐藏的问题。 白盒测试的缺点有: 1. 程序运行会有很多不同的路径,不可能测试所有的运行路径;测试基于代码,只能测试开发人员做的对不 对,而不能知道设计的正确与否,可能会漏掉一些功能需求;系统庞大时,测试开销会非常大。 ``` ------ ## 灰盒测试 介于白盒与黑盒之间,针对被测对象信息的不同,采用不同的测试方法。 - 检验被测对象整体特性信息,采用黑盒测试 - 检验被测对象内部实现,采用白盒测试 - 既要观察被测对象整体信息,又要观察内部具体信息,信息占比不同,这就是所谓灰盒测试。 ## 软件测试文档 软件研发如同工厂生产,整个过程会有产品输出,输出的产品有两类 - 编译好的代码程序,如QQ.exe - 用户使用手册,QQ使用手册 - 源代码,QQ源代码  - 需求分析:软件测试依据 - 概要设计:根据需求分析的内容,进行方案设计,明确是否覆盖到软件的需求 - 详细设计:包含方案、策略、架构、体系、接口名、接口文档、数据结构算法,保证开发过程细致 - 测试设计:测试需要进行哪些内容,包含哪些功能点,是否会影响其他功能,例如第三方支付页面跳转 - 测试用例:用例是进行测试的依据,测试的规范条文 - 测试报告:测试成功数量、失败数量、测试是否通过,允许产品上线等 ## 动态测试与静态测试 静态测试:不运行被测试的软件系统,采用例如代码阅读、文档评审、代码分析等方式进行软件测试。 动态测试:按照预先规划好的测试数据与流程执行被测软件系统。 ### 静态分析技术 定义:静态分析是不执行程序而分析程序的技术 功能:检查软件功能与需求是否一致,没有明显缺陷与歧义 测试点: - 程序代码语法上是否一致性与完整性 - 文档描述是否规范、精准、便于查阅 - 程序与文档之间描述的一致性 ### 动态分析技术 对软件系统进行数据驱动运行,与期望结果进行对比检查的过程。 - 脚本录制工具,进行反复测试,回归测试,如Robot、QTP、Selenium工具 - 性能测试工具,LoadRunner、Robot等
目录
预科:为什么学测试
什么是计算机
第一章 测试理论
软件测试方法
软件测试需求
软件测试计划书
测试用例
缺陷管理
配置管理
禅道
软件质量