测试软件的基础

一.软件基础

软件测试的定义

就是通过人工或自动化的方式来验证软件的实际结果与用户需求是否一致的过程；

软件的应用场景

游戏型测试，电商型测试，金融型软件，嵌入式测试等

软件架构分类

1. B/S架构软件：web端
2. C/S架构软件：APP端

相同：

都可进行兼容性测试
web端：IE，谷歌，火狐各浏览器版本的兼容
APP端：系统版本，手机型号

不同：

APP可进行专项测试:中断测试，弱网，热启动

区别：

1. 标准：Cs架构比Bs架构的两端使用的是现成的成熟产品，会标准一些；
2. 效率：相对于Bs架构来说Cs中的客户端可以分担一些数据的处理，执行效率会高一些；
3. 安全：Bs架构中数据都是以Http协议进行传输的，而Http协议又是明文输出,可以被抓包，所以相对Cs架构来说不是很安全；
4. 升级：Bs架构只需要在服务器端更新数据，前台只需要刷新页面就可以升级，而Cs架构必须要将两端都进行更新才可以。
5. 开发成本：相对于Bs架构来说Cs当中的客户端需要自己开发，Bs不用，所以说Cs成本会高一些。

二.软件测试的定义与原则

为什么需要软件测试

1. 通过测试工作可以及时发现并修复软件当中存在的缺陷，
2. 可以降低同产品开发遇到的风险，
3. 记录软件运行过程中的一些数据，从而为决策者提供技术支持。

软件测试的原则

1. 2/8定律，核心功能占20%，非核心占80%，我们会集中测试20%的核心功能，因为在这20%功能模块里发现缺陷的几率会高于80%。
2. 不能进行穷尽测试，有些功能是无法将所有测试情况体现出来的，任何的测试都有结束的时间。

三.测试模型

Ｖ模型

用户需求-需求分析-概要设计-详细设计-编码-单元测试-集成测试-系统测试-验收测试
优点

1. 每个阶段都清晰明了，便于控制开发的每一个过程。
2. 既包含单元测试又包含系统测试。

缺点

1. 测试介入的比较晚，对于前期的一些缺陷无从发现和修改。

W模型

开发测试同时开始：

1. 开发：需求分析-概要设计-详细设计-编码-集成-实施-交付
2. 测试：需求分析-概要设计-详细设计-单元测试-集成测试-系统测试-验收测试

优点

1. 测试伴随着软件的整个生命周期，可减少不必要损失。
2. 测试于开发而言是并行且独立进行的。

缺点

1. 有些项目在开发过程中根本没有文档产生，故W模型无法使用。
2. 对于需求和设计的测试技术要求很高，实践起来很困难。

四.软件测试的流程

首先确定项目 – 然后产品那边会出一个产品说明书 – 在需求人员编写需求文档 – 需求评审 – 开发编写详细设计 – 测试编写测试用例 – 测试用例评审 – 开发进行编码 – 测试部署环境进行测试 – 首先进行冒烟测试(主的业务要实现) – 接着进行功能测试 – 出现bug使用禅道进行记录跟踪 – 开发进行修改 – 测试进行验证 – 然后进行回归测试 – 接着验收测试，验收测试通过 – 进行上线

五.软件测试的分类

按技术划分

1. 黑盒测试：不需要了解程序的源代码，通过使用整个软件功能来验证程序是否满足需求的测试方法
2. 白盒测试：是一种按照程序内部逻辑结构和编码结构设计测试数据并完成测试的测试方法
3. 灰盒测试：一种基于程序运行时的外部表现同时又结合程序内部结构来设计测试数据的测试方法

按阶段划分

1. 单元测试：对一个模块、一个函数或者一个类来进行正确性检验的测试方法
2. 集成测试：单元测试后，将单独的模块按照设计要求组装成为子系统或系统，作为整体进行测试的测试方法
3. 系统测试：集成测试后，将硬件、软件看作一个整体,对系统的功能及性能的总体测试
4. 验收测试：系统测试后以用户测试为主，或有测试人员共同参与检验软件质量的测试方法

按内容划分

功能测试、性能测试、兼容性测试

功能测试

1. 功能测试：根据产品操作描述和需求文档，测试一个产品的特性和可操作行为是否满足用户需求的测试方法
2. 界面测试：测试用户界面的功能模块的布局是否符合客户使用习惯，界面操作便捷性、导航简单易懂性的测试
3. 冒烟测试：验证系统的核心功能是否能够正常运行的测试方法
4. 回归测试：指修改了旧代码后，重新进行测试以确认修改没有引入新的错误或导致其他代码产生错误的测试方法
5. 业务逻辑测试：在基本的功能点都已合格的基础上，准备多种测试数据，来驱动各种约束条件下业务流程，确定最终输出的结果是否符合预期的测试
6. 易用性测试：指用户使用软件时是否感觉方便的测试

性能测试

1. 性能测试：通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行校验的测试方法
2. 压力测试：通过逐步增加系统负载，测试系统性能的变化，并确定在什么条件下系统性能处于失效状态
3. 负载测试：通过逐步增加系统负载，测试系统性能的变化，在满足性能指标的情况下，系统所能承受的最大负载量的测试
4. 并发测试：是一个负载测试和压力测试的过程，即逐渐增加并发用户数负载直到系统的瓶颈，通过分析资源监控指标等来确定系统并发性能

兼容性测试

1. 游览器，不同版本，分辨率
2. 手机型号，不同版本，分辨率

按其他划分

1. 随机测试：随机测试主要是根据测试者的经验无需测试用例对软件进行功能和性能抽查的测试方法
2. 安全性测试：通过不同的测试方法，检验程序、网络、数据库安全性的测试方法
3. Alpha测试：俗称内测，α测试。内部环境下的测试；开发人员或测试人员在现场
4. Beta测试：俗称外测、公测，β测试。生产环境下的测试；开发人员和测试人员都不在现场

六.常识

测试部门的组织结构

技术总监-项目经理-开发工程师,测试工程师

补充

PM产品经理
PRD 产品需求文档
RD:研究和开发人员
QA测试
OP运维
case 测试用例

测试用例的定义：

什么是测试用例？

测试用例是执行测试的依据，把测试系统的操作步骤用文档的形式描述出来

1. 测试用例是为达到最佳的测试效果或高效的揭露隐藏的错误，而精心设计的少量测试数据，包括测试输入、执行条件和预期的结果，实际结果
2. 测试用例是执行的最小实体。
3. 测试用例是测试工作的指导，是软件测试的必须遵守的准则，更是软件测试质量稳定的根本保障

测试用例的特征：

1. 有效性：测试用例的能够被使用，且被不同人员使用测试结果一致
2. 可重复性：良好的测试用例具有重复使用的功能。(回归测试)
3. 易组织性：好的测试用例会分门别类地提供给测试人员参考和使用(功能、性能、易用分类编号)
4. 清晰、简洁：好的测试用例描述清晰，每一步都应有相应的作用，有很强的的针对性，不应出现一些无用的操作步骤。
5. 可维护性：由于软件开发过程中需求变更等原因的影响，常常对测试用例进行修改、增加、删除等，以便测试用符合相应测试要求。

编写测试用例的好处：

测试用例的作用：

在开始实施测试之前设计好测试用例，可以避免盲目测试并提高测试效率。
测试用例的使用令软件测试的实施重点突出、目的明确。
在软件版本更新后只需修正少部分的测试用例便可展开测试工作，降低工作强度、缩短项目周期。
检验软件是否满足客户需求、体现一个测试人员的工作量、展现测试用例的设计思路

测试用例的4个特性

1. 代表性：能够代表并覆盖各种合理的和不合理、合法的和不合法的、边界的和越界的以及极限的输入数据、操作等。
2. 针对性：对程序中的可能存在的错误有针对性地测试
3. 可判定性：测试执行结果的正确性是可判定的，每一个测试用例都应有相应的期望结果
4. 可重现性：对同样的测试用例，系统的执行结果应当是相同的。

测试用例通常包括以下几个组成元素：

用例编号、测试模块、用例标题、用例级别、测试环境、测试输入、执行操作、预期结果,实际结果

编写测试用例的基本方法

等价类划分法

应用场景：多用于输入框

概念

等价类划分是指分步骤地把海量（无限）的测试用例集减得很小，但过程同样有效。

等价类 ：何为等价类，某个输入域的集合，在这个集合中每个输入条件都是等效的。

一般可分为有效等价类和无效等价类

等价类划分为：
有效等价类：指符合《需求规格说明书》，输入合理的数据集合
无效等价类：指不符合《需求规格说明书》，输入不合理的数据集合

边界值法

一般边界值分析是因为程序开发循环体时的取数可能会因为<,<=搞错。
比如：有效等价类是0<=y<=100，所以边界值就是-1，0，100，101

对数据进行软件测试，就是在检查用户输入的信息、返回的结果以及中间计算结果是否正确。即使最简单的程序要处理的数据量也可能极大，使这些数据得以测试的技巧是，根据一些关键的原则进行等价类的划分，以合理减少测试用例，这些关键的原则是：边界条件，次边界条件、空值和无效数据。

确定边界值的方法

选取正好等于、刚刚大于或刚刚小于边界值作为测试数据

输入要求是1 ～ 100之间的整数，因此自然产生了1和100两个边界，我们在设计测试用例的时，要重点考虑这两个边界问题。
[1 100] 上点1 ，100 离点 0 101所属
(1,100) 上点 2，99 离点 1 ，100
(1,100] 上点 2，100 离点 1 ，101

因果图法

概念:

因果图法比较适合输条件比较多的情况，测试所有的输入条件的排列组合。所谓的原因就是输入，所谓的结果就是输出。

场景法

这个流经过程要从用例开始到结束遍历其中所有基本流和备选流。

基本流和备选流的区别

正交表法

正交实验法就是利用排列整齐的表 -正交表来对试验进行整体设计、综合比较、统计分析，实现通过少数的实验次数找到较好的生产条件，以达到最高生产工艺效果，这种试验设计法是从大量的试验点中挑选适量的具有代表性的点，利用已经造好的表格—正交表来安排试验并进行数据分析的方法。

公式

正交表测试用例设计方法的特点是什么？

1. 用最少的实验覆盖最多的操作，测试用例设计很少，效率高，但是很复杂；
2. 对于基本的验证功能，以及二次集成引起的缺陷，一般都能找出来；但是更深的缺陷，更复杂的缺陷，还是无能为力的；
3. 大体的环境下，正交表一般都很难做的。大多数，只在系统测试的时候使用此方法。

测试报告模板

测试目标，测试依据，测试范围，测试环境，测试进度，执行结果，缺陷分布，遗留缺陷，测试结论，建议附，附录等等。

测试用例模板

用例编号，测试模板，用例标题，用例级别，前置条件，测试输入，执行操作，预期结果，实际结果…

测试计划模板

确定测试范围，制定测试策略，测试资源安排人员的分配，时间安排，风险分析等。

需求变动应该如何做

由于现在的测试项目都是维护版本，测试过程发现很多的新增需求，而测试人员每次测试时，都接收不同的测试项目，经过一段时间后，这些变更的需求无法组合在一起。导致测试人员不能及时掌握相关变更。为了解决这个问题，特提出如下改善方法。 

1．测试结束后，测试人员编写测试报告，其中测试报告包括测试内容，测试策略等。

2．编写“新增和变更需求文档”，该文档用EXCEL保存，所有测试人员都可以访问，其中的字段包括（系统名称，测试时间，提交人，BUG来源，业务类型，功能概要描述，功能详细描述，涉及接口，测试策略，测试数据，优先级，汇总状态，备注等），其中测试策略尽量详细，把测试过程的一些测试方法，开发人员提供的测试数据，以及测试需求文档进行归纳总结，并保存在“新增和变更需求文档”中，
3．指定每个子系统的专门测试人员，定时更新汇总各个子系统的变更需求。