您现在的位置是：首页 >学无止境 >关于开发测试面试跟经验之谈（三年经验）—直接拿下网站首页学无止境

测试开发面试经验：

1.面试大套路

面试从自我介绍开始，还是应该喷话术，如果自己能喷上20分钟，成功概率会高很多。

对于测试，大家说技能点的时候，把我一条主线 W+H 是什么?怎么用的！

2.说一下测试用例

嗯，做测试，好多时间是在琢磨分析测试用例怎么去写，这个每个公司规范可能不太一样，但是大致思想是一致的。都是想要通过测试用例，把每一个分析到位，进行测试。
就拿我上家公司来说吧，我们的测试用例包括像测试编号，测试所属模块，测试步骤，预期结果，测试结果这些栏位，当然这些还可以在细分，比如我们有些时候还会根据模块差异，平台差异等设计其他测试用例规范形式。
测试用例编写的话，一般是根据产品需求来定的，比如一个注册功能，产品需求上需要验证哪些，用户名，密码，邮箱，等等有什么要求，根据这个产品效果图或者产品需求来定测试用例怎么去编写。当然还要考虑到普通用户使用软件的习惯，以及一些特殊情况和极端情况。
写测试用例，这个测试用例要有一定的代表性，针对性，当然需要有复现性，不能是我们测出的bug无法复现，这样没有意义。
对于测试常用的方法，一般有这么常用的几种，有等价类划分法， 就是一类信息，我们在测试的时候，只测试一种，没有必要所有的都进行测试。还有像边界值法，一般注册登录的时候，或者涉及到数学测试的时候，会用到。我**项目中就用到了边界值测试法，比如需要上传学生成绩信息，做数据分析，学生成绩的测试用例，就牵扯到边界值法。还有一些场景法，设定不同的场景，不同场景就会有不同的操作。
嗯，这是写测试用例时我们常用到的测试方法。
当然，测试用例还需要注明软硬件环境，比如是mac和windows，是pc端还是移动端，这些环境信息。
我们写测试用例，上上家公司，一开始测试经理让我们使用excel来写，不过使用excel效率太低了，后来我们使用bug管理工具，禅道，可以在软件上写测试用例，也可以直接将测出的bug直接转成测试用例，效率上提高了不少。

当然，上边我所提的是功能测试，当然性能测试用例也不太一样，用例id，测试步骤，测试模块这块是一样的，但是性能测试用例里边我们一般还会包含，事务设置，前置条件等信息，事务设置，就是在做压测或者负载测试的时候，我们会设置一些事务，从xx开始到xx结束，叫做一个完整的事务，前置条件就是在执行这些测试，是否有什么必须的条件，比如是否要登录。

再就是设计测试场景，这块是性能测试特殊的地方。比如在用例中指定并发用户数，指定压力方式，是随机，还是一次启动，还是逐步递增，指定负载测试时间，是10分钟还是1小时，把这些信息也要包含到用例中。

还有就是期望结果，期望结果应该包含多项内容，比如事务成功率，CPU利用率，内存利用率，硬盘利用率，响应时间等信息，这些的预期结果都是跟我们的测试需求上相匹配的。
用例描述
用例ID 1
业务名称 首页、博客、学院
URL www.csdn.net
权重 高
前置条件 成功登陆CSDN
测试步骤 1、使用Jmeter录制脚本,添加线程组（线程数30，循环5次），添加HTTP请求（www.csdn.net）,添加录制控制器；
2、在工作台添加HTTP代理服务器，指定端口号8888，点击启动；
3、打开浏览器设置手动代理（127.0.0.1,8888），访问CSDN首页、博客、学院；
4、添加监听器：聚合报告、结果树、表格结果、图形结果并观察数据；
事务设置 事务名称 起始位置
访问首页 www.csdn.net
访问博客 blog.csdn.net
访问学院 edu.csdn.net
场景设计
NO 业务 并发用户数 压力方式 压力时间 运行时设置
1 访问首页 30 随机加载 5:00 循环5次，节奏随机，思考时间5秒
期望结果
NO 测试项 事务平均响应时间 90%响应时间 事务成功率 CPU利用率 内存利用率 硬盘利用率
1 博客 2s内 3s内 90% 50% 100M
2 学院 2s内 3s内 90% 50% 100M
实际结果
NO 测试项 事务平均响应时间 90%响应时间 事务成功率 CPU利用率 内存利用率 硬盘利用率
1 博客 36416毫秒 42014毫秒 54%
2 学院 42013毫秒 69382毫秒 67%
测试执行
执行人 纪运旺 执行日期 2018/3/22

3.测试分为哪些种类

我理解的测试种类的话，就分为功能测试，性能测试和自动化测试。当然还有其他的一些名词，你比如说咱要是按照阶段来进行测试划分的话，又可以说分为单元测试，集成测试，系统测试，还有验收测试。又可以根据懂不懂代码，分为白盒测试和黑盒测试，还有一些其他的测试，比如回归测试，冒烟测试，还有随机测试。像这个测试种类可是太多了。
3.1.功能测试
我就重点说一下这个功能测试吧，功能测试，我们主要是测试软件功能是否可用，当然功能测试也不是这么简单，我们要测试逻辑功能，就是这个操作是否符合正常人的逻辑思维，你比如说，我用智联招聘，就感觉它有一块功能做的不好，一般我们是先登录，没有账号的话才进行注册，而智联招聘，我进入到主界面，输入完信息准备登录，才发现默认是注册，这个就属于一块逻辑上的问题。当然问题还不算很大。还有界面测试，就是界面正常操作，是否都能够执行成功，比如注册能够执行成功，注册结束之后，能够跳转到登录界面，这个就是进行界面测试。还有就是测试这个软件是否容易使用，也就是易用型测试，如果不好用，用户操作不了，也可以算做一个bug。还有兼容性测试，比如我们测试Android手机上的应用，就经常有兼容性的问题，比如分辨率兼容问题，Android的App分辨率我们就需要使用多台不同尺寸分辨率的手机进行测试，还有性能兼容问题，咱们国内都对手机源代码进行了改动，同一款app，可能在华为上好使，在小米，锤子，oppo上不好使。这些都是功能测试的范围内容。
3.2.性能测试
3.2.1.性能测试整体概念
时间性能:软件的一个具体事务的响应时间。比如点击一个登陆按钮，到登录成功(失败)的反应时间，浏览器非常常见，ANR（Application not responding 应用程序无响应）
空间性能:软件运行时所消耗的系统资源，比如对内存和cpu的消耗
一般性能测试:软件正常运行，不向其施加任何压力的测试
稳定性测试:也叫可靠性测试，是指连续运行被测系统，检查系统运行时的稳定成都。
负载测试:让被测系统在其能够忍受的压力范围之内连续运行，来测试系统的稳定性。
压力测试:持续不断的给被测试的系统增加压力，直到被测试的系统压垮为止，用来测试系统所承受的最大压力。

3.3.自动化测试
自动化测试,一般就需要使用脚本来进行测试，也可以叫做白盒测试，技术含量相对来说比较高，这个我也会。我会的语言是python，基本上python的代码基础我是掌握了的。比如python的变量和基本数据类型，输入输出语句，集合和元组操作，以及循环和条件判断操作，还有python中的字典和set集合操作，以及python中面向对象编程，异常，单元测试这些内容，比较熟悉。
自动化测试软件:selenium和appium这两个软件我也使用的比较熟悉，当然也算不上精通，基本的操作，写一些自动化测试脚本是没有问题的。
3.4.静态测试和动态测试
静态测试，是指不实际运行被测试软件，而只是静态的检查程序代码、界面或者文档中可能存在的错误的过程。
动态测试:是指实际运行被测程序，输入相应的测试数据，检查实际输出结果和预期结果是否相符的过程。
3.5.单元测试、继承测试、系统测试和验收测试
3.5.1.单元测试
是指对软件中最小可测试单元进行检查和验证
单元测试当一段代码完成之后，是由白盒测试工程师或者开发人员自行测试，比如java中执行单元测试叫做junit测试。
目前大部分公司单元测试由开发人员简单编译和调试一下自己的程序，没有相应的单元测试计划。
单元测试方式:先静态地观察代码是否符合规范，然后动态地运行一下代码,检查运行的结果。
3.5.2.集成测试
集成测试是单元测试的下一个阶段，是指将通过测试单元模块组装成系统或者子系统，再进行测试，重点测试不同模块的接口部分。
集成测试也是由白盒测试或者开发人员来完成。
3.5.3.系统测试和验收测试
集成测试完成之后，就是系统测试和验收测试。
系统测试:指的是将整个软件系统看做一个1个整体进行测试，包括对功能、性能，以及软件所运行的软硬件环境进行测试。
系统测试由黑盒测试人员在整个系统集成完毕后进行测试，前期主要测试系统的功能是否满足需求，后期主要测试系统运行的性能是否满足需求，以及系统在不同的软硬件环境的兼容性等。
3.6.回归测试、冒烟测试、随机测试
3.6.1.回归测试
是指对软件的新版本进行测试时，重复执行上一个版本测试时的用例，比如在1.0版本中，有一个bug，到了2.0版本中,再重新测试1.0中这个bug
3.6.2.冒烟测试
指对一个软件进行系统大规模的测试之前，先验证一下软件的基本功能是否实现，是否具备可测性。
测试小组在正式测试一个新版本之前，先指派一两个测试人员测试一下软件的主要功能，如果没有实现，则打回开发组重新开发，这样做可以节省大量的时间成本和人力成本。
3.6.3.随机测试
是指测试中所有的输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性的错误。

4.Web应用测试方法

4.1.兼容性测试
操作系统兼容
windows windows7 win8 win10
mac
ubuntu centos(Linux)

浏览器兼容
IE 8,9,10
Chrom
fireFox
safari 苹果出的
欧朋浏览器
其他主流市场
QQ浏览器
360浏览器
搜狗浏览器

分辨率兼容
16*9
…

4.2.安全性测试
常见的安全性测试：
⑴用户验证：登录密码验证、IP地址访问限制等
用户超时:登录超过30分钟，重新登录(安全设置，cookie过期时间30分钟)
⑵用户权限管理:验证低级别用户是否具有了高级别用户的权限，各级别用户权限都得到了实现。
⑶系统数据的保护:对例如系统文件、用户密码文件等进行隐藏、密码验证、内容加密、备份。

功能安全类

sql注入
xss攻击(跨站脚本攻击)(脱敏，加密)
攻击的浏览器
业务安全类:
账户
资金
数据传输，加密敏感信息脱敏
超时验证
角色验证
所有权验证

4.3.可用性测试 & 逻辑功能测试
页面,页面元素、功能部分、提示信息、容错性、权限部分、键盘操作

页面，页面元素部分
（1）页面清单是否显示，是否显示完整（3） 页面在窗口中的显示是否正确、美观（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示(5)页面元素是否显示正确(6)页面元素的容错性是否存在

功能部分
（1）数据初始化是否正确
（2）数据操作(增删改查)是否正确

提示信息
（1） 操作页面成功、失败提示
（2） 危险操作、重要操作提示(比如删除某些重要的信息)
容错性
（1） 为空、非空,唯一性
（3） 特殊字符 、双引号，符号
权限部分

功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。
4.4.响应时间测试
看页面的 渲染时间
看数据的返回时间等等

5.手机端测试

5.1.What
5.1.1.介绍手机测试的概念架构
对于手机端测试，按照平台来分，分为Android和IOS两大主流系统，
对于ios和Android，二者有区别，我就说一下我在测试这两款手机app的感受吧
Android开源导致碎片化比较严重，bug比较多，而IOS通常bug会少一些。
Android手机长按home建，会呼出应用列表和切换应用，右滑择会终止应用。
还有分辨率测试，Android手机分辨率有20多种，IOS较少一些
再就是手机操作系统，Android系统太多了，IOS较少，但是升级之后不能够降级，不过呢，发现了最近ios中boss直聘的一个bug
是有关于Boss直聘强更的一个bug，当我们点击手机APP端 Boss直聘 进入主页面弹出提示框“新增邮箱上传附件简历功能” 弹窗中有立即升级的链接，点击别的区域没有反应；
必须点击“立即升级”才会跳转到“App Store”若不升级，重新切换回Boss直聘界面，依旧提示“立即升级”全部退出依然如此。我继续说哈

按照目前技术架构的话，现在有一些原生的app架构，类似于Client Server架构，也有基于Html5的app，类似于pc机的BS(Broswer server)架构。手机测试和pc机类似，又有一些不同的地方。

当然除了手机，现在还有好多使用Android系统，比如酒店点餐的平板，银行对公或者对个人业务的业务平台，还有一些智能的穿戴设备，小米的手环，google 联想的智能眼镜，智能家居，电视盒子，这些都是在使用android系统，我之前最早的时候，就要测试过一个智能家居设备，测试的时候需要考虑蓝牙，wifi连接传输这块，也有好多要测试的内容。

5.2.How
5.2.1.功能测试
我就先来说一下功能测试吧，对于手机app来说，和我们测试web项目差不太多，也是各种测试方式需要考虑进来，比如说逻辑功能测试，现在移动端越来越火爆，大家用的软件也越来越多，对软件也越来越挑剔，现在公司在开发移动端的时候，肯定是有相应的需求文档和UI所设计的产品效果图，我们做逻辑功能测试，就是根据这些资料，当然也根据我们正常人的逻辑思维进行逻辑功能测试，就拿我上个项目来说，它就是一个移动端项目，在做逻辑功能测试的时候，我们要测试主页面，我的页面，商城页面这些功能是否合理。
5.2.2.安装与卸载测试
软件安装后是否可以正常运行，安装过程中是否可以取消,安装空间不足时，是否有相应提示,是否可以卸载应用（可通过桌面卸载，也可以通过软件卸载。曾发现在IOS手机上有个应用安装时未完全安装，终止安装后，未完成安装的应用图标一直显示在手机上，并且无法成功删除）,卸载是否支持取消功能，单击取消后软件卸载功能是否正常,卸载后文件是否全部删除所有的安装文件夹,从不同的应用市场下载进行安装测试，比如测试小米市场，华为市场，应用宝，安卓市场，安智市场的安装测试。

5.2.3.软件升级测试
当客户端有新版本时，是否有更新提示当版本为非强制升级版时，用户可以取消更新，老版本能正常使用，用户在下次启动app时，仍能出现更新提示；当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端，下次启动app时，仍出现强制升级提示，当然现在强更已经很少出现了。检查更新后各个功能是否能正常使用；在线跨版本升级后能否正常使用，当然现在主流的安装更新方式开始向热更新热部署方式转变，就是在用户不需要手动更新的情况下，完成版本的静默更新，这个技术是有难度的，需要看公司中程序员的技术能力还有就是是否有这样的产品需求。

5.2.4.登录测试
对于登录测试，基本上每一款app都有登录注册功能，所以在测试App的时候，登录测试是必不可少的一项。
我们做登录测试的时候，往往包含这么些项，登录用户名和密码错误时，界面有提示信息
用户主动退出登陆后，下次进入app时，应该进入登陆界面
密码更改后，登录时是否做到了有效数据的校验，对于未登录状态时，一些页面的操作，是否做了控制
切换账号登录，检验登录的信息是否做到及时更新，对于多个端（web、iso、android等）进行操作时，确保数据库操作无误，且每个端可以及时看到数据的更新,一个账号只允许一台机器登陆的软件，需要账号登录多个手机时，是否将原用户踢下线，且能够给出提示信息,用户登录状态太久，session会过期，会出现“虽然是登录状态，系统会提示用户没有登陆”

5.2.5.安全性测试——权限测试
对于手机权限，如果我们是刚开发不知名的app，权限这块尽量少一些，这些权限在安装的时候都必须用户同意。在Android 6.0之后，权限需要动态的申请，我们测试的时候,需要测试在使用到这些权限的时候，程序员是否做逻辑判断，用户同意权限应该怎么操作，不同意权限又应该怎么操作。
5.2.6.消息推送测试
消息推送，是移动端的一大特色。我就说一下消息推送我们所做的这些方面吧，未锁屏时，应用后台运行，消息推送是否可正常接收，未锁屏时，APP客户端使用过程中，可以收到消息提醒，且点击可查看。
锁屏时，手机消息栏是否可以接收到消息提醒。且点击可查看。点击后消息栏中消失。
当推送消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误的将其他人的消息推送过来
push推送消息是是否能有针对性的推送，如相应内容推送给相应用户（精准推送）
退出登录后，是否接受push推送（根据需求来）
5.2.7.前后台切换测试
APP切换到后台，再回到APP，检查是否停留在上一次操作界面；检查功能及应用状态是否正常；程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候
手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常
当APP使用过程中有电话进来中断后再切换到APP，功能状态是否正常
当关闭APP进程后，在开启APP，APP能否正常启动
对于有数据交换的页面，尤其是有视频图片之类的页面，每个页面都必须要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃

5.2.8.UI测试
确保产品UI符合产品经理制定的原型图与效果图
一般涉及界面（如菜单、对话框、窗口和其他可视控件）布局、风格、文字是否正确，页面是否美观，操作是否友好。
如：安装app后的加载页显示，分享页面的产品logo显示

5.2.9.兼容性测试
我再说一下兼容性测试吧，兼容性测试主要考虑手机的版本，型号，分辨率，就像我说的，现在手机碎片化比较严重，各个版本，比如Android，从Android4.0到Android8.0的版本它是不一样的，然后现在各大手机厂商像华为，三星，小米，锤子，魅族，vivo这些厂商都修改android源代码，也是给我们增加和好多工作量，好多时候开发的软件在三星上没问题，但是华为，小米就不行。还有手机分辨率，现在主流的可能是19201080，但是还有好多其他分辨率，比如7201280，还有一些更大分辨率的手机，都要考虑这些分辨率的兼容，不然用户视觉体验就不好。
兼容测试，公司中会买好多测试机来太让我们进行测试，一般是不同厂商的手机，当然还有第三方云测平台，比如testin还有腾讯wetest，就可以做兼容性测试。可以一次性测试100台测试机，同时会有相应的兼容报告，bug报告。

对于IOS，ISO版本有7.1.2、8.3、9.1等；能否适配各种屏幕尺寸。
5.2.10.网络环境测试
测试2G、3G、4G、wifi、有网、无网、弱网情况下应用的运行
网络不好时，提交数据是否一直处理提交中，是否会有延迟，数据交换失败是否会有提醒
有网到无网再到有网环境时，数据是否可以自动恢复，正常加载
无网络时，各种提示信息是否友好，数据本地化是否正确（比如提示当前已断开网络，请检查网络设置；还有从wifi环境切换到4G环境提示是否启用4G网络，会产生扣费。

5.2.11.mokey测试
对于手机测试，除了我们一些常规的功能测试，我们还会做压力测试，比如对于Android手机，我会使用adb指令进行一些相应的操作，比如通过adb查看设置，进入设备，抓取log，我们测试的时候，会使用adb logcat所抓出来的log日志存到电脑，发给开发，方便他们快速解决bug。
另外，我还会使用monkey对app进行测试，可以使用monkey对app做压力测试，主要就是测试操作app的时候，程序是否会崩溃。
我们使用adb shell monkey 指定对应的app，执行要测试的次数，指定要触摸的比率，超时时间和忽略崩溃信息，就可以执行测试，将测试log存到某个位置，然后把测试出的bug 日志发送给开发。300000

我就简单的说一下测试的指令吧，比如我上边所说的逻辑，我们用 adb shell mokey -p 指定要测试的包名 --ignore-crashs 忽略崩溃 --ignore-timeout 忽略超时 --throttle 38指定延迟时间毫秒 -s 指定测试种子 指定测试次数，然后将文件 >输出到磁盘中。

5.2.12.性能测试

对于性能测试，（eclipse和Android studio中本身有检测cpu和内存的工具，也有检测手机内存泄漏的工具）靠工具来测试手机cpu占用，内存占用，电池温度等，以及测试我们的app在后台持续运行的流量消耗和电量消耗问题。

6.APP测试与web测试的区别
相同点：
同样的测试用例设计方法；
同样的测试方法；都会依据原型图或效果图检查UI；
测试页面载入和翻页的速度、登录时长、内存是否溢出等；
测试应用系统的稳定性
不同点：
app的中断测试：来电中断、短信中断、蓝牙、闹钟、拔插数据线、手机锁定、手机断电、手机问题（系统死机重启）
app的安装卸载：全新安装、升级安装、第三方工具安装、第三方工具卸载、直接卸载删除、消息推送测试、手机授权测试、前后台切换、网络环境（wifi/2G/3G/4G/无网络）
兼容性测试：web项目考虑不同浏览器的兼容；app需要考虑手机不同操作系统、不同机型、不同屏幕等
web自动化测试工具较常用：selenium，而手机自动化monkey、monkeyrunner
4.app测试平台：百度云测、testin云测--------

7.接口测试话术

7.1.Why
程序进行集成测试的时候，需要测试各个模块的接口的连接问题。或者是程序是前后台分离的，暂时没法通过界面测试，就使用接口测试，并且，在查看信息安全，请求参数和结果方面，接口测试比较方便。测试的重点是要检查数据的交换，传递和控制管理过程

7.2.How

接口测试,根据接口文档，进行测试，包含接口的url，请求参数，响应结果。

我们在测试的时候，跟测试有页面的应用一样，也是使用等价类划分法，边界值这些方法来测试，在使用接口测试的时候，只需要调整请求参数就可以。

接口测试，我一般使用的是postman，测试的时候这几个方面:
改变请求参数，看响应结果是否和接口文档一致
查看参数是否有敏感信息（比如个人账户信息，资金信息）
查看是否对关键参数进行加密处理(密码信息)
所有列表页接口必须考虑排序值
接口返回的图片地址能否打开，图片尺寸是否符合需求；
接口有翻页时，页码与页数的异常值测试；
当输出参数有联动性时，需要校验返回两参数的实际结果是否都符合需求
每个接口入参的默认值、异常类型、非空校验
入参支持多个值时，要考虑传的值的个数多的情况下，接口会不会报错

8.性能测试话术

8.1.What
性能测试，是为了获取或者验证系统性能指标而进行的测试。

对于我们测试，一个系统如果仅仅通过功能测试就发布出去，是很危险的，也是不允许的。系统必须通过性能测试，当然还要有安全性测试，兼容性测试等，才能够对外发布。

对于性能测试，并不是简单的描述为系统性能好，反应速度快，就行了，这种描述比较含糊，通常我们测试一个系统，项目经理或者产品经理都会提出这个系统的性能需求，比如系统在正常负载下必须3秒内做出响应，一分钟能够接收至少50个请求，会提出比较明确的需求，当然，有的项目经理不提，那我们的测试经理也应该去问，或者定出性能需求来。

一般情况下，性能需求包含这么几个方面:

1)最终用户体验，例如2-5-10原则，即按照正常用户体验，如果用户能够在2秒内得到响应，会感觉速度很快，如果2-5秒得到响应，用户感觉系统的响应速度还不多，在5-10秒之内得到响应时，用户会感觉系统的响应速度慢，但是可以接受，超过10秒后还没有响应，用户就会感觉不能够接受。
2)商业需求，做一个系统，还需要考虑竞品(竞争产品)，一般我们要求系统性能比竞争对手高10/20%,当然，也不能比竞争对手低超过10/20%.
3)技术需求,当服务器cpu使用率超过80%时，客户端的请求就不能及时处理，需要排队等待，就会影响用户体验，所以从咱们技术角度讲，需要定义一个性能指标就是cpu使用率不超过70%，内存占有率不能超过50M
4)标准要求:软件行业有一些标准要求，比如对时间要求，如客户端连接时间，系统响应时间，单笔业务处理时间，页面下载时间。容量要求，也就是系统正常工作的时候，能承受到最大容量，最大并发在线用户数，数据库系统中的最大记录数。当然这些参数是指我们系统能够正常运行的指标。数据吞吐量，系统单位时间内处理的数据量，如每秒处理的请求书，每分钟打开的页面数，每秒传递的数据包量。

比如:我们的性能需求是，30个在线用户按照正常操作速度访问网上购物系统的下订单功能，下订单交易的成功率是100%，而且90%的下订单请求响应时间不超过5S，当并发在线用户数达到100个时，下订单交易的成功率大于98%，其中90%的在线用户的请求响应时间不大于用户的最大容忍时间10S。
8.2.How

8.2.1.第一步，确定关键业务，关键路径。
做负载测试，并不是对所有的业务，界面和接口做负载测试，这样工作量太大，通常我们会寻找关键任务，也就是找到用户最常用的功能模块进行负载测试。比如对一个网站，首页是用户访问必经之路，最起码是用户访问频率最高的页面之一，再就是对一个电商网站，99%的客户只是搜索商品，只有1%的客户将真正购买，商品搜索和列表显示等功能是用户经常用到的，这块数据库的操作有可能就是性能的瓶颈。所以，我们就会把搜索啊，数据库存取这块功能视为“关键业务”。我们做负载测试，就是对这块关键业务进行负载测试。

8.2.2.第二步, 确定输入参数和输出参数，指定负载测试方案。
做负载测试，常见的参数有这么几个方面：
(1)并发用户数，一般会通过测试工具模拟虚拟用户，并发用户数越多，则连接的数目越多，系统所受的负载越大。
(2)思考时间，也就是用户发出请求之间的间隔时间。用户在进行操作的时候，总是有思考，有停顿，这个就是思考时间，可以通过软件模拟出来，在相同的并发用户数的情况下，每秒发出一个请求和每10秒发出一个请求，负载差别很大，咱就拿100个并发用户数和一分种单位时间计算，前者发出的请求时6000次，后者就是600次。负载就差很多了。
(3)加载的循环次数或者持续时间，循环次数会直接影响负载测试时间。
(4)请求的数据量，每次请求发送的数据量，数据流越大，系统所受的负载越大，比如同时请求一个url和同时播放一个视频，对系统的负载压力是不一样的。
(5)用户加载的方式，比如一次加载，就是一次性加载某个数量的虚拟用户(virtual user)，比如有的网站在早晨上班的时候，访问比较频繁，向智联招聘这样的网站就是。

递增加载，有规律的增加虚拟用户的数量，比如每几秒增加一个用户，交错上升，这样能够在递增用户的时候，发现性能拐点，确定负载极限，或者查看多少并发的时候能能够超过响应时间的阈值。
当然还有随机加载，高低突变等加载方式(一会儿加载很多，一会儿加载很少)

对于输出参数，就是我们要监控的数据，一般情况下，会监控这些参数。
数据传输的吞吐量，数据处理效率，数据请求的响应时间，内存和cpu使用率。
对于这些参数，我们在使用jmeter或者是loadRunner的时候都能够监测的到。

8.2.3.第三步，准备测试环境，完成脚本录制或者测试脚本开发。
对于测试环境的准备，每个工具是不同的，但是基本原理类似，一般就是需要录制脚本，或者指定要测试的接口地址。
8.2.4.第四步, 设计测试场景，比如负载水平，加载方式以及其他参数
对于测试场景，一般分为静态和动态的两个部分，静态的比如设置用户生成器，用户数量，用户组等。对于设置虚拟用户，jmeter是设定线程组，而loadRunner来说就是指定虚拟用户的个数。
动态部分主要指添加性能技术器，检查点，阈值等，从而获得负载测试过程中反馈回来的数据–系统运行的动态状态。

对于loadRunner还可以对场景进行设置，比如设置手动场景，手工为每一个录制的脚本分配要运行的虚拟用户的百分比。
还有面向目标的场景，就是服从于一个具体的性能指标来实施负载测试，如每秒20次的点击，每秒5个事务处理，每分钟下载50个页面，达到虚拟并发用户数500等。

对于loadRunner还可以设置同步点，比如我们在测试计划中要求系统能够承受500个用户同时提交订单，当在提交订单之前设置一个同步点，当虚拟用户没有达到500个时，负载测试工具可以让先到达这一点的虚拟用户暂时停下来，处于等待状态，当足够的虚拟用户到达同步点时，才执行所设定的动作。
8.2.5.第五步，执行测试，观察或监控输出参数，比如数据吞吐量，响应时间，资源占有率等。

8.2.6.第六步，对测试结果进行分析，如果是测试设计问题，重新调整测试场景，如果系统测试有指标达不到要求
分析测试结果，是一个关键点，要求我们测试善于捕捉被监控的数据曲线发生突变的地方，就是拐点，这一点就是饱和点或者性能瓶颈。

例如，以数据吞吐量为例，刚开始，系统会有足够的空闲线程去处理增加的负载，吞吐量会以一个稳定的速度增长，然后再某一个点上稳定下来，达到系统的饱和点。对于饱和点，我们就可以理解为，所有的线程投入了使用，传入的请求不再被立即处理，而是放到队列中，新的请求不能及时处理。如果继续增加负载，执行的队列开始增长，系统的响应时间就随之延长，再继续增加负载，系统的响应时间就会发生图片，使执行队列排得过长，无法处理，服务器接近死机或者崩溃，响应时间就变得很长或者根本无法响应，即性能出现拐点，负载达到饱和。

另外，在负载接近极限的情况下，不仅响应时间急剧增大，而且事务处理的错误率也越来越高，例如会出现连接服务器失败或者超时错误，造成这些问题的原因可能是:
系统资源使用率很高，如长时间cpu使用在100%，从而导致请求操作超时。
由于连接太多，服务器端口太忙，不能及时提供服务数据包的传输；
当前页面的数据流太大，可能因为页面内容多或者数据库存取太频繁。
客户端连接请求被服务器拒绝，可能因为服务器的一些参数设置不合适。

通过分析负载测试中系统容易出现瓶颈的地方，从而有目的地调整测试策略或测试环境，使压力测试结构真实地反应出软件的性能，例如，服务器的硬件限制，数据库的访问性能设置。

8.3.性能测试常见的问题
8.3.1.资源泄漏
包括内存泄漏，系统占用的资源(如内存，CPU等) 随着运行时间不断增长，从而降低系统性能，系统响应越来越慢，甚至系统出现混乱，只有重启系统才能恢复到最初的水平，这类问题产生的主要原因是有些对象没有被及时销毁，内存没有释放干净，缓冲区回收等。

8.3.2.CPU使用率达到100%，系统被锁定等，

有可能是程序员的代码中存在无限死循环，缺乏保护（如对失败请求的不断重试），频繁对数据库存取，没有使用数据缓存功能。

8.3.3.数据库连接成为性能瓶颈
可能因为数据库存取交互过多，没有使用连接池或者连接池配置参数不当，单个SQL请求的数据量过多等问题，采用监控工具(p6spy)分析程序与数据库的交互(sql数量和响应时间)，发现此类问题。

8.3.4.查询速度慢或者列表效率低
主要原因是列表查询未使用索引，过于复杂的sql语句，分页算法效率低等；也可能是查询结果集过大或不规范的查询，如返回全部的数据，查询全部字段而不是所需字段。

9.介绍一下压力测试

Jmeter版本
9.1.Jmeter-What
一般情况下，我们提压力测试，通常指是指负载测试和压力测试.
我们做压力测试,基本上会使用到工具进行测试,我常用的工具，一个是jmeter，另外一个是loadRunner。
我先介绍一下jmeter吧，jmeter是Apache组织开发的基于java的压力测试工具，支持接口测试，压力测试，还可以做录制回放操作，操作比较简便。
9.2.Jmeter-How

9.2.1.整体流程

我先说一下JMeter的操作的整体流程吧，我们测试的时候，通常是创建一个线程组，指定并发的线程数量，然后指定要测试的接口，创建相应的监听器，比如表格结果，结果树和聚合报告信息，通过监听器来监听测试是否通过或者接口是否存在什么问题

另外，jmeter中还有一些重要的组件信息，像逻辑控制器，比如循环控制器，比如事务控制器等相关的控制器。还有一些配置原件，比如可以配置http请求的请求头信息，配置Cookie信息管理器，可以配置CSV配置文件信息，从配置文件中读取出参数。

当然，我们在做测试的时候，并不是单拿一个接口进行测试，我们往往也是进行脚本的录制。对于Jmeter脚本录制可以使用badboy或者jmeter自带的http代理服务可以进行录制，我在公司里通常是使用badboy进行录制，这个badboy是一个第三方的软件，它本身也可以做压测，也可以导出测试报告，但是它的压测功能相对弱一些，我们通常就是使用badboy录制脚本，然后导出到Jmeter中进行压测。另外，Jmeter还提供自带的录制方式， 就是在工作台上添加http代理服务器，指定相应的代理服务器的端口。配置对应的浏览器，我一般使用火狐或者google浏览器多一些。配置完之后，我们浏览器的请求，就会被录制到录制控制器中，当然，这里请求信息会非常多，我们需要对这些信息进行过滤，把无关的信息给它过滤掉。当把响应的请求操作录制下来之后，我们就可以在线程组中指定线程进行相应的压力测试了。

Jemter除了可以进行web端录制外，还可以进行App端录制，我们可以将手机上的请求操作抓取到，进行压力测试。对于他们开发来讲，App中接口太多了，我们测试人员有些时候根本拿不到所有的接口信息，甚至有的公司没有完善的接口文档，这个就需要我们自己去抓取测试的请求包。当然抓包有专门的工具，你比如说fiddler，还有charles这些工具是能够将包抓到的，但是我们还得每个包的进行测试，效率太低了，通过jemter我们可以直接录制手机上的操作，将所有的请求抓取到，然后执行线程组和循环控制器进行相应的压力测试，这样会提高不少的工作效率。

对于Jmeter还有比较重要的一点，就是检查点，如果不设置检查点，那我们的测试到底是成功还是失败，这个是没法判定的。在Jmeter中，我们可以对请求的响应结果设置断言，断言可以指定是包含，还是匹配什么内容，如果匹配不上，在请求的结果树中会显示相应的错误信息。当然我们也可以指定断言结果的监听器，来监听断言是否执行成功。

一般情况下，Jmeter生成的测试结果，都是表格类型的结果，比如聚合报告，会反应出每秒点击次数，吞吐量，响应时间，错误率等信息，但是我们没法看到一个折线图，这个在进行数据分析的时候，不太方便。这个我们可以使用Jmeter的插件来完成，这个需要把相应的jar包拷贝到JMeter中，想要监听服务器CPU，内存或者磁盘IO读写，需要在服务器上配置一个server Agent(服务代理)，打开这个Server Agent我们就可以检测到服务器上的数据了。

9.3.问题
在使用Jmeter的时候，我碰到过这样一个问题，就是用户session关联的问题，咱们知道，在网站有登录功能的时候，我们会获取到一个sessionID，这个sessionID是唯一的，代表一次唯一的会话，每次登录都是一个新的值，当我们使用badboy录制脚本，导入到Jmeter中时，在执行线程组时候，发生过用户session过期的问题，因为我们在Jmeter中使用的session是一个定值，导致登录失败。这个我是这样来解决，在登录的时候，我们获取到这个session，然后设置一个后置处理器–正则提取器将这个session提取出来，作为一个变量，在进行其他操作的时候，使用这个变量就可以了。这样就完美解决这个问题。

9.4.LoadRunner-What
loadruner是一种有预测系统行为和性能的负载测试工具，相对Jmeter而言，loadrunner是一个稍重量级的测试工具，功能比Jmeter强大很多。
9.5.LoadRunner-How
对于loadrunner的使用，主要分为这几个方面，一个是虚拟用户生成器，一个是Controller，还有一个分析器。我就先说一下虚拟用户生成器把，我一般管它叫做 VUG virtual User Generator
9.5.1.VUG
VUG会帮我们创建虚拟用户脚本，通过录制和回放的原则进行工作，当我们完成对测试软件的业务流程操作之后，Vug会记录操作，按照每一步骤，翻译成脚本，我们从而可以执行脚本，进行模拟操作。
并且，loadRunner在脚本回放，可以做好多设置，比如设置运行次数，设置两次脚本执行的中间间隔，设置停顿时间，还可以log级别信息。
在执行loadRunner脚本录制的时候，有一个比较重要的问题需要注意，就是用户会话问题，有些模块，在测试的时候，会生成一个会话id，比如登录功能，当用户登录成功之后，会为用户生成一个唯一的session ID，用户后续的操作，都是基于这个session ID，那我们如果使用loadRunner录制时所生成的那个sessionID，后续的操作就会报错。
LoadRunner在执行回放的时候，可以设置值得关联，将session ID设置成动态的，当回访脚本，会使用最新的session ID，来避免这个问题。
9.5.2.Controller
我再来说一下loadRunner中的Controller组件操作，controller主要是用于创建负载测试场景，我们可以模拟多个用户并发执行vug录制的脚本操作，并且controller可以对每个用户的操作都做个性化的设置，比如有的用户使用goole浏览器，有的用户使用ie浏览器，不同的用户访问频率，间隔都不一致都操作，都可以通过controller模拟出来。
Controller在操作的时候，可以指定要进行负载测试的脚本，可以指定设置虚拟用户的场景，可以在设计板块中指定虚拟用户的个数，以及虚拟用户启动的方式，比如一次全部启动，或者逐渐启动方式
设置启动的时候，需要设置负载发生器，主要需要关联要测试的web项目的服务器位置，才能连接上，想要检测服务器，需要点击服务器资源，关联服务器ip，这样就建立了对服务器的监测，服务器的状态信息，就可以在此刻收集得到。
在运行的过程中，可以通过运行界面试图，监测到vuser运行的场景，事务响应时间，以及每秒点击次数，都可以在controller中统计出来。另外，还可以监测到吞吐量，也就是虚拟用户从服务器在任意一秒中接收到的bytes(字节)总量等信息。
另外，在controller中还可以设置单个用户停止，或者是查看单个用户运行的时候的运行日志信息。这个也是loadRunner做的比较细致的地方。
9.5.3.Analysis
对于LoadRunner，VUG主要是完成录制，脚本生成，回放功能，Controller主要有设计，控制，对于我们测试完的数据，还需要做一个分析，而loadRunner也提供了一个分析的工具，Analysis，在Analysis中，可以查看摘要报告，事务总量，事务平均响应时间，吞吐量，和每秒响应数量等信息。
除了以上信息，还可以在Analysis中分析SLA，也就是服务水平指标，在Controller中或者Analysis中可以设置对应的指标，loadRunner会将事务的平均响应时间和目标对比，如果响应时间超过了临界值，可以在analysis中查看到问题，进行问题分析。
另外，Analysis还可以将测试报告导出，提取出来，发给程序员。
10.介绍一下Selenium
10.1.What
selenium是一个基于web端自动化测试工具，selenium测试直接运行在浏览器中，就像真正的操作浏览器一样，它支持各种操作语言，像java，python都支持。同时selenium提供了IDE录制功能，但是更多的时候，我们还是自己去写自动化脚本。

10.2.How
Selenium,在使用的时候，首先应该配置好selenium的环境，selenium有几个核心的组件，一个是seleniumIDE，IDE主要用在浏览器录制环境上边，可以在浏览器上安装selenium IDE插件，打开录制按钮，录制用户操作，可以进行脚本回放，通过脚本回放，演示录制的脚本是否可用。还可以从浏览器上将录制的脚本导出，以执行脚本代码的形式，执行自动化测试。
我们使用Selenium主要是使用Python代码写脚本，这个需要在python中配置selenium的依赖包，我一般是在python的Scripts的文件夹中，在线下载selenium的相关包。
使用Python做selenium的自动化脚本编写，我一般情况下，会使用Python的unitest执行测试代码。而selenium中比较核心的API，是webDriver，可以通过webDriver完成相应的代码调用。我就简单介绍一下webDriver中常用的操作吧。
要做自动化测试，比较关键的是能够定位到页面元素，定位到元素之后，就可以执行相应元素操作。webDriver中提供了各种方式来定位页面元素，比如通过id，通过link Text，通过css，通过xpath来定位元素，一般，如果有id，我们就使用id，然后使用css或者xpath来定位，dom(document object model) 元素，当然定位的时候，需要在浏览器里边安装firebug firepath来抓取页面元素对应的xpath信息。
定位到元素之后，可以对元素进行操作，比如最简单的操作，我们对文本框使用send_keys设置值，可以使用clear清除值，也可以调用一些键盘的按钮做值得操作，比如回车，比如删除一个字母，还可以调用按钮的点击，其实就是模拟我们人为的操作。通过这些操作，我们就可以完成界面基本的操作，比如登录注册，跳转界面，可以使用这些api来做到。
当然除了这些，Selenium中还有其他一些API的操作，比如关闭浏览器，设置浏览器界面的大小，回退前进操作，还可以获取当前界面的title，获取当前界面的url，还可以设置当前操作等待，当然了，我们使用python中的API time.sleep本身是可以做到的，而webDriver中提供了对应的显示等待和隐式等待的方式，
我一般使用隐式等待，通过一定时长等待，如果超出设置的时长元素还没有被加载，才会抛出异常，如果元素找到了，就直接执行下一步操作。
我们公司在做selenium自动化测试的时候，还会生成测试报告，我们使用的是HTMLTestRunner这个工具包来形成html形式的报告，测试fail的信息，会呈现在报告中，并且可以点击查看错误内容。然后将测试信息发送到开发或者我们测试自己的手里。
以上就是我们使用selenium的基本操作吧
11.介绍一下Appium
11.1.What
Appium是一款测试移动端设置的自动化测试软件，我在公司测试Android客户端的时候，使用过Appium这个软件，Appium和Selenium是一种类型的软件，都是可以通过操作元素，完成界面操作的软件。
11.2.How
在公司测试移动端设备，有好多种方式，我这里就重点说一下这种自动化测试的方式吧，使用自动化测试，可以提高我们的工作效率，我们小组有时候干脆在下班的时候，执行自动化测试，到第二天再去查看测试日志，或者测试报告，或者是直接打开邮箱，查看测试报告就可以了。
对于Appium安装的话，并不太复杂，直接找一个Appium的包安装就行，当然Appium需要有一些依赖的环境，比如说测试Android手机，需要有JAVA环境，需要有adb环境，还需要Android SDK环境，在安装Appium之前，需要把这些环境变量配好。另外，使用Appium，需要自己写脚本，这就需要用到开发环境，我们用的还是python，需要在python的Scripts下边去安装好Appium的依赖包，这样，在Python中就可以导入Appium包下边的相关的API进行脚本的编写了。
使用Appium，不像使用Selenium，还可以使用Selenium IDE录制一部分脚本，Appium需要我们自己手写脚本，另外使用Appium需要对移动端开发有一点点了解，我了解一些Android的知识，比如Android中所有的界面承载都是在Activity中，界面布局，控件基本上可以通过id取到。
对于写Python自动化测试脚本，我就说一下我们的执行流程吧，首先呢，我们需要把Appium启动起来，启动之后，需要打开我们要测试的应用程序，如果不知道包名和启动Activity名称的话，我们就需要通过adb指令获取，我记得是
dumpsys activity | grep mFocusedActivity
然后需要在Android SDK的工具包中启动Android手机的一个可视化界面，叫做ui automator viewer，这个工具可以以快照的形式获取到Android手机或者模拟器界面，能够类似firebug工具抓取到界面的控件元素。
使用Appium抓取控件元素，也是有这么几种方式，可以通过id来获取，这是最简单，最准确的方式，对于有resoure id的控件，我们最好通过resoure ID来获取，另外，还可以通过text，name，xpath，className或者其他方式比来获取元素。
获取到元素之后，我们就可以对元素进行操作，比如我们可以对文本框输入值，清除值，对按钮或者条目执行点击事件。就可以完成基本的操作。
另外，对于智能手机，还有其他操作比如一些触摸操作，滑动操作，Appium包下的webDriver也有响应的API,不过这块做起来就麻烦一些，需要根据所触控点的坐标来进行操作，对于手机屏幕，原点是左上角的点，向右是x轴正方向，向下是y轴正方向，我们可以通过ui authmator view那个小软件，获取想要操作点的坐标，从而完成滑动操作，这块就需要我们不停的去调试了。
另外，在执行测试的时候，我们使用的是python的unitest框架进行执行的，在执行的时候，我们可以通过代码执行执行的次数，可以指定使用HtmlTestRunner生成对应的测试文档，测试fail的信息，会呈现在报告中，并且可以点击查看错误内容，也可以使用代码将生成的文档定时发送给开发和我们测试人员。

12.介绍一下测试计划
一般情况下，会由项目经理提出，当然，如果项目经理不提出的话，我们的测试经理会提出测试需求。需求中其中包含功能需求还有性能需求。功能需求，在我们公司又包含，逻辑功能，易用性，兼容性，安装卸载等功能性需求。性能需求的话，主要就是关注响应时间，成功率，CPU占有率，事务通过率，内存占有率等主要的能够反映我们软件和服务器性能的参数。
比如，对于我们的xxx项目，我们当时性能需求是这样提的，30个在线用户按照正常操作速度访问xxx功能，操作成功率是100%，而且90%的响应时间不超过4S，当并发在线用户数达到100个时，xxx的成功率大于98%，其中90%的在线用户的请求响应时间不大于用户的最大容忍时间10S。这个是测试需求。

当除了测试需求之后，我们就会做测试计划，通常我们的测试计划需要包括几大项。
像测试背景也就是要测试的这个项目的背景情况，包括项目内容，人员配备，项目模块，这些都是测试背景的内容。
还有就是,测试目标，比如我们逻辑功能的达标率是多少，界面测试和产品原型图覆盖率是多少，还有一些性能测试的内容。测试范围,对于测试范围的话，我们一般是包含一些测试分类，比如我们要测试什么，单元测试，集成测试，系统测试啥的，当然还要考虑到回归测试，随机测试，兼容性测试等等。还要包含测试输出文档，比如我们要输出测试用例，bug报告，测试报告等文档型的资料。当然还要有测试工具，功能测试工具和性能测试工具这些，还会涉及到一些自动化测试工具。再就是最主要的测试计划要有人员安排，就是谁谁谁做哪方面测试，模块安排，测试分类安排，我们的测试计划通常会有时间节点的安排，也就是测试进度，比如应该在某个时间节点完成什么样的工作，比如是测试用例什么时候做，什么时候结束，测试评审工作什么时候开展，又是什么时候结束，再比如是某种类型的测试，比如兼容性测试应该在什么时间节点完成。还有就是某个测试工程师应该在xx时间完成某个模块的测试工作。这个就是基本的测试计划的内容。

13.介绍一下测试报告

对于测试报告，就是对整个测试过程以及测试结果的一个文档形式的总结。我们通常会包含功能测试报告和性能测试报告。
我就先说功能测试报告吧。我就捡重点的来说吧，首先是把测试的整个背景介绍一下，然后对测试过程，测试的方式总结，比如兼容性测试怎么做的，安装卸载测试怎么做的，整个测试的流程内容要在测试报告中体现出来。还要统计测试用例的信息，比如一共写了多少测试用例，覆盖了多少模块，多少方式(兼容性，一般性能等等)，还有就是通过的测试用例数，失败的测试用例数，当然最重要的就是缺陷(bug)统计还有分析。
先说缺陷统计，我们要再测试报告中统计bug的总数量，致命bug多少，严重bug多少，一般bug多少，提示性的bug又有多少。再就是各个模块的bug数量，严重程度，还有就是分类型的bug数量，比如兼容性类型bug，一般功能性bug，这个我们都要在测试报告中形成书面的文档。当然，还要做一个缺陷分析，就是分析一下哪些模块bug比较多。

当然，还有非常重要的一点，有时候为了赶商机，我们项目并不是在没有bug的情况下去上线，那我们在测试报告中必须要声明上线前还存在哪些bug没有解决。

我再说一下性能测试报告吧。性能测试报告，首先要包含项目性能需求，然后将我们做性能测试所测出的数据在性能报告上进行分析，当然会列出这些数据，比如不同并发用户时的吞吐量，CPU占有率，内存占有率等信息，我们都会在性能测试报告中呈现。然后将我们的分析，呈现到报告中。比如在测试中，是否存在cpu占有率超过我们性能需求中阈值的情况，是否存在系统崩溃的风险，系统是否稳定，系统能承受多少用户的并发访问，系统响应时间是否是能够达到我们的标准。
对以上所有的情况，都会做一些风险评估和预测。
这个就是测试报告。

13.1.正交表测试用例设计方法的特点是什么？
比如说:有四个选项框，每个各有三个选择，一共需要81个测试用例，但是使用正交表法，均匀覆盖后，缩减到9个
参考答案：
用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；

13.2.简述一下缺陷的生命周期？
参考答案：提交->确认->分配->修复->验证->关闭

13.3.画出软件测试的V模型图。
参考答案：

13.4.您所熟悉的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。
参考答案：
1．等价类划分
　　划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.
　　2．边界值分析法
　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.
　　使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.
3．错误推测法
　　基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.
　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.
4．因果图方法
　　前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.、
(1)判定表
(2)正交表
13.5.请以您以往的实际工作为例，详细的描述一次测试用例设计的完整的过程。
参考答案：登录

就说最近的这次网站功能的测试吧

首先：得到相关文档（需求文档和设计文档），理解需求和设计设计思想后，想好测试策略（测试计划简单点就OK了），考虑到测试环境，测试用例，测试时间等问题。
　　第二步：设计测试用例，测试策略是：把网站部分的功能点测试完，然后在进行系统测试（另外个模块呢有另一个测试人员负责，可以进行联调测试），网站模块的测试基本是功能测试和界面测试（用户并发的可能性很小，所以不考虑）：这次的网站的输入数据呢是使用数据库中的某张表记录，如果表中某一数据记录中新加进来的（还没有被处理的，有个标志位），网站启动后会立刻去刷那张表，得到多条数据，然后在进行处理。处理过程中，会经历3个步骤，网站才算完成了它的任务。有3个步骤呢，就可以分别对　　这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况（包括数据库中的数据，用户的输入等），得出了差不多50个用例。界面测试，也就是用户看的到的地方，包括发送的邮件和用户填写资料的页面展示。
　　第三步：搭建测试环境（为什么这个时候考虑测试环境呢？因为我对网站环境已经很熟了，只有有机器能空于下来做该功能测试就可以做了），因为网站本身的环境搭建和其他的系统有点不同，它需要的测试环境比较麻烦，需要web服务器（Apache,tomcat），不过这次需求呢，网站部分只用到了tomcat，所以只要有tomcat即可
　　第四步：执行测试
13.6.你以前工作时的测试流程是什么？
参考答案：（灵活回答）
公司对测试流程没有规定如何做，但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正（自己总结，吸取同行的方法）后的流程吧。需求评审（有开发人员，产品经理，测试人员，项目经理）－>需求确定(出一份确定的需求文档)－>开发设计文档（开发人员在开始写代码前就能输出设计文档）－>制定测试计划，写出测试用例－>发给开发人员和测试经理看看（非正式的评审用例）－>接到测试版本（可能测试的代码 通过冒烟测试的代码）－>执行测试用例（中间可能会补充用例）－>提交bug（有些bug需要开发人员的确定（严重级别的，或突然发现的在测试用例范围之外的，难以重现的），有些可以直接写到TD（Test Director 相当于禅道））－>开发人员修改（可以在测试过程中快速的修改）－>回归测试（可能又会发现新问题，再按流程开始跑）。

13.7.描述一下Http协议

http协议又叫做超文本传输协议，在做网络请求的时候，我们基本上是使用http协议。
http协议包括请求和响应。
请求中包括:请求地址，请求方式，请求方式包括get请求和post请求，get和post的区别是get请求是在地址栏后边跟随请求参数，但是请求参数大小是有限制，不同浏览器是不同的。一般是4KB。post请求主要用于向服务器提交请求参数。post请求的参数是放到请求实体内容中的，相对get请求较为安全一些。

另外，请求中会有各种请求头信息，比如支持的数据类型，请求的来源位置，以及Cookie头等相关头信息。

响应，主要包含响应的状态码，像200(),404(),500(),304(),307()
还有各种响应头信息，比如设置缓存的响应头，Content-Type内容类型，设置cookie头信息。

13.8.什么是测试计划？
话术
13.9. 测试计划包括哪些要素？

话术
13.10.什么是测试报告？

话术
13.11.测试报告包括哪些要素？
话术
13.12.缺陷包括哪些要素？
　　1.和bug产生对应的软件版本
　　2.开发的接口人员
　　3.bug的优先级
　　4.bug的严重程度
　　5.bug可能属于的模块，如果不能确认，可以用开发人员来判断
　　6.bug标题，需要清晰的描述现象
　　7.bug描述，需要尽量给出重新bug的步骤
　　8.bug附件中能给出相关的日志和截图。
　　高质量的bug记录就是指很容易理解的bug记录，所以，对于描述的要求高，能提供的信息多且准确，很好的帮助开发人员定位。

13.13.Monkey测试的优点和缺点？
优点：
1、使用简单
2、节省了重复性操作的时间
3、随机输入可能会发现一些平常意想不到的缺陷。
Monkey虽然可以根据一个指定的命令脚本发送按键消息，但其不支持条件判断，也不支持读取待测界面的信息来执行验证操作。
3、可对Monkey Test的对象，事件数量，类型，频率等进行设置。

缺点：
1、测试的对象仅为应用程序包，有一定的局限性。
2、Monky测试使用的事件流数据流是随机的，不能进行自定义。
13.14.请详细阐述接口测试和UI测试在测试活动中是如何协同测试的？

接口测试和UI测试这两块其实是有一部分是重叠的，UI测试是通过前端写的界面，来调用接口，而接口测试是直接调接口。所以排除前端的处理的逻辑和调用的正确性，在理论上接口测试是可以覆盖所有的UI测试。但实际过程中，如果只是在接口层覆盖所有的业务流，在UI上只测试前端的逻辑，最终的结果可能会是忽视很多原有的功能点，导致了UI测试的不充分。所以存在多人分工且时间充分的时候可以尝试接口去做业务流的全覆盖，否则不要轻易尝试。

13.15.请详述缺陷在管理工具中的状态转换
New 为测试人员新问题提交所标志的状态。
Open 为任务分配人（开发组长/经理）对该问题准备进行修改并对该问题分配修改人员所标志的状态。Bug解决中的状态，由任务分配人改变。对没有进入此状态的Bug，程序员不用管。
Reopen 为测试人员对修改问题进行验证后没有通过所标志的状态；或者已经修改正确的问题，又重新出现错误。由测试人员改变。
Fixed 为开发人员修改问题后所标志的状态，修改后还未测试。
Closed 为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
Rejected 开发人员认为不是Bug、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由Bug分配人或者开发人员来设置。
Delay 开发人员认可是缺陷，但认为当前版本无法修复的缺陷。故拖延到后期再进行修复。若是有缺陷被标为该状态，则开发人员必须附上缺陷修复的具体版本或日期。

13.16.如何查看启动端口2222的服务？
参考答案：netstat –an|grep 2222。

13.17.查看本机是否已经安装TFTP软件，若已经安装，先删除后再安装；否则，先安装后再删除。写出实现上述操作的命令列表。
参考答案：查看：rpm –qa|grep tftp；删除： rpm –e tftp-0.42-3.1，安装rpm –ivh tftp-0.42-3.1。

13.18.找出/etc下，文件大小介于50KB到60KB之间的文件，并列出文件的操作权限。
参考答案：find /etc –size +50k –and –size -60k。

13.19.adb常用的指令
ADB，即 Android Debug Bridge，
adb logcat //显示全部日志
adb logcat > c: est.log //将日志保存到文件
test.log adb logcat *:W //显示所有优先级大于等于“warning”的日志
adb start-server adb启动
Adb Kill-server 停止adb
adb -P start-server adb指定adb server 的端口
adb devices 查看已连接的设备
adb shell pm list packages 所有应用
adb shell pm list packages -s 系统应用
adb shell pm list packages aaa 查看包名包含字符串 aaa 的应用列表
adb shell pm list packages | grep aaa 查看包名包含字符串 aaa 的应用列表
adb install 安装
adb uninstall 卸载
adb shell pm clear com.baidu.com 清除应用数据和缓存
adb logcat -c 清除日志
Adb logcat -v 指定日志输出格式 format（tag/process/raw/time/threadtime）
过滤：
adb logcat ActivityManager:I MyApp:D *:S
表示输出 tag ActivityManager 的 Info 以上级别日志，输出 tag MyApp 的 Debug 以上级别日志，及其它 tag 的 Silent 级别日志（即屏蔽其它 tag 日志）
按级别过滤日志
Android 的日志分为如下几个级别：
V —— Verbose（最低，输出得最多）
D —— Debug
I —— Info
W —— Warning
E —— Error
F —— Fatal
S —— Silent（最高，啥也不输出）
按某级别过滤日志则会将该级别及以上的日志输出。
比如，命令：adb logcat *:W 将 Warning、Error、Fatal 和 Silent 日志输出

13.20.如何用adb快速查看电脑连接设备的状态？
adb devices
13.21.如何用adb查看手机进程？
adbshellprocrank查询各进程内存使用情况

13.22.什么是手机Monkey测试？如何使用Monkey测试？
Monkey是AndroidSDK提供的一个命令行工具，可以简单，方便地运行在任何版本的Android模拟器和实体设备上。Monkey会发送伪随机的用户事件流，适合对app做压力测试。主要目的就是为了测试app是否会Crash

13.23.写一条完整的monkey测试指令

13.24.APP测试的稳定性
了解什么是稳定性，这项工作一般是在软件产品基本功能无缺陷后进行的一项测试工作。一般使用软件系统满足持续运行模式，进行临界情况的测试，看系统是否有异常。
一般使用monkey工具，向系统发送随机事件流，如按键输入、触摸屏输入、手势输入等，实现对软件的稳定性测试

13.25.如何理解压力、负载、性能测试测试？
参考答案：
性能测试是一个较大的范围，实际上性能测试本身包含了性能、强度、压力、负载等多方面的测试内容。
压力测试是对服务器的稳定性以及负载能力等方面的测试，是一种很平常的测试。增大访问系统的用户数量、或者几个用户进行大数据量操作都是压力测试。而负载测试是压力相对较大的测试，主要是测试系统在一种或者集中极限条件下的相应能力，是性能测试的重要部分。100个用户对系统进行连续半个小时的访问可以看作压力测试，那么连续访问8个小时就可以认为负载测试，1000个用户连续访问系统1个小时也可以看作是负载测试。
实际上压力测试和负载测试没有明显的区分。测试人员应该站在关注整体性能的高度上来对系统进行测试。

13.26.您以往是否曾经从事过性能测试工作？
话术

13.27.adb 怎么过滤
adb logcat | grep MyApp
adb logcat | grep -i myapp #忽略大小写。
adb logcat | grep --color=auto -i myapp #设置匹配字符串颜色
13.28.Jmeter为什么要参数化
第一点:多用户登录的时候，如果不进行参数化，就没法演示了，需要使用CSV将参数放到文件，来演示多用户登录
第二点:在进行录制的时候，有可能存在第二个请求的参数是从第一个请求中获取出来的，需要在第一个请求下，去将参数提出取来，再在第二个请求中进行参数化

13.29.你用什么机器对服务器进行压力测试
按照规范的话，需要使用一台性能比较好服务器来对服务器进行压力测试。

在Linux系统下搭建测试环境，然后进行测试。
可以说使用的Jmeter进行的测试，前期需要搭建的环境包括Java MySQL 等环境

13.30.使用Jmeter回放脚本的时候遇到的问题？
sessionId的问题，添加后置选择器，正则提取器，需要设置参数关联

13.31.对于登陆你是怎么测得？
基本的登陆么?（回答我是的）这个先测一下能不能正确登陆，然后呢对输入框进行测试，就是测各种输入情况，空格啊，NONE啊，数字啊，汉字，数字，特殊字符等等，以及他们之间的组合，长度等 密码的话基本差不多，还要有密码长度限制啊，保密啊，再然后就是测测按钮等等

具体需求：
有一个登录页面，有一个账号和一个密码输入框, 一个提交按钮。 请针对这个页面设计Test Case。
此题的考察目的：
1、了解需求（测什么都是从了解需求开始）；
2、是否有设计Test Case的能力
3、是否熟悉各种测试方法；
4、是否有丰富的Web测试经验；
5、是否了解Web开发；
了解需求：
测试需求分析过程，可以从质量要求出发，来展开测试需求分析，如从功能、性能、安全性、兼容性等各个质量要求出发，不断细化其内容，挖掘其对应的测试需求，覆盖质量要求。也可以从开发需求（如产品功能特性点、敏捷开发的用户故事）出发，针对每一条开发需求形成已分解的测试项，结合质量要求，这些测试项再扩展为测试任务，这些测试任务包括了具体的功能性测试任务和非功能性测试任务。在整理测试需求时，需要分类、细化、合并并按照优先级进行排序，形成测试需求列表。
1、登录界面应该是弹出窗口式的，还是直接在网页里面；
2、账号长度和密码的强度（比如需要多少位、大小写敏感、特殊字符混搭等）；
3、界面美观是否有特殊要求？（即是否要进行UI测试）；
4、····
用例设计：
测试需求分析完成后，开始用例设计，主要可以从以下几个方面考虑：
功能测试(Function Test)
1、输入正确的账号和密码，点击提交按钮，验证是否能正确登录。（正常输入）
2、输入错误的账号或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
3、登录成功后能否跳转到正确的页面（低）
4、账号和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
5、账号和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
6、记住账号的功能
7、登录失败后，不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示（星号圆点等）
10、牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码，登出用另一帐号登录等链接是否正确
12、输入密码的时候，大写键盘开启的时候要有提示信息。
13、什么都不输入，点击提交按钮，看提示信息。（非空检查）
界面测试(UI Test)
1、布局是否合理，2个Testbox 和一个按钮是否对齐
2、Testbox和按钮的长度，高度是否复合要求
3、界面的设计风格是否与UI的设计风格统一
4、界面中的文字简洁易懂，没有错别字。
性能测试(Performance Test)
1、打开登录页面，需要几秒
2 、输入正确的账号和密码后，登录成功跳转到新页面，不超过5秒
安全性测试(Security Test)
1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)
2、账号和密码是否通过加密的方式，发送给Web服务器
3、账号和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javaScript验证
4、账号和密码的输入框，应该屏蔽SQL注入攻击
5、账号和密码的的输入框，应该禁止输入脚本（防止XSS攻击）
6、错误登录的次数限制（防止暴力破解）
7、考虑是否支持多用户在同一机器上登录；
8、考虑一用户在多台机器上登录
可用性测试(Usability Test)
1、是否可以全用键盘操作，是否有快捷键
2、输入账号，密码后按回车，是否可以登录
3、输入框是否可以以Tab键切换
兼容性测试（Compatibility Test）
1、主流的浏览器下能否显示正常已经功能正常（IE6~11, FireFox, Chrome, Safari 等 ）
2、不同的平台是否能正常工作，比如Windows, Mac
3、移动设备上是否正常工作，比如iPhone, Android
4、不同的分辨率
本地化测试 （Localization Test）
1、不同语言环境下，页面的显示是否正确。
软件辅助性测试 （Accessibility Test）
软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
1、高对比度下能否显示正常（视力不好的人使用）

13.32.web端测试流程？
web测试话术

13.33.版本控制器使用的什么
svn 有的公司会让我们自己部署环境，比如我在上一家公司的时候，程序员会把项目代码发布到svn上，我们自己讲代码下载下来，然后部署程序运行的环境，再进行测试，这样的话，会省掉不少的时间。
13.34.常用查看服务器信息
ps ax | grep emacs
sun % grep telnet /ect/services
查看cpu占用情况
cpu sar -u
查看硬盘使用情况
df -k bdf

13.35.Linux常用命令
cd 进去
Ls 查看文件目录
Cat 查看内容 Grep 分析 Find 查找 Cp 复制 Mv 移动 Vim 文件编辑
Rm 删除 Ps 运行情况 Kill 发送命令 Killall
Tar 压缩 Chmod 改变权限 Time 文件执行时间

13.36.什么是测试环境
测试环境（Testing environment）是指测试运行其上的软件和硬件环境的描述，以及任何其他与被测软件交互的软件，包括驱动和桩。测试环境是指为了完成软件测试工作所必需的计算机硬件、软件、网络设备、历史数据的总称。
其实就是，测试环境=软件+硬件+网络+数据准备+测试工具

13.37.如何搭建测试环境
个人PC(windows)可以搭建测试环境，但是由于个人PC硬件和软件的局限性，我们一般不使用其搭建测试环境，但如果是自己做模拟实验是没问题的。
但是在企业中我们一般都不使用windows平台搭建服务器，而是选择linux平台。
这是因为我们经常选择linux平台作为服务器的操作系统。
4.搭建测试环境
如果你需要搭建的测试环境是刚装的linux操作系统，
通常测试环境包括JDK环境，Tomcat环境和MySQL环境
下边是安全配置的步骤，大家可以理解，不用强背…,面试的时候，可以说就从网上找一份文档，按照文档进行配置

1.安装jdk
如果有自带，先卸载再装
1.把包复制/usr/local
2.解压
3.配置环境变量
export JAVA_HOME=/usr/local/jdk1.7.0_71
export CLASSPATH=.:$JAV{A}_{H}OME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export PATH=$JAV{A}_{H}OME/bin:$PATH
4.检查java是否安装成功
java -version
2.安装tomcat
1.把下载的tomcat包复制/usr/local
2.解压
3.在tomcat/bin目录执行startup.sh文件
启动服务
在浏览器中连接：IP:8080
4.如果连接不上，但tomcat又是显示启动OK，检查firewall
路径为 /etc/sysconfig/iptables，将8080端口开启
5.重启服务
3.安装数据库
数据库一般安装mysql和oracle多一些
首先下载相应的数据库安装包
mysql安装比较简单，可以使用源码安装，也可以使用yum在线安装，在这里简单地介绍一下yum在线安装
用yum在线安装

1. rpm -qa|grep mysql --检查linux是否有存在的mysql
   2.如果有mysql,卸载
   rpm -e --nodeps mysql
   3.安装
   yum install mysql-server mysql mysql-dev -y
   4.安装成功后，启动服务
   service mysqld start
   service 服务名 restart/start
   5.直接输入mysql 进入到数据库
   以上的只会在干净的操作系统上进行安装，一般来说只需要安装一次

13.38.linux查看日志文件内容命令

tail、cat、tac、head、echo

13.39.做过多接口联调的测试吗？
答：做过，我们之前有这样一个应用场景，就是我们先填写一个表单的数据，然后再填写另外一张表单的数据，最后生成到统一的一个表格中，这个我们就是通过接口调试来进行测试，要不然效率太低，另外使用这种联调的方式，能快速的查找到bug的位置
13.40.web端测试流程？

一、立项后测试需要拿到的文档

二、需求评审

三、用例编写（同时根据开发计划编写测试计划）

四、用例评审

五、测试执行

六、测试报告及操作手册

13.41.app端测试流程？

13.42.APP的环境搭建

配置一个adb环境变量
使用adb连接Android设备，并执行相应指令，获取产品数据（占用cpu、内存等）；
使用monkey对产品进行压力测试和随机测试并将日志输出到本地；
13.43.正交表测试设计方法的特点？
以最少的测试用例覆盖最多的功能点。

13.44.吞吐量（TPS）、QPS、并发数、响应时间（RT）概念
QPS 每秒查询率，因特网上，经常用每秒查询率来衡量域名系统服务器的机器的性能，其即为QPS。
对应请求数/sec，即每秒的响应请求数，也即是最大吞吐能力。
原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间。
公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS) 。
机器：峰值时间每秒QPS / 单台机器的QPS = 需要的机器 。
每天300w PV 的在单台机器上，这台机器需要多少QPS？
( 3000000 * 0.8 ) / (86400 * 0.2 ) = 139 (QPS)。
一般需要达到139QPS，因为是峰值。

响应时间(RT)
响应时间是指系统对请求作出响应的时间

吞吐量
吞吐量是指对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量（以比特、字节、分组等测量）。

13.45.服务端和客户端的性能分析从哪些角度来进行
服务端

1. 数值说明
   测试完成的总事务数
   平均请求响应时间
   统计意义上的平均响应时间
   除特殊情况之外的最大响应时间
   最短响应时间
   最大响应时间
   吞吐量，和ab的每秒处理请求数相同
   流量，权衡
   2.测试并发性能
   3.测试获得结果分析
   a)整个场景中的网络传输量
   b) Request per second：每秒处理的请求数，即每秒事务数（TPS）,一般来说100~200是 比较理想的范围
   c) Time per request：每个请求所花的时间，即平均事务时间。此数值一般有两行，一般 关注后一行的数值，也就是计算请求平均响应的时间。
   d) Transfer rate：平均每秒的网络流量，此数据可以帮助排除是否存在网络流量过大导 致响应时间延长的问题。

服务端性能测试的几个注意事项：
a) 性能测试最好在本地进行，至少要保证服务器和测试机都在内网中，这样才能排除网络的干扰，更准确的测出系统本身的问题。
b) 必须根据服务端应用的实际情况选用合适的输入参数，这样可以预估出和目标性能相似的测试。

客户端
稳定性测试的三个要点：
a) 应用的运行实际要尽可能的长，
b) 保持运行时是多线程运行状态
c) 尽可能使用多的机型或者操作系统进行测试
13.46.写出http接口性能测试过程中的关注点
13.47.性能测试关注哪些指标
从外部看，性能测试主要关注如下三个指标
吞吐量：每秒钟系统能够处理的请求数、任务数。
响应时间：服务处理一个请求或一个任务的耗时。
错误率：一批请求中结果出错的请求所占比例。
从服务器的角度看，
性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等

用户切换：默认登录的是普通用户权限
显示$符tree@ubuntu:/usr$
从普通用户切换超级用户权限：
sudo su
tree@ubuntu:/usr$ sudo su
输入密码
[sudo] password for tree:
输入密码之后即可切换到超级用户了。
从超级用户切换普通用户：
su 用户名
root@ubuntu:/usr# su tree
从超级用户切换到普通用户是不需要输入密码的，输入上面的命令之后直接回车即可
tree@ubuntu:/usr$
授权命令： 比如对于一个文件 可以采用 chmod 命令进行授权 假设文件 / 文件夹 tset chmod 777 test

13.48.常见的一些错误、异常
a)NullPointerException 空指针异常
b)ClassNotFoundException 指定的类不存在
c)NumberFormatException 字符串转换成数字异常
d)IndexOutOfBoundsException 角标越界
e)ArithmeticException 运算异常
f)FileNotFoundException 文件找不到
g)ArrayStoreException 数组存储异常
13.49.说一些常见的响应码
h)200 – 服务器成功返回网页
i) 404 – 请求的网页不存在
j)503 – 服务不可用
k)404 （未找到） 服务器找不到请求的网页。
l)500 （服务器内部错误） 服务器遇到错误，无法完成请求。
m)303 重定向
2、抓包工具用过什么？
a)Fiddler
i.断点 在菜单中选择“Rules”->“Automatic Breakpoint”->“Before Requests”，这种方式会截断所有Request请求。
ii.过滤 filters use Filter show only the folwinghosts 在添加过滤的内容 、点击action
b)Charles
i.断点 在抓包之后。在请求数据、右键选中BreakPoints、在弹出的断点窗 、在editRequest可以添加、修改参数、进行调试、EditRespone可以设计响应、点击excute、在fillter中就可以设置网址或者其他过滤

13.50.系统间的接口联调测试
例如：两个系统之间的部分数据是相互读取的

1. 在一个甲系统增加，修改A数据后，乙系统也会相应的呈现这个改动的数据；在乙系统增加，修改B数据后，甲系统也会相应的呈现这个改动的数据；
   即A部分的数据，是由甲系统来维护的，乙系统读入数据并同步；B部分的数据，是由乙系统来维护的，甲系统读取数据并同步；
2. 在具体的操作过程中，在甲系统增加，修改A数据后，然后在乙系统查看对应的数据是否同步一致；反之亦然；
   在乙系统查看对应的数据是否同步一致？分为三个层面；
   （1）甲系统传输过来的数据和乙系统接收到的数据是否一致；
   （2）乙系统接收到数据后，会存入到自己的数据库，这个存储过程是否成功？（主要是考虑到甲系统传过来的数据格式是否和乙系统的格式一致）且数据存储成功与否乙系统会返回一条信息（例如：返回1，表示数据正确传输并存储到数据库了；返回0及错误信息表示数据传输或存储出了问题）
   （3）然后在乙系统的界面查看，新增或修改的数据是否和接收到的数据一致；