测试的日常笔记——（一）：
1.软件开发的生命周期：
a.客户提出需求(概念，也可以理解为想象)
b.根据客户的需求写出相对的<<需求文档>>
c.前端设计效果图(原型图)
后台开发人员设计与编写代码实现功能
测试人员也会根据需求文档编写测试计划和测试用例
d.在后台开发实现功能后根据测试用例测试人员进行测试。
e.开发完全结束后测试人员进行整体测试，全面测试。测试成功后进入上线
f.软件上线后根据用户体验和实际效果进行小版本的迭代。
2. 软件缺陷产生的原因种类：
1.需求变更次数频繁 理解误差 产品或者是客户
2.开发和设计 代码问题 开发人员
3.运维 资源使用率产生 公司问题
3. 测试流程：
1.在立项会(项目成立会)上根据客户需求编写需求文档/规格说明书，ui设计原型图后台编码，测试人员编写测试 计划和测试用例
2.随着开发的代码实现测试进行测试评审
3.主要代码实现后测试人员先进行冒烟测试
4.代码实现后测试执行测试用例
5.根据执行的结果进行对应bug提交给相对应的开发人员让其修改代码
6.开发修改后测试人员进行回归测试
7.直至项目上线后 测试人员编写测试总结用于下一个版本的迭代
**冒烟测试： 在这个软件中主要的功能实现后进行测试
**回归测试： 在开发人员修改后进行的同一个问题的测试
4.软件测试分类：
1.按阶段划分：
a.单元测试 对一个模块测试
b.集成测试 对多个模块测试(有一定的关联)
c.系统测试 在软件编译后执行的整体测试
d.验收测试 对软件执行后的用户体验的测试
α 阿尔法测试 有一定的开发测试人员的测试 内测
β 贝塔测试 只有用户参与的测试 公测
2.按是否运行程序划分;
a.静态测试 UI设计图
b.动态测试 有执行代码过程中产生的问题
3.是否查看源代码方式划分;
a.黑盒测试 不看源代码结构 只关心外观和能否输入输出以及响应时间
功能测试 界面 安装 兼容 易用
性能测试 压力测试 负载测试 一般性能 稳定性测试
压力测试 在同一时间内进行多个用户的访问
负载测试 在多个用户在一段时间的持续访问
b.白盒测试 只看代码结构以及代码实现方式
c.灰盒测试 介于黑盒和白盒之间一种
5.软件测试的原则：
1.尽早原则
2.考虑意外情况和极端情况发生
3.群集现象
4.测出问题能够复现问题
5.回归测试的关联性
6.善于总结相关文档
6.最常见得一道面试题：
如果你在测试过程中发现了BUG 而开发人员不认为是BUG的时候你怎么办？
回答思路：自我 别人 领导
1.首先我会从自身去经过多次的测试发现bug的出现次数和频率,记录复现bug的方式，然后发送 给开发人员
2.再根据需求文档来确认是否为BUG
3.如果开发不认为是BUG的 将复现BUG的记录和需求文档找产品经理进行商议由产品经理和项 目来确认是否为BUG
4.如果项目经理和产品经理都不认为是BUG，我会将BUG记录在我的测试文档中，以便于日后出现BUG或在下次 评审会上将问题再次抛出
7.软件测试开发模式常见的为:
V型
WW型
H型
螺旋型
8.公司的组织架构：
一般公司现有的部门： 人事 财务 开发(前端 后台 移动端 测试) 市场(产品) 运维（产品维护的服务）
开发，测试 1个测试对应3-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
