环境搭建思路/测试流程
1.软件测试环境搭建
思考：
在什么条件下做软件测试？
怎么做软件测试？
1.1 搭建测试环境前
确定测试目的
功能测试（验证软件是否满足用户的需求），稳定性测试，还是性能测试（软件的效率），测试目的不同,搭建测试环境时应注意的点也不同。
例如：
1.功能测试：不需要大量的数据，需要覆盖率高，测试数据要尽量真实；
性能测试：需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置；（比如对于app在当一千万个用户同时访问的时候能否应付）
2.测试的软件环境要尽可能模拟真实的环境，选用合适的操作系统和软件。（比如有的用户用ios系统，有的用安卓系统）
3.了解测试软件运行的最低要求及用户使用的硬件配置
4.了解用户常使用的软件，避免我们做的软件配置与其相冲突（万一产生冲突可能会闪退或者别的错误，所以要避免和用户常用软件配置冲突。）
5.产品化的测试需要考虑兼容性测试（举例就是对外的app或者网页，即不管什么手机装了什么软件都能使用我的软件）
6.营造独立的测试环境，不同人员和项目不要对当前测试产生影响（希望我们的测试不要因为其他人员，项目而改变。比如我现在做的测试，万一开发也能看到他改动了，对我的测试就会有影响。）
7.构建可复用的测试环境
通过备份或数据隔离的方式。
重复运用一套测试环境进行多版本多时间段的测试。
1.2 环境搭建模式
线下搭建：在公司本地进行搭建
申请独立测试服务器或者虚拟机
测试环境配置
测试项目导入
例如：
对于搭建java环境：
配置java环境(下载jdk并配置环境变量)
下载并安装中间件(tomcat、 jetty或其他)
安装数据库并导，入初始化脚本
线上搭建：
Docker模式（我把我的环境，想要的东西封到一个大盒子里，然后想用的时候就把盒子扔出去，盒子就直接构建出环境。）
构建自己的image镜像，然后执行deploy
依赖第三方平台：
比如一个云环境，上面有可以使用的虚拟机，数据库等，自己按需组合即可
eg.蚂蚁金融云
1.3 测试环境建设思路
考虑点:
用途、使用成本、维护成本
基本架构:
研发环境:用于研发自测、集成测试（基于研发使用的环境，他自己可以进行自调）
测试环境:用于日常单系统或两两微服务之间测试，可同时集成自动化测试回归
联测环境:
完备环境，用于大型联测。
（整体的联测涉及到所有的业务流，接口等，所以要一个非常完备的环境）
外联环境(如果有需求) :
稳定版本环境，用于外部商户等联调
灰度/沙箱环境：
用于生产数据测试，仿真测试。
仅仅在测试中自己造数据可能会遗漏，所以引入生产数据
（灰度 生产验证等；沙箱 数据查询 生产数据，生产文件校验等）
2.测试过程
在逻辑上。测试活动是按顺序进行的
但是实际测试过程中，这些活动是可以重叠或同时进行的（比如支付宝的加好友，登录，转账等。对于加好友模块的测试，还是需要先登录这个模块的操作的）
2.1 测试策划过程
测试策划分为以下三个部分：
测试策划步骤：
进行 测试需求的分析
确定需要测试的内容或质量特征
明确测试的充分性要求
提出 测试的基本方法
测试策划需要进行：
确定 测试的资源和技术需求
进行 风险分析与评估
根据上述分析结果制 定测试计划
根据测试计划开展相应的 测试控制活动
2.1.1 需求分析
过往的软件生命周期中，需求分析阶段是没有测试人员参与的。但随着软件过程的优化， 测试人员的加入对需求分析阶段有了更大的作用。
测试在需求分析阶段加入的原因
1.测试工程师参与需求分析， 对需求了解很深刻，减少与开发人员的交互，节省时间（针对一些功能，测试需要在初期和开发人员来进行沟通）
2.早期确定测试用例的编写思路， 为测试打好了基础
3.可以 获取一些测试数据，为测试用例设计提供帮助（产品可能会更了解用户的需求和掌握更多的数据，所以早一点可以获取一些测试数据）
4.可以 发现需求不合理的地方，降低测试成本（违反正常的操作准则等 可以提早发现，避免更多的回炉重造。）
需求测试的作用：
1.测试需求的分析用来确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础。
2.被确定的测试需求项必须是可核实的，测试需求必须有一个可观察、可评测的结果。
3.如果无法核实的需求就不是测试需求。
4.测试需求分析还包括与客户的交流以澄清某些混淆
5.明确哪些需求更重要
6.确保风险承担者尽早对项目达成共识
7.对将来的产品有清晰的认识
8.测试需求是制订测试计划的基本依据
9.测试需求是设计测试用例的指导
10.确定了要测什么、测哪些方面才能有效设计用例
需求验证：
◆审查需求文档
◆对需求文档及相关模型进行仔细检查
◆另外在需求开发期间所做的非正式评审也是有所裨益的
应当这样做：
以需求为依据编写测试用例：
编写用户手册
在需求开发早期即可起草一份浅显易懂的用户手册，用以描述出所有对用户可见的功能并用它作为需求规格说明的参考并辅助需求分析
确定合格的标准：
让用户描述什么样的产品才算满足他们的要求和适合他们的使用
将确认合格的测试建立在使用情景描述或使用实例的基础之.上
余额宝需求测试实战
以支付宝上余额宝业务为例分析
1.原始需求:
早在2012年左右，支付宝虽然很快被大众接受,但是却面临着一种比较普遍的现象:支付宝账户余额内总是有一 笔闲置资金，虽然不同账户资金数额有多有少，但总的来说，这笔躺在账户什么做不了的闲置资金数额还是比较庞大的，对于支付宝的发展而言非常不利
2.产生需求：
于是，产生了这样一个需求，与基金公司合作推出货币基金产品，同时用户购买货币基金后，可直接通过货币基金金额进行支付购买商品或服务。
货币基金可以视同余额、集分宝一样作为支付工具进行消费。
3.审查需求文档：
我们一起简单看下需求文档，大概分为以下：
需求分析
流程图
文字流程
约束条件
扣款的优先级
异常处理
安全控制
页面
需求分析过程中我们会将上面的流程分为:
货币基金购买、提现、消费、资产管理、交易查询几部分
可以通过需求规格说明书检查列表进行检查
2.1.2 测试策略
测试之前需要考虑的问题：
你知道要测试的系统是干什么的吗?
你了解系统有些什么特点吗?
系统有些什么功能?
系统哪些部分需要测试?哪些不要测试?
系统对性能有什么要求?
系统对安全性有什么要求?
由以上问题可以得出测试策略的要求：
测试策略是描述测试项目和测试任务之间的关系。
它用来说明要测什么，如何测，如何协调测试资源和测试时间等。
测试策略要素：
1.测试安排、发布计划
罗列测试项目本身重要的里程碑
每个里程碑都需要有明确的结束时间，这个时间可以指导我们后续的测试
2.测试时间
如果测试时间安排不足，我们就可以在后续的测试范围中挑选优先级比较高的特性来执行测试
这样可以最大限度的保证产品的质量
3.测试范围（按照优先级排列）
分为In Scope和Out Of Scope（分为在范围内和范围外）
需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
对于在测试范围中的模块，需要给出优先级，以便相应测试时间不足的情况
对于不在测试范围中的模块，需要给出原因
4.测试资源
测试资源在测试策略中也是很重要的一环，它分为人力和工具两部分
人力资源主要说明参与测试的人员，当然可以包括很多的角色，如专业测试人员，客户，产品经理等
工具即可能用到的其他软件
5.测试环境
测试环境主要包括推荐环境解决方案，操作系统要求，软硬件要求
对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖
比如测试项目对JAVA有依赖，推荐版本可能就是1.7
6.测试方法
测试方法的罗列主要是为了说明针对测试项目我们要开展哪些类型的测试
功能测试是必须的，非功能测试是可选的
7.文档管理
对于一个完整的产品来说，文档是很重要的一环，它一般包括安装、升级文档，用户指南等
文档不单单是一个文件，已经是软件的一部分，所以需要完成测试才能发给用户，以免文档不正确误导用户从而使他们对测试项目失去信心。
8.风险管理
风险管理模块需要罗列出来现在已知的可能会出现不确定性的因素（比如我们这个公司的技术没法达到用户的要求，比如同时有3亿人来访问某个app）
这些因素可能来自技术，资源或者其他方面的（对于需要的软件，有可能非常贵，公司负担不起，或者需要和银行对接才能测试成功，但是有可能无法和银行对接）
2.1.3 测试方案设计
测试策略:
侧重需求分析，评估风险，定义测试范围
确定测试方法，制定测试启动、停止、完成标准和条件
测试计划:
制定项目 测试过程中的测试重点
各个阶段的任务分配以及时间进度安排
并提出对各项任务的评估，风险分析，可以包括测试策略
测试方案:
侧重测试的方法，测试环境的规划
测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案
测试策略VS测试计划VS测试方案
◆实际实施过程中，往往存在这样类似的方式:
◆ 测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案
◆ 测试计划=测试策略+测试任务分配+时间进度安排
货币基金消费测试方案分析过程
1.分析需求:
当前测试包含需求项(需求文档或wiki链接等)
2.测试计划(里程碑)及负责人:
整理当前项目各模块测试负责人、任务分配及测试时间安排
3.测试范围、测试重点:
那些point需要测试， 重点放在什么地方，优先级安排
4. 策略及工具: 是否需要进行自动化、性能、安全测试?使用哪些工具.
5. 测试用例设计方法:
使用什么样的黑盒测试方法进行设计(等价类?边界值?因果图?等等)
6. 测试环境:
测试环境是什么?需要哪些服务器、数据库，配置如何等
7.联调测试:
是否需要与第三方或其他部门进行联调?何时开展?联调包括哪些功能?例如基金公司
8.测试限制:
在测试环境中哪些内容无法测试?
9.测试风险:
在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量
2.1.4 测试方案评审
如果不进行测试方案的评审，会造成严重后果：
仅从文档、沟通获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题
缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧,个人的思维难以突破，可能会出现测试遗漏的情况
测试评审的目的：
呈现测试的工作
与开发达成共识.（比如发红包这个操作，对于开发来说：钱到了账上 就算操作完成；对于测试：用户是否有不想要这个红包的需求）
不同的思维方式碰撞出火花，借鉴被人的思考方式
培养这样的行为模式:愿意为团队或他人出谋划策
发挥团队协作，最大限度发挥个人的经验，特长，实现技能互补.
评审重点:
采用的测试方法（比如我认为这个项目不需要用性能测试，但是有可能他需要）
等价类划分的依据
测试数据的选取和准备方法（比如现在做一个加法计算器，验证它是否选取，不可能输入所有的数据，那么选取那些数据为什么选取就是需要评审的）
流程测试的路径组合（在淘宝中如何进行购买商品的流程）
数据比对选取的对象和检查点（比如在淘宝上买了新手机，评估下单后数据库的接口，数据等是否正常）
是否需要模拟数据及模拟数据的方法（比如预言双十一的活动，那么需要模拟多少数据多少下单量来制定方案）
基于风险的测试取舍（当克服不了风险的时候需要批漏出来）
