单元测试中的条件编译

⑴ 软件测试中的单元测试，如果测试的单元为类，请问怎么对一个类进行测试

单元测试应该是重点对方法和函数进行测试，写好桩和驱动，通过调用和被调用，验证方法在处理不同参数时的结果。
如果单元是一个类，主要就是看类设计的合理性，是否已经囊括需要的对象的必要属性，属性的类型设计是否正确，类的方法是否能满足对类的操作，是否和其他类有冲突或重复的设计等。

⑵ 集成测试单元测试.系统测试,的联系和区别

一、区别

1、方式不同

单元测试一般由开发小组采用白盒方式来测试。

集成测试一般由开发小组采用白盒加黑盒的方式来测试。

系统测试一般由独立测试小组采用黑盒方式来测试。

2、粒度不同

单元测试的粒度最小。

系统测试的粒度最大。

集成测试界于单元测试和系统测试之间，起到“桥梁作用”。

3、内容不同

单元测试主要测试单元是否符合“设计”。

集成测试既验证“设计”，又验证“需求”。

系统测试主要测试系统是否符合“需求规格说明书”。

二、联系

单元测试是开发者编写的一小段代码，集成测试是单元测试的逻辑扩展，系统测试是将经过集成测试的软件。

⑶ c语言中，什么是条件编译

条件编译属于三种宏定义中的一种，条件指示符的最主要目的是防止头文件的重复包含和编译，例如:一个c文件包含同一个h文件多次，如果不加#ifndef宏定义，会出现变量重复定义的错误

条件编译常用的有四个预处理命令：#if、#else、#elif、#endif。
#if指令的形式为：
#if 常量表达式
代码块
#endif
#if后面的常量表达式为值，则编译它与#endif之间的代码，否则跳过这些代码。指令#endif标识一个#if块的结束。

#else被使用来标志#if的末尾和#else块的开始。这是必须的，因为任何#if仅有一个#endif与之关联。

#elif意指"else if"，它形成一个if else if嵌套语句用于多种编译选择。#elif后面跟一个常量表达式，如果表达式是真，则编译其后的代码块，不对其他#elif表达式进行检测，否则顺序测试下一块。常见的形式如下：
形式1:
#ifdef 标识符
/*程序段 1*/
#else
/*程序段 2*/
#endif
它的作用是当标识符已经由#define定义过了,则编译程序段1,否则编译程序段2，也可以使用简单形式
#ifdef 标识符
/*程序段1*/
#endif

形式2:
#ifndef 标识符
#define 标识符
/*程序段 1*/
#else
/*程序段 2*/
#endif
它的作用是当标识符没有由#define定义过,则编译程序段1,否则编译程序段2 ，也可以使用简单形式
#ifndef 标识符
#define 标识符
/*程序段 1*/
# endif
形式3:
#if 表达式
/*程序段 1*/
#else
*程序段 2*/
# endif
它的作用是 当“表达式”值为真时编译程序段1。否则则编译程序段2,也可以使用简单形式
# if 表达式
/*程序段 1*/
# endif
形式4:
#if 表达式1
/*程序段 1*/
#elif 表达式2
/*程序段 2*/
............
#elif 表达式n
/*程序段n */
#endif
它的作用是当“表达式1”值为1时编译程序段1，表达式2的值为真是编译程序段2,否则依次顺序判断到表达式n。

最后，条件编译的条件是一个常量表达式，支持逻辑与&&和或||运算。以上四种形式的条件编译预处理结构都可以嵌套使用，
标识符: 在理论上来说可以是自由命名的，但每个头文件的这个标识符都应该是唯一的。标识的命名规则一般是头文件名全大写，前后加下划线，并把文件名中的“.”也变成下划线，如：stdio.h。
#ifndef _STDIO_H_
#define _STDIO_H_
/*程序段 */
#endif

⑷ 关于c++中的assert语句

C里用法:
使用断言可以创建更稳定，品质更好且不易于出错的代码。当需要在一个值为FALSE时中断当前操作的话，可以使用断言。单元测试必须使用断言（Junit/JunitX）。
除了类型检查和单元测试外，断言还提供了一种确定各种特性是否在程序中得到维护的极好的方法。
使用断言使我们向按契约式设计更近了一步。
断言特性:
前置条件断言：代码执行之前必须具备的特性
后置条件断言：代码执行之后必须具备的特性
前后不变断言：代码执行前后不能变化的特性
使用方式:
断言可以有两种形式
1.assert Expression1
2.assert Expression1:Expression2
其中Expression1应该总是一个布尔值，Expression2是断言失败时输出的失败消息的字符串。如果Expression1为假，则抛出一个 AssertionError，这是一个错误，而不是一个异常，也就是说是一个不可控制异常（unchecked Exception),AssertionError由于是错误，所以可以不捕获，但不推荐这样做，因为那样会使你的系统进入不稳定状态。
java断言:
断言在默认情况下是关闭的，要在编译时启用断言，需要使用source1.4标记 既javac source1.4 Test.java ,在运行时启用断言需要使用 -ea参数 。要在系统类中启用和禁用断言可以使用 -ea和 -dsa参数。

⑸ 什么是单元测试

单元测试（模块测试）是开发者编写的一小段代码，用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言，一个单元测试是用于判断某个特定条件（或者场景）下某个特定函数的行为。例如，你可能把一个很大的值放入一个有序list 中去，然后确认该值出现在list 的尾部。或者，你可能会从字符串中删除匹配某种模式的字符，然后确认字符串确实不再包含这些字符了。 单元测试是由程序员自己来完成，最终受益的也是程序员自己。可以这么说，程序员有责任编写功能代码，同时也就有责任为自己的代码编写单元测试。执行单元测试，就是为了证明这段代码的行为和我们期望的一致。 工厂在组装一台电视机之前，会对每个元件都进行测试，这，就是单元测试。 其实我们每天都在做单元测试。你写了一个函数，除了极简单的外，总是要执行一下，看看功能是否正常，有时还要想办法输出些数据，如弹出信息窗口什么的，这，也是单元测试，老纳把这种单元测试称为临时单元测试。只进行了临时单元测试的软件，针对代码的测试很不完整，代码覆盖率要超过70%都很困难，未覆盖的代码可能遗留大量的细小的错误，这些错误还会互相影响，当BUG暴露出来的时候难于调试，大幅度提高后期测试和维护成本，也降低了开发商的竞争力。可以说，进行充分的单元测试，是提高软件质量，降低开发成本的必由之路。 对于程序员来说，如果养成了对自己写的代码进行单元测试的习惯，不但可以写出高质量的代码，而且还能提高编程水平。 要进行充分的单元测试，应专门编写测试代码，并与产品代码隔离。老纳认为，比较简单的办法是为产品工程建立对应的测试工程，为每个类建立对应的测试类，为每个函数（很简单的除外）建立测试函数。首先就几个概念谈谈老纳的看法。 一般认为，在结构化程序时代，单元测试所说的单元是指函数，在当今的面向对象时代，单元测试所说的单元是指类。以老纳的实践来看，以类作为测试单位，复杂度高，可操作性较差，因此仍然主张以函数作为单元测试的测试单位，但可以用一个测试类来组织某个类的所有测试函数。单元测试不应过分强调面向对象，因为局部代码依然是结构化的。单元测试的工作量较大，简单实用高效才是硬道理。 有一种看法是，只测试类的接口(公有函数)，不测试其他函数，从面向对象角度来看，确实有其道理，但是，测试的目的是找错并最终排错，因此，只要是包含错误的可能性较大的函数都要测试，跟函数是否私有没有关系。对于C++来说，可以用一种简单的方法区隔需测试的函数：简单的函数如数据读写函数的实现在头文件中编写(inline函数)，所有在源文件编写实现的函数都要进行测试(构造函数和析构函数除外)。 为什么要使用单元测试 我们编写代码时，一定会反复调试保证它能够编译通过。如果是编译没有通过的代码，没有任何人会愿意交付给自己的老板。但代码通过编译，只是说明了它的语法正确；我们却无法保证它的语义也一定正确，没有任何人可以轻易承诺这段代码的行为一定是正确的。 幸运，单元测试会为我们的承诺做保证。编写单元测试就是用来验证这段代码的行为是否与我们期望的一致。有了单元测试，我们可以自信的交付自己的代码，而没有任何的后顾之忧。 什么时候测试？单元测试越早越好，早到什么程度？XP开发理论讲究TDD，即测试驱动开发，先编写测试代码，再进行开发。在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从老纳的经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。所谓先编写产品函数的框架，是指先编写函数空的实现，有返回值的随便返回一个值，编译通过后再编写测试代码，这时，函数名、参数表、返回类型都应该确定下来了，所编写的测试代码以后需修改的可能性比较小。 由谁测试？单元测试与其他测试不同，单元测试可看作是编码工作的一部分，应该由程序员完成，也就是说，经过了单元测试的代码才是已完成的代码，提交产品代码时也要同时提交测试代码。测试部门可以作一定程度的审核。 关于桩代码，老纳认为，单元测试应避免编写桩代码。桩代码就是用来代替某些代码的代码，例如，产品函数或测试函数调用了一个未编写的函数，可以编写桩函数来代替该被调用的函数，桩代码也用于实现测试隔离。采用由底向上的方式进行开发，底层的代码先开发并先测试，可以避免编写桩代码，这样做的好处有：减少了工作量；测试上层函数时，也是对下层函数的间接测试；当下层函数修改时，通过回归测试可以确认修改是否导致上层函数产生错误。 在一种传统的结构化编程语言中，比如C，要进行测试的单元一般是函数或子过程。在象C++这样的面向对象的语言中， 要进行测试的基本单元是类。对Ada语言来说，开发人员可以选择是在独立的过程和函数，还是在Ada包的级别上进行单元测试。单元测试的原则同样被扩展到第四代语言(4GL)的开发中，在这里基本单元被典型地划分为一个菜单或显示界面。 单元测试不仅仅是作为无错编码一种辅助手段在一次性的开发过程中使用，单元测试必须是可重复的，无论是在软件修改，或是移植到新的运行环境的过程中。因此，所有的测试都必须在整个软件系统的生命周期中进行维护。 经常与单元测试联系起来的另外一些开发活动包括代码走读(Code review)，静态分析(Static analysis)和动态分析(Dynamic analysis)。静态分析就是对软件的源代码进行研读，查找错误或收集一些度量数据，并不需要对代码进行编译和执行。动态分析就是通过观察软件运行时的动作，来提供执行跟踪，时间分析，以及测试覆盖度方面的信息。 一些流行的误解 在明确了什么是单元测试以后，我们可以进行"反调论证"了。在下面的章节里，我们列出了一些反对单元测试的普遍的论点。然后用充分的理由来证明这些论点是不足取的。 它浪费了太多的时间
一旦编码完成，开发人员总是会迫切希望进行软件的集成工作，这样他们就能够看到实际的系统开始启动工作了。 这在外表上看来是一项明显的进步，而象单元测试这样的活动也许会被看作是通往这个阶段点的道路上的障碍， 推迟了对整个系统进行联调这种真正有意思的工作启动的时间。 在这种开发步骤中，真实意义上的进步被外表上的进步取代了。系统能够正常工作的可能性是很小的，更多的情况是充满了各式各样的Bug。在实践中，这样一种开发步骤常常会导致这样的结果：软件甚至无法运行。更进一步的结果是大量的时间将被花费在跟踪那些包含在独立单元里的简单的Bug上面，在个别情况下，这些Bug也许是琐碎和微不足道的，但是总的来说，他们会导致在软件集成为一个系统时增加额外的工期， 而且当这个系统投入使用时也无法确保它能够可靠运行。 在实践工作中，进行了完整计划的单元测试和编写实际的代码所花费的精力大致上是相同的。一旦完成了这些单元测试工作，很多Bug将被纠正，在确信他们手头拥有稳定可靠的部件的情况下，开发人员能够进行更高效的系统集成工作。这才是真实意义上的进步，所以说完整计划下的单元测试是对时间的更高效的利用。而调试人员的不受控和散漫的工作方式只会花费更多的时间而取得很少的好处。 使用AdaTEST和Cantata这样的支持工具可以使单元测试更加简单和有效。但这不是必须的，单元测试即使是在没有工具支持的情况下也是一项非常有意义的活动。 它仅仅是证明这些代码做了什么
这是那些没有首先为每个单元编写一个详细的规格说明而直接跳到编码阶段的开发人员提出的一条普遍的抱怨， 当编码完成以后并且面临代码测试任务的时候，他们就阅读这些代码并找出它实际上做了什么，把他们的测试工作基于已经写好的代码的基础上。当然，他们无法证明任何事情。所有的这些测试工作能够表明的事情就是编译器工作正常。是的，他们也许能够抓住(希望能够)罕见的编译器Bug，但是他们能够做的仅仅是这些。 如果他们首先写好一个详细的规格说明，测试能够以规格说明为基础。代码就能够针对它的规格说明，而不是针对自身进行测试。这样的测试仍然能够抓住编译器的Bug，同时也能找到更多的编码错误，甚至是一些规格说明中的错误。好的规格说明可以使测试的质量更高，所以最后的结论是高质量的测试需要高质量的规格说明。 在实践中会出现这样的情况： 一个开发人员要面对测试一个单元时只给出单元的代码而没有规格说明这样吃力不讨好的任务。你怎样做才会有更多的收获，而不仅仅是发现编译器的Bug？第一步是理解这个单元原本要做什么， --- 不是它实际上做了什么。 比较有效的方法是倒推出一个概要的规格说明。这个过程的主要输入条件是要阅读那些程序代码和注释， 主要针对这个单元， 及调用它和被它调用的相关代码。画出流程图是非常有帮助的，你可以用手工或使用某种工具。 可以组织对这个概要规格说明的走读(Review)，以确保对这个单元的说明没有基本的错误， 有了这种最小程度的代码深层说明，就可以用它来设计单元测试了。 我是个很棒的程序员， 我是不是可以不进行单元测试？
在每个开发组织中都至少有一个这样的开发人员，他非常擅长于编程，他们开发的软件总是在第一时间就可以正常运行，因此不需要进行测试。你是否经常听到这样的借口？ 在真实世界里，每个人都会犯错误。即使某个开发人员可以抱着这种态度在很少的一些简单的程序中应付过去。 但真正的软件系统是非常复杂的。真正的软件系统不可以寄希望于没有进行广泛的测试和Bug修改过程就可以正常工作。 编码不是一个可以一次性通过的过程。在真实世界中，软件产品必须进行维护以对操作需求的改变作出反应， 并且要对最初的开发工作遗留下来的Bug进行修改。你希望依靠那些原始作者进行修改吗？ 这些制造出这些未经测试的原始代码的资深专家们还会继续在其他地方制造这样的代码。在开发人员做出修改后进行可重复的单元测试可以避免产生那些令人不快的负作用。

⑹ 单元测试、集成测试、系统测试的顺序可否调换，为什么

不可以，软件的开发也是从小的模块开始，不可能没有模块就开始集成，后来才打包成一个软件，形成一个系统。
单元测试是测试各个小的模块，通过对他们的测试，才能找出基本的bug，然后为各个模块搭建接口，也就是把模块组装起来，之后进行集成测试，看各个模块的接口是否正常稳定，打包成软件后，先做出一个demo版本，由开发和测试一起进行系统测试。