发布新日志

  • 使用svn开发，目录的约定与开发流程

    2011-07-28 14:41:31

    Subversion有一个很标准的目录结构，是这样的。
    比如项目是proj，svn地址为svn://proj/，那么标准的svn布局是
    svn://proj/
|
+-trunk
+-branches
+-tags
    这是一个标准的布局，trunk为主开发目录，branches为分支开发目录，tags为tag存档目录（不允许修改）。但是具体这几个目录应该如何使用，svn并没有明确的规范，更多的还是用户自己的习惯。

    对于这几个开发目录，一般的使用方法有两种。我更多的是从软件产品的角度出发（比如freebsd），因为互联网的开发模式是完全不一样的。
    第一种方法，使用trunk作为主要的开发目录。
    一般的，我们的所有的开发都是基于trunk进行开发，当一个版本/release开发告一段落（开发、测试、文档、制作安装程序、打包等）结束后，代码处于冻结状态（人为规定，可以通过hook来进行管理）。此时应该基于当前冻结的代码库，打tag。当下一个版本/阶段的开发任务开始，继续在trunk进行开发。
    此时，如果发现了上一个已发行版本（Released Version）有一些bug，或者一些很急迫的功能要求，而正在开发的版本（Developing Version）无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支（branch）进行开发。
    例如，刚刚发布1.0，正在开发2.0，此时要在1.0的基础上进行bug修正。
    按照时间的顺序
    1. 1.0开发完毕，代码冻结
    2. 基于已经冻结的trunk，为release1.0打tag
      此时的目录结构为
      svn://proj/
                   +trunk/  (freeze)
                   +branches/
                   +tags/
                           +tag_release_1.0　(copy from trunk)
    3. 2.0开始开发，trunk此时为2.0的开发版
    4. 发现1.0有bug，需要修改，基于1.0的tag做branch
      此时的目录结构为
      svn://proj/
                   +trunk/  ( dev 2.0 )
                   +branches/
                                 +dev_1.0_bugfix (copy from tag/release_1.0)
                   +tags/
                           +release_1.0　(copy from trunk)
    5. 在1.0 bugfix branch进行1.0 bugfix开发，在trunk进行2.0开发
    6. 在1.0 bugfix 完成之后，基于dev_1.0_bugfix的branch做release等
    7. 根据需要选择性的把dev_1.0_bugfix这个分支merge回trunk（什么时候进行这步操作，要根据具体情况）
    这是一种很标准的开发模式，很多的公司都是采用这种模式进行开发的。trunk永远是开发的主要目录。

    第二种方法，在每一个release的branch中进行各自的开发，trunk只做发布使用。
    这种开发模式当中，trunk是不承担具体开发任务的，一个版本/阶段的开发任务在开始的时候，根据已经release的版本做新的开发分支，并且基于这个分支进行开发。还是举上面的例子，这里面的时序关系是。
    1. 1.0开发，做dev1.0的branch
      此时的目录结构
      svn://proj/
                   +trunk/  (不担负开发任务 )
                   +branches/
                                 +dev_1.0 (copy from trunk)
                   +tags/
    2. 1.0开发完成，merge dev1.0到trunk
      此时的目录结构
      svn://proj/
                   +trunk/  (merge from branch dev_1.0)
                   +branches/
                                 +dev_1.0 (开发任务结束，freeze)
                   +tags/
    3. 根据trunk做1.0的tag
      此时的目录结构
      svn://proj/
                   +trunk/  (merge from branch dev_1.0)
                   +branches/
                                 +dev_1.0 (开发任务结束，freeze)
                   +tags/
                           +tag_release_1.0 (copy from trunk)
    4. 1.0开发，做dev2.0分支
      此时的目录结构
      svn://proj/
                   +trunk/  
                   +branches/
                                 +dev_1.0 (开发任务结束，freeze)
                                 +dev_2.0 （进行2.0开发）
                   +tags/
                           +tag_release_1.0 (copy from trunk)
    5. 1.0有bug，直接在dev1.0的分支上修复
      此时的目录结构
      svn://proj/
                   +trunk/  
                   +branches/
                                 +dev_1.0 (1.0bugfix)
                                 +dev_2.0 （进行2.0开发）
                   +tags/
                           +tag_release_1.0 (copy from trunk)
    6. 选择性的进行代码merge

    这其实是一种分散式的开发，当各个部分相对独立一些（功能性的），可以开多个dev的分支进行开发，这样各人/组都不会相互影响。比如dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。

    这里要注意一下的，第六步进行选择性的merge，是可以当2.0开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版本开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行测试等之后再merge回trunk。
    这两种方法各有利弊，第一种方法是可以得到一个比较纯的dev_2.0的开发分支，而第二种方法则更加的保险，因为要测试嘛。

    以上呢，就是我说的两种开发模式了，具体哪种好，并没有定论。这里大致的说一下各自的优缺点
    第一种开发模式（trunk进行主要开发，集中式）：
    优点：管理简单
    缺点：当开发的模块比较多，开发人数/小团队比较多的时候，很容易产生冲突而影响对方的开发。因为所有的改动都有可能触碰对方的改动
    第二重开发模式（分支进行主要开发，分散式）：
    优点：各自开发独立，不容易相互影响。
    缺点：管理复杂，merge的时候很麻烦，容易死人。

    查看(399) 评论(0) 收藏 分享 管理

  • 关于LoadRunner中参数值的引用

    2007-11-12 16:14:01

    这两天被这个参数化值的引用问题困扰的好苦恼，不想无心插柳柳成荫，今天在早loadrunner如何访问数据库的方法的时候，得到了这个使用方法，赶紧收藏，以备后用，谢谢xingcyx和zee的辛勤劳动和无私奉献！^-^

    关于LoadRunner中参数值的引用

    发布时间: 2007-8-21 14:20    作者: xingcyx    来源: xingcyx的博客

    字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿

    　　昨天在研究脚本的时候偶然遇到一个问题，今天正好有了点时间，就拿来再研究一下。
    　　问题是这样的：我想用strcpy函数把一个字符串赋给一个变量，再将这字符串做一个参数化，然后我想看看参数化是否成功，于是我用了lr_message函数把它打印出来。脚本代码很简单，如下所示：
      Action()
    {
        char a[10];
        strcpy(a,"{a}");
        lr_message(a);
        return 0;
    } 
    　　其中，{a}我已经做了参数化，参数值为11。
    　　运行这个脚本后，发现运行日志里打印出来的a值显示为{a}。
    　　在尝试了N遍以后，我把lr_message(a);这句代码改成lr_message(lr_eval_string(a));后问题解决，运行日志里打印出了我所期望的值11。
    　　问题虽然解决了，但我还是很纳闷，为什么在用lr_message的时候不能直接引用参数，而我记得之前在web_url、web_submit_data等函数里都是可以直接引用参数化的值，而从来没有出现过问题。也许是在LoadRunner里，这几个函数对参数值的引用方式不同吧，不知道我这样想是否正确，希望大家批评指正！

    　　昨天和Zee讨论了一个下午，结论还是没有明确。今天上午继续试验，试验结果表明Zee说的是正确的，不能直接将C语言里的变量直接当作LR变量使用，而需要做一些转换。事实上，执行strcpy(a,"{a}");后，并没有真正将参数值传给a。需要这样写：strcpy(a,lr_eval_string("{a}"));这样就没问题了。

    　　不过，问题还没有结束，在tuxedo协议中，用 lrt_strcpy函数则没有这个问题存在，例如：lrt_strcpy(sendBuf1, sendBuf);则可以成功地将sendBuf中的参数值赋值给sendBuf1。目前怀疑是该函数在内部已经进行过转换，但并不肯定，尚待证实。 

    　　再次针对以上问题进行试验，我在lrt_strcpy(sendBuf1, sendBuf);语句的前后各加了一句调试信息：lr_output_message("sendBuf:%s",sendBuf);
    和lr_output_message("sendBuf1:%s",sendBuf1);
    　　打印出来的结果截然不同，前者的输出显示没有传入参数值，而后者则成功传入参数。这表明确实是lrt_strcpy这个函数在搞鬼。
    　　至此，这个问题可以圆满结束了！感谢Zee同学的热情解答！^_^

    查看(932) 评论(0) 收藏 分享 管理

  • TD8.0项目移植

    2007-11-07 04:32:01

    TD8.0项目移植

     

    本文档目的：

    将服务器server1上的TD8.0下的项目移植到服务器server2上的TD8.0上

    本文档项目实现环境：

    工具：TD8.0

    数据库：sql server2000

    操作系统：win2000 sp4

    本文档约定：

    Server1上TD8.0下的相关环境如下：

          服务器名：server1

          数据库：Sql Server2000

          被移植项目：zb_test

          项目所在域：zb_tb

          项目在sql中的数据库名字：zb_tb_zb_test_db

          项目所在目录：c:\TD_DIR\zb_td\zb_test

    Server2上TD8.0下的相关环境：

          服务器名：server2

          数据库：Sql Server2000

          现有项目：新配置服务器，尚未建立项目

          现有在域：已经建立域zb_tb（与server1上域名一致）

          项目在sql中的数据库名字：尚未移植数据库

          项目所在目录：c:\TD_DIR\zb_td\

    关于TD8.0的项目文件存放说明：

         TD8.0的项目文件存储两个地方：

    1、  安装TD时建立的目录C：\TD_DIR,

    本目录安装时默认在C盘，如果你在安装时修改了路径及文件夹名字，请以实际情况为准。

    该目录说明如下：

       该目录包含第一级文件夹 

    _scrīpts   (该文件夹用途不明)

    Default （该文件夹为系统示例项目的域）

    ZB_TD （该文件加为用户自己建立的于）

    ……    （第一级文件夹为域文件夹）

               在各级域文件夹下为具体的项目文件夹：

                                         Default\ Demo_DB_0 （系统示例项目）

                                                  

                                         ZB_TD\ zb_test      （本次移植项目）

                                                  

                                         ……     （第二级文件夹为项目文件夹） 

    2、  数据库。

    本文档为sqlserver2000数据库存储，在sqlserver的企业管理器中可找到相应项目的对应的数据库。系统默认建立的数据库名字为：域名+项目名+db，本文档移植数据库为：zb_tb_zb_test_db

    项目移植需要移植的文件：

    1、  C：\TD_DIR下的域文件夹及其子文件夹（项目文件夹）。建议将_scrīpts也复制过去，Default为示例项目，示例项目数据库为access，这里不做移植。

    2、  数据库文件。需要在sqlserver的企业管理器中将数据库分离或备份，然后附加或还原到新服务器server2的sqlserver下。

    移植步骤：

    假设：server2上已经装好了TD8.0，已经按server1上的域创建了需要的。

    操作步骤：

    1、  在server1使用管理员用户（admin）登录进入TD的 site adminstratir模块

    2、  选择将要移植的项目，这里选择zb_td域下的zb_test项目

    3、  右键选择‘Deactivate project’，将选中项目（zb_test）设置为‘不活动状态’，（图标右边变红）

    4、  右键选择‘Remove project’，将选中项目（zb_test）从TD中移除（放心，这里非删除，但是切勿选择‘Delete project’，否则项目将被彻底删除）

    5、  将server1上C：\TD_DIR下的文件夹‘_scrīpts’和除了Default之外的其他文件夹，复制到server2上的C：\TD_DIR下（不要修改文件夹的名字），覆盖server2上的文件夹

    6、  将server1上sqlserver2000中的项目数据库分离或者备份，然后将数据库文件或者备份文件复制到server2的数据库目录下，附加或者还原到server2的sqlserver2000上（注意不要修改数据库的名字，比如原来数据库在server1上叫zb_tb_zb_test_db，附加或者还原到server2上还叫zb_tb_zb_test_db）

    7、  修改项目配置文件。配置文件位于每个C：\TD_DIR每个项目的文件夹下，名字叫Dbid.ini。

       

    比如本文档描述项目该文件在：C：\TD_DIR\ZB_TD\ZB_TEST\Dbid.ini.

    该文件内容如下：

    [General]

    Database_Type=MSSQL                   //表示项目数据库类型为sqlserver

    Created_Date=11/07/07 01:06:31            //数据库创建时间

    Created_By=td                           //数据库为td创建

    AliasName=zb_test                       //项目名称

    Database Name=zb_td_zb_test_db           //sqlserver2000中项目数据库的名字          

    Database Server=server1              //数据库所在服务器的机器名

    Domain Name=ZB_TD                    //项目所在的域名

    SendAllQualified=N                     

    Has_VCS_DB=N                         

    本文档移植项目需要改动的地方。Database Server=server2 。

    如果你按前面描述操作没有修改数据库名字和C：\TD_DIR下文件夹的名字，只修改该处即可。否则按上面的说明对应你修改内容修改相应的配置。

    8、  在server2使用管理员用户（admin）登录进入TD的 site adminstratir模块

    9、  点击‘Restore project’按钮 。

    10、              出现一下 窗口。在Restore Into Domain 中选择要移植的域，然后点击‘DBID.INI file Iocation’后的连个点，\\server2\TD_DIR\ZB_TD\ZB_TEST\DBID.INI

    (注意：该路径只能为网络路径，即使在本机上也需要输入网络路径格式，选择时可通过网上邻居选择本机的共享目录：TD_DIR)

    11、              路径和文件选择正确后将出现下面界面：

    12、              选择Restore，成功后返回界面如下：

    13、              此时项目已经添加进来，处于未激活状态

              

    14、              右键选择‘Activate’，激活后完成移植。

     

    完成后如图，经测试原数据和汉化字段，设定的流程都不受影响，可正常使用。

    查看(697) 评论(0) 收藏 分享 管理

  • 软件测试面试

    2007-08-01 23:16:39

    本文来自：http://www.cnitblog.com/charester/articles/14597.html

    前段时间公司招聘软件测试人员，虽然基本上都是招的应届毕业生，但我还是从现实以及网络上找到了一些应聘软件测试/QA的面试问题集，当然这个也都不会有

    标准答案的，现在只是以偶的一点理解加上网上的一些内容列举出来供有需要的XDJM们作一下参考：

    1. 首先一般都是比较老套点的问题：介绍一下你的经历。
    HOHO......这个问题我想谁都被问过吧，注意一下重点，不要紧张慢慢说就OK了。

    2. 老套话说了就可以马上切入正题了。根据你的经验说说你对软件测试/质量保证的理解？
    这个就要仁者见仁、智者见智了，也基本上都是书上的东东，如果能有一些自己独特的想法那就最好啦，呵呵

    3. 理解完了那当然就要问一下是不是对软件测试了解啰。这就轮到问软件测试的流程是什么，你原先的公司又是怎么的流程了？
    前面个问题也还是书本上的东西，一般介绍软测的书上都有，实际上国内一般的中小公司根本就达不到书上所说的那些个测试规范，测试流程也是如此，没办法，

    这就是现在我们整个大的测试环境，这个问题照着书上说的办就行了，后面那个知道该怎么做了吧，尽量把原来公司的测试流程言简意赅的表达出来。

    4. 接着问题就可以有一大堆了，这些问题很多都是要看自己的测试经验以及对测试的理解来作答了，如：
    (1) 你对SQA的职责和工作活动(如软件度量)的理解：
    SQA就是独立于软件开发的项目组，通过对软件开发过程的监控，来保证软件的开发流程按照指定的CMM规程（如果有相应的CMM规程），对于不符合项及时提出建

    议和改进方案，必要是可以要高层经理汇报以求问题的解决。通过这样的途径来预防缺陷的引入，从而减少后期软件的维护成本。ＳＱＡ主要的工作活动包括制定

    SQA工作计划，参与阶段产物的评审，进行过程质量、功能配置及物理配置的审计等;对项目开发过程中产生的数据进行度量等等；

    (2) 说说你对软件配置管理的理解：
    项目在开发的过程中要用相应的配置管理工具对配置项（包括各个阶段的产物）进行变更控制，配置管理的使用取决于项目规模和复杂性能及风险的水平。软件的

    规模越大，配置管理就显得越重要。还有在配置管理中，有一个很重要的概念，那就是基线，是在一定阶段各个配置项的组合，一个基线就提供了一个正式的标准

    ，随后的工作便基于此标准，并且只有经过授权后才能变更这个标准。配置管理工具主要有CC,VSS,CVS等，偶只用过CVS，对其它的不熟悉

    (3) 怎样写测试计划和测试用例：
    简单点，测试计划里应有详细的测试策略（测试方法等），合理详尽的资源安排等，至于测试用例，那是依赖于需求（包括功能与非功能需求）是否细化到功能点

    ，是否可测试等。

    (4) 说说主流的软件工程思想(如CMM，CMMI，RUP，XP，PSP，TSP等)的大致情况以及你对它们的理解：
    CMM:SW Capability Maturity Model 软件能力成熟度模型,其作用是用于软件过程的改进、评估及软件能力的评鉴
    CMMI:Capability Maturity Model Integration　能力成熟度模型集成　CMMI融入了大部分最新的软件管理实践，同时弥补了SW-CMM模型中的缺陷
    RUP:rational unified process 是软件工程化过程。它提供了在开发机构中分派任务和责任的纪律化方法.它的目标是在可预见的日程和预算前提下确保满足最

    终用户需求的高质量产品,个人认为：它的核心观念是开发的迭代，每个公司可以根据自身的软件开发的流程和待开发项目的特点对RUP进行适当的剪裁，制定出符

    合自己的软件开发流程。
    ＸＰ：extreme program，即极限编程的意思，适用于小型团队的软件开发，想上面第三个问题就可以结合原型法采用这样的开发流程。要明白测试对于xp开发的

    重要性，强调测试（重点是单元测试）先行的理念。编程可以明显提高代码的质量，持续集成对于快速定位问题很有好处。
    PSP ,TSP 分别是个体软件过程（Personal Software Process），群组软件过程（Team Software Process）大家都知道，CMM只是告诉你怎么做但并没有告诉

    你如何做，所以PSP/TSP就是告诉你企业在实施CMM的过程中如何做，PSP强调建立个人技能（如何制定计划、控制质量及如何与其他人相互协作等等）而TSP着重

    于生产并交付高质量的软件产品（如何有效地规划和管理所面临的项目开发任务等等）
    总之，单纯实施CMM，永远不能真正做到能力成熟度的升级，只有将实施CMM与实施PSP和TSP有机地结合起来，才能发挥最大的效力。因此，软件过程框架应该是

    CMM/PSP/TSP的有机集成。

    (5) 对项目管理、白盒测试、单元测试、自动测试、性能测试、压力测试工具的了解程度和实际使用经验。(其实基本上也就是MI和Rational工具)：
    这个就要看个人的了，没法说了

    (6) 其它一些具体的技术知识(如各种计算机语言的了解程度、数据库等)；

    5. 还有问一下你是怎样保证软件质量的，也就是说你觉得怎样才能最大限度地保证软件质量？
    测试并不能够最大限度的保证软件的质量，软件的高质量是开发和设计出来的，而不是测试出来的，它不仅要通过对软件开发流程的监控，使得软件开发的各个阶

    段都要按照指定的规程进行，通过对各个阶段产物的评审，QA对流程的监控，对功能及配置的审计来达到开发的最优化。当然测试也是保证软件质量的一个重要方

    式，是软件质量保证工程的一个重要组成部分。

    6. 然后紧接着就基于目前中国的国情，大多数公司的软件项目进度紧张、人员较少、需求文档根本没有或者很不规范，你认为在这种情况下怎样保证软件的质量

    ？(大多数公司最想知道的就是在这种困难面前你该怎么保证软件的质量，因为这些公司一般就是这种情况-----既不想投入过多又想保证质量，faint )

    出现以上的情况，如果仅仅想通过测试来提高软件质量，那几乎是不可能，原因是没有足够的时间让你去测试，少而不规范的文档导致测试需求无法细化何谈足够

    且有针对性进行测试。所以，作为公司质量保证的你应该先后项目经理确定符合项目本身最适合的软件生命周期模型（比如RUP的剪裁，原型法）,明确项目的开发

    流程并督促项目组按照此流程开展工作，所有项目组成员（项目经理更加重要）都要制定出合理的工作计划，加强代码的单元测试，在客户既定的产品交付日期范

    围之内，进行产品的持续集成等等，如果时间允许可以再配合客户进行必要的系统功能测试。

    7. 差不多了就该问一些只和软件测试相关的问题了，如：
    (1) 你觉得怎样才能做一个(或者，怎样才能算一个)优秀的测试工程师？(faint，这个问题好像是必问的，答案也无非是什么要求全面的技术能力、缜密的逻辑思

    维、出色的沟通能力、还要有怀疑精神、幽默感、洞察力等等。啥叫优秀啊？该有的能力都有，不该有的也有，而且个个能力还都是出色的，这就是优秀，呵呵，

    开玩笑的，反正这个问题差不多就这样，具体的什么要求网络上也到处都有。

    (2) 还有其它的如对自己优缺点的评价、自己的职业理想、为何离开上一家公司、自己在职业生涯中印象最深的事情、能否出差和加班、能否承受压力和挑战、薪

    水要求、何时能到岗等等这些啥面试都要回答的问题，这个就只能自己斟琢着办了。

    (3) 另外还有一个重要的问题就是语言能力啦，尤其是英语水平，这个的话每个具体的公司都有不同的要求，也就没啥好说的了。

    差不多基本上就是这些了，如果有需要的可以有针对性的google一下，hoho...仅供参考!

     

    做好软件测试的一些关键点
    本文作者 未知 摘自 机电之家

    1.测试人员必须经过测试基础知识和理论的相关培训。
    2.测试人员必须熟悉系统功能和业务。
    3.测试必须事先要有计划，而且测试方案要和整个项目计划协调好
    4.必须事先编写测试用例，测试执行阶段必须根据测试用例进行
    5.易用性，功能，分支，边界，性能等功能性和非功能性需要都要进行测试
    6.对于复杂的流程一定要进行流程分支，组合条件分析，再进行等价类划分准备相关测试数据
    7.测试设计的一个重要内容是要准备好具体的测试数据，清楚这个测试数据是测哪个场景或分支的
    8.个人任务平均每三个测试用例至少应该发现一个BUG，否则只能说明测试用例质量不好
    9.除了每日构建的冒烟测试可以考虑测试自动化外，其它暂时都不要考虑去自动化。

     


    软件测试员自身素质培养

    　　（1） 首先，应对软件测试感兴趣和对自己有自信，如果具备了这两点，那么在开发过程中不管遇到什么样的困难，我相信你一定能克服。

    　　（2） 善于怀疑，世界上没有绝对正确的，总有错误的地方，具有叛逆心理，别人认为不可能发生的事，我却认为可能发生。别人认为是对的，我却认为不是

    对的。

    　　（3） 打破砂锅问到底的精神，对于只出现过一次的bug，一定找出原因，不解决誓不罢休。

    　　（4） 保持一个良好的心情，否则可能无法把测试作好。不要把生活中的不愉快的情绪带到工作中来。

    　　（5） 做测试时要细心，不是所有的bug都能很容易的找出，一定要细心才能找出这些bug。

    　　（6） 灵活一些，聪明一点，多制造一些容易产生bug的例子。

    　　（7） 在有条件的情况下，多和客户沟通，他们身上有你所需要的。

    　　（8） 设身处地为客户着想，从他们的角度去测试系统。

    　　（9） 不要让程序员，以“这种情况不可能发生”这句话说服你，相反，你应该去说服他，告诉他在客户心里，并不是这样的。

    　　（10） 考虑问题要全面，结合客户的需求、业务的流程、和系统的构架，等多方面考虑问题。

    　　（11） 提出问题不要复杂化，这一点和前面的有点矛盾，如果你是一新手，暂时不要管这一点，因为最终将有你的小组成员讨论解决。

    　　（12） 追求完美，对于新测试员来说，努力的追求完美，这对你很好，尽管有些事无法做到，但你应该去尝试。

    　　（13） 幽默感，能和开发小组很好的沟通是关键，试着给你的开发小组找一个“BUG杀手”，或对他们说“我简直不敢相信，你写的程序居然到现在没有找到

    BUG”。

    　　（14） 到此是不是对测试很有兴趣呢？不过我要告诉你，测试过程中有酸甜苦辣，其中的滋味只有你知道，也许你会感到枯燥，要学会放松自己，去溜冰或

    做你喜欢做的事，不过，别放弃，因为你的自信告诉过你“你会是很优秀的测试员”不是吗？

    查看(1525) 评论(2) 收藏 分享 管理

  • 第一份面试结束了

    2007-07-29 22:32:35

        二面通知下来了，经过n多天的辛苦等待，终于还是等到了用人单位的拒绝。其实在等了n久之后已经有感觉了。我礼貌的问了原因。对方说是因为待遇问题。真是的原因无从考证了。如果纯粹是因为待遇原因，我想我没有什么遗憾的了。从面试的经过来说一切都很顺利，好像对方对我也比较满意，唯一我觉得不妥的是二面时关于我的学历的问题，不过当时面试官没有表现出什么不同（自我感觉他个人修为好，哈哈），最后一个面试官给我拒信是在msn中，还向我表示了歉意，说耽搁了这么长时间，但是不知道经理是出于什么考虑，可能是待遇问题。

      最近有些同学已经就业了，其他的同学都有点浮躁，经常和同学聊天，可以看出同学对用人单位的满腹牢骚和对待遇的不满。今天还和一个同学聊到这些话题。我觉得我们要放平心态，绝对的公平是没有的，要面对现实，不要理想话。更重要的要提高自己，技术和其他的素质，个人修养挺重要的。要分析自己的优势和不足，比如用人单位要求学历、英语、测试能力、沟通能力、编程语言、网络等，我们自己是否可以没有折扣的拍这胸口说没有问题呢。没有多少人。多以不要抱怨，不要气愤。我们要理智的分析情况，用人单位当然也是理想话的，他的要求都达到了就不可能是他出的价码了。所以我们要做到的先得到认可，表现出自己的优点，在和他们在合理范围内谈谈待遇，如果职业有发展，个人有发展，拿个半年的一年的不合理收入也是可以接受的。能忍胯下之辱者必成大气也。

       反省自己，面对现实，理智做事，感情做人。生活在继续，准备我的下一次面试

    查看(896) 评论(6) 收藏 分享 管理

  • 喝酒和it人的故事

    2007-06-26 16:58:24

    2007-06-25 09:07:12 / 个人分类：生活如此

    大家喝的是啤酒，这时你入座了......
    　　你给自己倒了杯可乐，这叫低配置。
    　　你给自已倒了杯啤酒，这叫标准配置。
    　　你给自己倒了杯茶水，这茶的颜色还跟啤酒一样，这叫木马。
    　　你给自己倒了杯可乐，还滴了几滴醋，不仅颜色跟啤酒一样，而且不冒热气还有泡泡，这叫超级木马。
    　　你的同事给你倒了杯白酒，这叫推荐配置。 
       人到齐了，酒席开始了。
    　　你先一个人喝了一小口，这叫单元测试。
    　　你跟旁边的人说哥们咱们随意，这叫交叉测试。
    　　但是他说不行，这杯要干了，这叫压力测试。
    　　于是你说那就大家一起来吧，这叫内部测试。
    　　这个时候boss向全场举杯了，这叫公开测试。
    　　菜过三巡，你就不跟他们客气了。
    　　你向对面的人敬酒，这叫p2p.
    　　你向对面的人敬酒，他回敬你，你又再敬他......，这叫tcp.
    　　你向一桌人挨个敬酒，这叫令牌环。
    　　你说只要是兄弟就干了这杯，这叫广播。
    　　可是你的上司jj听了不高兴了，只有兄弟么，罚酒三杯。这叫炸弹。
    　　可是你的下级mm听了不高兴了，我喝一口，你喝一杯，这叫恶意攻击。
    　　有一个人过来向这桌敬酒，你说不行你先过了我这关，这叫防火墙。
    　　你的小弟们过来敬你酒，这叫一对多。
    　　你是boss，所有人过来敬你酒，这叫服务器。

    　　酒是一样的，可是喝法是不同的。
    　　你喝了一杯，boss喝了一口，这叫c#。
    　　你喝了一杯，mm喝了一口，这叫vb。
    　　你喝了一杯，你大哥喝了半杯，这叫c++。
    　　你喝了半杯，你小弟喝了一杯，这叫汇编。
    　　你喝了一杯，你的搭档也喝了一杯，这叫c。
    　　死就是一念的事，活着却是一辈子的事，所以活着比死更需要勇气 says:
    　　酒是一样的，可是喝酒的人是不同的。
    　　你越喝脸越红，这叫频繁分配释放资源。
    　　你越喝脸越白，这叫资源不释放。
    　　你已经醉了，却说我还能喝，叫做资源额度不足。
    　　你明明能喝，却说我已经醉了，叫做资源保留。
    　　你喝一段时间就上厕所，这叫cache。

    　　酒过三巡，你也该活动活动了。
    　　你一桌一桌的走，这叫轮巡。
    　　你突然看到某一桌的漂亮mm，走了过去，这叫优先级。
    　　你去了坐下来就不打算走了，这叫死循环。
    　　你的老大举杯邀你过去，你只好过去，这叫激活事件。 
    　　你向一桌敬酒，他们说不行不行我们都喝白的，于是你也喝白的，这叫本地化。
    　　你向boss敬酒，可是boss被围了起来，你只能站在外圈，这叫排队。
    　　你终于到了内圈，小心翼翼的向前一步，这叫访问临界区。
    　　你拍着boss的肩膀说哥们咱们喝一杯，这叫越界。
    　　你不知喝了几圈了，只会说两个字，干了，这叫udp。
    　　可是还有人拿着酒瓶跑过来说，刚才都没跟你喝，这叫丢包。

    　　喝酒喝到最后的结果都一样
    　　你突然跑向厕所，这叫捕获异常。
    　　你在厕所吐了，反而觉得状态不错，这叫清空内存。
    　　你在台面上吐了，觉得很惭愧，这叫程序异常。
    　　你在boss面前吐了，觉得很害怕，这叫系统崩溃。
    　　你吐到了boss身上，只能索性晕倒了，这叫硬件休克

    查看(442) 评论(0) 收藏 分享 管理

Open Toolbar