新浪微博：罗斯汀zdlzx
Scrum Gathering 参会笔记
上一篇 /
下一篇 2011-06-27 20:36:49
/ 个人分类：其它
提到：爱因斯坦说：什么是疯了？用同样的方法做事却希望得到不一样的结果就是疯了。
想到：在测试中应该不存在＂不能重现的缺陷＂。如果我们能捕捉到所有诱发缺陷的因素，再重现它们，结果应该是可以重现的。
提到：做持续集成不仅仅是有一个CI server （当时我们分会场几乎所有人所在的公司都有CI server)，而且应该有超过60%的auto test coverage, 每天至少一次代码的check in.目前能做到第二条的公司比例不高。
想到：虽然这三个实践是嘉宾对于是否真的做到CI的一家之言，但也反映出我们和它之间的差距，以及对于一个东西大家的理解的多样性。
提到：如何证明TDD的价值？Lance的做法是自己用TDD的方法写一个简单程序，然后让别的程序员来任意修改程序以引入缺陷，然后看原来的测试案例是否会失败（表明发现了缺陷）
想到：我们也可以这样试试。但是这好像并不能直接说明TDD有效，只能说单元测试案例有效。
提到：QA宠坏人。有时QA对开发人员说，别担心测试的事，我们会搞定的。这也成为一种推进TDD的阻碍。
想到：环境变了，最好人也一起去适应环境的变化。一直都和睦也许让人舒服，但不知道与外界已经不和谐的内部和谐能支持多久。呵呵，我拥抱变化，也祝福那些不想改变的人们！
提到：尹哲把没有单元测试的代码比喻成没有保护措施的徒手攀岩，太有趣了！攀岩中的钉子和绳子有两个作用：一是保护你在万一踏空时不会掉下去（就像代码出现严重错误）；二是能让你下一次仍然从钉子这个高度开始继续往上爬（就像单元测试能够马上指出你的错误，就在这里改，就在此基础上继续，从而保护你的已有成果）
想到：能够没有任何保护的徒手攀岩如果没有严重后果要么是高度不高，要么是攀岩者是个超级大牛且运气极佳。我们的项目可不具备其中任意之一，所以还是老老实实做单元测试吧！从新代码开始，当然！^_^
提到：底层的测试通过了没有意义，失败了有意义（让你马上能够知道要到哪里去修复什么问题）；反之，高层的测试通过了有意义（说明系统运行正常），失败了没有意义（因为你不太明确具体哪里出错了）。
想到：与其在GUI 自动化测试中去追求详尽的出错报告机制，不如看看和单元测试，接口测试如何有效协作，各斯其职。
想到：＂发现缺陷＂就是测试，确实消耗大量资源。＂定位缺陷＂我们最常用的是log,然后就是查看源代码。如果我们能够按照时间段把程序动态运行过的轨迹抽取出来（就像代码覆盖率工具那样，但只对应一次特定的运行），最好再以图形化的方式展现出来（象GPS展现历史路径一样），是否可以大量缩减定位缺陷的时间呢？当然，通过可测试性的考虑把问题限定到一个较小的范围，或者在各个层级建立不同的测试案例，也应该对于在内部测试甚至更早阶段定位缺陷起到一定的帮助作用。
提到：童骅建议至少同时使用两种燃尽图（如，基于hour的和基于story point的）来较全面地反应项目当前是否运行正常。他还介绍了通过一个量化的模型来度量项目基于燃尽图的健康程度的方法。
Gerrit: 基于GIT的code review工具
book: Working effectively with legacy code
paper:the new new product development game
收藏
举报
TAG:
