一、概述
1、什么叫软件、系统、被测系统
软件:由三部分组成:程序,文档,数据。
系统:多个软件(配置项)集成后的产品
测试对象:被测系统,支付宝、微信、某个小程序、信贷系统(app、后台管理系统、征信系统、多客服系统等)、淘宝系统(淘宝web端、app端、淘宝商家端、客服系统、淘宝后台管理系统等)——>重新定义系统、测试对象。
2、软件测试能做什么
- 找bug、缺陷管理
- 需求分析、设计测试用例
- 测试计划、测试报告等
- (8大质量特性)功能测试、性能测试、安全性测试、兼容性测试、易用性测试、可移植性测试、可靠性测试、可维护性测试
- 手工测试、自动化测试
- 是软件质量的一个保证、通过测试的软件,质量是可靠的
3、软件测试岗位
- 助理工程师
- 初级测试工程师:功能测试
- 中级测试工程师:功能+接口+自动化测试
- 高级测试工程师:技术(行业、性能、安全、可靠性等专项测试)+管理(测试组长、测试经理、测试总监)
4、软件测试行业
- 金融
- 电信
- ERP类
- 电商(短视频、直播电商)
- 教育类等
- 智能穿戴类、嵌入式类
- 智能终端的测试(偏硬件)
软件测试的就业要求:测试技术+行业知识
二、软件工程相关(了解)
1、软件危机
软件危机是在软件系统达到一定规模的时候,没办法正常的实现开发了
2、软件工程
是当时解决软件危机的重要手段
采用工程化的思想来管理软件开发过程
1968年作为软件工程元年,是有序开发和无序开发的分水岭
软件工程提出了两方面改进:
- 开发技术:方法、工具、环境
- 开发过程管理:项目预算、进度管理、人员管理、配置管理、质量管理
在现代软件工程思想中,关注的是项目的开发过程,采用CMM、CMMI软件成熟度模型(开发能力评价):
- 初始级:混乱状态
- 已管理级:项目开发开始有管理、有流程了
- 已定义级:对项目做好坏评价,有文档跟踪了
- 量化管理级别:通过数据、量化的指标评价软件做的好坏
- 优化管理级:不仅能够评价,还能通过指标去优化过程
软件工程的三大要素:方法、工具、过程
3、软件测试岗位
60年代是没有软件测试岗位的,是由开放来完成测试工作的
测试岗位是由调试,逐渐演变而来的(区别背一下)
调试:开发人员的行为,是为了验证软件功能是正确的,是一种建设性的行为
测试:测试人员的行为,是为了验证软件是有问题的,需要找bug,是一种破坏性的行为
三、软件的生命周期
LifeCycle:生命周期
- 客户、老板的一个idea想法开始,生命周期开始了
- 需求分析
- 概要分析
- 详细分析
- 编码
- 测试
- 验收
- 上线(长期的运行、维护)
- 没人用了、被新的产品替代了、被下架了,生命周期结束了
1、开发模型
1)瀑布模型:最早的一种开发模型,前一个阶段完成之后才能进入下一个阶段(明显的前后顺序),周期会比较长、后阶段发现问题成本高。
- 计划
- 需求
- 概要设计
- 详细设计
- 编码
- 测试
- 验收
- 上线、运行和维护
瀑布模型的优点:
- 每个阶段都有自己的通过标准,只有通过评审才能进入下一个阶段(配置管理中加入基线(基线文档是标准,不允许随便改动))
- 进入到下个阶段后,就把上个阶段的输出成果作为依据,只用关注当前阶段的产物即可了
瀑布模型的缺点:
- 阶段文档多,成本高
- 前阶段文档多,只有在较为后期用户才能看到实际的结果,增加了开发的风险
- 需求变更比较频繁的项目不适合使用该模型(金融、国防的项目更适合,而互联网项目不适合)
2)螺旋模型,是一种基于风险控制的开发模型
3)迭代模型,基于需求变化的一种开发模型,可以快速抢占市场,通过后续不断的版本迭代来完善系统。每一次迭代都是完整的开发过程
4)敏捷开发:快,需求变化快
总结:常见的面试问题
- 你们项目组的工作是采用哪一种开发模型
- 你们项目组的工作流程是什么样的
2、软件测试过程模型
1)v模型:最常见的一种测试模型,v其实是将瀑布模型中的测试过程细分,体现测试过程和开发过程对应关系
缺点:测试仍然是编码之后的一个过程,没有体现应该尽早测试的原则
2)w模型:双v模型,每个开发阶段都进行验证和确认的过程,是尽早测试的体现(早发现问题,早修复,降低修复成本)
缺点:整个模型的过程仍然是有明显的先后顺序的
3)h模型:所有的测试过程完全的从开发流程中独立出来了,多个流程可以并行开展,识别到就绪点,就可以介入测试执行了
优势:尽早测试、各个环节相互独立
劣势:对管理者的管理能力、技术要求相对较高,要能准确识别就绪点
4)x模型:在探索性测试中可用的一种模型,不断测试,不断熟悉系统,不断发现问题的过程
四、软件测试常见概念
1、软件和软件的分类
软件的三要素:程序、数据、文档
软件的分类:
按照层次划分:系统软件、中间件(支撑类软件)、应用软件等
按照组织划分:政府软件、企业官网等
按照架构划分:bs(browser/server)、cs(client/server)
2、缺陷和缺陷的由来
缺陷是bug,是软件中功能实现和需求不一致的内容
1)如何确定一个缺陷(熟背)
- 软件实现的功能和需求规格说明书SRS、产品需求规格说明书PRD的描述不一致
- 软件未实现需求规格说明书所要求的功能
- 软件实现了需求规格说明书明确要求不要的功能
- 软件未实现需求规格说明书未明确要求,但是应该实现的功能(隐式需求)
- 功能实现了,但是运行速度、易用性、最终用户体验不好的问题
总结:
- 所有不满足需求、超出需求、未实现需求的功能都是缺陷
- 没有不存在缺陷的软件,只有尚未发现的缺陷
2)缺陷在不同开发阶段的定义(熟背)
- 错误:比如设计人员在写文档的时候写错了需求、编码人员写代码的时候写错了运算符(==写成了=)由于人无意引入了错误到软件中
- 缺陷:引入到软件的错误,在测试阶段被发现(通过代码错误所导致的现象),没找到的错误是隐性缺陷
- 失效:由于隐性的缺陷导致软件不可用的状态,称之为软件 失效了
- 事故:由于软件失效,而导致软硬件不可用,而发生的严重的经济损失,称之为发生了事故
3、软件测试的定义和目的
1)软件测试定义
正向定义:软件测试是为了建立一种信心,验证软件是按照预期的设定在运行,是一种建设性的行为,证明软件没有问题
反向定义:软件测试是为了发现一个软件中存在问题的过程,是一种破坏性的行为,目的是证明软件有问题
- 什么样的测试是好的测试
一个好的测试用例是能发现至今尚未发现的bug的用例
一个好的测试是发现至今尚未发现的bug的测试
现代软件测试的定义:软件测试贯穿整个软件开发生命周期,对软件产品进行验证和确认的过程,体现尽早、尽快发现软件中问题的过程,既要验真、又要验假 现代软件测试=正向(做了该做的事情、有限的)+反向(没做不该做的事情、无限的)
2)软件测试的目的
- 发现软件中潜在的缺陷,跟踪并确认缺陷已被修复,从而减少软件中潜在的缺陷,最终降低因潜在缺陷而导致商业风险(事故)
- 持续改进(PDCA戴明环),当次测试的结果进行分析,作为下次开发的指导
- 软件测试是一种技术,采用各种工具、方法进行测试,提高软件测试的效率,进而提升软件质量
4、软件测试的原则
做软件测试的人员都需要默认遵守的一些规则
1)测试不能穷尽原则
所谓的穷尽,指的是所有的情况,所有的数据都覆盖到
假设:一个文本框,输入的数据范围是1~100之间,问穷尽测试怎么测?(等价类)
穷尽测试的输入量太大、输出结果太多、场景太多,覆盖的成本太高,所以不能进行穷尽测试
2)尽早测试原则
尽早测试、尽早发现缺陷、尽早修复缺陷,提升软件质量,节省了修复的成本
随着开发阶段的后移(需求—发布),修复一个缺陷的成本是呈指数级增长的
3)80—20原则(82原则、28原则)
80%的缺陷分布在20%的模块中
每个开发阶段,都可以发现该阶段缺陷的80%
每天80%的邮件是在20%的时间内发出的
4)缺陷的集群原则
在一个模块中发现了大量的缺陷,说明该模块中可能隐藏的缺陷更多,我们需要加大后续的测试力度才行
5)杀虫剂悖论
如果一个人(一种测试方法、一条测试用例)使用的时间长了,就很难再发现新的问题了
- 团队内可以做交叉测试执行
- 不间断的更新、增加新的测试用例
- 不断探索、更新新的测试的方法
6)木桶原则(短板原则)
主要是用于性能测试中,有的模块性能好、有的差,问整个系统的性能由哪个决定
在系统的任何一个部分出现性能问题(出现短板),都会影响整个系统的性能
五、软件测试的分类(重点)
按照不同的层次、阶段、类型、参与者等,有不同的划分,不能混着讲
1、按照阶段划分
按照软件测试的先后顺序、阶段进行划分
- 单元测试:依据详细设计文档,测试对象:代码中的最小单元(方法、对象)
- 集成测试:将多个单元组装在一起,对组装后的整体的测试,集成测试的策略,大棒集成、自顶向下集成、
- 确认测试:功能验证
- 系统测试:将软硬件全部部署起来,可以进行系统级的测试
- 验收测试:由用户进行验收,依据的是用户需求
2、按照技术划分
- 黑盒测试:不用知道系统是如何实现的,只需要关心输入(正确用户名、密码)和输出(输出成功)即可
- 白盒测试:关心软件内容实现的逻辑(用if、for实现),对代码级别的测试。需要做的是逻辑覆盖测试(语句覆盖、条件覆盖、判定覆盖、条件组合、修正条件判定覆盖等)
- 灰盒测试:白+黑
3、按照代码是否运行划分
静态测试:不让代码运行起来,纯去看代码、检查代码、做分析(圈复杂度、注释率等)
动态测试:让代码跑起来,单元、集成、系统、验收等都是动态的
4、按照软件质量特性划分
- 功能性测试:安装、卸载、注册、登录、个人中心、商品管理等,能不能用
- 性能/效率性测试:做的好不好、快不快
- 易用性测试
- 可靠性测试
- 可移植性测试
- 可维护性测试
- 兼容性测试:和系统依赖的其他要素是否匹配,包括os、os版本、屏幕大小、网络、软件
- 安全性测试:软件的安全性特性测试
5、测试执行的方式
- 手工测试:点点点,但是可以发现大量缺陷
- 自动化测试:为了提升测试执行的效率
6、其他划分
- 回归测试:贯穿整个软件测试过程中的,部分回归和全量回归
- 验证之前提交的缺陷是否被修复了
- 修复代码是否引入新的缺陷
- 冒烟测试:在进行大规模的系统性测试之前,要先验证系统的核心业务流程是否能走通
- 开发做:可以由测试编写冒烟测试用例(十几条就行),由开发去执行
- 测试做:万一冒烟测试过不了,就会耽误时间
- 猴子测试/随机测试:可以不用关心系统的业务,随便玩、随便点,可以发现一些意想不到的问题
- 探索性测试:前期不熟悉系统,随着不断的去测试,逐渐的加深对系统的理解,从而发现不同层次的缺陷