| 1、单元测试应该在最基本的功能/参数上验证程序的正确性。 |
单元测试应该测试程序中最基本的单元一如在 C++/C#/ava中的类，在此基础上，可以测试一些系统中最基本的功能点(这些功能点由几个基本类组成)。从面向对象的设计原理出发，系统中最基本的功能点也应该由-一个类及 其方法来表现。单元测试要测试API中的每一个方法及每一个参数。单元测试必须由最熟悉代码的人(程序的作者)来写。代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。 |
| 2、单元测试过后，机器状态保持不变。 |
这样就可以不断地运行单元测试，如果单元测试创建了临时的文件或目录，应该在Teardown阶段删掉。如果单元测试在数据库中创建或修改了记录，那么也许要删除或恢复这些记录，或者每一个单元测试使用一个新的数据库，这样可以保证单元测试不受以前单元测试实例的干扰。 |
| 3、单元测试要快(一个测试的运行时间是几秒钟，而不是几分钟)。 |
快，才能保证效率。因为一个软件中有几十个基本模块(类)，每个模块又有几个方法，基本上我们要求- -个类的测试要在几秒钟内完成。如果软件有相互独立的几个层次，那么在测试组中可以分类，如数据库层次、网络通信层次、客户逻辑层次和用户界面层次，可以分类运行测试，比如只修改了“用户界面”的代码，则只需运行“用户界面”的单元测试。 |
| 4、单元测试应该产生可重复、一致的结果。 |
如果单元测试的结果是错的，那- -定是 程序出了问题，而且这个错误一-定 是可以重复的。 |
| 5、独立性一单元测试的运行/通过/失败不依赖于别的测试，可以人为构造数据，以保持单元测试的独立性。 |
程序中的各个模块都是互相依赖的，否则它们就不会出现在一个程序中。一般情况下，单元测试中的模块可以直接引用其他的模块，并期待其他的模块能返回正确的结果。如果其他的模块很不稳定，或者其他模块运行比较费时(如进行网络操作)，而且对于本模块的正确性并不起关键的作用，这时可以人为地构造数据，以保证单元测试的独立性。 |
| 6、单元测试应该覆盖所有代码路径。 |
单元测试应覆盖所测单元的所有代码路径，包括错误处理路径。为了保证代码覆盖率，单元测试必须测试公开的和私有的函数1方法。 |
| 7、单元测试应该集成到自动测试的框架中。 |
另一个重要的措施是要把单元测试自动化，这样每个人都能随时、随地运行单元测试。团队一般是在每8构建之后运行单元测试的，这样单元测试的错误就能及时被发现并得到修改。 |
| 8、单元测试必须和产品代码一起保存和维护。 |
单元测试必须和代码一起 进行版本维护。如果不是这样，过了一阵，代码和单元测试就会出现不一致,程序员要花时间来确认哪些是程序出现的错误，哪些是由于单元测试滞后造成的错误。这样就失去了单元测试的意义，同时又给大家增加了负担。如此折腾多次以后，大家就会觉得维护单元测试费时又费力。 |
| 问题二、软件的特殊性是什么？有哪些？ |
|
| 在谈软件工程之前，不妨先来看看软件。软件是可以运行在计算机及电子设备中的指令和数据的有序集合。软件有各种分类方法，下面是其中的一一种: |
|
| 系统软件:操作系统、设备驱动程序、工具软件等应用软件:用户使用它们来完成工作，从管理核电厂到写文章，或者是通信、游戏、浏览网页、播放视频等 |
|
| 恶意软件:软件病毒等。软件和人类制造出来的其他产品相比，有许多共性，也有一些特殊性。它们都是解决某种需求。随着人类社会的发展，技术的进步，很多需求变得越来越容易满足，例如，现在人们旅行的方便程度和速度是几百年前所不可想象的。另一些事情， 像怀孕生小孩，几千年来的确变得比较容易了，但还是需要大约九个月的时间，生小孩的“成本”也许更大了。我们知道许多计算机硬件的能力大致以每两年提高- -倍的速度发展*,而软件开发的流程却没有这样的提速过程，开发成本也没有下降，为什么?软件开发过程有什么特别的难题?学者们总结了下面五点: |
|
| 1.复杂性 ( Complexity ) |
软件可以说是人类创造的最复杂的系统类型。大型软件(操作系统、办公软件、搜索引擎)有超过百万行的源代码，上万个不同的文件。而软件工程师的肉眼通常一-次只能看到30- -80 行源代码(相当于显示器的- -屏)，他们的智力、记忆力和常人差不多，在过去的几十年中并没有大的提高。软件的各个模块之间有各种显性或隐性的依赖关系，随着系统的成长和模块的增多，这些关系的数量往往以几何级数的速度增长。而理解运用这些复杂性的人并没有太大的变化。 |
| 2.不可见性( Invisibility ) |
软件工程师能直接看见源代码，但是源代码不是软件本身。软件以机器码的形式高速运行，还可能在几个CPU核上同时运行，工程师是“看”不到自己的源代码如何具体地在用户的机器上被执行的。商用软件出现了错误，工程师可以看到程序在出错的一瞬间留下的一些痕迹 (错误代号、大致的目标代码位置、错误信息)，但是几乎无法完整重现到底程序出现了什么问题。当工程师回过头来看源代码时，它们还是安静地排列在屏幕上。 |
| 3.易变性 (Changeability ) |
软件看上去很容易修改，修改软件比修改硬件容易多了。人们自然地期待软件能在下面两种情况下“改变”: a)让软件做新的事情: b)让软件适应新的硬件。但是与此同时，正确地修改软件是--件很困难的事情。 |
| 4.服从性( Conformity ) |
软件不能独立存在，它总是要运行在硬件上面，它要服从系统中其他组成部分的要求，它还要服从用户的要求、行业系统的要求(例如银行利率的变化)。 |
| 5.非连续性 ( Discontinuity ) |
人们比较容易理解连续的系统:增加输人，就能看到相应输出的增加。但是许多软件系统却没有这样的特性，有时输人上很小的变化，会引起输出上极大的变化。 |
问题三、计算机科学与软件工程的区别有哪些？一级侧重点是什么
计算机科学中的理论研究部分，大多可以从形式上证明，与数学、离散数学、数理逻辑密切相关;计算机科学中与实践相关的部分，都和数据以及其他学科发生关系;软件工程则和人的行为、现实社会的需求息息相关。软件工程的研究目标(软件的开发、运营和维护)中都有“人”出现，这些“人”可以是项目需求的提供者，可以是软件的开发人员，还可以是软件的用户。这一特征与其他计算机科学的子领域明显不同。其实，在任何科学领域中,都有偏理论的子领域和偏应用的子领域(例如数学与应用数学)，当偏应用的领域得到长足发展之后，就会更多地被大家所熟知，甚至成为一一门独立的学科，这并不说明相对应的两方面有高低或优劣之分。|
| 计算机科学 |
软件工程 |
| 发现和研究长期的、客观的真理 |
短期的实际结果(具体的软件会过时) |
| 理想化的 |
对各种因素的折衷 |
| 确定性，完美，通用性 |
对不确定性和风险的管理，足够好，具体的应用 |
| 各个学科独立深入研究，做出成果 |
关注和应用各个相关学科的知识，解决问题 |
| 理论的统一 |
百花齐放的实践方法 |
| 强调原创性 |
最好的、成熟的实践方法 |
| 形式化。追求简明的公式 |
在实践中建立起来的灵感和直觉 |
| 正确性 |
可靠性 |
| 计算机理论的进展会帮助软件工程(例如对程序正确性的分析);软件工程的进展(更好的工具，更多的应用领域)会帮助计算机科学家更有效地进行实验和探索。理论方面的不足或错误，也会对实践造成深远的影响。 |
|
