软件开发模型和软件测试模型基础知识

什么叫软件测试？

在规定的条件下对程序进行操作，以发现程序错误，衡量软件质量，并对其是否能满足设计要求进行评估的过程。称之为软件测试。

QA—Quality assurance, 质量保证，质量保证或者质量控制,从流程控制的角度进行保证软件质量。

QC—Quality control, 质量控制，从技术角度保证软件质量，产品的质量检验，发现质量问题后的分析、改善和不合格品控制相关人员的总称。

QA和QC的区别:

QA着重于对整个质量管理体系进行建立，维护与改善。而QC主要是产品质量检验，还包括产品相关的人，环境，设备的控制。

软件测试的目的：

发现程序中的错误，保证软件产品的最终质量。

软件测试的原则：

• 测试用例中一个必须部分是对预期输出或接口进行定义
• 程序员应避免测试自己编写的程序
• 编写软件的组织不应当测试自己编写的软件
• 应当彻底检查每个测试的执行结果
• 测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
• 检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
• 应避免测试用例用后即弃，除非软件本身就是个一次性的软件
• 计划测试工作时不应默许假定不会发现错误
• 程序某部分存在更多错误的可能性，与该部分已经发现错误的数量成正比

软件的可测性

软件的可测性太差会导致测试的难度相当大，甚至无法测试。这种情况往往是由于极差的软件架构设计和极为不规范的软件开发工作导致的。

• 紧耦合。不把大半个系统实例化就无法测试。
• 弱内聚。这个类实现了太多功能，导致测试非常复杂。
• 冗余。同一个方法在多处使用，每一处都得测。

好的软件架构应该是松耦合、高内聚的。提高软件的测试性的同时也提高了软件的可维护性和可管理性。

软件开发模型

瀑布模型

瀑布模型式是最典型的预见性的方法，严格遵循预先计划的需求分析、设计、编码、集成、测试、维护的步骤顺序进行。步骤成果作为衡量进度的方法，例如需求规格，设计文档，测试计划和代码审阅等等。瀑布式的主要有以下问题：

• 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
• 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
• 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。

因此，瀑布式方法在需求不明并且在项目进行过程中可能变化的情况下基本是不可行的。

瀑布模型的特点：

线性模型，是其他模型的基础

文档驱动，每个阶段只执行一次

瀑布模型的优点：

各个阶段比较清晰

当前阶段完成后只关注后续阶段

瀑布模型的缺点：

不适用需求变化的场景

风险滞后，失去及时纠错的机会

适用场景：

需求明确的大型项目

迭代开发模型

迭代式开发是一种与传统的瀑布式开发相反的软件开发过程，具有更高的成功率和生产率。在迭代开发中，整个开发工作被组织为一系列的短小的、固定长度（如3周）的小项目，逐步逐步的完成，故为迭代。每一次迭代都包括需求分析、设计、实现与测试。采用这种方法，开发工作可以在需求被完整地确定之前启动，并在一次迭代中完成系统的一部分功能或业务逻辑的开发工作。再通过客户的反馈来细化需求，并开始新一轮的迭代。迭代开发具有以下优点：

• 降低风险。如果开发人员重复某个迭代，那么损失只是这一个开发有误的迭代的花费。
• 适应需求变更。由于用户的需求并不能在一开始就作出完全的界定，它们通常是在后续阶段中不断细化的。
• 持续的测试与集成，降低后期的工作量与风险。

螺旋开发模型

螺旋开发，将瀑布模型和快速原型模型结合起来，强调了其他模型所忽视的风险分析，特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小，当项目被定义得更好、更稳定时，逐渐展开。 “螺旋模型”的核心就在于不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵，定义最重要的功能，实现它，然后听取客户的意见，之后再进入到下一个阶段。如此不断轮回重复，直到得到您满意的最终产品。 螺旋开发分为以下四个阶段：

• 制定计划：确定软件目标，选定实施方案，弄清项目开发的限制条件；
• 风险分析：分析评估所选方案，考虑如何识别和消除风险；
• 实施工程：实施软件开发和验证；
• 客户评估：评价开发工作，提出修正建议，制定下一步计划。

一个阶段首先是确定该阶段的目标，完成这些目标的选择方案及其约束条件，然后从风险角度分析方案的开发策略，努力排除各种潜在的风险，有时需要通过建 造原型来完成。如果某些风险不能排除，该方案立即终止，否则启动下一个开发步骤。最后，评价该阶段的结果，并设计下一个阶段。

敏捷开发模型

敏捷开发是一种指导思想，一种新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

什么是Scrum？

scrum是迭代式增量软件开发过程。

Scrum的英文意思是橄榄球运动的一个专业术语，表示“争球”的动作；把一个开发流程的名字取名为Scrum，我想你一定能想象出你的开发团队在开发一个项目时，大家像打橄榄球一样迅速、富有战斗激情、人人你争我抢地完成它，你一定会感到非常兴奋的。

而Scrum就是这样的一个开发流程，运用该流程，你就能看到你团队高效的工作。

极限编程（XP）

极限编程是敏捷开发的一种方法，极限编程针对小型的开发团队来说是一个不错的方法。

极限编程本质是务实主义的体现，快速稳定的实现每一个用户要求，是极限编程的基本要求。

客户尽量和开发人员在一起，一是可以知道开发的进度；二是可以和开发人员进行沟通，实时调整功能点的优先级。

Kanban

Kanban的关键思想之一是避免产生过剩。Kanban通过使用Kanban卡和Kanban板来可视化资源在生产周期中的移动。这使每个人都能够最大程度地了解流程，并帮助管理人员实时解决盈余/短缺问题。

Kanban系统还引入了“pull”与“push”的概念，工人可以根据自己的能力进行工作，而不是在传送带上或在待办事项列表形式中工作。

Kanban开发的另一个方面是，活动始终与客户需求紧密相关，并与客户保持持续的沟通。除非在经济上有利于客户，否则什么都不会产生。

scrum和XP是敏捷开发的具体方式，Scrum和XP的区别是，scrum偏重于过程，XP偏重实践。在实际中，两者结合应用。

scrum三大核心角色：Product Owner 产品负责人Scrum Master流程管理员 Scrum Team开发团队

敏捷开发的核心理念：敏捷开发的核心理念就是以简单有效的方式快速达成目标，能够根据外界的变化，迅速做出调整。

价值观：以人为本 目标导向 客户为先 拥抱变化

• 个体和互动重于流程和工具。
• 可工作的软件重于求全而完备的文档。
• 客户协作重于合同谈判。
• 应对变化重于遵循计划。

其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。人员彼此信任，人少但是精干，可以面对面的沟通。

敏捷开发小组主要的工作方式可以归纳为：作为一个整体工作；按短迭代周期工作；每次迭代交付一些成果；关注业务优先；检查与调整。

最重要的因素恐怕是项目的规模。规模增长，面对面的沟通就愈加困难，因此敏捷方法更适用于较小的队伍，40、30、20、10人或者更少。

四种模型比较

传统的瀑布式开发，也就是从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段都要做到最好。特别是前期阶段，设计的越完美，提交后的成本损失就越少。

迭代式开发，不要求每一个阶段的任务做的都是最完美的，而是明明知道还有很多不足的地方，却偏偏不去完善它，而是把主要功能先搭建起来为目的，以最短的时间，最少的损失先完成一个“不完美的成果物”直至提交。然后再通过客户或用户的反馈信息，在这个“不完美的成果物”上逐步进行完善。

螺旋开发，很大程度上是一种风险驱动的方法体系，因为在每个阶段之前及经常发生的循环之前，都必须首先进行风险评估。

敏捷开发，相比迭代式开发两者都强调在较短的开发周期提交软件，但是，敏捷开发的周期可能更短，并且更加强调队伍中的高度协作。敏捷方法有时候被误认为是无计划性和纪律性的方法，实际上更确切的说法是敏捷方法强调适应性而非预见性。

适应性的方法集中在快速适应现实的变化。当项目的需求起了变化，团队应该迅速适应。这个团队可能很难确切描述未来将会如何变化。

软件测试模型

V模型：

V 和瀑布比较像，体现测试层级，横坐标表时间

分析 用户验收测试（user acceptance test UAT）

​ 概要设计 系统测试（IT）

​ 详细设计　　　　　　　　 集成测试（IT）

​ 编码 单元测试（module test、unit　test）

软件具有的功能是否满足用户、客户的需求

优点：展示由底层到高层的测试过程

缺点：不适用于需求变化，灵活性差

局限性：V模型是基于瀑布模型的，V模型有一个缺点，就是将测试放在整个开发的最后阶段，没有让测试今早介入开发，没有在需求阶段就进入测试。测试与开发串行。

W模型：

W 测试尽早开始，和开发并行；

用户需求 V&V 用户验收测试设计 交付 用户验收测试

需求分析 V&V 系统测试设计 实施 系统测试

​ 概要设计 V&V 集成测试设计 集成 集成测试

​ 详细设计 V&V 单元测试设计 编码 单元测试

W模型优点：

​ 测试伴随整个产品开发周期，测试对象有程序、设计、需求

​ 测试介入早，提前发现问题及时修复降低成本

W模型缺点：

​ 实施起来复杂，体现在测试的设计阶段和需求的设计阶段

verification build the right thing 做正确的软件 验证文档操作是否正确 qc物

validation build things the right way 正确的做软件 验证是否按照文档规则进行相应的开发 qa流程

V&V在开发相关的文档生成后，对文档进行校验，后续校验是否按照文档来进行活动，同时将文档对应层次的测试活动设计出来

X模型

探索性测试，针对单独程序片段进行相互分离的编码和测试，此后进行频繁的交接，通过集成，最终成为可执行的程序，然后针对这些可执行程序进行测试。

H模型

测试过程活动完全独立，贯穿于整个产品周期，与其他流程并发进行，可以尽早进行，可根据被测物不同分层次进行。

总结：

在这些模型中，V模型强调了在整个软件项目开发中需要经历的若干个测试级别，但是它没有明确指出应该对软件的需求、设计进行测试，在这一点上，W模型得到了补充。但是W模型和V模型一样没有专门针对测试的流程说明。随着软件测试的不断发展，第三方测试已经独立出来这个时候，H模型就得到了相应的体现，表现为测试独立。X模型和前置测试模型又在此基础上增加了许多不确定的因素处理情况，这就对应了实际情况中，项目经常变更的情况发生。

总而言之，在实际的项目中，我们要合理应用这些模型的优点，比如在W模型下，合理运用H模型的思想进行独立的测试，或者在前置测试模型中，参考X模型的一个程序片段也需要相关的集成测试的理论等，将测试和开发紧密结合，寻找最适合的测试方案。