《软件测试常见面试题》由会员分享，可在线阅读，更多相关《软件测试常见面试题（9页珍藏版）》请在金锄头文库上搜索。
1、软件测试常见面试题汇总的测试流程1 .拿到需求文档后，写测试用例2 .审核测试用例3 .等待发包4 .部署测试环境5 .冒烟测试（ 网页架构图）6 .页面初始化测试（查看数据库中的数据内容和页面展示的内容否一致，并且否按照某些顺序排列 ）7 .具体执行测试用例（几乎所有的功能测试、流程法、场景法）8 .发现缺陷就要再填写缺陷表9 .非功能性测试（sql 、 js 注入、页面效率、绕过js 验证直接数据到数据库）10 .书写最终的测试报告测试用例设计方法等价类、边界值、正交试验法、状态迁移法、因果图、场景测试法、异常分析法、因果图、猜测法、判定表测试用例的要素Id 主题测试名称创建日期设计者描述
2、步骤名步骤描述预期结果执行状态测试的优先级1 .先测试经过变更的部分，然后测试没有变更的部分2 .先测试程序的核心功能，然后测试一般功能3 .先测试逻辑性的功能，然后测试性的功能4 .先测试常规情况，然后测试异常情况5 .先测试功能，然后测试性能测试报告包含哪些内容1 .写测试背景2 .测试目标3 .测试范围4 .测试环境5 .测试数据6 .测试标准（重）7 .测试进度8 .测试结果9 .测试结论有的会采用非标准的测试报告致会包含测试所用时间测试环境测试人员测试发现bug 数量已修复bug 数量遗留bug 遗留 bug 原因测试结果等。BUG 的生命周期提交 -发验证-接受 -拒绝 -发解决-
3、测试人员验证-关闭 -不通过打BUG 的状态1.NEW:所有提交到发对接的问题状态为NEW,表示为未处理2.OPEN:发对接人初判为需流转问题，指定测试人员和发人员，状态为OPEN。3 .REFUSE发对接人判断为不需要流转至下环节的问题，状态为 REFUSE并且填写原因4 .FIXED:发人员完成修复，待测试，状态为 FIXED5 .REOPEN测似人员针对发人员的修复结果测试部通过，状态为 REOPEN6 .CLOSE测试人员判断问题为需求或其他问题，需填写原因 ；缺陷的要素缺陷标题缺陷状态提交人负责人优先级严重程度缺陷描述时间截图缺陷的级别致命问题核心功能不可用或系统崩溃严重问题主要流程
4、无法使用，主要流程中的某个功能存在缺陷导致主要流程无法继续使用一般问题一般性问题，非主要流程上的功能缺陷轻微问题界面ui 问题，提示不规范等建议性问题根据自己的经验提一些建议性的问题WEB 测试与APP 测试的区别1 .架构不同。web 端 b/s 架构的， b/s 架构基于浏览器访问的app 端 c/s 架构的， c/s 架构要有客户端作为载体的2 .版本发布的和流程不同。web 发版本，发部署新的代码到对应器，就可统一实现web 端的更新app 发版本，发需要打包（apk 包和 ipa 包），打包之后需要发布到对应的渠道3 .兼容性web ，测试不同浏览器的兼容性（ie、 chrome 、
5、 firefox 、 360、 QQ）app,测试不同的分辨率、屏幕尺寸、品牌、系统版本4 .性能方面web ，测试响应的时间app ，测试响应时间、流量、耗电量、CPU、 GPU、 memory5 .性web， sql 注入。 xss 攻击等app ， https 加密、签名、加固、密码加密等6 、 app 测试特适配性测试网络测试升级测试中断测试耗电量测试弱网测试卸载测试流量测试app 测试的主要内容1 .功能测试逻辑正确性的测试2 .兼容性测试系统版本分辨率网络情况3 .异常测试热启动网络切换信息终端恢复4 .升级、卸载5 .健壮性测试资源消耗流量消耗电量测试崩溃恢复如果一个 bug ，
6、发认为不一个bug ，怎么处理1 .将问题提交到缺陷管理库里面进行备案。2 .获取判断的依据和标准根据需求说明书、产品说明、设计文档等，确认实际结果否与计划有不一致的地方，缺陷否确认的直接依据;如果没有文档依据，可以根据类似软件的一般特性来说明否存在不一致的地方，来确认否缺陷 ;根据用户的一般使用习惯，来确认否缺陷 ;与设计人员、发人员和客户代表等相关人员探讨，确认否缺陷 ;3 .合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。4 .等待测试经理出最终决定，如果仍然存在争议，可以通过政策所的渠道，向上级反映，并有上级出决定。常用 linux 命令1.1 fconfi
7、g 查看 IP2 .cat 用于显示指定文件的全部内容3 .more 用分页的形式显示指定文件的内容4 .mkdir 创建目录5 .touch 创建新的文件6 .grep 查找文件里符合条件的字符串7 .find 查找指定的文件8 .tail-f 用于自动刷新显示文件后 N 行数据内容9 .kill-9 强制结束10 .netstat-anp|grep 端口号查看端口11 .chmod-R777 赋予 777 权限什么情况下定位不到元素1 .代码写错2 .元素未出现（需要元素等待）3 .元素在iframe 中4 .多窗口5 .出现弹窗（系统弹窗、JS弹窗）6 .元素属性值动态加载的7 .元素无
8、法确定性8 .只读属性（元素不可操作）GET 请求和 POST 请求的区别1 .GET使用URL或Cookies传参，POST将数据放在BODY中2 .GET的URL会有长度上的限制，POST的数据则可以非常3 .POST比GET,因为在栏不可见4 .一般GET 用来获取数据， POST 用来数据为什么要接口测试1 .越底层发现BUG,修复成本越低2 .前端发生变化时，后端接口可以不用变3 .检查系统的性、稳定性，前端传参不可信接口测试怎么的由于们前后端调用主要基于 http 协议的接口，所以测试接口时主要通过工具或代码模拟 http 请求的与接收。工具有很多如： postman、 jmete
9、r 、 soupUI 等。也可以用接口自动化来实现，就用代码实现，框架和 UI 自动化差不多，请求用断言来判断。接口测试的重1 .检查接口返回的数据否与预期的结果一致2 .检查接口的容错性，加入传递的类型时否可以处理3 .接口测试的边界值4 .接口的性能5 .接口的性http 状态码1 .cookies 数据存放在客户的浏览器上， session 数据放在器上;2 .cookies 不很，别人可以分析存放在本地的 cookies 并进行 cookies 欺骗考虑到应当使用 session;3 .session 会在一定时间内保存在器上，当访问增多，会比较占用，你器的性能考虑到减轻器性能方面，应
10、当使用 cookies 。常用的 adb 命令1 .adbstart-server 启动 adb2 .adbkill-server 关闭 adb3 .adbdevices 查看设备号4 .adbpush 电脑5 .adbpull 电脑6 .adblogcat|grep 包名 (unix)7 .adblogcat|findstr 包名 (win)8 .adbshell 进入 shell 命令行9 .adbinstallapp 到上10 .adbuninstall 卸载 app 到上11 .adblogcat文件名输出log到文件12 .adbshelltop 测试 app 的资源消耗命令产品的流
11、程解析问你简历上写的某个整体的流程比如电商中的注册功能，从始注册到注册成功的整个过程版本符合上线的标准什么验收标准(1)软件需求分析说明书中定义的所有功能已全部实现，性能指标全部达到要求。(2)在验收测试中发现的已经得到，各级缺陷修复率达到标准(3)所有测试项没有残余紧急、严重级别。(4) 需求分析文档、设计文档和编码实现一致。(5) 验收测试工件齐全(测试计划、测试用例、测试日志、测试通知单、测试分析报告，待验收的软件程序。 )缺陷修复率标准(1) 紧急、严重级别修复率应达到 ;(2)普通级别修复率应达到95% 以上 ;(3)优化级别修复率应达到60% 以上 ;注：紧急时，普通级别修复率达6
12、0%以上 ;优化级别修复率达20% 即可。器运行状态响应指标(1)cpu% 并发期间使用率应不超过70-80% ，如有集合并发可允许短暂接近或到达100&但部分不应查过95%;(2)memery 测试期间保证内存充足可用内存不少于20%;(3)disk 监控硬盘否有读写不超过40%;(4)cpuloadaverage 不应超过 cpu 核心数 *2 或者不超过cpu 核心数。测试用例评审过程及相关参与人员1:评审的过程A：始前好如下准备(1) 确定需要评审的原因(2) 确定进行评审的时机(3) 确定参与评审人员(4) 明确评审的内容(5) 确定评审结束标准(6) 提前至少一天将需要评审的内容以
13、邮件的形式给评审会议相关人员。并注明详审时间、地及偿参与人员等。(7)在邮件中提醒评审会议相关人员至少简读一遍评审内容，并记录相关的疑问，以便在评审会议上提出。(8)会议主持者(一般为用例编写人员 )应在会议前整理相关疑问，以便在会议上提出。B:始评审(1) 召评审会议。与会者在设计人员讲解之后给出意见和建议，同时进行详细的评审记录。(2) 通用邮件与相关人员(3) 通用 IM 工具直接与相关人员交流(4)根据评审内容进行评审2：评审内容(1) 用例设计的结构安排否清晰、合理，否利于对需求进行覆盖。(2)优先极安排否合理。(3) 否覆盖测试需求上的所有功能。(4) 用例否具有很好可执行性。例如
14、用例的前提条件、执行步骤、输入数据和期待结果否清晰、正确;期待结果否有明显的验证方法。(5) 否已经删除了冗余的用例。(6) 否包含充分的负面测试用例。充分的定义，如果在这里使用 2&8 法则，那就4倍于正面用例的数量，毕竟一个健壮的软件，其中 80% 的代码都在 “保护 ” 20%的功能实现。(7) 否从用户层面来设计用户使用场景和使用流程的测试用例。(8) 否简洁，复用性强。例如，可将重复度高的步骤或过程抽取出来定义为一些可复用标准步骤。3：参与评审人员(这里会分为多个级别进行评审)(1) 部门评审，测试部门全体成员参与的评审。(2)评审，这里包括了经理、需求分析人员、架构设计人员、发人员和测试人员。(3)客户评审，包括了客户方的发人员和测试人员。这种情况在外包比较常见。
