1、软件全生命周期
1.需求分析
2.制定测试计划
目标 | 准则 | 进度 | 责任 | 测试用例库及标准 | 工具 | 计算时间 | 硬件配置 | 集成 | 跟踪步骤 | 调试步骤 | 回归测试 |
3.总结测试概要
4.编写测试用例
5.编码结束后开始执行测试用例测试
单元测试 | |
集成测试 | |
系统测试 | |
验收测试 |
6.提交BUG
7.进行缺陷跟踪管理
8.进行回归测试
9.出具测试报告
2、软件测试原则
1.测试表明项目存在缺陷 | |
2.避免无穷尽枚举测试 | 测试数据、输入和测试场景的所有组合是不可能的,因为它需要大量的时间。相反,测试团队只能专注于一些重要的标准,如设置测试策略的风险和优先级。项目时间表永远不允许测试团队在项目中测试大量有效的组合。这就是为什么在测试项目中,访问和管理风险被认为是必不可少的活动之一。 |
3.尽早介入原则 | 必须尽快进行测试活动,为软件开发的下一阶段做好准备。只要生成产品需求或文档,测试人员甚至可以开始测试。显然,从一开始就解决问题总是更容易、更便宜,而不是如果发现错误太晚就改变整个系统。因此,通过早期测试,测试人员可以检测到错误,并帮助开发团队以更少的成本和精力解决问题。 |
4.缺陷聚类 | 缺陷聚类指的是在几个模块中发现了大部分缺陷。这一原则要求测试团队利用自己的知识和经验,确定要测试的潜在模块。这一预测有助于节省时间和精力,因为团队只需要关注那些 “敏感” 领域。然而,这种方法也有缺点: 一旦测试人员只专注于所有团队的一小块区域,他们可能会错过其他区域的错误。 |
5.杀虫剂悖论 | 杀虫剂悖论是指测试人员在项目中进行的重复测试。这些测试只适用于一些有限的模块,而不是整个系统。这种测试可能会导致在模块之外没有发现新错误的问题。因此,为了涵盖项目的各个部分,它要求测试团队经常审查和更新测试用例。 |
6.不同项目不同测试方法 | 各种产品或项目包含不同的元素、特征和要求。因此,测试人员不能对不同的项目应用相同的测试方法。例如,银行行业的应用程序应该比娱乐软件需要更多的测试。 |
7.无错误谬论 | 软件产品不仅要在技术方面进行测试,还要根据用户的期望和需求进行测试。虽然测试没有在软件中显示任何错误,但这并不意味着产品已经准备好发布,因为必须确认测试是按照正确的要求进行的。 |
3、黑盒白盒测试方法
1.黑盒测试方法
黑盒测试方法是一种重要的测试策略,又称为数据驱动的测试方法或者输入输出的测试方法;黑盒测试常用的方法有等价类、边界值、因果图、错误推测法等;其中等价类分为有效等价类和无效等价类,根据测试场景的不同可以划分一个或多个有效等价类和一个或多个无效等价类;
黑盒测试可以采取枚举法设计测试用例,显然真实的测试场景中并不会提供穷尽的枚举用例。
等价类
有效等价类和无效等价类
可以是1个有效等价类+1个无效等价类 如X>=0是有效等价类,X<0是无效等价类
可以是1个有效等价类+多个无效等价类 如100<X<500是有效等价类,X<=100和X>=500是无效等价类
可以是多个有效等价类+多个无效等价类 如100<X<500和700<X<900是有效等价类,其他是无效等价类
边界值
注意边界的左右两边
因果图
多种输入条件+存在约束关系+多种输出条件
的原因和结果的关系,设计出多种因果组合
1.原因和结果的关系
恒等
与
或
非
2.原因之间的约束
互斥
唯一
包含
要求
3.结果之间的约束
屏蔽
正交实验法
资源变更运行环境:变更前运行环境和变更后运行环境
剥离出几个有效等价类进行类似求笛卡尔积的方法
如
变更前:测试环境和生产环境
变更后:测试环境和生产环境
变更前 | 变更后 |
测试环境C1 | 测试环境C2 |
生产环境C1 | 生产环境C2 |
进行正交实验
得
C1-C2
C1-S2
S1-C2
S1-S2
场景法
基本流和备选流
错误推测法
2.白盒测试方法
白盒测试又称逻辑驱动测试,这种测试方法对代码逻辑结构进行测试,同时也需要对代码规范测试;
白盒测试是对程序中的每条代码路径进行测试,显然在一个循环程序中,白盒测试不可能提供完全的测试路径。
语句覆盖
判定覆盖
判定覆盖只关心判定表达式的值(真/假)
判定覆盖是设计足够多的测试用例,使得程序中的每一个判断至少获得一次“真”和一次“假”,即使得程序流程图中的每一个真假分支至少被执行一次。
一个判定包括两个条件如下
y>1and z=0
一组符合判定/条件覆盖的用例需要满足下面
1.使得判定为真
2.使得判定为假 -- 1.2是为判定覆盖
3.使得y>1
4.使得y<=1
5.使得z=0
6.使得z!=0
条件覆盖
条件覆盖涉及到判定表达式的每个条件的值(真/假)
条件覆盖的含义是:使每个判定表达式中的每个条件都取到各种可能的结果。
一个判定包括两个条件如下
y>1and z=0
一组符合判定/条件覆盖的用例需要满足下面
1.使得判定为真
2.使得判定为假
3.使得y>1
4.使得y<=1
5.使得z=0
6.使得z!=0
3.4.5.6是为判定覆盖
判定/条件覆盖
一个判定包括两个条件如下
y>1and z=0
一组符合判定/条件覆盖的用例需要满足下面
1.使得判定为真
2.使得判定为假
3.使得y>1
4.使得y<=1
5.使得z=0
6.使得z!=0
多重覆盖
3.正常、异常场景
正常场景 异常场景
实现本次需求的功能要求 不多加其他的功能 本次改动不会影响本主流程的实现 不会影响其他流程的实现
4、代码检查、走查、评审
5、单元测试
1、自顶而下的测试策略 | 2、自底而上的测试策略 |
6、系统测试
1、能力测试 | 逐条检查目标文档,判断程序是否实现目标文档提及的需求。 |
2、容量测试 | 使程序经受大容量数据的检测。 |
3、强度测试 | 使程序经受高负载或强度的测试。 |
4、可用性测试 | 用户体验测试 |
5、安全性测试 | 安全漏洞 SQL注入 |
6、性能测试 | |
7、存储测试 | 针对软件的存储目标,进行内存、辅存、临时文件、溢出文件的测试 |
8、配置测试 | io设备 通信线路配置测试 计算机操作系统 浏览器版本 程序组件配置的测试 |
9、兼容性/转换测试 | |
10、安装测试 | 程序的安装 修改 卸载 |
11、可靠性测试 | 构建异常场景测试程序响应 |
12、可恢复性测试 | 程序错误、硬件失效、数据错误中恢复性测试 数据回滚 |
13、服务/可维护性测试 | 存储转存程序、诊断程序、调试程序平均时间、维护过程、内部业务文档的质量 |
14、文档测试 | 概要设计文档、测试用例文档、测试报告文档 |
15、过程测试 | 数据库的备份、恢复、操作构成的记录 |
16、系统测试的执行 | 不能由程序开发人员执行测试 |