测试知识汇总2
W模型
v模型
需求分析 验收测试
概要设计 系统测试
详细设计 集成测试
编码 单元测试
V
$\alpha,\beta,\gamma$测试
α是第一阶段，一般只供内部测试使用；
β是第二个阶段，已经消除了软件中大部分的不完善之处，但仍有可能还存在缺陷和漏洞，一般只提供给特定的用户群来测试使用；
Beta测试是一种验收测试。所谓验收测试是软件产品完成了功能测试和系统测试之后，在产品发布之前所进行的软件测试活动，它是技术测试的最后一个阶段，通过了验收测试，产品就会进入发布阶段。
验收测试一般根据产品规格说明书严格检查产品，逐行逐字地对照说明书上对软件产品所做出的各方面要求， 确保所开发的软件产品符合用户的各项要求。
Beta测试由软件的最终用户们在一个或多个客房场所进行。与Alpha测试不同，开发者通常不在Beta测试的现场，因Beta测试是软件在开发者不能控制的环境中的“真实”应用。用户Beta测试过程中遇到的一切问题（真实在或想像的），并且定期把这些问题报告给开发者。
λ是第三个阶段，此时产品已经相当成熟，只需在个别地方再做进一步的优化处理即可上市发行。
软件测试的基本标准
所有的测试都应追溯到用户需求。
应当把“尽早地和不断地进行软件测试”作为座右铭。
pareto原则：测试发现的错误中80%很可能起源于20%的模块中。
完全测试是不可能的，测试需要终止。
应由独立的第三方来构造测试。
尽量避免测试的随意性。
兼顾合理的输入和不合理的输入数据。
程序修改后要回归测试。
回归测试是指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误。
应长期保留用例，直至系统废弃。
设计系统测试计划需要参考的项目文挡有哪些
- 【软件需求】是软件开发之前做好的，软件开发是根据这个做的，那么软件测试自然也需要参考该文件
- 【迭代计划】是软件的某个周期的计划，自然也需要参考
- 【可行性】是软件开发前做好，用于证明该计划可行的，没有必要参考
白盒测试的方法
- 语句覆盖：语句覆盖是最起码的结构覆盖要求，语句覆盖要求设计足够多的测试用例，使得程序中每条语句至少被执行一次。
- 判定覆盖：判定覆盖又称为分支覆盖，它要求设计足够多的测试用例，使得程序中每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次。每个判断的取真、取假至少执行一次。
- 条件覆盖：条件覆盖要求设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值。
- 判定/条件覆盖：设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次。
- 组合覆盖：要求设计足够多的测试用例，使得每个判定中条件结果的所有可能组合至少出现一次。
- 路径覆盖：设计足够的测试用例，覆盖程序中所有可能的路径。
覆盖准则由弱到强依次是语句覆盖、判定覆盖（分支覆盖）、条件覆盖、判定/条件覆盖、条件组合覆盖、路径覆盖。
静态测试与动态测试
- 静态测试：桌前检查，代码走查，代码审查
- 动态测试：-
- 白盒法（白盒测试的方法：语句、条件、判定、判定\条件、组合、路径）
- 黑盒法（等值划分，边界分析，因果法，功能法，错误推测）
- 灰盒法（介于白黑盒法之间）
什么是接口测试
请求模型
看下图中“A”线，可以理解为接口就是一个电灯的开关，它在接口里面给你提供了一个参数，参数的值一个是“开”，一个是“关”。
说起来，怎么才能让灯亮？一个灯头接两根线，一根线接火线，一根线接零线这时灯就亮了。反之，不接零线、火线灯就灭了。
其实接口呢，就把这些复杂的操作简化了，让你看到的就只有一个开关，而你来操作这个开关就好了。我们做接口测试也只需要测试这个开关就完成任务了，接口测试就是这么简单。
- 当你访问“http://127.0.0.1:8080/light?opt=open”，让零线、火线连通，此时灯亮。
- 当你访问“http://127.0.0.1:8080/light?opt=close”，让零线、火线断开，此时灯灭。
请求结构
看到这里我们大致就明白了接口测试是怎么一回事了。接下来需要理解一下HTTP的URL是怎么组成为一个接口的。如图：
一个URL就是一个接口：接口大致会分为一下几个部分：
请求协议：
- http — 普通的http请求
- https — 加密的http请求，传输数据更加安全
- ftp — 文件传输协议，主要用来传输文件
请求IP：就是指提供接口的系统所部署的服务器地址
请求端口：如果不填端口，默认是80，否则需要填写端口号
接口路径：指系统提供的接口在什么位置
接口参数：参数在接口路径后，用“?”来表示路径地址完了，剩下的都是参数了，用“&”来区分参数个数，
如下示例：
http://127.0.0.1:8080/light?opt=open&use=yy&pwd=123456假设要操作这个灯，需要用户密码，则可以增加新的参数”use”、”pwd”，用”&”来隔开。可以看到这个示例有3个参数：
- “opt”：”open”
- “use”: “yy”
- “pwd”: “123456”
接口HTTP参数【url看不见等隐藏参数】
http请求方式
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16GET --- 通过请求URI得到资源
POST --- 用于添加新的内容
PUT --- 用于修改某个内容
DELETE --- 删除某个内容
CONNECT --- 用于代理进行传输，如使用SSL
OPTIONS --- 询问可以执行哪些方法
PATCH --- 部分文档更改
PROPFIND (wedav) --- 查看属性
PROPPATCH (wedav) --- 设置属性
MKCOL (wedav) --- 创建集合（文件夹）
COPY (wedav) --- 拷贝
MOVE (wedav) --- 移动
LOCK (wedav) --- 加锁
UNLOCK (wedav) --- 解锁
TRACE --- 用于远程诊断服务器
HEAD --- 类似于GET, 但是不返回body信息，用于检查对象是否存在，以及得到对象的元数据http请求头
请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度。
http请求体
请求体就是请求等正文了，可以有很多种请求体。
- json格式
- xml格式
- html格式
- 二进制格式（用于图片）
- 字符串格式
看到上面的请求结构，就能接口测试了，只需要修改接口的参数，就可以像功能测试一样测了。可以用功能测试设计用例的方法来设计接口测试的用例。
一个用户接口可以通过以下4种不同方式的请求，来做不同的事情：
- 获取用户信息
- 创建用户
- 修改用户
- 删除用户
1 | 你完全可以像“灯”的那个例子，用GET请求来传递不同的参数来实现，但是这样如果接口多了，就会很混乱，很难管理。 |
这时，我们需要一种规则：
- 当用“GET”方式时，只用来获取数据，成功了返回http状态码200
- 当用“POST”方式时，只用来创建数据，成功了返回http状态码201
- 当用“PUT”方式时，只用来修改数据，成功了返回http状态码203
- 当用“DELETE”方式时，只用来删除数据，成功了返回http状态码204
- 当请求发送失败，返回http状态码400
这样子的规则，我们称它为“RESTful”标准。
下图是RESTful的状态码返回
接口测试
前面的搞清楚了，接口测试就简单了，其实就是几个步骤。
- 拿到接口的URL地址
- 查看接口是什么方式发送的
- 添加请求头，请求体
- 发送查看返回结果，校验返回结果是否正确
这个是正常的一套流程，异常的情况，就不用我多说来吧。比如参数不传值呀，传的值不正确呀，明明要求用”GET”请求发送，偏要用”POST”请求发送呀。等等有很多异常情况，一般懂功能测试都能想到很多的异常情况，这里不再举例来。
测试点与测试用例
1. 用户发送电子邮件的测试点
- 用户使用正常的输入数据来发送电子邮件
- 用户使用边界值来发送电子邮件
- 用户收到一封电子邮件后，再接着发送这封收到的电子邮件
- 用户正在发送电子邮件的过程中，同时又接收到了电子邮件
- 用户使用异常的输入数据来发送电子邮件
- 在存在网络故障的情况下发送电子邮件。
- 一个用户持续发送1000封电子邮件
- 500个用户同时发送电子邮件（稳定性测试）。
- 500个用户反复进行登录邮箱、编写邮件、发送邮件、退出邮箱操作的测试
- 用户持续（如1天、1周）发送接收邮件地址是非法输入值的邮件。
- 用户在长时间（如1天、1周）处于网络故障的情况下
- 1000个用户发送电子邮件（性能规格测试）
- 以每5分钟为一个周期，在一个周期里，前4分钟为400个用户同时发送电子邮件，后1分钟为1100个用户同时发送电子邮件，持续测试1天。
- 以每60分钟为一个周期，在一个周期里，前30分钟为1400个用户同时发送电子邮件，后30分钟为600个用户同时发送电子邮件，持续测试1天。
2. 测试点不等同于测试用例
问题1：这些测试点在内容上有重复，存在冗余。
- 例如：发送邮件测试点1和测试点4都会测试到“正确发送邮件”。
问题2：一些测试点的测试输入不明确，不知道测试时要测试哪些。
- 例如：发送邮件测试点1时，我们并不知道我们要测试哪些“正常的输入数据”。存在类似问题的测试点5.
问题3：总是在搭相似的环境，做类似的操作。
- 有些测试点之间存在一定的执行顺序，需要把这些测试点放在一起测试。例如，先执行测试点6，再紧接着执行测试点11，可以最大限度地利用之前的测试环境和测试结果。
问题4：测试点描述得太粗，不知道是不是测对了。
有些测试点写得很粗，我们不知道测试目标是什么，或是改关注哪些地方。例如，测试点4，我们不知道将“用户发送电子邮件”和“用户接收电子邮件”这两个操作放在一起，它们的“交互点”在哪里？我们需要发送特殊的电子邮件，还是随便发送一篇就可以了？这使得测试人员可能会漏掉一些关键内容，测不到点子上。
3. 测试点是测试者在测试时需要关注的地方
虽然我们在分析测试点时，会使用各种测试方法，但这些方法在思路和操作上都是不同的，一些方法得到的测试点要细一些、具体一些，一些方法得到的测试点粗一些、泛一些是非常正常的。另外，谁也不能保证这些测试点之间不会重复或是相互包含。
4. 测试用例是在测试点“加工”的基础上得到的
首先把测试点“去重”（去掉重复的内容）、“合并”（把太细的测试点合并起来）、“细化”（把太泛的测试点说清楚、说具体），然后再确定各个测试点的测试条件、测试数据和输出结果。如果说测试带你还只是一些散乱的测试思路的集合，那么测试用例就是一份真正能够指导测试的测试说明书。
5. 测试点设计及编写思路
在测试点设计的时候，需要思考如下几点：
测试操作的难度；
测试操作包括环境、配置、执行等因素，在测试设计时，尽量减小操作的难度。
重要性及优先级；
测试点一定要区分重要性及优先级，以便在实际项目测试中进行选择。重要性部门建议突出内部测试、外部验收、线上问题等标签，便于管理和分类更新。
自动化可实现性；
测试点一定要考虑自动化实现的难易度，因为自动化是提高测试效率的关键；在此还有一个问题需要注意，那就是自动化按照测试点设计要求的实现程度，如果不能100%按照预期要求进行覆盖的话，可能会遗漏非常重要的测试部门，这时候最好拆分成两个测试点。
真实场景的需求及模拟；
测试点在编写的过程中，一定要考虑真实使用场景，这会非常的高效，场景模拟本来就是测试点编写的重要方法之一。
层次分明（点、面、体），切勿大小用例及测试模块混淆；
测试点分类中注意区分所属模块和层级，层级中注明基本测试点、高级测试点和系统测试点，这个可以根据项目的具体进行区分。
用例编写策略一致性，简单、明了、直接，最好不要超过8步；
好的测试用例一定是非常清楚的，执行步骤不超过8步，这个在测试点和测试用例的设计中一定要注意；执行步骤太长，不利于问题的定位分析。
测试配置的复用；
所有的测试设计，最终都是为了执行，执行的时候有很多的配置，这些配置能否复用是非常关键的，直接关系到执行的效率。
测试用例的维护和管理；
测试用例的维护和管理历来都是非常重要的问题，如何维护用例的基线，如何不断的调整和更新，如何不断的优化和改进，都是极其重要的。
测试用例评审；
测试用例必须要评审，以听取多方面的意见，为了提高评审的效率，建议先内部评审，之后在项目组内部评审，听取相关人的评审建议（以测试点讲解为主，且重点是研发可能关注的用例，这个需要提前判断）。
必须经过长期的大量的积累，才能写出高质量的用例；
用例编写从来都不是一件易事，需要相当多的积累和大量的反复练习。
测试点设计三步走
测试点最好一次性设计完成，之后不断修改和完善，根据经验，设计主要分为三步，每一步都有其不同要求，在项目测试执行阶段的侧重点也有不同，下面简单介绍下思路。
第一步：以“点”为主；
点阶段是项目测试前期执行中的最小单元，这个阶段测试点的设计及执行有几个要求：
- 测试点设计要简单、独立、明确、减少与其它点的交叉；
- 测试点设计的范围局限于单个模块内部；
- 测试点设计以功能验证为主，性能指标、可靠性、可用性等暂不涉及；
- 测试点设计以正向测验为主，异常测试及复杂场景模拟先不考虑；
- 测试点执行时的策略：优先选择简单、执行难度小、功能最核心的指标，尽早暴露问题；
- 项目前期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部基本功能测试；
第二步：以“面”为主；
面阶段是项目测试中期执行中的单元，这个阶段测试点的设计及执行有几个特点：
- 测试点设计要稍微复杂些，考虑单模块内部的异常和复杂场景；
- 测试点设计的范围不仅包括单模块的复杂设计要求，还包括模块间的接口测试；
- 测试点设计以功能验证为主，单模块及模块间的性能指标、可靠性、可用性可以涉及；
- 测试点设计以正向测验为主、异常测试及复杂场景模拟为辅；
- 测试点执行时的策略：优先选择功能最核心的指标，必要的性能和异常场景，尽早暴露问题；
- 项目中期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是模块内部高级功能和性能测试，模块间的接口测试；
第三步：以“体”为主；系统、性能和异常模拟
- 测试点设计要复杂些，考虑被测系统多模块/全模块内部的功能、性能、稳定性、可用性、可靠性等指标的测试；
- 测试点设计的范围不仅包括被测系统多模块/全模块级别的测试，还包括系统与外界环境的兼容性、真实场景模拟等；
- 测试点设计以被测系统多模块/全模块功能验证为主，其次是性能指标，最后是可靠性、可用性、可升级性等指标；
- 测试点设计以被测系统多模块/全模块的正向测验，功能性能全部通过之后是异常测试及复杂场景模拟；
- 测试点执行时的策略：优先选择被测系统多模块/全模块的功能、性能最核心测试指标，必要的可靠性和异常场景模拟，尽早暴露问题；
- 项目后期执行策略：根据项目实际情况，灵活安排各种测试资源、问题反馈、进度把控等；重点是被测系统多模块/全模块的功能和性能测试，各种稳定性、可靠性测试等；
总之，测试点的设计绝非易事，需要在多种因素下分步骤进行，在测试执行过程中，也需要灵活选择相应的测试点，把控项目测试进度和质量。
常见问题：
8、结合你以前的学习和工作经验，你认为如何做好测试
根据我以前的工作和学习经验，我认为做好工作首先要有一个良好的沟通，只有沟通无障碍了，才会有好的协作，才会有更好的效率，再一个就是技术一定要过关，做测试要有足够的耐心，和一个良好的工作习惯，不懂的就要问，实时与同事沟通这样的话才能做好测试工作。
11、根据你的经验说说你对软件测试/质量保证的理解
软件质量保证与测试是根据软件开发阶段的规格说明和程序的内部结构而精心设计的一批测试用例(即输入数据和预期的输出结果)，并根据这些测试用例去运行程序，以发现错误的过程。它是对应用程序的各个方面进行测试以检查其功能、语言有效性及其外观排布。
12、软件测试的流程是什么？
需求调查：全面了解系统概况、应用领域、软件开发周期、软件开发环境、开发组织、时间安排、功能需求、性能需求、质量需求及测试要求等。根据系统概况进行项目所需的人员、时间和工作量估计以及项目报价。
制定初步的项目计划。
测试准备：组织测试团队、培训、建立测试和管理环境等。
测试设计：按照测试要求进行每个测试项的测试设计，包括测试用例的设计和测试脚本的开发等。
测试实施：按照测试计划实施测试。
测试评估：根据测试的结果，出具测试评估报告。
15、怎样写测试计划和测试用例
简单点，测试计划里应有详细的测试策略和测试方法，合理详尽的资源安排等，至于测试用例，那是依赖于需求(包括功能与非功能需求)是否细化到功能点，是否可测试等。
20、描述测试用例设计的完整过程？
1、需求分析 + 需求变更的维护工作；
2、根据需求得出测试需求；
3、设计测试方案，评审测试方案；
4、方案评审通过后，设计测试用例，再对测试用例进行评审；
21、单元测试的策略有哪些？
逻辑覆盖、循环覆盖、同行评审、桌前检查、代码走查、代码评审、景泰数据流分析
