码迷,mamicode.com
首页 > 其他好文 > 详细

构建之法第二章

时间:2017-01-29 23:04:43      阅读:260      评论:0      收藏:0      [点我收藏+]

标签:需求分析   代码覆盖率   自己   合作   软件开发   个人   mil   cal   分析   

构建之法第二章

本章为个人技术和流程,主要介绍了单元测试、回归测试、效能分析和个人软件开发流程等内容。

单元测试:如何能让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证,单元测试就是一个很有效的解决方案。

1、VSTS写单元测试:在写技术模块的规格说明书的时候,要越详细越好,最好各项要求都可以表示为一个单元测试用例。

2、好的单元测试的标准:

1>单元测试应该在最基本的功能/参数上验证程序的正确性

2>单元测试必须由最熟悉代码的人(程序的作者)来写

3>单元测试后,机器状态保持不变

4>单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)

5>单元测试应该产生可重复、一致的结果

6>独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立性

7>单元测试应该覆盖所有代码路径:100%的代码覆盖率并不等同于100%的正确性

8>单元测试应该集成到自动测试的框架中

9>单元测试必须和产品代码一起保存和维护

3、回归测试:可以理解为“回归到以前不正常的状态”,单元测试是回归测试的基础

4、效能分析工具:两种分析方法为抽样和代码注入;一般做法为先用抽样的方法找到效能瓶颈所在,然后对特定的模块用代码注入的方法进行详细分析;如果我们不经过分析就盲目优化,也许会事倍功半

5、个人开发流程:根据数据显示,从学生到职业程序员,并不是更加没完没了地写程序,花在写代码的时间反而少了许多,而在“需求分析”和“测试”这两方面明显要花更多时间,在具体编码上花费时间少。

    虽然,在实际软件开发中,需要团队的合作,但是在团队中,每个人都应该到达一定的水平,也就是这章讲述的个人技术和流程,可以说这是基础,只有每个人的技术和开发流程打到一定的标准,有一定的规范,才有利于团队之间多人的合作,才能保证配合开发出来的软件的各个模块都是符合标准的,具有一定健壮性的,利于维护和更新。

构建之法第二章

标签:需求分析   代码覆盖率   自己   合作   软件开发   个人   mil   cal   分析   

原文地址:http://www.cnblogs.com/zhaoziming/p/6357769.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!