发布新日志

  • 转:保持工作热情的一点看法

    2011-05-25 11:12:24

    迈入工作10年生涯,有团队邀请我结合实际案例简单聊聊"工作热情",附上我自己的理解,希望能对大家有所帮助。像很多成长课程一样,本文也是知易行难,实践是消化的唯一之道。

    一 热情的正反表现

    正:

    冲劲十足,执行力强
    自我驱动、要性强
    坚持如初,有感染力、激情四射

    反:

    被动接受任务,分外工作
    安于现状
    冷却,平淡


    你身边的榜样特质又是怎么样的呢?

    二热情来源

    1做事获取成就感,收获成长,自我鼓励、他人肯定,长期正反馈
    2做自己喜欢做并且擅长的事情
    3挖掘工作中乐趣,保持好奇心、新鲜感,了解底层原理、实现细节
    4适当危机感,持续高标准自我要求,把事情做到极致
    5明确阶段性目标,把握节奏,好心态

    三 热情消退的方式

    1经常性挫折,心累,很有无力感
    2缺乏反馈,不受重视
    3单纯重复性、事务性工作
    4目标过高或者安于现状,自我定位过高,过多比较、计较心

    四保持热情的一些做法

    和上述消退呼应。

    1 不逃避问题,寻求支持,借用团队力量,点滴进步、沉淀到量变导致质变
    2从不同角色、角度获取尽早反馈,管理上司
    3 换角度思考、思维创新,交流碰撞,开拓思路,反思深度、广度是否够
    4目标跳一跳就够着,分解到可执行,调整心态,做好持久战准备
    5适当自我调节,他人低谷
    6 重复N次变成习惯

  • 不能这么沉沦下去...

    2008-12-26 14:13:40

    最近发生了一些事情,不想说的太明白,但是它们确确实实的影响了我的心情.

    然后这两天我也发现自己早上起床的动力有点不足了,开始想赖床了.说实话我很讨厌赖床的时候还想着我不能样子的想法.所以一般我会选择在周末休息的时候好好休息一下,然后在平时上班时间准时起床,出门.

    可能是天开始真正冷了吧,可是这不应该是原因啊.我已经进入了人生另一个最重要的阶段,我想对自己说:"向着目标沉稳的走下去".没有什么事业是可以在被窝里完成的.加油...

  • 又快过年了...

    2008-12-22 10:25:35

    又快过年了...

    没一点点激动和兴奋, 前些天又发现多了两根白发, 很白很白, 从发梢到发根都白了, 白的有些晶莹剔透.

    是不是我已经到了白发的年龄了? 一到阴天, 心情还是莫名的低落, 心很虚, 盼着回家, 可又不知道回去除了看

    看父母还有什么可以做的.

  • 网站测试的系统测试方法

    2008-09-16 11:09:44

    Web的系统测试方法

    随着Internet和Intranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。

      Yogesh Deshpande和SteveHansen在1998年就提出了Web工程的概念。Web工程作为一门新兴的学科,提倡使用一个过程和系统的方法来开发高质量的基于Web的系统。它"使用合理的、科学的工程和管理原则,用严密的和系统的方法来开发、发布和维护基于Web的系统"。目前,对于web工程的研究主要是在国外开展的,国内还刚刚起步。

      在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对Web和Internet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。

      在Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,Internet和Web媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

      一般软件的发布周期以月或以年计算,而Web应用的发布周期以天计算甚至以小时计算。Web测试人员必须处理更短的发布周期,测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的Web应用系统的转变。

      一、功能测试

      1、链接测试

      链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。

      链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

      2、表单测试

      当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

      3、Cookies测试

      Cookies通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

      如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

      4、设计语言测试

      Web设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如Java、Javascrīpt、ActiveX、VBscrīpt或Perl等也要进行验证。

      5、数据库测试

      在Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

      在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

      二、性能测试

      1、连接速度测试

      用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

      另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

      2、负载测试

      负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

      3、压力测试

      负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

      进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

      压力测试的区域包括表单、登陆和其他信息传输页面等。

      三、可用性测试

      1、导航测试

      导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

      在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

      导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

      Web应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

      2、图形测试

      在Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

      (1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

      (2)验证所有页面字体的风格是否一致。

      (3)背景颜色应该与字体颜色和前景颜色相搭配。

      (4)图片的大小和质量也是一个很重要的因素,一般采用JPG或GIF压缩。

      3、内容测试

      内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

      信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word的"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"。

      4、整体界面测试

      整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?
    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

      对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

      四、客户端兼容性测试

      1、平台测试

      市场上有很多不同的操作系统类型,最常见的有Windows、Unix、Macintosh、Linux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

      因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

      2、浏览器测试

      浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、Javascrīpt、ActiveX、plug-ins或不同的HTML规格有不同的支持。例如,ActiveX是Microsoft的产品,是为Internet Explorer而设计的,Javascrīpt是Nets
  • 需求跟踪矩阵与需求双向跟踪

    2008-08-26 09:18:59

    刚刚接触CMMI的人在研究Requirement Management这个PA的时候,对SP 1.4 Maintain Bidirectional Traceability of Requirements可能会比较疑惑,足以让国内大多数的没有真正软件工程开发管理的软件工程师,开发管理者不知所云了。
    所谓的&ldquoTraceability of Requirements&rdquo即&ldquo需求跟踪矩阵(Requirements Traceability Matrix)&rdquo,用比较通俗的话来说,就是不要将需求遗漏了,虽然听来简单,但是真正能够实施此活动的并不多,通常来做的多为 &ldquo纵向跟踪(Vertical traceability)&rdquo,也即生命周期内的跟踪,再说的明白一点就是沿着&ldquo用户需求――软件需求――概要设计――详细设计――编码实现――单元测试――集成测试――集成测试――系统测试――验收测试&rdquo进行需求的跟踪。

    What is bidirectional traceability?


    In the Requirements Management (REQM) process area, specific practice 1.4 states, ?Maintain bidirectional traceability among the requirements and the project plans and work products.? Bidirectional traceability primarily applies to vertical traceability and at a minimum needs to be implemented both forward and backward (i.e., from requirements to end products and from end product back to requirements).


    Vertical traceability identifies the origin of items (e.g., customer needs) and follows these same items as they travel through the hierarchy of the Work Breakdown Structure to the project teams and eventually to the customer. When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.


    Horizontal traceability is also important and is mentioned in subpractice 3, but it is not required to satisfy bidirectional traceability. Horizontal traceability identifies the relationships among related items across work groups or product components for the purpose of avoiding potential conflicts. It enables the project to anticipate potential problems (and mitigate or solve them) before integration testing. For example, horizontal traceability would follow related requirements across two work groups working on two associated components of a product. The traceability across these two work groups enables the work groups to see when and how a change in a requirement for one of the components may affect the other component. Thus, horizontal traceability enables the project to anticipate potential problems (and mitigate or solve them) before integration testing.


    纵向跟踪是最普遍的一种跟踪方式,也是CMMI进行SCAMPI最低要求。即针对此PA,或者说这个SP,做到纵向跟踪后,一般的主任评估师就认为已经满足条件了,可以打及格分数了。
    CMMI V1.1版本中的要求是:RM SP 1.4 Maintain Bi-directional Traceability of Requirements.
    其具体要求是:Maintain bi-directional traceability among the requirements and the project plans and work products.
    CMMI V1.2版本中的要求是:RM SP 1.4 Maintain Bi-directional Traceability of Requirements.
    其具体要求是:Maintain bidirectional traceability among the requirements and work products.
    大家从描述上就能看到区别了。
    《CMMI® Version 1.2 and Beyond》中的描述如下:
    v1.2 SP 1.4 practice statement now reads, &ldquoMaintain bidirectional traceability among the requirements and work products.&rdquoProject plans are no longer mentioned in this SP statement.
    Bidirectional Traceability descrīption is improved in the notes and Glossary.

    这个也证明了SEI发现了此SP的描述或者要求和实际的有出入,难以执行;但是为什么呢?
    其实大家在google上搜索一下关键字&ldquobidirectional traceability &rdquo就会发现很多的资料在解释&ldquobidirectional traceability &rdquo,即所谓的&ldquoVertical
    traceability &rdquo和&ldquoHorizontal traceability &rdquo时,概念并不统一,而且对于&ldquoVertical
    traceability &rdquo和&ldquoHorizontal traceability &rdquo的概念解释甚至是相反的。

    话说了这么多,其实归根到底的原因是:什么是&ldquo横向跟踪&rdquo(Horizontal traceability )?
    SEI的Tim Kasse(CMMI模型制定者之一)在其著作《Practical Insight into CMMI》中曾经对&ldquo横向跟踪&rdquo(Horizontal traceability )进行了如下解释:
    Horizontal traceability refers to the traceability from the requirements to the associated plans such as the project plan, quality assurance plan, Configuration Management plan, risk management plan, and so forth.
    即横向跟踪是需求到计划的跟踪。

    文章链接:http://bbs.51testing.com/viewthread.php?tid=74646
  • 奥运男篮:China VS Spain

    2008-08-13 10:19:47

    相信大多数篮球迷都看了昨晚China vs Spain的比赛了!

    比赛一度让我感觉赢Spain有戏,前三节三分雨下的很好,大致昨晚也确实打得不错!

    可是中国队后卫上的短缺永远都是块心病,前场包夹失误立马增多的场景都见怪不怪了!

    可是中国在内线应该还是有一定的优势的,实际情况却是:

    姚明被Gasol打爆了,太空易状态低迷,原本被人寄予厚望的2个点都歇菜了!这样的比赛还能赢么?

    尤纳斯最后的换人固然有问题,可是姚明,太空易也应该对这场失利负责!

    不管怎样,这场比赛至少打出了自己的风格。这点值得欣慰!自家球队,能力再差还得继续顶......

    中国队加油......

Open Toolbar