提问：紧急情况下压缩了测试周期应该怎么办？
　　回答：本期话题分几个要素点，我将根据命题划分的几个关键词：紧急情况，压缩，测试周期，来一起分析探讨。
　　项目中难免会碰到很多“紧急情况”，如：
　　1、需求变更
　　客户是善变的，我们必须伺候好客户，不是么？没有任何理由，他们要变更需求，一般情况下，最为乙方、丙方只有服从。
　　2、项目外包
　　很少有人碰到过吧？不过的确存在！项目进行到一半时由于自身团队或者高层决策、成本等方面上的要求，直接将项目外包出去，或者重新让一个项目团队接手。
　　3、开发设计架构存在明显严重缺陷
　　显然，架构师、项目经理等没有在前期做好评审和确认，但是很多项目，尤其是政府项目团队成员很随意，反正是有扶持款项。但这不是质量低下的理由！
　　4、不确定因素造成人员减少
　　如核心员工跳槽离职、女同事怀孕、家里生老病死等。
　　5、客户要求提前上线
　　在交付阶段，再次回到客户，他是老大，出钱的，给项目的！甲方要求提前项目上线，这不得不加快进度，不是么？
　　关键点把握——“压缩”
　　综合上述我列举的几个原因，在项目决策和进度上已经批复下来，我们必须得“压缩”进度安排。这里明显不存在沟通、协商的必要了，或者说与相关部门、人员沟通/协商无效了。
　　但是对于我们测试团队的“测试周期”，个人认为，有必要澄清或者继续不断与相关涉众进行沟通和协商！毕竟整个周期被砍，直接最大影响的是我们测试部门同事！
　　这里根据之前列举的5大理由，我会有侧重地整理下解决方案：
　　1、需求一旦变更，项目团队前面阶段也肯定有影响，开发需要重新设计编码，然后才是到测试阶段。由于需求变更是客户方提出的，我们有权利去交涉争取最长“测试周期”。这里作为测试经理必须和项目经理统一战线，和客户方达成共识。因项目后期客户自身提出的临时需求变成要求，本不在合约范围内，所以综合已有的项目计划和人员安排，在强制要求“压缩”进度、或者保证原有进度的情况下，个人认为必须给客户列举出详细的测试风险和影响要素。让客户方明确在进度被压缩的前提下，我们能保证的质量效果和最佳状态！知道风险是多方面必须一起承担的。
　　2、项目突然被外包给别人，有点不可思议！但是整个项目被第三方接手，这里的交接情况，主要是新项目组对需求的快速把握、理解，开发方对项目架构、设计及代码的熟悉都是不得不去考虑的。这样对于测试团对来说，只能延后开始执行测试时间点，那势必得把握测试要素的重点。个人建议按测试优先级、功能重要等级进行分类和划分，给客户方一个明确能保证质量的测试业务点清单。毕竟不可能在短时间项目被重新分包情况下，让测试团队控制什么进度来交付产品/项目。这个是整个项目进度的问题。
....
更多内容请查阅51Testing软件测试网
版权声明：本文由会员 土土的豆豆 首发于51Testing软件测试论坛每周一问活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

特大好消息！让大家期待了很久的2013中国软件测试现状调查报告发布啦！！这次的报告新增了很多新的问题和分析，力求给大家更加全面和客观的了解软件测试行业的现状，想要了解的朋友请点击网址http://www.51testing.com/html/84/n-863184.html 　　调查背景 　　我国的软件测试行业相对欧美国家，现在还是处于很年轻的阶段。借鉴美国等软件测试的历史发展经验，测试行业发展的前景还是乐观的。伴随着我国软件产业的蓬勃发展以及对软件质量的重视，软件测试也越来越被软件企业所重视，企业对软件测试从业人员的技能要求也逐步提高，这就要求测试人员要了解国内外被测技术发展历程，掌握目前软件测试行业最新的发展动态，运用新的测试技术、新的测试方法和新的测试工具，以满足不断前进的软件行业的要求，有效提高软件测试的效率和成果，确保软件测试的质量。 　　为了使大家更详细的了解2013年软件测试从业人员现状，从而帮助大家更清晰的认识、定位自我，规划职业发展，迎接更多的挑战，51Testing发起了2013年第七届中国软件测试现状调查活动，对测试从业人员现状及行业现状进行调查。 　　本次调查延续以往的惯例，根据07-12年的技术趋势和热点，对调查项进行了调整和增补，力求及时准确的反映07-12年中国软件测试从业人员的发展变化，帮助测试人员了解2013年软件测试从业人员现状，有针对性的提高自身的软件测试技术水平和管理水平，为相关的企业了解测试人员最全面、真实、有效的各项数据提供权威的参考依据。 　　本次调查历时三个多月，期间得到了广大会员广泛的关注和参与，总共收到有效答卷近两千余份。 　　调查目的 　　51Testing希望通过本次调查活动，帮助软件测试人员和企业了解2013年内软件测试从业人员的现状，帮助测试人员更好的认识和定位自我，规划职业发展；也可以为企业决策提供有力的数据支持。 　　调查报告内容 　　中国软件测试从业人员所在公司的基本属性 　　中国软件测试从业人员的基本属性

 　   在回答要不要做全才之前，我们应该先弄清楚一个问题，作为一个全才应该需要哪些能力？
　　我认为作为一个测试人员，应该具备四方面知识：测试基础，行业业务储备，测试工具和技术，测试管理能力和经验。
　　以上四方面也是测试人员晋升的参考，当然测试基础咱们都有就看储备了多少，其他三方面是咱们努力的方向。
　　测试基础是所有测试人员应该具备的，其他三项精于一项可以一招鲜，精于两项可以称之为高手，精于三项的话？我的天啦
　　行业业务知识，基本上可以说能够称为行业的，基本上其业务知识就不是一年两年可以弄清楚的，比如金融，ERP，供应链，游戏
　　测试工具和技术，精于测试的大两项（性能和自动化）就已经在这个行业可以很好了，还有安全测试，数据库，WEB测试甚至一些其他测试。技术是没有边界的，同时技术一直在发展。
　　测试管理能力和经验，以前认为做管理的要通才，都懂一些的人但可以不精。等后来PMP大行其道的时候，发现原来项目管理也有方法，将这些方法用熟工作自然就做好了。
　　现在，请问：亲爱的朋友，你想做全才吗？你还能做全才吗？
　　我的答案是，业务、技术，管理三大方面都要有所储备，不要因为自己对哪方面不擅长而放弃，这是咱们职业进阶的钱途，是钱途就没有放弃的想法。
　　说到现在，我想我支持的是全能型的全才这个观点，但这一次毕竟不是话题PK，所以我不需要明确的支持哪个观点。
　　据我多年的经验，一个人要完成全才这个战略目标，咱们这个行业也许还有，但肯定不多。
　　因为社会已经实现了高度分工与合作的特点，每一个人的工作限制了他主要应用的是某几方面的知识和技能。
　　如果被认为是万金油型的成员，要么就成为了公司的一把手人物（张小龙级别），要么就是角色不固定的团队拼图成员。
　　在NBA里面，万金油型的队员没有成为球队核心的，除了james，也没有能打五个位置还是球队核心的成员。
　　当今的主流文化告诉咱们，要成为团队的核心，要的是多能一专，用一专来取得团队的认可，用多能来黏合整个团队。
　　最后引用韩寒在《穿着棉袄洗澡》中的一段话作为结束语：如果现在这个时代能出全才，那便是应试教育的幸运和这个时代的不幸。如果有，他便是人中之王，可惜没有，所以我们只好把“全”字人下的“王”给拿掉。时代需要的只是人才。
　　原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
　　版权声明：本文由会员 千里 首发于51Testing软件测试论坛每周一问活动。

　　安全性测试都有什么？简单的就包括跳过权限验证啊，修改提交信息啊，复杂的呢，就有sql盲注、跨站点脚本等等。这些咱们暂时不一一细表，只说说我们为什么要进行安全性测试。、
　　其实网上关于安全性测试的资料并不是非常多，即使有人关注已只是很浅显的谈到部门安全性因素。当然，据我了解部分大公司都有自己的安全性测试团队，这部分工作并不由测试人员进行。
　　胡扯了两句，今天我们来聊聊为什么进行安全性测试，或者说，安全性到底会引起哪些问题、后果。
　　第一，提到安全。我们一个产品一个网站最需要加强安全防范的就是数据库。那么如果缺少了安全性测试，在高手的sql盲注下，你的数据库就会逐步展现在黑客的面前，无论是数据库类型、表结构、字段名或是详细的用户信息，都有无数种手段可以让人“一览无余”。
　　第二，就是权限。网站一般都规定了什么样的用户可以做什么事。比如版主可以修改所有人的帖子，而你普通用户只能编辑自己的帖子，同样游客只能看大家的帖子。这就是简单的权限。如果少了安全性保证，那么就容易有人跳出权限做他不该做的事情。
　　简单举个小例子，一个登录模块，让你输入用户名密码。我们会老老实实的输入我们的用户名密码，比如“风落几番”-“password”。如果我们刻意的去绕过登录认证呢？
　　猜想一下这个sql，单说用户名，开发人员很可能会这样去数据库里对比：
　　Select count(id) from sys_user where username=‘XXX’
　　当然可能更复杂，咱们就用这个说。如果我们在输入框里输入一段特殊的字符会如何？
　　’or‘1=1
　　这是段神奇的字符，因为这样这个sql就变成：
　　Select count(id) from sys_user where username=‘’or‘1=1’
　　好吧，我们就跳过了用户名的验证。。。
　　说的好基础和无聊的感觉，其实这就是安全性的一部分。
   接着说第三，就是修改提交数据信息。曾经我们公司做过一个关于在线支付的商城，在安全性测试过程中，我发现通过抓包抓到的提交价格，经过修改再发包可以通过。简单来说就是本来100块钱买的东西，我抓包修改为1块就能成功购买。这就成为了一个巨大的隐患。
　　再说第四，类似跨站脚本的安全隐患。这方面网上资料很多，具体过程呢就像这样：
　　1.HTML注入。所有HTML注入范例只是注入一个JavaScript弹出式的警告框：alert(1)。
　　2.做坏事。如果您觉得警告框还不够刺激，当受害者点击了一个被注入了HTML代码的页面链接时攻击者能作的各种的恶意事情。
　　3.诱捕受害者，可能会redirect到另一个钓鱼网站之类的，使其蒙受损失。

UI自动化测试，首要考虑的是我们所选用的测试工具或框架对测试程序的支持如何。而这个支持，则主要是通过对控件的识别和操作来体现的；但是，不管一个测试工具或者框架对测试程序的支持程序如何，它执行测试程序时最终都是以屏幕的绝对坐标来定位执行的，尽管我们平时都能听到很多人在说，尽量避免用坐标。
　　尽量避免用坐标和最终通过坐标来识别，这个看起来有点冲突，但是却又不会冲突，是不是有点类似太极的感觉了。
　　坐标，通常分为两类：绝对坐标和相对坐标。
　　1. 通常我们所说的坐标都是基于屏幕左上角的绝对坐标。测试工具和我们人的操作最终也都是通过这个坐标来进行测试程序操作的，只不过有的我们知道，有的我们不知道，仅此而已。
　　通俗的讲：我们人手动来点击屏幕的时候，只是在点击的位置<x,y>发送一个屏幕点击事件，这个屏幕点击事件通过windows库定位到当前活动的窗体，再对这个窗体的一个具体位置传递点击事件，从而获得响应。这个过程，在我们的感官和需求中，我们只需要直接对活动窗体的进行操作的结果，至于定位，who care？
　　自动化测试本质上就是来模拟人的行为的操作，所以实现过程大致类似。它首先通过我们在代码中编写的id、text、index、class等来定位到我们要操作的控件，然后再读取这个控件的x、y属性来发送点击事件。但是，在使用层面，我们只看到了通过id来点击，至于其他获取坐标这些，leave them alone。
　　2. 说到相对坐标，这个就稍微有点复杂。目前已知的相对方式有相对左上、左下、右上、右下、中上、中下、居中；并且根据是否随着父窗口变化而变化，又可分类为：不扩展、同步扩展(和父窗口一起放大/缩小)、按比例扩展(父窗口扩大3倍，该对象也扩大3倍)。
　　举个例子来说，屏幕上有一个记事本窗口“记事本.txt”，它的坐标绝对坐标是400,600，这个记事本的开始菜单栏，它的坐标是450,700。如果假设记事本窗口的坐标为<x,y>，那么这个开始菜单栏就可以描述为：相对于窗口"记事本.txt"的坐标为50,100，绝对坐标就可以表示为<x+50,y+100>；再假设菜单栏中的编辑按钮绝对坐标为500,700，那么它就可以描述为：相对于菜单栏的坐标为50,0，绝对坐标就可以表示为<x+50+50,y+100+0>。这样的话，这个窗口上的所有坐标就都可以用一个坐标来维护了，如果窗口位置发生变化，我们也只需要修改一个最上层父窗口的坐标就可以动态适配所有按钮的坐标了。
　　上面就是相对的解释。其实说白了，所谓相对坐标，就是一种优化的坐标计算方式，可以让我们用尽量少的改动去适应更多的变化。
　　至于它的相对方式和扩展方式，则就只是其中的一些计算方式，在这里就不一一举例了。
　　那么，了解了上面的这些，我们可以做些什么呢？
　　平时在开展自动化测试时，总是会遇到一些不能识别的自定义控件，尤其是app类型程序。那么这时候我们就可以通过上面的坐标适配来完善解决一下。
　　下面，我来简单说一个基于坐标的控件识别的简单实现思路：
　　1. 实现思想：通过虚拟截图的方式来提供一个快速定位虚拟控件的坐标系，并对齐赋予一些额外的识别参数；嵌入到其他测试工具中直接使用。
　　2. 首先，通过调用windows api或者其他截图程序，对测试程序的全窗口截一个半透明的截图（可以按比例缩放）；
　　然后，获取测试程序的坐标，并监控这个截图上的拖拽事件来计算控件的坐标系，并写入xml文件；
　　其次，将这个xml文件导入到测试工具的对象库中进行使用。这里需要注意，有的测试工具不支持外部自定义对象，所以需要做一些转换。
　　3. 代码：以后再传吧。这块东西最好做成可视化的，比较易于操作

今天是2011年的第一天，2010年就这样匆匆忙忙，紧紧张张地过去了。这一年里来来去去，变化最大的就是很多一起工作了多年的同事离开了，很多都去了"更给力”的地方，呵呵!公司里来来往往是很正常的，想想我最近一次换到“更给力”的地方，那都是5年前了。总之，现在的地方还是挺给力的，好好工作，争取2011年有更大的进步，呱唧呱唧!
　　测试用例设计的最基本要求：覆盖住所要测试的功能。这是再基本不过的要求了，但别看只是简单的一句话，要能够达到切实覆盖全面，需要对被测试产品功能的全面了解、明确测试范围(特别是要明确哪些是不需要测试的)、具备基本的测试技术(如：等价类划分等)等。那么满足了上述这条要求是不是设计出来的测试用例就是好的测试用例了呢?答案：在理论上是，但在实际工程中还远远不是。之所以理论和实际会有这样的差别，是因为在理论上不要考虑的东东，而在实际工程中是不得不考虑的 - 成本。这里的成本包括：测试计划成本、测试执行成本、自动化测试用例、测试自动化成本，测试分析成本，以及测试实现技术局限、测试环境的Bug、人为因素和不可预测的随机因素等引入的附加成本等。
　　由于成本因素的介入，决定了工程中设计好的测试用例原则不只有“覆盖住所要测试的功能”这一条，下面是我根据自己的工作经验总结出的其它四条原则，在这里抛砖引玉，希望大家拍砖和指正。这些原则特别是针对那些需要被自动化，并且是要被经常执行的测试用例。
　　1. 单个用例覆盖最小化原则。
　　这条原则是所有这四条原则中的”老大“，也是在工程中最容易被忘记和忽略的，它或多或少的都影响到其它几条原则。下面举个例子来介绍，假如要测试一个功能 A，它有三个子功能点 A1，A2 和 A3，可以有下面两种方法来设计测试用例：
　　方法1 ：用一个测试用例覆盖三个子功能 -Test_A1_A2_A3，
　　方法2 ：用三个单独的用例分别来覆盖三个子功能 - Test_A1，Test_A2，Test_A3
　　方法1适用于规模较小的工程，但凡是稍微有点儿规模和质量要求的项目，方法2则是更好的选择，因为它具有如下的优点：
　　测试用例的覆盖边界定义更清晰
　　测试结果对产品问题的指向性更强
　　测试用例间的耦合度最低，彼此之间的干扰也就越低
　　上述这些优点所能带来直接好处是，测试用例的调试、分析和维护成本最低。每个测试用例应该尽可能的简单，只验证你所要验证的内容，不要“搂草打兔子”捎带着把啥啥啥啥都带进来，这样只会增加测试执行阶段的负担和风险。David Astels在他的著作《Test Driven Development：A Practical Guide》曾这样描述，最好一个测试用例只有一个Assert语句。此外，覆盖功能点简单明确的测试用例，也便于组合生成新的测试，在Visual Studio中就引入了Ordered Test的概念。
　　2. 测试用例替代产品文档功能原则。
　　通常我们会在开发的初期(Scrum每个Sprint的头两天)用Word文档或者OneNote的记录产品的需求、功能描述、以及当前所能确定的任何细节等信息，勾勒将要实现功能的样貌，便于团队进行交流和细化，并在团队内达成对产品功能共识。假设我们在此时达成共识后，描述出来的功能为A，随着产品开发深入，团队会对产品的功能有更新的认识，产品功能也会被更具体细化，在一个迭代或者Sprint结束的时候最终实现的功能很可能是A+。如此往复，在不断倾听和吸收用户的反馈，修改产品功能，多个迭代过后，原本被描述为A的功能很可能最终变为了Z。这是时候再去看曾经的Word文档和OneNote页面，却仍然记录的是A。之所以会这样，是因为很少有人会去(以及能够去)不断更新那些文档，以准确反映出产品功能当前的准确状态。不是不想去做，而是实在很难!这里需要注意：早期的Word或者OneNote的文档还是必要的，它至少能保证在迭代初期团队对要实现功能有一致和准确的认识。

最近，某著名信息安全公司发布了一个更新补丁，导致用户的密钥管理软件无法正常工作，应该从类似的问题中学习到怎样的教训呢?评论家Andrew Binstock撰文强调了回归测试的重要性!
　　有关问题的背景，Andrew做了相应的介绍：
　　在我看来，不使用一个全面的回归测试集合是错误的。这种错误将导致正如卡巴斯基——这家消费者导向的安全软件公司(提供反病毒，反恶意软件)——所面临的尴尬局面。卡巴斯基的一款产品是供用户存放安全密钥的密钥安全软件。当用户需要使用一个密钥时，用户通过密钥安全软件的密码打开软件，复制/粘贴要使用的密钥。其要使用的密钥会显示为一组圆点。完成操作后，他们关闭安全软件然后继续他们的工作。通过一个简单的列表，用户就可以添加新的密钥。这个列表还非常明智地添加了密钥有效期限。用户也可以将选择“从不设定有效期限”。
　　下面我将仔细说明。更新的结果是所以的密钥都突然过期，而且修改有效期的按钮失效。我并不知道卡巴斯基是怎么开发软件的。尽管如此，我们不难从这些现象推断出一些信息。
　　Andrew强调了测试的重要性：
　　和很多人一样，我一直以来很欣赏“Uncle Bob”Martin的部分观点。尽管我不赞同他的一些观点(有时是强烈不赞同)，但我从来没有质疑过的他一直强调的这一点：没有测试的提交代码方式是不正确的。我并不是在推崇Martin的大解决方案(测试驱动开发)，而是强调他基本立场的正确性。老实说，Martin即不是唯一的、也不是第一个提出测试与提交代码同步的重要性的人。Kent Beck、Michael Feathers等许多持续集成和DevOps的倡导者们，一直以来都持有这个观点。但是Martin孜孜不倦的倡导这个观点。并且正是由于他的推动努力，很多勤奋的开发人员今天本能地理解了写完代码后立即进行测试的重要性。
　　测试已经成为开发工作的重要部分。Andrew认为，以至于当开发者没有进行测试时，人们会认为开发者又陷入了老的工作模式或者指责开发者草率行事，对自己的代码毫不关心。直到几年前，我们还可以说可以不用对开发者编写的代码进行测试，就能成功地把人类送到月球上。当时，大部分人都认为自己可以不进行测试就完成出色的代码。直到今天，还都需要面对这个重要的问题：他们如何知道自己对代码的修改不会影响到现存代码的正常运行?测试的作用——作为整个代码的传感器和监视器——是对进行测试工作的必要性的最有力的论证。
　　对于该信息安全公司的问题，Andrew分析道：
　　卡巴斯基公司肯定没有进行回归测试，否则它将不会遇到这个问题。这个问题发生在Windows 7的机器上——我的朋友告诉我这个问题发生在普通的Window 7家庭机上(家庭机的主要运行的程序是Office、Outlook和IE浏览器)。评论说很多Window 7的电脑都遇到了这个问题。考虑到Windows 7是当下最流行的操作系统，卡巴斯基公司肯定没有针对这款系统进行测试。
　　还有另外一条线索说明测试工作没有进行或者至少进行的不充分：这款软件里被标明“从不设定有效期限”的密钥突然显示为过期状态，而且其到期日期变为1601年。
　　Andrew认为，这个日期非常麻烦。在测试中，了解程序的不变量十分有用。不变量是程序中不管程序处于什么状态，总为真的一些东西。不变量是程序中丰富的“静脉”，我们在回归测试集合中要充分利用它们。在这个程序中，我们可以知道它的一个不变量是任何软件的到期日期都不能早于软件发布日期。打个比方，如果说卡巴斯基是在2011年7月1日第一次发布的这个软件，那么所有用户的密钥的截止日期就不会早于这个日期。这就是一个不变量——任何密钥的截止日期不能早于2011年7月1日。如果密钥的截止日期早于这个日期，那就说明程序有错误。而现在程序中出现1601年这个日期，这说明测试工作不足或设计工作很差。也就是说,使用无效的日期作为使用的数据，如一个错误代码。这种重用数据字段来代表一个完全陌生的数据项的做法是很可怕的。这种做法在磁盘空间和内存都很昂贵的时代非常流行。标志位的字节常常被重载来表示独特的信号或者罕见的条件。如今在资源受限制的嵌入式系统中我们依旧可以见到这种做法，那是因为现在还没有更好的做法来替代这种做法。不过对于桌面程序，这是一个严重的问题。首先，你会给正在试图解决一些困惑问题的用户带来新的令人困惑。其实，你会让不变量不稳定。现在，针对不变量的测试必须测试所有合法的异常值——一个常数的维护问题作为新的误差值被添加到这个重载的字段。相反，错误常常被他们自身的领域和诊断所标明。这保证了测试的完整性，代码的清晰、可读性。关于后者，想想那些测试错日期、翻译错日期的代码。当你在你是用的应用程序中看到这些问题是你会怎么想?
　　我朋友现在明智的思考她是否应该更换一款安全软件，用一款从不会锁住她的密钥的软件。如果你不充分测试你的软件(从开发者测试开始进行——开发者测试将在产品发布前早早发现问题)，你可能会遇到大麻烦。

含有abstract修饰符的class 即为抽象类，abstract类不能创建实例对象，含有abstract的方法的类必须定义为abstract class ，abstract class 里的方法不必是抽象的，抽象类中定义抽象方法必须放在具体子类中实现，所以呀，不能有抽象的构造方法或抽象的静态方法，如果子类没有实现抽象父类中的所有 方法，那么，子类也必须定义为抽象类。
　　接口（interface）可以说成是抽象类的特例。接口中的所有方法都必须是抽象的，接口中的方法定义默认为public abstract 。接口中的变量是全局常量，即public static final修饰的。 看一下他们在语法上的区别吧！
　　1，抽象类里可以有构造方法，而接口内不能有构造方法。
　　2，抽象类中可以有普通成员变量，而接口中不能有普通成员变量。
　　3，抽象类中可以包含非抽象的普通方法，而接口中所有的方法必须是抽象的，不能有非抽象的普通方法。
　　4，抽象类中的抽象方法的访问类型可以是public ，protected和默认类型，但接口中的抽象方法只能是public类型的，并且默认即为public abstract类型。
　　5，抽象类中可以包含静态方法，接口内不能包含静态方法。
　　6，抽象类和接口中都可以包含静态成员变量，抽象类中的静态成员变量的访问类型可以任意，但接口中定义的变量只能是public static类型，并且默认为public static类型。
　　7，一个类可以实现多个接口，但只能继承一个抽象类。再补充点两者在应用上的区别： 接口更多的是在系统框架设计方法发挥作用，主要定义模块之间的通信，而抽象类在代码实现方面发挥作用，可以实现代码的重用

　　何为嵌入式系统？

　　嵌入式系统是指操作系统和功能软件集成于计算机硬件系统之中。简单的说就是系统的应用软件与系统的硬件一体化，类似与BIOS的工作方式。具有软件代码小，高度自动化，响应速度快等特点。特别适合于要求实时的和多任务的体系。

　　嵌入式实时多任务操作系统

　　实时多任务操作系统（RealTimeOperatingSystem）是根据操作系统的工作特性而言的。实时是指物理进程的真实时间。实时操作系统是指具有实时性，能支持实时控制系统工作的操作系统。首要任务是调度一切可利用的资源完成实时控制任务，其次才着眼于提高计算机系统的使用效率，重要特点是要满足对时间的限制和要求。

　　实时多任务操作系统与分时多任务操作系统

　　它们有明显的区别。具体的说，对于分时操作系统，软件的执行在时间上的要求，并不严格，时间上的错误，一般不会造成灾难性的后果。而对于实时操作系统，主要任务是对事件进行实时的处理，虽然事件可能在无法预知的时刻到达，但是软件上必须在事件发生时能够在严格的时限内作出响应（系统响应时间），即使是在尖峰负荷下，也应如此，系统时间响应的超时就意味着致命的失败。另外，实时操作系统的重要特点是具有系统的可确定性，即系统能对运行情况的最好和最坏等的情况能做出精确的估计。

　　实时操作系统中的重要概念

　　系统响应时间(Systemresponsetime)系统发出处理要求到系统给出应答信号的时间。

　　任务换道时间(Context-switchingtime)是任务之间切换而使用的时间。

　　中断延迟(Interruptlatency)是计算机接收到中断信号到操作系统作出响应，并完成换道转入中断服务程序的时间。

　　实时操作系统应具有如下的功能：

　　1)任务管理（多任务和基于优先级的任务调度）

　　2)任务间同步和通信（信号量和邮箱等）

　　3)存储器优化管理（含ROM的管理）

　　4)实时时钟服务

　　5)中断管理服务

　　实时操作系统的工作特性

　　实时操作系统中的任务(Task)等同于分时操作系统中的进程(Process)的概念。系统中的任务有四种状态：运行(Executing)，就绪(Ready)，挂起(Suspended)，冬眠(Dormant)。

　　运行:获得CPU控制权。

　　就绪:进入任务等待队列。通过调度转为运行状态。

　　挂起:任务发生阻塞，移出任务等待队列，等待系统实时事件的发生而唤醒。从而转为就绪或运行。

　　冬眠:任务完成或错误等原因被清除的任务。也可以认为是系统中不存在了的任务。

　　系统中只能有一个任务在运行状态。各任务按级别通过时间片分别获得对CPU的访问权。

        本文转载至51testing软件测试网