1.按阶段对测试分类
1.1 单元测试（单元：一个独立的功能模块）
针对程序的源代码进行测试（交付程序之前自己自测一下）、
bug 太多，修复率太低，耗时的时候必须要单元测试
1.2 集成测试（接口测试，针对模块之间的访问来测试）
1.3 系统测试
我们把整个系统，整个软件组装起来之后，再去做一个验证测试。
因为单个模块或者两个模块测得没问题，真正组装成一个系统就有问题。
整体测：需求说明书，兼容性，什么软件各种说明书也要测。
1.4 验收测试（内测，公测）
比如说游戏，测试人员站在功能得专业角度已经测得没问题了。
需要不同得人群来测试，而不是直接上线。
这个时候，找一个用户内测，就能发现一些不同视角得bug。
2.对代码的可见度进行划分
2.1 黑盒测试(源代码不可见）
2.2 白盒测试（源代码可见）单元测试
2.3 灰盒测试（部分源代码可见）也是集成，接口测试。
部分源代码是可见的
3.质量模型
3.1 功能性
3.2 性能
3.3 兼容性
你的app和其他的应用兼容吗？
3.4 易用性
3.5 可靠性
出现无响应，卡顿，死机
3.6 安全性
传输是否加密，存储是否加密。
3.7 可移植性
服务器里的数据实在是太多了，所以需要考虑把数据搬到性能更好的服务器上。
如果你的软件 不好移动，就很难受。
基本上两三年都要换一下服务器。
4.测试流程
5.用例和测试用例
测试用例：为了测项目而设计的执行文档。
测试用例作用：防止漏测
5.1 测试用例格式
核心功能：用户使用最频繁的功能。
用例标题：结果（原因）
6. 场景问题
6.1 等价类划分法（解决穷举场景）
有效等价类：满足需求的数据集合。一个
无效等价类：不满足需求的数据集合。可以两个
步骤：
- 先确定根据什么需求来划分等价类，按年龄还是按性别？
- 确定有效等价类和无效等价类
- 提取数据编写测试用例
6.1.1 验证qq账号合法性的案例
例如：需求里要求是6-10位自然数。
如果要求 qq的输入类型必须得是自然数，那还得考虑 8位 非自然数的情况，还有特殊的情况就是空。
6.1.2 验证某城市电话号码的正确性
测试用例部分如下：
6.2 边界值分析法（用边界值来划分等价类）
因为开发可能把>号写成了 >=号。
6.2.1 边界值分析设计测试用例
6.3 验证标题长度的合法性
6.4 边界值法分析qq的合法性
等价类用来划分类型，边界值用来划分范围，结合使用
6.4.1 边界值优化
其实7个点可以优化成 5个点。
-98 ，98 其实和 50是一个性质的。
6.4.2 适用场景
6.5 判定表法（多条件依赖问题，四个条件以内）
这就相当于，叫或者不叫这个功能，有前置条件的依赖。
n个条件就最多有2的n次方个项。
6.5.1 适用于场景
条件最好少于4个以内，如果条件多了，可以考虑正交法或者因果图。
6.5.2 订购单检查
6.5.3 案例2
先写条件，然后写反应的动作。动作会根据条件的不同而不同。
6.6 场景法(业务覆盖测试）
对于京东，淘宝这种电商项目，业务执行功能很重要。
先测试业务，再测试单个功能和模块。
6.6.1 我们需要业务的流程图
因为业务的逻辑是根据流程图来梳理的。
用viso画流程图。
6.6.2 ER图（不用，了解一下）
ER图就是实体之间的关系。
6.7 业务测试（ATM机取款案列）
看流程图有多少条 能走向结束的路径，按个测试这些路径。
举例子，改前置条件即可。
7.错误推测法（根据经验）
1.时间紧任务重的时候，根据经验判断。
2.放眼于之前测试多出现问题的模块。
8.缺陷（bug）
文字和描述也可以是缺陷。
少功能，功能错，功能多，隐性功能错误，不易使用。
文章来源地址https://www.toymoban.com/news/detail-416623.html
8.1 缺陷出现的四个阶段
需求阶段：需求不好理解或者有歧义，理解错误。
设计阶段：设计文档出存在错误或缺陷。
编码阶段：代码出现错误。
运行阶段：软硬件本身故障，导致软件缺陷。
8.2 缺陷类型
功能错误，UI页面错误，兼容性，数据错误，易用性，架构缺陷。
8.3 描述缺陷（跟用例描述一样）
执行完测试用例，没通过的就要进行缺陷管理。
8.4 缺陷管理工具禅道（工具，用于产品管理，项目管理，质量管理）
进入软件，点提交bug。
文章来源：https://www.toymoban.com/news/detail-416623.html
到了这里，关于软件测试 理论的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
