2007年11月30日

质量的定义总会带有政治的和情感的色彩吗?

    什么是质量?似乎已经有了非常多的答案,从“质量就是零缺陷”、“质量就是满足客户需求”一直到“质量是满足客户需求的程度”,仿佛我们已经找到了答案。可是这些答案为什么总是无法解决我心中的困惑?

    “满足客户需求是我们唯一的目标”作为公司的质量方针已经这么多年,可是为什么在软件开发中我们始终还只能不断的喊着“从客户的角度”的口号,而“从客户的角度”出发的思想却始终无法在开发团队中落实?

    项目经理们一旦受到了进度的压力,什么质量、什么从客户角度出发就被他们毫不犹豫的扔到了九霄云外?

    为什么在公司提高过程符合度的重压下,过程符合度指标急速上升,而有的团队质量却没有根本性的进步?

    为什么有的产品终于实现了第一次开发达到了进度零偏差,但实际却偷偷拿着另外的版本提供给客户,并因此得到了公司的嘉奖?再后,进行审计时发现,获得嘉奖的产品其开发过程审计结果也一般般,甚至是同一个部门中比较落后的团队,其他开发团队对此更是嗤之以鼻!

    ……

    虚伪的质量

    最被大家认可的质量定义“质量就是满足客户需求的程度”,以前从未对此表示过怀疑,一切都如此的自然,就好像质量天经地义就应该是这样。我的思考和理解也就停留在“客户是不同的,需要区分”、“满足的程度应该如何衡量”等诸如此类上,但它却始终没能解决我心中的困惑,我也没能成功将它和我们软件开发中存在的各式各样的奇特现象联系在一起,除了在无计可施时,向着开发和测试人员喊喊“你们要从客户的角度考虑问题”的口号,就毫无办法!直到一天看到了大师温伯格的三卷套(《质量.软件.管理》),才明白这一切的根本,没有谁比温伯格更深刻的揭示了“质量”的奥秘。而这奥秘对我来说,无异于当头棒喝,将所有的困惑打在了一起,又一个个解了开来,也能让我更冷静的看待开发中存在的种种问题,从而能够更好的处理这些看似简单却复杂的质量问题。

    究竟什么是质量的奥秘呢,上面的质量定义中究竟隐藏了什么让我们看不真切呢?答案竟然如此简单和虚伪:“质量就是对某个人而言的价值,它的背后是行政和情感!”。“行政和情感”意味着,质量好并不仅仅是缺陷少、功能多或者是服务好,一切在于客户的感受!一个容易忽视的例子是:我每次去买衣服时,最害怕的是什么,是怕服务员太热情,总是一见面就拉着我介绍这介绍那,她们的介绍总是那么详细以至于我总是心里发毛,为什么?我对名牌和款式实在是所知甚少,而她们的介绍几乎总是让我感觉自己是那么无知,而这让我很自卑(以前一直没意识到),于是每当看到太过热情的服务员我几乎每次都选择了逃避,我会告诉她,我只是随便逛逛。是她们的服务不好吗?显然不是,我会说她们服务得很好,可是这对我来说却不是什么好的购物感受,我却不能说她们的服务质量很好,因为她们显然没有达到她们的目的-卖出,而我也同样没有得到我想要的-买进。一切在于客户的感受,这和以客户为中心的思想并没有什么区别,只是事情的关键在于质量的行政和情感本质,当这从软件组织向外看时,没有什么稀奇,但是一旦以它的目光看回开发组织的内部,事情就不那么简单了,它揭示了软件质量的“不确定性”之外的另一个重要特性——层次性。而如何破除内部质量层次的封闭性将是一个软件组织实现真正的“以客户为中心”的关键,否则“以客户为中心”就只能沦落为一句口号。

2007年11月26日

项目过程
1、项目启动
  1)、项目组成立(公司成员、客户成员)
  2)、制定项目预期目标
  3)、制定项目计划周期
  4)、建立好项目组成员沟通机制
2、需求调研
  1)、创建调研计划、协调调研时间
  2)、收集客户资料,获取客户需求
  所有的资料都需要保留一份,资料中存疑的需要及时询问
  3)、编写需求文档
  重点描述出客户的业务流程性能要求。
  采用Word、Excel、Rose等形式。
  4)、需求变更记录
  5)、确定开发环境和运行环境
  6)、扩展性要求
  7)、与旧系统的接驳要求。
  8)、估算出项目工作
  本阶段需要一套需求管理系统来进行需求的管理。
  本阶段的需求文档也是用户测试的依据。
3、系统设计/详细设计
  一个系统可以分为基础平台和应用模块两部分。
  1)、选择基础平台,无论是采用第三方平台还是自行开发平台,都需要深入了解,查看是否符合要求。
  2)、应用模块设计(针对业务流程)
  3)、中间件的采用或自行开发,需要深入了解。
  4)、用户界面的设计
  如果用户界面设计完毕并确认,即可初步写出用户使用手册、管理员使用手册。
  5)、变更记录
  本阶段的系统设计是集成测试的依据。
4、程序开发
  创建开发任务计划表、开发计划日程表
  1)、优先编写测试用例
  2)、按照编码规范编写代码
  3)、按照文档注释规范注释
  以上形成开发文档。
  本阶段需要一套版本管理系统。
  本阶段的测试用例也是单元测试的依据。
  如果能做到,最好每日构建。
5、测试
  本阶段需要一套Bug管理系统,形成需求、设计、开发、测试互动。
  1)、编写测试计划和测试方案
  2)、
  单元测试、集成测试
  3)、
性能测试
  集成测试、压力测试
  如果能做到,最好能进行自动化测试。
  如果能做到,做分析统计工作。
  最后形成测试报告。
6、试用、培训、维护
  本阶段需要解决:
  1)、解决异地修改和公司修改的同步问题
  2)、用户测试中的Bug修改问题,按照级别分为
  a)、程序Bug
  b)、设计变更
  c)、需求变更
  尽量按照a b c的顺序来进行修改,尽量避免b、c级的修改。
  最后形成安装手册、维护记录。
  项目成员组成
  根据以上过程,一个项目组中,需要:
1、需求工程师,其要求
  善于与客户沟通,能快速了解客户的需求,对客户所在的行业比较熟悉。
  善于学习新知识。
  熟悉Word、Excel、Rose等工具的使用。
  熟悉开发语言和开发框架
  熟悉已积累的产品的功能、性能等。
2、系统分析师/设计师,其要求
  精通开发语言和开发框架,部分需要精通数据库
  精通已积累的产品的功能、性能等
  深入了解客户行业特点
  能根据客户的要求分析出其实质
  能做出优秀的设计
  熟悉Word、Excel、Rose等工具的使用
3、开发工程师,其要求
  熟悉开发语言,熟悉开发要求和注释规范,部分需要熟悉数据库。
  熟悉单元测试。
  能根据设计做出良好的编码,保证功能和性能。
  部分需要有一定的设计要求,因为涉及到将来的维护。
4、测试工程师,其要求
  熟悉测试工作,能按照测试计划进行测试。
  熟悉开发语言,能协助开发工程师找错。
  能独立完成黑、白盒测试。
  如果是高级测试人员,还要能够对系统能深入进行分析并能制定出优秀的测试方案。
5、管理人员
  一般由以上人员兼任,主要有
  项目经理:负责整个项目
  开发经理:负责系统设计、开发工作
  测试经理:负责测试工作
6、其他人员
  一些项目涉及到其他人员,如页面设计人员、页面制作人员。
  部分大的项目,还有专门的维护人员。
  由于目前国内很多公司并没有严格这么区分,如果项目小的话,可以一人兼任多项职位.功能测试

2007年11月16日

Watir 是一个使用 Ruby 实现的开源Web 自动化测试框架,相对于那些庞大的商业工具来说,它很小巧,也很灵活,提供的功能也足够用。最近抽时间试用了一下,感觉还不错,准备下一步在公司推广使用。因为 Watir 的网站上用户手册、示例代码以及 FAQ 都维护的不错,所以已有的东西我就不重复了,在这里简单介绍一下,如果同行们有兴趣,可以一起研究一下。

  Watir 是一个使用 Ruby 实现的开源Web 自动化测试框架,相对于那些庞大的商业工具来说,它很小巧,也很灵活,提供的功能也足够用。最近抽时间试用了一下,感觉还不错,准备下一步在公司推广使用。

  因为 Watir 的网站上用户手册、示例代码以及 FAQ 都维护的不错,所以已有的东西我就不重复了,在这里简单介绍一下,如果同行们有兴趣,可以一起研究一下。

  1. 脚本示例

  先丢一段脚本给大家看看使用 Watir 来书写脚本是多么的方便。下面的例子是 Watir 自带的一段测试 Google 的搜索功能的脚本,不过我只保留了最主要的部分,以使它看起来更简洁一些:

  require ’watir’ # the watir controller
  # open the IE browser
  ie = Watir::IE.new
  # Step 1: go to the test site: http://www.google.com
  ie.goto (http://www.google.com)
  # Step 2: enter ’pickaxe’ in the search text field
  ie.text_field(:name, "q").set("pickaxe") # q is the name of the search field
  # Step 3: click the ’Google Search’ button
  ie.button(:name, "btnG").click # "btnG" is the name of the Search button
  # Actual Result: Check that the ’Programming Ruby’ link appears on the results page
  if ie.contains_text("Programming Ruby")
  puts "Test Passed. Found the test string: ’Programming Ruby’. Actual Results match Expected Results."
  else
  puts "Test Failed! Could not find: ’Programming Ruby’"
  end
  # End of test: Google search

  这段脚本要做的事情是打开 Google 的主页,然后在 Google 唯一的那个文本框内输入“pickaxe”这个字符串,然后按下“Google 搜索”按钮,之后验证搜索结果的页面中是否包含了“Programming Ruby”这个字符串,并根据结果使用 puts 函数在屏幕上打印不同的信息。脚本中“#”后面的绿色部分是注释的内容。简单吗?说实话要比那些商业工具录制的脚本还要简洁和简单。

  2. 所需要的环境

  Ruby : 因为是使用 Ruby 实现的,脚本也是 Ruby 的脚本,所以需要在本机安装 Ruby。可以点击这里下载。根据文档中说的,最好选择Ruby 1.8.2-14 或者更高的版本,我安装的是Ruby 1.8.2-15 Stable Release。

  Watir : 可以点击从这里下载,我下载的是 Watir 1.4 ,是一个.zip 文件,解压缩以后执行 install.rb 就可以了,具体的安装和配置请参见 Watir 用户手册。不要怕,虽然是英文的,但是很简单。

  WINDOWS 2000 或 XP + IE 5.5 以上版本 : 根据 Watir 网站上的描述,这是他们目前支持的环境。

  3. 所需的知识背景

  因为毕竟还是要写代码的,所以开发经验是必需的,任何语言的开发经验都可以——虽然 Ruby 是一个面向对象的脚本语言,不过你可以暂时不理它那么多(别被面向对象、脚本语言之类的词汇吓倒),如果你写过 VBScript 或者其他什么代码那么 Watir 就是很简单的。不过,需要了解 Web 开发,比如 HTML 的基本语法,因为在开发脚本时需要根据 Web 页面的源代码来确定对 Web 对象的识别方式——当然,也可以借助其他工具来实现,例如 Mozilla Firefox 中提供的“DOM 查看器”(可以在 Mozilla Firefox“工具”菜单下找到,具体的使用方法参见 Mozilla Firefox 帮助)。

  另外,测试和自动化测试方面的基本知识还是要有的。

  4. 脚本的生成

  录制功能就别想了,Watir 没有提供这项功能。如果你非用录制不可,那就选择其他吧。不过就我自己的使用来看,Watir 的脚本写起来比用 QTP 或者 Rational 的工具录制还要方便和快捷。

  5. 对象的识别、操作和自动验证

  Watir 提供了对多种常见 Web 对象的识别和操作的支持,例如 Hyperlinks 的点击、Checkboxes 的选中和清除、Radio Buttons 的选中和清除、下拉框和列表框的选择、文本框的输入、各种按钮的点击以及 Frame 的访问、弹出窗口的控制等。当然,既然可以识别和操作这些对象,也可以访问这些对象,使测试结果的验证自动化。具体信息可以参见 Watir 用户手册。

  6. 其他特性

  如果你熟悉了 Ruby ,再结合其他一些工具,可以在 Watir 框架的基础上扩展出很多特性。例如:外部文件或的读取、模块化的开发、可重用的函数库、数据驱动、关键字驱动、脚本的版本化控制以及测试结果的管理,等等。数据

  7. 相关链接

  Watir 主页:http://wtr.rubyforge.org/

  Ruby中文手册:http://www.ruby-cn.org/doc.html

  Ruby主页:http://ruby-lang.org/en/

  就如前面所说的,Watir 的用户手册、FAQ等方面维护的很不错,如果完整的看完 Watir 主页上的 sample test 和 User’s Guide 基本上就可以用 Watir 开始测试 Web 应用了。如果有兴趣进一步研究,可以参考一下 Technical Doc ,也可以读一下 Watir 自带的几个示例。