面试的那些事儿--01
相信大家一直都在为面试的时候的笔试 以及面试官所提出的问题而烦恼吧 今天就来谈谈我的一些面试经验以及面试复盘吧
刚入门的时候肯定是都是围绕着黑盒测试也就是所谓的功能测试为中心,再进行发散性的测试,其中包括一些测试方法及其测试用例的设计让你阐述一下你在日常工作中是如何进行测试的。相信大家都遇到过这种问题,直到前不久我去长沙面试找工作的时候,技术方面已经不仅仅只局限于功能的一点点,更多的是性能跟安全。接口自动化以及测开到没有要求那么多,可见现在的趋势发展慢慢的可以延伸到安全跟性能了,那么我总结一下我面试时遇到过的问题吧,可能在这篇文章的你也遇到过类似的,可以一起吐槽一下呀!
1、设计测试用例的八大要素
答:测试用例的编号、被测模块、测试用例的标题、前置条件、操作步骤、预期结果、实际结果、测试用例的优先级。
2、整个软件的测试周期是怎么样的
3、如何对一部电梯进行测试
2.报警器是否能用
3.电梯上/下行运行是否正常
4.电梯通风口
5.显示屏是否正常
6.手机在电梯中是否有信号
7.电梯门的打开/关闭是否正常
8.电梯是否与其他设备兼容
9.电梯门是否有感应装置
2.根据按键次数不同选择是否选择和取消
2.电梯内部是否具有扶手
3.对特殊人群是否友好
4.按钮的宽度
2.电梯的形状(原型,方形)
3.电梯内的空间大小
2.电梯的绳索在一直上升状态下最大的运行时间
3.电梯的绳索在一直下降状态下最大运行时间
1.电梯在不同气压下的运行情况
2.电梯与楼层墙壁之间的缝隙
3.电梯在不同电压下运行的情况
安全性:1.暴力测试(在电梯内中剧烈跳动,用锤子砸)
2.摄像头能否正常看清楚电梯内的用户
3.能否在电梯出现故障的情况下,容易将用户解救出来
4.在电梯停电时是否有临时电源进行供应
4、测试方法有哪些,请举例说明一下
5、一个登陆接口 让你去设计测试用例 请从 功能 安全 性能几个方面做一个设计
用例设计:测试需求分析完成后,开始用例设计,主要可以从以下几个方面考虑:
功能测试(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、不同的分辨率
6、如果用fiddler做断点,设置弱网?
7、能具体说说安全测试中的sql注入吗?如果让你来做你会如何预防?
原文链接:https://blog.csdn.net/github_36032947/article/details/78442189
$sql = "SELECT * FROM article WHERE id =",$id
正常情况下,应该返回一个id=1的文章信息。那么,如果在浏览器地址栏输入:learn.me/sql/article.php?id=-1 OR 1 =1,这就是一个SQL注入攻击了,可能会返回所有文章的相关信息。为什么会这样呢?
这是因为,id = -1永远是false,1=1永远是true,所有整个where语句永远是ture,所以where条件相当于没有加where条件,那么查询的结果相当于整张表的内容
有这样一个用户登录场景:登录界面包括用户名和密码输入框,以及提交按钮。输入用户名和密码,提交。
这是一个post请求,登录时调用接口learn.me/sql/login.html,首先连接数据库,然后后台对post请求参数中携带的用户名、密码进行参数校验,即sql的查询过程。假设正确的用户名和密码为user和pwd123,输入正确的用户名和密码、提交,相当于调用了以下的SQL语句:
SELECT * FROM user WHERE username = 'user' ADN password = 'pwd123'
由于用户名和密码都是字符串,SQL注入方法即把参数携带的数据变成mysql中注释的字符串。mysql中有2种注释的方法:
1)'#':'#'后所有的字符串都会被当成注释来处理
用户名输入:user'#(单引号闭合user左边的单引号),密码随意输入,如:111,然后点击提交按钮。等价于SQL语句:
SELECT * FROM user WHERE username = 'user'#'ADN password = '111'
'#'后面都被注释掉了,相当于:
SELECT * FROM user WHERE username = 'user'
2)'-- ' (--后面有个空格):'-- '后面的字符串都会被当成注释来处理
用户名输入:user'-- (注意--后面有个空格,单引号闭合user左边的单引号),密码随意输入,如:111,然后点击提交按钮。等价于SQL语句:
SELECT * FROM user WHERE username = 'user'-- 'AND password = '1111'
'-- '后面都被注释掉了,相当于:SELECT * FROM user WHERE username = 'user'
因此,以上两种情况可能输入一个错误的密码或者不输入密码就可登录用户名为'user'的账号,这是十分危险的事情。
如何预防SQL注入? 这是开发人员应该思考的问题,作为测试人员,了解如何预防SQL注入,可以在发现注入攻击bug时,对bug产生原因进行定位。 1)严格检查输入变量的类型和格式 对于整数参数,加判断条件:不能为空、参数类型必须为数字 对于字符串参数,可以使用正则表达式进行过滤:如:必须为[0-9a-zA-Z]范围内的字符串 2)过滤和转义特殊字符 在username这个变量前进行转义,对'、"、\等特殊字符进行转义,如:php中的addslashes()函数对username参数进行转义 3)利用mysql的预编译机制 把sql语句的模板(变量采用占位符进行占位)发送给mysql服务器,mysql服务器对sql语句的模板进行编译,编译之后根据语句的优化分析对相应的索引进行优化,在最终绑定参数时把相应的参数传送给mysql服务器,直接进行执行,节省了sql查询时间,以及mysql服务器的资源,达到一次编译、多次执行的目的,除此之外,还可以防止SQL注入。具体是怎样防止SQL注入的呢?实际上当将绑定的参数传到mysql服务器,mysql服务器对参数进行编译,即填充到相应的占位符的过程中,做了转义操作。
8、如何使用Charles做断点,修改入参请求
9、mysql 请写出左表查询的语句
10、mysql 请写出右边查询的语句
欢迎转载 请注明原出处 https://www.cnblogs.com/yushengaqingzhijiao/p/14514826.html 但未经本人允许转载或复制 如有发现需要承担法律责任 @罐装七喜的后花园