测试基本了解

1. 软件缺陷产生的原因种类：
   (1).需求变更次数频繁 理解误差 产品或者是客户
   (2).开发和设计 代码问题 开发人员
   (3).运维 资源使用率产生 公司问题
   2.测试流程：
   1.在立项会上根据客户需求编写需求文档/规格说明书，ui设计原型图后台编码，测试人员编写测试计划和测试用例
   2.随着开发的代码实现测试进行测试评审
   3.主要代码实现后测试人员先进行冒烟测试
   4.代码实现后测试执行测试用例
   5.根据执行的结果进行对应bug提交给相对应的开发人员让其修改代码
   6.开发修改后测试人员进行回归测试
   7.直至项目上线后 测试人员编写测试总结用于下一个版本的迭代

**冒烟测试： 在这个软件中主要的功能实现后进行测试
**回归测试： 在开发人员修改后进行的同一个问题的测试
**随机测试：
3.软件测试分类：
1.按阶段划分：
a.单元测试 对一个模块测试
b.集成测试 对多个模块测试(有一定的关联)
c.系统测试 在软件编译后执行的整体测试
d.验收测试 对软件执行后的用户体验的测试
α 阿尔法测试 有一定的开发测试人员的测试 内测
β 贝塔测试 只有用户参与的测试 公测

2.按是否运行程序划分;
    a.静态测试     UI设计图  
	b.动态测试     有执行代码过程中产生的问题
	
3.是否查看源代码方式划分;
   a.黑盒测试    不看源代码结构 只关心外观和能否输入输出以及响应时间
		功能测试		 界面 安装 兼容 易用 
		性能测试	     压力测试  负载测试  一般性能 稳定性测试
			压力测试   在同一时间内进行多个用户的访问
			负载测试   在多个用户在一段时间的持续访问
	
   b.白盒测试     只看代码结构以及代码实现方式
   c.灰盒测试     介于黑盒和白盒之间一种

4.测试常规面试题： 对任意物品的测试
回答思路： 1.功能上 体积 形状 用途 材质
2.界面上 颜色 图案
3.性能上
4.易用性
5.安全性

        对碗的测试：

5.软件测试的原则
1.尽早原则
2.考虑意外情况和极端情况发生
3.群集现象
4.测出问题能够复现问题
5.回归测试的关联性
6.善于总结相关文档

6.面试题：
如果在测试过程中出现的bug 而开发人员不认为是bug的时候你怎么办？
回答思路：自我
别人
领导
1.首先我会从自身去经过多次的测试发现bug的出现次数和频率,记录复现bug的方式，然后发送给开发人员
2.再根据需求文档来确认是否未bug
3.如果开发不认为是bug的 将复现bug的记录和需求文档找产品经理进行商议由产品经理和项目来确认是否bug
4.如果项目经理和产品经理都不认为是Bug 我会将bug记录在测试文档中，方便在下次评审会上将问题再次抛出

7.软件测试开发模式常见的为
V型
WW型
H型
螺旋型

8.公司的组织架构：
一般在公司内部有的部门： 人事 财务 开发(前端 后台 移动端 测试) 市场(产品) 运维（产品维护的服务）
开发，测试 1个测试对应5个开发 1个前端 3个后台 1个移动端
ceo 首席执行官
CTO 首席技术执行官
CFO 首席财务执行官
COO 首席运营执行官

	UI
	ANDROID
	IOS
	QA 
	TS  
	DBA
	UE
	RD
	
	总监
	项目经理：pm
		组长：    
		组员：
	产品经理：

9.测试工具;

World文档   测试计划  测试用例 缺陷报告
接口工具    charles Fiddler   postman
性能工具    Jmeter Loadrunner
bug管理工具 禅道 QTP 
自动化管理工具  selenium  appnium  untest.  pytest  
云测工具  Testing