本节书摘来自异步社区《精通软件性能测试与LoadRunner最佳实战》一书中的第1章1.5节软件开发与软件测试的关系，作者于涌 , 王磊 , 曹向志 , 高楼 , 于跃，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.5 软件开发与软件测试的关系精通软件性能测试与LoadRunner最佳实战前面已经提到软件生命周期，大家已经清楚软件从无到有是需要需求人员、研发人员、测试人员、实施维护等人员相互协作的。作为软件测试人员，在从事软件测试工作的同时，最好对软件的研发过程有一个整体的了解。随着信息技术和各行各业的蓬勃发展，现在的软件系统通常都比较复杂，一个新的软件产品研发过程少则需要几个人，多则需要几百人、数千人来协同完成，下面我们就来看一看软件的开发模式。
常见的几种软件开发模式从开始构思到正式发布软件产品的过程称为软件开发模式。一个软件系统的顺利完成是和选择正确的、适宜的软件开发方法，严格地按照整个开发进程密不可分的。
由于软件开发需求和规模各不相同，因此，在实际工作中也有针对性地运用了多种开发模式，下面给大家介绍一下。
1．直接编写法在早期的软件开发过程中，通常由于软件的规模比较小，有些开发人员不遵从软件工程的思想，直接编写代码，而不经过前期的概要设计、详细设计等过程，通常会有两种结果。第一种结果是开发出来的软件非常优秀（开发人员思路非常清晰，代码编写能力非常强）；第二种结果是软件产品开发失败（毕竟在开发过程中，能够很好掌控整体构架，并能够很好实现细节的开发人员还是很少）。
直接编写法的优点显而易见就是思路简单，对开发人员的要求很高，要求开发人员必须思路清晰，因为多数时候功能模块的实现是依赖于开发人员的“突发奇想”，由于不需要编写相应的需求、设计等文档，软件开发过程有可能会缩短。其缺点也非常明显，就是这种方法没有任何计划、进度安排和规范的开发过程，软件项目组成员的主要精力花费在程序开发的设计和代码编写上，它的开发过程是非工程化的。这种方法的软件测试通常是在开发任务完成后进行，也就是说已经形成了软件产品之后才进行测试。测试工作有的较容易，有的则非常复杂，这是因为软件及其说明书在最初就已完成，待形成产品后，已经无法回头修改存在的问题，所以软件测试的工作只是向客户报告软件产品经过测试后发现的情况。
通过上面的介绍，大家不难发现这种开发软件方法存在着很大的风险，但是，现行软件产品通常都是功能繁多、业务处理复杂的产品，这些软件产品开发工作应当避免采用直接编写法作为软件开发的方法。
2．边写边改法软件的边写边改开发模式是软件项目小组在没有刻意采用其他开发模式时常用的一种开发模式。它是对直接编写法的一种改进，参考了软件产品的要求。这种方法通常只是在开发人员有了比较粗略的想法就开始进行简单设计，然后进行较长的反复编写、测试与修复这样一个循环的过程，在认为无法更精细地描述软件产品要求时就发布产品。因为从开始就没有计划和文档的编制，项目组织能够较为迅速地展示成果。因此，边写边改模式极其适合用在快速制作的小项目上，如示范程序与演示程序比较适合采用该方法。
处于边写边改开发项目组的软件测试人员要明确的是，测试人员和开发人员有可能长期陷入循环往复的开发过程中。通常，新的软件（程序）版本在不断地产生，而旧的版本的测试工作可能还未完成，新版本软件（程序）还可能又包含了新的或已修改的功能。
在进行软件测试工作期间，边写边改开发模式最有可能遇到。虽然它有缺点，但它是通向采用合理软件开发的路子，有助于理解更正规的软件开发方法。
3．瀑布法1970年，WinSTon Royce提出了著名的“瀑布模型”，直到20世纪80年代早期，它一直是被广泛采用的软件开发模型。瀑布模式是将软件生命周期的各项活动规定为按照顺序相连的若干个阶段性工作，形如瀑布流水，最终得到软件产品，如图1-4所示。瀑布模式本质上是一种线性顺序模型，因此存在着较明显的缺点，各阶段之间存在着严格的顺序性和依赖性，特别强调预先定义需求的重要性，在着手进行具体的开发工作之前，必须通过需求分析预先定义并“冻结”软件需求，然后再一步一步地实现这些需求。但是实际项目很少遵循着这种线性顺序进行的。虽然瀑布模式也允许迭代，但这种改变往往对项目开发带来混乱。在系统建立之前很难只依靠分析就确定出一套完整、准确、一致、有效的用户需求，这种预先定义需求的方法更不能适应用户需求不断变化的情况。
（1）瀑布开发模式优点。① 各个阶段之间具有顺序性和依赖性。
② 推迟程序的物理实现。
③ 每个阶段必须完成规定的文档；每个阶段结束前完成文档审查，对修正错误起到一定作用。
④ 易于组织，易于管理。
⑤ 是一种严格线性的、按阶段顺序的、逐步细化的过程模型（开发模式）。
（2）瀑布开发模式缺点。
① 在项目开始的时候，用户常常难以清楚地给出所有需求。
② 用户与开发人员对需求理解存在差异。
③ 顺序的开发流程使得开发中的经验教训不能反馈到该项目的开发中去，实际的项目很少按照顺序模式进行。
④ 因为瀑布模式确定了需求分析的绝对重要性，但是在实践中要想获得完善的需求说明是非常困难的，导致出现“阻塞状态”情况发生。
⑤ 开发中出现的问题直到开发后期才能够显露，因此失去及早纠正的机会。
⑥ 不能反映出软件开发过程的反复与迭代性。
（3）瀑布开发模式适用场合。
① 对于有稳定的产品定义和易被理解的技术解决方案时，使用瀑布模式非常适合。
② 对于有明确定义的版本进行维护或将一个产品移植到一个新的平台上，使用瀑布模式也比较适合。
③ 对于那些易理解但很复杂的项目，应用瀑布模式同样比较合适，因为这样的项目可以用顺序方法处理问题。
④ 对于那些质量需求高于成本需求和进度需求的项目，使用瀑布模式处理效果也很理想。
⑤ 对于那种研发队伍的技术力量比较薄弱或者新人较多缺乏实战经验的团队，采用瀑布模式也非常合适。
4．快速原型法根据客户需求在较短的时间内解决用户最迫切解决的问题，完成可演示的产品。这个产品只实现最重要功能，在得到用户的更加明确的需求之后，原型将丢弃。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。显然，快速原型方法可以克服瀑布模式的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。快速原型实施的关键在于尽可能快速地建造出软件原型，一旦确定了客户的真正需求，所建造的原型将被丢弃。因此，原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求，如图1-5所示。图1-5 快速原型开发模式5．螺旋模式法1988年，Barry Boehm正式发表了软件系统开发的“螺旋模式”，他将瀑布模式和快速原型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代，图1-6中的4个象限代表了以下活动。
（1）规划：确定软件目标，选定实施方案，弄清项目开发的限制条件。
（2）风险分析：分析评估所选方案，考虑如何识别和消除风险。
（3）原型开发：实施软件开发和验证。
（4）用户评审：评价开发工作，提出修正建议，制订下一步计划。图1-6 螺旋模式法螺旋模式有风险分析，强调可选方案和约束条件，从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。螺旋模式的第一个阶段是确定该阶段的目标——制订计划，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。螺旋模式是瀑布模式与边写边改演化模式相结合，并加入风险评估所建立的软件开发模式。主要思想是在开始时不必详细定义所有细节，而是从小开始，定义重要功能，尽量实现，接受客户反馈，进入下一阶段，并重复上述过程，直到获得最终产品。但是，螺旋模式也有一定的限制条件，具体如下。
（1）螺旋模式强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的，因此，这种模式往往适应于内部的大规模软件开发。
（2）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模式只适合于大规模软件项目。
（3）软件开发人员应该擅长寻找可能的风险，准确地分析风险，否则，将会带来更大的风险。
测试与开发各阶段的关系测试应该从生命周期的第一个阶段开始，并且贯穿于整个软件开发的生命周期。生命周期测试是对解决方案的持续测试，即使在软件开发计划完成后或者被测试的系统处于执行状态的时候，都不能中断测试。在开发过程的几个时期，测试团队所进行的测试是为了尽早发现系统中存在的缺陷。软件的开发有其自己的生命周期，在整个软件生命周期中，软件都有各自的相对于各生命周期的阶段性的输出结果，其中也包括需求分析、概要设计、详细设计及程序编码等各阶段所产生的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序等，而所有这些输出结果都应成为被测试的对象。测试过程包括了软件开发生命周期的每个阶段。在需求阶段，重点要确认需求定义是否符合用户的需要；在设计和编程阶段，重点要确定设计和编程是否符合需求定义；在测试和安装阶段，重点是审查系统执行是否符合系统规格说明；在维护阶段，要重新测试系统，以确定更改的部分和没有更改的部分是否都正常工作，如图1-7所示。
基于“V”模型，如图1-8所示。在开发周期中的每个阶段都有相关的测试阶段相对应，测试可以在需求分析阶段就及早开始，创建测试的准则。每个阶段都存在质量控制点，对每个阶段的任务、输入和输出都有明确的规定，以便对整个测试过程进行质量控制和配置管理。通常在测试中，使用验证来检查中间可交付的结果，使用确认来评估可执行代码的性能。一般来说，验证回答这样的问题：“是否建立了正确的系统？”，而确认回答的问题是：“建立的系统是否正确”。 所谓验证，是指如何决定软件开发的每个阶段、每个步骤的产品是否正确无误，并与其前面的开发阶段和开发步骤的产品相一致。验证工作意味着在软件开发过程中开展一系列活动，旨在确保软件能够正确无误地实现软件的需求。所谓确认，是指如何决定最后的软件产品是否正确无误。
测试的经济学观念随着信息技术的飞速发展，软件产业在国民经济中扮演着越来越重要的角色，各行各业对软件质量要求也越来越高，那么软件企业是不是为了保证产品的质量，测试人员就需要无限期地对软件产品测试下去呢？回答是否定的，从经济学的角度考虑就是确定需要完成多少测试，以及进行什么类型的测试。经济学所做的判断，确定了软件存在的缺陷是否可以接受，是否符合企业产品定义的质量标准。“太少的测试是犯罪，而太多的测试是浪费。”对风险测试得过少，会造成软件的缺陷和系统的瘫痪；而对风险测试得过多，就会使本来没有缺陷的系统进行没有必要的测试，或者是对轻微缺陷的系统所花费的测试费用远远大于它们给系统造成的损失。测试费用的有效性，可以用测试费用的质量曲线来表示，如图1-9所示。随着测试费用的增加，发现的缺陷也会越多，两线相交的地方是过多测试开始的地方，这时，发现缺陷的测试费用超过了缺陷给系统造成的损失费用。
由于市场和软件研发成本的影响，软件测试不可能无限期地测试下去，软件测试最佳的发布日期通常是在测试多轮以后，在较长的时期发现不了缺陷或者发现很少的缺陷（如2周、3周，甚至1、2个月也发现不了缺陷），但是该阶段耗费的研发成本日益增长的时候终止。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。 相关资源：敏捷开发V1.0.pptx