判断闰年的标准是:能整除4且不能整除100，能整除400。
设定合法的年份为1-9999
publicclassTest2{publicstaticvoidmain(String[]args){Scannerin=newScanner(System.in);intyear=in.nextInt();if(year<=0||year>9999){System.out.println("请输入正确的年份");}if((year%4==0&&year%100!=0)||year%400==0){System.out.println("闰年");}else{System.out.println("不是闰年");}}}测试用例：
用户名和密码，如果太短或者太长，应该怎么处理
用户名和密码，中有特殊字符（比如空格），和其他非英文的情况
记住用户名的功能
登陆失败后，不能记录密码的功能
用户名和密码前后有空格的处理
密码是否非明文显示显示，使用星号圆点等符号代替。
牵扯到验证码的，还要考虑文字是否扭曲过度导致辨认难度大，考虑颜色（色盲使用者），刷新或换一个按钮是否好用
输入密码的时候，大写键盘开启的时候要有提示信息。
什么都不输入，点击提交按钮，检查提示信息。
布局是否合理，testbox和按钮是否整齐。
testbox和按钮的长度，高度是否符合要求。
界面的设计风格是否与UI的设计风格统一。
界面中的文字简洁易懂，没有错别字。
模拟大量用户同时登陆，检查一定压力下能否正常登陆跳转。
用户名和密码是否通过加密的方式，发送给Web服务器。
用户名和密码的验证，应该是用服务器端验证，而不能单单是在客户端用javascript验证。
用户名和密码的输入框，应该屏蔽SQL注入攻击。
用户名和密码的的输入框，应该禁止输入脚本（防止XSS攻击）。
防止暴力破解，检测是否有错误登陆的次数限制。
是否可以全用键盘操作，是否有快捷键。
输入用户名，密码后按回车，是否可以登陆。
输入框能否可以以Tab键切换。
不同浏览器下能否显示正常且功能正常（IE,6,7,8,9,Firefox,Chrome,Safari,等）。
同种浏览器不同版本下能否显示正常且功能正常。
不同的平台是否能正常工作，比如Windows,Mac。
移动设备上是否正常工作，比如Iphone,Andriod。
不同的分辨率下显示是否正常。
不同语言环境下，页面的显示是否正确。
1.功能：
一.功能测试
使用正常的车牌，保持车牌静止，检查每个摄像头是否能抓拍车牌；
使用类似非车牌的写有字的纸板，检查每个摄像头是否抓拍；
使用正常的车牌，保持车牌较高速移动，检查每个摄像头是否能抓拍车牌；
在多种情况下检查每个摄像头抓拍到的车牌能否正常交给系统处理，如临时断电、断网后能否正常将数据交给系统；
使用抓拍到的正常的车牌，交由系统处理，检查系统能否识别车牌；
使用非车牌的其他图片，交由系统处理，检查系统能否识别；
在多种情况下检查系统能否将正常识别出的车牌进行上传，如临时断电、断网后未上传数据是否能继续上传；
构造非车牌的其他内容的数据，检查系统能否将异常内容进行上传；
检查上传至网络的车牌能否正常展示出来；
上传非车牌的其他内容的数据，检查能否正常显示出来。
二.性能测试
同时向一个摄像头展示多个静止的车牌，检查摄像头能否抓拍到多个车牌；
同时向一个摄像头展示多个较高速运动的车牌，检查摄像头能否抓拍到多个车牌；
模拟大量抓拍照片同时交由系统处理，检查一定压力下系统能否正常识别车牌；
模拟大量车牌同时上传，检查一定压力下能否上传成功。
三.安全性测试
检查是否能够通过给车牌加装饰物等方法，使摄像头无法抓拍或抓拍后系统无法正常识别车牌。
首先明确需要测试压力的内容:
a.硬盘I/o
b.内存
c.CPU
a.长连接
a1.最大连接数
a2.流量(内网、外网、进、出)
b.长连接短周期(类似Http的TCP应用，这个比较特殊的一个需求，专门针对LoginAgent)
b1.每秒建立的连接数
b2.实际处理能力
a.每秒事务数
b.每秒锁等待数
c.平均延时(ms)
d.CPU暂用
a.数据库执行的多线程
b.多连接处理
WindowsServer环境测试方式
使用Server自带的性能监测器设置各个进程的监测参数。Window的这个自动工具做的相当强大。大家自己摸一摸基本就会用了。每个参数都由详细的说明。
a.对于数据库的性能测试上，现在由于所有的游戏服务器构架在DB前面都有一个实现DB缓冲功能的进程，以减少数据库频繁的读写操作。所以其实数据库的读是一个轻量级的数量；而数据库的写操作是一个周期性能过程。案例设计一定要能够驱动这种周期性能过程。比如我们游戏的战斗，导致游戏玩家数据的改变，或驱动所有在线玩家数据的周期性存储。
b.选择具有代表性，并且最频繁的游戏操作。用于进行最高用户在线的各种性能指标采集。如，开枪、道具拾取、道具使用、移动、聊天
c.聊天性能测试
广播聊天是最为考验游戏信息发送能力的功能。通过进行全局广播的压力测试。我们可以获取服务器进程发送信息到客户端的最高承载量。进而可以对我们的各种广播功能进行一个预估和频率限制。
d.同屏玩家的移动测试
移动+广播。这两种信息，基本是网络游戏流量的70-80%左右。同屏玩家数量，将会增加各种数据的广播需求，非常影响游戏性能。所以同屏的移动测试也是广播测试的一个必要环节。需要根据实际结果进行适当的优化。
f.由于线程池处理事务，随着事务的时耗，存在一个最优线程数的问题。过多的线程反而会降低服务器效率
a.进行测试需要仔细思考客户端性能影响服务器最后表现的可能性。比如
a1.模拟客户端的性能无法有效处理服务器返回信息,可能就导致服务器发送的信息缓存在服务器系统缓存，从而表现出服务器内存不断增加。表现为服务器发送能力不足，其实可能根本就是客户端的性能问题
b.网络带宽导致最后表现不足
b1.确认服务器的各个网卡，以及相互的带宽。不然可能因为相互带宽，导致服务器对于客户端请求的处理延时。表现为服务器卡机
b2.客户端模拟多个玩家，比如1000个玩家。而客户端的网卡或者客户端与服务器之间的中转服务器带宽过小，导致服务器数据发送不出，内存不断增加。表现为服务器发送能力不足，其实是中间带宽问题。
c.debugi/o导致服务器性能下降
c1.进行性能测试，一定要取消debug用的同步的i/o.比如我们服务器的debuginternalLog.同步i/o是非常影响性能的，特别在压力测试下可能导致每秒上千上万甚至几十万次的执行。一处的文件写入操作就可以导致几十万次的处理能力变成几千次的处理能力。
c2.客户端避免进行阻塞操作导致模拟多用户性能下降，导致服务器表现性能下降
d.流量需要区分内网
网内、外网流量在游戏正式运行时是完全分开的。价格也是完全不同的。一个千M的外网是一个无法想象的运营成本，而kmbps/s现在已经是一个可以接受的代价。游戏进程需要进行不同网卡的配置和绑定。确定内外网流量。
备注；
水倒水杯容量的一半
水倒规定的安全线
水杯容量刻度与其他水杯一致
盖子拧紧水倒不出来
烫手验证
掉地上不易损坏
盖子拧到什么程度水倒不出来
杯子的耐热性
杯子的耐寒性
杯子上放置重物达到什么程度杯子会被损坏
外观完整、美观
大小与设计一样（高、宽、容量、直径）
拿着舒服
材质与设计一样
杯子上的图案掉落
图案遇水溶解
杯子使用的材质毒或细菌的验证
高温材质释放毒性
低温材质释放毒性
倒水方便
喝水方便
携带方便
使用简单，容易操作
防滑措施
杯子能够容纳果汁、白水、酒精、汽油等。
杯子加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
杯子在不同地方、温度环境下都可以正常使用。
水倒水壶容量的一半
水壶容量刻度与其他水壶一致
壶的耐热性
壶的耐寒性
壶上放置重物达到什么程度壶会被损坏
壶上的图案掉落
壶使用的材质毒或细菌的验证
壶能够容纳果汁、白水、酒精、汽油等。
壶加包装（有填充物），六面震动，检查产品是否能应对铁路/公路/航空运输。
壶在不同地方、温度环境下都可以正常使用。
1.功能测试
1.输入关键字，查看:返回结果是否准确，返回的文本长度需限制
1.1输入可查到结果的正常关键字、词、语句，检索到的内容、链接正确性；
1.2输入不可查到结果的关键字、词、语句；
1.3输入一些特殊的内容，如空、特殊符、标点符、极限值等，可引入等价类划分的方法等；
2.结果显示：标题，卖家，销售量，单行/多行，是否有图片
3.结果排序：价格销量评价综合
4.返回结果庞大时，限制第一页的现实量，需支持翻页
5.多选项搜索：关键字品牌产地价格区间是否天猫是否全国购
6.是否支持模糊搜索，支持通配符的查询
7,网速慢的情况下的搜索
8.搜索结果为空的情况
2.负载测试：看极限能承载多大的用户量同时正常使用
3.稳定性测试：常规压力下能保持多久持续稳定运行
4.内存测试：有无内存泄漏现象
5.大数据量测试：如模拟从庞大的海量数据中搜索结果、或搜索出海量的结果后列示出来，看表现如何等等。
2.查询出的结果罗列有序，如按点击率或其他排序规则，确保每次查询出的结果位置按规则列示方便定位，显示字体、字号、色彩便于识别等等；
3.标题查询、全文检索、模糊查询、容错查询、多关键字组织查询（空格间格开）等实用的检索方式是否正常？
4.输入搜索条件的控件风格设计、位置摆放是否醒目便于使用者注意到，有否快照等快捷查看方式等人性化设计？
1.WINDOWS/LINUX/UNIX等各类操作系统下及各版本条件下的应用
3.SQL/ORACLE/DB2/MYSQL等各类数据库存储情况下的兼容性测试
4.简体中文、繁体中文、英文等各类语种软件平台下的兼容性测试
5.IPHONE/IPAD、安卓等各类移动应用平台下的兼容性测试
2.录入一些数据库查询的保留字符，如单引号、%等等，造成查询SQL拼接出的语句产生漏洞，如可以查出所有数据等等，这方面要有一些黑客攻击的思想并引入一些工具和技术，如爬网等。
3.通过白盒测试技术，检查一下在程序设计上是否存在安全方面的隐患；
界面测试:查看外观是否美
功能度：查看水瓶漏不漏；瓶中水能不能被喝到
安全性：瓶子的材质有没有毒或细菌
可靠性：从不同高度落下的损坏程度
可移植性：再不同的地方、温度等环境下是否都可以正常使用
兼容性：是否能够容纳果汁、白水、酒精、汽油等
易用性：是否烫手、是否有防滑措施、是否方便饮用
用户文档：使用手册是否对的用法、限制、使用条件等有详细描述
压力测试：用根针并在针上面不断加重量，看压强多大时会穿透
跌落测试:测试在何种高度跌落会破坏水瓶
Jmeter：ApacheJMeter是Apache组织开发的基于Java的压力测试工具。用于对软件做压力测试，它最初被设计用于Web应用测试，但后来扩展到其他测试领域。它可以用于测试静态和动态资源，例如静态文件、Java小服务程序、CGI脚本、Java对象、数据库、FTP服务器，等等。JMeter可以用于对服务器、网络或对象模拟巨大的负载，来自不同压力类别下测试它们的强度和分析整体性能。另外，JMeter能够对应用程序做功能/回归测试，通过创建带有断言的脚本来验证你的程序返回了你期望的结果。为了最大限度的灵活性，JMeter允许使用正则表达式创建断言。
开源免费，基于Java编写，可集成到其他系统可拓展各个功能插件
支持接口测试，压力测试等多种功能，支持录制回放，入门简单
相较于自己编写框架或其他开源工具，有较为完善的UI界面，便于接口调试
多平台支持，可在Linux，Windows，Mac上运行
Jmeter的用例格式为jmx文件，实际为xml格式，感兴趣可以学习下自己定制生成想要的jmx文件。
每个功能模块为一个独立的jmx文件。增加可维护性。（尽量不要将一个jmx文件放入太多功能，后期维护成本会很高。）
模块的私有变量保存在模块中，多模块共有的（例如服务器ip端口等）可以考虑存在单独的文件中读取。
接口测试不要放太多线程，毕竟不是做压力测试，意义也不大。
编写测试用例
GUI模式
打开已有的jmx文件（文件——打开）
点击启动按钮运行
命令行模式
依赖：
配置jmeter环境变量（windows下为将${jmeterhome}/bin加入Path变量）
如果未加入环境变量，在执行的时候可以直接给出全路径或在${jmeterhome}/bin下执行
命令：
jmeter-n-t-l
参数：
-h帮助->打印出有用的信息并退出
-n非GUI模式->在非GUI模式下运行JMeter
-t测试文件->要运行的JMeter测试脚本文件
-ljtl文件->记录结果的文件
-r远程执行->启动远程服务
-H代理主机->设置JMeter使用的代理主机
-P代理端口->设置JMeter使用的代理主机的端口号
-j日志文件->设置JMeter日志文件的名称
JMeter-n-tmy_test.jmx-llog.jtl-Hmy.proxy.server-P8000
JMeter默认去当前目录寻找脚本文件，并把日志记录在当前目录。比如你在C:\tools\apache-jmeter-2.11\bin目录下执行以上命令，JMeter会去该目录下寻找test.jmx脚本并把执行结果放在该目录。如果你的脚本在其他目录，而且想要把执行结果放在另外文件夹，可以使用绝对路径告诉JMeter。
GUI界面打开聚合报告
在GUI界面创建一个聚合报告
Jmeter创建接口测试计划实例
数据准备：用于测试数据的准备（例如账号信息）。
结果查看：用于放置需要查看结果的控件（例如结果树）。
线程组：所有的接口测试用例放在线程组下，集中定义线程等信息
获取线程对应测试数据：用于获取针对独立线程的测试数据，例如在数据准备里面获得了账号信息，在这里根据账号信息去数据库获取对应的名称，ID等信息。
请求名称：用简单控制器为文件夹，内有不同的请求。简单控制器为一个独立的接口，不同请求对应不同的代码路径（例如成功请求，失败请求等）。建议请求名称最好用英文形式，否则后期持续集成或许会出现问题（nozuonodie！）。
在每条请求内放置正则匹配（用于应对需要返回值作为下次请求的参数的情况）以及断言。
Selenium+Python自动化测试对下拉菜单的定位
定位代码：
#先定位到下拉菜单drop_down=driver.find_element_by_css_selector("div#select2_container>ul")#再对下拉菜单中的选项进行选择drop_down.find_element_by_id("li2_input_2").click()#注：也可以用此方法定位
try:num=input("Enteranumber:")assert(num==10),"Thenumberisnot10!"exceptAssertionError,msg:printmsgprint("Sadly,numnotequalsto10")在上面的程序中，运行到的python的异常与断言。通过raw_input()方法要求用户输入一个数字，通过arrsert判断用户输入的num是否等于10；通过python的AssertionError类型的异常来实捕获这个异常，msg接收异常信息并打印，注意，msg所结构的异常信息是我们自定义的（“Thenumberisnot10!”）。
assertEqual(first,second,msg=None)：判断first和second的值是否相等，如果不相等则测试失败，msg用于定义失败后所抛出的异常信息。
assertNotEqual(first,second,msg=None)：测试first和second不相等，如果相等，则测试失败。
assertTure(expr,msg=None)、assertFalse(expr,msg=None)：测试expr为Ture（或为False）
以下为python2.7版新增的断言方法：
assertIs(first,second,msg=None)、assertIsNot(first,second,msg=None)：测试的first和second是（或不是）相同的对象。
assertIsNone(expr,msg=None)、assertIsNotNone(expr,msg=None)：测试expr是（或不是）为None
assertIn(first,second,msg=None)、assertNotIn(first,second,msg=None)：测试first是（或不是）在second中。second包含是否包含first。
assertIsInstance(obj,cls,msg=None)、assertNotIsInstance(obj,cls,msg=None)：测试obj不（或不是）cls的一个实例。（obj和cls可以是一个类或元组），要检查他们的类型使用assertIs(type(obj),cls)。
界面布局、排版是否合理；文字是否显示清晰；不同卖家的商品是否区分明显。
所有链接是否跳转正确；
商品是否可以成功加入购物车；
购物车商品总数是否有限制；
商品总数是否正确；
全选功能是否好用；
删除功能是否好用；
填写委托单功能是否好用；
委托单中填写的价格是否正确显示；
价格总计是否正确；
商品文字太长时是否显示完整；
店铺名字太长时是否显示完整；
创新券商品是否打标；
购物车中下架的商品是否有特殊标识；
新加入购物车商品排序（添加购物车中存在店铺的商品和购物车中不存在店铺的商品）；
是否支持TAB、ENTER等快捷键；
商品删除后商品总数是否减少；
购物车结算功能是否好用。
不同浏览器测试。
删除功能是否有提示；是否有回到顶部的功能；商品过多时结算按钮是否可以浮动显示。
压力测试；并发测试。
bandwidth——带宽，即上行、下行数据传输速度
utilisation——带宽可用率，大部分modern是100%
round-triplatency——第一个请求的时延，单位是ms。
MTU——最大传输单元，即TCP包的最大size，可以更真实模拟TCP层，每次传输的分包情况。
Releability——指连接的可靠性。这里指的是10kb的可靠率。用于模拟网络不稳定。
方法二：chrome的webview调试工具弱网模拟
使用chrome的webview调试工具，缺点是只适用于web页面的弱网模拟。
具体步骤：
应用打开webview调试功能，具体如下：
if(Build.VERSION.SDK_INT>=Build.VERSION_CODES.KITKAT){WebView.setWebContentsDebuggingEnabled(true);}手机链接电脑，运行APP，进入具体H5页面；
chrome的DevTools中打开Webview：进入chrome://inspect/#devices，会显示已经连接设备，选中待调试webview的inspect
network页面，Nothrottling下拉框，可以进行网络模拟。
方法三：iOS手机自带NetworkLinkConditioner弱网模拟
iPhone手机打开开发者选项
具体参考：
设置-开发者选项>NetworkLinkConditioner入口。
系统已经内置常见网络配置，也可以增加自定义配置。
具体配置参数：
inBandwidth下行带宽，即下行网络速度
Inpacketloss下行丢包率
indelay下行延迟，单位ms
outbandwidth上行带宽
outpacketloss上行丢包率
outdelay上行延迟
DNSdelayDNS解析延迟
protocol支持Any，IPV4、IPV6
开发测试驱动程序一般分为4步：
在编码完成时，应该保证代码处于健康状态–不要遗留下任何测试失败。
写过前端程序。
然后，撰写测试桩与驱动，白盒测试保证代码逻辑中循环和分支都能够走到，黑盒测试保证函数和首先，代码走查结合动态单步跟踪以及观察日志与文件输出，网络、CPU状态。
功能脚本接口正确，输入输出符合设计预期。
另外，需要考虑所依赖的其他功能脚本以及二进制工具，这些功能性单元应该如何使用，调用后的返回会有哪些情况，对于正常和异常结果，脚本是否能够捕捉到并且作出正确的判断。
Web测试主要从下面几个大方向考虑：
主要做链接测试，表单测试，cookies测试，设计语言测试等
考虑连接速度测试，以及负载测试，例如：Web应用系统能允许多少个用户同时在线？如果超过了这个数量，会出现什么现象？Web应用系统能否处理大量用户对同一个页面的请求？还有压力测试
比如导航测试，图形测试，内容测试，整体界面测试等
市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但在另外的操作系统下可能会运行失败。因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试。
现在的Web应用系统基本采用先注册，后登陆的方式。因此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。
当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性。
可以采用lperf这个命令
Lperf是一个网络性能测试工具，可以测量最大tcp和udp带宽，具有多种参数和特性，可以记录带宽，延迟抖动，数据包丢失，通过这些信息可以发现网络问题，检查网络质量，定位网络瓶颈。
iperf的使用非常简单，测试的原理是在wan口连接一台PC机，在LAN口连接一台PC，两边分别运行iperf服务端和客户端模式，用来测量LAN->WAN和WAN->LAN性能。具体命令如下：
服务端：iperf-s-w1m
客户端：iperf-c-w1m-t20-P10
功能测试：
按下开机键，屏幕能否亮起
性能测试：
压力测试
健壮性测试
给定一个中了病毒的手机或者是淘汰许久的老机子，安歇开机键观察屏幕能否亮起
可靠性测试
连续按下开机键有限次数，比如1万次，记录屏幕未亮起的次数
可用性测试
开机键按下费不费力，开机键的形状设计是否贴合手指，开机键的位置设计是否方便
面试官询问遇到过哪些印象深刻的bug，其实它并不关心你描述的这个bug是否真的有价值，或有多曲折离奇？他只是：了解你平时工作中的测试能力
所以，这就要求的你平时工作中遇到bug时试着自己去定位，定位bug的过程远比你的单纯的执行测试用例有“价值”（自我技能提高的价值），在定位bug的过程中你需要掌握和运用更多知识。
另外，建议你平时养成总结的好习惯，发现的bug，开发解决了，最好问问他原因以及解决的方法，这样再遇到类似问题时，自己也可以试着定位解决。遇到难解决的bug，也可以把最终的解决过程记录下来。（这不是就有素材了）
接口测试常见的bug有以下几个:
第一种方式可以通过写脚本产生压力机器人对服务器进行发包收报操作
第二点借助一些压力测试工具比如Jmeter,LoadRunner
需要用压力测试工具或者其他方法录制脚本，模拟用户的操作
需要明确压力测试限制的数量，即用户并发量
首先制定测试计划，然后进行测试设计，将在测试计划阶段指定的测试活动分解，进而细化，为若干个可执行程序的子测试过程，然后执行测试，按照测试计划使用测试用例对待测项目进行逐一的，详细的排查分析评估，最后对测试结果进行统计和分析，
什么是接口（API）
现在市面上有非常多种风格的WebAPI，目前最流行的是也容易访问的一种风格是REST或者叫RESTful风格的API。从现在开始，以下我提到的所有API都是指RESTful风格的API。
什么是接口测试和为什么要做接口测试
接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换，传递和控制管理过程，以及系统间的相互逻辑依赖关系等。
现在很多系统前后端架构是分离的，从安全层面来说，只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端太容易了），需要后端同样进行控制，在这种情况下就需要从接口层面进行验证。
如今系统越来越复杂，传统的靠前端测试已经大大降低了效率，而且现在我们都推崇测试前移，希望测试能更早的介入测试，那接口测试就是一种及早介入的方式。例如传统测试，你是不是得等前后端都完成你才能进行测试，才能进行自动化代码编写。而如果是接口测试，只需要前后端定义好接口，那这时自动化就可以介入编写接口自动化测试代码，手工测试只需要后端代码完成就可以介入测试后端逻辑而不用等待前端工作完成。
接口测试的策略
接口测试也是属于功能测试，所以跟我们以往的功能测试流程并没有太大区别，测试流程依旧是：
自动化测试工具用过selenium和appium
性能测试工具有用过Jmeter
点赞某条朋友圈，验证是否成功
接口测试：
点赞朋友圈，验证朋友能否收到提示信息
性能测试
兼容性测试
在不同的终端比如ipad,手机上点赞朋友圈，验证是否成功
此时就应该找技术领导拍板或leader们基于安全性、性能、可测试性、可维护性讨论敲定一个解决方案，做到开发环境方便开发，线上环境少配置