优秀是一种习惯,生命是一个过程,不求进步很大,只求每天进步一点点,无为之道!

发布新日志

  • BUG的严重级别分类

    2007-12-19 13:18:10

    BUG的严重级别分类

    Severity

    This field describes the impact of a bug.

    Blocker : Blocks development and/or testing work

    Critical : crashes, loss of data, severe memory leak

    Major : major loss of function

    Minor : minor loss of function, or other problem where easy workaround is present

    Trivial : cosmetic problem like misspelled words or misaligned text

    Enhancement : Request for enhancement

     

    Difference between priority and severity?

    "Priority" is associated with scheduling, and "severity" is associated with standards. "Piority" means something is afforded or deserves prior attention; a precedence established by order of importance (or urgency). "Severity" is the state or quality of being severe; severe implies adherence to rigorous standards or high principles and often suggests harshness; severe is marked by or requires strict adherence to rigorous standards or high principles, e.g. a severe code of behavīor. The words priority and severity do come up in bug tracking. A variety of commercial, problem-tracking/management software tools are available. These tools, with the detailed input of software test engineers, give the team complete information so developers can understand the bug, get an idea of its 'severity', reproduce it and fix it. The fixes are based on project 'priorities' and 'severity' of bugs. The 'severity' of a problem is defined in accordance to the customer's risk assessment and recorded in their selected tracking tool. A buggy software can 'severely' affect schedules, which, in turn can lead to a reassessment and renegotiation of 'priorities'


     
     
    另一个关于“严重级别”和“优先级”的回帖
    In layman terms, we can say Severity means how much the bug is impacting the system.
    Priority means how quickly it should be resolved. It doesn't mean always that high severity bug is always high priority.
    Let's say an example where your report application crashes if you will take print out of the same during third try without closing the application.
    In this case your bug is of critical severity but the priority to resolve it is low. As in real scenario this will happen rarely.
    Take another example, where in company web site. Logo of the company is not proper but your application is working fine. In that scenario it is low severity bug but priority is highest.
     
    BUG的严重级别的分类被分的很详细,Blocker是最严重的情况,包括阻碍测试的执行、大部分测试用例无法执行,这个时候可以直接把版本打回去。Critical是灾难性的BUG,必须立刻通知告知开发人员进行修改,但对其他测试用例的执行影响不大。Major是执行有效测试用例时发现的比较严重的BUG。Minor是执行无效测试用例时发现的比较严重的BUG。Trivial是易修改功能影响不大的BUG,Enhancement是对某项功能点表象的建议修改,可改可不改,或者有新的功能建议,严重级别最低。
    严重级别和优先级的区别
    大部分情况下严重级别高的应该优先解决,但也会根据版本的发布情况将严重级别高的设置为优先级别低的,也有可能非常严重但很容易修改也可以设置优先级别低的。其他情况我还没想到。
  • 软件测试面试题整理

    2007-12-13 20:53:10

     

     软件测试面试题整理

    面试题目:

    01. 为什么要在一个团队中开展软件测试工作

    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。

    02. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    我曾经做过web测试,后台测试,客户端软件,其中包括功能测试性能测试,用户体验测试。最擅长的是功能测试

    03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)

    测试类型有:功能测试,性能测试,界面测试。

    功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。 

    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

    界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

    区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试

    05.  请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。

    白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。

      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:

    1、是否有不正确或遗漏的功能?

    2、在接口上,输入是否能正确的接受?能否输出正确的结果?

    3、是否有数据结构错误或外部信息(例如数据文件)访问错误?

    4、性能上是否能够满足要求?

    5、是否有初始化或终止性错误?

      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:

    1、对程序模块的所有独立的执行路径至少测试一遍。

    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。

    3、在循环的边界和运行的界限内执行循环体。

    4、测试内部数据结构的有效性,等等。

    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。

         单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。

    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。

    系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)

          系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。

    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

    06. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

    软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)

    07. 您认为做好测试计划工作的关键是什么?

    1. 明确测试的目标,增强测试计划的实用性

    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

    2.坚持“5W”规则,明确内容与过程

    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

    3.采用评审和更新机制,保证测试计划满足实际需求

    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。

    4. 分别创建测试计划与测试详细规格、测试用例

    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。 

    08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

    1.等价类划分

    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

    2.边界值分析法

      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    3.错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    4.因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 

    08.您认为做好测试用例设计工作的关键是什么?

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题

    09. 请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。

    就说最近的这次网站功能的测试吧

    首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。

    第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。

    第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat,所以只要有tomcat即可

    第四步:执行测试

    11. 您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。

    是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。

    性能测试类型包括负载测试,强度测试,容量测试等

         负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。

         强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。

         容量测试:确定系统可处理同时在线的最大用户数  

    在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),

    Web服务器指标指标:

    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数; 

    * Successful Rounds:成功的请求; 

    * Failed Rounds :失败的请求; 

    * Successful Hits :成功的点击次数; 

    * Failed Hits :失败的点击次数; 

    * Hits Per Second :每秒点击次数; 

    * Successful Hits Per Second :每秒成功的点击次数; 

    * Failed Hits Per Second :每秒失败的点击次数; 

    * Attempted Connections :尝试链接数;

    13. 您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

    17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

    18. 在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    20. 您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。

    23. 您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?

    27. 在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?

    31. 在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)

    33.    你对测试最大的兴趣在哪里?为什么?

    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。

    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。

    不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。

    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。

    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。

    34. 你的测试职业发展是什么?

    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。

    35. 你自认为测试的优势在哪里?

    优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。

    36. 你以前工作时的测试流程是什么?

    公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。

    37. 当开发人员说不38. 是BUG时,39. 你如何应付?

    开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。

    23.你为什么想离开目前的职务?

    因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。

      24:你对我们公司了解有多少?

      25:你找工作时,最重要的考虑因素为何?

    工作的性质和内容是否能让我发挥所长,并不断成长。

    26:为什么我们应该录取你?

    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。

      27:请谈谈你个人的最大特色。

    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。

    28.白箱测试和黑箱测试是什么?什么是回归测试?

       29。单元测试、集成测试、系统测试的侧重点是什么?

       30。设计用例的方法、依据有那些?

       31。一个测试工程师应具备那些素质和技能?

       32.集成测试通常都有那些策略?

       33.你用过的测试工具的主要功能、性能及其他?

       34.一个缺陷测试报告的组成

       35.基于WEB信息管理系统测试时应考虑的因素有哪些?

    36.软件测试项目从什么时候开始,?为什么?

        37.需求测试注意事项有哪些?

        38.简述一下缺陷的生命周期

        39.测试分析测试用例注意(事项)?

    你在你所在的公司是怎么开展测试工作的?是如何组织的?

    你认为理想的测试流程是什么样子?

    你是怎样工作的?

    软件测试活动的生命周期是什么?

    请画出软件测试活动的流程图?

    针对缺陷采取怎样管理措施?

    什么是测试评估?测试评估的范围是什么?

    如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?

    测试结束的标准是什么?

    软件验收测试除了alpha,beta测试以外,还有哪一种?

    做测试多久了?

    以前做过哪些项目?

    你们以前测试的流程是怎样的?

    <答:测试计划-测试用例设计-测试执行-测试分析报告>

    用过哪些测试工具?

    为什么选择测试这行?

    <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>

    查看(351) 评论(0) 收藏 分享 管理

  • 软件测试面试题整理

    2007-12-13 20:51:36

     

     软件测试面试题整理

    面试题目:

    01. 为什么要在一个团队中开展软件测试工作

    因为没有经过测试的软件很难在发布之前知道该软件的质量,就好比ISO质量认证一样,测试同样也需要质量的保证,这个时候就需要在团队中开展软件测试的工作。在测试的过程发现软件中存在的问题,及时让开发人员得知并修改问题,在即将发布时,从测试报告中得出软件的质量情况。

    02. 您在以往的测试工作中都曾经具体从事过哪些工作?其中最擅长哪部分工作?

    我曾经做过web测试,后台测试,客户端软件,其中包括功能测试性能测试,用户体验测试。最擅长的是功能测试

    03. 您所熟悉的软件测试类型都有哪些?请试着分别比较这些不同04. 的测试类型的区别与联系(如功能测试、性能测试……)

    测试类型有:功能测试,性能测试,界面测试。

    功能测试在测试工作中占的比例最大,功能测试也叫黑盒测试。是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时,需要测试软件产品的功能,不需测试软件产品的内部结构和处理过程。采用黑盒技术设计测试用例的方法有:等价类划分、边界值分析、错误推测、因果图和综合策略。 

    性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试,两者可以结合进行。通过负载测试,确定在各种工作负载下系统的性能,目标是测试当负载逐渐增加时,系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接收的性能点,来获得系统能提供的最大服务级别的测试。

    界面测试,界面是软件与用户交互的最直接的层,界面的好坏决定用户对软件的第一印象。而且设计良好的界面能够引导用户自己完成相应的操作,起到向导的作用。同时界面如同人的面孔,具有吸引用户的直接优势。设计合理的界面能给用户带来轻松愉悦的感受和成功的感觉,相反由于界面设计的失败,让用户有挫败感,再实用强大的功能都可能在用户的畏惧与放弃中付诸东流。

    区别在于,功能测试关注产品的所有功能上,要考虑到每个细节功能,每个可能存在的功能问题。性能测试主要关注于产品整体的多用户并发下的稳定性和健壮性。界面测试更关注于用户体验上,用户使用该产品的时候是否易用,是否易懂,是否规范(快捷键之类的),是否美观(能否吸引用户的注意力),是否安全(尽量在前台避免用户无意输入无效的数据,当然考虑到体验性,不能太粗鲁的弹出警告)?做某个性能测试的时候,首先它可能是个功能点,首先要保证它的功能是没问题的,然后再考虑该功能点的性能测试

    05.  请试着比较一下黑盒测试、白盒测试、单元测试、集成测试、系统测试、验收测试的区别与联系。

    黑盒测试:已知产品的功能设计规格,可以进行测试证明每个实现了的功能是否符合要求。

    白盒测试:已知产品的内部工作过程,可以通过测试证明每种内部操作是否符合设计规格要求,所有内部成分是否以经过检查。

      软件的黑盒测试意味着测试要在软件的接口处进行。这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书,检查程序的功能是否符合它的功能说明。因此黑盒测试又叫功能测试或数据驱动测试。黑盒测试主要是为了发现以下几类错误:

    1、是否有不正确或遗漏的功能?

    2、在接口上,输入是否能正确的接受?能否输出正确的结果?

    3、是否有数据结构错误或外部信息(例如数据文件)访问错误?

    4、性能上是否能够满足要求?

    5、是否有初始化或终止性错误?

      软件的白盒测试是对软件的过程性细节做细致的检查。这种方法是把测试对象看做一个打开的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑路径进行测试。通过在不同点检查程序状态,确定实际状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。白盒测试主要是想对程序模块进行如下检查:

    1、对程序模块的所有独立的执行路径至少测试一遍。

    2、对所有的逻辑判定,取“真”与取“假”的两种情况都能至少测一遍。

    3、在循环的边界和运行的界限内执行循环体。

    4、测试内部数据结构的有效性,等等。

    单元测试(模块测试)是开发者编写的一小段代码,用于检验被测代码的一个很小的、很明确的功能是否正确。通常而言,一个单元测试是用于判断某个特定条件(或者场景)下某个特定函数的行为。

         单元测试是由程序员自己来完成,最终受益的也是程序员自己。可以这么说,程序员有责任编写功能代码,同时也就有责任为自己的代码编写单元测试。执行单元测试,就是为了证明这段代码的行为和我们期望的一致。

    集成测试(也叫组装测试,联合测试)是单元测试的逻辑扩展。它的最简单的形式是:两个已经测试过的单元组合成一个组件,并且测试它们之间的接口。从这一层意义上讲,组件是指多个单元的集成聚合。在现实方案中,许多单元组合成组件,而这些组件又聚合成程序的更大部分。方法是测试片段的组合,并最终扩展进程,将您的模块与其他组的模块一起测试。最后,将构成进程的所有模块一起测试。

    系统测试是将经过测试的子系统装配成一个完整系统来测试。它是检验系统是否确实能提供系统方案说明书中指定功能的有效方法。(常见的联调测试)

          系统测试的目的是对最终软件系统进行全面的测试,确保最终软件系统满足产品需求并且遵循系统设计。

    验收测试是部署软件之前的最后一个测试操作。验收测试的目的是确保软件准备就绪,并且可以让最终用户将其用于执行软件的既定功能和任务。

    验收测试是向未来的用户表明系统能够像预定要求那样工作。经集成测试后,已经按照设计把所有的模块组装成一个完整的软件系统,接口错误也已经基本排除了,接着就应该进一步验证软件的有效性,这就是验收测试的任务,即软件的功能和性能如同用户所合理期待的那样。

    06. 测试计划工作的目的是什么?测试计划工作的内容都包括什么?其中哪些是最重要的?

    软件测试计划是指导测试过程的纲领性文件,包含了产品概述、测试策略、测试方法、测试区域、测试配置、测试周期、测试资源、测试交流、风险分析等内容。借助软件测试计划,参与测试的项目成员,尤其是测试管理人员,可以明确测试任务和测试方法,保持测试实施过程的顺畅沟通,跟踪和控制测试进度,应对测试过程中的各种变更。

    测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。所以其中最重要的是测试测试策略和测试方法(最好是能先评审)

    07. 您认为做好测试计划工作的关键是什么?

    1. 明确测试的目标,增强测试计划的实用性

    编写软件测试计划得重要目的就是使测试过程能够发现更多的软件缺陷,因此软件测试计划的价值取决于它对帮助管理测试项目,并且找出软件潜在的缺陷。因此,软件测试计划中的测试范围必须高度覆盖功能需求,测试方法必须切实可行,测试工具并且具有较高的实用性,便于使用,生成的测试结果直观、准确

    2.坚持“5W”规则,明确内容与过程

    “5W”规则指的是“What(做什么)”、“Why(为什么做)”、“When(何时做)”、“Where(在哪里)”、“How(如何做)”。利用“5W”规则创建软件测试计划,可以帮助测试团队理解测试的目的(Why),明确测试的范围和内容(What),确定测试的开始和结束日期(When),指出测试的方法和工具(How),给出测试文档和软件的存放位置(Where)。

    3.采用评审和更新机制,保证测试计划满足实际需求

    测试计划写作完成后,如果没有经过评审,直接发送给测试团队,测试计划内容的可能不准确或遗漏测试内容,或者软件需求变更引起测试范围的增减,而测试计划的内容没有及时更新,误导测试执行人员。

    4. 分别创建测试计划与测试详细规格、测试用例

    应把详细的测试技术指标包含到独立创建的测试详细规格文档,把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。测试计划和测试详细规格、测试用例之间是战略和战术的关系,测试计划主要从宏观上规划测试活动的范围、方法和资源配置,而测试详细规格、测试用例是完成测试任务的具体战术。 

    08. 您所熟悉的测试用例设计方法都有哪些?请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

    1.等价类划分

    划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

    2.边界值分析法

      边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

      使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

    3.错误推测法

      基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

      错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

    4.因果图方法

      前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图(逻辑模型). 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况. 

    08.您认为做好测试用例设计工作的关键是什么?

    白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

    黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试,以最少的用例在合理的时间内发现最多的问题

    09. 请以您以往的实际工作为例,10. 详细的描述一次测试用例设计的完整的过程。

    就说最近的这次网站功能的测试吧

    首先:得到相关文档(需求文档和设计文档),理解需求和设计设计思想后,想好测试策略(测试计划简单点就OK了),考虑到测试环境,测试用例,测试时间等问题。

    第二步:设计测试用例,测试策略是:把网站部分的功能点测试完,然后在进行系统测试(另外个模块呢有另一个测试人员负责,可以进行联调测试),网站模块的测试基本是功能测试和界面测试(用户并发的可能性很小,所以不考虑):这次的网站的输入数据呢是使用数据库中的某张表记录,如果表中某一数据记录中新加进来的(还没有被处理的,有个标志位),网站启动后会立刻去刷那张表,得到多条数据,然后在进行处理。处理过程中,会经历3个步骤,网站才算完成了它的任务。有3个步骤呢,就可以分别对这3个步骤进行测试用例的设计,尽量覆盖到各种输入情况(包括数据库中的数据,用户的输入等),得出了差不多50个用例。界面测试,也就是用户看的到的地方,包括发送的邮件和用户填写资料的页面展示。

    第三步:搭建测试环境(为什么这个时候考虑测试环境呢?因为我对网站环境已经很熟了,只有有机器能空于下来做该功能测试就可以做了),因为网站本身的环境搭建和其他的系统有点不同,它需要的测试环境比较麻烦,需要web服务器(Apache,tomcat),不过这次需求呢,网站部分只用到了tomcat,所以只要有tomcat即可

    第四步:执行测试

    11. 您以往是否曾经从事过性能测试工作?如果有,12. 请尽可能的详细描述您以往的性能测试工作的完整过程。

    是的,曾经做过网站方面的性能测试,虽然做的时间并不久(2个月吧),当时呢,是有位网站性能测试经验非常丰富的前辈带着我一起做。

    性能测试类型包括负载测试,强度测试,容量测试等

         负载测试:负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。

         强度测试: 强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。

         容量测试:确定系统可处理同时在线的最大用户数  

    在网站流量逐渐加大的情况下,开始考虑做性能测试了,首先要写好性能测试计划,根据运营数据得出流量最大的页面(如果是第一次的话,一般是首页,下载页,个人帐户页流量最大,而且以某种百分比),

    Web服务器指标指标:

    * Avg Rps: 平均每秒钟响应次数=总请求时间 / 秒数; 

    * Successful Rounds:成功的请求; 

    * Failed Rounds :失败的请求; 

    * Successful Hits :成功的点击次数; 

    * Failed Hits :失败的点击次数; 

    * Hits Per Second :每秒点击次数; 

    * Successful Hits Per Second :每秒成功的点击次数; 

    * Failed Hits Per Second :每秒失败的点击次数; 

    * Attempted Connections :尝试链接数;

    13. 您在从事性能测试工作时,14. 是否使用过一些测试工具?如果有,15. 请试述该工具的工作原理,16. 并以一个具体的工作中的例子描述该工具是如何在实际工作中应用的。

    17. 您认为性能测试工作的目的是什么?做好性能测试工作的关键是什么?

    18. 在您以往的工作中,19. 一条软件缺陷(或者叫Bug)记录都包含了哪些内容?如何提交高质量的软件缺陷(Bug)记录?

    20. 您以往所从事的软件测试工作中,21. 是否使用了一些工具来进行软件缺陷(Bug)的管理?如果有,22. 请结合该工具描述软件缺陷(Bug)跟踪管理的流程。

    23. 您认为在测试人员同24. 开发人员的沟通过程中,25. 如何提高沟通的效率和改善沟通的效果?维持测试人员同26. 开发团队中其他成员良好的人际关系的关键是什么?

    27. 在您以往的测试工作中,28. 最让您感到不29. 满意或者不30. 堪回首的事情是什么?您是如何来对待这些事情的?

    31. 在即将完成这次笔试前,32. 您是否愿意谈一些自己在以往的学习和工作中获得的工作经验和心得体会?(可以包括软件测试、过程改进、软件开发或者与此无关的其他方面)

    33.    你对测试最大的兴趣在哪里?为什么?

    最大的兴趣就是测试有难度,有挑战性!做测试越久越能感觉到做好测试有多难。曾经在无忧测试网上看到一篇文章,是关于如何做好一名测试工程师。一共罗列了11,12点,有部分是和人的性格有关,有部分需要后天的努力。但除了性格有关的1,2点我没有把握,其他点我都很有信心做好它。

    刚开始进入测试行业时,对测试的认识是从无忧测试网上了解到的一些资料,当时是冲着做测试需要很多技能才能做的好,虽然入门容易,但做好很难,比开发更难,虽然当时我很想做开发(学校专业课我基本上不缺席,因为我喜欢我的专业),但看到测试比开发更难更有挑战性,想做好测试的意志就更坚定了。

    不到一年半的测试工作中,当时的感动和热情没有减退一点(即使环境问题以及自身经验,技术的不足,做测试的你一定也能理解)。

    我觉得做测试整个过程中有2点让我觉得很有难度(对我来说,有难度的东西我就非常感兴趣),第一是测试用例的设计,因为测试的精华就在测试用例的设计上了,要在版本出来之前,把用例写好,用什么测试方法写?(也就是测试计划或测试策略),如果你刚测试一个新任务时,你得花一定的时间去消化业务需求和技术基础,业务需求很好理解(多和产品经理和开发人员沟通就能达到目的),而技术基础可就没那么简单了,这需要你自觉的学习能力,比如说网站吧,最基本的技术知识你要知道网站内部是怎么运作的的,后台是怎么响应用户请求的?测试环境如何搭建?这些都需要最早的学好。至少在开始测试之前能做好基本的准备,可能会遇到什么难题?需求细节是不是没有确定好?这些问题都能在设计用例的时候发现。

    第二是发现BUG的时候了,这应该是测试人员最基本的任务了,一般按测试用例开始测试就能发现大部分的bug,还有一部分bug需要测试的过程中更了解所测版本的情况获得更多信息,补充测试用例,测试出bug。还有如何发现bug?这就需要在测试用例有效的情况下,通过细心和耐心去发现bug了,每个用例都有可能发现bug,每个地方都有可能出错,所以测试过程中思维要清晰(测试过程数据流及结果都得看仔细了,bug都在里面发现的)。如何描述bug也很有讲究,bug在什么情况下会产生,如果条件变化一点点,就不会有这个bug,以哪些最少的操作步骤就能重现这个bug,这个bug产生的规律是什么?如果你够厉害的话,可以帮开发人员初步定位问题。

    34. 你的测试职业发展是什么?

    测试经验越多,测试能力越高。所以我的职业发展是需要时间累积的,一步步向着高级测试工程师奔去。而且我也有初步的职业规划,前3年累积测试经验,按如何做好测试工程师的11,12点要求自己,不断的更新自己改正自己,做好测试任务。

    35. 你自认为测试的优势在哪里?

    优势在于我对测试坚定不移的信心和热情,虽然经验还不够,但测试需要的基本技能我有信心在工作中得以发挥。

    36. 你以前工作时的测试流程是什么?

    公司对测试流程没有规定如何做,但每个测试人员都有自己的一套测试流程。我说下我1年来不断改正(自己总结,吸取同行的方法)后的流程吧。需求评审(有开发人员,产品经理,测试人员,项目经理)->需求确定(出一份确定的需求文档)->开发设计文档(开发人员在开始写代码前就能输出设计文档)->想好测试策略,写出测试用例->发给开发人员和测试经理看看(非正式的评审用例)->接到测试版本->执行测试用例(中间可能会补充用例)->提交bug(有些bug需要开发人员的确定(严重级别的,或突然发现的在测试用例范围之外的,难以重现的),有些可以直接录制进TD)->开发人员修改(可以在测试过程中快速的修改)->回归测试(可能又会发现新问题,再按流程开始跑)。

    37. 当开发人员说不38. 是BUG时,39. 你如何应付?

    开发人员说不是bug,有2种情况,一是需求没有确定,所以我可以这么做,这个时候可以找来产品经理进行确认,需不需要改动,3方商量确定好后再看要不要改。二是这种情况不可能发生,所以不需要修改,这个时候,我可以先尽可能的说出是BUG的依据是什么?如果被用户发现或出了问题,会有什么不良结果?程序员可能会给你很多理由,你可以对他的解释进行反驳。如果还是不行,那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug,我也只是建议的方式写进TD中,如果开发人员不修改也没有大问题。如果确定是bug的话,一定要坚持自己的立场,让问题得到最后的确认。

    23.你为什么想离开目前的职务?

    因为公司运作情况并不理想,公司需要调整部门体系,公司考虑到缩减部门人员,所以大批量的裁员(有6,7个),这是我的第一份工作,对公司也有较深的感情,因为在这里我找到了职业理想(就是测试),所以公司需要精简人员,我自愿退出。虽然很舍不得,但我将会有新的发挥能力的舞台。

      24:你对我们公司了解有多少?

      25:你找工作时,最重要的考虑因素为何?

    工作的性质和内容是否能让我发挥所长,并不断成长。

    26:为什么我们应该录取你?

    您可以由我过去的工作表现所呈现的客观数据,明显地看出我全力以赴的工作态度。

      27:请谈谈你个人的最大特色。

    我的坚持度很高,事情没有做到一个令人满意的结果,绝不罢手。

    28.白箱测试和黑箱测试是什么?什么是回归测试?

       29。单元测试、集成测试、系统测试的侧重点是什么?

       30。设计用例的方法、依据有那些?

       31。一个测试工程师应具备那些素质和技能?

       32.集成测试通常都有那些策略?

       33.你用过的测试工具的主要功能、性能及其他?

       34.一个缺陷测试报告的组成

       35.基于WEB信息管理系统测试时应考虑的因素有哪些?

    36.软件测试项目从什么时候开始,?为什么?

        37.需求测试注意事项有哪些?

        38.简述一下缺陷的生命周期

        39.测试分析测试用例注意(事项)?

    你在你所在的公司是怎么开展测试工作的?是如何组织的?

    你认为理想的测试流程是什么样子?

    你是怎样工作的?

    软件测试活动的生命周期是什么?

    请画出软件测试活动的流程图?

    针对缺陷采取怎样管理措施?

    什么是测试评估?测试评估的范围是什么?

    如果能够执行完美的黑盒测试,还需要进行白盒测试吗?为什么?

    测试结束的标准是什么?

    软件验收测试除了alpha,beta测试以外,还有哪一种?

    做测试多久了?

    以前做过哪些项目?

    你们以前测试的流程是怎样的?

    <答:测试计划-测试用例设计-测试执行-测试分析报告>

    用过哪些测试工具?

    为什么选择测试这行?

    <答:它是一个新兴的行业,有发展潜力,而且很锻炼人,需要掌握更多的技能,比做开发要更难>

    查看(655) 评论(0) 收藏 分享 管理

  • 《unix环境高级编程》通读学习笔记(五)(第13、14章)

    2007-12-13 20:41:41

    《unix环境高级编程》通读学习笔记(五)(第13、14章)

    2007-08-04 18:06:11 / 个人分类:unix环境高级编程的学习记录

    13 精灵进程

    13.1 引言

    精灵进程(daemon)是生存期长的一种进程。它们常常在系统引导装入时起动,在系统关闭时终止。因为它们没有控制终端,所以说它们是在后台运行的。 UNIX系统有很多精灵进程,它们执行日常事物活动。

     

    13.2 精灵进程的特征

    所有精灵进程都以超级用户(用户 ID0)的优先权运行。没有一个精灵进程具有控制终端—终端名称设置为问号(?)、终端前台进程组ID设置为-1。缺少控制终端可能是精灵进程调用了setsid的结果。除update以外的所有精灵进程都是进程组的首进程,对话期的首进程,而且是这些进程组和对话期中的唯一进程。update是它所在进程组(37)和对话期(37)中的唯一进程,但是该进程组的首进程(可能也是该对话期的首进程)已经终止。最后,应当引起注意的是所有这些精灵进程的父进程都是init进程。

     

    13.3 编程规则

    在编写精灵进程程序时需遵循一些基本规则,以便防止产生并不希望的交互作用。

    (1) 首先做的是调用fork,然后使父进程exit

    (2) 调用setsid以创建一个新对话期。

    (3) 将当前工作目录更改为根目录。

    (4) 将文件方式创建屏蔽字设置为0

    (5) 关闭不再需要的文件描述符。

     

    13.4 出错记录

       与精灵进程有关的一个问题是如何处理出错消息。因为它没有控制终端,所以不能只是写到标准出错输出上。需要有一个集中的精灵进程出错记录设施。

    13.4.1 SVR4log驱动程序

    SVR4提供了一种流设备驱动程序,其界面具有流出错记录,流事件跟踪以及控制台记录功能。图13-1详细给出了这种设施的整个结构。

    有三个记录进程(logger):出错记录进程、跟踪记录进程以及控制台记录进程。每一条记录消息可以送给其中之一。

    13.4.2 4.3+BSD syslog设施

    4.2BSD以来,广泛地应用了BSD syslog设施。大多数精灵进程使用这一设施。图13-2显示了syslog设施的详细组织结构。

     

    13.5 客户机-服务器模型

        精灵进程常常用作为服务器进程。确实,图 13-2中,可以称syslogd进程为服务器,用户进程(客户机)用UNIX域数据报套接口向其发送消息。

    一般而言,服务器是一个进程,它等待客户机与其联系,提出某种类型的服务要求。图13-2中,由syslogd服务器提供的服务是记录出错消息。

     

    14 进程间通信

    14.1 引言

        8章说明了进程控制原语并且观察了如何调用多个进程。但是这些进程之间交换信息的唯一方法是经由forkexec传送打开文件,或通过文件系统。本章将说明进程之间相互通信的其他技术IPCInterProcess Communication)。

    UNIX IPC已经是而且继续是各种进程通信方式的统称,其中极少能在所有 UNIX的实现中进行移植。表14-1列出了不同实现所支持的不同形式的IPC

    本章将讨论经典的 IPC;管道、FIFO、消息队列、信号量以及共享存储器。

     

    14.2 管道

    管道是UNIX IPC的最老形式,并且所有UNIX系统都提供此种通信机制,管道有两种限制;

    (1) 它们是半双工的。数据只能在一个方向上流动。

    (2) 它们只能在具有公共祖先的进程之间使用。通常,一个管道由一个进程创建,然后该进程调用fork,此后父、子进程之间就可应用该管道。

    管道是由调用pipe函数而创建的。

    ——————————————————————————————————————

    #include <unistd.h>

    int pipe(intfiledes[2]) ;

                                             返回:若成功则为0,若出错则为-1

    有两种方法来描绘一个管道,见图14-1。左半图显示了管道的两端在一个进程中相互连接,右半图则说明数据通过内核在管道中流动。

    单个进程中的管道几乎没有任何用处。通常,调用 pipe的进程接着调用fork,这样就创建了从父进程到子进程或反之的IPC通道。图14-2显示了这种情况。

    fork之后做什么取决于我们想要有的数据流的方向。对于从父进程到子进程的管道,父进程关闭管道的读端(fd[0]),子进程则关闭写端(fd[1])。图14-3显示了描述符的最后安排。

     

    14.3 popen pclose函数

    因为常见的操作是创建一个连接到另一个进程的管道,然后读其输出或向其发送输入,所以标准I/O库为实现这些操作提供了两个函数 popenpclose。这两个函数实现的操作是:创建一个管道,fork一个子进程,关闭管道的不使用端,exec一个shell以执行命令,等待命令终止。

    ____________________________________________________________________________

    #include <stdio.h>

    FILE *popen(const  *charcmdstring, const char *type);

                                 返回:若成功则为文件指针,若出错则为 NULL

    int pclose(FILE *fp);

                                 返回:cmdstring的终止状态,若出错则为-1

     

    14.4 协同进程

    UNIX过滤程序从标准输入读取数据,对其进行适当处理后写到标准输出。几个过滤进程通常在shell管道命令中线性地连接。当同一个程序产生某个过滤程序的输入,同时又读取该过滤程序的输出时,则该过滤程序就成为协同进程(coprocess)

    协同进程的工作方式在C程序中也是非常有用的.

     

    14.5 FIFO

         FIFO有时被称为命名管道。管道只能由相关进程使用,它们共同的祖先进程创建了管道。但是,通过FIFO,不相关的进程也能交换数据。

         14章已经提及FIFO是一种文件类型。创建FIFO类似于创建文件。确实,FIFO的路径名存在于文件系统中。

    ----------------------------------------------------------------------------------------------------------------------

    #include    <sys/types.h>

    #include    <sys/stat.h>

    int mkfifo(const *charpathname, mode_tmode);

                                               返回:若成功则为0,若出错则为-1

         一旦已经用 mkfifo创建了一个 FIFO,就可用 open打开它。确实,一般的文件 I/O函数(closereadwriteunlink等)都可用于FIFO

         FIFO有两种用途:

         (1) FIFOshell命令使用以便将数据从一条管道线传送到另一条,为此无需创建中间临时文件。

         (2) FIFO用于客户机-服务器应用程序中,以在客户机和服务器之间传递数据。

     

    14.6 系统V IPC

        三种系统V IPC:消息队列、信号量以及共享存储器之间有很多相似之处。

    14.6.1 标识符和关键字

    每个内核中的 IPC结构(消息队列、信号量或共享存储段)都用一个非负整数的标识符(identifier)加以引用。例如,为了对一个消息队列发送或取消息,只需知道其队列标识符。

    无论何时创建IPC结构(调用msggetsemgetshmget,都应指定一个关键字(key),关键字的数据类型由系统规定为key_t,通常在头文件<sys/types.h>中被规定为长整型。关键字由内核变换成标识符。

    14.6.2 许可权结构

    系统V IPC为每一个IPC结构设置了一个ipc_perm结构。该结构规定了许可权和所有者。

    14.6.3 结构限制

    14.6.4 优点和缺点

    系统V IPC的主要问题是;IPC结构是在系统范围内起作用的,没有访问计数。

    系统V IPC的另一个问题是;这些IPC结构并不按名字为文件系统所知。我们不能用第34章中所述的函数来存取它们或修改它们的特性。为了支持它们不得不增加了十多个全新的系统调用(msggetsemopshmat等)。我们不能用ls命令见到它们,不能用 rm命令删除它们,不能用chmod命令更改它们的存取权。于是,也不得不增加了全新的命令 ipcs ipcrm

    因为这些IPC不使用文件描述符,所以不能对它们使用多路转接 I/O函数:selectpoll。这就使得一次使用多个IPC结构,以及用文件或设备I/O来使用IPC结构很难做到。

     

    14.7 消息队列

    消息队列是消息的链接表 ,存放在内核中并由消息队列标识符标识。我们将称消息队列为“队列”,其标识符为“队列ID”。msgget用于创建一个新队列或打开一个现存的队列。 msgsnd用于将新消息添加到队列尾端。msgrcv用于从队列中取消息。我们并不一定要以先进先出次序取消息,也可以按消息的类型字段取消息。

    每个队列都有一个msqid_ds结构与其相关。此结构规定了队列的当前状态。

    调用的第一个函数通常是msgget,其功能是打开一个现存队列或创建一个新队列。

     

    #include <sys/types.h>

    #include <sys/ipc.h>

    #include <sys/msg.h>

    int msgget(key_tkey, int flag);

                                  返回:若成功则为消息队列ID,若出错则为-1

    ---------------------------------------------------------------------------------------------------------------------

    msgctl函数对队列执行多种操作。它以及另外两个与信号量和共享存储有关的函数 (semctlshmctl)是系统V IPC的类似于ioctl的函数(亦即垃圾桶函数)。

    ---------------------------------------------------------------------------------------------------------------------

    #include <sys/types.h>

    #include <sys/ipc.h>

    #include <sys/msg.h>

    int msgctl(intmsqid, int cmd, struct msqid_ds *buf);

                                               返回:若成功则为0,出错则为-1

    ---------------------------------------------------------------------------------------------------------------------

     

    调用msgsnd将数据放到消息队列上。

    --------------------------------------------------------------------------------------------------------------------

    #include <sys/types.h>

    #include <sys/ipc.h>

    #include <sys/msg.h>

    int msgsnd(intmsqid, const void *ptr, size_tnbytes, int flag)

                                              返回:若成功则为0,若出错则为-1

    ---------------------------------------------------------------------------------------------------------------------

     

    msgrcv从队列中取用消息。

    --------------------------------------------------------------------------------------------------------------------

    #include <sys/types.h>

    #include <sys/ipc.h>

    #include <sys/msg.h>

    int msgrcv(intmsqid, void * ptr , size_t nbytes, long type, int flag);

                                <

  • 《unix环境高级编程》通读学习笔记(四)(第12章)

    2007-12-13 20:40:42

    《unix环境高级编程》通读学习笔记(四)(第12章)

    2007-07-28 17:40:27 / 个人分类:unix环境高级编程的学习记录

    第12章 高级I/O

    12.1 引言
    12.2 非阻塞I/O

    低速系统调用是可能会使进程永远阻塞的一类系统调用.
    非阻塞I/O使我们可以调用不会永远阻塞的I/O操作,例如open,read和write。如果这种操作不能完成,则立即出错返回,表示该操作如继续执行将继续阻塞下去。

    12.3 记录锁
    记录锁(record locking)的功能是:一个进程正在读或修改文件的某个部分时,可以阻止其他进程修改同一文件区。
    12.3.1 历史
    12.3.2 fcntl记录锁
    fcntl函数的原型
    ---------------------------------------------------------------------
    #include <sys/types.h>
    #include <unistd.h>
    #include <fcnt1.h>
    int fcnt1(int filedes,int cmd,.../* struct flock *flockptr */);
    返回:若成功则依赖于c m d(见下),若出错则为- 1
    ---------------------------------------------------------------------
    12.3.3 锁的隐含继承和释放
    关于记录锁的自动继承和释放有三条规则:
    (1) 锁与进程、文件两方面有关。
    (2) 由fork产生的子程序不继承父进程所设置的锁。
    (3) 在执行exec后,新程序可以继承原执行程序的锁。
    12.3.4 4.3+BSD的实现
    12.3.5 建议性锁和强制性锁
    考虑数据库存取例程序。如果该库中所有函数都以一致的方法处理记录锁,则称使用这些函数存取数据库的任何进程集为合作进程(cooperating process)。如果这些函数是唯一的用来存取数据库的函数,那么它们使用建议性锁是可行的。
    强制性锁机制中,内核对每一个open、read和write都要检查调用进程对正在存取的文件是否违背了某一把锁的作用。

    12.4 流
    流是系统V提供的构造内核设备驱动程序和网络协议包的一种通用方法。
    流在用户进程和设备驱动程序之间提供了一条全双工通路。流无需和实际硬件设备直接对话—流也可以用作为伪设备驱动程序。图12-5示出了一个简单流的基本结构。
    图12-6示出了一个包含一个处理模块的流。
    12.4.1 流消息
    流的所有输入和输出都基于消息。流首和用户进程使用read、write、getmsg、getpmsg、putmsg和putpmsg交换消息。在流首、各处理模块和设备驱动程序之间,消息可以顺流而下,也可以逆流而上。
    有约2 5种不同类型的消息,但是只有少数几种用于用户进程和流首之间。其余的则只在内核中顺流、逆流传送。
    12.4.2 putmsg和 putpmsg函数
    putmsg和putpmsg函数用于将流消息(控制信息或数据,或两者)写至流中。
    12.4.3 流ioct1操作
    ioctl函数,它能做其他I / O函数不能处理的事情。流系统中继续采用了该函数。
    12.4.4 write至流设备
    12.4.5 写方式
    12.4.6 getmsg和 getpmsg函数
    12.4.7 读方式

    12.5 I/O多路转接
    当从一个描述符读,然后又写到另一个描述符时。如果必须读两个描述符又将如何呢?如果仍旧使用阻塞I / O,那么就可能长时间阻塞在一个描述符上,而另一个描述符虽有很多数据却不能得到及时处理。所以为了处理这种情况显然需要另一种不同的技术
    一种比较好的技术是使用I/O多路转接(I/O multiplexing)。其基本思想是:先构造一张有关描述符的表,然后调用一个函数,它要到这些描述符中的一个已准备好进行I/O时才返回。在返回时,它告诉进程哪一个描述符已准备好可以进行I/O。
    12.5.1 select函数
    select函数使我们在SVR4和4.3+BSD之下可以执行I/O多路转接。
    12.5.2 poll函数
    SVR4的poll函数类似于select,但是其调用形式则有所不同。我们将会看到,poll与流系统紧紧相关。

    12.6 异步I/O
    使用select和poll可以实现异步I/O。关于描述符的状态,系统并不主动告诉我们任何信息,我们需要主动地进行查询(调用select或poll)。SVR4和4.3+BSD提供了使用一个信号(在SVR4中是SIGPOLL,在4.3+BSD中是SIGIO)的异步I/O方法,该信号通知进程,对某个描述符所关心的某个事件已经发生。
    12.6.1 SVR4
    12.6.2 4.3+BSD

    12.7 readv和writev函数
    readv和writev函数用于在一个函数调用中读、写多个非连续缓存。
    --------------------------------------------------------------------
    #include <sys/types.h>
    #include <sys/uio.h>
    #include <sys/types.h>
    #include <sys/uio.h>
    ssize_t readv(int filedes,const struct ioveciov[ ],int iovcnt);
    ssize_t writev(int filedes,const struct ioveciov[ ],int iovcnt);
    两个函数返回:已读、写的字节数,若出错则为-1
    --------------------------------------------------------------------

    12.8 readn和 writen函数
    12.9 存储映射I/O

    存储映射I/O使一个磁盘文件与存储空间中的一个缓存相映射。于是当从缓存中取数据,就相当于读文件中的相应字节。与其类似,将数据存入缓存,则相应字节就自动地写入文件。这样,就可以在不使用read和write的情况下执行I/O。为了使用这种功能,应首先告诉内核将一个给定的文件映射到一个存储区域中。这是由mmap函数实现的。
    ------------------------------------------------------------------------------------
    #include <sys/types.h>
    #include <sys/mman.h>
    caddr_t mmap(caddr_t addr, size_tlen,int prot,int flag,int filedes,off_t off);
    返回:若成功则为映射区的起始地址,若出错则为 - 1
    ------------------------------------------------------------------------------------

  • 《unix环境高级编程》通读学习笔记(三)(第11章)

    2007-12-13 20:39:06

    《unix环境高级编程》通读学习笔记(三)(第11章)

    2007-07-28 17:12:59 / 个人分类:unix环境高级编程的学习记录

    第11章 终端I/O

    11.1 引言
    终端I/O的用途很广泛,包括:终端、计算机之间的直接连接、调制解调器、打印机等等,所以它就变得非常复杂。

    11.2 综述
    终端I/O有两种不同的工作方式:
    (1) 规范方式输入处理。在这种方式中,终端输入以行为单位进行处理。对于每个读要求,终端驱动程序最多返回一行。
    (2) 非规范方式输入处理。输入字符不以行为单位进行装配。
    如果不作特殊处理,则默认方式是规范方式。
    终端设备是由一般位于内核中的终端驱动程序所控制的。每个终端设备有一个输入队列,一个输出队列。
    图11-1   终端设备的输入、输出队列的逻辑结构
    大多数UNIX系统在一个称为终端行规程(terminal lined iscipline)的模块中进行规范处理。它是位于内核类属读、写函数和实际设备驱动程序之间的模块。
    图11-2   终端行规程
    我们可以检测和更改的终端设备特性都包含在termios结构中。该结构在头文件<termios.h>中定义。
    表11 - 1列出了所有可以更改以影响终端设备特性的终端标志。
    表11 - 2列出了POSIX.1所定义的对终端设备进行操作的各个函数。

    11.3 特殊输入字符
    表11-3 终端在输入时作特殊处理的字符。
    在POSIX.1的11个特殊字符中,可将其中9个更改为几乎任何值。可选地允许禁止使用这些字符。

    11.4 获得和设置终端属性
    使用函数tcgetattr和tcsetattr可以获得或设置termios。这样也就可以检测和修改各种终端选择标志和特殊字符,以使终端按我们所希望的方式进行操作。
    ——————————————————————————————————————————————
    #include <termios.h>
    int tcgetattr(int filedes, struct termios *termptr);
    int tcsetattr(int filedes, int opt, const struct termios *termptr);
    两个函数返回:若成功则为0,若出错则为-1
    ——————————————————————————————————————————————

    11.5 终端选择标志
    11.6 stty命令

    上节说明的所有选择项,在程序中都可用tcgetattr和tcsetattr函数(见11.4节)进行检查和更改。在命令行中则用stty(1)命令进行检查和更改。stty(1)命令是表11-2中所列的头6个函数的界面。如果以-a选择项执行此命令,则显示终端的所有选择项

    11.7 波特率函数
    波特率(baud rate)是一个历史沿用的术语,现在它指的是“位 /每秒”。虽然大多数终端设备对输入和输出使用同一波特率,但是只要硬件许可,可以将它们设置为两个不同值。
    —————————————————————————————————————
    #include <termios.h>
    speed_t cfgetispeed(const struct termios *termptr);
    speed_t cfgetospeed(const struct termios *termptr);
    两个函数返回:波特率值
    int cfsetispeed(struct termios *termptr,speed_t speed);
    int cfsetospeed(struct termios *termptr,speed_t speed);
    两个函数返回:若成功为0,出错为-1。
    —————————————————————————————————————

    11.8 行控制函数
    下列四个函数提供了终端设备的行控制能力。
    ——————————————————————————————————————
    #include <termios.h>
    int tcdrain(int filedes) ;
    int tcflow(int filedes, int action);
    int tcflush(int filedes, int queue);
    int tcsendbreak(int filedes, int duration);
    四个函数返回:若成功则为0,若出错则为-1
    ——————————————————————————————————————
    tcdrain函数等待所有输出都被发送。tcflow用于对输入和输出流控制进行控制。
    tcflush函数刷清(抛弃)输入缓存(终端驱动程序已接收到,但用户程序尚未读)或输出缓存(用户程序已经写,但尚未发送)。
    tcsendbreak函数在一个指定的时间区间内发送连续的 0位流。

    11.9 终端标识
    在大多数UNIX系统中,控制终端的名字是/dev/tty。POSIX.1提供了一个运行时函数,可被调用来决定控制终端的名字。
    --------------------------------------------------------------------
    #include <stdio.h>
    char * ctermid(char *ptr) ;
    返回:见下
    --------------------------------------------------------------------
    此函数的主要作用是帮助提高向其他操作系统的可移植性。

    11.10 规范方式
    规范方式很简单—发一个读请求,当一行已经输入后,终端驱动程序即返回。许多条件造成读返回。
    1.所要求的字节数已读到时读即返回。
    2.当读到一个行定界符时,读返回。
    3.如果捕捉到信号而且该函数并不自动再起动(见10.5节),则读也返回。

    11.11 非规范方式
    将termios结构中c_lflag字段的ICANON标志关闭就使终端处于非规范方式。
    当已读了指定量的数据后,或者已经过了给定量的时间后,即通知系统返回。这种技术使用了termios结构中c_cc数组的两个变量:MIN和TIME。
    MIN说明一个read返回前的最小字节数。TIME说明等待数据到达的分秒数。
    表11 - 4列出了非规范方式下的四种不同情形。

    11.12 终端的窗口大小
    可以对当前终端窗口的大小进行跟踪,在窗口大小发生变化时,使内核通知前台进程组。内核为每个终端和伪终端保存一个 winsize结构。
    提供这种功能的目的是,当窗口大小发生变化时通知应用程序(例如vi编辑程序)。应用程序接到此信号后,它可以取得窗口大小的新值,然后重绘屏幕。

    11.13 termcap, terminfo和 curses
    termcap的意思是终端性能(terminal capability),为了支持vi编辑器而发展起来的。termcap这种技术不是很完善的。导致开发另一种新技术—terminfo及与其相关的curses库。
    termcap和terminfo都致力于本章所述及的问题—更改终端的方式、更改终端特殊字符、处理窗口大小等等。它们所提供的是在各种终端上执行典型操作(清屏、移动光标)的方法。

  • unix编程相关知识点的Q&A

    2007-12-13 20:37:07

    unix编程相关知识点的Q&A【不断累积中】

    2007-08-06 21:47:22 / 个人分类:unix环境高级编程的学习记录

     

    为了学好unix下的编程,一方面系统的看书来学习,另一方面当遇到问题时查询答案后,将问题和答案进行整理。于是形成了下面的Q&A,希望能以此来提高学习效率。

    Q:在书中,经常看到各种Unix系统版本,包括SVR4/4.3BSD/4.3+BSD/V,这些版本之间有什么关系?和我目前使用的unix版本有什么关系?

    A:1973年,Dennis Ritchie用他自己开发的C语言重写了一遍UNIX,奠定了UNIX普及化的基础。1976年他们首次将第六版的UNIX流传到AT&T以外的地方。 UC Berkeley的人以UNIX 7.0为基础,发表了称作BSD的系统,并且开发到1992年的4.4版;而AT&T也不断改进他们的系统,发表了商业化的System Ⅲ直到System Ⅴ。总之,BSD Unix和Unix System V是Unix操作系统的两大主流,以后的Unix系统都是这两种系统的衍生产品。

    SVR4(UNIX System V Release 4)是AT&T UNIX系统实验室的产品,是UNIX系统V第4版,在1990年开始向最终用户提供。SVR4包含了BSD的兼容库〔AT&T 1990c〕,它提供了功能与4.3BSD对应的函数和命令。但是其中某些函数与POSIX的对应部分有所不同.

    BSD(Berkeley Software Distribution)是由加州大学伯克利分校的计算机系统研究组研究开发和分发的。 4.2BSD于1983年问世,4.3BSD则在1986年。这两个版本都在 VAX小型机上运行。本书中使用术语4.3+BSD表示BSD系统,该系统位于BSD网络软件2.0版和即将发布的4.4BSD之间。

    目前工作中接触过的unix版本有:AIX,HP-UX,Linux.
    AIX(Advanced Interactive Executive)是IBM版的UNIX系统,是根据SVR2以及一部分BSD延伸而来,加上各种硬件的支持。具备特有的系统管理(SMIT)。

    HP-UX是HP版的UNIX系统,旧系统是从SIII(SVRx)发展而来,现在是由SVR2和4.2BSD发展而来。
    Linux和Unix的历史版本和源码完全无关,严格来讲只能算仿制品。但Linux的开发者来自整个Internet,具有各种Unix系统的背景,因此Linux也集中了各种Unix的优点,从性能上与商业产品毫不逊色。

    Linux仅仅指操作系统的内核,使用这个内核的系统的Linux版本很多,例如RedHat Linux,Debian Linux,Slackware Linux等。

    参考资料:http://book.csdn.net/bookfiles/418/10041815055.shtml
    http://maruyue.spaces.live.com/blog/cns!907794A84AAAF537!151.entry?_c=BlogPart
    http://www.linuxeden.com/forum/archiver/tid-30218.html

  • 《unix环境高级编程》通读学习笔记(二)(第10章)

    2007-12-13 20:33:59

     

    《unix环境高级编程》通读学习笔记(二)(第10章)

     第10章 信号 

    10.1 引言 

    信号是软件中断。它提供了一种处理异步事件的方法。

    10.2 信号的概念 

    字符SIG开头 头文件<signal.h>中

    产生一个信号的条件:

    1.用户按某些终端键

    2.硬件异常产生信号

    3.进程用kill(2)函数可将信号发送给令一个进程或进程组

    4.用户可用kill(1)命令将信号发送给其他进程

    5.当检测到某种软件条件已经发生,并将其通知有关进程时也产生信号

    信号出现时的三种操作方式:

    1.忽略此信号

    2.捕捉信号

    3.执行系统默认动作

    表10-1 UNIX信号

    10.3 signal函数 

    signal函数为信号处理程序(signal handler)或信号捕捉函数(signal-catching function)

    ————————————————————————————————————————————————————

    #include <signal.h>

    void (*signal(int signo,void (*func)(int)))(int);

                                                返回:成功则为以前的信号处理配置,若出错则为SIG_ERR

    ————————————————————————————————————————————————————

    10.4 不可靠的信号 

    10.5 中断的系统调用 

    系统调用分为两类:低速系统调用和其他系统调用。低速系统调用是可能会使进程永远阻塞的一类系统调用。

    表10-2 几种信号实现所提供的功能

    10.6 可再入函数 

    进程捕捉到信号并继续执行时,首先执行该信号处理程序中的指令。如果从信号处理程序返回,则继续执行在捕捉到信号时进程正在执行的正常指令序列。

    如果进程正在执行某函数,由于捕捉到信号插入执行信号处理程序,其中又调用该函数,则可能会出错。所以引入了可再入函数的概念。

    表10-3 信号处理程序中可以调用的可再入函数

    10.7 SIGCLD语义 

    SIGCLD是系统V的一个信号名,它不同于其他信号。如果用signal或sigset设置信号配置,则SVR4存在兼容性限制。所以务必了解你所用的系统中SIGCHLD信号的语义。

    10.8 可靠信号术语和语义 

    当造成信号的事件发生时,为进程产生一个信号,内核在进程表中设置一个标志,这个动作称之为向一个进程递送了一个信号。在信号产生(generation)和递送(delivery)之间的时间间隔内,称信号未决(pending)。

    当递送一个原来北阻塞的信号给进程时,而不是在产生该信号时,内核才决定对它的处理方式。于是进程在信号递送给它之前仍可改变对它的动作。

    10.9 kill 和raise函数 

    kill函数将信号发送给进程或进程组。raise函数则允许进程向自身发送信号。

    ———————————————————————————————————————————————————

    #include <sys/ttpes.h>

    #include <signal.h>

    int kill(pid_t pid,int signo);

    int raise(int signo);

                                     两个函数返回:若成功则为0,若出错则为-1

    ———————————————————————————————————————————————————

    进程将信号发送给其他进程需要许可权。

    10.10 alarm和 pause函数 

    alarm函数可以设置一个时间值(闹钟时间),当所设置的时间值被超过后,产生SIGALRM信号。

    ————————————————————————————————————————————————————

    #include <unistd.h>

    unsigned int alarm(unsigned int seconds);

                                        返回:0或以前设置的闹钟实践的余留秒数

    ————————————————————————————————————————————————————

    每个进程只能有一个闹钟时间。大多数是使用闹钟的进程捕捉此信号。

    pause函数使调用进程挂起直至捕捉到一个信号。

    ————————————————————————————————————————————————————

    #include <unistd.h>

    int pause(void);

                                       返回:-1,errno设置为EINTR

    ————————————————————————————————————————————————————

    只有执行了一个信号处理程序并从其返回时,pause才返回。

    10.11 信号集 

    能表示多个信号-信号集(signal set)的数据类型。

    数据类型sigset_t包含一个信号集。五个处理信号集的函数:

    ————————————————————————————————————————————————————

    #include <signal.h>

    int sigemptyset(sigset_t *set);

    int sigfillset(sigset_t *set);

    int sigaddset(sigset_t *set,int signo);

    int sigdelset(sigset_t *set,int signo);

                                               四个函数返回:若成功则为0,若出错则为-1

    int sigismember(const sigset_t *set,int signo);

                                               返回:若真则为1,若假则为0

    ————————————————————————————————————————————————————

    函数sigemptyset初始化由set指向的信号集,使排除其中所有信号。

    函数sigfillset初始化由set指向的信号集,使其包括所有信号。

    所有应用程序在使用信号集前,要对该信号集调用sigemptyset或sigfillset一次。

    函数sigaddset将一个信号添加到现存集中,sigdelset则从信号集中删除一个信号。对所有以信号集作为参数的函数,都向其传送信号集地址。

    10.12 sigprocmask 函数 

    一个进程的信号屏蔽字规定了当前阻塞而不能递送给该进程的信号集。调用函数sigprocmask可以检测或更改(或两者)进程的信号屏蔽字。

    ————————————————————————————————————————

    # include <signal.h>

    int sigprocmask(int h o w, const sigset_t *s e t, sigset_t *o s e t) ;

    返回:若成功则为0,若出错则为-1

    ————————————————————————————————————————

    10.13 sigpending函数 

    sigpending返回对于调用进程被阻塞不能递送和当前未决的信号集。该信号集通过set参数返回。

    ——————————————————————————————————————————

    #include <signal.h>

    int sigpending(sigset_t *s e t) ;

    返回:若成功则为0,若出错则为-1

    ——————————————————————————————————————————

    10.14 sigaction函数 

    sigaction函数的功能是检查或修改(或两者)与指定信号相关联的处理动作。此函数取代了UNIX早期版本使用的signal函数。

    ————————————————————————————————————

    #include <signal.h>

    int sigaction(int signo, const struct sigaction *a c t,

    struct sigaction *oact) ;

    返回:若成功则为0,若出错则为- 1

    ————————————————————————————————————

    struct sigaction {

    void       (*sa_handler)(); /* addr of signal handler,

    or SIG_IGN, or SIG_DFL */

    sigset_t sa_mask;           /* additional signals to block */

    int        sa_flags;       /* signal options, Table 10-5 */

    } ;

    表10-5  信号处理的选择项标志( sa_flags)

    10.15 sigsetjmp 和siglongjmp函数 

    在信号处理程序中经常调用longjmp函数以返回到程序的主循环中,而不是从该处理程序返回。

    POSIX.1定义了两个新函数sigsetjmp和siglongjmp。在信号处理程序中作非局部转移时应当使用这两个函数。

    ——————————————————————————————————

    #include <setjmp.h>

    int sigsetjmp(sigjmp_buf env, int savemask) ;

    返回:若直接调用则为0,若从siglongjmp调用返回则为非0

    void siglongjmp(sigjmp_buf env, int val)

    ——————————————————————————————————

    10.16 sigsuspend函数 

    一个原子操作中实现恢复信号屏蔽字,然后使进程睡眠,这种功能是由sigsuspend函数所提供的。

    ——————————————————————————————————

    #include <signal.h>

    int sigsuspend(const sigset_t *sigmask) ;

    返回:-1, errno设置为EINTR

    ——————————————————————————————————

    10.17 abort函数 

    abort函数的功能是使程序异常终止。

    ——————————————————————————————————

    #include <stdlib.h>

    void abort(void);

    此函数不返回

    ——————————————————————————————————

    此函数将SIGABRT信号发送给调用进程。进程不应忽略此信号。

    ANSI C要求若捕捉到此信号而且相应信号处理程序返回, abort仍不会返回到其调用者。

    10.18 system 函数 

    POSIX.2要求system忽略SIGINT和SIGQUIT,阻塞SIGCHLD。

    因为由system执行的命令可能是交互作用命令,以及因为system的调用者在程序执行时放弃了控制,等待该执行程序的结束,所以system的调用者就不应接收这两个终端产生的信号。

    system的返回值是shell的终止状态,它不总是执行命令字符串进程的终止状态。

    10.19 sleep函数 

    ——————————————————————————————————

    #include <unistd.h>

    unsigned int sleep(unsigned int seconds);

    返回:0或未睡的秒数

    ——————————————————————————————————

    此函数使调用进程被挂起直到:

    (1) 已经过了seconds所指定的墙上时钟时间,或者

    (2) 该进程捕捉到一个信号并从信号处理程序返回。

    sleep可以用alarm函数实现,但这并不是必需的。如果使用alarm,则这两个函数之间可以有交互作用。

    10.20 作业控制信号 

    在表10-1中有六个POSIX.1认为是与作业控制有关的信号。

    SIGCHLD  子进程已停止或终止。

    SIGCONT  如果进程已停止,则使其继续运行。

    SIGSTOP  停止信号(不能被捕捉或忽略)。

    SIGTSTP  交互停止信号。

    SIGTTIN  后台进程组的成员读控制终端。

    SIGTTOU  后台进程组的成员写控制终端。

    大多数应用程序并不处理这些信号——交互式shell通常做处理这些信号的所有工作

    10.21 其他特征 

  • unix环境高级编程》通读学习笔记(一)(前9章)

    2007-12-13 20:20:03

    unix环境高级编程》通读学习笔记(一)(前9章)

     

    第1章 UNIX基础知识
    1.2 登录
    1.3 文件和目录
    1.4 输入和输出
    1.5 程序和进程
    1.6 ANSI C
    1.7 出错处理
    1.8 用户标识
    1.9 信号
    1.10 UNIX时间值
    1.11 系统调用和库函数
    第2章 UNIX标准化及实现
    2.2 UNIX标准化
    2.3 UNIX实现
    2.4 标准和实现的关系
    2.5 限制
    2.6 功能测试
    2.7 基本系统数据类型
    2.8 标准之间的冲突
    第3章 文件I/O
    3.2 文件描述符
    3.3 open函数


    3.4 creat函数


    3.5 close函数


    3.6 lseek函数


    3.7 read函数


    3.8 write函数


    3.9 I/O的效率
    3.10 文件共享
    3.11 原子操作
    3.12 dup和dup2函数


    3.13 fcntl函数


    3.14 ioctl函数


    3.15 /dev/fd

    第4章 文件和目录
    4.2 stat,fstat和lstat函数


    4.3 文件类型
    4.4 设置-用户-ID和设置-组-ID
    4.5 文件存取许可权
    4.6 新文件和目录的所有权
    4.7 access函数

    4.8 umask函数


    4.9 chmod 和fchomod函数


    4.10 粘住位
    4.11 chown, fchown和 lchown函数


    4.12 文件长度
    4.13 文件截短
    4.14 文件系统
    4.15 link, unlink, remove和 rename 函数


    4.16 符号连接
    4.17 symlink 和readlink函数


    4.18 文件的时间
    4.19 utime函数


    4.20 mkdir和 rmdir函数


    4.21 读目录
    4.22 chdir, fchdir和 getcwd函数


    4.23 特殊设备文件
    4.24 sync和 fsync函数


    4.25 文件存取许可权位小结


    第5章 标准I/O库
    5.2 流和FILE对象
    5.3 标准输入、标准输出和标准出错
    5.4 缓存

    setbuf setvbuf fflush函数


    5.5 打开流

    fopen freopen fdopen fclose函数


    5.6 读和写流

    getc fgetc getchar putc fputc putchar函数


    5.7 每次一行I/O

    fgets gets fputs puts函数


    5.8 标准I/O的效率
    5.9 二进制I/O

    fread fwite函数


    5.10 定位流

    ftell fseek rewind fgetpos fsetpos函数


    5.11 格式化I/O

    printf fprintf sprintf scanf fscanf sscanf函数


    5.12 实现细节

    fileno函数


    5.13 临时文件

    tmpnam tmpfile函数


    5.14 标准I/O的替代软件


    第6章 系统数据文件和信息
    6.2 口令文件

    getpwuid getpwnam函数


    6.3 阴影口令
    6.4 组文件

    getrgid getgrnam函数


    6.5 添加组ID

    getgroups setgroups initgroups函数
    6.6 其他数据文件
    6.7 登录会计
    6.8 系统标识

    uname gethostname函数


    6.9 时间和日期例程

    time gmtime localtime mktime asetime ctime striftime函数

    第7章 UNIX进程的环境
    7.2 main 函数
    7.3 进程终止

    exit _exit atexit


    7.4 命令行参数
    7.5 环境表
    7.6 C程序的存储空间布局
    7.7 共享库
    7.8 存储器分配

    malloc calloc realloc free


    7.9 环境变量

    getenv setenv putenv unsetenv


    7.10 setjmp 和longjmp函数 


    7.11 getrlimit 和setrlimit函数



    第8章 进程控制
    8.2 进程标识

    getpid getuid geteuid getgid getegid


    8.3 fork函数


    8.4 vfork 函数


    8.5 exit函数


    8.6 wait和waitpid函数


    8.7 wait3和 wait4函数


    8.8 竞态条件
    8.9 exec函数

    execl execv enecle execve execlp execvp


    8.10 更改用户ID 和组ID 
    setreuid 和setregid函数

    seteuid和 setegid函数



    8.12 system函数


    8.13 进程会计
    8.14 用户标识

    getlogin


    8.15 进程时间

    times



    第9章 进程关系

    9.2 终端登录
    9.3 网络登录
    9.4 进程组

    getpgrp setpgid


    9.5 对话期

    setsid

    9.6 终端控制
    9.7 tcgetpgrp 和tcsetpgrp函数


    9.8 作业控制
    9.9 shell执行程序
    9.10 孤儿进程组
    9.11 4.3+BSD实现 

  • 《unix环境高级编程》的目录

    2007-12-13 20:16:16

    《unix环境高级编程》的目录

    2007-07-17 22:52:40 / 个人分类:unix环境高级编程的学习记录

    第1章 UNIX基础知识
    1.1 引言
    1.2 登录
    1.2.1 登录名
    1.2.2 shell
    1.3 文件和目录
    1.3.1文件系统
    1.3.2 文件名
    1.3.3路径名
    1.3.4工作目录
    1.3.5起始目录
    1.4输入和输出
    1.4.1文件描述符
    1.4.2标准输入、标准输出和标准出错
    1.4.3不用缓存的I/O
    1.4.4标准I/O
    1.5程序和进程
    1.5.1程序
    1.5.2进程和进程ID
    1.5.3进程控制
    1.6 ANSI C
    1.6.1 函数原型
    1.6.2类属指针
    1.6.3原始系统数据类型
    1.7 出错处理
    1.8 用户标识
    1.8.1 用户ID
    1.8.2 组ID
    1.8.3 添加组ID
    1.9 信号
    1.10 UNIX时间值
    1.11 系统调用和库函数
    1.12 小结 习题
    第2章 UNIX标准化及实现
    2.1 引言
    2.2 UNIX标准化
    2.2.1 ANSI C
    2.2.2 IEEE POSIX
    2.2.3 X/Open XPG3
    2.2.4 FIPS
    2.3 UNIX实现
    2.3.1 SVR4
    2.3.2 4.3+BSD
    2.4 标准和实现的关系
    2.5 限制
    2.5.1 ANSI C限制
    2.5.2 POSIX限制
    2.5.3 XPG3限制
    2.5.4 sysconf、pathconf和 fpathconf函数
    2.5.5 FIPS 151-1要求
    2.5.6 限制总结
    2.5.7 未确定的运行时间限制
    2.6 功能测试
    2.7 基本系统数据类型
    2.8 标准之间的冲突
    2.9 小结 习题
    第3章 文件I/O
    3.1 引言
    3.2 文件描述符
    3.3 open函数
    3.4 creat函数
    3.5 close函数
    3.6 lseek函数
    3.7 read函数
    3.8 write函数
    3.9 I/O的效率
    3.10 文件共享
    3.11 原子操作
    3.11.1 添加至一个文件
    3.11.2 创建一个文件
    3.12 dup和dup2函数
    3.13 fcntl函数
    3.14 ioctl函数
    3.15 /dev/fd
    3.16 小结 习题
    第4章 文件和目录
    4.1 引言
    4.2 stat,fstat和lstat函数
    4.3 文件类型
    4.4 设置-用户-ID和设置-组-ID
    4.5 文件存取许可权
    4.6 新文件和目录的所有权
    4.7 access函数 4.8 umask函数
    4.9 chmod 和fchomod函数
    4.10 粘住位
    4.11 chown, fchown和 lchown函数
    4.12 文件长度
    4.13 文件截短
    4.14 文件系统
    4.15 link, unlink, remove和 rename 函数
    4.16 符号连接
    4.17 symlink 和readlink函数
    4.18 文件的时间
    4.19 utime函数
    4.20 mkdir和 rmdir函数
    4.21 读目录
    4.22 chdir, fchdir和 getcwd函数
    4.23 特殊设备文件
    4.24 sync和 fsync函数
    4.25 文件存取许可权位小结
    4.26 小结 习题
    第5章 标准I/O库
    5.1 引言
    5.2 流和FILE对象
    5.3 标准输入、标准输出和标准出错
    5.4 缓存
    5.5 打开流
    5.6 读和写流
    5.7 每次一行I/O
    5.8 标准I/O的效率
    5.9 二进制I/O
    5.10 定位流
    5.11 格式化I/O
    5.12 实现细节
    5.13 临时文件
    5.14 标准I/O的替代软件
    5.15 小结 习题
    第6章 系统数据文件和信息
    6.1 引言
    6.2 口令文件
    6.3 阴影口令
    6.4 组文件
    6.5 添加组ID
    6.6 其他数据文件
    6.7 登录会计
    6.8 系统标识
    6.9 时间和日期例程
    6.10 小结 习题
    第7章 UNIX进程的环境
    7.1 引言
    7.2 main 函数
    7.3 进程终止
    7.3.1 exit和_exit函数
    7.3.2 atexit函数
    7.4 命令行参数
    7.5 环境表
    7.6 C程序的存储空间布局
    7.7 共享库
    7.8 存储器分配
    7.9 环境变量
    7.10 setjmp 和longjmp函数
    7.10.1 自动, 寄存器和易失变量
    7.10.2 自动变量的潜在问题
    7.11 getrlimit 和setrlimit函数
    7.12 小结 习题
    第8章 进程控制
    8.1 引言
    8.2 进程标识
    8.3 fork函数
    8.4 vfork 函数
    8.5 exit函数
    8.6 wait和waitpid函数
    8.7 wait3和 wait4函数
    8.8 竞态条件
    8.9 exec函数
    8.10 更改用户ID 和组ID
    8.10.1 setreuid 和setregid函数
    8.10.2 seteuid和 setegid函数
    8.10.3 组ID 8.11 解释器文件
    8.12 system函数
    8.13 进程会计
    8.14 用户标识
    8.15 进程时间
    8.16 小结 习题
    第9章 进程关系
    9.1 引言
    9.2 终端登录
    9.2.1 4.3+BSD终端登录
    9.2.2 SVR4终端登录
    9.3 网络登录
    9.3.1 4.3+BSD网络登录
    9.3.2 SVR4网络登录
    9.4 进程组
    9.5 对话期
    9.6 终端控制
    9.7 tcgetpgrp 和tcsetpgrp函数
    9.8 作业控制
    9.9 shell执行程序
    9.10 孤儿进程组
    9.11 4.3+BSD实现
    9.12 小结 习题
    第10章 信号
    10.1 引言
    10.2 信号的概念
    10.3 signal函数
    10.3.1 程序起动
    10.3.2 进程创建
    10.4 不可靠的信号
    10.5 中断的系统调用
    10.6 可再入函数
    10.7 SIGCLD语义
    10.8 可靠信号术语和语义
    10.9 kill 和raise函数
    10.10 alarm和 pause函数
    10.11 信号集
    10.12 sigprocmask 函数
    10.13 sigpending函数
    10.14 sigaction函数
    10.15 sigsetjmp 和siglongjmp函数
    10.16 sigsuspend函数
    10.17 abort函数
    10.18 system 函数
    10.19 sleep函数
    10.20 作业控制信号
    10.21 其他特征
    10.21.1 信号名字
    10.21.2 SVR4信号处理程序的附加参数
    10.21.3 4.3+BSD信号处理程序的附加参数
    10.22 小结 习题
    第11章 终端I/O
    11.1 引言
    11.2 综述
    11.3 特殊输入字符
    11.4 获得和设置终端属性
    11.5 终端选择标志
    11.6 stty命令
    11.7 波特率函数
    11.8 行控制函数
    11.9 终端标识
    11.10 规范方式
    11.11 非规范方式
    11.12 终端的窗口大小
    11.13 termcap, terminfo和 curses
    11.14 小结 习题
    第12章 高级I/O
    12.1 引言
    12.2 非阻塞I/O
    12.3 记录锁
    12.3.1 历史
    12.3.2 fcntl记录锁
    12.3.3 锁的隐含继承和释放
    12.3.4 4.3+BSD的实现
    12.3.5 建议性锁和强制性锁
    12.4 流 12.4.1 流消息
    12.4.2 putmsg和 putpmsg函数
    12.4.3 流ioct1操作
    12.4.4 write至流设备
    12.4.5 写方式
    12.4.6 getmsg和 getpmsg函数
    12.4.7 读方式
    12.5 I/O多路转接
    12.5.1 select函数
    12.5.2 poll函数
    12.6 异步I/O
    12.6.1 SVR4
    12.6.2 4.3+BSD
    12.7 readv和writev函数
    12.8 readn和 writen函数
    12.9 存储映射I/O
    12.10 小结 习题
    12.10 小结 习题
    第13章 精灵进程
    13.1 引言
    13.2 精灵进程的特征
    13.3 编程规则
    13.4 出错记录
    13.4.1 SVR4流log驱动程序
    13.4.2 4.3+BSD syslog设施
    13.5 客户机-服务器模型
    13.6 小结 习题
    第14章 进程间通信
    14.1 引言
    14.2 管道
    14.3 popen和 pclose函数
    14.4 协同进程
    14.5 FIFO
    14.6 系统V IPC
    14.6.1 标识符和关键字
    14.6.2 许可权结构
    14.6.3 结构限制
    14.6.4 优点和缺点
    14.7 消息队列
    14.8 信号量
    14.9 共享存储
    14.10 客户机-服务器属性
    14.11 小结 习题
    第15章 高级进程间通信
    15.1 引言
    15.2 流管道
    15.3 传送文件描述符
    15.3.1 SVR4
    15.3.2 4.3BSD
    15.3.3 4.3+BSD
    15.4 open服务器第1版
    15.5 客户机-服务器连接函数
    15.5.1 SVR4
    15.5.2 4.3+BSD
    15.6 open服务器第2版
    15.7 小结 习题
    第16章 数据库函数库
    16.1 引言
    16.2 历史
    16.3 函数库
    16.4 实现概述
    16.5 集中式或非集中式
    16.6 并发
    16.6.1 粗锁
    16.6.2 细锁
    16.7 源码
    16.8 性能
    16.8.1 单进程的结果
    16.8.2 多进程的结果
    16.9 小结 习题
    第17章 与Postscrīpt打印机通信
    17.1 引言
    17.2 Postscrīpt通信机制
    17.3 假脱机打印
    17.4 源码
    17.5 小结 习题
    第18章 调制解调器拨号器
    18.1 引言
    18.2 历史
    18.3 程序设计
    18.4 数据文件
    18.5 服务器设计
    18.6 服务器源码
    18.7 客户机设计
    18.7.1 终端行规程
    18.7.2 一个进程还是两个进程
    18.8 客户机源码
    18.9 小结 习题
    第19章 伪终端
    19.1 引言
    19.2 概述
    19.2.1 网络登录服务器
    19.2.2 scrīpt程序
    19.2.3 expect程序
    19.2.4 运行协同程序
    19.2.5 观看长时间运行程序的输出
    19.3 打开伪终端设备
    19.3.1 SVR4
    19.3.2 4.3+BSD
    19.4 pty_fork函数
    19.5 pty程序
    19.6 使用pty程序
    19.6.1 utmp文件
    19.6.2 作业控制交互
    19.6.3 检查长时间运行程序的输出
    19.6.4 scrīpt程序
    19.6.5 运行协同进程
    19.6.6 用交互模式驱动交互式程序
    19.7 其他特性
    19.7.1 打包模式
    19.7.2 远程模式
    19.7.3 窗口大小变化
    19.7.4 信号发生
    19.8 小结 习题

Open Toolbar