软件测试常见的问题

1，B/S架构和C/S架构区别

2，HTTP协议

超文本传输协议，应用层协议，由请求与响应组成。
常见的请求方式有POST/GET,常见的状态码200ok，301永久移动，302临时移动，404找不到资源，500服务器内部错误。

3，POST与GET区别

4，Cookie和Session的区别与联系

5，测试的目的

发现软件的缺陷与漏洞，对软件的质量进行评估，提升软件质量。

6，软件测试原则

7，软件测试分为哪几个阶段/h2>

8，单元测试与集成测试的侧重点

单元测试是对程序最小可测试的模块进行测试
集成测试是把各个模块连接起来时，穿越模块接口的数据是否会丢失。

9，系统测试范围

功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等

10，a测试与?测试的区别

a测试：公司组织的内部人员进行的测试
?测试：公司组织的典型客户在实际生活中使用。

11，验收测试怎么做/h2>

在UAT测试之前，我们会制定测试方案，选择基线用例，即级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。

12，白盒、黑盒和灰盒测试区别

白盒测试：对程序的内部结构与算法进行的测试
黑盒测试：不考虑程序的内部结果，只检查程序是否实现了需求的功能
灰盒测试：关注系统接口所实现的功能，是否和需求一致。

13，冒烟测试的目的

检查程序的基本功能是否正常

14，回归测试怎么做/h2>

首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

15，全部回归与部分回归的区别/h2>

全量回归：对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止以前没有的问题现在出问题了
部分回归：当开发修复某个bug时，我们需要去检查该bug是否被修复，还需要检查与之相关联的模块是否受到影响。

16，需求分析的目的

澄清需求，提取测试点

17，测试计划的目的

规范软件测试内容方法和过程

18，什么时候开始写测试计划

需求分析之后

19，由谁来编写测试计划

测试经理或者是测试组长来编写

20，测试计划的内容

21，结束条件(项目上线的条件)

需求的覆盖率、用例的执行率和缺陷的遗留率达到质量目标。
通常来说：需求覆盖率和用例执行率需要达到100%
致命/严重的缺陷需要当天解决，轻微/一般遗留率不得超过30%

22，常见的测试风险

进度风险、质量风险和需求变更

23，测试用例的要素

用例编号,用例名称,级别,预置条件,测试步骤,期望结果

24，测试用例级别的划分

我们将测试用例分成：高，中和低。

25，怎样保证覆盖用户需求/h2>

项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。

26，写好测试用例的关键 /写好用例要关注的维度

1. 覆盖用户的需求；
2. 从用户使用场景出发，考虑用户的各种正常和异常的使用场景；
3. 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
4. 用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
5. 做好用例评审，及时更新测试用例。

27，测试用例的状态

No Test 未执行状态
Pass 通过状态
Fail 失败状态
Block 阻碍状态
Investigate 观察中状态

28，常见的测试用例设计方法

29，判定表用在哪些时候/哪些功能

? 判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表

30，什么时候用到场景法

? 使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等)

31，测试环境怎么搭建的/h2>

1、搭建测试环境，确定测试目的
测试环境尽可能的模拟真实环境
确保环境无毒
营造独立的测试环境
构建可复用的测试环境
2、安装依赖软件
　　拿python项目举例
　　　　安装python3、pymysql、redis等需要的工具。
　　　　导入Django、pymysql、redis等需要的第三方模块
　 拿Java项目举例
　　　　安装JDK、tomcat、数据库等需要的工具。
3、拉取代码
　　需要知道SVN地址或者Git地址
4、修改配置文件
　　修改数据库、redis等配置文件的配置信息，修改成测试环境的配置信息
5、编译、打包（python不需要编译直接可以运行，如果是Java、c、 c++需要编译）
6、导入基础数据
　　建表、导入管理员账号之类的信息，即把sql在测试数据库执行一次
7、启动程序。

32，偶然性问题的处理

1. 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位；
2. 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷；
3. 如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！

33，当我们认为某个地方是bug，但开发认为不是bug，怎么处理/h2>

1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。
2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。

34，产品在上线后用户发现bug，这时测试人员应做哪些工作/h2>

1. 测试人员复现问题后，提交问题单进行跟踪；
2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能；
3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试；
4. 总结经验，分析问题发生的原因，避免下次出现同样问题。

35，二八定理

80%的缺陷出现在 20%的模块。

36，如何跟踪缺陷

当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。

37，缺陷的状态

激活,确认,已解决,关闭

38，缺陷的等级

致命,严重,一般,轻微

39，缺陷单应该包含这些要素

40，测试报告的主要内容

人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论

41，如何定位bug：

1. 检查测试环境配置是否有问题，测试数据是否有问题
2. 用fiddler抓包，分析请求和响应数据是否存在问题
3. 查看应用服务器的日志
4. 然后再查看数据库的数据是否存在问题

42，开发没时间修复，如何推进bug的修复：

1. 和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进；
2. 确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。

43，软件测试流程

44，项目介绍

我们一般在项目进行开立项会【产品经理 项目经理 开发人员 测试人员】的时候进行参与，
讨论需求并提出建议，在立项会中制定需求文档，由ui设计原型图，开发根据需求文档进行编码，
我们测试会根据需求文档进行编写 测试计划，根据模块的（颗粒度）划分并编写测试用例以及对用例的评审，
开发结束侯测试对主要功能进行冒烟测试，执行测试用例，提交bug 开发进行修改，修改成功后关闭bug，
进行回归测试，在上线前进行测试总结。

45，对一支圆珠笔进行测试，要从哪些方面进行测试/h2>

1.功能测试：
圆珠笔按下是否能正常书写。
2.性能测试：
笔芯弹出弹回的快慢。
3.负载测试：
连续按，看弹簧能经受多少次伸缩。
4.兼容性测试：
看是否可以使用其他笔芯。
5.强度测试：
用力过度会有什么影响
6.可恢复性测试：
长时间按住弹簧，松开后看弹簧是否可以恢复
7.界面测试：
笔的外观，舒适度
8.安全性测试：
是否会对使用者造成伤害

46、三角形测试用例设计

在三角形计算中，要求三角形的三个边长：A B C。
1、 当三边不可能构成三角形时提示错误，可构成三角形时计算三角形周长。
2、若是等腰三角形打印“等腰三角形”， 若两个等腰的平方和等于第三边平方和，则打印“等腰直角三角形”。
3、若是等边三角形，则打印：“等边三角形”。
4、画出程序流程图并设计一个测试用例。
分析一下：
1、构成三角形的条件：任意两边之和大于第三边；
2、构成等腰三角形的条件：任意两边相等；
3、构成等腰直角三角形的条件：任意两边相等，而且两条边的平方和等于第三边的平方和；
4、构成等边三角形的条件：三条边都相等。

那么用什么样的设计方法进行测试用例的设计呢br> 一、等价类划分：三角形三条边A、B、C的数据类型不同
二、边界值分析：由于三角形的边长可以是正整数或正小数，所以就不对长度进行测试，那么边界值分析就不用了
三、因果图法：三角形的三条边数据输入组合

我们再分析一下三角形的等价类：
有效等价类：
输入3个正整数或正小数：
1、两数之和大于第三数，如A 2、两数之和不大于第三数
3、两数相等，如A=B或B=C或C=A
4、三数相等，如A=B=C
5、三数不相等，如A！=B，B！=C，C！=A
无效等价类：
1、空
2、负整数
3、非数字
4、少于三个数

47，在项目中发现哪些经典bug么原因导致的/h2>

1. 注册信息中的错误提示信息：如手机信息栏应填入11位有效电话号码，但提示信息却为“13位电话号码”，这是因开发人员粗心大意造成的
2. 接口bug：传的字段值为空，但是开发没给默认值设个0导致接收不到
3. 数据用fiddler可以抓包拦截篡改数据
4. 弱网环境下订单可以重复提交
5. 验证码可以重复使用
6. 跑性能测试的时候，当前账号下的订单跑到别的账户上去了每次重新登陆都提示重设支付密码，而且设置的密码不能和上次相同
7. 在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加
8. 第一次提现申请未审核，再继续第二次提现申请无法成功
9. 前台发布出租房源，后台通过审核并且成功加入出租列表，前台搜索失败

48，一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。

测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。

49，在需求文档不太详细的情况下，如何开展测试/h2>

1. 解决用户问题或达到用户目标需要具备的条件或能力
2. 遵守合同、协议、规范或其他要求

50，如何尽快找到软件中的bug/h2>

1. 尽快熟悉公司的产品业务，只有熟悉了产品的业务流程、你才能迅速找出软件中存在的一些重要的缺陷；
2. 把自己当成用户，把自己当成是用户去使用该系统
3. 善于怀疑，不要过于相信开发人员的能力；

51，什么是bug/h2>

1. 软件未实现需求和规格要求的功能 ；
2. 软件未实现需求和规格未明确提及但应该实现的内容 ；
3. 软件难以理解，不易使用，运行缓慢，或者最终用户(估计会)认为不好；
4. 测试用例执行中发现的与预期结果不符的现象

52，ATM机吞卡的吞卡现象是不是BUG/h2>

不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。

53，如何减少非问题单的提交/h2>

1. 熟悉项目需求，充分了解各个各个功能模块的功能、参数、约束条件，弄清存在数据交互的模块之间的数据来源、数据流向；
2. 跟产品确认该问题是否属于非问题单。

54，有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题/h2>

将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。

55，你们发现bug会怎么处理。

发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。

来源：凯凯要加班