构建之法 学习笔记04

关于软件工程的一些基本概念和技术

单元测试

绝大部分软件都是由多人合作完成的,大家的工作互相有依赖关系。最典型的的例子就是,某人负责的模板的功能被其他人调用。
软件的额很多错误都是来源于程序员对模块功能的误解、疏忽或不了解模块的变化。单元测试可以有效的解决这些问题。

用VSTS写单元测试
许多应用程序中都会用到“用户”这一类型,用户的标识通常是一个邮件地址。
创建单元测试含糊的主要步骤是:
1.设置数据(一个假想的正确的E-mail地址)
2.使用被测试类型的功能(用E-mail地址来创建一个User类的实体)
3.比较实际结果和预期的结果(Assert.IsTure(target!=null);)

需要注意的地方:
单元测试应该在最基本的功能/参数上验证程序的正确性。
单元测试必须有最熟悉代码的人(程序的作者)来写。代码的作者最了解代码的目的、特点和实现的局限性。
单元测试过后,机器状态不变,这样就可以不断的运行单元测试。
单元测试要快(一个测试的运行时间是几秒钟,而不是几分钟)。快,才能保证效率。
单元测试应该产生可重复、一致的结果。
独立性——单元测试的运行/通过/失败不依赖于别的测试,可以人为构造数据,以保证单元测试的独立性。
单元测试应该覆盖所有的代码路径,包括错误处理路径。100%的代码覆盖率并不等于100%的正确性。
单元测试应该集成到自动测试的框架中。把单元测试自动化,这样单元测试的错误就能被及时发现。
单元测试必须和代码一起进行版本保护。

时间: 2024-10-27 04:23:11

构建之法 学习笔记04的相关文章

《构建之法阅读笔记04》

构建之法的一核心就是“做中学”,所以在上次做软件需求分析后,我学习了软件需求分析这一章节内容.竞争性需求分析的框架 1.N(Need,需求)我们开发软件时为人服务,因此很大一定程度上,我们必须了解客户需求和市场需求,找到该产品的市场前景和需求人群如果,前景渺茫的话,项目产品就没有意义.因此需求是最重要的. 2.A(Approach,做法)这是我们与其他相似软件的独特之处,可以使我们的软件更加突出,用这个独特的招数来解决用户的痛苦,这不仅是技术上的,也可以是商业模式上的,人脉方面的,行业方面的或者

构建之法 学习笔记01

起初我只是在专业要求的硬性规定下去接触了这本<构建之法>,然后仔细的看下来之后确实让我受益匪浅,让我更切实的了解了这个行业.这本书对我来书最实用的地方在于,在高大上的理论之后会有具体的实例来帮助理解.在介绍方法论的同时,会介绍方法论不适用的场景,介绍方法论在现实中是怎样跑偏--什么叫宏观视角?什么叫最佳实践?什么叫算无遗策?就像画一棵决策树,向哪个分支走,结果会怎么样,清清楚楚,明明白白,让人信服.能让学生了解到工作中接触的种种角色及其想法.诉求,避免"以程序为中心"思考问

构建之法 学习笔记02

在一个项目运行的过程中,所有参与者都是团队的一份子,都是推进进度的零件.因此在知识和技术之上,不可或缺的是对于团队的建设. 在这次的学习笔记之中我想简要谈谈本书的第十七章的内容--人,绩效和职业德行. 在这个章节里,书中首先提出了这样一个概念:猪,鸡和鹦鹉,这三种动物都有着在团队中各自潜在的含义.一个团队的人可能来自五湖四海,有个各自的性格和特性,但是肯定都有着同一个目标,为着同一个目标而走到了一起. 有些人是猪--在这里的意向并无贬义,对他们来说,想要项目成功就得拿出自己身上的肉,背水一战:一

构建之法阅读笔记04

2017.4.1 今天我看的是绩效管理的内容,这是一个软件在阶段性总结时所不能逃避的话题,每个团队都应该有自己的团队绩效,应该用团队绩效来评估该团队的成员在这一阶段对这个软件做出的贡献.这好像的确是一个问题.我们应该从不同的方面来评估一个人在这一阶段对软件做出的贡献.单单从一个方面去评估一个人的价值是不合理的. 每个人在每个方面的贡献都是不可低估的.另外这章中还提到了团队合作的几个阶段,开始大家聚集在一起,是团队的萌芽阶段,每个人都很生疏,不知道做事的流程,不知道在团队中该怎么做.接着团队进入磨

构建之法 学习笔记07

在之前长时间的理论学习之后,这周也快到学期期末了,结合本书第十章 10.2用例(USE CASE)与我的java设计模式课程作业,我对我的原型模式课题稍做了一些研究 . 和典型人物.典型场景的方法类似,用例(UseCase)也是很常用的需求分析工具.用例有这样一些 基本元素: 标题:描述这个用例要达到的目标 角色(Actor):和软件系统交互的角色,例如用户,其他实体,甚至时间(在描述一些和时间相关的场景时有用) 主要成功场景(Main Success Scenario):一系列步骤描述角色是怎

构建之法 学习笔记06

关于敏捷流程. 在软件工程的语境中,"敏捷流程"是一系列价值观和方法论的集合.从2001年开始,一些软件界的专家开始倡导"敏捷"的价值观和流程,他们肯定了流行做法的价值,但是强调了敏捷做法更能带来价值 ."敏捷"(Agile)是一种思潮,或者说是一种价值观,它涵盖了好几种软件开发的方法论(Methodology):这些方法论又是建立在许多行之有效的最佳实践方法(Best Practices)之上的.而关于敏捷的方法论比较有名的是一下三种:1.爱抚

构建之法 阅读笔记04

敏捷开发原则:1.尽早并持续地交付有价值的软件以满足顾客需求.2.敏捷流程欢迎需求的变化,并利用这种变化来提高用户的竞争优势 3.经常发布可用的软件,发布间隔可以从几周到几个月,能短则短 4.业务人员和开发人员在项目开发过程中应该每天共同工作 5.以有进取心的人为项目核心,充分支持信任他们      6.无论团队内外,面对面的交流始终是最有效的沟通方式     7.可用的软件是衡量项目进展的主要指标     8.敏捷流程应能保持可持续的发展.领导.团队和用户应该能按照目前的步调持续合作下去   

构建之法读书笔记04

敏捷流程是一系列价值观和方法论的结合,顾名思义的来说,敏捷就是速度,在速度上要敏捷.上课时,老师利用动画给我们进行了生动的剖析,就客户的要求,树,绳子,板等要素,但由于不同人的不同理解,造成了很大的偏薄,客户的要求不一定会完全按照客户的想法完全展示出来,而最重要的就是经验,漫长的开发周期中,人员之间没有反馈,而客户又没有更改目标,造成了很多人的不满意. 敏捷流程的其中中心思想是注重最终的可用交付,注重人的沟通协作,但坦率的讲,在国内的项目型开发中,学要积极地地探索如何坚持这个敏捷的思路与需求编程

老师的问题和《构建之法》笔记

谈构建之法之前,先回答老师的几个问题~ 1.我本科专业是物联网工程,四年间的学习内容一直处于软硬件间摇摆,一度使我怀疑人生.这种学习方式最大的好处是可以从底层理解整个计算机的运作,循序渐进,而最大的缺点是,体系太过于庞大,低效,冗杂.当我到了大三的时候,我依然不能够独立编写一些软件,也不能处理有意义的硬件问题,所以当务之急便是做出取舍,否则我的大学可能就止步于C语言和单片机了.几经周折,最后还是选定了偏向软件的方向,原因众多,硬件的学习难度和深度让我苦不堪言,对数模电,通信原理,高频电路亦有较高