构建之法之个人技术和流程重点介绍

 

2.1 单元测试

软件是由多人合作完成的,不同人员的工作相互有依赖关系。例如,一个人写的模块被其他人写得模块调用。软件的很多错误都来源于程序员对模块功能的误解、疏忽或不了解模块的变化。如何能让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的、量化的保证?单元测试就是一个很有效的解决方法。

2.1.2 好的单元测试的标准

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

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

单元测试过后,机器状态保持不变。

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

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

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

单元测试应该覆盖所有代码路径。

单元测试应该集成到自动测试的框架中。How?

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

2.1.3 回归测试

针对一个Bug Fix,我们也要做Regression Test。目的是:

1.验证新的代码的确改正了缺陷

2.同时要验证新的代码有没有破坏模块现有的功能,有没有Regression

 

2.3 个人开发流程


PSP2.1


计划


*估计这个任务需要多少时间


开发


*分析需求


*生成设计文档


*设计复审(和同事审核设计文档)


*代码规范(为目前的开发制定合适的规范)


*具体设计


*具体编码


*代码复审


*测试(包括自测,修改代码,提交修改)


记录用时


测试报告


计算工作量


事后总结


提出过程改进计划

2.4 实践

2.4.2 实践最简单的项目:WC

1. 实现一个简单而完整的软件工具(源程序特征统计程序)

2. 进行单元测试、回归测试、效能测试,在实现上述程序的过程中使用相关的工具

3. 进行个人软件过程(PSP)的实践,逐步记录自己在每个软件工程环节花费的时间。

4. 使用项目管理系统,练习使用其中的事件跟踪系统。(选用TFS,Bugzilla或者Trac,了解原理)

2.4.2.1 WC项目要求

程序处理用户需求的模式为:

wc.exe[parament][file_name]

各个参数的意义:

基本功能列表:

wc.exe-c file.c:        char count

wc.exe-w file.c:       word count

wc.exe-l file.c:                   line count

扩展功能:

-s递归处理目录下符合条件的文件。

-a返回高级选项(代码行/空行/注释行)。

空行:

本行全部是空格或格式控制符,如果包括代码,则只有不超过一个可显示的字符,例如“}”。

代码行:本行包括多于一个字符的代码。

注释行:本行不是代码行,并且本行包括注释。一个有趣的例子是有些程序员会在单字符后面加注释;

}//注释

在这种情况下,这一行属于注释行。

[file_name]:文件或目录名,可以处理一般通配符。

文本文件,确定字/词/句。

高级功能:

-x参数。这个参数单独使用。如果命令行有这个参数,则程序会显示图形界面,用户可以通过界面选取单个文件,程序就会显示文件的字符数、行数等全部统计信息。

需求举例:

wc.exe -s -a *.c

返回当前目录及子目录中所有*.c文件的代码行数、空行数、注释行数。

2.4.2.2 工作的细分

罗马不是一天建成的。三个估计时间。

2.4.2.3 如何保证质量——回归测试

1. 手动测试,手工比较。

2. 要做到不断地测试,可以把WC的主要功能封装成一个类,然后测试程序调用这个类的主要函数,得出结果并与标准做比较。

3. 更进一步,把测试文件和正确的测试结果保存在文件中,测试驱动程序只要比较测试的输出和标准结果就能得出答案。

4. 再进一步,把自动构建脚本和构建验证测试结合起来。每一次构建之后,就自动运行测试,然后记录出现的Bug。

时间: 2024-10-15 13:42:36

构建之法之个人技术和流程重点介绍的相关文章

《构建之法》——个人技术和流程

#一.单元测试 单元测试的作用:让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块,而且模块的质量能得到稳定的.量化的保证. ##1.1 好的单元测试的标准 单元测试应该在最基本的功能/参数上验证程序的正确性. 单元测试必须由最熟悉代码的人(程序的作者)来写. 单元测试过后,机器状态保持不变. 单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟). 单元测试应该产生可重复.一致的结果. 独立性--单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保持单元测试的独立

构建之法---敏捷流程

最近为了完成java设计模式和uml的大作业算是花了不少时间来动脑理解和动手编写代码,也开始发现代码的神奇和美妙,java竟然可以开发简单的小游戏,而且代码并不向想象中那样难以理解,其中的规律似乎很神奇.带着这种愉悦美好的心情读<构建之法>,或许会比以前收获更多. 继瀑布模型之后又前辈们提出了"敏捷",1.敏捷这个词听起来就是反应灵敏迅速而有效,而在软件按工程里,敏捷不同于现有做法之处在于:敏捷的价值观和流程是个人和交流.可用的软件.与客户合作.响应变化,而现有做法的则是流

构建之法 第六章 敏捷流程

敏捷开发的原则是: 1.尽早并持续交付有价值的软件来满足顾客 2.利用不断的变化来提高用户竞争优势 3.发布软件的周期越短越好 4.业务人员和开发人员随时沟通共同工作 5.要有进取心,并给予大力的支持 6.以面对面交流为主要沟通方式 7.软件的可用率是衡量项目进展的主要指标 8.可持续发展:9.以技术和设计为核心 10.简化工作量,要少而精 11.有自我管理能力 12.不断总结自我,提高效率,改正问题.

作业四:《构建之法》567章关于流程的思考与问题

5.3.5——老板驱动的流程. “领导对许多技术细节是外行.”——这是说我现在不用专研一个领域到太深的境界吗?就像说我现在对于Java只要我知道它是一个高级编程语言就好了~哈哈哈哈哈· 6.4.2敏捷流程的经验教训 ——我从书中知道它是一系列价值观核方法论的集合(毛概?).在该点提出的经验第7条中,“不要和管理层谈‘流程’,他们只关心结果.” 这一点让我联想到5.3.5的老板驱动,这就是好好学习的学霸将来要为我们这些学渣干活的前奏了~会不会实现呢? 7.2.3充分授权和信任 书中提出了授权的两个

构建之法第六章学习心得

这周我学习了构建之法第六章敏捷流程,本章主要介绍了敏捷流程及其原则,Backlog.Burn-down.Sprint.Scrum方法论.以及什么时候选择敏捷的开发方法,什么时候选择其他方法..敏捷开发的原则是尽早并持续地交付有价值的软件以满足顾客需求敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势经常发布可用的软件,发布间隔可以从几周到几个月,能短则短业务人员和开发人员在项目开发过程中应该每天共同工作以有进取心的人为项目核心,充分支持信任他们无论团队内外,面对面的交流始终是最有效的沟通

构建之法(概论,个人技术和流程)

构建之法这本书第一章给我们讲述了软件以及软件工程的含义. 软件=程序+软件工程.书中用编写出加减法题目的程序的例子生动形象的说明了程序,软件,工程之间的关系,以及软件工程的一些概念.程序,在这里指的是源程序,就是一行行的代码.他们是建立在数据结构上的一些算法.但软件工程的内容远不止这些.软件工程的核心部分包括和软件开发活动(构建管理.源代码管理.软件设计.软件测试.项目管理)相关的内容.广义上的软件工程也包括用户体验.用户界面设计等.所以,一个推论是:软件=程序+软件工程,一个扩展的推论是:软件

构建之法 第二章 个人技术和流程

这一章重点介绍的是以前了解过但未曾注重过的单元测试&回归测试:个人技术素养是团队协作的基础. 1.VSTS单元测试 源代码 public Class User() { public User(string userEmail) { memail = userEmail; } private string memail;//private变量拒绝外部类访问(除非用get/set方法) } 测试代码1 public void ConstructorTest() { string userEmail

个人技术和流程(构建之法)

一个成功的商业软件的发不可能是一个人单枪匹马做出来的,而是一个团队通力协作共同完成的.而团队并不能让每个人都了解你的程序,也不能让你了解每个人的程序.所以一个团队要想做出一款好的产品团队里的成员必须是一名合格的软件工程师.所以我们还要先掌握些基本的概念和技术比如说单元测试.回归测试和效能分析工具.同时一个团队需要一定得流程来管理开发活动每个工程师在软件的生命周期所做的工作也该有个流程,即个人软件开发流程. 单元测试是一种能让自己负责的模块功能定义尽量明确,模块内部的改变不会影响其他模块.而且模块

《构建之法》学习(5)——团队和流程

<构建之法>学习(5)--团队和流程 1.非团队和团队   团队共同的特点: 团队有一致的集体目标,团队要一起完成这目标 团队成员有各自的分工,互相依赖合作,共同完成任务 2.软件团队的模式       一窝蜂模式       主治医师模式 有首席程序员,他/她负责处理主要模块的设计和编码,其他成员从各种角度支持他/她的工作.       明星模式 主治医师模式运用到极点,可以蜕化为明星模式,在这里,明星的光芒盖过了团队其他人的总和.       社区模式 社区由很多志愿者参与,每个人参与自己