复习提纲

************************** Linux ***************************
一.必须掌握的20个linux命令:
1、杀掉tomcat进程
ps -ef | grep tomcat
kill -9 进程号

2、启动http服务
service httpd start

3、把upload.zip解压到当前文件夹下
unzip upload.zip

4、给a.txt文件的属主和其他用户分别增加写和执行权限
chmod u+w+x,o+w+x a.txt

5、实时查看a.log日志文件的信息
tail -f a.log

6、查看8888端口是否被占用
netstat -ano | grep 8888

7、把a.log文件中的包含 Error 字符串的内容提取出来，追加到b.log文件中
cat a.log | grep Error >> b.log

8、在linux下，安装程序的命令
rpm -ivh 包名

9、查看文件的命令有哪些？
vi:通过vi编辑器查看文件内容
cat:一次性查看文件的所有内容
more:分屏查看文件内容,回车换行,空格换页,不支持方向键,Ctrl+Z退出,查看到文件最后自动退出
less:同more,但支持方向键,查找文件最后,需要手动退出
head:默认查看文件前10行
tail:默认查看文件后10行

10、从远程服务器(192.168.2.1)上把/root/log拷贝到本地的/opt目录下
scp -r root@192.168.2.1:/root/log /opt

11、在vi编辑器中，复制第800行的方法
800gg yy

12、在vi编辑器中，查找linux字符串
末行模式(shift+:):/linux 或者 :?linux

13、动态查看资源使用情况
top

14、输出变量SNAME的值
echo $SNAME

15、把当前文件夹中的T01/a.log复制到/T02，并改名为b.log
cp T01/a.log /T02/b.log

16、在当前文件夹中查找a.log
find ./ -name a.log

17、上传和下载的命令分别是什么
rz 上传
sz 下载

18、删除t01文件夹里面的所有内容
rm -rf t01/*

19、统计a.log文件有多少行
wc -l a.log

20、如何从root用户，切换到普通用户
su - 用户名

二.环境搭建步骤:
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

-- Unix可以改成Linux或CentOS或者AIX

停止tomcat服务器的方法：
ps -ef | grep tomcat -- 查询出tomcat的进程ID，然后，使用命令 kill -9 tomcat的进程ID
启动tomcat服务器的方法：
进入tomcat的bin目录，执行命令 ./catalina.sh start。

************************** oracle ***************************
一.多表查询的思路:
1.分析题目涉及哪几张表；
2.如果查询的数据来自于多张表，找到这些表的相同字段，在where后面，把这些字段用等于号连接起来；
3.如果需要对单条记录进行过滤，就把过滤条件追加到where子句后面，用and连接起来；
4.需要对多组数据进行统计，使用group by进行分组；
5.分组后的过滤，只能使用having；
6.需要排序，就用orader by。

二.delete、truncate、drop的区别:
delete：(delete from 表名)
1.会发生事务,可以有where过滤条件 (事务:开启事务,就是执行一条增.删.改的sql语句.提交事务:commit;回滚事务:rollback)
2.删除指定的数据，删除效率比truncate低

truncate：(truncate table 表名)
1.截断表,删除表中的数据,但是表结构依然存在。
2.不会发生事务,不能有where过滤条件
3.删除效率比delete高，但有危险性
4.在删除的表中如果有某列(主键)是其他表的外键，则不能在该表中使用truncate(即truncate会影响外键列)

drop：(drop table 表名)
即删除表的数据,又删除表的结构。

三.模糊查询:(like)
%:表示任意长度;
_:表示一个字符长度.
例子:
select * from student where name like "_w%" :查询学生表中名字第二个字母是"w"的学生的所有信息.

四.左连接和右连接的语法，主表和从表的关系(举例说明)
1.左查询(left join):
定义:以左表中的数据为准，将右表中不满足条件的数据为空显示出来,在left左边为左表，右边为右表
例子:
select * from t_student t1 left join t_score t2 on t1.id=t2.id;
select * from t_score t1 left join t_student t2 on t1.id=t2.id;

2.右查询(right join):
定义:以右表中的数据为准，将左表中不满足条件的数据为空显示出来,在right右边为右表,左边为左表
例子:
select * from t_student t1 right join t_score t2 on t1.id=t2.id;
select * from t_score t2 right join t_student t1 on t1.id=t2.id;

3.主表和从表的关系:
主表:拥有主键;
从表:将主表的主键用在外键,使两张表关联起来.
从表数据依赖于主表，一般查询数据时把主表与从表进行关联查询;
主表数据发生变化,从表也要随之发生变化
删除主从表时,要先删除从表,再删除主表(顺序不能乱,不然报错).
例子:
班级表(主表):
classId(主键),className

学生表(从表):
stuId(主键),stuName,age,classId(外键)

学生表依赖班级表

五.对重复的行，只返回一个值(去重)的关键字:
distinct 后面接字段 (一般用于单列去重)
例子:
select distinct age from student;

六.增、删、改、查的语法:
1.增加:
语法一:insert into 表名(列1,列2,列3) values(列1值,列2值,列3值)
语法二:insert into 表名 values(列1值,列2值,列3值)

2.修改:
语法:update 表名 set 字段名=新值 where [筛选条件]

3.查询:
语法:select 查询字段 from 表名 where [筛选条件]

4.删除:
语法:delete from 表名 where [筛选条件]

************************** web&网络 ***************************
一.B/S和C/S架构的区别:
1.B/S(Browser/Server)指浏览器和服务器端:
B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)

2.C/S(Client/Server)指客户机和服务器:
C/S架构需要考虑系统在不同平台的安装、卸载、升级

二.常见的http状态码(200 302 404 500):
200 OK 请求成功，请求所希望的响应头或数据体将随此响应返回
302 Move temporarily 临时移动
404 Not Found 请求失败，请求的资源无法找到(1.检查网络是否连通;2.服务器是否开启;3.资源被删除.)
500 Internal Server Error 服务器内部错误(1.该关联的地方没关联...)

三.get和post的区别:(其他请求方式:delete,put...)
1.通常Get用来从服务器上获得数据，传输速度快，而Post用来向服务器上传递数据，传输速度比get要慢一些；
2.Get方式把请求参数放到请求地址中传送，Post是把请求参数放到请求体中传送。

四.应用层有哪些协议:
HTTP和HTTPS

五.TCP和UDP协议的区别(传输层协议):
1.UDP(User Datagram Protocol)用户数据报协议:
不需要事先建立连接，直接发送数据
每个报文都带有完整的目的地址
不保证报文传输的可靠性
2.TCP(Transmission Control Protocol)传输控制协议:
先建立连接再传输数据
数据传输过程中，数据包不需要携带目的地址
保证数据传输的可靠性

六.三次握手的过程:
A------连接请求SYN,SEQ=x ------->B
A<------响应SYN,ACK,SEQ=y,ACK=x+1-------B
A------确认ACK,SEQ=x+1,ACK=y+1------->B
*注:
SYN:同步序列号
ACK:确认信号
SEQ:同步序列号里的编号,数据字段

************************** 软件测试理论 ***************************
一.瀑布模型，V模型:
1.瀑布模型:计划、需求分析、设计、编码、测试、运行/维护
优点:每个阶段要都有明确的输入件和输出件，为项目提供了按阶段划分的检查点。
缺点：
1）基于文档的驱动，各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。
2）由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
3）瀑布模型的突出缺点是不适应用户需求的变化。

2.V模型:用户需求、需求分析、概要设计、详细设计、编码、单元测试、集成测试、系统测试、验收测试
优点：强调了在整个软件项目开发中需要经历的若干个测试级别，并与每一个开发级别对应；指出测试的对象除了包括程序，还应该包括需求和设计。
缺点：V模型仅仅把测试过程作为在需求分析、系统设计及编码之后的一个阶段，忽视了测试对需求分析,系统设计的验证，需求的满足情况一直到后期的验收测试才被验证。

二.什么是软件测试:
在规定的条件下对程序进行操作，以发现程序的错误，并对软件质量进行评估。

三.回归测试怎么做:
全量回归:对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前应用没有的问题现在出问题了”；
部分回归:当在测试过程中，发现某个模块存在缺陷，开发修复后，测试人员重新验证该缺陷是否被修复，以及验证相关联的模块是否受影响。

四.软件测试的目的是什么:
软件测试不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量。

五.黑盒测试，灰盒测试和白盒测试的区别:
1、黑盒测试(Black box)：把软件看成一个黑盒子，在完全不考虑程序内部逻辑的情况下，检查程序是否满足用户需求。只考虑输入和输出是否满足需求。
2、白盒测试(White box)：对程序内部结构和算法进行测试。必须先全面熟悉程序内部逻辑结构，然后编写程序，对所有逻辑路径进行测试的一种方法。
3、灰盒测试(Gray box)：关注系统接口所实现的功能，是否和需求一致。

六.a测试和B测试的区别:
a测试：软件开发公司组织内部人员模拟各类用户行为对即将上市的产品进行测试。
B测试：软件开发公司组织各方面的的典型客户在日常工作中实际使用，并要求用户报告异常情况、提出改进意见，然后公司再进行完善。

七.系统测试范围/策略/方法:
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

八.软件质量模型(六大特性):
1.功能性：适合性、准确性、互操作性、安全保密性、功能性的依从性
2.可靠性：成熟性、容错性、易恢复性、可靠性的依从性
3.易用性：易理解性、易学性、易操作性、吸引性、易用性的依从性
4.效率：时间特性、资源利用性、效率依从性
5.维护性：易分析性、易改变性、稳定性、易测试性、维护性的依从性
6.可移植性：适应性、易安装性、共存性、易替换性、可移植性的依从性

************************** 需求分析 ***************************
需求分析怎么做:
1、澄清需求
2、提取测试点

************************** 软件测试计划 ***************************
一.测试计划的内容有哪些:
测试项目的背景、测试范围、测试方式/策略、测试资源、测试开始和结束条件、进度安排、测试组织，以及与测试有关的风险方面

二.软件测试结束的标准是什么:
需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。
具体标准:
1.需求覆盖率100%；
2.用例执行率要达到100%，但是如果时间紧，就执行优先级高的，低级别的用例就在下个版本执行；
3.致命、严重级别的缺陷必须解决，一般、轻微级别的缺陷，遗留率是30%以下。

************************** 测试用例 ***************************
一.测试用例设计方法有哪些:
1.等价类:
等价类划分法将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性

2.边界值:

3.错误推测法;
4.场景法;
5.判定表;
6.花瓣分析法

二.好的测试用例的标准是什么:
1.覆盖用户的需求；
2.从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
3.用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4.用例各个要素要齐全，步骤应该足够详细，操作应该明确，容易被其它测试工程师读懂，并能顺利执行；
5.做好用例评审，及时更新测试用例。

三.用例评审有哪些人参与:
1.产品经理;
2.测试人员;
3.开发人员.

四.用例的执行结果有哪些:
No Test:未执行状态;
Pass:通过状态;
Fail:失败状态;
Block:阻碍状态;
Investigate:观察中状态.

五.用例由哪些要素组成:
用例编号,用例名称,级别,预置条件,测试步骤,预期结果

六.用例的优先级怎么确定:
1.用户对该功能的使用频率;
2.该功能对系统的影响程度.

************************** 测试执行 ***************************
一.开发认为不是，你认为是bug，怎么处理:
1.先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2.如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

二.偶然性问题怎么处理:
1.在测试执行过程中，一旦系统出现异常信息，我们第一时间要做的是截图，保存证据；
2.确定是偶然性的bug之后，收集相关的日志，连同截图一起提单给开发定位；
3.如果没有日志记录，缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
4.如果这些不可复现的Bug是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

三.缺陷怎么跟踪:
当一个缺陷被发现了之后，我们需要及时向开发提交问题单，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题。修复完之后,我们要进行回归测试,如果回归测试通过,我们就关闭该bug;如果不通过,我们就和开发沟通,让他修复,如果他没在短时间内处理,我们就继续提单.

四.缺陷包含哪些要素:
1.缺陷标题;
2.严重级别;
3.问题所属模块;
4.复现步骤;
5.实际结果;
6.预期结果;
7.相关日志和截图.

五.缺陷等级有哪些，怎么划分:
致命:软件无法运行，或者软件的主要功能丧失，比如：系统无法注册，频繁闪退。
严重:软件的次要功能丧失，或者主要功能在一些特定情况下会出错 ，比如，金额计算错误
一般:软件在某些情况下会出错，但是造成的后果影响不大，比如：关键字输入%进行搜索，能把系统所有数据都搜索出来。
轻微:在某些情况下会出错，但是造成的后果影响很小，比如：表格显示错位。

六.产品上线后，用户发现了bug，应该怎么处理:
首先确定用户提的这个BUG所对应的功能，是不是在之前的需求上有的，如果之前需求没有提及，先判断bug的影响程度和修复成本,如果是不太严重的就建议在下个版本中修复,如果是严重的就要立即修复.问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试.总结问题，分析事件的发生，是在那个环节漏了，是需求漏了，还是设计漏了，还是前期用例分析不到位，还是测试执行不到位等，找到具体原因，避免在下个产品中再次发生。
七.缺陷有哪些状态:
激活、确认、已解决、关闭
八.测试环境怎么搭建:
参考答案：搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

************************** 项目总结 ***************************
一.项目介绍:
二.测试报告有哪些内容:
数据统计、bug遗留情况、测试风险、测试对象评估、测试结论等
三.与项目相关的其他细节问题:(《06_项目篇.txt》)

************************** 性能测试 ***************************
《04_性能测试篇.txt》
1.性能测试怎么做？
①做性能需求分析，挑选了用户使用最频繁的功能来做性能测试，比如：登陆，搜索，提交订单，确定性能指标，比如：事务通过率为100%，90%的事务响应时间不超过5秒，并发用户为1000人，CPU和内存的使用率为70%以下(*)
②搭建性能测试环境，准备好性能测试数据(*)
③录制性能测试脚本并对脚本进行调优，设置检查点、参数化、关联、集合点、事务，调整思考时间，删除冗余的脚本等(*)
④设计性能测试场景，使用nmon工具监控服务器，运行测试场景(*)
⑤分析性能测试结果，如果有问题，收集相关的日志和图片提单给开发修改(*)
⑥开发修改好后，回归性能测试(*)
⑦编写性能测试报告(*)

2.脚本怎么调优？
设置检查点、参数化、关联、集合点、事务、调整思考时间、删除冗余的脚本等

3.常见的函数有哪些？
添加检查点:web_reg_find()
设置关联:web_reg_save_param()
开始事务:lr_start_transaction()
结束事务:lr_end_transaction()
添加集合点:lr_rendezvous()

4.什么时候要做关联，怎么做关联？
当脚本需要使用服务器返回来的值，就用关联。
（手工关联的步骤：录制两个脚本，对比找到需要关联的值，在返回该值的函数前插入关联函数，用关联函数名替换脚本中的所有动态值）

5.场景怎么设置？
①添加调试好的脚本
②运行时设置
③设置用户数、用户加载和场景运行时间
④设置集合点策略
⑤LG的设置
⑥开启各项监控

6.结果怎么分析？
首先查看结果概况，查看有没有大面积失败的事务，有没有大量Error的数，虚拟用户数有没有正常加载，点击率和HTTP响应曲率是否一致，如果都正常，表明测试结果可信，可以继续分析其他性能指标，比如，确认响应时间，事务通过率，CPU等指标是否满足需求；如果测试结果不可信，要分析异常的原因，修改后重新测试。

问题一：响应时间不达标
分析思路：添加“网页细分图”，选中要细分的事务，选择”第一次缓冲时间”，查看事务所消耗的时间主要在网络传输还是服务器，如果是网络，就结合Throughput(网络吞吐量)图，计算带宽是否存在瓶颈，如果存在瓶颈，就要考虑增加带宽，或对数据的传输进行压缩处理；如果不存在瓶颈，那么，可能是网路不稳定导致。如果主要时间是消耗在服务器上，就要分别查看web服务器和数据库服务器的CPU，内存的使用率是否过高，因为过高的CPU，内存必定会造成响应时间过长，如果是web服务器的问题，就把web服务器对应上对应的用户操作日志取下来，发给开发定位；如果是数据库的问题，就把数据库服务器对应上对应的日志取下来，发给开发定位。

--------- 遇到下面这些问题，都可以说：把服务器对应的日志取下来发给开发定位
问题二：web服务器CPU超过性能测试指标
分析思路：就把web服务器对应上对应的用户操作日志取下来，发给开发定位。

问题三：数据库CPU超过性能测试指标
分析思路：把数据库服务器对应上对应的日志取下来，发给开发定位。

问题四：内存泄漏
分析思路：把内存的heap数据取下来，在用MAT工具分析是哪个对象消耗内存最多，然后发给开发定位。

问题五：程序在单用户场景下运行成功，多用户运行则失败，提示连不上服务器。
原因：程序没有做多线程处理。

问题六：程序实现的功能是，随机给用户分配不同的任务，单用户运行时，能成功分配；多用户并发申请任务时，所有用户得到的任务都是一样的。
原因：程序存在线程同步的问题。

7.负载量与响应时间的关系
随着负载量的增加,系统的响应时间也随之增加,当负载量超过系统承受上限时，系统已无法处理请求，响应时间直线上升。

8.负载量与吞吐量的关系
随着负载量的增加,系统的吞吐量也随之增加,当负载量超过系统承受上限时，吞吐量开始下滑甚至导致系统崩溃。

9.LoadRunner有哪些部件组成
脚本生成器VuGen,压力调度器Controller,结果分析工具Analysis,负载生成器LG

10.性能测试指标有哪些？
平均响应时间、90%事务响应时间、事务通过率、CPU\内存\IO\网络使用率、用户数。

11.怎么确定并发用户数？
①这种电商(面向互联网用户)的系统，我们是会先上线一段时间，根据收集到的用户访问数据进行预估的。
②从需求来的。

************************** 接口测试 ***************************
《05_接口测试篇.txt》
1、用到哪些工具做接口测试？
参考答案：jmeter

2、接口测试怎么测试的。
参考答案：1、拿到接口文档熟悉：（服务端开发人员把接口文档写出来，我们就可以拿过来熟悉）：
1）接口功能对应的需求
2）服务端地址、端口、接口地址（确定访问哪个接口）
3）熟悉请求方式，请求参数有哪些（工作当中了解请求参数的各种约束）
4）熟悉响应数据：
<1>响应数的字段个数是否足够（可以看需求文档中对应的功能需要显示的个数，只能多不能少）
<2>错误码(errcode)有哪些，对应的错误信息（message）。例如 ：errcode：4403 message：错误的请求信息

2、编写接口测试用例（接口测试用跟功能类似，只多了一个请求报文，响应报文）
1）考虑正常异常的请求参数的请求报文
2）考虑正常和异常请求后的响应报文（例如 ：异常的错误码是什么，对应的错误信息是否正确）

3、执行测试用例：
我们是用jmeter执行测试用例，先建立一个线程组，再添加http请求，填写好请求地址，端口，和请求参数，设置参数化，添加断言等，最后添加查看结果树再运行。运行完后，检查接口是否通过，如果不通过，先定位下原因，查看接口返回的数据为什么不正确，然后，把服务器上的日志取下来，提单给开发修改。

3、JMeter测试环境怎么搭建
1）、因为JMeter是JAVA程序开发的，所以要先安装JDK；
2）、配置JAVA环境变量，包括：JAVA_HOME，PATH，CLASSPATH；
3）、双击jmeter的bin目录里面的jmeter.bat文件，就可以启动Jmeter。

4、什么时候会用到使用Fiddler
1）、做安全测试，检测敏感信息是否加密，拦截篡改数据；
2）、当测试时发现缺陷，用fiddler抓包，定位该问题是前端还是后台的问题；
3）、模拟弱网环境。

5、Fiddler怎么拦截篡改数据
参考答案：结合实际案例和使用步骤来讲
拿房产系统的登录功能来说
①打开fiddler先在请求前设置断点,在网页输入账号密码点击登录.数据被fiddler拦截,在请求体里修改密码后点击通过.网页提示密码错误,登录失败.

6、Fiddler怎么模拟弱网测试
参考答案：结合实际案例和使用步骤来讲
①打开fiddler--tools--fiddler options,选择connections,勾选'Allow remote computers to connect(允许远程连接)',保存后重启fidd
②手机与电脑连接同一个网络,将手机WiFi的代理改为手动,主机名输入网络的IP,端口号输入8888
③fiddler--Rules--Custom Rules(弹窗选择否,如果选择是要安装一个东西,所以我们选择否),在文档里搜索300,将downloaded的oSession改成'4000'
④fiddler--Rules--Performance,选择第一个Simulate Modem Speeds

7、问：用jmeter做接口可以通过，但在手机上用到这接口时用不了，什么原因：
参考答案：抓包，查看从手机发出去的数据有没有问题。

8、问：接口测试的关注点(怎么验证接口是通过的)
1、接口返回的数据是否正确；
2、向系统提交的数据是否正确写入了数据库。

9、在进行接口的自动化测试，如果遇到token校验，你是怎么处理的？
首先需要获取token，获取token的整个思路为：
A.先进行登录
B.登录成功后
C.获取token,用正则表达式提取token值
D.把获取的token当作下一个接口的请求参数

10、Jmeter的断言怎么做？
输入参数并添加察看结果树,运行后获取结果树的响应字段,添加到响应断言中就可以了

11.接口测试报错,如何定位问题
①检查参数是否需正确
②检查网络是否正常(ping服务器域名,看是否有数据返回)
③接口问题

12.接口自动化测试流程：
第一步：分析需求
第二步：创建测试计划
第三步：写测试用例
第四步：构造接口测试请求并执行
第五步：输出测试报告，评审测试结果

13.什么是接口测试
接口测试的原理是，通过测试程序或工具，模拟客户端向服务器发送请求报文，服务器接收请求报文后对相应的报文做出处理，然后再把应答报文发送给客户端，客户端接收应答报文这一个过程。

14.接口测试要关注什么内容
1、服务器返回给客户端的信息是否和预期结果一致；
2、进入系统或者数据库，检查接口是否实现的相应的功能。

************************** App测试 ***************************
《02_APP移动测试篇.txt》
问：app测试与web测试的区别
参考答案：
1）、系统架构：web端的服务器更新后，客户端会自动同步更新；如果是app下修改了服务端，意味着客户端用户所使用的核心版本都需要进行回归测试一遍；
2）、兼容性。Web端要考虑不同的浏览器内核进行测试（IE、chrome、Firefox），APP的兼容性要考虑选择主流的机型，不同的分辨率、尺寸， 以及不同的操作系统；
3）、性能：APP客户端的性能，要考虑电量，流量，GPU渲染(用GPU来在屏幕上显示图像)；
4）app考虑弱网测试，交叉事件测试，安装、卸载、更新，前后台切换；
5）界面操作，如：横竖屏切换，多点触控，事件触发区域。

问：APP的兼容性怎么测试，测了哪些机型？哪些版本?那又怎么测Android的兼容性、怎么测手机的兼容

问：app测试点有哪些？
参考答案：功能，兼容性，用户体验，安全性，安装卸载升级测试，交叉事件，UI测试，性能测试。

问：app项目做了多久
参考答案：一直在做，现在app的主体需求已经完成了，后期都是一些零零散散的需求，测试工作量比较少。

问：你测了app哪些模块
参考答案：所有功能都测

问：你怎么做app测试的
参考答案：参考本文档后面的“APP项目介绍参考思路”

问：App的性能测试怎么做的
参考答案：App的性能分为服务器端的性能和手机端的性能。我先说服务器端的性能，再说手机端的性能。
服务器端的性能，我们可以用LoadRunner或Jmeter工具进行测试，我以Jmeter工具为例子说一下App服务器端的性能测试，首先，确定app的性能测试功能点，比如，查询，提交数据，登陆这些用户常用的功能，一般会被选来做性能测试，然后，根据该功能点的接口测试需求，或使用fiddler抓包，在jmeter上构造向服务器发送的请求数据，配置好相关的设置，并做好服务器的监控，并做好服务器的监控，然后运行测试，测试完之后，收集CPU，内存等信息，集合聚合报告的内容，分析性能测试结果。

手机端的性能测试步骤是：
1、在服务器上安装监控工具(iTest/GT)
2、启动监控工具，监控被测应用
3、清空logcat日志：adb logcat -c
4、获取logcat日志：adb logcat -v time > E:\share\logcat.log
5、使用monkey运行被测应用：adb shell monkey -p your.package.name -v 500 > E:\share\monkey.log
6、根据监控图，检查CPU，内存，流量，电量是否符合性能指标。如果不符合，就把不符合指标的报表和对应的logcat发给开发定位。

问：adb命令有哪些？
adb de
问：你这个app测试人员有几个？怎么分工？
参考答案：2个。按测试的手机类型分工，每个人负责几种测试机型，每个人都要测试app的所有测试点。

Q8：你做APP用过monkey，能具体讲一下吗？
A：我们用monkey模拟用户的伪随机操作（点、触摸、滑动），对APP的稳定性进行测试。
一般我们会用到命令 adb shell monkey -p 包名 -v 次数

Q9：那如果monkey测试出现crash你怎么定位？
A：我说这种crash一般是空指针导致的，在logcat日志中输入“nullpoint”搜索到相关的日志，然后把日志给开发定位。

Q10：那问题开发修复了你怎么验证？
A：我们会进行回归测试，会按照之前的轨迹（seed）去跑monkey。

3.面试官:看你写有用MONKEY做APP测试,怎么做的?如果有问题的话怎么定位?
我:(1)用adb命令,adb logcat -c清空日志,再获取日志 adb logcat -v time 导到要保存日志的地方
(2)再使用monkey命令adb shell monkey -p 包名 -v 次数,不过次数的话我一般都是算时间来跑,比如说我跑个5分钟大概要多少次,然后直接跑个1小时的次数这样，然后跑完就看monkey日志,如果说它跑的次数跟我设的次数不一样.就说明monkey中途跑失败了。那我就要去看看logcat日志有没有null point，或anr in的关键字,如果有null point，就表示app在测试过程中crash了，然后把null point前后的日志截取下来，发给开发定位；如果有anr in，表示app在测试过程中出现了ARN(程序无响应)，我们要把/data/anr/traces.txt文件取下下来，再把ARN进程号对应的日志发给开发定位问题。(日志具体的信息，我们看不懂)

APP出现ANR的原因：
1、线程阻塞的
2、内存不足
3、CPU满负荷

APP出现CRASH的原因：
1、空值指针
2、内存不足
3、CPU满负荷

APP项目介绍参考思路：
我负责的app项目叫“xxxxxx”
主要模块有xx,xx,xx,xx,xx，主要的业务流程是xxxxxx。
测试前，先熟悉app的原型图和业务需求，确定测试点，app开发好后，先做一个冒烟测试，看看软件的基本功能是否可用，如果正常，我们再做功能测试，UI测试，兼容性测试，交叉事件测试，安装卸载测试，接口测试等。

如果面试官问具体某个测试类型怎么，就要举例子加以说明。
比如：
UI测试：检查app的UI是否和原型图一致。
功能测试：xxxx
兼容性测试：xxxx
用户体验测试：xxxx
（补上app的8大测试点，并举例子说明）

接口测试，按接口测试的方法来讲。

************************** 自动化测试 ***************************
《09_自动化测试.txt》
1、自动化测试怎么做？
参考答案：
自动化测试，是在手工测试之后进行的，是将手工测试用例转化为自动化测试脚本，用于回归测试。
首先，我们会对手工测试用例进行评估，一般选取正常场景的，复杂度不高，复用性高手工测试用例来转化为脚本，因为，用例越复杂，脚本越难维护。我们是用selenium工具来实现自动化，采用python脚本语言，基于unittest框架实现。首先，我们会构建测试套，测试套包含public部分(包括测试用例中公共的部分)，testCases（存放测试用例），reports（存放测试报告），runAllCases（用于运行项目自动化用例），脚本调试完后，每天都会跑一次，跑完后生成html格式的自动化测试结果，然后，检查测试结果中有没有失败的脚本，如果失败，就定位一下脚本失败的原因，(失败的原因：1）、可能是测试环境不稳定；2）、开发修改了代码没通知到测试人员修改脚本；3）、开发引入了新的问题)，如果是脚本问题，就修改脚本，如果是系统的问题，就提交问题单。

2、测试脚本用到了哪些技术？
参考答案：元素定位，表单切换，模块调用，获取指定文本信息等等，脚本是基于python自带的unittest单元测试框架，采用了模块化方式编写，把复用性高的元素封装到模块中，如果脚本需要用到对应的元素，直接调用就可以了，减少了冗余代码，如果元素发生变化，只需要调整元素封装的代码就可以了，提高测试用例的可维护性。

xpath和CSS定位方式的区别：
1、语法不一样；
2、CSS定位比较稳定。

3、脚本怎么组织的？
参考答案：构建测试套，测试套包含public部分(包括测试用例中公共的部分)，testCases（存放测试用例），reports（存放测试报告），runAllCases（用于运行项目自动化用例），测试脚本使用的是python的unittest单元测试框架组织管理，将所有测试脚本通过单元测试框架组织起来运行，这样做的好处是，维护起来方便，可以生成测试html格式的测试报告，报告包括：测试用例，通过数，失败数。

4、自动化率多少？
一般是30%到40%

5、问：你们自动化脚本的通过率是多少？（注意这个题目的意思）
参考答案：这个说不准，如果没有什么异常情况，自动化脚本都是100%运行通过；如果异常情况比较多，比如出现测试环境不稳定，或者开发修改了代码没通知到测试人员及时修改脚本，又或者开发引入了新的问题等等，自动化脚本通过率可能80%都不到。

6、用那个方法判断元素是否显示
is_displayed()

7.你曾经都写过多少自动化测试用例？
这个具体没有算过。但是只要有时间，模块稳定的功能都会写。就拿上个项目来说，自动化测试用例大概写了将近有70-80条这样子吧。

8、python3 的数据类型有哪些？
Number（数字）
String（字符串）
List（列表）
Tuple（元组）
Sets（集合）
Dictionary（字典）

不可变数据（四个）：Number（数字）、String（字符串）、Tuple（元组）、Sets（集合）；
可变数据（两个）：List（列表）、Dictionary（字典）。

9、面：unittest框架了解吗？
参考答案：unittest框架，由setUp()--环境预置，testCase()--- 测试用例 tearDown()----环境恢复，三大部分组成，unittest框架可组织执行测试用例，并且提供丰富的断言方法，判断测试用例是否通过，最终生成测试结果。

10、app自动化做过吗？
参考答案：没有做过，不过和web端自动化的测试思路差不多的，也要用到元素定位，unittest框架这些，到时候工作需要的话，学一下很快就能上手了。

************************** 四大测试 ***************************
一.支付功能怎么测试(特别重要)
1、从功能方面考虑：
1）、用户的使用场景：包括正常完成支付的流程；支付中断后继续支付的流程；支付中断后结束支付的流程；单订单支付的流程；多订单合并支付的流程；余额不足；未绑定银行卡；密码错误；密码错误次数过多；找人代付；弱网状态下，连续点击支付功能功能，会不会支付多次；分期付款等；
2）、不同终端上支付：包括PC端的支付、笔记本电脑的支付、平板电脑的支付、手机端的支付等；
3）、不同的支付方式：包括POSE终端机支付、银行卡网银支付、支付宝支付、微信支付等；
4）、从产品容错性上：包括支付失败后，能否再次支付、能否退款；
2、从性能方面考虑：
多个用户并发支付能否成功；
支付的响应时间；
3、从安全性方面考虑
使用Fiddler拦截订单信息，并修改订单金额，或者修改订单号，(下两个订单A,B，付款时拦截订单B，并把订单B的订单号改为A订单的订单号)无法完成支付；
4、从用户体验方面考虑
是否支持快捷键功能；
点击付款按钮，是否有提示；
取消付款，是否有提示；
UI界面是否整洁；
输入框是否对齐，大小是否适中等。
5、兼容性
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试

二.购物车怎么测试？(特别重要)
1.功能测试
a）、未登录时：
将商品加入购物车，页面跳转到登录页面，登录成功后购物车数量增加。
b）、登录后：
所有链接是否跳转正确；
商品是否可以成功加入购物车；
购物车商品总数是否有限制；
商品总数统计是否正确；
全选功能是否可用；
删除功能是否可用；
价格总计是否正确；
商品文字太长时是否显示完整；
购物车中下架的商品是否有标识，是否还能支付；
新加入购物车商品排序（添加购物车中存在的店铺的商品和购物车中不存在的店铺的商品）；
是否支持快TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
收藏功能是否可用；
购物车结算功能是否可用。
2.兼容性测试
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试
3.用户体验测试
删除商品是否有提示；
是否支持快捷键功能；
是否有回到顶部的功能；
商品过多时结算按钮是否可以浮动显示；
购物车有多个商品时，能不能只对单个商品结算；
界面布局、排版是否合理；
文字是否显示清晰；
不同卖家的商品是否区分明显。
4.性能测试
打开购物车页面要多长时间

三.登陆功能怎么测：
1.功能:
（1）输入正确的用户名和正确的密码

（2）输入正确的用户名和错误的密码

（3）输入错误的用户名和正确的密码

（4）输入错误的用户名和错误的密码

（5）不输入用户名和密码（均为空格）

（6）只输入用户名，密码为空

（7）用户名为空，只输入密码

（8）输入正确的用户名和密码，但是不区分大小写

（9）用户名和密码包括特殊字符

（10）用户名和密码输入超长值

（11）已注销的用户名和密码能否登录

（12）登录时，当页面刷新或重新输入数据时，验证码是否更新

(13)异地登录有没有提示
2.安全:
使用fiddler抓包,拦截登录信息,看密码是否加密,修改用户名,密码能否成功登录
3.性能:
1).多个用户能否并发登录
2).点击登录的响应时间

4.兼容性测试
BS架构：不同浏览器测试。
APP：不同类型，不同分辨率，不同操作系统的手机上测试

5.用户体验:
输入框是否对齐,大小是否适中;
界面布局、排版是否合理；
文字是否显示清晰,有无错别字;
提示是否简介明了

四.文本输入框测试点：
功能:
1、重复
2、空 也就是不填写是否支持
2、长度：例如支持100字符， 那需要测试100字符、101字符、100字符后输入一个汉字的情况， 最大长度的显示是否正常
3、哪些是支持的字符类型：数字、字母、汉字、字符！@！#、特殊字符（tab 回车键是否支持）
4、是否支持多行，保存是否成功，显示是否按输入的多行显示
5、字符中带有HTML标记对时，显示是否正常 例如：:<br> <br> &nbsp;
6、字符串前后中带空格，前后的空格是否过滤， 中间的空格是否保留
7、最大长度显示是否正常
8、全角半角的字母、数字
9、字符串中带JS标记对， 比如<script>alert('aa');</script>
10、复制功能是否可用
11、粘贴功能是否可用、粘贴超过最大长度的字符串怎么显示？
12、多浏览器的兼容性
13 、权限校验

用户体验:
输入框是否对齐,大小是否适中;

************************** OK ***************************