测试理论

测试理论

1.测试的定义

​ 在软件中存在的bug

2.出现bug的地方以及找到bug的方式有：

1肉眼看到 （界面UI）

2系统资源使用率 cpu 内存 网络 电量 。。。

3服务器端

4访问的方式/数据库的

。。。

3.判定bug的依据：

1. 需求文档 原型图
2. 不相符合的错误类型
3. 难以理解 不易使用 运行缓慢。。

4.bug出现的原因

20%来源于代码 80%需求不明确 产品需求经常变更

5.产生bug的原因归纳为：

(1) 需求解释有错误；

(2) 用户需求定义错误；

(3) 需求记录错误；

(4) 设计说明有误；

(5) 编码说明有误；

(6) 程序代码有误；

(7) 数据输入有误；

(8) 测试错误；

(9) 问题修改不正确

6.测试流程 （面试题）

我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与，讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，我们测试会根据需求文档进行编写 测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审，开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug 开发进行修改，修改成功侯关闭bug，进行回归测试，在上线前进行测试总结。

《需求文档》/《规格说明使用书》

《测试计划》 一般由于测试组长或者是测试经理编写 （参与）

《测试用例》 根据模块划分/根据测试功能/性能/自动化进行划分

用例评审会【测试人员 测试组长/项目经理 产品经理】： a:组内评审

​ 【测试人员 测试组长/项目经理 产品经理 客户】： b:组外评审

冒烟测试： 对软件的主要功能进行测试

回归测试：

测试总结：一般由于测试组长或者是测试经理编写 （参与）

日常工作：（其中几个 并不是所有的）

1、参与需求讨论，制订测试计划，确保测试能顺利执行并完成。 2、负责项目的功能性测试、用户体验测试、兼容性测试以及性能测试 3、负责测试用例的编写；编写测试报告和对测试结果分析， 4、与开发人员、产品经理沟通和协作，推动整个项目的顺利进行； 5、负责软件开发团队项目进度管理工作，6.熟悉Linux常用命令，熟悉常用数据库，熟练使用基本的SQL语句； 7.熟练使用Loadrunner，Jmeter等至少一种性能测试工具 8 . 熟练掌握java/python/shell 等编程语言的一种

9.熟练使用python+selenium/appnium pytest untest innerHtml 10、持续性能监控

测试环境的搭建：

​ windos

​ linux ： tomcat jdk mysql 禅道 jenkins 。。。

7.测试分类 （笔试题）

测试分类： 按阶段划分 代码是否执行 程序运行划分 其他

阶段划分：

​ 单元测试： 单个功能的测试 （增删改查 分页 上传 下载 ）

​ 集成测试 ： 功能模块的测试 （多个功能功点进行总结在一起）

​ 系统测试： 多个模块合成测试 （整个软件的整体测试）

​ 验收测试 : 客户以及产品经理进行 （交付前的测试）

程序是否执行:

​ 静态测试： ui界面 业务逻辑

​ 动态测试： 链接数据之后

代码是否执行：

​ 黑 ： 纯功能测试 （手动测试。点点点）

​ 功能测试

​ 安装/卸载测试

​ 界面测试

						  易用测试

​ 兼容性测试

​ 逻辑功能测试

​ 性能测试

​ 稳定性测试 monkey命令

​ 压力测试

​ 负载测试

					    一般性能测试    系统资源使用率  

​ 白 ： 使用编程脚本进行测试 实现自动化

​ 灰： 介于黑和白之间

其他测试：

​ 冒烟测试

​ 回归测试

​ 随机测试

​ 暴力测试

8.测试原则：（笔试题）

一、Testing shows presence of defects
测试显示软件存在缺陷
测试只能证明软件中存在缺陷，但并不能证明软件中不存在缺陷。软件测试是为了降低存在缺陷的可能性，即便是没有找到缺陷，也不能证明软件是完美的。

二、Exhaustive testing is impossible
穷尽测试是不可能的
现在软件的规模越来越大，复杂度越来越高，想做到完全性的测试是不可能的。在测试阶段，测试人员可以根据风险和优先级来进行集中和高强度的测试，从而保证软件的质量。

三、Testing early
测试尽早介入
为什么测试要尽早介入呢，简单的说就是保证软件质量，降低风险和成本。测试人员一般在需求阶段就开始介入，使缺陷在需求或设计阶段就被发现，缺陷发现越早，修复的成本就越小。

四、Defect clustering
缺陷集群性（2/8原则）
缺陷集群性表明小部分模块包含大部分的缺陷。软件测试中存在Pareto原则：80%的缺陷发现在20%的模块中。
一个功能模块发现的缺陷越高，那存在的未被发现的缺陷也越高，故发现的缺陷与未发现的缺陷成正比。

五、Pesticide Paradox
杀虫剂悖论
反复使用相同的杀虫剂会导致害虫对杀虫剂产生免疫而无法杀死害虫。软件测试也一样。如果一直使用相同的测试方法或手段，可能无法发现新的bug。
为了解决这个问题，测试用例应当定期修订和评审，增加新的或不同的测试用例帮助发现更多的缺陷。
测试人员不能一直依赖于现有的测试技术，而要不断的提升测试方法以提高测试效率。

六、Testing is context dependent
测试活动依赖于测试内容
根据业务的不同，软件测试内部也分为不同的行业，比如游戏行业、电商行业、金融行业。不同的行业，测试活动的开展都有所不同，比如测试技术、测试工具的选择，测试流程都不尽相同，所以软件测试的活动开展依赖于所测试的内容。

七、Absence of error - fallacy
没有错误是好是谬论
有可能99%没有bug的软件也是不能使用的。如果对错误的需求进行了彻底的测试，这种情况就发生了。软件测试不仅是找出缺陷，同时也需要确认软件是否满足需求。如果开发出来的产品不满足用户的需求，即便找到和修复了缺陷也作用不大。

9.测试发现bug而开发不认为是bug 你怎么办？（面试题）

1.找到需求文档或者是原型图进行匹对

2.尝试多种测试环境和多种测试方式来确认是否为bug

3.整理bug的复现的步骤和出现的频率

4.开发坚持不认为是bug的时候找项目经理测试经理进行沟通来确认是否为bug

5.将客户经理 测试 测试经理和项目经理进行开确认会来判定是否为bug

6.测试人员需要将bug整理并写入测试总结中

10.开发流程：

瀑布模型：

螺旋模型：

v性模型：(笔试题 画图)

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-seVa7Kf3-1605859623678)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20201120114940128.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1ISLMjwS-1605859623683)(C:\Users\Administrator\AppData\Roaming\Typora\typora-user-images\image-20201120115047899.png)]

测试归测试组 测试组长/测试经理

测试归项目组 项目经理

项目组所属成员有哪些和比例划分

UI 1

前端 1

后台 5

移动端 iso android 2

测试 1

软件测试工具：

​ excel word 测试用例 缺陷报告 测试计划 测试总结

​ xmind 对项目认知【web项目 oa 办公自动化 crm 客户管理系统 erp 进销存系统 电力 医疗类】

金融保险类 医疗 物流 电商 电力 。。。 需求文档

​ bug管理工具： 禅道 Jira

​ 测试环境 Linux （虚拟机的方式 云平台）

​ 抓包工具： charles Fiddler (MAC无法使用)

​ 性能工具 ： jmeter Loadrunner（使用版）

​ 编程语言 shell python

​ 自动化 ui自动化

​ 接口自动化

​ 单元自动化

​ 移动端的专项测试

​ 监控k8s的使用

​ 数据库 mysql