测试基础(六)
测试案例设计
根据以下需求描述,运用测试基本理论知识设计一套测试案例验证相应功能,有一个PC客户端的命令行工具,这个工具可以接受3个命令行参数,其中,前两个是数字,后一个是运算符,运算符只支持加减乘除四种,工具的功能是把前两个数字使用运算符执行运算,然后输出运算结果
答:如图所示:
简要说明以下接口有哪些测试点
接口名称 4绑卡确认
请求类型 post
请求Url /cncharge/debit/resume_bind
请求参数列表
变量名 |
含义 |
类型 |
bankcode |
银行CODE |
string |
bankname |
银行名称 |
string |
cerdNo |
卡号 |
string |
IdNo |
身份证号 |
string |
mobile |
发送动态码手机号 |
string |
seqNo |
Token预绑卡页面返回值 |
string |
uid |
用户id |
string |
userName |
姓名 |
string |
vcode |
用户输入的验证码 |
string |
响应参数列表
变量名 |
含义 |
类型 |
BankName |
银行名称 |
string |
cardld |
卡ID |
string |
code |
返回码 |
string |
message |
返回消息 |
string |
status |
SUCCESS,FAILED |
string |
答:验证请求参数必填性,验证请求参数的正确性,银行卡是否实名认证,身份证号码是否是开户人所有,手机号是否是银行预留手机号。响应参数是否正确。
画出软件测试的V模型
答:如下图所示:
功能测试和集成测试有什么区别和练习,根据以往的测试经验侧重点是哪个?为什么
答:区别:1、测试bai对象不同:功能测试对象是整个系统,包括系统中的硬件等;集成测试对象是模块之间的集成和调用关系。
2、测试方法不同:功能测试一般由独立测试小组采用黑盒方式来测试;集成测试一般由开发小组采用白盒加黑盒的方式来测试。
3、测试依据不同:功能测试依据是系统结构设计,目标说明书,需求说明书等;集成测试依据是程序结构设计。
侧重点是功能测试。
原因:1、集成测试,也叫组装测试或联合测试。在单元测试的基础上,将所有模块按照设计要求,组装成为子系统或系统,进行集成测试。实践表明,一些模块虽然能够单独地工作,但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题,在全局上很可能暴露出来,影响功能的实现。
2、系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。
软件测试的安全性应该从哪些方面去测试,列举熟悉的或者常用的截包工具,及渗透工具
答:1、安全性从以下方面去测试:
- 用户认证机制:如数据证书、智能卡、双重认证、安全电子交易协议;
- 加密机制;
- 安全防护策略:如安全日志、入侵检测、隔离防护、漏洞扫描;
- 数据备份与恢复手段:存储设备、存储优化、存储保护、存储管理;
- 防病毒系统。
2、截包工具:Flidder、Httpwatch、Hping、Ostinato、Firefox的F12功能键
3、渗透工具: burpsuite、secuiSCAN、nessus 、SPIKEProxy
根据自己的理解,描述一下压力测试的原理,举例以下常见的压力测试工具,除了工具以外还如何进行压力测试
答:压力测试的原理:压力测试就是不断施压看承受的力度 电脑压力测试可以使用游戏加加,测试电脑的稳定性及性能好坏
压力测试工具:LoadRunner、jmeter
不用工具如何进行压力测试:一般都是要用工具,如果你不用工具,只能多用人了,但是这样也很难保证都是并发操作,多人同时登录、同时点击等操作,然后看网站后台的资源占用情况,是否出现异常等,从而确定系统的性能瓶颈。
如果由于时间仓促,留给测试时间比较短,如何来开展测试
答:1、对时间、成本、质量要有清晰明确的认识。2、加大成本,3、需求要对产品有准确的定位和适当的剪裁。4、开发人员实现的内容要及时充分印证和验证。5、测试的二八法则。6、测试计划的重要性。7、风险前置。8、建立高效的工作流程和沟通机制。9、适度的测试工具引入。10、人员合理安排。
历史收益表history_data,有三个字段:fundcode ,data,value 其中,fundcode代表基金代码,data代表日期,value代表收益率
基金基本信息表fund_base,有两个字段:fundcode,fundname,其中fundcode代表基金代码,fundname代表基金名称
问题:已知fundname=“嘉实黄金”,app中显示了近一个月的历史收益率的曲线,例如是从2016-4-10号至2016-5-10的收益率,请写出sql,并列出一下曲线图的测试点以及如何验证app中曲线是正确的?
APP中显示如下
答:sql:Select * from history_data t1 left join fund_base t2 on(t1.fundcode =t2.fundcode )
Where t2.fundname=’嘉实黄金’ and t1.data>=’2016-4-10’ and t1.data<=’2016-5-1’ order by t1.data desc
谈谈软件测试技术,以及一个优秀的软件测试人员应该具备哪些素质,应该掌握哪些知识,为什么要掌握这些知识
答:1、正确高效的沟通能力:测试工程师必须能够与测试工作所涉及到的所偶有人进行沟通,具有与技术人员(开发人员)和非技术人员(客户,管理人员)的交流能力。
2、超强责任心:测试工作在很大程度上依赖于测试人员自己,因此责任心应该被定义为软件测试人员的最基本素质
3、坚持原则:测试工程师需要对产品的质量负责们在这一点上一定要有原则
4、懂得尊重:工作的技能要求不同,工作化境不同,这样就导致了工作难度不同,虽然不能将测试的工作与其他的工作进行直接对比,但是我们也要其他的同时保持足够的尊重,无论你发现了什么样的缺陷或发现了多少缺陷,这只能说明产品有问题,但不能说明人员能力有问题,因为很多问题的成因非常的复杂,需要多方面来解决。
5、有较全面的技术知识:较全面的技术知识能够帮助测试人员定位缺陷,也能帮助测试人员与技术人员新型有效的沟通,同时还能提高测试人员的技术水平。
软件测试的目的
答:目的:软件测试是为了发现错误而执行程序的过程。或者说,软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入一些数据而得到其预期的结果),并利用这些测试用例去运行程序,以发现程序错误的过程。
用边界值分析法,假定1<x<100那么x在测试中应该取得边界值是
答:X=0,X=1,X=100,X=101
在您以往的工作中,一条软件缺陷(或叫bug)记录都包含了哪些内容
答:编号,标题,缺陷类型,所属模块,前置条件,重现步骤,预期结果和实际结果。
如何定位bug,是前端还是后端问题,用什么工具,还是利用别的
答:1.发现bug之后,重现bug的时候使用fiddler抓包去分析
2.如果前端提交的数据在fiddler中显示有误,那么就是前端的bug
3.如果在前端提交的数据在fiddler中显示无误,那么就是后台的bug
4.除了fiddler等抓包工具外,还可以通过后台的日志去判断
测试用例所包含的内容
答:包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。
简述一下session和cookie的区别
答:
1、数据存放位置不同:cookie数据存放在客户的浏览bai器上,session数据放在服务器上。
2、安全程度不同:cookie不是很安全,别人可以分析存放在本地的COOKIE并进行COOKIE欺骗,考虑到安全应当使用session。
3、性能使用程度不同:session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能,考虑到减轻服务器性能方面,应当使用cookie。
4、数据存储大小不同:单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie,而session则存储在服务端,浏览器对其没有限制。
5、会话机制不同:session会话机制:session会话机制是一种服务器端机制,它使用类似于哈希表(可能还有哈希表)的结构来保存信息。cookies会话机制:cookie是服务器存储在本地计算机上的小块文本,并随每个请求发送到同一服务器。 Web服务器使用HTTP标头将cookie发送到客户端。在客户端终端,浏览器解析cookie并将其保存为本地文件,该文件自动将来自同一服务器的任何请求绑定到这些cookie。
您以往所从事的软件测试工作中,是否使用了一些工具进行缺陷的管理,如果有,请结合该工具描述缺陷的跟踪管理流程
答:1. 新建 -- 开启 -- 修改 -- 关闭 提交缺陷后开发人员确认修改后回归通过
2. 新建 -- 拒绝 开发人员未确认缺陷拒绝修改,这个时候需要在确认需求理解正确(跟产品确认)和复现步骤(多次复现)的基础上, 跟开发人员沟通是否需要修改
3. 新建 -- 开启 -- 修改 -- 重开 修改后提交的版本回归不通过,这是需要重新打开缺陷,为了加快缺陷正确修改, 可以跟开发人员沟通,协助开发人员定位缺陷
4. 新建 -- 开启 -- 延期 部分开启的缺陷,由于无法复现, 难以修改, 进度压力等原因,可能需要延期修改,这个时候,是否延期,是需要多方确认的(测试,产品,开发, 领导)如果要做的工作不知道侧重哪一环,建议听听黑马程序员的免费课程,方向选对,事半功倍
常见的用例设计方法有哪些,编写一条登录的测试用例,并从安全的角度去考虑应该注意哪些问题
答:(1)用户名:输入长度最长位50个字符,区分大小写,必填项
(2)密码:长度最小6位,最长20位必填项
现在开发出来的效果-----如果输入长度有问题,则会提示长度有问题,如果两个长度没问题输入用户名错误,密码输入错误则提示密码输入错误,没有次数限制
并行之后你们的数据取哪里的?
答:并行过后所有的数据都会加一个字段来判断是新版本的数据还是老版本的数据。比如1是走新逻辑,就会去查数据字典为1的新数据,2是走老逻辑,就会去查对应数据字典为2的老数据。
开发提供的一些工具你是怎么获取?你怎么判断开发提供的工具是否需要测试?
答:自己去ftp下载或者开发直接发过来。
如果是提供一些开源的工具是不需要测试的。如果是一些内部工具会测试一下不同版本的是否能正常使用就是项目中你要用到新的开发知识,你是通过什么渠道获取?
答:百度自学或者咨询同事。
怎么保证测试用例的覆盖的?
答:出原型---在项目开始之后,都会确定相应的需求文档,然后根据需求文档,相关的产品人员会根据需求文档规划处相应的产品原型。
查功能---产品原型机会覆盖了改项目的所有功能,在开发人员的开发阶段,作为一名测试人员你可以在产品原型的基础上对功能进行检查,提前试验,发现其中的漏洞或者设计不合理的地方。
出文档---所有的结果,作为一个把控项目质量的QA(质量管理),最好的产出就是文档了,当然现在网络上有很多测试用例的工具,还是推荐大家用EXCEL这种最原始的工具,把一个功能的业务流程在表格里描述一遍。方便自己的差缺不漏。
你们做功能测试和接口测试的比例?
答:功能测试占比百分之二十,接口测试占比百分之八十
你这个自动数据采集测试的对象有几个接口?你会设计哪些测试用例呢?
答:接口:如果是贷款项目,数据采集接口,有获取征信接口,公安联网接口,社保公积金查询接口...等等
用例:设计接口用例根据参数来,一般正例会涉及一些正确的请求参数,反例会设计一些错误参数用例,还有token失效和不失效 的案例
你怎么验证数据的正确性呢?
答:如果是调数据查询出来的数据,我会去数据库比对数据是否一致。
你们之前外包公司对你什么考评吗?
答:这个回答不能太夸大其词也不能贬低自己,就中规中矩的回答就行。
怎么衡量测试用例覆盖已经够了?
答:测试需求的覆盖:保证所有需求都已经设计用例
测试特性的覆盖:保证所有不同类型已覆盖,如:功能测试,性能测试等
平台与层次的覆盖:保证所有平台有用例覆盖,不同层次都有设计用例,如业务层、接口层等
你对工作的期望?
答:这个每个人的期望不同,可以往积极的方向说。
你们闭环是怎么做的?怎么测的?有没有一种可能一个节点既走不下去也回不去?
答:没有遇见过这种情况,如果遇见结点走不下去,可以使用挡板测试
rpa用到过吗?
答:我没有用到过。这个RPA是智能化软件,可以bai理解为自动化机器人。只要预先设计好使用规则,RPA就可以模拟人工,进行复制、粘贴、点击、输入等行为,协助人类完成大量“规则较为固定、重复性较高、附加值较低”的事情。
你之前工作中最让你有成就感的事情是什么?
答:这个因人而异可以根据自身情况如实回答。
你转行做测试的过程中遇到过什么困难吗?
答:测试工具用的不太熟练,这个因人而异,可以根据自己的想法去说。
测试的思路?
答:1.聊测试目的;2.熟悉软件的功能;3.熟悉产品需求;4.测试用例的覆盖程度;5.软件菜单的遍历;6.针对变更以及新增功能进行重点测试;7.随机测试。
你平时是怎么理解业务流程的?
答:一般是通过需求文档、业务流程图、接口文档、咨询开发和产品经理、调用接口等了解业务流程。
你之前都在外包?外包公司你喜欢什么样的氛围?
答:这个按照自己的想法如实回答就行.、
软件工程需求分析阶段是
系统测试是将软件系统与硬件,外设和网络等其他因素结合,对整个软件系统进行测试(路径测试,可靠性测试,安装测试,安全测试)中()不是系统测试的内容
软件测试概念
在某小额贷款公司信息系统中,假设该贷款客户年龄输入范围为18-55,则根据黑盒测试中的等价类划分技术,应划分为
正确的集成测试描述
软件测试的基本方法包括白盒测试和黑盒测试方法,以下关于二者之间的描述
导致软件缺陷的额原因有很多,1-4是可能的原因,其中最主要的原因包括
- 软件需求说明书编写的不全面,不完整,不准确,而且经常更改
- 软件设计说明书
- 软件操作人员的水平
- 开发人员不能很好地理解需求说明书和沟通不足
web应用系统负载压力测试中,()不是衡量业务执行效率的指标
A并发请求数 B每秒点击率 C交易执行吞吐量 D交易执行响应时间
通过疲劳测试最容易发现什么问题
在设计测试用例是,(1)是用得最多的一种黑盒测试方法,在黑盒测试方法中,等价类划分方法设计测试用例的步骤是:
根据输入条件把数目极多的输入数据划分程若干个有效等价类和若干个无效等价类;设计一个测试用例,使其覆盖(2)尚未被覆盖的有效等价类,重复这一步,知道所有有效等价均被覆盖
设计一个测试用例,使其覆盖(3)尚未被覆盖的无效等价类,重复这一步,直至所有无效等价均被覆盖
因果图方法使根据(4)之间的因果关系来设计测试用例的
在实际应用中,一旦纠正了程序的错误后,还应选择部分或全部原先已测试过的测试用例,对修改后的程序重新测试,这种测试成为(5)
(1)A等价类划分 B边界值分析 C因果图 D判定表
(2)A1 B一半 C尽可能少的 D尽可能多的
(3)A1 B一半 C尽可能少的 D尽可能多的
(4)A输入与输出 B设计与现实 C条件与结果 D主程序与子程序
(5)A验收测试 B强度测试 C系统测试 D回归测试
为了提高测试的效率应该()
A随机地选取测试数据
B取一切可能的输入数据作为测试数据
C在完成编码以后制定软件地测试计划
D选择发现错误地可能性大地数据作为测试数据