分享知识,共同进步

发布新日志

  • 【翻页功能】的测试用例

    2010-08-09 17:42:27

    【翻页功能】的测试用例

    朋友的记录:
      翻页功能我们常碰到的一般有以下几个功能: 
      1、首页、上一页、下一页、尾页。 
      2、总页数,当前页数 
      3、指定跳转页 
      4、指定每页显示条数 

      当然,有一些是少于多少页,全部以数字的形式显示,多于多少页后,才出现下一页的控件。本文暂且用以上四点来做为通用的用例来设计吧。 

      对于1翻页链接或按钮的测试,主要要检查的测试点有: 
      1、有无数据时控件的显示情况 
      2、在首页时,首页和上一页是否能点击 
      3、在尾页时,下一页和尾页是否能点击 
      4、在非首页和非尾页时,四个按钮功能是否正确 
      5、翻页后,列表中的记录是否仍按照指定的排序列进行了排序 

      对于2总页数,当前页数,主要要检查的测试点有: 
      1、总页数是否等于总的记录数/指定每页条数 
      2、当前页数是否正确 

      对于3指定跳转页,主要要检查的测试点有: 
      1、是否能正常跳转到指定的页数 
      2、输入的跳转页数非法时的处理 

      对于4指定每页显示条数,主要要检查的测试点有: 
      1、是否有默认的指定每页显示条数 
      2、指定每页的条数后,列表显示的记录数,页数是否正确 
      3、输入的每页条数非法时的处理 

      分析完上面的测试点,应该可以进行用例的设计了。 
      step 1: 列表无记录   
      expect: 1、四个翻页控件变灰不可点击 
               2、列表有相应的无数据信息提示 
               3、不可指定页数 
               4、不可指定跳转页 
               5、总页数显示为0 
               6、当前页数显示为0 

      step 2: 列表的记录数 <= 指定的每页显示条数 
      expect: 1、四个翻页控件变灰不可点击 
               2、总页数显示为1 
               3、当前页数显示为1 

        step 3: 列表的记录数>指定的每页显示条数 
      expect: 1、默认在首页,当前页数为1               
               2、列表的数据按照指定的排序列正确排序 
               3、记录数与数据库相符 
               4、总页数=记录数/指定的每页显示条数 

      step 4: 列表的记录数 > 指定的每页显示条数,在首页 
      expect: 1、首页变灰不可点击 
               2、上一页变灰不可点击 
               3、下一页可点击,从(每页指定条数+1)条记录开始显示,当前页数+1 
               4、尾页可点击,显示最后页的记录 

      step 5: 列表的记录数 > 指定的每页显示条数,在中间的某页 
      expect: 1、首页可点击,显示1到每页指定条数的记录 
               2、上一页可点击,显示上一页的记录 
               3、下一页可点击,从后一页的记录 
               4、尾页可点击,显示最后页的记录 
               5、列表的数据按照指定的排序列正确排序 
               6、当前页数为所在页 

      step 6:列表的记录数 > 指定的每页显示条数,在尾页 
      expect: 1、首页可点击,显示1到每页指定条数的记录 
               2、上一页可点击,显示上一页的记录 
               3、下一页变灰不可点击 
               4、尾页变灰不可点击 
               5、列表的数据按照指定的排序列正确排序 
               6、当前页数为最后一页的页数 

      step 7:输入每页显示条数为正整数 
      expect: 1、每页显示条数更新成指定的条数 
               2、超过指定的条数的记录分页显示 
               3、总页数更新成列表的记录数/每页显示条数 

      step 8:输入每页显示条数为0 
      expect: 1、提示“每页显示条数必须为大于1的整数” 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 9:输入每页显示条数为负数 
      expect: 1、提示每页显示条数必须为大于1的整数 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 10:输入每页显示条数长度超过数据库指定的长度<<<maxlen>>> 
      expect: 1、提示每页显示条数不能超过<<<maxlen>>>位 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 11:输入每页显示条数为字符串,如中文翻页数 
      expect: 1、提示每页显示条数必须为大于1的整数 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 12:输入每页显示条数为特殊字符,如% 
      expect: 1、提示每页显示条数必须为大于1的整数 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 13:输入每页显示条数为html字符串,如<br> 
      expect: 1、提示每页显示条数必须为大于1的整数 
               2、提示后每页显示条数恢复为上次生效的条数 

      step 14:输入跳转的页数为存在的页数 
      expect: 1、正确跳转到指定的页数 

      step 15:输入跳转的页数不存在或非法值 
      expect: 1、跳转的页数值置为1,显示第一页的数据 
      以上的用例是将总页数,当前页数都揉进了翻页控件的测试用例中了。
     
    ------------一位高人的补充
    补充点自己的看发:
    1.要看具体的需求,本文提供的只是一个比较常用的测试设计,学东西应该是取其精华才对.比如STEP12就有不值得取的地方("提示":以什么做提示呢?AJAX方式的,JS形式的等等情况,所以要看需求来)
    2.该用力设计并没有写明去验证数据库.对于分页的操作个人认为应该充分测试数据库情况.
    3.网络差造成重复提交怎么办?怎么处理?数据完整性可是必须的哦!!!!! 
     
     
  • 企业级项目开发:究竟距离我们有多远?

    2010-08-09 09:05:26

    企业级项目开发:究竟距离我们有多远?
        一直以来,我们都在不停得做项目,赶项目。相信从大家开始做项目到现在,做过了很多大大小小的项目,或多或少也有让自己很引以为豪的成功了的项目。大家回头想想,我们的项目一般是怎么做出来的!每个公司有不同的做法,但是起码在有些方面还是差不多的。本篇的议题如下:

        1 . 项目开发的现状

        2. 什么是企业级项目

        1 . 项目开发的现状

        一直以来,我们都在不停得做项目,赶项目。相信从大家开始做项目到现在,做过了很多大大小小的项目,或多或少也有让自己很引以为豪的成功了的项目。大家回头想想,我们的项目一般是怎么做出来的!每个公司有不同的做法,但是起码在有些方面还是差不多的。

        每次项目到来,几次会议之后,项目就开始了,开始分配人员,开始分析一些从客户那里拿来的需求,然后一些骨干的开发人员就开始为项目搭架子。于是一个项目就算是进行起来了。谈到了为项目搭架子,专业点说就是做架构了,说是做架构,其实就是把项目按照惯例分割为几个逻辑层,至于说这个架构好不好,有什么风险,是否可以适应以后的变化,采用的技术的风险和可行性分析,这些很少考虑,原因很简单:一般的都是这么开发的,应该没有什么大的问题。确实,很多的项目也确实是这样的开发的,而且很多也成功了。这些无可厚非,至于说什么标准不标准,是否遵循了什么开发的原则,没有多少人在乎,不管怎样,项目是成功了。

        项目开发中,很多的原则我们是很清楚:什么单一职责,依赖反转,什么可测试性,维护性.....很多时候,在coding的时候,这些原创反倒成了多余,项目最后成为了功能代码的堆积,特别是在赶项目的过程中,代码堆积的效果就更加明显了:只要把功能搞定,其他的以后再说。可以往往这个“以后再说”就成为了“永不再说”。这个也无可厚非。

        就这样,一年又一年,开发项目,做项目,赶项目。而且很多人对做软件开发没有什么兴趣了:原本以为软件开发是一种高智商的活动,现在发觉有点像是体力活。一年一年,我们为一个个不同的客户开发出一个个不同的系统。

        相信很多公司也常常提出很多很“诱人”的口号:通过做大量的项目,积累和开发通用组件,组件越多,以后开发就是仅仅只是堆积木了....但是真正的项目中,客户不停在催,上头也在催,最后就没有人顾及什么通用不通用了。项目开发是越做越累,相信这也是很多开发人员转行和转型的原因之一吧。

        2. 什么是企业级项目

        企业级项目是什么? 为一个企业,机构,客户公司开发的项目就算得上是企业级项目了吗?一个很大的项目就是企业级项目吗?一个小的项目就算不上是企业级项目?

        其实,一直以来,我个人也对什么是“企业级”的概念不是很清晰。只是天天是在这么说。

        说到企业级项目,随着而来的有很多概念:企业级架构,企业级开发。

        但是不管怎么说:企业级这个概念和项目的大小是没有什么很大的关系的,甚至可以说是几乎没有什么关系。

        其实企业级项目其实就是一带着一种“企业级”的思想来做项目。

        在文章中的第一部分,我们到了现在我们做项目的方式:代码的功能“堆积”。通过这种堆积出来的代码就仅仅只是用于这一个项目,对于以后其他的项目几乎是没有什么用处的,也就说代码的重用行不够,而且往往在一个项目中,很多的代码都是杂七杂八的,很多相似的功能都是各自搞出一套代码。诸如之类的问题,导致项目越做越累,很多美丽的口号化为泡沫。

        企业级的项目起码有以下几个特征:

        稳定性
        灵活性
        隔离性
        重用性
        维护性
        相信这些特性大家都不陌生,这些特性我就不具体的解析,大家都清楚。说了这些多,可能大家认为我说的是废话,屁话,但是有一点可以说的:现在我们开发项目确实很多的时候忽略了这些东西,因为这个忽略,确实使得项目项目的开发加快,但是从长期的来看,项目开发还是越来越累的。如果在开发的时候,每次带着一点点这样的思考,尽量写出符合那些特性的代码,慢慢的,一种“企业级的心智”就慢慢出来了,一个很类似的比喻:在项目中,遇到了一个很难的技术问题,我们往往花很多的时间来攻克,最后终于搞定。确实这个攻克的过程我们从思维上可以这样分析:我们思维和问题的答案之间隔了一道墙,我们一次次的尝试各种解决方案去攻克问题的时候,我们的思维一次次的在撞击这道墙,最后墙被撞破,我们也得到了问题的解决方案。

        同理,我们在项目中带着“企业级”思维,我们就在一点点的撞击那道“墙”,最后的结果就是:通用的功能被封装为了通用的组件,为以后的项目的留下积累。

        这里我不是说教,本人的“企业级的心智”也没有,但是因为带着这个思想作项目,个人认为思想有了提升,而且还真的得到了不少通用的组件,虽然说组件善待完善,但是已经有了些甜头。

  • 前车之鉴 软件项目评估失败的十个原因

    2010-08-09 08:59:34

    前车之鉴 软件项目评估失败的十个原因

      回想一下你已经完成的网络和软件项目,当初估算了多长时间和多少费用?有多少估算是准确的?IT项目几乎都会超出预期,也意味着大部分软件项目的估算都是失败的,这是为什么呢?原因有很多,本文仅列举其中10个重要的原因。

      1、项目范围边界未确定好

      当你对项目尚不了解的情况下,你是如何估算项目需要的时间的?很难找出一位客户可以准确地说出他们的系统应该如何运行。

      我参与的每一个大型项目几乎无一例外都要求系统具有“灵活性”,换句话说就是,客户希望系统能处理将来需要处理的一切,但他们也说不清究竟需要什么功能,因此,“灵活性”本质上不是系统需求,因为它是一个模糊的概念。

      2、开发时间由非程序员估算

      如果你不是程序员,不要私自猜测开发需要的时间,如果项目经理象写小说那样虚构估算,项目注定会失去控制,开发时间的估算应该听取程序员的意见。

      3、开发人员的估算太过乐观

      开发人员估算时间一般都只考虑了编码需要的时间,另外,每个人的开发速度和效率都不一样,许多开发人员在估算开发时间时都过于乐观,他们往往会忽略掉诸如项目管理,需求整理,讨论,缺勤,电脑问题等因素。

      4、没有充分解剖项目

      对于一个独立的功能,如果估算的开发时间超过了一周就要小心了,象这样的功能应该进一步细分,这样开发人员可以更详细地分析更复杂的问题。

      5、估算多少时间就使用多少时间

      给一个程序员5天时间让他完成一个任务,他就一定会用5天时间,软件开发是可以无级变速的,任何代码都可以进行改善,如果开发人员只花了3天就完成了任务,他们会用剩下的时间来调整代码或干脆做其它事情。

      遗憾的是,这将会导致估算时间成为开发所需的最小时间,实际交付时间只能被进一步推迟。

      6、开发人员多!=开发速度快

      一个需要耗时100天的项目不可能用100个开发人员1天就完成了,开发人员越多只会导致项目复杂性呈指数级增长。

      7、项目范围变更

      这可能是每个开发人员感觉最头疼的问题,有时是应客户的要求对功能进行修改或添加,有时会是CEO一时兴起,觉得某个功能很酷就要求加上或修改。

      8、估算被固定

      估算应是一个持续的过程,应随系统的开发进度不断更新,程序员往往会认为他们能够弥补逝去的时间,但却很少有人真正做到。

      9、遗忘了测试时间

      要让开发人员自己测试自己的代码是不现实的,他们知道代码是如何工作的,因此会潜意识地使用一个特殊的测试方法,通常,测试和调试时间需要占到开发时间的50%。

      10、估算得太死

      非程序员很少能体会到软件开发的复杂性,因此很少有项目计划不被迫延后,影响项目进展的因素很多,估算时如果不预留部分机动时间,最终只会是一个失败的估算。

      开发延迟会导致代价高昂的连锁反应,遗憾的是,出了问题大家都喜欢将责任归咎于底层的程序员,这样下去对以后的项目也会不利,因为程序员会吃一盏长一智,下一次他们要么拒绝提供估算时间,要么会夸大开发时间。

      不知道你现在的项目是否处于失控的状态,谈谈你对项目估算失败的其它原因吧!

    英文原文链接:http://www.sitepoint.com/blogs/2010/07/29/10-reasons-why-software-project-estimates-fail/

  • 63个国外优秀测试网站地址

    2010-08-05 18:29:19


    63个国外优秀测试网站地址
    http://bdonline.sqe.com/ 一个关于网站测试方面的网页,对这方面感兴趣的人可以参考
    http://citeseer.nj.nec.com/ 一个丰富的电子书库,内容很多,而且提供著作的相关文档参考和下载,是作者非常推荐的一个资料参考网站
    http://groups.yahoo.com/group/LoadRunner 性能测试工具LoadRunner的一个论坛
    http://groups.yahoo.com/grorp/testing-paperannou-nce/messages 提供网站上当前发布的软件测试资料列表
    http://satc.gsfc.nasa.gov/homepage.html 软件保证中心是美国国家航天局(NASA)投资设立的一个软件可靠性和安全性研究中心,研究包括了度量、工具、风险等各个方面
    http://seg.iit.nrc.ca/English/index.html 加拿大的一个研究软件工程质量方面的组织,可以提供研究论文的下载
    http://sepo.nosc.mil/ 内容来自美国SAN DIEGO的软件工程机构(Sofrware Engineering Process Office)主页,包括软件工程知识方面的资料
    http://www.asq.org/ 是世界上最大的一个质量团体组织之一,有着比较丰富的论文资源,不过是收费的
    http://www.automated-testing.com/ 一个自动化软件测试和自然语言处理研究页面,属于个人网页,上面有些资源可供下载
    http://www.benchmarkresources.com/ 提供有关标杆方面的资料,也有一些其它软件测试方面的资料
    http://www.betasoft.com/ 包含一些流行测试工具的介绍、下载和讨论,还提供测试方面的资料
    http://www.brunel.ac.uk/~csstmmh2/vast/home.html VASTT研究组织,主要从事通过切片技术、测试技术和转换技术来验证和分析系统,对这方面技术感兴趣的人是可以在这里参考一些研究的项目及相关的一些主题信息
    http://www.cc.gatech.edu/aristotle/ Aristole研究组织,研究软件系统分析、测试和维护等方面的技术,在测试方面的研究包括了回归测试、测试套最小化、面向对象软件测试等内容,该网站有丰富的论文资源可供下载
    http://www.computer.org/ IEEE是世界上最悠久,也是在最大的计算机社会团体,它的电子图书馆拥有众多计算机方面的论文资料,是研究计算机方面的一个重要资源参考来源
    http://www.cs.colostate.edu/testing/ 可靠性研究网站,有一些可靠性方面的论文资料
    http://www.cs.york.ac.uk/testsig/ 约克大学的测试专业兴趣研究组网页,有比较丰富的资料下载,内容涵盖了测试的多个方面,包括测试自动化、测试数据生成、面向对象软件测试、验证确认过程等
    http://www.csr.ncl.ac.uk/index.html 学校里面的一个软件可靠性研究中心,提供有关软件可靠性研究方面的一些信息和资料,对这方面感兴趣的人可以参考
    http://www.dcs.shef.ac.uk/research/groups/vt/ 学校里的一个验证和测试研究机构,有一些相关项目和论文可供参考
    http://www.esi.es/en/main/ ESI(欧洲软件组织),提供包括CMM评估方面的各种服务
    http://www.europeindia.org/cd02/index.htm 一个可靠性研究网站,有可靠性方面的一些资料提供参考
    http://www.fortest.org.uk/ 一个测试研究网站,研究包括了静态测试技术(如模型检查、理论证明)和动态测试(如测试自动化、特定缺陷的检查、测试有效性分析等)
    http://www.grove.co.uk/ 一个有关软件测试和咨询机构的网站,有一些测试方面的课程和资料供下载
    http://www.hq.nasa.gov/office/codeq/relpract/prcls-23.htm NASA可靠性设计实践资料
    http://www.io.com/~wazmo/ Bret Pettichord的主页,他的一个热点测试页面连接非常有价值,从中可以获得相当大的测试资料,很有价值
    http://www.iso.ch/iso/en/ISOOnline.frontpage 国际标准化组织,提供包括ISO标准系统方面的各类参考资料
    http://www.isse.gmu.edu/faculty/ofut/classes/ 821-ootest/papers.html 提供面向对象和基于构架的测试方面著作下载,对这方面感兴趣的读者可以参考该网站,肯定有价值
    http://www.ivv.nasa.gov/ NASA设立的独立验证和确认机构,该机构提出了软件开发的全面验证和确认,在此可以获得这方面的研究资料
    http://www.kaner.com/ 著名的测试专家Cem Kanner的主页,里面有许多关于测试的专题文章,相信对大家都有用。Cem Kanner关于测试的最著名的书要算Testing Software,这本书已成为一个测试人员的标准参考书
    http://www.library.cmu.edu/Re-search/Engineer- ingAndSciences/CS+ECE/index.html 卡耐基梅陇大学网上图书馆,在这里你可以获得有关计算机方面各类论文资料,内容极其庞大,是研究软件测试不可获取的资料来源之一
    http://www.loadtester.com/ 一个性能测试方面的网站,提供有关性能测试、性能监控等方面的资源,包括论文、论坛以及一些相关链接
    http://www.mareinig.ch/mt/index.html 关于软件工程和应用开发领域的各种免费的实践知识、时事信息和资料文件下载,包括了测试方面的内容
    http://www.mtsu.ceu/-storm/ 软件测试在线资源,包括提供目前有哪些人在研究测试,测试工具列表连接,测试会议,测试新闻和讨论,软件测试文学(包括各种测试杂志,测试报告),各种测试研究组织等内容
    http://www.psqtcomference.com/ 实用软件质量技术和实用软件测试技术国际学术会议宣传网站,每年都会举行两次
    http://www.qacity.com/front.htm 测试工程师资源网站,包含各种测试技术及相关资料下载
    http://www.qaforums.com/ 关于软件质量保证方面的一个论坛,需要注册
    http://www.qaiusa.com/ QAI是一个提供质量保证方面咨询的国际著名机构,提供各种质量和测试方面证书认证
    http://www.qualitytree.com/ 一个测试咨询提供商,有一些测试可供下载,有几篇关于缺陷管理方面的文章值得参考
    http://www.rational.com/ IBM Rational的官方网站,可以在这里寻找测试方面的工具信息。IBM Rational提供测试方面一系列的工具,比较全面
    http://rexblackconsulting.com/Pages/publicat-ions.htm
    Rex Black的个人主页,有一些测试和测试管理方面的资料可供下载
    http://www.riceconsulting.com/ 一个测试咨询提供商,有一些测试资料可供下载,但不多
    http://www.satisfice.com/ 包含James Bach关于软件测试和过程方面的很多论文,尤其在启发式测试策略方面值得参考
    http://www.satisfice.com/seminars.shtml 一个黑盒软件测试方面的研讨会,主要由测试专家Cem Kanar和James Bach组织,有一些值得下载的资料
    http://www.sdmagazine.com/ 软件开发杂志,经常会有一些关于测试方面好的论文资料,同时还包括了项目和过程改进方面的课题,并且定期会有一些关于质量和测试方面的问题讨论
    http://www.sei.cmu.edu/ 著名的软件工程组织,承担美国国防部众多软件工程研究项目,在这里你可以获俄各类关于工程质量和测试方面的资料。该网站提供强有力的搜索功能,可以快速检索到你想要的论文资料,并且可以免费下载
    http://www.soft.com/Institute/HotList/ 提供了网上软件质量热点连接,包括:专业团体组织连接、教育机构连接、商业咨询公司连接、质量相关技术会议连接、各类测试技术专题连接等
    http://www.soft.com/News/QTN-Online/ 质量技术时事,提供有关测试质量方面的一些时事介绍信息,对于关心测试和质量发展的人士来说是很有价值的
    http://www.softwaredioxide.com/ 包括软件工程(CMM,CMMI,项目管理)软件测试等方面的资源
    http://www.softwareqatest.com/ 软件质量/测试资源中心。该中心提供了常见的有关测试方面的FAQ资料,各质量/测试网站介绍,各质量/测试工具介绍,各质量/策划书籍介绍以及与测试相关的工作网站介绍
    http://www.softwaretestinginstitute.com/ 一个软件测试机构,提供软件质量/测试方面的调查分析,测试计划模板,测试WWW的技术,如何获得测试证书的指导,测试方面书籍介绍,并且提供了一个测试论坛
    http://www.sqatester.com/index.htm 一个包含各种测试和质量保证方面的技术网站,提供咨询和培训服务,并有一些测试人员社团组织,特色内容是缺陷处理方面的技术
    http://www.sqe.com/ 一个软件质量工程服务性网站,组织软件测试自动化、STAR-EASE、STARWEST等方面的测试学术会议,并提供一些相关信息资料和课程服务
    http://www.stickyminds.com/ 提供关于软件测试和质量保证方面的当前发展信息资料,论文等资源
    http://www.stqemagazine.com/ 软件策划和质量工程杂志,经常有一些好的论文供下载,不过数量较少,更多地需要通过订购获得,内容还是很有价值的
    http://www.tantara.ab.ca/ 软件质量方面的一个咨询网站,有过程改进方面的一些资料提供
    http://www.tcse.org/ IEEE的一个软件工程技术委员会,提供技术论文下载,并有一个功能强大的分类下载搜索功能,可以搜索到测试类型、测试管理、 测试分析等各方面资料
    http://www.testing.com/ 测试技术专家Brain Marick的主页,包含了Marick 研究的一些资料和论文,该网页提供了测试模式方面的资料,值得研究。总之,如果对测试实践感兴趣,该网站一定不能错过
    http://www.testingcenter.com/ 有一些测试方面的课程体系,有一些价值
    http://www.testingconferences.com/asiastar/home 著名的AsiaStar测试国际学术会议官方网站,感兴趣的人一定不能错过
    http://www.testingstuff.com/ Kerry Zallar的个人主页,提供一些有关培训、工具、会议、论文方面的参考信息
    http://www-sqi.cit.gu.edu.au/ 软件质量机构,有一些技术资料可以供下载,包括软件产品质量模型、再工程、软件质量改进等

    欢迎转载此文,转载时请注明文章来源:文斯测试技术研究中心 http://blog.csdn.net/vincetest
  • 好产品的简洁之道

    2010-08-05 09:13:24

    好产品的简洁之道
    MG Siegler曾写过一篇博文《Keep It Simple, Stupid》,为我们分享了“简洁意味着优雅,引领产品走向成功;复杂表现出臃肿,导致产品走向失败”的观点,个人网站《想飞的翅膀》的楼主笑炊(网名)对此文进行了翻译,现转载于此,供大学借鉴学习:
    做好产品的Kiss原则:Keep it simple,Stupid
    每当我审视创业公司的时候,脑海里总冒出这句话。很多创业公司似乎想同时做好一百件事情,这通常是个坏主意。据我观察,多数公司都失败于想做的事情太复杂。
    表面上看,为用户提供更多的选择,让他们决定用什么,怎么用,似乎没有问题。但是做一个决定对用户就相当于设置一个障碍,通常用户也做不了什么英明的决定,笨用户多了去了。或许他们需要一个学习的过程,渴望被正确地引导。
    拿Twitter举个例子吧,你可以用140个字说正在做什么,就这么简单。但它很快就超越了这种简单的概念,创始人当时也未必想象地到。和别人通信,链接到精彩的文章,即时新闻报道,这些都超出了“你正在做什么”的概念。
    Twitter产生之初,很多人说这个服务太愚蠢了。即便是这样,他们也承认,Twitter把一件事情做地很简洁。运营过程中,很多用户打电话到Twitter,要求增加这样那样的功能,这事我也干过,Twitter并没有满足所有的用户,界面始终保持简洁,哦,也可能是他们没有足够的工程师。
    有趣的是,这件事引起了第3方开发者的兴趣,大伙开始踊跃为它开发新功能,围绕Twitter的整个生态系统逐步建立。这个几年前被人斥为愚蠢的服务, 现在正和Facebook一起,深入地影响着互联网。
    现在我们来说说Facebook,几年前,我开始使用Facebook,而不是Myspace,也是因为它的简洁、优雅。随后,Facebook高速增长,更多的功能陆续被开发出来,它也开始变得无比复杂。
    我坚持认为,Facebook的设计之所以引起用户不满,皆因复杂所致。想用好Facebook太难了,为了一个似乎微不足道的变化,你不得不花大量的精力适应和学习,这违背了Facebook的核心价值观:利用网络获知朋友的近况。许多用户离开了Facebook,我一点也不意外。
    某种程度上说,Windows也是因复杂走向失败的例子,即便一个使用计算机多年的老手,想玩转Windows操作系统,也极为不易。Windows陷入了不停地为产品添加新功能的怪圈,新功能满足了部分用户的需求,整个系统却越来越臃肿、难用。更糟糕的是,Microsoft开始推出不同的操作系统版本,谁也说不清它们之间的区别是什么。
    如果你想添加新功能,Gmail在对Lab上的处理可能是个很好的例子,与其面向所有用户推出新功能,Gmail把Lab作为新功能的可选项,这样当用户不喜欢Lab的时候,可以轻易地关掉它。
    让我们重新回到简洁的主题,简洁通常意味着优雅。再举个例子,Twitter的客户端很多,用过Tweetie的用户都会领会到简洁的魅力,它不会把我的Flickr和Facebook 新鲜事推送过来,相反,只把一件事做到了最好:展示Twitter的信息流。
    再次回到Facebook,它也意识到这一点,开始简化设计,生活流竭力做到和Twitter一样简洁,然而你看到的只是表象。真正的问题在于,Facebook的背后有一系列复杂的社区规则和关系,导致它很难做到真正的简洁,你可以按下图尝试下它的新鲜事设置。
    最近我关注的另一个应用是Foursquare,为什么关注它?可能因为身边的朋友都在使用,那么他们又为什么使用呢?因为它很简洁。使用FourSquare的iPhone App时,在某个地方签到只需要点击两次。
    为什么用户喜欢Digg?它也很简洁,你可以提交感兴趣的内容,或者给文章投个票,再懒的话仅仅阅读就行了。
    对多数初创公司来说,你能用一句话说清楚你的服务能做什么吗?让我们试一下:
    Google:搜索你想要的;
    Facebook:和你的朋友保持联系;
    Twitter:说说你在做什么;
    FourSquare:报告你现在的位置。
    下一个?你有什么想法么?
    原文链接:http://techcrunch.com/2009/04/28/keep-it-simple-stupid/
    译文链接:http://www.mobilefocus.net/?p=444

  • Web应用成功构建的十项黄金法则

    2010-08-04 19:52:20

    Web应用成功构建的十项黄金法则

     

    此文译自Fred Wilson 2010年2月在迈阿密举行的Web未来应用的年会上的演讲,以下是演讲内容:

      谢谢,大家好,很高兴能够来到迈阿密。昨晚我从纽约抵达的时候还很冷,地上都是积雪,但是现在这里却很温暖很舒服,非常高兴能够来到这里。

      演说前,Carsonified有人提议希望我能够列出构建成功web应用的十项法则,我想了想:“好吧,我都不知道是否能控制在是个”。不过,我现在已经列出来了并打算今天分享给大家。这些都是源自我十五年来对web应用投资实践所得的经验,包含了我所学到的,如哪些实践方式有效而哪些实践方式无效等等。

      我用过很多的web应用,对于我们来说,我们的投资方式都是非常直接的。在投资前我们很清楚什么样的应用是我们感兴趣的,如果这产品我们不感兴趣,那我们就会直接告诉项目的负责人这不是我们想要的,相反,我们就会采纳这个产品。紧接着如果发现产品和我们产生共鸣,那么我们就会尝试去了解他。一旦这个产品,以及对应的服务和项目团队都非常吸引我们,那么我们就会去投资。

      这十项是我一直在web应用中寻找的。我敢肯定在座的一定有人会不同意我的观点,但是这确确实实是对于优秀的web应用来说是不可或缺的。因此,今天的主题就是:“构建成功web应用的十项黄金法则”。

      1.速度

    1

      首先,我相信速度是最为重要的,对于一个web应用来说,速度快是所有特征中最重要的。如果你的应用很慢,人们是不会去用它的,这个在主流用户(一般用户)中要比高级用户更加来的显而易见。我认为对于高级用户来说,他们有的时候很能理解构建一个非常快速的应用背后的挑战和苦难,所以当他们面对速度缓慢的应用的时候,或许他们还能忍受。但就以我的妻子和孩子来说,他们是我认为的主流用户(一般用户),一旦某个应用速度慢了,他们不会耐心地等下去了,而是立马放弃使用。

      我觉得web应用速度必须要快,如果慢了,后果是显而易见的。我们公司(风险投资公司)的每一个投资的项目在Pingdom(网站性能测试服务站点)上都有记录,我们每周都会去看。我们发现,但凡有公司投资的应用陷入困境(出现性能问题,速度变慢了),这些应用通常也不会有快速的发展势头。这个真实有力的证据证实了“速度优于功能,速度是最重要的”这一事实,对于一个web应用来说,速度快不是一个优点,而是一项要求。

      2.即时效用

    1

      “即时效用”的意思就是说服务(其实就是web应用,因为web应用多数就是提供服务)对你来说是实时有帮助的(简单实用,并且具有实时性)。如果你构建一个服务,然后用户要想使用他不得不花上一个小时的时间完成如下流程:配置服务,启动它,导入联系人,做许许多多和数据有关的事情。那我想绝大部分人会放弃使用。服务必须要对用户来说是即时可用的,而这一点被很多人所忽视.

      利用许多技巧可以使得你能够快速让你的应用达到这种即时效用,举个比较适当的例子:当你构建一个信息服务的时候,一开始甚至长期你都可以在网络上的其他地方爬取比较受欢迎的信息作为你自己的服务。但是有一点,你一定要给用户即时的有帮助的信息。

      另一个例子是:当Google大概4,5年前发布Google Video的时候,差不多同一时间YouTube也发布了同样的服务。如果你在上传一个视频到Google Video,之后你得到了一个消息说:“一个星期后你的视频将会被播放出来”。当然了,这样的方式显然不是很好。而相比,YouTube提供了在线实时的编码工作,你可以立马看到你上传的视频。这就是我想要说的关于即时效用的东西。

      3.软件即是媒介

    1

      关于这点我有很多想说的.我的观点是现在的软件即是媒介。特别是消费者软件,当人们使用你软件的时候就如同接触各种媒介一样。这里我所说的媒介是指诸如杂志,新闻,电视节目等传统媒介。比如”纽约时报”和“华尔街日报”;“浮华世界”(一本杂志)和“时尚”(时尚杂志);FOXNews和CNN,每一种媒介都有自己的特点,都有不同于其他媒介的独一无二的态度和坚持。

      同传统的媒介一样,我认为现在的软件也要有自己的个性特点,发出自己的声音,表达自己的态度。有些看上去诸如“Fail Whale(失败鲸)”(twitter宕机时候的提示图案)很“傻乎乎”的东西,其实也是一种个性化的东西。虽然对于Twitter用户来说宕机这件事难免有些尴尬,但人们仍会穿着”Fail Whale”的衣服在街上行走,这至少证明了一点: 这个服务背后有属于自己的特点,它提供了一种媒介,用同一种声音将人们联系在一起.这就是我想要说的.这一点对于web应用来说是非常重要的.  


      4. 少即是多

    1

      “少即是多”,这一点我深信不疑,尤其在你构建应用初期.而后你可以慢慢地增强你网站的功能.以Facebook为例, 如今在他它的服务中提供了20到30种不同的核心功能.但是,在它刚刚起步的时候他的应用却非常的简单好用.我想这就是一个好的应用所必须具备的.

      公司对Delicious的投资是我最满意的投资之一.我喜欢它的简单,Delicious的功能很少,但是却很强大.人们一天要用五次甚至十次,而且天天都用.这些服务虽然涉及面很窄,但是对用户非常有用,时刻都要用到它.他们非常的强大并且对你有很大的帮助,与此同时我认为他们的快速,简单,易用做得非常的好,给你提供了一个很好的平台.

      5.可编程

    1

      对于web应用开发者而言,我觉得这一点本身无需多说. 但是我认为非常的关键,非常的重要.能够让其他人通过某种方式在你的应用基础上构建其他的应用或者在你应用基础上添加其他的东西是非常重要的!这就意味着开放(你应用的)API,并且在我看来是可读写的API. Delicious的创始人两三年前和我说如果API不是可读写的,那就不算是开放API.这个已经在我们公司内部形成了一个信条了.我们认为如果API只是可读的,那么它和RSS没什么区别.

      不是所有我们投资的应用都开放了可读写API,但我们始终尝试着鼓励并且说服他们这样做.可编程性最为重要的一点是,人们能够通过这个能够令你的应用更有价值,给你的应用注入更大的能量,为你的应用带来更多的用户,更多的数据以及更多的财富. 或许2,3年前,我们还会投资不具备高可编程性的web应用,但在今天我们肯定不会这么做了,因为如同速度一样,可编程性对于成功的web应用也是必不可少的.

      6.个性化

    1

      个性化对于用户来说是非常有意义的,就好像我前面一张ppt提到的,你要让第三方的开发者乃至用户都为你的应用注入他们的“能量”,他们在你的应用中注入越多的他们个性化的东西,他们就会对你的应用更加有归属感和拥有感,这很有可能会成为你推动市场的重要力量。个性化你的应用是非常重要的,方式也有很多,比如可以让用户自定义背景,上传头像,添加自定义的内容等等等等,这些都能让用户就对你的应用产生归属感。

      当然了,个性化难免也会带来一些问题。之前我和一个原Last.fm的女员工聊天的时候,她告诉我他们社区用户都感觉他们就是网站的主人,是他们在负责这个网站,于是就导致了这样的问题:每次网站有了改动,就会在论坛上看到成千上百的留言。我认为这是一件好事情,因为这就意味着人们非常关注你的网站,你的应用。

      这对于我们投资的一些公司来说的确也是一个头疼的问题。比如,当我们投资的一家公司:Meetup (需要翻墙)上个星期在它站点的页面上作了些改动之后,就有许许多多关于这件事情的评论,当然了,大部分都是骂声(持反对意见)。对于这些评论,积极回应也好,完全不予以理会也罢,完全由你自己确定。但是从某个层面上来看,这确实是件非常好的事情,因为这恰恰说明了人们在关注你的应用,他们花费了他们的时间和精力在你的应用上面。

      7. RESTful(计算机领域专业名词)

    1

      我不确定我用这个词是否准确。我想在座的大部分都应该知道什么是REST(REpresentational State Transfer的简称)。它是一个软件架构中提出的一个观点即:任何事物都应该有详细的定义。但是我这里所指的REST则有些许不同,甚至有点使用不当,但是不管怎么样我仍然觉得还是讲得通的,还是挺有道理的。

      软件架构中的REST指的是你的每资源都有一个可被访问的URL来表示,这个是在软件架构层面的。但是我对他的定义则有些古怪,我所谓的REST是指整个应用层面,其中所有的资源都有一个URL,而且是一个非常简洁,容易理解的URL。

      好比Twitter在3,4个月前发布的Twitter list,如果你去某人的twitter页面,单击了“lists”这个链接,你就会看到类似于“twitter.com/fredwilson/list/….”这样的URL,这个URL就表示了我twitter上的所有的list。整个Twitter应用都是以这样的方式来构建的,它上面所有的资源都是以简单易懂的URL来直接表示的。你可以拿到这个URL,然后通过email或者其他方式发送到互联网上。

      Google将会搜索到这个URL,它能够让别人发现你的应用并且直接访问到你应用中原本要从首页通过很多次交互才能访问到的内容。我认为那些不以这种方式构建web应用的人都犯了一个很大的错误。就好像现在非常流行的LinkedIn,它在这方面就做的非常的糟糕。

      以上就是我想要说的关于RESTFUL的东西,尽管有些怪异,但是我认为对于成功的web应用来说的确是非常重要的。


      8. 让你的应用更容易被人发现

    1

      这张ppt和上一张ppt有点像。当你刚刚构建好你的应用的时候,它就好像是一堆稻草上的一根针。世界上存在着说不上成千上万吧,至少也有成千上百的应用和你类似,那么怎么样才能让人们发现你的应用呢?基于这一点,我认为,你要做的就是搜索引擎优化。对于优化,你不仅仅要知道其规则更要清楚如何去优化。你的应用必须要让Google能够很容易的发现。

      不仅如此,你的应用也应该很容易被社会媒体所发现。现如今,就传播能力而言,社会媒体如同搜索引擎一样重要。就好像病毒一样。First Round Capital的创始人,同时也是我的同事,Josh Kopelman发表了一遍很好的博文,那篇博文的标题大致是:“我们需要注入病毒”。大致意思是说,他们构建的web应用根本没人使用,于是他就和他的团队说:“我们注入些病毒进去”。当然了,你不能这么做。但是你的应用就应该自始至终都应该是很容易被人发现,可传播能力很强的。产品本身就应该是面向互联网,搜索引擎,社会媒体的。这就是我所说的如何让你的应用更容易被人发现。

      9.简洁

    1

      我认为,简洁意味着你应用的页面不要太拥挤。你的页面应该让人一目了然,任何页面都不要放置太多的功能点在上面,要让用户一看就能知道是干什么的,怎么用。

      在我刚开始做这张ppt的时候,想把一些应用的截图放上去,感觉这样会比较好。但是后来想想这并不好,于是我就放了这些肥皂上去了。但是之前在这个位置我放的是Tumblr(需要翻墙)的登陆界面的截图,截图如下:

      当你进入Tumblr的登陆界面的时候,它整个页面上就只有两个巨大的输入框,用来输入用户名和密码,非常简洁直白,我非常喜欢。用户非常清楚这个页面是干嘛的以及如何使用。这点非常重要,很多人都低估了这种简洁性的价值,总觉得页面上的功能越多越好。

      10.趣味性

    1

      最后一点,同样重要的是娱乐化。我们合广投资公司(Union Square Ventures)有6个关键词(类似学校的校训之类的),有一个碰巧和我说的这一点吻合。这六个关键词是:移动化、社会化、全球化、娱乐化、智能化,第六个我忘记了。不管怎么样,这些都是和我们的web应用有关的东西,而其中娱乐化就是我想要说的。

      之前有人说我放一个空的场地只有积水的图片作为背景不好,但是我这么做是有原因的。这张ppt上的图片是旧金山的南方公园。在这个滑梯的上面只有一小块地方,但是就在这一小块地方上诞生了Twitter:那是一个春天,有天中午4,5个来自一家名叫Odeo的公司的员工来到这个公园讨论他们要构建的新的项目,最后就在这个滑梯上方的那一小块平台上,想到了Twitter。这就是为什么我要放这张图的原因。

      总之,对于web应用来说,娱乐化是非常重要的.游戏互动性是指你可以用他来引导用户做一些事情.举个不是web apps的例子吧,一款具有良好互动性的名叫Weight Watchers的游戏,它的良好互动性体现在。你可以在这个游戏中建立一个目标,然后去努力完成这个目标,同时,你可以将你的目标公布出来,当你达到目标之后会获得一些奖励。就是这一游戏互动性得Weight Watchers非常的成功。

      不同的应用可以提供不同的游戏互动性,比如linkedIn,我有些朋友在这上面就喜欢在上面结识更多的朋友,就好像人们在Twitter上就想让更多人来follow自己,或者自己去follow更多的人一样。这是所说的就是另外一种游戏互动性了。

      Foursquare则有很多的游戏元素:诸如状态,徽章之类的来衡量作为为对本地信息的挖掘的能力强弱。你的应用没有必要和Foursquare一样做的这么明显,但是我想说的是你的应用需要娱乐化。因为这样,它会让用户觉得你的应用很有趣。

      Greg,能把屏幕切换到我的blog吗?我周日的时候把这篇演讲ppt发布到了我的blog上面,地址是:www.avc.com,这就是这篇文章“构建成功web应用的十项法则”。你往下翻就会发现有许许多多的留言,一共有171条。之前有一些内容大家争论了3,4天关于是否除了这十条还有别的更重要的十条,是否你对这真的感兴趣;是否拟对你刚刚构建的应用仔细考量过,是否你这十条包含了全部的关键点。当然了,在留言中至少还提到了5,6点非常关键的,比如:隐私性,易用性,品牌性等应该被列入其中,但是我被要求只能列出10个,于是就只能压缩成了10个了。

  • Sql server中时间函数用法详解

    2010-07-27 18:41:26

    SQL中的时间函数非常有用,特别是在我们进行初始赋值、复杂查询的时候,就显得特别方便。

    1、获得系统当前时间

    select getdate() 

     

    2、DateName ( datepart , date )返回表示指定日期的指定日期部分的字符串。

    --今天是2009-2-24--星期二

    SELECT DATENAME(yeargetdate()) AS 'Year Name' --------返回:2009

    SELECT DATENAME(monthgetdate()) AS 'Month Name'  --------返回:02

    SELECT DATENAME(weekday, getdate()) AS 'Weekday Name'------返回:星期二

     

    3、DATEADD (datepart , number, date ),在向指定日期加上一段时间的基础上,返回新的 datetime 值。

    select DateAdd(MM,2,'2008-8-8'--------------返回:2008-10-08 00:00:00.000

    select DateAdd(dd,2,'2008-8-8'--------------返回:2008-08-10 00:00:00.000

    select dateadd(hh,-1,getdate()) --------------返回:2009-02-23 12:46:46.450,返回前一个小时的时间

     

    4、DATEDIFF ( date-part, date-expression-1, date-expression-2 )  返回两个日期之间的间隔。

      此函数计算两个指定日期之间日期部分的数目。结果为日期部分中等于(date2 - date1)的有符号的整数值。

     

    SELECT datediff( hour, '4:00AM''5:50AM' )---------------------------返回: 1

    SELECT datediffmonth'1987/05/02''1995/11/15' )------------------返回: 102

    SELECT datediffday'00:00''23:59' )------------------------------返回:0

    SELECT datediffday,  '1999/07/19 00:00',  '1999/07/23 23:59' )------返回:4

    SELECT datediffmonth'1999/07/19''1999/07/23' )------------------返回:0

    SELECT datediffmonth'1999/07/19''1999/08/23' )------------------返回:1

     

     实例:查询当天更新的数据

     

    select * from tableName where datediff(dd,F_EditTime,getdate())=0

     

     

    5、DATEPART datepart ,date )返回代表指定日期的指定日期部分的整数。

    --今天是2009-2-24 星期二
    SELECT DATEPART(year,getdate()) as 'Year'    --------返回:2009

    SELECT DATEPART(month,getdate()) as 'Month'   ---------返回:2

    SELECT DATEPART(weekday,getdate()) as 'Weekday' ---------返回:3,如:Sunday = 1、Saturday = 7

    SELECT DAY(getdate())             -----------------------返回:24

     

    备注:DAY、MONTH、和 YEAR 函数分别是 DATEPART(dddate)、DATEPART(mmdate)、和 DATEPART(yydate) 的同义词。

     

    附录:datepart

    日期部分缩写
    Yearyy, yyyy
    quarterqq, q
    Monthmm, m
    dayofyeardy, y
    Daydd, d
    Weekwk, ww
    Hourhh
    minutemi, n
    secondss, s
    millisecondms

Open Toolbar