标签：产品 方法 机器 影响 demo 依赖关系 覆盖率 基本概念 类型
读书记录W2
在过去的两周中，我抽空读完了邹欣老师的《构建之法》第二章 个人技术和流程。在前一章中，大多是关于软件工程这门学科的基本概念与介绍，而在这一章内容则是介绍软件开发过程中的必要测试和流程。由于邹老师举例用的C#语言并没有学过，在阅读这章内容中，带给我不少麻烦。
绝大部分软件都是由多人合作完成的，大家的工作互相有依赖关系。单元测试是一种可以让自己负责的模块功能定义尽量明确，使得模块内部的改变不会影响其他模块，而且模块的质量可以得到稳定的、量化的保证。
“// TODO：”一般这样的备注是程序员提醒自己待办事项，相当于备忘录一样的东西。管理设置文件必须双击设置文件才能进入管理及设置界面。进入设置界面后，可以让单元测试产生“demouser.dll”的代码覆盖报告。
创建单元测试函数的主要步骤是：
1.设置数据（一个假想的正确的E-mail地址）
2.使用被测试类型的功能（用E-mail地址来创建一个User类的实体）
3.比较实际结果和预期的结果（Assert.IsTrue（target！=null）；）
单元测试应该准确、快速地保证程序基本模块的正确性。验证其好坏有一系列标准：单元测试应该在最基本的功能/参数上验证程序的正确性；
单元测试必须由最熟悉代码的人（程序的作者）来写；
单元测试过后，机器状态保持不变；
单元测试要快（一个测试的运行时间是几秒钟，而不是几分钟）
单元测试应该产生可重复，一致的结果。
独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。
单元测试应该覆盖所有的代码路径。（100%的代码覆盖率不等同于100%的正确性）
单元测试应该集成到自动测试的框架中。
单元测试必须和产品代码一起保存和维护。
基于单元测试的知识，还有个“回归测试”，即验证在软件升级后，过去正常的地方有没有退化为不正常的状态。这个环节一般在软件开发完毕或新版本升级后的测试阶段，目的就是减少bug的出现。尤其像微软，在一个项目的最后稳定阶段，要进行全面的测试工作，把过去的bug都拿出来测试。
除此之外，有个效能分析工具，即让自己的程序跑的比别人的又快又好。分析方法分两种：抽样（运行快，不精确）和代码注入（时间长）。一般的做法是，先用抽样的方法找到效能的瓶颈，然后对特定的模块用代码注入的方法进行详细分析。如果不经分析就盲目优化，也许会事倍功半。
个人开发流程（PSP）是针对软件工程师团队能力成熟度的一套模型。他每个版本对程序员有更多的要求，其依赖数据，需要大量的时间和精力。PSP的目的是记录工程师如何实现需求的效率，而不是顾客对产品的满意度。
虽然看懂了本章内容中关于单元测试、回归测试、效能分析工具及个人开发流程（PSP）中的基本概念，但由于对C#语言的一知半解，没看懂本章内容中的举例语句，并不能亲身体验下测试，等以后学会了，再学习测试吧。
标签：产品 方法 机器 影响 demo 依赖关系 覆盖率 基本概念 类型
原文地址：http://www.cnblogs.com/SHong0321/p/6750190.html
