Roboby's Home

项目前期需求收集过程的效果好坏，会对软件产品的最终质量产生直接的影响。如何收集好需求，本文作者给出了一条行之有效的实际操作途径。 什么是需求收集？ 需求收集，是确定和理解不同类别用户的需要和限制的过程，是需要高度协作的活动，是在问题及其最终解决方案之间架设桥梁的第一步，因此其重要性不言而喻。据调查显示50%以上产品在市场上失败的原因，是由于忽视了用户需求。 需求收集在需求开发活动中的示意图如图1： 如图1 需求收集为什么会困难？ 困扰项目组需求收集活动的原因可能如下： v 需求收集人员往往只关注用户反映的表面问题，而不能主动深入挖掘用户的真实需求； v 需求收集人员考虑的问题时习惯干“以产品为中心”，而不是“以客户为中心”； v 用户往往不清楚自己的真实需求是什么，或者不知道如何准确地描述出自己的需求—“我心里很清楚，但就是说不出来”； v 没有从所有可能的渠道去收集需求，需求信息来源不完整； v 收集的需求没有规范记录下来，造成原始信息丢失或失真，且无法回溯；等等。 怎么做好需求收集活动？ 首先，需要建立需求收集机制。其次，使用统一的需求收集系统。最后，在需求收集时，采取一定的技术和方法。 建立需求收集机制 (1). 明确每个需求收集活动参与者的岗位职责 根据项目组可能的需求来源（需求来源可能包括：市场调研，竞争对手信息分析，标准和协议等等，视项目组的实际情况而定），指定每个需求来源的收集负责人。同时，对通过各个渠道收集的需求信息，指定专门的接口人进行汇总和审核。 (2). 建立需求预处理流程 对收集到的需求，除了指定专门的接口人进行汇总和审核以外，还要建立相应的预处理流程，在对需求进行预处理时，相关的讨论，决策可以通过“需求CCB会议”完成（需求CCB是指：专门用于需求讨论和决策的Change Control Board）。 一个对收集到的需求信息的预处理流程例子如图2： 如图2 项目组可以参考上例，结合自身实际情况进行适当剪裁，建立适合自己的预处理流程。 (3). 周期性的重复需求收集活动 当产品处于研发过程中，或已经交付给用户使用后，项目组还需要定期从各个来源重新去收集和审视一下产品的所有相关需求，这样就可以及时获知市场和用户对产品的反应，为下一个步工作提供输入和依据。项目组可以依据自身产品的特定，指定周期性的需求收集策略，选择相应的时机。 使用统一的需求收集系统 很多项目组都采取表格的方式记录收集到的需求信息，而不是通过电子流程的方式提交，这样会到来一些问题，如：收集到的需求信息被延迟处理，项目信息无法跟踪，回溯，等等。因此，项目组有必要使用统一的需求收集系统，作为唯一，明确的入口，对需求信息进行填报和跟踪。 企业可以选择自己开发电子的需求收集系统，也可以选择购买市场上现有的产品，如：Telelogic公司的Focal Point等。如果使用自己开发的需求收集系统，就可以让系统流程和企业的业务流程相结合，而且日后维护和扩展也比较方便。 一个需求收集的二维流程图实例如图3： 如图3 在实际工作中，需求收集系统还可以和需求管理系统，变更控制系统等通过一定的接口实现集成，共同构成企业的综合需求管理平台，从而提供“完善的需求管理解决方案”。一个公司级综合需求管理平台搭建的实例如图4： 如图4 采取一定的需求收集技术和方法 在需求收集时，还应采取一定的技术和方法。一些常用的需求收集技术和方法包括：客户访谈，客户交流，市场调研，技术支持，高层拜访，竞争对手分析，查阅媒体信息，需求专题分析讨论会等等。 下面选取几种技术和方法，通过一些案例分析，进行更为详细地阐述。 (1). 客户访谈 案例分析1：某次客户访谈 ü 访谈时间：选择45-60分钟比较合适。 ü 访谈地点：选择比较宽松的非工作环境进行。 ü 访谈问卷：在访谈之前要事先设计访谈问卷，要注意的是问卷只是提供一个思路。 ü 填表方式：不要采取让客户直接填表的方式。 ü 录音：前提不要让客户发现或是事前征求客户的同意。 ü 访谈结束：再次确认，每次访谈后要优化访谈的提纲以备下次使用。 (2). 客户交流 案例分析2： 交流前的沟通：充分与客户沟通交流，重点可以以下角度考虑问题： ü 本次客户关系什么内容？ 参与人是谁？ 主要决策者有哪些倾向性的观点？ ü 竞争对手可能方案的卖点？主推什么？ ü 我们要住推什么？怎么避免我们的弱点？ ü 客户预计会提那些问题？我们应该怎么回答？ ü 交流会的讲解重点：在交流会上，可以选择以下讲解重点： ü 客户面临的问题是什么？ ü 针对客户面临的问题，我们的解决方案是什么？ ü 我们的总体方案如何？ ü 今天交流的内容在公司总体方向中的位置？ 此外，在交流时还可以自己设计一些问题并加以回答。特别需要注意的是，在交流的时候不要攻击竞争对手，但是可以多讲一些自己的成功案例和优点。 交流后的工作：交流之后，还需要完成以下工作： ü 分析记录和答疑； ü 提出项目的应对策略建议； ü 对交流会上遗留的问题进行跟踪直至关闭； (3). 需求专题分析讨论会 需求专题分析讨论会的目的，是在较短的时间内鼓励与会者在需求上达成共识，尽快取得统一意见。需求专题分析讨论会通常邀请客户代表参加 案例分析3 会前准备 ü 确定所有相关的干系人，不要有遗落； ü 事先做好会议后勤保障； ü 事先准备会议相关材料，需求文档初稿，调查问卷，相关清单； ü 找合适的主持人：善于控制时间，维持会议“规则”，制定会议目标和议程，能够调动所有人员积极参与。 会议举行： ü 制定会议纪律并宣布； ü 支持人要把握好会场气氛，并及时化解矛盾； ü 记录人要做好会议记录 ü 参与人员使用投票方式确定需求优先级； ü 发言人的发言时间不得超过一定长度，不能打断； 会后工作 ü 把会上收集到的意见归类； ü 记录讨论后的需求； ü 确定下一步工作； 结束语 需求收集在客户问题及最终解决反感之间起着架设桥梁的作用，从某种程度上来讲，需求收集工作的质量决定了产品的成败，因此我们必须加强对其的重视。为了做好这项工作我们需要建立日常的需求收集工作机制，并采用统一的需求收集系统作为信息入口；同时，由于需求收集是统一的讲求技术和方法的活动，选择和的技术和方法有助于获取完整且有效的需求。

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。 软件需求分析的任务是：深入描述软件的功能和性能，确定软件设计的约束和软件同其他系统元素的接口细节，定义软件的其他有效性需求，借助于当前系统的逻辑模型导出目标系统逻辑模型，解决目标系统“做什么”的问题。 需求分析可分为需求提出、需求描述及需求评审三个阶段。 需求提出主要集中于描述系统目的。需求提出和分析仅仅集中在使用者对系统的观点上。用户、开发人员和用户确定一个问题领域，并定义一个描述该问题的系统。这样的定义称作系统规格说明，并且它在用户和开发人员之间充当合同。 在问题分析阶段分析人员的主要任务是：对用户的需求进行鉴别、综合和建模，清除用户需求的模糊性、歧义性和不一致性，分析系统的数据要求，为原始问题及目标软件建立逻辑模型。分析人员要将对原始问题的理解与软件开发经验结合起来，以便发现哪些要求是由于用户的片面性或短期行为所导致的不合理要求，哪些是用户尚未提出但具有真正价值的潜在需求。 在需求评审阶段，分析人员要在用户和软件设计人员的配合下对自己生成的需求规格说明和初步的用户手册进行复核，以确保软件需求的完整、准确、清晰、具体，并使用户和软件设计人员对需求规格说明和初步的用户手册的理解达成一致。一旦发现遗漏或模糊点，必须尽快更正，再行检查。 软件需求说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解， 使之成为整个开发工作的基础。编制软件需求说明书的内容要求如下： 　　1　引言 1.1编写目的 说明编写这份软件需求说明书的目的，指出预期的读者。 1.2背景 说明： a．待开发的软件系统的名称； b．本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络； C．该软件系统同其他系统或其他机构的基本的相互来往关系。 1.3定义 列出本文件中用到的专门术语的定义和外文首字母组词的原词组。 1.4参考资料 列出用得着的参考资料，如： a．本项目的经核准的计划任务书或合同、上级机关的批文； b．属于本项目的其他已发表的文件； c．本文件中各处引用的文件、资料、包括所要用到的软件开发标准。 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。 　　2　任务概述 2.1目标 叙述该项软件开发的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料。解释被开发软件与其他有关软件之间的关系。如果本软件产品是一项独立的软件，而且全部内容自含，则说明这一点。如果所定义的产品是一个更大的系统的一个组成部分，则应说明本产品与该系统中其他各组成部分之间的关系，为此可使用一张方框图来说明该系统的组成和本产品同其他各部分的联系和接口。| 2.2用户的特点 列出本软件的最终用户的特点，充分说明操作人员、维护人员的教育水平和技术专长，以及本软件的预期使甩频度。这些是软件设计工作的重要约束 2.3假定和约束 列出进行本软件开发工作的假定和约束，例如经费限制、开发期限等。 　　3　需求规定 3.1对功能的规定 用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述对软件所提出的功能要求，说明输入什么量、经怎样的处理、得到什么输出，说明软件应支持的终端数和应支持的并行操作的用户数。 3.2对性能的规定 3.2.1精度 说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 3.2.2时间特性要求 说明对于该软件的时间特性要求，如对： a．响应时间； b．更新处理时间； c．数据的转换和传送时间； d．解题时间； 等的要求。 3.2.3灵活性 说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如： a．操作方式上的变化； b．运行环境的变化； c．同其他软件的接口的变化； d．精度和有效时限的变化； e．计划的变化或改进。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。 3.3输人输出要求 解释各输入输出数据类型，并逐项说明其媒体、格式、数值范围、精度等。对软件的数据输出及必须标明的控制输出量进行解释并举例，包括对硬拷贝报告（正常结果输出、状态输出及异常输出）以及图形或显示报告的描述。 3.4数据管理能力要求 说明需要管理的文卷和记录的个数、表和文卷的大小规模，要按可预见的增长对数据及其分量的存储要求作出估算。 3.5故障处理要求 列出可能的软件、硬件故障以及对各项性能而言所产生的后果和对故障处理的要求。 3.6其他专门要求 如用户单位对安全保密的要求，对使用方便的要求，对可维护性、可补充性、易读性、可靠性、运行环境可转换性的特殊要求等。 　　4　运行环境规定 4.1设备 列出运行该软件所需要的硬设备。说明其中的新型设备及其专门功能，包括： a．处理器型号及内存容量； b．外存容量、联机或脱机、媒体及其存储格式，设备的型号及数量； c．输入及输出设备的型号和数量，联机或脱机； d．数据通信设备的型号和数量； e．功能键及其他专用硬件 4.2支持软件 列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。 4.3 接口 说明该软件同其他软件之间的接口、数据通信协议等。 4.4控制 说明控制该软件的运行的方法和控制信号，并说明这些控制信号的来源。  

作者：iFire 先谈谈我的想法。 一、要讨论怎么写需求文档，首先就的搞清楚需求的构成，我是这么分的： 1、功能需求； 2、非功能需求或技术需求； 我一般把功能需求划分为几个部分： a、业务过程； b、业务规则； c、业务数据； 非功能需求（技术需求）我就不多说了，大致就是可用性，可靠性，性能，可支持性等等。 二、弄清楚需求的构成后，我们就得考虑以什么样的文档结构来描述这些需求了，UP的做法是这样的： 1、用例规格说明描述业务过程； 2、业务规则文档描述业务规则； 3、术语表描述业务数据； 4、补充规格说明描述非功能需求（技术需求）； UP的做法还是很有道理的。这体现了两个原则： 1、分离关注点（每个文档描述相对独立的领域）； 2、减少重复（很多用例都会引用相同的业务规则及业务数据）； 这样便能够尽可能的使文档结构清晰，易阅读，易理解。也便于跟踪和维护。 但另一方面由于将不同的领域分离到不同文件的做法也使得可阅读性有所降低。比如用例规格说明中的业务过程描述时常需要引用业务规则文档中的业务规则及术语表中的业务数据。由于不是很方便在各个文档之间导航，你可能需要打开多个文档进行交叉阅读。这是比较麻烦的，特别是对于用户来说。 而且UP中每个用例都单独作为一个文件存在，这可能是为了便于跟踪及管理的缘故吧。但正如上所述，文件多了看着就觉得不爽了。我觉得完全可以将用例合并到一个文档中。或者几个相对独立的文档中（比如根据子系统划分）。 至于交叉阅读，导航困难的问题是否有什么别的方法解决呢？html文档似乎不错。不过写起来似乎没word方便啊。 三、总结： 无论怎么写需求文档，最终的目的无外乎易阅读，易理解，易沟通，易确认，易跟踪，易测试，易验收。我想我们都应该以这个为目标来进行思考。

作者: Job Vranish  来源: 伯乐在线  发布时间: 2012-03-21 英文原文：How to write good requirements 编写需求文档，在嵌入式开发领域是非常普遍的。需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。 从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：

• 工程师可以根据系统所说进行实现
• 测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。
• 最终产生的成果满足终端用户的要求。

• 黑盒测试

书写优质的需求文档： 最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。 列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤： 1. 定义系统的边界。这也是黑盒系统所必要的。 2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。 3. 用最易懂的方式描述系统的预期行为 4. 除了输入和输出之外，你的需求是不是还涉及了系统的其他部分？如果是，那么你的需求就设计过度了。重构需求，让它变得精简。 5. 你的需求是不是过于模棱两可？加入更多的限定规范。注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要（也不应该）把系统的行为限制得过头。 6. 你的需求是否可测试？（这里指的是黑盒测试）如果不是，你最好返回到第 4 步。如果这种返工发生很多次，那就说明你的黑盒无法正确描述系统，或者你的测试工具不够优秀。无论是哪种情况，不可测试的需求文档几乎就是一文不值的。 7. 你的需求文档通俗易懂么？如果你的需求文档非常难以读懂，那就说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第 3 步。 8. 你是不是真的做到了第 4 步？你确认么？再检查一下。 例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个 LED 闪烁。 显然，我们已经完成了步骤 2 和步骤 3 了! · 输入：从弯曲传感器读取数据。 · 输出：LED。 但是我们跳过了步骤1： · 在这个例子里，我们将把黑盒画到设备的微处理器上。 让我们继续往下进行, 第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界？ · 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量 ADC 脚的电压而已。 · LED 仅由数字输出脚控制。 下面，让我们来修正这个问题： 第 0 版本的需求： 1. 该设备应当根据 ADC 脚的不同频率的电压，来切换数字输出端的状态。 第五步: 需求写模棱两可么? 恩，我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧: 版本0.1 1. 输出端应当由一个自由活动的定时器进行控制 2. 自由运行定时器的频率最高不得高于每秒 10 次，不得低于每秒 1 次. 3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化，并与 ADC 端的输入电压成正比. 4. ADC 端的输入电压应当每 100 毫秒读取一次 5. 当 ADC 端的输入电压端被读入时，控制自由运行定时器周期时间的注册值也应当被更新. 6. ADC 输入端的电压有效范围应当被控制在 0 到 1 伏之间. 第六步: 你的需求是可测试的么? · 首先，自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试，它既不是输入也不是输出，而且跟这两者也没有什么联系。 让我们用“数字输出端变化的频率应控制在每秒 10 次和每秒 1 次之间”来代替自由运行定时器的测试标准。 · 对于上述的第四条需求，可能需要一些小修改才能作为测试标准。让我们用“ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次”来加以描述，这样的描述能让我们预期的测试行为显得更加通俗易懂。 · 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在 0 到 1 伏之间呢？ 总不能给个 2 伏的电压，然后看看元器件有没有被烧毁吧？ 那么，说“检验系统在 ADC 端输入电压为 1 到 2 伏之间的时候，工作是否正常”，这样就检验就容易多了。需求描述应当是“正面”的，应当描述设备“应该”的行为，而不是设备“不应该”的行为。否则的话，测试将会无法进行。 版本0.2 1. 数字输出端的切换频率应当控制在每秒 10 次到每秒 1 次之间 2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化，并与 ADC 端的输入电压成正比 3. ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次 4. 检验当 ADC 端的输入电压范围在 0 到 1 伏之间的时候，系统工作是否正常 第七步：你的需求是否通俗易懂？ 相比于我们原来的描述：“根据弯曲传感器的输出不同频率来控制 LED 闪烁”，我们上面的那些需求描述显得难以阅读和理解。 我发现，让需求文档变得通俗易懂，最简单办法莫过于，把过于细节的东西抽取出来，然后以条目的形式单独定义。 版本1 1. 弯曲传感器应当保证至少在 100 毫秒内读取一次数据（放到注释单独列出） 2. 切换 LED 的状态，使其与弯曲传感器的读数保持一致 3. 当弯曲传感器的读数为 1 伏特时，LED 状态切换的次数应当保持在平均一秒十次；当传感器的读数为 0 伏特时，LED 的切换次数应保持在一秒 1 次。 定义： · 弯曲传感器：输入电压位于 ADC 的X端。安全电压范围为 0 到 1 伏特（放到注释单独列出） · LED 状态：数字状态由Y端输出 这样就好多了（尽管还不完美）。这些需求通俗易懂，不涉及到系统内部实现，且易于测试。对于系统行为的限定也仅仅限于需要做什么，点到为止。（例如，对弯曲传感器的采样频率，在实现上也可以更高，只要不产生非预期行为，一切都可以）。 编写需求就仿佛是在大脑中构建软件的过程。因此要重于实作。 编译：伯乐在线 – 黄小非

   VTIME指定了等待的时间,VMIN指定了读取字符的最小数量。    它们不同组合地取值会得到不同的结果，分别如下：    1．当VTIME>0，VMIN>0时。read调用将保持阻塞直到读取到第一个字符，读到了第一个字符之后开始计时，此后若时间到了VTIME或者时间未到但已读够了VMIN个字符则会返回；若在时间未到之前又读到了一个字符(但此时读到的总数仍不够VMIN)则计时重新开始。    2. 当VTIME>0，VMIN=0时。read调用读到数据则立即返回，否则将为每个字符最多等待VTIME时间。    3. 当VTIME=0，VMIN>0时。read调用一直阻塞，直到读到VMIN个字符后立即返回。    4. 若在open或fcntl设置了O_NDELALY或O_NONBLOCK标志，read调用不会阻塞而是立即返回，那么VTIME和VMIN就没有意义，效果等同于与把VTIME和VMIN都设为了0。 来自：http://blog.sina.com.cn/s/blog_4d32d0b40100j7d2.html

Vmware的主窗口， 点击“Vmware -> Settings -> Hardware -> Add ” ， 选择Serial port， 继续选择”use named pipe” 这样就OK 。 测试： /*   同时在两台机的Linux下输入 stty ispeed 115200 ospeed 115200 -F /dev/ttyS0 配置串口的波特率，否则很有可能连不通～～(这一段我测试的时候好像没用到，系统是rhel5.4) */ 测试两台机的串口是否连通： 在A上输入 cat /dev/ttyS0 在B上输入 echo hello > /dev/ttyS0 如果在A的终端上可以弹出hello的消息的话，证明B→A连通了。将A、B角色互换再试一次，若都成功的话，恭喜你，虚拟串口线的配置算是完成了 本文来自：http://www.diybl.com/course/6_system/linux/Linuxjs/20101230/548731.html

之前找了好多教程啊啥的都配置不成功，用了一年多iPhone，始终没能接收和发送彩信。 今天再次找了篇文章，按照所说的参数配置完成，果然收到彩信了，既郁闷又兴奋。 下面再说说iPhone3GS的配置过程。 第一、从设置->通用里进入“网络”   打开“蜂窝数据”，进入“蜂窝数据网络”：   “蜂窝数据”中的APN一定要填cmnet，其他空着：   “彩信”中的“APN”一定要写“cmwap”、“MMSC”为“http://mmsc.monternet.com”，记得必须加“http://”，“彩信代理”写“10.0.0.72”，没必要加80端口号！“最大的彩信大小”设置成50000足够了。其他不用管。 第二、返回到“设置”，找到“短信”栏   进入后如下设置即可： 记得设置完后必须重启，我尝试进入飞行模式然后重新取消飞行默认来重置网络，似乎不起作用。  

来源：Linux社区  作者：Linux编辑 在Linux中可以动态加载库，其使用方法如下： 1. 先生成一个动态库libtest.so

/* test.c */
#include <stdio.h>
#include <stdio.h>
void test1(int no)
{
printf("*****************************************\n");
printf("This is test1, the number is %d.\n", no);
printf("*****************************************\n");
}
void test2(char *str)
{
printf("=========================================\n");
printf("This is test2, the string is %s.\n", str);
printf("=========================================\n");
}

编译库： gcc -fPIC -shared -o libtest.so test.c 这样就可以生成libtest.so动态库。 在这个库里，定义个两个函数test1，test2，下面将在程序中加载libtest.so，然后调用test1，test2。 2. 动态加载libtest.so

/* main.c */
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <dlfcn.h> /* 必须加这个头文件 */
#include <assert.h>
int main()
{
void *handler = dlopen("./libtest.so", RTLD_NOW);
assert(handler != NULL);
void (*test1)(int) = dlsym(handler, "test1");
assert(test1 != NULL);
void (*test2)(char *) = dlsym(handler, "test2");
assert(test2 != NULL);
(*test1)(10);
(*test2)("hello");
dlclose(handler);
return 0;
}
/* end */

在这个程序中，dlopen函数用来打开一个动态库，其返回一个void *的指针，如果失败，返回NULL。 dlsym返回一个动态库中的一个函数指针，如果失败，返回NULL。 dlclose关闭指向动态库的指针。 编译的时候需要加上 -ldl gcc -o main main.c -ldl(编译时要使用共享库dl 其中有dlopen dlsynm dlerror dlclose 函数) 运行main，将会看到调用test1，和test2的结果