标签：代码审查 本地测试 codereview
软件测试虽然辛苦，但是掌握了一定的技巧之后将使你事半功倍。
（1） 边界测试，测试用户输入框中的数值的最大数和最小数，以及为空时的情况。
（2） 非法测试，例如在输入数字的地方输入字母。
（3） 跟踪测试，跟踪一条数据的流程,保证数据的正确性。
（4） 在开始测试时应保证数据的正确性，然后在从系统中找出各种BUG。
（5） 接口测试，程序往往在接口的地方很容易发生错误，要在此模块测试勿掉以轻心。
（6） 代码重用测试，在开发过程中有些模块功能几乎相同，程序员在重用代码时可能忘记在原有代码上修改或修改不全面，而造成的错误。
（7） 突发事件测试，服务器上可能发生意外情况的测试。
（8） 外界环境测试，有些系统在开发时依赖于另外一个系统,当另外一个系统发生错误时, 这个系统所受到的影响的情况。
（9） 在程序员刚修复Bug之后的地方,再找一找，往往程序员只修复报告出来的缺陷而不去考虑别的功能在修改时可能会重新造成错误。
（10） 认真做好测试记录在做完一天的测试记录之后,第二天再根据第一天的测试记录重复测试你会发现有未修正的错误。
（11） 文字测试，如果在系统中有用词不当的地方，我想这是不应该的。
（12） 系统兼容测试，例如有些程序在IE6能运行正常，到IE5下不能运行。有些程序在WIN2000下能运行，而到WIN98却不能运行。像一些很特别的用户去使用系统，你很有可能发现BUG。
（13） 用户的易用性测试，往往用户的需求是不断的变化的，而其中的一部份变化的原因，是有用户操作上不方便引起的。
首先，让我们谨记为什么要做代码审查。对于任何专业的软件开发人员来说，最重要的目标之一是能够持续的提高他们的工作质量。即使你的团队里尽是优秀的程序员，你也不能将你自己与一个有能力的自由从业者区分开来，除非你能够作为一个团队工作。代码审查是达到这个目的的最重要方式之一。
数百万年前，猿从树上下来，进化出了对生拇指，最终，变成了人类。
我们以类似的眼光来看下强制性代码审查（Code Review）：好像是一种能在软件开发这块广阔的领域里将人类从兽里分离出来的东西。
不过，我有时候会从我们的团队成员里听到下面这样的评论：
为什么我们要做代码审查？
首先，让我们谨记为什么要做代码审查。对于任何专业的软件开发人员来说，最重要的目标之一是能够持续的提高他们的工作质量。即使你的团队里尽是优秀的程序员，你也不能将你自己与一个有能力的自由从业者区分开来，除非你能够作为一个团队工作。代码审查是达到这个目的的最重要方式之一。尤其，它们：
做彻底深入的审查
不过，如果不在审查工作上倾注一定的时间和精力，这些目标都是无法实现的。仅仅滚动浏览下patch，确保缩进正确、所有的变量采取小骆驼拼写法并不能构成一次彻底的审查。受到业界的启发也可以考虑结对编程，这是一个相当流行的做法，但也在所有的开发时间上增加了100%的额外开销来作为代码审查工作的基准。你可能会在代码审查中花费很多时间，但与结对编程相比，使用的总体工程时间仍少得多。
我认为花在代码审查工作上的时间应该是原开发时间的25%左右。例如，如果一个开发者花两天时间实现了个小项目，那么审查者应该花大致4个小时的时间来审查它。
当然，花在审查工作上多少时间并不是最重要的，只要审查能够准确无误的完成即可。特别地，你必须要能理解你正在审查的代码。这不仅仅意味着你只要懂该代码所采用语言的语法即可，它还意味着你必须了解该代码如何适应于更大的应用环境、组件或库下。如果你不抓住每一行代码的全部含义，那么你的审查就不是非常有价值的。这也是为什么好的审查都不可能非常快的完成：因为还要花时间去调查触发某个给定函数的不同代码路径，要去确保第三方API能够正确使用（包括任何边缘情况），等等。
除了寻找你所审查的代码中的瑕疵或其它问题之外，你还应该确保：
甚至擅长写测试和文档的开发人员也并不总能记得在代码改动之后及时更新。在适当的时候来自代码审查人员的细微调整对于确保代码在随着时间的推移不会变质是至关重要的。
防止代码审查工作超负荷
如果你的团队强制要求做代码审查，那这是有风险的，因为你的代码审查工作可能一直积压，最终到无法管理的地步。如果你两周之内不做任何审查工作，你可以很容易的花上几天时间来赶补它。不过这也意味着当你最终决定去处理它们的时候，你自己的开发工作将遭到一定的意外搁浅。这也使得做好审查工作更加困难，因为正确的代码审查需要强烈、持续的脑力劳动，很难这样数日保持下去。
因此，开发者每天应该竭尽全力的清空他们的审查积压工作。一个方法是早晨的第一件事情就用来解决审查工作。在开始自己的开发工作之前先做完所有的优秀审查工作，你可以防止以后的审查局面失控情况。有些人更喜欢在午休之前或之后或在一天结束后做审查工作。无论你什么时候做这些事情，通过将代码审查作为正规的日常工作而不是作为一种分散注意力的工作，你可以避免：
写易于审查的代码
无法管理的审查积压工作也不能全怪审查人员。如果我的同事不管三七二十一的花费一周的时间来给一个大工程项目添加代码，那么他们发布的patch将真的很难审查，因为在一个阶段里有太多的工作要处理，代码的目的和底层架构体系也会很难理解。
这是将你的工作切割为一个个可管理单元之所以非常重要的众多原因之一，我们使用scrum管理方法，所以对我们来说合适的单元是重点。通过一起努力，用单元来组织我们的工作，并提交仅与我们正在进行的某个单元相关的审查，我们可以写出更加易于审查的代码。你的团队可能使用另一种管理方法，但是原则都是一样的。
为了写出易于审查的代码，还有一些其它的必备条件。如果要做出一些很棘手的架构决策，为满足审查者的要求，事先进行讨论是合理的。这将使得审查者更加容易的理解你的代码，因为他们将知道你在代码中试着达到什么目的以及怎么计划来达到该目的。这也有助于避免这样一种情况：在审查者提出一个不同的更好的方法后，你必须要重写你的大段代码。
在你的设计文档里项目架构应该要详细的描述。这无论如何都是很重要的，因为它能让一个新的项目成员很快的赶上进度并理解现有的代码库。它还能帮助审查者更好的做好自己的工作，这是另一个好处。单元测试也有助于向审查者说明组件应该如何使用。
如果你的patch里包含了第三方代码，请单独提交。例如当jQuery的9000行代码被插入代码中间时，要做好代码审查工作就难上加难了。
写出易于审查的代码的最重要步骤之一是给你的代码审查部分添加注释。这表示你可以自己浏览审查部分，并在任何你觉得有助于审查者理解代码意思的地方添加注释。我发现这样的注释仅花费相对较少的时间（经常仅几分钟的时间）却能产生巨大的作用，能让代码审查工作完成的更快、更好。当然，代码注释也有许多相同的优点，应该在合适的地方使用，但是通常来说审查注释更为明智。最后可以说是一个奖励吧， 研究表明，当开发者重新阅读和注释代码时，竟然发现他们自己的代码里有很多的瑕疵。
庞大的代码重构
有时有必要重构能影响许多组件的某个代码库。对于一个庞大的应用程序，这个过程可能花费好几天（甚至更久）且导致庞大的补丁。在这些情况下一个标准的代码审查工作可能是不切实际的。
最好的解决方法是递增式重构代码。在工作代码库的合理范围内找到能达到你目的的某个改动点。一旦改好了，review通过了，接着进行下一个改动，直到整个重构工作完成。这个方法可能并不是每次都行得通，但是有想法和计划，在重构时要避免巨大的补丁通常是实际可行的。像这样来重构代码可能要花开发人员更多的时间，但它同时也产生了更好的代码质量和更容易的审查工作。
如果真的实现不了递增式重构代码（这可能要说一些关于如何写好和组织好源代码的事情），一个可能的解决方案是当进行重构工作时用结对编程来代替代码审查。
解决争议
你的团队无疑是由一群聪明的专业人士组成。当大家对某个确定的编码问题观点不同时，基本上都会产生争议。作为一名开发人员，保持开放的心态，在你的审查者更倾向于一个不同的方法时要随时准备妥协。不要对你的代码持专有的态度，也不要带个人审查意见。如果仅仅是因为有人觉得你应该将一些重复的代码重构为一个可重复利用的函数时，这并不能表明你就不是一个有吸引力的、出色的和有魅力的人。
作为一个审查者，一定要机智。在改变建议之前，认真考虑下是否你给的提议真的更好或仅仅只是你个人风格问题。如果你选择的战场集中在一些源代码中明显需要改进的区域，你将能获得更多的成功。说一些诸如“考虑下……可能是值得的”或“有人建议……”的话更适合，而不是“连我的宠物仓鼠都能写出一个比这更高效的排序算法”。
如果达不到一个中间立场（即双方都不愿意妥协），那么就邀请一个双方都尊敬的第三方开发人员过来看看，让他们给出一些观点和建议。
代码审查（Code Review)是软件开发中常用的手段，和QA测试相比，它更容易发现和架构以及时序相关等较难发现的问题，还可以帮助团队成员提高编程技能，统一编程风格等。
1.代码审查要求团队有良好的文化
团队需要认识到代码审查是为了提高整个团队的能力，而不是针对个体设置的检查“关卡”。
“A的代码有个bug被B发现，所以A能力不行，B能力更好”，这一类的陷阱很容易被扩散从而影响团队内部的协作，因此需要避免。另外，代码审查本身可以提高开发者的能力，让其从自身犯过的错误中学习，从他人的思路中学习。如果开发者对这个流程有抵触或者反感，这个目的就达不到。
2.谨慎的使用审查中问题的发现率作为考评标准
在代码审查中如果发现问题，对于问题的发现者来说这是好事，应该予以鼓励。但对于被发现者，我们不主张使用这个方式予以惩罚。软件开发中bug在所难免，过度苛求本身有悖常理。更糟的是，如果造成参与者怕承担责任，不愿意在审查中指出问题，代码审查就没有任何的价值和意义。
3.控制每次审查的代码数量
根据smartbear在思科所作的调查，每次审查200行-400行的代码效果最好。每次试图审查的代码过多，发现问题的能力就会下降，具体的比例关系如下图所示：
我们在实践中发现，随着开发平台和开发语言的不同，最优的代码审查量有所不同。但是限制每次审查的数量确实非常必要，因为这个过程是高强度的脑力密集型活动。时间一长，代码在审查者眼里只是字母，无任何逻辑联系，自然不会有太多的产出。
4.带着问题去进行审查
我们在每次代码审查中，要求审查者利用自身的经验先思考可能会碰到的问题，然后通过审查工作验证这些问题是否已经解决。一个窍门是，从用户可见的功能出发，假设一个比较复杂的使用场景，在代码阅读中验证这个使用场景是否能够正确工作。
使用这个技巧，可以让审查者有代入感，真正的沉浸入代码中，提高效率。大家都知道看武侠小说不容易瞌睡，而看专业书容易瞌睡，原因就是武侠小说更容易产生代入感。
有的研究建议每次树立目标，控制单位时间内审核的代码数量。这个方法在我们的实践中显得很机械和流程化，不如上面的方法效果好。
5.所有的问题和修改，必须由原作者进行确认
如果在审查中发现问题，务必由原作者进行确认。
这样做有两个目的：
有些时候为了追求效率，有经验的审查者更倾向于直接修改代码乃至重构所有代码，但这样不利于提高团队效率，并且会增加因为重构引入新bug的几率，通常情况下我们不予鼓励。
6.利用代码审查激活个体“能动性"
即使项目进度比较紧张，无法完全的进行代码审查，至少也要进行部分代码的审查，此时随即抽取一些关键部分是个不错的办法。
背后的逻辑是，软件开发是非常有创造性的工作，开发者都有强烈的自我驱动性和自我实现的要求。让开发者知道他写的任何代码都可能被其他人阅读和审察，可以促使开发者集中注意力，尤其是避免将质量糟糕，乃至有低级错误的代码提交给同伴审查。开源软件也很好的利用了这种心态来提高代码质量。
7.在非正式，轻松的环境下进行代码审查
如前所述，代码审查是一个脑力密集型的工作。参与者需要在比较轻松的环境下进行该工作。因此，我们认为像某些实践中建议的那样，以会议的形式进行代码审查效果并不好，不仅因为长时间的会议容易让效率低下，更因为会议上可能出现的争议和思考不利于进行如此复杂的工作。
8.提交代码前自我审查，添加对代码的说明
所有团队成员在提交代码给其他成员审查前，必须先进行一次审查。这次自我修正形式的审查除了检查代码的正确性以外，还可以完成如下的工作：
我们在实践中发现，即使只有原作者进行代码审查，仍然可以很好的提高代码质量。
9.实现中记录笔记可以很好的提高问题发现率
成员在编码的时候应做随手记录，包括在代码中用注释的方式表示，或者记录简单的个人文档，这样做有几个好处：
10.使用好的工具进行轻量级的代码审查
“工欲善其事，必先利其器”。我们使用的是bitbucket提供的代码托管服务。
每个团队成员独立开发功能，然后利用Pull Request的形式将代码提交给审查者。复审者可以很方便在网页上阅读代码，添加评论等，然后原作者会自动收到邮件提醒，对审阅的意见进行讨论。
即使团队成员分布在天南海北，利用bitbucket提供的工具也能很好的进行代码审查。
标签：代码审查 本地测试 codereview
原文地址：http://blog.csdn.net/lemon89/article/details/45067041
