一. 测试基础
1.1:定义与测试的顺序;
寻找软件出现的缺陷和问题,保证软件质量!
编写测试方案
编写测试计划
提取测试需求
编写测试用例
执行测试用例
提交测试缺陷
回归测试 (测的是BUG和更改过的需求)
1.3:测试的方向:
功能测试 (web测试;app测试;)
自动化测试
接口测试
安全渗透
测开=====开发测试工具(python ; django ; flask;)
性能测试
白盒测试工程师
1.4:软件测试的分类:
1.4.1:按测试阶段划分:
1.4.1.1:单元测试
测试:针对的是单个功能;例如:注册!
针对代码进行测试,一般是开发负责!
1.4.1.2:集成测试
组装测试
1.4.1.3:系统测试
针对系统的整体性测试
软件功能
硬件功能
1.4.1.4:验收测试
用户检查产品的是否符合自己的预期
α 测试:内测版本 bug 比较多
β 测试:公测版本 bug 相对较少
γ 测试:候选发布版本 bug 没有
验收是由:甲方
第三方
甲方授信,乙方协助测试
1.4.2:按照是否覆盖源代码
1.4.2.1:黑盒
1.4.2.1.1:
关心输入和输出,不关心内部实现!
1.4.2.2:白盒:
代码内部实现,技术难度高!
1.4.2.3:灰盒
黑盒 + 白盒综合
及关注黑盒的输入和输出,又关注白盒的代理逻辑!
1.4.3:按照是否运行
1.4.3.1:静态测试:
不运行测试的程序
测试对象:文档
代码
1.4.3.2:动态测试
运行被测程序
测试对象:运行中的程序
1.4.4:按照是否自动化
1.4.4.1:人工测试
手工测试,功能测试
1.4.4.2:自动化测试
大量的,重复的功能,可以使用自动化
工具自动化:Postman等
代码自动化:
java ui自动化,接口自动化
python ui自动化 接口自动化
ruby
1.4.5:其他
1.4.5.1:冒烟测试
开发提示的版本,进行接受性测试
关注点:
最基本的功能
最重要的功能
1.4.5.2:回归测试
关注点:
修复的bug
修改的新需求
部分旧功能
1.4.6:软件开发流程
- 1.4.6.1:瀑布模型:(!!重点!!)项目需求清晰的大型模型!
以文档形式进行驱动,都要进行文档的编写与输出
1.4.6.2:优点:
开发阶段很清晰,当前阶段完成之后,主要只关注后续阶段!
1.4.6.3:缺点:
代码完成之后,测试入场,可能已经有缺陷的风险,不能及时纠正缺陷不太适应·多变的需求;
可能会有延期的风险;
成本很高;
1.4.6.4:适合的场景:
适合需求清晰的大型项目:”银行,建筑,审批等“
1.4.6.5:快速原型:需求多变的小型项目;
先进行简单的需求分析,先出一个简单的原型,在跟客户交流,不断迭代更行原型;
1.4.6.6:螺旋模型:适合项目需求不太清晰的大型项目!
1.4.7:测试项目的目的
1.4.7.1:项目早期:针对需求,设计做测试,发现其中的问题,规避更多的错误,处于缺陷预防。
1.4.7.2:项目中期:及早的发现缺陷,即使修改缺陷。
1.4.7.3:项目后期:主要看软件是否可用,功能是否实现,是否满足用户的需求。
二.系统测试
2.1.定义:
系统测试是将已经集成完成的的系统软件作为整个基于计算机系统的一个元素,和计算机硬件,外部设备,某些支持软件数据结合在一起,在实际使用的环境下对计算机系统进行一系列测试活动!
2.2.系统测试的过程:
2.2.1:计划(系统测试计划):
制定测试计划:制定测试计划有(5)w 和(1)H;
2.2.1.1:(5)w 分别是:① why:为什么要进行测试;② what:测试什么,测试哪些方面,测试范围;③ who:谁测试;④ where:在哪里测试,测试环境,测试数据文档保存在哪里等;⑤ when:什么时间测试,需要多长时间测试,起止时间等;
(1)H 是:how:怎么测试,测试方法,测试工具等;
2.2.1.2:参考文档:分别是:”开发计划“,“软件需求规格说明书”。
2.2.2:设计(系统测试方案):
通过功能需求分析得出的测试策略,更偏重于技术;
2.2.3:实现(系统测试用例):
更加具体的补充测试步骤以及测试数据,输出的测试用例;
2.2.4:执行(系统测试执行):(重点)
2.2.4.1:搭建系统环境:① 安装环境,可集成:如下图:↓↓↓↓↓↓↓↓↓↓↓
2.2.4.2:② 硬件环境:pc,网络设备等!
2.2.4.3:③ 软件环境:如下图:↓↓↓↓↓↓↓↓↓↓↓
2.3.常见的测试类型:如下图 ↓↓↓↓↓↓↓↓↓↓↓
2.3:测试的四个阶段:如下图↓↓↓↓↓↓↓↓↓↓↓