软件测试演义2——思想篇

《软件测试演义2——思想篇》由会员分享，可在线阅读，更多相关《软件测试演义2——思想篇（14页珍藏版）》请在金锄头文库上搜索。

1、软件测试演义软件测试演义第二部分第二部分 理论思想篇理论思想篇作者：朱少民 出处：CSDN理论思想篇理论思想篇第第 1 回回 V 模型，我的完整诠释模型，我的完整诠释万事开头难，第一回起头自然比较难，我选择了“V 模型，我的完整诠释”作为开始。因为，软件测试的思 想方法是建立在软件开发过程模型（思想）基础之上，例如测试驱动开发来源于敏捷开发思想。在这里，也 是假定 V 模型是大家更好理解软件测试思想和方法的基础。现在谈 V 模型，是否落后于时代？不一定，实际许多软件过程思想是相通的，例如迭代模型、增量模型和 螺旋模型都可以归为“分阶段开发”思想这一类。极限编程（XP）对于现在 Internet

2、 服务模式的软件开发很有 效，也只适合软件开发的小团队。V 模型适合企业级的软件开发，它更清楚地揭示了软件开发过程的特性及 其本质。V 模型是在快速应用开发 (RAD，Rap Application Development)模型基础上演变而来，由于将整个开发过程 构造成一个 V 字形而得名。V 模型强调软件开发的协作和速度，将软件实现和验证有机地结合起来，在保证 较高的软件质量情况下缩短开发周期。下面通过对这种模型的水平和垂直的关联和比较分析，理解软件开发和测试的关系，理解 V 模型具有面向 客户、效率高、质量预防意识等特点，能帮助我们建立一套更有效的、更具有可操作性的软件开发过程。1从水平对

3、应关系看左边是设计和分析，是软件设计实现的过程，同时伴随着质量保证活动审核的过程，也就是静态的测 试过程；右边是对左边结果的验证，是动态测试的过程，即对设计和分析的结果进行测试，以确认是否满足 用户的需求。如：需求分析和功能设计对应验收测试，说明在做需求分析、产品功能设计的同时，测试人员就可以阅读、 审查需求分析的结果，从而了解产品的设计特性、用户的真正需求，确定测试目标，可以准备用例 (Use Case)并策划测试活动。 当系统设计人员在做系统设计时，测试人员可以了解系统是如何实现的，基于什么样的平台，这样可 以设计系统的测试方案和测试计划，并事先准备系统的测试环境，包括硬件和第三方软件的采

4、购。因 为这些准备工作，实际上是要花去很多时间。 当设计人员在做在做详细设计时，测试人员可以参与设计，对设计进行评审，找出设计的缺陷，同时 设计功能、新特性等各方面的测试用例，完善测试计划，并基于这些测试用例以开发测试脚本。 在编程的同时，进行单元测试，是一种很有效的办法，可以尽快找出程序中的错误，充分的单元测试 可以大幅度提高程序质量、减少成本。 从中可以看出，V 模型使我们能清楚地看到质量保证活动和项目同时展开, 项目一启动，软件测试的工作 也就启动了,避免了瀑布模型所带来的误区软件测试是在代码完成之后进行。2从垂直方向看水平虚线上部表明，其需求分析、定义和验收测试等主要工作是面向用户，要

5、和用户进行充分的沟通和交 流，或者是和用户一起完成。水平虚线下部的大部分工作，相对来说，都是技术工作，在开发组织内部进行， 主要是由工程师、技术人员完成。从垂直方向看，越在下面，白盒测试方法使用越多，到了集成、系统测试，更多是将白盒测试方法和黑盒 测试方法结合起来使用，形成灰盒测试方法。而在验收测试过程中，由于用户一般要参与，使用黑盒测试方 法。第第 2 回回 究竟什么是软件测试？究竟什么是软件测试？在 G.J.Myers 的经典著作软件测试之艺术（The Art of Software Testing）中，给出了测试的定义：“程序 测试是为了发现错误而执行程序的过程”。这个定义，被业界所认可

6、，经常被引用。除此之外，G.J.Myers 还 给出了与测试相关的三个重要观点，那就是：1. 测试是为了证明程序有错，而不是证明程序无错误； 2. 一个好的测试用例是在于它能发现至今未发现的错误； 3. 一个成功的测试是发现了至今未发现的错误的测试。 实际上，这里暗示了“软件测试”在不同侧面上的含义，也就决定了对软件测试不同的定义和不同的理解。 根据作者多年的经验和理解，软件测试的不同视野，概括为如下 5 类：软件测试的狭义论和广义论静态和动态的测试 软件测试的辨证论正向思维和反向思维 软件测试的风险论测试是评估 软件测试的经济学观点为盈利而测试 软件测试的标准论验证和确认 1. 软件测试的狭

7、义论和广义论G.J.Myers 所给出了测试定义“程序测试是为了发现错误而执行程序的过程”，实际是一个狭义的概念， 因为他认为测试是执行程序的过程，也就是传统意义上的测试在代码完成后，通过运行程序来发现程序 代码或软件系统中错误。但是，这种意义上的测试是不能在代码完成之前发现软件系统需求、发现设计上的 问题，把需求、发现设计上的问题遗留到后期，这样就会可能造成设计、编程的部分返工。增加软件开发的 成本、延长开发的周期等。需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。 这种狭义论是受软件开发瀑布模型影响。正是为了更早地发现问题，所以将测试延伸到需求评审、设计审查活动中去

8、，也就是将“软件质量保证”的 部分活动归为测试活动。实际上，在软件开发实际操作中，常常将软件测试和质量保证这两种努力 （efforts）合并起来。延伸后的软件测试，被认为是一种软件测试的广义概念。这就引出软件测试的两个概念“静态测试”和“动态 测试”，如 测试方法的辩证统一 （1）所述，这样就由静态测试和动态测试构成一个全过程的、完整的软件 测试，而且静态测试显得更为重要。2.软件测试的辨证论 G.J.Myers 的第 2 个观点“测试是为了证明程序有错，而不是证明程序无错误”，引出了软件测试的另外一个 争论，软件测试究竟是证明所有软件的功能特性是正确的呢？还是其反向思维对软件系统进行各种试探

9、 和攻击，找出软件系统中不正常或不工作的地方呢？从我个人理解，这两个方面都有一定道理，前者（证明 所有软件的功能特性是正确的）是从质量保证的角度来思考软件测试，后者（证明程序有错）从软件测试的 直接目标和测试效率来思考，两者应该相辅相成。在后者的思想背景下，我们认为，测试不是为了证明所有 的功能可以正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的地方。也就是说，测试 的一般工作就是发现缺陷 (detect bug)，即在软件开发过程中，分析、设计与编码等工作都是建设性的，而测 试是带有“破坏性”的工作。对于不同的应用领域，两者的比重是不一样的，如国防、航天、银行等软件系统，承受

10、不了任何系统失效， 因为一次系统的失效完全有可能导致灾难性的损失，所以强调前者以保证非常高的软件质量。而一般的软件 服务应用则不同，强调后者，质量目标设置在“用户可接受水平”，不要国度追求质量，从而可以降低软件开 发成本。作者建议，在我们实际操作中，可以分阶段实施不同的测试思想，在早期阶段集中在“证明程序有错” 发现 Bug，后期集中在验证所有特性是否正常工作降低风险，见作者的另外一篇讨论：测试执行中 非常有效的策略 下面就是这两种观点的基本描述：验证软件是验证软件是“工作的”，以正向思维，针对软件系统的所有功能点，逐个验证其正确性。其 代表人物是软件测试领域的先驱 Dr. Bill Hetz

11、el （代表论著The Complete Guide to Software Testing) 。 证明软件是“不工作的”，以反向思维方式，不断思考开发人员理解的误区、不良的习惯、程序代码的 边界、无效数据的输入以及系统的弱点，试图破坏系统、摧毁系统，目标就是发现系统中各种各样的 问题。其代表人物就是上面多次提到的 G.J.Myers。他强调，一个成功的测试必须是发现 Bug Bug 的 测试，不然就没有价值。 3.软件测试的风险论 测试被定义为“对软件系统中潜在的各种风险进行评估的活动”，这就是软件测试的风险论。软件测试自身 的风险性是大家公认的，测试的覆盖度不能做到 100。测试的这种风险

12、定义一方面源于这层含义，另外软 件测试的标准有时不清楚，“软件规格说明书（Specification/ Spec）”是其中的一个标准，但也不是唯一的， 因为 Spec 中有些内容完全有可能是错误的。所以，我们常常强调软件测试人员应该站在客户的角度去进行测 试，除了发现程序中的错误，还要发现需求定义的错误、设计上的缺陷，可以针对 Spec 去报 Bug。但是， 测试在大多数时间/情况下,是由工程师完成，而不是客户自己来做，所以又怎么能保证工程师和客户想得一 样呢？有人把开发比作打靶，目标明确，就是按照 Spec 去实现系统的功能。而把测试比作捞鱼，目标不明确， 自己判断哪些地方鱼多，就去哪些地方

13、捞；如果只捞大鱼（严重缺陷），网眼就可以大些、撒网区域相对比 较集中（测试点集中在主要功能-major features）。如果想把大大小小的鱼捞上来，网眼就要小、普遍撒网，不放过任何一块区域（测试点遍及所有功能all features）。在“风险”论的框架下，软件测试可以被看作是一个动态的监控过程，对软件开发全过程进行检测，随时发 现不健康的征兆，发现问题、报告问题，并重新评估新的风险，设置新的监控基准，不断地持续下去，包括 回归测试。这时，软件测试可以完全看作是软件质量控制的过程。对应这种观点，产生基于风险的测试策略，首先评估测试的风险，功能出问题的概率有多大？哪些是用户 最常用的 20功

14、能Pareto 原则（也叫 80/20 原则）？如果某个功能出问题，其对用户的影响有多大？然 后根据风险大小确定测试的优先级。优先级高的测试，优先得到执行，一般来讲，针对用户最常用的 20功 能（优先级高）的测试会得到完全执行，而低优先级的测试（另外用户不经常用的 80功能）就不是必要的， 如果时间或经费不够，就暂时不做或少做。4.软件测试的经济学观点软件测试的经济学观点“一个好的测试用例是在于它能发现至今未发现的错误”，体现了软件测试的经济学观点。实际上，软件测 试经济学问题至今仍是业界关注的问题之一。经济学的核心就是要盈利，盈利的基础就是要有一个清楚的商 业性目标。同样，商业性目标是否正确

15、，直接决定了企业是否盈利的结果。多数情况下，软件测试是在公司 内的执行。正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅正是公司的行为目的，决定了软件测试含义或定义的经济性一面。正如，对软件质量的定义不仅 仅局陷于仅局陷于“和客户需求的一致性、适用性和客户需求的一致性、适用性”，而且要增加其它的要求，而且要增加其它的要求“预算内、按时发布、易于维护预算内、按时发布、易于维护”。软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而软件测试也一样，要尽快尽早地发现更多的缺陷，并督促和帮助开发人员修正缺陷。原因很简单：平均而

16、 言，如果在需求阶段修正一个错误的代价是言，如果在需求阶段修正一个错误的代价是 1，那么，在设计阶段就是它的，那么，在设计阶段就是它的 36 倍，在编程阶段是它的倍，在编程阶段是它的 10 倍，在内部测试阶段是它的倍，在内部测试阶段是它的 2040 倍，在外部测试阶段是它的倍，在外部测试阶段是它的 3070 倍，而到了产品发布出去时，这个数倍，而到了产品发布出去时，这个数 字就是字就是 40 1000 倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。倍。修正错误的代价不是随时间线性增长，而几乎是呈指数级增长的。5. 软件测试的标准论如果从标准论来看软件测试，可以定义为软件测试就是“验证（Verification）”和“有效性确认（Validation）” 活动构成的整体，即软件测试 = V&V。“验证”是检验软件是否已正确地实现了产品规格书所定义的系统功能和特性。验证过程提供证据表明软件 相关产品与所有生命周期活动的要求（如正确性、完整性、