目录
33、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
33、产品在上线后用户发现bug，这时测试人员应做哪些工作？
47、一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
53、有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
1、B/S架构和C/S架构区别
- B/S架构需要重点考虑系统在不同的浏览器中的兼容性问题(浏览器的内核不同)
- C/S 架构需要考虑系统在不同平台的安装、卸载、升级
2、HTTP协议
超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。
3、POST与GET区别
- get请求常用在获取数据，post常用于发送数据
- get请求速度比post稍快
- get请求的数据是跟随请求地址一起发送，而post是在请求体中单独发送。
4、Cookie和Session的区别与联系
cookie是存放在浏览器上而session是存放在服务器上的。
cookie不是很安全，涉及到用户隐私方面尽量存放在session中。
当访问量增多时，session会更加占用服务器资源。
5、测试的目的
发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。
6、软件测试原则
- 所有的软件测试都应追溯到用户需求。
- 尽早地和不断地进行软件测试
- 完全测试是不可能的，测试需要终止。
- 充分注意测试中的群集现象。
- 程序员应避免检查自己的程序。
- 尽量避免测试的随意性
7、软件测试分为哪几个阶段？
单元测试、集成测试、系统测试、验收测试
8、单元测试与集成测试的侧重点
单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。
9、系统测试范围
功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等
10、a测试与ß测试的区别
a测试：公司组织的内部人员进行的测试
ß测试：公司组织的典型客户在实际生活中使用。
11、验收测试怎么做？
在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。
12、白盒、黑盒和灰盒测试区别
白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。
13、冒烟测试的目的
检查程序的基本功能是否正常
14、回归测试怎么做？
首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。
15、全部回归与部分回归的区别？
全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。
16、需求分析的目的
澄清需求，提取测试点
17、测试计划的目的
规范软件测试内容、方法和过程
18、什么时候开始写测试计划
需求分析之后
19、由谁来编写测试计划
一般都是由测试经理或者测试组长来编写
20、测试计划的内容
测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。
21、结束条件(项目上线的条件)
需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%
22、常见的测试风险
进度风险、质量风险和需求变更
23、测试用例的要素
用例编号,用例名称,级别,预置条件,测试步骤,期望结果
24、测试用例级别的划分
一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定
25、怎样保证覆盖用户需求？
项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。
26、写好测试用例的关键 /写好用例要关注的维度
- 覆盖用户的需求；
- 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
- 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
- 用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
- 做好用例评审，及时更新测试用例。
27、测试用例的状态
| 英文 | 中文 |
|---|---|
| No Test | 未执行状态 |
| Pass | 通过状态 |
| Fail | 失败状态 |
| Block | 阻碍状态。 |
| Investigate | 观察中状态。 |
28、常见的测试用例设计方法
- 等价类
- 边界值
- 判定表
- 场景法
- 错误推测法
29、判定表用在哪些时候/哪些功能
判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表
30、什么时候用到场景法
使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)
31、测试环境怎么搭建的？
搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我这个xx系统，是搭建在Unix系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用xshell(或CRT)远程连接上Unix系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。
32、偶然性问题的处理
- 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
- 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
- 如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！
33、当我们认为某个地方是bug，但开发认为不是bug，怎么处理？
- 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
- 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改
33、产品在上线后用户发现bug，这时测试人员应做哪些工作？
- 测试人员复现问题后，提交问题单进行跟踪；
- 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
- 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
- 总结经验，分析问题发生的原因，避免下次出现同样问题。
34、二八定理
80%的缺陷出现在 20%的模块。
35、如何跟踪缺陷
当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。
36、缺陷的状态
激活,确认,已解决,关闭
37、缺陷的等级
致命,严重,一般,轻微
38、缺陷单应该包含这些要素
缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。
39、测试报告的主要内容
人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论
40、如何定位bug：
- 检查测试环境配置是否有问题，测试数据是否有问题
- 用fiddler抓包，分析请求和响应数据是否存在问题
- 查看应用服务器的日志
- 然后再查看数据库的数据是否存在问题
41、开发没时间修复，如何推进bug的修复：
- 和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
- 确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。
42、软件测试流程
我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入SIT测试，之后进行UAT用户验收测试，验收通过后，编写测试报告。
43、项目介绍
参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程
参考：我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。
44、对一支圆珠笔进行测试，要从哪些方面进行测试？
45、三角形测试用例设计
解题思路
我们可以设三角形的3条边分别为A，B，C。如果它们能够构成三角形的3条边，必须满足：A B C均是正数且大于0，还需满足
- A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。
- 如果是等腰的，还要判断A=B，或B=C，或A=C。
- 如果是等边的，则需判断是否A=B，且B=C，且A=C。
46、在项目中发现哪些经典bug？什么原因导致的？
- 注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的
- 接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到
- 数据用fiddler可以抓包拦截篡改数据
- 弱网环境下订单可以重复提交
- 验证码可以重复使用
- 跑性能测试的时候，当前账号下的订单跑到别的账户上去了每次重新登陆都提示重设支付密码，而且设置的密码不能和上次相同
- 在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加
- 第一次提现申请未审核，再继续第二次提现申请无法成功
- 前台发布出租房源，后台通过审核并且成功加入出租列表，前台搜索失败
47、一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。
测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。
48、在需求文档不太详细的情况下，如何开展测试？
- 首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
- 提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
然后再编写测试用例，再评审，评审通过后，再进行后续的测试。
49、如何尽快找到软件中的bug?
- 尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
- 把自己当成用户，把自己当成是用户去使用该系统
- 善于怀疑，不要过于相信开发人员的能力；
50、什么是bug？
- 软件未实现需求和规格要求的功能 ；
- 软件未实现需求和规格未明确提及但应该实现的内容 ；
- 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；
- 测试用例执行中发现的与预期结果不符的现象
51、ATM机吞卡的吞卡现象是不是BUG?
不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。
52、如何减少非问题单的提交？
- 熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
- 跟产品确认该问题是否属于非问题单。
53、有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？
将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。
54、你们发现bug会怎么处理。
发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。
5012
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
