构建之法阅读心得（二）

第二章中，作者写到了好的单元测试的标：单元测试应该在最基本的功能/参数上验证程序的正确性、单元测试必须由最熟悉的人来写、单元测试过后，机器状态保持不变、单元测试要快、单元测试应该产生可重复、一致的结果。独立性——单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。单元测试应该覆盖所有代码路径，但是100%的代码覆盖率并不等同于100%的正确性、单元测试应该集成到自动测试的框架中、单元测试必须和产品代码一起保存和维护。

程序要进行单元测试来保证程序的健壮性。

还要进行回归测试，就是在原版本上运行的测试用例通过的话，在下一版本上再运行时，却没有通过，这就是软件"退化"，所以需要进行回归测试。在新版本上运行所有已经通过的测试用例，来验证后面的版本没有出现软件"退化"的情况。

但是如果是模块功能发生了变化，那么测试用例也需要修改来测试新的模块。

程序还要进行效能分析，这个是以前从来没有了解过的。就是找出程序运行时，哪个函数或方法消耗的时间多，就是程序运行的瓶颈所在，进行效能分析，从而对相应模块的代码进行优化。进行效能分析的方法有抽样和代码注入，各有优缺点。不过普遍用的是先用抽样方法找到瓶颈所在，然后对特定模块的代码用代码注入的方法进行详细分析。还要注意避免没有做分析就过早进行"效能提高"。

对程序员或者工程师是有能力成熟度模型的。工程师在需求分析和测试上花的时间更多，而在具体编码中比大学生花的时间少一半多，从学生到职业程序员，以后在写代码的时间会少很多，更多是用在分析上。

转载于:https://www.cnblogs.com/panjiawei/p/6713246.html

构建之法阅读心得（二）相关推荐

深入理解Java虚拟机阅读心得(二)
深入理解Java虚拟机阅读心得(二) 垃圾收集程序计数器.虚拟机栈.本地方法栈三个区域随线程而生,随线程而灭:这几个区域的内存分配和回收都具备稳定性,不需要过多的考虑回收的问题.而Java堆和方法区 ...
构建之法阅读笔记之三
构建之法阅读笔记之三本章为团队和流程,主要介绍了典型的软件团队模式和开发流程以及它们的优缺点.TSP.MVP.MBP.RUP 团队:并不是几个人凑到一起就叫团队,称之为团队 1.应该有一致的集体目标 ...
构建之法阅读笔记（二）
离上次写阅读笔记很长时间了,罪恶感涌来.. 这次主要写一下我对创新的感受,这部分是在<构建之法>的第16章-IT行业的创新. 最近几年我经常能够听到"创新"这个词,总以 ...
构建之法第一、二、十六章
<构建之法>第一.二.十六章疑问我通过阅读发现这是一本十分有趣的书.不同于别的书的晦涩难懂,<构建之法>利用浅显易懂的语言,贴近生活的例子向我们讲述了软件工程的内容. 第一章 ...
构建之法阅读笔记05
这周时间,我阅读了构建之法的第九.十.十一章节. 在第九章中,邹欣老师给我们讲述了在我们的软件团队里除了能写代码.测试代码和画图做设计的成员,还有一类角色,不做上面这些事情但也很重要,我们叫他们项目经 ...
构建之法阅读笔记03
又到了一周的结尾,时间过得真快.这一周,阅读了<构建之法>关于团队和流程的部分.正好,这周我们用的就是结对开发的模式.算是理论加上实践吧. 和以往的单独编程不同的是,团队开发增加了与同学的 ...
构建之法阅读笔记之速读篇
新学期开始,我们开设了软件工程课程,在老师的指导下,我从网上找到了<构建之法>这本书,随着课堂上老师的讲解以及书籍的快速阅读,我对软件工程有了很多的了解.之前我们的编程只能算是基础,远远没 ...
05构建之法阅读笔记之三
今天看的构建之法的第10章"典型用户和场景",书上开始举了一个很好理解的例子,是一个理发师给顾客剪头发的例子,由例子可见,你光看用户的表面语言是不够的,我们应该理解的是用户语言背后 ...
构建之法阅读笔记06
第十二章:用户体验用户对产品的第一印象是非常重要的,所以要尽量让用户在第一次使用时,少花时间在对他没有价值的部分,并且尽量花最少的时间让用户了解软件的基本功能并学会使用.需要站在用户的角度考虑问题, ...

构建之法阅读心得（二）

构建之法阅读心得（二）相关推荐

最新文章

热门文章