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

发布新日志

  • 猎头给人才的十点忠告(转载)

    2008-07-14 12:02:26

    猎头给人才的十点忠告(转载)

    作为一名猎头,我将自己几年来从事职业经理工作的锦囊经验贡献出来与大家分享,
    愿这些吐血经验能够引起大家深层次的思考,并对大家有所帮助。

      1、打工无尊卑。无论你今天是普通工程师,还是贵为总经理,心态上都要保持平衡一致。
           反映在具体表现上就是与人为善,永远保持谦虚谨慎。
          如果你当工程师时见了门卫会打招呼,当了总裁后也要依然同门卫打招呼,
          切不可鼻孔朝天,否则死得很快。

      2、高薪者死。如果你今天能够赚到的月薪自己觉得还可以,就不要处心积虑谋求升值加薪。
          当你的薪水加到足以让老板对你时时重点关注的时候,你的死期也快到了。

      3、领导支持。作为各级职业经理人,一定不要忘记“密切联系领导”的道理,
          尤其对于广大中层干部。你的创意,你的计划,你的方案,要想得到顺利推行,
          首先一定要取得领导的支持。坚信:世上只有领导好,有领导支持的干部像块宝。

      4、群众信任。一个干部要想成功,除了领导的支持,还要取得同事的信任。
          因此,平时要时刻注意跟同事们打成一片,在一些无原则的小事上,要替他们争取利益,
          取得他们的信任,这样你就离成功不远了。

      5、请示汇报。永远不要相信公司里会有真正的授权。
          更不要以为你是MBA就可以踢开党委闹革命。那些埋头做事不看路,不请示少汇报的人,
          永远无法得到老板的信任和赏识。老板花了钱雇你们,其实他心里是很恐慌的,
         生怕你们拿了钱不干活。所以你要天天跟老板主动汇报你的工作,让他了解他没有白花钱雇你。

      6、鄙视海龟。对于所有的海龟(海外留学归来人士),以及国内大大小小的MBA们,
          不要考虑,统统采取鄙视的态度,没错!搞管理,其实不需要太多的理论。
          知识越多越反动!无论毛主席,还是比尔盖茨,无论李宏治还是赖昌星,大凡成功人士,
          没有几个具有本科以上学历的。你们信我吧!海龟之所以归来,
          90%以上是因为在国外混不下去.属于出国人群中的低能儿;
         要么干脆就是“克莱登”大学毕业的方鸿渐之流。用他们?一边呆着去吧!
         海龟唯一的作用就是把他们的牌牌挂到公司门口吸引风险投资,
         好比饭店门口的幌子。至于干活的本事,还是“汉阳造”的盒子炮好使。

      7、三招两式。做一个合格职业经理人,必须懂得三招:大力沟通,全力执行,谦虚谨慎。
         同时,随着你所在的行业以及所处的管理角色不同,你必须知道两式:
         涉及本专业的所有名词术语,涉及本行业的名人轶事等所有谈资。
         比如我作为人力资源经理,我每天大概花6个小时到各个部门跟人聊天,
         对于公司的任何人事政策,我都会始终不渝地抓落实,执行到底。
         我见了任何人都鞠躬问好,包括对扫地的阿姨。
         我熟知人力资源管理的所有理论、概念、名词,什么招聘与面试技巧、结构化面试、
         职位说明书、绩效考核、平衡记分卡(BSC)、X理论Y理论、培训、企业文化、
         马斯洛需求层次理论、员工满意度、职业发展规划、薪酬管理等等等等,
         同时我也对我所在企业所处的行业知识有着广泛但并不精深的了解。

      8、兔子不吃窝边草。作为职业经理人,千万不要对周围的同事发生感情,
           比如不要跟异性同事搞对象,不要跟同事做哥们儿。
           除了工作上的事情,没有私人感情可言。
          永远不要做烂好人,要保持自己的严肃性,或者说是威严。

      9、急流勇退。当感觉到自己已经爬到顶峰,无论职位还是薪酬都已经达到了无法再逾越的高度,
         一定要开始寻找全身而退的道路。比如开始跟猎头公司联系,留心跳槽事宜等。
         这个周期应该在半年到一年左右时间,换句话讲,如果你已经达到顶峰,
         而还赖在这个位子上超过一年无变化,就是你的失败。

      10、雁过留声。职业经理人最可宝贵的不是自己的薪酬,而是自己的名声。
         “人过留名雁过留声”的道理一定要记得。
           一定不要做损害原企业利益的事情,一定不要对同事做阴暗卑鄙的小人勾当。
          在新企业面前谈论旧企业一定要说好,在任何一家企业,只要你干一天,
         就要全心投入,敬业爱人。哪怕明天你就要办理离职交接了,
        今天也要全心全力为公司争取到最后一单生意。

     

  • 我的测试经历(20080712记录)

    2008-07-12 10:39:07

    测试记录:
    1、对相同的客户报价,以哪一个为准;(报价单)
    测试步骤:在两台电脑上同时报价;
    2、已解决单据按顺序连号问题;

    讨论:B/S系统测试:
    1、总公司(子母公司权限测试)基础资料是否共用,
    2在网页操作B/S应用程序时,怎样防止数据是否同步;
    (进销存系统,仓库的进出,财务金额的收入和支出等等)
    3打印报表,什么方式比较可取,是将报表格式下载到客户端,还是在服务端生成后,在客户端下载该报表格式;(多个客户都下载时,速度大受影响的;
    4怎样控制单据,列表,工具栏按钮的权限,各个部门的权限等等;
    5出错信息的异常处理和返回到的页面;
    6有没有人做过多页面在BS上操作?数据都能保存正确?

    网站测试实例--登录及权限测试
    验证用户输入有效性
    不能输入非法字符
    如:‘ %&nbsp; < -- 等脚本语言中常用的特殊字符
    不能直接访问有安全限制的页面
    如:浏览器历史记录中记录的页面

    用户名/密码验证SQL语句
    Select * from userinfo whereusername= 'i_username' and pwd = 'i_password'
    恶意登录 admin/ 'or '1'='1
    Select * from userinfo whereusername = 'admin' and pwd = '' or '1'= '1'
    用户名可以输入任意字符,只要密码中输入了 or true条件

    不能直接访问有安全限制的页面
    例子:
    用户A有登录网站的权限
    用户B直接访问历史记录中A访问过的页面

    数据过滤:参考,单据关联,单据列表,基础资料,找不到页面问题;

    BS系统主要的反映问题:1、过滤问题,出错信息(编辑信息),
    2、页面的出错信息是否与当前的页面或界面相适应,出现的提示信息是否明白,
    3、权限问题(不该有的信息是否能显示出来,要显示出来的东西是否显示正确;),
    4、数据不存在问题(可输入字段的前半部分在编辑界面上,特殊符号的输入%,空格键,令过滤信息检测不正确;)
    5参考:只有树;既有树,又有列表;参考界面,
    6基础信息是否共用,还是私用;
    7单据编号是否唯一,且连号;
    8两个用户或者三个用户同时操作同一单据,同一列表,同一单据明细,同一编辑界面,同一按钮,同时保存,同时改单,同时修改,同时删除,
    9多页面操作的复杂性,暂不考虑;(数据是否同步)
    10仓库库存量是否及时,准确反映出数据;
    11原则上不允许报表出现负的数量和金额,并且在月结转或年结转时,数据的处理方式的合理性;
    11系统流程设计的合理性,程序员设计系统时应该引导用户进行正确的操作,并且设计的流程是通用,简单,可操作性的;
    12客户需求只不过客户想达到怎样的结果,至于表达形式,程序员应该是对系统比较熟悉的,用最简单的方法满足客户需求,
    13考虑设计的合理性问题,不能说只能按这样操作,按这样的操作会出错,系统给出的东西,按正确操作,出错的机率比较少,多数出错都是由于用户不按常规操作造成的;
    14在操作单据过程中:会调出登录系统界面;
    15不同用户在IE上不同切换问题;
    16批增,选择记录后,要点击另外一条记录,才可反向选择;
    17最近操作的合理性;
    18对账单保存,系统错误;
    19权限(关联查找,单据上下查,编辑按钮);目前没有权限就不能访问该信息;
    20多几层的编辑界面;

    升级文件:要模拟的问题:
    1、登录系统,输入错误的用户或密码时,没有返回到登录页面;(已测到;)
    2、下面问题:要待测;
    素材入库单据明细:新增时,编辑界面只看见确定,没有出现该有的界面;
    素材入库选择:客户时,出现错误,应该找不到所属的页面;(进入编辑按钮时的返回页面;)
    3素材入库:客户参考,编辑,删除记录后,退出,再退出才返回到客户参考界面上;
    4素材入库:客户参考:编辑,点击记录,进入编辑界面,退出后,新增按钮不可用;
    5素材入库:客户参考:点击编辑按钮,进入后,退出界面,选择客户参考的一条记录,
    再点击新增按钮,没有编辑界面出来;
    6网页正在载入中:素材入库新增产品,编辑,再编辑(连接到产品分类)
    7.出现产品编号字段不唯一后,返回再修改,还会出现系统错误的信息;

    测试难点:
    1、需求不确定,客户和开发人员观点存在差异,没有达成共识;
    2、测试环境和用户环境有出入,没有配置正确的环境,导致有些BUG没有重现出来;
    3、系统所有单据状态没有统一规则,使系统流向不明确;
    4、用户需求和理论分析有区别,比如仓库要符合进出原则,产品进多少,产品就应该出多少,但客户没有明确规定,出的数量可以大于入的数量都允许;
    5、单据被引用后,再修改单据数据,导致单据数据没有确定关系;
    6、测试员不能和用户进行有效的沟通,了解客户所需要系统的功能,会使测试效率得不到有效提高,测试员应该尽可能地到用户的工作环境来了解;
    7、每个开发人员都可能有自己的观点时,如果开发人员没有主见,任由客户说了算,
    虽然解决了问题,但使系统过于复杂化,系统不能实时跟踪到问题;
    8、开发人员对自己系统不负责,只完成自己的职责,而不是更好完善自己的产品;
    因为开发人员对自己的产品比测试人员了解得更清楚;
    9、每修改一次系统,都进行回归测试,会使测试人员的时间分配不合理;
    10、做系统时,没有按行业进行规范和设计,使系统面向不同客户时,都要重新设计,
    系统面向一个客户时,都要做成通用的系统,并增加客户的特殊需要就可以了;
    11、并发操作;

  • BS产品测试要点

    2008-07-11 17:29:12

    功能方面:
       增删改及附件类:
    1. 对于所有的编码及名称输入是否作了重名处理
    2. 添加、修改记录时应有唯一性验证(尤其注意修改的重名)
    3. 输入框字符串长度限制,输入不当时应该有合适的错误提示
    4. 输入框字符类型限制(尤其<、>、%、’ 等非法字符),输入不当时应有合适的提示,
       如果允许输入应能正确处理
    5. 在列表中进行相关操作后,页面应该能及时自动刷新,而不应该需要手动刷新
    6. 所有读取、写入内容的时间都应以服务器时间为准,而非客户端时间
    7. 有下级内容或被引用的项目,应提示不能删除
    8. 多个用户同时操作同一数据(删、改),是否会产生错误
    10. 所有可以上传附件的地方都应能顺利上传、正确浏览或下载
    11. 下载文件时,如果能直接使用IE打开,是否会引发错误
    12. 附件是否支持特殊文件名(英文名、中文名、中英文混合名称、
       超长文件名、含有空格的文件名、含有特殊字符的文件名 etc)
    13. 附件是否支持该处应有的文件格式(文本、Office文档、影音文件、flash、exe etc)
    14. 服务器端口为非默认的80端口时,客户端上传、下载文件等应该也能正常进行
    15. 有弹出框操作的页面,出现过提示后如果使用键盘back键或F5刷新,则又会弹出该提示,
       这样的现象很多页面有

       查询及翻页类:
    1. 中文的条件查询
    2. 高级查询中应进行单条件查询、组合条件查询;查询条件为需要手动输入的以及系统提供被选项的
    3. 各种方式的翻页功能(上一页、下一页、首页、尾页、跳转、回车 etc)是否好用,查询后翻页
    4. 排序后翻页
    5. 查询后翻页,或查询结果排序后再翻页

      流程及其他类:
    1. 所有需求是否按要求实现,有无错漏
    2. 所有可能的操作
    3. 所有可能的异常流程
    4. 在执行流程时应测试出所有可能弹出的提示对话框
    5. 文字过长、页面不能完全显示时处理应得当、一致
    6. 所有模块各功能点都应连有其对应的帮助信息,应定位在该功能点上,而非帮助首页
    7. 不同用户的权限问题(详见后)
    8. 客户端的所有操作应以服务器时间为准
    9. 在安装后的asp文件中,有很多编程时的冗余信息,既影响效率也容易出错,还可能引发别的问题。
    10. 安装文件中有很多垃圾文件,如复件XX、temp.xxx,浪费磁盘空间
    11. 主页面注销退出或异常退出后,其他模块页面出现错乱,比如网络会议中该用户将永远被登记在他退出时的会议室里,以后也不能进入

       权限问题细测:
    1. 默认岗位对应的权限是否全部正确
    2. 通过直接对用户授权(系统管理)后的权限是否正确
    3. 系统管理中的取消用户授权是否正确
    4. 岗位兼职的权限是否正确
    5. 删除后的用户登录
    6. 禁用/锁定后的用户登录
    7. 权限a的用户A登录并进行一些操作后,权限b的用户B登录,其权限是否正确
    8. 没有权限的用户是否可以通过Del键删除系统信息

       安全问题细测:
    1. 未登录时在地址栏中直接输入要登录鉴权后才可访问的页面的地址或通过历史进入这些页面,
      系统应拒绝。
    2. SQL Server设置了超级用户(sa)的密码,系统应能正常使用。
    3. 进入具体的存储用户名和密码的表或文件中查看密码是否已经加密
    4. 对于一次Session会话连接,若长时间没有响应,系统应自动退出
    9. 通过ie的历史浏览查看信息

    易用性:
    测试要点:
    1. 主要页面在800*600和1024*768下不应该有滚动条(上下、左右)
    2. 所有能够翻页的页面在800*600和1024*768下都应显示正常
    3. 所有弹出页面的标题、图标等都为用友或U8特色
    4. 列表中不能显示完整内容的项目,鼠标置于其上时应出现完整信息
    5. 所有页面(包括标题及内容)是否出现“登陆”,“纪录”“察看”“等侯/稍侯”等错别字
    6. 所有“用户登录名”、“登录名”等都应统一为“用户名”
    7. 各模块中导入导出及打印页面的风格应一致
    8. 所有的翻页功能操作风格和效果均一致
    9. 在主要页面上都应支持键盘操作,如回车、Del (但要注意权限)、Back、Tab
    10. 一般二级或更低级的目录或项目显示页面上应该有“返回”按钮
    11. 很多有提示的地方提示用语是否通顺易懂
    12. 翻页对某条记录相关操作后,返回时应能回到所操作记录的页面而不是第一页

  • 佛学的181条智慧 献给压抑的IT人

    2008-07-11 17:15:24

    一、人之所以痛苦,在于追求错误的东西。 
    二、与其说是别人让你痛苦,不如说是自己的修养不够。 
    三、如果你不给自己烦恼,别人也永远不可能给你烦恼。因为在你自己的内心,你放不下。
    四、好好的管教你自己,不要管别人。
    五、不宽恕众生,不原谅众生,是苦了你自己。 
    六、别说别人可怜,自己更可怜,自己又懂得人生多少? 
    七、学佛是对自己的良心交待,不是做给别人看的。
    八、福报不够的人,就会常常听到是非;福报够的人,从来就没听到过是非。 
    九、修行是点滴的工夫。 
    十、在顺境中修行,永远不能成佛。
    十一、你永远要感谢给你逆境的众生。
    十二、你随时要认命,因为你是人。
    十三、你永远都要宽恕众生,不论他有多坏,甚至他伤害过你,你一定要放下,才能得到真正的快乐。
    十四、这个世界本来就是痛苦的,没有例外的。 
    十五、当你快乐时,你要想,这快乐不是永恒的。当你痛苦时你要想这痛苦也不是永恒的。
    十六、认识自己,降伏自己,改变自己,才能改变别人。
    十七、今日的执著,会造成明日的后悔。
    十八、你可以拥有爱,但不要执著,因为分离是必然的。
    十九、不要浪费你的生命在你一定会后悔的地方上。
    二十、你什么时候放下,什么时候就没有烦恼。
    二一、内心没有分别心,就是真正的苦行。
    二二、学佛第一个观念,永远不去看众生的过错。你看众生的过错,你永远污染你自己,你根本不可能修行。
    二三、你每天若看见众生的过失和是非,你就要赶快去忏悔,这就是修行。
    二四、业障深重的人,一天到晚都在看别人的过失与缺点,真正修行的人,从不会去看别人的过失与缺点。
    二五、每一种创伤,都是一种成熟。
    二六、当你知道迷惑时,并不可怜, 当你不知道迷惑时,才是最可怜的。
    二七、狂妄的人有救,自卑的人没有救。
    二八、你不要一直不满人家,你应该一直检讨自己才对。不满人家,是苦了你自己。
    二九、一切恶法,本是虚妄的,你不要太自卑你自己。一切善法,也是虚妄的,你也不要太狂妄你自己。
    三十、当你烦恼的时候,你就要告诉你自己,这一切都是假的,你烦恼什么? 
    三一、当你未学佛的时候,你看什么都不顺。当你学佛以后,你要看什么都很顺。
    三二、你要包容那些意见跟你不同的人,这样子日子比较好过。你要是一直想改变他,那样子你会很痛苦。要学学怎样忍受他才是。你要学学怎样包容他才是。
    三三、承认自己的伟大,就是认同自己的愚疑。
    三四、修行就是修正自己错误的观念。
    三五、医生难医命终之人,佛陀难渡无缘的众生。
    三六、一个人如果不能从内心去原谅别人,那他就永远不会心安理得。
    三七、心中装满着自己的看法与想法的人,永远听不见别人的心声。
    三八、毁灭人只要一句话,培植一个人却要千句话,请你多口下留情。
    三九、当你劝告别人时,若不顾及别人的自尊心,那么再好的言语都没有用的。
    四十、不要在你的智慧中夹杂着傲慢。不要使你的谦虚心缺乏智慧。
    四一、根本不必回头去看咒骂你的人是谁?如果有一条疯狗咬你一口,难道你也要趴下去反咬他一口吗?
    四二、忌妒别人,不会给自己增加任何的好处。忌妒别人,也不可能减少别人的成就。
    四三、永远不要浪费你的一分一秒,去想任何你不喜欢的人。
    四四、多少人要离开这个世间时,都会说出同一句话,这世界真是无奈与凄凉啊!
    四五、恋爱不是慈善事业,不能随便施舍的。感情是没有公式,没有原则,没有道理可循的。
         可是人们至死都还在执著与追求。
    四六、请你用慈悲心和温和的态度,把你的不满与委屈说出来,别人就容易接受。
    四七、创造机会的人是勇者。等待机会的人是愚者。
    四八、能说不能行,不是真智慧。
    四九、多用心去倾听别人怎么说,不要急着表达你自己的看法。
    五十、同样的瓶子,你为什么要装毒药呢?同样的心理,你为什么要充满着烦恼呢?
    五一、得不到的东西,我们会一直以为他是美好的,那是因为你对他了解太少,没有时间与他相处在一起。当有一天,你深入了解后,你会发现原不是你想像中的那么美好。
    五二、这个世间只有圆滑,没有圆满的。
    五三、修行要有耐性,要能甘于淡泊,乐于寂寞。
    五四、活着一天,就是有福气,就该珍惜。当我哭泣我没有鞋子穿的时候,我发现有人却没有脚。
    五五、多一分心力去注意别人,就少一分心力反省自己,你懂吗?
    五六、眼睛不要老是睁得那么大,我且问你,百年以后,那一样是你的。
    五七、欲知世上刀兵劫,但听屠门夜半声。不要光埋怨自己多病,灾祸横生,多看看横死在你刀下的众生又有多少?
    五八、憎恨别人对自己是一种很大的损失。
    五九、每一个人都拥有生命,但并非每个人都懂得生命,乃至于珍惜生命。不了解生命的人,生命对他来说,是一种惩罚。
    六十、自以为拥有财富的人,其实是被财富所拥有。
    六一、情执是苦恼的原因,放下情执,你才能得到自在。
    六二、随缘不是得过且过,因循苟且,而是尽人事听天命。
    六三、不要太肯定自己的看法,这样子比较少后悔。
    XXXXX、当你对自己诚实的时候,世界上没有人能够欺骗得了你。
    六五、用伤害别人的手段来掩饰自己缺点的人,是可耻的。
    六六、世间的人要对法律负责任。修行的人要对因果负责任。
    六七、在你贫穷的时候,那你就用身体去布施,譬如说扫地、洒水、搬东西等,这也是一种布施。
    六八、内心充满忌妒,心中不坦白,言语不正的人,不能算是一位五官端正的人。
    六九、默默的关怀与祝福别人,那是一种无形的布施。
    七十、多讲点笑话,以幽默的态度处事,这样子日子会好过一点。
    七一、与人相处之道,在于无限的容忍。
    七二、不要刻意去猜测他人的想法,如果你没有智慧与经验的正确判断,通常都会有错误的。
    七三、要了解一个人,只需要看他的出发点与目的地是否相同,就可以知道他是否真心的。
    七四、人生的真理,只是藏在平淡无味之中。
    七五、不洗澡的人,硬擦香水是不会香的。名声与尊贵,是来自于真才实学的。有德自然香。
    七六、与其你去排斥它已成的事实,你不如去接受它,这个叫做认命。
    七七、佛菩萨只保佑那些肯帮助自己的人。
    七八、逆境是成长必经的过程,能勇于接受逆境的人,生命就会日渐的茁壮。
    七九、你要感谢告诉你缺点的人。
    八十、能为别人设想的人,永远不寂寞。
    八一、如果你能像看别人缺点一样,如此准确般的发现自己的缺点,那么你的生命将会不平凡。
    八二、原谅别人,就是给自己心中留下空间,以便回旋。
    八三、时间总会过去的,让时间流走你的烦恼吧!
    八四、你硬要把单纯的事情看得很严重,那样子你会很痛苦。
    八五、永远扭曲别人善意的人,无药可救。
    八六、人不是坏的,只是习气罢了,每个人都有习气,只是深浅不同罢了。
    只要他有向道的心,能原谅的就原谅他,不要把他看做是坏人。
    八七、说一句谎话,要编造十句谎话来弥补,何苦呢?
    八八、其实爱美的人,只是与自己谈恋爱罢了。
    八九、世界上没有一个永远不被毁谤的人,也没有一个永远被赞叹的人。当你话多的时候,别人要批评你,当你话少的时候,别人要批评你,当你沈默的时候,别人还是要批评你。在这个世界上,没有一个不被批评的。
    九十、夸奖我们,赞叹我们的,这都不是名师。会讲我们,指示我们的,这才是善知识,有了他们我们才会进步。
    九一、你目前所拥有的都将随着你的死亡而成为他人的,那为何不现在就布施给真正需要的人呢?
    九二、为了赞美而去修行,有如被践踏的香花美草。
    九三、白白的过一天,无所事事,就像犯了窃盗罪一样。
    九四、能够把自己压得低低的,那才是真正的尊贵。
    九五、广结众缘,就是不要去伤害任何一个人。
    九六、沈默是毁谤最好的答覆。
    九七、对人恭敬,就是在庄严你自己。
    九八、拥有一颗无私的爱心,便拥有了一切。
    九九、仇恨永远不能化解仇恨,只有慈悲才能化解仇恨,这是永恒的至理。
    一00、你认命比抱怨还要好,对于不可改变的事实,你除了认命以外,没有更好的办法了。
    一0一、不要因为众生的愚疑,而带来了自己的烦恼。不要因为众生的无知,而痛苦了你自己。
    一0二、别人讲我们不好,不用生气、难过。说我们好也不用高兴,这不好中有好,好中有坏,就看你会不会用?
    一0三、如果你自己明明对,别人硬说你不对,你也要向人忏悔,修行就是修这些。你什么事都能忍下来,才会进步。就是明明是你对,你也要向他人求忏悔,那就是修行了。
    一0四、当你的错误显露时,可不要发脾气,别以为任性或吵闹,可以隐藏或克服你的缺点。
    一0五、不要常常觉得自己很不幸,世界上比我们痛苦的人还要多。
    一0六、愚痴的人,一直想要别人了解他。有智慧的人,却努力的了解自己。
    一0七、别人永远对,我永远错,这样子比较没烦恼。
    一0八、来是偶然的,走是必然的。所以你必须,随缘不变,不变随缘。
    一0九、慈悲是你最好的武器。
    一一0、只要面对现实,你才能超越现实。
    一一一、良心是每一个人最公正的审判官,你骗得了别人,却永远骗不了你自己的良心。
    一一二、不懂得自爱的人,是没有能力去爱别人的。
    一一三、学佛就是在学做人而已。
    一一四、正人行邪法,邪法亦正,邪人行正法,正法亦邪,一切唯心造。
    一一五、有时候我们要冷静问问自已,我们在追求什么?我们活着为了什么?
    一一六、不要因为小小的争执,远离了你至亲的好友,也不要因为小小的怨恨,忘记了别人的大恩。
    一一七、勇于接受别人的批评,正好可以调整自己的缺点。
    一一八、感谢上苍我所拥有的,感谢上苍我所没有的。
    一一九、凡是能站在别人的角度为他人着想,这个就是慈悲。
    一二0、学佛不是对死亡的一种寄托,而是当下就活得自在和超越。
    一二一、佛陀从不勉强别人去做他不喜欢的事情,佛陀只是告诉众生,何者是善?何者是恶?善恶还是要自己去选择,生命还是要自己去掌握。 
    一二二、所谓的放下,就是去除你的分别心、是非心、得失心、执著心
    一二三、说话不要有攻击性,不要有杀伤力,不夸已能,不扬人恶,自然能化敌为友。
    一二四、一个常常看别人缺点的人,自己本身就不够好,因为他没有时间检讨他自己。
    一二五、是非天天有,不听自然无,是非天天有,不听还是有,是非天天有,看你怎么办?
    一二六、真正的布施,就是把你的烦恼、忧虑、分别和执著心通通放下。
    一二七、如果你真的爱他,那么你必须容忍他部份的缺点。 
    一二八、要克服对死亡的恐惧,你必须要接受世上所有的人,都会死去的观念。
    一二九、所有的病患,医生最难治,所有的众生,自以为是的人最难渡。
    一三0、一匹驴,吃再好的草,也不会成为一匹骏马。用执著和分别心去修行,再大的精进,也不会成佛。 
    一三一、了解永恒真理的人,就不会为任何的生离死别而哀伤悲泣,因为生离死别是必然的。
    一三二、虽然你讨厌一个人,但却又能发觉他的优点好处,像这样子有修养的人,天下真是太少了。
    一三三、若能一切随他去,便是世间自在人。
    一三四、希望你常对自己说,闻到了佛法,我是最幸福的人,除了这幸福外,再没有别的了。
    一三五、如果你能每天呐喊二十一遍「我用不着为这一点小事而烦恼」,你会发现,你心里有一种不可思议的力量,试试看,很管用的。

    一三六、诚实的面对你内心的矛盾和污点,不要欺骗你自己。
    一三七、因果不曾亏欠过我们什么,所以请不要抱怨。
    一三八、我们确实有如是的优点,但也要隐藏几分,这个叫做涵养。
    一三九、无事莫把闲话聊,是非往往闲话生。
    一四0、大多数的人一辈子只做了三件事;自欺、欺人、被人欺。
    一四一、太过于欣赏自己的人,不会去欣赏别人的优点。
    一四二、活在别人的掌声中,是禁不起考验的人。
    一四三、心是最大的骗子,别人能骗你一时,而它却会骗你一辈子。
    一四四、坏孩子,父母总是比较操心。所以对于罪业愈深重的众生,我们更应该特别宽恕他怜愍他,而不应该远离他舍弃他。
    一四五、只要自觉心安,东西南北都好。如有一人未度,切莫自己逃了。
    一四六、用平常心来生活,用惭愧心来待人,心来处事,用菩提心契佛心。
    一四七、当你手中抓住一件东西不放时,你只能拥有这件东西,如果你肯放手,你就有机会选择别的。人的心若死执自己的观念,不肯放下,那么他的智慧也只能达到某种程度而已。
    一四八、人家怕你,并不是一种福,人家欺你,并不是一种辱。
    一四九、不是某人使我烦恼,而是我拿某人的言行来烦恼自己。
    一五0、不要刻意去曲解别人的善意,你应当往好的地方想。
    一五一、世上的事,不如己意者,那是当然的。
    一五二、我的财富并不是因为我拥有很多,而是我要求的很少。
    一五三、吃了就一定要拉,人一定要学会随缘放下,否则就会?便秘。
    一五四、常以为别人在注意你,或希望别人注意你的人,会生活的比较烦恼。
    一五五、我能为你煮东西,但我不能为你吃东西。各人吃饭是各人饱,各人生死是个人了。
    一五六、看轻别人很容易,要摆平自己却很困难。
    一五七、人类最大的错误,在于不敢承担圣人的心。
    一五八、你只管活你自己的,不必去介意别人的扭曲与是非。
    一五九、如果你准备结婚的话,告诉你一句非常重要的哲学名言「你一定要忍耐包容对方的缺点,世界上没有绝对幸福圆满的婚姻,幸福只是来自于无限的容忍与互相尊重。」
    一六0、如果你能够平平安安的渡过一天,那就是一种福气了。多少人在今天已经见不到明天的太阳,多少人在今天已经成了残废,多少人在今天已经失去了自由,多少人在今天已经家破人亡。
    一六一、是非和得失,要到最后的结果,才能评定。
    一六二、你不必和因果争吵,因果从来就不会误人。你也不必和命运争吵,命运它是最公平的审判官。
    一六三、你有你的生命观,我有我的生命观,我不干涉你。只要我能,我就感化你。如果不能,那我就认命。
    一XXXXX、你希望掌握永恒,那你必须控制现在。
    一六五、恶口永远不要出自于我们的口中,不管他有多坏,有多恶。你愈骂他,你的心就被污染了,你要想,他就是你的善知识。
    一六六、当你明天开始生活的时候,有人跟你争执,你就让他赢,这个赢跟输,都只是文字的观念罢了。当你让对方赢,你并没有损失什么。所谓的赢,他有赢到什么?得到什么?所谓的输,你又输到什么?失去什么?
    一六七、我们大部份的生命都浪费在文字语言的捉摸上。
    一六八、你不要常常觉得自己很委曲,你应该要想,他对我这样已经很好了,这就是修行的功夫。
    一六九、别人可以违背因果,别人可以害我们,打我们,毁谤我们。可是我们不能因此而憎恨别人,为什么?我们一定要保有一颗完整的本性和一颗清净的心。
    一七0、与任何人接触时,要常常问自己,我有什么对他有用?使他得益。如果我不能以个人的道德、学问和修持的力量,来使人受益,就等于欠了一份债。
    一七一、出家是一生一世的事,修行是多生多劫的事。
    一七二、信佛,学佛,不是为自己,乃是为一切苦海中的众生。
    一七三、佛不渡无缘的人,不能渡的人,我们就把他当做菩萨来看。
    一七四、如果一个人没有苦难的感受,就不容易对他人给予同情。你要学救苦救难的精神,就得先受苦受难。
    一七五、一般人在遇到对方的权势大,财富大,气力大,在无可奈何的情形之下而忍,这算什么忍耐呢?真正的忍是,就算他欺负了你,对不住你,但他什么都不及你,你有足够的力量对付他,而你却能容忍他,认为他的本性和我一样,只是一时糊涂,或在恶劣的环境中受到熏染罢了,你不必与他计较,能在这样的情况及心境之下容忍那才是真正的忍耐。 
    一七六、如果我们放眼从累生历劫去看,那么一切的众生,谁不曾做过我的父母、兄弟姊妹、亲戚眷属?
    谁不曾做过我的仇敌冤家?如果说有恩,个个与我有恩;如果说有冤,个个与我有冤。
    这样子我们还有什么恩怨亲疏之别呢?再就智慧愚笨来说,人人有聪明的时候,也有愚痴的时候,
    聪明的人可能变愚痴,愚痴的人也可能变聪明。最坏的人,也曾做过许多好事,而且不会永远坏;
    好人也曾做过许多坏事,将来也不一定会好。如此我们反覆思索,所谓的冤亲、贤愚,这许多差别的概念,
    自然就会渐渐淡了。这绝对不是混沌,也不是不知好坏,而是要将我们无始以来的偏私差别之见,
    以一视同仁的平等观念罢了!
    一七七、世界原本就不是属于你,因此你用不着抛弃,要抛弃的是一切的执著。
           万物皆为我所用,但非我所属。
    一七八、宁可自己去原谅别人,莫让别人来原谅你。
    一七九、当你用烦恼心来面对事物时,你会觉得一切都是业障,世界也会变得丑陋可恨。
    一八0、欲为诸佛龙象,先做众生马牛。
    一八一、虽然我们不能改变周遭的世界,我们就只好改变自己,用慈悲心和智慧心来面对这一切。

  • 如何编写有效的测试报告?

    2008-07-10 09:20:29

    根据我们小组的项目时间进度安排,现在这段时间正处于项目设计和测试的关键阶段,这里结合实践谈谈我对编写测试报告的看法。

        既然说到有效,我觉得要有两个特点:完整和实用,突出重点。引用一句广告词就是说“简约而不简单”,重点部分要突出,要细说,非重点部分,一笔带过,只是为了保证一个文档的完整性。

        说到一个测试报告,是对测试的过程和结果的汇总描述,所以其核心内容是两个,一个是测试结果的汇总报告,一个是测试过程的汇总总结,前者是针对所测软件本身,是给所测软件一个客观真实的评价;后者则是针对过程改进,回顾测试流程中存在的不足,加以总结改进。具体来说一般一个测试报告有如下部分构成。

    1.引言

    这个不用多说了,一般包括编写目的,项目背景介绍,参考资料等等,该项基本可以随便写写。(上次的项目展示在设计部分已经提到,所以测试部分并没有再做赘述)

    2.测试用例设计

    对用例设计做一个简单的描述,包括测试范围阿,测试目标阿,测试重点阿等。(早前的项目需求分析时我们已经分析过了,但为了保持文档的完整性这里可以修改后添上)

    3.测试环境

    主要描述测试所用环境,包括硬件环境和软件环境,服务端和客户端。(因为条件关系,只写了软硬件的环境^_^)

    4.测试方法

    主要描述测试过程中自己用到什么测试方法,白盒还是黑盒,用到了哪些测试类型和测试技术,用到多少。(该项比较重要)

    6.测试时间安排(执行情况)

    主要描述测试过程,每个时间段都做了什么事情。该项必不可少。

    7. Bug汇总及分析

    这一部分由于项目的设计还没有完成,现在只做了某些假设和分析。但是这部分是绝对重要的,也必不可少的。

    7.1 Bug总结

    一般按照严重程度,功能模块进行划分。(这部分我们在需求阶段已有划分,但设计阶段还没结束,所以仍有待完善)

    7.2 Bug分析

    通过上面7.1的总结,对bug进行分析。这项是测试报告的核心所在,一般有Bug功能模块

    7.3遗留问题

    目前软件残存的已知问题。有些是解决不掉的问题。

    7.4测试结论

    基于以上分析,给被测软件一个全面客观真实的结论,功能如何,性能如何,稳定性,安全性等等给出一个评价。该项最重要,绝不可少。

    8.测试过程改进

    对整个测试活动进行一个总结,有哪些得失,测试方法和流程需要哪些改进,测试过程中暴露出哪些问题,有哪些好的地方值得发扬等等。这项也很重要。

     

  • 比尔·盖茨 经典语录

    2008-07-10 09:16:07

    在比尔·盖茨写给高中毕业生和大学毕业生的书里,有一个单子上面列有10项学生没能在学校里学到的事情。它们是:

    ·生活是不公平的,要去适应它。

    ·这世界并不会在意你的自尊。这世界指望你在自我感觉良好之前先要有所成就。

    ·高中刚毕业你不会成为一个公司的副总裁,直到你将此职位挣到手。

    ·如果你认为你的老师严厉,等你有了老板再这样想。老板可是没有任期限制的。

    ·如果你陷入困境,不要尖声抱怨我们的错误,要从中吸取教训。

    ·在你出生之前,你的父母并非像现在这样乏味。他们变成今天这个样子是因为这些年来他们一直在为你付账单,给你洗衣服,听你大谈你是如何的酷。

    ·你的学校也许已经不再分优等生和劣等生,但生活却仍在作出类似区分。

    ·生活不分学期。你并没有暑假可以休息,也没有几位雇主乐于帮你发现自我。自己找时间做吧。

    ·电视并不是真实的生活。在现实生活中,人们实际上得离开咖啡屋去干自己的工作。善待乏味的人。有可能到头来你会为一个乏味的人工作。

    20年来比尔·盖茨的一些充满智慧的名言所进行的总结:

    ·1983年

    “目前已经有很多主要在计算机上应用的软件开发出来。就现在的情况看,面向IBM计算机的软件在其中占据着绝对的统治地位,但我相信,这种情况是会改变的,虽然其比例降到50%以下的可能性极小。”

    “在市场上目前的确存在很多垃圾软件,我们必须要对开发师们进行培训,告诉他们如何才能开发出更好的软件产品来。”

    ——摘录于1983年比尔·盖茨与PC World的一次访谈。

    ·1983年/1984年

    “但是,当我和保罗·艾伦(Paul Allen)在1975年开发出第一台微机版BASIC语言时,由于高级语言要求系统需具备高速处理器和大容量内存,这使其在大型机和小型机上的应用受到了限制。”

    “计算机语言必须不断与新的情况相适应。这意味着,计算机语言和人类语言一样。我们的语言并非是一臣不变的,它们要随着新的情况不断进行调整。与此类似,由于微型计算机的规模不断扩大,计算机语言也必须随之不断发展完善自己。”

    ——摘自比尔·-盖茨为《PC World年度软件回顾特刊》撰写的一篇文章。

    ·1986年

    “我们相信很多组织自己拥有计算机的时代很快就要到来,在这之前,有两件主要的事情需要我们做好准备,这就是设计好图形用户界面,以便能使像更大尺寸的显示器、新型芯片、激光打印机和互联网这些设备能够发挥最大的优势。大家将很快便可感受到运行在分布模式下的软件优势。”

    “从现在开始,一年以后市场上出售的所有计算机都将以286为基础,三年之后,大家将看到它们升级成386计算机。今天,如果我们将数据长期存储,目前计算机的存储性能(或程序运行它们的方便性),实在让人不敢恭维。我相信最终,能够满足公司处理工作需求的应用程序将会面世。标准软件程序和硬件将会使计算机的性能、用途得到显著的提高。那时人们将会感觉到如果没有计算机帮忙,他们的工作效率将会大幅下降。”

    “我们还没有见过那种只有10个非存储芯片(non-memory chips)的超级小型计算机(其中一个芯片的显示分辨率为1000×1000像素),或是不断更新的显示器。但是在接下来的三年里,这些都将变成现实,那时的人们如果看到现在的我们在640×200的模式下工作时,一定搞不懂我们在干什么。”

    ——摘自1986年1月比尔·盖茨与PC World进行的一次访谈。

    ·1987年

    比尔·盖茨与最喜欢的应用程序:“Excel。这是一款你和它接触越多,越发对其喜爱的软件。我经常使用Word,但是它不能进行分类规划,而且也不能充分发挥我的创造性。”

    同期取得的最重要成就:“帮助创建了一座MS-DOS标准的工作站,由此实现了在数千台电脑上运行同一种应用程序的梦想。当我16岁时,曾经夜以继日的开发FORTRAN编辑器,我发现那时已经有数百个在我之前写出的应用程序,我所开发的可能并不是最好的。但是由于存在很多不同的构架和操作系统,我又不得不写这些程序。所以我想能不能找到某种方法,以杜绝这些不得不做的无用功?这样不仅可以降低开发的应用程序数量,同时又能提高其质量。最终我终于达成了这个心愿,这让我非常开心。”

    ——摘自1987年与PC World的一次访谈。

    ·1993年

    “工作小组不断增长的现象将会激发人们对使用计算机的需求……未来微软所有的应用程序都将是工作组形式为基础的,而Windows工作组正是实现这个目标的一种方法。”

    ——摘自1993年1月PC World的一篇报道。

    ·1997年

    就微软花费4.25亿美元购买WebTV网络的议案,比尔·盖茨指出:“我们的目标是不仅要不断积累如何不断提高PC连接设备性能的经验,还要着眼于新一代TV产品。”

    ——摘自1997年6月9日信息电子世界(InfoWorld Electric)Bob Trott对新闻发布会的一篇报道。

    ·1999年

    “数码市场有广阔的发展前景,我们要不断的简化数码产品的技术含量、不断降低它们的价格,并使其更加贴进消费市场。”

    他说,关于在个人隐私上存在的问题,是可以轻易被技术发展所解决的,但是隐私保护条例与政治的关系要远远大于技术因素。盖茨还强调要对软件进行更多的测试以保证其质量。这被业界广泛认为是微软客户的福音。

    ——摘自1999年4月3日PC World编辑Tom Spring发表的比尔?盖茨在MIT实验室对于计算机技术举行的35周年庆典上的讲话。

    “计算机将成为用户存储信息和创建文档的总服务站。至于浏览网站关注世界的变化,消费者将有范围广阔的设备可供选择。

    ——摘自1999年12月28日IDG新闻服务机构Clare Haney的一篇报道。

    ·2000年

    “个人电视机具备录制下用户喜欢观看的电视节目的功能。”

    使用这些新的或旧的网络设备,“整个房子就如一台计算机一样。”

    ——摘自比尔·盖茨在2000年国际消费者电子大会上的致辞,由PC World的Cameron Crouch在2000年1月6日进行报道。

    “他们在不断的商讨计算机如何才能解决世界存在的所有问题。他们被自己做的事情深深的吸引了,他们还要为人类价值的前景做出全面的考虑。”

    ——摘自纽约时报的一篇关于比尔·盖茨在澳大利亚墨尔本2000年10月的讲话,PC World在2001年2月对其进行了全版引用。

    ·2001年

    “手写板计算机能够摆脱真正的约束,我预测在5年之内它将成为美国出售的PC中最受欢迎的机型。”

    ——摘自比尔·盖茨在计算机分销商展览会的发言(2006年由Martyn Williams在IDG新闻服务板块上引用)。

    ·2003年

    “我一直梦想着运行非常、非常好的计算机在某天能够来到这个世界,那时,我会使用微软开发的新产品。我再也不用给所有的开发师们发电子邮件质问他们:‘你们为什么要这样做?’”

    “如果你已经制定了一个远大的计划,那么就在你的生命中,用最大的努力去实现这个目标吧。”

    ——摘自比尔·盖茨在印度技术协会50周年庆典聚会上的讲话,由InfoWorld.com的编辑Paul Krill在2003年1月21日对其进行了报道。

    ·2004年

    “如果我们观察今天的计算机,其对简便易用的目标,可谓只实现了一半。”

    ——摘自比尔·盖茨与伯克利大学工程技术学院主任Richard Newton的谈话。由IDG新闻服务板块的记者Joris Evers在2004年10月1日进行了报道。

    2006年

    “我们的目标不是成为设备中心,而是要成为用户中心。”

    ——摘自比尔·盖茨在MIX 2006大会上的讲话,由IDG新闻服务板块记者Elizabeth Montalbano在2006年3月20日进行了报道。

    “我们的确已经看到,长时间以来,墨水服务写字板平台输入子系统和语音辨识输入系统已经变的和键盘一样重要,虽然相互之间不能取代,但重要性相同。”

    “事实上,我们相信在未来的某一天,所有的学生不用再背着教科书,代之使用的是连接无线网络的写字板电脑,学生们无论到哪里,都可以随身携带写字板电脑,它的亮度要高于教科书并且更具灵活性。提供的内容也更加丰富。”

    ——摘自2006年4月21日IDG新闻服务板块的记者Martyn Williams在东京大会上的一篇报道。PC World的编辑Amber Bouman为此篇报道也做出了贡献。

  • 管理学100个效应(1---50)

    2008-07-05 10:00:54


    第一章:管人用人育人留人之道

        企业的竞争,归根结底是人才的竞争。人才是企业的生命所在,如何管好人才、用好人才、培养和留住人才,则成为企业在激烈的竞争中成长发展的关键。

    1.  奥格尔维定律:善用比我们自己更优秀的人

        提出者:美国奥格尔维——马瑟公司总裁奥格尔维。

        点评:如果你所用的人都比你差,那么他们就只能做出比你更差的事情。如果我们每个人都雇用比我们自己都更强的人,我们就能成为巨人公司。

    2.  光环效应:全面正确地认识人才

      提出者:美国心理学家凯利(H. Kelly)

      点评:如一个人最初被认定是好的,则他身上的其它品质也都被认为是好的,有似“爱屋及乌”的原理。它指个人在敬仰、爱慕他人过程中所形成的夸大了的社会认知。光环效应在爱情和偶像崇拜中最明显。

    3.  不值得定律:让员工选择自己喜欢做的工作

       不值得定律最直观的表述是,不值得做的事情,就不值得做好,这个定律似乎再简单不过了,但它的重要性却时时被人们疏忘。不值得定律反映出人们的一种心理,一个人如果从事的是一份自认为不值得做的事情,往往会保持冷嘲热讽,敷衍了事的态度。不仅成功率小,而且即使成功,也不会觉得有多大的成就感。

      因此,对个人来说,应在多种可供选择的奋斗目标及价值观中挑选一种,然后为之奋斗。选择你所爱的,爱你所选择的,才可能激发我们的斗志,也可以心安理得。而对一个企业或组织来说,则要很好地分析员工的性格特性,合理分配工作,如让成就欲较强的职工单独或牵头完成具有一定风险和难度的工作,并在其完成时,给予及时的肯定和赞扬;让依附欲较强的职工,更多地参加到某个团体中共同工作;让权力欲较强的职工,担任一个与之能力相适应的主管。同时要加强员工对企业目标的认同感,让员工感觉到自己所做的工作是值得的,这样才能激发职工的热情。”

    4.  蘑菇管理定律:尊重人才的成长规律

      蘑菇管理是许多组织对待初出茅庐者的一种管理方法,初学者被置于阴暗的角落(不受重视的部门,或打杂跑腿的工作),浇上一头大粪(无端的批评、指责、代人受过),任其自生自灭(得不到必要的指导和提携)。相信很多人都有过这样一段蘑菇的经历,这不一定是什么坏事,尤其是当一切刚刚开始的时候,当几天蘑菇,能够消除我们很多不切实际的幻想,让我们更加接近现实,看问题也更加实际。

         一个组织,一般对新进的人员都是一视同仁,从起薪到工作都不会有大的差别。无论你是多么优秀的人才,在刚开始的时候,都只能从最简单的事情做起,“蘑菇”的经历,对于成长中的年轻人来说,就像蚕茧,是羽化前必须经历的一步。所以,如何高效率地走过生命的这一段,从中尽可能汲取经验,成熟起来,并树立良好的值得信赖的个人形象,是每个刚入社会的年轻人必须面对的课题。

    5.  贝尔效应:为有才干的下属创造脱颖而出的机会

      提出者:英国学者贝尔

      点评:贝尔天赋极高。有人估计过他毕业后若研究晶体和生物化学,定会赢得多次诺贝尔奖。但他却心甘情愿地走了另一条道路——把一个个开拓性的课题提出来,指引别人登上了科学高峰,此举被称为贝尔效应。这一效应要求领导者具有伯乐精神、人梯精神、绿地精神,在人才培养中,要以国家和民族的大业为重,以单位和集体为先,慧眼识才,放手用才,敢于提拔任用能力比自己强的人,积极为有才干的下属创造脱颖而出的机会。

    6.  酒与污水定律:及时清除烂苹果

      把一匙酒倒进一桶污水,得到的是一桶污水,如果把一匙污水倒进一桶酒,得到的还是一桶污水,这就是酒与污水定律最直白的表达。在现实中,在任何组织里,几乎都存在这样的人物,他们存在的目的似乎就是为了把事情搞糟。最糟糕的是,他们像果箱里的烂苹果,如果不及时处理,它会迅速传染,把果箱里其他苹果也弄烂。“烂苹果”的可怕之处,在于它那惊人的破坏力。一个正直能干的人进入一个混乱的部门可能会被吞没,而一个无德无才者能很快将一个高效的部门变成一盘散沙。组织系统往往是脆弱的,是建立在相互理解、妥协和容忍的基础上的,很容易被侵害、被毒化。

          破坏者能力非凡的另一个重要原因在于,破坏总比建设容易。一个能工巧匠花费时日精心制作的陶瓷器,一头驴子一秒钟就能毁坏掉。如果一个组织里有这样的一头驴子,即使拥有再多的能工巧匠,也不会有多少像样的工作成果。如果你的组织里有这样的一头驴子,你应该马上把蛇清除掉;如果你无力这样做,就应该把它拴起来。

    7.  首因效应:避免凭印象用人

        提出者:美国社会心理学家洛钦斯

      点评:首因效应,是指个体在社会认知过程中,通过“第一印象”最先输入的信息对客体以后的认知产生的影响作用。

        在社会认知中,个体获得对方第一印象的认知线索往往成为以后认知与评价的重要根据。首因效应的影响作用可以在一定程度上得到控制。首因效应的产生与个体的社会经历、社交经验的丰富程度有关。如果个体的社会经历丰富、社会阅历深厚、社会知识充实,则会将首因效应的作用控制在最低限度;另外,通过学习,在理智的层面上认识首因效应,明确首因效应获得的评价,一般都只是在依据对象的一些表面的非本质的特征基础上而做出的评价,这种评价应当在以后的进一步交往认知中不断地予以修正完善,也就是说,第一印象并不是无法改变,也不是难以改变的。

      

    8.  格雷欣法则:避免一般人才驱逐优秀人才

      提出者:托马斯·格雷欣爵士(Sir Thomas Gresham,英国伊莉莎白女王一世的顾问)

      点评:格雷欣法则,简单来说就是劣币驱逐良币。是说在市场上流通a,b两种币,面值一样但a是足值的货币,而b不足值,仍然可以充当交换货币。那么理性的人都会选择以次充好,将a留下来,将b用出去。从而在市场上,b驱逐了a。

    9.  雷尼尔效应:以亲和的文化氛围吸引和留住人才

      提出者:华盛顿大学教授

      点评:西雅图位于太平洋沿岸,华盛顿湖等大大小小的水域星罗棋布,天气晴朗时可以看到美洲最高的雪山之一雷尼尔山峰,华盛顿大学的教授们出于留恋西雅图的湖光山色,愿意接受较低的工资,而不到其它大学去寻找更高报酬的职位,他们为了美好的景色而牺牲更高的收入机会,被华盛顿大学的教授们戏称为“雷尼尔效应”。由此可见,美丽的景色也是一种无形财富,它起到了吸引和留住人才的作用。我们可否利用“雷尼尔效应”呢?美丽的西雅图风光可以留住吸引华盛顿大学的教授们,同样的道理,企业也可以用“美丽的风光”来吸引和留住人才。当然,这里的“美丽风光”不仅是自然风光,更多的是良好的人际关系和健康的文化氛围。

    10. 适才适所法则:将恰当的人放在最恰当的位置上

        做好人力资源配置是人力资源管理的基础。简单地说就是将合适的人放在合适的岗位上,真正做到适才适所。建立完善的激励机制与掌握合适的激励手法是人力资源管理的中心任务。对于激励通常有两种。第一种是普遍的物质激励;第二种就是人性面激励。两种激励应该是整合使用,关键是必须把握员工的需求层次,以最有效的补偿手段满足他的心理需要,并把这种需要引导成为他内在的驱动力量,并激发这种力量释放到企业发展所需要的本职工作上,让平凡的人做出不平凡的业绩。

    11. 特雷默定律:企业里没有无用的人才

        提出者:英国管理学家E·特雷默

      点评:  每个人的才华虽然高低不同,但一定是各有长短,因此在选拔人才时要看重的是他的优点而不是缺点,利用个人特有的才能再委以相应责任,使各安其职,这样才会使诸方矛盾趋于平衡。否则,职位与才华不能适合,使应有的能力发挥不出﹐彼此之间互不信服﹐势必造成冲突的加剧。在一个团队中,每个人各有所长,但更重要的是领导者能将这些人依其专长运用到最适当的职位,使其能够发挥自己所长,进而让整个企业繁荣强盛。没有无用的人,只有不会用人的人。

    12. 乔布斯法则:网罗一流人才

        提出者: 苹果计算机公司老板史蒂夫·乔布斯

        点评:乔布斯说,他花了半辈子时间才充分意识到人才的价值。他在最近一次讲话中说:“我过去常常认为一位出色的人才能顶两名平庸的员工,现在我认为能顶50名。”由于苹果公司需要有创意的人才,所以乔布斯说,他大约把四分之一的时间用于招募人才。高级管理人员往往能更有效地向人才介绍本公司的远景目标。而对于新成立的富有活力的公司来说,其创建者通常在挑选职员时十分仔细,老板亲临招聘现场,则可使求职者以最快速度了解与适应公司的文化氛围和环境。

     13. 大荣法则:企业生存的最大课题就是培养人才

      提出者:日本大荣公司

      点评:企业的发达,乃人才的发达;人才的繁荣,即事业的繁荣。

    14. 海潮效应:以待遇吸引人,以事业激励人

        海水因天体的引力而涌起,引力大则出现大潮,引力小则出现小潮,引力过弱则无潮。此乃海潮效应。人才与社会时代的关系也是这样。社会需要人才,时代呼唤人才,人才便应运而生。依据这一效应,作为国家,要加大对人才的宣传力度,形成尊重知识、尊重人才的良好风气。对于一个单位来说,重要的是要通过调节对人才的待遇,以达到人才的合理配置,从而加大本单位对人才的吸引力。现在很多知名企业都提出这样的人力资源管理理念:以待遇吸引人,以感情凝聚人,以事业激励人。

    第二章:以人为本的人性化管理

      古语云:得人心者得天下!在企业管理中多点人情味,有助于赢得员工对企业的认同感和忠诚度。只有真正俘获了员工心灵的企业,才能在竞争中无往而不胜。

     

    15. 南风法则:真诚温暖员工

      提出者:“南风”法也称为“温暖”法则,源于法国作家拉封丹写的一则寓言

      点  评:北风和南风比威力,看谁能把行人身上的大衣脱掉。北风首先来一个冷风凛冽寒冷刺骨,结果行人把大衣裹得紧紧的,南风则徐徐吹动,顿时风和日丽,行人因为觉得春意上身,始而解开纽扣,继而脱掉大衣,南风获得了胜利。

      领导者在管理中运用“南风”法则,就是要尊重和关心下属,以下属为本,多点人情味,使下属真正感觉到领导者给予的温暖,从而去掉包袱,激发工作的积极性。

    16. 同仁法则:把员工当合伙人

     提出者:美国一个家庭用品公司

     点  评:该公司把销售人员称作“同仁”。公司非基层职位90%以上的是由公司人员填补的,公司400名部门负责人中,只有17人是从外面招聘的。公司股票购置计划也力图使全体员工都成为真正的“同仁”。所有员工都可以在任何时候以低于公司股票价格15%的幅度购买。以此表现出的是,公司人才流失比零售业的平均水平低20%。“二人同心,其利断金。”企业与员工有了共同的目标与使命感,才会风雨同舟、同甘共苦。

    17. 互惠关系定律:爱你的员工,他会百倍地爱你的企业

      “给予就会被给予,剥夺就会被剥夺。信任就会被信任,怀疑就会被怀疑。爱就会被爱,恨就会被恨。”这就是心理学上的互惠关系定律。人是三分理智、七分感情的动物。士为知己者死,从业者可以为认可自己存在价值的上司鞠躬尽瘁。当你真诚地帮助员工的时候,员工才能真正地帮助你!  

    18. 蓝斯登定律:给员工快乐的工作环境

      提出者:美国管理学家蓝斯登

      点  评:跟一位朋友一起工作,远较在“父亲”之下工作有趣得多。你给员工快乐的工作环境,员工给你高效的工作回报。让你的员工快乐起来!

      有关调查结果表明,企业内部生产率最高的群体,不是薪金丰厚的员工,而是工作心情舒畅的员工。愉快的工作环境会使人称心如意,因而会工作得特别积极。不愉快的工作环境只会使人内心抵触,从而严重影响工作的效绩。

      有很多公司管理者,比较喜欢在管理岗位上板起面孔,做出一副父亲的模样。他们大概觉得这样才能赢得下属的尊重,树立起自己的权威,从而方便管理。这是走入了管理的误区。现代人的平等意识普遍增强了,板起面孔不能真正成为权威!放下你的尊长意识,去做你下级的朋友吧,你会有更多的快乐,也将使工作更具效率、更富创意,你的事业也终将辉煌!

    19. 柔性管理法则:“以人为中心”的人性化管理

      提出者:金星啤酒集团

      点  评:著名的马斯洛需求理论提出人的需求有五个层次:生理、安全、社交、尊重、自我实现,而且这五个层次是逐级渐进和同时存在的。为员工创造经济需求(生理、安全)及精神需求(社交、尊重、自我实现)“自我实现”的文化氛围和参与管理的“自我改善”机制,充分调动了员工积极性,增强了企业的活力和凝聚力。

      自我改善的柔性管理不是放任自流,随心所欲,而是以严格规范管理为基础,以高素质的员工队伍为条件,突出员工自我管理的主体,通过顺势而人性化的管理,强化管理的应变能力。把员工在企业中自我价值的实现与企业的发展目标相融合。

    20. 坎特法则:管理从尊重开始

      尊重员工是人性化管理的必然要求,是回报率最高的感情投资。尊重员工是领导者应该具备的职业素养,而且尊重员工本身就是获得员工尊重的一种重要途径。

    21. 波特定律:不要总盯着下属的错误

      提出者:1766年,普鲁士天文学家约翰·提丢斯(1729-1796)推导出了用天文单位来计算从太阳到行星距离的公式。该公式于1772年被德国天文学家约翰·波特(1747-1826)公诸于众。

      点  评:该公式(D=(N+4)AU/10)  用字母D表示从太阳到某一行星的距离,在推导出这个公式的时候,人们发现了水星、金星、火星、木星及土星与D值相吻合。 1781年天王星的发现正好与D值19.6相吻合, 1929年发现的冥王星,其D值有所误差,而对于海王星来说,这个公式则完全失效。

      再好的人也有犯错误的时候,不要总盯着下属的错误不放。重要的是,查找错误的原因。

    22. 刺猬法则:与员工保持“适度距离”

      两只困倦的刺猬,由于寒冷而拥在一起。可因为各自身上都长着刺,于是它们离开了一段距离,但又冷得受不了,于是凑到一起。几经折腾,两只刺猬终于找到一个合适的距离:既能互相获得对方的温暖而又不致于被扎。

      “刺猬”法则就是人际交往中的“心理距离效应”。领导者要搞好工作,应该与下属保持亲密关系,这样做可以获得下属的尊重。与下属保持心理距离,避免在工作中丧失原则。

    23. 热炉法则:规章制度面前人人平等

      每个单位都有自己的规章制度,单位中的任何人触犯了都要受到惩罚。

    “热炉”法则形象地阐述了惩处原则:

    (1)热炉火红,不用手去摸也知道炉子是热的,是会灼伤人的——警告性原则。领导者要经常对下属进行规章制度教育,以警告或劝戒不要触犯规章制度,否则会受到惩处。

    (2)每当你碰到热炉,肯定会被灼伤。也就是说只要触犯单位的规章制度,就一定会受到惩处

    (3)当你碰到热炉时,立即就被灼伤——即时性原则。惩处必须在错误行为发生后立即进行,决不拖泥带水,决不能有时间差,以便达到及时改正错误行为的目的。

    (4)不管谁碰到热炉,都会被灼伤——公平性原则。

    24. 金鱼缸效应:增加管理的透明度

      鱼缸是玻璃做的,透明度很高,不论从哪个角度观察,里面的情况都一清二楚。

    “金鱼缸”法则运用到管理中,就是要求领导者增加各项工作的透明度。各项工作有了透明度,领导者的行为就会置于全体下属的监督之下,就会有效地防止领导者滥用权力,从而强化领导者的自我约束机制。

    第三章:灵活有效的激励手段

      有效的激励会点燃员工的激情,促使他们的工作动机更加强烈,让他们产生超越自我和他人的欲望,并将潜在的巨大的内驱力释放出来,为企业的远景目标奉献自己的热情。

    25. 鲶鱼效应:激活员工队伍

      点  评:挪威人的渔船返回港湾,可是渔民们捕来的沙丁鱼已经死了,只有汉斯捕来的沙丁鱼还是活蹦乱跳的,原来,汉斯将几条沙丁鱼的天敌鲶鱼放在运输容器里。因为鲶鱼是食肉鱼,放进鱼槽后使沙丁鱼们紧张起来,为了躲避天敌的吞食,沙丁鱼自然加速游动,从而保持了旺盛的生命力,因而它们才存活下来。如此一来,沙丁鱼就一条条活蹦乱跳地回到渔港。

      这在经济学上被称作“鲶鱼效应”。其实用人亦然。一个公司,如果人员长期固定,就缺乏活力与新鲜感,容易产生惰性。因此有必要找些外来的“鲶鱼”加入公司,制造一些紧张气氛。当员工们看见自己的位置多了些“职业杀手”时,便会有种紧迫感,知道该加快步伐了,否则就会被Kill掉。这样一来,企业自然而然就生机勃勃了。

      当压力存在时,为了更好地生存发展下去,惧者必然会比其他人更用功,而越用功,跑得就越快。适当的竞争犹如催化剂,可以最大限度地激发人们体内的潜力。

    26. 马蝇效应:激起员工的竞争意识

    提出者:美国前总统林肯

    点  评:1860年,林肯当选为美国总统。有一天,有位名叫巴恩的银行家到林肯的总统官邸拜访,正巧看见参议员萨蒙?蔡思从林肯的办公室走出来。于是,巴恩对林肯说:“如果您要组阁的话,千万不要将此人选入您的内阁。”林肯奇怪地问:“为什么?”巴恩说:“因为他是个自大成性的家伙,他甚至认为他比您伟大得多。”《纽约时报》主编亨利?雷蒙顿拜访林肯的时候,特地告诉他蔡思正在狂热地上蹿下跳,谋求总统职位。

      林肯以他一贯以来特有的幽默对雷蒙顿说:“亨利,你不是在农村长大的吗?那你一定知道什么是马蝇了。有一次,我和我兄弟在肯塔基老家的农场里耕地。我吆马、他扶犁。偏偏那匹马很懒,老是磨洋工。但是,有一段时间它却在地里跑得飞快,我们差点都跟不上他。到了地头,我才发现,有一只很大的马蝇叮在他的身上,于是我把马蝇打落在了。我的兄弟问我为什么要打掉它,我告诉他,不忍心让马被咬。我的兄弟说:哎呀,就是因为有那家伙,这匹马才跑得那么快。”然后,林肯意味深长地对雷蒙顿说:“现在正好有一只名叫‘总统欲’的马蝇叮着蔡思先生,那么,只要它能使蔡思那个部门不停地跑,我还不想打落它。”

      没有马蝇叮咬,马慢慢腾腾,走走停停;有马蝇叮咬,马不敢怠慢,跑得飞快。这就是马蝇效应。马蝇效应给我们的启示是:一个人只有被叮着咬着,他才不敢松懈,才会努力拼搏,不断进步。

    27. 罗森塔尔效应:满怀期望的激励

      提出者:美国心理学家罗森塔尔

      点  评:美国心理学家罗森塔尔考查某校,随意从每班抽3名学生共18人写在一张表格上,交给校长,极为认真地说:“这18名学生经过科学测定全都是智商型人才。”事过半年,罗氏又来到该校,发现这18名学生的确超过一般,长进很大,再后来这18人全都在不同的岗位上干出了非凡的成绩。这一效应就是期望心理中的共鸣现象。

      运用到管理中,就要求领导对下属要投入感情、希望和特别的诱导,使下属得以发挥自身的主动性、积极性和创造性。如领导在交办某一项任务时,不妨对下属说:“我相信你一定能办好”、“你是会有办法的”┉这样下属就会朝你期待的方向发展,人才也就在期待之中得以产生。一个人如果本身能力不是很行,但是经过激励后,才能得以最大限度的发挥,也就变成了行。

    28. 彼得原理:晋升是最糟糕的激励措施

      每个组织都是由各种不同的职位、等级或阶层的排列所组成,每个人都隶属于其中的某个等级。彼得原理是美国学者劳伦斯.彼得在对组织中人员晋升的相关现象研究后,得出的一个结论:在各种组织中,雇员总是趋向于晋升到其不称职的地位。彼得原理有时也被称为“向上爬”原理。

         这种现象在现实生活中无处不在:一名称职的教授被提升为大学校长后,却无法胜任;一个优秀的运动员被提升为主管体育的官员,而无所作为。对一个组织而言,一旦相当部分人员被推到其不称职的级别,就会造成组织的人浮于事,效率低下,导致平庸者出人头地,发展停滞。

         因此,这就要求改变单纯的“根据贡献决定晋升”的企业员工晋升机制,不能因某人在某岗位上干得很出色,就推断此人一定能够胜任更高一级的职务。将一名职工晋升到一个无法很好发挥才能的岗位,不仅不是对本人的奖励,反而使其无法很好发挥才能,也给企业带来损失。

    29.“保龄球”效应:赞赏与批评的差异

       两名保龄球教练分别训练各自的队员。他们的队员都是一球打倒了7只瓶。教练甲对自己的队员说:“很好!打到了7只。”他的队员听了教练的赞扬很受鼓舞,心里想,下次一定再加把劲,把剩下的3只也打倒。教练乙则对他的队员说:“怎么搞的!还有3只没打倒。”队员听了教练的指责,心里很不服气,暗想,你咋就看不见我已经打倒的那7只。结果,教练甲训练的队员成绩不断上升,教练乙训练的队员打得一次不如一次。

      希望得到他人的肯定、赞赏,是每一个人的正常心理需要。而面对指责时,不自觉的为自己辩护,也是正常的心理防卫机制。

      一个成功的管理者,会努力去满足下属的这种心理需求,对下属亲切,鼓励部下发挥创造精神,帮助部下解决困难。相反,专爱挑下属的毛病,靠发威震慑下属的管理者,也许真的能够击败他的部下,但是,一头暴怒的狮子领着一群绵羊,又能创造出什么事业呢?

      用好赞赏的技巧,关键是把你的注意力集中到“被球击倒的那7只瓶”上,别老忘不了没击倒的那3只。要相信任何人或多或少都有长处、优点,只要“诚于嘉许,宽于称道”,你就会看到神奇的效力。

    30. 末位淘汰法则(活力曲线):通过竞争淘汰来发挥人的极限能力

      提出者:GE公司前CEO杰克·韦尔奇(活力曲线其实质就是“末位淘汰”)

      点  评:将员工划分为不同的类别,然后严格地加以区别对待。这正是韦尔奇所推崇的“活力曲线”,这一曲线被认为是给GE带来无限活力的法宝之一。

        以业绩为横轴(由左向右递减),以组织内达到这种业绩的员工的数量为纵轴(由下向上递增)。

        利用这张正态分布图,你将很容易区分出业绩排在前面的20%的员工(A类)、中间的70%的员工(B类)和业绩排在后面的10%的员工(C类)。

        这种评估组织内人力资源的方法,韦尔奇称之为“活力曲线”。

      “末位淘汰法则”顾名思义是“将工作业绩靠后的员工淘汰掉”,其实质是企业为了满足市场竞争的需要,在对企业员工的工作表现做出科学的评价后,进行分类或排序,并按照一定的比例标准,将末几位予以调岗或辞退的行为。

    31. 默菲定律:从错误中汲取经验教训

      提出者:美国空军上尉工程师爱德华·默菲

      点  评:源于美国空军1949年进行的关于“急剧减速对飞行员的影响”的研究。实验的志愿者们被绑在火箭驱动的雪橇上,当飞速行驶的雪橇突然停止时,实验人员会监控他们的状况。监控器具是一种由空军上尉工程师爱德华·默菲所设计的甲胄,甲胄里面装有电极。有一天,在通常认为无误的测试过程中,甲胄却没有记录任何数据,这使技术人员感到非常吃惊。默菲后来发现甲胄里面的电极每一个都放错了,于是他即席说道:如果某一事情可以有两种或者两种以上的方法来实现,而其中有一种会导致灾难性的错误,那么这一错误往往就会发生。

      默菲的这一说法后来得到广泛的流传并被总结成默菲定律:如果坏事有可能发生,不管这种可能性多么小,它总会发生,并可能引起更大的损失。

      我们对于幸福快乐的事情总是容易忘记,而对于不幸郁闷的事情却总是耿耿于怀。

         我们在日常排队时也不是总排在最慢的队伍中,排上快或慢的队伍发生的概率大致是相同的,也是一个随机的事件。在一些其它的事情上,原因也与此很相似。

    32.“垃圾桶”理论:有效解决员工在工作期间偷懒的问题

       荷兰有一个城市为解决垃圾问题而购置了垃圾桶,但由于人们不愿意使用垃圾桶,乱扔垃圾现象仍十分严重。该市卫生机关为此提出了许多解决办法。第一个方法是:把对乱扔垃圾的人的罚金从25元提高到50元。实施后,收效甚微。第二个方法是:增加街道巡逻人员的人数,成效亦不显著。后来,有人在垃圾桶上出主意:设计了一个电动垃圾桶,桶上装有一个感应器,每当垃圾丢进桶内,感应器就有反应而启动录音机,播出一则故事或笑话,其内容还每两周换一次。这个设计大受欢迎,结果所有的人不论距离远近,都把垃圾丢进垃圾桶里,城市因而变得清洁起来。

      在垃圾桶上安装感应式录音机,丢垃圾进去播出一则故事或笑话,效果远比那些惩罚手段好得多,既省钱,又不会让人们感到厌恶。同样,要解决员工在工作期间偷懒的问题,用监管和处罚的手段实际上也是很难奏效的,因为员工的工作成效主要还是要靠其用心努力。员工偷懒,是故意偷懒还是忙里偷闲?是员工自身的原因还是公司管理出了问题?具体问题要具体分析。在处理员工偷懒问题上,加强沟通很重要。须注意的是,让员工超时且拘束地工作,已是不合时宜的管理方法;给员工多点理解、关心和体谅,会有助于发挥员工的工作积极性和创造力。

    33. 比马龙效应:如何在“加压”中实现激励

      人会期待别人对自己好印象,就会认真的表现良好行为;若期待别人会讨厌自己,就会随便表现。让人比成龙,自己就会像龙一样地表现,反之,被比成马,会像马一样地反应。这种现象称之为“比马龙”效应。

      现代管理科学研究表明,如果一个人长期不能面临挑战,甚至无事可干,那他必然会产生一种“怀才不遇”的挫折感,极有可能失去原有的一腔抱负和凌云壮志,甚至产生抵触情绪,进而离开他最初的组织。因此,任何一个组织都应该给新参加工作的人员以必要的压力,为他们提供成长锻炼的机会和施展才华的舞台。松下公司的“中级人才”观以及“让B级人做A级事”等都是高期望式激励,这些无一不是人力资源管理中“比马龙效应“的具体实践。

    34. 横山法则:自发的才是最有效的,激励员工自发地工作

      提出者:日本社会学家横山宁夫。

      点评:有自觉性才有积极性,无自决权便无主动权。在管理的过程中,我们常常过多地强调了“约束”和“压制”,事实上这样的管理往往适得其反。如果人的积极性未能充分调动起来,规矩越多,管理成本越高。聪明的企业家懂得在“尊重”和“激励”上下功夫,了解员工的需要,然后满足他。只有这样,才能激起员工对企业和自己工作的认同,激发起他们的自发控制,从而变消极为积极。真正的管理,就是没有管理。

        促进员工自我管理的方法,就是处处从员工利益出发,为他们解决实际问题,给他们提供发展自己的机会,给他们以尊重,营造愉快的工作氛围。做到了这些,员工自然就和公司融为一体了,也就达到了员工的自我控制。

    35. 肥皂水效应:将批评夹在赞美中

       提出者:美国前总统约翰·卡尔文·柯立芝

    点评:约翰·卡尔文·柯立芝于1923 年成为美国总统, 他有一位漂亮的女秘书, 人虽长得很好, 但工作中却常因粗心而出错。一天早晨, 柯立芝看见秘书走进办公室, 便对她说:“今天你穿的这身衣服真漂亮, 正适合你这样漂亮的小姐。”这句话出自柯立芝口中, 简直让女秘书受宠若惊。柯立芝接着说:“但也不要骄傲, 我相信你同样能把公文处理得像你一样漂亮的。”果然从那天起, 女秘书在处理公文时很少出错了。一位朋友知道了这件事后, 便问柯立芝:“这个方法很妙, 你是怎么想出的?”柯立芝得意洋洋地说:“这很简单, 你看见过理发师给人刮胡子吗?他要先给人涂些肥皂水, 为什么呀, 就是为了刮起来使人不觉痛。”

    36. 威尔逊法则:身教重于言教

      提出者:美国行政管理学家切克·威尔逊

      点评:领导的指导是员工克服困难的后盾。每个组织都有自己管理绩效和指导员工的方法。指导有助于个人的成长并对组织的成功产生作用。如果对员工的指导很出色,绩效管理就转变成为一个协作的过程,这个过程可以让每一个人受益。

      麦当劳快餐店创始人雷·克罗克是美国社会最有影响的十大企业家之一。他不喜欢整天坐在办公室里,而是大部分工作时间都用在"走动管理上",即到所有分公司部门走走、看看、听听、问问,随时准备帮助下属解决工作中遇到的问题。。

      最先创造"走动式管理"模式的惠普公司,为推动部门负责人深入基层,又创造了一种独特的"周游式管理办法"。为达此目的,惠普公司的办公室布局采用美国少见的"敞开式大房间",即全体人员都在一间敞厅中办公,各部门之间只有矮屏分隔,除少量会议室、会客室外,无论哪级领导都不设单独的办公室。这样,哪里有问题需要解决,部门负责人就能以最快的速度赶到现场,带领自己的员工以最快的速度解决问题。正是这些保证了惠普公司对问题的快速反应能力和解决能力,并成就了它的辉煌。

      通用电气公司的韦尔奇也是一位专注于带领部下解决问题的优秀管理者。

    37. 麦克莱兰定律:让员工有参加决策的权力

      提出者: 哈佛大学教授戴维.麦克莱兰(David McClelland)

      点  评:麦克莱兰经过大量深入研究发现从根本上影响个人绩效的并非人们通常所认为的是智商、技能或经验,而是诸如“成就动机”、“人际理解”、“团队影响力”等一些可被称为资质的东西。1973年,麦克莱兰教授发表了题为《测量资质而非智力》的文章。

      成就需要理论:成就的需要是权利的需要、归属的需要、等等需要中的一个重要的需要。

      必要的时候,为自己的员工贴上一个权力的标签,可以极大地提升他们的工作热情与主人翁意识,而且它所产生的效果许多时候是其他激励方式所不及的。

    38. 蓝柏格定理:为员工制造必要的危机感没有压力便没有动力。

      提出者:美国银行家路易斯·B·蓝柏格

      点  评:压力只有在能承受它的人那里才会化为动力。

      一天一头驴子,不小心掉进一口枯井里,农夫绞尽脑汁想办法救出驴子,但几个小时过去了,驴子还是在井里痛苦地哀嚎着。最后,这位农夫决定放弃。于是他便请来左邻右舍帮忙一起将井中的驴子埋了,以免除它的痛苦。农夫的邻居们人手一把铲子,开始将泥土铲进枯井中。当这头驴子了解到自己的处境时,刚开始哭得很凄惨。但出人意料的是,一会儿之后这头驴子就安静下来了。农夫好奇地探头往井底一看,出现在眼前的景象令他大吃一惊:当铲进井里的泥土落在驴子的背部时,驴子的反应令人称奇──它将泥土抖落在一旁,然后站到铲进的泥土堆上面!

      就这样,驴子将大家铲在它身上的泥土全数抖落在井底,然后再站上去。很快地,这只驴子便上升到了井口,然后在众人惊讶的表情中快步地跑开了!

      就如驴子的情况,在生命的旅程中,有时候我们难免会陷入"枯井"里,会被各式各样的"泥沙"倾倒在我们身上,而想要从这些"枯井"脱困的秘诀就是:将"泥沙"抖落掉,然后站到上面去!

      对一个企业的发展来说,压力的促进作用尤为明显。对于一个成功者来说,压力越大,动力越大。

    39. 赫勒法则:有效监督,调动员工的积极性

      提出者:英国管理学家H·赫勒

      点  评:当人们知道自己的工作成绩有人检查的时候会加倍努力。没有有效的监督,就没有工作的动力。

      从本质上来说,人都是有惰性的。管理之成为必要,一部分原因也就在此。管理的主体是人,客体也是人,要真正达到调动员工的工作热情,提高员工的工作积极性,就要良好地运用起你手中的激励和监督机制,调动好你的指挥棒。

      企业不仅要建立起科学有效的激励机制,还必须要进行科学的实施和管理,监督各项工作的顺利进行。有效的激励机制能大大加强员工的工作主动性和热情。但光有激励是不够的,建立一个有效的监督机制。

      美国著名快餐大王肯德基国际公司的连锁店遍布全球60多个国家和地区,总数多达9900多个。然而,肯德基国际公司在万里之外,又怎么能相信它的下属能循规蹈矩呢?

      有一次,上海肯德基有限公司收到3份国际公司寄来的鉴定书,对他们外滩快餐厅的工作质量分3次进行了鉴定评分,分别为83、85、88分。公司中外方经理都为之瞠目结舌,这3个分数是怎么评定的?

      原来,肯德基国际公司雇佣、培训了一批人,让他们佯装顾客、秘密潜入店内进行检查评分。这些“神秘顾客”来无影、去无踪,而且没有时间规律,这就使快餐厅的经理、雇员时时感受到某种压力,丝毫不敢懈怠。正是通过这种方式,肯德基在最广泛了解到基层实际情况的同时,有效地实行了对员工的工作监督,从而大大提高了他们的工作效率。

    40. 激励倍增法则:利用赞美激励员工

      员工从管理者的赞美中所得到的要远远大于管理者的付出。学会使用激励的杠杆,就会明白做人和管理的真谛。

    41. 倒金字塔管理法则:赋予员工权利

      “倒金字塔管理法”能激发员工的工作热情。员工一旦受到信任与重视,就会为企业发展提出好的建议,就会使自己甚至使整个企业的工作效率大大提高。

    42. 古狄逊定理:不做一个被累坏的主管

      提出者:英国证券交易所前主管N·古狄逊

      点评:一个累坏了的管理者,是一个最差劲的管理者。管理是让别人干活的艺术。

      在现实生活中,我们会发现有不少管理者常常忙得焦头烂额,恨不得一天有48小时可用;或者常常觉得需要员工的帮忙,但是又怕他们做不好,以致最后事情都往自己身上揽。虽然一个称职的管理者最好是一个“万事通”,但一个能力很强的人并不一定能管理好一家企业。管理的真谛不是要管理者自己来做事,而是要管理者管理别人做事。

      管理者要做的也不是自己亲自处理困难的工作,而是去发现能干的人去做这些事。而要做到这一点,一方面是给下属成长的机会,增强他们的办事能力,另一方面是要懂得授权。

      企业的发展壮大不能光靠一个或几个管理者,必须依靠广大员工的积极努力,借助他们的才能和智慧,群策群力才能逐步把企业推向前进。再能干的领导,也要借助他人的智慧和能力,这是一个企业发展的最佳道路。

    第四章:沟通是管理的浓缩

      松下幸之助有句名言:“企业管理过去是沟通,现在是沟通,未来还是沟通。”管理者的真正工作就是沟通。不管到了什么时候,企业管理都离不开沟通。

    43. 霍桑效应:1)让员工将自己心中的不满发泄出来

           2)由于受到额外的关注而引起绩效或努力上升

      提出者:哈佛大学心理专家梅奥为首的研究小组

      点  评:1)社会心理学家所说的“霍桑效应”也就是所谓“宣泄效应”。霍桑工厂是美国西部电器公司的一家分厂。为了提高工作效率,这个厂请来包括心理学家在内的各种专家,在约两年的时间内找工人谈话两万余人次,耐心听取工人对管理的意见和抱怨,让他们尽情地宣泄出来。结果,霍桑厂的工作效率大大提高。这种奇妙的现象就被称作“霍桑效应”。

          2)1924年11月,以哈佛大学心理专家梅奥为首的研究小组进驻西屋(威斯汀豪斯)电气公司的霍桑工厂,他们的初衷是试图通过改善工作条件与环境等外在因素,找到提高劳动生产率的途径。他们选定了继电器车间的六名女工作为观察对象。在七个阶段的试验中,支持人不断改变照明、工资、休息时间、午餐、环境等因素,希望能发现这些因素和生产率的关系——这是传统管理理论所坚持的观点。但是很遗憾,不管外在因素怎么改变,试验组的生产来效率一直上升。

          历时九年的实验和研究,学者们终于意识到了人不仅仅受到外在因素的刺激,更有自身主观上的激励,更有自身主观上的激励,从而诞生了管理行为理论。就霍桑试验本身来看,当这六个女工被抽出来成为一组的时候,她们就意识到了自己是特殊的群体,是试验的对象,这些专家一直关心的对象,是这些专家一直关心的对象,这种受注意的感觉使得她们加倍努力工作,以证明自己是优秀的,是值得关注的。

           有一所国外的学校,在入学的时候会对每个学生进行智力测试,以智力测验的结果将学生分为优秀班和普通班。结果有一次在例行检查时发现,一年之前入学的一批学生的测验结果由于某种失误被颠倒了,也就是说现在的优秀班其实是普通的孩子,而真正聪明的孩子却在普通班。但是这一年的课程成绩却如同往年一样,优秀班明显高于普通班,并未出现异常。原本普通的孩子被当作优等生关注,他们自己也就认为自己是优秀的,额外的关注加上心理暗示使得丑小鸭真的成了白天鹅。

    44. 杰亨利法则:运用坦率真诚的沟通方式

      在企业里,人际的沟通是无可避免的,沟通问题也同样无可避免,开放、真诚、坦率是人际关系中的重要元素,是促进沟通渠道畅通的有效保证。

    45. 沟通的位差效应:平等交流是企业有效沟通的保证

      提出者:美国加利福尼亚州立大学

      点  评:沟通的位差效应是美国加利福尼亚州立大学对企业内部沟通进行研究后得出的重要成果。他们发现,来自领导层的信息只有20%-25%被下级知道并正确理解,而从下到上反馈的信息则不超过10%,平行交流的效率则可达到90%以上。

      进一步的研究发现,平行交流的效率之所以如此之高,是因为平行交流是一种以平等为基础的交流。为试验平等交流在企业内部实施的可行性,他们试着在整个企业内部建立一种平等沟通的机制。结果发现,与建立这种机制前相比,在企业内建立平等的沟通渠道,可以大大增加领导者与下属之间的协调沟通能力,使他们在价值观、道德观、经营哲学等方面很快地达成一致;可以使上下级之间、各个部门之间的信息形成较为对称的流动,业务流、信息流、制度流也更为通畅,信息在执行过程中发生变形的情况也会大大减少。他们得出了一个结论:平等交流是企业有效沟通的保证。

    46. 威尔德定理:有效的沟通始于倾听

      提出者:英国管理学家L.威尔德

      点评:说的功夫有一半在听上。一问一答之间就可以受益无穷。在企业内部,倾听是管理者与员工沟通的基础。但在现实中很多人并没有真正掌握“听”的艺术。

    47. 踢猫效应:不对下属发泄自己的不满

      点评:是人与人之间的泄愤连锁反应。

      某公司董事长为了重整公司一切事务,许诺自己将早到晚回。事出突然,有一次,他看报看得太入迷以至忘了时间,为了不迟到,他在公路上超速驾驶,结果被警察开了罚单,最后还是误了时间。这位老董愤怒之极,回到办公室时,为了转移别人的主意,他将销售经理叫到办公室训斥一番。销售经理挨训之后,气急败坏地走出老董办公室,将秘书叫到自己的办公室并对他挑剔一番。秘书无缘无故被人挑剔,自然是一肚子气,就故意找接线员的茬。接线员无可奈何垂头丧气何地回到家,对着自己的儿子大发雷霆。儿子莫名其妙地被父亲痛斥之后,也很恼火,便将自己家里的猫狠狠地踢了一脚。

    48. 雷鲍夫法则:认识自己和尊重他人

      提出者:美国管理学家雷鲍夫。

      点评:在你着手建立合作和信任时要牢记我们语言中经常使用“我承认我犯过错误 / 你干了一件好事 / 你的看法如何 / 咱们一起干 / 不妨试试 / 谢谢您 / 咱们 / 您。”它会让你事半功倍。

    49. 特里法则:坦率地承认自己的错误。承认错误是一个人最大的力量源泉。

      提出者:美国田纳西银行前总经理L·特里

      点评:正视错误,你会得到错误以外的东西。

      谁都难免会犯一些错误。当我们犯错误的时候,脑子里往往会出现想隐瞒自己错误的想法,害怕承认之后会很没面子。其实,承认错误并不是什丢脸的事。反之,在某种意义上,它还是一种具有"英雄色彩"的行为。因为错误承认得越及时,就越容易得到改正和补救。而且,由自己主动认错也比别人提出批评后再认错更能得到别人的谅解。更何况一次错误并不会毁掉你今后的道路,真正会阻碍的,是那不愿承担责任,不愿改正错误的态度。

      勇于承认错误和失败也是企业生存的法则。市场不是两军对垒的战场,企业不是军队。承认失败,企业可以避免更大的市场损失,可以重新调整自己的市场策略,也就可以重新取得市场机会。

    第五章:崇尚团队合作精神

      比尔·盖茨说:“团队合作是企业成功的保证,不重视团队合作的企业是无法取得成功的。”建设一支有凝聚力的团队,已是现代企业生存发展的一个基本条件。

     50. 华盛顿合作定律:团队合作不是人力的简单相加

       点  评:1964年3月凌晨3点的时候,在纽约一位年轻的酒吧女经理被一个杀人狂杀死。作案时间长达半个小时,附近有38人看到或听到女经理被刺的情况和呼救声,但没有一个人出来保护她,也没有一个人及时给警察打电话。

      事后,美国大小媒体同声谴责纽约人的异化与冷漠。然而,两位年轻的心理学家——巴利与拉塔内并没有认同这些说法。他们专门为此进行了一项试验。

      他们寻找了72名不知真相的参与者与一名假扮的癫痫病患者参加试验,让他们以一对一或四对一两种方式,保持远距离联系,相互间只使用对讲机通话。事后的统计数据出现了很有意思的一幕:在交谈过程中,当假病人大呼救命时,在一对一通话的那组,有85%的人冲出工作间去报告有人发病;而在四个人同时听到假病人呼救的那组,只有31%的人采取了行动!

      两位心理学家把它叫做“旁观者介入紧急事态的社会抑制”,更简单地说,就是“旁观者效应”。他们认为:在出现紧急情况时,正是因为有其他的目击者在场,才使得每一位旁观者都无动于衷,旁观者可能更多的是在看其他观察者的反应。

      这种现象产生的原因之一,正在于“旁观者效应”,与人们一般以为的世态炎凉之类的社会氛围或看客的冷漠等集体性格缺陷没有太大关系。

      如果把这当作一次合作,那么合作失败的最根本原因就在于“旁观者效应”,众多的旁观者分散了每个人应该负有的解救责任。因此,社会学家认为责任不清是华盛顿定律产生的最主要原因。

       人与人的合作,不是人力的简单相加,而是要复杂和微妙得多。在这种合作中,假定每个人的能力都为1,那么,10个人的合作结果有时比10大得多,有时,甚至比1还要小。因为人不是静止物,而更像方向各异的能量,相互推动时,自然事半功倍;相互抵触时,则一事无成。

          我们对合作研究得不多,最直观的反映就是,目前的大多数管理制度和行为都是致力于减少人力的无谓消耗,而非利用组织提高人的效能。换言之,不妨说管理的主要目的不是让每个人做到最好,而是避免内耗过多!

       对一个组织来说,进行详细的职务设计是绝对必要的,只有让每个人都知道自己该做什么,才能遏制“华盛顿合作现象”的发生。

     

  • IT人和管理者的最大分别

    2008-07-04 16:36:56

    有一个迷路的人正向对面走来的一位路人问路道:“对不起!请问这儿是哪里?”
      “你现在正在一条分岔路上,”路人说。
      “先生,我猜你一定是从事IT行业的。”迷路人道。
      “对啊!你为什么会知道?”
      “因为你给我的答复很技术性,但完全没有用?”
      “先生,我也猜猜你的职业吧!你一定是做管理的。”路人说。
      “对呀!你为什么也能知道?”
      “因为你不知自己在哪?也不知自己应往哪儿走,但你却希望我帮你解决问题,你现在的处境和先前没有两样,但责任已归咎在我身上!”
  • 微软五大经典经营之道

    2008-07-04 16:23:00


      (1)公司支持人人平等

    资深人员基本上没有“特权”,依然要自己回电子邮件,自己倒咖啡,自己找停车位,每个人的办公室基本上都一样大。有一次,一些从中国来访微软的教授在等待听JimGray(发明数据库的著名科学家,图灵奖的获得者,加州研究院的院长)的演讲时,看见一个满头华发的老头趴在地上接电线,还以为他只是一名老工人。等他站起来时,大家却惊讶地发现,他就是演讲者JimGray。这些教授都很震惊,没想到连Jim这样的人都亲自动手接线装电脑。微软就是这样一个崇尚技术、人人平等的公司。

    (2)公司主张施行“开门政策”

    也就是说,任何人可以找任何人谈任何话题,当然任何人也都可以发电子邮件给任何人。一次,有一个新的员工开车上班时撞了比尔·盖茨停着的新车。她吓得问老板怎么办,老板说:“你发一封电子邮件道歉就是了。”她发出电子邮件后,在一小时之内,比尔不但回信告诉她,别担心,只要没伤到人就好,还对她加入公司表示欢迎。

    一个平等的公司可以降低公司内部的信息阻塞,增加所有员工的主人翁精神,还能更早地发现公司在发展中遇到的问题。平等的公司可以说是微软发展的必备平台。

    (3)自我批评、追求卓越

    微软文化的一大特色就是自我批评。在科技呈指数趋势飞跃发展的今天,不愿意批评自己,不承认自己的错误,不追求卓越的公司将面临灭亡。

    一个刚加入微软的市场经理,代表产品去参加一个商品展。回来后,他兴高采烈地发了一封电子邮件给整个产品小组。他说:“我很高兴地告诉大家,我们在这个展览获得了令人振奋的成绩。十项大奖中我们囊括了九项。让我们去庆祝吧!”但是,他没想到,在一个小时内,他收到了十多封回信。大家问他:“没得到的是哪一个奖?为什么不告诉我们?为什么没得到那个奖?我们得到什么教训?明年怎么样才能得到这第十个奖?”他告诉我,在那一刻,他才理解了微软为什么会成功。

    自我批评在公司早已被系统化。每一个产品推出后,会有一段特别时间空出来给产品团队做“post-mortem”,也就是系统化的“自我批评”。所有小组成员都会被询问,什么地方可以做得更好,每一个动作和决定都会被分析,结果将在公司公布,以帮助别的小组避免同样的问题,让公司的项目能越做越好。

    比尔·盖茨鼓励员工畅所欲言,对公司的发展、存在的问题,甚至上司的缺点,毫无保留地提出批评、建议或提案。他说:“如果人人都能提出建议,就说明人人都在关心公司,公司才会有前途。”微软开发了满意度调查软件,每年至少做一次员工满意度调查,让员工以匿名的方式对公司、领导、老板等各方面作回馈。其中有选择题(例如:“我对我的副总裁有信心。以下选一:非常同意、同意、无意见、不同意、非常不同意),也有问答题(例如:你对公司战略有什么建议?)。每个经理都会得到多方面的回馈和客观的打分。比尔、史蒂夫、其他高层领导和人事室都会仔细地研究每个组和经理的结果,计划如何改进。

    除了自我批评,还要有能接受别人批评的胸怀,和改变自己的魄力。

    1995年,当比尔·盖茨宣布不涉足Internet领域产品的时候,很多员工提出了反对意见。其中,有几位员工直接发信给比尔说,你这是一个错误的决定。当比尔·盖茨发现有许多他尊敬的人持反对的意见时,又花了更多的时间与这些员工见面,最后写出了《互联网浪潮》这篇文章,承认了自己的过错,扭转了公司的发展方向。同时,他把许多优秀的员工调到Internet部门,并取消或削减了许多产品,以便把资源调入Internet部门。当时,有些员工在某一天上班时,老板会告诉他:“我们的产品被取消了,因为公司需要我们做更重要的IE浏览器。明天起,我们整个部门将加入Internet部门。”那些批评比尔·盖茨的人不但没有受处分,而且得到重用,今天都成了公司重要部门的领导。在软件这个市场变化迅速的领域,调整企业方向对微软无比重要。从这个例子里我们看到的是:平等的环境、直接的沟通、宽大的胸怀、宏大的魄力拯救了公司。

    (4)责任至上、善始善终

    公司和领导者有了关注的目标之后,还要有足够的责任心,才能把事情做好。微软公司要求每一个部门、每一个员工都要有自己明确的目标,同时,这些目标必须是“SMART”的,也就是:

    。S–Specific(特定的、范围明确的,而不是宽泛的)

    。M–Measurable(可以度量的,不是模糊的)

    。A–Attainable(可实现的,不是理想化的)

    。R–Result-based(基于结果而非行为或过程)

    。T–Time-based(有时间限制,而不是遥遥无期的)

    只有每个人都拥有了明确的目标,并可以随时检查自己是否达到了预先设定的目标,公司员工才能在工作中体现出强烈的责任感和工作热情。

    微软公司要求部门和员工制定的目标必须是可分享的,即,每个人都应当通过某种渠道,如公司的内部网站等将自己的目标公布出来(当然,某些需要保密的工作目标除外)。这样,当某位员工对领导或其他员工的工作方式不理解的时候,就可以去查看对方的工作目标,以寻求最好的沟通和理解。

    除了针对目标、结果的负责,公司更需要在决策方面有负责的框架。微软的“决策制定框架”下,每一项重要决策都有一定的制定流程和人员角色划分。每一个决策流程的推动人很自然地就是决策的责任人。对该决策有支持和认可权利的人是决策的审批者。对该决策进行核查、提出支持或反对意见的人是决策的复核者。在整个决策流程中,虽然复核者可提出反对意见,但审批者仍拥有决策的最终决定权。有了这样的框架,公司的决策流程更加清晰,人员责任更加明确,决策不会被轻易拖延或推翻,决策的效率也大大提高了。

    (5)虚怀若谷、服务客户

    微软公司对技术相当重视,对合作伙伴和客户也同样重视。作为软件平台公司,合作伙伴和客户都是公司的命脉。微软公司在价值观中强调,所有员工都要信守对客户和合作伙伴的承诺,而且在产品研发过程中,不仅要考虑到产品的技术特性,还更要关注客户和合作伙伴最需要的功能。

    微软的大企业产品部鼓励每一个员工在加入公司的前几个星期到技术支持中心工作,帮助客户解决问题。无论一位员工的资历有多深,公司都希望他经过最基层技术支持工作的锻炼,能理解客户的困难。在大企业产品部的近一万名员工如果以前没有做过技术支持工作,在公司就没有晋升过某一级别的机会。

    除了要求员工悉心聆听客户意见之外,微软的软件也会自动收集客户的反馈意见。多年前,当Office开发者无法决定该把哪些功能放进常用工具栏时,Office的程序员制作了一套特别的Office软件。这套Office在用户允许的情况下,记录用户最常用的功能,传送到微软。最后,借助这些统计数据,开发者就可以决定什么样的用户界面才会对大多数用户有利。今天,微软把这个技术做进了所有的产品。任何微软的软件碰到问题(如宕机)时会搜集数据,并在用户的允许下经过网络把这些数据传到总部的服务器,以帮助开发人员诊断和测试软件。有了这样的技术,WindowsXP推出一个月后,微软就把用户碰到的一半问题都解决了,然后再通过网络自动帮助合所有法用户升级软件。此类工作集中体现了公司的创新精神以及借助软件技术解决问题的目标,当然也体现了公司悉心聆听客户意见的决心。
     

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

    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. 每条错误报告只包括一个错误

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

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

  • BS系统大家谈(个人经验)续记!

    2008-07-04 14:06:20

    20.换版本时,要检查要更新的文件都更新完成;

    21.重复点击;

    22.某一段时期出现的错误;

    23系统链接页面没有响应时,退出系统后,不断打开多开多个页面;

    24.光标落在节点上才能新增;(类似:工具栏什么状态下才能用到该按钮;)

    25.操作时要注意自己操作的环境,有时出现错误后,不一定立刻能弄明白错误出现的原因;

    26.有条件的话可将自己测试的系统和其他测试人员调换来测试,这样的效果往往能发现自己不能发现
    的错误,提高效率;

    27.两个操作员在成品入库中选择相同的客户的同一张生产单号时,数据重复录入;

    28.两个操作员在同一单据上修改数据;

    29.多界面,不是对应关系,二对多,就会出现报错;

    30.点击节点不能打开,之前操作了紧缩节点;

    31.通过一段时间测试后,了解系统的一些架构和业务知识,对系统设计能提出自己的见解;

    32.列出可能的状态或者不同的出错情况,进行用例测试;

    35.过程哪些地方用到?检测规则哪些单据用到?表或者单据之间的依赖关系;

    36.一个出错现象,可能模拟出来的情况不止一种;(使用者会有不同的操作习惯)

    37.数据几时保存到数据库表中,什么状态能保存;修改时,什么状态能修正数据记录;

    38.整理自己的测试内容,测试的环境,测试的步骤,测试过的测试点,提交测试报告及问题,
    并能重现测试到的问题;不能重现的做好记录,多次操作或者做一些测试用例,或者请教下
    开发人员,尽量了解有关的信息;

    39.尽量拓展自己的思维,想得到比不停测试轻松很多,不要怕思考,尽量设计多的有用用例,
    并作好记录,可重复利用;因为你已经分析问题的发生是由哪些问题造成的,就可以先排除
    一些原因,并尽可能地让开发人员解决目前所发现的问题;

    40.产品结存数太依赖单据或者没有仓库作记录,且一个产品有两个数为标准时,结存数要两个数
    也要正确也不好把握;

    41.审核时单据不时点击的那条记录,或者审核后跳到另一条记录中;

    42.有条件或者有可能都尽可能返回到出错之前的操作环境;

    43.有时开发人员或者其他人员的一段话会触动自己测试的灵感,而开发人员却不知道自己
    程序问题所在,如果能捕捉得到,自己测试出来的问题也更有意义;

    ---说明:很随意写,可以激发自己的一些灵感;有些可能重复,没有整理,只不过每天有时间收集
    一些经验罢了!

  • 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)

  • web应用程序测试方法和测试技术详述

    2008-06-26 15:30:01

    web应用程序测试方法和测试技术详述

    1. 概述

    随着web应用的增多,新的模式解决方案中以web为核心的应用也越来越多, 很多公司各种应用的架构都以B/Sweb应用为主,但是有关WEB测试方面的内容并没有相应的总结,所以我在这里对web的测试方法和采用的测试技术进行总结,便于内部交流。

    测试方法尽量涵盖web程序的各个方面,测试技术方面在继承传统测试技术的技术上结合web应用的特点。

    l 相关的测试和实现技术也有着很大的关系,由于本公司使用J2EE体系,也许例子中只有JAVA平台可以使用,.NET平台测试技术暂时不涉及,如果你有请与我联系。

    2. 测试方法

    说明:测试方法的选择取决你的测试策略。

    一般的web测试和以往的应用程序的测试的侧重点不完全相同,基本包括以下几个方面。

    当然圆满的完成测试还要有好的团体和流程等的方方面面的支持,你同样应该对这些方面进行注意。

    有些测试方法设计到了流程,哪些应该在你的测试团队建设中建立。

    2.1 界面测试

    现在一般人都有使用浏览器浏览网页的经历,用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试,那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分,但是恰恰相反界面对不懂技术的客户来说那相当关键,慢慢体会你会明白的。

    方法上可以根据设计文档,如果够专业的话可以专业美工人员,来确定整体风格页面风格,然后根据这个可以页面人员可以生成静态的HTMLCSS等甚至生成几套不用的方案来讨论,或者交给客户评审,最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格,那样可能会很糟糕。

    主要包括以下几个方面的内容:

    Ø 站点地图和导航条 位置、是否合理、是否可以导航等内容布局 布局是否合理,滚动条等简介说明 说明文字是否合理,位置,是否正确;

    Ø 背景/色调 是否正确、美观,是否符合用户需求;

    Ø 页面在窗口中的显示是否正确、美观(在调整浏览器窗口大小时,屏幕刷新是否正确)表单样式 大小,格式,是否对提交数据进行验证(如果在页面部分进行验证的话)等;

    Ø 连接 连接的形式,位置,是否易于理解等。

    web测试的主要页面元素

    Ø 页面元素的容错性列表(如输入框、时间列表或日历);

    Ø 页面元素清单(为实现功能,是否将所需要的元素全部都列出来了,如按钮、单选框、复选框、列表框、超连接、输入框等等);

    Ø 页面元素的容错性是否存在;

    Ø 页面元素的容错性是否正确;

    Ø 页面元素基本功能是否实现(如文字特效、动画特效、按钮、超连接);

    Ø 页面元素的外形、摆放位置(如按钮、列表框、核选框、输入框、超连接等);

    Ø 页面元素是否显示正确(主要针对文字、图形、签章);

    Ø 元素是否显示(元素是否存在);

    Ø 页面元素清单(为实现功能,是否将所需要的元素全部都列出来了,如按钮、单选框、复选框、列表框、超连接、输入框等等)。

    测试技术

    Ø 通过页面走查,浏览确定使用的页面是否符合需求。可以结合兼容性测试对不用分辨率下页面显示效果,如果有影响应该交给设计人员提出解决方案;

    Ø 可以结合数据定义文档查看表单项的内容,长度等信息;

    Ø 对于动态生成的页面最好也能进行浏览查看。如Servelet部分可以结合编码规范,进行代码走查。是否支持中文,如果数据用XML封装要做的工作会多一点等等。

    2.1.l 界面测试要素:

    符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性

    2.1.l.1 直观性:

    Ø 用户界面是否洁净,不唐突,不拥挤.界面不应该为用户制造障碍.所需功能或者期待的响应应该明显,并在预期出现的地方;

    Ø 界面组织和布局合理吗?是否允许用户轻松地从一个功能转到另一个功能?下一步做什么明显吗?任何时刻都可以决定放弃或者退回,退出吗?输入得到承认了吗?菜单或者窗口是否深藏不露?

    Ø 有多余功能吗?软件整体抑或局部是否做得太多?是否有太多特性把工作复杂化了?是否感到信息太庞杂?

    Ø 如果其他所有努力失败,帮助系统真能帮忙吗?

     

    2.1.l.2 一致性

    Ø 快速键和菜单选项.Windows 中按F1键总是得到帮助信息;

    Ø 术语和命令.整个软件使用同样的术语吗?特性命名一致吗?例如,Find是否一直叫Find,而不是有时叫Search?

    Ø 软件是否一直面向同一级别用户?带有花哨用户界面的趣味贺卡程序不应该显示泄露技术机密的错误提示信息;

    Ø 按钮位置和等价的按键.大家是否注意到对话框有OK按钮和Cancle按钮时,OK按钮总是在上方或者左方,Cancle按钮总是在下方或右方?同样原因,Cancle按钮的等价按键通常是Esc,而选中按钮的等价按钮通常是Enter.保持一致。

     

    2.1.l.3 灵活性

    Ø 状态跳转:灵活的软件实现同一任务有多种选择方式;

    Ø 状态终止和跳过:具有容错处理能力;

    Ø 数据输入和输出:用户希望有多种方法输入数据和查看结果.例如,在写字板插入文字可用键盘输入,粘贴,6种文件格式读入,作为对象插入,或者用鼠标从其他程序拖动。

     

    2.1.l.4 舒适性

    Ø 恰当:软件外观和感觉应该与所做的工作和使用者相符;

    Ø 错误处理:程序应该在用户执行严重错误的操作之前提出警告,并允许用户恢复由于错误操作导致丢失的数据,如大家认为undo /redo是当然的;

    Ø 性能:快不见得是好事,要让用户看得清程序在做什么,它是有反应的。

     

    2.2 功能测试

    功能测试是测试中的重点,主要包括一下几个方面的内容:

    Ø 连接:这个连接和界面测试中的连接不同。那里注重的是连接方式和位置,如是图像还是文字放置的位置等,还是其他的方式;这里的连接注重功能,如是否有连接,连接的是否是说明的位置等;

    Ø 表单提交:应当模拟用户提交,验证是否完成功能,如注册信息,要测试这些程序,需要验证服务器能正确保存这些数据,而且后台运行的程序能正确解释和使用这些信息。还有数据正确性验证,异常处理等,最好结合易用性要求等。B/S结构实现的功能可能主要的就在这里,提交数据,处理数据等如果有固定的操作流程可以考虑自动化测试工具的录制功能,编写可重复使用的脚本代码,可以在测试、回归测试时运行以便减轻测试人员工作量;

    Ø Cookies 验证:如果系统使用了cookie,测试人员需要对它们进行检测。如果在 cookies 中保存了注册信息,请确认该 cookie能够正常工作而且已对这些信息已经加密。如果使用 cookie 来统计次数,需要验证次数累计正确。关于cookie的使用可以参考浏览器的帮助信息。如果使用B/S结构cookies中存放的信息更多;

    Ø  功能易用性测试 完成了功能测试可以对应用性进行了解,最好听听客户的反映,在可以的情况下对程序进行改进是很有必要的,和客户保持互动对系统满意度也是很有帮助的。

    2. 2.1 测试技术

    功能测试的测试技术可是很多的,我们可以结合实际环境选择使用。

    Ø 白盒测试技术(White Box Testing) 深入到代码一级的测试,使用这种技术发现问题最早,效果也是最好的。该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主,在JAVA平台使用Xunit系列工具进行测试,Xunit测试工具是类一级的测试工具对每一个类和该类的方法进行测试。

    Ø 黑盒测试技术(Black Box Testing):黑盒测试的内容主要有以下几个方面,但是主要还是功能部分。主要是覆盖全部的功能,可以结合兼容,性能测试等方面进行,根据软件需求,设计文档,模拟客户场景随系统进行实际的测试,这种测试技术是使用最多的测试技术涵盖了测试的方方面面,可以考虑以下方面

     正确性 (Correctness):计算结果,命名等方面。

     可用性 (Usability):是否可以满足软件的需求说明。

     边界条件 (Boundary Condition):输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等。

     性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间在可以接受范围内。J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了。如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。因此在产品开发的开始阶段,就要考虑到软件的性能问题

     压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行。如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况,如果有必要可以模拟大量数据输入,对硬盘的影响等等信息。如果有必要的话必须进行性能优化(软硬件都可以)。这里的压力测试针对的是某几项功能。

     错误恢复 (Error Recovery):错误处理,页面数据验证,包括突然间断电,输入脏数据等。

     安全性测试(Security):这个领域正在研究中,防火墙、补丁包、杀毒软件等的就不必说了,不过可以考虑。破坏性测试时任意看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件时的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容。

     兼容性 (Compatibility):不同浏览器,不同应用程序版本在实现功能时的表现不同的上网方式,如果你测试的是一个公共网站的话。

    兼容性测试内容详述:

    Ø 硬件平台

    Ø 浏览器软件和版本:浏览器插件,浏览器选项,视频分辨率和色深,文字大小,调制解调器速率.

     软件配置 (Configuration):如IE浏览器的不用选项-安全设定最高,禁用脚本程序等等,你们的程序在各种不用的设置下表现如何。

    2. 2.2 单元测试技术(Unit Test):

    2. 2.2.1 下面是对白盒测试和单元测试的区别的论述:

    单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能,他们都需要代码支持,但是级别不同。白盒测试关注的是类中一个方法的功能,是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要写驱动和稳定桩,比如查询单元是一个查询包,包括N多的测试类、测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等,是比类大的一个整体进行的。

    另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试。

    不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分。不过要看你对质量的关注程度来决定。

    2. 2.2.2 功能测试边界测试\越界测试技术详述

    Ø 边界条件

    边界条件是指软件计划的操作界限所在的边缘条件,如果软件测试问题包含确定的边界,那么数据类型可能是:数值、速度、字符、地址、位置、尺寸、数量。同时,考虑这些类型的下述特征:第一个/最后一个、最小值/最大值、开始/完成、超过/在内、空/满、最短/最长、最慢/最快、最早/最迟、最大/最小、最高/最低、相邻/最远。

    Ø 越界测试

    通常是简单加1或者很小的数(对于最大值)和减少1或者很小的数(对于最小值),例如:第一个减1/最后一个加1、开始减1/完成加1、空了再减/满了再加、慢上加慢/快上加快、最大数加1/最小数减1、最小值减1/最大值加1、刚好超过/刚好在内、短了再短/长了再长、早了更早/晚了更晚、最高加1/最低减1

    另一些该注意的输入:默认,空白,空值,

  • 有效编写软件的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的人需要通知相关人员基线已经形成,并且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.

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

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

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

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

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

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

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

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

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

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

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

          使用

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

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

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

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

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

  • 软件测试工作需掌握的Linux的快捷键和主要命令

    2008-06-25 16:17:42

    Linux基本的键盘输入快捷键和一些常用命令-
    <Ctrl><Alt><F1>
    切换到第一个文本终端。在Linux下你可以有多达六个不同的终端。这个命令的意思是:“同时按住<Ctrl>键和<Alt>键,然后按<F1>键,再释放所有的键”。

    <Ctrl><Alt><Fn> (n=1..6)

    切换到第n个文本终端。(你也可以使用不是很经常用到的命令chvt n 来实现,n指的是第n个文本终端)。在文本终端下(不是在X窗口),你也可以简单使用<ALT><Fn>来实现切换,不需要<CTRL>键。

    打印出你正在使用的终端名称,如果你希望知道终端的名字,可以使用命令fgconsole。

    <Ctrl><Alt><F7>

    切换到第一个图形用户界面(一般来说X-window在第七个终端)

    <Ctrl><Alt><Fn> (n=7到12)

    切换到第n个图形用户街面。根据缺省,第一个X-Window在第7个终端运行,从第8到第12什么也没有,当然你可以逐个启动这些图形用户界面。

    <Tab>

    (在文本终端下)可以使用TAB自动完成命令,或者显示所有的可选项。这个快捷键真的非常好用,经常使用你会发觉它可以节约你很多的时间。

    <ArrowUp>

    (在文本终端或者X窗口下)滚动和编辑以前输入的命令。按<ENTER>执行一个历史命令

    <ArrowDown>

    回滚

    <Shift><PgUp>

    滚动终端输出。对于登录提示也起作用,所以你可以使用它回滚启动信息。你显卡的内存大小决定你可以回滚多少内容

    <Shift><PgDown>

    回滚终端输出

    <Ctrl><Alt><+>

    (在X窗口下) 改变X服务器的屏幕解析率 (如果你设置X服务器有多个不同的屏幕解析率)。比如对于我的标准SVGA卡和显示器,在文件/etc/X11/XF86Config有以下的设置行: (从缺省开始,到可以支持的最大虚拟屏幕解析率)

    Modes "1024x768" "800x600" "640x480" "512x384" "480x300" "400x300" "1152x864"Z

    当然,首先我必须设置我的X服务器,可以使用using Xconfigurator, xf86config, 也可以手工编辑文件:/etc/X11/XF86Config。XFdrake (Mandrake使用图形用户界面进行配置 )。你也可以参考命令xvidtune和xvidgen。

    <Ctrl><Alt><->

    (在X窗口下)把X服务器的屏幕解析率修改到上一次的设置。

    <Ctrl><Alt><Esc>

    (在X窗口,KDE下)关闭我鼠标将要指向的窗口(鼠标的光标形状会有所改变)。同样的效果也可以使用命令xkill(在X终端上)来实现。当一个程序窗口被挂住的时候特别有用。

    <Ctrl><Alt><BkSpc>

    (在X窗口下) 终止当前的 X窗口服务。如果X窗口不能正常退出时可以使用。

    <Ctrl><Alt><Delete>

    (适用于文本终端下)关机和重新启动。这是一个在文本终端下的正常关机命令,千万不要按计算机上的reset键来重新关机和重新启动!

    <Ctrl>c

    终止当前进程(对于一般的小型文本模式的应用程序)

    <Ctrl>d

    (在一个空白的命令行上输入)退出当前的终端。参加下一个命令。

    <Ctrl>d

    给当前的进程送文件结束符合。不要按两次否则你会把自己退出系统。

    <Ctrl>s

    停止终端传输

    <Ctrl>q

    从新开始终端传输。如果你的终端突然莫名其妙的停止响应,可以参考上一条命令。

    <Ctrl>z

    把当前进程送到后台处理。

  • 自动化测试的七个步骤(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 。

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

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

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

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

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

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

  • 软件测试技术归类--您擅长哪些呢?

    2008-06-21 17:21:55

    软件测试技术归类--您擅长哪些呢?
    软件测试技术水平划分有:手动测试,自动测试,静态测试,动态测试,功能(黑盒)测试,结构(白盒)测试等.而垂直划分有很多种,并且与水平划分相交.下面是归类小结:
    1)手动测试--验收测试,随机测试,Alpha测试,Beta测试,比较测试,兼容性测试,桌面检查,端到端测试,探索测试,直方图,增量集成测试,代码审查,集成测试,JAD,负载测试,突变测试,正交矩阵测试,帕雷托分析法,性能测试,缺陷历史预测试,恢复性测试,基于风险测试,运行图,健全性测试,安全性测试,统计概况测试,压力测试,结构化走查,系统测试,单元测试,易用性测试,用户验收测试。

    2)自动测试--验收测试,基本路径测试,黑盒测试,自底向上测试,边界值测试,分支覆盖测试,分支/条件测试,因果图,比较,兼容性,条件覆盖,CRUD测试,数据库测试,决策表,端到端,等价类,异常,自由形式,灰盒测试,增量集成,集成,负载测试,突变测试,性能测试,正反测试,原型法,随机,范围测试,恢复性测试,三明治测试,健全性测试,安全性测试,状态转换,语句覆盖测试,压力,语法,系统测试,表测试,线序测试,自顶向下测试,单元测试,易用性,用户验收测试,白盒测试。

    3)静态测试--代码审查,正交矩阵测试,缺陷历史预测,基于风险的测试,运行图,统计概况测试,语法测试,单元测试。

    4)动态测试--很多了,不敲了,哪些不能动态测试的我列一下:随机,兼容性,端到端,直方图,JAD,正交矩阵,帕雷托分析,缺陷历史预测,基于风险测试,运行图,安全性,统计概况,单元测试。

    5)功能测试--也很多,有测试经验的都可以说出来,自己理解吧。

    6)结构测试--基本路径,自底向上,自顶向下,条件、分支覆盖,兼容性,数据库,桌面检查,灰盒测试,代码审查,JAD,负载,性能,恢复性,三明治测试,安全性,语句覆盖,结构化走查,表测试,线序测试,单元测试。
     

Open Toolbar