测试相关知识点梳理

软件测试的标准流程：

获取测试需求——编写测试计划——制定测试方案——设计测试用例——用例评审——执行测试——提交缺陷报告——测试分析与审批——提交测试报告

• 需求分析阶段
  • 阅读需求、理解需求、分析需求点、参与需求审评会议
• 测试计划阶段
  • 主要任务就是编写测试计划，参考软件需求规格说明书，项目总体计划，内容包括测试范围，进度安排，人力物力分配，整体测试策略的判定
• 编写测试用例
  • 适当的了解设计，搭建测试用例框架，根据需求和设计编写测试用例
• 测试执行阶段
  • 搭建环境准备数据，执行冒烟测试（预测试），然后进入正式测试（系统测试、回归测试、交叉测试、自由测试），bug管理直到测试结束
• 输出测试报告
  • 输出测试报告，确认是否可以上线

测试用例的组成部分

用例编号、功能模块、用例标题、前置条件、执行步骤、预期结果、实际结果、执行人、用例等级。

如何提高测试用例的有效性

• 使用等价分类法，避免测试用例的冗余
• 考虑特殊场景，提高测试用例的覆盖率
• 交叉测试，一个测试用例包含互不相关的多个测试点的不同值
• 准确描述用例前置条件、操作路径、预期结果、实际结果
• 了解本次需求变动的涉及部分，非本次影响范围内的模块可以不测试

黑盒测试、白盒测试、灰盒测试

黑盒测试——黑盒测试指的是把被测的软件看成一个黑盒子，我们不去关心盒子里的结构是什么样的，只关心软件的输入数据和输出结果，它只检测程序呈现给用户的功能是否按照需求规格说明书的规定正常使用、程序是否能接收输入数据并产生正确的输出信息，黑盒测试着眼于外部测试结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试

 白盒测试——百合测试指的是把盒子打开，去研究里面的源代码和程序执行结果，它是按照程序内部结构测试程序的，通过测试来检测产品内部动作是否按照设计规格说明书的规定正常进行，检验程序中的每条逻辑路径，是否都能按预定要求正确工作。

灰盒测试——灰盒测试是介于白盒和黑盒之间的，灰盒测试既关注输出对于输入的正确性，同时也关注内部表现，但这种关注不像白盒测试那样详细、完整，它只是通过一些象征性的现象、事件、标志来判断内部的运行状态，有时候输出是正确的，但是内部结构已经错了，这种情况非常多，如果每次都通过白盒测试来操作，效率会很低，因此需要采取灰盒测试的方法

功能测试与性能测试

功能测试——功能测试主要检测实际功能是否符合用户的需求，因此测试的大部分工作也是围绕软件的功能进行，设计软件的目的就是满足用户对其功能的需求，若偏离目的，任何测试工作将没有意义

功能测试：逻辑功能测试、界面测试、易用性测试、安装测试、兼容性测试等

性能测试——性能测试是通过自动化测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试

性能测试：时间性能测试、空间性能测试

时间性能：主要指软件的一个具体响应时间，例如：账号登录所需时间，商品交易所需时间（需要搭建好一个具体且独立的测试环境进行、抛开具体的测试环境来分析事务的响应时间是没有任何意义的）

空间性能：主要指软件运行时所消耗的系统资源，例如：硬件资源、CPU、内存、网络宽带消耗等

手工测试与自动化测试

手工测试——手工测试是由测试人员一个一个的去执行测试用例，通过键盘鼠标等输入一些参数，并查看返回结果是否符合预期结果。通常指我们在系统测试阶段所进行的功能测试

自动化测试——自动化测试是把人为驱动的测试行为转化为机器执行的一种过程，通常，在设计测试用例并通过审核之后，由测试人员根据测试用例中描述的规则流程一步步执行测试，把得到的实际结果与预期结果进行比较，在此过程中，为了介绍人力、时间、硬件资源、提高测试效率，便引入了自动化测试

自动测试：功能自动化测试和性能自动化测试

功能自动化测试：是把以人为驱动的测试行为转化为机器执行的一种过程，通过测试工具（框架）录制/编写测试脚本，对软件的功能进行测试，并验证测试结果是否正常，从而代替部分手工测试，达到节约人力成本和时间成本的目的

性能自动化测试：通过性能工具老模拟成千上万的虚拟用户向系统发送请求，从而验证系统的处理能力

冒烟测试、回归测试、随机测试、探索性测试和安全测试

冒烟测试——冒烟测试是指对一个新版本进行大规模的系统测试之前，先验证一下软件的基本功能是否实现，是否具备可测性（测试小组在正式测试一个新版本之前，先投入较少的人力和时间验证一个软件的主要功能，如果主要功能都没有运行通过，则打回开发组重新开发，这样做可以节省时间和人力投入）

回归测试——回归测试是指修改了旧代码后重新进行测试以确认修改后没有引入新的错误或导致其他代码产生错误（回归测试一般是在进行第二轮软件测试时开始的，验证第一轮软件测试中发现的问题是否得到修复，当然，回归也是一个循环的过程，如果回归的问题通不过，则需要开发人员修改后再次进行回归，直到所有问题回归通过为止）

随机测试—— 随机测试指测试中所有输入数据都是随机生成的，其目的是模拟用户的真实操作，并发现一些边缘性错误（随机测试可以发现一些隐蔽的错误）

探索性测试——探索性测试可以说是一种测试思维技术，它没有很多实际的测试方法、技术和工具，但却是所有测试人员都应该掌握的一种测试思维方式，探索性测试强调测试人员的主观能动性，抛弃繁杂的测试计划和测试用例设计过程，强调在碰到问题时及时改变测试策略

安全测试——安全测试是在IT软件产品的生命周期中，特别是产品开发基本完成至发布阶段，对产品进行检验已验证产品符合安全需求定义和产品质量标准的过程

软件测试工程师的职业规划

• 首先是先就业再择业，我会划分三个阶段来实现自我价值以及充分吸收公司核心价值观来提高自我竞争力；
• 第一阶段：我会稳扎稳打，快速汲取技术，保证在这个岗位上沉淀下来，积累工作经验，把基础打牢
• 第二阶段：利用三至五年时间，希望可以成为这个领域可以在这个方面在公司可以独挡一面，能够承担问题，发现问题，解决问题，不让上司操心
• 第三阶段：充分展现出自己的核心竞争力，成为公司专业化人士，在工作中有自己的创新或者新的发展，以为公司带来更大的价值为核心，以努力提高自身能力为主导，走进管理层，展现出自我价值最大化

软件生存周期

定义阶段（计划）——>开发阶段（需求分析——>软件设计——>程序编码——>软件测试）——>维护阶段（运行、维护）

需求分析：（系统需要做什么）

软件需求说明书、系统功能说明书、初步系统用户手册

软件设计：（如何去做）概要设计、详细设计

设计说明书，软件结构图

程序编写：具体如何实现

源程序清单

软件测试：（测Bug）单元测试、集成测试、系统测试、验收测试

测试报告文档（测试计划、测试用例、测试结果）

单元测试：又称模块测试，是对程序中的单个子程序或具有独立功能的代码进行测试的过程

集成测试：集成测试是在单元测试的基础上，先通过单元模块组装成系统或者子系统，再进行测试，重点是检查模块之间的接口是否正确

系统测试：系统测试是针对整个产品系统进行的测试，验证系统是否满足需求规格的定义，以及软件系统的正确性和性能等是否满足其需求规格的要求

验收测试：验收测试是上线软件之前的最后一个阶段的测试（预发环境），验收测试的目的是确保软件准备就绪，像软件购买者展示该软件系统能够满足用户的需求

运行维护：改正性维护、适应性维护、完善性维护

什么项目更适合自动化测试

需求变动小、项目周期长、可复用性高

趣谈软件需求分析：http://www.testclass.net/software_test/requirement-analysis

一个BUG的声明周期：http://www.testclass.net/software_test/bug-processing-flow

测试用例：http://www.testclass.net/software_test/test_case

测试用例编写方法：

等价类划分

等价类是指某个输入域的一个特定的子集合，在该子集合中各个输入数据对于揭露程序中的错误都是等效的，也就是说，如果用这个等价类中的代表值作为测试用例未发现程序错误，那么该类中其他数据（测试用例）也不会发现程序中的错误。

有效等价类： 输入满足程序输入的要求（来自规格说明书），通俗的说就是正确的输入。

无效等价类： 输入不满足程序输入的要求，即异常输入，需要系统对此有一定的容错性。

例如：

一个输入框要求输入1-10000的数字

有效等价类：可以输入1-10000之间的数来验证，如：2、5、99、8495......

无效等价类：可以输入1-10000之外的任意字符验证，如：0、10001、字母、下划线、特殊符号、空格、回车.....

边界值

边界值是对等价类的补充，测试工作经验告诉我们，大量的错误是出在输入输出的边界价上。我们还拿上面的例子，一个输入框要求输入1-10000之间的数。我们要测它有没有超出这个范围，如：0、-1、-2、1000、10001.....等等，来判定是否超出了我们的范围。

因果图

因果图方法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。举个例子：原因：A=0，B=0，结果我就可以判定：A=B。确切的说他是一种因果关系思想。它会无形中指导这我们的测试。当然了，我们为了以免遗漏，可以把系统中的因果关系用图画出。不过系统大而复杂的话就是个体力活了。

错误推测法

基于经验和直觉推测出系统可能存在的错误，从而有针对性的设计测试用例的方法。

其他

设计测试用例的方法有很多，我们常用就上面几种，其它的方法还有：状态迁移图、流程分析法、正交验证法等等。

软测流程

说一个你工作中有价值的BUG（实则考研你在工作过程中的测试方法和步骤描述）

找一个自己工作中很熟悉的项目，然后，谈谈你是如何对这个项目进行测试的，然后，在某一个版本测试中，发现xxx，开发也xxxx，前端也xxxx，运维也xxxx，最后终于发现原来是xxx引起的xxxx 。

吞吐量（tps——transaction per second）

吞吐量下降可能是因为频繁访问redis，而频繁访问Redis的原因是参数过多

解决思路：减少参数（我们可以把多组参数变成json字符串之类的一个参数，从而达到信息量不减少而参数个数变少的效果）

了解HTTP协议，这个可以去协议里看哦，重点！

你认为测试工程师应该掌握哪些技术

简述cookies和是怎么工作的

Cookies机制：正统的Cookie分发是通过扩展HTTP协议来实现的，服务器通过在HTTP的响应投中加上一行特殊的指示以提示浏览器按照指示生产相应的Cookie。然而纯粹的客户端脚本如JavaScript或者VBScript也可以生成Cookie，而Cookie的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的Cookie，如果某个Cookie所声明的作用范围大于等于将要请求的资源所在的位置，则把该cookie符在请求资源的HTTP请求头上发送给服务器。

Session机制：Session机制是一种服务器端的机制，服务器使用一种类似于散列表的结构来保存信息。

列举Web测试和App测试的不同