本文最初发表于赖勇浩（恋花蝶）的博客：
http://blog.csdn.net/lanphaday，如蒙转载，必须保留全文完整，未经本人同意，不得用于商业目的。
简明 Python 编程规范编码 所有的 Python 脚本文件都应在文件头标上 # -*- coding:utf-8 -*- 。设置编辑器，默认保存为 utf-8 格式。
注释 业界普遍认同 Python 的注释分为两种的概念，一种是由 # 开头的“真正的”注释，另一种是 docstrings。前者表明为何选择当前实现以及这种实现的原理和难点，后者表明如何使用这个包、模块、类、函数（方法），甚至包括使用示例和单元测试。
坚持适当注释原则。对不存在技术难点的代码坚持不注释，对存在技术难点的代码必须注释。但与注释不同，推荐对每一个包、模块、类、函数（方法）写 docstrings，除非代码一目了然，非常简单。
缩进 Python 依赖缩进来确定代码块的层次，行首空白符主要有两种：tab 和空格，但严禁两者混用。如果使用 tab 缩进，设定 tab 为 4 个空格。
公司内部推荐使用 4 个空格的 tab 进行缩进。
空格 空格在 Python 代码中是有意义的，因为 Python 的语法依赖于缩进，在行首的空格称为前导空格。在这一节不讨论前导空格相关的内容，只讨论非前导空格。非前导空格在 Python 代码中没有意义，但适当地加入非前导空格可以增进代码的可读性。
1） 在二元算术、逻辑运算符前后加空格：如 a = b + c；
2） 在一元前缀运算符后不加空格，如 if !flg: pass；
3） “:”用在行尾时前后皆不加空格，如分枝、循环、函数和类定义语言；用在非行尾时两端加空格，如 dict 对象的定义 d = {‘key’ : ’value’}。
4） 括号（含圆括号、方括号和花括号）前后不加空格，如 do_something(arg1, arg2)，而不是 do_something( arg1, arg2 )；
5） 逗号后面加一个空格，前面不加空格；s
空行 适当的空行有利于增加代码的可读性，加空行可以参考如下几个准则：
1） 在类、函数的定义间加空行；
2） 在 import 不同种类的模块间加工行；
3） 在函数中的逻辑段落间加空行，即把相关的代码紧凑写在一起，作为一个逻辑段落，段落间以空行分隔；
断行 尽管现在的宽屏显示器已经可以单屏显示超过 256 列字符，但本规范仍然坚持行的最大长度不得超过 78 个字符的标准。折叠长行的方法有以下几种方法：
1) 为长变量名换一个短名，如：
this.is.a.very.long.variable_name = this.is.another.long.variable_name
应改为：
variable_name1 = this.is.a.very.long.variable_name
variable_name2 = this.is.another.variable_name
variable_name1 = variable_name2s
2) 在括号（包括圆括号、方括号和花括号）内换行，如：
class Edit(CBase):
def __init__(self, parent, width,
font = FONT, color = BLACK, pos = POS, style = 0):
或：
very_very_very_long_variable_name = Edit(parent, \
width, \
font, \
color, \
pos)
如果行长到连第一个括号内的参数都放不下，则每个元素都单独占一行：
very_very_very_long_variable_name = ui.widgets.Edit( \
panrent, \
width, \
font, \
color, \
pos)
3) 在长行加入续行符强行断行，断行的位置应在操作符前，且换行后多一个缩进，以使维护人员看代码的时候看到代码行首即可判定这里存在换行，如：
if color == WHITE or color == BLACK \
or color == BLUE: # 注意 or 操作符在新行的行首而不是旧行的行尾
do_something(color);
命名 一致的命名可以给开发人员减少许多麻烦，而恰如其分的命名则可以大幅提高代码的可读性，降低维护成本。
常量 常量名所有字母大写，由下划线连接各个单词，如
WHITE = 0XFFFFFF
THIS_IS_A_CONSTANT = 1
变量 变量名全部小写，由下划线连接各个单词，如
color = WHITE
this_is_a_variable = 1
不论是类成员变量还是全局变量，均不使用 m 或 g 前缀。私有类成员使用单一下划线前缀标识，多定义公开成员，少定义私有成员。
变量名不应带有类型信息，因为 Python 是动态类型语言。如 iValue、names_list、dict_obj 等都是不好的命名。
函数 函数名的命名规则与变量名相同。
类 类名单词首字母大写，不使用下划线连接单词，也不加入 C、T 等前缀。如：
class ThisIsAClass(object):
passs
模块 模块名全部小写，对于包内使用的模块，可以加一个下划线前缀，如
module.py
_internal_module.py
包 包的命名规范与模块相同。
缩写 命名应当尽量使用全拼写的单词，缩写的情况有如下两种：
1） 常用的缩写，如 XML、ID等，在命名时也应只大写首字母，如
class XmlParser(object):pass
2） 命名中含有长单词，对某个单词进行缩写。这时应使用约定成俗的缩写方式，如去除元音、包含辅音的首字符等方式，例如：
function 缩写为 fn
text 缩写为 txt
object 缩写为 obj
count 缩写为 cnt
number 缩写为 num，等。
特定命名方式 主要是指 __xxx__ 形式的系统保留字命名法。项目中也可以使用这种命名，它的意义在于这种形式的变量是只读的，这种形式的类成员函数尽量不要重载。如
class Base(object):
def __init__(self, id, parent = None):
self.__id__ = id
self.__parent__ = parent
def __message__(self, msgid):
# …略
其中 __id__、__parent__ 和 __message__ 都采用了系统保留字命名法。
语句import import 语句有以下几个原则需要遵守：
1） import 的次序，先 import Python 内置模块，再 import 第三方模块，最后 import 自己开发的项目中的其它模块；这几种模块中用空行分隔开来。
2） 一条 import 语句 import 一个模块。
3） 当从模块中 import 多个对象且超过一行时，使用如下断行法（此语法 py2.5 以上版本才支持）：
from module import (obj1, obj2, obj3, obj4,
obj5, obj6)
4） 不要使用 from module import *，除非是 import 常量定义模块或其它你确保不会出现命名空间冲突的模块。
赋值 对于赋值语言，主要是不要做无谓的对齐，如：
a = 1 # 这是一个行注释
variable = 2 # 另一个行注释
fn = callback_function # 还是行注释
没有必要做这种对齐，原因有两点：一是这种对齐会打乱编程时的注意力，大脑要同时处理两件事（编程和对齐）；二是以后阅读和维护都很困难，因为人眼的横向视野很窄，把三个字段看成一行很困难，而且维护时要增加一个更长的变量名也会破坏对齐。直接这样写为佳：
a = 1 # 这是一个行注释
variable = 2 # 另一个行注释
fn = callback_function # 还是行注释
分枝和循环 对于分枝和循环，有如下几点需要注意的：
1) 不要写成一行，如：
if !flg: pass 和 for i in xrange(10): print i都不是好代码，应写成
if !flg:
pass
for i in xrange(10):
print i
注：本文档中出现写成一行的例子是因为排版的原因，不得作为编码中不断行的依据。
2) 条件表达式的编写应该足够 pythonic，如以下形式的条件表达式是拙劣的：
if len(alist) != 0: do_something()
if alist != []: do_something()
if s != “”: do_something()
if var != None: do_something()
if var != False: do_something()
上面的语句应该写成：
if seq: do_somethin() # 注意，这里命名也更改了
if var: do_something()
3) 用得着的时候多使用循环语句的 else 分句，以简化代码。
已有代码 对于项目中已有的代码，可能因为历史遗留原因不符合本规范，应当看作可以容忍的特例，允许存在；但不应在新的代码中延续旧的风格。
对于第三方模块，可能不符合本规范，也应看作可以容忍的特例，允许存在；但不应在新的代码中使用第三方模块的风格。
tab 与空格混用的缩进是不可容忍的，在运行项目时应使用 –t 或 –tt 选项排查这种可能性存在。出现混用的情况时，如果是公司开发的基础类库代码，应当通知类库维护人员修改；第三方模块则可以通过提交 patch 等方式敦促开发者修正问题。
已有风格 开发人员往往在加入项目之前已经形成自有的编码风格，加入项目后应以本规范为准编写代码。特别是匈牙利命名法，因为带有类型信息，并不适合 Python 编程，不应在 Python 项目中应用。
请选择国家或地区...
| 中国China |
+86 |
|
| 中国香港China Hong Kong |
+852 |
|
| 中国澳门China Macao |
+853 |
|
| 中国台湾China Taiwan |
+886 |
|
| 阿尔巴尼亚Albania |
+355 |
|
| 阿尔及利亚Algeria |
+213 |
|
| 阿富汗Afghanistan |
+93 |
|
| 阿根廷Argentina |
+54 |
|
| 阿拉伯联合酋长国United Arab Emirates |
+971 |
|
| 阿塞拜疆Azerbaijan |
+994 |
|
| 埃及Egypt |
+20 |
|
| 埃塞俄比亚Ethiopia |
+251 |
|
| 爱尔兰Ireland |
+353 |
|
| 爱沙尼亚Estonia |
+372 |
|
| 安道尔共和国Andorra |
+376 |
|
| 安哥拉Angola |
+244 |
|
| 安圭拉岛Anguilla |
+1264 |
|
| 安提瓜和巴布达Antigua and Barbuda |
+1268 |
|
| 奥地利Austria |
+43 |
|
| 澳大利亚Australia |
+61 |
|
| 巴巴多斯Barbados |
+1246 |
|
| 巴布亚新几内亚Papua New Cuinea |
+675 |
|
| 巴哈马Bahamas |
+1242 |
|
| 巴基斯坦Pakistan |
+92 |
|
| 巴拉圭Paraguay |
+595 |
|
| 巴林Bahrain |
+973 |
|
| 巴拿马Panama |
+507 |
|
| 巴西Brazil |
+55 |
|
| 白俄罗斯Belarus |
+375 |
|
| 百慕大群岛Bermuda Is. |
+1441 |
|
| 保加利亚Bulgaria |
+359 |
|
| 贝宁Benin |
+229 |
|
| 比利时Belgium |
+32 |
|
| 冰岛Iceland |
+354 |
|
| 波多黎各Puerto Rico |
+1787 |
|
| 波兰Poland |
+48 |
|
| 玻利维亚Bolivia |
+591 |
|
| 伯利兹Belize |
+501 |
|
| 布基纳法索Burkina-faso |
+226 |
|
| 布隆迪Burundi |
+257 |
|
| 朝鲜North Korea |
+850 |
|
| 丹麦Denmark |
+45 |
|
| 德国Germany |
+49 |
|
| 多哥Togo |
+228 |
|
| 多米尼加共和国Dominica Rep. |
+1890 |
|
| 俄罗斯Russia |
+7 |
|
| 厄瓜多尔Ecuador |
+593 |
|
| 法国France |
+33 |
|
| 法属玻利尼西亚French Polynesia |
+689 |
|
| 法属圭亚那French Guiana |
+594 |
|
| 菲律宾Philippines |
+63 |
|
| 斐济Fiji |
+679 |
|
| 芬兰Finland |
+358 |
|
| 冈比亚Gambia |
+220 |
|
| 刚果Congo |
+242 |
|
| 哥伦比亚Colombia |
+57 |
|
| 哥斯达黎加Costa Rica |
+506 |
|
| 格林纳达Grenada |
+1473 |
|
| 古巴Cuba |
+53 |
|
| 关岛Guam |
+1671 |
|
| 圭亚那Guyana |
+592 |
|
| 海地Haiti |
+509 |
|
| 韩国Korea |
+82 |
|
| 荷兰Netherlands |
+31 |
|
| 荷属安的列斯Netheriands Antilles |
+599 |
|
| 洪都拉斯Honduras |
+5
查看(1026)
评论(0)
收藏
分享
管理
2009-01-29 13:55:44
转载地址：http://vipnews.csdn.net/newscontent.aspx?pointid=2008_12_09_165929685
本文以一个工作流测试项目为例， 总结了在测试过程中积累的经验，探讨了目前国内软件开发企业在软件测试过程中遇到的问题以及解决的方法。测试项目背景和实施情况工作流在某公司软件产品线中占有重要地位，XXX5.2
Workflow项目是5系列中的一个小版本，主要增加了任务代办、任务代理、以及任务交接等功能，同时还修复了一些易用性和功能性的Bug。下面，我们大概介绍一下这个项目的实施情况：
● 项目规模与测试人员配置：
○ 项目代码行数：5万行
○ 开发人员配置：开发人员5名、实习生1名
○ 测试人员配置：测试设计人员1名、测试执行人员2名、实习生1名
● 项目测试时的系统部署情况:
● 测试预期与测试执行情况整个测试项目是比较成功的，项目的时间执行情况和预期的测试指标度量都比较接近。发现Bug总数和缺陷密度都达到了要求的标准。当然，测试周期的实际值比计划值晚了两周，原?因是在系统测试后期，为了满足PSO部门提出的定时器需求造成了一定的延期。回顾整个项目的测试过程，我有几点小小的感悟，愿在此和大家一起分享。
测试如何尽早介入
基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格按照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和（很多测试人员无所事事），而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点地工作。但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：
● 测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。
● 测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。那么，在这个XXX5.2 Workflow项目中我们是怎么做的呢？实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：
● 评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求是测试设计的基础。
● 在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案是测试用例的保证。
● 和项目团队中的集成组和开发组协?商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
● 开发人员每天下午4：30之前提交所有可编译的代码，每天晚上进行日编译；
● 开发经理根据版本稳定情况，每周提交测试申请单。
● 测试人员根据测试进度需要，提取测试版本。
● 提前准备测试环境，包括数据库环境，操作系统和web应用服务器，以及复杂集群环境。
● 如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。根据产品的成熟度调整测试策略开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug数最多）。在这个XXX5.2 Workflow项目过程中，我们合理制定了不同阶段的测试策略，收到了很好的效果。
产品开发期同情的测试
要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行穷兵黩武式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。另一方面，测试工作不应停滞，特别是不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要告诉测试执行人员：
● 这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员只会发现简单的Bug。
● 换位思考，了解此时开发人员最关心的是功能是否能正确运行，多对基本功能进行测试。
产品成熟期积极的测试
随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序人员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。
产品稳定期多样的测试
在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。为什么？因为此时必须测试得更加深入，才能发现更深层次的Bug，于是多样性的测试、探索式的测试必不可少。产品发布期谨慎的测试在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。测试经理应知人善任为了保证测试工作的质量，首当其冲地就是应该有专业的测试团队。在很多小的软件项目中，往往没有专门的测试团队。这样一来，到了代码基本完成之时，就只能从客户支持部门或研发部门抽调一些人手临时拼凑出“测试团队”进行几周的测试工作，测试质量难以保证。我们则会尽早规划测试团队的人员结构，完善测试团队的配置。每个测试人员的特点和强项常常不尽相同，例如，擅长测试数据质量的测试员，未必能胜任系统环境配置复杂的测试任务。总之，对测试经经理而言，做到知人善任非常重要。同时，在项目测试过程中及时进行调整有时也很必要。此次测试的工作流系统，要求测试人员不仅应掌握一定的工作流业务知识，还需要有较强的逻辑思维能力。而在此项目测试过程中，笔者发现一位测试人员对功能的细节过分关注，而对整个工作流程总是理解不到位。显然，其设计出的测试用例不能适应工作流测试的要求。于是，立即进行人员分工和测试任务的调整，保证了测试工作顺利进行。坚持立场，规范流程我们公司有严格的测试流程，所有提交测试的软件版本，在提交之前，都要完成必需的冒烟测试（Smoking Test）。冒烟测试是一种测试包，其目标是检查版本的基本功能。这个测试包是由测试人员根据测试用例中级别为“基本”的测试用例抽取出来的，如果该版本没有通过冒烟测试，则就可以说明该版本不太稳定，不值得提交测试人员进行系统测试。有的公司冒烟测试是由测试人员手工或者自动测试。在我们这个项目中，为了保证每个可测试版本的冒烟测试质量，是由开发人员负责完成的。他们知道，如果程序不能通过冒烟测试，测试小组就会拒绝该版本。因此，他们会填写一份提交测试申请表来申请进行系统测试。在这份表格中，不仅会明确版本号，修改或新增的功能详细说明，还会给测试人员提供此版本的测试重点，以及可能会影响到的功能。这些内容对测试人员都是至关重要和大有裨益的。
在项目测试过程中，我们也出现过打回某个版本的情况，拒绝测试。总结起来，基本上有以下几种情况：
● 由于任务查询的技术难度比较大，开发进度已经延期了5天，测试人员正在焦急的等待这部分的功能测试。可是，新提交的可测试版本中，这个功能根本就不能使用，如果进一步测试就是浪费时间，我们立即打回了这个测试版本。
● 新增了代办的功能，可是以往的代理功能中的增加代理人功能却不能正常使用，而增加代理人功能又是代办功能的基础，也就是说，在这个版本中，及时代办功能完全能够测试，可离开了增加代理人功能，代办测试是没有意义的。
● 在回归测试阶段，可测试版本的提交是比较频繁的。开发人员一旦解决了一部分bug就会提交一个可测试版本，如果此时测试人员并不急需更换版本，并且得知另一个版本会在几个小时之后就会完成，我们可以不测试这个版本。为了能更好的完成冒烟测试这个关键阶段，测试人员积极与开发人员配合：
● 负责提供冒烟测试案例。
● 如果测试人员处于版本等待阶段，主动和开发人员一起做冒烟测试。开展有效测试，提高测试效率有效的测试用例是软件测试成功的关键，有助于提高测试效率和测试覆盖率。在这个工作流软件测试项目中，我们从测试模型（Test Model）入手，结合丰富的测试经验和专业知识，从繁多的测试用例中挑选出有效的用例，用尽可能少的测试输入，覆盖尽可能多的软件需求。主要采用了状态机模型和组合模型，并结合了正交设计技术和组合覆盖技术，完成了对整个系统的测试设计。详细内容可以参考笔者在《程序员》杂志2007年第4期上的文章《基于模型的有效测试用例设计——工作流系统测试实战》一文。知己知彼，合力制胜提供服务使测试人员有机会赢得程序员的信任，同时也有机会展示自己的才能。同时，带来的回报是得到了开发人员对我们的帮助。在整个项目过程中，我们获得了很好的回报，比如：开发人员讲解设计思路、算法流程；和测试人员一起构造测试数据；积极参加每日测试例会，主动解决问题等。这样良好的合作状态与测试人员的主动努力是分不开的，主要体现在：
● 获取程序员信任，及时沟通不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息，比如他们的计划、设计文档的早期草案和早期原型等，测试工作会更加有效。越早与程序员接触，情况就越好。尽早提出你的意见和反馈，了解程序员提交前完成的工作。
● 主动出击，提供服务
○ 在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员是能够与之合作的人。我们在项目过程中提供给开发人员的服务：
○ 对工作流的运算逻辑?构件进行了测试，方便了后期开发工作流客户端应用的使用。
○ 对内部版本和原?型进行测试。
○ 对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。
○ 帮助程序员建立测试环境，方便程序员进行测试。
● 耳目作用
○ 在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限于测试命令链本身，及时验证和发现项目环节中的问题。总之，测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人的帮助和支持，以及认可
(文 / 徐异婕) 徐异婕，10年软件开发与测试从业经验，对需求分析、测试设计、测试管理、测试分析有深入研究。目前在普元软件从事测试工作，曾在中国工商银行总行软件开发中心从事测试工作。
查看(365)
评论(0)
收藏
分享
管理
2009-01-29 01:44:27
关于嵌入式系统－－献给热爱此道的初学者们
前言
网上看到众多网友都问了关于嵌入式系统方面的很多问题，很多都可在这里找到答案，希望我的这篇文章能给他们以启发。也请大家不要轻易转载。
一、嵌入式系统的概念
着重理解“嵌入”的概念
主要从三个方面上来理解。
1、从硬件上，将基于CPU的处围器件，整合到CPU芯片内部，比如早期基于X86体系结构下的计算机，CPU只是有运算器和累加器的功能，一切芯片要造外部桥路来扩展实现，象串口之类的都是靠外部的16C550/2的串口控制器芯片实现，而目前的这种串口控制器芯片早已集成到CPU内部，还有PC机有显卡，而多数嵌入式处理器都带有LCD控制器，但其种意义上就相当于显卡。比较高端的ARM类Intel Xscale架构下的IXP网络处理器CPU内部集成PCI控制器（可配成支持4个PCI从设备或配成自身为CPI从设备）；还集成3个NPE网络处理器引擎，其中两个对应于两个MAC地址，可用于网关交换用，而另外一个NPE网络处理器引擎支持DSL，只要外面再加个PHY芯片即可以实现DSL上网功能。IXP系列最高主频可以达到1.8G，支持2G内存，1G×10或10G×1的以太网口或Febre channel的光通道。IXP系列应该是目标基于ARM体系统结构下由intel进行整合后成Xscale内核的最高的处理器了。
2、从软件上前，就是在定制操作系统内核里将应用一并选入，编译后将内核下载到ROM中。而在定制操作系统内核时所选择的应用程序组件就是完成了软件的“嵌入”，比如WinCE在内核定制时，会有相应选择，其中就是wordpad,PDF,MediaPlay等等选择，如果我们选择了，在CE启动后，就可以在界面中找到这些东西，如果是以前PC上将的Windows操作系统，多半的东西都需要我们得新再装。
3、把软件内核或应用文件系统等东西烧到嵌入式系统硬件平台中的ROM中就实现了一个真正的“嵌入”。
以上的定义是我在6、7年前给嵌入式系统下自话侧重于理解型的定义，书上的定义也有很多，但在这个领域范围内，谁都不敢说自己的定义是十分确切的，包括那些专家学者们，历为毕竟嵌入式系统是计算机范畴下的一门综合性学科
二、嵌入式系统的分层与专业的分类。
嵌入式系统分为４层，硬件层、驱动层、操作系统层和应用层。
1、硬件层，是整个嵌入式系统的根本，如果现在单片机及接口这块很熟悉，并且能用C和汇编语言来编程的话，从嵌入式系统的硬件层走起来相对容易，硬件层也是驱动层的基础，一个优秀的驱动工程师是要能够看懂硬件的电路图和自行完成CPLD的逻辑设计的，同时还要对操作系统内核及其调度性相当的熟悉的。但硬件平台是基础，增值还要靠软件。
硬件层比较适合于，电子、通信、自动化、机电一体、信息工程类专业的人来搞，需要掌握的专业基础知识有，单片机原理及接口技术、微机原理及接口技术、C语言。
2、驱动层，这部分比较难，驱动工程师不仅要能看懂电路图还要能对操作系统内核十分的精通，以便其所写的驱动程序在系统调用时，不会独占操作系统时间片，而导至其它任务不能动行，不懂操作系统内核架构和实时调度性，没有良好的驱动编写风格，按大多数书上所说添加的驱动的方式，很多人都能做到，但可能连个初级的驱动工程师的水平都达不到，这样所写的驱动在应用调用时就如同Windows下我们打开一个程序运行后，再打开一个程序时，要不就是中断以前的程序，要不就是等上一会才能运行后来打开的程序。想做个好的驱动人员没有三、四年功底，操作系统内核不研究上几编，不是太容易成功的，但其工资在嵌入式系统四层中可是最高的。
驱动层比较适合于电子、通信、自动化、机电一体、信息工程类专业尤其是计算机偏体系结构类专业的人来搞，除硬件层所具备的基础学科外，还要对数据结构与算法、操作系统原理、编译原理都要十分精通了解。
3、操作系统层，对于操作系统层目前可能只能说是简单的移植，而很少有人来自已写操作系统，或者写出缺胳膊少腿的操作系统来，这部分工作大都由驱动工程师来完成。操作系统是负责系统任务的调试、磁盘和文件的管理，而嵌入式系统的实时性十分重要。据说，XP操作系统是微软投入300人用两年时间才搞定的，总时工时是600人年，中科院软件所自己的女娲Hopen操作系统估计也得花遇几百人年才能搞定。因此这部分工作相对来讲没有太大意义。
4、应用层，相对来讲较为容易的，如果会在Windows下如何进行编程接口函数调用，到操作系统下只是编译和开发环境有相应的变化而已。如果涉及Jave方面的编程也是如此的。嵌入式系统中涉及算法的由专业算法的人来处理的，不必归结到嵌入式系统范畴内。但如果涉及嵌入式系统下面嵌入式数据库、基于嵌入式系统的网络编程和基于某此应用层面的协议应用开发（比如基于SIP、H.323、Astrisk）方面又较为复杂，并且有难度了。
三、目标与定位。
先有目标，再去定位。
学ARM，从硬件上讲，一方面就是学习接口电路设计，另一方面就是学习汇编和C语言的板级编程。如果从软件上讲，就是要学习基于ARM处理器的操作系统层面的驱动、移植了。这些对于初学都来说必须明确,要么从硬件着手开始学，要么从操作系统的熟悉到应用开始学，但不管学什么，只要不是纯的操作系统级以上基于API的应用层的编程，硬件的寄存器类的东西还是要能看懂的，基于板级的汇编和C编程还是要会的。因此针对于嵌入式系统的硬件层和驱动程的人，ARM的接口电路设计、ARM的C语言和汇编语言编程及调试开发环境还是需要掌握的。
因此对于初学者必然要把握住方向，自己的目标是什么，自己要在那一层面上走。然后再着手学习较好，与ARM相关的嵌入式系统的较为实际的两个层面硬件层和驱动层，不管学好了那一层都会很有前途的。
如果想从嵌入式系统的应用层面的走的话，可能与ARM及其它体系相去较远，要着重研究基嵌入式操作系统的环境应用与相应开发工具链，比如WinCe操作系统下的EVC应用开发（与Windows下的VC相类似），如果想再有突破就往某些音视频类的协议上靠，比如VOIP领域的基于SIP或H.323协议的应用层开发，或是基于嵌入式网络数据库的开发等等。
对于初学者来讲，要量力而行，不要认为驱动层工资高就把它当成方向了，要结合自身特点，嵌入式系统四个层面上那个层面上来讲都是有高人存在，当然高人也对应的高工资，我是做硬件层的，以前每月工资中个人所得税要被扣上近3千大元，当然我一方面充当工程师的角色，一方面充当主管及人物的角色，两个职位我一个人干，但上班时间就那些。硬件这方面上可能与我PK的人很少了，才让我拿到那么多的工资。
四、开发系统选择。
很多ARM初学者都希望有一套自己能用的系统，但他们住住会产生一种错误认识就是认为处理器版本越高、性能越高越好，就象很多人认为ARM9与ARM7好，我想对于初学者在此方面以此入门还应该理智，开发系统的选择最终要看自己往嵌入式系统的那个方向上走，是做驱动开发还是应用，还是做嵌入式系统硬件层设计与板级测试。如果想从操作系统层面或应用层面上走，不管是驱动还是应用，那当然处理器性能越高越好了，但这个东西自学，有十分大的困难，不是几个月或半年或是一年二年能搞定的事。
在某种意义上请，ARM7与9的差别就是在某些功能指令集上丰富了些，主频提高一些而已，就比如286和386。对于用户来讲可能觉查不到什么，只能是感觉速度有些快而已。
ARM7比较适合于那些想从硬件层面上走的人，因为ARM7系列处理器内部带MMU的很少，而且比较好控制，就比如S3C44B0来讲，可以很容易将Cache关了，而且内部接口寄存器很容易看明白，各种接口对于用硬件程序控制或AXD单步命令行指令都可以控制起来，基于51单片机的思想很容易能把他搞懂，就当成个32位的单片机，从而消除很多51工程师想转为嵌入式系统硬件ARM开发工程师的困惑，从而不会被业界某此不是真正懂嵌入式烂公司带到操作系统层面上去，让他们望而失畏，让业界更加缺少这方面的人才。
而嵌入式系统不管硬件设计还是软件驱动方面都是十分注重接口这部分的，选择平台还要考察一个处理器的外部资源，你接触外部资源越多，越熟悉他们那你以后就业成功的机率就越高，这就是招聘时所说的有无“相关技能”，因为一个人不可能在短短几年内把所有的处理器都接触一遍，而招聘单位所用的处理器就可能是我们完全没有见过的，就拿台湾数十家小公司（市价几千万）的公司生产的ARM类处理器，也很好用，但这些东西通用性太差，用这些处理器的公司就只能招有相关工作经验的人了，那什么是相关工作经验，在硬件上讲的是外围接口设计，在软件上讲是操作系统方面相关接口驱动及应用开发经验。我从业近十年，2000年ARM出现，我一天始做ARM7,然后直接跑到了Xscale（这个板本在ARM10-11之间），一做就是五年，招人面试都不下数百人，在这些方面还是深有体会的。
我个人认为三星的S3C44b0对初学者来说比较合适，为什么这么说哪？因为接口资源比较丰富，技术成熟，资料较多，应该十分适合于初学者，有问题可能很容易找人帮且解决，因为大多数人都很熟悉，就如同51类的单片机，有N多位专家级的人物可以给你帮忙，相关问题得以很快解答，所然业界认为这款ARM都做用得烂了，但对于初学者来，就却是件好事。
因此开发系统的选择，要看自己的未来从来目标方向、要看开发板接口资源、还要看业界的通用性。
五、如何看待培训。
首先说说我自己，我目前从业近十年，与国内嵌入式系统行业共同起步，一直站在嵌入式系统行业前沿，设计过多款高端嵌入式系统平台产品并为众多公司提供过解决方案，离职前为从事VOIP的美资公司设计IP-PBX，历任项目经理、项目主管、技术总监、部门经理，积累众多人脉，并集多年经验所得，考虑到学生就业与公司招人的不相匹配，公司想招人招不到，而学生和刚毕业的工程师想找份工作也不太容易，于此力创知天行科技有限公司，开展嵌入式系统教育培训。
因一线的科研人员和一线的教师不相接触，导至国内嵌入式人才缺乏，国外高校的技术超前于业界公司，而国内情况是业界公司方面的嵌入式系统技术要远远领先于高校。为架构业界与高校沟通的桥梁，把先进技能带给高校学子，为学生在就业竞争中打造一张王牌，并为业界工程师快速提升实现自我创造机遇，我就这样辞去了外企年薪20多万的职位，做嵌入式系统方面的培训了。
对于培训来讲，是花钱来买时间，很多工程师都喜欢自己学，认为培训不值，这也是有可能的，纯为赚钱的培训当然不会太有价值，但对于实力型的培训他们可能就亏大了，有这样一笔帐不知他们算过没有，如果一个一周的培训，能带给他们自学两年后才能掌握的知识，在培训完后他们用三个月到半年时间消化培训内容，这样他会省约至少一年半的时间来学其它的或重新站在另一个高度上工作，那么他将最迟一年后会拿到他两年后水平所对应的工资，就是在工资与水平对应的关系上比同批人缩短一年，每月按最少1千计，再减去培训费用至少多1.0万，同时也省了一年时间，不管是休闲也好，再继续提高也好，总之是跑到了队伍的前面了。
另一层面上讲，对于新人的培训相当于他们为自己提前买了份失业保险，有师傅会带领他们入道，我今年暑假时班里最年轻的一个学生是大二的，今年才上大三，这学期才刚学单片机，但现在ARM方面的编程工作已经搞得有声有色了，再过一年多毕业，他还会失业吗？
再者通过培训，你可以知道很多业界不为常人所知的事，同时也为自己找了个师傅，就比如说，两个工程师分别用S3C2410和PXA255来做手持设备，同样两人都工作四年，再出去找工作，两人工资可能最多可相差一倍，为什么？这就是业界不为常人所知的规则，2410属于民品，被业界用烂了，做产品时成本特敏感，当然也对人才成本敏感了，PXA255是intel的东西，一个255 CPU能买三个2410，一直被业界定义为贵族产品，用的公司都是大公司或为军方服务的公司，不会在乎成本，只要把东西做好，一切都好说，但这方面做的人也少啊，因为开发系统贵啊。
对于说为自已找了个好师傅，我想是这样的，因为同级工程师间存在着某此潜在的竞争关系，有很多人不愿意把自己知道的东西教给别人，这意味着他将要失业，就是所说的教会徒弟，饿死师傅，但对于我们这些人就不存在这样的关系了，我是在嵌入式系统平台设计上走到了一定程序，目前在国内这块的技术上已经是自己很难再突破自己，因此很多东西我对大家都是OPEN的，就比如说下面那部分关于接口设计中所提到的时序接口东西，我要是不讲，却使是高级硬件工程师我想也几乎只有10%的人能知道吧。
六、成为高级嵌入式系统硬件工程师要具备的技能。
首先我声明，我是基于嵌入式系统平台级设计的，硬件这个方向我相对来讲比较有发言权，如果是其它方面所要具备的基本技能还要和我们培训中心其它专业级讲师沟通，或去网站看看www.zt-training.com。他们的方面上我只能说是知道些，但不是太多，初级的问题也可以问我。
对于硬件来讲有几个方向，就单纯信号来分为数字和模拟，模拟比较难搞，一般需要很长的经验积累，单单一个阻值或容值的精度不够就可能使信号偏差很大。因此年轻人搞的较少，随着技术的发展，出现了模拟电路数字化，比如手机的Modem射频模块，都采用成熟的套片，而当年国际上只有两家公司有此技术，自我感觉模拟功能不太强的人，不太适合搞这个，如果真能搞定到手机的射频模块，只要达到一般程度可能月薪都在15K以上。
另一类就是数字部分了，在大方向上又可分为51/ARM的单片机类，dsp类，FPGA类，国内FPGA的工程师大多是在IC设计公司从事IP核的前端验证，这部分不搞到门级，前途不太明朗，即使做个IC前端验证工程师，也要搞上几年才能胜任。dsp硬件接口比较定型，如果不向驱动或是算法上靠拢，前途也不会太大。而ARM单片机类的内容就较多，业界产品占用量大，应用人群广，因此就业空间极大，而硬件设计最体现水平和水准的就是接口设计这块，这是各个高级硬件工程师相互PK，判定水平高低的依据。而接口设计这块最关键的是看时序，而不是简单的连接，比如PXA255处理器I2C要求速度在100Kbps，如果把一个I2C外围器件，最高还达不到100kbps的与它相接，必然要导致设计的失败。这样的情况有很多，比如51单片机可以在总线接LCD，但为什么这种LCD就不能挂在ARM的总线上，还有ARM7总线上可以外接个Winband的SD卡控制器，但为什么这种控制器接不到ARM9或是Xscale处理器上，这些都是问题。因此接口并不是一种简单的连接，要看时序，要看参数。 一个优秀的硬件工程师应该能够在没有参考方案的前提下设计出一个在成本和性能上更加优秀的产品，靠现有的方案，也要进行适当的可行性裁剪，但不是胡乱的来，我遇到一个工程师把方案中的5V变1.8V的DC芯片，直接更换成LDO，有时就会把CPU烧上几个。前几天还有人希望我帮忙把他们以前基于PXA255平台的手持GPS设备做下程序优化，我问了一下情况，地图是存在SD卡中的，而SD卡与PXA255的MMC控制器间采用的SPI接口，因此导致地图读取速度十分的慢，这种情况是设计中严重的缺陷，而不是程序的问题，因此我提了几条建议，让他们更新试下再说。因此想成为一个优秀的工程师，需要对系统整体性的把握和对已有电路的理解，换句话说，给你一套电路图你终究能看明白多少，看不明白80%以上的话，说明你离优秀的工程师还差得远哪。其次是电路的调试能力和审图能力，但最最基本的能力还是原理图设计PCB绘制，逻辑设计这块。这是指的硬件设计工程师，从上面的硬件设计工程师中还可以分出ECAD工程师，就是专业的画PCB板的工程师，和EMC设计工程师，帮人家解决EMC的问题。硬件工程师再往上就是板级测试工程师，就是C语功底很好的硬件工程师，在电路板调试过程中能通过自已编写的测试程序对硬件功能进行验证。然后再交给基于操作系统级的驱动开发人员。
总之，硬件的内容很多很杂，硬件那方面练成了都会成为一个高手，我时常会给人家做下方案评估，很多高级硬件工程师设计的东西，经常被我一句话否定，因此工程师做到我这种地步，也会得罪些人，但硬件的确会有很多不为人知的东西，让很多高级硬件工程师也摸不到头脑。
那么高级硬件件工程师技术技能都要具备那些东西哪，首先要掌握EDA设计的辅助工具类如Protel\ORCAD\PowperPCB\Maplux2\ISE、VDHL语言，要能用到这些工具画图画板做逻辑设计，再有就是接口设计审图能力，再者就是调试能力，如果能走到总体方案设计这块，那就基本上快成为资深工程师了。
硬件是要靠经验，也要靠积累的，十年磨一剑，百年磨一针。
查看(403)
评论(1)
收藏
分享
管理
2009-01-29 01:39:52
嵌入式Linux操作系统学习规划
ARM+LINUX路线，主攻嵌入式Linux操作系统及其上应用软件开发目标：
（1） 掌握主流嵌入式微处理器的结构与原理（初步定为arm9）
（2） 必须掌握一个嵌入式操作系统 （初步定为uclinux或linux,版本待定）
（3） 必须熟悉嵌入式软件开发流程并至少做一个嵌入式软件项目。
从事嵌入式软件开发的好处是：
（1）目前国内外这方面的人都很稀缺。这一领域入门门槛较高，所以非专业IT人员很难切入这一领域；另一方面，是因为这一领域较新，目前发展太快，大多数人无条件接触。
（2）与企业计算等应用软件不同，嵌入式领域人才的工作强度通常低一些（但收入不低）。
（3）哪天若想创业，搞自已的产品，嵌入式不像应用软件那样容易被盗版。硬件设计一般都是请其它公司给订做（这叫“贴牌”：OEM），都是通用的硬件，我们只管设计软件就变成自己的产品了。
（4）兴趣所在，这是最主要的。
从事嵌入式软件开发的缺点是：
（1）入门起点较高，所用到的技术往往都有一定难度，若软硬件基础不好，特别是操作系统级软件功底不深，则可能不适于此行。
（2）这方面的企业数量要远少于企业计算类企业。
（3）有少数公司经常要硕士以上的人搞嵌入式，主要是基于嵌入式的难度。但大多数公司也并无此要求，只要有经验即可。
（4）平台依托强，换平台比较辛苦。
兴趣的由来：
1、成功观念不同，不虚度此生，就是我的成功。
2、喜欢思考，挑战逻辑思维。
3、喜欢C
C是一种能发挥思维极限的语言。关于C的精神的一些方面可以被概述成短句如下：
相信程序员。
不要阻止程序员做那些需要去做的。
保持语言短小精干。
一种方法做一个操作。
使得它运行的够快，尽管它并不能保证将是可移植的。
4、喜欢底层开发，讨厌vb类开发工具（并不是说vb不好）。
5、发展前景好，适合创业，不想自己要死了的时候还是一个工程师。
方法步骤：
1、基础知识：
目的：能看懂硬件工作原理，但重点在嵌入式软件，特别是操作系统级软件，那将是我的优势。
科目：数字电路、计算机组成原理、嵌入式微处理器结构。
汇编语言、C/C++、编译原理、离散数学。
数据结构和算法、操作系统、软件工程、网络、数据库。
方法：虽科目众多，但都是较简单的基础，且大部分已掌握。不一定全学，可根据需要选修。
主攻书籍：the c++ programming language（一直没时间读）、数据结构-C2。
2、学习linux：
目的：深入掌握linux系统。
方法：使用linux—〉linxu系统编程开发—〉驱动开发和分析linux内核。先看深，那主讲原理。看几遍后，看情景分析，对照深看，两本交叉，深是纲，情是目。剖析则是0.11版，适合学习。最后深入代码。
主攻书籍：linux内核完全剖析、unix环境高级编程、深入理解linux内核、情景分析和源代。
3、学习嵌入式linux：
目的：掌握嵌入式处理器其及系统。
方法：（1）嵌入式微处理器结构与应用：直接arm原理及汇编即可，不要重复x86。
（2）嵌入式操作系统类：ucOS/II简单，开源，可供入门。而后深入研究uClinux。
（3）必须有块开发板（arm9以上），有条件可参加培训（进步快，能认识些朋友）。
主攻书籍：毛德操的《嵌入式系统》及其他arm9手册与arm汇编指令等。
4、深入学习：
A、数字图像压缩技术：主要是应掌握MPEG、mp3等编解码算法和技术。
B、通信协议及编程技术：TCP/IP协议、802.11，Bluetooth，GPRS、GSM、CDMA等。
C、网络与信息安全技术：如加密技术，数字证书CA等。
D、DSP技术：Digital Signal Process，DSP处理器通过硬件实现数字信号处理算法。
说明：太多细节未说明，可根据实际情况调整。重点在于1、3，不必完全按照顺序作。对于学习c++，理由是c++不只是一种语言，一种工具，她还是一种艺术，一种文化，一种哲学理念、但不是拿来炫耀得东西。对于linux内核，学习编程，读一些优秀代码也是有必要的。
注意： 要学会举一反多，有强大的基础，很多东西简单看看就能会。想成为合格的程序员，前提是必须熟练至少一种编程语言，并具有良好的逻辑思维。一定要理论结合实践。
不要一味钻研技术，虽然挤出时间是很难做到的，但还是要留点余地去完善其他的爱好，比如宇宙，素描、机械、管理，心理学、游戏、科幻电影。还有一些不愿意做但必须要做的！
技术是通过编程编程在编程编出来的。永远不要梦想一步登天，不要做浮躁的人，不要觉得路途漫上。而是要编程编程在编程，完了在编程，在编程！等机会来了在创业（不要相信有奇迹发生，盲目创业很难成功，即便成功了发展空间也不一定很大）。
嵌入式书籍推荐
Linux基础
1、《Linux与Unix Shell 编程指南》
C语言基础
1、《C Primer Plus，5th Edition》【美】Stephen Prata着
2、《The C Programming Language, 2nd Edition》【美】Brian W. Kernighan David M. Rithie（K & R）着
3、《Advanced Programming in the UNIX Environment，2nd Edition》（APUE）
4、《嵌入式Linux应用程序开发详解》
Linux内核
1、《深入理解Linux内核》（第三版）
2、《Linux内核源代码情景分析》毛德操 胡希明著
研发方向
1、《UNIX Network Programming》（UNP）
2、《TCP/IP详解》
3、《Linux内核编程》
4、《Linux设备驱动开发》（LDD）
5、《Linux高级程序设计》 杨宗德著
硬件基础
1、《ARM体系结构与编程》杜春雷着
2、S3C2410 Datasheet
英语基础
1、《计算机与通信专业英语》
系统教程
1、《嵌入式系统――体系结构、编程与设计》
2、《嵌入式系统――采用公开源代码和StrongARM/Xscale处理器》毛德操 胡希明着
3、《Building Embedded Linux Systems》
4、《嵌入式ARM系统原理与实例开发》 杨宗德著
理论基础
1、《算法导论》
2、《数据结构（C语言版）》
3、《计算机组织与体系结构?性能分析》
4、《深入理解计算机系统》【美】Randal E. Bryant David O''Hallaron着
5、《操作系统：精髓与设计原理》
6、《编译原理》
7、《数据通信与计算机网络》
8、《数据压缩原理与应用》
C语言书籍推荐
1. The C programming language 《Ｃ程序设计语言》
2. Pointers on C 《Ｃ和指针》
3. C traps and pitfalls 《Ｃ陷阱与缺陷》
4. Expert C Lanuage 《专家Ｃ编程》
5. Writing Clean Code -----Microsoft Techiniques for Developing Bug-free C Programs
《编程精粹--Microsoft 编写优质无错Ｃ程序秘诀》
6. Programming Embedded Systems in C and C++ 《嵌入式系统编程》
7.《C语言嵌入式系统编程修炼》
8.《高质量C++/C编程指南》林锐
尽可能多的编码，要学好C，不能只注重C本身。算法，架构方式等都很重要。
查看(641)
评论(0)
收藏
分享
管理
2009-01-28 15:09:09
1、结余你的爱情血本，不要见人就爱；
2、工作辛苦点没关系，累死总比饿死好，至少无愧于心；
3、储备资金与精力，父母年岁已高，要保证他们的善终；
4、凡事得失心不要太重，因为你的青春时间余下不多，开心最重要 ；
5、抽烟固然会影响身体健康，如果因为戒烟而倒致心里失常那损失更大 ；
6、做适量的运动，但做爱除外 ；
7、没必要的话，大可不必看一些韩国偶像剧之类的电影，因为我们不是小孩子了；
8、不要把某个明星当作偶像，理由如第七条；
9、不要耍小孩子脾气，动不动就要离职换工作，因为你需要这份工作，而不是这份工作需要你；
10、陌生人面前一定要装作很笨的样子，一个乞丐都可能有不寻常的经历，值得我们尊重；
11、即便你平时饭后只是用袖子蹭蹭嘴巴，也要把自己的床收拾干净，没有什么比自己的床更能给你温暖 ；
12、如果有朋友向你借钱，不要着急告诉他你的经济有多困难，先表示关心他是不是出了什么事，哪怕是象征性的；
13、朋友结婚是件快乐的事，没必要回家后独自默默悲哀；
14、至少喜欢一门以上的艺术，否则你的生活会没有追求；
15、一定要锻练御寒能力，不知道哪一天你可能需要在冰天冻地的天气穿一件单薄的西服或一身晚装出席宴会；
16、如果你的女友突然戴上了在她经济能力以外的首饰，请自觉地离开她；
17、和一名异性"朋友"开好房之后，当对方躺在床上等你脱衣服的时候，你应该拿起西服上衣或包包，向她/他道晚安，然后吹着口哨、哼着小曲走出房间，以此抗义对方对你高尚人格的藐视；
18、如果你不是急着生孩子，人格比肉体欢愉更重要，不要轻易与人上床 ；
19、不要搭理那些喜欢骂人或喜欢对陌生人抱人成见的人，他们没素质，不配与你交流；
20、自我膨胀只是一时开心的工具，心里要知道自己的老底及创伤；
21、夸你的话笑笑就好，不是有阴谋就是有所求，要清楚地知道人性是丑陋的，他们不可能强忍着妒忌而夸你，千万不能当真；
22、如果你的业余时间太多，可以尝试着写小说，然后拿去给朋友看，他们要是不看的话你就给他钱；
23、多学点东西，任何时候都要相信自己还很年轻，哪怕是40岁以上，装也要装作年轻；
24、如果你是男人，而且事业没有起色，请不要谈恋爱更不要结婚，现实些，去先努力奋斗吧；
25、准备结婚的朋友们要注意了，同样睡在你枕头边的另一个人结过婚之后，他/她不再是路人，而是你的亲人，你首先要考虑的不是爱与不爱，而是能不能容忍；
26、信用卡的负债要及时还上，因为会直接影响到你今后的贷款、按竭；
27、要有理想，哪怕只是想学会做西红柿炒鸡蛋；
28、结婚前没必要爱得死去活来，如果有一天她/他跟人走了，你人财两空；
29、当爱情不在得时候，请你对它说声祝福，不要去恨它，因为曾经都爱过，错过了是两个人得责任，只是有缘无份罢了；
30、别把哀伤挂在嘴上， 每个人都有自己的故事。活着不是为了怀念昨天， 而是要等待希望 ， 让大家都看到你的坚强；
31、别说你最爱的是谁， 人生还很长， 谁也无法预知明天。也许你的真爱还在下一秒等着你 ；
32、说分手的时候不要吵闹。 毕竟两个在在一起那么久，分了他也会难过。 只是他比较明智，不想束缚你的或他的明天。好聚好散，以后，还是朋友。 大家都有自己的无奈 ；
33、人生会遇见四种人：自己，你最爱得人，最爱你得人，和你共度一生得人，遇见同一个人，注意了，真得要好好珍惜，你可是相当幸运儿 ；
34、同上，否则，请你不要伤心，难过，你所遇见得都是过客而已，世界这么大，谁又遇见了你，而你又遇见了谁呢；
35、明知道海不会枯、石不会烂、地不会老、天不会荒; 就算会，也活不到那时候。许下诺言的时候千万注意，不要许下可以实现的诺言，最好是承诺做不到的事，反正做不到的，随便说说也不要紧 ；
36、请记住："不可能实现的诺言最动人" ，在爱情里，说的是一套，做的是另一套; 讲的人不相信，听的人也不相信；
37、当我们得爱情遇到父母阻挠得时候，应该放下热度，接受冷度得想一想，父母是爱我们得，父母只有一个，而朋友却很多；
38、同上，更不应该有放弃父母，然后私奔，这样得想法真得太幼稚，同志们要记得一句话：母爱，父爱，最伟大，他们永远是最爱我们的，万岁！
查看(348)
评论(2)
收藏
分享
管理
2009-01-27 00:56:51
IPTV作为一种具有发展潜力的新的网络业务，备受电信运营商的重视，纷纷在各地区开展多个业务试用点。运营商的这一举动带动了设备制造商的积极性，特别是IPTV终端更是各类设备制造商研发的重点。但是，由于IPTV是一个新业务，目前试运营大多构建于单一设备制造商的技术解决方案上，终端与系统是捆绑关系，没有为终端提供开放的系统环境。从长远考虑，业务不断发展会促进产业链逐渐完善，如果终端继续维持与系统的捆绑关系非常不利于产业链发展，同时也会阻碍IPTV业务的发展。针对这种情况，中国通信标准化协会及时成立了IPTV业务特别工作组，重点研究IPTV业务系列标准，其中就包括IPTV终端技术标准。经过协会成员单位的深入研究和多次讨论，最终形成《IPTV机顶盒技术要求》终端标准，目前已和其他IPTV标准一起提交信息产业部报批。
IPTV业务的终端存在多种类型，可以有PC机、机顶盒配合电视机、移动便携设备（如手机、PDA等）。从家庭用户的实际应用习惯上来看，机顶盒+电视机类型的终端在IPTV业务中应该是主流终端。在IPTV机顶盒技术标准中对机顶盒的业务能力、功能、性能、接口、安全和应用环境等给出了具体技术要求。首先，IPTV机顶盒应满足标准的技术要求，可以提供标准中规定的直播、点播和时移三种基本业务能力。业务能力的检测是一个综合测试项目，它应建立在以下一系列技术指标检测项之上，如接口电气性能、网络适应性、编解码能力、协议一致性、互通性等。只有其他各项指标完全满足技术要求，才能使终端充分展现出IPTV业务的魅力。
IPTV机顶盒终端是一种类似家庭媒体平台的设备，需要多种类型接口。网络接入侧可以有10/100BAES-T、ADSL、WLAN等接口，外接设备侧有音视频接口、红外遥控接口，以及下行以太网接口、VGA接口、USB接口等等。IPTV机顶盒所用的接口，基本都是公开标准接口。在测试过程中，主要关注机顶盒所具有的接口是否可以满足IPTV基本业务的需求以及机顶盒附加功能所提供的接口是否完备。
IPTV机顶盒性能测试重点要考察机顶盒的网络适应性和抗时延抖动的能力。一个机顶盒的优劣表现在它对于网络环境的适应能力。IPTV业务传输是基于现存IP网络的，由于IP技术的固有机制不能提供端到端的包延时、包丢失率以及带宽控制能力，难以保证实时业务的服务质量，因此在IPTV直播业务这种要求实时性强的业务应用中，就会造成服务质量下降。在同样的网络环境下，如果机顶盒的设计合理可以弥补一些网络缺陷，如适当配置缓存，使直播业务的内容在机顶盒中经过短暂缓存再播放出去，从用户感官上提高图像的效果。在测试过程中，在媒体服务器与机顶盒之间适当加入网络损伤，当媒体数据通过网络传输到机顶盒再播放时，观察图像变化。不同机顶盒的播放效果会有差别，以此可以较为直观地评价机顶盒的网络适应性能。当然也可以用仪表更量化的分析图像质量来测试机顶盒性能。
机顶盒编解码能力和图像功能也是测试重点。机顶盒的输出接口包括模拟复合视频接口和S视频接口，采用RGB格式。有些机顶盒还配备有模拟分量接口（采用YPbPr格式）、VGA接口。如果是支持标清和高清的机顶盒，那么典型的测试信号格式还应当包括480i、480p、576i、576p、720p、1080i或某些VGA格式。在测试过程中采用定制码流，有些测试还需要将其它测试码流与定制码流进行复合，来进行图像质量测试、功能测试。模拟复合视频和模拟分量视频的测试信号质量参数有所不同。在通常情况下，模拟复合视频有四类测量参数，它们是幅度和定时测量、线性失真、非线性失真和噪声失真。对于模拟分量视频测试更关心的是每个RGB/YPbPr通道的频率响应、K2T、非线性、噪声和通道延迟。有关详细参数不在此处讨论。除此之外，在图像质量测试中需要关注的参数还有色度/亮度增益和延迟、频率响应、群延迟、K因子、差分增益和差分相位、亮度非线性和噪声等。
机顶盒测试的另一个重点是协议一致性。在IPTV机顶盒技术要求中，规定了各接口的通信协议栈。对机顶盒实现IPTV业务的各个过程的通信协议都有具体要求，特别是在媒体传输与控制相关协议栈中，规定机顶盒可以采用实时流传输协议RTP/RTCP和GB/T13818-12000的规定MPEG-2TS两种方式进行媒体封装和传输。采用这两种传输协议都可以有效避免网络传输过程中的包乱序，利用RTP/RTCP的有效载荷区域，可以识别承载类型。利用MPEG-2TS传输，其封装包内有一个内置的4位连续计数器，根据计数器顺序，可以利用带有IP和MPEG解码双重能力的在线测试设备就能够方便地检测到是否有包乱序。
互通性是机顶盒与IPTV业务系统之间信息交互、媒体传输、管理控制等一系列通信过程的保证。在通常情况下，只要符合标准规定的协议栈设计的机顶盒，利用仪表进行单机测试都可以满足协议一致性。然而在互通时由于采标的差异，或延时的不同，都会给互通带来困难。所以机顶盒与系统的互通性是测试的重点，也是测试的难点。如何解决互通问题，目前很多解决方案采用中间件方式。机顶盒与系统之间采用公开的API接口，机顶盒提供必要的硬件平台和相应的中间件适配层。机顶盒的某些功能通过下载插件获得，互通过程完全由系统完成。同时，机顶盒的很多扩展业务能力也可以利用中间件下载，使机顶盒更有利于适应不断发展的业务需求。中间件方案将计算机软件设计理念引入到电信设备中，是一个融合的思路，也是一种进步，会具有很好的发展前途。未来的机顶盒测试也可能增加中间件测试项。 除此之外，机顶盒作为用户终端设备，也可以算是一种家用电器。在电器特性的测试上，既要进行电信终端的电磁兼容性等入网测试，还要通过家用电器的3C认证。只有通过严格检验的机顶盒设备，才能为用户提供性能良好的安全的终端，使其能够显现出完美的IPTV业务内容。
查看(184)
评论(1)
收藏
分享
管理
2009-01-04 23:12:30
转自：http://blog.csdn.net/imlogic/archive/2007/03/22/1537328.aspx
测试工程师最开心的事:发现了一个很严重的bug,特别是那种隐藏很深,逻辑性的错误.偶第一次发现这种问题的时候,听到上司和开发人员的表扬时,高兴的就想扭pp.不过现在慢慢矜持些了,呵呵.
测试工程师最提心吊胆的事:版本release出去后,客户发现了很多或很严重的bug.经过紧张的系统测试之后,好不容易可以轻松一下了,却又陷入了每天担心正在做验收或使用的客户一封邮件或一个电话说产品有问题.碰到好些的老板还会比较乐观的看这样的问题,最惨的就是有些人一顿臭骂,之前的辛苦,加班全部都给抹杀了.
测试工程师最憎恨听到的话:"为什么这个bug没有在测试的发现呢?"这句话经常是客户发现bug后,老板对测试人员的质问.当然这里排除那种很明显的错误.其实谁都知道bug是不可能全部发现的,这句话其实也是客户对大头,大头对小兵一级一级问下来的.除了希望测试人员警惕之外,还有更多的是一种"踢猫"的行为.对于这句话,偶第一次听到这句话的反映是"我们怎么可能发现所有的bug呢",后来变成"制造bug的人不是我们,是开发",到现在的"让我查查我的日志,问问开发这个bug的原因,为什么我们会没有找到,下次我们会怎样"的回复.
测试工程师最郁闷的事:"刚才那个版本打包打错了,你们要重测".新版本来了,马上投入紧张的测试,希望能够多找些bug.没想到辛苦了可能大半天,开发人员说打包打错了,你重测吧.这种情况虽然可以通过规范流程之类的办法控制发生的机率,但人总会犯错,多少而已.碰到这样,你除了提醒开发部门下次注意,你除了重测没有太多办法.
测试工程师最不想面对的事:在测试晚期或最新的版本里发现了以前一直存在的问题,特别是当问题很严重时决定到底报不报bug.报吗,开发人员肯定会问以前有没有这个问题,不报吗,客户发现更惨.毕竟客户或老板的责备比开发部门或主管的责备轻许多,最后还是会报到bug库里的.
测试工程师最不想做的事:申请版本推迟发布.由于在版本发现了太多的问题,觉得产品不能达到发布的标准,建议公司推迟发布产品.这时虽然大家都知道产品有问题,尽管你自己也不希望这样,但谁都觉得你是一个制造麻烦的人,毕竟市场的压力很大呀.
测试工程师最丢人的事:辛苦的发现了一个bug,居然是该配的参数没有配等一些自己的失误造成的.有些该注意的地方居然测试时忘了,找出的问题给开发人员一顿臭扁,无比丢人啦.
测试工程师最怕的事:一天,甚至几天都没有发现一个bug!经过一段时间的bug高峰期后,有段时间会发现bug数量的减少,最可怕的就是一天都没有发现一个bug.偶有时会难过的吃饭都没心情.搞得偶的开发朋友说了一句最让人吐血的话:"要不要我在代码里放几个bug给你呀,hoho"
测试工程师最伤心的事:每年的调薪,发bonus或发股票时,测试工程师总比开发工程师少.偶有一同事在调薪的第二天就申请转开发,说测试太没前途了.
测试工程师最有力的保护方法:把你认为是bug的问题都提交到一个正式的,可以追踪的地方(一般来说是bug 库).有时总会碰到一些很小的或是很难判断的问题,犹豫一定是否要报,特别是一些UI的问题.有时问开发人员,他们可能会轻描淡写的回复你导致你没有report它.但多年的经验一定要报,了解bug流程走向的人都知道,后面还有人verify,还有开发经理判断,如果不是bug,自然他们会回复,会写明原因.说白了,出了问题也不是你的事情.当然一开始经验不足时会收到一些白眼球,但慢慢经验多了,对系统熟悉了,自然这种情况会少些.人也可以从一些问题中发现自己的弱点.但如果不报,那天客户提出来,你除了懊悔还要面对指责,严重的炒鱿鱼.
测试工程师最任重道远的事:测试驱动开发.碰到这种开发模式的项目,既是测试扬眉吐气的机会,也是可能会陷你于深渊的恶潭.你就必须打起十二分的精神.等于你在引导开发,有什么问题一定要提出来,否则你就等着被盲目的牵着鼻子走了.
测试工程师最期待的事:测试能够越来越受重视,测试工程师的考核越来越合理.
查看(153)
评论(0)
收藏
分享
管理
标题搜索
数据统计
- 访问量: 11127
- 日志数: 24
- 建立时间: 2009-01-04
- 更新时间: 2009-05-15
|
