测试管理培训

第32页
测试因素与测试类型的关系



测试因素是基础 测试类型是综合了测试因素，白盒、黑盒测试技术 后，对测试种类的一种分类。属于测试case的类型 测试类型可以根据实际测试情况、测试不同阶段进 行增删 在测试策略制定中，首先选择测试因素。再根据所 选择的测试因素，在测试case设计中，尽量考虑多 的测试类型，构造测试case.
第4页
软件测试的组织


开发人员不适合测试自己的软件 独立测试组织（ITG）的存在必要性： – 不受开发固有思维的影响 – 站在中立的角度，避免利益冲突 – 专职于查找问题，分工明确 – 更有利于V&V中发挥作用 – 更利于对软件进行评估
第5页
ITG的测试活动（repeat）

独立测试组织的测试活动是软件质量保证的关 键元素，代表了规约、设计和编码的最终检查
第7页
贯穿瀑布模型的测试过程
1 需求 需求review
2 设计 设计review
3 代码 测试case设计 、代码review
4 测试 测试执行
5 运行/维护 Patch测试
第8页
测试流程举例
制定测试策略 系统测试
软件项目计划
确认测试
制定测试计划
集成测试
制定配置计划
接口测试
确立需求基线
模块测试
设计测试case
第26页
测试类型举例（1）

正常测试：
– 测试某个功能是否满足需求的定义，功能是否 正确，完备。

边界测试：
– 对某个功能的边界情况进行测试。

异常测试：
– 对某些功能来说，其边界情况无法简单的了解 或某些操作不完全是正确的但又是可能发生的， 类似这样的情况需要书写相关的异常测试
第27页
测试类型举例（2）

文件完整性（File Integrity）
– 对系统数据文件的完整性、安全性的要求。如数据库文件 的完整性等。

服务等级（Service levels）
– 服务等级包括是否需要7*24小时不来自百度文库断业务，是否需要非 常高的保密控制，是否需要数据的决定准确等。测试系统 需求说明书中对平均失效间隔时间(MTBF),故障停机时间 (MTTR)的相关测试。
第17页
测试因素（1）

在制定测试策略时，首先要分析出系统的主要测试 因素。通过对测试因素的分析，制定出在整个软件 生命周期中采用什么样的测试技术和方法。
第18页
测试因素（2）

符合度（Compliance）
– 确认系统与需求、标准、规则的符合程度。如 系统设计是否符合产品需求，是否符合用户提 出的业务标准、行业标准等。 – 此测试因素强调的是测试的依据是用户的需求、 规范和标准。

易掌握程度（Ease of operation）
– 这里强调的是系统的学习过程是否容易，指导 手册是否完备、准确。使系统易学、易掌握。 如windows等这种使用人数众多的通用系统，就 要求非常容易的被掌握。
第20页
测试因素（4）

过程的可跟踪性（Audit trail）
– 操作的过程、轨迹是否有log记录，可以被跟踪。这在一 些服务等级很高的系统中要求非常严格，如银行系统，要 求对每个操作过程都有记录。
第24页
测试因素小结

针对不同的系统，测试因素即测试重点是不一样。 一般系统选取3到7个测试因素即可。
第25页
测试类型


测试类型为一个统称，它包括了简单的黑盒测试方 法和测试策略上的集合。 其中所反映的黑盒测试方法主要为边界测试和异常 测试。 其他所有的测试类型实际上都是测试的策略上的选 取。 融合一定的黑盒测试技术的原因是为了能够提醒测 试者在设计测试案例的时候更多的考虑功能在边界 和异常情况下是否正确。 测试类型会随着测试的实际开展而有所删减

多语言测试：
– 对不同的语言平台，环境下，包括界面， 语法，基本功能方面的测试
第31页
测试类型小结

正常测试： 边界测试： 异常测试： 性能测试： 压力测试： 兼容测试： 接口测试： 可安装性测试： 界面测试： 启动/停止测试： 文档测试： 配置测试： 易用性测试： 多语言测试：
第39页
测试team组成（2）

测试工程师
– 具有相关行业背景知识 – 具有相关领域的技术技能 – 良好的沟通、表达和分析能力 – 负责测试case的设计 – 负责执行测试、申报bug、汇总测试报告 – 负责对售后或用户的产品培训
第40页
测试team组成（3）

版本控制工程师
– 有软件版本控制的概念 – 负责源代码、release程序、文档的版本 管理 – 开发必要的版本控制脚本 – 参与版本计划的指定，并在每个 milestone中执行
第21页
测试因素（5）

易维护性（Maintainability）
– 系统是否易于维护。 – 可以通过定位和修复一个错误所需要的工作量来衡量

权限控制（Authorization）
– 系统功能和数据的访问权限被分级 – 只有授权用户可以访问 – 加密方法安全，不容易破解

进程的连续性（Continuity of processing）
– 在临时或永久的软件故障和系统故障发生的时候，系统自 动或手动进行恢复的可能性，系统其他相关软件能否正常 运行的可能性
第22页
测试因素（6）

访问控制（Access Control）
– 检查系统的安全性，软件的安全性及保密性，是否有破坏 软件安全性的方法和工具等。

可移植性（Portability）
第33页
测试策略小结




测试策略是软件测试的行动方针和实施方法 测试策略规划了软件测试的路线图 测试策略包括测试计划、资源分配、测试因素选择、 各个阶段的测试重点等综合信息 测试策略的目的是如何计划、组织测试活动，选取 适当的测试方法，发现更多的软件问题，有效的完 成测试任务
第34页
第35页

性能测试：
– 检查系统是否满足在需求中所规定达到的性能，性能主要 包括了解程序的内外部性能因素。内部性能因素包括测试 环境的配置，系统资源使用状况；外部因素包括响应时间， 吞吐量等。

压力测试：
– 压力测试又称强度测试，主要是检查系统运行环境在极限 情况下软件运行的能力，比如说给一个相当大的负荷或网 络流量给应用软件

正确性（Correctness）
– 系统的功能数据输入、处理流程、输出是否正 确。 – 程序满足它的需求规约和实现用户需求的程度
第19页
测试因素（3）

易用性（Ease of Use）
– 这是一个共性问题，任何用户都希望自己所使 用的系统是好用的。但对于不同的用户，对这 个因素的要求程度不一样，有一些只运行在后 台的进程，不需要操作员手工操作的系统，对 此项的要求不高。
– 可以在不同操作系统、不同数据库环境中运行 – 移植代码易于维护

耦合度（Coupling）
– 不同模块之间的关联是否紧密 耦合度高，集成性高，性能高 耦合度底，易于扩展

性能（Performance）
– 大容量数据及大访问量情况系统的响应速度
第23页
测试因素

访问控制（Access Control） 可移植性（Portability） 耦合度（Coupling） 性能（Performance） 易维护性（Maintainability） 权限控制（Authorization） 进程的连续性（Continuity of processing） 过程的可跟踪性（Audit trail） 文件完整性（File Integrity） 服务等级（Service levels） 易用性（Ease of Use） 易掌握程度（Ease of operation） 符合度（Compliance） 正确性（Correctness）

可安装性测试：
– 主要检查软件能否按照其可能发生的安装过程和配置正确， 成功的安装软件。

界面测试：
– 主要为了测试基于UI界面的测试
第29页
测试类型举例（4）

启动/停止测试：
– 检查系统，启动，停止，监控，维护等相关的 功能是否正常

文档测试：
– 检查内部/外部文档的清晰性和准确性，对外部 文档而言，还必须考虑文档的简单明了，相关 的技术术语是否解释清晰等方面的检查。
软件测试流程的质量决定测试是否成功
第11页
测试什么时候开始 ？

测试应从需求开始 测试越早开始，效率越高
第12页
缺陷放大
600 500 400 300 200 100 0 缺陷数量 需求 设计 编码 测试 维护
第13页
尽早开始测试

有50%的错误是在需求阶段产生的。修复这些缺陷 的代价，远小于这些缺陷转移后的代价 抓住机会，在开发的早期进入测试，达到事半功倍 的效果
测试管理 高级培训教程
主讲人：王国彬
第1页
第2页
测试策略

策略：根据实际情况制定的行动方针和实施方式 测试策略：把软件测试用例的设计方法集成到一系 列周密计划的测试流程中，为软件测试提供一个清 晰的路线图，以指导软件测试的成功完成。

第3页
测试策略（2）

测试策略包括计划、测试case设计、测试执行、测 试结果收集和分析

第14页
测试什么时候结束？

测试没有止境，只是从开发转到测试，测试转到维 护，维护转到客户

时间、资源不够的时候，就到了测试该结束的时候
第15页
量化的软件故障模型
第16页
测试结束的标准




建立在量化基础上 随着测试时间，单位之间里的bug数减少 当故障模型曲线趋近于直线，且单位时间发现 bug很少，甚至为0时，可以做为一个 milestone 随着运行环境、需求的变化，故障曲线会发生 变化
第9页
不成熟组织中的测试流程

测试有自己的周期，和开发生命周期并行 测试组和一个不成熟的开发组织一起工作，将感 到非常痛苦 不成熟的开发组织将产生一个非产品化、混乱的、 屡受搓折的环境中产生低质量的 不另人满意的结 果


第10页
成熟组织中的测试流程


在一个成熟的开发组织中，测试组可以并能够集中 精力在内部流程改进上 测试流程的有效改革将会成为促进不成熟组织改进 开发流程的催化剂
测试流程中的问题
1、如何组建测试team 2、怎样执行测试活动 3、怎样设计测试用例 4、如何写好bug report 5、如何维护软件版本 6、如何衡量测试的质量
测试流程改进
第36页
测试流程改进的六要素

软件测试质量根本上是软件流程决定的。 预防缺陷转移在软件生命周期的早期 要有专人对测试流程负责 测试是专业学科，需要经过培训，有专业技能的人 培养一只高效的有创造性破坏观点的团队 适当的选则合适的测试工具

兼容测试：
– 测试软件产品在不同的平台，不同的工具，相同工具的不 同版本下功能的兼容性。
第28页
测试类型举例（3）

接口测试：
– 在模块组装测试中，很多问题出现在接口部分。单个模块 的功能实现了，但组装在一起，就无法正常工作。接口测 试要包括两部分的测试：（1）根据设计文档，构造测试 数据，验证接口是否正确（2）将接口关联的模块组装在 一起进行连调测试。接口测试可以同时检查设计文档的正 确性。

配置测试：
– 原本主要是测试整个系统中各个设备，资源之 间的功能，可控度和可维护程度。现在主要说 明的是基于配置文件所提供的各种功能，选项 的测试。
第30页
测试类型举例（5）

易用性测试：
– 从使用的合理性和方便程度对系统及软 件进行相关的测试和检查，在不影响程 序主体和耗费时间太长的前提下，建议 多从客户的使用角度来考虑

与开发独立，可以明确工作界面，减少开发 人员和开发leader对测试结果的主观影响。
作为一个职能部门，与开发处于同等重要的作 用。

第6页
ITG的职责





制定产品测试计划 划分每个测试阶段及测试重点 设计测试case 开发测试程序 执行测试，申报bug 向组织提交测试报告 进行技术转移 参加产品实施
第37页
关于测试team的建立

明确职能：
– 责、权、利统一

人员招聘：
– 了解并乐意从事测试工作、具有专业技能 、有很好的学习 能力 、勾通能力

测试管理流程需要考虑的：
– bug管理工具、版本控制工具
第38页
测试Team组成（1）

Team Leader
– – – – – – – – – 有丰富的业务知识和技术背景 有良好的组织、协调、管理能力 负责测试人员招聘 制定测试规范及测试流程 设计测试有关的模板 负责主要产品的测试计划和方案制定 跟踪测试进度 协调与开发及售后相关部门的关系 团队建设，树立测试team在整个组织中的威信