软件测试常见的问题

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. 在未登录的情况下添加商品到购物车跳转到登录页面，登录成功后购物车数量不会增加

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. 跟产品确认该问题是否属于非问题单。

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

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

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

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