总是很难忘记生活的点点滴滴, 脑海中总是闪过好多的曾经, 美好的回忆, 但成长中却让我们失去了很多, 很想在忙碌的生活中淡淡忘记; 不曾放低的东西却始终让我忘记不了, 但我还要在忙碌的生活中继续生活!

发布新日志

  • 微软测试技术可借鉴的点

    2008-07-04 14:59:42

    1.1  测试驱动开发,尽早、不间断地进行软件测试。建立强大的支撑daily build和daily test的自动化测试体系。围绕BUG数据为中心建立缺陷管理平台、统计分析、项目管理平台。决策从经验模型转向科学模型,整个软件开发流程宏观、微观细节都用数据说话。透过数据管理者花精力在尚未做好的事情上
    1.2  建立制衡制度、文化,不让有问题的代码check in,保证代码库神圣。减少围绕BUG的各种成本。
    1.3  完善各种CheckList 或者模版(文档、用例)、开发测试工具(白盒…),让能力瞬间transfer 到团队,充分应用已有成员的成果,提升team Level。充分避免手工测试弊端(无知识传承、置信度低、相对持续在一个水平)
    1.4  自动化测试不仅仅是技术,更是思想,自动化测试不是找BUG的而是一种质量保证手段。自动化本质是引入一种痛苦解决另外一种痛苦。基础设施不足是问题根本。脚本是自动化的最低形式。框架充分re-use、封装复杂度,提高框架的适应能力。自动化测试应在单元级上细致验证。建立自动化的平方环境
    1.5  在每一个环节细致严格要求,比如BUG提交规范减少人为沟通。每一个QA把自己的事情一次作好、做专业
    1.6  发布标准: 95% case通过率以及85% 代码覆盖率,<5%不重要的case bug。
    1.7  强调文档价值(能力转换形式,对管理的支撑)以及定义高质量文档的要求
    1.8  可靠性测试、可扩展性测试针对设计而言,尽早测试,否则即使结果不满意,成本也很高昂
    1.9  Work around和彻底解决问题间,选择后者。硬碰硬突破
    1.10  测试工程师业绩考核指标:增加check in前预防BUG、发现别模块的BUG、开发自动化工具等贡献度大的项比重
  • 软件测试错误报告规范

    2008-07-04 14:12:25

    软件测试的报告中,报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误,从而有利于分析错误产生的原因

    报告软件测试错误的目的是为了保证修复错误的人员可以重复报告的错误,从而有利于分析错误产生的原因,定位错误,然后修正之。因此,报告软件测试错误的基本要求是准确、简洁、完整、规范。需要掌握的报告技术归纳如下。
      1. 描述 (Descrīption),简洁、准确,完整,揭示错误实质,记录缺陷或错误出现的位置

      描述要准确反映错误的本质内容,简短明了。为了便于在软件错误管理数据库中寻找制定的测试错误,包含错误发生时的用户界面(UI)是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称。

      2. 明确指明错误类型:布局、翻译、功能、双字节
    根据错误的现象,总结判断错误的类型。例如,即布局错误、翻译错误、功能错误、双字节错误,这是最常见的缺陷或错误类型,其他形式的缺陷或错误也从属于其中某种形式。

      3. 短行之间使用自动数字序号,使用相同的字体、字号、行间距

      短行之间使用自动数字序号,使用相同的字体、字号、行间距,可以保证各条记录格式一致,做到规范专业。

      4. UI要加引号,可以单引号,推荐使用双引号

      UI加引号,可以容易区分UI与普通文本,便于分辨、定位缺陷或错误。

      5. 每一个步骤尽量只记录一个操作

      保证简洁、条理井然,容易重复操作步骤。

      6. 确认步骤完整,准确,简短

      保证快速准确的重复错误,“完整”即没有缺漏,“准确”即步骤正确,“简短”即没有多余的步骤。

      7. 根据缺陷或错误类型,选择图象捕捉的方式

      为了直观的观察缺陷或错误现象,通常需要附加缺陷或错误出现的界面,以位图的形式作为附件附着在记录的“附件”部分。为了节省空间,又能真实反映缺陷或错误本质,可以捕捉缺陷或错误产生时的全屏幕,活动窗口和局部区域。为了迅速定位、修正缺陷或错误位置,通常要求附加中英文对照图。

      8. 附加必要的特殊文档和个人建议和注解

      如果打开某个特殊的文档而产生的缺陷或错误,则必须附加该文档,从而可以迅速再现缺陷或错误。有时,为了使缺陷或错误修正者进一步明确缺陷或错误的表现,可以附加个人的修改建议或注解。

      9. 检查拼写和语法错误

      在提交每条缺陷或错误之前,检查拼写和语法,确保内容正确,正确的描述错误。

      10. 尽量使用业界惯用的表达术语和表达方法

      使用业界惯用的表达术语和表达方法,保证表达准确,体现专业化。

      11. 通用UI要统一、准确

      错误报告的UI要与测试的软件UI保持一致,便于查找定位。

      12. 尽量使用短语和短句,避免复杂句型句式

      软件错误管理数据库的目的是便于定位错误,因此,要求客观的描述操作步骤,不需要修饰性的词汇和复杂的句型,增强可读性。

      13. 每条错误报告只包括一个错误

      每条错误报告只包括一个错误,可以使错误修正者迅速定位一个错误,集中精力每次只修正一个错误。校验者每次只校验一个错误是否已经正确修正。

      以上概括了报告测试错误的规范要求,随着软件的测试要求不同,测试者经过长期测试,积累了相应的测试经验,将会逐渐养成良好的专业习惯,不断补充新的规范书写要求。此外,经常阅读、学习高级测试工程师的测试错误报告,结合自己以前的测试错误报告进行对比和思考,可以不断提高技巧。

  • 08年最有前景的行业

    2008-07-01 11:19:03

    众所周知,最舒服最赚钱的工作是那些垄断行业的专属,这么惬意的工作不是人人努力就能得到的,因此,我们把那些无能为力的金饭碗放一边,来关注下经过权威资料收集整理,得出真正属于那些勤奋聪明不断进取的草根同胞的最具前景行业。


    1. 同声传译


    同声传译员被称为“21世纪第一大紧缺人才”。随着中国对外经济交流的增多和奥运会带来的“会务商机”的涌现,需要越来越多的同声传译员。


     “同传的薪金可不是按照年薪和月薪来算的,是按照小时和分钟来算的,现在的价码是每小时4000元到8000元。”相关人士告诉记者。“4年之后入驻中国和北京的外国大公司越来越多,这一行肯定更吃香,一年挣个三四十万元应该很轻松的。”业内相关人士表示。


    2. 软件测试工程师

    软件测试工程师在一家软件企业中担当的是“质量管理”角色,及时纠错及时更正,确保产品的正常运作。据有关调查数据表明,目前国内许多软件企业内部的测试人员和开发人员之比在1:5,与国外软件业1:1的比例还相去甚远。


    以工作3-5年从业人员为例,深圳地区的平均年薪是全国各城市最高的,其中外商独资欧美企业的年薪为17.8万元,国营企业的年薪紧随其后,超过了17.3万元,北京地区该职位的平均年薪逾15.8万元;其中外商独资企业的年薪为全国之最,将近18.5万元。


    软件测试是正在快速发展,充满挑战的领域。尽管现在单机版桌面软件的测试已经成熟了很多,但对于网络时代的到临,包括微软在内的公司对基于网络的测试也没有一套完整的体系,也是处于探索中,网络中被攻击的可能性太大,这就是为什么黑客在网络上能兴风作浪的原因。网络测试是一个新环境,而且是很大的挑战。
    软件测试未来的发展空间很大,软件测试工程师的职业之路同样充满希望。


    3. 心理咨询师


    据了解,国内现在有上千万人存在不同程度的心理障碍,急需解决。对于从业者来说,或者投资者来说,国内心理咨询业方兴未艾,必须术业有专攻,针对某些特定的群体提供细致、周到、个性化的服务和解决方案改变大众对心理学的片面看法,把专业的术语转变为老百姓能够接受的故事、案例、方法,使之更加普及化、通俗化、时尚化。


    4. 网络游戏设计师


    网络游戏,已经不仅仅是年轻人、孩子们的游戏,据笔者了解,在我们眼中异常忙碌的外交官和企业老总,都会忙里偷闲玩一玩游戏,调节自己。可见网络游戏普及率之广。已经悄然成为一种全球化生活方式,改变着这个世界消费格局。
    而网络游戏本身这个行业已经变成了高技术、高创意、高资金的三高产业,高级人才的火热程度可想而知。。


    5. 商务策划师


    随着全球500强企业纷纷入驻,策划已成为颇有市场的“智慧产业”。65%的企业急需聘用企划人员,但90%的企业招聘不到优秀的企业策划人才。据保守估计,目前我国专业策划公司超过1万家,但专业商务策划师不足800人。从业者大多在30岁左右,最低年薪15万元,平均40万元左右,最高年薪已超过百万元。为此,每年商务策划师认证培训,参加者达三四千人。


    6. 家具设计师


    3万多家家具企业,家具设计师却不到3000人,平均每10家家具企业只有一个设计师。深圳一家家具厂开出20万元年薪,依然难觅成熟的家具设计师。  按照国际家具业一般要求,家具企业的设计人员应为市场营销人员的1倍以上。随着房地产业的发达,室内设计行业、装潢行业、家具制造企业均需要专业的家具设计师,家具设计师已逐步成为家具企业、家装企业的核心人物。


    但目前,我国的家具设计师更多的是只能从事简单模仿、图纸绘制的“绘图员”。高水平专业人才匮缺,导致我国家具虽然出口很多,但大多是贴牌产品,为他人作嫁衣。专家认为,论建材,论做工,国内有些厂家丝毫不输于北欧风情,但设计理念输了,就全盘皆输


    7. 精算师


    精算师年收入在12万至15万元我国被世界保险界认可的精算师不足10人,“准精算师”40多人,在当今的国内人才市场上,精算师可谓凤毛麟角。


      随着国际保险巨头在中国开拓市场以及国内企业的需要,精算师是几年后保险业最炙手可热的人才,目前在国外的平均年薪达10万美元,国内目前月薪也在1万元以上。4年以后,随着人们对于保险认识的加强,保险行业的兴起必然会需要更多的精算师。据预测,年收入应在12万元至15万元。


     

  • 软件测试中网站测试技术简介

    2008-07-01 11:13:56

    1 概述

    地球人都知道,在一个软件项目开发中,系统测试是保证整体项目质量的重要一环,本文将就网站的测试技术及相应的自动测试工具做一个简要的介绍。主要就如下几个方面进行探讨:

    功能测试

    性能测试

    安全性测试

    稳定性测试

    浏览器兼容性测试

    可用性/易用性测试

    链接测试

    代码合法性测试

    2 测试内容

    2.1 功能测试

    在实际工作中,功能在每一个系统中的具有其不确定性,而我们不可能采用穷举的方法进行测试,因而导致了功能测试较为困难,我们依据80/20原则(即80%的错误存在于系统的20%的部分)对于测试用例的设计采用如下两种方法

    2.1.1 白盒测试

    白盒测试即使用程序设计的控制结构导出测试用例。基于目前的现状我们采用基本路径测试方法进行白盒测试,此种方法简单高效。基本路径测试方法的简单说明如下:

    ¨ 首先通过系统设计的流程图导出数据流图

    ¨ 根据数据流图计算其环形复杂性

    V(G)=E-N+2

    或 V(G)=P+1

    V(G):环形负责性

    E :流图中边的数量

    N :流图中节点的数量

    P :流图中判定节点的数量

    ¨ 我们设定V(G)条路径

    ¨ 我们设计V(G)条路径的模拟数据

    ¨ 根据数据进行相应的测试

    2.1.2 黑盒测试

    黑盒测试即派生出执行程序所有功能需求的输入条件,从而导出测试用例,进行测试的方法,黑盒测试用于辅助白盒测试。

    我们采用等价划分的方法进行测试,即为将程序的输入域划分为数据类,以便导出测试用例。一般情况下输入条件为:一个特定的数值、一个数值域、一组相关值或者一个布尔条件。

    2.1.3 网站功能测试

    对于网站的测试而言,每一个独立的功能模块需要单独的测试用例的设计导出,主要依据为《需求分析》,对于应用程序模块需要设计者提供基本路径测试法的测试用例

    具有测试用例后可以采用OpenSTA(Open System Testing Architecture)进行自动化测试

    2.2 性能测试

    网站的性能测试对于网站的运行而言异常重要,但是目前对于网站的性能测试做的不够,我们在进行系统设计时也没有一个很好的基准可以参考,因而建立网站的性能测试的一整套的测试方案将是至关重要的。

    网站的性能测试主要从两个方面进行:负荷测试(Load)和压力测试(Stress),负荷测试指的是进行一些边界数据的测试,压力测试更像是恶意测试,压力测试倾向应该是致使整个系统崩溃。

    性能测试可以采用相应的工具进行自动化测试,我们目前采用如下工具

    ab -----Apache 的测试工具

    OpenSTA—开发系统测试架构

    2.3 安全性测试

    目前网络安全问题日益重要,特别对于有交互信息的网站及进行电子商务活动的网站尤其重要。目前我们的测试没有涵盖网站的安全性的测试,我们拟定采用工具来测定,工具如下

    SAINT------- Security Administrator's Integrated Network Tool

    此工具能够测出网站系统的相应的安全问题,并且能够给出安全漏洞的解决方案,不过是一些较为常见的漏洞解决方案。

    2.4 稳定性测试

    网站的稳定性测试是指网站的运行中整个系统是否运行正常,目前没有更好的测试方案,主要采用将测试服务器长时间运转进行测试。

    2.5 浏览器兼容性测试

    通过白盒测试或者黑盒测试导出的测试用例,采用相应的工具进行测试,可以采用OpenSTA进行测试,此测试工具可以采用不同的浏览器进行测试。

    2.6 可用性/易用性测试

    可用性/易用性方面目前我们只能采用手工测试的方法进行评判,而且缺乏一个很好的评判基准进行,此一方面需要大家共同讨论。

    2.7 链接测试

    超级链接对于网站用户而言意味着能不能流畅的使用整个网站提供的服务,因而链接将作为一个独立的项目进行测试。目前我们已经有了一个测试工具

    Xenu------主要测试链接的正确性的工具

    可惜的是对于动态生成的页面的测试会出现一些错误。

    2.8 代码合法性测试

    代码合法性测试主要包括2个部分:程序代码合法性检查与显示代码合法性检查

    ¨ 程序代码合法性检查

    程序代码合法性检查主要标准为《intergrp小组编程规范》,目前采用由SCM管理员进行规范的检查,未来期望能够有相应的工具进行测试。

    显示代码合法性检查

    显示代码的合法性检查,主要分为Html、Javascrīpt、Css代码检查,目前采用

    HTML代码检查------采用CSE HTML Validator进行测试

    Javascrīpt、Css也可以在网上下载相应的测试工具。

    3 测试工具

    AutoRunner主要做功能测试,使用比较方便,可以编写测试脚本,也可以先行自动生成测试脚本,而后对于应用测试脚本进行测试。

    SAINT

    网站安全性测试,能够对于指定网站进行安全性测试,并可以提供安全问题的解决方案。

    CSE HTML Validator

    一个有用的对于HTML代码进行合法性检查的工具

    Ab(Apache Bench)

    Apache自带的对于性能测试方面的工具,功能不是很多,但是非常实用。

    Crash-me

    Mysql自带的测试数据库性能的工具,能够测试多种数据库的性能。

    TestCenter,测试管理工具,专门用来管理测试用例的,提高了测试用例的复用性,系统了测试效率

    上述工具自行google去查找

    4 后记

    此文只是对于网站的测试方面做了一个简单的介绍,提供的工具比较少,但是可以保证能够使用(当然都是可以从网上免费得到的),另外还有很多测试工具是需要Money的,大家有兴趣可以试用,对于上述提到的测试工具我也只是做了一个初步的调研,详细的功能说明请察看相关的说明文档。

    对于网站的测试中比较重要的还有一个部分就是对于数据库的测试,由于对于数据库性能测试较好的工具需要一些Money因而我们采用Mysql的Crash-me,但是同时也存在一个问题就是对于不同的数据库的测试采用第三方的工具较好。因而大家可以对于其他数据库性能测试的工具进行研究。

  • 性能测试(并发负载压力)

    2008-06-27 17:59:39

    性能测试(并发负载压力)
      分析原则:
         具体问题具体分析(这是由于不同的应用系统,不同的测试目的,不同的性能关注点)
         查找瓶颈时按以下顺序,由易到难。
        服务器硬件瓶颈-〉网络瓶颈(对局域网,可以不考虑)-〉服务器操作系统瓶颈(参数配置)-〉中间件瓶颈(参数配置,数据库,web服务器等)-〉应用瓶颈(SQL语句、数据库设计、业务逻辑、算法等)
        注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
         分段排除法 很有效

    分析的信息来源:
        1 根据场景运行过程中的错误提示信息
        2 根据测试结果收集到的监控指标数据

    一.错误提示分析
    分析实例:
      1 Error: Failed to connect to server "10.10.10.30:8080": [10060] Connection
      Error: timed out Error: Server "10.10.10.30" has shut down the connection prematurely

      分析:
    A、应用服务死掉。
       (小用户时:程序上的问题。程序上处理数据库的问题)
    B、应用服务没有死
       (应用服务参数设置问题)
        例:在许多客户端连接Weblogic应用服务器被拒绝,而在服务器端没有错误显示,则有可能是Weblogic中的server元素的AcceptBacklog属性值设得过低。如果连接时收到connection refused消息,说明应提高该值,每次增加25%
    C、数据库的连接
       (1、在应用服务的性能参数可能太小了 2、数据库启动的最大连接数(跟硬件的内存有关))

    2  Error: Page download timeout (120 seconds) has expired 
    分析:可能是以下原因造成
    A、应用服务参数设置太大导致服务器的瓶颈
    B、页面中图片太多
    C、在程序处理表的时候检查字段太大多

    二.监控指标数据分析
    1.最大并发用户数:
    应用系统在当前环境(硬件环境、网络环境、软件环境(参数配置))下能承受的最大并发用户数。
    在方案运行中,如果出现了大于3个用户的业务操作失败,或出现了服务器shutdown的情况,则说明在当前环境下,系统承受不了当前并发用户的负载压力,那么最大并发用户数就是前一个没有出现这种现象的并发用户数。
    如果测得的最大并发用户数到达了性能要求,且各服务器资源情况良好,业务操作响应时间也达到了用户要求,那么OK。否则,再根据各服务器的资源情况和业务操作响应时间进一步分析原因所在。

    2.业务操作响应时间:
     分析方案运行情况应从平均事务响应时间图和事务性能摘要图开始。使用“事务性能摘要”图,可以确定在方案执行期间响应时间过长的事务。
     细分事务并分析每个页面组件的性能。查看过长的事务响应时间是由哪些页面组件引起的?问题是否与网络或服务器有关?
     如果服务器耗时过长,请使用相应的服务器图确定有问题的服务器度量并查明服务器性能下降的原因。如果网络耗时过长,请使用“网络监视器”图确定导致性能瓶颈的网络问题
    3.服务器资源监控指标:
    内存:
        1 UNIX资源监控中指标内存页交换速率(Paging rate),如果该值偶尔走高,
         表明当时有线程竞争内存。如果持续很高,则内存可能是瓶颈。也可能是内存访问命中率低。

        2 Windows资源监控中,如果Process\Private Bytes计数器和Process\Working Set计数器的值
          在长时间内持续升高,同时Memory\Available bytes计数器的值持续降低,
          则很可能存在内存泄漏。

    内存资源成为系统性能的瓶颈的征兆:
        很高的换页率(high pageout rate)
        进程进入不活动状态
        交换区所有磁盘的活动次数可高
        可高的全局系统CPU利用率

     内存不够出错(out of memory errors)

    处理器:
        1 UNIX资源监控(Windows操作系统同理)中指标CPU占用率(CPU utilization),
         如果该值持续超过95%,表明瓶颈是CPU。可以考虑增加一个处理器或换一个更快的处理器。
         如果服务器专用于SQL Server,可接受的最大上限是80-85%
         合理使用的范围在60%至70%。
        2 Windows资源监控中,如果System\Processor Queue Length大于2,
          而处理器利用率(Processor Time)一直很低,则存在着处理器阻塞。

    CPU资源成为系统性能的瓶颈的征兆:  
         很慢的响应时间(slow response time)
         CPU空闲时间为零(zero percent idle CPU)
         过高的用户占用CPU时间(high percent user CPU)
         过高的系统占用CPU时间(high percent system CPU)
        长时间的有很长的运行进程队列(large run queue size sustained over time)

    磁盘I/O:
        1 UNIX资源监控(Windows操作系统同理)中指标磁盘交换率(Disk rate),如果该参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统。
        2 Windows资源监控中,如果 Disk Time和Avg.Disk Queue Length的值很高,而Page Reads/sec页面读取操作速率很低,则可能存在磁盘瓶径。

    I/O资源成为系统性能的瓶颈的征兆 :
         过高的磁盘利用率(high disk utilization)
        太长的磁盘等待队列(large disk queue length)
        等待磁盘I/O的时间所占的百分率太高(large percentage of time waiting for disk I/O)
        太高的物理I/O速率:large physical I/O rate(not sufficient in itself)
        过低的缓存命中率(low buffer cache hit ratio(not sufficient in itself))
        太长的运行进程队列,但CPU却空闲(large run queue with idle CPU)

    4.数据库服务器:
    SQL Server数据库:
        1 SQLServer资源监控中指标缓存点击率(Cache Hit Ratio),该值越高越好。
          如果持续低于80%,应考虑增加内存。
        2 如果Full Scans/sec(全表扫描/秒)计数器显示的值比1或2高,
          则应分析你的查询以确定是否确实需要全表扫描,以及SQL查询是否可以被优化。
        3 Number of Deadlocks/sec(死锁的数量/秒):死锁对应用程序的可伸缩性非常有害,
          并且会导致恶劣的用户体验。该计数器的值必须为0。
       4 Lock Requests/sec(锁请求/秒),通过优化查询来减少读取次数,可以减少该计数器的值。

    Oracle数据库:
      1 如果自由内存接近于0而且库快存或数据字典快存的命中率小于0.90,
         那么需要增加SHARED_POOL_SIZE的大小。
        快存(共享SQL区)和数据字典快存的命中率:
       select(sum(pins-reloads))/sum(pins) from v$librarycache
        select(sum(gets-getmisses))/sum(gets) from v$rowcache
        自由内存:    select * from v$sgastat where name=’free memory’
    2 如果数据的缓存命中率小于0.90,那么需要加大DB_BLOCK_BUFFERS参数的值(单位:块)。
      缓冲区高速缓存命中率:
        select name,value from v$sysstat where name in ('db block gets’,
        'consistent gets','physical reads') 
       
        Hit Ratio = 1-(physical reads / ( db block gets + consistent gets))
    3 如果日志缓冲区申请的值较大,则应加大LOG_BUFFER参数的值。
        日志缓冲区的申请情况 :
         select name,value from v$sysstat where name = 'redo log space requests'
    4 如果内存排序命中率小于0.95,则应加大SORT_AREA_SIZE以避免磁盘排序 。
       内存排序命中率 :
         select round((100*b.value)/decode
             ((a.value+b.value), 0, 1,(a.value+b.value)), 2)
           from v$sysstat a, v$sysstat b
           where a.name='sorts (disk)' and b.name='sorts (memory)

  • 有效编写软件的75条建议

    2008-06-25 17:46:40


        1. 你们的项目组使用源代码管理工具了么?
        应该用。VSS、CVS、PVCS、ClearCase、CCC/Harvest、FireFly都可以。我的选择是VSS。
      2. 你们的项目组使用缺陷管理系统了么?
        应该用。ClearQuest太复杂,我的推荐是BugZilla。

      3. 你们的测试组还在用Word写测试用例么?
        不要用Word写测试用例(Test Case)。应该用一个专门的系统,可以是Test Manager,也可以是自己开发一个ASP.NET的小网站。主要目的是Track和Browse。

      4. 你们的项目组有没有建立一个门户网站?
        要有一个门户网站,用来放Contact Info、Baselined Schedule、News等等。推荐Sharepoint Portal Server 2003来实现,15分钟就搞定。买不起SPS 2003可以用WSS (Windows Sharepoint Service)。

      5. 你们的项目组用了你能买到最好的工具么?
        应该用尽量好的工具来工作。比如,应该用VS.NET而不是Notepad来写C#。用Notepad写程序多半只是一种炫耀。但也要考虑到经费,所以说是“你能买到最好的”。

      6. 你们的程序员工作在安静的环境里么?
        需要安静环境。这点极端重要,而且要保证每个人的空间大于一定面积。

      7. 你们的员工每个人都有一部电话么?
        需要每人一部电话。而且电话最好是带留言功能的。当然,上这么一套带留言电话系统开销不小。不过至少每人一部电话要有,千万别搞得经常有人站起来喊:“某某某电话”。《人件》里面就强烈谴责这种做法。

      8. 你们每个人都知道出了问题应该找谁么?
        应该知道。任何一个Feature至少都应该有一个Owner,当然,Owner可以继续Dispatch给其他人。

      9. 你遇到过有人说“我以为…”么?
        要消灭“我以为”。Never assume anything。

      10. 你们的项目组中所有的人都坐在一起么?
        需要。我反对Virtual Team,也反对Dev在美国、Test在中国这种开发方式。能坐在一起就最好坐在一起,好处多得不得了。

      11. 你们的进度表是否反映最新开发进展情况?
        应该反映。但是,应该用Baseline(见后附件资料1)的方法来管理进度表:维护一份稳定的Schedule,再维护一份最新更改。Baseline的方法也应该用于其它的Spec。Baseline是变更管理里面的一个重要手段。

      12. 你们的工作量是先由每个人自己估算的么?
        应该让每个人自己估算。要从下而上估算工作量,而不是从上往下分派。除非有其他原因,比如政治任务工期固定等。

      13. 你们的开发人员从项目一开始就加班么?
        不要这样。不要一开始就搞疲劳战。从项目一开始就加班,只能说明项目进度不合理。当然,一些对日软件外包必须天天加班,那属于剥削的范畴。

      14. 你们的项目计划中Buffer Time是加在每个小任务后面的么?
        不要。Buffer Time加在每个小任务后面,很容易轻易的就被消耗掉。Buffer Time要整段的加在一个Milestone或者checkpoint前面。

      15. 值得再多花一些时间,从95%做到100%好值得,非常值得。
        尤其当项目后期人困马乏的时候,要坚持。这会给产品带来质的区别。

      16. 登记新缺陷时,是否写清了重现步骤?
        要。这属于Dev和Test之间的沟通手段。面对面沟通需要,详细填写Repro Steps也需要。

      17. 写新代码前会把已知缺陷解决么?
        要。每个人的缺陷不能超过10个或15个,否则必须先解决老的bug才能继续写新代码。

      18. 你们对缺陷的轻重缓急有事先的约定么?
        必须有定义。Severity要分1、2、3,约定好:蓝屏和Data Lost算Sev 1,Function Error算Sev 2,界面上的算Sev 3。但这种约定可以根据产品质量现状适当进行调整。

      19. 你们对意见不一的缺陷有三国会议么?
         必须要有。要有一个明确的决策过程。这类似于CCB (Change Control Board)的概念。

      20. 所有的缺陷都是由登记的人最后关闭的么?
        Bug应该由Opener关闭。Dev不能私自关闭Bug。

      21. 你们的程序员厌恶修改老的代码么?
        厌恶是正常的。解决方法是组织Code Review,单独留出时间来。XP也是一个方法。

      22. 你们项目组有Team Morale Activity么?
        每个月都要搞一次,吃饭、唱歌、Outing、打球、开卡丁车等等,一定要有。不要剩这些钱。

      23. 你们项目组有自己的Logo么?
        要有自己的Logo。至少应该有自己的Codename。

      24. 你们的员工有印有公司Logo的T-Shirt么?
        要有。能增强归属感。当然,T-Shirt要做的好看一些,最好用80支的棉来做。别没穿几次就破破烂烂的。

      25. 总经理至少每月参加次项目组会议要的。
        要让team member觉得高层关注这个项目。

      26. 你们是给每个Dev开一个分支么?
        反对。Branch的管理以及Merge的工作量太大,而且容易出错。

      27. 有人长期不Check-In代码么?
        不可以。对大部分项目来说,最多两三天就应该Check-In。

      28. 在Check-In代码时都填写注释了么?
        要写的,至少一两句话,比如“解决了Bug No.225”。如果往高处拔,这也算做“配置审计”的一部分。

      29. 有没有设定每天Check-In的最后期限?
        要的,要明确Check-In Deadline。否则会Build Break。

      30. 你们能把所有源码一下子编译成安装文件吗?
        要的。这是每日编译(Daily Build)的基础。而且必须要能够做成自动的。

      31. 你们的项目组做每日编译么?
      当然要做。有三样东西是软件项目/产品开发必备的:1. bug management; 2. source control; 3. daily build。 (4、是否还应该有结点文档管理?)

      32. 你们公司有没有积累一个项目风险列表?
        要。Risk Inventory。否则,下个项目开始的时候,又只能拍脑袋分析Risk了。

      33. 设计越简单越好越简单越好。
        设计时候多一句话,将来可能就带来无穷无尽的烦恼。应该从一开始就勇敢的砍。这叫scope management。

      34. 尽量利用现有的产品、技术、代码千万别什么东西都自己Coding。BizTalk和Sharepoint就是最好的例子,有这两个作为基础,可以把起点提高很多。或者可以尽量多用现成的Control之类的。或者尽量用XML,而不是自己去Parse一个文本文件;尽量用RegExp,而不是自己从头操作字符串,等等等等。这就是“软件复用”的体现。

      35. 你们会隔一段时间就停下来夯实代码么?
        要。最好一个月左右一次。传言去年年初Windows组在Stevb的命令下停过一个月增强安全。Btw,“夯”这个字念“hang”,第一声。

      36. 你们的项目组每个人都写Daily Report么?
        要写。五分钟就够了,写10句话左右,告诉自己小组的人今天我干了什么。一则为了沟通,二则鞭策自己(要是游手好闲一天,自己都会不好意思写的)。

       37. 你们的项目经理会发出Weekly Report么?
         要。也是为了沟通。内容包括目前进度,可能的风险,质量状况,各种工作的进展等。

       38. 你们项目组是否至少每周全体开会一次?
         要。一定要开会。程序员讨厌开会,但每个礼拜开会时间加起来至少应该有4小时。包括team meeting, spec review meeting, bug triage meeting。千万别大家闷头写code。

      39. 你们项目组的会议、讨论都有记录么?
        会前发meeting request和agenda,会中有人负责主持和记录,会后有人负责发meeting minutes,这都是effective meeting的要点。而且,每个会议都要形成agreements和action items。

       40. 其他部门知道你们项目组在干什么么?
        要发一些Newsflash给整个大组织。Show your team’s value。否则,当你坐在电梯里面,其他部门的人问:“你们在干嘛”,你回答“ABC项目”的时候,别人全然不知,那种感觉不太好。

      41. 通过Email进行所有正式沟通
        Email的好处是免得抵赖。但也要避免矫枉过正,最好的方法是先用电话和当面说,然后Email来确认。

      42. 为项目组建立多个Mailing Group
        如果在AD+Exchange里面,就建Distribution List。比如,我会建ABC Project Core Team,ABC Project Dev Team,ABC Project All Testers,ABC Project Extended Team等等。这样发起Email来方便,而且能让该收到email的人都收到、不该收到不被骚扰。

      43. 每个人都知道哪里可以找到全部的文档么?
        应该每个人都知道。这叫做知识管理(Knowledge Management)。最方便的就是把文档放在一个集中的File Share,更好的方法是用Sharepoint。

      44. 你做决定、做变化时,告诉大家原因了么?
        要告诉大家原因。Empower team member的手段之一是提供足够的information,这是MSF一开篇的几个原则之一。的确如此,tell me why是人之常情,tell me why了才能有understanding。中国人做事喜欢搞限制,限制信息,似乎能够看到某一份文件的人就是有身份的人。大错特错。权威、权力,不在于是不是能access information/data,而在于是不是掌握资源。

      45. Stay agile and expect change 要这样。
        需求一定会变的,已经写好的代码一定会被要求修改的。做好心理准备,对change不要抗拒,而是expect change。

      46. 你们有没有专职的软件测试人员?
        要有专职测试。如果人手不够,可以peer test,交换了测试。千万别自己测试自己的。

      47. 你们的测试有一份总的计划来规定做什么和怎么做么?
         这就是Test Plan。要不要做性能测试?要不要做Usability测试?什么时候开始测试性能?测试通过的标准是什么?用什么手段,自动的还是手动的?这些问题需要用Test Plan来回答。

       48. 你是先写Test Case然后再测试的么?
        应该如此。应该先设计再编程、先test case再测试。当然,事情是灵活的。我有时候在做第一遍测试的同时补上test case。至于先test case再开发,我不喜欢,因为不习惯,太麻烦,至于别人推荐,那试试看也无妨。

      49. 你是否会为各种输入组合创建测试用例?
        不要,不要搞边界条件组合。当心组合爆炸。有很多test case工具能够自动生成各种边界条件的组合——但要想清楚,你是否有时间去运行那么多test case。

      50. 你们的程序员能看到测试用例么?
        要。让Dev看到Test Case吧。我们都是为了同一个目的走到一起来的:提高质量。

       51. 你们是否随便抓一些人来做易用性测试?
        要这么做。自己看自己写的程序界面,怎么看都是顺眼的。这叫做审美疲劳——臭的看久了也就不臭了,不方便的永久了也就习惯了。
      52. 你对自动测试的期望正确么?
        别期望太高。依我看,除了性能测试以外,还是暂时先忘掉“自动测试”吧,忘掉WinRunner和LoadRunner吧。对于国内的软件测试的现状来说,只能“矫枉必须过正”了。

      53. 你们的性能测试是等所有功能都开发完才做的么?
        不能这样。性能测试不能被归到所谓的“系统测试”阶段。早测早改正,早死早升天。

      54. 你注意到测试中的杀虫剂效应了么?
        虫子有抗药性,Bug也有。发现的新Bug越来越少是正常的。这时候,最好大家交换一下测试的area,或者用用看其他工具和手法,就又会发现一些新bug了。

       55. 你们项目组中有人能说出产品的当前整体质量情况么?
        要有。当老板问起这个产品目前质量如何,Test Lead/Manager应该负责回答。

      56. 你们有单元测试么?
        单元测试要有的。不过没有单元测试也不是不可以,我做过没有单元测试的项目,也做成功了——可能是侥幸,可能是大家都是熟手的关系。还是那句话,软件工程是非常实践、非常工程、非常灵活的一套方法,某些方法在某些情况下会比另一些方法好,反之亦然。

      57. 你们的程序员是写完代码就扔过墙的么?
        大忌。写好一块程序以后,即便不做单元测试,也应该自己先跑一跑。虽然有了专门的测试人员,做开发的人也不可以一点测试都不做。微软还有Test Release Document的说法,程序太烂的话,测试有权踢回去。

       58. 你们的程序中所有的函数都有输入检查么?
        不要。虽然说做输入检查是write secure code的要点,但不要做太多的输入检查,有些内部函数之间的参数传递就不必检查输入了,省点功夫。同样的道理,未必要给所有的函数都写注释。写一部分主要的就够了。

       59. 产品有统一的错误处理机制和报错界面么?
        要有。最好能有统一的error message,然后每个error message都带一个error number。这样,用户可以自己根据error number到user manual里面去看看错误的具体描述和可能原因,就像SQL Server的错误那样。同样,ASP.NET也要有统一的Exception处理。可以参考有关的Application Block。

      60. 你们有统一的代码书写规范么?
        要有。Code Convention很多,搞一份来发给大家就可以了。当然,要是有FxCop这种工具来检查代码就更好了。

      61. 你们的每个人都了解项目的商业意义么?
        要。这是Vision的意思。别把项目只当成工作。有时候要想着自己是在为中国某某行业的信息化作先驱者,或者时不时的告诉team member,这个项目能够为某某某国家部门每年节省多少多少百万的纳税人的钱,这样就有动力了。平凡的事情也是可以有个崇高的目标的。

       62. 产品各部分的界面和操作习惯一致么?
        要这样。要让用户觉得整个程序好像是一个人写出来的那样。

       63. 有可以作为宣传亮点的Cool Feature么?
        要。这是增强团队凝聚力、信心的。而且,“一俊遮百丑”,有亮点就可以掩盖一些问题。这样,对于客户来说,会感觉产品从质量角度来说还是acceptable的。或者说,cool feature或者说亮点可以作为质量问题的一个事后弥补措施。

       64. 尽可能缩短产品的启动时间要这样。
         软件启动时间(Start-Up time)是客户对性能好坏的第一印象。

       65. 不要过于注重内在品质而忽视了第一眼的外在印象程序员容易犯这个错误:太看重性能、稳定性、存储效率,但忽视了外在感受。而高层经理、客户正相反。这两方面要兼顾,协调这些是PM的工作。

       66. 你们根据详细产品功能说明书做开发么?
        要这样。要有设计才能开发,这是必须的。设计文档,应该说清楚这个产品会怎么运行,应该采取一些讲故事的方法。设计的时候千万别钻细节,别钻到数据库、代码等具体实现里面去,那些是后面的事情,一步步来不能着急。

       67. 开始开发和测试之前每个人都仔细审阅功能设计么?
        要做。Function Spec review是用来统一思想的。而且,review过以后形成了一致意见,将来再也没有人可以说“你看,当初我就是反对这么设计的,现在吃苦头了吧”

      68. 所有人都始终想着The Whole Image么?
        要这样。项目里面每个人虽然都只是在制造一片叶子,但每个人都应该知道自己在制造的那片叶子所在的树是怎么样子的。我反对软件蓝领,反对过分的把软件制造看成流水线、车间。参见第61条。

       69. Dev工作的划分是单纯纵向或横向的么?
        不能单纯的根据功能模块分,或者单纯根据表现层、中间层、数据库层分。我推荐这么做:首先根据功能模块分,然后每个“层”都有一个Owner来Review所有人的设计和代码,保证consistency。

      70. 你们的程序员写程序设计说明文档么?
        要。不过我听说微软的程序员1999年以前也不写。所以说,写不写也不是绝对的,偷懒有时候也是可以的。参见第56条。

      71. 你在招人面试时让他写一段程序么?
        要的。我最喜欢让人做字符串和链表一类的题目。这种题目有很多循环、判断、指针、递归等,既不偏向过于考算法,也不偏向过于考特定的API。

      72. 你们有没有技术交流讲座?
        要的。每一两个礼拜搞一次内部的Tech Talk或者Chalk Talk吧。让组员之间分享技术心得,这笔花钱送到外面去培训划算。

      73. 你们的程序员都能专注于一件事情么?
        要让程序员专注一件事。例如说,一个部门有两个项目和10个人,一种方法是让10个人同时参加两个项目,每个项目上每个人都花50%时间;另一种方法是5个人去项目A,5个人去项目B,每个人都100%在某一个项目上。我一定选后面一种。这个道理很多人都懂,但很多领导实践起来就把属下当成可以任意拆分的资源了。

      74. 你们的程序员会夸大完成某项工作所需要的时间么?
        会的,这是常见的,尤其会在项目后期夸大做某个change所需要的时间,以次来抵制change。解决的方法是坐下来慢慢磨,磨掉程序员的逆反心理,一起分析,并把估算时间的颗粒度变小。

      75. 尽量不要用Virtual Heads 最好不要用Virtual Heads。
        Virtual heads意味着resource is not secure,shared resource会降低resource的工作效率,容易增加出错的机会,会让一心二用的人没有太多时间去review spec、review design。一个dedicated的人,要强过两个只能投入50%时间和精力的人。我是吃过亏的:7个part time的tester,发现的Bug和干的活,加起来还不如两个full-time的。参见第73条。73条是针对程序员的,75条是针对Resource Manager的。

         76.  非常注意用户体验和美工

     

    -----------------

    附件资料1

     基线(Baseline)说起. 基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.

          基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准,随后的工作基于此标准,并且只有经过授权后才能变更这个标准。建立一个初始基线后,以后每次对其进行的变更都将记录为一个差值,直到建成下一个基线。

          参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展,基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线,开发人员就采用新的基线,以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。

          建立基线的三大原因是:重现性、可追踪性和报告。

          重现性是指及时返回并重新生成软件系统给定发布版的能力,或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布说明。

          建立基线后,需要标注所有组成构件和基线,以便能够对其进行识别和重新建立。

          建立基线有以下几个优点:

          基线为开发工件提供了一个定点和快照。

          新项目可以从基线提供的定点之中建立。作为一个单独分支,新项目将与随后对原始项目(在主要分支上)所进行的变更进行隔离。

          各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。

          当认为更新不稳定或不可信时,基线为团队提供一种取消变更的方法。

          您可以利用基线重新建立基于某个特定发布版本的配置,这样也可以重现已报告的错误。

          使用

          定期建立基线以确保各开发人员的工作保持同步。但是,在项目过程中,应该在每次迭代结束点(次要里程碑),以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线:

          生命周期目标里程碑(先启阶段)

          生命周期构架里程碑(精化阶段)

          初始操作性能里程碑(构建阶段)

          产品发布里程碑(产品化阶段)

  • 自动化测试的七个步骤(l转载)

    2008-06-25 16:04:28

    【摘要】 我们对自动化测试充满了希望,然而,自动化测试却经常带给我们沮丧和失望。虽然,自动化测试可以把我们从困难的环境中解放出来,在实施自动化测试解决问题的同时,又带来同样多的问题。在开展自动化测试的工作中,关键问题是遵循软件开发的基本规则。本文介绍自动化测试的 7 个步骤:改进自动化测试过程,定义需求,验证概念,支持产品的可测试性,具有可延续性的设计( design for sustainability ),有计划的部署和面对成功的挑战。按照以上 7 个步骤,安排你的人员、工具和制定你的自动化测试项目计划,你将会通往一条成功之路。

    一个故事 :

    我在很多软件公司工作过,公司规模有大有小,也和来自其他公司的人员交流,因此经历过或者听说过影响自动化测试效果的各种各样的的问题。本文将提供若干方法规避可能在自动化测试中出现的问题。我先给大家讲一个故事,以便各位了解自动化测试会出现哪些问题。

    以前,我们有一个软件项目,开发小组内所有的人都认为应该在项目中采用自动化测试。软件项目的经理是 Anita Delegate 。她评估了所有可能采用的自动化测试工具,最后选择了一种,并且购买了几份拷贝。她委派一位员工 ——Jerry Overworked 负责自动化测试工作。 Jerry 除了负责自动化测试工作,还有其他的很多任务。他尝试使用刚刚购买的自动化测试工具。当把测试工具应用到软件产品测试中的时候,遇到了问题。这个测试工具太复杂,难于配置。他不得不给测试工具的客户支持热线打了几个电话。最后, Jerry 认识到,他需要测试工具的技术支持人员到现场帮助安装测试工具,并找出其中的问题。在打过几个电话后,测试工具厂商派过来一位技术专家。技术专家到达后,找出问题所在,测试工具可以正常工作了。这还算是顺利了。但是,几个月后,他们还是没有真正实现测试自动化, Jerry 拒绝继续从事这个项目的工作,他害怕自动化测试会一事无成,只是浪费时间而已。

    项目经理 Anita 把项目重新指派给 Kevin Shorttimer ,一位刚刚被雇佣来做软件测试的人员。 Kevin 刚刚获得计算机科学的学位,希望通过这份工作迈向更有挑战性的、值得去做的工作。 Anita 送 Kevin 参加工具培训,避免 Kevin 步 Jerry 的后尘 —— 由于使用测试工具遇到困难而变得沮丧,导致放弃负责的项目。 Kevin 非常兴奋。这个项目的测试需要重复测试,有点令人讨厌,因此,他非常愿意采用自动化测试。一个主要的版本发布后, Kevin 准备开始全天的自动化测试,他非常渴望得到一个机会证明自己可以写非常复杂的,有难度的代码。他建立了一个测试库,使用了一些技巧的方法,可以支持大部分的测试,这比原计划多花费了很多时间,不过, Kevin 使整个测试工作开展的很顺利。他用已有的测试套测试新的产品版本,并且确实发现了 bug 。接下来, Kevin 得到一个从事软件开发职位的机会,离开了自动化的岗位。

    Ahmed Hardluck 接手 Kevin 的工作,从事自动化测试执行工作。他发现 Kevin 留下的文档不仅少,并且没有太多的价值。 Ahmed 花费不少时间去弄清楚已有的测试设计和研究如何开展测试执行工作。这个过程中, Ahmed 经历了很多失败,并且不能确信测试执行的方法是否正确。测试执行中,执行失败后的错误的提示信息也没有太多的参考价值,他不得不更深的钻研。一些测试执行看起来仿佛永远没有结束。另外一些测试执行需要一些特定的测试环境搭建要求,他更新测试环境搭建文档,坚持不懈地工作。后来,在自动化测试执行中,它发现几个执行失败的结果,经过分析,是回归测试的软件版本中有 BUG ,导致测试执行失败,发现产品的 BUG 后,每个人都很高兴。接下来,他仔细分析测试套中的内容,希望通过优化测试套使测试变得更可靠,但是,这个工作一直没有完成,预期的优化结果也没有达到。按照计划,产品的下一个发布版本有几个主要的改动, Ahmed 立刻意识到产品的改动会破坏已有的自动化测试设计。接下来,在测试产品的新版本中,绝大多数测试用例执行失败了, Ahmed 对执行失败的测试研究了很长时间,然后,从其他人那里寻求帮助。经过商讨,自动化测试应该根据产品的新接口做修改,自动化测试才能运转起来。最后,大家根据新接口修改自动化测试,测试都通过了。产品发布到了市场上。接下来,用户立刻打来投诉电话,投诉软件无法工作。大家才发现自己改写了一些自动化测试脚本,导致一些错误提示信息被忽略了。虽然,实际上测试执行是失败的,但是,由于改写脚本时的一个编程错误导致失败的测试执行结果被忽略了。这个产品终于失败了。

    这是我的故事。或许您曾经亲身经历了故事当中某些情节。不过,我希望你没有这样的相似结局。本文将给出一些建议,避免出现这样的结局。

    问题

    这个故事阐明了几个使自动化测试项目陷入困境的原因:

    自动化测试时间不充足:根据项目计划的安排,测试人员往往被安排利用自己的个人时间或者项目后期介入自动化测试。这使得自动化测试无法得到充分的时间,无法得到真正的关注。

    缺乏清晰的目标:有很多好的理由去开展自动化测试工作,诸如自动化测试可以节省时间,使测试更加简单,提高测试的覆盖率,可以让测试人员保持更好的测试主动性。但是,自动化测试不可能同时满足上述的目标。不同的人员对自动化测试有不同的希望,这些希望应该提出来,否则很可能面对的是失望。

    缺乏经验:尝试测试自己的程序的初级的程序员经常采用自动化自动化测试。由于缺乏经验,很难保证自动化测试的顺利开展。

    更新换代频繁( High turnover ):测试自动化往往需要花费很多时间学习的,当自动化测试更新换代频繁的时候,你就丧失了刚刚学习到的自动化测试经验。

    对于绝望的反应:在测试还远没有开始的时候,问题就已经潜伏在软件中了。软件测试不过是发现了这些潜伏的问题而已。就测试本身而言,测试是一件很困难的工作。当在修改过的软件上一遍接一遍的测试时,测试人员变得疲劳起来。测试什么时候后结束?当按照计划的安排,软件应该交付的时候,测试人员的绝望变得尤其强烈。如果不需要测试,那该有多好呀!在这种环境中,自动化测试可能是个可以选择的解决方法。但是,自动化测试却未必是最好的选择,他不是一个现实的解决方法,更像是一个希望。

    不愿思考软件测试:很多人发现实现产品的自动化测试比测试本身更有趣。在很多软件项目发生这样的情况,自动化工程师不参与到软件测试的具体活动中。由于测试的自动化与测试的人为割裂,导致很多自动化对软件测试并没有太大的帮助。

    关注于技术:如何实现软件的自动化测试是一个很吸引人的技术问题。不过,过多的关注如何实现自动化测试,导致忽略了自动化测试方案是否符合测试需要。

    遵守软件开发的规则

    你可能了解 SEI (软件工程研究所)提出的 CMM (能力成熟度模型)。 CMM 分为 5 个界别,该模型用来对软件开发组织划分等级。 Jerry Weinberg (美国著名软件工程专家)也创建了自己的一套软件组织模型,在他的组织模型中增加了一个额外的级别,他称之为零级别。很显然,一个零模式的组织实际上也是开发软件;零模式组织中,在开发人员和用户之间没有差别 [Weinberg 1992] 。恰恰在这类组织环境中,经常采用自动化测试方法。因此,把资源用于自动化测试,并且把自动化测试当作一个软件开发活动对待,把软件测试自动化提升到一级。这是解决测试自动化的核心的方案。我们应该像运作其他的开发项目一样来运作软件自动化测试项目。

    像其他软件开发项目一样,我们需要软件开发人员专注于测试自动化的开发任务;像其他软件开发项目一样,自动化测试可以自动完成具体的测试任务,对于具体的测试任务来说,自动化开发人员可能不是这方面的专家,因此,软件测试专家应该提供具体测试任务相关的咨询,并且提供测试自动化的需求;像其他软件开发项目一样,如果在开发编码之前,对测试自动化作了整体设计有助于测试自动化开发的顺利开展。像其他软件开发项目一样,自动化测试代码需要跟踪和维护,因此,需要采用源代码管理。像其他软件开发项目一样,测试自动化也会出现 BUG ,因此,需要有计划的跟踪 BUG ,并且对修改后的 BUG 进行测试。像其他软件开发项目一样,用户需要知道如何使用软件,因此,需要提供用户使用手册。

    本文中不对软件开发做过多讲述。我假定您属于某个软件组织,该组织已经知道采用何种合理的、有效的方法开发软件。我仅仅是推动您在自动化测试开发过程中遵守已经建立的软件开发规则而已。本文按照在软件开发项目中采用的标准步骤组织的,重点关注测试自动化相关的事宜和挑战。

    •  改进软件测试过程

    •  定义需求

    •  验证概念

    •  支持产品的可测试性

    •  可延续性的设计( design for sustainability )

    •  有计划的部署

    •  面对成功的挑战

    步骤一:改进软件测试过程

    如果你负责提高一个商业交易操作的效率,首先,你应该确认已经很好的定义了这个操作的具体过程。然后,在你投入时间和金钱采用计算机提供一套自动化的商业交易操作系统之前,你想知道是否可以采用更简单、成本更低的的方法。同样的,上述过程也是用于自动化测试。我更愿意把 “ 测试自动化 ” 这个词解释成能够使测试过程简单并有效率,使测试过程更为快捷,没有延误。运行在计算机上的自动化测试脚本只是自动化测试的一个方面而已。

    例如,很多测试小组都是在回归测试环节开始采用测试自动化的方法。回归测试需要频繁的执行,再执行,去检查曾经执行过的有效的测试用例没有因为软件的变动而执行失败。回归测试需要反复执行,并且单调乏味。怎样才能做好回归测试文档化的工作呢?通常的做法是采用列有产品特性的列表,然后对照列表检查。这是个很好的开始,回归测试检查列表可以告诉你应该测试哪些方面。不过,回归测试检查列表只是合于那些了解产品,并且知道需要采用哪种测试方法的人。

    在你开始测试自动化之前,你需要完善上面提到的回归测试检查表,并且,确保你已经采用了确定的的测试方法,指明测试中需要什么样的数据,并给出设计数据的完整方法。如果测试掌握了基本的产品知识,这会更好。确认可以提供上面提到的文档后,需要明确测试设计的细节描述,还应该描述测试的预期结果,这些通常被忽略,建议测试人员知道。太多的测试人员没有意识到他们缺少什么,并且由于害怕尴尬而不敢去求助。这样一份详细的文档给测试小组带来立竿见影的效果,因为,现在任何一个具有基本产品知识的人根据文档可以开展测试执行工作了。在开始更为完全意义上的测试自动化之前,必须已经完成了测试设计文档。测试设计是测试自动化最主要的测试需求说明。不过,这时候千万不要走极端去过分细致地说明测试执行的每一个步骤,只要确保那些有软件基本操作常识的人员可以根据文档完成测试执行工作既可。但是,不要假定他们理解那些存留在你头脑中的软件测试执行的想法,把这些测试设计的思路描述清楚就可以了。

    我以前负责过一个软件模块的自动化测试工作。这个模块的一些特性导致实现自动化非常困难。当我了解到这项工作无需在很短的时间内完成后,决定制定一个详细回归测试设计方案。我仔细地检查了缺陷跟踪库中与该模块相关的每个已经关闭的缺陷,针对每个缺陷,我写了一个能够发现该问题的测试执行操作。我计划采用这种方法提供一个详细的自动化需求列表,这可以告诉我模块的那一部分最适合自动化测试。在完成上述工作后,我没有机会完成测试自动化的实现工作。不过,当我们需要对这个模块做完整回归测试的时候,我将上面提到的文档提供给若干只了解被测试产品但是没有测试经验的测试人员。依照文档的指导,几乎不需要任何指导的情况下,各自完成了回归测试,并且发现了 BUG 。从某种角度看,这实际上是一次很成功的自动化测试。在这个项目中,我们与其开发自动化测试脚本,还不如把测试执行步骤文档化。后来,在其它项目中,我们开发了自动化测试脚本,发现相关人员只有接受相关培训才能理解并执行自动化测试脚本,如果测试自动化设计的很好,可能会好一些。不过,经过实践我们总结出完成一份设计的比较好的测试文档,比完成一份设计良好的测试脚本简单的多。

    另外一个提高测试效率的简单方法是采用更多的计算机。很多测试人员动辄动用几台计算机,这一点显而易见。我之所以强调采用更多的计算机是因为,我曾经看到一些测试人员被误导在单机上努力的完成某些大容量的自动化测试执行工作,这种情况下由于错误的使用了测试设备、测试环境,导致测试没有效果。因此,自动化测试需要集中考虑所需要的支撑设备。

    针对改进软件测试过程,我的最后一个建议是改进被测试的产品,使它更容易被测试,有很多改进措施既可以帮助用户更好的使用产品,也可以帮助测试人员更好的测试产品。稍后,我将讨论自动化测试的可测试需求。这里,我只是建议给出产品的改进点,这样对手工测试大有帮助。

    一些产品非常难安装,测试人员在安装和卸载软件上花费大量的时间。这种情况下,与其实现产品安装的自动化测试,还不如改进产品的安装功能。采用这种解决办法,最终的用户会受益的。另外的一个处理方法是考虑开发一套自动安装程序,该程序可以和产品一同发布。事实上,现在有很多专门制作安装程序的商用工具。

    另一些产品改进需要利用工具在测试执行的日志中查找错误。采用人工方法,在日志中一页一页的查询报错信息很容易会让人感到乏味。那么,赶快采用自动化方法吧。如果你了解日志中记录的错误信息格式,写出一个错误扫描程序是很容易的事情。如果,你不能确定日志中的错误信息格式,就开始动手写错误扫描程序,很可能面临的是一场灾难。不要忘记本文开篇讲的那个故事中提到的测试套无法判断测试用例是否执行失败的例子。最终用户也不愿意采用通过搜索日志的方法查找错误信息。修改错误信息的格式,使其适合日志扫描程序,便于扫描工具能够准确的扫描到所有的错误信息。这样,在测试中就可以使用扫描工具了。

    通过改进产品的性能对测试也是大有帮助的。很显然的,如果产品的性能影响了测试速度,鉴别出性能比较差的产品功能,并度量该产品功能的性能,把它作为影响测试进度的缺陷,提交缺陷报告。

    上面所述的几个方面可以在无需构建自动化测试系统的情况下,大幅度的提高测试效率。改进软件测试过程会花费你构建自动化测试系统的时间,不过改进测试过程无疑可以使你的自动化测试项目更为顺利开展起来。

    步骤二:定义需求

    在前面的故事中,自动化工程师和自动化测试的发起者的目标存在偏差。为了避免这种情况,需要在自动化测试需求上保持一致。应该有一份自动化测试需求,用来描述需要测试什么。测试需求应该在测试设计阶段详细描述出来,自动化测试需求描述了自动化测试的目标。很多人认为自动化测试显然是一件好事情,但是,他们不愿意对自动化测试的目标给出清晰的描述。下面是人们选用自动化测试的几个原因:

    •  加快测试进度从而加快产品发布进度

    •  更多的测试

    •  通过减少手工测试降低测试成本

    •  提高测试覆盖率

    •  保证一致性

    •  提高测试的可靠性

    •  测试工作可以由技术能力不强测试人员完成

    •  定义测试过程,避免过分依赖个人

    •  测试变得更加有趣

    •  提高了编程技能

    开发管理、测试管理和测试人员实现自动化测试的目标常常是有差别的。除非三者之间达成一致,否则很难定义什么是成功的自动化测试。

    当然,不同的情况下,有的自动化测试目标比较容易达到,有的则比较难以达到。测试自动化往往对测试人员的技术水平要求很高,测试人员必须能理解充分的理解自动化测试,从而通过自动化测试不断发现软件的缺陷。不过,自动化测试不利于测试人员不断的积累测试经验。不管怎么样,在开始自动化测试之前应该确定自动化测试成功的标准。

    手工测试人员在测试执行过程中的一些操作能够发现不引人注意的问题。他们计划并获取必要的测试资源,建立测试环境,执行测试用例。测试过程中,如果有什么异常的情况发生,手工测试人员立刻可以关注到。他们对比实际测试结果和预期测试结果,记录测试结果,复位被测试的软件系统,准备下一个软件测试用例的环境。他们分析各种测试用例执行失败的情况,研究测试过程可疑的现象,寻找测试用例执行失败的过程,设计并执行其他的测试用例帮助定位软件缺陷。接下来,他们写作缺陷报告单,保证缺陷被修改,并且总结所有的缺陷报告单,以便其他人能够了解测试的执行情况。

    千万不要强行在测试的每个部分都采用自动化方式。寻找能够带来最大回报的部分,部分的采用自动化测试是最好的方法。或许你可能发现采用自动化执行和手动确认测试执行结果的方式是个很好的选择,或许你可以采用自动化确认测试结果和手工测试执行相结合和方式。我听到有人讲,除非测试的各个环节都采用自动化方式,否则不是真正意义上的自动化测试,这真是胡言乱语。如果仅仅是为了寻找挑战,可以尝试在测试的每个环节都采用自动化方法。但是,如果寻找成功测试的方法,请关注那些可以快速建立的,可以反复利用的自动化测试。

    定义自动化测试项目的需求要求我们全面地、清楚地考虑各种情况,然后给出权衡后的需求,并且可以使测试相关人员更加合理的提出自己对自动化测试的期望。通过定义自动化测试需求,距离成功的自动化测试近了一步。

    步骤三:验证概念

    在前面的故事当中,那个自动化测试人员在对测试方向一片茫然的情况下一头扎进了自动化测试项目中。不过,在项目的进行中,他得到了来自各个方面的支持。

    你可能还没有认识到这一点,不过,你必须验证自动化测试项目的可行性。验证过程花费的时间往往比人们预期的要长,并且需要来自你身边的各种人的帮助。

    很多年前,我从事一个测试自动化项目的工作,参加项目的人员有各种各样的好点子。我们设计了一个复杂的自动化测试系统,并且非常努力工作去实现系统的每个模块。我们定期的介绍测试自动化的设计思路和工作进度,甚至演示已经完成的部分功能。但是,我们没有演示如何利用该套测试自动化系统如何开展实际的测试工作。最后,整个项目被取消了,此后,我再也没有犯这个错误。

    你需要尽可能快地验证你采用的测试工具和测试方法的可行性,站在产品的角度验证你所测试的产品采用自动化测试的可行性。这通常是很困难的,需要尽快地找出可行性问题的答案,需要确定你的测试工具和测试方法对于被测试的产品和测试人员是否合适。你需要做是验证概念 —— 一个快速、有说服力的测试套可以证明你选在测试工具和测试方法的正确性,从而验证了你的测试概念。你选择的用来验证概念的测试套是评估测试工具的最好的方式。

    对于很多人来说,自动化测试意味着 GUI 自动化测试,我不同意这种观点。我曾经做过 GUI 和非 GUI 自动化测试,并惊奇的发现这两类测试的测试计划有很大的互补性。不过, GUI 测试工具很昂贵、并且过分讲究。选择合适的 GUI 测试工具是很重要的,因为,如果没有选择合适的测试工具,你会遇到很多不可预测的困难。 Elisabeth Hendrickson 曾经写过一篇关于选择测试的工具的指导性文章 [Hendrickson 1999] 。我建议在评估测试工具中,找出能够验证你的想法的证据是很重要的环节。这需要测试工具至少有一个月试用期,你可能打算现在购买一份测试工具,然后直到评估完成后再购买更多份。你需要在付出大笔金钱购买测试工具的之前,找出工具存在的问题。这样,你可以从测试工具供应商得到更好的帮助,当你打算更换工具的时候,你不会感觉很为难。

    下面是一些候选的验证概念的试验:

    回归测试:你准备在每个版本运行同样的测试用例吗?回归测试是最宜采用自动化测试的环节。

    配置测试:你的软件支持多少种不同的平台?你打算在所有支持的平台上测试执行所有的测试用例吗?如果是的,那么采用自动化测试是有帮助的。

    测试环境建立:对于大量不同的测试用例,可能需要相同的测试环境搭建过程。在开展自动化测试执行之前,先把测试环境搭建实现自动化。

    非 GUI 测试:实现命令行和 API 的测试自动化比 GUI 自动化测试容易的多。

    无论采用什么测试方法,定义一个看得见的目标,然后集中在这个目标上。验证你自动化测试概念可以使自动化更进一步迈向成功之路。

    步骤四:支持产品的可测试性

    软件产品一般会用到下面三种不同类别的接口:命令行接口( command line interfaces ,缩写 CLIs) 、应用程序接口( API )、图形用户接口( GUI )。有些产品会用到所有三类接口,有些产品只用到一类或者两类接口,这些是测试中所需要的接口。从本质上看, API 接口和命令行接口比 GUI 接口容易实现自动化,去找一找你的被测产品是否包括 API 接口或者命令行接口。有些时候,这两类接口隐藏在产品的内部,如果确实没有,需要鼓励开发人员在产品中提供命令行接口或者 API 接口,从而支持产品的可测试性。

    下面,更多多的讲解 GUI 自动化测试相关内容。这里有几个原因导致 GUI 自动化测试比预期的要困难。第一个原因是需要手工完成部分脚本。绝大多数自动化测试工具都有 “ 录制回放 ” 或者 “ 捕捉回放 ” 功能,这确实是个很好的方法。可以手工执行测试用例,测试工具在后台记住你的所有操作,然后产生可以用来重复执行的测试用例脚本。这是一个很好的方法,但是很多时候却不能奏效。很多软件测试文章的作者得出结论 “ 录制回放 ” 虽然可以生成部分测试脚本,但是有很多问题导致 “ 录制回放 ” 不能应用到整个测试执行过程中。 [Bach 1996, Pettichord 1996, Kaner 1997, Linz 1998, Hendrickson 1999, Kit 1999, Thomson 1999, Groder 1999]. 结果, GUI 测试还是主要由手工完成。

    第二个原因,把 GUI 自动化测试工和被测试的产品有机的结合在一起需要面临技术上的挑战。经常要在采用众多专家意见和最新的 GUI 接口技术才能使 GUI 测试工具正常工作。这个主要的困难也是 GUI 自动化测试工具价格昂贵的主要原因之一。非标准的、定制的控件会增加测试的困难,解决方法总是有的,可以采用修改产品源代码的方式,也可以从测试工具供应商处升级测试工具。另外,还需要分析测试工具中的 BUG ,并且给工具打补丁。也可能测试工具需要做相当的定制,以便能有效地测试产品界面上的定制控件。 GUI 测试中,困难总是意外出现,让人惊奇。你也可能需要重新设计你的测试以规避那些存在问题的界面控件。

    第三个原因, GUI 设计方案的变动会直接带来 GUI 自动化测试复杂度的提高。在开发的整个过程中,图形界面经常被修改或者完全重设计,这是出了名的事情。一般来讲,第一个版本的图形界面都是很糟糕。如果处在图形界面方案不停变动的时候,就开展 GUI 自动化测试是不会有任何进展的,你只能花费大量的时间修改测试脚本,以适应图形界面的变更。不管怎样,即便界面的修改会导致测试修改脚本,你也不应该反对开发人员改进图形界面。一旦原始的设计完成后,图形界面接口下面的编程接口就固定下来了。

    上面提到的这些原因都是基于采用 GUI 自动化测试的方法完成产品的功能测试。图形界面接口当然需要测试,可以考虑实现 GUI 测试自动化。不过,你也应该考虑采用其他方法测试产品的核心功能,并且这些测试不会因为图形界面发生变化而被中断,这类测试应该采用命令行接口或者 API 接口。我曾经看到有人选择 GUI 自动化测试,因为,他们不打算修改被测试产品,但是,最终他们认识到必须对产品做修改,以保证 GUI 测试自动化可以正常工作。无论你选择哪种方法,自动化都需要对被测试的产品做修改。因此,采用可编程的接口是最可靠的。

    为了让 API 接口测试更为容易,应该把接口与某种解释程序,例如 Tcl 、 Perl 或者 Python 绑定在一起。这使交互式测试成为可能,并且可以缩短自动化测试的开发周期。采用 API 接口的方式,还可以实现独立的产品模块的单元测试自动化。

    一个关于隐藏可编程接口的例子是关于 InstallShield—— 非常流行的制作安装盘的工具。 InstallShield 有命令行选项,采用这种选项可以实现非 GUI 方式的安装盘,采用这种方式,从提前创建好的文件中读取安装选项。这种方式可能比采用 GUI 的安装方式更简单更可靠。

    另一个例子是关于如何避免基于 WEB 软件的 GUI 自动化测试。采用 GUI 测试工具可以通过浏览器操作 WEB 界面。 WEB 浏览器是通过 HTTP 协议与 WEB 服务器交互的,所以直接测试 HTTP 协议更为简单。 Perl 可以直接连接 TCP/IP 端口,完成这类的自动化测试。采用高级接口技术,譬如客户端 JAVA 或者 ActiveX 不可能利用这种方法。但是,如果在合适的环境中采用这种方式,你将发现这种方式的自动化测试比 GUI 自动化测试更加便宜更加简单。

    我曾经受雇在一家公司负责某个产品 GUI 相关的自动化测试,该产品也提供命令行接口,不过,他们已经实现了 GUI 的自动化测试。经过一段时间的研究,我发现找到图形界面中的 BUG 并不困难,不过,用户并不关注图形界面,他们更喜欢使用命令行。我还发现我们还没有针对最新的产品功能(这些功能即可通过 GUI 的方式,也可以通过命令行的方式使用)实现自动化测试。我决定推迟 GUI 自动化测试,扩展命令行测试套,测试新增的产品功能。现在回过头看这个决定,我没有选择 GUI 自动化测试是最大的成功之处,如果采用了 GUI 自动化测试所有的时间和努力都会浪费在其中。他们已经准备好做 GUI 自动化测试了,并且已经购买了一套测试工具和其他需要的东西,但我知道在开展具体的 GUI 自动化测试活动中,会遇到各种各样的困难和障碍。

    无论你需要支持图形界面接口、命令行接口还是 API 接口,如果你尽可能早的在产品设计阶段提出产品的可测试性设计需求,未来的测试工作中,你很可能成功。尽可能早的启动自动化测试项目,提出可测试性需求,会使您走向自动化测试成功之路。

    步骤五:具有可延续性的设计

    在开篇的故事中,我们看到由于自动化工程师把注意力仅仅集中在如何使自动化运转起来,导致测试自动化达不到预期的效果。自动化测试是一个长期的过程,为了与产品新版本的功能和其他相关修改保持一致,自动化测试需要不停的维护和扩充。自动化测试设计中考虑自动化在未来的可扩充性是很关键的,不过,自动化测试的完整性也是很重要的。如果自动化测试程序报告测试用例执行通过,测试人员应该相信得到的结果,测试执行的实际结果也应该是通过了。其实,有很多存在问题的测试用例表面上执行通过了,实际上却执行失败了,并且没有记录任何错误日志,这就是失败的自动化。这种失败的自动化会给整个项目带来灾难性的后果,而当测试人员构建的测试自动化采用了很糟糕的设计方案或者由于后来的修改引入了错误,都会导致这种失败的测试自动化。失败的自动化通常是由于没有关注自动化测试的性能或者没有充分的自动化设计导致的。

    性能: 提高代码的性能往往增加了代码的复杂性,因此,会威胁到代码的可靠性。很少有人关心如何对自动化本身加以测试。通过我对测试套性能的分析,很多测试套都是花费大量的时间等候产品的运行。因此,在不提高产品运行性能的前提下,无法更有效的提高自动化测试执行效率。我怀疑测试自动化工程师只是从计算机课程了解到应该关注软件的性能,而并没有实际的操作经验。如果测试套的性能问题无法改变,那么应该考虑提高硬件的性能;测试套中经常会出现冗余,也可以考虑取出测试套中的冗余或者减少一个测试套中完成的测试任务,都是很好的办法。

    便于分析: 测试自动化执行失败后应该分析失败的结果,这是一个棘手的问题。分析执行失败的自动化测试结果是件困难的事情,需要从多方面着手,测试上报的告警信息是真的还是假的?是不是因为测试套中存在缺陷导致测试执行失败?是不是在搭建测试环境中出现了错误导致测试执行失败?是不是产品中确实存在缺陷导致测试执行失败?有几个方法可以帮助测试执行失败的结果分析,某些方法可以找到问题所在。通过在测试执行之前检查常见的测试环境搭建问题,从而提高测试套的可靠性;通过改进错误输出报告,从而提高测试自动化的错误输出的可分析性;此外,还可以改进自动化测试框架中存在的问题。训练测试人员如何分析测试执行失败结果。甚至可以找到那些不可靠的、冗余的或者功能比较独立的测试,然后安全地将之删除。上面这些都是减少自动化测试误报告警、提高测试可分析性的积极有效的方法。另外,有一种错误的测试结果分析方法,那就是采用测试结果后处理程序对测试结果自动分析和过滤,尽管也可以采用这种测试结果分析方法,不过这种方法会使自动化测试系统复杂化,更重要的是,后处理程序中的 BUG 会严重损害自动化测试的完整性。如果由于自动化测试本身存在的缺陷误把产品中的正常功能视为异常,那该怎么办?我曾经看到测试小组花费开发测试自动化两倍的时间来修改测试脚本,并且不愿意开展培训过程。那些仅仅关注很浅层次测试技术的测试管理者对这种方法很感兴趣,他们排斥采用隐藏测试复杂度的方法。

    综上所述,应该集中精力关注可以延续使用的测试套,从以下几方面考虑,测试的可检视性、测试的可维护性、测试的完整性、测试的独立性、测试的可重复性。

    可读性: 很多情况下,在测试人员开始测试项目之前,公司已经有了一套测试脚本,并且已经存在很多年了。我们可以称之为 “ 聪明的橡树 ”(wise oak tree)[Bach 1996] 。大家很依赖它,但是并不知道它是什么。由于 “ 聪明的橡树 ” 类型的测试脚本缺乏可读性,在具体应用中,那些脚本常常没有多大的实用价值,越来越让人迷惑。因此,测试人员很难确定他们实际在测试什么,反而会导致测试人员对自身的测试能力有过高的估计。测试人员能够检视测试脚本,并且理解测试脚本究竟测试了什么,这是很关键的。好的文档是解决问题的手段之一,对测试脚本全面分析是另外一个手段。由上面两种方法可以引申出其它的相关方法,我曾经在一个项目中使用过引申之后的方法。在测试脚本中插桩,把所有执行的产品相关的命令记录到日志里。这样,当分析日志确定执行了哪些产品命令,命令采用了何种参数配置时,可以提供一个非常好的测试记录,里面记录了自动化测试执行了什么,没有执行什么。如果测试脚本可读性不好,很容易变得过分依赖并没有完全理解的测试脚本,很容易认为测试脚本实际上做的工作比你想象中的还要多。测试套的可读性提高后,可以更容易的开展同行评审活动。

    可维护性: 在工作中,我曾经使用过一个测试套,它把所有的程序输出保存到文件中。然后,通过对比输出文件内容和一个已有的输出文件内容的差别,可以称已有的输出文件为 “ 标准文件 ” ( “gold file” )。在回归测试中,用这个方法查找 BUG 是不是明智之举。这种方法太过于敏感了,它会产生很多错误的警告。随着时间的推移,软件开发人员会根据需要修改产品的很多输出信息,这会导致很多自动化测试失败。很明显,为了保证自动化测试的顺利进行,应该在对 “ 标准文件 ” 仔细分析的基础上,根据开发人员修改的产品输出信息对之做相应的修改。比较好的可维护性方法是,每次只检查选定的产品的某些特定输出,而不是对比所有的结果输出。产品的接口变动也会导致原来的测试无法执行或者执行失败。对于 GUI 测试,这是一个更大的挑战。研究由于产品接口变化引起的相关测试修改,并研究使测试修改量最小的方法,测试中采用库是解决问题的方法。当产品发生变化的时候,只需要修改相关的库,保证测试与产品的变动同步修改即可。

    完整性: 当自动化测试执行后,报告测试执行通过,可以断定这是真的吗?这就是我称之为测试套的完整性。在前面的故事中,当没有对自动化测试完整性给予应有的关注的时候,发生了富有喜剧性的情况。我们应该在多大程度上相信自动化化测试执行结果?自动化测试执行中的误报告警是很大的问题。测试人员特别讨厌由于测试脚本自身的问题或者是测试环境的问题导致测试执行失败,但是,对于自动化测试误报告警的情况,大家往往无能为力。你期望自己设计的测试对 BUG 很敏感、有效,当测试发现异常的时候,能够报告测试执行失败。有的测试框架支持对特殊测试结果的分类方法,分类包括 PASS , FAIL 和第三种测试结果 NOTRUN 或者 UNRESOLVED 。无论你怎么称呼第三种测试结果,它很好的说明了由于某些测试失败导致其他测试用例无法执行而并非执行失败的情况。得到正确的测试结果是自动化测试完整性定义的一部分,另一部分是能够确认执行成功的测试确确实实已经执行过了。我曾经在一个测试队列中发现一个 BUG ,这个 BUG 引起测试队列中部分测试用例被跳过,没有执行。当测试队列运行完毕后,没有上报任何错误,我不得不通过走读代码的方式发现了这个 BUG 。如果,我没有关注到这个 BUG ,那么可能在认识到自动化测试已经出现问题之前,还在长时间运行部分测试用例。

    独立性: 采用自动化方法不可能达到和手工测试同样的效果。当写手工测试执行的规程时候,通常假定测试执行将会由一个有头脑、善于思考、具有观察力的测试人员完成的。如果采用自动化,测试执行是由一台不会说话的计算机完成的,你必须告诉计算机什么样的情况下测试执行是失败的,并且需要告诉计算机如何恢复测试场景才能保证测试套可以顺利执行。自动化测试可以作为测试套的一部分或者作为独立的测试执行。测试都需要建立自己所需要的测试执行环境,因此,保证测试执行的独立性是唯一的好方法。手工回归测试通常都相关的指导文档,以便一个接着一个有序地完成测试执行,每个测试执行可以利用前一个测试执行创建的对象或数据记录。手工测试人员可以清楚地把握整个测试过程。在自动化测试中采用上述方法是经常犯的错误,这个错误源于 “ 多米诺骨牌 ” 测试套,当一个测试执行失败,会导致后续一系列测试失败。更糟糕的是,所有的测试关联紧密,无法独立的运行。并且,这使得在自动化测试中分析合法的执行失败结果也困难重重。当出现这种情况后,人们首先开始怀疑自动化测试的价值。自动化测试的独立性要求在自动化测试中增加重复和冗余设计。具有独立性的测试对发现的缺陷的分析有很好的支持。以这种方式设计自动化测试好像是一种低效率的方式,不过,重要的是在不牺牲测试的可靠性的前提下保证测试的独立性,如果测试可以在无需人看守情况下运行,那么测试的执行效率就不是大问题了。

    可重复性: 自动化测试有时能够发现问题,有时候又无法发现问题,对这种情况实在没有什么好的的处理办法。因此,需要保证每次测试执行的时候,测试是以同样的方式工作。这意味着不要采用随机数据,在通用语言库中构造的随机数据经常隐藏初始化过程,使用这些数据会导致测试每次都以不同的方式执行,这样,对测试执行的失败结果分析是很让人沮丧的。这里有两个使用随机数据发生器的的方法可以避免上述情况。一种方法是使用常量初始化随机数据发生器。如果你打算生成不同种类的测试,需要在可预测,并且可控制的情况下建立不同类型的随机数据发生器。另外一个办法是提前在文件中或数据库中建立生成随机测试数据,然后在测试过程中使用这些数据。这样做看起来似乎很好,但是我却曾经看到过太多违反规则的做法。下面我来解释到底看到了什么。当手动执行测试的时候,往往匆匆忙忙整理文件名和测试数据记录。当对这些测试采用自动化测试方法,该做哪些工作呢?办法之一是,可以为测试中使用的数据记录给固定的命名。如果这些数据记录在测试完成后还要继续使用,那么就需要制定命名规则,避免在不同的测试中命名冲突,采用命名规则是一种很好的方法。然而,我曾经看到有些测试只是随机的命名数据记录,很不幸,事实证明采用这种随机命名的方式不可避免的导致命名冲突,并且影响测试的可重复性。很显然,自动化工程师低估了命名冲突的可能性。下面的情况我遇到过两次,测试数据记录的名字中包含四个随机产生的数字,经过简单的推算如果我们采用这种命名方式的时候,如果测试使用了 46 条记录,会存在 10% 冲突的可能性,如果使用 118 条记录,冲突的几率会达到 50% 。我认为测试当中使用这种随机命名是出于偷懒的想法 —— 避免再次测试之前写代码清除老的数据记录,这样引入了问题,损害了测试的可靠性和测试的完整性。

    测试库: 自动化测试的一个通用策略是开发可以在不同测试中应用的测试函数库。我曾经看到过很多测试函数库,自己也写了一些。当要求测试不受被测试产品接口变动影响的时候,采用测试库方法是非常有效的。不过,根据我的观察测试库已经使用的太多了,已经被滥用了,并且测试库往往设计的不好,没有相关的文档支撑,因此,使用测试库的测试往往很难开展。当发现问题的时候,往往不知道是测试库自身的问题,还是测试库的使用问题。由于测试库往往很复杂,即便在发现测试库存在问题,相关的维护人员也很不愿意去修改问题。通过前文中的论述,可以得出结论,在一开始就应该保证测试库设计良好。但是,实际情况是测试自动化往往没有花费更多的精力去保证一个优良设计的测试库。我曾经看到有些测试库中的功能根本不再使用了或仅仅使用一次。这与极限编程原则保持一致,即 " 你将不需要它 " 。这会导致在测试用例之间的代码出现一些重复,我发现微小的变化可能仍然存在,很难与测试库功能协调。你可能打算对测试用例作修改,采用源代码的方式比采用库的方式更容易修改。如果有几个测试,他们有某些共同的操作,我使用剪切和粘贴的方式去复制代码,有的人认为我采用的方法不可理喻。这允许我根据需要修改通用代码,我不必一开始尝试和猜测如何重用代码。我认为我的测试是很容易读懂的,因为阅读者不必关心任何测试库的语法。这种办法的优势是很容易理解测试,并且很方便扩展测试套。在开发软件测试项目的时候,大多数程序员找到与他们打算实现功能类似的源代码,并对源代码做修改,而不是从头开始写代码。同样,在写测试套的过程中可以采用上述方法,这也是代码开发方式所鼓励的方法。我比较喜欢写一些规模比较小的测试库,这些库可以被反复的使用。测试库的开发需要在概念阶段充分定义,并且文档化,从始至终都应该保持。我会对测试库作充分的测试后,才在测试中使用这些测试库。采用测试库是对所有面临的情况作权衡的。千万不要打算写一个大而全的测试库,不要希望有朝一日测试人员会利用你的测试库完成大量的测试,这一天恐怕永远不会到来。

    数据驱动测试: 把测试数据写入到简单表格中,这种测试技术得到了越来越广泛的应用,这种方法被称为表驱动( table-driven ),数据驱动 (data-driven) 或者 “ 第三代 ” 自动化测试( "third generation" automation )。这需要写一个解析器,用来解释表格中的数据,并执行测试。该测试架构的最主要的好处是,它允许把测试内容写在具有一定格式的表格中,这样方便数据设计和数据的检视。如果测试组中有缺少编程经验的业务专家参与测试,采用数据驱动测试方法是很合适的。数据驱动测试的解析器主要是由测试库和上层的少量开发语言写成的代码组成的,所以,上面关于测试库的说明放在这里是同样合适的。在针对上面提到的少量代码的设计、开发、测试的工作,还存在各种困难。代码所采用的编程语言是不断发展的。也许,测试人员认为他们需要把第一部分测试的输出作为第二部分测试的输入,这样,加入了新的变量。接下来,也许有人需要让测试中的某个环节运行一百次,这样加入一个循环。你可以采用其他语言,不过,如果你预料到会面临上述情况的时候,那么做好采用一些能够通过公开的渠道获取的编程语言,比如 Perl,Python 或者 TCL ,这样比设计你自己的语言要快的多。

    启发式确认: 我曾经看到很多测试自动化没有真正意义上的结果校验,其原因有两个,一个原因是做完全意义上的自动化测试结果确认从技术上讲是很困难的,另外一个原因是通过测试设计规格很难找出自动化测试的预期结果。这很不幸。不过,采用手工校验测试结果的方法是真正意义上的测试校验。标准文件( Gold file )是另外一中校验测试结果的方法。首先,捕获被测试程序的输出,并检视程序的输出,然后,把输出信息文档化,并归档,作为标准文件。以后,自动化测试结果与标准文件作比较,从而达到结果校验的目的。采用标准文件的方法,也有弊端。当产品发生变化,自动化测试的环境配置发生变化,产品的输出发生变化的时候,采用标准文方法,会上报大量的误报告警。做好的测试结果校验方法是,对输出结果的特定内容作分析,并作合理的比较。有时候,很难知道正确的输出结果是什么样的,但是你应该知道错误的输出结果是什么样的。开展启发式的结果校验是很有帮助的。我猜想一些人在自动化测试中设计了大而全的测试结果校验方法,是因为担心如果结果校验漏掉了任何信息,可能导致自动化测试自身出现错误。不过,我们在测试过程中往往采用折衷的做法,没有采用大而全的测试结果校验方法,这样就不得不面对少量漏测情况的出现的风险。自动化测试不能改变这种情况的出现。如果自动化工程师不习惯采用这种折衷的方法,那么他必须找相关人员咨询,寻找一种合适的测试结果校验策略,这需要有很大的创造性。目前有很多技术可以保证在不产生误报告警的情况下,找到被测试产品的缺陷。

    把注意力放在通过设计保证测试的可延续性上,选择一个合适的测试体系架构,你将进一步迈向成功的自动化测试。

    步骤六:有计划的部署

    在前面的故事中,当自动化工程师没有提供打包后的自动化测试程序给测试执行人员,会影响到测试执行,测试执行人员不得不反过来求助自动化工程师指出如何使用自动化测试程序。

    作为自动化工程师,你知道如何利用自动化方法执行测试和分析执行失败的结果。不过,测试执行人员却未必知道如何使用自动化测试。因此,需要提供自动化测试程序的安装文档和使用文档,保证自动化测试程序容易安装和配置。当安装的环境与安装的要求不匹配,出现安装错误的时候,能够给出有价值的提示信息,便于定位安装问题。

    能够把自动化测试程序和测试套作为产品对待,那真是太好了。你应该对自动化测试程序和测试套开展测试,保证它们不依赖于任何专用的库或者是设备上的任何其他程序。

    保证其他测试人员能够随时利用已经提供的自动化测试程序和测试套开展测试工作;保证自动化测试是符合一般测试执行人员的思维习惯的;保证测试执行人员能够理解测试结果,并能够正确分析失败的测试执行结果;这需要自动化工程师提供自动动化测试相关的指导性文档和培训。

    作为测试管理者,你希望在自动化工程师离开前,能够识别并修改测试套中的所有问题。自动化工程师迟早会离开的,如果你没有及时的把测试套中的问题提出来,就会面临废弃已有的测试套的决定。

    良好的测试套有多方面的用处。良好的测试套支持对产品新版本的测试;良好的测试套在新的软件平台上可以很方便的验证产品的功能;良好的测试套支持每天晚上开始的软件每日构造过程;甚至开发人员在代码 check in 之前,用良好的测试套验证代码的正确性。

    测试套的共享也很重要。很难预见以后什么人会继续使用你开发的测试套。因此,尽量让产品开发测试团队中的成员都很容易获得你的测试套。可以把测试套放在公司的内部网络上,这是个很好的办法。这样,大家就不必为了获取一份需要的测试套而四处打听。有些人总是感觉自己的测试套还没有最终完工或者不够完美,而没有拿出来与人分享,这种做法一定要改变,共享出来的测试套不一定非常完美,共享才是关键。

    有计划的自动化测试部署,保证你的测试套能够被产品相关人员获取到,你就向成功的自动化测试又迈进了一步。并且你的自动化测试会被一次又一次的重用。

    步骤七:面对成功的挑战

    当你完成了所有的事情,测试套已经文档化了,并且文档已经交付了。测试执行人员能够理解要开展的测试,并知道如何完成测试执行。随着你所负责产品的进一步开发和维护,测试被反复重用。虽然,在自动化使测试变简单的同时,也总是使测试过程复杂化。测试人员需要学习如何诊断自动化测试执行失败的情况,如果不这样做,测试执行人员会认为执行失败的情况是由自动化引起,然后,自动化工程师被叫过来帮助诊断每一个执行失败的情况,开发人员往往也会认为执行失败是由于自动化测试自身引起的问题,这样,测试执行人员就不得不学习通过手工的方式,或者通过采用少量脚本的方式重现自动化测试发现的问题,以证明他们确实发现了产品当中的 BUG 。

    测试套的相关工作还没有结束,为了提高测试覆盖率或者测试新的产品特性,需要增加更多的测试。如果已有的测试不能正常工作,那么需要对之修改;如果已有的测试是冗余的,那么需要删除这部分测试。

    随着时间的推移,开发人员也会研究你设计的测试,改进产品的设计并且通过模拟你的测试过程对产品做初步测试,研究如何使产品在第一次测试就通过,这样,你设计的测试很可能无法继续发现新的问题,这种现象被称为一种杀虫剂悖论。这时候,会有人对你的测试有效性提出质疑,那么,你必须考虑是否应该挖掘更严格的测试,以便能够发现开发人员优化之后的产品中的缺陷。

    以前,我提到过一个基本上无法实现的设想,设想通过按下一个按钮就完成了所有的测试工作。自动化测试是不是全能的,手工测试是永远无法完全替代的。

    有些测试受测试环境的影响很大,往往需要采用人工方法获取测试结果,分析测试结果。因此,很难在预先知道设计的测试用例有多大的重用性。自动化测试还需要考虑成本问题,因此,千万不要陷入到一切测试都采用自动化方法的错误观念中。

    我曾经主张保证给与测试自动化持续不断的投入。但是,在开展自动化测试的时候,一个问题摆在面前,测试自动化应该及时的提供给测试执行人员,这个不成问题,但是如何保证需求变更后,能够及时提供更新后的自动化测试就是个大问题了。如果自动化测试与需求变更无法同步,那么自动化测试的效果就无法保证了,测试人员就不愿意花费时间学习如何使用新的测试工具和如何诊断测试工具上报的错误。识别项目计划中的软件发布日期,然后把这个日期作为里程碑,并计划达到这个里程碑。当达到这个里程碑后,自动化工程师应该做什么呢?如果自动化工程师关注当前产品版本的发布,他需要为测试执行人员提供帮助和咨询,但是,一旦测试执行人员知道如何使用自动化测试,自动化测试工程师可以考虑下一个版本的测试自动化工作,包括改进测试工具和相关的库。当开发人员开始设计产品下一个版本中的新特性的时候,如果考虑了自动化测试需求,那么自动化测试师的设计工作就很好开展了,采用这种方法,自动化测试工程师可以保持与开发周期同步,而不是与测试周期同步。如果不采用这种方式,在产品版本升级的过程中,自动化测试无法得到进一步的改进。

    持续在在自动化投入,你会面临成功的挑战,当自动化测试成为测试过程可靠的基础后,自动化测试的道路将会越来越平坦。

  • 提高软件开发知识的12条建议

    2008-06-19 10:41:35

    1、分享第一条经验:“学历代表过去、能力代表现在、学习力代表未来。”其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。但我相信这一点也很重要:“重要的道理明白太晚将抱憾终生!”所以放在每一条,让刚刚毕业的朋友们早点看到哈!

            2、一定要确定自己的发展方向,并为此目的制定可行的计划。不要说什么,“我刚毕业,还不知道将来可能做什么?”,“跟着感觉走,先做做看”。因为,这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。一直做技术,将来成为专家级人物?向管理方向走,成为职业经理人?先熟悉行业和领域, 将来自立门户?还是先在行业里面混混,过几年转行做点别的?这很重要,它将决定你近几年、十年内“做什么事情才是在做正确的事情!”。

            3、软件开发团队中,技术不是万能的,但没有技术是万万不能的!在技术型团队中,技术与人品同等重要,当然长相也比较重要哈,尤其在MM比较多的团队中。在软件项目团队中,技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码,还是产品管理、测试、文档、实施、维护,多少你都 要有技术基础。算我孤陋寡闻,我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目,哪怕就一个,也没有看到。倒是曾经看到过一个 “高学历的牛人”(非技术型)带一堆人做完过一个项目,项目交付的第二天,项目组成员扔下一句“再也受不了啦!”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。

    4、详细制定自己软件开发专业知识学习计划,并注意及时修正和调整(软件开发技术变化实在太快)。请牢记:“如果一个软件开发人员在1、2年内都没有更新过自己的知识,那么,其实他已经不再属于这个行业了。”不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们:另外的那8小时如何 使用将决定你的人生成败!本人自毕业以来,平均每天实际学习时间超过2小时。

            5、书籍是人类进步的阶梯,对软件开发人员尤其如此。书籍是学习知识的最有效途径,不要过多地指望在工作中能遇到“世外高人”,并不厌其烦地教你。 对于花钱买书,我个人经验是:千万别买国内那帮人出的书!我买的那些家伙出的书,!00%全部后悔了,无一本例外。更气愤的是,这些书在二手市场的地摊上 都很难卖掉。“拥有书籍并不表示拥有知识;拥有知识并不表示拥有技能;拥有技能并不表示拥有文化;拥有文化并不表示拥有智慧。”只有将书本变成的自己智 慧,才算是真正拥有了它。

            6、不要仅局限于对某项技术的表面使用上,哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。开发 Windows应用程序,看看Windows程序的设计、加载、执行原理,分析一下PE文件格式,试试用SDK开发从头开发一个Windows应用程序;用VC++、 Delphi、Java、.Net开发应用程序,花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码;除了会用J2EE、 JBossSpring、Hibernate等等优秀的开源产品或者框架,抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。 试着这样做做,你以后的工作将会少遇到一些让你不明就里、一头雾水的问题,因为,很多东西你“知其然且知其所以然”!

           7、在一种语言上编程,但别为其束缚了思想。“代码大全”中说:“深入一门语言编程,不要浮于表面”。深入一门语言开发还远远不足,任何编程语言的 存在都有其自身的理由,所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。我的 经验是:用面对对象工具开发某些关键模块时,为什么不可以借鉴C、C51、汇编的模块化封装方式?用传统的桌面开发工具(目前主要有VC++、 Delphi)进行系统体统结构设计时,为什么不可以参考来自Java社区的IoC、AOP设计思想,甚至借    Spring、Hibernate、 JBoss等等优秀的开源框架?在进行类似于实时通信、数据采集等功能的设计、实现时,为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模 式?为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题???“他山之石、可以攻玉”。

           8、养成总结与反思的习惯,并有意识地提炼日常工作成果,形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。众所周知,对软 件开发人员而言,有、无经验的一个显著区别是:无经验者完成任何任务时都从头开始,而有经验者往往通过重组自己的可复用模块、类库来解决问题(其实这个结 论不应该被局限在软件开发领域、可以延伸到很多方面)。这并不是说,所有可复用的东西都必须自己实现,别人成熟的通过测试的成果也可以收集、整理、集成到 自己的知识库中。但是,最好还是自己实现,这样没有知识产权、版权等问题,关键是自己实现后能真正掌握这个知识点,拥有这个技能。

           9、理论与实践并重,内外双修。工程师的内涵是:以工程师的眼光观察、分析事物和世界。一个合格的软件工程师,是真正理解了软件产品的本质及软件产 品研发的思想精髓的人(个人观点、欢迎探讨)。掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作,但从软件工程 师这个角度来看,这只是外在的东西,并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论,并在实践中理解、应用软件产品的分析、设 计、实现思想来解决具体的软件产品研发问题,才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题,并在具体实践中验证和修正这些思想与方式,最终形成自己的理论体系和实用方法。

          10、心态有多开放,视野就有多开阔。不要抱着自己的技术和成果,等到它们都已经过时变成垃圾了,才拿出来丢人现眼。请及时发布自己的研究成果:开 发的产品、有创意的设计或代码,公布出来让大家交流或者使用,你的成果才有进化和升华的机会。想想自己2000年间开发的那些Windows系统工具, 5、6年之后的今天,还是那个样子,今天流行的好多Windows系统工具都比自己的晚,但进化得很好,且有那么多用户在使用。并且,不要保守自己的技术 和思想,尽可能地与人交流与分享,或者传授给开发团队的成员。“与人交换苹果之后,每个人还是只有一个苹果;但交换思想之后,每个人都拥有两种思想”,道理大家都懂,但有多少人真正能做到呢?

             11、尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品,千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”,网上有很多的开源 项目、合作开发项目、外包项目,这都是涉猎工作以外的知识的绝好机会,并且能够结识更广的人缘。不要因为工作是做ERP,就不去学习和了解嵌入式、实时、 通信、网络等方面的技术,反过来也是一样。如果当他别人拿着合同找你合作,你却这也不会,那也不熟时,你将后悔莫及。

            12、书到用时方恨少,不要将自己的知识面仅仅局限于 技术方面。诺贝尔经济学奖得主西蒙教授的研究结果表明:“对于一个有一定基础的人来说,他只要真正肯下功夫,在6个月内就可以掌握任何一门学问。”教育心理学界为感谢西蒙教授的研究成果,故命名为西蒙学习法。 可见,掌握一门陌生的学问远远没有想想的那么高难、深奥。多方吸取、广泛涉猎。极力夯实自己的影响圈、尽量扩大自己的关注圈。财务、经济、税务、管理等等 知识,有空花时间看看,韬光养晦、未雨绸缪。

           本文的总结:

           A:不要去做技术上的高手,除非你的目标如此。虽然本文是关于提高软件开发知识的建议,做技术的高手是我一向都不赞同的。你可以提高自己的专业知识,但能胜任工作即止。

           B:提高软件知识和技术只是问题的表面,本质是要提高自己认识问题、分析问题、解决问题的思想高度。软件专业知识的很多方法和原理,可以很容易地延伸、应用到生活的其它方面。

           C:在能胜任工作的基础上,立即去涉猎其它领域的专业知识,丰富自己的知识体系、提高自己的综合素质,尤其是那些目标不在技术方面的朋友。

  • 软件测试管理之Bug分析:为bug预防奠定基础

    2008-06-18 10:41:19

    软件测试管理之Bug分析:为bug预防奠定基础

        生产软件的企业安排很多测试人员来测试它们的软件产品。测试的目的就是发现bug以便修正它们。正常情况是尽快处理可能的bug,从而减少修正bug的成本。因为,众所周知,bug越早被发现并修正,所消耗的资源越少。问题是在很多情况下,由于修正已发现的bug,测试过程不得不停顿下来。如果一个软件存在各种各样的问题在里面,我们为什么不考虑去努力预防bug,而不仅仅是修正它们。这就是真正的质量。

    预防的重要性

        正如我们所知,bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC(Quality Control,质量控制)阶段的产品的bug,而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候,相当于把你之前做的事情重做一次。因此,越晚修正bug,你所重做的事情就越多。如果bug修正是在产品测试之前,那么重做的工作只有代码实现。如果bug修是在测试阶段,那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程(process),随着项目的进行,产品依赖的组件和流程也会随之增加。从另一个层面来讨论这个问题。如果bug发现和修正越早,开发成本越少,那么在第一时间就避免bug引入是不是成本消耗得更少?如果bug可以被完全预防,那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义,而且在很多情况下已得到严密的证实。然而,并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下,软件企业并不试着去达到这样的目标。在产品发布之后,企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为,这样的企业始终处于“问题解决模式”,它们并不试图发现问题的根本原因,而只是把局部的大火扑灭。

        这种模式并不仅仅导致重复工作直接带来成本的增加,而且会带来一个长期效应,而这将影响企业的业务。首先,发布带有bug的产品将给企业的声誉造成影响,并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外,由于企业需要资源来不断解决现有产品中的问题,那么开发新产品的资源势必减少。

        对很多人来说,零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说:“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪,因为我们“期望”开发人员制造bug。不幸的是,发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。

        事实上,每个软件企业都可以通过一些简单的方法,在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理:最好的方法是适当借鉴我们自己的经验。

    今天的发现就是明天的预防

        为了能够预防bug,我们必须首先了解bug的来源。软件bug可以分为几个类别(可能相互之间有所重叠)。第一类bug可能是随机的,它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防,但是,适当的分析将有助于避免这些bug。

        另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现,否则这些bug将一直存在。例如,一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题,只有当产品被其他组织(如QC组)测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。

        软件中的bug往往倾向于重复出现,即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上,而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是,至少其中一些的错误足以成为经常性出现的问题。所以,为什么我们认为重复的错误是一个好消息?因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题,并采取相应的措施去预防它(或至少减少类似错误出现的次数)。

        人为bug的子集?那么这些bug被预防的可能性更大。域bug?域bug和产品的问题域或解决方案域紧密相关。这样的bug有更大的机会重现,因为开发人员、项目组甚至企业不断地在这个域上工作。

        现在的问题是如何预防各种bug的产生。基于这次讨论的目的,我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug,而是将目标设为——预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时,我们就有了一个很好的机会来阻止类似问题的发生。

    记录bug   长筒袜

        前提条件是持续跟踪发现的bug并正确地记录它们,离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果,重要的是保存这些数据以便用于后来的分析。在分析bug时,bug记录的问题值得注意。bug的定义越广泛,bug分析的数据越有用。报告bug的测试人员应该明白这一点,并不限于狭义上的bug。可能的话,测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。和记录bug同样重要的是bug分析的第一步。仅仅跟踪过去的bug不能预防bug的发生,因为许多不同的bug可能来源于同一个核心问题。不同于信息收集,适当地分析bug的原因对bug预防非常有用。

    缺陷分析

    目标

        上面我们说明了bug分析的理由。如上所述,最终目标是预防bug而不是修正它们。然而,我们可以定义一个重要的子目标,这就使不断提高整个开发团队(包括QC组)的技能和实践经验。当然,这两个目标是息息相关的。离开了不断的知识累积,也不能实现bug预防。不过,我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是,你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识,以使他们逐渐改善他们的工作。

    策略

        本次讨论的焦点——bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动,也不会引入一些新的角色到开发过程中。

        我们的策略是发现bug,找出bug的根源,然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug,因此该策略的大部分工作实际上已经执行,大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到,尽管策略的这一部分并不需要昂贵的花费,但是却带来了极大的额外价值。

    分析过程

    (1) Bug发现和初步分析

        如前所述,bug分析的第一步是发现bug。然而,发现bug的QC工程师(注:测试工程师)不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时,不应该将产品看作一个黑盒,而应该像开发人员那样了解产品的内在,包括深入源代码,理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码,QC工程师就可能推测出bug的根本原因。我要强调是下面这个短语的本质:bug的根本原因?bug的根本原因并不是产生这bug的源代码所在,尽管这些信息可能和分析过程关系密切。但是,发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。

        让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下,应用程序尽管没有Crash,但是会停止响应。正常的QC过程是,这个bug被记录在bug跟踪系统中,并描述了测试情景和停止响应的实际结果。然而,如果这个QA工程师熟悉源代码,就可以进行bug产生原因的初步分析。例如,这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex,从而造成了冲突。这些分析可以记录在bug的详细说明中,作为bug分析的一个基础。

    (2) Bug修订和进一步分析

        一如既往,发现一个bug之后,开发人员应该负责处理它。但是,如果bug的发现过程包含了bug根本原因的初步分析,那么关于如何解决这个bug,开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的,但是它可能为开发人员提供了更多的观点。除了修正缺陷以及记录实现的具体步骤,开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。

        在线程同步的例子中,开发人员不应该仅仅记录增加了一个调用来释放mutex(注:Mutal Exclusion = 互斥锁,保证了共享数据不会同时被多个线程访问,只向一个线程授予对共享资源的独占访问权)。反之,开发人员应该找出没有释放mutex的原因。假设分析的原因是:因为需要同步的方法超过一个的返回点,因此开发人员在某些控制路径上忘记清理代码。

        这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法,我们现在有了可以解决许多情况的经验,有些情况甚至并不涉及到线程同步和释放mutex。但是,分析过程并没有结束,我们需要进一步的分析来将收集的所有数据转换为实践,从而帮助在将来避免类似bug的发生。

    (3) bug预防分析

        分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师,还涉及到不直接负责代码编写的资深开发人员。

        这一阶段的成果是一些有用的实践经验,开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中,可能得到这样一个实践:是否有审计范围机制来获取和释放资源?这种实践 (不一定适合所有编程语言)可以指导开发人员用一个类(class)封装资源, 这样构造(constructor)函数容易分配和而与析构(destructor) 函数释放资源。如果遵守这样的约定, 当程序结束这方法时,不管控制路径是怎样的,资源(上述例子中获得的mutex)总能被释放。

        Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性,分析某个具体问题的投入将很容易被收回。

        非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时,这样的bug是随机产生的,但是类似bug产生的几率却非常高。所以,尽管这一类bug是随机的,但仍然可以被预见并防止发生。

    (4) 发布经验

        分析得出的实践经验应该被记录并发布,这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。

        如果不将分析结果传达给组织内相关的其他人员,那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它,并鼓励他们这么做。

    Bug分析实例

        让我们研究另外一个例子,以便更好地理解bug分析的益处。在这个事例中,QC工程师进行了如下的操作:当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析,但这个QC工程师并不满足于这样的分析,进一步研究了相关的代码,发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中,而这个数组有时候显得太小了。和线程同步的例子一样,QC工程师的初步分析带来了很大的价值,开发可以更容易的发现和修正这个bug。此外,记录缺陷的真正原因而不是表象,将帮助其他人避免类似的bug。

        接着,开发人员开始修正这个bug。当修正的时候,她不仅记录了解决措施,并说明了导致缺陷产生的原因。在这个例子中,造成bug的原因是在操作未经处理的C/C++缓冲区时,没有经常检验缓冲区的大小是否不够。然而,这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以,在分析的最后阶段,开发人员在组内更资深的开发人员的帮助下,得到了下面的实践经验:避免使用未经处理的C/C++缓冲区,尽量使用安全的collections和strings,如标准模版数据库中提供的可用collections和strings。这样就完全可以避免前面发现的这个bug。

    益处

        Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验,并使他在将来避免类似的错误。有时,只修正一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下,只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。

        更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生,这样的知识在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。

        从更一般的角度来看,发布最佳实践(如bug分析总结的实践)促进了组织内成员的学习和自我提高。这样看来,Bug分析的价值还不仅仅是缺陷的预防。

        另一个好处是通过从更广的角度上记录bug,组织内的其他QC工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验,bug分析过程可以促进开发更好的测试技术和工具,从而帮助发现类似的bug。所以,就算缺陷没有被完全预防,也能更容易被发现。

        作为上面所有好处的结果,QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生,而且QC都有更好的技术来发现类似的bug,就有了更充裕的时间来进行更高级的测试。当然,组织所生产的产品的质量也将得到提高。

        最后,我想强调的是bug分析不仅收集了执行中的问题,而且从这些问题中总结了实践经验。举例来说,导致一个bug产生的原因可能是需求不够清楚。这样,通过bug分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管QC工程师开始验证开发人员的实现结果,但是还需要改善开发流程,如需求收集、设计流程等。

        真正的质量是生产没有bug的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以,第一步就是防止相同的bug再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个bug提高整个组织的实践经验。

        通过深入产品分析一个bug,我们可以明白这个bug的机制:为什么会产生?如何去预防它?下一次我们如何更容易地发现它?只要花一点时间去理解我们的bug,而不是仅仅是尽快修正它,我们就可以从中得到经验。这样,因为一个缺陷所浪费的时间也可以转化为投入:确保类似的错误永远不会再发生。

  • IT人不要一辈子靠技术为生

    2008-06-17 16:13:41

        一. 在中国你千万不要因为学习技术就可以换来稳定的生活和高的薪水待遇,你千万更不要认为哪些从事 市场开发,跑腿的人,没有前途.

      不知道你是不是知道,咱们中国有相当大的一部分软件公司,他们的软件开发团队都小的可怜,甚至只有1-3个人,连一个项目小组都算不上,而这样的团队却要承担一个软件公司所有的软件开发任务,在软件上线和开发的关键阶段需要团队的成员没日没夜的加班,还需要为测试出的BUG和不能按时提交的软件模块功能而心怀忐忑,有的时候如果你不幸加入现场开发的团队你则需要背井离乡告别你的女友,进行封闭开发,你平时除了编码之外就是吃饭和睡觉(有钱的公司甚至请个保姆为你做饭,以让你节省出更多的时间来投入到工作中,让你一直在那种累了就休息,不累就立即工作的状态)

      更可怕的是,会让你接触的人际关系非常单一,除了有限的技术人员之外你几乎见不到做其他行业工作和职位的人,你的朋友圈子小且单一,甚至破坏你原有的爱情(想象一下,你在外地做现场开发2个月以上,却从没跟女友见过一面的话,你的女友是不是会对你呲牙裂嘴).

      也许你拿到了所谓的白领的工资,但你却从此失去享受生活的自由,如果你想做技术人员尤其是开发人员,我想你很快就会理解,你多么想在一个地方长期待一段时间,认识一些朋友,多一些生活时间的愿望.

      比之于我们的生活和人际关系及工作,那些从事售前和市场开发的朋友,却有比我们多的多的工作之外的时间,甚至他们工作的时间有的时候是和生活的时间是可以兼顾的,他们可以通过市场开发,认识各个行业的人士,可以认识各种各样的朋友,他们比我们坦率说更有发财和发展的机会,只要他们跟我们一样勤奋.(有一种勤奋的普通人,如果给他换个地方,他马上会成为一个勤奋且出众的人.)

      二.在学习技术的时候千万不要认为如果做到技术最强,就可以成为100%受尊重的人.

      有一次一个人在面试项目经理的时候说了这么一段话:我只用最听话的人,按照我的要求做只要是听话就要,如果不听话不管他技术再好也不要.随后这个人得到了试用机会,如果没意外的话,他一定会是下一个项目经理的继任者.

      朋友们你知道吗?不管你技术有多强,你也不可能自由的腾出时间象别人那样研究一下LINUX源码,甚至写一个LINUX样的杰作来表现你的才能.你需要做的就是按照要求写代码,写代码的含义就是都规定好,你按照规定写,你很快就会发现你昨天写的代码,跟今天写的代码有很多类似,等你写过一段时间的代码,你将领略:复制,拷贝,粘贴那样的技术对你来说是何等重要.(如果你没有做过1年以上的真正意义上的开发不要反驳我).

      如果你幸运的能够听到市场人员的谈话,或是领导们的谈话,你会隐约觉得他们都在把技术人员当作编码的机器来看,你的价值并没有你想象的那么重要.而在你所在的团队内部,你可能正在为一个技术问题的讨论再跟同事搞内耗,因为他不服你,你也不服他,你们都认为自己的对,其实你们两个都对,而争论的目的就是为了在关键场合证明一下自己比对方技术好,比对方强.(在一个项目开发中,没有人愿意长期听别人的,总想换个位置领导别人.)

      三.你更不要认为,如果我技术够好,我就自己创业,自己有创业的资本,因为自己是搞技术的.

      如果你那样认为,真的是大错特错了,你可以做个调查在非技术人群中,没有几个人知道C#与JAVA的,更谈不上来欣赏你的技术是好还是不好.一句话,技术仅仅是一个工具,善于运用这个工具为别人干活的人,却往往不太擅长用这个工具来为自己创业,因为这是两个概念,训练的技能也是完全不同的.

      创业最开始的时候,你的人际关系,你处理人际关系的能力,你对社会潜规则的认识,还有你明白不明白别人的心,你会不会说让人喜欢的话,还有你对自己所提供的服务的策划和推销等等,也许有一万,一百万个值得我们重视的问题,但你会发现技术却很少有可能包含在这一万或一百万之内,如果你创业到了一个快成功的阶段,你会这样告诉自己:我干吗要亲自做技术,我聘一个人不就行了,这时候你才真正会理解技术的作用,和你以前做技术人员的作用.

      [小结]

      基于上面的讨论,我奉劝那些学习技术的朋友,千万不要拿科举考试样的心态去学习技术,对技术的学习几近的痴迷,想掌握所有所有的技术,以让自己成为技术领域的权威和专家,以在必要的时候或是心里不畅快的时候到网上对着菜鸟说自己是前辈.

      技术仅仅是一个工具,是你在人生一个阶段生存的工具,你可以一辈子喜欢他,但最好不要一辈子靠它生存.

      掌握技术的唯一目的就是拿它找工作(如果你不想把技术当作你第二生命的话),就是干活.所以你在学习的时候千万不要去做那些所谓的技术习题或是研究那些帽泡算法,最大数算法了,什么叫干活?

      就是做一个东西让别人用,别人用了,可以提高他们的工作效率,想象吧,你做1万道技术习题有什么用?只会让人觉得酸腐,还是在学习的时候,多培养些自己务实的态度吧,比如研究一下当地市场目前有哪些软件公司用人,自己离他们的要求到底有多远,自己具体应该怎么做才可以达到他们的要求.等你分析完这些,你就会发现,找工作成功,技术的贡献率其实并没有你原来想象的那么高.

      不管你是学习技术为了找工作还是创业,你都要对技术本身有个清醒的认识,在中国不会出现BILL GATES,因为,中国目前还不是十分的尊重技术人才,还仅仅的停留在把软件技术人才当作人才机器来用的尴尬境地.(如果你不理解,一种可能是你目前仅仅从事过技术工作,你的朋友圈子里技术类的朋友占了大多数,一种可能是你还没有工作,但喜欢读比尔.盖茨的传记).

     

  • 测试你适合什么职业(超级精准、科学)

    2008-06-16 15:09:44

    要求:每题考虑的时间不得超过10秒钟。
    每7题为一部分找出你选择最多的那个字母,按顺序进行排列。
     

       1.你倾向从何处得到力量:
      (E)别人。
      (I)自己的想法。
      2.当你参加一个社交聚会时,你会:
      (E)在夜色很深时,一旦你开始投入,也许就是最晚离开的那一个。
      (I)在夜晚刚开始的时候,我就疲倦了并且想回家。
      3.下列哪一件事听起来比较吸引你?
      (E)与情人到有很多人且社交活动频繁的地方。
      (I)待在家中与情人做一些特别的事情,例如说观赏一部有趣的录影带并享用你最喜欢的外卖食物。
      4.在约会中,你通常:
      (E)整体来说很健谈。
      (I)较安静并保留,直到你觉得舒服。
      5.过去,你遇见你大部分的异性朋友是:
      (E)在宴会中、夜总会、工作上、休闲活动中、会议上或当朋友介绍我给他们的朋友时。
      (I)通过私人的方式,例如个人广告、录影约会,或是由亲密的朋友和家人介绍。
      6.你倾向拥有:
      (E)很多认识的人和很亲密的朋友。
      (I)一些很亲密的朋友和一些认识的人。
      7.过去,你的朋友和同事倾向对你说:
      (E)你难道不可以安静一会儿吗?
      (I)可以请你从你的世界中出来一下吗?
    ----------------------------------------
      8.你倾向通过以下哪种方式收集信息:

      (N)你对有可能发生之事的想像和期望。
      (S)你对目前状况的实际认知。
      9.你倾向相信:
      (N)你的直觉。
      (S)你直接的观察和现成的经验。
      10.当你置身于一段关系中时,你倾向相信:
      (N)永远有进步的空间。
      (S)若它没有被破坏,不予修补。
      11.当你对一个约会觉得放心时,你偏向谈论:
      (N)未来,关于改进或发明事物和生活的种种可能性。例如,你也许会谈论一个新的科学发明,或一个更好的方法来表达你的感受。
      (S)实际的、具体的、关于“此时此地”的事物。例如,你也许会谈论品酒的好方法,或你即将要参加的新奇旅程。
      12.你是这种人:
      (N)喜欢先纵观全局。
      (S)喜欢先掌握细节。
      13.你是这类型的人:
      (N)与其活在现实中,不如活在想像里。
      (S)与其活在想像里,不如活在现实中。
      14.你通常:
      (N)偏向于去想像一大堆关于即将来临的约会的事情。
      (S)偏向于拘谨地想像即将来临的约会,只期待让它自然地发生。
    ----------------------------------------------------------------

      15.你倾向如此做决定:
      (F)首先依你的心意,然后依你的逻辑。

      (T)首先依你的逻辑,然后依你的心意。
      16.你倾向比较能够察觉到:
      (F)当人们需要情感上的支持时。
      (T)当人们不合逻辑时。
      17.当和某人分手时:
      (F)你通常让自己的情绪深陷其中,很难抽身出来。
      (T)虽然你觉得受伤,但一旦下定决心,你会直截了当地将过去恋人的影子甩开。
      18.当与一个人交往时,你倾向于看重:
      (F)情感上的相容性:表达爱意和对另一半的需求很敏感。
      (T)智慧上的相容性:沟通重要的想法;客观地讨论和辩论事情。
      19.当你不同意情人的想法时:
      (F)你尽可能地避免伤害对方的感情;若是会对对方造成伤害的话,你就不会说。
      (T)你通常毫无保留地说话,并且对情人直言不讳,因为对的就是对的。
      20.认识你的人倾向形容你为:
      (F)热情和敏感。
      (T)逻辑和明确。

      21.你把大部分和别人的相遇视为:
      (F)友善及重要的。
      (T)另有目的。
     ------------------------------------------------------------- 

                    22.若你有时间和金钱,你的朋友邀请你到国外度假,并且在前一天才通知,你会:
      (J)必须先检查你的时间表。
      (P)立刻收拾行装。
      23.在第一次约会中:
      (J)若你所约的人来迟了,你会很不高兴。
      (P)一点儿都不在乎,因为你自己常常迟到。
      24.你偏好:
      (J)事先知道约会的行程:要去哪里、有谁参加、你会在那里多久、该如何打扮。
      (P)让约会自然地发生,不做太多事先的计划。
      25.你选择的生活充满着:
      (J)日程表和组织。
      (P)自然发生和弹性。
      26.哪一项较常见:
      (J)你准时出席而其他人都迟到。
      (P)其他人都准时出席而你迟到。
      27.你是这种喜欢……的人:
      (J)下定决心并且做出最后肯定的结论。
      (P)放宽你的选择面并且持续收集信息。
      28.你是此类型的人:
      (J)喜欢在一段时间里专心于一件事情直到完成。
      (P)享受同时进行好几件事情。

     

    事业称心如意的秘密在于做你最想做的事。少数几个幸运儿早年便能发现这一秘密,但多数人都困在一种矛盾的心理苦役中,不知道自己能做什么、自己或别人认为我们该做什么、或自己认为自己想做什么。我们认为,只要你能细想想自己是什么样的人,其余一切也就水到渠成了。
    传统的事业道路分析只看"三大项":能力、兴趣和价值观。但这标准差远了!你的个性中也有一些方面需要引起注意。一般来说,个性越适合工作,对工作的满意度越高。
    人各有各的个性,就象一个内在胎记终生不变。个性评估分类系统的依据是一个人个性的4个基本特征,我们称之为"层面",因为它们可以看作是两种极端之间的连续体,如:

    我们与世界怎样互动,能量释放到何处
    (E)外向型-|-内向型(I)

    我们留意到的信息种类
    (S)感知型-|-直觉型(N)

    我们的决策方式
    (T)思考型-|-感觉型(F)

    我们喜欢一种更有条理(做决定),还是更随意性的(获取信息)生活方式
    (J)判断型-|-认知型(P)

    外向型的人把注意力和精力放在身外的世界,主动与人交往,喜欢互动。与人为伴就精神抖擞,常认识很多人。
    内向型的人专注于自我的内心世界,喜欢独处并陶然其中。他们总是先想后做,这意味着心理活动居多。他们不喜欢受人注目,一般比外向型的人更矜持。
    个性的第二层面与我们平时注意的信息有关。

    有一些人注重事实,其他人则注重愿望。
    感知型的人注重自己看到、听到、触到、嗅到和尝到的具体感受。他们只相信可以测量、能够记录下来的东西,只注重真实可靠的事。他们也相信自己的个人经验。
    直觉型的人更相信"第六感觉"(直觉)。他们善于理解字面以外的含义,对一切事情都要寻求一个内在意义。
    他们总能预示事件的发生,通常不愿意维持事物的现状,总想不断来点新花样。
    个性类型的第三层面涉及到我们做决定和结论的方式。
    思考型的人喜欢符合逻辑的决策,善于客观地分析一切,并常引以为豪。
    感觉型的人常因着自己的喜好和感觉决策。他们很能体贴人、常富有同情心,并因此自以为荣。
    个性类型的第四层面所关注的是,一个人更愿意有条理、还是随意地生活。
    判断型的人条理性很强。只要生活安排得有条不紊、事事井井有序,他们就快乐无比。凡事他们总要断个分明,喜欢决策。
    认知型的人生活散漫随意,生活机动性强时最高兴。他们乐意尝试一切可能的事情。他们往往理解生活,而不是努力控制生活。
    个性的每个层面都有两个彼此对立的极端,这样统共有八种个性偏好,每种用一个字母来表示。把这些字母组合起来,便代表16种个性。每一个人都可以在当中对号入座。

    ISTJ:内向、感知、思考、判断型
    这种人一丝不苟、认真负责,而且明智豁达,是坚定不移的社会维护者。他们讲求实际、非常务实,总是孜孜以求精确性和条理性,而且有极大的专注力。不论干什么,他们都能有条不紊、四平八稳地把它完成。
    对这类人而言,满意的工作是技术性的工作,能生产一种实实在在的产品或有条理地提供一种周详服务。他们需要一种独立的工作环境,有充裕的时间让自己独立工作,并能运用自己卓越的专注力来完成工作。
    ISFJ:内向、感知、感觉、判断型
    这种人忠心耿耿、一心一意、富有同情心,喜欢助人为乐。由于这种人有很强的职业道德,一旦觉得自己的行动确有帮助,他们便会担起重担。
    最令他们满意的工作是,需要细心观察和精确性要求极高的工作。他们需要通过不声不响地在背后工作以表达自己的感情投入,但个人贡献要能得到承认。


    INFJ :内向、直觉、感觉、判断型
    这种人极富创意。他们感情强烈、原则性强且具有良好的个人品德,善于独立进行创造性思考。即使面对怀疑,他们对自己的观点仍坚信不疑。看问题常常更能入木三分。
    对他们来说,称心如意的事业就是,能从事创新型的工作,主要是能帮助别人成长。他们喜欢生产或提供一种自己能感到自豪的产品或服务。工作必须符合个人的价值观。
    INTJ:内向、直觉、思考、判断型
    这类人是完美主义者。他们强烈要求自主、看重个人能力、对自己的创新思想坚定不移,并受其驱使去实现自己的目标。这种人逻辑性强,有判断力,才华横溢,对人对己要求严格。在所有类型的人中,这种人独立性最强,喜欢我行我素。面对反对意见,他们通常多疑、霸道、毫不退让。对权威本身,他们毫不在乎,但只要规章制度有利于他们的长远目标他们就能遵守。
    最适合的工作是:能创造和开发新颖的解决方案来解决问题或改进现有系统;他们愿意与责任心强,在专业知识、智慧和能力方面能赢得自己敬佩的人合作;他们喜欢独立工作,但需要定期与少量智囊人物切磋交流。
    ISTP:内向、感知、思考、认知型
    这种人奉行实用主义,喜欢行动,不爱空谈。他们长于分析、敏于观察、好奇心强,只相信可靠确凿的事实。由于非常务实,他们能很好地利用一切可资利用的资源,而且很会瞧准时机。
    对于ISTP这种人而言,事业满意就是,做尽可能有效利用资源的工作。他们愿意精通机械技能或使用工具来工作。工作必须有乐趣、有活力、独立性强,且常有机会走出工作室去户外
    ISFP:内向、感知、感觉、认知型
    这种类型的人温柔、体贴、敏感,从不轻言非常个人化的理想及价值观。他们常通过行动,而非语言来表达炽烈的情感。这种人有耐心、能屈能伸、且十分随和、无意控制他人。他们从不妄加判断或寻求动机和意义。
    适合的工作是,做非常符合自己内心价值观的工作。在做有益他人的工作时,希望注重细节。他们希望有独立工作的自由,但又不远离其他与自己合得来的人。他们不喜欢受繁文缛节或一些僵化程序的约束。
    INFP:内向、直觉、感觉、认知型
    INFP类型的人珍视内在和谐胜过一切。他们敏感、理想化、忠心耿耿,在个人价值观方面有强烈的荣誉感。如果能献身自己认为值得的事业,他们便情绪高涨。在日常事物中,他们通常很灵活、有包容心,但对内心忠诚的事业义无反顾。这类人很少表露强烈的情感,常显得镇静自若、寡言少语。不过,一旦相熟,他们也会变得十分热情。
    对INFP类型的人而言,最好的工作是,做合乎个人价值观、能通过工作陈述自己远见的工作;工作环境需要有灵活的架构,在自己激情高昂时可以从事各种项目;能发挥个人的独创性。
    INTP:内向、直觉、思考、认知型
    这类人善于解决抽象问题。他们经纶满腹,时能闪现出创造的睿智火花。他们外表恬静,内心专注,总忙于分析问题。他们目光挑剔,独立性极高。
    对于这类人,事业满意源自这样的工作:能酝酿新观念;专心负责某一创造性流程,而不是最终产品。在解决复杂问题时,能让他们跳出常规的框框,冒一定风险去寻求最佳解决方案。
    ESTP:外向、感知、思考、认知型
    这类人无忧无虑,属乐天派。他们活泼、随和、率性,喜欢安于现状,不愿从长计议。由于他们能够接受现实,一般心胸豁达、包容心强。这种人喜欢玩实实在在的东西,善于拆拆装装。
    对这种人来说,事业满意度来自这种工作:能随意与许多人交流;工作中充满冒险和乐趣,能冒险和随时抓住新的机遇;工作中当自己觉得必要时希望自我组织,而不是听从别人的安排。
    ESFP:外向、感知、感觉、认知型
    ESFP这一类人生**玩、充满活力,用自己的陶醉来为别人增添乐趣。他们适应性强,平易随和,可以热情饱满地同时参加几项活动。他们不喜欢把自己的意志强加于人。
    对于这类人来说,适合的工作是,能在实践中学习,利用常识搜集各种事实来寻找问题的解决方案;他们喜欢直接与顾客和客户打交道;能同时在几个项目或活动中周旋。尤其爱从事能发挥自己审美观的项目或活动。
    ENFP:外向、直觉、感觉、认知型
    ENFP这类人热情奔放,满脑子新观念。他们乐观、率性、充满自信和创造性,能深刻认识到哪些事可为。他们对灵感推崇备至,是天生的发明家。他们不墨守成规,善于闯新路子。ENFP这类人适合的工作是,在创造性灵感的推动下,与不同的人群合作从事各种项目;他们不喜欢从事需要自己亲自处理日常琐碎杂务的工作,喜欢按自己的工作节奏行事。

    ENTP:外向、直觉、思考、认知型
    这种人好激动、健谈、聪明、是个多面手。他们总是孜孜以求地提高自己的能力。这种人天生有创业心、爱钻研、机敏善变、适应能力强。
    令这类人满意的工作是:有机会从事创造性解决问题的工作。工作有一定的逻辑顺序和公正的标准。希望通过工作能提高个人权力并常与权力人物交流。
    ESTJ:外向、感知、思考、判断型
    这种人办事能力强,喜欢出风头,办事风风火火。他们责任心强、诚心诚意、忠于职守。他们喜欢框架,能组织各种细节工作,能如期实现目标并力求高效。
    ESTJ类型的人适合做理顺事实和政策以及人员组织工作,能够有效利用时间和资源以找出合乎逻辑的解决方案,在目标明确的工作中姝运用娴熟的技能。他们希望工作测评标准公正。
    ESFJ:外向、感知、感觉、判断型
    ESFJ类型的人喜欢通过直接合作以切实帮助别人。由于他们尤其注重人际关系,因而通常很受人欢迎,也喜欢迎合别人。他们的态度认真、遇事果断、通常表达意见坚决。
    这类人最满意的事业是,整天与人交往,密切参与整个决策流程。工作的目标明确,有明确的业绩标准。他们希望能组织安排自己及周围人的工作,以确保一切进展得尽可能顺利。
    ENFJ :外向、直觉、感觉、判断型
    这种人有爱心,对生活充满热情。他们往往对自己很挑剔。不过,由于他们自认为要为别人的感受负责,所以很少在公众场合发表批评意见。他们对行为的是非曲直明察秋毫,是社交高手。
    这种人最适合的工作是,工作中能建立温磬的人际关系,能使自己置身于自己信赖、且富有创意的人群中工作。他们希望工作多姿多采,但又能有条不紊地干。
    ENTJ:外向、直觉、思考、判断型
    这种人是极为有力的领导人和决策者,能明察一切事物中的各种可能性,喜欢发号施令。他们是天才的思想家,做事深谋远虑、策划周全。这种人事事力求做好,生就一双锐眼,能够一针见血地发现问题并迅速找到改进方法。
    最令ENTJ这类人满意的事业是,做领导、发号施令,完善企业的运作系统,使系统高效运行并如期达到目标。他们喜欢从事长远战略规划,寻求创造性的解决问题的方式。
    对号入座
    ISTJ:审计员、后勤经理、信息总监、预算分析员、工程师、技术作者、电脑编程员、证券经纪人、地质学者、医学研究者、会计、文字处理专业人士。
    ISTP:证券分析员、银行职员、管理顾问、电子专业人士、技术培训人员、信息服务开发人员、软件开发商、海洋生物学者、后勤与供应经理、经济学者。
    ESTP:企业家、业务运作顾问、个人理财专家、证券经纪人、银行职员、预算分析者、技术培训人员、综合网络专业人士、旅游代理、促销商、手工艺人、新闻记者、土木/工业/机械工程师。
    ESTJ:银行官员、项目经理、数据库经理、信息总监、后勤与供应经理、业务运作顾问、证券经纪人、电脑分析人员、保险代理、普通承包商、工厂主管。
    ISFJ:人事管理人员、簿记员、电脑操作员、顾客服务代表、信贷顾问、零售业主、房地产代理或经纪人、艺术人员、室内装潢师、商品规划师、语言病理学者。
    ISFP:优先顾客销售代表、行政人员、商品规划师、测量师、海洋生物学者、厨师、室内/风景设计师、旅游销售经理、职业病理专业人员。
    ESFP:公关专业人士、劳工关系调解人、零售经理、商品规划师、团队培训人员、旅游项目经营者、表演人员、特别事件的协调人、社会工作者、旅游销售经理、融资者、保险代理/经纪人。
    ESFJ:公关客户经理、个人银行业务员、销售代表、人力资源顾问、零售业主、餐饮业者、房地产经纪人、营销经理、电话营销员、办公室经理、接待员、信贷顾问、簿记员、口笔译人员。
    INFJ:人力资源经理、事业发展顾问、营销人员、企业组织发展顾问、职位分析人员、企业培训人员、媒体特约规划师、编辑/艺术指导(杂志)、口译人员、社会科学工作者。
    INFP:人力资源开发专业人员、社会科学工作者、团队建设顾问、编辑、艺术指导、记者、口笔译人员、娱乐业人士、建筑师、研究工作者、顾问、心理学专家。
    ENFP:人力资源经理、变革管理顾问、营销经理、企业/团队培训人员、广告客户经理、战略规划人员、宣传人员、事业发展顾问、环保律师、研究助理、广告撰稿员、播音员、开发总裁。
    ENFJ:人力资源开发培训人员、销售经理、小企业经理、程序设计员、生态旅游业专家、广告客户经理、公关专业人士、协调人、交流总裁、作家/记者、非营利机构总裁。
    INTJ:管理顾问、经济学者、国际银行业务职员、金融规划师、设计工程师、运作研究分析人员、信息系统开发商、综合网络专业人员。
    INTP:电脑软件设计师、系统分析人员、研究开发专业人员、战略规划师、金融规划师、信息服务开发商、变革管理顾问、企业金融律师。
    ENTP:人事系统开发人员、投资经纪人、工业设计经理、后勤顾问、金融规划师、投资银行业职员、营销策划人员、广告创意指导、国际营销商。
    ENTJ:(人事、销售、营销)经理、技术培训人员、(后勤、电脑信息服务和组织重建)顾问、国际销售经理、特许经营业主、程序设计员、环保工程师

  • 性能测试

    2008-06-16 14:58:04

    转载:http://www.51testing.com/?action_viewnews_itemid_84042.html

     我最近在项目中兼任项目测试组长角色,这次项目中负责性能测试的QA组长调走了,只好由我硬着头皮顶上去。在这段日子里,使我对性能测试有了新的认识,性能测试绝不象大多数人认为的是一件简单的事情。目前,性能测试已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段,正朝着自动化和智能化方向发展。
      
      性能测试的重要性随着网络发展更凸显重要性,由于网络环境、数据库环境、应用服务器环境、系统平台和技术等的复杂性和多样性,难以预知的用户负载和愈来愈复杂的应用程序使软件性能非常难于控制。虽然,改善系统性能不是单单依靠性能测试就能完成的,但性能测试至今仍是控制性能有效的手段。
      
      
      什么是性能测试
      性能测试主要是通过自动化的测试工具模拟多种正常、峰值及异常负载来对系统的各项性能指标进行测试。一般来说,性能测试可概括为三个方面:在客户端性能的测试、在网络上性能的测试和在服务器端性能的测试。通常情况下,三方面有效的结合可以达到对系统性能全面的分析和瓶颈的预测。
      
      性能测试的基本策略是自动负载和压力测试。通过在一台或几台PC机上模拟成百上千的虚拟用户同时执行业务的情景,对应用程序进行测试,同时记录下每一事务处理的时间、服务器峰值数据、数据库状态等。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等,其中并发性能测试是重点。
      
      (1)并发性能测试
      并发性能测试是一个负载测试和压力测试的过程,即逐渐增加负载,直到系统出现瓶颈或者不能接收更多负载,通过综合分析执行指标和资源监控指标来确定系统并发性能的过程。例如当负载压力逐渐增加时,通过检测系统的相应输出如通过量、响应时间、CPU负载、内存使用等来决定系统的性能。
      
      并发性能测试一般不采用手工方式,而是利用工具采用自动化方式进行。在测试时常常需要模拟真实环境测试,以考察在真实环境中的表现,这样测试出来的数据才有实际意义。目前,成熟的并发性能测试工具有很多,选择的依据主要是测试需求和性能价格比。
      
      (2)疲劳强度测试
      疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数,持续执行业务一段时间,通过综合分析执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
      
      疲劳强度测试可以采用工具自动化的方式进行测试,也可以手工编写程序测试,其中后者占的比例较大。一般情况是以服务器能够正常稳定响应请求的最大并发用户数进行一定时间的疲劳测试,获取执行指标数据和系统资源监控数据。如出现错误导致测试不能成功执行,则及时调整测试指标,例如降低用户数、缩短测试周期等。还有一种情况的疲劳测试是对当前系统性能的评估,用系统正常业务情况下并发用户数为基础,进行一定时间的疲劳测试。
      (3)大数据量测试
      大数据量测试可以分为两种类型:一是针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试;二是与压力性能测试、负载性能测试、疲劳性能测试相结合的综合数据量测试方案。大数据量测试的关键是测试数据的准备,可以依靠工具准备测试数据。
      
      进行性能测试的前提条件
      在任何性能测试活动开始前,软件应用程序必须达到性能测试接受标准。如果应用程序没有达到这些标准,则不应该进行性能测试,否则就是浪费时间和成本。进行性能测试的前提条件包括:
      
      (1)已通过单元测试能力
      在性能测试前所有应用程序必须先通过全面的单元测试策略,同时所附带的可被执行的单元测试代码应是完整和有效的。如果单元测试因为应用程序中的错误或缺少单元测试代码,那么应用程序则不应该进行性能测试。
      
      (2)已通过低负载级别能力
      在单用户和10个用户的低负载级别上,应用程序应该能在正常的计算时间达到合理的性能。如果应用程序无法在低负载级别正常运行,那么它肯定无法在更高负载级别正常运行。这时,开始性能测试将会浪费时间。
      
      (3)已准备好测试数据
      在性能测试期间执行应用程序所需的数据必须先准备好或已详细描述,以使性能测试小组能够建立与生产环境尽可能接近的模拟数据,要确保测试数据必须是真实、一致和完整的,任何与真实环境相差太远的测试数据都是无用的性能测试行为。

  • 软件测试工具介绍

    2008-06-16 14:54:31

    业级自动化测试工具WinRunner

      Mercury Interactive公司的WinRunner是一种企业级的功能测试工具,用于检测应用程序是否能够达到预期的功能及正常运行。通过自动录制、检测和回放用户的应用操作,WinRunner能够有效地帮助测试人员对复杂的企业级应用的不同发布版进行测试,提高测试人员的工作效率和质量,确保跨平台的、复杂的企业级应用无故障发布及长期稳定运行。

      工业标准级负载测试工具Loadrunner

      LoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题,LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ,企业能最大限度地缩短测试时间,优化性能和加速应用系统的发布周期。

      全球测试管理系统testdirector

      TestDirector 是业界第一个基于Web的测试管理系统,它可以在您公司内部或外部进行全球范围内测试的管理。通过在一个整体的应用系统中集成了测试管理的各个部分,包括需求管理,测试计划,测试执行以及错误跟踪等功能,TestDirector极大地加速了测试过程。

      功能测试工具Rational Robot

      IBM Rational Robot 是业界最顶尖的功能测试工具,它甚至可以在测试人员学习高级脚本技术之前帮助其进行成功的测试。它集成在测试人员的桌面 IBM Rational TestManager 上,在这里测试人员可以计划、组织、执行、管理和报告所有测试活动,包括手动测试报告。这种测试和管理的双重功能是自动化测试的理想开始。

      单元测试工具xUnit系列

      目前的最流行的单元测试工具是xUnit系列框架,常用的根据语言不同分为JUnit(java),CppUnit(C++),DUnit (Delphi ),NUnit(.net),PhpUnit(Php )等等。该测试框架的第一个和最杰出的应用就是由Erich Gamma (《设计模式》的作者)和Kent Beck(XP(Extreme Programming)的创始人 )提供的开放源代码的JUnit.

      功能测试工具SilkTest

      Borland SilkTest 2006属于软件功能测试工具,是Borland公司所提出软件质量管理解决方案的套件之一。这个工具采用精灵设定与自动化执行测试,无论是程序设计新手或资深的专家都能快速建立功能测试,并分析功能错误。

      性能测试工具WAS

      Microsoft Web Application Stress Tool 是由微软的网站测试人员所开发,专门用来进行实际网站压力测试的一套工具。透过这套功能强大的压力测试工具,您可以使用少量的Client端计算机仿真大量用户上线对网站服务所可能造成的影响。

      自动化白盒测试工具Jtest

      Jtest是parasoft公司推出的一款针对java语言的自动化白盒测试工具,它通过自动实现java的单元测试和代码标准校验,来提高代码的可靠性。parasoft同时出品的还有C++ test,是一款C/C++白盒测试工具。

      功能和性能测试的工具JMeter

      JMeter是Apache组织的开放源代码项目,它是功能和性能测试的工具,100%的用java实现。

      性能测试和分析工具WEBLODE

      webload是RadView公司推出的一个性能测试和分析工具,它让web应用程序开发者自动执行压力测试;webload通过模拟真实用户的操作,生成压力负载来测试web的性能。

  • 详细分析软件测试的14种类型

    2008-06-14 09:29:54

    详细分析软件测试的14种类型

    软件测试是指使用人工或者自动的手段来运行或测定某个软件产品系统的过程,其目的是在于检验是否满足规定的需求或者弄清预期的结果与实际结果的区别。本文主要描述软件测试的类型。

      1. 数据和数据库完整性测试

      数据与数据库完整测试是指测试关系型数据库完整性原则以及数据合理性测试。

      数据库完整性原即:

      主码完整性:主码不能为空;

      外码完整性:外码必须等于对应的主码或者为空。

      数据合理性指数据在数据库中的类型,长度,索引等是否建的比较合理。

      在项目名称中,数据库和数据库进程应作为一个子系统来进行测试。在测试这些子系统时,不应将测试对象的用户界面用作数据的接口。对于数据库管理系统(DBMS),还需要进行深入的研究,以确定可以支1持测试的工具和技术。

      比如,有两张表:部门和员工。部门中有部门编号,部门名称,部门经理等字段,主码为部门编号;员工表中有员工编号,员工所属部门编号,员工名称,员工类型等字段,主码为员工编号,外码为员工所属部门编号,对应部门表。如果在某条部门记录中部门编号或员工记录员工编号为空,他就违反主码完整性原则。如果某个员工所属部门的编号为##,但是##在部门编号中确找不到,这就违反外码完整性原则。

      员工类型如下定义:0:职工,1:职员,2:实习生。但数据类型为Int,我们都知道Int占有4个字节,如果定义成char(1).就比原来节约空间。

      2. 白盒测试

      白盒测试是基于代码的测试,测试人员通过阅读程序代码或者通过使用开发工具中的单步调试来判断软件的质量,一般黑盒测试由项目经理在程序员开发中来实现。白盒测试分为动态白盒测试和静态白盒测试

      2.1 静态白盒测试

      利用眼睛,浏览代码,凭借经验,找出代码中的错误或者代码中不符合书写规范的地方。比如,代码规范中规定,函数必须为动宾结构。而黑盒测试发现一个函数定义如下:

      Function NameGet(){

      ….

      }

      这是属于不符合开发规范的错误。

      有这样一段代码:

      if (i<0) & (i>="0)

      …

      这段代码交集为整个数轴,IF语句没有必要

      I="0;

      while(I>100){

      J="J+100;

      T="J*PI;

      }

      在循环体内没有I的增加,bug产生。

      2.2 动态白盒测试

      利用开发工具中的调式工具进行测试。比如一段代码有4个分支,输入4组不同的测试数据使4组分支都可以走通而且结果必须正确。

      看一段代码

      if(I<0){

      P1

      }else{

      P2

      }

      在调试中输入I="-1,P1程序段通过,P2程序段未通过,属于动态黑盒测试的缺陷

      3. 功能测试

      功能测试指测试软件各个功能模块是否正确,逻辑是否正确。

      对测试对象的功能测试应侧重于所有可直接追踪到用例或业务功能和业务规则的测试需求。这种测试的目标是核实数据的接受、处理和检索是否正确,以及业务规则的实施是否恰当。此类测试基于黑盒技术,该技术通过图形用户界面(GUI) 与应用程序进行交互,并对交互的输出或结果进行分析,以此来核实应用程序及其内部进程。功能测试的主要参考为类似于功能说明书之类的文档。

      比如一个对电子商务系统,前台用户浏览商品-放入购物车-进入结账台,后台处理订单,配货,付款,发货,这一系列流程必须正确无误的走通,不能存在任何的错误。

      4. UI测试

      UI测试指测试用户界面的风格是否满足客户要求,文字是否正确,页面美工是否好看,文字,图片组合是否完美,背景是否美观,操作是否友好等等

      用户界面(UI) 测试用于核实用户与软件之间的交互。UI 测试的目标是确保用户界面会通过测试对象的功能来为用户提供相应的访问或浏览功能。另外,UI 测试还可确保UI 中的对象按照预期的方式运行,并符合公司或行业的标准。包括用户友好性,人性化,易操作性测试。UI测试比较主观,与测试人员的喜好有关

      比如:页面基调颜色刺眼;用户登入页面比较难于找到,文字中出现错别字,页面图片范围太广等都属于UI测试中的缺陷,但是这些缺陷都不太严重。

      5. 性能测试

      性能测试主要测试软件测试的性能,包括负载测试,强度测试,数据库容量测试,基准测试以及基准测试

      5.1负载测试

      负载测试是一种性能测试指数据在超负荷环境中运行,程序是否能够承担。

      在这种测试中,将使测试对象承担不同的工作量,以评测和评估测试对象在不同工作量条件下的性能行为,以及持续正常运行的能力。负载测试的目标是确定并确保系统在超出最大预期工作量的情况下仍能正常运行。此外,负载测试还要评估性能特征,例如,响应时间、事务处理速率和其他与时间相关的方面。

      比如,在B/S结构中用户并发量测试就是属于负载测试的用户,可以使用webload工具,模拟上百人客户同时访问网站,看系统响应时间,处理速度如何?

      5.2 强度测试

      强度测试是一种性能测试,他在系统资源特别低的情况下软件系统运行情况。这类测试往往可以书写系统要求的软硬件水平要求。

      实施和执行此类测试的目的是找出因资源不足或资源争用而导致的错误。如果内存或磁盘空间不足,测试对象就可能会表现出一些在正常条件下并不明显的缺陷。而其他缺陷则可能由于争用共享资源(如数据库锁或网络带宽)而造成的。强度测试还可用于确定测试对象能够处理的最大工作量。

      比如:一个系统在内存366M下可以正常运行,但是降低到258M下不可以运行,告诉内存不足,这个系统对内存的要求就是366M。

      5.3 数据库容量测试

      数据库容量测试指通过存储过程往数据库表中插入一定数量的数据,看看相关页面是否能够及时显示数据。

      数据库容量测试使测试对象处理大量的数据,以确定是否达到了将使软件发生故障的极限。容量测试还将确定测试对象在给定时间内能够持续处理的最大负载或工作量。例如,如果测试对象正在为生成一份报表而处理一组数据库记录,那么容量测试就会使用一个大型的测试数据库,检验该软件是否正常运行并生成了正确的报表。做这种测试通常通过书写存储过程向数据库某个表中插入一定数量的记录,计算相关页面的调用时间。

      比如,在电子商务系统中,通过insert customer 往user表中插入10 000数据,看其是否可以正常显示顾客信息列表页面,如果要求达到最多可以处理100 000个客户,但是顾客信息列表页面不能够在规定的时间内显示出来,就需要调整程序中的SQL查询语句;如果在规定的时间内显示出来,可以将用户数分别提高到20 000 , 50 000, 100 000进行测试。

      5.4 基准测试

      基准测试与已知现有的系统进行比较,主要检验是否与类似的产品具有竞争性的一种测试。

      如果你要开发一套财务系统软件并且你已经获得用友财务系统的性能等数据,你可以测试你这套系统,看看哪些地方比用友财务系统好,哪些地方差?以便改进自己的系统,也可为产品广告提供数据。

      5.5 竞争测试

      软件竞争使用各种资源(数据纪录,内存等),看他与其他相关系统对资源的争夺能力。比如:一台机器上即安装您的财务系统,又安装用友财务系统。当CPU占有率下降后,看看是否能够强过用友财务系统,而是自己的系统能够正常运行。

      6. 安全性和访问控制测试

      安全性和访问控制测试侧重于安全性的两个关键方面:

      1) 应用程序级别的安全性,包括对数据或业务功能的访问

      2) 系统级别的安全性,包括对系统的登录或远程访问。

      6.1 应用程序级别的安全性

      可确保:在预期的安全性情况下,主角只能访问特定的功能或用例,或者只能访问有限的数据。例如,可能会允许所有人输入数据,创建新账户,但只有管理员才能删除这些数据或账户。如果具有数据级别的安全性,测试就可确保“用户类型一”能够看到所有客户消息(包括财务数据),而“用户二”只能看见同一客户的统计数据。

      比如B/S系统,不通过登入页面,直接输入URL,看其是否能够进入系统?

      6.2 系统级别的安全性

      可确保只有具备系统访问权限的用户才能访问应用程序,而且只能通过相应的网关来访问。

      比如输入管理员账户,检查其密码是否容易猜取,或者可以从数据库中获得?

      7. 故障转移和恢复测试

      故障转移和恢复测试指当主机软硬件发生灾难时候,备份机器是否能够正常启动,使系统是否可以正常运行,这对于电信,银行等领域的软件是十分重要的。

      故障转移和恢复测试可确保测试对象能成功完成故障转移,并能从导致意外数据损失或数据完整性破坏的各种硬件、软件或网络故障中恢复。

      故障转移测试可确保:对于必须持续运行的系统,一旦发生故障,备用系统就将不失时机地“顶替”发生故障的系统,以避免丢失任何数据或事务。

      恢复测试是一种对抗性的测试过程。在这种测试中,将把应用程序或系统置于极端的条件下(或者是模拟的极端条件下),以产生故障(例如设备输入/输出(I/O) 故障或无效的数据库指针和关健字)。然后调用恢复进程并监测和检查应用程序和系统,核实应用程序或系统和数据已得到了正确的恢复。一定要注意定时备份,比如电信系统,突然主机程序发生死机,备份机器是否能够启动,使系统能够正常运行,从而不影响用户打电话?

      8. 配置测试

      又叫兼容性测试。配置测试核实测试对象在不同的软件和硬件配置中的运行情况。在大多数生产环境中,客户机工作站、网络连接和数据库服务器的具体硬件规格会有所不同。客户机工作站可能会安装不同的软件例如,应用程序、驱动程序等而且在任何时候,都可能运行许多不同的软件组合,从而占用不同的资源。(如浏览器版本,操作系统版本等)

      下面列出主要配置测试

      8.1 浏览器兼容性

      1) 测试软件在不同产商的浏览器下是否能够正确显示与运行;

      2) 比如测试IE,Natscape浏览器下是否可以运行这套软件?

      8.2 操作系统兼容性

      1) 测试软件在不同操作系统下是否能够正确显示与运行;

      2) 比如测试WINDOWS98,WINDOWS 2000,WINDOWS XP,LINU, UNIX下是否可以运行这套软件?

      8.3 硬件兼容性

      1) 测试与硬件密切相关的软件产品与其他硬件产品的兼容性,比如该软件是少在并口设备中的,测试同时使用其他并口设备,系统是否可以正确使用.

      2) 比如在INTER,舒龙CPU芯片下系统是否能够正常运行?

      3) 这样的测试必须建立测试实验室,在各种环境下进行测试。

      9. 安装测试

      安装测试有两个目的。第一个目的是确保该软件在正常情况和异常情况的不同条件下: 例如,进行首次安装、升级、完整的或自定义的安装_都能进行安装。异常情况包括磁盘空间不足、缺少目录创建权限等。第二个目的是核实软件在安装后可立即正常运行。这通常是指运行大量为功能测试制定的测试。

      安装测试包括测试安装代码以及安装手册。安装手册提供如何进行安装,安装代码提供安装一些程序能够运行的基础数据。

      10. 多语种测试

      又称本地化测试,是指为各个地方开发产品的测试,如英文版,中文版等等,包括程序是否能够正常运行,界面是否符合当地习俗,快捷键是否正常起作用等等,特别测试在A语言环境下运行B语言软件(比如在英文win98下试图运行中文版的程序),出现现象是否正常。

      本地化测试还要考虑:

      1) 当语言从A翻译到B,字符长度变化是否影响页面效果。比如中文软件中有个按键叫“看广告”,翻译到英文版本中为“View advertisement”可能影响页面的美观程度

      2) 要考虑同一单词在各个国家的不同意思,比如football在英文中为足球,而美国人使用中可能理解为美式橄榄球。

      3) 要考虑各个国家的民族习惯,比如龙个美国中被理解邪恶的象征,但翻译到中国,中国人认为为吉祥的象征。

      11. 文字测试

      文字测试测试软件中是否拼写正确,是否易懂,不存在二义性,没有语法错误;文字与内容是否有出入等等,包括图片文字。

      比如:“比如,请输入正确的证件号码!”何谓正确的证件号码,证件可以为身份证,驾驶证,也可为军官证,如果改为“请输入正确的身份证号码!”用户就比较容易理解了。

      12. 分辨率测试

      测试在不同分辨率下,界面的美观程度,分为800*600,1024*768,1152*864,1280*768,1280*1024,1200*1600大小字体下测试。一个好的软件要有一个极佳的分辨率,而在其他分辨率下也都能可以运行。

      13. 发布测试

      主要在产品发布前对一些附带产品,比如说明书,广告稿等进行测试

      13.1 说明书测试

      主要为语言检查,功能检查,图片检查

      语言检查:检查说明书语言是否正确,用词是否易于理解;

      功能检查:功能是否描述完全,或者描述了并没有的功能等;

      图片检查::检查图片是否正确

      13.2 宣传材料测试

      主要测试产品中的附带的宣传材料中的语言,描述功能,图片

      13.3 帮助文件测试

      帮助文件是否正确,易懂,是否人性化。最好能够提供检索功能。

      13.4 广告用语

      产品出公司前的广告材料文字,功能,图片,人性化的检查

      14 文档审核测试

      文档审核测试目前越来越引起人们的重视,软件质量不是检查出来的,而是融进软件开发中来。前置软件测试发越来越受到重视。请看一个资料:

      文档审核测试主要包括需求文档测试,设计文档测试,为前置软件测试测试中的一部分。

      14.1 需求文档测试

      主要测试需求中是否存在逻辑矛盾以及需求在技术上是否可以实现;

      14.2 设计文档测试

      测试设计是否符合全部需求以及设计是否合理。

      总结

      据美国软件质量安全中心2000年对美国一百家知名的软件厂商统计,得出这样一个结论:软件缺陷在开发前期发现比在开发后期发现资金,人力上节约90%;软件缺陷在推向市场前发现比在推出后发现资金,人力上节约90%。所以说软件的缺陷应该尽早发现。不是所有的软件都要进行任何类型的软件测试的,可以根据产品的具体情况进行组装测试不同的类型。

    参考文献

      《Rational统一过程模型》

      《软件测试》

  • 网络语言大扫盲

    2008-06-14 09:25:35



    简单的不说了,说些复杂的(痛苦整理中)
      874:鄙视,猫扑的符号之一,一孩拿扫把猛扇一男
      XHW:小黑屋,猫扑的处理办法之一,封ID
      BH:彪悍
      tjjtds,踢鸡鸡踢到死,也可以说是弹鸡鸡弹到死,猫扑大熊老大的原创。这个语出应该有史可以考证的
      loli:是小女孩
      正太:是小男孩;
      SM:有几种解释,一个是性虐待(sexy maltreat),一个是贴吧和天涯名人舒穆禄雪梅的简称,一开始是玉米吧的大姐,由于率先挑起玉米和凉粉之争,名气大振
      HD:厚道,一般说LZ8HD,就是楼主不厚道的意思
      BT=变态
      HC=花痴
      GJM=抄袭或复制,郭敬明的简称,由于那个梦里花落知多少的抄袭事件,被鄙视的不行,于是GJM也成了抄袭或复制的代称
      CJ=纯洁,也来源于郭敬明,小四的“我习惯纯洁地45度仰望”被一再引用,CJ开始流行
      MS:貌似
      马赛克:来源于天涯名人环佩叮当,她写文章很有意思,当写道不CJ的东西,不好写出来的时候,就用马赛克三个字代替,大家知道什么意思了吧,举例:……于是“马赛克”,……
      FB:腐败,意指吃饭
      酵母:教母的意思,来源于天涯,天涯八卦版好多教的,菊花教的郭敬明,冷艳教的陈红(唱歌的那个)等等

    论坛日常用语:
      1、BBS:①Bulletin Board System的缩写,指电子公告板系统,国内统称论坛。②波霸,Big-Breasted Sister的缩写。
      2、斑竹:版主,也可写作板猪。由于拼音输入造成的美妙谐音。副版主叫“板斧”。
      3、马甲:注册会员又注册了其他的名字,这些名字统称为马甲,与马甲相对的是主ID。 例句:青眉建议斑竹进行版务管理时,不可以用马甲发言。
      4、菜鸟:原指电脑水平比较低的人,后来广泛运用于现实生活中,指在某领域不太拿手的人。与之相对的就是老鸟。
      5、大虾:“大侠”的通假,指网龄比较长的资深网虫,或者某一方面(如电脑技术,或者文章水平)特别高超的人,一般人缘声誉较好才会得到如此称呼。
      6、灌水:原指在论坛发表的没什么阅读价值的帖子,现在习惯上会把绝大多数发帖、回帖统称为“灌水”,不含贬义。
      7、纯净水:无任何实质内容的灌水,也说水蒸气。
      8、水手:喜欢灌水的人。级别高的也称水桶、水鬼、水仙。指女性灌水狂人时,还有个特定称呼:水母。
      9、潜水:天天在论坛里呆着,但是不发帖,只看帖子、而且注意论坛日常事务的人。
      10、打铁:写帖子,一般指有点儿重量的帖子。
      11、拍砖:对某人某帖发表与其他人不同看法和理解的帖子。 例句:侠友们拍砖请注意口气和态度,否则很容易转化为人参公鸡。
      12、刷屏:打开一个论坛,所有的主题帖都是同一个ID发的。
      13、扫楼:也叫刷墙,打开一个论坛,所有主题帖的最后一个回复都是同一个ID的。
      14、楼主:发主题帖的人。
      15、盖楼:回同一个主题帖,一般粉丝比较喜欢盖楼。
      16、楼上的:比你先一步回复同一个主题帖的人,与之相对的是“楼下的”。
      17、几楼的:除楼主外,所有回复帖子的人,依次可称为“2楼的”、“3楼的”……
      18、沙发:SF,第一个回帖的人。后来,坐不到沙发的人,声称自己坐了“床”或楼主的“大腿”~
      19、椅子:第二个回帖的人。
      20、板凳:第三个回帖的人。
      21、地板:连板凳都没得坐的人。
      22、顶:一般论坛里的帖子一旦有人回复,就到主题列表的最上面去了。这个回复的动作叫做“顶”,与“顶”相对的是“沉”。
      23、走召弓虽:超强,通常用于回帖时表示对主题帖的膜拜。
      24、汗:表示惭愧、无可奈何之意。衍生词有:暴汗、大汗、汗死、瀑布汗、暴雨梨花汗等。
      25、倒:晕倒,表示对某帖某人或某现实很惊异。
      26、寒:对某帖某人或某现象感到浑身发冷。
      27、抓狂:形容自己受不了某人某帖的刺激而行为失常,处于暴走状态中。
      28、踩一脚:也称踢一脚、留个爪子印等,都是跟帖之意。
      29、路过:不想认真回帖,但又想拿回帖的分数或经验值。与之相对的字眼还有:顶、默、灌水、无语、飘过、路过等。 例句:在侠客社区,凡回帖只回路过、顶、默、灌水、无语、飘过、路过等字眼的行为,都会被视为故意灌水。
      30、闪:离开。
      31、匿鸟:隐身了。“匿”作“藏匿”讲;“了”是多音字,在句尾本该读“LE”,有人喜欢误读“LIAO”,遂谐音为“鸟”。
      32、找抽帖:楼主发的帖子内容特别找抽,让绝大多数人都不待见,也称找砖帖。
      33、火星帖:很久以前已经被无数人看过转过的旧帖,转火星帖的人被称为火星人。通常回帖会这样说:楼主还是快回火星吧,地球是很危险滴。(来自周星星《少林足球》)
      34、恐龙:长得不漂亮的女性网民,含贬义。与之相对的是“青蛙”,形容相貌抱歉的男性网民。
      35、犬科:喜欢追逐论坛里的女生的那种类型,尤其喜欢死缠烂打。
      36、狼族:热爱美色,不过比犬科作风正派一点,不会纠缠。
      37、……的说:动词后置的一种用法,来自日文语法。 例句:青眉要去吃饭的说。
      38、……ing:动词进行时的一种用法,来自英文语法。 例句:侠友们如此支持《武侠版》和侠客社区,青眉感动ing。
      39、残念:可惜之意,引申有“碎碎念”等。
      40、×××××:儿童不宜的内容。
      41、王道:相当于“权威、真理”之意。
      42、黑旺财:旺财是《唐伯虎点秋香》里的一条狗,狗者,犬也。黑犬,就是“默”。此典出自晋江。
      43、小白:①白烂的昵称,指专在网上无事生非的人。②“小白痴”的缩写。
      44、小黑:黑名单。
      45、浸小黑:ID被登记进黑名单。
      46、小强:《唐伯虎点秋香》中的那只蟑螂,泛指生命力特别顽强的人。
      47、粉丝:FANS的音译,超迷某人或某物的一类人,也称扇子、蕃薯,简称“粉”或“迷”。
      48、包子:形容某人笨,或者长相欠佳。
      49、蛋白质:笨蛋+白痴+神经质。
      50、白骨精:白领+骨干+精英。
      51、腊鸭:垃圾(来自《麦唛》系列)。“挂腊鸭”在粤语俗语中指吊颈自杀。
      52、Kuso:日语“粪”的发音。起先是教游戏玩家如何把“烂Game认真玩”的意思,后来经台湾传入大陆,渐渐演化成“恶搞”之意。
      53、维客:喜欢使用WIKI这种超文本技术的网络爱好者。
      54、博客:一种网上共享空间,让人以日记的方式在网络上展现自己的形式。博客让两个女人飞速走红:木子美和芙蓉姐姐。
      55、黑客:又称骇客,指在电脑领域有特殊才能或技巧的人。这类人运用自己的才能或技巧,要么是专门检测系统漏洞,要么有可能做有违道德或法律的事。
      56、红客:具有民族主义倾向的中国网络技术爱好者,与黑客相对。
      57、朋客:起源于“朋克”。电脑朋客现在越来越多的被等同于电脑罪犯了。
      58、闪客:使用Flash软件做动画的人,我们看到的很多电子贺卡和网站MTV都是闪客的杰作。
      59、极客:也称奇客,Geek,指有较高超电脑能力的人。
      60、驴友:泛指爱好旅游,经常一起结伴出游的人。 例句:阿肥去年才和松风古琴他们一起去过新疆,现在又要征集驴友去湖南啦。

    中文缩写指南:
      1、BT:①Bit Torrent的缩写,是一种P2P(点对点)共享软件,中文译名“比特流”或“变态下载”。②“变态”的缩写。
      2、ZT:①“转帖”的缩写。②“猪头”的缩写,引申有ZT3,猪头三;ZT4,猪头四。 例句:青眉郑重告诉侠客社区的侠友们,ZT一定要注明。
      3、PP:①“片片”的缩写,片片指代照片。②“屁屁”的缩写,屁屁指代臀部。
      4、GG:哥哥的缩写,指代男性,有时候女生用来指代自己的男友。与之相对的是MM,妹妹或者美眉的缩写,指代女性,有时候男生用来指代自己的女友。
      5、NB:牛×的缩写,北京方言里用来表示叹为观止之意。
      6、JJ:①姐姐的缩写。②鸡鸡的缩写。
      7、DD:①弟弟的缩写,偶尔有引申义。②东东的缩写,指代东西。
      8、GF:Girl Friend,女友。与之相对的是BF,Boy Friend,男友。
      9、PLMM:漂亮美眉的缩写。
      10、PPMM:PLMM的升级版,漂漂美眉。
      11、RPWT:人品问题的缩写,来自猫扑论坛。一般来说,只要某上遇上了不可解之事,统统可归结为其有RPWT。
      12、人品帖:测试你是否有RPWT的帖子,帖子题目很劲爆,只要你被骗进去,就说明你有RPWT。 例句:这张名为《朴树的裸照》的帖子是个人品帖,其实里面真的是一棵朴树的照片啊,树当然是裸的,哪里有穿衣服的树?青眉居然被这个人品帖骗进去了,果真有RPWT.
      13、PF:佩服的缩写。
      14、SL:色狼的缩写。
      15、KH:葵花,代指练《葵花宝典》的高手。
      16、KHBD:葵花宝典。
      17、PXJF:辟邪剑法,源于KHBD,KH专用的剑法。
      18、BS:鄙视的缩写,也可写作B4。 例句:你要是ZT不注明,青眉会BS你,全论坛的人都会B4你的。
      19、PMP:拍马屁。
      20、PMPMP:拼命拍马屁。
      21、MPJ:“马屁精”的缩写。
      22、BC:“白痴”的缩写。也说是“白菜”的缩写,在网上,如果人家说你很白菜,那么就是形容你BC。
      23、ODBC:“哦,大白痴”的缩写。
      24、XB:小白的缩写。
      25、YY:意淫的缩写,出自《红楼梦》第六回,精神上行淫。在网络上其意得到进一步推广,凡信心极度膨胀的小说,统称为YY小说。
      26、ZE:“贼恶”的缩写,即真恶心,东北地区的方言发音。
      27、SE:“少恶”即“少恶心”的缩写。 28、XHW:小黑屋的缩写,来自猫扑,在猫扑,违反规则是要被关小黑屋的。
      29、FB:腐败的缩写,现在通常指出去吃喝一顿好的。
      30、MD:妈的,粗话,慎用。
      31、TMD: ,粗口,慎用。
      32、TNND:他奶奶的,粗口,慎用。
      33、JR:贱人,脏话,特别慎用。
      34、SJB:神经病,脏话,慎用。
      35、SB:脏话,对别人的蔑称,禁用。
      36、LR:烂人,禁用。
      37、LJ:垃圾,禁用。
      38、RY:人妖,慎用。
      39、JS:“奸商”的缩写。
      40、BXCM:冰雪聪明。
      41、HJ:汉奸。
      42、FQ:愤青。
      43、BD:笨蛋。
      44、JJWW:叽叽歪歪。
      45、Tjjtds:弹鸡鸡弹到死,来自猫扑论坛。
      46、CJ:纯洁。
      47、HC:花痴。
      48、BH:剽悍。出自新东方罗胖子的名言:剽悍的人生不需要解释。
      49、GJM:某当红青春作家,曾涉嫌抄袭。GJM后来被当作抄袭的简称,意义接近于“ZT”。出自天涯社区。
      50、三毛抄四:该当红青春作家写过一本书,和三毛作品同名,由此衍生而来的新成语。意指盲信某种理论、某个人物而完全不管真相,本末倒置、颠倒黑白的一种狂热精神状态。出自龙空。
      51、145:猫扑论坛某名女,代表该论坛参加过雅典奥运。她曾做过一套网上广泛流传的测试智商的题目,得分为145,遂有名言:比我聪明的都没有我漂亮,比我漂亮的都没有我聪明。天涯社区遂演绎出一句名言:比我CJ的都没我BT,比我BT的都没我CJ。
      52、FRJJ:芙蓉姐姐,一个女人,一种网络现象。从2005年4月起直到现在,她上了几乎所有网站的头条、新浪腾迅等各大网站及大小报纸争相报导、连中央电台都开始讨论她的现象。芙蓉姐姐的走红和持续走红,证明部分媒体和人已到了一个极端恶意的境界。
    英文缩写指南:
      1、DIY:Do It Yourself的缩写,自己动手做的意思。 例句:清欢太坏了,青眉电脑坏了找他修,他让青眉DIY。
      2、SOHO:Small Office Home Officer的简称,意思是“在家办公”。 例句:《游侠秀秀》的作者小非是SOHO一族啊。
      3、BUG:原意是“臭虫”,后来把跟电脑有关的故障都称之为“BUG”。 例句:每回侠客社区出现BUG,青眉都急得跳脚。
      4、I服了U:我服了你……周星星片子里的经典台词。 例句:你居然能让清欢不对你说“不”,I服了U!
      5、伊妹儿:Email的音译,电子邮件的意思。也可简称为“妹儿”。 例句:青眉从来不用伊妹儿,给她写信是没用的啦。
      6、CU:See You的缩写带音译,再见。 例句:CU,今天就到这里吧。
      7、IC:I See的缩写带音译,我知道了。 例句:IC,你是个神经病。(《大话西游》里的经典台词)
      8、Q:Cute 的音译,可爱。 例句:傲月寒长得好Q,像个芭比娃娃。
      9、FT:分特,Faint的缩写,昏倒、晕厥之意。
      10、SP:support,支持。
      11、败:BUY的音译,买的意思。
      12、SIGH:叹息,有无可奈何之意。
      13、LOL:Laugh Out Loud,大笑。
      14、KFC:Kill fu*king customers。
      15、PK:player kill。
      16、BTW:By the way,顺便说一句。
      17、BRB:Be right back,马上回来。
      18、TTYL:Talk to you later,回头再谈。
      19、BBL:Be back later,过会儿就回。
      20、kick your ass:打你屁屁。
      21、PPL:people,人们。
      22、PLZ:please,请,也有缩写成PLS。
      23、RUOK:Are you OK?
      24、IOWAN2BWU:I only want to be with you。
      25、M$ULKeCraZ:Miss you like crazy。
      26、CUL8R:see you later。
      27、IMHO:In my humble opinion。

    四、音译术语指南:
      1、3166:沙哟娜拉,日语,再见。
      2、886:拜拜喽,再见。
      3、3Q:Thank You,谢谢。
      4、7456:气死我了。
      5、9494:就是就是。
      6、818:八卦一下,出自天涯社区。
      7、616:遛一遛。通常回帖时贴教猫教花等图片时,通称“遛一遛”。
      8、8:不。
      9、54:“无视”的谐音,即漠视一个人,对其表达最大的不屑。
      10、4242:是啊是啊。
      11、稀饭:喜欢。
      12、木有:没有。“木”不知道是来源于哪里的发音。同样用法的还有“米有”。
      13、粉:很。来自闽南方言。
      14、表:“不要”速读连音,据说来自上海人的发音。
      15、白烂:来自闽南语“白卵”,意指一个人既笨又啰唆,还很麻烦,含贬义。
      16、素:台湾普通话“是”的读音。与之对应的有“8素”。
      17、酱紫:“这样子”速读连音,也作“绛紫”。
      18、酷:也说“裤”、“库”,Cool的音译。
      19、偶:台湾普通话“我”的读音。
      20、虾米:啥,什么之意,来自闽南语发音。
      21、口耐:也说可耐,可爱之意。
      22、滴:的,地。
      23、介个:这个。
      24、奔四:笨死的谐音。
      25、果酱:过奖。
      26、马甲决:马家爵。
      27、二硫碘化钾:KISS。
      28、咔嚓:某种练《葵花宝典》前必做的手术。
      29、口年:可怜。
      30、人参公鸡:“人身攻击”的通假。
      31、泥:你。
      32、好康:好看。来自闽南方言。
      33、筒子:同志。
      34、厚厚、吼吼、咔咔、kaka、嘻嘻、xixi、hiahia等:表示笑声,通常当作语气助词用。

    动漫术语浅析:
      1、TV版:指在电视上放的动画版本。
      2、OVA:Original Video Anime(原创影象动画),和TV相对,不在电视上放映的版本。
      3、剧场版:动画的电影版本。
      4、OST:Original Sound Track(原创音乐专集),专收录与某动画有关的音乐。
      5、OP:片头曲/主题曲。
      6、ED:片尾曲。
      7、CAST:声优,即配音演员,日本动漫的配音演员是非常重要的哦。
      8、STAFF:参与制作改编动画的全体成员,连场务道具都会算进去的。
      9、OTAKU:日语,原意为“御宅”,御宅族是指疯狂热烈动漫,沉浸在幻想世界中,欠缺正常社交生活经验的次文化族群。
      10、幼齿:也称“素人”,年纪小,不怎么懂事的意思。
      11、达人:很强的人。
      12、SF:SCIENCE FICTION,科幻机械类的作品。
      13、FF: FINAL FANTASY,最终幻想。
      14、M0:MACROSS ZERO,超时空要塞零。
      15、欧巴:30岁以上的女性。
      16、兄贵:全身肌肉的强壮男子。
      17、姐贵:全身肌肉的大姐姐。
      18、御姐:比自己年长的女性。
      19、恶趣味:怪癖、与众不同的特殊喜好。
      20、流星:指略带一点儿情色意味或稍有些露点成份的CG图。
      21、口胡:港式动漫用语,也可写作“口古月”,相当于“靠”之类的语气助词。
      22、口桀:港漫用语,常用来指坏人的笑声,特别是奸笑。
      23、轰杀:港漫用语,用来指去杀某人的动作。
      24、废柴:港漫用语,指废物、没用的人。
      25、破天:港漫用语,即“打破天”,不爽时可使用。
      26、逆天:港漫用语,指逆着天道而行,愤怒时可使用。
      27、未够班:港漫用语,意指不够格。
      28、收声:港漫用语,指闭嘴。
    耽美术语浅析:
      1、耽美:出自日语,原意是指唯美主义,后经台湾演绎,变成BL的代称了,专指女作家写/画给女读者看的小说或漫画。其实在日本,JUNE才是BL的代称。
      2、BL:BOY’S LOVE,男同性恋。谐音玻璃,也称同志。
      3、GL:GIRL’S LOVE,女同性恋。 4、蕾丝:lesbine,女同性恋,简称女同,也称同好,拉拉。
      5、同人女:超级喜欢BL文化的女性,在日语中被称为“腐女子”。
      6、耽美狼:超喜欢耽美文学的女性,比同人女程度更进一步。
      7、LOLI:罗莉,幼女的意思。出自《LOLITA》中的洛丽塔,本意指12岁以下的小女孩,泛指天真可爱到白目的小女生。类似的幼男则被称为“正太”,出自《铁人28号》中的金田正太郎,最开始的正太是以穿西装短裤造型出现的哦。
      8、LOLI控:对罗莉有强烈偏好的变态叔叔,嘿嘿~
      9、18禁:未满18岁不能观看。
      10、H:来自日文“变态(HENTAI)”罗马拼音的第一个字母,通常指18禁的东东,与make love同义。
      11、激H:H度非常高,描述相当激烈火爆。
      12、清水文:没有H情节的文章。
      13、SM:Sadism & Masochism,虐待狂与被虐狂,多指性方面。可进一步引申为:Slave and Master,主子与奴才。指两人从事H行为时,有明显的主奴之别,在不危及人身安全的情况下,奴不得违抗主的任何命令。
      14、鬼畜:来自日语,原意指像魔鬼畜生一样残酷无情。指攻残忍虐待受的身体或精神。
      15、紧缚:H时将受的身体用绳子捆绑起来,使其不能挣扎。
      16、攻:BL的双方,充当主动的那一方,即男同志中通称的一号。与“攻”相对的,就是“受”了,受是零号。
      17、年下攻:攻的年纪比受小。
      18、年上攻:攻的年纪比受大。
      19、女王受:受的性格像女王一样高傲,可以把攻吃得死死的。
      20、下克上:地位较低的是攻,地位较高的是受。
      21、立场倒换:攻受相互转换身份。
      22、总受:不管跟谁配对,都是充当受。
      23、总攻:不管跟谁配对,都是充当攻。
      24、强气攻:个性很强悍的攻。
      25、强气受:个性很强悍的受。
      26、健气受:个性比较活泼、健康、开朗类型的受。
      27、天然受:个性比较少根筋的受。
      28、诱受:主动诱惑攻和自己H的受。
      29、YAOI:整部小说以H为主,没什么情节。
      30、女王:女性主子被称为女王,性格一般比较高傲、残酷。女王的通常形象总是穿紧身衣、高跟鞋,手执皮鞭的。后引申为强势的女性。
      31、调教:顾名思义。在有H情节的小说中,调教不仅是从生理上,更从心理上,以摧残对方的自尊,使其完全臣服为目的。此类小说通常会被称为“调教系”。
      32、圣水:指代小便。与之对应的是“黄金”,指代大便。黄金圣水是调教系小说中必不可少的道具。超恶~
      33、同人:二次创作,将名家名作中的情节或人物衍生出自己的故事。同人创作不限于BL,一般性向的也可以。
      34、女体化:把原著中的男性角色改成女孩子进行同人创作。
      35、同人志:由作者自己花钱出版的书刊。由出版社所出的书刊叫“商业志”
    简短但经典的回复:
      1、楼下的木有小鸡鸡。(来自猫扑,先回帖的人对后回帖的一种调侃)
      2、实乃人间惨剧,竟无语凝噎。(来自天涯,对无语的帖子都可如此回复)
      3、做人要厚道。(《手机》经典台词)
      4、出来混,迟早要还的。(《无间道》经典台词)
      5、这无涯的一场生啊。(时未寒《碎空刀》经典台词)
      6、人生真是寂寞如雪啊。
      7、灌,是一种美德。
      8、什么什么,才是王道。(举例:恶搞才是王道。)
      9、YY是我思考的方式,BT是我追求的境界。(来自猫扑)
      10、虎躯一震,三分走人。(来自天涯,天涯回一个帖三分。“虎躯一震”常见于黄易作品)
      11、CJ的45度角仰望天空。(来自天涯)
  • 从测试用例看测试的问题及变化(转)

    2008-06-14 09:20:15

     

    对于一个测试人员来说测试用例的设计编写是一项必须掌握的能力。但有效的设计和熟练的编写却是一个十分复杂的技术,它需要你对整个软件不管从业务还是从功能上都有一个明晰的把握。

    一、问题:
    许多测试类书籍中都有大幅的篇章介绍用例的设计方法,如等价类划分,边界值,错误推断,因果图等。但实际应用中这些理论却不能给我们很明确的行为指导,尤其是业务复杂,关联模块紧密,输入标准和输出结果间路径众多时,完全的遵循这些方法只能让我们在心理上得到一种满足,而无法有效的提高测试效率。有时我们只有依靠以前项目的用例编写经验(或习惯),希望能在这一个项目中更加规范,但多数情况下我们规范的只是“书写的规范”,在用例设计上以前存在的问题现在依旧。

    当好不容易用例基本完成,我们却发现面对随之而来的众多地区特性和新增需求,测试用例突然处于一种十分尴尬的境地:

    l       从此几乎很少被执行

    l       已经与程序的实现发生了冲突(界面变动,功能变动)

    l       执行用例发现的bug很少

    l       根本没有时间为新的功能需求增补用例

    l       有时间补充,但用例结构越来越乱,

    l       特性的用例与通性用例之间联系不明确(以新增需求为主线列出所有涉及到的更改,但特性与通行之间的数据或业务联系在用例中逐渐淡化)

    l       知道怎样执行这个用例,但它要说明什么呢?(多数用例给我们的感觉是只见树木,不见森林,只对某一功能,无法串起)

    通过上面的一系列问题可以看到,似乎测试用例给我们带来的问题远多于益处,也正是因为在实际过程中遇到的问题积累,导致我们有很充分的理由忽视或拒绝用例的应用。

    但没有用例或简略用例的编写我们又会舒服很多么?不言自明,谁也不想倒退发展吧。

    二、原因:
    事实上我们在测试用例编写和设计上遇到的一系列问题只是一种表面的呈现,究其原因我认为有如下几点:

    1、没有适合的规范
    “适合的规范”或称“本地化的规范”。这是我们在测试过程中遇到的第一个问题,通常也是很容易习惯且淡忘的。我们拥有相当多的流程文档、书本上的定义,但它适合我们当前的项目么?

    每一个测试工程师在进入这个职业的初期都会了解一些测试上的概念和术语,进入公司或项目组后也会进一步学习相应的文档,例如怎样规范编写,怎样定义bug级别,软件实现的主要业务等。但当测试经理开始给我们分配某一模块的用例编写时,又有多少人知道该怎样去写,怎样写算是好?

    在测试论坛中常能看到介绍用例编写方法的帖子,而迷茫于怎样应用到实践的回复也不为少数。为何我们无法在公司和项目组内找到明确且适合的规范?于是我们只得选择从书本或之前的用例中复制,不管是结构还是方式都依赖于以往·的经验,我并不是说这样就是错误的,但不能总结成文的经验无法给予测试更多帮助。

    我们有太多经验,但却没有形成适合的规范。

    2、功能与业务的分离
    我们知道怎样列举一个输入框的用例,但却很少考虑说明这个输入框是用来做什么的,如果仔细分析不难发现,用例中这种功能与业务的分离越来越普遍也越来越明显。

    边界值、等价类划分、因果图,这些用例方法是一种高度提纯的方法,本身就很偏向于功能及代码,所以怎样编写业务的用例我们就从理论上失去了参考。

    复杂的业务会贯穿于整个软件,涉及众多功能点,里面组合的分支更不可胜数。测试用例务求简洁、明确,这一点也与业务“格格不入”。功能用例依赖程序界面,业务描述依赖需求文档。于是我们更偏向于根据已实现的界面编写功能用例,列举出众多的边界值、等价类。流程的操作只有凭借经验和理解,这时测试出的bug是最多的,但我们却无法使这个bug对应到一个用例中(点击一个按钮报出的错误有时原因并不在这个按钮或按钮所在的窗体)。正因为我们没有很好的积累业务上的用例,才使得我们感到执行用例时发现的bug不多。

    用例结构的划分一定程度上也造成了功能和业务的分离,依照界面模块建立文件夹,并在其中新建不同用例,这使得用例从结构上就很难联通起来。

    3、测试未能跟上变化
    变化!想象一下,当我们越来越多的听到开发人员在那里高呼“拥抱变化”“敏捷开发”的时候,测试又有什么举措呢?当地区特性,软件版本越来越多的时候,测试是否在积极响应呢?变化是我们面临的最大挑战,我认为测试未能跟上变化是造成测试过程中遇到种种问题和矛盾的主要原因。

    对需求和程序的变化测试人员的感受是非常深的,测试总是跟在需求和开发后面跑,使得所有风险都压在自己身上。不断压缩的时间和资源使我们只能放弃那些“不必要”的工作:尽快投入测试,尽快发现bug,而非从整体把握软件的质量情况,统筹策略。

    疲于应对的直接影响就是程序质量无法准确度量,进度无法控制,风险无法预估。用例与程序脱节,新增用例混乱和缺少。长此以往我们只得放弃修改、增补用例,甚至放弃之前积累的所有成果。用例变为程序变更的记录摘要,没有测试数据的保留,测试步骤和重点无法体现,新加功能与原来的程序逐渐“脱离”,可能还会出现相互违背的情况,但这我们却无法很快发现。

    永远是变化决定我们的下一步工作,这也是混乱的开始。

    三、可能的解决办法:
    在这里我希望以探讨的方式提出一些可能的解决办法,因为上面的问题也许在成熟的公司和项目组内很少遇到,而遇到问题的也需根据不同的情况单独考虑。不用拘泥形式,最适合的就是最好的。

    1、测试驱动开发,用例指导结果,数据记录变化
    “测试驱动开发”(TDD)是一个比较新的概念,在网上可以看到很多介绍文章,它主要讨论如何让开发的代码更奏效(Work)更洁净(Clean),“测试驱动开发的基本思想就是在开发功能代码之前,先编写测试代码”。可以看到,TDD是建立在“代码”级别的驱动,但目前我们需要探讨的问题是怎样在黑盒测试中做到“测试驱动开发”。

    首先我们需要纠正一个态度,很多人认为黑盒测试的技术含量不高,可思考可拓展的内容不多,主要的工作就是用鼠标在那里瞎点,于是很多“高级”的技术方法都试图与黑盒测试划清界限。但测试人员发现的bug有80%以上都是黑盒测试发现的,手工操作软件仍是目前检验软件质量最有效的一种方法。

    如何在黑盒测试中做到测试驱动开发?我认为可以从用例级别做起,以业务用例指导过程和结果。

    开发人员通常比较关注技术,对于业务上的理解容易忽视并出现偏差,而需求文档又不会很明确的指出应该实现怎样的结果,这使得从业务到功能出现一个“阅读上的障碍”,如果最后程序错误了还需返工,这样耗费的人力物力就非常大了。使用业务用例驱动开发,就是一个比较好的方法,同样这也需要运用测试中的各种方法,列举出业务流程里数据的等价类和边界值。

    业务用例的构造要先于程序实现,与需求和开发人员沟通一致,并以此作为一个基准,保证程序实现不会错,还能对整个软件的进度和质量有一个很好的估计和度量。业务用例可以不关注程序的界面,但一定要有数据的支持。这就是测试主导变化的另一点“数据记录变化”。

    我们不仅要应对变化,还要记录变化,使测试用例成为对程序持续性的监控,数据可以作为最基本、最简单的支持。当一个业务很复杂时可以拆分成段(业务段与程序中以窗体或页面的划分是不一样的),使用典型的用例方法列出实际输入和预期结果。我们希望数据能做到通用和共享,最理想的情况就是建立一个“数据库”,每个业务用例都从“数据库”中取得输入数据和预期结果,这个数据只是针对业务入口和出口的,当程序内部设计变更时,保留的数据不会因此而作废。举一个例子,例如我的程序要从某种文件中读取数据并计算结果,一段时间后程序内部字段增加了,如果是以保存的文件附件方式提供数据,则现在程序很可能就打不开这个文件了。使用“数据库”指导测试人员可以在变化的程序里直接针对业务输入,而不关心程序内部结构。

    再进一步的话“数据库”就开始涉及到程序内部的接口了,这需要开发人员的配合。

    2、为用例标明时间(版本)和优先级
    为测试用例标明时间或版本可以起到一种基准的作用,标明项目进度过程中的每一个阶段,使用例直接和需求基线、软件版本对应。同样这需要规范流程,也是对变更的一种确认和控制。或者可以为用例增加一个状态,指明这个用例目前是否与程序冲突,当程序变更时改变用例的状态,并更新用例版本。

    为测试用例标明优先级可以指出软件的测试重点、用例编写的重点,减少用例回归的时间,增加重点用例执行的次数,帮助项目组新人尽快了解需求,在自动化测试的初期也可以参考这个优先级录制脚本。

    3、功能用例与业务用例分开组织
    将功能用例与业务用例分开组织,按照不同关注点列举执行路径。业务用例应在开发前或同期编写,帮助测试人员和开发人员明确业务,了解正确流程和错误流程。功能用例更依赖于程序界面的描述,但功能用例并不等于使用说明。对某些模块的等价类、边界值测试会发现很多严重的bug,也许与业务无关,但用户往往很容易这样操作(例如登录名,你是否考虑到很长的名字,或者用户的键盘有问题,总是敲入n多空格在里面,这与业务无关,但程序将会怎样处理?)。

    4、审核用例,结对编写
    测试组长或经理对用例进行审核可以做到用例的补充和校对,但一般情况下是很难做到的,我们可以采用另一种方法,就是结对编写测试用例(前提是你有两个以上的测试人员),内部审核。

    测试用例不是一个人编写一个人执行,它需要其他测试人员都能读懂且明白目标所指。结对编写可以尽量减少个人的“偏好习惯”,同时也能拓展思维,加强测试重点的确认,小组内部达到统一。一定程度上结对编写也可以减少组长或经理对用例的管理,提高组员的参与积极性。

    四、发展
    上面的这些解决方法只是一种建议,具体怎样实施到项目中还需根据情况而定。可以看到测试的发展方向是很多很广的,传统的黑盒测试并不是毫无新意,测试工作怎样适合我们而发展,将给予我们更多的思考。

  • 软件缺陷管理

    2008-06-13 15:00:53

    认识软件缺陷,首先要了解软件缺陷的概念,其次是了解软件缺陷的详细特征,最后就是它的属性了,再高一个层次就是学习利用管理软件缺陷的工具了。
    1、首先介绍软件缺陷的概念
    软件缺陷是指系统或系统部件中那些导致系统或部件不能实现其功能的缺陷。
    2、软件缺陷的详细特征
    a、单一准确
    b、可以再现(要求软件缺陷具有精确的步骤)
    c、完整统一
    d、短小简练
    e、特定条件
    f、补充完整
    g、不做评价
    3、软件缺陷的属性
    软件缺陷的属性包括缺陷标识、缺陷类型、缺陷严重程度、缺陷产生可能性、缺陷优先级、缺陷状态、缺陷起源、缺陷来源、缺陷原因。
    下面详细介绍一下以上这些属性:
    a、缺陷标识:是标记某个缺陷的唯一标识,可以用数字序号表示;
    b、缺陷类型:功能、用户界面、文档、软件包、性能、系统"模块接口
         功能:影响了各种系统功能、逻辑的缺陷;
         用户界面:影响了用户界面、人机交互特性,包括屏幕格式、用户输入灵活性、结果输入格式等方面的缺陷;
         文档:影响发布和维护,包括注释、用户手册、设计文档;
         软件包:由于软件配置库、变更管理或版本控制引起的错误;
         性能:不满足系统可测量的属性值,如执行时间、事务处理速率等;
         系统"模块接口:与其他组件、模块或设备驱动程序、调用参数、控制块或参数列表等不匹配、冲突。
    c、缺陷严重程度:致命(Fatal)、严重(Ceritical)、一般(Major)、较小(Minor)
        致命:系统任何一个主要功能完全丧失,用户数据受到破坏,系统崩溃、悬挂、死机或者危机人身安全;
        严重:系统的主要功能部分丧失,数据不能保存,系统的次要功能完全丧失,系统所提供的功能或服务受到明显的影响;
        一般:系统的次要功能没有完全实现,但不影响用户的正常使用。例如:提示信息不太准确或用户界面差、操作时间长等一些问题;
        较小:使操作者不方便或遇到麻烦,但它不影响功能过的操作和执行,如个别不影响产品理解的错别字、文字排列不整齐等一些小问题
    d、缺陷产生可能性:总是、通常、有时、很少
         总是:总是产生这个软件缺陷,其产生的频率是100;
         通常:按照测试用例,通常情况下会产生这个软件缺陷,其产生的频率大概是80—90;
         有时:按照测试用例,有时候产生这个软件缺陷,其产生的频率大概是30—50;
         很少:按照测试用例,很少产生这个软件缺陷,其产生的频率大概是1—5.
    e、缺陷的优先级:立即解决、高优先级、正常排队、低优先级
         立即解决:缺陷导致系统几乎不能使用或者测试不能继续,需立即修复;
         高优先级:缺陷严重,影响测试,需要优先考虑;
         正常排队:缺陷需要正常排队等待修复;
         低优先级:缺陷可以再开发人员有时间的时候被纠正。
    f、缺陷状态:激活或打开、已修正或修复、关闭或非激活、重新打开、推迟、保留、不能重现、需要更多信息
        激活或打开:问题还没有解决,存在源代码中,确认”提交的缺陷”,等待处理,如新报的缺陷;
        已修正或修复:已被开发人员检查、修复过的缺陷,通过单元测试,认为已经解决但还没有被测试人员验证;
        关闭或非激活:测试人员验证后,确认缺陷不存在之后的状态;
        重新打开:测试人员验证后,确认缺陷不存在之后的状态;
        推迟:这个软件缺陷可以在下一个版本中解决;
        保留:由于技术原因或第三者软件的缺陷,开发人员不能修复的缺陷;
        不能重现:开发不能再现这个软件缺陷,需要测试人员检查缺陷再现的步骤;
         需要更多信息:开发能再现这个软件缺陷,但开发人员需要一些信息,例如缺陷的日志文件、图片等。
    g、软件缺陷的起源:需求、构架、设计、编码、测试、用户
         在团建生命周期中软件缺陷占的比例:需求和构架设计阶段占54、设计阶段占25、编码阶段占15、其他占6.
    h、软件缺陷的来源:需求说明书、设计文档、系统集成接口、数据流(库)、程序代码
        需求说明书:需求说明书的错误或不清楚引起的问题;
        设计文档:设计文档描述不准确。和需求说明书不一致的问题;
        系统集成接口:系统个模块参数不匹配、开发组之间缺乏协调引起的缺陷;
        数据流(库):由于数据字典、数据库中的错误引起的缺陷;
        程序代码:纯粹在编码中的问题所引起的缺陷。
    i、缺陷根源:测试策略,过程、工具和方法,团队"人,缺乏组织和通讯,硬件,软件,工作环境
       测试策略:错误的测试范围,误解测试目标,超越测试能力等;
       过程、工具和方法:无效的需求收集过程,果实的风险管理过程,不使用的项目管理方法,没有估算规程,无效的变更控制过程等;
       团队"人:项目团队职责交叉,缺乏培训。没有经验的项目团队,缺乏士气和动机不纯等;
       缺乏组织和通讯:缺乏用户参与,职责不明确、管理失败等;
       硬件:硬件配置不对、缺乏、或处理器缺陷导致算术精度丢失,内存溢出等;
       软件:软件设置不对、缺乏,或操作系统错误导致无法释放资源,工具软件的错误,编译器的错误,千年虫问题等;
       工作环境:组织机构调整,预算改变,工作环境恶劣,如噪音过大。
    4、学会利用管理缺陷的工具
    例如TD、bugfree、bugzille等
  • 企业管理软件平台架构内幕揭秘

    2008-06-12 11:17:22

    企业管理软件,由于进入门坎低,各行各业各层次企业都需要,做面向企业应用比做面向个人应用要赚钱多,好销售,所以中国内地有相当大部分的程序员在从事着企业管理软件的开发。

    尤其是接项目的软件公司,这类公司往往在中国当前软件行业占很多。3-4个或5-6个程序员,老板拉来什么项目就做什么项目,进销存、费用报销、销售管理、客服维修工单、请假考勤管理等等为大部分单子内容。

    有朋友留言:就10来万的单子,就1-2个程序员,从调研到设计到开发到测试到打包到实施安装到培训到推动上线到支持,全活儿。哪来的精力再去开发平台。再说了,都是10来万的单子,开发平台就大才小用了,什么设计模式,什么OO,什么界面和代码分离,什么代码重构,都扯淡,往界面拖控件,用ADO连数据库,OK。费那精神干嘛,把钱快速赚到才是真理。

    其实,你发现没,你做的管理软件(叫它MIS也行,你爱戴高帽就叫它ERP)有一些东西都挺相似。我有个专门给小企业做网站的哥们,5天一个网站。他手里面从免费邮箱服务器、BBS论坛、流量统计软件、网站新闻内容管理系统全从网上找好源代码,各种图标图片素材库,机器上装好Dreamweaver、PhotoShop、Flash。小企业老板来了,他把过去做的案例往出一拿,你挑吧。然后七凑八凑几天完工。

    这是不是平台呢?

    我们为什么需要平台?我们需要什么样的平台?平台应该包括哪些东西?一个完备的平台是怎样的?

    带着这些问题,我们一一揭秘。

    拿我哥们刚才的例子剖析。我个人认为那就是一个平台。我们为什么需要平台?就是为了不每次都重新发明轮子,为了能快速的完成代码工作(可以多赚点钱或者可以多打会游戏或者瞌睡或者可以多时间去泡MM)。

    快速完成,是平台的第一目标。但是快速三下五除二干完了,去客户那里一跑,BUG百出,倒霉,还得熬夜修改,长期出差回不了家。修改代码,痛苦,还不如推倒重新正式写代码。

    看来,平台的第二个目标必须是稳定。

    既能快速开发,又能稳定,这是个好平台了吧。

    不,客户个性化需求来了,发现真难改。按照普通简单流程处理(增/删/改/查 列表/明细),确实平台能给很大帮助,但是客户一个性化,平台就不灵了,个性化代码怎么都插不进去手。平台自成一套圈子,外围异常代码根本插不进去(这是现在很多号称平台的产品都共有的最大弊病)。

    好不容易遇到个好个性化定制的平台,平台性能不佳,老挂机,客户的电话吼的真想把电话线拔掉,甚至幻想全公司电话和互联网和自己的手机都坏了。

    终于搞定以上的所有问题,给客户安装上,培训好,推动上线,终于可以闪人了。回到自己的床上,真舒服呀。

    没想到恶梦才刚刚开始。客户的电话来了:我发现报表不对呀,数对不上去,你看哪里出问题了?

    O,My God。我刚回来,你就...。 我又不能飞过去。好吧,好吧,你有QQ或PcAnyWhere吗,我们来连一下,我给查一下数据库。什么?服务器不容许上网?那我怎么办?

    看来需要一个排错、可跟踪、可输出详细日志、可过滤日志的东西,就像SQLSERVER的查询跟踪器一样。

    嗯,好不容易把问题搞定,修改完代码,需要给客户升级。

    什么,你们家没有网管,都是兼职的,根本不会SQLSERVER,脚本怎么执行,怎么备份,不知道?

    算我倒霉,电话我告诉你一步步操作。(长途电话费N多,老板冲你发火,你低头不语,心里念到这个猪头)

    什么?升级了也不好用?那你肯定没按我说的操作来。

    什么?有的机器好用,有的机器不好用?你肯定没有把所有客户端都升级了。

    哦,看来需要一个自动升级的模块。

    挖咔咔,软件卖的好好哦。咿呀咿呀咿。可是,可是...。居然有家伙盗版使用我们的软件,看来我不加密不行了。

    加密,加KEY,加并发用户数,加正版判别,加使用期过期。

    嗯,终于天下太平了,抱得美人归。

    从以上来看,我们似乎并不是为了平台而平台,为了市场宣传和销售便利而做平台噱头。我们确实在多如牛毛的小项目的水深火热战火纷飞中,我们渴望有这些东西将我们快速解脱。如果我们是开发中大型系统的,我们的产品需要延续生命周期8-10年,需要部署给成千上万的客户,客户需要管理几亿的关键数据,有几千个客户并发,我们更需要平台。

    所以,不管做小项目的,或者做大项目的,我们都需要平台。

    那我们需要什么样的平台。其实上述的场景中已经把平台的关键特性都说了一遍,现在我总结一下:

    1可以帮助开发人员快速开发

    2稳定

    3可以个性化定制

    4可以跟踪日志排错

    5可以自动升级

    6软件版权保护

    为了做到这些,国内软件精英不知有多少人前赴后继的的投入研究(甚至做OA的,做工作流的,也号称做平台)。让我们历数历数,看看各自的特点和优缺点,以对照一下我们需要的特性,他们的平台具备不?

    大连雅奇,95年我就知道它了。当时好像是Foxbase版本的。可以生成菜单、界面代码。其他的我现在忘了。不过去年CSDN还报道了一次大连雅奇

    1报表打印,支持二维、交叉、套打、单据格式、多栏头、导出HTML、PDF、EXCEL、DBF肯定是必须的。计算公式有没有?变量有没有?代码调用API有没有?嵌入图表有没有?小分组合计行不行?最底最右的总合计有没有?支持不支持主从?支持不支持链接钻取?

    2图表 当然支持折线、直方、饼图。不知道EXCEL所能支持的图表,它是否都能支持,而且像EXCEL一样好看。漏斗图有没有,里程图有没有?做领导报表(可以起名为管理驾驶舱或商业智能门户)时非常需要。

    3控件 可分组、可过滤、可定制查询、可定制列视图、可多排序、可导出、可预览、可小计的Grid控件有没有?可以权限管制行列数据,定制列视图的参照录入控件有没有?日历控件有没有?财务凭证控件有没有?

    4企业内部即时通讯模块、邮件收发模块、预警提醒模块有没有呢?

    其实,这是在企业应用中极为常见的一些公共功能。有一部份朋友给我QQ留言,他说平台架构就是:中间件+Hibernate(ORM框架)+structs(MVC框架)+spring(AOP框架)+JSF控件(UI框架)+Log4j(日志框架)+JUnit(测试框架)+Ant(Build框架)+JasperReports(报表框架)+JFreeChart(图表框架)+osWorkFlow(工作流框架)。

    我说对,这是平台架构,但不是企业管理软件的平台架构。企业管理软件的平台架构需要更上一层,能方便开发人员快速稳定的开发和修改。

    大连雅奇能一直存活到如今,从各方面看虽已跟不上未来,但目前很多小软件公司和小企业还在进行着初步的信息化,所以还是有很多的市场空间的。(我看到华军软件里有人发布的所谓强大平台,一下载一看,原来是一个数据库维护软件,让人尴尬,但是还有大量的个人或2人工作室在不断奋斗制造着这类软件,我已经看到了很多雷同的软件了,也有市场?可能)。

    讲完最老的大连雅奇,在企业管理软件平台界,最有名的就数思维加速(现在改名起步)。起步从1999年开始起步,技术一直跟的很紧,做的也非常深入,我个人认为,起步是做企业管理软件平台最优秀的一个。

    1 起步加入了工作流,非常适应时代

    2加入了集团企业多组织结构,非常适应时代

    3起步有数据库建模工具,有版本管理工具,有部署工具,报表、图表自不用说。居然还有甘特图和日历,还有即时通讯工具

    4起步拥有自己研发的代码开发IDE。这是国内没有的。老宋为了解决常规平台自我封闭无法定制的诟病下了很大的气力,让简单开发和个性定制融合。

    5能支持JAVA中间件,也能支持COM+,能WEB,也能C/S。这也是国内没有的。

    IDE,既是起步的杀手功能,也是起步的软肋(想起一句古龙的话:敌人的优点也就是他的缺点)。IDE这个东西,世界有三巨头:Eclipse、visual studio、Borland。大家都是干软件的,大部分都是选择这三类IDE,对这三类IDE很是习惯。但是现在要舍弃三巨头,用了起步的平台,就需要用起步的IDE,而且IDE还没有三巨头做的好(要想做好,谈何容易。君不见Eclipse有IBM巨资推动,visual  studio更是微软的一个重要产品线,投入大量人力。如果起步也要做,那岂不是平台、IDE、工作流都要并进?要知道,这三块中的每一块,都是需要单独一个公司,而且是相当实力的公司才能做好)。

    于是,上海普元学乖了。IDE,我们就用Eclipse。

    当然,还是老三套:控件+工作流+报表。

    普元的平台框架有组织结构管理(不知道是否支持区域管理组织和集团管理组织?)、部署工具、权限管理(这个非常重要,不知道能不能管理到业务实体的每一个操作和数据行列可访问性?)、业务字典管理(这个没必要单提出来吧?运行参数的配置才是最重要的)。不过普元具备了日志、异常、定制任务。更难能可贵的是,普元还提出了Cache机制(这个在企业管理软件领域中其实挺难。它不像咱们的通常论坛网站,如天涯,也并发量大需要Cache,但是天涯也仅仅是看,而企业管理软件主要是频繁读写和业务计算处理,这怎么Cache,我也需要学习学习,过去一直主要依赖数据库设计和代码写法和功能设计来保证性能)。

    普元做JAVA,金富瑞就做.NET。

    三大件继续拿上来:控件+工作流+报表。

    但很可贵的是,金富瑞提出了虚拟组织这一说法。这个确实老遇到。还有就是权限管理,从菜单到数据到列到行到按钮,控制的挺细,不过细就是多,多就会漏洞多,看来金富瑞需要深刻去思考一下数据库架构的设计。

    这些都是专注做平台的。

    但是,那些主要做管理软件的公司,也有自己的平台。甚至自己的平台还卖。如浪潮楼上(不过山东人的朴实与粗糙,尽在软件中)。

    自己用的平台,东软也有,但没有对外宣传,也不卖。偷偷自己用,做了N多医保、税务局之类的项目。(我曾经剖析的时候,发掘设计的思想和金蝶K3的平台特别相似)

    用友、金蝶这两大企业管理软件公司当然也有自己的平台。用友有U8平台和NC平台,金蝶有K3和EAS平台。不过,明显的是,金蝶的平台架构思路比用友高一级。从业务实体自省到权限控制到日志到二次开发,金蝶颇有套路,思路清晰抽象高度。而用友的平台,似乎还看业务是业务,看菜单是菜单。

    讲了这么多,几乎主流的平台厂商我都数了个遍,当然从事各细分行业管理软件的公司也都有自己的平台,只不过那类平台和本行业业务又结合的特别紧密,开发自己行业软件特别快速稳定易用,但不具有普遍意义。

    我把我在上一篇文章中写的企业管理软件平台架构内容再贴到最后,以使大家好总览:

    1登陆用户口令验证、license许可验证、盗版验证、过期失效验证、版本差异验证

    2主控台 用户功能树 管理主控台

    3表单设计器、业务实体设计器、工作流设计器、报表设计器、功能菜单设计器、多语言设计器、多皮肤设计器、查询过滤定制器

    4UI框架:Grid/Toob bar/Tree/TabSheet/Menubar/参照录入组件/Edit/Button/Combo之类

    5单实体输入框架、主从List/Detail输入框架

    6运行配置参数设置、单号计数器、业务预警设置

    7异常框架、业务实体权限框架、业务实体存储引擎、业务实体查询引擎

    8报表:套打、单据报表、普通二维查询统计报表、交叉报表、图表

    9工作流引擎、消息引擎、自动任务引擎

    10企业组织结构设计工具、权限分配工具、数据导入导出工具、数据备份恢复工具、升级更新工具、错误诊断跟踪工具、性能监测工具、日志查看工具

    11OFFICE集成、BO集成、通信集成、邮件集成、短信集成、IM集成、搜索集成、电子商务集成、企业门户集成等等一切外围集成

  • 系统构架设计应考虑的因素

    2008-06-12 10:48:25

    系统构架设计应考虑的因素

    摘要:
      本文从程序的运行时结构和源代码的组织结构两个方面探讨了系统构架设计应考虑的各种因素,列举了系统构架设计文档应考虑的一些问题。
      关键字:
      系统构架、设计、考虑、因素
      正文:
      约公元前25年,古罗马建筑师维特鲁威说:“理想的建筑师应该既是文学家又是数字家,他还应通晓历史,热衷于哲学研究,精通音乐,懂得医药知识,具有法学造诣,深谙天文学及天文计算。”(好难哪,软件构架设计师的要求呢?大家好好想想吧。)
      本文目录
      一、与构架有关的几个基本概念;
      二、构架设计应考虑的因素概揽;
      三、程序的运行时结构方面的考虑;
      四、源代码的组织结构方面的考虑;
      五、写系统构架设计文档应考虑的问题
      六、结语
      一、与构架有关的几个基本概念:
      1、模块(module):一组完成指定功能的语句,包括:输入、输出、逻辑处理功能、内部信息、运行环境(与功能对应但不是一对一关系)。
      2、组件(component):系统中相当重要的、几乎是独立的可替换部分,它在明确定义的构架环境中实现确切的功能。
      3、模式(pattern):指经过验证,至少适用于一种实用环境(更多时候是好几种环境)的解决方案模板(用于结构和行为。在 UML 中:模式由参数化的协作来表示,但 UML 不直接对模式的其他方面(如使用结果列表、使用示例等,它们可由文本来表示)进行建模。存在各种范围和抽象程度的模式,例如,构架模式、分析模式、设计模式和代码模式或实施模式。模式将可以帮助我们抓住重点。构架也是存在模式的。比如,对于系统结构设计,我们使用层模式;对于分布式系统,我们使用代理模式(通过使用代理来替代实际的对象,使程序能够控制对该对象的访问);对于交互系统,我们使用MVC(M模型(对象)/V视图(输出管理)/C控制器(输入处理))模式。模式是针对特定问题的解,因此,我们也可以针对需求的特点采用相应的模式来设计构架。
      4、构架模式(architectural pattern):表示软件系统的基本结构组织方案。它提供了一组预定义的子系统、指定它们的职责,并且包括用于组织其间关系的规则和指导。
      5、层(layer):对模型中同一抽象层次上的包进行分组的一种特定方式。通过分层,从逻辑上将子系统划分成许多集合,而层间关系的形成要遵循一定的规则。通过分层,可以限制子系统间的依赖关系,使系统以更松散的方式耦合,从而更易于维护。(层是对构架的横向划分,分区是对构架的纵向划分)。
      6、系统分层的几种常用方法:
      1) 常用三层服务:用户层、业务逻辑层、数据层;
      2) 多层结构的技术组成模型:表现层、中间层、数据层;
      3) 网络系统常用三层结构:核心层、汇聚层和接入层;
      4) RUP典型分层方法:应用层、专业业务层、中间件层、系统软件层;
      5) 基于Java的B/S模式系统结构:浏览器端、服务器端、请求接收层、请求处理层;
      6) 某六层结构:功能层(用户界面)、模块层、组装层(软件总线)、服务层(数据处理)、数据层、核心层;
      7、构架(Architecture,愿意为建筑学设计和建筑物建造的艺术与科学): 在RUP中的定义:软件系统的构架(在某一给定点)是指系统重要构件的组织或结构,这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互;《软件构架实践》中的定义:某个软件或者计算系统的软件构架即组成该系统的一个或者多个结构,他们组成软件的各个部分,形成这些组件的外部可见属性及相互间的联系;IEEE 1471-2000中的定义:the fundamental organization of a system emboided in its components,their relationships to each other,and to the enviroment and the principles guiding its design and evolution,构架是系统在其所处环境中的最高层次的概念。软件系统的构架是通过接口交互的重要构件(在特定时间点)的组织或结构,这些构件又由一些更小的构件和接口组成。(“构架”可以作为名词,也可作为动词,作为动词的“构架”相当于“构架设计”)
      8、构架的描述方式:“4+1”视图(用例视图、设计视图、实现视图、过程视图、配置视图)是一个被广为使用的构架描述的模型;RUP过程的构架描述模板在“4+1”视图的基础上增加了可选的数据视图(从永久性数据存储方面来对系统进行说明);HP公司的软件描述模板也是基于“4+1”视图。
      9、结构:软件构架是多种结构的体现,结构是系统构架从不同角度观察所产生的视图。就像建筑物的结构会随着观察动机和出发点的不同而有多种含义一样,软件构架也表现为多种结构。常见的软件结构有:模块结构、逻辑或概念结构、进程或协调结构、物理结构、使用结构、调用结构、数据流、控制流、类结构等等。
      二、构架设计应考虑的因素概揽:
      模块构架设计可以从程序的运行时结构和源代码的组织结构方面考虑。
      1、程序的运行时结构方面的考虑:
      1) 需求的符合性:正确性、完整性;功能性需求、非功能性需求;
      2) 总体性能(内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响);
      3) 运行可管理性:便于控制系统运行、监视系统状态、错误处理;模块间通信的简单性;与可维护性不同;
      4) 与其他系统接口兼容性;
      5) 与网络、硬件接口兼容性及性能;
      6) 系统安全性;
      7) 系统可靠性;
      8) 业务流程的可调整性;
      9) 业务信息的可调整性
      10) 使用方便性
      11) 构架样式的一致性
      注:运行时负载均衡可以从系统性能、系统可靠性方面考虑。
      2、源代码的组织结构方面的考虑:
      1) 开发可管理性:便于人员分工(模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响)、利于配置管理、大小的合理性与适度复杂性;
      2) 可维护性:与运行可管理性不同;
      3) 可扩充性:系统方案的升级、扩容、扩充性能;
      4) 可移植性:不同客户端、应用服务器、数据库管理系统;
      5) 需求的符合性(源代码的组织结构方面的考虑)。


      1、 需求的符合性:正确性、完整性;功能性需求、非功能性需求
      软件项目最主要的目标是满足客户需求。在进行构架设计的时候,大家考虑更多的是使用哪个运行平台、编成语言、开发环境、数据库管理系统等问题,对于和客户需求相关的问题考虑不足、不够系统。如果无论怎么好的构架都无法满足客户明确的某个功能性需求或非功能性需求,就应该与客户协调在项目范围和需求规格说明书中删除这一需求。否则,架构设计应以满足客户所有明确需求为最基本目标,尽量满足其隐含的需求。(客户的非功能性需求可能包括接口、系统安全性、可靠性、移植性、扩展性等等,在其他小节中细述)
      一般来说,功能需求决定业务构架、非功能需求决定技术构架,变化案例决定构架的范围。需求方面的知识告诉我们,功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务构架,以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术构架要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计,结合功能需求和非功能需求,我们就可以确定一个需求的范围,进而确定一个构架的范围。(此段From林星)
      这里讲一个前几年因客户某些需求错误造成构架设计问题而引起系统性能和可靠性问题的小小的例子:此系统的需求本身是比较简单的,就是将某城市的某业务的全部历史档案卡片扫描存储起来,以便可以按照姓名进行查询。需求阶段客户说卡片大约有20万张,需求调研者出于对客户的信任没有对数据的总量进行查证。由于是中小型数据量,并且今后数据不会增加,经过计算20万张卡片总体容量之后,决定使用一种可以单机使用也可以联网的中小型数据库管理系统。等到系统完成开始录入数据时,才发现数据至少有60万,这样使用那种中小型数据库管理系统不但会造成系统性能的问题,而且其可靠性是非常脆弱的,不得不对系统进行重新设计。从这个小小的教训可以看出,需求阶段不仅对客户的功能需求要调查清楚,对于一些隐含非功能需求的一些数据也应当调查清楚,并作为构架设计的依据。
      对于功能需求的正确性,在构架设计文档中可能不好验证(需要人工、费力)。对于功能需求完整性,就应当使用需求功能与对应模块对照表来跟踪追溯。对于非功能需求正确性和完整性,可以使用需求非功能与对应设计策略对照表来跟踪追溯评估。
      “软件设计工作只有基于用户需求,立足于可行的技术才有可能成功。”
      2、 总体性能
      性能其实也是客户需求的一部分,当然可能是明确的,也有很多是隐含的,这里把它单独列出来在说明一次。性能是设计方案的重要标准,性能应考虑的不是单台客户端的性能,而是应该考虑系统总的综合性能;
      性能设计应从以下几个方面考虑:内存管理、数据库组织和内容、非数据库信息、任务并行性、网络多人操作、关键算法、与网络、硬件和其他系统接口对性能的影响;
    几点提示:算法优化及负载均衡是性能优化的方向。经常要调用的模块要特别注意优化。占用内存较多的变量在不用时要及时清理掉。需要下载的网页主题文件过大时应当分解为若干部分,让用户先把主要部分显示出来。
      3、 运行可管理性
      系统的构架设计应当为了使系统可以预测系统故障,防患于未然。现在的系统正逐步向复杂化、大型化发展,单靠一个人或几个人来管理已显得力不从心,况且对于某些突发事件的响应,人的反应明显不够。因此通过合理的系统构架规划系统运行资源,便于控制系统运行、监视系统状态、进行有效的错误处理;为了实现上述目标,模块间通信应当尽可能简单,同时建立合理详尽的系统运行日志,系统通过自动审计运行日志,了解系统运行状态、进行有效的错误处理;(运行可管理性与可维护性不同)
      4、 与其他系统接口兼容性(解释略)
      5、 与网络、硬件接口兼容性及性能(解释略)
      6、 系统安全性
      随着计算机应用的不断深入和扩大,涉及的部门和信息也越来越多,其中有大量保密信息在网络上传输,所以对系统安全性的考虑已经成为系统设计的关键,需要从各个方面和角度加以考虑,来保证数据资料的绝对安全。
      7、 系统可靠性
      系统的可靠性是现代信息系统应具有的重要特征,由于人们日常的工作对系统依赖程度越来越多,因此系统的必须可靠。系统构架设计可考虑系统的冗余度,尽可能地避免单点故障。系统可靠性是系统在给定的时间间隔及给定的环境条件下,按设计要求,成功地运行程序的概率。成功地运行不仅要保证系统能正确地运行,满足功能需求,还要求当系统出现意外故障时能够尽快恢复正常运行,数据不受破坏。
      8、 业务流程的可调整性
      应当考虑客户业务流程可能出现的变化,所以在系统构架设计时要尽量排除业务流程的制约,即把流程中的各项业务结点工作作为独立的对象,设计成独立的模块或组件,充分考虑他们与其他各种业务对象模块或组件的接口,在流程之间通过业务对象模块的相互调用实现各种业务,这样,在业务流程发生有限的变化时(每个业务模块本身的业务逻辑没有变的情况下),就能够比较方便地修改系统程序模块或组件间的调用关系而实现新的需求。如果这种调用关系被设计成存储在配置库的数据字典里,则连程序代码都不用修改,只需修改数据字典里的模块或组件调用规则即可。
      9、 业务信息的可调整性
      应当考虑客户业务信息可能出现的变化,所以在系统构架设计时必须尽可能减少因为业务信息的调整对于代码模块的影响范围。
      10、 使用方便性
      使用方便性是不须提及的必然的需求,而使用方便性与系统构架是密切相关的。WinCE(1.0)的失败和后来改进版本的成功就说明了这个问题。WinCE(1.0)有太多层次的视窗和菜单,而用户则更喜欢简单的界面和快捷的操作。失败了应当及时纠正,但最好不要等到失败了再来纠正,这样会浪费巨大的财力物力,所以在系统构架阶段最好能将需要考虑的因素都考虑到。当然使用方便性必须与系统安全性协调平衡统一,使用方便性也必须与业务流程的可调整性和业务信息的可调整性协调平衡统一。“满足用户的需求,便于用户使用,同时又使得操作流程尽可能简单。这就是设计之本。”
      11、构架样式的一致性
      软件系统的构架样式有些类似于建筑样式(如中国式、哥特式、希腊复古式)。软件构架样式可分为数据流构架样式、调用返回构架样式、独立组件构架样式、以数据为中心的构架样式和虚拟机构架样式,每一种样式还可以分为若干子样式。构架样式的一致性并不是要求一个软件系统只能采用一种样式,就像建筑样式可以是中西结合的,软件系统也可以有异质构架样式(分为局部异质、层次异质、并行异质),即多种样式的综合,但这样的综合应该考虑其某些方面的一致性和协调性。每一种样式都有其使用的时机,应当根据系统最强调的质量属性来选择。
      四、源代码的组织结构方面的考虑:
      1、 开发可管理性
      便于人员分工(模块独立性、开发工作的负载均衡、进度安排优化、预防人员流动对开发的影响:一个好的构架同时应有助于减少项目组的压力和紧张,提高软件开发效率)、利于配置管理、大小的合理性、适度复杂性;
      1)便于人员分工-模块独立性、层次性
      模块独立性、层次性是为了保证项目开发成员工作之间的相对独立性,模块联结方式应该是纵向而不是横向, 模块之间应该是树状结构而不是网状结构或交叉结构,这样就可以把开发人员之间的通信、模块开发制约关系减到最少。同时模块独立性也比较利于配置管理工作的进行。现在有越来越多的的软件开发是在异地进行,一个开发组的成员可能在不同城市甚至在不同国家,因此便于异地开发的人员分工与配置管理的源代码组织结构是非常必要的。
      2)便于人员分工-开发工作的负载均衡
      不仅仅是开发出来的软件系统需要负载均衡,在开发过程中开发小组各成员之间工作任务的负载均衡也是非重要的。所谓工作任务的负载均衡就是通过合理的任务划分按照开发人员特点进行分配任务,尽量让项目组中的每个人每段时间都有用武之地。这就需要在构架设计时应当充分考虑项目组手头的人力资源,在实现客户需求的基础上实现开发工作的负载均衡,以提高整体开发效率。
      3)便于人员分工-进度安排优化;
      进度安排优化的前提是模块独立性并搞清楚模块开发的先后制约关系。利用工作分解结构对所有程序编码工作进行分解,得到每一项工作的输入、输出、所需资源、持续时间、前期应完成的工作、完成后可以进行的工作。然后预估各模块需要时间,分析各模块的并行与串行(顺序制约),绘制出网络图,找出影响整体进度的关键模块,算出关键路径,最后对网络图进行调整,以使进度安排最优化。
      有个家喻户晓的智力题叫烤肉片策略:约翰逊家户外有一个可以同时烤两块肉片的烤肉架,烤每块肉片的每一面需要10分钟,现要烤三块肉片给饥肠辘辘急不可耐的一家三口。问题是怎样才能在最短的时间内烤完三片肉。一般的做法花20分钟先烤完前两片,再花20分钟烤完第三片。有一种更好的方法可以节省10分钟,大家想想。
      4)便于人员分工-预防员工人员流动对开发的影响
      人员流动在软件行业是司空见惯的事情,已经是一个常见的风险。作为对这一风险的有效的防范对策之一,可以在构架设计中考虑到并预防员工人员流动对开发的影响。主要的思路还是在模块的独立性上(追求高内聚低耦合),组件化是目前流行的趋势。
      5)利于配置管理(独立性、层次性)
      利于配置管理与利于人员分工有一定的联系。除了逻辑上的模块组件要利于人员分工外,物理上的源代码层次结构、目录结构、各模块所处源代码文件的部署也应当利于人员分工和配置管理。(尽管现在配置管理工具有较强大的功能,但一个清楚的源码分割和模块分割是非常有好处的)。
      6)大小的合理性与适度复杂性
      大小的合理性与适度复杂性可以使开发工作的负载均衡,便于进度的安排,也可以使系统在运行时减少不必要的内存资源浪费。对于代码的可阅读性和系统的可维护性也有一定的好处。另外,过大的模块常常是系统分解不充分,而过小的模块有可能降低模块的独立性,造成系统接口的复杂。
      2、 可维护性
      便于在系统出现故障时及时方便地找到产生故障的原因和源代码位置,并能方便地进行局部修改、切割;(可维护性与运行可管理性不同)
      3、 可扩充性:系统方案的升级、扩容、扩充性能
      系统在建成后会有一段很长的运行周期,在该周期内,应用在不断增加,应用的层次在不断升级,因此采用的构架设计等方案因充分考虑升级、扩容、扩充的可行性和便利
      4、 可移植性
      不同客户端、应用服务器、数据库管理系统:如果潜在的客户使用的客户端可能使用不同的操作系统或浏览器,其可移植性必须考虑客户端程序的可移植性,或尽量不使业务逻辑放在客户端;数据处理的业务逻辑放在数据库管理系统中会有较好的性能,但如果客户群中不能确定使用的是同一种数据库管理系统,则业务逻辑就不能数据库管理系统中;
    达到可移植性一定要注重标准化和开放性:只有广泛采用遵循国际标准,开发出开放性强的产品,才可以保证各种类型的系统的充分互联,从而使产品更具有市场竞争力,也为未来的系统移植和升级扩展提供了基础。
      5、 需求的符合性
      从源代码的组织结构看需求的符合型主要考虑针对用户需求可能的变化的软件代码及构架的最小冗余(同时又要使得系统具有一定的可扩展性)。
      五、写系统构架设计文档应考虑的问题
      构架工作应该在需求开发完成约80%的时候开始进行,不必等到需求开发全部完成,需要项目经理以具体的判断来评估此时是否足以开始构建软件构架。
      给出一致的轮廓:系统概述。一个系统构架需要现有概括的描述,开发人员才能从上千个细节甚至数十个模块或对象类中建立一致的轮廓。
      构架的目标应该能够清楚说明系统概念,构架应尽可能简化,最好的构架文件应该简单、简短,清晰而不杂乱,解决方案自然。
      构架应单先定义上层的主要子系统,应该描述各子系统的任务,并提供每个子系统中各模块或对象类的的初步列表。
      构架应该描述不同子系统间相互通信的方式,而一个良好的构架应该将子系统间的通信关系降到最低。
      成功构架的一个重要特色,在于标明最可能变更的领域,应当列出程序中最可能变更的部分,说明构架的其他部分如何应变。
      复用分析、外购:缩短软件开发周期、降低成本的有效方案未必是自行开发软件,可以对现有软件进行复用或进行外购。应考虑其对构架的影响。
      除了系统组织的问题,构架应重点考虑对于细节全面影响的设计决策,深入这些决策领域:外部软件接口(兼容性、通信方式、传递数据结构)、用户接口(用户接口和系统层次划分)、数据库组织和内容、非数据库信息、关键算法、内存管理(配置策略)、并行性、安全性、可移植性、网络多人操作、错误处理。
      要保证需求的可追踪性,即保证每个需求功能都有相应模块去实现。
      构架不能只依据静态的系统目标来设计,也应当考虑动态的开发过程,如人力资源的情况,进度要求的情况,开发环境的满足情况。构架必须支持阶段性规划,应该能够提供阶段性规划中如何开发与完成的方式。不应该依赖无法独立运行的子系统构架。将系统各部分的、依赖关系找出来,形成一套开发计划。
      六、结语
      系统构架设计和千差万别的具体的开发平台密切相关,因此在此无法给出通用的解决方案,主要是为了说明哪些因素是需要考虑的。对于每个因素的设计策略和本文未提到的因素需要软件构架设计师在具体开发实践中灵活把握。不同因素之间有时是矛盾的,构架设计时需要根据具体情况进行平衡。
      参考文献
      《软件构架实践》SEI软件工程译丛,林·巴斯著
      《微软项目:求生法则》Steve McConnell著,余孟学译
      《实用软件工程》第二版,郑人杰、殷人昆、陶永雷等著
      《软件工程:实践者的研究方法》(第5版)Roger S.Pressman著
      《软件开发的科学与艺术》陈宏刚等著
  • 软件测试概述

    2008-06-05 14:55:01

    软件开发和使用的历史已经留给了我们很多由于软件缺陷而导致的巨大财力、物力损失的经验教训。这些经验教训迫使我们这些测试工程师们必须采取强有力的检测措施来检测未发现的隐藏的软件缺陷。

        生产软件的最终目的是为了满足客户需求,我们以客户需求作为评判软件质量的标准,认为软件缺陷( Software Bug )的具体含义包括下面几个因素:

        软件未达到客户需求的功能和性能;

        软件超出客户需求的范围;

        软件出现客户需求不能容忍的错误;

        软件的使用未能符合客户的习惯和工作环境。

    考虑到设计等方面的因素,我们还可以认为软件缺陷还可以包括软件设计不符合规范,未能在特定的条件(资金、范围等)达到最佳等。可惜的是,我们中的很多人更倾向于把软件缺陷看成运行时出现问题上来,认为软件测试仅限于程序提交之后。

    在目前的国内环境下,我们几乎看不到完整准确的客户需求说明书,加以客户的需求时时在变,追求完美的测试变得不太可能。因此作为一个优异的测试人员,追求软件质量的完美固然是我们的宗旨,但是明确软件测试现实与理想的差距,在软件测试中学会取舍和让步,对软件测试是有百益而无一弊的。

    下面是一些软件测试的常识,对这些常识的理解和运用将有助于我们在进行软件测试时能够更好的把握软件测试的尺度。

        测试是不完全的(测试不完全)

    很显然,由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素,哪怕是一个极其简单的程序,要想穷尽所有逻辑路径,所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子,比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话,从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的,即便某一天我们能够穷尽该程序,只怕我们乃至我们的子孙都早已作古了。为此作为软件测试,我们一般采用等价类和边界值分析等措施来进行实际的软件测试,寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

        测试具有免疫性(软件缺陷免疫性)

    软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ,测试人员对其采用的测试越多,其免疫能力就越强,寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的,则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算,软件存在 500 个缺陷时,我们查找一个软件缺陷需要 X 小时,当软件只存在 5 个错误时,我们每查找一个软件缺陷需要 100X 小时。实践证明,实际的测试过程比上面的假设更为苛刻,为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷,因此软件测试应该尽可能的多采用多种途径进行测试。

        测试是 “ 泛型概念 ” (全程测试)

    我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话,需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷,记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证(自检)和设计验证(自检)也可以算作软件测试(建议称为:需求测试和设计测试)的一种。软件测试应该是一个泛型概念,涵盖整个软件生命周期,这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估(信息系统审计和软件工程监理),即测试本身也应当被测试,从而确保测试自身的可靠性和高效性。否则自身不正,难以服人。

    另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件,软件测试是提高产品质量最直接、最快捷的手段,但决不是一个根本手段。

        80-20 原则

    80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们,如果你想使软件测试有效地话,记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

    80-20 原则的另外一种情况是,我们在系统分析、系统设计、系统实现阶段的复审,测试工作中能够发现和避免 80% 的软件缺陷,此后的系统测试能够帮助我们找出剩余缺陷中的 80% ,最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷,却无法保证能够发现所有的软件缺陷。

    80-20 原则还能反映到软件测试的自动化方面上来,实践证明 80% 的软件缺陷可以借助人工测试而发现, 20% 的软件缺陷可以借助自动化测试能够得以发现。由于这二者间具有交叉的部分,因此尚有 5% 左右的软件缺陷需要通过其他方式进行发现和修正。

        为效益而测试

    为什么我们要实施软件测试,是为了提高项目的质量效益最终以提高项目的总体效益。为此我们不难得出我们在实施软件测试应该掌握的度。软件测试应该在软件测试成本和软件质量效益两者间找到一个平衡点。这个平衡点就是我们在实施软件测试时应该遵守的度。单方面的追求都必然损害软件测试存在的价值和意义。一般说来,在软件测试中我们应该尽量地保持软件测试简单性,切勿将软件测试过度复杂化,拿物理学家爱因斯坦的话说就是: Keep it simple but not too simple 。

        缺陷的必然性

    软件测试中,由于错误的关联性,并不是所有的软件缺陷都能够得以修复。某些软件缺陷虽然能够得以修复但在修复的过程中我们会难免引入新的软件缺陷。很多软件缺陷之间是相互矛盾的,一个矛盾的消失必然会引发另外一个矛盾的产生。比如我们在解决通用性的缺陷后往往会带来执行效率上的缺陷。更何况在缺陷的修复过程中,我们常常还会受时间、成本等方面的限制因此无法有效、完整地修复所有的软件缺陷。因此评估软件缺陷的重要度、影响范围,选择一个折中的方案或是从非软件的因素(比如提升硬件性能)考虑软件缺陷成为我们在面对软件缺陷时一个必须直面的事实。

        软件测试必须有预期结果

    没有预期结果的测试是不可理喻的。软件缺陷是经过对比而得出来的。这正如没有标准无法进行度量一样。如果我们事先不知道或是无法肯定预期的结果,我们必然无法了解测试正确性。这很容易然人感觉如盲人摸象一般,不少测试人员常常凭借自身的感觉去评判软件缺陷的发生,其结果往往是把似是而非的东西作为正确的结果来判断,因此常常出现误测的现象。

        软件测试的意义 - 事后分析

    软件测试的目的单单是发现缺陷这么简单吗?如果是 “ 是 ” 的话,我敢保证,类似的软件缺陷在下一次新项目的软件测试中还会发生。古语说得好, “ 不知道历史的人必然会重蹈覆辙 ” 。没有对软件测试结果进行认真的分析,我们就无法了解缺陷发生的原因和应对措施,结果是我们不得不耗费的大量的人力和物力来再次查找软件缺陷。很可惜,目前大多测试团队都没有意识到这一点,测试报告中缺乏测试结果分析这一环节。

1215/7<1234567>
Open Toolbar