首页 > 代码库 > 读构建之法 第二章:个人技术和流程
读构建之法 第二章:个人技术和流程
绝大部分软件都是由多人合作完成的,大家的工作相互有依赖关系。某人负责的模块的功能被其他人调用,但如何让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证???单元测试就是一个很有效的解决方案。
创建单元测试函数的主要步骤是:
1.设置数据(一个假象的正确的E-mail地址)
2.使用被测试类型的功能(用E-mail地址来创建一个User类的实体)
3.比较实际结果和预期的结果(Assert.IsTrue(target!=null)
创建完就可以运行单元测试了,同时可以看看代码覆盖报告,代码百分百地都被覆盖了。
怎样才算一个好的单元测试呢?单元测试应该准确、快速地保证程序基本模块的正确性。
验证单元测试好坏的一系列标准:
1.单元测试应该在最基本的功能、参数上验证程序的正确性;
2.单元测试必须由最熟悉代码的人(程序的作者)来写;最好是在设计的时候就写好单元测试,这样单元测试就能体现API的语义,保障语义的准确性。
3.单元测试过后,机器状态保持不变;这样就能不断地运行单元测试。
4.单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟);快才能保证效率
5.单元测试应该产生可重复、一致的结果;
6.独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性;
7.单元测试应该覆盖所有代码路径,包括错误处理路径;(要注意:100%的代码覆盖率并不等同于100%的正确性)
8.单元测试应该集成到自动测试的框架中;把单元测试自动化,这样每个人都能随时随地运行单元测试。
9.单元测试必须和产品代码一起保存和维护;
在单元测试的基础上,建立关于这一模块的回归测试(Regression Test)
针对一个Bug Fix,我们也要做Regression Test。目的是1.验证新的代码的确改正了缺陷 2.同时要验证新的代码有没有破坏模块的现有功能,有没有Regression
回归测试中的回归可以将其理解为“回归到以前不正常的状态”
回归测试最好要自动化,这样就可以对于每一个构建快速运行所有回归测试,以保证尽早发现问题。
VSTS提供了方便的效能分析工具,让我们能很快地找到程序的效能瓶颈,从而能有的放矢,改进程序。
效能分析可以选择两种分析方法:
1.抽样(Sampling)优点:不需改动程序,运行较快,可以很快找到瓶颈,缺点:不能得出精确的数据,也不能准确表示代码中的调用关系树
2.代码注入(Instrumentation)缺点是程序的运行时间会大大加长,还会产生很大的数据文件,相应的增加了数据分析的时间,同时注入的代码也影响了程序真实的运行情况。
一般的做法是先用抽样的方法找到效能瓶颈所在,然后对待定的模块用代码注入的方法进行详细分析。
看个人项目耗时对比记录表,显然,从学生到职业程序员,并不是更加没完没了的写程序——花在写代码上的时间反而少了许多。
实践是理论的基础和验证标准
实践最简单的项目:WC,根据书上项目要求,实现一个统计程序
如何保证质量——回归测试
如何为这个程序做有效的测试,有以下几种方法,自动化程序由低到高。
1.手动测试,手工比较
2.要做到不断地测试,可以把WC的主要功能封装成一个类,然后测试程序员调用这一个类的主要函数,得出结果并与标准作比较。
3.更进一步,比较测试的输出和标注结果
4.再进一步,把自动构建脚本和构建验证测试结合起来。记录出现的bug。
我看完认为第二章主要讲的是 在设计的时候就写好单元测试,保证程序基本模块的正确性;在单元测试的基础上,建立模块的回归测试,保证之前所有已经发现并修复的bug的确得到了修复,并没有在最后一个版本中复发,才能保证尽早发现问题。还有对程序的效能分析,提高效能,优化程序。
读构建之法 第二章:个人技术和流程