敏捷测试

敏捷反馈 守护天使 Coding feedback. 为了应对代码的变化，你需要持续获得代码健康状态的反馈：他是在做你期望的事情吗？最近一次修改有没有无意中破坏了什么功能？为了确保所有功能都能正常工作，就需要自动化单元测试。 一些开发者会对“测试”这个词有意见，应把它看作是一个代码技术。用代码来检查变量的具体值，而不是手工检查那些感兴趣的变量。 只要有了单元测试，就让到他们自动运行，也就是每次编译或者构建代码的时候，就运行一次测试。把单元测试的结果看作是和编译器一样——如果测试没有通过，那就像变异没有通过一样糟糕。 接下来就是在后台假设一个 构建机器 ，不断获取最新版本的源代码，然后编译代码，并运行单元测试，如果有任何错误它会让你及时知道，这是最容易修复也是成本最低的时候。 具体技巧 单元测试是优质股，值得投资。但一些简单的属性访问方法或者价值不大的方法，是不值得花费时间进行测试的。 人们不编写单元测试的很多借口都是因为代码中的设计缺陷。通常，抗议越强烈，就说明设计越糟糕。 单元测试只有在达到一定测试覆盖率的时候，才能真正地发挥作用。你可以使用一些测试覆盖率工具，大致了解自己的单元测试的覆盖情况。 不是测试越多质量就会越高，测试必须要有效。如果测试无法发现任何问题，也许它们就是没有测试对路。 先用它再实现它 我们的业务是要创造出能调用的API和可以使用的接口。这就是说

交付用户想要的软件 让客户做决定 在设计方面，做决定的时候好必须有开发者参与。可是，在一个项目中，它们不应该做所有决定，特别是业务方面的决定。 Decide what you shouldn’t decide. 开发者（及项目经理）能做的一个最重要的决定就是：判断哪些是自己决定不来的，应该让企业主做决定。你不需要自己给业务上的关键问题做决定。毕竟那不是你的事情。如果遇到了一个问题，会影响到系统的行为或者如何使用系统，把这个问题告诉业务负责人。如果项目领导或经理试图全权负责这些问题，要委婉地劝说他们，这些问题最好还是和真正的业务负责人或客户商议。 当你和客户讨论问题的时候，准备好几种可选择的方案。不是从技术的角度，而是从业务的角度，介绍每种方案的优缺点，以及潜在的成本和利益。和他们讨论每个选择对时间和预算的影响，以及如何权衡。无论他们做出了什么决定，他们必须接受它，所以最好让他们了解一切之后再做这些决定。如果时候他们又想要其他的东西，可以公正地就成本和时间重新谈判。 毕竟，这是他们的决定。 具体技巧 记录客户做出的决定，并注明原因。好记性不如烂笔头，但你选择的记录方法不能太笨重或太繁琐。 不要用过于具体和没有价值的问题打扰繁忙的业务人员。如果问题对他们的业务没有影响，就应该是没有价值的。 不要随意假设具体的问题不会影响他们的业务。如果能影响他们的业务，就是有价值的问题。

本文已经首发于 InfoQ中文站 ，版权所有，原文为《XXX》，如需转载，请务必附带本声明，谢谢。 InfoQ中文站 是一个面向中高端技术人员的在线独立社区，为Java、.NET、Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如 QCon 、线下技术交流活动 QClub 、免费迷你书下载如 《架构师》 等。​ 在与不少测试从业人员讨论到敏捷的时候，被问得最多的大约是两个问题：“到底什么是敏捷软件测试？”，“敏捷软件开发还需要测试工程师吗？”。前一个问题是对于敏捷测试本身定义的疑问，第二个问题则是对敏捷开发将测试工程师排除在外的担心。其实，在探寻这两个问题答案的过程中，我们可以更清晰的了解敏捷软件开发中测试的工作定义，测试价值观，以及敏捷开发中开发与测试工程师的配合。鉴于这两个问题的意义，在本敏捷测试专栏的第一篇文章中，本人尝试从自己的实践出发，尽可能清楚的回答这两个问题。 确实，相对于敏捷开发红遍大江南北的状况而言，对敏捷测试的讨论则低调得多。敏捷联盟定义了敏捷的4个价值声明，以及伴随的12条支持原则，这12条原则中没有一条单独提到测试。这是不是意味着测试在敏捷开发中并不重要呢？实际上，如果仔细研读敏捷的12个原则，以及各种不同的敏捷实践，就会发现，测试在敏捷开发中占有非常重要的地位。无论是原则中的“频繁交付”，还是对“可工作的软件”的度量

高效程序员的45个习惯 敏捷开发修炼之道 敏捷工具箱 第一章 敏捷---高效软件开发之道 第二章 态度决定一切 第三章 学无止境 第四章 交付用户想要的软件 敏捷反馈- 第六章 敏捷编码 第七章 敏捷调试 第八章 敏捷协作 敏捷工具箱 Wiki 网站 是一个很友好的支持协作的工具，团队中的每一个人都可以根据需要动态的新增和重新组织网页中的内容 版本控制 使用CVS 单元测试 《JunitRecipes 中文版》 自动构建 《项目自动化之道》 5. http://draconet.sourceforge.net 供.net平台使用的持续集成工具，通过Windows 服务的方式运行。 6. http://sourceforge.net/projects/nunit 7. http://c2.com/cgi/wiki?PrinciplesOfObjectOrientedDesign //面向对象设计原则 8. http://c2.com/cgi/wiki?TestDrivenDevelopment //测试驱动开发 9. http://www.xprogramming.com/software.htm //测试工具在内的资源集合 第一章 敏捷—高效软件开发之道 1.先难后易。我们要首先解决困难的问题，把简单的问题留到最后。 第二章 态度决定一切 做事：把矛头对准问题的解决办法，而不是人