发布新日志

  • 新的产品设计趋势

    2013-12-26 13:44:15

    做产品设计的,已经从怎么提供给用户很多功能进化到怎么提供给用户单一快捷的服务,从提高用户友好度增加用户体验进化到降低用户的学习成本,达到0学习
  • 探究自动测试与手动测试的利与弊(一点个人的看法)

    2013-02-06 15:16:00

    探究自动测试与手动测试的利与弊

    发布时间: 2013-2-06 11:26    作者: 曾月天 译    来源: 51Testing软件测试网采编 
    字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签: 软件测试 手动测试 自动化测试

      几个星期以前我遇到我们团队中的自动测试专家,从他们那里得到了一些什么时候适宜进行自动测试什么时候适合进行手动测试的信息。其实掰掰手指头都能想到,必须使用常识来决定。如果你只需要运行测试一两次,或者做自动测试非常昂贵,那最好采用手动测试。不过,在使用常识之前,你必须拿出确定的一些关于何时开始自动化测试的指导方针。

      自动测试的好处:

      如果你需要反复运行一组测试,那么自动测试将会对你非常有用。(回归测试,build测试,压力测试,负载测试,性能测试,安全测试,缺陷追踪测试等等这些测试场景相同,需要多次执行的,就适合自动化测试)

      自动测试使你能够应对频繁改变的代码从而跟上周期性回归测试的脚步。(不错,所以自动化测试特别适合回归测试)

      自动测试可以使你能够自动运行主流业务场景从而跟上周期性回归测试的脚步。(原文:It gives you the ability to run automation in main stream scenarios to catch regressions in a timely manner)(自动化测试的好处就是在测试框架搭建好后,新的需求变更引起的业务场景的变更,比手工测试的update效率更高,成本更低)

      自动测试可以帮助你测试大量测试矩阵(在不同操作系统上的不同语言)。自动测试可以使你的测试同时运行在不同的机器上,而手动测试必须不断地继续执行。(自动化测试的可以用一套脚本进行版本测试和分布式测试,对于web gui的测试,效果是倍增的。)

      自动测试的限制:

      花费大。编写测试用例,编写和配置自动化测试框架将会在测试开始时花费比手动测试更多的费用。
    (其实自动化测试的成本在任何时刻都是比手工测试高的,并不是自动化测试的速度比手工测试的速度快,就武断的认为自动化测试的成本低。自动化的成本唯一的好处是对一个成型的产品,能够减少回归测试的成本,但是必须是长生命周期的项目,一般2年左右的才有必要去大规模自动化覆盖,对于6个月以内的产品,除非是同架构的产品,否则很难套用原有的测试框架,往往得不偿失)

      无法自动测试一些可视的场景。例如,如果你无法通过代码告诉自动测试工具字体颜色,那么只好使用手动测试。
    (自动化测试的测试用例,首先就要和手工测试用有所区别,两者的scope是有迭代,但是也有各自的独立范畴,如何挑选测测试用例进行自动化转换,是一个技术活,例如,字体的颜色,其实是可以进行自动化验证的,比如固定的模板色的话,或者使用同一CSS文件的情况下)


      手动测试的好处:

      如果一个测试用例在编码阶段只运行两次,那最好使用手动测试,它将比自动测试花费少得多的费用。
    (其实现在很多自动化工具并非是针对case进行转制的,比如cucumber,是基于正则表达式的,往往只需要1周时间,对100多条正则表达式与自动化脚本进行匹配,就能实现全面自动化,所以现在以执行频度去考虑是否进行自动话,实际上已经过时了)

      手动测试允许测试员进行更多的随机测试。以我的经验来看,更多的bug将会由随机测试发现,而不是自动测试。并且,一个测试员花费越多的时间进行随机测试,发现真正的用户bug的几率就越大。

    (随机测试的实现,自动化工具更加有效率,之所以随机测试发现更多的bug,就在于自动化转制时,选择的手工测试用例的覆盖率偏低,overlap的场景太少,业务逻辑和workflow只考虑了正向等等愿意,很多公司在转制自动化时,是使用录制的方式,依据现有的手工测试用例,其实这时,基本上能够录制成功的话,已经很难发现miss的bug,最多只能在后续的版本中发现一些regression bug,所以很多自动化之后,发现没有比手工测试发现更多的bug,就认为自动化测试的效果不佳,是错误的。根源除了以上之外,还是对自动化脚本的target没有过的考虑,从出发点上就是模糊的)

      手动测试的限制:

      手动进行测试将花费大量的时间。
    (手工测试未必就比自动化测试花费的时间更多,有很多操作,自动化因为缺少上下文,所以很多pre-condition需要准备,而手工测试反而可以直接忽略了这些pre-condition)

      每次有了新的build,测试员必须重新运行测试-经过一段时间以后将会非常繁琐和疲惫。
    (其实手工测试的plan和method设置的很好的话,手工测试也很轻松,原来好多公司都经常在一个新版本上进行所有测试用例的回归测试,带来的是麻木和大量的缺失。其实通过引入case的severity和priority,以及bug的分析等因素,完全可以设定选取测试用例的范围,未必要都测试)


      其他的因素:

      你将哪些部分进行自动测试也由你使用的工具决定。如果该工具有很多限制,那么这些部分还是手动测试吧。
    (究竟是根据需求选择测试工具,还是根据测试工具选择测试范围,这是个难题。所以,解决之道还是你想使用自动化测试达到什么效果,你的目标是什么,才能去选择工具和划定范畴,为了纯粹自动化而自动化,是很多公司的现状,完全没有人去考虑我究竟为什么自动化,就为了说我们是自动化测试的?自动化很流行,所以我们也要自动化?自动化的测试工程师才是最好的测试工程师?)

      是否投资的回报值得运行自动测试?是否你自动化测试的产出值得建立和支持测试用例,自动框架和运行测试用例的系统?

    (恩,自动化的过程很复杂,有些公司是为了降低成本,有些公司为了提高竞争力,有些公司是为了锻炼技术,总之,自动化的目的太多了,完全要依据你自己的需求)

      自动测试的标准

      有两个问题可以用来判断是否应该为你的测试用例进行自动化。

      Q1:是否测试场景可以自动化? (
      A1:是的,并且花费很少。
      A2:是的,但是花费很多。
      A3:不,不可能进行自动化。

      Q2:该测试场景有多么重要?
      A1:我必须在任何可能的时候都对其进行测试。
      A2:我需要有规律地对该场景进行测试。
      A3:我只需要测试该场景一次。

      如果这两个问题你的答案都是#1,那么你肯定需要自动化该测试。

    (还是上面说的,自动化的目的是什么才能决定是否自动化,上面两个问题,更像是在自动化过程中,如果进行优先级的安排的问题,那些先自动化,那些后自动化)

      如果这两个问题你的答案是一个#1和一个#2,那么你最好自动化该测试。

      如果这两个问题你的答案都是#2,那么你应该好好考虑一下是否你值得为自动化测试投资。

      如果你无法自动测试,会有什么结果

      让我们假设如果你有一个测试必须在任何可能的时间运行,但是却无法自动化它,你的选择是:

      再评估 – 是否我真的需要如此频繁地运行它?

      如果手动测试它会有多大的花费?

      寻找新的测试工具。

      考虑使用test hooks。

    (没有一种测试工具是万能的,自动化的本质还是个工具,能否成功的进行自动化,还是取决于你测试的基本素质,手工测试能够组织的优秀的团队,进行自动化就是一个游戏的过程)
  • 让测试团队慢慢死去?

    2013-02-04 17:52:06

    哈哈,n久前就有人跟我说这个文章了,说实话,一直懒得看,今天有时间,咱也搞个辩论,直接copy过来,红色的是个人意见。

    让测试团队慢慢死去!
    (首先什么叫测试团队呢?有独立的测试部门,测试组,测试人员,从来没听说过独立的测试团队,就算是纯粹的测试外包,也是作为项目团队的一部分,项目团队可不是由开发团队和测试团队构成的,是由各个不同的角色构成的,如果你连这个基本概念都混淆,就不用往下看了,何必呢,有着时间干点别的去吧。)


    让我们先由2个问题引出今天的话题,第一,为什么选择做测试?第二,做测试的发展又如何?
    第一个问题,你为什么要选择做测试,我敢说十个人有九个不会说实话,什么测试能够让我开阔视野啦,测试同样也需要很好的技术啦,,,全是虚伪的借口。真正地答案只有一个,测试的收入高,要求低!(注意是相对你的能力比来说收入算高,因为你要是选择做开发,肯定不如现在的收入)不管你愿不愿意承认你都得承认,这是绝大部分测试入这一行的原因。
    (01年开始做测试的,那个时候根本不了解什么叫测试,很多外界人以为就是点点点,所以自己也这么稀里糊涂的加入,倒不是因为钱多,是因为当时的经理说了一句话,开发都是盲目的实现功能,测试是保证开发是盲目而不是盲动,说实话,这句话过了4,5年才真正理解)BTW,那个时候开发是3k,测试是1.5k,哥就是傻乎乎的被人忽悠入行的。

    第一个问题的答案决定了一个事实,测试团队的发展永远不可能像开发团队一样,随着公司的发展而发展,为什么呢?成本! 世界上没有傻逼的公司,你的公司之所以能够存在,是因为它善于控制成本。站在管理层来看,测试团队是一个"显著"消耗成本而又不"显著"创造价值的团队。
    (这个问题其实已经不是偏激了,纯粹是不懂,测试的目的是保证质量,带来的效果就是减少盲目的开发成本,你要是见识过太极开发了个项目化了2年,为了补bug花了三年就知道了,高质量的测试带来的绝对是最优化的资源成本,你们公司老板连这个都不知道,何必招开发呢,找几个hr mm没事点点点就行了,中软当初就这么干过)

    第二个问题,测试的发展如何?既然我们的收入又不低,那么干的就得比人家多,你说是不。人家一天接一个客人,咱就得接三个。作为测试的你,是不是有同感?

    (收入跟工作量一定成正比吗?反正我当team member的时候,一直耿耿于怀,我们pm基本上就是陪客户吃吃饭,连C和Java是啥都不知道,完全的关系型的项目经理,人家一个人拿的比我们整个团队都多,这不是更扯淡)

    那么,第二个问题的答案是什么呢?答案就是这篇文章的title,测试团队将慢慢死去!就像《黑天鹅》的作者塔勒布所讲的,这个世界是由一系列不可能发生的事件组成的。测试团队死去这件事情随时可能发生,你要做的,是要提前做好准备!
    (哈哈,这个我喜欢,理论上软件做的多了,就没啥可干的了,所以IBM自己都当投资公司去了,为啥,利润太低,所以啊,指不定那天,软件行业就拉倒了,甭管测试开发需求美工,一起死而已。现在的情形就是这样啊,为什么离岸外包一塌糊涂,就是客户不舍得花钱升级了,旧的能用,要啥新的啊)

    我喜欢描述这样一个场景,一线测试工程师对着电脑在干活儿,左边的高层管理着指着他的鼻子说"别再跟我要head count,我要控制成本!",右边的中层管理着指着他的鼻子说"去给我拓展业务,我要创造业绩!",中间的你,那一脸苦逼的表情,还用我描述吗?

    (哈,这个场景,说实话不太明白,一个测试工程师要去控制成本,去扩展业务,难道公司已经堕落到这种地步?这些东西,跟测试这个role没关系,跟你是负责哪方面的管理有关系,说白了是管理成本而已)

    我认为,测试团队的发展大概要经过这样三个阶段。
    第一阶段,公司快速扩张,不计研发成本,当然测试也不例外,每天都在非常happy的招人中。。。。
    (没计划性?产品开始的时候,连测试计划都没有,你们的测试经理估计是编简历进来的吧,面试的也该拉出去打屁股,连最起码的resource plan都没做,玩个蛋啊,乱堆积木,早晚会塌,不管那个行业)
    第二阶段,经过第一阶段的快速扩张,你的测试团队积累了大量的高级测试工程师,成本已经开始进入高层的考虑范围,技术部开始考虑适度控制成本,而此时,控制最厉害的,肯定是测试团队,当然裁员首先也会从测试团队开始。如果你幸运的没有被裁掉,不要盲目乐观,还有第三阶段。
    (还是那句话,老板太有钱了,没事招一堆高级测试工程师来,最起码的成本cost都没做过预算,看来老板不怕亏本啊)

    第三阶段,(我认为我所在的公司正处于这个阶段)严格控制测试成本,老大们开始考虑将测试工作向上游转移。此时大量的词汇开始进入我们的KPI,什么推动单元测试,推动开发自测,控制提交测试质量,等等,等等。
    讲到这里,今天的关键就出现了,如何将测试的工作向上游转移呢?答案就是第四阶段,让测试团队慢慢死去。。。。
    节省测试成本的最好方式就是把自己干掉!没错!下面我说说方法。
    (哈哈,推动单元测试,推动开发自测,控制提交测试质量...这些说不好听,是process的问题,难道现在还有开发,弄完代码直接往code base里扔,我艹,80年的程序员都知道自测了。好的测试保障,无非是将开发的那些盲目的单元测试合理化而已,user story的出现,就是为了更精确的让所有人有个共同的AC可以依据)

    测试团队当中,首先应该干掉的是纯手工测试工程师,因为他们的性价比是最低的(有些公司这个时候会选择测试外包)。然后,开发测试工程师当中出色的那部分,会加入开发团队当中,不出色的将被淘汰。他们有一项艰巨的任务,那就是,以开发自测为基础,为开发团队建立起一套完整的基于风险的质量控制体系。开发做测试不是能力问题,而是思想,思想却是最难以改变的。这也是好多人天天说要推动开发自测却没有进展的原因,没有认识到改变别人思想的工作有多难!我提的办法呢一石二鸟。开发测试工程师转入开发团队,既能节省测试成本,又可以帮助开发转变思想,以一带二,以一带三,逐步完成开发团队,全民皆测试的目标!

    (首先,干掉什么样的测试人员不依据他们的方式,很多测试本身就是只能纯手工,对于信奉automation可以100%覆盖测试范围的,我只能叹息,你的test scope小,能实现自动化程度高而已,天不是就井口那么大)

    (一般来说,测试没有推动开发的质量提高,这个是PM的问题,甚至是公司文化素质的问题,你能直接教会大字不识的人写出李白那种诗吗,什么事都得一步步来,所以,很多问题根源不是做不做,是做的时候是不是太急功近利了,没错,很多时候建立一个高质量交付团队最多的障碍就是急功近利!没等下鸡蛋,这边油锅就热了)

    (开发测试,本身就应该是在开发范畴中,是为了提供更好的测试做开发,基本上task都是和开发并行的,让开发轮流做开发测试,本身就是个定规啊)

    那么最后,测试团队中还剩什么呢?只会剩测试工具组。他们为全公司提供测试工具,平台和流程方面的支持。极少量的团队会保留纯手工测试工程师。但是,你绝对不应该看到"开发测试工程师"这个title,因为他们已经成为了开发团队中的一员,一起开发,一起测试。。。

    恩,我最讨厌title了,每个人都是不同的role,挂上一个title就不用干别的吗,最起码,一个测试人员,除了测试这个role,还有质量管理这个role,需求人员这个role,文档人员这个role,模拟客户这个role,。。。别提title,sb才觉得自己是什么title就干什么活呢)

    插一段说明,我觉得不必说,但有些人会这么想的。有人会说测试团队应该保留一些测试职位,负责集成测试,系统测试和性能测试。这样说的人很多,但绝对没有过实践经验。为什么呢? 没有与开发天天在一起讨论问题,功能测试这个阶段,怎么能做好集成,系统测试呢? 不要妄想了,这些工作也会由开发团队完成。你可能会觉得开发工程师怎么会做呢? 他们为什么不会做呢?别忘了那些转入开发团队的开发测试工程师有一项艰巨的任务,"以开发自测为基础,为开发团队建立起一套完整的基于风险的质量控制体系",其中就包括测试分工这些在测试团队习以为常的工作。我相信,开发暴发出来的测试能力是你想象不到的。

    (恩,开发的测试能力确实很好的,对代码逻辑足够了解,覆盖率高,但是,自己给自己当监督,早晚权利腐败,尤其是没有文化的项目团队,内部倾轧,都觉得自己代码好,测试的时候随手改别人的代码,测试覆盖面小,考虑的是功能实现,而不是用户体验,说实话,这样的项目做出来客户用起来不爽的例子,那是太多了,12306就是例子,基本上都是开发吧什么集成,系统啊,性能啊做完了,结果呢,出来就是一狗屎,别以为那个单独的开发牛人能一个人把一个团队带到同一个水平,水桶永远是最短的那个木板来决定容量的)

    接下来可能要转换一下角度,站在开发角度来看,他们愿意接受这样一个变化吗?答案是不一定,但只有开发负责人愿意就没问题。我不刻意想学习google,facebook那种模式,但我想说,开发懂测试是一个必然趋势,如果你不想像测试一样被淘汰的话,还是接受吧。
    (很多大的公司,本事是测试覆盖少,很多所有用户都当做免费的测试劳工的,小米的miui就是啊,海量的终端反馈,才是它的测试主体活动)

    测试是一个矛盾体,我们过去,现在,将来一直会做的事情就是让自己死掉(提升开发测试比,开发自测,等等,这些工作我们不是一直在做吗?)。

    (测试不矛盾,矛盾的是测试人员的定位,你的目的不是为了学一个自动化测试工具就是好的测试工程师,什么时候理解项目团队的质量测试体系是全面的质量控制,那就不是一个挂着测试头衔,只会点点点的文档复读机了)

    作为测试的你,能做什么呢?如果你不懂开发,要赶紧去学开发,学设计。如果你懂开发,那就还是要学开发,学设计,技术没有止境。有人跟我说"你过于强调技术,其实测试思想才是最重要的",我认可这种看法,但不完全同意。因为技术能力会束缚你的测试思想,同样也会拓宽你的测试思想。试想都不懂tcp/http协议,怎么测试web server呢? 

    (不错,做好测试,不能只会依据测试文档去覆盖功能,一个好的测试人员,可以当甲方,可以当BA,可以当SA,可以当QA,你需要多方面的知识才行,但是知识是无穷无尽的,所以,知识积累很重要。其实同理也有,你丫不懂java,你怎么给我写个jsp文件出来啊,用C#去写?)

    空谈误国,实干兴邦,牢牢把握技术才是王道!

    (测试技术和开发技术本事是一体的,技术就是技术,没有开发需要学的技术和只有测试需要学的技术,单元测试也是测试范畴啊,你别那纯粹点点点的入门手工测试工程师,又是title,来代表整个测试水平,就跟没人拿一个刚学了三天java的开发去代表开发的整体水品一个道理)


    上面这篇文章是前阶段淘宝前辈邓悟写的,感觉有一定道理,就拿过来跟大家分享下(已得到前辈同意);关于测试团队的前三个阶段发展的论述比较赞同,感觉现在好多大公司的确也有这种趋势;
    (说实话,什么叫大,外包这种纯粹堆人头的叫大?还是那些动不动拿自己当50强的it公司觉得自己大,摩托罗拉为啥没落了,那么大的公司,已经不是技术范畴内的问题了,是人的恶性导致的,就是窝里斗,甭管那个国家,人类窝里斗那是人类史的源动力,人就是地球的寄生虫)
    对于第四个阶段不发表评论,感觉测试职位只是一种合理分工的产物,如果这种分工方式对于公司来说成本相对较低,公司当然会保留;
    (对职位是职位,职责是职责,对于很多混日子的人民公仆也同样道理,只不过,公司老板烦了能开人,我们当家做主的烦了只能自己在家画圈圈。)

    对于前辈说的这种可能对于国内大多数公司感觉暂时不太可能(未来就不做猜测了),当然像淘宝这样的公司要另说;对于前辈说的“技术”,我的看法也是多多益善,但是人的精力毕竟有限,要结合实际工作做取舍。

    (没有哪个公司能逃过这种社会悲剧的,天下没有不散的筵席,没有不倒闭的公司,与制度有关,与技术无关,技术宅才是希望,瓦咔咔)
    原文链接:http://blog.sina.com.cn/s/blog_71ad0d3f0101bytk.html
  • 随遇而安(倚天屠龙记 主题曲)

    2007-08-08 11:50:57

    马锦涛版的倚天屠龙记 也许不是最好看的 但是主题歌是我看过的电视剧集里面最好听的

    随遇而安(倚天屠龙记 主题曲)
    作词:姚若龙下载
    作曲:小虫
    演唱: 黄沾

    人外有人山外有山
    不怕拼命怕平凡
    有得有失有欠有还
    老天不许人太贪
    挺起胸膛咬紧牙关
    生死容易低头难
    就算当不成英雄
    也要是一条好汉
    万般恩恩怨怨都看淡
    不够潇洒就不够勇敢
    苦来我吞酒来碗乾
    仰天一笑泪光寒
    滚滚啊红尘翻呀翻两翻
    天南地北随遇而安
    但求情深缘也深
    天涯知心长相伴

  • 景黛音

    2007-08-08 11:20:03

    

    景黛音:
      1980年《上海滩》饰阿娣 (周润发 赵雅芝 吕良伟 汤镇业合演)
      1984年《鹿鼎记》饰建宁公主 (梁朝伟 刘德华 刘嘉玲合演)
      1984年《决战玄武门》饰李洛云 (苗侨伟 黄日华 翁美玲 汤镇业合演)
      1985年《陆小凤之凤舞九天》饰薛冰 (万梓良 黄允材合演)
      1985年《雪山飞狐》饰程灵素 (吕良伟 赵雅芝 曾华倩合演)

    呵呵 居然演过我最喜欢的程灵素!

     

  • 什么叫做绝望

    2007-08-08 11:09:41

    昨天那么好的天 算的上北京一年中最适合堕落的一天了, 我居然没睡舒服了, 真是暴殓天物啊(居然google拼音没这个词)

    总体来说分为三个阶段:

    刚回家 发现同屋的猫跑到我的屋子里面大闹了一番 不过既没大小便 也没乱翻一气 就是把灯绳咬成了三节 让我怀疑他上辈子是不是做那个两条绳子计算半个小时之类的题给累死的 这辈子福来心至 老是要给大家证明一下

    只好把所有的床单 被子 枕套 衣服 都扔到洗衣机里面消毒去了

    然后打开了昨天下的陆小凤传奇, 发现薛冰挺好看. 呵呵 一大堆老面孔, 虽然不知道名字, 只是些 死跑龙套的. 演员表如下: 

       领衔主演:万梓良、陈秀珠、欧阳震华、景黛音、
                黄允材、刘江、李香琴、陈洁仪、吴君如 

    没注意谁是吴君如, 不过欧阳振华好年轻啊 也没那么胖 就是没现在那么好玩了 不容易啊 85年的片子 到了2000年人才红

    然后到点睡觉

    结果做了几个梦 只有一个记得很清楚:

    似乎俺成某个地方的老大, 但是不作恶的那种, 有一天不知道怎么回事 就杀了人了 就跑 路边拦了一个黑车 开车的是石头里面的黑狗 跑啊跑 居然跑到当初住过的地下室了

    结果被人认了出来 居然成了国安局的卧底神探了 乱起八糟的 呵呵

    印象最深的是当时被人认出来的时候那种绝望感, 整个人浑身沉巅巅的, 但是有觉得自己空无一物, 明明要晕过去 却神志非常清楚 想要瘫倒 发现原来这样也要花力气能控制整个自己才行

    整个人就跟悬在空中 浑身上下都压力十足 偏偏还感觉浑身不着力 在那一个 真是绝望了 一切一切都是空啊

    呵呵 醒来了 浑身也没啥不舒服的 就是觉得这个梦有点太真实了 绝对的绝望感觉啊 不错不错 算是很好的体验

     

  • 夹起品格做人!

    2007-08-08 10:37:28

     
    转贴一下, 什么叫做品格呢?
     
    什么叫品格?品者,次第也;格者,标准也。品格就是有等次的标准,合乎等次的标准的东西,是够等级够资格的人和事。也就是说,品格就是有品味的人格。品味就是层次,品味就是不俗,品味就是高雅,所以讲品味就是具有高雅层次的、不平庸入俗的人格。
     
     呵呵, 由此看来, 所谓品格, 就是一个人具有了讲究品味的高雅的人格. 所谓雅, 要从风雅颂讲起:
     
    风。是不同地区的地方音乐。《风》诗是从周南、召南、邶、鄘、卫、王、郑、齐、魏、唐、秦、陈、桧、曹、豳等15个地区采集上来的土风歌谣。共160篇。大部分是民歌。
    雅。是周王朝直辖地区的音乐,即所谓正声雅乐。《雅》诗是宫廷宴享或朝会时的乐歌,按音乐的不同又分为《大雅》31篇,《小雅》74篇,共105篇。除《小雅》中有少量民歌外,大部分是贵族文人的作品。
    颂。是宗庙祭祀的舞曲歌辞,内容多是歌颂祖先的功业的。《颂》诗又分为《周颂》31篇,《鲁颂》4篇,《商颂》5篇,共40篇。全部是贵族文人的作品。从时间上看,《周颂》和《大雅》的大部分当产生在西周初期;《大雅》的小部分和《小雅》的大部分当产生在西周后期至东迁时;《国风》的大部分和《鲁颂》、《商颂》当产生于春秋时期。从思想性和艺术价值上看,三颂不如二雅,二雅不如十五国风
     
    由此可见 雅 最早是指的音乐 也就是说高雅 就是那些有地位有特权才有能力听的宫廷歌曲.
     
    呵呵 所以说品格就是所谓的贵族气质. 夹起了贵族气质做人, 说白了 就是做人不作派.
     
    呜呼挨宰, 这年头连贵族气质都没几个人能撑的起来, 何况品格啊. 所以书呆子们都自我麻痹, 万般皆下品,唯有读书高啊. 啥时候你成了个只会死要面子的书呆子了, 恭喜你, 你有品味了, 品格高尚了, 反正你也不在乎别人说什么, 呵呵.
     
    所以总结一句 品格, 就是yy到极点, 不要也罢!
  • 人生得积累

    2007-08-06 11:39:13

    呵呵 晃一晃 做测试也6年了. 很多感悟 该花点时间整理一下了
Open Toolbar