产品经理确认本次版本的需求，召开需求评审会，进行估时排期，需求和时间都确定之后，UI出设计图，开发人员进行开发，测试人员编写测试用例，召开用例评审会议，制定测试计划，包括准备一些测试数据，等到开发提测，先进行冒烟测试，然后进行单元测试，集成测试以及系统测试（测试内容：功能、界面、可靠性、易用性、性能、兼容性、安全性等），测试人员确认没有问题后进行验收测试，由开发人员部署到预生产环境，进行一轮回归测试，最后部署到生产环境，进行版本对比测试，确认线上用户的正常使用。

根据需求文档，产品说明二次进行确认，提供bug的证据，或者与产品经理进行确认，等待产品经理最终决定，若还有问题，向上级领导进行反映。

增：insert into +表 values（value1，value2...）
删：delect from +表 where 值
改：update +表 set 字段=新值 where 
查：select * from +表 where ....
like ：select * from +表 where 值 like '%字段%'
in：允许在where中规定多个值 select * from +表 where 字段 in（value1，value2...）
between：select * from +表 where 字段 between 最小值 And 最大值
inner join：select * from +表1 inner join 表2 on 表1.id =表2.id
left join 与right join：
left join 是罗列出左表中的所有数据，然后找出右表中满足条件的所有数据，右表数据不足的地方用NULL填充
right join 是罗列出右表中的所有数据，然后找出左表中满足条件的所有数据，左表数据不足的地方用NULL填充
平均值avg()：select avg(字段) from 表 where +条件
求行数量count()：select count(字段) from +表 where +条件
累计之和sum()：select sum(字段) from +表
最大值max()：select max(字段) from +表
最小值min()：select min(字段) from +表

面试题：

1：列出各部门中工资不低于6000的职工的平均工资

select dname,avg(salary) from emp inner join dept where emp.id=dept.id And salary >=6000 group by dname；

• 1

2：将销售部工资低于6000的职工工资上调10%

update emp set salary=salary*1.1 from emp A,eno B where A.dno=B.dno And B.dname ='销售部'And B.salary<6000；

• 1

cat：查看文件内容，-n 显示行号
tail：输出尾部文件，-n 显示行号
head：输出头部文件，-n 显示行号
grep：查找文件里符合条件的字符串，- o，只输出匹配的内容，- n，显示行号，- v，取反，- i，不区分大小写，- w，按单词位单位过滤
find：查找目录下文件，- name，按文件名查找，- type，按文件类型查找，- exec，对搜索结果在处理，- mtime，按修改时间查找
tar：压缩打包，- z，压缩，- c，创建，- v，输出打包过程，- f，文件，- t，查看文件，- C，指定解压路径，- x，解压，- h，跟随软连接
which：查询所在路径
pwd：查询所在位置路径
cd：切换目录
mkdir：创建目录文件
rm：删除
touch：更新文件时间戳
hostname：修改主机名
echo：打印输出，-h 不换行，- e 支持转义，\t 代表top，\n 代表回车

adb devices：查询当前设备列表
adb connect +IP：连接模拟器
adb install +APK：将电脑上的安装包安装到手机上
adb uninstall +包名：卸载APK
adb shell pm clear +包名：清楚应用缓存
adb shell cat ：查看内存信息
adb shell monkey -p +包名 -v +次数：进行压力测试
adb shell monkey -p +包名 --throttle 时间(毫秒)：插入固定延迟
adb logcat -v time ：抓取实时日志
adb logcat *.E：抓取APP崩溃日志
adb logcat -c ：清楚旧日志信息
adb version：查询adb版本

接口查看法：

1.请求接口的URL是否正确，若错误，为前端bug

2.body的传参是否正确，若错误，为前端bug

3.响应的状态码是否正确，若错误，为后端bug

4.响应的内容是否正确，若错误，为后端bug

5.请求和响应都正确时，前端是否跳转、渲染，若错误，为前端bug

日志查看法：

当我们发现一个bug，并不确定这个bug属于前端还是后端，可以查看后端服务的日志，复现bug时，查看日志中有没有相关信息，基本可以认为，如果日志没有输出，很可能这个功能并没有与后端交互，也就不存在后端的问题。反之，如果日志有输出，可以进一步查看有无错误日志信息，进一步分析。

经验法：

在工作中慢慢积累，负责的项目多了，自然对功能的实现过程有了解，也就明白如何分类bug了。在平常的工作和实践中慢慢总结，不要只是一味的点点点测测测，总结复盘很重要。

等价类划分法：适用于测试数据量过大，且数据操作可以分类，例如给三角形三个边赋值，三角形的3个边长是要输入的3个参数，定义取值范围（0-100）；

边界值分析法：边界值分析法是作为等价类的补充方法，其测试数据取自等价类的取值范围边界，如上输入参数取值0到100的开区间，即有效边界就是1和99；

错误推断法：在测试程序时，人们可以根据经验或直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的测试用例的方法；

判定表法：又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表；

正交实验法：简单说，就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例；

随机测试：在APP或者网页中随意点击，没有任何逻辑章法，确保不会出现问题。

不常用的：因果图法、场景法

功能：

在用户名与密码均不输入的情况下，点击提交，看toast提示信息

输入正确的用户名及密码，点击登录，验证是否可以正常登录

登录成功之后是否跳转相对应的页面

输入正确的用户名+错误的密码，点击登录，是否可以正常登录

输入错误的用户名+正确的密码，点击登录，是否可以正常登录

用户名及密码为空格时，点击登录，是否有toast信息提示

用户名及密码在头部，中部，尾部有空格时，点击登录，是否有toast信息提示

用户名及密码输入英文大小写和特殊符号及表情时，能否支持输入，支持登录

登录成功之后是否有记住密码的功能提示，下次登录就不需要再次输入，方便用户体验

输入密码时，密码是否自动加密，出现遮挡

输入密码错误时，点击登录，会不会自动记住密码

输入法上的快捷键及Tab键是否支持切换

UI：

两个输入框与按钮是否对齐

输入框的高度，长度是否符合要求

界面内有没有错别字

界面设计风格与全局设计风格是否统一

用户名及密码是否有默认文字提示

toast提示的文字时间是否符合要求

性能：

进入登录页面，需要多久

点击登录，接口的响应时间为多久

1000个人同时使用登录，接口响应时间为多久

安全：

防SQL注入

用户名及密码是否通过加密的方式传输给服务器

验证是在服务器验证还是前端JavaScript验证

清除登录的cookie后，是否还能再次登录

一个用户在不同设备上进行登录

多个用户使用同一IP进行登录

兼容性：

在不同浏览器内能否正常打开（谷歌，火狐，IE，Safari）

不同的电脑系统下，能否正常打开（Windows、Mac）

不同设备下，能否正常打开（安卓、苹果、iPad）

不同屏幕不同分辨率下，打开是否显示正常

请求行：请求方法（get，post，put，delete）+URL + 协议（HTTP、HTTPS）+回车符

消息头：host 主要用于指定被请求资源的Internet主机和端口号

User-Agent用户代理，现在浏览器的详细信息

Accept-Language ：能够接受的回应内容的自然语言列表

Content-Type ：请求体的多媒体类型（用于POST和PUT请求中）

cookie：之前由服务器通过Set- Cookie发送的一个超文本传输协议Cookie

报文体：它将一个页面表单中的组件值通过param1=value1¶m2=value2的键值对形式编码成一个格式化串，它承载多个请求参数的数据。

200：表示客户端请求成功

301：永久重定向

302：临时重定向

304：客户端发送了一个带条件的GET 请求且该请求已被允许，而文档的内容并没有改变，则服务器应当返回这个304状态码

400：表示客户端请求有语法错误，不能被服务器端解析

401：表示请求未经授权，该状态码必须与WWW-Authenticate报文头一起使用

404：请求的资源不存在，例如输入了错误的url

500：表示服务器发生了不可预期的错误，导致无法完成客户端的请求

503：表示服务器当前不能处理客户端的请求，在一段时间后服务器可能恢复正常

Jmeter进行全流程压测时，可以使用阿里云、Jmeter聚合报告、自研脚本等对服务器性能监控与数据收集。

Jmeter中需要关注的聚合报告：

（1）线程数：并发用户数

（2）请求数Samples：发出了多少个请求，例：模拟10个用户，每个用户迭代10次，就是100次

（3）平均响应时间Average：单个请求平均响应时间（毫秒）

（4）中位数Median：50％ 用户的响应时间（毫秒）

（5）90% Line：90％ 用户的响应时间。

（6）Min：最小响应时间（毫秒）

（7）Max：最大响应时间（毫秒）

（8）错误率Error%：出现错误的请求的数量/请求的总数

（9）吞吐量Throughput：表示每秒完成的请求数（Request per Second）

中断测试：

收到电话、短信、通知栏信息、电量不足弹出框、第三方警告框，切换后台应用

弱网测试：

使用Charles进行APP代理，在Charles中点击proxy，throttle settings，选择启用限制，enable throttling，可以选择56kb/s、256kb/s、512kb/s、2M/S、8M/S等

兼容性测试：

系统：Android5.0，Android6.0，Android7.0，Android8.0，Android9.0，Android10.0，Android11.0，Android12.0，IOS12，IOS13，IOS14.4，IOS15。。。

机型：华为，小米，vivo，OPPO，三星，iPhone 8 plus，iPhone X，iPhone 11，iPhone 12，iPhone 13。。。

CPU：高通，联发科，麒麟，苹果

屏幕：曲面屏，刘海屏，直面屏

分辨率：1280720 标清，19201080 高清。。。

网络：2G/3G/4G/5G/Wifi，弱网、断网时

白盒测试：

是指实际运行被测程序，通过程序的源代码进行测试而不使用用户界面。这种类型的测试需要从代码句法发现内部代码在算法、溢出、路径和条件等方面的缺点或者错误，进而加以修正。白盒测试把测试对象看作一个打开的盒子。

黑盒测试：

又称功能测试、数据驱动测试或基于规格说明的测试，是通过使用整个软件或某种软件功能来严格地测试,，而并没有通过检查程序的源代码，或者很清楚地了解该软件的源代码程序具体是怎样设计的。测试人员通过输入他们的数据看输出的结果，从而了解软件怎样工作，应该更适合测试网页游戏。黑盒测试把程序看作一个不能打开的黑盒子。

区别一：

从定义上：白盒测试需要从代码句法发现内部代码在算法，溢出，路径，条件等等中的缺点或者错误，进而加以修正。而黑盒测试着重测试软件功能，它并不涉及程序的内部结构和内容特性。黑盒测试并不能取代白盒测试，它与白盒是互补的测试方法，它很可能发现白盒测试不易发现的其他类型错误。

区别二：

从测试目的上：黑盒测试的目的是检测是否有不正确或遗漏的功能；数据或者参数上，输入能否正确接收；是否有数据结构错误或外部信息访问错误；性能上是否能够满足要求；是否有初始化或终止性错误。而白盒测试的目的是通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致，而不顾它的功能。

区别三：

检测方式上：白盒测试是穷举路径测试，黑盒测试是穷举输入测试，这两种方法是基于完全不同的观点，反应了事物的两个极端，它们各有侧重和优势，但不能彼此替代。在现代的测试理念中，这两种测试方法不是截然分开的，而是交叉使用。

GET 请求可被缓存

GET 请求保留在浏览器历史记录中

GET 请求可被收藏为书签

GET 请求不应在处理敏感数据时使用

GET 请求有长度限制，最大长度是2048个字符

GET 请求只应当用于取回数据

POST 请求不会被缓存

POST 请求不会保留在浏览器历史记录中

POST 不能被收藏为书签

POST 请求对数据长度没有要求

对于我一个新入职公司的员工来说，需要对公司的环境，业务，代码在短期内提高熟悉度，自己也会主动加班，另一方面来说，加班可能会加快我和公司同事之间的相处，在公司需要加班时，比如产品需要上线，那么会和大家一起加班，这样也是保证项目进度和项目质量的要求。