测试：面试问题(多精全)
目录面试问题 1，你们原来项目的测试流程是怎么样的？ 2，你介绍下，你最熟悉的项目？ 3，你们原来项目的主要的功能模块有哪些，你主要负责哪些模块？ 4，你说原来充值功能，你是怎么测试的？ 5，产品是怎么上线的？ 6，你提交的bug，开发不认可怎么办？ 7，对应无法重现bug，应该怎么处理？ 8，原来项目有遇到哪些经典的bug，你是怎么发现的，最后怎么解决的？ 9，linux你是怎么用的？ 10，数
文章共36,083字 · 阅读需要大约121分钟
3，你们原来项目的主要的功能模块有哪些，你主要负责哪些模块？
8，原来项目有遇到哪些经典的bug，你是怎么发现的，最后怎么解决的？
23.web测试中，如何判断是前端的bug还是后端的bug呢？
35.电商的库存逻辑怎么测。比如客户下订单，库存减少，规定时间内未支付定单就取消，库存又加回来
46.请写出项目一中核心模块（erp、fangwe）有哪些，请写出模块的业务流程
54.你测试的时候发现哪些经典bug，你描述出来。（erp 和 方维）
58. 用例包含哪些部分，哪些测试用例设计方法，你一般常用哪些方法？
60.linux在测试工具中有没有用到过，具体哪些场景用到？
面试问题
1，你们原来项目的测试流程是怎么样的？
我们的测试流程主要有三个阶段：需求了解分析，测试准备和测试执行
１需求了解分析阶段
【我们的SE会把需求文档给我们自己先去了解一到两天这样，之后我们会有一个需求澄
清会议，我们会把不明白不理解的需求在会议上说出来，包含需求的合理性
还有需求的可测性等，产品这边解答，目的是让我们测试这边和开发对需求的理解达到一致】
２测试准备阶段
【会议结束之后我们开始准备测试工作，我们测试这边会写一个测试计划，分配每个人
负责的模块，然后我们就根据自己负责的模块用xmind（思维导图）进行测试需求分析
，分析测试点，以及编写测试用例。之后我们会在自己的组内先进行评审，评审修改之
后还会在我们的项目组评审。评审完后进行修改测试用例】
３测试执行阶段
【开发人员编写好代码之后，我们会把代码包部署到测试环境中进行SIT测试，在正
式测试之前我们会先做一个冒烟测试，冒烟测试通过之后我们才转测。在执行测试的过
程中，我们如果重现有bug就会用禅道记录并且提交bug ，也会进行回归测试，一直到没
有重现bug达到上线为止，每一轮测试结束之后我们都会写一个测试报告。一般情况下，测
试2-3轮之后会达到上线要求。上线前我们会做UAT测试，当达到上线的标准后，测试报告会认为测试通过，由项目组与产品决定时间上线，上线完成，一周左右我们会写一个项目总结测试报告，总结我们在上一个版本中遇到的问题以及今后有哪些地方需要改进。产品迭代几次后，我们会跑自动化用例来测试所有的功能模块】
2，你介绍下，你最熟悉的项目？
【我最熟悉的项目是一个金融p2p理财项目。这是一个由第三方控管资金，它通过采用众筹模式，借款功能，统一管理来实现借款人资金周转和投资人投资理财以及管理平台赚取管理服务费的项目】
项目的核心业务是同过借款人放标，让投资人选择投标的方式使借款人获得所需的资金。
该项目的前台模块主要有：前台首页、我要理财、我要借款、我的p2p信贷、安全保障、积分商城、理财中心；该项目的后台主要有：后台首页、借贷管理、理财管理、会员管理、资金管理、数据统计、部门管理、前端设置、微信平台设置、营销推广、系统配置。
方维借贷的借款业务流程大概如下：
注册—> 登录-> 借款 - > 后台初审 -> 后台复审 -> 公布、投标 -> 满标 -> 后台放款->借款人提现->借款人每个月还款-> 投资人每个月收取收益。
还款业务流程：贷款人可以在我的P2P信贷的贷款管理中随时查看或还款，可以选择还款、提前还款和申请续约。
我负责的模块只要是：借贷管理、会员管理、我的p2p信贷3个模块；借贷管理主要包含借贷审核管理、贷款管理、借贷记录、债权转让；会员管理主要包含会员列表、会员审核、认证管理、额度申请、信息快速查询；我的p2p信贷主要包含投资管理、借款管理、账户管理。
后台的借贷管理主要功能是审核各种类型的借贷以及在满标后进行放款，查看过往的借贷记录。同时在投标信息和债权转让中可以对所有的投标和债券转让进行操作。
3，你们原来项目的主要的功能模块有哪些，你主要负责哪些模块？
我们原来的项目主要功能模块分为前台和后台，我们组主要负责前台的借款、
投资、充值、提现以及个人信息的展示与修改，还有就是登陆和注册等模块。
4，你说原来充值功能，你是怎么测试的？
一.首先我们先测试充值的主体功能，看看能否充值成功；（等价类，边界值，判定表，流程分析法，状态迁移法，错误推测法，异常处理法来测试）
用边界值的方法测试充值限定的额度能否充值成功
用特殊字符在充值输入框输入是否有提示语提醒
充值输入框为空时点击充值是否有提示
在输入框里输入金额，再后退网页再进入充值页面，是否还保存着输入的金额数
多次往返充值界面，是否还可以正常充值
选择多个充值支付方式能否充值成功
选择各银行网银能否充值成功
充值成功时，有没有相关的提示和页面是否正确跳转
充值成功后，相关联的金额是否正确显示
充值成功后，查看数据库的相关数据是否有存在和正确
点击第三方支付（如支付宝，微信）是否有相关的连接页面跳转
能否同时选择多个支付方式来充值
交叉选择支付方式后，再选择其中一个支付方式能否充值成功
充值输入框多次修改充值金额，能否充值正确
等..........
二.我们再测试充值的性能，用jmeter模拟大量用户同时充值，看看能否充值成功；
三.我们再对充值的安全性进行测试，
（1）绑定银行卡充值和未绑定银行卡能否充值成功；
（2）绑定多张同名的银行卡以及一个用户绑定多张不同名的银行了能否绑定充值成功
（3）实名认证和未实名认证能否充值成功；
（4）用边界值的方法测试每天充值限额，次数
（5）测试一天之内最多可以输入密码错误次数是多少，次数达到多少次锁卡，是否需要
到银行解锁方能再进行充值
（6）输入充值金额后需要输入多少次密码，是否有加密，不输入密码能否充值成功；
（7）使用其他的支付方式支付能否充值成功；
（8）测试充值金额的类型；
（9）充值之后所充值的账户以及平台的余额额度是否有增加；
（10）单次点击，多次点击会不会充值成功；以及多次点击会不会多次充值；
（11）同时打开多个充值界面，能否充值成功；
（12）不登陆用户的情况下是否充值成功；
（13）不选择银行卡或其他方式支付是否能充值成功；
（14）跨站攻击，数据泄密；
四.我们还要对兼容性进行测试，看看不同的版本、分辨率，不同的浏览器，能否正常充
值；
五.对易用性进行测试，测试充值的整个流程是否易用，遇到一些不懂的有没有相应的温
馨提示；
六、我们还会考虑测试异常的情况：（网络异常和设备异常）
比如说：
（1）充值的过程中突然没网或者网络中断或弱网情况下是否充值成功；
（2）充值过程中突然断电了，能否充值成功；
（3）充值过程中设备卡顿能否充值成功；
（4）银行卡挂失，被注销，卡内余额不足，卡里金额被冻结，额度超过限额的情况能否
充值成功；
七.我们再对界面进行测试：
（1）界面是否美观，格式是否正确，中文是否有错别字；
（2）在其他浏览器能否打开我们这个充值界面，能否正常显示并且正常充值；
（3）界面上的按钮是否符合用户的使用习惯，主要关键的功能按钮是否容易找到，操作是否便捷；
（4）在不同的浏览器里界面缩放后，界面排版是否正常显示
5，产品是怎么上线的？
一般我们会选择晚上上线，开发测试还有客户产品全部到场，进行上线测试
首先，开发将代码打包到生产环境的服务器中，把代码包替换到服务器的目录中。如果
数据表有变化，开发就会运行sql脚本，创建表，修改表的操作；
3）接着，我们测试就开始先测试主体业务功能以及新增的功能模块；
测试通过之后，我们会在界面上把上线测试的数据删除，在规定的日期正常上线。
4）如果发现bug，开发人员当场修复bug，修复成功之后我们测试再复测，通过就可以
正常上线。
5）如果发现了bug开发人员在上线规定时间之前都还没有修复好的话，就看问题的严重性，如果严重就延期上线，或者迭代到下一个版本中。如果我们是迭代版本的话我们还需要版本回滚。如果不严重，产品跟客户觉得可以上线，就正常上线。
6，你提交的bug，开发不认可怎么办？
【首先我会再看需求文档，是不是我的理解有误，如果是我对需求理解错的话我就去关闭bug】
如果是bug再去让身边的同看看听下他们的意见，然
后自己先再三确去复测，并且保存好截图和日志，确定这是一个bug之后我就去跟开发说明
白，并且给他看bug重现的截图以及日志。如果开发还是不认可的话我就跟产品或项目经理说明
白情况，
7，对应无法重现bug，应该怎么处理？
【首先，我会多测几次，测了好多次都无法重现的话我就先把bug挂起。并且留意一下
，看看往后的测试中会不会重现类似代码的bug，因为有些是偶现bug。如果在后面的测
试中重现bug就激活。如果经过几个版本都还没发现的话就关闭bug】
8，原来项目有遇到哪些经典的bug，你是怎么发现的，最后怎么解决的？
【经典bug：1.在理财中心的赚取小金库中，投资人投资收益为负数】
【发现途径：我是在模拟投资人，输入投资金额的时候，显示出来的收益为负数】
【解决：首先我去数据库查找到对应的表，比对结果跟界面显示的数据是否一样，一样
我就把数据库的记录和界面显示截图都保存好。之后提交这个bug，开发人员通过修改
代码，我再复测，没有重现bug】
2、还有一个就是在借款流程中，我们通过修改数据库中的数据，把借款时间修改了，制造出一个逾期未还款的数据，结果显示还款的金额比借款金额还少，而且管理费收得特别高，存在不合理性。3、还有一个是在产品上线后，运维人员在统计数据时发现少了一条数据，我们去数据库检查发现0分0秒的数据没有统计，后来开发人员修改了代码之后就解决了
9，linux你是怎么用的？
（1）在测试执行的过程中，我们发现的bug，有时候需要定位bug，协助开发修复bug
时需要在linux里通过命令tail -200 或tail -500查看当天的日志的后面多少行或者前面多少行定位bug或者通过tail -f来查看日志里的关键字exception(异常)、error(错误)或用重定向（ls -la > ls.txt）把信息保存起来再用vi命令进入信息里然后打开搜索命令shift + ：/进入文件定位模式搜索error,fatal（致命）,或者exception等
（2）后台程序运行久了会对系统造成卡顿等诸多隐患或我们做性能测试的时候。我们都会通过linux的命令Ps -ef(显示所有进程)、top(监控程序执行状况)、free -m(显示内存使用情况)来查看系统资源，如果服务器出现故障时我们也会用(service httpd status)看下服务器是否启动,用ps -ef|grep httpd 查看apache进程是否启动，用ps -ef | grep java查看jdk进程是否启动。如果服务器起不来，常见的问题有端口可能被占用，用netstat -an | grep 8080 查看端口是否已被占用。
（3）搭建测试环境的时候我们在是在linux下进行的，搭建LAMP时在线用命令yum install安装apache，php以及mysql；或通过xshell来导入需要的环境包来搭建LTMJ（Tomcat、Mysql、jdk）
10，数据库原来工作当中是怎么用的？
原来我们数据库用的比较多的，就是数据结果检查，测试一些数据准备，性能测试造大量数据
测试执行到的结果，我们需要通过sql语句select来查找数据库对应的表，看看数据库信息跟我们执行的结果是否一致，比如：生成申请订单后，我们会去数据库里面去检查下，数据库中数据是否跟申请订单数据一致。
我们在测试执行时需要做一些测试数据准备，我们就用insert into输入数据或（者 update set 修改数据），我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致；比如：原来我们一个初审功能里面有个分页功能，测试分页功能，需要100条数据，我们就通过数据库操作添加100，可以用insert into。
insert into 表名 value（）
insert ignore insert 表名 value（） 忽略主键重复
replace insert 表名 value（）主键或者unique索引重复时替换
还有在做性能测试时，模拟用户场景时需要用到大量的数据，这时就需要我们到数据库中制造大量的数据出来。比如说，测试充值，需要大量用户数据，充值表中大量数据，比如10W条数据，我们就用存储过程去造。
delimiter //
create procedure 存储过程名(n int)
BEGIN
declare i int default 0;
while i <= n do
Insert into 表名 values(值1，值2,.......);
set i=i+1;
end while;
end //
delimiter ;
call 存储过程名(数据量（n）);
我认为接口测试其实是比较简单的，原来我们的接口测试，开发这边会给我们一个接口文档，我们根据接口文档编写测试用例，考虑接口正常场景跟异常场景。测试用例编写完成后，我们会用python+request去执行，查看返回的结果是否跟用例的一致，不一致有bug。
我们需要注意的是参数之间是不是组合关系，如果是组合关系就需要同时考虑，如果不是组合关系就要单独考虑。也需要考虑正常和异常的场景，多一个参数和少一个参数以及参数为空的情况。比如我们用python+request做的一个前端注册接口，首先我们把每条用例定义成一个函数模块，再把需要组合的参数编写进用例里面。比如用户名跟密码这是组合关系就要同时对这两个参数进行考虑。当用户名与密码正确的情况下，返回的是一个正确的注册成功的信息。当用户名为空和两个密码一至的情况下返回的提示应该是一个用户名不能为空的信息。当用户名正确和两个密码不一至的情况下返回的提示应该是一个密码不一至的信息，当用户名正确和两个密码都为空的情况下返回的提示应该是一个密码不能为空或密码过弱的信息。当用户名重复，手机号码重复，勾选了协议和没勾选了协议的情况，还有同时我们也需要用等价类边界值对参数的长度、特殊符号的输入和类型进行考虑。最后我们再加assert来断言判断返回的参数是否正确。
我觉得接口测试的主要好处是，在后端测试接口，覆盖更加全面，测试时间可以提前，
原来在接口过程，发现问题最多的，来源于格式的校验这块，，比方说，原来我们申请借款，利率设置成5000，也可以申请成功，功能测试，界面已经做了校验，只能在接口中才能测试出这个问题，还有原来我们申请借款时候，需要勾选，同意，协议，接口中不没有勾选，也表示成功。
12，接口自动化测试怎么测？
原来我们也做了很多接口自动化。接口自动化这块，其实原来我们也是用jmeter请求去做的，这个时候，我们也用到一些工具，http代理，主要方便编写接口请求，通过录制就行了，我觉得接口自动化只是在接口测试中多加了一些参数化、关联、断言参数，主要是函数参数化，自定义变量参数化，文件参数化，主要文件类型csv跟txt，不过原来csv文件用的比较多，还有一些数据库的参数化，断言，主要响应代码断言，响应文档断言。
比方说，原来我们一个登录接口主要是正常场景，异常场景这块。正常场景，主要是用户跟密码正确，采用数据参数化，把用户名用随机函数进行参数化，随机长度大一些，用户名不存在的情况，原来是通过文件参数化，设置参数值，密码不正确也是通过文件参数化，接口请求中host地址，目录地址，我们都进行数据化，自定义变量去操作，结果检查中，我们主要是用断言来检查，每个请求，设置了2个断言，一个响应代码断言，一般是200，响应文本断言，登录成功，返回码为1，状态提示成功，检查是否成功，对应异常场景也是，都需要设置断言，去检查结果原来做的申请借款接口，需要登录接口cookie，我需要建立2个接口，一个登录接口，一个申请借款接口，通过正则表达式去提取 登录接口返回cookie，在申请借款请求接口，设置http cookie时，值为登录接口返回cookie，还有也要考虑原来我们项目，还有token值，提取登录返回token，提取，当成申请借款的请求参数，当测试场景的脚本编写完成，执行接口测试用例，我们在察看结果树中，检查，主要是看颜色这块，红色检查哪些地方失败，绿色表示通过
13，自动化测试怎么测？
之前我们公司是通过python+selenium+unittest框架编写脚本来实现自动化。我们也会用selenium2Library + RF框架来实现自动化的。
我觉得unittest和RF（RobotFramework）框架都差不多一样，都是用来组织用例的。【相同点】
不同的是unittest框架是用webbdriver作为驱动，并且要考虑驱动的传递。而RF框架是用关键字keyword_driven来驱动。Unittest框架是通过调用自己封装的方法来实现自动化测试，而RF框架是通过调用自带的第三方库或者扩展库里的关键字来实现自动化测试。RF框架平时调用比较多的就是selenium2Library,excellibrary,
mysqllibrary测试库。【不同点】
用unittest框架编写脚本时，我们需要对元素进行定位，我们用得比较多的元素定位方法有：css,id,xpath,class,link。我们也会考虑下拉框、windows的弹出框以及滚动条的跳转，还有进入内嵌和退出内嵌界面的操作【元素定位】。我们也会对模块进行封装，把公共的方法和共同的操作步骤封装在一起【模块封装】。还会编写代码对元素进行参数化【一句话带过】。也会用assert进行判断检查，看看结果跟预期结果是否一致【断言】。
使用RF（RobotFramework）框架先是建立测试项目，再建测试套件，最后建测试用例。元素定位方法跟unittest一样，还有需要建立公共的关键字以及套件的公共资源。我们也会把公共的方法和共同的操作步骤封装在一起。配置参数用得比较多的是数据库连接，excel表格以及py文件，前两种情况我们需要先导入DatabaseLibrary和excellibrary测试库。我们也会用：Should Be Empty 添加断言来判断检查结果是否跟预期结果一致。同时我们也会考虑新界面和新元素的出现，所以我一般会用到只能等待时间和强制等待时间。
当然python+selenium+unittest框架也需要导入unittest模块，继承unittest里面的一些方法。以及我们需要注意的执行顺序，首先是setup(),接着是执行testcase(),最后执行 teardown() 如果是多个用例的话，每执行一个testcase()就要先执行setup(),最后执行teardown()
总的来说RF（RobotFramework）比较简单方便上手比较快，如果公司对自动化要求不高的话可以选择RF框架来做，如果比较高的话就选用unittest框架来做。
例如我们用python+selenium+unittest来执行一个审请提现的模块；首先我们先进行自动化框架分类，分成测试数据、需要定位的元素、公共方法（比如说，一些数据的操作、excel操作，我们会封装成一个公共方法）。先采用css定位，把审请提现所对应的元素定位出来，然后编写测试用例，我们都会建立一个文件夹存放这些测试用例，用例里包含了到用户登陆后，用户登陆前，当提现金额和支付密码正确的情况下，当提现金额为空和支付密码正确的情况下，当提现金额正确和支付密码为空或错误的情况下，不选择银行卡的情况下，重新选择了银卡的情况下，多次重新选择银银行卡的情况下，异常情况下审请提现，同时我们也需要用等价类边界值对参数的长度、特殊符号的输入和类型进行考虑，我们再加assert来断言判断，再把它们封装成一个公共方法。然后我们是用unittest脚本，去执行所有测试用例的，再通过调用HTMLTestRunner模块生成html格式的报告。再分析报告，总结报告。
在做自动化测试的过程中我们会遇到一些比较麻烦的事情就是元素定位：（1）比如说在申请贷款中选择还款方式有个下拉框，我们定位很久都没定位到，后来才了解到下拉框有好几种定位方法，有class还有css中的父子元素定位：（2）在描述信息中，内嵌元素没有id和name值，这我们就需要用到标签来定位；（3）还有一些元素是变动的，比如之前在审核订单号时，订单号是变动的，我们就通过连接数据库查询出订单号，再去拼接元素属性来定位。
在自动化测试中我们也会发现bug。（1）我们在自动化测试中报错，之后我们去定位问题，发现多了一个弹出框，这是开发编写代码调试用的，没有删除调试代码，导致脚本运行不成功；（2）还有就是在充值过程中，开发添加了一个新的支付宝支付功能，编写代码是把原有的快捷支付代码做了覆盖，导致原来的支付功能支付不成功。
14,APP测试怎么测？
我们app测试有Android app 和ios app 两种。Android app主要是从以下几点进行测试（1）界面测试，我们测试界面跟需求文档中界面原图是否一致，使用不同的手机界面分辨率，以及界面大小等方面进行测试。（2）功能测试，功能测试和web测试差不多，主要测试app对其他相关功能模块的影响。（3）兼容性测试，我们也会用真机来测试一下兼容性像用的三星Android版本6.0.1、红米Android版本5.1、小米5Android版本7.0,华为mate10Android版本8.0，IPhone5、IPhonex、IPhone6s puls对应的IOS为8.4.1-11，也可以借助阿里云测试；还要测试手机是否方便好用，以及跟手机自带的软件是否有冲突，和市场上排名前100的主流软件是否有冲突来进行交互性测试，防止被当成病毒不允许安装。（4）网络测试，在不同的网络中进行测试，比如：2G，3G，4G，移动，电信，联通，还有网络之间切换，用fiddler进行弱网测试。（5）交互性测试，（6）易用性测试，（7）异常测试，异常测试手机关机、重启以及断网的一些异常情况（8）安全测试，安全测试的话，我们会使用xss脚本和sql注入来进行代码攻击，一般使用扫描工具Appscan来进行攻击，然后还会用fiddler进行抓包，查看关键信息有没有进行加密，查看日志中有没有加密，数据库有没有加密，以及界面上的展示和输入是否加密了，会在fiddler抓包的时候设置断点，篡改数据，看能不能篡改成功。（9）权限测试，（10）稳定性测试，还会使用monkey测试App的稳定性，一般运行100W次，大概八个小时，查看日志文件，如果出现crash，anr，exception这些单词，则是出现bug，我们会将bug提交给开发，开发修复之后，我们会用种子数来进行回归复测（11）性能测试，是为了提高用户的体验感，我们一般是用emaggee来测试监控App的cpu、内存、fps等性能指标，监控完之后编写性能测试报告，然后再对比性能指标，看是否达标。
15,安全测试怎么测试的？
安全测试我们常用的方法是：1，sql注入，2，xss脚本攻击，3，数据加密，4，权限控制运用扫描工具appscan扫描web系统。扫描app的一般用腾讯wetest 等平台测试。
测试前端（web）时我们首先检查检查一下用户的感敏信息有没有进行加密显示，通过Fiddle抓包工具检查一下用户的感敏信息有没有进行加密后传输如：用户密码，相应的银行卡，个人信息等，再到日志中搜索关键信息，搜索到，就泄密，存在安全漏洞，数据库中是否做了加密处理。还有就是把发送请求的数据篡改例如：打开fiddler工具，设置过滤器，设置断点把商城里的支付订单的1000完金额修改成1块钱，再放行发送数据，看是否，支付1块钱，订单支付成功，如果成功则是bug，预期结果是支付金额不对才行。
用Sql语句注入和xss脚本攻击，把sql语句或xss脚本编缉成csv文档通过jmeter工具添加“CSV 数据文件设置”来调用里面的语句来在所有的查询位置、所有的接口请求、url请求链接参数中，进行sql语句注入或xss脚本攻击：模拟sql语句xss脚本攻击数据库，看它是否把sql注入代码或xss脚本当成字符处理、，如果不是就是bug，再看功能不能正常使用、系统是否崩溃，错误弹出框，界面是否变形。还有在所有可以保存的地方，都添加xss脚本攻击代码，看看是否出现异常。
权限控制（用户的校验）校验用户安全认证信息是否正确，如没有权限的界面不能进入，不能提供操作入口或不能通过url直接去访问：例如；把所有需要权限的界面，全部复制一份出来然后退出用户再通过url链接去访问功能如果可以访问，就是bug，如有提示登录，属于正常。还有登陆用户再退出用户后，点击浏览器的后退不能进入原来的界面。
通过appscan扫描工具去扫描，我们一般是这样操作的；1.启动软件进入主界面—>选择创建新的扫描：2.在弹出的新建扫描对话框中选择常规扫描：3.在弹出的扫描配置向导对话框中选择AppScan(自动或手动)，点击下一步：4.在此页面中填写需要扫描系统的网址，点击下一步：5.选择登陆方式为记录，点击下一步：6完成系统登录操作后，关闭浏览器，选择登录管理中的“详细信息”；7.在“详细信息”中，取消“激活会话中的检测”，同时在“登录会话标识中”，对变量参数值进行跟踪以确保参数的正确处理而获得系统访问权限；8.把密码修改页面URL、用户权限删除URL等页面添加至排除测试范围，防止Appscan的请求产生相应影响（防止Appscan修改密码或删除用户帐号）；9.在“自动表单填充”中，填入用户名和密码参数，并填写参数值，其余不做修；10.如果测试过程中，应用服务出现性能响应过慢的问题，适当调整测试线程数为2~5；11.测试策略选择为“严重性”进行过滤只勾选关注的严重性级别，把“高”、“中”和“低”选上。13.点击确定按钮，结束扫描配置工作；14.点击扫描按钮，选择“仅探索”，Appscan开始执行探索工作；15.探索自动结束后，点击“手动探索”按钮，此时，在弹出的IE浏览器窗口中登录系统，手工的任意访问系统页面（1~10个），关闭浏览器；16.在弹出的参数添加窗口中，点击“确定按钮”；17.点击扫描按钮，选择“完全扫描”，Appscan开始执行测试工作；18.测试执行结束后，点击报告按钮，选择关注的测试结果信息，勾选“报告内容”里的所有勾选；19.“保存报告”，保存类型建议选择为html；然后分析报告。（只需辽解面试尽量不要提及）
16,抓包工具怎么用的？
我原来的公司对于抓包这块，在App的测试用得比较多。我们会使用fiddler抓取数据检查结果，定位问题，测试安全，制造弱网环境；
如：抓取数据通过查看请求数据，请求行，请求报头，请求正文，信息是否正确去检查结果，如果是以4开头的话就有可能是前端问题一般我会到前端排查，以5开头就有可能是后端问题我就会到后端排查；如果是200的话，就需要检查请求参数是否正确，然后定位问题所在如果错误：前端问题，查看请求url，js有没写入，没有错误：后端问题，看后端具体返回的数据，如代码问题，看运行日志 ，是否包含 exception，error或根据时间点去看日志。
测试安全，抓取数据查看用户的感敏信息有没有进行加密显示，还有就是把发送请求的数据篡改是否成功。
弱网环境，通过fiddler工具选择Customize Ruels...（Ctrl+R）调出定义脚本编辑器找到“if (m_SimulateModem)”设置上行下行网速，然后把Rules->Performance->Simulate Modem Speeds选中生效
常用抓包工具有：Charles，wireshark，fiddler，谷歌浏览器内置抓包 f12，fiddler；（只需辽解面试尽量不要提及）
17,协议了解有哪些？
HTTP协议（HyperText Transfer Protocol，超文本传输协议）是用于从WWW服务器传输超文本到本地浏览器的传送协议。它可以使浏览器更加高效，使网络传输减少。它不仅保证计算机正确快速地传输超文本文档，还确定传输文档中的哪一部分，以及哪部分内容首先显示等。超文本传输协议，是一个基于请求与响应，无状态的，应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议,所有的WWW文件都必须遵守这个标准。设计HTTP的初衷是为了提供一种发布和接收HTML页面的方法。
HTTP是一个应用层协议，由请求和响应构成，是一个标准的客户端服务器模型。HTTP是一个无状态的协议。
请求行以一个方法符号开头，以空格分开，后面跟着请求的URI和协议的版本，格式如下：Method Request-URI HTTP-Version CRLF GET /login?from=%2F HTTP/1.1其中【Method表示请求方法；Request-URI是一个统一资源标识符；HTTP-Version表示请求的HTTP协议版本；CRLF表示回车和换行（除了作为结尾的CRLF外，不允许出现单独的CR或LF字符）】。
请求方法（所有方法全为大写）有多种，各个方法的解释如下：GET（请求获取Request-URI所标识的资源），POST（在Request-URI所标识的资源后附加新的数据），PUT（请求服务器存储一个资源，并用Request-URI作为其标识），DELETE（请求服务器删除Request-URI所标识的资源）
HTTP响应也是由三个部分组成，分别是：状态行、消息报头、响应正文。
返回状态行：HTTP-Version Status-Code Reason-Phrase CRLF
HTTP/1.1 200 OK
HTTP常见的响应状态码有：
200 OK //客户端请求成功
401 Unauthorized //请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
403 Forbidden //服务器收到请求，但是拒绝提供服务
404 Not Found //请求资源不存在，eg：输入了错误的URL
500 Internal Server Error //服务器发生不可预期的错误
503 Server Unavailable //服务器当前不能处理客户端的请求
而数字；2开头的表示请求成功 ; 3开头，重定向，4开头的一般都是客户端的问题 ;5开头的一般都是服务器的问题
HTTPS是身披SSL外壳的HTTP。HTTPS是一种通过计算机网络进行安全通信的传输协议，经由HTTP进行通信，利用SSL/TLS建立全信道，加密数据包。HTTPS使用的主要目的是提供对网站服务器的身份认证，同时保护交换数据的隐私与完整性。
HTTP特点:无状态,无连接,基于请求和响应：基本的特性，由客户端发起请求，服务端响应简单快速、灵活,通信使用明文、请求和响应不会对通信方进行确认、无法保护数据的完整性。
HTTPS特点：基于HTTP协议，通过SSL或TLS提供加密处理数据、验证对方身份以及数据完整性保护，如：内容加密，验证身份，保护数据完整性，混合加密，数字摘要，数字签名技术。
客户端输入URL回车，DNS解析域名得到服务器的IP地址，服务器在80端口监听客户端请求，端口通过TCP/IP协议（可以通过Socket实现）建立连接。HTTP属于TCP/IP模型中的应用层协议，所以通信的过程其实是对应数据的入栈和出栈。
Tcp协议：TCP协议又称传输控制协议，是面向连接的可靠传输。udp协议是用户数据报协议，是面向非连接快速度的传输。
tcp协议： 传输控制协议
tcp 三次握手
第一次握手：建立连接时，客户端发送syn包（syn=j）到服务器，并进入SYN_SENT状态，等待服务器确认；SYN：同步序列编号（Synchronize Sequence Numbers）。
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN+ACK包，向服务器发送确认包ACK(ack=k+1），此包发送完毕，客户端和服务器进入ESTABLISHED（TCP连接成功）状态，完成三次握手。
再进行数据传输
为什么需要三次握手呢？为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
18,性能测试怎么做的？
接口性能测试其实就是通过工具模拟多种正常，峰值，异常的负载条件来对系统的各项性能指标进行测试。性能指标主要考虑，平均响应时间，吞吐量，吞吐率还有每秒事务数，以及系统的资源使用率，CPU，内存等。接口性能测试主要考虑硬件配置和组网方面，接口性能分析的对象有包括网络传输的快慢，我们可以用ping命令来查看，还要考虑服务器的硬件配置内存，CPU，磁盘读写，可以用top命令来监控，网络传输快慢和硬件配置的CPU，men,磁盘读写 这几个我们平时还会用nmon来监控，nmon会把监控的数据形成表格形式，更方便我们查看。还要考虑Apache中间件，要考虑中间件设置的最大连接数，看设置的合不合理，连接数太少了，当会话数超过了设置的最大连接数会导致等待时间变长可能会导致超时，还要考虑数据库的最大连接数和SQL语句的执行时间以及执行的计划有没有用索引,还要考虑索引的命中率，最后还要考虑代码写的好不好，处理的时间长不长的问题。做性能测试我们平时都是用排除法一个一个的去排除（一般代码方面的问题我们是最后去考虑的），在我以前的公司我们主要是会考虑用户操作使用比较频繁的模块，比如借贷，充值，投资模块，我们一般会通过增加并发数来压测，观察CPU ,mem 磁盘读写 还有吞吐量和每秒事务数等性能指标，以前我老大呢是要求我并发100个用户，我用jmeter 把线程数设为了100，永久循环，持续时间半个小时，启动延迟5s,我在Linux上用nmon监控了网络快慢和CPU和mem,当我运行脚本的时候我看聚合报告90%的平均响应时间达到了6s吞吐量也比较小，在Linux上用nmon监控CPU，mem还有网络，但是发现CPU差不多到了100%，也有用top命令监控资源，并且我还在Navicat用SQL命令show full processlist去抓取当前运行的SQL语句，发现有很多语句是用的多次左关联，在查看了这条SQL语句的执行计划发现没有用索引，再查看了索引的命中率，命中率到是还行，运行完了我首先看了下nmom生成的报告，发现CPU一直是处于爆满状态，其中主要是mysql的占比很大，这个时候我基本上判断数据库的问题，我呢就照着前面的在运行了一次，同样还是用nmom命令去监控CPU，mem，网络问题，这次我是主要在Navicat上用命令去抓取SQL语句，还是一样有很多语句都是左关联，并发现很多空连接（sleep）我就用show global variable like "wait_time"
命令查看了设置的休眠时间(等待时间) 发现时间很长28800s ，然后我就把这个休眠时间改成了20s，因为SQL语句有用很多左连接并用show variables like "tables_size"查看了临时表的空间大小，发现临时表只有16m 我就改成了1个G在去跑了一下发现CPU只是降了10%左右，nmom上监控的数据还是mysql占的CPU很大，然后运行的时候用top命令监控，发现有的时候有很多mysql进程同时运行（因为没有设置连接池）我就用命令查看了下mysql的最大连接数，因为SQL语句的执行速度还是挺快的，所以就把mysql的连接数调小到50，再去跑了一遍发现CPU降到了40%左右并且其他的性能指标也都还不错。最后把聚合报告的数据以及nmom的数据整理成性能报告给老大。其实做接口性能主要就是用排除法一个一个去排除，发现性能问题就要先解决了这个性能问题在压测，不然其他的性能问题也可能是这个性能问题导致的。基本上就是观察各个性能指标都在范围之内就差不多了。
19,你是怎么使用monkey测试稳定性的？
Monkey这个工具是针对Andriod系统来测试稳定性。一般我们是在功能测试完成的情况下，再用monkey对其稳定性进行测试，主要是晚上下班前进行测试。一般我们主要是检查软件长时间运行，看看会不会出现崩溃（crash）、超时无响应（anr）、异常（exception）。原则上是monkey的工具，可实际上就是一条命令。一般情况下我们都是在下班时运行，我们一般设置的事件数是100W次，大概八小时这样，一般间隔时间25毫秒，等到第二天早上去看结果。然后分析monkey运行的日志看是否包含 crash，anr，exception，找出问题，问题给开发去修复解决。提交bug，等开发修复完成之后我们会根据上次运行的种子数 -s ，进行回归测试。执行命令例如：
命令中包含几个点：事件数、打印日志级别（-v -v -v）、忽略机制、指定事件比例（--pct-touch 50）以及设置间隔事件（--throttle 25）(25表示25毫秒)。
adb shell monkey -p app安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 执行事件次数 >保存在pc的路径\日志名.log
回归测试命令：adb shell monkey -p app 安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v -s 种子数 执行事件次数 >保存在pc的路径\日志名.log
20,adb命令用到哪些？
Adb命令是监控手机资源在Android里使用
命令如下：
查看设备号 adb devices
安装 adb -s 设备号 install 包名
卸载软件 adb -s 设备名 uninstall 软件包名(以com开始的例如：com.qqmusic)
查看安装的软件包名 adb shell pm list package 查看所有的手机软件包名
查看第三方的手机软件包名 adb shell pm list -3
查看手机当前使用的内存情况，各个线程的内存占用情况 adb shell dumpsys meminfo
查看手机的电池信息 adb shell dumpsys batteryinfo
查看系统资源状态 adb shell top
手机日志 adb logcat 产看手机日志
adb logcat -c 清除手机日志
adb logcat -v time 显示时间
将日志导入一个文件中 adb logcat > mobile.log
将手机的图片导入到PC端 adb pull 手机文件的路径 电脑路径
例如：Adb pull /storage/emulated/legacy/Pictures/Screenshots/Screenshot_2019-02-21-17-48-55.png F:\
进入手机linux系统 adb shell monkey -p app安装包名 --throttle 25 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v 执行事件次数 >保存在pc的路径\日志名.log
设置时间的比率 --pct-touch(percent touch)
adb shell monkey -p app 安装包名 --throttle 25 --pct-touch 50 --ignore-crashes --ignore-timeouts --ignore-security-exceptions --ignore-native-crashes --monitor-native-crashes -v -v -v -s 种子数 执行事件次数 >保存在pc的路径\日志名.log(一般不设置，都选择默认的事件处理事项)
adb 命令录屏：
adb shell screenrecord --time-limit 10 /sdcard/demo.mp4 （10表示录制10秒，默认是180s）
Aa
你好，我叫某某，祖籍江西，目前定居在广东佛山。大学本科毕业。我是从2016年开始从事软件测试工作，到现在也有三年时间了。web端项目和app项目都做过。前一年主要做一些功能测试和接口测试，后两年主要做接口自动化测试和功能自动化测试和性能测试，包括app的性能测试。对数据库，linux都比较熟悉。我平时喜欢运动，读书的时候一直是校足球对队的。今天来贵公司是想面试测试工程师一职，以后也会长期在广州佛山这一带发展。
23.web测试中，如何判断是前端的bug还是后端的bug呢？
通常可以利用抓包工具来进行分析。可以从三个方面进行分析：请求接口，传参数，响应。
1.请求接口url是否正确,如果请求的接口url错误，为前端的bug
2.传参是否正确,如果传参不正确，为前端的bug
3.请求接口url和传参都正确，查看响应是否正确,如果响应内容不正确，为后端bug
4.也可以在浏览器控制台输入js代码调试进行分析.
24. App是怎么测试？
答：一般我们从界面，功能，兼容性，稳定性，交互性，安全性，易用性，性能，网络，异常情况，权限，等方面进行测试。
界面测试：主要测试界面展示是否与UI设计的原图一致，测试手机屏幕大小及分辨率对界面的影响
功能测试： 除安装，卸载，更新 和web端差不多，都需要考虑人员与权限，场景与步骤，异常场景，用户补充场景，关联模块，但是app测试功能，在相关功能模块需要添加一项，就是web界面的变化，如你在手机上投资了一笔钱，你需要在web端查看投资情况是否一致。
兼容性测试：就是用不同的厂商，型号，安卓系统版本进行测试， 【华为 mate10 Android 8.0 三星note5 Android6.0.1三星s6 Android6.0.1 红米1s Android5.1 小米5 Android7.0 乐视2 Android6.0ios 机型，iphone 5 ios 8.4.1 iphone 6splus ios 10.3.2，iphone x ios 11.0】 也可以借助阿里云测试辅助
稳定性测试：一般我们是功能测试完成情况下，再进行稳定性测试，一般主要是检查软件长时间运行，会不会出现崩溃，crash，anr 超时不响应，exception异常， 原来我们测试稳定性是用的monkey工具，其实就是一条命令，一般我们再下班的时候运行，一般事件数100W次，大概10个小时左右，一般间隔是25毫秒，第二天早上看结果， 出现了bug，我们会提交bug，等开发修复完成，以后，我们会根据 上次运行种子数 -s ，进行回归测试。
交互性测试：跟手机固有的功能模块，进行交互使用，像音量的调节，锁屏，旋转，返回键，主菜单键，截图，闹钟，待机，插拔数据线，耳机，wifi、蓝牙，电话，短信，低电量，看功能是否正常使用，界面是否为原来界面，输入数据是否保存，还有跟其他app进行交互性测试，一般 跟应用排行榜前100 是否可以同时使用
安生性测试：主要考虑的是sql语句的注入，xss脚本的攻击，数据加密还有就是权限测试
sql语句的注入和xss脚本的攻击的检查因为手动操作比较麻烦与繁琐，app我们一般是通过腾讯优测来进行测试的，web界面我们一般是通过appscan进行扫描测试的，把扫描结果发给开发进行修复的数据加密主要是考虑在前端输入的时候进行加密，传输过程中进行加密，数据库进行加密，在服务日志文件中也是需要加密的
易用性：主要是把控用户的体验问题，驾驭需求以外，用户使用是否方便，好用
性能测试：我们通常使用Emmagee去测试APP的性能，去监测cpu、内存、fps等性能指标
网络测试 ：分 2,3,4G，移动，联通，电信，wifi 网络之间组合 网络之间的切换，还弱网，用fiddler 工具进行模拟
权限： 1，前台不能访问后台 2，不能通过url连接支架访问 3，后台不能直接进入界面
异常测试 手机 ：关机，重启，网络中文 服务器卡死 服务器重启
25.h5界面是怎么测试的？
答：我们主要测试的是UI，功能，网络，兼容性,，易用性，安全性测试
UI测试的话，我们一般检查界面的布局展示是不是和需求说明一致。 还有测试不同的屏幕大小，不同的分辨率对界面展示的影响。功能测试的话，和web的功能测试差不多，主要是考虑操的功作权限，模块能，用户场景等方面，兼容性测试主要考虑的是浏览器不同版本的兼容，屏幕大小跟分辨率，网络测试我们一般是考虑在不同网络情况下，h5界面能否正常运行，比如说网络之间的切换，和网络之间组合，外景和弱网环境下的使用情况
18.安全测试怎么做的？
答：安全性测试，我们主要考虑能否对系统进行sql注入，xss脚本攻击。以及检查关键数据是否加密，同时进行权限测试。而且我们还会通过fiddler设置断点，看能否篡改数据成功。sql语句的注入和xss脚本的攻击的检查因为手动操作比较麻烦与繁琐，app我们一般是通过腾讯wetest来进行测试的，web界面我们一般是通过appscan进行扫描测试的，把扫描报告给开发进行修复
数据加密主要是考虑在前端输入的时候是否进行加密，传输过程中是否进行加密，
数据库是否进行加密，在服务器日志文件中是否加密的
权限牵扯到前台和后台操作，比如前台界面不能出现后台界面的入口，不能通过直接在浏览器输入后台url地址进入，不能同过后退按钮回退到后台操作界面。
26.fiddler抓包用来做什么？
答：我们原来主要用fiddler抓包，来抓取传输过程中的数据进行对比，查看请求参数是否正确，一般是app测试，用得比较多,
另外我们对问题进行定位，分析是前端还是后端问题时，可以根据抓包中返回的状态码以及请求数据和返回的数据，进行判断
也可以通过抓包，查看数据传输过程中是否进行加密，,还可以通过设置断点来拦截，进行数据的篡改，SQL注入，来进行安全性测试
还有弱网测试模拟网络
27.网络协议了解多少？
答：原来我们用得比较多的协议是http和https,以及tcp协议
http和https都是超文本协议，浏览器发送数据请求基本用的都是他们，不同的是https在http的基础上增加了ssl加密协议，http的默认端口是80,https的默认端口是443，https收费，http免费
tcp协议的话，作用在传输层，在发送请求前，会有三次握手。是面向连接的协议，传输过程比较可靠
28.WEB测试和APP测试的区别。
他们在功能上测试是一样的。因为功能是基础，功能没过关其他的扯淡。web是B/S架构，app是C/S架构，所以web端的前端和后代代码都在服务器上，web端是不需要升级的，就是展示它请求返回来的数据。而app的前端代码是在手机上，需要安装，更新，后台代码是在服务器上。所以app测试相比web测试更加注重专项测试。比如app的安装，卸载，升级或者更新，还有兼容性测试，性能，交互性，稳定性，弱网测试。拿兼容性来说，web端主要测试五大浏览器的兼容性和操作系统的兼容性，而app的安卓测试得测试不同的机型测试，华为，小米，vivo等，还有不同的版本，比如华为的就有7.0,8.0,9.0等版本。也要考虑屏幕的大小，分辨率等。
29.app怎么测试。
当我拿到需求后就要进行需求分析，提炼测试点，设计测试用例，并进行评审。然后如果没有搭建测试环境的话就要搭建测试环境。开发人员把apk把发给我，我就先做一个冒烟测试。不通过就打回，通过了再进行执行测试用例。先做功能测试，保证每一个功能都能过关。然后再做一些专项测试。主要的专项测试有安装，卸载，升级，交互性，稳定性，弱网，兼容性，性能测试。
30. 你用过哪些adb命令
测试前如果没有搭建环境要我们自己搭建的话，会用adb install 安装包，卸载的话用adb uninstall 包名。这个包名可以通过adb -s 设备ID uninstall com.taobao.taobao(包名)去查询到。平常用到最多的是adb devices，查到当前连接的设备，以防掉线了执行命令会报错。找到bug时，我会去分析查找bug的原因，要去查日志的话会用到adb logcat -d，或者用adb logcat <tag>:I *:S,通过信息错误等级去查找。查找到的结果为了方便查看我会导出到windows里查看会用adb logcat -d > 路径\文件名。
31.app兼容性你是怎么测的？
兼容性测试主要测试app在不同机型，不同手机系统版本上能不能正常启动，运行。不同屏幕分辨率和屏幕大小能不能正常显示，会不会出现拉伸，显示不全的情况。以前我们公司测试兼容性主要是通过真机和云测相结合的方法做测试的。公司会我们提供七八台真机，一般都是市场上主流的几款机型，比如华为P10,华为荣耀10，vivo x20，vivo y85，小米8等。我先用公司提供的真机一台一台测试。其他没有真机的手机就在云测上测试，生成测试报告，进行分析。云测上如果发现某些有问题的手机型号，就会拿真机进行再次测试，这里一般公司会租用手机，降低成本。
32.app性能你是怎么测的？
APP测试主要有了解性能需求，指定测试计划，编写测试用例，和准备测试数据。执行测试用例，提交bug，编写测试报告，这几个流程。
App的性能测试主要从两个方面入手，一个是app占用手机的性能，一个是app对服务器的性能测试。
手机性能性能测试主要测的是cpu占用率，内存占用率，耗电量，流量以及流畅度。除此之外也要重点关注app的安装，启动，卸载时间，加载页面的响应时间，以及是否有内存泄漏的情况。测试之前，一般se会给我们提供指标。如果没有给的话，我会通过分析竞品，比如要测试京东，我会拿淘宝作为竞品，所测的京东性能要强于淘宝的才行。如果app之前有版本的话，可以拿上一个版本的数据作为对比对象，所测的性能要优于上一个版本的。通常来说，cpu平均占用率不超过10%，内存占用率不超过100M，平均安装时间50S，平均启动时间4S等，这都是一些比较普遍的app的性能，也可以作为一种参考。
服务器性能是用jmeter进行测试。主要看并发数，响应时间，事务通过率，以及资源占用情况。首先分业务，这可以通过组内评审得出，然后准备数据，了解并发数。并发数可以通过需求了解，没有的话可以跟客户交谈总结，或者分析竞品得出。得到了并发数后，按各个场景的使用比例进行分配并发数。先测试单一场景，并发数在原来的基础上增加百分之十到二十，用linux监控资源，找出系统中隐藏的问题，比如通过查看内存前后对比看看有没有内存泄漏，通过查看日志内存溢出（OutOfMemoryError，StackOverflowError），死锁。必要时要考虑二八原则，测试一个场景一般15-30分钟。在测试混合场景，就是各个不同场景，一起压测，找出未满足的需求。测试时间一般为30-60分钟。然后再进行一个负载测试，找出系统所能承受的最大的并发数。然后把所有的报告汇总，进行分析，最后写一个性能测试报告。
33.你们是怎么做接口自动化的
原来我们接口 主要是用的python+requests 去运行的
首先，开发会给我们一个接口文档，拿到接口文档后，我们就进行测试点的分析，考虑正确场景，条件的组合，异常场景，多一个参数，少一个参数，参数为空的情况，比如原来我们 做一个生成订单的接口，考虑正常场景，异常场景正常场景就是不同的 订单类型，订单金额，能不能申请订单，每个参数的格式类型的校验，异常场景，多一个参数，少一个必填参数的时候，还有参数为空的情况，原来我们是用python+request去做的接口。
首先，导入request包。建立一个 headers，保存请求头的信息，因为订单请求方式 是post类型，数据格式是 form表单格式，我们把数据保存到data的字典里面，这个时候我们还需求 登录的cookie值跟登录后产生的token值，我们会去通过动态关联去获取 登录的token跟cookies，cookies值的话，我们是直接调用登录返回的 cookies，token值的时候，我能是通过导入re模块，通过正则表达式去提取当参数，headers，cookies输入完成以后，我们就发送请求，打印返回结果，检查返回结果是否跟我们测试用例一致当运行其他测试用例时，我们去修改data里面的参数就行，在发送请求，有的请求时https协议的时候，我们发送请求的时候 还会verify=false 去忽略掉证书验证对应多个接口调用 cookies 我们会用到session去保存，接口发现比较多的问题，就是格式校验这块。比如说我们提交订单，订单数据没有显示，订单格式也没有显示，输入字母，汉字都可以订单类型 为空，也会生成订单成功，我觉得接口可以发现接口更多的bug，还可以提早进行测试，提高测试的质量。
原来我们接口自动化是用 python+request+unittest执行。接口自动化其实主要就是接口测试的基础上填加了断言，参数化，动态关联，做接口自动化之前，我们也会划分模块，报告，公共的模块，测试数据，测试报告，主要的目的是为了方便后期的维护。测试数据，一般原来我们就是用的接口测试用例，公共的模块，主要是里面的一些公共的操作，比如说用例excel数据的读取，数据库的连接，还有我们封装的每个接口请求，断言的主要是 获取访问接口的值判断，用的是assert，参数化主要用的比较多是 excel表格，就是测试用例数据，还有需要调用登录后的cookies跟token的时候，我们就会用到关联，比如说原来我们写的一个 申请借款的接口吧。首先我们会编写测试用例，把每个用例数据保存到excel中再建立一个 申请借款的模块，这个时候我们去调用申请借款的功能模块，里面的参数我们是保存在excel表格中，我们建立发送请求，通过参数化，去读写excel表格中的数据，获取到返回的数据，通过assert 去对应返回的数据跟用例中异常的数据，这个时候也会做数据库断言，去连接数据库去查询数据库中时候存在查询，如果是返回结果是json数据格式，我们还会转化下格式后，再去断言，这个申请借款模块，也会用到登录的cookie值token，我们先建立一个登录的请求，提取返回的cookie值token，excel表格多个用例，我们就用到循环去运行，读取excel中用例总的条数，去循环运行，这里要注意的是，就是excel表格数据时是str我们要eval转化成字典格式，把每个接口封装好以后，我们就会调用unittest框架去运行所有test文件的测试用例，如果只是执行部分用例，也可以通过unittest框架来指定接口自动化，我个人觉得，性价比是比较高的，实现起来简单、维护成本低，容易提高覆盖率等特点。接口是稳定的，最多是增加一个字段或者新增接口之类的低成本，有了相对的稳定性，不需要大量重新编写脚本，只需要基础维护包括用例的扩充就可以了，执行的快，反馈的速度快
35.电商的库存逻辑怎么测。比如客户下订单，库存减少，规定时间内未支付定单就取消，库存又加回来
我会先测一下界面，比如界面的排版是否美观，有没有错别字，颜色适不适合等。然后再测试一下功能。提交订单页面，我会测试购买商品数量，自己输入的边界值和点击加就加或者减少修改数量。不选择数量会不会有默认数量。不选择商品类型以及选择多个商品类型。然后测试正确提交订单后，看库存是否有减少相应的数量。再测试规定时间的边界值，比如规定时间是1个小时，那1个小时内完成支付，库存有没有变化，61分钟还是否能去支付，订单有没有关闭。接着会测试一下1个小时内取消订单，单库存有没有增加相应的数量，以及1小时内没有去支付，系统自动取消订单，库存有没有加上相应的数量。再测安全性，涉及到支付，用finddler工具抓包拦截数据，看能否修改参数，再发送请求支付成功。测逻辑的话大概就这些。
36.平常你是怎么测试接口的？
通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，
商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
接口安全：
1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
性能测试
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别
接口测试经常遇到的bug和问题，如下：
（1）传入参数处理不当，导致程序crash；
（2）类型溢出，导致数据读出和写入不一致；
（3）因对象权限未进行校验，可以访问其他用户敏感信息；
（4）状态处理不当，导致逻辑出现错乱；
（5）逻辑校验不完善，可利用漏洞获取非正当利益等。
37，tcp，udp的区别
38.三次握手，四次挥手
39.http跟https的区别
1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。
2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。
4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
4.osi模型和tcp模型
osi七层网络模型
（1）参考模型：只是提供给生产商或者软件开发商参考的模型
（2）开发系统互联
（3）有七层
应用层、表示层、会话层、传输层、网络层、数据链路层、物理层
TCP模型
有四层：应用层（telnet、sftp、http）、传输层（TCP UDP）、网络层、数据链路层
GET请求在URL中传送的参数是有长度限制的，而POST没有。
GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。GET参数通过URL传递，POST放在Request body中。
对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；
而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok
40.cookie跟session的区别
在网站中，http请求是无状态的。也就是说即使第一次和服务器连接后并且登录成功后，第二次请求服务器依然不能知道当前请求是哪个用户。cookie的出现就是为了解决这个问题，第一次登录后服务器返回一些数据（cookie）给浏览器，然后浏览器保存在本地，当该用户发送第二次请求的时候，就会自动的把上次请求存储的cookie数据自动的携带给服务器，服务器通过浏览器携带的数据就能判断当前用户是哪个了。cookie存储的数据量有限，不同的浏览器有不同的存储大小，但一般不超过4KB。因此使用cookie只能存储一些小量的数据。
（2）session:
session和cookie的作用有点类似，都是为了存储用户相关的信息。不同的是，cookie是存储在本地浏览器，而session存储在服务器。存储在服务器的数据会更加的安全，不容易被窃取。但存储在服务器也有一定的弊端，就是会占用服务器的资源，但现在服务器已经发展至今，一些session信息还是绰绰有余的。
41.http协议包含哪些内容
（1）请求信息
1.请求行：请求方式、请求地址、http版本1.1
2.请求头：
HTTP消息报头包括普通报头、请求报头、响应报头、实体报头
Cache-Control??：no-cache 缓存
Connection ： close/keep-alive 是否关闭或者保持连接
Accept-Charset ：iso-8859-1 字符集
Accept-Encoding:gzip.deflate 编码格式
Accept-Language:zh-cn 语言
Authorization：服务器授权验证
Host ：主机
User-Agent ：浏览器配置
Location ：重定向
Server ：服务器版本信息
Content-Encoding ： 实体报头的编码格式
- 请求正文
data
（2）响应信息
1.状态行：http版本 、 状态码、状态信息
2.响应头：跟请求头一样
3.响应正文：
42，http常见的状态码有哪些？
常见状态码：400、404、200、500、302、501、504
101服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议。
102 (代表处理将被继续执行) 由WebDAV（RFC 2518）扩展的状态码，代表处理将被继续执行。
2开头 这一类型的状态码，代表请求已成功被服务器接收、理解、并接受。
200 （成功） 服务器已成功处理了请求。 通常，这表示服务器提供了请求的网页。
201 （已创建） 请求成功并且服务器创建了新的资源。
202 （已接受） 服务器已接受请求，但尚未处理。
203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。
204 （无内容） 服务器成功处理了请求，但没有返回任何内容。
205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。
206 （部分内容） 服务器成功处理了部分 GET 请求。
207 (代表之后的消息体将是一个XML消息)，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
3开头 （请求被重定向）表示要完成请求，需要进一步操作。 通常，这些状态代码用来重定向。
300 （多种选择） 针对请求，服务器可执行多种操作。 服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
301 （永久移动） 请求的网页已永久移动到新位置。 服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
302 （临时移动） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
303 （查看其他位置） 请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
304 （未修改）自从上次请求后，请求的网页未修改过。 服务器返回此响应时，不会返回网页内容。
305 （使用代理） 请求者只能使用代理访问请求的网页。 如果服务器返回此响应，还表示请求者应使用代理。
307 （临时重定向） 服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
4开头 （请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。
400 （错误请求） 服务器不理解请求的语法。
401 （未授权） 请求要求身份验证。 对于需要登录的网页，服务器可能返回此响应。
403 （禁止） 服务器拒绝请求。
404 （未找到） 服务器找不到请求的网页。
405 （方法禁用） 禁用请求中指定的方法。
406 （不接受） 无法使用请求的内容特性响应请求的网页。
407 （需要代理授权） 此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
408 （请求超时） 服务器等候请求时发生超时。
409 （冲突） 服务器在完成请求时发生冲突。 服务器必须在响应中包含有关冲突的信息。
410 （已删除） 如果请求的资源已永久删除，服务器就会返回此响应。
411 （需要有效长度） 服务器不接受不含有效内容长度标头字段的请求。
412 （未满足前提条件） 服务器未满足请求者在请求中设置的其中一个前提条件。
413 （请求实体过大） 服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
414 （请求的 URI 过长） 请求的 URI（通常为网址）过长，服务器无法处理。
415 （不支持的媒体类型） 请求的格式不受请求页面的支持。
416 （请求范围不符合要求） 如果页面无法提供请求的范围，则服务器会返回此状态代码。
417 （未满足期望值） 服务器未满足"期望"请求标头字段的要求。
5开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。
这些错误可能是服务器本身的错误，而不是请求出错。
500 （服务器内部错误） 服务器遇到错误，无法完成请求。
501 （尚未实施） 服务器不具备完成请求的功能。 例如，服务器无法识别请求方法时可能会返回此代码。
502 （错误网关） 服务器作为网关或代理，从上游服务器收到无效响应。(比如：nginx里设置了反向代理，自己代理给自己，形成了死循环，造成大量的访问日志，每秒上万)
503 （服务不可用） 服务器目前无法使用（由于超载或停机维护）。 通常，这只是暂时状态。
504 （网关超时） 服务器作为网关或代理，但是没有及时从上游服务器收到请求。
505 （HTTP 版本不受支持） 服务器不支持请求中所用的 HTTP 协议版本
43你想问什么问题？
1，公司现在做什么项目
2，公司目前做哪方面测试
3，公司这边测试人员分配比例
4，进入公司，我这边大概的工作安排
5，公司怎么后续发现机会还有培养
44请写出你们公司的测试流程，你是怎么保证测试质量的
澄清需求（需求分析）-测试计划-测试需求分析-测试用例-测试执行-测试报告-测试总结
（1）开始产品那边会发需求给我们了解2天，再开需求澄清会议，会议中提出理解需求的问题，产品这边解答，包含需求的合理性还有需求的可测性等
（2）了解需求后，测试组这边会编写一个测试计划，安排整个测试的进度与测试的工作分工与测试的方法与策略,功能模块，测试策略（每个阶段采用的测试方法），测试交付件，测试进度跟安排，测试资源准备 半天-一天
（3）测试计划以后，每个测试人员拿到自己负责的功能模块，进行测试的需求分析，编写出测试点，编写后，会整合一起评审测试点(组内评审).文档分析，测试点
（4）评审修改完的测试点以后，我们测试人员会根据测试点与需求来编写测试用例，编写完测试用例会做一个整合，进行评审（组内评审-开发评审（你说的功能跟我做的功能是否一致）-产品评审（会议评审）-你对需求理解是否跟我原来描述的是否一致）
（5）等开发完成后会进入到正式测试执行，执行之前会先做一个冒烟测试，再进行系统测试
（6）系统测试过程中，每轮测试完成，都会形成一个测试报告，也需要做回归测试，当多轮测试中，达到上线的标准后，测试报告会认为测试通过，由项目组与产品决定时间上线
主要统计每一轮测试，用例执行情况，bug执行情况，修复情况，测试结论（判断是否可以上线）
（6）上线后会一个星期后对项目做一个测试总结，本次项目中的测试不足与后续的改进意见
上线一个星期，bug爆发期
如何保证质量
（1）需求要吃透，多问，多去了解
（2）严格按照测试流程去执行
（3）高质量用例：
引入合适的测试用例设计方法
引入测试用例评审机制
（4）良好的测试执行
要求用例执行率达到100%，多次的测试轮次
引入测试工具，让测试可以做得更深入（通过查看日志，查数据库）
（5）良好的缺陷管理
良好的缺陷写作和过Bug机制（缺陷修复效率可以提高，修复率也更高）
引入合适的缺陷管理工具和缺陷管理流程
（6）良好的测试流程
引入更合适的测试流程和测试方法
采用更多的非功能测试，不要忽略非功能测试
（7）多评审，完善大家的测试思维点
（8）做好人员备份机制
交叉测试、人员备份，多个人，不同测试考虑点
（9）需求要吃透，多问，多去了解
45.请写出以下测试点
Ui界面
1，验证：界面布局合理
功能测试
1，不同员工的账号登录，是否登录成功（等价类）
2，离职的员工，是否登录成功
3，注销的员工，是否登录成功
登录过程（判定表补充）
1，正确的用户名，正确的密码，错误的验证码
2，错误的用户名，错误的密码，正确的验证码
操作的步骤
1,记住密码登录，下次登录，多次登录情况
2,不记住密码，下次登录，多次登录情况
3,第一次不记住密码，后期记住密码，再登录情况
4,记住密码，7天后再登录情况
验证码校验
1，验证码错误，点击验证码，是否变化
2，变化后的验证码，输入原验证码情况
注册
1，点击注册是否跳转注册界面
2, 多次点击注册是否会跳转注册界面
异常情况
1, 用户名中包含空格
2，用户名中首尾包含空格
3，用户名中添加多的值比如说用户名为 3232 登录时输入32321的情况
4，用户名中存在大小写情况
6，密码中包含空格
7，密码中包含多输入情况
8，密码长度过长的情况
9，用户名，员工删除
关联模块
1，登录后，用户名是否会显示
2，登录后，用户名是否有登录记录
3，登录后界面跳转哪个界面
添加场景
1，同一个用户单机多次登录情况
2，同一个用户不同机型登录情况
兼容性：
1，不同的浏览器上界面展示是否合理，是否能正确登录
异常场景
1，员工表锁的情况
安全测试
1，输入的密码，是否显示*号
2，输入的密码，传输过程中是否加密
3，密码在数据库中是否加密保存
4，大量用户登录时，是否达到性能指标
46.请写出项目一中核心模块（erp、fangwe）有哪些，请写出模块的业务流程
（1）借款流程，还款流程，资金流向流程，注册流程，借款流程
核心业务流程：注册—> 登录-> 借款 - > 后台初审 -> 后台复审 -> 公布、投标 -> 满标 -> 后台放款->借款人提现->借款人每个月还款-> 投资人每个月收取收益。
- 购货流程、销货流程、仓库管理、财务报表
核心业务流程：配置中注册新用户->登录->购货->入库->销货->生成财务报表
- 请问你们项目怎么上线的，你们怎么安排的
（1）上线的时间一般会选择在周六周日，或者晚上，用户使用量比较少的时间
（2）一般开发与测试（部分到场）到场，做上线支撑
步骤
1，开发人员会准备生产环境的代码包，运维人员在上线时间替换掉生产环境的包
2，包替换后，需要测试与用户进行产品测试，测试主体的功能是否正常使用
1，能正常使用
测试人员删除到测试数据，测试结束，上线结束
2，不能正常使用
开发人员需要修改bug，测试人员测试，开发人员再次发包
验证是否正常使用，回顾原来的步骤
3，到时间点，如果上线没有问题，就表示上线成功
4，部分问题，需要产品，用户决定是否上线
5，到时间点，不能上线，延迟上线，版本回滚（回到原来老的版本）
47.你们版本多久一个迭代，每个迭代测试策略
（1）一般半个月或者一个月上线一次；后期迭代大部分是敏捷开发测试；开发一 部分，测试一部分，上线之前把原有的功能测试一遍，开发一部分，测试一部分的 整体思路如下：
在第一轮测试中，针对系统已经完成的新模块功能，执行所有的测试，用例优先级高的要先测试，bug上午发现的，下午修改完成，回归通过，下午发现的bug，第二天上午需要回归通过,且第一轮测试需要把所有用例执行完成，（如果有自动化，那么第一轮需要用自动化覆盖所有用例，在测试环境上执行，且自动化通过率至少90%以上）
在第二轮测试中，将上轮测试未通过的以及补充的测试用例重新测试，确认所有的缺陷都已经改正，上一轮bug最多的功能再进行测试，第二轮需要把自动化重新跑一遍，在测试环境上执行，且通过率为100%
48.你们bug怎么管理的，怎么提交一个好的bug
（1）需要把发现的bug提交到禅道管理工具当中，并且邮件通知到开发人员，去修复bug。
（2）每半天跟进一下bug的修改情况，如果bug还没有修复，督促开发人员及时修复。
（3）开发人员修改完bug，测试人员要对bug进行回归测试，并闭环。
49.编写用例如果只给4项，你保留那4项，怎么写好一个用例
（1）八大要素：用例编号 测试项目 测试标题 用例级别 预置条件 测试步骤 输入数据 预期结果
（2）保留四项：输入数据 测试标题 操作步骤 预期结果
输入数据有代表性；
测试标题描述准确；
测试步骤要详细清晰；
预期结果要准确；
50.测试报告有哪些重点内容
（1）项目背景和目的
（2）测试用例设计
（3）测试环境
（4）测试过程用到的工具
（5）测试范围
（6）测试用例执行情况
（7）测试缺陷分析和总结
（8）测试结果
51.测试计划的作用，测试计划有哪些重点内容
（1）目的和范围
（2）规程
（3）测试方案和方法
（4）测试的准入和准出
（5）测试计划(流程、时间安排、对应人员)
（6）测试的环境配置和人员安排
（7）交付件
52.给你一个需求，5天时间上线，你怎么安排
1.了解需求会议 0.5天
2.编写测试计划 0.5天
3.测试点 0.5
4.编写测试用例 1天
5.搭建测试环境 0.2天
6.执行测试 1天
7.提交bug、回归测试、关闭bug
8.编写测试报告 0.5天
9.验收测试 0.5天
10.产品上线 0.3天
53.做了这么久的测试，你有什么心得
1，了解需求，吃透需求
2，测试用例完整度，考虑的测试点要全面-细心
3 ，测试执行，耐心，沟通能力比较好
4，学习能力强，总结能力强
54.你测试的时候发现哪些经典bug，你描述出来。（erp 和 方维）
ERP bug:
（1）在search条件查找，在条件中输入“%”，系统没有对%进行转义和限制，导致查询出所有的记录
（2）在新增客户类别中，类别输入框对长度没有要求，检查了数据，发现列别名称的长度为50，最多只能保存50位的长度。
方维bug：
- 管理费计算错误，管理费偏高
- 上传附件，大于2G时，系统会崩溃
55.你提交的bug开发人员不认可，如何解决?
首先，在提交缺陷的时候，需要自己确认认定缺陷的依据是否正确，缺陷表述是否正确，然后，当开发人员不认可的时候，我会跟他沟通不认可的原因是什么，是不是我需求理解错了，表述错了，还是需求、设计变更了，还是其他原因，找到他不认可的原因就好解决了，如果开发人员只是毫无理由的不认可，拒绝，那还是可以可能需要我的经理去处理了。
56.怎么样编写好测试用例？
（1）写测试用例一定要精简、清晰
（2）测试用例一定要覆盖全面
（3）测试标题要简单、清晰，测试用例输入数据需要明确，操作步骤要清晰，预期结果要明确。
57.测试工作完成后，你发现一个bug，该怎么办？
（1）及时的帮忙定位bug，分析bug，找出引发bug的原因，让开发人员帮忙修复。
（2）采取一些bug的解决方案，避免造成重大损失。
（3）总结bug的原因，后续制定有效的测试计划，与相关人员review测试用例，并改进，掌握好测试进度，避免后续在发生这种事情。
（1）任何情况下都要使用边界值
（2）用等价类补充测试用例
（3）错误推测法追加一些测试用例
（4）多个条件的组合情况，用判定表或者因果图
（5）业务场景比较清晰的情况下，可以使用流程分析法
（6）检查是否覆盖所有场景，如果没有覆盖，需要从新补充测试用例
（7）异常分析法写测试用例
锁表
关闭数据库
7天*60条=420条
7天*30条=210条
12 * 420条 = 5000条
2500条
60.linux在测试工具中有没有用到过，具体哪些场景用到？
Ｅｘｃｅｐｔｉｏｎ异常
Ｅｒｒｏｒ错误
（从其他平台导入代码包到我们内部系统，发现少了一条数据。我们通过tail -200 tail -500查看最新日志，去查看导入数据时的日志，查看内容记录是有数据导入的，可是数据库里面没有保存对应的数据，所以无法识别，就报错。定位原因是因为数据库没有导入到这条数据，后开开发把数据插入到数据库就把问题解决了）
端口号：netstat -anp
tail -f 查看动态日志
Ps-ef 显示终端机下所有进程
Top [-] 时间秒 时时监控程序执行状况
Free -m 查看内存
查看日志：cat more less head tail tac
（1）搭建测试环境的时候我们在是在linux下进行的，在线安装apache，php以及mysql；
（2）在测试执行的过程中，我们发现的bug，有时候需要定位bug，协助开发修复bug,需要用linux去查看日志，通过查看日志的后面多少行或者前面多少行定位bug；
- 后台程序运行久了会对系统造成卡顿等诸多隐患。所以我们都会通过linux命令查看系统资源并且定期清理下缓存，保证我们的系统能正常运行和使用；
61.数据库在测试工作有没有用到过，具体在什么场景下用到
（1）在模拟用户场景时需要用到大量的数据，这时就需要我们到数据库中制造大量的数据出来；
- 测试用例执行后，我们需要通过sql语句查找数据库对应的表，看看数据库信息跟我们执行的结果是否一致；
- 我们在测试执行时需要输入数据或者修改数据，我们需要到数据库查看有没有相关记录保存，保存的数据跟我们输入或者修改的记录是否一致；（比如说注册，当注册成功后，数据库有没有这个注册用户的信息保存）
- 数据表的备份
（1）从开发人员那边获取到一个接口需求文件，并对接口需求文件进行分析（内容描述是否清晰和准确），
如果发现接口需求文件中有不清晰和不明的点，要找开发人员确认。有错误的点要找开发人员修改。
（2）编写手工测试用例
（3）把手工的测试用例转换自动化接口脚本
（4）找开发人员部署接口测试环境
（5）执行接口自动化脚本，在执行的过程中，让开发人员也到参与，把执行过程中的错误，让开发人员分析并修改。
（6）没有及时定位出来的bug，可以提交到禅道管理工具中继续跟进
（7）回归测试接口
（8）关闭bug
（1）之前开发出来的接口，在后续的版本中继续使用
（2）版本要上线，我可以一次性跑一下所有的集成接口，查看上线是否存在风险
（3）旧的接口有时候因为需求改变，要测试人员重新进行为接口。把旧的接口修改成符合新需求的接口
（4）一个中小项目中涉及到的接口大概有多少呢？？？ 100个左右接口
（5）一般情况下，这些接口，大概要测试多久？？？ 一个月可以写完所有的接口自动化脚本。 （存在一个不太确定，需要和开发或者客户确认）
- 写完接口后 ，要做什么？？？ 持续集成， 可能也会新增一些新的接口
（1）认证和授权
用户名和密码
手机验证
实名认证
安全问题
安全控件
邮箱认证
人脸识别
指纹识别
语音认证
等等
注意：系统都是多因素认证，认证越多，客户体验越差。
（2）安全性测试
用户只能访问被授权的模块和功能。
权限的控制只能由系统管理员来维护，其它用户不能做任何修改。
权限控制要细，最好细到增删查改这种功能上，并且不同模块有不同的权限。
登录失败的错误提示消息不应该明确告知是用户名不存在还是密码错误，避免客户端使用暴力破解方式。
连接 N 次登录失败，应该暂停用户登录。并将该信息发送给系统管理员，并告知客户端的IP 地址。举例：网银登陆3次锁定2小时。
必须要登录成功后才能访问的页面中都需要用Session 对客户端进行验证，确认当前Session 已经登录过，否则访问该页面时应该自动跳转到登录页面。避免客户端直接在
登录时应该使用图片验证码，避免机器人暴力工具。
目前图片验证码是被证明最可靠的防攻击手段之一。
URL修改访问的实例
（3）安全性测试-文件上传漏洞
上传文件类型，不能是一些可执行的文件 （可执行文件可能带有病毒）
上传文件大小要有要求。上传太大的文件占用服务器的宽带。
（4）缓存溢出漏洞
（5）sql注入的脚本大全
https://www.jb51.net/hack/575622.html
直接用sql注入工具测试
（6）XSS攻击
如下是：xss攻击的脚本
<br />
<script type="text/javascript">
function change(){
window.location.href="http://localhost:81/fanwe/index.php?ctl=user&act=loginhttp://localhost:81/fanwe/index.php?ctl=user&act=login";
}
</script>
<br />
<input type="button" οnclick="change()" value="点击一下，你就知道" />
（7）拒绝服务
模拟大量的虚拟请求
通过模拟tcp连接，只连接tcp一部分，消耗TCP连接数。导致其他正常用户不能访问服务器
注意：解决方法：购买硬件防火墙
（8）cookies测试
（1）对cookies的操作
查看Cookie存储路径
清理Cookie的方法
设置Cookie访问提醒
查看Cookie的详细信息
测试用例1： 设置不记住cookie ，屏蔽cookie 登录方维。预期结果：方维登录界面要提示：“取消屏蔽cookies ”
测试用例2： 打开本地的cookie，查看方维的cookie中是否包含有敏感信息（用户名和密码），确认cookie是否为密码的加密，如果是密码的加密也不行。
测试用例3： 不同的系统设置cookie的过期时间，方维设置的过期时间为30分钟，测试30分钟方维的cookie值是否过期。
测试用例4： 检查cookie的设置
HttpOnly 属性的设置：把Cookie 的HttpOnly 属性设置为True 有助于缓解跨站点脚本威胁，防止Cookie 被窃取。
Secure 属性的设置：把Cookie 的Secure 属性设置为True，在传输Cookie 时使用SSL连接，能保护数据在传输过程中不被篡改。
自动安装还是手工配置安装，测试各种不同的安装组合，并验证各种不同组合的正确性，最终目标是所有组合都能安装成功
安装退出之后，产生的目录结构和文件属性是否正确，确认应用程序可以正确启动、运行
在安装之前请备份你的注册表，查看是否有多余的垃圾信息
至少要在一台笔记本上进行安装测试，因为很多在笔记本中会出现问题，尤其是系统级的产品
安装完成之后，可以在简单的使用之后再执行卸装操作，有的系统再使用之后变的不可卸装
对于客/户服务器模式的应用程序，可以先安装客户端，然后安装服务器端，测试是否会出现问题
安装之后，该系统是否对其他的应用程序造成不正常影响（如操作系统、应用软件、冲突）
安装时的异常（断电、数据库终止、网络终止等）
软件能够通过不同方式启动卸载。
通过安装程序进行卸载；
在控制面板中卸载；
能够通过第三方卸载工具卸载
在卸载过程中，是否有终止或者结束按钮。
系统卸载时，询问用户建立文档是否保留。
卸载成功系统能恢复到软件安装前的状态：
安装目录被删除，菜单、桌面快捷方式、任务栏、系统栏中的软件启动程序被删除
系统设置恢复(包含动态库,注册表，系统配置文件,驱动程序,关联情况等
检测卸载成功后，对其他的应用程序不会造成影响
软件能够正确处理使用状态下的卸载要求
程序正在使用时卸载
程序页面打开但没有任何操作时卸载
程序使用后关闭时卸载。
将提示不能卸载或重启后才能卸载。
卸载过程被中断，不能卸载成功，软件可重新被卸载。（断电、重启、取消、删掉进程）
删除内容后，是否可以正常卸载
删除安装目录下的文件
删除开始-程序菜单中的程序组
删除注册表中的关于软件的信息
不同环境下都能正确卸载（windowsxp、vista、win7）
将程序卸载后再次安装，一切功能是否正常
卸载程序时，卸载画面上的软件名称及版本信息正确
卸载后重新安装软件，能否打开原来保存的文件，并一切运行正常；
是否可以选择组件进行卸载
旨在为数千万中国开发者提供一个无缝且高效的云端环境，以支持学习、使用和贡献开源项目。
更多推荐
58
0- 0
已为社区贡献1条内容
所有评论(0)