瀑布模型是将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型，它为软件的开发和维护提供了一种有效的管理模式，从一种非常高层的角度描述了软件开发过程中进行的活动，并且提出了要求开发人员经过的事件序列。适合于软件需求很明确的软件项目的模型。

V模型是瀑布模型的变种，它说明测试活动是如何与分析和设计相联系的。

演化模型在获取一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，然后逐步演化成为最终软件产品。

原型模型快速构造软件的原型，在此基础上开发最终软件产品。允许开发人员快速地构造整个系统或系统的一部分以理解或澄清问题。演化模型，原型模型这两类模型主要是针对需求不确定或者不清楚的情况下，进行项目开发建议采用的。

而螺旋模型增加了风险分析。螺旋模型把开发活动和风险管理结合起来，以将风险减到最小并控制风险。

极限编程（XP)是一种软件开发方法，其核心价值观是简单、沟通、反馈和勇气。 成功的软件开发是团队努力的结果—不仅仅指开发团队，而是包括了客户、管理人员和开发人员组成的更大团队。XP是一种将上述人员组织起来并帮助他们取得成功的简单的过程。XP主要针对一个十几人或更少程序员组成的、在同一个场所工作的面向对象的项目团队。XP原则适用于需要快速且灵活地交付髙质量软件的中等规模项目组。

一个XP项目组需要一个全程参与的客户给予指导。客户、程序员和项目经理协同工作来构建需要的软件系统。客户，也就是需要软件的人，将学到简单而有效的沟通方法，来确保获得他们所需要的，从而引导项目走向成功。

敏捷开发方法XP是一种轻量级、高效、低风险、柔性、可预测的、科学的软件开发方法，其特性包含在12个最佳实践中。

（1）计划游戏：快速制定计划、随着细节的不断变化而完善；

（2）小型发布：系统的设计要能够尽可能早地交付；

（3）隐喻：找到合适的比喻传达信息；

（4）简单设计：只处理当前的需求使设计保持简单；

（5）测试先行：先写测试代码再编写程序；

（6）重构：重新审视需求和设计，重新明确地描述它们，以符合新的和现有的需求;

（7）结队编程；

（8）集体代码所有制；

（9）持续集成：可以按日甚至按小时为客户提供可运行的版本；

（10）每周工作40个小时；

（11）现场客户；

（12）编码标准。

风险分析：风险分析实际上是4个不同的活动：风险识别、风险预测、风险评估和风险控制。在对风险进行优先级排序时，需要根据风险概率和后果来进行排序。

1. 风险识别是试图系统化地确定对项目计划（估算、进度、资源分配）的威胁。
2. 风险预测又称为风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生时所产生的后果。
3. 风险评估根据风险及其发生的概率和产生的影响预测是否影响 参考水平值。
4. 风险控制的目的是辅助项目组建立处理风险的策略，有效的策略应考虑风 险避免、风险监控、风险管理及意外事件计划。而其中风险避免是最好的风险控制策略

一、前言

      在开发新的软件系统过程中，由于存在许多不确定因素，软件开发失败的风险是客观存在的。因此，风险分析对于软件项目管理是决定性的。一般认为软件的风险包含两个特性：不确定性和损失。下面小编会依次向大家介绍：

二、要点

      风险分析实际上就是贯穿在软件工程过程中的一系列风险管理步骤，其中包括：风险识别、风险预测、风险评估、风险控制等。

❤风险识别❤

      风险识别就是试图系统化的指出对项目计划的威胁。识别出已知的风险和可预测的风险后，项目管理者首先是要做的可能是回避风险，在必要时控制这些风险。

      风险识别一种方法是建立风险条目检查表。

❤风险预测❤

风险预测又称为风险估计，试图从两个方面评估一个风险：

①风险发生的可能性或概率；

②如果风险发生了，所产生的后果；

❤风险评估❤

      一种对风险评估很有用的技术就是定义风险参照标准。

❤风险控制❤

      目的是辅助项目组建立处理风险的策略。

1.风险避免

      最好的方法是主动避免风险，即在风险发生前分析引起风险的原因，然后采取措施，以避免风险发生。

2.风险监控

      项目管理者应监控某些因素，这些因素可以提供风险是否正在变高或变低的指示。

3.RMMM计划

      风险管理策略可以包含在软件项目计划中，或者风险管理步骤也可以组织成一个独立的风向缓解，监控和管理计划（RMMM计划）。讲所有的风险分析工作文档化，并由项目管理者作为整个项目计划中的一部分。

三、小结

      风险时长有，更多的还是要多多的预防。小编详细推荐大家去了解一下风险，就当自己带的很大的项目，比如，今年的双十一马上就要到了，双十一还是一个大关，就要考虑到所有的风险，来应对这个大关。最后加油~~~

设计方面：

　　风险：(1)没有详细设计说明书;

　　解决方案：测试人员要在开发阶段对相关设计及需求文档进行分析，对大体模块功能进行分类，分析业务逻辑，在不清楚的地方及时与开发人员沟通。

　　风险：(2)没有统一的界面设计规范。

　　解决方案：与项目负责人确认测试标准。

　　开发方面：

　　风险：(1)所有模块开发没有统一设计，开发人员有自己的设计方式;

　　解决方案：与项目负责人确认标准方式，与标准方式不一致的地方全部以BUG形式提交。

　　风险：(2)需求变更开发。

　　解决方案：建议将需求变更形成文档，对没有文档的需求变更，在测试过程中发现及时与开发负责人确认，并存档相关变更文档。

　　测试本身：

　　风险：(1)人力资源;

　　解决方案：保证稳定的人员安排。

　　风险：(2)硬件资源;

　　解决方案：事先分析测试所需硬件资源，及时申请，保证测试工作顺利进行。

　　风险：(3)版本控制;

　　解决方案：严格控制版本，BUG以版本为单位进行提交。在测试过程中及BUG确认阶段禁止任何代码更新。

　　风险：(4)测试时间不足。

　　解决方案：动员测试人员完成测试任务，必要时，应给予相应物质奖励。

　　测试风险是不可避免的、总是存在的，所以对测试风险的管理非常重要，必须尽力降低测试中所存在的风险，最大程度地保证质量和满足客户的需求。在测试工作中，主要的风险有：

　　一、质量需求或产品的特性理解不准确，造成测试范围分析的误差，结果某些地方始终测试不到或验证的标准不对;

　　二、测试用例没有得到百分之百的执行，如有些测试用例被有意或无意的遗漏;

　　三、需求的临时/突然变化，导致设计的修改和代码的重写，测试时间不够;

　　四、质量标准不都是很清晰的，如适用性的测试，仁者见仁、智者见智;

　　五、测试用例设计不到位，忽视了一些边界条件、深层次的逻辑、用户场景等;

　　六、测试环境，一般不可能和实际运行环境完全一致，造成测试结果的误差;

　　七、有些缺陷出现频率不是百分之百，不容易被发现;如果代码质量差，软件缺陷很多，被漏检的缺陷可能性就大;

　　八、回归测试一般不运行全部测试用例，是有选择性的执行，必然带来风险。

　　前面三种风险是可以避免的，而四至七的四种风险是不能避免的，可以降到最低。最后一种回归测试风险是可以避免，但出于时间或成本的考虑，一般也是存在的。

　　针对上述软件测试的风险，有一些有效的测试风险控制方法，如：

　　测试环境不对可以通过事先列出要检查的所有条目，在测试环境设置好后，由其他人员按已列出条目逐条检查;

　　有些测试风险可能带来的后果非常严重，能否将它转化为其他一些不会引起严重后果的低风险。如产品发布前夕，在某个不是很重要的新功能上发现一个严重的缺陷，如果修正这个缺陷，很有可能引起某个原有功能上的缺陷。这时处理这个缺陷所带来的风险就很大，对策是去掉(Diasble)那个新功能，转移这种风险;

　　有些风险不可避免，就设法降低风险，如“程序中未发现的缺陷”这种风险总是存在，我们就要通过提高测试用例的覆盖率(如达到99.9%)来降低这种风险;

　　为了避免、转移或降低风险，事先要做好风险管理计划和控制风险的策略，并对风险的处理还要制定一些应急的、有效的处理方案，如：

　　在做资源、时间、成本等估算时，要留有余地，不要用到100%;

　　在项目开始前，把一些环节或边界上的可能会有变化、难以控制的因素列入风险管理计划中;

　　对每个关键性技术人员培养后备人员，作好人员流动的准备，采取一些措施确保人员一旦离开公司， 项目不会受到严重影响，仍能可以继续下去;

　　制定文档标准，并建立一种机制，保证文档及时产生;

　　对所有工作多进行互相审查，及时发现问题，包括对不同的测试人员在不同的测试模块上相互调换;

　　对所有过程进行日常跟踪，及时发现风险出现的征兆，避免风险。

　　要想真正回避风险，就必须彻底改变测试项目的管理方式;针对测试的各种风险，建立一种“防患于未然”或“以预防为主”的管理意识。与传统的软件测试相比，全过程测试管理方式不仅可以有效降低产品的质量风险，而且还可以提前对软件产品缺陷进行规避、缩短对缺陷的反馈周期和整个项目的测试周期。