测试工程师八股文

软件的生命周期（基础）

计划阶段-〉需求分析-〉设计阶段-〉编码->测试->运行与维护

公司一般测试流程

项目立项->需求评审->开发设计->设计评审->开发编码->测试用例编写->用例评审->功能测试->上线跟踪

1、测试准备阶段：需求对接、需求评审、测试计划、测试负责人。
2、测试准备阶段：编写测试用例、评审，环境部署、测试工具（用最少的用例覆盖最多的测试点）
分两类，一是根据需求分解出测试功能点并标出优先级，二是根据功能点设计测试用例和流程方面用例。
3、测试执行阶段：单体测试、系统测试
4、测试总结和验收：输出测试报告

软件测试方法

1、软件测试方法：
白盒测试、黑盒测试、灰盒测试、静态测试、动态测试

2、白盒测试： 是一种测试用例设计方法，在这里盒子指的是被测试的软件，白盒，顾名思义即盒子是可视的，你可以清楚盒子内部的东西以及里面是如何运作的，因此白盒测试需要你对系统内部的结构和工作原理有一个清楚的了解，并且基于这个知识来设计你的用例。

白盒测试技术一般可被分为静态分析和动态分析两类技术。

静态分析主要有：控制流分析技术、数据流分析技术、信息流分析技术。

动态分析主要有：逻辑覆盖率测试(分支测试、路径测试等)，程序插装等。

白盒测试优点：迫使测试人员去仔细的思考软件的实现；可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；最优化。

白盒测试缺点：昂贵；无法检测代码中遗漏的路径和数据敏感性错误；不验证规格的正确性。

3、黑盒测试又叫功能测试，这是因为在黑盒测试中主要关注被测软件的功能实现，而不是内部逻辑。在黑盒测试中，被测对象的内部结构，运作情况对测试人员是不可见的，测试人员对被测产品的验证主要是根据其规格，验证其与规格的一致性。

在绝大多数没有用户参与的黑盒测试中，最常见的测试有：功能性测试、容量测试、安全性测试、负载测试、恢复性测试、标杆测试、稳定性测试、可靠性测试等。

4. 灰盒测试：白盒测试和黑盒测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。灰盒测试就是这类界于白盒测试和黑盒测试之间的测试。

最常见的灰盒测试是集成测试。

5. 静态测试： 是一种不通过执行程序而进行测试的技术。它的关键功能是检查软件的表示和描述是否一致，没有冲突或者没有歧义。

6. 动态测试： 包含了程序在受控的环境下使用特定的期望结果进行正式的运行。它显示了一个系统在检查状态下是正确还是不正确。

单元测试属于白盒测试范畴；集成测试属于灰盒测试范畴；系统测试属于黑盒测试范畴。

黑盒测试和白盒测试是什么？二者有什么区别

黑盒测试主要是在程序界面进行测试，通过设定某种场景检验程序在这种场景下是否给出了正确的反应，验证程序正确实现了需求规格说明书中的需求，
而白盒测试主要是针对程序内部结构，对程序代码进行代码走查等，但是白盒测试的成本会比较大，当程序有 多个路径时，可能会产生较多的遗漏。

黑盒测试和白盒测试两者有什么方法，

黑盒测试方法有等价类划分，边界值分析，错误推测，因果图法
白盒测试方法有逻辑覆盖法，程序插桩技术，基本路径法，符号测试，错误驱动测试

软件测试有什么类型？

常见的软件测试类型有:功能测试、性能测试、兼容性测试、可靠性测试、安全性测试、压力测试、负载测试等。

测试用例

测试用例编写依据

需求说明书
产品测试需求功能点
所属行业的业务知识掌握程度
测试工程师本人的理解程度（个人经验）

测试用例编写原则

系统性：对系统业务流程要完整说明整个系统的业务需求、系统由几个子系统组成以及它们之间的关系；对模块业务流程要说明子系统内部功能、重点功能以及它们之间的关系；

连贯性：对系统业务流程要说明各个子系统之间是如何连接在一起，若需要接口，各子系统之间是否有正确的接口，若是依靠页面链接，则页面的链接是否正确；对模块业务流程要说明同级模块以及上下级模块是如何构成一个子系统，其内部功能接口是否连贯；

全面性：应尽可能覆盖各种路径、尽可能覆盖各个业务点，并要考虑跨年、跨月的数据以及大数据量并发测试的准备；

正确性：输入界面后的数据应与测试文档所记录的数据一致，而预期结果也应与测试数据发生的业务吻合；

符合正常业务规则：测试数据要符合用户实际工作中的业务流程，同时也要兼顾各种业务的变化以及当前该业务行业的法律、法规、人名、地名、电话号码等应具有模拟功能，符合一般的命名惯例；不允许出现与知名人士、小说中人物名等雷同情况；

可操作性：测试用例中要写清楚测试的操作步骤，以及不同的操作步骤相对应的测试结果

测试用例设计方法

白盒测试：逻辑覆盖、循环覆盖、基本路径覆盖
黑盒测试：边界值分析法、等价类划分、错误猜测法、因果图法、状态图法、测试大纲法、随机测试、场景法（老司机靠脑补大法）
测试用例设计方法

用例内容

用例的维护

1、删除过时的测试用例
因为需求的改变等原因可能会使一个基线测试用例不再适合被测系统，那么这些测试用例就会过时，需要对这些测试用例进行及时的删除，在删除过程中，不能将所有用例删除，仅将计划中用例去除，将用例评审状态置为废弃状态；
2、修改的测试用例
随着软件项目的进展，测试需求可能会有部分变更，甚至大范围的变更，这个时候我们就会根据需求的变化相应的对测试用例进行维护，修改已经不符合目前需求的内容，并在备注栏中加以说明【原则上测试用例执行三分之二后不允许变更及新增新的开发需求】
3、删除冗余的测试用例
如果存在两个或更多测试用例对一组相同的输入和输入进行测试，则需要对其进行删除，只需留下其中的一个
4、增添新的测试用例
对新增的功能、在评审过程及测试过程中发现缺少测试用例或者系统出现BUG但是没有与之对应的测试用例，需要按照测试用例的设计标准进行增添【不含新增的开发任务】，增加测试用例时，需要在相应功能模块的最下方插入新增的测试用例，并在备注栏中加以说明

测试结束的标准

1、用例全部测试。
2、覆盖率达到标准。
3、缺陷率达到标准。
4、其他指标达到质量标准

测试报告里面包含什么内容？

分析：测试报告，是测试工作结束后测试部门输出的一份测试结果，但每个公司的测试报告内容都会有些差别。有些公司的测试报告是有测试部门的负责人一人编写，或者是由每个测试工程师输出自己对应模块的测试报告再由测试组长整合成一份完整的测试报告。
测试报告内容一般有：编写目的、系统简介、测试环境、测试方法和工具、测试
执行结果与记录、缺陷汇总、遗留缺陷跟踪、测试用例执行情况、测试结论与建议等

软件测试分为几个阶段 各阶段的测试策略和要求

测试过程会依次经历单元测试、集成测试、系统测试、验收测试四个主要阶段。

单元测试：是针对软件设计的最小单位（对于功能测试就是模块） 集成测试：是将模块按照设计要求组装起来进行测试，主要目的是发现与接口有关的问题。
系统测试：是在集成测试通过后进行的，目的是充分运行系统，验证各子系统是否都能正常工作并完成设计的要求。
验收测试：以需求阶段的《需求规格说明书》为验收标准，测试时模拟实际用户的运行环境

快速区分bug来源以及常见状态码（12345）

哥，咱们一起看报文，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对；请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题，状态码如下：

状态码	原因语句
1XX Informational （信息性状态码）	接收的请求正在处理
2XX Success （成功状态码）	请求正常处理完毕
3XX Redirection （重定向状态码)	需要进行附加操作以完成请求
4XX Client Error（客户端错误状态码）	服务器无法处理请求
5XX Server Error （服务器错误