软件测试面试题之软件基础

B/S架构与C/S架构的区别

• 由于浏览器的内核不同，所以b/s架构需要重点考虑在不同浏览器中的兼容性问题
• c/s架构则需要着重考虑在不同平台的安装、卸载与升级

简述HTTP协议

HTTP协议是一个超文本传输协议，由请求与响应组成，常见的请求方式有get与post

通常用get请求的请求参数会跟随请求地址一起发送，通常用来向服务器上获取数据，传输速度快，但相对不安全。

而post请求的请求参数会在请求体中单独发送，通常用来向服务器传递数据，传输速度比get慢，但相对安全。

常见的HTTP状态码有200 请求成功，301 永久移动，302 临时移动，404 找不到资源，403 权限被拒绝，500 服务器内部错误

cookie与session的区别与联系

1. cookie的数据存放在浏览器上，而session的数据存放在服务器上的。
2. cookie不是很安全，别人可以利用本地的cookie进行cookie欺骗，考虑安全的话，应该使用session
3. session会在一定时间内，保存在服务器上，当访问增多时，会占用服务器资源。

什么是软件测试？软件测试的定义是什么？

用简单的话来概述，就是在把软件交付给用户使用前，我们先用一遍，站在用户的角度，模拟各种正常的和异常的场景来使用软件。

测试的目的是什么？

软件测试不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量，降低软件开发成本。

软件测试的原则

1. 所有的软件测试都应追溯到用户需求。
2. 尽早地和不断地进行软件测试
3. 完全测试是不可能的，测试需要终止。
4. 充分注意测试中的群集现象。
5. 程序员应避免检查自己的程序。
6. 尽量避免测试的随意性

软件测试分为哪几个阶段

单元测试、集成测试、系统测试、验收测试。

软件测试的风险有哪些？

风险也包括进度风险、质量风险、人员风险、需求变更等

什么是单元测试（Unit Testing）

单元测试是指对软件中的最小可测试单元进行检查和验证。

集成测试的关注点

在把各个模块连接起来时，查看穿越模块接口的数据是否会丢失。

系统测试范围/策略/类型

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

а测试与ß测试的区别

а测试是公司组织内部人员对即将上市的产品进行测试。
ß测试是公司组织的典型客户在日常工作中实际使用，然后公司再进行完善。

正式的验收测试怎么做？

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

质量的六大特性/测试一个软件从哪些方面进行测试

功能、安全、用户体验、兼容性、性能、可靠性

常见的安全测试类型

1. 检查敏感信息是否在前端加密，在网络传送过程中是否加密；
2. 检查系统是否存在SQL注入漏洞；
3. 检查系统是否存在XSS注入漏洞；

补充；XSS注入又称(跨站点脚本攻击)，使用的就是JS脚本

白盒、黑盒与灰盒测试的区别

• 白盒测试主要是对程序的内部结构与算法
• 黑盒测试是不考虑程序内部逻辑情况下， 检查程序是否满足需求
• 关注接口所实现的功能，是否与需求一致。

冒烟测试的目的

检查系统的主要流程能够使用，确保基本功能正常。

全量回归与部分回归的区别

• 全量回归主要是对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前没有问题的地方现在出问题了”

• 部分回归就是在测试过程中，发现bug，开发修复后，我们会去验证该缺陷是否被修复，以及验证相关联的模块是否受影响。

回归测试怎么做？

首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题；

项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。

需求分析的目的

澄清需求，提取测试点

常见软件的默认端口

• http :80
• https:443
• tomcat:8080
• mysql:3306
• oracle:1521

tomcat 目录内容

• tomcat的bin目录是存放启动或者停止tomcat服务的指令
• tomcat的webapps目录，是存放项目的安装包的目录
• tomcat的logs目录，默认是存放日志的目录

为什么要编写测试计划？/测试计划的目的

为了规范软件测试内容、方法和过程，所以在对软件进行测试之前，必须创建测试计划。

什么时间开始编写测试计划？

需求分析后编写测试计划，在整个测试工作过程中，不断修改

由谁来编写测试计划？

具有丰富经验的项目测试负责人

测试计划的内容是什么？

测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险等方面的内容。

软件开始和结束条件

软件测试开始的条件是在项目启动、需求分析开始时随之启动。

结束条件(项目上线的条件)：是需要需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。
一般 用例对需求的覆盖率达到100%；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是30%以下。

用例的级别如何划分

测试用例级别的划分，一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定

什么是用例颗粒度？

颗粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理。
通常，一个用例测试一个场景即可。

写好测试用例的关键

熟悉业务，了解系统；
充分考虑用户的各种正常和异常的使用场景，覆盖用户的需求；
用例的颗粒大小要均匀。通常，一个测试用例对应一个场景；
用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行；
做好用例评审，及时更新测试用例。

怎样保证覆盖用户需求？

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

测试用例的状态有哪些

当用例还尚未被执行时，是No Test,未执行状态
当执行结果与预期结果相符时，是Pass,通过状态
当执行结果与预期结果不符时，是Fail,失败状态
当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是Block,阻碍状态。
当用例正在执行中，但是需要耗较多时间去观察其结果，是Investigate,观察中状态。

测试用例的要素

用例编号，用例标题，优先级，预置条件、测试步骤、预计结果

测试环境怎么搭建的？

搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我最近这一个项目，就是搭建在Linux系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用CRT远程连接上Linux系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。

偶然性问题的处理

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

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

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

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

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

二八定理

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

如何跟踪缺陷

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

缺陷的状态

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

缺陷的等级

致命,严重,一般,轻微

缺陷单应该包含这些要素

缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。

测试报告的主要内容

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

如何定位bug：

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

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

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

软件测试流程

我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入系统测试，就开始执行用例，发现bug就提交bug，并跟踪bug，直至bug解决，之后进行用户验收测试，验收通过后，编写测试报告。

ATM机吞卡的吞卡现象是不是BUG?

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

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

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

项目介绍

参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程

• 参考：我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。

你们发现bug会怎么处理。

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

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

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

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

首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来；
提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的，
然后再编写测试用例，再评审，评审通过后，再进行后续的测试。

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

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

什么时候用到场景法

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

三角形测试用例设计

解题思路
我们可以设三角形的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。