[TOC] ## B/S架构与C/S架构的区别 * 由于浏览器的内核不同，所以b/s架构需要重点考虑在不同浏览器中的兼容性问题 * c/s架构则需要着重考虑在不同平台的安装、卸载与升级 <br /> ## 简述HTTP协议 HTTP协议是一个超文本传输协议，由请求与响应组成，常见的请求方式有`get`与`post` 通常用get请求的请求参数会跟随请求地址一起发送，通常用来向服务器上获取数据，传输速度快，但相对不安全。 而post请求的请求参数会在请求体中单独发送，通常用来向服务器传递数据，传输速度比get慢，但相对安全。 常见的HTTP状态码有`200 请求成功`，`301 永久移动`，`302 临时移动`，`404 找不到资源`，`403 权限被拒绝`，`500 服务器内部错误` <br /> ## cookie与session的区别与联系 1. cookie的数据存放在浏览器上，而session的数据存放在服务器上的。 2. cookie不是很安全，别人可以利用本地的cookie进行cookie欺骗，考虑安全的话，应该使用session 3. session会在一定时间内，保存在服务器上，当访问增多时，会占用服务器资源。 <br /> ## 什么是软件测试？软件测试的定义是什么？ 用简单的话来概述，就是在把软件交付给用户使用前，我们先用一遍，站在用户的角度，模拟各种正常的和异常的场景来使用软件。 <br /> ## 测试的目的是什么？ 软件测试不仅仅是为了发现软件缺陷与错误，而且也是对软件质量进行度量和评估，以提高软件的质量，降低软件开发成本。 <br /> ## 软件测试的原则 1. 所有的软件测试都应追溯到用户需求。 2. 尽早地和不断地进行软件测试 3. 完全测试是不可能的，测试需要终止。 4. 充分注意测试中的群集现象。 5. 程序员应避免检查自己的程序。 6. 尽量避免测试的随意性 <br /> ## 软件测试分为哪几个阶段 单元测试、集成测试、系统测试、验收测试。 <br /> ## 软件测试的风险有哪些？ 风险也包括进度风险、质量风险、人员风险、需求变更等 <br /> ## 什么是单元测试（Unit Testing） 单元测试是指对软件中的最小可测试单元进行检查和验证。 <br /> ## 集成测试的关注点 在把各个模块连接起来时，查看穿越模块接口的数据是否会丢失。 <br /> ## 系统测试范围/策略/类型 功能测试、用户体验测试、性能测试、UI测试、兼容性测试、安装测试、文档测试、稳定性测试等 <br /> ## а测试与ß测试的区别 а测试是公司组织内部人员对即将上市的产品进行测试。 ß测试是公司组织的典型客户在日常工作中实际使用，然后公司再进行完善。 <br /> ## 正式的验收测试怎么做？ 在验收测试之前，我们会制定测试方案，选择级别高的用例，在UAT测试环境上进行测试，如果测试通过，验收测试就通过了。 <br /> ## 质量的六大特性/测试一个软件从哪些方面进行测试 功能、安全、用户体验、兼容性、性能、可靠性 <br /> ## 常见的安全测试类型 1. 检查敏感信息是否在前端加密，在网络传送过程中是否加密； 2. 检查系统是否存在SQL注入漏洞； 3. 检查系统是否存在XSS注入漏洞； 补充；XSS注入又称(跨站点脚本攻击)，使用的就是JS脚本 <br /> ## 白盒、黑盒与灰盒测试的区别 * 白盒测试主要是对程序的内部结构与算法 * 黑盒测试是不考虑程序内部逻辑情况下， 检查程序是否满足需求 * 关注接口所实现的功能，是否与需求一致。 <br /> ## 冒烟测试的目的 检查系统的主要流程能够使用，确保基本功能正常。 <br /> ## 全量回归与部分回归的区别 * 全量回归主要是对软件的新版本测试时，重复执行上一个版本测试时使用的测试用例，防止出现“以前没有问题的地方现在出问题了” * 部分回归就是在测试过程中，发现bug，开发修复后，我们会去验证该缺陷是否被修复，以及验证相关联的模块是否受影响。 <br /> ## 回归测试怎么做？ 首先，把bug单对应的用例执行一遍，还要检查有数据交互的模块会不会受影响，有没有引入新的问题； 项目上线前，还要把当前版本的重要功能以及冒烟测试的用例都回归一遍，确保重要功能上线后不出问题。 <br /> ## 需求分析的目的 澄清需求，提取测试点 <br /> ## 常见软件的默认端口 * http :`80` * https:`443` * tomcat:`8080` * mysql:`3306` * oracle:`1521` <br /> ## tomcat 目录内容 * tomcat的`bin`目录是存放启动或者停止tomcat服务的指令 * tomcat的`webapps`目录，是存放项目的安装包的目录 * tomcat的`logs`目录，默认是存放日志的目录 <br /> ## 为什么要编写测试计划？/测试计划的目的 为了规范软件测试内容、方法和过程，所以在对软件进行测试之前，必须创建测试计划。 <br /> ## 什么时间开始编写测试计划？ 需求分析后编写测试计划，在整个测试工作过程中，不断修改 <br /> ## 由谁来编写测试计划？ 具有丰富经验的项目测试负责人 <br /> ## 测试计划的内容是什么？ **测试项目的背景、测试范围和测试策略、测试环境、测试开始和结束条件、进度安排，测试组织，以及与测试有关的风险**等方面的内容。 <br /> ## 软件开始和结束条件 软件测试开始的条件是在项目启动、需求分析开始时随之启动。 结束条件(项目上线的条件)：是需要需求覆盖率、用例执行率、缺陷遗留率达到预定质量目标。 一般 用例对需求的覆盖率达到100%；致命、严重级别的缺陷必须当天解决，一般、轻微级别的缺陷，遗留率是30%以下。 <br /> ## 用例的级别如何划分 测试用例级别的划分，一般是依据用户使用该场景的频率，和该功能对系统的影响程度来确定 <br /> ## 什么是用例颗粒度？ 颗粒度，指的是粗细程度。粒度大，就是说一个用例所涵盖的关注内容比较多，反之同理。 通常，一个用例测试一个场景即可。 <br /> ## 写好测试用例的关键 熟悉业务，了解系统； 充分考虑用户的各种正常和异常的使用场景，覆盖用户的需求； 用例的颗粒大小要均匀。通常，一个测试用例对应一个场景； 用例各个要素要齐全，步骤应该足够详细，容易被其它测试工程师读懂，并能顺利执行； 做好用例评审，及时更新测试用例。 <br /> ## 怎样保证覆盖用户需求？ 项目开始前，我们会先熟悉需求，画好流程图，保证整个流程都覆盖全面，小组之间每个人都要根据各自的流程图，各个功能点有哪些限制条件，来讲解一下自己对测试点的理解，防止之后编写测试用例时出现遗漏；用例编写完之后，再进行用例的评审，看看测试点有没有用遗漏，对需求理解有没有错误，测试场景是否覆盖完全。 <br /> ## 测试用例的状态有哪些 当用例还尚未被执行时，是`No Test`,`未执行状态` 当执行结果与预期结果相符时，是`Pass`,`通过状态` 当执行结果与预期结果不符时，是`Fail`,`失败状态` 当因为软件有缺陷而妨碍了用例步骤的执行，且该缺陷并不是我们的测试点，则用例是`Block`,`阻碍状态`。 当用例正在执行中，但是需要耗较多时间去观察其结果，是`Investigate`,`观察中状态`。 <br /> ## 测试用例的要素 用例编号，用例标题，优先级，预置条件、测试步骤、预计结果 <br /> ## 测试环境怎么搭建的？ 搭建环境前，开发都会给到我们一份系统发布手册，我们会根据这个手册来搭建。比如，我最近这一个项目，就是搭建在Linux系统下的，web服务器用的是Tomcat8，MySQL版本是5.7，程序是JAVA编写的，首先我们向开发拿到编译好的安装包，然后用CRT远程连接上Linux系统，把tomcat服务器停掉，把程序包放到webapps目录下，然后再启动tomcat服务器就可以了。 <br /> ## 偶然性问题的处理 1. 发现bug之后，我们会先截图，如果确定是偶然性的问题，会将日志和截图一起提单给开发定位； 2. 如果缺陷在当前版本无法复现，且缺陷的影响程度比较低，可以提交问题单进行跟踪，跟踪三个版本，如果后三个版本都无法复现，就可以关闭该缺陷； 3. 如果是很严重的Bug，比如导致系统崩溃等，并且，实在没有再次出现，除了要及时反馈给上级之外，最后还要写到测试报告中，说明出现了什么现象，但无法再现！ <br /> ## 当我们认为某个地方是bug，但开发认为不是bug，怎么处理？ 1. 先跟开发沟通，确认系统的实际结果是不是和需求有不一致的地方；有些地方可能需求没提及，但是用户体检不好，我们也可以认为是bug。 2. 如果开发以不影响用户使用为理由，拒绝修改，我们可以和产品经理，测试经理等人员进行讨论，确定是否要修改，如果大家都一致认为不用改，就不改。 <br /> ## 产品在上线后用户发现bug，这时测试人员应做哪些工作？ 1. 测试人员复现问题后，提交问题单进行跟踪； 2. 评估该问题的严重程度，以及修复问题时的影响范围，回归测试需要测试哪些功能； 3. 问题修复后，先在测试环境上回归，通过后再在生产环境上打补丁，然后再进行回归测试； 4. 总结经验，分析问题发生的原因，避免下次出现同样问题。 <br /> ## 二八定理 80%的缺陷出现在 20%的模块。 <br /> ## 如何跟踪缺陷 当发现缺陷后，我们要在禅道上提交问题单给开发，并每隔一段时间(间隔一个小时，或两个小时都可以)去检查缺陷是否被处理，如果没及时处理，就要提示开发，让开发及时修复问题，问题修复后，要及时进行回归测试。 <br /> ## 缺陷的状态 激活,确认,已解决,关闭 <br /> ## 缺陷的等级 致命,严重,一般,轻微 <br /> ## 缺陷单应该包含这些要素 缺陷标题，严重级别，问题所属模块，复现步骤，预期结果，实际结果，有关的日志和截图。 <br /> ## 测试报告的主要内容 人力投入，用例统计，问题单分类统计，遗留bug情况，测试风险，测试对象评估，测试结论 <br /> ## 如何定位bug： 1. 检查测试环境配置是否有问题，测试数据是否有问题 2. 用fiddler抓包，分析请求和响应数据是否存在问题 3. 查看应用服务器的日志 4. 然后再查看数据库的数据是否存在问题 <br /> ## 开发没时间修复，如何推进bug的修复： 1. 和开发说明该问题的严重性，会怎样影响产品的正常使用，如何还是坚持不改，就上报领导，让领导辅助推进； 2. 确认问题的严重程度，如果影响不大，不是非要改的bug，并且修复风险比较大，和领导商量后，如果认为暂时可以不用修复，也可以不修复。 <br /> ## 软件测试流程 我们这个项目是两个人负责测试的，按模块进行分工，我负责xxx模块。项目启动后，我们会到服务器上下载相关的需求文档，熟悉项目的流程，进行需求澄清，提取测试点；然后编写测试用例，再进行组内的评审，修改，定稿；在开发阶段，开发人员写完一个接口，我们就测试一个接口；等开发转测后，我们从svn上获取安装包，搭建测试环境；之后我们开始进行冒烟测试，冒烟通过后，我们就进入系统测试，就开始执行用例，发现bug就提交bug，并跟踪bug，直至bug解决，之后进行用户验收测试，验收通过后，编写测试报告。 <br /> ## ATM机吞卡的吞卡现象是不是BUG? 不一定，看是什么情况下吞卡。如：输入三次密码错误吞卡是正常的，不属于BUG；若输入一次密码错误吞卡则是不正常的，属于BUG。 <br /> ## 有个程序，在windows上运行很慢，怎么判断是程序存在问题，还是软硬件系统存在问题？ 将程序放在其他的windows上运行，如果运行的还是很慢则是程序的问题。 <br /> ## 项目介绍 参考思路：项目叫什么名字，什么架构，有哪些模块，用来干什么的，主要的操作流程 * 参考：我就说一下最近的一个项目，是集书芸管理系统，主要是一款基于B/S架构的电商分销管理系统，前台模块有店铺首页，购物车，会员中心，申请分销等，后台模块有店铺管理，书籍管理，订单管理，分销管理等，在后台可以上架新的商品，设置店铺活动，管理订单等，用户可以在前台注册成为会员，然后登陆系统，搜索上架的商品，将商品加入购物车之后进行结算下单，或者直接进行结算下单，下单后在用户的‘我的订单’能看到该订单信息，订单状态为待付款，在系统后台的订单管理列表也能看到该订单的信息，买家付款后，订单状态为待发货状态 ，卖家就可以进行发货，买家收到产品后进行确认，评论，整个购物的流程就结束了。这就是我这个项目的大概情况。 <br /> ## 你们发现bug会怎么处理。 答:发现bug后，我们会先自己定位一下，比如，抓个包，看看是前端的问题，还是后端的问题，检查下数据库的数据是不是正确的，尽量把问题发生的原因或者产生的日志找出来，方便开发定位问题，然后就提单给开发，然后开发做出相应的处理，开发修复完后就进行回归测试，回归测试通过后就关闭这个bug，没有通过就继续给回开发修复。如果遇到开发认为这个不是bug的话，那么我们就要和开发沟通，然后我们要坚持自己的立场，通过讨论后一致认为是bug就给开发修复，不是就关闭这个bug。如果开发和我们意见一直不一致，那么就要将问题升级，召集开发经理和测试经理一起讨论，再做决定。 ## 一个项目完成时，有多个重要的缺陷没有被修复，但是项目负责人说可以不修改，你认为测试是不通过的，请简述你的理由。 测试是对软件的质量进行的把关，如果一个项目仍然有很多的缺陷未被修复，那么从质量的角度上我们会认为这个软件质量是不达标的，一般来说缺陷的遗留，是不允许严重、致命bug的遗留，轻微和一般的bug遗留率不超过30%。 <br /> ## 在需求文档不太详细的情况下，如何开展测试？ 首先，把需求文档中有异议的部分标识出来，再找产品和开发一起讨论，把需求明确下来； 提取测试点，然后再叫上产品和开发一起对测试点进行讨论，看有没有遗漏，是不是合理的， 然后再编写测试用例，再评审，评审通过后，再进行后续的测试。 <br /> ## 判定表用在哪些时候/哪些功能 判定法，是用在不同的输入组合，可能会产生不同的输出这种情况，比如，一个有多个查询条件的查询功能，输入不同的查询条件组合，输出的结果是不一样的，这样的功能就要用到判定表 <br /> ## 什么时候用到场景法 使用场景法通常是在冒烟测试中或者 一些流程性比较强的软件/功能(比如安装，卸载等等) <br /> ## 三角形测试用例设计 **解题思路** 我们可以设三角形的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。