也许是因为我经常在twitter上鼓吹“代码质量来自code review和单元测试”，老赵的这篇文字《一份用于学习单元测试的案例需求》也at我一下，抱歉的是近欠债太多，正在着手完成答应侯伯薇的那篇关于appengine的文字。

　　趁着兴头和近的一些工作简单谈谈我的软件测试观点。

　　上周五小组对前一阵的一个项目做了整体的代码review，然后对单元测试代码也简单review了一下，大概二十几个测试用例完全通过，mstest中一条条绿杠杠让人很开心。

　　英语加技术学习，看了这篇 http://net.tutsplus.com/tutorials/ruby/the-intro-to-rails-screencast-i-wish-i-had/ 其中正好讲解了如何使用TDD开发rails程序，酷毙了，其中guard，rspec，capybara这些Ruby的好玩意让我等DotNet程序员羡慕不已。

　　如何进行高质量软件开发？是我这大半年一直在思考和研究的问题。对于我们大部分项目的流程，简单总结起来是，前期需求review，设计review，风险评估，开发中期review，代码结束review，维护阶段。

　　前期review主要是保证项目不要过早的投入编码，设计上不够成熟或者没有考虑的很清晰。我发现不少人是以编码代替设计，或者说还没有想好怎么设计，代码号称写完百分之八十了，很无语。前期review以主力程序员担当设计和主要技术攻关，并且反复确认设计中不清晰的地方。在前期设计阶段也会对任务进行分派，其中有程序实现，单元测试实现，手动测试实现，代码review等不同角色。理论上说单元测试应该由程序实现者完成，但是由于项目特点决定，我们对于某些项目的单元测试是有另外的程序员实现，稍大一些的项目（或者说story）需要有三个人熟悉设计和代码实现，大致是一到两个实现者，一到两个代码review人员，这样有些人担心的“对项目不熟悉代码不熟悉，怎么进行code review？“的问题不存在了，而且也很好的保证了万一有人请假有事，其他人也可以很快完成任务。

　　开发中期review，主要是对整体思路再次检查一遍，另外确保项目整体质量是OK的，上个月在中期review的时候，果断叫停某个质量很低的项目，调入一个主力程序员重新设计，虽然浪费了一些时间，但是代码质量比前一个版本要好很多。

　　代码结束review，是整个小组对项目实现进行逐行的分析解读，貌似这样会比较浪费时间。但是我们现在团队初建，很多技术甚至是常识都需要反复强调，这种小组review很有必要，也是很好的学习过程。

　　再着重谈谈单元测试。通过比较NUnit和MSTest后选择MSTest作为测试框架，另外也会选择集成测试或者是接口测试等不同测试级别，主要是看项目需要，并不拘泥于非要单元测试。现在的问题是单元测试本身设计的还不够，基本上只考虑”正常、异常、上临界、下临界、空值、复杂值“这些情况，没法做到很好的代码覆盖率，希望这个在以后能慢慢提高。MSTest的使用很简单，基本上跟Nunit没啥区别，好处是可以直接集成在VS2010高级版中，另外也可以通过mstest命令行调用，持续集成也很容易。

　　我们基本上会在项目设计阶段对测试用例同时进行设计考虑，然后会留出大约百分之三十到四十的时间给单元测试或者自动测试。这个比例根据项目重要程度或者复杂程度也会相应地调整。

　　另外一个很关键的问题是”如何测试GUI？”对于asp.net mvc，我们基本上只会自动测试controller，对于view部分，是准备使用自动的browser测试框架来做，现在还是以手动测试为主；对于wpf程序，主要是测试viewmodel部分，但是现在也主要以手动测试为主。对于需求倾向于前端的应用，基本上不会考虑单元测试。但是为了很好地保证质量，我们会把关键的需求点作为测试用例，然后有人专门做手动测试。也开发了一个自动记录回放的小软件，但是效果一般，基本没用。

　　团队初建，我个人经验不足，所以很多也是在摸索调整，希望以后能有更完整高效的开发流程可以分享给各位。