软件测试流程

软件测试环境

确定测试目的
功能测试、稳定性测试，还是性能测试，测试目的不同，搭建测试环境时应注意的点也不同
功能测试：不需要大量的数据，需要覆盖率高，测试数据要求尽量真实
性能测试：可能需要大量存量数据或者实际硬件环境极可能相似的硬件配置（数据量大才能保证模拟效果）

测试的软件环境极可能的模拟真实环境
尽可能的模拟用户使用环境，选用何使的操作系统和软件平台
了解符合测试软件运行的最低要求及用户使用的硬件配置
了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间（考虑到软件可能会与其他软件互斥，发生冲突，导致闪退等）
产品化的测试则需要考虑兼容性的方案

搭建独立的测试环境
不同的项目、不同的公司会对测试环境的独立性有不同的要求
测试过程中金量保证测试环境独立，不会收到其他测试人员以及项目研发人员的影响

构建可复用的测试环境
通过备份或数据隔离的方式
重复运用一套测试环境进行多版本多时间段的测试（同一套环境进行不同内容的测试）

线下搭建
独立测试服务器或虚拟机（公司自己搭建）
测试环境配置（比如装个eclipse、自动化测试工具）
测试项目导入

测试环境配置
配置java环境（下载jdk并配置环境变量）
下载并安装中间件（tomcat、jetty或其他）
安装数据库并导入初始化脚本

Docker模式
构建属于自己的 image
一键deploy

依赖第三方平台
如蚂蚁金融云

测试环境的建设落地

环境建设思路

**考虑点：用途、使用成本、维护成本
基本架构：
研发环境：用于研发自测、集成测试（研发联调测试），由研发人员维护
测试环境：用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归
联调环境：完备环境，用于大型联调测试，涉及多个系统的联合测试
外联环境（如果有需求）：稳定版本环境，用于外部商户等联调
（如外部调用 API）
灰度/沙箱环境：用于生产数据 **测试，仿真测试

测试过程

在逻辑上，测试活动是按顺序进行的。在实际测试过程中由于模块是分开提交上来的，因此这些活动是可以重叠或同时进行的。

测试策划过程

1、测试需求，进行测试需求的分析
2、测试计划，明确需要测试的内容或质量特征，明确测试的充分性要求
3、测试控制，提出测试的基本方法

确定测试的资源和技术需求（功能测试？性能测试?稳定性测试？）
进行风险分析与评估（由于哪方面的内容导致测试结果偏差，结果可行性低）
根据上述分析结果制定测试计划
根据测试计划开展相应的测试控制活动

测试控制只要由测试经理把控，经验多了知道那个阶段需要重点测试

需求测试

过往的软件生命周期中，需求分析阶段是没有测试人员参与的。但随着软件过程的优化，测试人员的加入对需求分析阶段有了更大的作用。

需求分析的作用具体体现在：
1、测试工程师参与需求分析，对需求了解很深刻，减少与开发人员的交互，节省时间。测试阶段只需要看代码输入输出是否符合需求即可
2、早期确定测试用例的编写思路，为测试打好了基础
3、可以获取一些测试数据，为测试用例设计提供帮助
4、可以发现需求不合理的地方，降低测试成本
5、测试需求的分析用来确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础
6、被确定的测试需求项必须是可核实的，测试需求必须有一个可观察、可评测的结果
7、如果无法核实的需求就不是测试需求
8、测试需求分析还包括与客户的交流以澄清某些混淆
9、明确哪些需求更重要，对需求优先级划分
10、确保风险承担着今早地对项目达成共识
11、并对将来的产品有个清晰的认识（从客户方需求方全面的了解认识产品）
12、测试需求是制定测试计划的基本依据
13、测试需求是设计测试用例的指导
14、确定了要测什么、测哪些方面才能有效设计用例

需求测试的步骤

1、审查需求文档
对需求文档及相关模型进行仔细检查
另外在需求开发期间所做的非正式评审也是有所裨益的
2、以需求为依据编写测试用例
编写用户手册，用户手册不会很复杂
在需求开发早起即可起草一份浅显易懂的用户手策，用以描述出所有对用户可见的功能并用它作为需求的规格说明的参考并辅助需求分析
3、确定合格的标准
让用户描述什么样的产品才算满足他们的要求和适合他们的使用
将确认合格的测试建立在使用情景描述或使用实例的基础之上

需求规格说明书检查列表
1、需求规格说明书需要覆盖用户所有的需求项
2、需求规格说明书是项目以来产生的第一个产物
NA 是无须，不需要

测试策略

测试策略当作是测试方案前的一个思考，也是测试计划的一个部分。

思考：
你知道要测试的系统是干什么的吗？
你了解系统有些什么特点吗？
系统有些什么功能？
系统哪些部分需要测试？哪些不要测试？
系统对性能有什么要求？
系统对安全性有什么要求？
。。。。。。

测试策略是描述测试项目和测试任务之间的关系。用来说明要测什么，如何测，如何协调测试资源和测试时间等。
测试策略制定得是否合理高效会对测试项目的进度产生很大的影响。

如何制定一个好的测试策略并且能防止遗漏呢？——>策略要素

测试安排、发布计划
罗列测试项目本身重要的里程碑
每个里程碑都需要有明确的结束时间
这个时间可以指导我们后续的测试
如果测试时间安排不足，我们就可以在后续范围中挑选优先级比较高的特性来执行测试
这样可以最大限度的保证产品的质量

测试范围（按优先级排列）
分为 In Scope 和 Out Scope，需要说明哪些模块实在测试范围中的，哪些是本阶段测试不考虑的
对于在测试范围中的模块，需要给出优先级，以便相应测试时间不足的情况，对于不在测试范围中的模块，需要给出原因

测试资源
测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分
人力资源主要说明参与测试的人员，当然可以包括很多的角色，如专业测试人员，客户，产品经理等
工具主要是指可能用到其他软件（如自动化，selenium等）

测试环境
测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求
对于推荐解决方案，需要陈述的是测试项目对其他软件的依赖（比如测试项目对JAVA有依赖，推荐的版本可能是JDK1.7）

测试方法
测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试
其中功能测试是必须的，非功能测试是可选的

文档管理
对于一个完整的产品来说，文档很重要
一般包括安装、升级文档，用户指南，测试用例等
他需要经过完整的测试才能发布给客户
差的文档很可能会误导用户，从而使他们对测试项目失去信心

风险管理
风险管理模块需要罗列处理现在已知的可能会出现不确定性的因素，这些因素可能来自技术，资源或者其他方面的（比如需要联合其他企业才能完成的测试等等）

测试计划与测试方案

测试策略

定义：侧重于需求分析，评估风险，定义范围
用于确定测试方法，制定测试启动、停止、完成标准喝条件

测试计划（什么时候做）

定义：制定项目测试过程中的测试重点
各个阶段的任务分配以及时间进度安排
并提出对各项任务的评估，风险分析，可以包括测试策略，即测试计划包括了测试策略被

测试方案（如何做）

定义：侧重测试的方法，测试环境的规划
测试工具的设计喝选择，测试用例的设计方法，测试代码的设计方案

在实际项目实施中，测试方案=测试计划 + 用例设计方案 + 工具选择 + 自动化 / 性能测试具体方案

测试计划 = 测试策略 + 测试任务分配 + 时间进度安排

测试方案分析过程：

测试方案评审

如果没有对测试方案进行评审，仅从文档、沟通获取信息，可能会造成信息不对称，认识片面等。缺乏评审，可能会出现遗漏。

评审目的：
1、呈现测试的工作 2、与开发达成共识 3、不同的思维方式碰撞出火花，借鉴被人的思考方式 4、培养这样的行为模型：愿意为团队或他人出谋划策 5、发挥团队协作

评审重点：
1、采用的测试方法
2、等价类划分的依据
3、测试数据的选取和准备方法
4、流程测试的路径组合
5、数据比对选取的对象和数据检查点的选择
6、是否需要模拟数据及模拟数据的方法
7、基于风险的测试取舍