软件接口示意图_api接口软件

给大家分享一些软件测试常见的面试题，以及复习资料 　　1. Linux 　　Linux在软件测试中的主要作用： 　　(1) 搭建测试环境 　　(2) 查看日志 　　(3) 修改配置文件 　　答：工作中会经常会用到Linux命令，还是比较熟悉，简单的就不说了，说一点稍微复杂的，例如： 　　①　比如我不能打开或查看一个文件时，就可能需要修改、设置文件权限用chmod,加-R对所有子目录下的文件也都进行同样的操作(有两种方式可以修改：数字法和字母法，数字法是基于字母法，我一般工作中使用的是数字法） 　　②　工作中有时也会遇到需要修改文件属性，就要用到chgrp和chown，其中修改文件所属的用户组用chgrp,修改文件所有者用chown 　　③　还有就是日常中工作中需要复制文件和目录时，就会用到使用频率比较高的cp命令拷贝目录（如：cp -r aaa aaa1(r复制文件夹及文件下所有的内容，不带r只能复制空的文件夹）、拷贝文件，如:cp 111.txt 222.txt(将A文件内容拷贝至其他文件，且文件内容一致）） 　　④　移动文件或者将文件改名时，用mv命令，（mv aaa oppo(将aaa目录（文件）从命名为oppo)、mv aaa bbb/ccc(将aaa目录移动到bbb目录下，并重名为ccc) 　　⑤　需要把多个文件和目录放在一起，就用tar命令，tar命令是创建备份和归档比较好的方式（tar -c打包、tar -x解包、tar -z（用gzip压缩）、tar -j（用bzip2压缩）、tar -v(压缩过程中显示详细信息）、ar -f（指定一个文件名，在f之后只能接文件名）、打包:tar -cvf 文件名+后缀 打包文件1 打包文件2 打包文件3、解压:tar -xvf abc.rar） 　　⑥　需要实时查看某文件，用tail -f 　　Tail -30 -f 1.txt//动态/实时查看某文件的最后30行 　　⑦　查询tomcat服务器的运行日志，用taif -30 -f tomcat.log 　　⑧　需要根据端口号查进程，用netstart -an | grep “:3306” //端口 　　⑨　需要搜索文本中相同的字符，用grep 　　⑩　需要快速找出自己所需要的文件，用find 　　–find / -name \*.txt(搜索当前目录下，名字为.txt格式的所有文件） 　　–find / -name \*.txt(通过通配符\*去查找所有.txt格式文件（记得格式，忘记名字） 　　–find / -name a\*(通过通配符\*去查找名字带aaa的文件（记得名字，忘记格式） 　　—-find . -size +6k(搜索文件大小大于6k) 　　—-find . -size -6k(搜索文件大小小于6k) 　　注意:find /(代表从根目录开始搜索） 　　find https://zhuanlan.zhihu.com/p/（代表从当前目录开始搜索） 　　⑪　编辑文本，用vi/vim 　　—新建文件并且输入内容 　　—将空文件进行编辑 　　—将已有内容的文件进行编辑–vi +文件名（txt）–按i 进入编辑模式–输入内容==========—按esc 回到基本模式– 　　在英文下输入 :wq 保存并退出–cat +文件名（查看一下） 　　如果保存并退出不行– :q！ 强制退出 　　⑫　需要删除文件时，用rm命令 　　–rm -i询问删除–同意y—不同意n 　　–rm -f直接删除不询问 　　–rm -r删除此目录下所有文件和目录，会询问是否删除（未删除文件之前无法删除目录） 　　–rm -rf可以强制删除文件，可以删除空目录/非空目录 　　⑬　需要根据进程名来查看进程，用ps -ef | grep “tomcat” 　　⑭　杀死进行的命令，kill/kill -9 　　⑮　不打开文件查看文件内容，sed -ne “2,10p” 2.txt (查看2.txt的第[2,10]行文本) 　　⑯　有时候想查看一下系统cpu及内存利用率，用top命令 　　⑰　对系统的磁盘操作活动进行监视，用iostat 　　⑱　查看当前系统未使用和已使用的内存数目，用free 　　⑲　查看磁盘使用情况，用df 　　⑳　查看目录占用的磁盘资源，用du 　　21　同个内网服务器文件传输： 　　Linxu服务器1：ip为192.168.0.114 　　输入命令： 　　scp -r root@192.168.0.115:/A/1.txt /B/2.txt 　　Linux服务器2:192.168.0.115 　　1.1 说一下常见的Linux？（说10个复杂的命令） 　　答：Linux命令还是比较熟悉的，像ls，cd，cat等简单命令就不说了，我说一些稍微复杂一点的命令，常见的压缩命令有tar,zip,gzip,bzip2,切换用户su，拷贝文件和目录cp，修改权限chmod，修改文件或目录所有者chown，编辑文本内容vi，删除 rm -rf,查询文件中是否包含某字符grep，查询文件find 　　1.2 测试环境搭过没有？ 　　答：搭过呀，去年有个项目就是我们测试人员自己搭的环境，服务器系统用的是CentOS7.4，项目是java项目，1.安装jdk并配置环境变量2.我们公司用的服务器的tomcat，需要安装tomcat并配置3.项目需要用到数据库，安装mysql数据库并配置4.将war包项目上传到tomcat服务器的webapps目录，5.重启tomcat，war包将自动解压。 　　1.3比较重要的Linux命令 　　(1) 查看1.txt的第[2，10]行 　　sed -ne “2,10p”1.txt 　　(2) 动态/实时查看某文件的最后30行 　　tail -n 30 -f 1.txt 　　(3) 实时查询tomcat服务器的运行日志 　　taif -n 30 -f tomcat.log 　　(4) 根据端口号查进程 　　netstat -an | grep “:3306” 　　1.4发包 　　(1) 将war包上传至tomcat-》webapps目录下 　　(2) 进入tomcat-》bin目录执行 sh startup.sh 启动tomcat 　　(3) 浏览器打开http://IP地址:8080/A/main.html 　　1.5停包 　　(1) 执行命令：sh shutdown.sh 　　(2) 发包，停包都要基于搭建环境下 　　或输入命令： 　　(1) ps -ef|grep 服务名 　　(2) 找到该服务进程号 　　(3) 执行命令：kill -9 服务进程号 　　2.Mysql 　　2.1 数据库用的怎么样？ 　　答：数据库还是比较熟悉的，我一般会用Mysql,Oracle,平时比较常用的是Mysql，会更熟悉一点，对于业务上的增删查改都没问题。数据库一般用于验证前端操作是否成功，比如前端添加购物车，可以查询数据库中的购物车是否有增加一条记录，验证UI显示数据是否准确，比如前台页面显示某商品价格100块，可以查询数据库商品价格是否与前台页面一致，造测试数据，可以利用数据库的存储过程造大量测试数据。 　　2.2数据库一般用来干啥? 　　我一般用数据库来验证前端操作是否成功，验证数据UI显示数据是否准确和造测试数据（用数据库的存储，JDBC造数据） 　　2.3 游标（cursor）的应用场景 　　以前看同事用过游标，它是用来做数据迁移的，将多张表中的部分数据，迁移到其他表中，中间需要游标进行存储这个数据，需要与储存环境配合使用 　　2.4 Mysql和Oracle的区别 　　Mysql是开源的，Oracle需要收费 　　Mysql是创建数据库再建表，Oracle是创建表空间再建表 　　Mysql是int，double类型，Oracle是number类型包含整数，浮点数 　　Mysql是varchar，Oracle是varchar2 　　Mysql默认端口号：3306，默认用户是:root 。Oracle默认端口号:1521，默认用户是：system 　　2.5 常见命令 　　selct * from emp 查询 　　drop table emp 删除表 　　delete from emp where name = ”张三” 根据条件删除 　　truncate table emp 情况表数据drop, delete, truncate的区别:1.drop 是删除整张表,删除表结构,以及被依赖的约束与触发器、索引等等。 2.truncate是清空表中的数据，但表结构还在,将表中的数据全部删除,不支持带where条件删除;删除内容，不删除表结构。 3.delete 跟where连用根据条件删除数据,删除整张表和数据,如果删除部分数据需要带where子句。总结:当你不再需要该表时，用drop；当你仍要保留该表,但要删除所有记录时，用truncate；当你要删除部分记录时用delete。 　　alter table emp rename to emp1 修改表名 　　alter table emp add(id int(10) default null) 插入一个字段 　　insert into emp values(填写全部字段的值) 增加数据 　　insert into emp (字段名)values(值) 　　update emp set sex=”女” 全部修改 　　update emp set (新值)where (旧值) 根据条件修改 　　updat emp set (新增) where id=”1” 根据条件修改 　　Select * from emp,emp1 where emp.sid=emp1.sid 内连接 　　Select * from emp left join emp1 on emp.sid=emp1.sid 左连接 　　select * from emp right join emp1 on emp.sid=emp1.sid 右链接 　　2.6 如何编写存储过程？ 　　首先我会创建一个存储过程，如果用到变量我会输入变量并且声明变量，当用到if else 判断结构我会判断之后输出变量。如果用到循环结构我会用循环。用到参数的话我会调用函数。如果表多的话我可能会用到游标 　　问：什么是触发器？什么是存储过程？ 　　触发器：通过事件来触发运行的，主要是没有人工干预的情况下来完成复杂度高一些的约束条件，从而保证数据库的完整性和一致性。 　　存储过程：在大型数据库中，一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给出参数来执行它。 　　DELIMITER //(语句块结束符) 　　CREATE PROCEDURE过程名(OUT s in) 　　BEGIN 　　语句…… 　　END 　　// 　　DELIMITER ; 　　2.7 如何编写存储过程？ 　　关于SQL优化 　　优化之一 – 从数据库设计方面考虑 　　1. 表与表之间的业务联系要明确 　　2. 表字段尽量使用数值型 　　3. 属性尽量使用定长 　　4. 建立合理的索引：索引就是用某种数据结构来查找对应的信息，从而减低时间复杂度提高查找效率. 　　优化之二 – 从SQL语句优化方面考虑 　　1.尽量将要输出的字段写出来 　　2.合理使用连表查询 　　3.查询的时候要注意是否走索引 　　优化之三 – 读写分离与分库分表 　　3.测试理论 　　3.1 测试用例的设计方法？ 　　写测试用例可以用的方法有很多，我就说一些我比较常用的吧，例如： 　　(1) 等价类划分：比如我要去超市买水果，有效等价类：苹果、香蕉、桃子。无效等价类：青菜、大米、饮料 　　(2) 边界值：比如淘宝商城添加购物车，上限是120件，边界值就是119,120,121 　　(3) 场景设计法:以一个取款机取款为例，基本流是插卡–输入正确的密码–输入金额–取款成功–取卡，备选流是插卡–输入错误的密码–输入正确的密码–输入金额–取款–取卡，异常流是插卡–输入3次错误密码–吞卡 　　(4) 因果图：比如某软件规格说明书要求，第一列字符必须是A，第二列字符必须是数字，在这种情况下进行文件修改，如果第一列字符不正确，则给出信息L，第二列字符不是数字，则给出信息M 　　(5) 状态转换图：例如复印机，在未接到复印命令时，处于闲置状态，接到复印命令时，进入复印状态，完成后又回到闲置状态，如果执行复印命令时发现没有纸时，则进入缺纸状态，还要在执行复印命令时发生卡纸，则进入卡纸状态，待处理后又回到闲置状态 　　3.2 测试流程 　　一般在产品迭代或者增加新需求的时候，我们产品，开发测试，会开一个需求评审会议，产品会拿着需求文档和初始的产品原型告诉我们这期我们需要做什么，涉及那些模块和功能，研发人员会评估技术实现难度和时间，我作为测试也会针对疑问的地方提出我的建议，最后大家再技术和功能实现上达到统一之后开展这个项目，研发在开发的过程中，我会根据需求文档还有产品原型剖析测试点，编写测试用例，我会在前端完成之后测基本的UI测试，功能测试，后面接口开发完毕，前后端联调之后，我再针对整个功能做一个详细的SIT测试，发现的问题会提到我们的BUG管理工作上，阻塞问题及时催促开发修改，修改之后的问题会做UAT测试，达到上线标准之后申请上线，上线之后也需要进行一遍整体的测试，保证系统功能的完善，后期也会正对这次产品迭代出一个测试报告，这是我测试的一个整体流程。 　　3.3 测试每个阶段有哪些产出物？ 　　根据我个人的工作经验，我认为在测试需求分析阶段会有测试计划输出，在测试用例设计及评审阶段会输出测试用例，然后执行测试用例的时候会出测试执行记录和系统BUG清单，最后在测试评估阶段，由测试经理汇总测试人员的测试结果出测试报告 　　3.4 Bug定级在测试计划的体现？ 　　在我们公司的测试计划中，会把一些界面， 不影响项目使用的bug定为轻微的bug,像字段控件这种小功能bug定为一般的bug,关系到主流程、关联功能、重点和难点的bug定为严重bug,还有那些严重阻碍测试和开发工作或者功能完全没有实现的bug，定级为致命bug。 　　3.5 缺陷报告的组成/bug单的组成？ 　　我们公司的缺陷报告的组成大致由：缺陷编号、缺陷标题、缺陷发现者、发现缺陷的日期、缺陷所属的模块、缺陷的版本、指派给谁处理、缺陷的状态、缺陷的严重程度、缺陷的优先级、缺陷描述等。 　　然后Bug单是由：bug标题、bug描述、bug出现步骤、附件、bug的严重程度和优先级、指派给谁等组成。 　　3.6 bug的生命周期？ 　　Bug的生命周期就是发现bug,提交bug,指派bug,开发确认这个bug,然后开发修复bug,返测bug,返测通过后就关闭这个bug,如果在这个Bug在返测时没有通过，就需要重复这个过程。 　　3.7 测试用例的组成？ 　　每个公司的测试用例模板都不太一样，一般都包括：需求编号、需求名称、模块名称、用例编号、用例名称、优先级、前置条件、操作步骤、输入数据、预期结果 　　3.8 bug管理工具？ 　　我们公司使用的bug管理工具是禅道（bugfree/jira） 　　3.9 测试报告的组成部分？ 　　我看我们公司的测试报告里包含的有这个项目的项目背景、需要测试的版本、测试的范围、测试环境、测试策略以及测试用例的设计方法，还有测试人员、测试时间、测试类型等，还有发现bug的数量，以及多少bug通过了回归测试等。 　　l 概述（细节:目的、项目背景、参考资料） 　　l 测试概要（细节：测试版本、测试范围、测试环境、测试策略、测试用例设计方法） 　　l 测试组织（细节：测试人员、测试时间、测试类型） 　　l 测试用例执行状况 　　l 测试总结（细节：缺陷数量汇总、缺陷状态汇总） 　　3.10 测试计划 　　被测试项目的范围，方式，资源，测试计划，进度组织，本测试执行的进入与退出标准，本计划的审批与变更方式，以及与测试有关的风险等 　　我们公司的测试计划，一般是我们老大写，不过有一次我们老大带着我写过一次，我们公司的测试计划大概包括：项目背景，测试目的，测试起止时间，测试参与人员，测试环境要求，测试范围，任务分配，测试里程碑，测试策略，风险和问题等等，比如以一个50天的项目为例，在人员安排上，我安排了5个测试，我把测试进度分为需求分析10天测试计划1天编写/评审测试用例10天 SIT第一轮5 天SIT第二轮5天 UAT第一轮5 天UAT第二轮5 天交叉测试2天 验收测试4天 输出测试报告1天产品上线2天。 　　3.11 web测试和app测试的区别 　　l Web项目一般都是b/s架构，通过浏览器访问；使用的话会比较方便；但是访问速率相对较慢；更易维护更新，只需更新服务器数据；安全性相对较低。app为c/s架构。需下载app；由于要下载安装app才能使用，相对来说不易使用；由于有部分数据存储在客户端，所以访问速率相对较快；维护更新较为复杂；安全性更高。 　　l 相比较web测试，app多了一些专项测试，例如：弱网测试/干扰测试/安装、更新、卸载 　　3.12 开发不承认bug 　　以前我也遇到过这种情况，因为毕竟开发的思维跟测试的思维也不是太一样，这个是难免的，遇到这种情况，首先我会跟他沟通，然后我会回顾需求文档，看自己理解有没有问题，然后找到开发，将出错的地方重现，如果开发还是不认，我会把跟我们老大沟通，我们老大也认为这是一个bug,我们老大就会去找开发沟通。 　　3.13 对偶发性bug怎么处理？ 　　公司要求是明确记录，如果出现频率高就提单，频率低我一般不提，但是会先记录下来，接口请求参数，响应参数，日志log，截图或录屏等。 　　3.14 测试通过上线的标准？ 　　(1) 测试需求执行覆盖率达到100% 　　(2) 致命、严重、一般Bug修复率应达到100%，轻微Bug修复率应达到96% 　　(3) 回归测试已通过 　　3.15 当场出题：朋友圈、发红包、登录UI、注册UI? 　　（1）朋友圈: 　　功能测试： 　　点赞功能： 　　1）网速对点赞的影响 　　2）点赞人数的个数显示是否正确 　　3）共同好友能否看到点赞状态 　　4）一行能显示几个点赞的头像 　　5）能否正常的点赞和取消点赞 　　6）点赞是否有上限 　　评论功能： 　　1）网速对评论的影响 　　2）评论能否按时间先后顺序显示 　　3）能否正常sigusoft评论 　　4）评论是否有上限 　　5）能否及时刷新 　　6）发表评论后能否正常删除 　　7）评论能否正常sigusoft 　　界面测试: 　　1）页面布局是否跟产品原型图一致 　　2）功能操作是否简便，页面布局排版风格是否美观合理，提示语相关信息是否易于理解 　　中断测试： 　　APP端中断：前后台切换、锁屏解锁、断网重连、app切换、来电/来短信中断 　　网络测试： 　　1）三大营运商不同网络制式测试 　　2）2G/3G/4G/5G/WIFI切换 　　3）无网络测试 　　4）弱网测试：延时、丢包、页面呈现的完整性 　　兼容性测试： 　　1）安卓手机端、苹果手机端功能界面是否正常 　　2）各平台朋友圈展示数据是否一致 　　性能测试： 　　app压力稳定性测试：通过monkey工具实现，频繁发送朋友圈，浏览朋友圈请求，是否容易发生崩溃 　　（2）发红包： 　　输入金额功能: 　　1)红包钱数、红包个数的输入框只能输入数字 　　2）红包里最多和最少可以输入的钱数 　　3）红包的金额的小数位数是否有限制 　　4）输入钱数有0，“塞钱进红包”按钮不能 　　红包个数功能： 　　1）超过最大拼手气红包的个数是否有提醒 　　2）发送的红包个数超过最大范围是不是有提示 　　支付功能： 　　1）余额不足时，红包发送失败 　　2）余额不足，会不会自动匹配支付方式 　　3）支付时可以密码支付也可以指纹支付 　　（3）登录ui: 　　功能： 　　1）输入正确的用户名、正确密码 　　3）输入错误的用户名、正确的密码 　　4）输入正确用户名、错误的密码 　　5）输入的错误的用户名、错误的密码 　　6）不输入用户名和密码 　　7）用户名和密码不能包含特殊字符 　　安全： 　　1）同一用户能否在多个页面同时登录 　　2）密码应该密文显示、保存 　　3）同一用户的登录次数限制 　　(4) 注册UI 　　功能： 　　1）用户名、密码字段的长度 　　2）输入正确的验证码 　　3）输入错误的验证码 　　4）输入超过60s的验证码 　　5）用户名的唯一性 　　性能： 　　1）提交后，响应速度，跳转时间 　　3.16你们公司有多少开发多少测试？ 　　我们公司大概有20多个开发，前端有几个（安卓、IOS、小程序），后端有几个，DBA，架构师，测试：我加另外2个。还有一个专门做性能测试，以及我们测试经理，一起的话，测试目前是4个，之前是6个，后面有2个辞职了，我这边来公司X年多了，我主要负责XX方面的测试 　　3.17 你怎么跟开发沟通的? 　　l 要有耐心，就事论事，不要带有个人情绪与评价去沟通问题 　　l 平时与开发沟通，除了工作，其他方式的也可以多多交流，增加互相的关系，后期工作的时候也好交流一些 　　l 不要随便向上级领导去反馈这类问题最好能够私下交流 　　l 不要在背后议论开发的技术问题 　　3.18 你们公司的测试流程与阶段是怎么划分的？ 　　我们公司主要做敏捷开发： 　　敏捷开发以人为本，小版本迭代，项目经理组织需求会议，开发和测试，产品进行需求分析， 　　敏捷的时间比较短，我们公司一般都是一个星期迭代一个版本。需求分析以后，我们会列出测试点，编写测试用例，然后会进行评审，没问题，就进入测试，测试我们一般分为2个阶段，一个sit，一个uat，没有问题了以后就进入验收，然后上线，有问题的时候，提出bug，跟踪bug。及时的跟开发沟通。 　　我们项目组这样的，项目比较紧急的时候不会写测试用例了，根据测试点进行测试。 　　一般2个周期的项目迭代，我们会编写测试用例，并且进行详细的评审。上线了以后，我们也会系统，看上线的功能有没有出现问题。 　　然后敏捷的话，我们公司每天下班之前都会开会议。会汇报今天的工作任务，以及困难等等。 　　3.19 测试用例怎么写？（你如何保证你的测试用例编写是完美的？） 　　(1) 我写测试用例之前会参考需求文档和开发的概要设计和详细设计等文档，(寻找现有参考文档） 　　(2)写测试用例，一般我们使用测试用例方式，比如：等价类，边界值，场景法这几个是常用的，但是我除了这几个常用的方法以外，我还会状态转换图。大纲法。除了这些方法以外。我还会使用测试思维去异常部分以及特殊情况和前后台数据交互等。 　　(3)我写测试用例的时候，主要业务逻辑实现，重点和难点部分。这个比较有意思。 　　(4)我写完测试用例以后，我会自己检查2-3遍，基本的功能点有没有遗漏，我写的测试用例是否简洁明了。容易被读、然后，我跟同事互相检查自己的测试用例，会提出问题。然后立即修改。 　　(5)我们公司对测试的要求很严格。我们那个领导，就是个变态。一条一条去评审。有问题就会直接批我们。但是在这种高压的情况，第一个版本和第二个版本稍微艰难一些。但是后面的基本上没问题 　　(6)整体来说，我的测试用例还是不错的 　　感觉面试官不怎么满意可继续下面： 　　进阶版1： 　　Ø 需求改动的时候，我们测试用例要随之改变 　　Ø 平时测试用例的时候，有问题，我们会当场加批注，评审完成以后，及时修改。 　　Ø 经常与开发需求进行沟通，自己有想法的时候一定要多多沟通。 　　进阶版2： 　　Ø 我会经常看高手写的测试用例，进行独立思考，总结。应用实战我自己的测试用例当中” 　　3.20 印象最深的bug？ 　　印象最深的bug，就是在我刚进入测试行业的时候，我还记得当时负责的是一个电商项目，在对添加购物车进行测试时，输入数量时应该是只能输入整数，但是我输入浮点数也可以，我就把这个bug提单了，后来发现是开发在写代码的时候把数据类型写成浮点数了。 　　3.21 为什么要做弱网测试？ 　　因为手机的网络目前主要分为3G、4G、5G、wifi，不同的网络的差异，都会对用户使用app造成一定影响，另外当前app的使用场景多变，如进地铁、上公交、进电梯等也会对使用APP有影响，如果app没有对各种网络异常进行兼容处理，那么用户在使用app时就可能会遇到闪退、anr、数据丢失。 　　3.22如何使用fiddler弱网测试？ 　　搭建fiddler抓包环境，电脑和手机端连接同个wifi，手机连接的WiFi的http代理设置为电脑的IP，如果是抓http协议，不需要下载证书并认证证书，如果是抓https协议，需要下载证书并信任，抓包环境搭建成功后，2.启动fiddler，规则，再自定义规则，可以改变上行、下载模拟2G,3G,4G,弱网等不同环境，测试APP在不同环境下的运行情况，是否会出现卡顿，闪退等现象。 　　3.23 用户提示付款成功了，商家未收到款? 　　这种情况可能是开发把代码写死了，我们可以使用fiddler抓包，如果抓到的请求数据都ok，就说明不是前端的问题，然后可以去查看数据库日志，看数据库有没有这条数据的记录，如果有就没问题，还可以看fiddler抓的响应数据，分析响应数据，如果响应数据有问题，一般是后端接口有问题。 　　注意:很大问题是代码的问题，支付那么大的平台一般不会有问题 　　3.24 软件的生命周期？ 　　一个软件生命周期是从产品立项开始，用户提出需求或者公司主动去挖掘市场需求，在经过市场需求调研、可行性研究评审确认可行后，产品立项，出计划，产品或者项目成立后，由需求人员、项目经理、测试经理等项目组人员进行分析项目的业务逻辑，由需求人员反复与客户确认最终需求人员需要输出需求文档，然后就是开发出一个概要设计，概要设计通过以后再出一个详细设计，概要和详细设计都通过评审之后，就可以进行编码，编码完成后，测试人员进行测试，测试ok，项目上线，后期开发人员需要进行维护，这就是一个软件的生命周期。 　　3.25 软件测试的风险？ 　　(1) 时间资源，测试工作量较大，分配时间较少 。可以增加测试工程师或加班， 在验收阶段，可以调用公司人员参与到测试当中 　　(2) 人力资源，人员较少，且都不具备所测项目的相关经验，对被测对象不熟悉。优先招聘有行业背景的测试工程师 ，向被测对象行业人员了解相关的业务经验 ，允许测试人员参与开发组的需求讨论会 　　(3) 需求变更,有些需求不是很明确，且客户的需求会不断改变。让需求人员明确所有的需求信息 ，当用户需求变更时，及时与BA沟通，以便及时更新需求文档 　　(4) 其他风险,如遇上大面积停电或台风、火灾等不可抗力因素。做好备份方案和容灾机制 　　3.26 你在测试中起什么作用？ 　　督促和卸载开发人员尽快解决程序中的缺陷，对缺陷进行跟踪、分析和分类总结，以便让项目管理人员和相关负责人能够及时、清楚的了解产品的当前质量状态 　　3.27 你是怎么做到设计的用例覆盖所有的需求？ 　　（1）参考需求文档（2）多沟通—跟开发-产品-项目组的测试人员（3）新增需求或者优化需求一定要及时更新测试用例（4）分析需求的时候，一定要重点难点部分 　　3.28 你来我们公司，我们公司没有一个人懂这个需求，也没有任何的文档给你参考，你怎么下手？ 　　1.找现有的内容：比如：系统是有的 　　2.先操作一遍这个系统，把重点模块和难点模块使用xmind列出，进行总结，根据以往的工作经验进行简单的分解 　　3.找到对应的开发，和产品，进行讨论 　　4.参考同类型的项目进行梳理，或者借助百度等资料进行分解 　　5.自己分解清楚了以后，与对应的开发和产品进行需求串讲。 　　6.流程：1）自己排一下测试计划，什么时间该干什么 　　2）根据计划进行SIT测试，UAT测试 　　3）找问题提bug单，回归测试 　　4）输出测试报告 　　3.29 你上一个公司在哪？ 有多少人？开发多少？测试多少？ 　　成都 有四十多人。 开发二十多个， 测试九个 　　4. Monkey 　　常见面试题梳理：https://www.cnblogs.com/6J2B2/p/12980350.html 　　4.1 monkey命令参数介绍？ 　　adb shell monkey -p com.jym.mall -v -v -s 10000000 –throttle 500 1000000 　　-p:包名 　　-v:日志的详细程度(越多越详细） 　　-s:用于指定伪随机数生成器的 seed 值 　　Throttle：两个事件的事件隔 　　1000000：事件总次数 　　4.2 monkey怎么分析日志？ 　　(1) 先观察日志文件的最后，判断monkey是否正常结束“monkey finshed”,并且执行次数是否给少了 　　(2) Ctrl+f在日志文件中搜索“ANR”“Exception”“Error”“Crash” 　　(3) 在这些异常的地方，看一下发生这些异常之前的monkey干了什么 　　(4) 用相同的种子再跑一边monkey，并且注意观察 　　(5) 用手动执行一次monkey的步骤 　　4.3 Monkey各个事件的百分比？ 　　(1) pct-touch:触摸事件，时间百分比 　　(2) pct-motion:动作事件，设定动作时间百分比 　　(3) pct-majornav:主要导航事件，设定主要导航事件百分比 　　5. adb命令 　　(1) 查看在线设备:adb devices 　　(2) 对某一台设备执行命令:adb -s 设备id install xxx.apk 　　(3) 进入设备或模拟器的:adb shell 　　(4) 将手机日志导出并显示 ：adb logcat 　　(5) 从电脑上发送文件到设备：adb push <本地路径> <进程路径> 　　(6) 从设备上下载文件到电脑:adb pull <进程路径> <本地路径> 　　(7) 累出当前系统中所有包的名字（软件包名）:adb shell pm list packages 　　(8) 卸载软件：adb uninstall <包名> 　　(9) 文件的读写权限:adb remount 　　(10) 查看屏幕分辨率：adb shell vm size 　　Adb命令:https://blog.csdn.net/zhcswlp0625/article/details/53889187 　　6. http协议及抓包 　　6.1 TCP协议和UDP协议 　　TCP是有连接的/有状态的。数据不会丢失。 　　UDP是无连接的/无状态的。数据可能会丢失。 　　6.2 TCP4层模型/OSI7层模型？ 　　OSI7层：应用层，表示层，会话层，传输层，网络层，数据链路层，物理层 　　TCP4层：应用层，传输层，网络层，数据链路层。 　　HTTP位于应用层 　　6.3 GET和POST区别 　　（1）GET 请求不安全，请求参数在浏览器地址栏中可以看到！POST 请求，安全，在地址栏中看不到！ 　　（2）GET 请求的请求参数的大小是有限制的，但是 post 请求的请求参数大小是无限制的！ 　　（3）GET 请求中请求参数可以被添加为浏览器书签！但是 POST 请求带参数，不能被保存为浏览器书签！ 　　（4）对于GET请求，回退浏览器/刷新操作是无害的，但是对于 POST 请求，回退浏览器/刷新操作都是再次提交的意思！ 　　Get和Post请求有什么不同？ 　　1）请求方式不同 　　请求方式为GET,则可以在请求的URL地址后以？的形式带上交给服务器的数据，各数据之间以&进行分隔；请求方式为POST，则可以在请求实体内容中向服务器发送数据； 　　2）传输数据有大小不同 　　GET传输的特点，在URL地址后附带的参数是有限制的，其数据容量通常不能超过1K；POST传送的数据量无限制。 　　3）安全性不同 　　Post方式比GET方式更安全。 　　6.4常见的响应状态码有哪些？ 　　2开头： 　　200:ok,正常处理并返回 　　204：没有资源可以返回 　　206：客户端进行了范围请求 　　3开头: 　　301:永久重定向 　　302：临时性重定向 　　303：表示客户端应采用GET请求 　　4开头： 　　400:错误请求 　　401：未授权 　　403：禁止访问 　　404：页面不存在 　　405：方法禁用 　　408：请求超时 　　415:参数类型错误 　　5开头： 　　500:服务器内部错误 　　501：尚未实施 　　502：网关错误 　　503：服务不可用 　　504:网关超时 　　505：http版本不受支持 　　状态码分类：(5种类型) 　　1xx，信息，服务器接收到请求，需要请求者继续执行操作 　　2xx，成功，操作被成功接收并处理 　　200 （请求成功成功） 服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。 　　201 （已创建） 请求成功并且服务器创建了新的资源。 　　202 （已接受） 服务器已接受请求，但尚未处理。 　　203 （非授权信息） 服务器已成功处理了请求，但返回的信息可能来自另一来源。 　　204 （无内容） 服务器成功处理了请求，但没有返回任何内容。205 （重置内容） 服务器成功处理了请求，但没有返回任何内容。 　　206 （部分内容） 服务器成功处理了部分 GET 请求。 　　3xx，重定向，需要进一步的操作以完成请求 　　301-资源(网页等)被永久转移至其他URL 　　4xx，客户端错误，请求包含语法错误或无法完成请求 　　404-请求的资源(网页等)不存在 　　5xx，服务器错误，服务器在处理请求的过程中发生了错误 　　500-内部服务器错误 　　6.5网络基础 　　HTTP和HTTPS协议的区别是: 　　HTTP协议：是超文本传输协议，是一个基于请求与响应（客户端发起请求，服务器响应），无状态的（协议对客户端没有状态储存，对事务处理没有“记忆”能力）应用层的协议，常基于TCP/IP协议传输数据，互联网上应用最为广泛的一种网络协议 　　HTTPS：基于HTTP协议，通过SSL/TLS提供加密处理数据、验证对方身份以及数据完整性保护： 　　1、内容加密：采用混合加密技术，中间者无法直接查看明文内容； 　　2、验证身份：通过证书认证客户端访问的是自己的服务器； 　　3、保护数据完整性：防止传输的内容被中间人冒充或者篡改。 　　HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的查 ，改 ，增 ，删 4个操作 　　ftp、mysql、http、adb、tomcat、https、apache的默认端口： 　　HTTP通信用的端口号是:80 　　HTTPS通用端口号是:443 　　FTP的端口是:21 　　mysql默认端口是:3306 　　Sql服务的默认端口是:3389 　　tomcat默认端口是:8080 　　windows远程终端的端口号是:3389 　　ORACLE默认端口是:1521、1526 　　SSH (Secure Shell)服务使用端口是：22 　　Telnett 端口是：24 　　DHCP server的端口号是：67 　　MAIL 的端口号是：25\110 　　pop3\smtp 的端口号是： 110/25 　　DNS 的端口号是 ：53 　　6.6 cookie和session的区别 　　（1）cookie存放在客户端浏览器上，session存放在服务器上。 　　（2）cookie可以减轻服务器压力，但是不安全，容易进行cookies欺骗 　　（3）session较安全，但占用服务器资源 　　cookie 和 session 的区别 ： 　　答：cookie数据存放在客户的浏览器上，session数据放在服务器上。cookie不是很安全，别人可以分析存放在本地的cookie并进行 cookie欺骗，考虑到安全应当使用session。 　　session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面应当使用cookie。 　　单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存 20 个cookie； 　　可以将登陆信息等重要信息存放为session；其他信息需要保存，可以放在 cookie。 　　6.7 http和https的区别 　　（1） https=http+ssl。即 https 协议在 http 协议的基础上增加了 ssl 加密协议！ 　　（2）http 不太安全，https 安全一点！ 　　（3） http 无需证书。但是 https 协议的部署需要在服务器端安装部署 https 证书。https 证书：免费版、收费版 　　（4）表面上区别：端口不同，http端口80，https端口443。Url 上协议不同！ 　　6.8 谈谈你对http协议/报文的理解 　　http协议是一个应用层面的面向对象协议，http请求由三部分组成，分别是请求行、请求头、请求实体，请求行包含请求方法，例如get/post等，常用的请求头有，accept用于制定客户端接受那些类型的信息，host用于查看服务器的IP和域名，User-Agent：查看浏览器标识，使用什么服务器，然后服务器在接受和解释请求后，返回一个http响应消息，响应也是由三个部分组成，分别是：响应行、响应头、响应实体，常见的响应状态码有200表示客户端请求成功，300表示重定向，400客户端请求有语法错误，401请求未授权，403禁止访问，500服务器内部错误，502网关错误，504网关超时。 　　6.9 一个web请求完整的流程/一个http请求的完整过程 　　客户端先对这个请求进行DNS解析，然后发送请求至服务器，服务器校验数据的合法性，转化sql语句发送至数据库，数据库执行sql语句，将数据返回给服务器，服务器返回给客户端，并渲染UI界面。 　　6.10 如果一个http请求发送失败的原因？ 　　(1) 请求方式不对 　　(2) 请求地址不对 　　(3) 请求实体的格式不对 　　(4) 缺少相关的请求头 　　6.11 常见请求头 　　Content-Type:查看请求实体的类型是from格式或者json格式 　　Host：查看服务器的IP和域名 　　User-Agent：查看浏览器标识，使用什么服务器（谷歌，火狐） 　　Cookie：浏览器存储数据容器 　　Connection：客户端和服务器的连接，Connection：keep-alive保持链接，Connection：close 关闭链接 　　Referer：该请求的来源 　　Accept：指定客户端期望接受那些类型的信息 　　6.12 常见响应头 　　Server：指定后台代码所用的web服务器的服务器类型（apache服务器，tomcat服务器） 　　Location：重定向 　　Content-Type：响应实体的类型（html，json） 　　Refresh：刷新 　　Set-Cookie：服务器返回的cookie，登陆凭证可能就在某个Set-cookie中 　　6.13 怎么这个bug属于前端还是后端 　　可以通过Fiddler抓包定位,如果抓包发现该请求的请求方式，请求头，请求实体，请求参数有问题导致请求发送失败，这个属于前端bug，如果请求没问题，发现后端响应内容，响应头，响应状态码有问题，这个bug属于后端bug 　　（拓展：面试官接着问，如何精准定位。假设是后端有问题，可以利用Jmeter发送请求，查看接口的响应日志，tomcat日志，分析java异常导致的原因） 　　1）请求接口URL是否正确：如果请求接口URL不正确，为前端Bug； 　　2）http请求中的参数是否正确：如果http请求中的参数不正确，为前端Bug； 　　3）如果接口URL和参数都正确，查看响应内容是否正确：如果这种情况下响应内容不正确，则为后端Bug 　　6.14 Fiddler如何搭建抓app的环境/Fiddle如何搭建环境 　　（1）手机和PC连接同个wifi 　　（2）手机链接的WiFi的http代理设置为PC的IP 　　（3）如果app走http协议，无需再手机上安装https证书和信任证书，但是app走https协议，那么必须在手机上安装https证书并信任证书（app要走Fiddler协议，不然抓不了） 　　6.15 Fiddler环境都OK，但是某app就是抓不了包，什么原因？ 　　该app不走Fiddler能抓的协议 　　6.16 Fiddler的工作原理? 　　1.Fiddler会自动设置浏览器的代理服务器为Fiddler自己,即打开Fiddler时，浏览器的代理服务器就被设置为Fiddler的IP和端口了。关闭Fiddler时，浏览器的代理服务器会自动还原为原始状态。 　　2.这个抓包是为了客户端和服务器之间的通信数据 　　工作原理是，以web服务器代理的形式，fiddler截获客户端发送给服务器的数据，然后模拟客户端发送给服务器，服务器返回的数据也会被fiddler截获，经fiddler返回给客户端Ip：127.0.0.1，端口：8888 　　fiddler抓包的工作原理是？ 　　Fiddler是位于客户端和服务器端之间的HTTP代理， 它能够记录客户端和服务器之间的所有HTTP(S)请求，可以针对特定的HTTP(S)请求，分析网络传输的数据，还可以设置断点、修改请求的数据和服务器返回的数据。 　　Fiddler在浏览器与服务器之间建立一个代理服务器，Fiddler工作于七层中的应用层，能够捕获通过的HTTP(S)请求。Fiddler启动后会自动将代理服务器设置成本机，默认端口为8888。Fiddler不仅能记录PC上浏览器的网络请求数据，还可以记录同一网络中的其他设备的HTTP(S)请求数据。 　　1)客户端像WEB服务器发送HTTP(S)请求时，请求会先经过代理Fiddler代理服务器。 　　2)Fiddler代理服务器截取客户端的请求报文，再转发到WEB服务器，转发之前可以做一些请求报文参数修改的操作。 　　3)WEB服务器处理完请求以后返回响应报文，Fiddler代理服务器会截取WEB服务器的响应报文。 　　4)Fiddler处理完响应报文后再返回给客户端。 　　6.17 Fiddler断点、Fiddler修改请求参数，Fiddler修改响应内容？ 　　比如一个购买的金额输入框，输入框前端做了限制100-1000，那么我们测试的时候，需要测试小于100的情况下。很显然前端只能输入大于100的。这是我们可以先抓到接口，修改请求参数，绕过前端，传一个小于100的数，检查服务端的功能是否OK。 　　Fiddler设置断点，可以修改HTTP请求头信息。如修改Cookie,User-Agent等 　　可以修改请求数据，突破表单限制，提交任意数字，如充值最大100,可以修改成10000 　　拦截响应数据，修改响应体，如修改服务端返回的页面数据 　　6.18 tcp的三次握手？ 　　第一次握手：建立连接，客户端发送syn包到服务器，进入syn_sent状态第二次握手：服务器接收syn包，同时给客户端发个syn包，进入syn_recv状态第三次握手：客户端接收服务器的包，发送确认包，两者进入连接成功状态 　　7. 接口功能测试 　　1、 请说一下怎么使用jmeter做接口测试的过程？ 　　首先在测试计划中创建线程组； 　　添加http 默认请求头，http 信息头管理器，http cookie管理器； 　　添加http请求，填写正确的请求方法，URL，以及参数； 　　添加断言； 　　添加察看结果树。 　　2、 加密接口你是怎样做的？ 　　首先向开发拿一个加密jar包； 　　在jmeter测试计划中导入加密jar包； 　　添加http请求，设置用户参数； 　　在http请求中插入bean shell预处理器，对参数进行加密，将加密数据转换为可调用参数； 　　最后在需要调用加密参数的URL中添加加密参数。 　　1.接口功能测试是什么？ 　　我们测试人员根据接口文档，我会用用接口测试工具（PostMan、JMeter）给某接口发送请求参数、cookie、请求头来验证该接口是否 OK！该验证由人工根据接口的响应码、响应内容来验证 　　2. 接口功能测试的流程（怎么做接口功能测试） 　　答：我在做接口功能测试时，首先拿到接口文档，接口文档是html，就问开发要网址，如果是word，pdf格式的，就去ftp服务器里面下载。然后就分析接口文档，分析接口的请求方式，是get还是post请求，接口的地址，接口需要带那些请求头，接口的请求实体，例如参数的类型问题，参数的格式问题，参数的数量问题，参数是否有默认值，参数的长度问题，参数的加密问题等。分析完接口文档，我就会列测试点，比如有一个需求是产品a需要b系统提供一个api,输入参数为:出生日期，参数格式为：2021-02-01，如果输入格式不正确或异常，那么接口反馈为空，我会列出1）不是出生日期2）错误的出生日期格式3）今天的日期4）未来的日期5）不存在的日期等，接着我会编写接口测试用例，写Jmeter脚本，运行Jmeter脚本，发现bug（响应内容和预期内容不一致，响应状态码不友好，不按规范来，响应内容中的提示有歧义，请求发过去，啥都没有返回），提bug单，最后写接口测试报告。 　　接口测试怎么测试的（接口测试怎么做）。 　　1）需求分析–2）Api文档分析与评审–3）测试计划编写–4）用例设计与评审–5）环境搭建（工具）–6）执行用例–7）缺陷管理–8）测试报告 　　(1)当我们拿到接口文档后，会先进行熟悉需求文档，了解每个接口的功能、服务器地址、 端口、请求方式、请求参数、参数的约束条件有哪些还有一些响应的字段和响应的状态码； 　　(2)之后就会开始编写测用例的，跟功能测试一样，考虑到正常异常的请求参数，还要考虑 到与之对应响应报文是否正确； 　　(3)最后就开始使用 Jmeter执行用例了，先建立一个线程组，再添加 http请求，填写好请求地址，端口，和请求参数，设置参数化，添加断言等，最后添加查看结果树再运行。运行完后，检查接口是否通过，如果不通过，先定位下原因，如果是请求的参数有问题， 修改后再进行测试，如果是接口本身存在 bug，就把服务器上的日志取下来，提单给开发修改，一直到接口没问题了，就放到我们搭建好的 Jmeter+Jenkins框架上做持续集成测试。 　　这就是我们接口测试的大概流程。 　　7.2.1怎么搭建Jmeter测试环境 　　1)因为 JMeter是 JAVA程序开发的，所以要先安装 JDK； 　　2)配置 JAVA环境变量，包括：JAVA_HOME，PATH，CLASSPATH； 　　3)双击 jmeter的 bin目录里面的 jmeter.bat文件，就可以启动Jmeter。 　　4.2为什么要尽早介入接口测试？ 　　1)当接口完成开发后，就可以进行接口测试，尽早介入测试，bug越早发现修复成本越低； 　　2）接口测试相对于UI测试变化小，相对稳定，维护成本低； 　　3）接口测试工作量低于UI测试，执行效率比UI测试高； 　　4）接口测试可以覆盖更多测试场景，可以绕过前端限制，可以发现很多页面操作中发现不了的Bug和检查系统的异常处理能力； 　　5）接口测试可以做性能、稳定性、安全、自动化测试。 　　7.2.2 Jmeter之前用的是什么版本？如何安装的？ 　　Jmeter5.4.1, 先安装JDK1.8 再装JMETER ,并配置环境变量 　　7.2.3在项目中如何用jmeter进行接口测试？ 　　1）首先新建一个线程组。 　　2）然后再新建一个HTTP请求默认值。（输入接口服务器IP和端口） 　　3) 再新建HTTP请求，输入接口路径，请求方式，参数等。 　　4）然后增加断言和查看结果树。 　　5）调试及强化脚本（参数化，关联） 　　6）执行用例，最后编写接口测试报告 　　3.如果公司还没有接口文档，怎么做接口测试？ 　　1. 点出实际情况：我们一般都是有接口文档才做接口测试！ 　　2. 点出解决：如果公司没有接口文档还要做接口测试，怎么做？ 　　以我的理解，应该是通过抓包、和开发沟通等方式来接口信息，并整理出简版的接口文档，再做接口测试！ 　　4.Jmeter怎么实现参数化？ 　　1.接收接口文档， 　　2.分析接口文档，及需求，例如请求方式是get请求，还是post请求，是否有需要带的请求头，以及分析请求参数，参数的类型问题，参数的格式是from，还是json，参数的数量问题，参数是否有默认值，分析过后，就在Jmeter中添加线程组，线程组中添加http取样器，按照接口文档的需求填写相关信息，准备好测试数据文件，添加CSV组件，将http取样器中的固定值转化为动态值，添加察看结果树，发送http请求，分析请求的响应内容是否实现参数化成功。 　　5.Jmeter绕开数据库实现参数化？ 　　向开发拿已写好的相关jar包（mysql，oracle，sqlite），1.在测试计划中添加jar包，2.添加数据库连接配置组件，3.根据需求准备测试数据文件，4.添加CSV组件，5.添加线程组，在线程组中添加JDBC取样器， 6.替换JDBC取样器中的固定值为动态值，7.设置线程组的迭代次数。 　　6.Jmeter造大量加密数据 　　让java开发写好加密函数，并把加密函数打包成加密jar包， 　　1. 在测试计划中添加加密jar包， 　　2. 添加数据库连接配置组件， 　　3. 根据需求准备测试数据文件， 　　4. 添加CSV组件， 　　5. 添加线程组，在线程组中添加JDBC取样器，在JDBC取样器中添加BeanShell前置处理器。 　　6.替换JDBC取样器中的固定值为动态值，7.设置线程组的迭代次数。 　　7.接口性能测试的步骤流程？ 　　我在做接口性能测试时，首先拿到性能指标，然后分析某性能指标，挑选用户使用最频繁的场景来测试，比如：登录、搜索、下单等等。确定性能指标，比如事物通过率为100%，最大并发用户为1000人，cpu和内存的使用率在70%以下。根据该性能指标搭建性能场景，然后编写性能测试脚本，设计性能场景，运行性能场景，分析性能场景的运行结果，收集相关的日志提单给开发，回归性能测试，编写测试报告。 　　如果实际结果达到预期结果（性能指标中的该指标）！ 　　后面步骤不用做啦！ 　　（1）定位性能瓶颈的原因（从TPS指标分析） 　　（2）解决性能瓶颈 　　1) 判断硬件性能瓶颈 　　2) 网络优化 　　电信专线：有固定公网 IP 　　3) 代码方面优化： 　　前端代码和后端代码！ 　　4) 数据库优化：数据库配置优化、sql 优化 　　5) 项目架构优化 　　（3）再用相同场景的再跑一遍！ 　　8. 接口自动化测试？ 　　测试人员根据接口文档，测试人员用接口测试工具 JMeter 或写代码来某对接口发送请求参数、cookie、请求头来验证该接口是否 OK！该验证是由 JMeter 断言或写代码来自动验证。 　　9. 接口自动化测试的流程？（线程组+参数化+断言+关联） 　　(1) 分析该接口的接口文档 　　(2) 写接口测试用例 　　(3) 根据测试用例准备测试数据文件:data.csv（加断言内容） 　　(4) 写 JMeter 脚本 　　(5) 运行 JMeter 脚本 　　10.负载测试？ 　　通过逐步增加系统负载，测试系统性能的变化，并最终确定在满足系统的性能指标情况下，系统所能够承受的最大负载量的测试，负载情况下，场景运行一般是 0.5h~2h 或者大于业务峰值时间 　　11.压力测试？ 　　通过逐步增加系统负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于【失效】状态。 　　12.常用的性能指标？ 　　(1) 服务器硬件资源指标：CPU使用率、内存空闲率 　　(2) 最大并发用户数 　　(3) ART：平均响应时间 　　(4) 吞吐量 Throughput 　　(5) 每秒请求数/每秒数 　　(6) 错误率/异常率 　　做性能测试你需要做些什么准备？ 　　首先要保证相关功能点无重点bug,无影响性能测试执行的bug; 　　其次要准备独立的测试环境，软硬件的配置（电脑，服务器，网络，压机,测试工具，监控工具等）； 　　再者要准备足够的数据，一般要准备1.5年的数据； 　　最后要保证计划用例评审通过，脚本调试完成。 　　当要造大量数据时，你们如何操作？ 　　可以通过存储过程造数据； 　　也可以通过UI自动化脚本，接口自动化脚本造数据； 　　或者是通过性能测试工具录制脚本进行插入数据。 　　请写出你所知的LR 的函数 　　Web_URL(); 调用URL 　　Web_reg_find();插入检查点 　　Web_reg_save_parm();关联 　　Web_submit_data();插入表单 　　Lr_think_time();思考时间 　　lr_randezvours;插入集合点 　　lr_start_transaction;事务开始时间 　　lr_stop_transaction;事务结束时间 　　13.并发数如何确定？ 　　情况 1：性能指标明确告诉你并发数！比如：在 500 人并发情况下！ 　　情况 2：根据业务辅助系统的统计结果来确定并发数！比如：抖音 app 的业务辅助系统确定 　　某业务的峰值并发数是 5W。那么就能确定并发数：5W 　　情况 3：根据自身经验来常规设置并发数。递增时设置。比如：想要测试某系统的服务器最 　　大支持多少并发数。建议：测试环境下，200 并发-》400 并发-》600 并发-》800 并发-》1000 　　并发！ 　　14.接口测试用例组成？ 　　用例编号 所属模块 标题 请求方式 请求地址 前置条件 请求参数 预期结果 实际结果 优先级 　　15.多个接口怎么测（跨线程组怎么测） 　　添加01线程组，线程组中添加http01取样器，按照接口文档填写接口信息，在http01下添加正则表达式提取器，提取登陆token，添加Beanshell后置处理器，使用setProperty将提取到的数值变为全局变量。添加02线程组，线程组中添加http02取样器，使用P函数调取全局变量。 　　16.依赖于登录接口怎么测？ 　　由于http协议是无状态，无连接的，每次http请求都是独立，没有关联的，所以需要提取登陆接口中的登陆凭证。在Jmeter中添加线程组，线程组中添加http取样器，根据接口文档填写登陆接口，在http中添加正则表达式提取器，提取登陆凭证，发送http请求，提取登陆凭证后，添加http01，填写http01的相关信息，带上登陆凭证后发送请求，分析响应内容，是否关联成功 　　8.移动app 　　怎么抓取APP端的动态日志？ 　　首先连接移动端设备，使用adb命令 adb devices查看是否连接到设备； 　　连接成功后，执行命令adb logcat >日志存放路径； 　　打开应用，进行操作（将报错的步骤再操作一遍），然后通过ctrl+c 结束抓取； 　　8.1.移动app崩溃原因？ 　　(1) 设备多样化 　　(2) 宽带限制 　　(3) 网络的变化 　　(4) 内存管理 　　(5) 用户过多 　　(6) 代码错误 　　(7) 第三方服务 　　App crash原因： 　　主要有：内存管理错误，程序逻辑错误，设备兼容，网络因素等 　　1.内存管理错误：可能是可用内存过低，app所需的内存超过设备的限制，app跑不起来导致App crash。或是内存泄露，程序运行的时间越长，所占用的内存越大，最终用尽全部内存，导致整个系统崩溃。亦或非授权的内存位置的使用也可能会导致App crash。 　　2.程序逻辑错误：数组越界、堆栈溢出、并发操作、逻辑错误。e.g. app新添加一个未经测试的新功能，调用了一个已释放的指针，运行的时候就会crash。 　　3.设备兼容：由于设备多样性，app在不同的设备上可能会有不同的表现。 　　4.网络因素：可能是网速欠佳，无法达到app所需的快速响应时间，导致app crash。或者是不同网络的切换也可能会影响app的稳定性。 　　8.2.移动app崩溃的测试用例设计？ 　　测试用例是移动测试最重要部分之一。准备和执行预先定义的针对移动 App 　　崩溃的测试用例将简化和加速移动 App 崩溃的测试。 　　一些通用的触发移动 App 崩溃的测试场景，如下： 　　(1) 验证在有不同的屏幕分辨率，操作系统和运营商的多个设备上的 App 行 　　为。 　　(2) 用新发布的操作系统版本验证 App 的行为。 　　(3) 验证在如隧道，电梯等网络质量突然改变的环境中的 App 行为。 　　(4) 手动把网络从蜂窝更改到 Wi-Fi ，或反过来，验证 App 行为。 　　(5) 验证在没有网络的环境中的 App 行为。 　　(6) 验证来电/短信和设备特定的警报（如警报和通知）时的 App 行为。 　　(7) 通过改变设备的方向，以不同的视图模式，验证 App 行为。 　　(8) 验证设备内存不足时的 App 行为。 　　(9) 通过用测试工具施加载荷验证 App 行为。 　　(10) 用不同的支持语言验证 App 行为。 　　8.3 App测试中ios和Android的区别 　　(1) 操作习惯 　　(2) 多分辨率测试 　　(3) push 测试： 　　Android： home 键，程序后台运行时，此时接收到 push，后唤醒应用，此时是否可以正确跳转； 　　ios： home 键关闭程序和屏幕锁屏的情况； 　　(4) 安装卸载测试 　　(5) 升级测试 　　8.4 App测试流程？ 　　正式测试前先向主管确认项目排期，接收 App测试版本以及送测规范，然后先 UI测试：核对rp/效果图， 功能测试：核对需求文档、兼容性测试、性能压力测试， 尽快申请到正式环境下测试，后台订单统计测试、用户行为统计测试、发送上线报告、回归测试 ，测试还需要产品功能需求文档； 产品原型图； 产品效果图； 行为统计分析定义文档； 测试设备这些，我们测试人员每天需对所测项目发送测试日报，产品上线前，测试人员发送产品上线报告。 　　8.5 APP测试点？ 　　1.安全测试 　　2.安装卸载测试 　　3.UI测试 　　导航测试、图形测试、内容测试 　　4.功能测试 　　运行、前后台交换、免登录、数据更新、离线浏览、定位和照相机、时间测试、PUSH测试、弱网测试 　　5.性能测试 　　极限测试、响应能力测试、压力测试、性能评估、耗电量测试（腾讯电池、金山电池） 　　6.中断交叉测试 　　7.兼容测试（云测平台） 　　8.回归测试 　　9.升级、更新测试 　　10.用户体验测 　　8.6 app专项测试 　　1. 安装测试：检测能否在安装过程中取消安装，内存不足时是否有提示。 　　2. 卸载测试：卸载成功之后对应文件是否删除，app运行过程中能否卸载。 　　3. 更新测试：是否会提示更新版本，能否跨版本升级，升级过程中能否取消升级。 　　4. UI测试：界面能否正常滑动，能否横竖屏切换。 　　5. 性能测试：除了app响应时间之外，还需要耗电量，CUP，流量消耗。 　　6. 兼容性测试：检测不同型号，不同操作系统功能能否正常实现。 　　7. 中断测试：运行APP过程中突然来电，视频通话等操作，APP的运行情况。8. 弱网测试：模拟APP在2G,3G,4G等不同网络环境下的运行情况，是否会出现卡顿，闪退等情况。 　　8.7 App与Web测试的区别？ 　　1）系统构架不一样，App测试是C/S构架，Web测试是B/S构架；Web端更新服务器时，不需要更新客户端，APP端如果更新了服务器，客户端也要跟着更新并测试。 　　2）兼容性测试方法不一样。Web端要考虑不同的浏览器内核进行兼容测试（IE、chrome、Firefox），App的兼容性测试要考虑选择主流机型，包括不同的分辨率、尺寸以及不同的操作系统； 　　3)App要考虑交叉事件测试，前后台切换测试； 　　4)App还要考虑界面操作，如：横竖屏切换，多点触控，事件触发区域； 　　5)APP 在设计界面需要考虑用户的习惯及体验（简洁、简单、移动端输入习惯）； 　　6)因系统架构不一样，APP 还有专项测试： 　　（1）APP 项目需要安装卸载更新测试 　　（2）APP 项目需要考虑弱网测试 　　（3）APP 项目需要考虑干扰测试（阻断测试） 　　（4）APP 项目需要考虑电量、流量、边界测试 　　（5）APP 项目界面测试时需注意手势，横竖屏切换，多点触控 　　（6）APP 项目需要考虑权限测试 　　扩展： 　　1.版本问题： 　　1.1 Linux版本:Centos7.4 　　Tomcat8.5 　　JDK 1.8.1 　　Jmeter 5.4.1 　　1.2一个完整的测试流程： 　　1、需求分析 　　2、制定测试计划 　　3、编写测试用例 　　4、执行测试用例 　　5、提交测试报告及Bug清单报告 　　1.3.常用测试工具 　　1）测试管理工具 　　禅道（简单好用） 　　svn(代码和文档管理工具) 　　git，同svn，但是多分支管理比svn好 　　2）接口测试工具 　　Jmeter（开源） 　　postman 　　jmeter是一款100%纯Java编写的免费开源的工具，它主要用来做性能测试，相比loadrunner来说，它内存占用小，免费开源，轻巧方便、无需安装，越来越被大众所喜爱。 　　Postman是谷歌的一款接口测试插件，它使用简单，支持用例管理，支持get、post、文件上传、响应验证、变量管理、环境参数管理等功能，可以批量运行，并支持用例导出、导入。 　　3）性能测试工具 　　loadrunner，大而全，要学精通还是有点难度，重量级工具 　　jmeter 基于java平台的性能开源测试工具，其实也很强大，而且比较好用 　　4）app自动化工具 　　1）appium 这个应该算是目前最流行的基于app的自动化测试框架了 　　2)Monkey 安卓自带的测试工具 　　3)fiddler抓包工具 　　1.4测试计划主要包含哪些内容，你是怎么写的？ 　　测试计划由测试负责人或有丰富经验的测试人员撰写。 　　包含内容：项目的背景、测试内容、测试目的、准入准出条件、测试通过准则、测试方法、测试人员安排、时间安排、资源、进度安排、风险。 　　1.5测试结束的标准是什么？ 　　从项目周期看： 　　1、超出了所分配的测试时间； 　　2、用尽了分配的测试资源； 　　3、到达了某一个固定的里程碑（如合同规定的交付日期）。 　　从测试角度看： 　　1、测试需求覆盖率； 　　2、测试代码覆盖率； 　　3、测试用例度量； 　　4、缺陷检查度量 　　1.6因果图的问题： 　　因果图，简单来说就是： 　　1.因为什么样的原因会得到什么样的结果， 　　2.因为什么条件和什么条件组合，会导致什么原因 　　3.因果图需要配合判定表使用，工作中使用比较麻烦 　　4.一般工作中，我们会使用场景法和等价类进行代替。 　　当然因果图也会稍带进去。 　　5.毕竟我写的测试点和测试用例在公司里面受到领导和同事的一致好评 　　1.7 交bug时的注意事项 　　（1） 发现一个问题时，不必急着提交，可以先做验证(包括复现、、对比测试等)进行证实，看是概率性问题还是每次必现的问题，需要时也应使用不同版本不同机器做对比验证，当然，如果已经很确信是一个bug了，也就不用浪费时间去对比验证了。 　　（2） 描述要清晰、准确，不要使用含糊的词语(例如，好像，似乎)来描述发现的现象。关于这点，如测试某款软件时，提交一个bug描述为“软件帮助说明中好像有错别字”，并没有说出哪一页哪一行以及具体哪个字错了，应该修改成什么样的。因此就不能说是个好的描述。 　　（3） 要考虑开发人员的感受，有些问题尤其是有些主观性比较强的问题，在问题描述中一般不要出现带强烈感情色彩的词语标点符号，如“要求”、“必须”和感叹号等(特殊情况除外)。在提交此类问题时可以使用一些诸如“建议……”、“希望……”、“请……”之类比较委婉些的词语。 　　（4） 不能确认一个现象是不是一个bug的时候可以向其他人或者开发人员进行确认，然后再去提交。 　　（5） 概率性的问题，测试过程中难免遇到一些概率性问题，很难找出其产生的规律，甚至该问题在测试过程中只出现一次，对于此类问题也一定要提交，并补充说明无法复现或者无规律。 　　（6） 描述问题时，要实事求是，不要夸大，比如概率性问题，本来出现的概率只有10%，你把它写成50%都是不应该的。 　　（7） 提交bug时，应该在描述清楚问题点的时候把正确的预期输出结果写明，即正确的结果应该是什么样的，这点很重要。现在我们提交的bug中有些测试和开发双方都知道该修改成什么样子了，而在bug描述中未写出修改成什么样子的，如“来电时按挂机键不能拒接来电”这样描述一个bug，并没有写明该如何修改，一般这样描述大家一看就知道该如何修改，所以写不写预期正确结果大家都可以接受。但对于有些bug的描述一定要把预期的正确结果给写进去，否则开发人员会无所适从，不知道该修改成什么样子的。 　　（8） 很多时候，提交的bug都需要重现，而有的bug是在测试过程中偶然间发现的，时间一长，会对发现bug时的特定数据或环境模糊，导致不能重现bug。所以提交bug时描述的越详细越好。如果语言文字难以清楚的描述出发现的问题，最好能附件图片或者log记录等做辅助说明。 　　（9） 提交测试bug的时候，如果该问题在某一特定环境下才能出现，一定要将该问题产生的环境(硬件、软件)描述清楚。 　　（10） 提交问题前要清楚的知道软件需求、规格定义。相信很多人都遇到过这样的尴尬情况，提交了一个重要问题后，却被告知其实那并不是一个问题，软件就是那样设计的或者需求就要求那样处理的。 　　（11） 有些问题出现了，不一定就是我们测试软件本身的问题，也可能是其他一些问题。 　　1.8 APP测试 　　1、你怎么做 app测试的？ 　　测试前，先熟悉 app的原型图和业务需求，确定测试点，开发做完接口之后，先做接口测试，App开发好后，先做一个冒烟测试，看看软件的基本功能是否可用，如果正常，我们再做功能测试，UI测试，兼容性测试，交叉事件测试，安装卸载测试等。 　　比如： UI测试：检查 app的 UI是否和原型图一致。 　　功能测试：xxxx 　　兼容性测试：xxxx 　　用户体验测试：xxxx