完整的测试流程与怎样提高测试效率

❖ 软件测试员的目标是尽可能早的找出软件缺 陷，并确保其得以修复。
7
2、基于不同的立场，存在着两种完全不 同的测试目的
❖ 从用户的角度出发，普遍希望通过软件测试暴露 软件中隐藏的错误和缺陷，以考虑是否可接受该 产品。
❖ 从软件开发者的角度出发，则希望测试成为表明 软件产品中不存在错误的过程，验证该软件已正 确地实现了用户的要求，确立人们对软件质量的 信心
29
3.并非所有软件缺陷都能修复
❖ 没有足够的时间—必须保证按时完成 ❖ 不算真正的软件缺陷 ❖ 修复的风险太大—修复一个可能导致其他 ❖ 不值得修复—不常出现或在不常用功能中出现的
对于软件缺陷是否应该修复，其决来自百度文库过程 应由软件测试员、项目管理员和程序员共 同参与。
30
五、提高测试效率
1、软件中存在的问题
1.完全测试程序是不可能的
❖输入量太大 ❖输出结果多 ❖软件实现途径太多 ❖软件说明书没有客观标准
28
2.软件测试是有风险的行为
❖如果试图测试所有情况，费用将大幅增加，软 件缺陷漏掉的数量并不会随费用上涨而显著下 降。
❖如果减少测试或者错误地确定测试对象，那么 费用很低，但是会漏掉大量软件缺陷。 （每个项目都有一个最优的测试量）
10
三、测试过程概述
Testing Process
3.1 常见的测试过程模型
❖瀑布模型 ❖ V模型 ❖ W模型 ❖ X模型 ❖ H模型
12
瀑布模型
❖ 瀑布模型的核心思想是按 工序将问题化简，将功能 的实现与设计分开，采用 机构化的分析与设计方法 将逻辑实现与物理实现分 开。
❖ 软件生命周期划分为制定 计划、需求分析、软件设 计、程序编写、软件测试、 运行维护。
❖ 5）独立测试人员应该在软件开发的需求阶段就 参与项目的研制，以便更好地制定测试计划、 确定测试目标及编写测试用例。
❖ 6）被测软件在测试中发现了问题，要进行有组 织的分析研究，然后权衡利弊进行规范化修改 ，避免反复修改，反复测试。
❖ 7）规范软件配置管理，通过管理及技术手段， 对软件和文档版本进行控制，保障软件测试的 有效性。
4、结论
通过提高被测软件的可测试性，以及合理 组织软件测试工作，可以有效地提高软件测试 效率。随着软件测试的重要性得以承认，软件 测试阶段在整个软件开发周期中所占的比重也 日益增大。为了将缺陷和错误消灭在萌芽之中， 软件测试将逐步发展成为软件开发每一阶段都 要进行而且需要反复进行的活动。软件测试中 大量的工作是机械的、重复的、枯燥的和非智 力的，但逐步加强软件自动化测试的研究和推 广将是今后软件产业的发展趋势。
43
❖ H模型指出，软件测试要尽早准备，尽早执行。 ❖ 当某个测试时间点就绪时，软件测试即从测试准
备阶段进入测试执行阶段。 ❖ 软件测试可以根据被测物的不同而分层次进行。
不同的测试活动可以是按照某个次序先后进行的 。但也可能是反复的,只要某个测试达到准备就绪 点,测试执行活动就可以开展。
26
四、测试效率
39
❖白盒测试(white box testing)：结构性测试
基于覆盖全部代 码、分支、路径 、条件的测试。
由于实现是已知的，测试人员可以严格描 述要测试的确切内容。
40
软件测试的组织
❖ 1）根据不同测试人员的特点进行测试分工。 ❖ 2）软件测试人员应注重与用户的沟通，及早发
现需求分析、理解不合理的问题，避免今后花 费大量的资源和时间进行改正。 ❖ 3）对于软件开发人员，需加强测试方法的培训 ，提高自我测试的效率。 ❖ 4）在选择独立测试人员时，尽量选择比较熟悉 了解被测软件相关领域知识的人员。
各个阶段的划分完全固定，阶段之间产生大量 的文档，极大地增加了工作量。
由于开发模型是线性的，用户只有等到整个过 程的末期才能见到开发成果，从而增加 了开发 的风险。
17
测试传统模型-V模型
V模型是最广为人知的测 试模型
由Paul Rook在２０世纪 ８０年代后期提出的，旨 在改进软件开发的效率和 效果。
14
瀑布模型的优点
❖ 为项目提供了按阶段划分的检查点。 ❖ 当前一阶段完成后，您只需要去关注后续阶段。 ❖ 可在迭代模型中应用瀑布模型。
15
缺点
❖在项目各个阶段之间极少有反馈。 ❖只有在项目生命周期的后期才能看到结果。 ❖通过过多的强制完成日期和里程碑来跟踪各个
项目阶段。
16
总结
传统的瀑布模型，软件测试的地位和价值并没 有体现出来，测试只能作为一个事后补救工作。 早期的错误可能要等到开发后期的测试阶段才 能发现，进而带来严重的后果。
试也是与此并行的V。 ❖ 相对于V模型，W模型增加了软件各开发阶段中
应同步进行的验证和确认活动。
21
W模型
❖ 测试伴随整个软 件开发周期，而 且测试的对象不 仅仅是程序，需 求、设计等同样 要测试，测试与 开发是同步进行 的。
❖ W模型有利于尽 早地全面的发现 问题。
22
W模型的缺点
❖ W模型也存在局限性。在W模型中，需求、设计、 编码等活动被视为串行的，同时，测试和开发 活动也保持着一种线性的前后关系，上一阶段 完全结束，才可正式开始下一个阶段工作。这 样就无法支持迭代的开发模型。
完整的测试流程与怎样提高测试效率
Contents
一、 软件缺陷 二、 软件测试 三、 完整的测试流程 四、 测试效率 五、怎样提高测试效率
一、软件缺陷
1、软件缺陷是什么？
❖ 定义：只有符合下列5个规则的软件问题，我们 将其定义为软件缺陷（software fault）
软件未达到产品说明书标明的功能 软件出现了产品说明书指明不会出现的错误 软件功能超出产品说明书指明范围 软件未达到产品说明书虽未指出但应达到的目标 软件测试员认为软件难以理解、不易使用、运行速度
己通过集成测试的成品可以进行封 装并提交给用户，也可以作为更大 规模和范围内集成的一部分。多根 并行的曲线表示变更可以在各个部 分发生。
X模型还定位了探索性测试，这是 不进行事先计划的特殊类型的测试， 给有经验的测试人员在测试计划之 外发现更多的软件缺陷。
24
H模型
25
H模型
❖ 在H模型中，软件测试过程是一个独立的流程，贯 穿于整个产品周期，与其他流程并发地进行。
从左到右，描述了基本的 开发过程和测试行为
非常明确地标明了测试过 程中存在的不同级别，描 述了这些测试阶段和开发 过程期间各阶段的对应关 系
18
V模型（测试与开发阶段对应关系）
❖单元和集成测试应检测程序的执行是否满足软 件设计的要求；
❖系统测试应检测系统功能、性能的质量特性是 否达到系统要求的指标；
❖ 规定活动自上而下、相互
衔接的固定次序，逐级下
13
落。
瀑布模型的重要地位
瀑布模型是最早出现的软件开发模型，在软 件工程中占有重要的地位，它提供了软件开发的 基本框架。其过程是从上一项活动接收该项活动 的工作对象作为输入，利用这一输入实施该项活 动应完成的内容给出该项活动的工作成果，并作 为输出传给下一项活动。同时评审该项活动的实 施，若确认，则继续下一项活动；否则返回前面， 甚至更前面的活动。对于经常变化的项目而言， 瀑布模型毫无价值。
❖验收测试确定软件的实现是否满足用户需要或 合同的要求。
19
V模型的缺陷
❖ 存在局限性，仅仅把测试过程作为在需求分析、 系统设计及编码之后的一个阶段，只针对程序 进行的寻找错误的活动，忽视了测试活动对需 求分析,系统设计等活动的验证和确认的功能， 直到后期的验收测试才被发现。
20
W模型
❖ W模型由Evolutif公司提出。 ❖ W模型从V模型演化过来，实际上开发是V，测
37
3、软件测试方法与组织
❖ 3.1软件测试方法 ❖ 3.2软件测试人员 ❖ 3.3通过软件测试的组织提高软件测试效率
38
黑盒测试的优点：
❖ 黑盒测试（功能性测试）与软件如何实现无关， 所以如果实现发生变化，测试用例仍然有用；
❖ 测试用例开发可以与实现并行进行，可缩短项目 总的开发时间。
不足！！测试用例之间可能存在严重的冗 余，此外可能还会有未测试的软件漏洞
缓慢、或者最终用户认为不好。
4
2、为什么会出现软件缺陷？
❖ 从小程序到大项目的无数研究得出：导致软
件缺陷最大的原因是产品说明书（需
求） ❖ 其次的原因是设计方案的问题。
其他 设计 编制说明书 编写代码
5
二、软件测试
1、软件测试员的工作
❖ 软件测试员是客户的眼睛，是第一次看到软 件的人，代表客户说话，应力求完美。
❖ 对于当前软件开发复杂多变的情况，W模型并 不能解除测试管理面临着困惑。
23
X模型
很好地处理测试与开发的交接过程 （交接的过程是一个时间段，而不 是一个点）
左边描述的是针对单独程序片段所 进行的相互分离的编码和测试，此 后将进行频繁的交接，通过集成最 终合成为可执行的程序，然后再对 这些可执行程序进行测试。
8
换言之，测试的目的是：
❖ 以最少的时间和人力，系统地找出软件中潜在的 各种错误和缺陷。
❖证明 ❖检测 ❖预防
9
测试对象
❖ 软件测试并不等于程序测试。软件测试应贯穿于 软件定义与开发的整个期间。
❖ 需求分析、概要设计、详细设计以及程序编码等 各阶段所得到的文档，包括需求规格说明、概要 设计规格说明、详细设计规格说明以及源程序， 都应成为软件测试的对象。
❖ 1.1软件测试是软件开发的最后一个环节 ❖ 1.2软件测试目的不明确 ❖ 1.3忽视验证用户需求的正确性 ❖ 1.4以为单元测试和验收测试没有什么区别
32
❖产生上述问题的原因主要是没有完全理解软件 测试的方法，也就无法按照合理的软件测试流 程进行测试，导致测试效率的低下。
35
2、软件的可测试性
❖ 2.1可测试性软件的特征 ✓ 1）可操作性 ✓ 2）可观察性 ✓ 3）可控制性 ✓ 4）可分解性 ✓ 5）简单性 ✓ 6）稳定性 ✓ 7）易理解性
36
❖ 2.2提高软件可测试性的途径 ✓ 2.2.1减少并控制需求的变更 ✓ 2.2.2加强软件可测试性设计 ✓ 2.2.3重视并规范技术文档的编写