环境搭建思路/测试流程

• 1.软件测试环境搭建
• • 1.1 搭建测试环境前
  • 1.2 环境搭建模式
  • 1.3 测试环境建设思路
• 2.测试过程
• • 2.1 测试策划过程
  • • 2.1.1 需求分析
    • 余额宝需求测试实战
    • 2.1.2 测试策略
    • 2.1.3 测试方案设计
    • 2.1.4 测试方案评审

是看着课程听的，做的课程的随堂笔记
课程的链接如下：
https://coding.imooc.com/class/411.html

1.软件测试环境搭建

思考：
在什么条件下做软件测试br> 怎么做软件测试/p>

1.1 搭建测试环境前

确定测试目的
功能测试（验证软件是否满足用户的需求），稳定性测试，还是性能测试（软件的效率），测试目的不同,搭建测试环境时应注意的点也不同。

例如：
1.功能测试：不需要大量的数据，需要覆盖率高，测试数据要尽量真实；
性能测试：需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置；（比如对于app在当一千万个用户同时访问的时候能否应付）

2.

3.了解测试及用户使用的硬件配置

4.（万一产生冲突可能会闪退或者别的错误，所以要避免和用户常用软件配置冲突。）

5.（举例就是对外的app或者 页，即不管什么手机装了什么软件都能使用我的软件）

6.营造，不同人员和项目不要对当前测试产生影响（希望我们的测试不要因为其他人员，项目而改变。比如我现在做的测试，万一开发也能看到他改动了，对我的测试就会有影响。）

7.构建
通过备份或数据隔离的方式。
重复运用一套测试环境进行多版本多时间段的测试。

1.2 环境搭建模式

线下搭建：在公司本地进行搭建

例如：
对于搭建java环境：
配置java环境(下载jdk并配置环境变量)
下载并安装中间件(tomcat、 jetty或其他)
安装数据库并导，入初始化脚本

线上搭建：
Docker模式（我把我的环境，想要的东西封到一个大盒子里，然后想用的时候就把盒子扔出去，盒子就直接构建出环境。）
构建自己的image镜像，然后执行deploy

依赖第三方平台：
比如一个云环境，上面有可以使用的虚拟机，数据库等，自己按需组合即可
eg.蚂蚁金融云

进行

确定需要测试的内容或质量特征

明确测试的充分性要求

提出

测试策划需要进行：

确定

进行 分析与评估

根据上述分析结果制

根据测试计划开展相应的

2.1.1 需求分析

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

测试在需求分析阶段加入的原因

1.测试工程师参与需求分析， 减少与开发人员的交互，节省时间（针对一些功能，测试需要在初期和开发人员来进行沟通）
2.早期确定测试用例的编写思路，
3.可以 （产品可能会更了解用户的需求和掌握更多的数据，所以早一点可以获取一些测试数据）
4.可以 ，降低测试成本（违反正常的操作准则等 可以提早发现，避免更多的回炉重造。）

需求测试的作用：
1.测试需求的分析用来确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础。
2.被确定的测试需求项必须是可核实的，测试需求必须有一个可观察、可评测的结果。
3.如果无法核实的需求就不是测试需求。
4.测试需求分析还包括与客户的交流以澄清某些混淆
5.明确哪些需求更重要
6.确保风险承担者尽早对项目达成共识
7.对将来的产品有清晰的认识
8.测试需求是制订测试计划的基本依据
9.测试需求是设计测试用例的指导
10.确定了要测什么、测哪些方面才能有效设计用例

需求验证：
◆审查需求文档
◆对需求文档及相关模型进行仔细检查
◆另外在需求开发期间所做的非正式评审也是有所裨益的

应当这样做：

编写用户手册
在需求开发早期即可起草一份浅显易懂的用户手册，用以描述出所有对用户可见的功能并用它作为需求规格说明的参考并辅助需求分析

确定合格的标准：
让用户描述什么样的产品才算满足他们的要求和适合他们的使用
将确认合格的测试建立在使用情景描述或使用实例的基础之.上

余额宝需求测试实战

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.测试限制:
在测试环境中br> 9.测试:
在测试或计划测试过程中由于时间安排、测试限制、优先级分布可能带来的测试风险考量

2.1.4 测试方案评审

如果不进行测试方案的评审，会造成严重后果：
仅从文档、沟通获取信息，可能会造成信息不对称，认识片面，理解错误或不深入等问题
缺少同行交叉评审和开发评审机制，无法充分发挥集体智慧,个人的思维难以突破，可能会出现测试遗漏的情况

测试评审的目的：
呈现测试的工作
（比如发红包这个操作，对于开发来说：钱到了账上 就算操作完成；对于测试：用户是否有不想要这个红包的需求）
碰撞出火花，借鉴被人的思考方式
培养这样的行为模式:愿意为团队或他人出谋划策
发挥最大限度发挥个人的经验，特长，实现技能互补.

评审重点:
（比如我认为这个项目不需要用性能测试，但是有可能他需要）

（比如现在做一个加法计算器，验证它是否选取，不可能输入所有的数据，那么选取那些数据为什么选取就是需要评审的）
（在淘宝中如何进行购买商品的流程）
（比如在淘宝上买了新手机，评估下单后数据库的接口，数据等是否正常）
及模拟数据的方法（比如预言双十一的活动，那么需要模拟多少数据多少下单量来制定方案）
基于（当克服不了风险的时候需要批漏出来）