标签：团队 单元测试 应该 自动 重复 程序代码 瓶颈 下标 集成
一个成功的商业软件的发不可能是一个人单枪匹马做出来的，而是一个团队通力协作共同完成的。而团队并不能让每个人都了解你的程序，也不能让你了解每个人的程序。所以一个团队要想做出一款好的产品团队里的成员必须是一名合格的软件工程师。所以我们还要先掌握些基本的概念和技术比如说单元测试、回归测试和效能分析工具。同时一个团队需要一定得流程来管理开发活动每个工程师在软件的生命周期所做的工作也该有个流程，即个人软件开发流程。
单元测试是一种能让自己负责的模块功能定义尽量明确，模块内部的改变不会影响其他模块、而且模块的质量能得到稳定的量化的保证的很有效的解决方案。
一个好的单元测试应当准确快速的保证程序基本模块的正确性。一个好的单元测试应该满足一下标准：
1.单元测试应该在最基本的功能（参数）上验证程序的正确性。
2.单元测试应该由最熟悉代码的人（最好是程序的作者）来写。
3.单元测试过后机器的状态应保持不变。
4.单元测试要快（一个测试要几秒钟而不是几分钟）。
5.单元测试应该产生可重复一致的结果。
6.独立性 单元测试的运行、通过、失败不依赖别的测试，可以认为构造数据，以保持单元测试的独立性。
7.单元测试应该覆盖所有代码路径。
8.单元测试应该集成到自动测试的框架中。
9.单元测试必须和产品代码一起保存维护。
每个单元都进行了100%的覆盖后，就可以进行关于这一模块的回归测试。回归测试可以理解为“回归到以前不正常的状态”所进行的测试。针对一个Bug Fix也要做一个回归测试，目的是验证新的代码的确改正了缺陷同时要验证新的代码有没有破坏现有的功能，有没有功能的退化。
回归测试最好要自动化，这样可以对每一个构造快速的运行所有的回归测试，以保证尽量早的发现问题。所以说单元测试是回归测试的基础。
效能分析工具可以测试代码运行的效率，让程序员有针对性的对程序代码进行优化升级。常用的方法有两个 1.抽样。 2.代码注入。
抽样就是当程序运行时 效能分析工具时不时的看看程序运行在哪一个函数里，程序运行结束就会得出一个程序运行时间的大致印象。抽样的有点是不需要改动程序运行较快可以很快找到瓶颈但是不能得出精确数据也不能准确得表示出代码中得调用关系树。
代码注入就是将检验代码加入到每个函数中，这样程序得一举一动都会被记录下来，程序得各个效能数据可以被精准的测量，但是缺点也很明显，他会让程序运行的时间大大加长，还会产生大量得数据文件也增加了数据分析得时间，同时注入的程序代码也影响了程序真实得运行情况。所以一般常用先抽样找到效能的瓶颈所在让后对特定的模块用代码注入的方式进行详细得分析。
个人开发流程就是软件工程师开发软件的工作流程它并不局限在某种软件技术而是着眼于软件的开发流程，它不依赖考试而是要靠工程师自己收集数据然后分析提高。psp依赖于数据而非程序本身。psp的目的是记录工程师如何完成实现需求的效率而不是记录顾客对产品的满意度。
个人的技术和流程只有在实践中才能真正了解体会到当中的深意。实践的过程中能够找到自己的不足。才能加以改正。
标签：团队 单元测试 应该 自动 重复 程序代码 瓶颈 下标 集成
原文地址：http://www.cnblogs.com/wangfengbin/p/6380518.html
