导入
测试工作是从研发中分出来的，因此测试工作是研发过程的一部分。要做好测试工作，必须深刻理解研发过程和模型。
研发工程师相当于挖战壕，而测试工程师相当于检测战壕。
早期模型
- 大爆炸：随意开发，计算机工程师中的顶尖人物如图灵、冯诺依曼。
大爆炸模式的特点包括：
缺乏详细的需求分析和计划，依赖开发团队的经验和直觉，适用于小规模或实验性质的项目，但面临高失败风险，不适合大规模复杂项目。
- 缺乏规划：在项目开始时几乎没有进行详细的需求分析和计划，项目的成功高度依赖于开发团队的直觉和经验。
- 一次性交付：目标是通过一次主要的努力来构建并交付最终产品，而不是分阶段或迭代地发展。
- 高风险性：由于前期缺少详细的规划和需求收集，项目可能面临很高的失败风险，尤其是在大型或复杂项目中。
- 适用于小规模或实验性项目**：对于那些需要快速验证概念的小型项目或者实验性质的项目来说，大爆炸模式可能会是一个合适的选择。
适用场景：
尽管大爆炸模型存在明显的缺点，比如高失败率和不适合大规模复杂项目，但它也有一定的适用场景。例如，当项目非常小、时间紧迫、对结果的要求不高或只是为了初步验证某个想法是否可行时，这种模式可以快速地将创意转化为实际产品。
然而，对于大多数商业软件开发项目而言，这种方法并不推荐使用。更为结构化和迭代的开发模型，如敏捷开发、Scrum或看板管理等，能够更好地适应变化、降低风险并提高项目的成功率。这些模型强调持续的反馈循环、灵活的需求管理和紧密的团队协作，以确保最终产品满足用户的实际需求。
- 边做边改(Build-and-Fix Model)：仅限于非常有能力的大牛使用，比如比尔、埃里等。
适用于编写几百行的小程序，但不适用于任何规模的开发，主要问题是缺少规划和设计环节，忽略需求环节，未考虑测试和程序的可维护性，也无任何文档。
中期模型
-
瀑布模型（Waterfall Model）
1970年Winston Royce提出了著名的“瀑布模型“,直到80年代早期,它一直是唯一被广泛采用的软件开发模型。瀑布模型从可行性研究(或称系统分析)开始,逐步进行阶段性变换,直至通过确认测试并得到用户确认的软件产品位置,瀑布模型上一阶段的变换结果是下一阶段变换的输入,相邻两个阶段具有因果关系,紧密相连,一个阶段工作的失误将蔓延到以后各个阶段,为了保障软件开发的正确性,每一个阶段任务完成后,都必须对的阶段性产品进行评审,确认之后再转入下一阶段的工作。评审过程发现错误和疏漏后,应该反馈到前面的有关阶段修正错误、弥补疏漏,然后再重复前面的工作,直至某一个阶段通过评审后进入下一阶段。这种形式的瀑布模型是带有反馈的瀑布模型。
- 定义：将软件研发过程按照需求分析、设计、实现、测试、发布的顺序进行规划的一种研发方法论。
- 优点：
- 至少有一个可用的框架。
- 对于小型项目非常适合，可提高成本效益和项目交付成功率（从不足50%提升到80%），并显著提高交付质量。
- 缺点：
- 不适用于大型或中型项目。
- 需求变化频繁的项目不适合。
- 过程中缺少反馈，早期问题要等到后期才能发现，增加了维护成本。
- 交付效率低。
-
增量迭代式模型(Incremental Model)
- 定义：每次只设计和实现产品的一部分，逐步完成的方法叫迭代开发。
- 过程：
- 需求分析
- 迭代计划：将需求拆分为多个部分，选择最主要的部分先开发，并将其拆分成多个迭代。
- 设计、实现、测试
- 优点：
- 可以将大型项目拆分为多个小项目来完成。
- 能够应对需求的变化，因为迭代周期较短，可以在下一个迭代周期解决变化的需求。
- 在研发过程中可以进行有效的反馈，通过反馈来进行效果评估。
- 提高了交付效率。
- 缺点：
- 划分迭代数量没有标准，取决于产品经理的能力。
- 同行评审可能导致管理维护成本增加，问题也会增多。
-
螺旋模型(Spiral Model)
1988年,巴利-玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。“螺旋模型”刚开始规模很小,当项目被定义得更好、更稳定时,逐渐展开。“螺旋模型”的核心就在于您不需要在刚开始的时候就把所有事情都定义的清清楚楚。您轻松上阵,定义最重要的功能,实现它,然后听取客户的意见,之后再进入到下一个阶段。如此不断轮回重复,直到得到您满意的最终产品。
-
定义：结合了瀑布模型和快速原型模型的特点，强调风险分析，特别适合大型复杂的系统。其核心在于不需要在一开始就定义所有细节，而是逐步展开。
-
步骤：
· 制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
· 风险分析:分析评估所选方案,考虑如何识别和消除风险;
· 实施工程:实施软件开发和验证;
· 客户评估:评价开发工作,提出修正建议,制定下一步计划。
-
螺旋模型很大程度上是一种风险驱动的方法体系,因为在每个阶段之前及经常发生的循环之前,都必须首先进行风险评估。
- 敏捷模型
-
定义：以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。它是一种应对快速变化需求的软件开发能力。
-
价值观：
- 以人为本
- 目标导向
- 客户为先
- 拥抱变化
-
敏捷实践对测试的指导意义：
-
以人为本：与产品经理、研发工程师面对面沟通和交流，及时获取信息。
-
目标导向：在测试过程中优先验证和确认软件功能及其可用性。
-
客户为先：听取客户意见，有机会时充分交流，了解客户的实际需求。
-
拥抱变化：测试工程师需要深刻理解业务及被测对象，并持续学习。
-
-
敏捷开发的十二条原则:
-
(1)我们最重要的目标,是通过持续不断地及早交付有价值的软件使客户满意。
-
(2)欣然面对需求变化,即使在开发后期也一样。为了客户的竞争优势,敏捷过程掌控变化。
-
(3)经常地交付可工作的软件,相隔几星期或一两个月,倾向于采取较短的周期。
-
(4)业务人员和开发人员必须相互合作,项目中的每一天都不例外。
-
(5)激发个体的斗志,以他们为核心搭建项目。提供所需的环境和支援,辅以信任,从而达成目标。
-
(6)不论团队内外,传递信息效果最好和效率最高的方式是面对面的交谈。
-
(7)可工作的软件是进度的首要度量标准。
-
(8)敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
-
(9)坚持不懈地追求技术卓越和良好设计,敏捷能力由此增强。
-
（10）以简洁为本,它是极力减少不必要工作量的艺术。
-
（11）最好的架构、需求和设计出自组织团队。
-
（12）团队定期地反思如何能提高成效,并依此调整自身的举止表现。
-
-
敏捷只是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是在实际中,两者往往是结合在一起应用的。
- 敏捷实践分类：
敏捷只是一种指导思想或开发方式,但是它没有明确告诉我们到底采用什么样的流程进行开发,而Scrum和XP就是敏捷开发的具体方式了,你可以采用Scrum方式也可以采用XP方式;Scrum和XP的区别是,Scrum偏重于过程,XP则偏重于实践,但是在实际中,两者往往是结合在一起应用的。
-
XP（极限编程）(eXtreme Programming)：一般团队难以实施。
1. XP主要目标在于降低因需求变更而带来的成本,它由价值观、原则、实践和行为四个部分组成,它们彼此相互依赖、关联,并通过行为贯穿于整个生命期。 2.四大价值观:沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气(Courage) 5.五大原则:快速反馈、简单性假设、逐步修改、提倡更改、优质工作。 6.极限编程和传统开发方法的不同在于它更强调可适应性而不是可预测性。它是一种轻量(敏捷)、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。 7.用一种近似螺旋式的开发方法将复杂的过程分解为一个个相对比较简单的小周期,并且强调测试、代码质量和及早发现问题。通过一个个短小的选代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出应。在此过程中通过积极的交流、反馈等使开发人员和客户可以非常清楚的解决开发的进度、变化、待解决的问题和潜在的困难,并根据实际情况及时的调整开发过程。通过一个个短小的迭代周期,我们就可以获得一个个阶段性的进展,并且可以及时形成一个版本供用户参考,以便及时对用户可能的需求变更作出应。 8.极限编程与其他方法最大的不同在于:强调在更短的周期内,更早的提供具体、持续的反馈信息;首先快速生成一个总体计划,然后在整个项目开发过程中不断地发展完善它;依赖于口头的交流、测试和源程序进行沟通;倡导持续的演化式设计。
极限编程 13个最佳实现:
现场客户(Customer Tests):客户长期与开发人员在同一间办公室办公,随时解决开发人员关于需求的问题。现场客户负责编写用户故事,负责决定用户故事的优先级以及实现顺序。现场客户负责编写验收测试用例。
代码规范(Code Standards):开发团队应该拥有一个编码标准。
完整团队(Whole Tealh):XP的核心是其总结的沟通(Communication)、简单(Simplicity)、反馈(Feedback)、勇气
(Courage)四大价值观,一切都建立在团队成员之间的相互关心、相互理解的基础之上。
集体所有(Collective Ownership):团队中的每个成员都拥有对代码进行改进的权利,每个人都拥有全部代码,也都需要对全部代码负责。同时,XP强调代码是谁破坏的,就应该由谁来修复。
平稳工作(Sustainable Pace):加班最终会扼杀团队的积极性,最终导致项目失败,每周工作40小时是一种顺势行为,是一种规律。
计划博弈(Planning Game):客户编写故事,开发人员进行估算,确定迭代的周期。
系统隐喻(System Metaphor):寻求共识,发明共享词汇,描述体系结构。隐喻是设计和沟通的辅助手段,使项目成员对于系统的实现方式达成共识。
简单设计(Simple Design):只要今天够用就行,不考虑明天会发现的新问题。
测试驱动(Test-driven):测试先行代码重构(Refactoring):时刻对代码进行重构,一直保持其良好的结构与可扩展性。集体CodeReview也是很重要的。
结对编程(Pair Programming):系统的任何一个部分都肯定至少有2个人以上熟悉,好处是代码会被100%review,有效地降低代码缺陷率。
持续集成(Continuous Integration):开发人员坚持随时进行提交,系统每天一次集成。
小型发布(Small Release):开发周期经常发布中间版本。要做到小型发布,则必须先实现持续集成。
-
Scrum：冲刺，这个术语来源于美式足球。Scrum是以经验性过程控制理论作为理论基础的过程,主张只是源于经验,采用迭代、增量的方法来优化可预见性并控制风险。Scrum的整个开发过程是由若干个段的迭代周期组成,其中一个短的迭代周期是一个Sprint,每个Sprint的长度是2-4周,而每个Sprint迭代中又分成若干个build。
-
作为敏捷开发机制,Scrum有以下重要特性:
1、迭代开发。
2、增量交付,增量是一个Sprint及以前所有Sprint中完成的所有产品待办事项列表条目的总和。在Sprint的结尾,新的增量必须“完成”。
3、自组织团队,Scrum团队是一个自组织的团队,自己决定团队内如何开展工作,决定谁来做什么,即分工协作的方式。
4、高优先级的需求驱动,总是先开发对客户具有较高价值的需求,在Sprint中,Scrum团队从产品代办事项中挑出优先级最高的需求进行开发,挑选的需求在Sprint会议上经过讨论、分析和估算得到相应的任务列表。
-
Scrum的核心要点(即所谓的3355)
· 第一个3即Scrum的三大核心角色:Product Owner、Scrum Master、Scrum Team。
· 产品负责人(Product Owner)主要负责确定产品的功能和达到要求的标准,制定软件的发布日期和交付内容。
· 流程管理员(Scrum Master)主要负责整个流程在项目中的顺利实施和进行,以及清除挡在客户和开发工作之间的沟通障碍,使得客户可以直接驱动开发。
· 开发团队(Scrum Team)主要负责流程下开发工作,人数控制在5~10人左右,每个成员可能负责不同的技术方面,但要求每个成员必须要有很强的自我管理能力,同时具有一定的表达能力;成员可以采用任何工作方式,只要能达到Sprint的目标。
· 第二个3即三个工件,产品待办事项(Product Backlog)(即产品的需求列表)、Sprint 待办事项(Sprint Backlog)(即本次迭代周期内要完成的任务)、可交付产品增量(Increment)(即迭代结束后可对外发布的产品功能增量部分)。
· 第一个5即Scrum的五大事件,主要包括Sprint、Sprint Planning Meeting(确定下一个迭代要实现的目标和内容)、Sprint Daily Standup、Sprint Review(迭代期末展开,用来检查本期的成果)、Sprint Retrospective(总结经验与教训,并形成切实可行的改进清单)。
· 第二个5即Scrum的五大价值观。即承诺、专注、开放、尊重、勇气。
· 产品负责人按优先顺序排列确认一个产品需求列表(Product Backlog)
· 开发团队根据Product Backlog列表,做工作量的预估和安排
· 有了Product Backlog列表,我们需要通过 Sprint Planning Meeting(任务计划会议)来从中挑选出一个Story作为本次迭代完成的目标,这个目标的时间周期是1~4个星期,然后把这个Story进行细化,形成一个Sprint Backlog(任务列表)
· Sprint Backlog是由Scrum Team去完成的,每个成员根据Sprint Backlog再细化成更小的任务(细到每个任务的工作量在2天内能完成)
· 在Scrum Team完成计划会议上选出的Sprint Backlog过程中,需要进行 Daily Scrum Meeting(每日站立会议),每次会议控制在15分钟左右,每个人都必须发言,并且要向所有成员当面汇报你昨天完成了什么,并且向所有成员承诺你今天要完成什么,同时遇到不能解决的问题也可以提出,每个人回答完成后,要走到黑板前更新自己的 Sprint burn down(任务燃尽图)
· 做到每日集成,也就是每天都要有一个可以成功编译、并且可以演示的版本
· 当一个Story完成,也就是Sprint Backlog被完成,也就表示一次Sprint完成,这时,我们要进行 Srpint Review Meeting(演示会议),也称为评审会议,产品负责人和客户都要参加(最好本公司老板也参加),每一个Scrum Team的成员都要向他们演示自己完成的软件产品(这个会议非常重要,一定不能取消)
· 最后就是 Sprint Retrospective Meeting(回顾会议),也称为总结会议,以轮流发言方式进行,每个人都要发言,总结并讨论改进的地方,放入下一轮Sprint的产品需求中
