去面试倒没有网上搜索到的那些事情，保安态度恶劣啊，前台秘书接待不周啊什么的，

对了，还有说坐什么破车去面试，我这次绝对不是的，因为根本就没有坐车，11路走的……

总的印象是厂大，人多。里面好多小青年，毕竟生产多余研发，食堂是印象最差的，走在富士康的园区，对面就是华为…………

1、10点准时到前台，报告身份，前台查下微机，告知什么部门面试，先去考试

2、漫步200M处，找到微机房，根据个人信息登陆人家的考试系统，本科考英语四级

单选15个，阅读理解选择10个，每题4分

其实都是初中英语，语法，to 放前放后，过去时，进行时什么的

3、做完英语竟然还有智力题，呵呵

但不是老赵的那种猪撞树上的问题

还是数学题，逻辑题，对了，如果想去面试的话，带上草纸哦，有些数学题目还是要动动笔的

4、考完，那秘书把考试成绩封起来让去找面试的部门秘书

中间上午吃饭时间，不象华为面试免费管饭，这里自己掏包，不过进去食堂感觉就知道了，很多很杂乱……

5、秘书通知人事，有人来面试

6、人事介绍，领着去面试技术官，中间路上那人事领导态度相当不错，介绍很多，为富士康正名呵呵

7、2个技术官加一个人事同时面试，问的问题基本都是那些老问题，就不重复了（为啥想来富士康，对富士康了解多少等等）

今天就到这里，等待复试通知（不象华为，说这样的话不是当时拒绝了，后面还有技术更高的领导复试）

QQBUG之二

BUG概要：用户离线后语音和视频均正常使用

使用软件：QQ2008祈福版本、QQ2007、XP系统

BUG详述：

1、和一朋友视频或者语音聊天，连接成功

2、自己一方QQ切换至“离线”状态

3、发消息不能成功、建立新聊天窗口不成功

但此时语音或者视频通话正常，无任何异常

此种情况可以在本机上用两个QQ号码登陆测试均能发现

最近一直和远方的朋友“切磋”开发的知识，其实就是共同学习 呵呵

所以经常把代码拷贝来拷贝去，这也就出现了一些问题：

工作环境： VC6.0、QQ2008 Beta1 祈福版 、QQ2007、

         PC_XP、在网状态、搜狐输入法、智能ABC输入法

BUG描述：从VC中拷贝中文，QQ聊天窗口出现乱码

具体操作步骤：

1、拷贝vc中的源代码如下内容：

  cout<<"请输入一个整数：";

2、打开一个聊天窗口（QQ上好友随便一个人）

3、粘贴，或者粘贴后对窗口刷新操作（拉动滚动条，切换程序）

4、马上看出中文部分都变成乱码了，而且以前如果是以同样字体发过去的中文内容也全部变成乱码了

（这个问题主要发生在我方，对方只有刚发送的那条带中文代码的短消息是乱码。）

此时做如下动作，切换输入法，切换聊天窗口、关闭聊天窗口问题依然，给任意一个好友发中文都是乱码

乱码解决方法：

QQ切换文字类型，宋体 -> 楷体 

就是切换到发乱码时使用过的字体就正常了

不过如果要想拷贝带有中文注释的代码放到QQ中还是可以的，方法多的是。

简单的，从VC拷贝到记事本，再从记事本拷贝到QQ，完事，没有任何问题！

软件测试到底要不要追究BUG发生的原因呢？这个问题的争议很多，有人认为寻找BUG的原因是开发的事情，软件测试只要能发现BUG就够了；还有人认为软件测试可以尽自己所能尽可能的去寻找BUG的原因。到底哪个观点正确？我个人认为这个问题是仁者见仁，智者见智，站在一个产品不同的层面看，会有不同的看法。这里所谈到的观点，也仅代表个人看法。

要搞清楚这个问题，先要明确几个定义，首先要明确什么是QA？简单从字面上理解是Quality Assure（质量保证），CMM对QA的要求主要有下面几点：保障制度体系；促使过程改进；指导项目实施；增加透明度；评审项目活动；审核工作产品；协助问题解决；提供决策参考；进行缺陷预防；实现质量目标。其次什么是软件测试，软件测试是根据软件开发各个阶段的规格说明和程序的内部结构而精心设计一批测试用例（即输入数据及其预期结果），并利用这些测试用例去执行程序，以发现程序错误的过程。

而软件测试人员就是这一过程的执行者。

从上面的定义可以看到，QA重点关注的不仅仅是质量，而是整个软件过程，保证的首先是过程和体系，也就是说只有规范了过程和体系，才有可能做出好的产品。而软件测试就是通过自己的活动，来给QA人员提供尽可能的有效的信息和数据，使他们能够发现过程上的异常或者制度上的不妥之处。可见软件测试的任务不仅仅是测试，还要把项目的异常情况向QA报告，所以只能报出BUG是不够的。

其实QA和软件测试的目的都是一样的，就是尽可能的使发布出去的产品更加符合用户的需要，尽可能的没有bug。不同之处只是一个关注的是整个软件过程，一个只是关注最终的质量。所以为了搞清楚软件测试要不要追究BUG发生的原因，先要明确的是弄清楚BUG发生的原因对整个软件过程有什么好处，或者说对最终的质量有什么好处？

对于开发来说，一般是能够重现这个BUG就够了，这样对于那些发生几率在100％的bug来说，软件测试人员只要详细清晰的描述出bug发生的步骤，写明bug的发生条件，执行这些操作的用户的角色以及权限，使用的操作系统和浏览器，然后写清楚实际结果和期望结果，基本上就差不多了，开发根据这些描述能够知道是如何出现的问题，并且知道应该改成什么样。到时候软件测试人员（可能不是原来报BUG的那个人了）进行回归测试时根据BUG的描述，也可以很清楚的知道这个BUG是否真的改好了。但是如果一个BUG的发生几率不是100％，或者说在某些特定的条件下的发生几率是100％，但是一般情况下都不存在。测试人员可能只是偶然发现这个问题，却会认为是100％出现，报BUG时也就没有指明这个问题出现的条件，开发看到这种BUG，根本无法重现，再打给测试人员，如此反复几次，虽然最终问题得以解决，但是对于整个项目来说，却是浪费了很多的时间。如果在发现问题时。能够多试几下，或者换个环境试试，可能就会找到发生几率不是100％的原因，比如非法数据，特殊字符，特殊用户权限，特殊日期，或者在系统中还有其他自己不知道的参数的影响，或者是操作系统的问题，又或者是浏览器的设置问题，还有可能是浏览器的版本问题等等，寻找这些原因的过程，是一个自我提高的过程，也是积累自己测试经验的过程，同时也是证明测试角色重要的过程，是证明测试人员价值的过程。

当然目前国内的软件公司中测试人员的水平还不是很高，想看懂开发的代码并且进行测试难度还比较大，所以我也不主张去看着开发的代码进行测试，只需要在测试的时候，多考虑一下，尤其是出现问题的时候，多想想这个问题为什么会发生，会影响到系统中其他什么地方，还会有其他哪些地方有可能存在这样的问题，这样等到开发修改好之后，提交测试进行回归检测时也可以做到有的放矢，尤其是在回归测试时间很短的情况下，如何进行有效的回归测试，并且保证不漏掉重大隐患，我想和开发水平固然有关，但是关系最大的还是测试人员对系统的熟悉程度，以及是否具有软件开发的思想。

追究bug的原因，不是一朝一夕的事，需要长期的摸索和总结，开始会很烦，可能还会很郁闷，但是慢慢的你会发现其中的乐趣，想一想当你报给开发一个Bug的时候，随着bug的报告还有一个详尽的发生这个bug的条件数据，以及测试平台等数据，开发根据这些很容易重现这个问题，会对测试人员的专业度有很大的认可，那时我想自己心里的成就感不是几句话可以说完的了！