软件测试实例整理

1、给你一个字符串，你怎么判断是不是ip地址？手写这段代码，并写出测试用例

链接: Python
链接: Java

2、请进行测试用例设计：一串数字，闰年的判别

链接: Python
链接: Java

3、请你说一说简单用户界面登陆过程都需要做哪些分析

答：一、功能测试

1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。

2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。

3.登录成功后能否能否跳转到正确的页面

4.用户名和密码，如果太短或者太长，应该怎么处理

5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况

6.记住用户名的功能

7.登陆失败后，不能记录密码的功能

8.用户名和密码前后有空格的处理

9.密码是否非明文显示显示，使用星号圆点等符号代替。

10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使 用者），刷新或换一个按钮是否好用

11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确

12.输入密码的时候，大写键盘开启的时候要有提示信息。

13.什么都不输入，点击提交按钮，检查提示信息。

二、界面测试

1.布局是否合理，testbox和按钮是否整齐。

2.testbox和按钮的长度，高度是否复合要求。

界面的设计风格是否与UI的设计风格统一。

界面中的文字简洁易懂，没有错别字。

三、性能测试

1.打开登录页面，需要的时间是否在需求要求的时间内。

2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。

3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

四、安全性测试

1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。

2.用户名和密码是否通过加密的方式，发送给Web服务器。

3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。

4.用户名和密码的输入框，应该屏蔽SQL注入攻击。

5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。

6.防止暴力破解，检测是否有错误登陆的次数限制。

是否支持多用户在同一机器上登录。

同一用户能否在多台机器上登录。

五、可用性测试

是否可以全用键盘操作，是否有快捷键。

输入用户名，密码后按回车，是否可以登陆。

输入框能否可以以Tab键切换。

六、兼容性测试

1.不同浏览器下能否显示正常且功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）。

2.同种浏览器不同版本下能否显示正常且功能正常。

2.不同的平台是否能正常工作，比如Windows, Mac。

3.移动设备上是否正常工作，比如Iphone, Andriod。

4.不同的分辨率下显示是否正常。

七、本地化测试

不同语言环境下，页面的显示是否正确。

4、请对这个系统做出测试用例：一个系统，多个摄像头，抓拍车牌，识别车牌，上传网上，网上展示

答：功能分析：
1.每个摄像头都能抓拍车牌；
2.每个摄像头抓拍到的车牌能正常交给系统处理；
3.系统能够正确识别车牌；
4.系统能够将识别出的车牌上传；
5.上传至网络的车牌能够正常展示出来；

一、功能测试
1.使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；
2.使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；
3.使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；
4.在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；
5.使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；
6.使用非车牌的其他图片，交由系统处理，检查系统能否识别；
7.在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；
8.构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；
9.检查上传至网络的车牌能否正常展示出来；
10.上传非车牌的其他内容的数据，检查能否正常显示出来。

二、性能测试
1.同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；
2.同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；
3.抓拍后，检查系统识别车牌的时间是否在需求要求的时间内；
4.模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；
5.模拟大量车牌同时上传，检查一定压力下能否上传成功。

三、安全性测试
1.检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。

5、请你对吃鸡游戏进行压力测试

答：一.首先明确需要测试压力的内容:
1.游戏服务器硬件
a.硬盘I/o
b.内存
c.CPU
2.网络压力
a.长连接
a1.最大连接数
a2.流量(内网、外网、进、出)
b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)
b1.每秒建立的连接数
b2.实际处理能力
3.数据库
a.每秒事务数
b.每秒锁等待数
c.平均延时(ms)
d.CPU暂用
4.多线程的最优线程数
a.数据库执行的多线程
b.多连接处理

二.Windows Server环境测试方式
1.服务器性能监测
使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。
2.案例设计注意
a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。
b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天
c.聊天性能测试
广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。进而可以对我们的各种广播功能进行一个预估和频率限制。
d.同屏玩家的移动测试
移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。
e.大量玩家同时登录测试
玩家登录时，有大量的信息需要进行分配和初始化；同时也有大量的数据需要下传客户端。服务器需要进行大量的TCP连接建立。所以是一个比较关键的过程。这个测试案例是一个比较特殊，但是运营是肯定会碰到的案例。
f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率
3.细节问题
a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如
a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题
a2.客户端性能问题，导致发起的请求数过少，从而导致单位时间内服务器处理的请求过少。表现为服务器性能不足，其实根本就是客户端的请求能力不足。
b.网络带宽导致最后表现不足
b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机
b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。
c.debug i/o导致服务器性能下降
c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。
c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降
d.流量需要区分内网网
内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。

6、请你根据微信登录界面设计测试用例

答：一、功能测试
1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。 2.输入错误的用户名或者密码,验证登录会失败，并且提示相应的错误信息。 3.登录成功后能否能否跳转到正确的页面 4.检查能否选择不同登录方式进行登录，如使用手机号登录、使用微信号登录或扫码登录。 5.记住用户名的功能 6.登陆失败后，不能记录密码的功能 7.密码是否非明文显示显示，使用星号圆点等符号代替。 8.有验证码时，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色、刷新或换一个按钮是否好用 9.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确 10.输入密码的时候，大写键盘开启的时候要有提示信息。 11.什么都不输入，点击提交按钮，检查提示信息。

二、界面测试
1.布局是否合理，testbox和按钮是否整齐。 2.testbox和按钮的长度，高度是否复合要求。 3. 界面的设计风格是否与UI的设计风格统一。 4. 界面中的文字简洁易懂，没有错别字。

三、性能测试
1.打开登录页面，需要的时间是否在需求要求的时间内。 2.输入正确的用户名和密码后，检查登录成功跳转到新页面的时间是否在需求要求的时间内。 3.模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。

四、安全性测试
1.登录成功后生成的Cookie，是否是httponly (否则容易被脚本盗取)。 2.用户名和密码是否通过加密的方式，发送给Web服务器。 3.用户名和密码的验证，应该是用服务器端验证， 而不能单单是在客户端用javascript 验证。 4.用户名和密码的输入框，应该屏蔽SQL注入攻击。 5.用户名和密码的的输入框，应该禁止输入脚本 （防止XSS攻击）。 6.防止暴力破解，检测是否有错误登陆的次数限制。 7. 是否支持多用户在同一机器上登录。 8. 同一用户能否在多台机器上登录。

五、兼容性测试
1.不同移动平台或PC环境下下能否显示正常且功能正常 2.同种平台下不同微信版本下能否显示正常且功能正常。 3.不同的分辨率下显示是否正常。

六、本地化测试
不同语言环境下，页面的显示是否正确。

7、请你对朋友圈点赞功能进行测试

答：1.功能测试
是否可以点赞
取消点赞
多次点赞会出现什么情况
多人点赞时的顺序是否按照时间顺序进行排列
点赞是否显示头像和名称
点赞之后能否进行评论
点赞之后退出该页面，再次进入朋友圈点赞消息是否还存在
多用户点赞，再次打开朋友圈是是否可以按照顺序看到是谁谁谁赞了我
2.接口测试
点赞之后相同好友是否收到提示信息
相同好友处的提示信息是否按照时间顺序
相同好友处的点赞是否显示头像和名称
3.兼容测试
电脑端和手机端是否都可以进行点赞和取消点赞功能
不同的移动端是否都可以行点赞和取消点赞功能（包括苹果，安卓）
4.可用性测试
弱网的时候进行点赞是什么情况
网络断开时是否可以点赞
用户点击点赞几秒后可以看到点赞成功，取消同理
多用户同时给我点赞时，我是否可以全部接收到提示消息
5.安全性测试
点赞是否会泄漏微信用户相关信息

8.如果做一个杯子的检测，你如何测试

答：需求测试：查看杯子的使用说明书，安全说明书等。
功能测试：
1、杯子能否装水；
2、可以装多少L的水；
3、杯子是否可以放冰箱；
4、水可不可以被喝到。
安全性测试：
1、杯子有没有毒和细菌；
2、杯子从高处坠落，是否已破；
3、杯子是否有缺口，容易滑倒嘴巴；
4、将杯子放入微波炉中，是否爆炸或融化；
性能测试：
1、看杯子能够容纳的最大体积和最高温度；
2、将杯子盛上水，经过24小时后查看杯子的泄露情况和时间(可分别使用水和汽油做测试)；
3、将杯子装上填充物，看不会摔破的最高度；
4、用根针并在针上面不断加重量，看压强多大时会穿透；
可用性测试：杯子是否好拿，是否烫手，是否防滑，是否方便饮用。
兼容性测试：除了装水，是否还可以装其它的液体，比如果汁，汽油等。
界面测试：查看杯子的外观：杯子是什么材质的，颜色，外形，重量，图案是否合理，是否有异味。
用户文档：使用手册是否对杯子的用法、限制、使用条件等有详细描述。

9.如何对一个页面进行测试

答：第一个方法：分类法
界面控件功能按钮类：
1.比如搜索控件、单程、往返、多程的单选控件
2.选择单程、往返、多程的单选控件，是否会先在界面上显示
3.勾选带儿童、带婴儿的界面显示，以及点击搜索后，界面跳转情况

界面检查类：
界面上有没有显示模糊，或者被遮挡的，影响用户体验，界面的检查，注意从兼容性（浏览器的兼容性，比如常用的IE、谷歌、360、火狐等），还要从浏览器全屏和缩小的使用场景进行测试。

界面跳转链接类：
界面上经常会有跳转链接的功能，这时候我们需要进行测试，这个界面比如“儿童/婴儿票”

查询条件或者搜索条件的检查：
比如下拉框选择、手动输入内容进行检查。输入框的检查，需要注意前端界面对输入框输入规范的控制，比如：这个输入框的限制长度，只允许输入什么类型的字符，当输入不规范的时候，提示语是否符合用户体验
查询条件
时间的检查（一般时间的检查包括：日期+时间：时分秒）
这里日期有出发日期和返回日期，且做了可选择的操作，同时用户可以自己输入，注意一个细节，这个界面在还没有选择出发日期前，这个返回日期是置灰的，但是选择返回日期是可选的。这个时间需要考虑的场景如下：
1：选择单程的情况下，返回日期小于/大于/等于出发日期
返回日期小于出发日期，是否会友好提示
返回日期大于出发日期，是否能正常跳转到相应的机票界面
返回日期等于出发日期，是否能正常跳转到相应的机票界面
2：选择往返的情况下，返回日期小于/大于/等于出发日期
同上考虑
3：选择多程的情况下，返回日期小于/大于/等于出发日期
同上考虑
注:
这里还需要考虑今天以前的日期是否可选，站在用户思维的角度，出行只有正在进行时和将来时，没有过去时。

第二种方法：探索性测试
站在用户的角度去使用该界面，随意操作

界面的功能测试完毕，我们还需要或者还可以做什么？
一个界面，直接面对的是用户，所以界面的适用性和可用性，对用户体验来说是特别重要的。我们可以参考市场上，同类型的产品，进行亲身体验操作，对我们目前的界面提一些建设性的意见。

10.如何对水壶进行测试

答：1.功能
（1）水倒水壶容量的一半
（2）水倒规定的安全线
（4）水壶容量刻度与其他水壶一致
（5）盖子拧紧水倒不出来
（6）烫手验证
2.性能
（1）使用最大次数或时间
（2）掉地上不易损坏
（3）盖子拧到什么程度水倒不出来
（4）保温时间长
（5）壶的耐热性
（6）壶的耐寒性
（7）长时间放置水不会漏
（8）壶上放置重物达到什么程度壶会被损坏
3.界面
（1）外观完整、美观
（2）大小与设计一样（高、宽、容量、直径）
（3）拿着舒服
（4）材质与设计一样
（5）壶上的图案掉落
（6）图案遇水溶解
4.安全
（1）壶使用的材质毒或细菌的验证
（2）高温材质释放毒性
（3）低温材质释放毒性
5.易用性
（1）倒水方便
（2）喝水方便
（3）携带方便
（4）使用简单，容易操作
（5）防滑措施
6.兼容性
（1）壶能够容纳果汁、白水、酒精、汽油等。
7.震动测试
（1）壶加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
8.可移植性
（1）壶在不同地方、温度环境下都可以正常使用。

11.如何对淘宝搜索框进行测试

答：功能测试
1 输入关键字，查看: 返回结果是否准确，返回的文本长度需限制
1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
1.2输入不可查到结果的关键字、词、语句；
1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2 结果显示：标题，卖家，销售量，单行/多行，是否有图片
3 结果排序：价格 销量 评价 综合
4 返回结果庞大时，限制第一页的现实量，需支持翻页
5 多选项搜索：关键字 品牌 产地 价格区间 是否天猫 是否全国购
6 是否支持模糊搜索，支持通配符的查询
7 网速慢的情况下的搜索
8 搜索结果为空的情况
9 未登录情况和登录情况下的搜索（登录情况下 存储用户搜索的关键字/搜索习惯）

性能测试
1 压力测试：在不同发用户数压力下的表现（评价指标如响应时间等）
2 负载测试：看极限能承载多大的用户量同时正常使用
3 稳定性测试：常规压力下能保持多久持续稳定运行
4 内存测试：有无内存泄漏现象
5 大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。

界面/易用性
交互界面的设计是否便于、易于使用
1 依据不同的查询结果会有相关的人性化提示，查不到时告知？查到时统计条数并告知？有疑似输入条件错误时提示可能正确的输入项等等处理；
2 查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
3 标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
4 输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？

兼容性
1 WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
2 IE/FIREFOX/GOOGLE/360/QQ等各类浏览器下及各版本条件下、各种显示分辨率条件下的应用
3 SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
4 简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5 IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
6 与各相关的监控程序的兼容性测试，如输入法、杀毒、监控、防火墙等工具同时使用

安全性
1 被删除、加密、授权的数据，不允许被SQL注入等攻击方式查出来的，是否有安全控制设计；
2 录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。
3 通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
4 对涉及国家安全、法律禁止的内容是否进行了相关的过滤和控制；

12.如何对一瓶矿泉水进行测试

答：测试项目：矿泉水
需求测试:查看使用说明书
界面测试:查看外观
功能度：用水杯装水看漏不漏；水能不能被喝到
安全性：瓶子的材质有没有毒或细菌
可靠性：从不同高度落下的损坏程度
可移植性：再不同的地方、温度等环境下是否都可以正常使用
兼容性：是否能够容纳果汁、白水、酒精、汽油等
易用性：是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对的用法、限制、使用条件等有详细描述
疲劳测试：将盛上水（案例一）放24小时检查泄漏时间和情况；盛上汽油（案例二）放24小时检查泄漏时间和情况等
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试:高度

13、如何测试登陆界面

答：具体需求： 有一个登陆页面， （假如上面有2个textbox, 一个提交(登陆)按钮。 请针对这个页面设计30个以上的TestCase.）
首先，你要了解用户的需求，比如这个登录界面应该是弹出窗口式的，还是直接在网页里面。对用户名的长度，和密码的强度（就是是不是必须多少位，大小写，特殊字符混搭）等。还有比如用户对界面的美观是不是有特殊的要求？（即是否要进行UI测试）。剩下的就是设计用例了 ，等价类，边界值等等。
请你记住一点，任何测试，不管测什么都是从了解需求开始的。

功能测试(Function test)
　　0. 什么都不输入，点击提交按钮，看提示信息。（非空检查）
　　1.输入正确的用户名和密码，点击提交按钮，验证是否能正确登录。（正常输入）
　　2.输入错误的用户名或者密码, 验证登录会失败，并且提示相应的错误信息。（错误校验）
　　3.登录成功后能否能否跳转到正确的页面（低）
　　4.用户名和密码，如果太短或者太长，应该怎么处理（安全性，密码太短时是否有提示）
　　5.用户名和密码，中有特殊字符（比如空格），和其他非英文的情况（是否做了过滤）
　　6.记住用户名的功能
　　7.登陆失败后，不能记录密码的功能
　　8.用户名和密码前后有空格的处理
　　9.密码是否加密显示（星号圆点等）
　　10.牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
　　11.登录页面中的注册、忘记密码，登出用另一帐号登陆等链接是否正确
　　12.输入密码的时候，大写键盘开启的时候要有提示信息。

界面测试(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.主流的浏览器下能否显示正常已经功能正常（IE,6,7,8,9, Firefox, Chrome, Safari,等）
　　2.不同的平台是否能正常工作，比如Windows, Mac
　　3.移动设备上是否正常工作，比如Iphone, Andriod
　　4.不同的分辨率

本地化测试（Localization test）
　　1. 不同语言环境下，页面的显示是否正确。
　　软件辅助性测试 （Accessibility test）
　　软件辅助功能测试是指测试软件是否向残疾用户提供足够的辅助功能
　　2. 高对比度下能否显示正常 （视力不好的人使用）

14.请你说一下jmeter

Jmeter：Apache JMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。 它可以用于测试静态和动态资源，例如静态文件、Java 小服务程序、CGI 脚本、Java 对象、数据库、FTP 服务器， 等等。JMeter 可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
为什么使用Jmeter：

• 开源免费，基于Java编写，可集成到其他系统可拓展各个功能插件

• 支持接口测试，压力测试等多种功能，支持录制回放，入门简单

• 相较于自己编写框架或其他开源工具，有较为完善的UI界面，便于接口调试

• 多平台支持，可在Linux，Windows，Mac上运行

用例生成与导出：

Jmeter的用例格式为jmx文件，实际为xml格式，感兴趣可以学习下自己定制生成想要的jmx文件。

生成原则：

每个功能模块为一个独立的jmx文件。增加可维护性。（尽量不要将一个jmx文件放入太多功能，后期维护成本会很高。）

模块的私有变量保存在模块中，多模块共有的（例如服务器ip端口等）可以考虑存在单独的文件中读取。

接口测试不要放太多线程，毕竟不是做压力测试，意义也不大。

导出方法：

编写测试用例

文件——保存为——确定：

Jmeter运行模式及参数

GUI模式

打开已有的jmx文件（文件——打开）

点击启动按钮运行

命令行模式

依赖：

配置jmeter环境变量（windows下为将${jmeterhome}/bin加入Path变量）

如果未加入环境变量，在执行的时候可以直接给出全路径或在${jmeterhome}/bin下执行

命令：

jmeter -n -t -l

参数：

-h 帮助 -> 打印出有用的信息并退出

-n 非 GUI 模式 -> 在非 GUI 模式下运行 JMeter

-t 测试文件 -> 要运行的 JMeter 测试脚本文件

-l jtl文件 -> 记录结果的文件

-r 远程执行 -> 启动远程服务

-H 代理主机 -> 设置 JMeter 使用的代理主机

-P 代理端口 -> 设置 JMeter 使用的代理主机的端口号

-j 日志文件->设置JMeter日志文件的名称

实例：

JMeter -n -t my_test.jmx -l log.jtl -H my.proxy.server -P 8000

执行步骤：

JMeter 默认去当前目录寻找脚本文件，并把日志记录在当前目录。比如你在 C:\tools\apache-jmeter-2.11\bin 目录下执行以上命令，JMeter 会去该目录下寻找 test.jmx 脚本并把执行结果放在该目录。如果你的脚本在其他目录，而且想要把执行结果放在另外文件夹，可以使用绝对路径告诉 JMeter。

执行结果查看：

GUI界面打开聚合报告
在GUI界面创建一个聚合报告
聚合报告界面点击浏览，选中生成的.jtl文件，打开

Jmeter使用
Jmeter创建接口测试计划实例：
测试用例应该作为测试的基础内容，而用例的结构可能划分，则是用例的基础（忽然在这里想说一下，用例仅仅是一项测试活动的纲要，有最好，没有的话能保证质量也OK。更不用说用例的格式问题，无论是表格还是导图，其实都无所谓！本文的用例是指jmx文件中的控件结构）。

• 模块名称（测试计划）：每个模块独立划分为一个jmx文件（例如登陆模块），最好与接口类一一对应。对应的服务器信息，数据库信息等可存在这里。

• 数据准备：用于测试数据的准备（例如账号信息）。

• 结果查看：用于放置需要查看结果的控件（例如结果树）。

• 线程组：所有的接口测试用例放在线程组下，集中定义线程等信息

• 获取线程对应测试数据：用于获取针对独立线程的测试数据，例如在数据准备里面获得了账号信息，在这里根据账号信息去数据库获取对应的名称，ID等信息。

• 请求名称：用简单控制器为文件夹，内有不同的请求。简单控制器为一个独立的接口，不同请求对应不同的代码路径（例如成功请求，失败请求等）。建议请求名称最好用英文形式，否则后期持续集成或许会出现问题（no zuo no die！）。

• 在每条请求内放置正则匹配（用于应对需要返回值作为下次请求的参数的情况）以及断言。

15.请你进行测试：前端下拉框实现，测试下拉框定位方式

链接: Selenium+Python自动化测试对下拉菜单的定位
链接: 【Selenium自动化测试】多种下拉框定位及选择

16.请你来聊一聊appium断言

17.请你来说一下购物车的测试用例

答：界面测试
界面布局、排版是否合理
文字是否显示清晰
不同卖家的商品是否区分明显

功能测试
未登录时
将商品加入购物车，页面跳转到登录页面，登陆成功后购物车数量增加
点击购物车菜单，页面跳转到登陆页面
登录后
所有连接是否跳转正确
商品是否可以成功加入购物车
购物车总数是否有限制
商品总数是否正确
全选功能是否好用
删除功能是否好用
价格总计是否正确
商品文字太长时是否显示完整
店铺名字太长时是否显示完整
购物车中下架的商品是否有标注
新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）
是否支持TAB/ENTER等快捷键
商品删除后商品总数是否减少
购物车结算功能是否好用
将商品移入收藏夹功能是否好用

兼容性测试
不同浏览器测试
pc端和移动端
ios和安卓

易用性测试
删除功能是否有提示
是否有回到顶部功能

性能测试
压力测试
并发测试

18.请你进行一下弱网模拟

答：方法一：charles弱网模拟


配置参数解析：
bandwidth —— 带宽，即上行、下行数据传输速度
utilisation —— 带宽可用率，大部分modern是100%

round-trip latency —— 第一个请求的时延，单位是ms。
MTU —— 最大传输单元，即TCP包的最大size，可以更真实模拟TCP层，每次传输的分包情况。

Releability —— 指连接的可靠性。这里指的是10kb的可靠率。用于模拟网络不稳定。
Stability —— 连接稳定性，也会影响带宽可用性。用于模拟移动网络，移动网络连接一般不可靠。

使用chrome的webview调试工具，缺点是只适用于web页面的弱网模拟。

方法二：chrome的webview调试工具弱网模拟
使用chrome的webview调试工具，缺点是只适用于web页面的弱网模拟。

具体步骤：

（1）应用打开webview调试功能，具体如下：

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {

WebView.setWebContentsDebuggingEnabled(true);

}

（2）手机链接电脑，运行APP，进入具体H5页面；

（3）chrome的DevTools中打开Webview：进入chrome://inspect/#devices，会显示已经连接设备，选中待调试webview的inspect
network页面，No throttling下拉框，可以进行网络模拟。

方法三：iOS手机自带Network Link Conditioner 弱网模拟
iPhone手机打开开发者选项，具体参考：
设置-开发者选项 > Network Link Conditioner 入口。
系统已经内置常见网络配置，也可以增加自定义配置。

具体配置参数：
in Bandwidth 下行带宽，即下行网络速度
In packet loss 下行丢包率
in delay 下行延迟，单位ms
out bandwidth 上行带宽
out packet loss 上行丢包率
out delay 上行延迟
DNS delay DNS解析延迟
protocol 支持Any，IPV4、IPV6
interface 支持Any，WI-Fi，cellular（蜂窝网）

19、你写的测试程序是怎么样的，你写过前端、后端程序吗？

答：我写的测试程序是用Java语言的Junit测试框架实现的
比如：

package org.jbpm.tutorial.helloworld;   
   
import junit.framework.TestCase;   
import org.jbpm.graph.def.ProcessDefinition;   
import org.jbpm.graph.exe.ProcessInstance;   
import org.jbpm.graph.exe.Token;   
   
public class HelloWorldTest extends TestCase {   
     
  public void testHelloWorldProcess() {   
      /*  
          这个类测试方法演示了一个流程的在代码中以字符串形式定义和这个流程定义的具体执行。   
          这个流程定义包含三个节点：一个未命名的开始状态（start-state），   
          一个名字为's'的状态（state）和一个名字为'end'的结束状态（end-state）。   
          下一行的功能是把一段xml文本解析为一个ProcessDefinition，  
          一个ProcessDefinition是一个java对象的形式对流程的正式的描述。  
      */   
      ProcessDefinition processDefinition = ProcessDefinition.parseXmlString(   
        "<process-definition>" +   
        "  <start-state>" +   
        "    <transition to='s' />" +   
        "  </start-state>" +   
        "  <state name='s'>" +   
        "    <transition to='end' />" +   
        "  </state>" +   
        "  <end-state name='end' />" +   
        "</process-definition>"   
      );   
      /*  
          下边的一行根据流程定义构造了的一个具体的执行实例。 构造以后，执行的流程就有了一个被定位在开始 
          状态（start-state）上的主要的执行路径   
      */   
          ProcessInstance processInstance =    
              new ProcessInstance(processDefinition);   
      /*  
          构造以后，执行的流程就有了一个主要的执行路径（root token）   
      */   
          Token token = processInstance.getRootToken();   
      /*  
              当然，构造以后，流程定义的主要的执行路径被定位在开始状态（start-state）  
      */   
          assertSame(processDefinition.getStartState(), token.getNode());     
      /*  
              开始流程执行，通过默认的转换（transition）离开开始状态（start-state）  
      */   
          token.signal();   
      /*  
              直到运行的流程进入一个等待状态，signal方法将一直被阻塞，运行的流程将要进入第一个等待状态：状 
              态‘s’.因此现在主要的执行路径,定位到了状态‘s’上。   
      */   
          assertSame(processDefinition.getNode("s"), token.getNode());   
      /*  
              执行signal，流程将继续执行，将通过默认的转换（transition）离开状态‘s’  
      */   
          token.signal();   
      /*  
                  流程实例已经到达了结束状态。  
      */   
      assertSame(processDefinition.getNode("end"), token.getNode());   
    }  
}  

前端和后端不同开发工具需要编写程序进行跨域处理，然后前端程序才能通过Ajax从后端获取文本数据，后端程序是通过连接数据库编写sql语句来操作数据的。

20、请问你有没有写过测试脚本，怎么写的？

答：写过性能测试-用户登录测试脚本

#!/bin/sh
# 用户登录信息监控测试 
# 能够显示最近几次、截止某一日期用户登录情况：
# 能够现实当前系统最近重启情况
# 
 
#步骤1
test_title="用户登录信息监控测试 "
expect_result1=" 预期结果：能够显示最近几次、截止某一日期用户登录情况"
result_path=./
echo -e "\n" >> ${result_path}test_102_result.txt
date >> ${result_path}test_102_result.txt
echo ${test_title} >> ${result_path}test_102_result.txt
echo -e  >> ${result_path}test_102_result.txt
echo ${ecpect_result1} >> ${result_path}test_102_result.txt
 
(who /var/log/wtmp) >> ${result_path}test_102_result.txt 2>&1
 
#步骤2
expect_result2="预期结果：能够显示当前系统最近重启的情况"
echo -e   >> ${result_path}test_102_result.txt
echo ${expect_result2} >> ${result_path}test_102_result.txt
echo -e   >> ${result_path}test_102_result.txt
(last | grep reboot) >> ${result_path}test_102_result.txt 2>&1
echo -e "\n" >> ${result_path}test_102_result.txt

21、请问你有没有写过web测试，怎么写的？

答：Web测试主要从下面几个大方向考虑
功能测试，主要做链接测试，表单测试，cookies测试，设计语言测试等

性能测试，考虑连接速度测试，以及负载测试，例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？还有压力测试

可用性测试，比如导航测试，图形测试，内容测试，整体界面测试等

兼容性测试，市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。

安全性测试，

（1）现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。

（2）Web应用系统是否有超时的限制，也就是说，用户登陆后在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆才能正常使用。

（3）为了保证Web应用系统的安全性，日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

（4）当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。

（5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编辑脚本的问题。

23、请你回答一下如何测试手机开机键？

答：功能测试：
按下开机键，屏幕能否亮起

性能测试：

按下开机键，屏幕能否在规定时间内亮起

压力测试

连续多次按下开机键，观察屏幕是否能一直亮起，到多久时间失灵

健壮性测试

给定一个中了病毒的手机或者是淘汰许久的老机子，安歇开机键观察屏幕能否亮起

可靠性测试

连续按下开机键有限次数，比如1万次，记录屏幕未亮起的次数

可用性测试

开机键按下费不费力，开机键的形状设计是否贴合手指，开机键的位置设计是否方便

24、请问你遇到过哪些印象深刻的bug，接口测试出现bug的原因有哪些？

答：WEB测试常见BUG：
1、翻页
翻页时，没有加载数据为空，第二页数据没有请求
翻页时，重复请求第一页的数据
翻页时，没有图片的内容有时候会引用有图片的内容
2、图片数据为空
图片数据为空时，会保留为空的图片数据位置
3、链接为空
链接为空时，点击图片，会刷新页面
4、服务端部分字段为空
整个页面出现空白
5、session过期
session过期后，可能整个页面的数据就会丢失，页面呈现空白6、文字内容过多
文字内容过多时，页面排版错乱
7、不同平台的浏览器，功能、样式问题
PC与手机浏览器，同段代码会展示不同的样式
同个功能在不同的浏览器上面，功能会出现失效的现象
8、弹窗，针对图片弹窗
不同的手机，弹窗处理机制会不一样，导致有些手机点击弹窗按钮，弹窗不会出现
9、第三方应用，访问网页
会偶尔出现，HTML+CSS样式不起任何作用，页面呈现空白（遇见过，无复现）
第三方应用登录网页后，登录账户错乱
第三方应用分享，微信、QQ、微博三种分享渠道，有三种不一样的分享机制
10、音频网页
不同手机、不同的系统版本，有些手机进入网页后，音频效果会自动播放，相反有些手机需要点击播放按钮，才能播放
11、自动检测是否安装应用
有些手机上是安装过应用的，通过手机浏览器打开此应用的任何页面，页面顶部会不会自动判断是否安装此应用，有些手机可以自动检测，但部分手机是不可以检测的，安卓手机偏多，iPhone手机也不少
12、cookie过期
WEB系统基本上会用到cookie，如果cookie未在预定的时间内进行保存，刷新页面，会对cookie有影响
13、链接正确性
链接未按指定的跳转
所跳转的链接不存在
链接不正确跳转
14、导航测试
WEB基本上每个页面顶部都会有导航，看下导航是否为死导航、乱导航等
15、分辨率
页面文字及样式，应支持常见的分辨率
16、文本字符
简单的文本字符判断，像手机号不能输入非数字以外的字符
17、性能测试
请求数据时的响应，会不会很久才会请求到数据
18、图片测试
正常的图片展示，是否会模糊
图片是否会截断及压缩
图片格式的处理，JPG、PNG、GIF
19、客户端兼容性
平台兼容性，第三方客户端应用内引用web页面，主要是Android与IOS系统
浏览器兼容性
20、整体界面测试
整体界面的样式、文字排列、图片展示等

PS：
session与cookie的区别：
session是保存在服务器上面的，cookie是保存在本地的，本地cookie向服务端请求时，会在coolie中带一个session id向服务端发出数据请求，而服务端会根据这个session id去找到这个session文件，然后进行数据处理。

接口测试
一、接口参数数据类型：

1. 数值型
2. 字符串类型
3. 数组或者 链表类型
4. 结构体
   二、接口测试常见bug：
5. 特殊值处理不当导致程序异常退出或者崩溃
6. 类型边界溢出，导致数据读出和写入不一致
7. 取值边界外值未返回正确的错误信息
8. 参数 为null或空字符串“”等
9. 权限未处理，可以访问其他用户的信息
   例如:无权限可以访问，或者 一般用户可以访问管理员权限）
10. 逻辑校验不完善，可利用漏洞获取非正当利益
    例如：某网站兑换1块钱需要100币，当小于100币时调用后台 接口是否可以兑换
    例如：购物结算时为100元，调用 后台接口设为0元，哈哈
11. 状态处理不当，导致逻辑出现错误（可能程序员123都搞懵了）
12. 数组类型item个数为0或者item重复时程序异常退出
13. 超时问题，超时后处理
14. 潜在性能问题（后台提交处理或者把性能风险提前提出）

25、你在做项目中有做过压力测试吗，怎么做

答：1、首先对要测试的系统进行分析，明确需要对那一部分做压力测试，比如秒杀，支付

2、如何对这些测试点进行施压

第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作

第二点借助一些压力测试工具比如Jmeter,LoadRunner

3、如何对这些测试点进行正确的施压

需要用压力测试工具或者其他方法录制脚本，模拟用户的操作

4、对测试点设计多大的压力比较合适？

需要明确压力测试限制的数量，即用户并发量

5、测试结束后如何通过这些数据来定位性能问题

通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的

26、请问你在项目中关于功能测试和接口测试是怎么做的

答：功能测试：
首先制定测试计划，然后进行测试设计，将在测试计划阶段指定的测试活动分解，进而细化，为若干个可执行程序的子测试过程，然后执行测试，按照测试计划使用测试用例对待测项目进行逐一的，详细的排查分析评估，最后对测试结果进行统计和分析，

接口测试：
什么是接口（API）
API全称Application Programming Interface，这里面我们其实不用去关注AP，只需要I上就可以。一个API就是一个Interface。我们无时不刻不在使用interfaces。我们乘坐电梯里面的按钮是一个interface。我们开车一个踩油门它也是一个interface。我们计算机操作系统也是有很多的接口。(这是目前个人找到比较好理解的一段解释)

接口就是一个位于复杂系统之上并且能简化你的任务，它就像一个中间人让你不需要了解详细的所有细节。那我们今天要讲的Web API就是这么一类东西。像谷歌搜索系统，它提供了搜索接口，简化了你的搜索任务。再像用户登录页面，我们只需要调用我们的登录接口，我们就可以达到登录系统的目的。

现在市面上有非常多种风格的Web API，目前最流行的是也容易访问的一种风格是REST或者叫RESTful 风格的API。从现在开始，以下我提到的所有API都是指RESTful风格的API。

什么是接口测试和为什么要做接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。

现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。

如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。

接口测试的策略
接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：1.测试接口文档（需求文档） 2.根据接口文档编写测试用例（用例编写完全可以按照以往规则来编写，例如等价类划分，边界值等设计方法）3. 执行测试，查看不同的参数请求，接口的返回的数据是否达到预期。

27、请问你有用过什么测试工具吗，用过哪些？

答： AppUI自动化测试
Appium 是一个移动端自动化测试开源工具，支持iOS 和Android 平台，支持Python、Java 等语言，即同一套Java 或Python 脚本可以同时运行在iOS 和Android平台，Appium 是一个C/S 架构，核心是一个 Web 服务器，它提供了一套 REST 的接口。当收到客户端的连接后，就会监听到命令，然后在移动设备上执行这些命令，最后将执行结果放在 HTTP 响应中返还给客户端。

WebUI自动化测试
Selenium是一个用于Web应用程序测试的工具。Selenium测试直接运行在浏览器中，就像真正的用户在操作一样。支持的浏览器包括IE(7、8、9)、Mozilla Firefox、Mozilla Suite等。这个工具的主要功能包括：测试与浏览器的兼容性——测试你的应用程序看是否能够很好得工作在不同浏览器和操作系统之上。测试系统功能——创建回归测试检验软件功能和用户需求。支持自动录制动作和自动生成 .Net、Java、Perl等不同语言的测试脚本。Selenium 是ThoughtWorks专门为Web应用程序编写的一个验收测试工具。其升级版本为Webdriver。

Jmeter接口测试，性能测试
JMeter是Apache组织的开放源代码项目，它是功能和性能测试的工具，100%的用java实现；
JMeter可以用于测试静态或者动态资源的性能（文件、Servlets、Perl脚本、java对象、数据库和查询、ftp服务器或者其他的资源）。JMeter用于模拟在服务器、网络或者其他对象上附加高负载以测试他们提供服务的受压能力，或者分析他们提供的服务在不同负载条件下的总性能情况。你可以用JMeter提供的图形化界面分析性能指标或者在高负载情况下测试服务器/脚本/对象的行为。

接口测试
Postman 提供功能强大的 Web API 和 HTTP 请求的调试，它能够发送任何类型的HTTP 请求 (GET, POST, PUT, DELETE…)，并且能附带任何数量的参数和 Headers。不仅如此，它还提供测试数据和环境配置数据的导入导出，付费的 Post Cloud 用户还能够创建自己的 Team Library 用来团队协作式的测试，并能够将自己的测试收藏夹和用例数据分享给团队。
Jenkins持续集成
自动化构建 编译，部署，任务执行，测试报告，邮件通知等。

28、请你设计一个微信朋友圈点赞的测试用例

答：功能测试：
点赞某条朋友圈，验证是否成功

接口测试：
点赞朋友圈，验证朋友能否收到提示信息

性能测试
点赞朋友圈，是否在规定时间显示结果，是否在规定时间在朋友手机上进行提示

兼容性测试
在不同的终端比如ipad,手机上点赞朋友圈，验证是否成功

29、请问如果用户点击微博的关注图标但是app上面没有反应，应该怎么排查这个问题

答：先排除手机是否出现故障
在排除手机网络是否稳定，换一个稳定的网络再试一次，因为在弱网或者没网的情况下也会出现该类问题
若手机网络环境差或者无网络连接，还要验证是否有关于网络差的提示。
判断是否手机内存溢出
看该用户关注人数是否已达上线，普通用户上限2000，会员用户最高上限可3000
若达到上限，可能返回提示信息出错
可能是版本问题或者是安装包问题
更新应用
重新安装
在debug模式下，查看app的线程列表，看线程是否卡主。

30、在做测试的过程中，假如前端和后端吵起来了都在踢皮球觉得对方该改代码，你怎么办？

答：找技术领导或者leader们基于安全性、性能、可测性、可维护性讨论敲定一个解决方案，做到开发环境方便开发，线上环境少配置、少依赖、少出错机会。

31、如果广东用户头条app刷不出东西了，你应该怎么排查问题

答：先排除手机是否出现故障
在排除手机网络是否稳定，换一个稳定的网络再试一次，因为在弱网或者没网的情况下也会出现该类问题
若手机网络环境差或者无网络连接，还要验证是否有关于网络差的提示。
判断是否手机内存溢出
看该用户关注人数是否已达上线，普通用户上限2000，会员用户最高上限可3000
若达到上限，可能返回提示信息出错
可能是版本问题或者是安装包问题
更新应用
重新安装
在debug模式下，查看app的线程列表，看线程是否卡主。

32、请你说一下能不能用机器学习去进行自动化测试，如何监控异常流量，如果是脉冲呢，如何和正常流量作区分

答：如何用机器学习去进行自动化测试，就是让自动化测试变得更加智能，在自动化测试过程中，当测试功能模块越来越多，没有太多的时间去全部覆盖，我们可以采用归纳学习的方式，基于自动化测试的执行结果或者手工测试执行的结果为数据输入，然后基于一定的模型（例如：以通过率和模块的重要率计算的平均值）得出测试推荐模块，或者当要执行一个功能模块时，基于历史数据和模型（bug出现的错误相关性，功能相关性等）计算出与该功能模块相关性最大模块，并推荐测试。
如何监控异常流量

1、抓包
tcpdump -i eth0 -w server.cap
对包文件使用第三方工具如：wireshark做分析

2、iftop
yum install iftop

3、iptraf
yum install iptraf –y 或 yum install iptraf-ng -y
启动命令ifptraf-ng

33、请问如何将大量日志的异常记录或错误揪出来

链接: 为了方便查找服务器的运行原因，最好对错误日志进行记录，那么该如何记录日志呢？
按Ctrl+F 查找error和exception关键字

34、请问如何对登录界面进行测试

35、请你说一说当前工作中涉及的测试问题(测试流程和测试性能)

答：需求分析，测试计划，测试设计，测试环境搭建，测试执行，测试记录，缺陷管理，软件评估，测试总结，测试维护

36、请你说一说洗牌问题的思路并手写代码，并设计测试用例

答：洗牌问题：有个长度为2n的数组{a1,a2,a3,…,an,b1,b2,b3,…,bn}，希望排序后{a1,b1,a2,b2,….,an,bn}，请考虑有无时间复杂度o(n)，空间复杂度0(1)的解法。
void PerfectShuffle(int A,int n){
if(n <= 1){
return;
}//if
//
int size = 2n;
int index,count;
for(int i = n;i < size;++i){
// 交换个数

count = n - (i - n) - 1;

// 待交换

index = i;
for(int j = 1;j <= count;++j){
swap(A[index],A[i-j]);
index = i - j;
}//for
}//for
}
};
可以就数组的类型，可以是int型的，浮点型的，还可以是大数类型，负数，进行测试。

37、请你测试一下游戏中英雄的技能

答：去实战模拟测试，技能效果：生成的buff与debuff，造成伤害，作用范围，造成伤害时间点与动画匹配。 特殊：冲突性检测，该角色该技能的释放，能否取消后摇，能否隐藏掩盖前摇，释放过程自身的硬直时间段。从动画哪一段开始生效，buff与伤害的同时性。buff与其他buff的冲突问题。多段伤害生效先后问题。 最终，角色技能的设计预期是否匹配是最重要的，如果没有这样的预期，就需要考虑整体平衡性问题。

38、请你回答一下性能测试有哪些指标，对一个登录功能做性能测试，有哪些指标，怎么测出可同时处理的最大请求数量？

答：性能测试常用指标：
从外部看，主要有
1、吞吐量：每秒钟系统能够处理的请求数，任务数
2、响应时间：服务处理一个请求或一个任务的耗时
3、错误率：一批请求中结果出错的请求所占比例

从服务器的角度看，性能测试关注CPU，内存，服务器负载，网络，磁盘ＩＯ

对登录功能做性能测试
单用户登陆的响应界面是否符合预期
单用户登陆时后台请求数量是否过多
高并发场景下用户登录的响应界面是否符合预期
高并发场景下服务端的监控指标是否符合预期
高集合点并发场景下是否存在资源死锁和不合理的资源等待
长时间大量用户连续登录和登出，服务器端是否存在内存泄漏

怎么测出可同时处理的最大请求数量
可以采用性能测试工具(WeTest服务器性能)，该工具是腾讯wetest团队出品，使用起来很简单方便，但测试功能相当强大，能提供10w+以上的并发量，定位性能拐点，测出服务器模型最大并发

39、请问你有没有做过什么单元测试，怎么进行单元测试，对一个没有参数没有返回值但可能对全局变量有影响的怎么进行单元测试

答：如何进行单元测试：
１、创建单元测试，该工具可以对任何类、接口、结构等实体中的字段、属性、构造函数、方法等进行单元测试。创建单元测试大致可以分为两类：

整体测试，整体测试是在类名称上右击鼠标，在下拉菜单中点击创建单元测试选项。这样就可以为整个类创建单元测试了，这时他会为整个类可以被测试的内容全部添加测试方法。开发人员直接在这些自动生成的测试方法中添加单元测试代码就可以了。

单独测试，如果只想单独对某个方法、属性、字段进行测试，则可以将鼠标焦点放在这个待测试的项目名称之上，然后点击鼠标右键，在右键菜单中选择创建单元测试选项。这样就可以单独为某个方法创建单元测试了。

运行单元测试

查看测试结果

编写单元测试代码

测试没有参数的函数，它可能还有别的输入，例如全局变量，成员变量，或调用子函数获得的输入（这个要使用工具才能做到），只要函数需读取的，都应该设定初始值，如果完全没有，没有输入也是一种输入，照样测试就是了。同样道理，输出也不仅仅是返回值，没有返回值还可能修改了全局变量什么的，这些也是要判断的输出。

40、请问你有没有做过压力测试

答：1、首先对要测试的系统进行分析，明确需要对那一部分做压力测试，比如秒杀，支付
2、如何对这些测试点进行施压 第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作 第二点借助一些压力测试工具比如Jmeter,LoadRunner
3、如何对这些测试点进行正确的施压 需要用压力测试工具或者其他方法录制脚本，模拟用户的操作
4、对测试点设计多大的压力比较合适？ 需要明确压力测试限制的数量，即用户并发量
5、测试结束后如何通过这些数据来定位性能问题 通过测试可以得到吞吐量，平均响应时间等数据，这个数据的背后是整个后台处理逻辑综合作用的结果，这时候就可以先关注系统的CPU，内存，然后对比吞吐量，平均响应时间达到瓶颈时这些数据的情况，然后就能确认性能问题是系统的哪一块造成的

41、对于有系统大量并发访问，你会如何做测试，有什么建议

答：如何做高并发系统的测试，一般而言，整体的测试策略是：先针对部分系统进行性能测试及压力测试，得到各部分的峰值处理性能，再模拟整体流程测试，重点测试整体业务流程以及业务预期负荷，着重测试以下几点：

1、不同省份，不同运营商CDN节点性能，可采用典型压力测试方案

2、核心机房BGP网络带宽，此部分重点在于测试各运行商的BGP网络可靠性，实际速率，一般采用smokeping,lxChariot等工具

3、各类硬件设备性能，一般采用专业的网络设备测试工具

4、各类服务器并发性能，分布式处理能力，可采用压力测试方案工具

5、业务系统性能，采用业务系统压力测试方案

6、数据库处理性能，这部分需要结合业务系统进行测试，以获取核心业务场景下的数据库的TPS/QPS，

7、如果有支付功能，需要进行支付渠道接口及分流测试，此部分相对而言可能是最大的瓶颈所在，此外还涉及备份方案，容灾方案，业务降级方案的测试。