测试相关基础知识

参考网址：https://www.bilibili.com/video/av35752315

1、计算机软件分类

1.1按层次划分

系统软件: windows\linux\Andriods
支持软件：RDBMS(关系型数据库管理系统，oracle，mysql，sqlserver),DB2
应用软件：

1.2按结构划分

单机软件：客户端和服务其在同一个电脑中
分布式软件：

• 客户端/服务器端(C/S-client server，例如qq软件，)，将重要的繁重的任务放在服务器上，客户端仅进行简单的计算，简单的业务逻辑处理
• 浏览器端/服务端（B/S-browser server）：进一步解放了客户端，将计算的绝大部分放到了服务器端，
• 云计算是B/S的下一个发展周期，仍属于B/S架构

1.3按组织划分

开源软件
闭源软件（商业）软件

2、软件生命周期

定义：软件生命周期是指软件的产生直到报废的生命周期
包括：

• 问题的定义及规划（开发与需求方讨论）
• 需求分析
• 软件设计
• 软件编码
• 软件测试（单元测试、集成测试、系统测试、验收测试）
• 运营维护
  瀑布型生命周期：
  
  

2.1 问题定义及规划

主要是确定软件开发的目的及可行性，制定开发计划

2.2 需求分析

来源：需求说明书或者原型图（原型图：产品各个模块业务的流转）
参与人员：产品经理，研发，设计，测试
需求分析的目的是：不懂就问，不对就质疑，最终目的就是对软件需求要实现的各个功能进行详细分析，弄清楚用户对软件系统的全部需求。

2.3 软件设计

开发人员把需求分析结果转化成软件结构和数据结构，形成系统架构
产出文档：

• 概要设计 ：主要是架构的实现，指搭建架构、表述各模块功能，模块接口连接和数据传递的实现等事务。
• 详细设计：对各模块进行深入分析，对各模块组合进行分析等。这一阶段要求达到伪代码级别

2.4软件编码

按照详细设计的模块功能表，开发开始编写代码

2.5 软件测试阶段（见5软件测试流程）

2.6运营维护阶段

是生命周期中持续时间最长的阶段，为了延长软件的使用周明，适应用户需求，就必须对软件进行维护，包括纠错性维护和改进性维护
版本升级改进
Bug修复

3、软件测试定义及目的

软件测试：使用人工和自动手段来运行或测试某个系统的过程，（为了发现错误而执行程序的过程）
**测试目的：**在于检测它是否满足规定的需求或弄清预期结果与实际结果之间的差别。

• 为了发现程序存在的代码或业务逻辑错误
• 为了检验产品是否符合用户要求
• 为了提高用户体验

4、软件测试原则/对象

4.1 测试原则

1. 测试证明软件存在缺陷、不存在缺陷的谬论
2. 不可能执行穷尽测试（完全测试是不可能的，测试需要终止）
3. 测试应尽早启动，尽早接入
4. 缺陷存在群集现象（二八原则，测试发现的错误中80%很可能起源于20%的模块中）
5. 杀虫剂悖论（在第一次测试发现bug后，再用相同的方法可能发现不了bug需要运用不同方法进行验证）
6. 突通的测试活动依赖不同的测试环境
7. 所有的测试都应追溯到用户需求
8. 程序员应该避免检查自己的程序（除了单元测试）。
9. 设计测试用例时，应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态
10. 对错误结果要进行一个确认过程
11. 制定严格的测试计划
12. 妥善保存测试过程中的所有文档

4.2 测试对象

软件源代码
与软件源代码匹配的文档（需求文档、概要设计、详细设计、用户手册等）
支撑源代码运行的配置数据
需求阶段——测试对象是需求文档——测试需求文档是否正确实现了用户的需求
系统设计阶段——测试对象包括概要设计和详细设计——是否有设计或逻辑上的错误
编码阶段——测试源代码——发现编程的错误
系统测试阶段——测试对象是否满足用户需求

5、软件测试流程

• 测试需求分析
• 测试计划
• 测试设计
• 测试执行
• 缺陷跟踪
• 回归测试
• 编写测试报告

5.1 测试流程框架图

5.2测试需求分析

测试需求主要解决“测什么”的问题，测试需求应全部覆盖已定义的业务流程，以及功能和非功能方面的需求。
例如:
一个购物网站，具备注册、登录、浏览商品、购买商品、支付等功能。这个例子里面注册、登录、浏览商品、购买商品以及支付等功能就是这个网站的需求。需求说明说明书中会详细描述登录是否支持老用户登录、是否支持手机号码登录，是否支持第三方登录等，每个模块的业务流程、细节都会体现在软件需求说明书里。

软件测试需求的分层：

• 用户需求 （重点关注）
• 业务需求
• 功能需求

分析来源： 原型图/软件需求说明书（产品提供）
参与人员：产品经理，研发，设计，测试
测试参与需求分析的目的：

• 产品的目的、定位 ，例如：社交类、电商类、金融类
• 产品的功能，例如：登录功能（手机，邮箱，支持第三方登录）
• 提出相关疑问，提出建议或意见

软件测试需求的作用（只有明确了测试需求，才能知道怎么去测试？什么时候开始测试，要多少人测试，在什么环境上测试）

• 软件测试需求是设计测试用例的依据
• 有助于保证测试质量和进度
• 软件测试需求是衡量测试覆盖率的重要指标

需求分析注意事项
需求分析中注意隐形需求：客户信息中需要填写手机号，需要对客户填写的数组验证是否符合手机号规则。（有效等价：正确的手机号，无效等价：字母、汉字、特殊字符，数字+字母+，数字+特殊符号，数字+汉字等。根据边界值确定的测试用例，10位，11位，12位）

需求分析输出
测试点：在项目比较紧急的情况下，用xmind罗列出需要测试的点
测试用例：在项目时间比较充裕的情况下可用excel、禅道等详细设计测试用例，主备测试数据

5.3测试计划

编制人：测试负责人/测试组长
包括内容：

• 人员
• 任务划分
• 时间规划
• 项目结束需要出具的文档：用例，bug表单，测试报告
• 做什么类型的测试（功能测试、性能测试、接口测试）？需要准备什么杨的工具

5.4测试设计

测试用例设计
来源：需求说明书/原型图
设计后需要评审，参加人员：开发，产品，测试（避免测试执行人员执行无效测试，避免三方人员理解需求不一致，查缺补漏）
修改：理解错误，删除无效CASE,添加缺漏CASE,需求变更

5.5测试环境和数据准备

测试环境=软件+硬件+网络（硬件包括PC/笔记本、服务器及各种终端，cpu要求，软件：软件运行的操作系统，网络：c/s结构还是b/s结构）
数据准备:主备测试过程需要的数据，例如账号密码，商品信息，客户信息等。

5.6测试执行

• 执行预测，即冒烟测试，以判定当前版本可测与否，如果测试通过，正式进入系统测试，否则打回
• 根据测试用例执行测试，发现bug则提交到缺陷管理平台，并对bug进行跟踪回归，直到被测然间达到测试发布要求，没有重大bug

5.7编写测试报告

• 测试完毕，出具测试报告
• 测试通过上线
• 测试不通过，打回修改，重新测试

5.8 补充

普通测试工程师：按照需求点写测试用例（例如针对某一个输入框内容的测试，为一个测试点）
中级测试工程师：按照场景些测试用例（针对各个测试点不同的组合的测试）
高级测试工程师：分析用户需求，根据用户的需求或者行业的特点，用户可能需要做什么杨的操作，进行响应的操作，例如购物网站中，有客户单件购物，有客户需要批量购物，而且发往不同的地点等。

6、测试分类

6.1按照测试阶段划分（又称为测试级别）

**单元测试：**针对被测试系统最小的组成单元实施的测试活动，一般是类或函数，也可能是最小的功能单元
**集成测试：**针对组件/单元与组件/单元之间的接口的测试活动，验证接口设计是否与设计相符。（主要针对模块之间的接口测试，分三种集成：模块间集成，函数间集成，子系统集成）
系统测试： 将通过集成测试的软件，部署在真实用户环境下执行测试，包括：安装测试、卸载测试、功能测试、兼容性测试、 性能测试、 安全性测试。
验收测试： 以用户为主的测试，验收组应当由项目组成员、用户代表组成

测试阶段	主要依据	测试人员、测试方式	目的	主要测试内容
单元测试	系统设计文档	由开发小组执行白盒测试 ，	被测对象或者被测单元是否符合详细设计说明书	接口测试、路径测试
集成测试	系统设计文档、需求文档	由开发小组执行白盒测试和黑盒测试 ，	即验证“设计” 也验证需求	接口测试、路径测试、功能测试，性能测试
系统测试	需求文档	由独立测试小组执行黑盒测试	是否符合“需求规格书”	功能测试、健壮性测试、性能测试、用户界面测试、安全性能测试、压力测试、可靠性测试、安装/卸载测试
验收测试	需求文档	由用户执行黑盒测试		同上

大型通用软件，在正式发布前，通常需要执行Alpha和Beta测试，目的是从实际终端用户的使用角度，对软件的功能和性能进行测试，以发现可能只有最终用户才能发现的错误。属于验收测试。

Alpha测试	Beta测试
是用户在开发环境下进行的测试，也可以是公司内部用户在模拟实际操作环境下进行的测试。这是在受控制的环境下进行的测试	是用户在实际使用环境下进行的测试。与Alpha测试不同的是开发者通常不在测试现场。因此beta测试时在开发者无法控制的环境下进行的软件现场应用
目的是评价软件产品的FURPS（即功能、可使用性、可靠性、性能和支持）	只有当Alpha测试达到一定可靠程度时，才能开始Beta测试，由于它处在整个测试的最后阶段，不能指望这时发现主要问题。
可以从软件产品编码结束之时开始，或在模块（子系统）测试完成之后开始，也可以在确认测试过程中产品达到一定稳定和可靠程度之后在开始	产品的所有手册文本也应在此阶段完全定稿

两者相同点就是都不能是测试和开发参与

UAT测试：用户接受度测试，一般商业用户验证系统可用性进行的测试

6.2 按照测试对象是否运行划分

• 动态测试 ：运行软件验证功能
• 静态测试（代码走查，文档检查，界面审核）

6.3 按照测试技术划分

• 黑盒测试：不需要知道内部逻辑结构，直接通过输入测试数据来进行测试，主要测试依据是需求文档
• 白盒测试：利用程序的逻辑结构等信息，设计测试用例，对程序的逻辑路径进行全方位测试，属于代码层面的测试。**主要依据是设计文档。**单元测试也属于代码层面的测试。白盒测试与单元测试区别是：白盒测试是在宏观的角度测试程序的整体逻辑，单元测试只是测试程序中一个独立的模块。（白盒自动化测试主要在单元测试）
• 灰盒测试：介于黑盒和白盒之间，即涉及到黑盒测试，又涉及到白盒测试。

	白盒测试	黑盒测试
测试规划	根据程序内部结构，如语句控制结构，模块控制结构以及内部数据结构等进行测试	根据用户的规格说明，即针对命令、信息、报表等用户界面及体现他们的输入数据与输出数据之间的对应关系，特别是针对功能进行测试
优点	能够对程序内部的特定部位进行覆盖测试	能站在用户的立场上进行测试
缺点	无法检验程序的外部特性，无法对未实现规格说明的程序内部欠缺部分进行测试	不能测试程序内部特定部位，如规格说明有无，无法发现
方法举例	语句覆盖、判定覆盖、条件覆盖、判定——条件覆盖，基本路径覆盖，循环覆盖	基于图的测试、等价类划分测试、边界值分析、比较测试

6.4 按不同的测试手段划分

• 手工测试
• 自动化测试

6.5 按测试包含的内容划分

- 功能测试 在指定的使用条件下，使用被测对象，验证其是否满足用户显性或隐形需求。测试关注点：
是否由不正确或者遗漏或多余的功能。
满足系统显性或隐形需求
是否对输入输出做出了正确的响应，输出结果能否正确显示
**- 性能测试：**通过模拟被测试对象运行业务压力或使用场景，验证被测对象是否满足预先设定的性能指标。存在三个特性：
验证系统是否具有宣称的能力
了解测试系统典型场景，并具有确定的想能目标
要求在真实环境下实施
- 安全测试: 测试被测对象的安全保护机制保护系统不受非法侵入，能够接收正确授权的操作
- 兼容性测试： 验证被测试对象在不同的操作系统、硬件信息等环境下的运行情况

• 易用性测试
• 界面测试
• 压力测试
• 负载测试
• 恢复测试

6.6 其它测试

• 冒烟测试：预测试——对主流程、主功能进行测试，冒烟测试通过后，我们才会进行下一步的测试
• 回归测试：开发修复Bug，测试验证Bug的一种模式。验证Bug包括与bug相关的功能或模块是否受到影响。例如：充值功能，充值100，界面显示的10.需验证用户界面显示、提现、支付等相关功能是否受到影响。
• 探索性测试（测试的一种思维）

7、软件质量

7.1定义

软件产品满足用户或规定的显性或隐形需求的程度，软件质量又分为：

• 内部质量：软件内部的设计和静态测试是否合格的
• 过程质量：软件的整个生产流程是否规范的合理的
• 外部质量：软件功能和性能的表现
• 使用质量：软件使用过程易用性和满意度的表现

7.2质量特性

质量特性包括：功能性、可靠性、易用性、效率、可移植、可维护

功能性
定义：软件在指定条件下使用时，满足用户需求和隐含需求的功能的能力，又分为5个子特性。

• 适合行：软件为指定的任务和用户目标提供一组合适功能的能的能力
• 准确性：软件提供具有所需精度的正确和相符的结果或效果的能力
• 互操作性：软件与一个或更多的规定系统进行交互的能力
• 保密安全性：软件保护信息和数据的能力，以使未授权的人员或系统不能阅读或者修改这些信息和数据，而不拒绝授权人员或系统对他们的访问。
• 功能性依从性：软件遵循与功能性相关的标准、约定或法规以及类似规定的能力。这些标准要考虑国际标准、国家标准、行业标准、企业内部规范等

可靠性
定义：软件在指定条件下使用时，维持规定的性能级别的能力

• 成熟型：软件为避免由软件中错误而导致失效的能力
• 容错性：在软件出现故障或者违反指定接口的情况下，软件维持规定的性能级别的能力
• 易恢复性：在失效发生的情况下，软件重建规定的性能级别并恢复受直接影响的数据能力 可靠性依从性：软件遵循与可靠性相关的标准、也顶或法规的能力

易用性
定义：在指定条件下使用时，软件被理解、学习、使用和学习、使用和吸引用户的能力

• 易理解性：软件使用用户理解软件是否合适，以及如何能将软件用于特定的任务和使用环境的能力
• 易学性：软件使用户能学习其应用的能力
• 易操作性：软件使用户能操作和空它的能力
• 吸引性：软件吸引用户的能力
• 易用性依从性：软件遵循与易用性相关的标准、也顶、风格指南或法规的能力

效率
定义：在规定条件下，相对于所用资源的数量，软件可提供适当性能的能力（在同等条件下，所使用的资源最少）

• 时间特性：在规定条件下，软件执行其功能时，提供适当的响应和处理时间以及吞吐率的能力，即完成用户的某个功能需要的响应时间
• 资源利用率：在规定条件下，软件执行功能时，使用合适的资源数量和类别的能力
• 效率依从性：软件遵循与效率相关的标准或约定的能力

可维护性
定义：软件可被修改的能力。修改可能包括修正、改进、或软件对环境、需求和功能规格说明数的适用性（可扩展性）

• 易分析性：软件诊断软件中的缺陷、失效原因或识别待修改部分的能力（软件运行中出现的错误，客户可以根据提示知道出现错误的原因是什么，并作出响应的操作）
• 易改变性：软件使指定的修改可以被实现的能力
• 稳定性：软件避免由于软件修改而造成意外结果的能力（模块化设计，或者面向对象的设计）
• 易测试性：软件使已修改软件能被确认的能力
• 维护性依从性：软件遵循与维护性相关的标准或约定的能力

可移植性
定义：软件从一种环境迁移到另外一种环境的能力

• 适应性：软件无需采用有别于为考虑该软件的目的而准备的活动或手段，就可能适应不同指定环境的能力
• 易安装行：软件在指定的环境中被安装的能力
• 共存性：软件在公共环境中同与其分享公共资源的其它独立软件的共存能力
• 易替换性：软件在同样环境下，替代另一个相同用途的指定软件产品的能力
• 可移植性依从性：软件遵顼于可以指相关的标准或约定的能力

8、软件测试关注重点

8.1根据软件的各种属性，将测试重点划分为

1. 输入（用什么输入，期望得到输出是什么）
2. 状态（输入之后，在软件内部的状态转换是什么）
3. 代码路径（代码运行路径）
4. 用户数据（输入数据的特点是什么，中文，字符，特殊符号，电话，邮箱等）
5. 执行环境（软件运行环境）

8.2合法输入&非法输入

• 明确哪些时合法输入，哪些时非法输入
• 关注程序对于非法输入的处理、反应
• 处理输入的方式：输入筛选器、输入检查
  输入筛选器：
  用于放置非法的输入值，传递给程序
  列表框、下拉框时常用的输入筛选器
  测试关注点：提供的输入选项本身是否正确，是否可以绕过筛选器的屏蔽而进入系统

8.3使用输出来指导输入选择

首先把所有的输出结果罗列出来
然后确定哪些输入会引发这些输出
该方法可以保证重要的场景都被测试

8.4状态

软件的一个状态就是状态空间中的一个点，由它所有内部数据结果的取值来唯一确定
例如：12306网站，首次订票和第二次订同一张票时完全不同的两个状态，应该是为两个不同的用户场景，分别涉及不同的测试用例。

8.5用户数据

创建一个含有特定数据的测试环境，含有的数据应该和软件真实使用的数据尽量相似
常用的方法是取得用户的数据导入到测试环境中

8.6运行环境

软件运行的环境本身也是一种输入原，测试人员在产品发布之前应进场尝试各种各样的用户环境。

6.1 测试理念

• 企业的主要目的时获取利润，降低测试成本也是盈利的一种方式。
• 用较低的代价实现有效的测试，不应为了追求完美的测试而不惜一切代价。

6.2提高测试效率

• 减少冗余的测试
  白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙。在喝多地方，白盒测试与黑盒测试会产生一摸一样的效果（或者能推理出来），这样的测试时冗余的。
  在集成测试、系统测阶段，可能要执行多次回归测试，每次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。
  利用代码比较工具，发现修改代码不同的模块，进行测试。未修改的不做测试。
• 减少无价值的测试
  无价值的测试通常由于不同的测试技术引起的。例如功能测试，在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测试了100次，那么其中99次就是无价值的。

6.3测试优先级

参考网址：https://www.bilibili.com/video/av35752315
测试网站http://sq.ytesting.com/example/