敏捷开发精品.pptVIP

有哪个项目不感叹测试资源投入太少呢？我们现在的开发和测试比例还是3：1，那google如何做到10：1？ 5个人做一个月的项目，bug数超过100，算是质量高吗？ 项目需求日益变化，代码重构的必要性很高，如何让重构有个保障呢？ 复杂的流程难以测试，应该怎样去完善可测试性呢？ 孰能无过？每个人都会犯错误。不能把错误留给测试。 编码规范、设计原则无法很好地执行。 团队成员变化较大，复杂逻辑的模块其他开发成员很难接替。 产品质量所有人都具有重要的责任 团队成员如何在项目中互相学习？ 个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到的文档 客户合作 胜过 合同谈判 响应变化 胜过 遵循计划  * 所有工程师对质量有着同等重要的责任 测试的任务不仅是发现bug，更重要的是帮助开发人员一起提高产品质量 有效地进行验收测试、持续集成、测试驱动开发、自动化测试、结对。 开发在设计的同时就考虑可测试性。 重沟通，每周会沟通做了什么功能，存在什么风险 以任务而非角色安排工作，共享同样的目标，共享同样的任务。 80%开发人员认为测试就是测试人员的事情 测试就是不断的发现bug 无建立好的持续集成框架 80%的项目无考虑可测试性，部分是提交了测试之后再考虑 单元测试覆盖率低 有codereview，但无结对 意识到提高产品的质量也是开发的重要责任 引用敏捷开发的测试驱动开发和结对，提高产品质量 帮助测试人员建立持续集成框架、验收测试的标准 可测试性的设计 编写单元测试是在进行验证，更是在进行设计。同样，它更是在编写文档。 一段时间的学习，让我的内心受到了深深的震撼。我们原来的方法居然如此的笨。 以前我面对测试先行这一名字时，最大的疑问就是程序都还没有写出来， 测试什么呀！。 后来一想，其实这是一个泥瓦匠都明白的道理，却是自己在画地为牢。我们来看看两个不同泥瓦匠是如何工作的。 工匠一:先拉上一根水平线，砌每一块砖时，都与这根水平线进行比较，使得每一块砖都保持水平。 　工匠二:先将一排砖都砌完，然后拉上一根水平线，看看哪些砖有问题，再进行调整。 这个就是线 有可能你会骂工匠二笨吧！这样多浪费时间呀！ 然而我们自己想想，我们平时在编写程序的时候又是怎么做的呢？ 我们就是按工匠二的方法在干活的呀！ 甚至有时候比工匠二还笨，是整面墙都砌完了，直接进行集成测试，经常让整面的墙倒塌。 看到这里，你还觉得自己的方法高明吗？ 每一个程序员都知道应该为自己的代码编写测试程序，但却很少这样做。 当有人问为什么的时候，最常听到的回答就是：我们的开发工作太紧张了 但这样却导致了一个恶性循环，越是没空编写测试程序，代码的效率与质量越差，花在找Bug、解决Bug的时间也越来越多， 实际效率大大降低。 由于效率降低了，因此时间更紧张，压力更大。你想想，为什么不拉上一根水平线呢？ 难道，我们不能够将后面浪费的时间花在单元测试上，使得我们的程序一开始就更加健壮，更加易于修改吗？ 将测试方案设计工作提前，在编写代码之前先做这一项工作； 从测试的角度来验证设计，推导设计； 将测试方案当作行为的准绳，有效地利用其检验代码编写的每一步，实时验证其正确性，实现软件开发过程的小步快走。 Test Driven Development(测试驱动开发) 测试先行。 持续重构。 测试驱动开发是一种在极限编程（XP）中处于核心地位的技术。 确保每个方法都是可用的且已被测试过 确保及时发现出现问题的模块 添加或修改代码更容易 频繁地运行测试 迭代式递增开发 不断重构以改善设计 TDD还能改善和验证设计: 以客户端的视角编写测试 为客户端提供了示例代码 更注重接口的设计 为了使测试容易,需要实现松散耦合 更少的Debug时间 1、写一个空方法。 2、写一个测试程序（单元测试用例）。 3、让程序编译通过。 4、运行测试程序，发现不能运行。（红条） 5、让测试程序可以运行。（绿条） 6、消除重复设计，优化设计结构。（绿条） 7、重构 1、用户可以选择付费月份为1、2、3个月 2、用户选择1个月最多可用1个红包 3、用户选择2个月最多可用2个红包 4、用户选择3个月最多可用3个红包 public class CouponManagerImpl { /** * 根据选择充值月数和拥有的最大红包数，取得可用红包数 * @param months 充值月数 * @param totalCoups 拥有的最大红包数 * @return 可用红包数 */ public int getNumOfCoupsCanUse(i