功能测试笔记PART1测试理念

软件分类：

系统软件：负责管理计算机系统中各自独立的硬件，使得他们可以协调工作。

应用软件：为了某种特定的用途而被开发的软件，它可以是一个特定的程序，比如一个浏览器，也可以是一组功能联系紧密，可以互相协作的程序的集合。

软件生命周期：

 问题定义（确定好要解决的问题）→可行性研究（该问题是否可以解决）→需求分析→概要设计→详细设计→编码和单元测试→综合测试→软件维护

文档：

需求分析文档 概要设计文档 详细设计文档（包含使用的方案，架构，体系，同时还包含接口名称、调用方式，数据库结构、落库结构、数据样式） 测试设计文档（测试方案，需要包含哪些方面，哪些方面，哪些功能点，是否交互，交互是否使用联合测试） 测试用例（测试依据，针对一个系统/功能点测试时的一个规范条文） 测试报告（包含测试用例，多少个bug，修复多少，失败多少等）

软件测试的目的：

软件测试目的在于发现问题，检查系统是否满足需求。

软件测试方法和分类

 生命周期各测试方法对比：

常见术语：

C/S： C：客户端Client，S服务器端Server，这种软件是基于局域网或互联网的，需要一台服务器来安装服务器软件，每台客户端都要安装客户端软件。比如QQ，游戏等数据C/S结构。

B/S：B 浏览器Browser，S指服务器，不需要安装客户端，只要有浏览器就可以i直接使用，比如Sina sohu，B/S结构软件是主流，便于升级和维护，是测试重点。

APP

缺陷Bug/Defect：指软件中（包括程序和文档）不符合用户需求的问题

测试环境： 测试环境=软件+硬件+网络

测试用例Test Case： 测试执行之前设计的一套详细的测试方案，包括测试环境，测试步骤，测试数据和预期结果

测试用例=输入+输出+测试环境；“输入”包括测试数据和操作步骤，“输出”指期望结果，“测试环境”指系统环境设置。

冒烟测试 Smoke Testing：

在对一个新版本进行系统大规模地测试之前，先验证一个软件的基本功能是否实现，是否具备可测性。

如：该版本上线购物功能，购物流程是否能走完。

α测试：

验收测试的一种，指的是由用户、测试人员、开发人员等共同参与的内部测试。

β测试：

验收测试的一种，指的是内测后的公测，即完全交给最终用户测试。比如游戏删档公测。

软件测试常见模型：

V模型：

W模型：研发线和测试线

H模型：测试完全独立出来，各阶段可以反复触发迭代增量，将测试准备活动和执行活动清晰的体现。

X模型：

 

 

项目进程 ：

编程阶段：单元 白盒- 测试参与

编程完成-开发联调 ：集成测试 -开发为主

提测-冒烟测试（自动化为主，手工为辅）-测试执行

测试阶段-系统测试（黑盒功能测试为主，自动化/接口测试为辅，根据项目进行性能、安全测试）

验收阶段-验收测试-测试配合用户需求

软件测试概念：

经典定义：软件测试，在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。

标准定义：软件测试是使用人工或者自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

测试覆盖率：

覆盖率是用来度量测试完整性的手段，同时也是测试技术有效性的度量。

覆盖率=（至少被执行一次的item数）/item总数

黑盒测试： 

需求覆盖=（被验证的需求数量）/（总需求数量）一般要求100%

用例覆盖=（验证通过的用例数量）/（总用例总数） 80%以上

简单的测试覆盖率=本次测试执行的用例数/所有用例数

基于产品的测试覆盖率=已测需求点/设计所有需求数

以产品、需求维度统计，无论大型或者小需求迭代都要求覆盖率100%

白盒测试：

大多工具判断语句覆盖，即单元测试代码覆盖代码行/总代码行 要求80%以上

缺陷：仅能代表测试过哪些代码，不能代表是否测试好这些代码，容易遗漏逻辑判断等场景

基于自动化的测试覆盖率：

自动化覆盖的测试场景（测试用例）/所有测试场景（用例）

用户80%的时间在使用20%的功能，自动化测试用例选择着重于20%的核心功能

用途：自动化测试更着重于回归验证，没必要追求过高覆盖率，而要考虑用例设计

测试覆盖率的最终意义

应用最多的地方在测试停止标准

单纯讨论测试覆盖率，在瀑布式开发模型中并不重要，但在螺旋式、敏捷开发模型中，由于不断迭代累加，很难确定哪些模块在开发过程中没有给予足够的测试。

在短迭代、DevOps中，更强调单元测试覆盖率来评估不断增加的代码数量

 

软件测试人员需要的知识体系

• 软件测试基础知识
• 软件测试流程
• 测试用例设计方法
• 兼容性测试/易用性测试
• 缺陷管理
• 测试工具使用
• 测试文档编写

具备的素质：踏实细心、积极主动、好奇心、交流能力、自我提高和总结、责任感……

测试原则：

原则1：所有的测试都应追溯到用户需求

原则2：尽早启动测试工作

原则3：Pareto法则应用于软件测试，28效率法则，在分析设计实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找到其余缺陷中的80%，最后4%的缺陷可能只有在用户的大范围长时间使用后才会暴露出来。

原则4：穷尽测试是不可能的

原则5：杀虫剂怪事。即软件测试越多，其对测试的免疫力越强。

原则6：前进两步，后退一步。

测试中一个基本问题为：缺陷修复总会以20-50%的机率引入新的缺陷。每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以隐蔽的方式被破坏。

原则7：三心二意

细心信心耐心  团队合作的沟通意识 时刻保持怀疑的态度且有缺陷预防意识

软件测试规范：

ISO9000 和 CMM 

ISO9000：

控制思想，即对产品形成的全过程，从采购原材料、加工制造到最终产品的销售、售后服务进行控制。

预防思想

CMM：

对软件企业的评估从初始级开始，共分5级。CMM是专门为软件开发组织设计的，侧重于软件开发和改进过程，在产品的设计和开发细节做了较多要求。

测试系统主要由6各相互关联，相互作用的过程组成：

测试管理、资源管理、配置管理、测试设计、测试规划、测试实施。

测试过程中一般会从一下几个方面入手来规范过程：

 

 

搭建测试环境

搭建环境前：

1、确定测试目的。

功能测试、稳定性测试还是性能测试，测试目的不同，搭建测试环境时注意的点也不同。

功能测试：不需要大量的数据，需要覆盖率搞，测试数据要求尽量真实。

性能测试：可能需要大量存量数据或者与实际硬件环境尽可能相似的硬件配置。

2、测试的软件环境尽可能的模拟真实环境。

尽可能模拟用户使用环境，选用合适的操作系统和软件平台。

了解符合测试软件运行的最低要求及用户使用的硬件配置。

了解用户常用的软件，避免所有配置所有操作系统下都要进行测试，没有侧重点，浪费时间。

产品化的测试则需要考虑兼容性方案。

3、营造独立的测试环境

不同的项目、公司会对测试环境的独立性有不同的要求。

测试过程中尽量保证测试环境独立，不会受到其他测试人员以及项目研发人员的影响。

4、构建可复用的测试环境

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

5、搭建测试环境过程分析

线下搭建

• 独立测试服务器或虚拟机
• 测试环境配置
• 测试项目导入

测试环境配置

配置java环境（下载jdk并配置环境变量）

下载并安装中间件（tomcat、jetty或其他）

安装数据库并导入初始化脚本

Docker模式 把自己想要的环境封装在一个盒子里，想用的时候随时可以用。

构建属于自己的image

一键deploy

依赖第三方平台（蚂蚁金融云、阿里金融云等）

测试环境落地

环境建设落地

考虑点：用途、使用成本、维护成本

基本架构：

研发环境：用于研发自测、集成测试。

联测环境：完备环境，用于大型联测。

外联环境（如果有需求）：稳定版本环境，用于外部商户等联调。

简单的测试过程

测试管理过程：

 

测试人员  制定测试计划→设计测试用例→执行测试→提交测试发现的问题→所有问题已修复（否→修改问题）→结束

测试过程划分：

测试策划过程 两个大的过程 ： 需求分析测试阶段&软件方案测试阶段

1、需求分析阶段：

进行测试需求的分析

2、测试计划阶段：

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

明确测试的充分性要求

明确测试的基本方法

• 确定测试的资源和技术需求（人力资源、机器、工具资源等，是否需要安全测试、性能测试、自动化测是等）
• 进行风险分析与评估（如是不是有哪些内容无法测试，由于数据环境等原因无法测试充分，结果没有百分之百的可行性）
• 根据上述分析结果制定测试计划
• 根据测试计划开展相应的测试控制活动

需求测试：

1. 测试工程师参与需求分析，对需求了解很深刻，减少与开发人员的交互，节省时间。
2. 早期确定测试用例的编写思路，为测试打好基础
3. 可以获取一些测试数据，为测试用例设计提供帮助
4. 可以发现需求不合理的地方，降低测试成本（比如违反正常操作规范的那个）

需求测试的作用：

• 测试需求的分析用来确定整个测试工作，明确测试对象以及测试工作的范围和作用，并作为测试覆盖的基础。
• 被确定的测试需求项必须是可核实的，测试需求必须有个可观察，可评测的结果。（比如转账手续费，必须可见，某些需求是不行的，比如“软件药好用”）
• 测试需求分析还包括与客户交流以澄清某些混淆
• 明确哪些需求更重要，需求等级分层（比如支付宝要上余额宝的时候）
• 确保风险承担者尽早地对项目达成共识
• 测试需求是制订测试计划的基本依据
• 测试需求是设计测试用例的指导
• 确定了要测什么、测哪些方面才能有效设计用例

需求验证过程中要做什么：

1、审查需求文档

• 对需求文档及相关模型进行仔细检查
• 在需求开发期间所做的非正式评审也是有利的

2、以需求为依据编写测试用例

编写用户手册（比较简单，作为后续制定真正的用户手册的基础或者跟客户对接的基本依据）

3、确定合格标准

余额宝需求测试实战【已完成】

测试前的思考

写用例之前要想到的问题：

1、要测试的系统是干什么的？

2、了解系统有哪些特点？

3、系统有哪些功能？

4、系统哪些部分需要测试？哪些不需要测试？

5、系统对性能、安全性等有什么要求？等

测试策略要素：测试策略是测试计划的一部分，对于测试理念来说，测试策略、测试计划、测试方案各有偏重点，在实现的时候可能三者合一。

 

测试安排 发布计划

• 罗列里程碑DDL，每个里程碑都有明确的DDL
• 如果时间安排不足，后续的测试范围中挑选优先级比较高的特性来执行测试，必须保证核心功能正常使用
• 测试范围 （按优先级排序）分为In Scope 和Out Of Scope 需要说明哪些模块是在测试范围中的，哪些是本阶段测试不考虑的
• 对于在测试范围中的模块，需要给出优先级 不在范围中的模块 需要给出原因

测试资源 【人力和工具】

• 人力主要说明参与测试的人员 包括很多角色 比如专业测试人员 客户 产品经理等
• 工具主要是指可能用到其他软件

测试环境

• 包括推荐环境解决方案、操作系统、软硬件
• 对于推荐解决方案，需要陈述的是对测试项目对其他软件的依赖，比如测试i项目对JAVA版本有依赖，推荐版本1.7

测试方法

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

文档管理

• 包含安装、升级文档、用户指南等
• 文档不单单是一个文件 需要完整的测试才能发布给客户 

风险管理

• 列出来已知的可能会出现不确定性因素
• 这些因素可能来自技术 资源或者其他的 比如并发3E（拼多多） C/S项目做自动化但是缺少商业工具

 

测试方案设计：

1. 测试策略：侧重需求分析，评估风险，定义测试范围，确定测试方法，制定测试启动、停止、完成标准和条件
2. 测试计划：制定项目测试过程中的测试重点。 各个阶段的任务分配以及时间进度安排，并提出对各项任务的评估，风险分析，可以包括测试策略
3. 测试方案：侧重测试的放啊，测试环境的规划。 测试工具的设计和选择，测试用例的设计方法，测试代码的设计方案。

实际： 测试方案=测试计划+用例设计方案+工具选择+自动化/性能测试具体方案

 

测试方案评审

评审目的：

1. 呈现测试的工作：包括测试的时间安排、每个阶段需要如何配合、测试如何开展。
2. 与开发达成共识
3. 头脑风暴

评审重点:

1. 采用的测试方法：是否需要性能、安全、自动化等
2. 等价类划分依据：
3. 测试数据的选取和准备方法：比如：验证计算器功能，需要选择数据，说明选择该数据的原因等
4. 流程测试的路径组合：比如：tb购买商品：登录→查看商品→加入购物车→下单→地址→付款等，评审要检查是否覆盖到核心流程。
5. 数据比对 选取的对象和数据检查点
6. 是否需要模拟数据及模拟数据方法
7. 基于风险的测试取舍

测试过程划分

思考：余额宝体现到银行卡需要思考哪些功能点？