今天晚上在家喝着红酒和可乐参杂的酒，味道非常好；好想退休啊！最近2周心情欠佳，主要是工作上的事情；工作那么久，遇到自己不能接受的事情我还是控制不了自己的情绪；今天静心想想最终还是开发惹的祸，开发质量非常非常的差，改个文字也能把功能改的不能用，真是无语；目前的开发团队能力水平真是让人堪忧、最倒霉和郁闷的是我的测试团队；从本周开始将要开始收集开发转测版本次数及bug的情况、从本周开始将要收集开发有多少延期转测的情况。

测试管理之前有写过2篇博文，今天给大家分享今年的最新版本，希望对大家有帮助！

做为管理者，每次给员工做工作绩效考核都会遇到这样或那样的问题，如：凭什么那位员工得分高？如何通过数据更客观的对员工的工作做考核？为什么某些人做的多，问题很多，结果不好？

在最近一次面试中，我问一个面试人：“如果你所管理的员工出现这么个现象：她做了很多工作，但问题很多，结果不好？你怎么看？”他回答到“说明这个人能力不行！！！”我说：“这里面管理者有问题”。。。。。。。。。。。

这周很累也很忙，情绪非常不好，有些像深圳的天气，一下热一下冷，也许还不习惯深圳的春天；目前这个职位快做1年了，当到了自己想要的终极目标职位时，有时会突然想回去做以前刚起步的职位，不知道为什么；每个阶段的工作职位都会遇到这样或那样的问题，有的问题会让人崩溃；每个公司都会有问题，本周收获了一句话“只有不做事情的人才不会犯错误”。

今天想写点什么，就把工作9年来自己问自己的那些问题，想起来的在这里随手记一记。

很多人问我，为什么你做测试做了那么多年还那么有激情？为什么你总能发现测试工作中有价值和有意思的东东并能讲出来？我回答：测试工作要做好很难很难，这个工种里有意思的东东一直存在，只是没有人去发现和挖掘，只是我们还没有发现和挖掘的能力，所以就没有找到；我正在一点点的学习这种发现和挖掘的能力。

大学毕业是在北京非典的那一年，我刚开始做测试时遇到的困难和问题：

1.         测试真的适合我吗？

2.         我的性格、我目前的能力真的适合做测试吗？

3.         测试这个工作岗位及工作流程是怎样的？我该如何快速掌握？

4.         测试这个工作岗位，我的职业规划该如何做才是我想要的？

5.         没有人教我如何做测试，我该怎么办？

6.         公司的同事不会手把手教我如何熟悉系统熟悉业务，我该怎么快速熟悉系统和业务？

7.         我发现的bug是真正的bug吗？

8.         我该怎么报bug让开发能看得懂？

9.         我该怎么准确的和开发沟通我发现的bug？

10.     我该如何与各种不同性格的开发人员沟通bug，让bug能顺利解决？

11.     我该如何与各种不同性格的技术支持人员或客户沟通问题，让问题能愉快高效的解决？

12.     和开发沟通bug的过程中，开发不搭理我怎么办？开发不认怎么办？

13.     短时间要测试完这么大的一个系统，我完不成怎么办？

14.     2天时间要写完一个大系统的使用说明书，我该如何写好它对用户帮助最大？

15.     遇到开发转测版本质量很差，开发不肯改bug怎么办？

16.     一个好的测试报告该如何写？它的意义和价值是什么？

17.     我的工作好坏老板从来不评论，我不知道自己的工作成果在同事中是如何评价的？

18.     这个公司的测试工作流程有哪些问题和可以提升的空间，我能做什么和改变什么？

19.     这个公司的测试工作技能和系统业务我都学透了吗？

20.     我目前的水平和其它公司的测试人员水平相比是什么的一个情况？

21.     在这家公司做测试工作，我快乐吗？我想要什么？

22.     我毕业的学校不是名校，大学同学都在考研，我是否辞掉工作也跟着考研呢？

23.     我拿什么资本去跳槽？如果我跳槽，我要在跳槽当中得到什么？想要什么？

到今年7月，毕业整7年，做测试也近7年；7年说短不短、说长不长，回头看自己的青春年华和激情都奉献给了这份职业；能培养一个测试团队并给整个团队带来测试的价值和理念，是我去年就想做的一件事情，现在算是做到了；接下来是考虑如何让这个测试团队里的每个人学习靠自己去提升自己的综合能力水平，把测试工作质量和速度上升到一个高度，把工作方法和技能总结并传承下去给新人。

         每周我们都有小组例会，每次例会我们都会有话题讨论，在近几周我们讨论了：测试计划、测试用例编写、测试环境部署工作做的好坏的标准；在讨论的过程中，大家还交流了做这些工作的方法和步骤，共享心得。在这里把我们总结的一些工作考核指标的标准放在这里，供同行参考并希望能给一些建议。

         说起绩效考核，2006年我有写过一篇文章《测试管理之绩效考核》，从中谈到了测试工作的绩效考核不能和开发放在一起做；因为工种不一样。现在看绩效考核，有了更多的收获。

首先绩效考核的目的：

1.          让员工知道自己工作中那些做的好，那些做不好；好的地方做总结，不好的地方寻求方法进行改进

2.          下一步的工作重点、目标及意见收集，想法沟通

3.          给员工有效的激励

要想达到上面3个目的，不是靠每一个季度和员工面谈一次就能达到；它需要每个管理者在日常的工作中就要关注这3个方面，这也是我现在花心思最多的地方。

1.          每周的工作要检查每个测试人员工作内容的质量和工作方法，有问题给予指导和说明，严重的给予批评，主要是工作上的问题能及时知道并得到改进。

2.          工作中每个人工作量的大小、难度及特长培养，都要花心思去观察并给予机会实践大家想做的事情。

3.          每个月会和每个人对当月的工作情况做总结和沟通。

有一天我在想，如果有一天我离开了这个团队，我该怎样让这个团队在没有我的时候，下面培养起来的人能很快的接手同时并正常运转；现在团队里良好的风气该如何让它存在？我想从让她们学会如何给自己定高标准开始。

下面是我们讨论的测试计划、测试用例编写、测试环境部署工作考核指标，这是7月份种的果实，希望在Q4季度能得到丰收。



 
 
 

     公司邮箱域名变更后，以前用Outlook 2003能收发邮件，现在变成是可以收邮件，发的邮件提示成功，但实际是没有发成功；经过现场同事的尝试，发现FoxMail可以正常收发邮件；为了便于回复邮件，因此决定放弃Outlook 2003，选择FoxMail；但是如何把Outlook 2003的邮件导入FoxMail是个问题，今天在网上查了资料，根据网上说的尝试了一把，成功了，在此记录收藏，便于日后使用。

Outlook 2003邮件如何导入FoxMail

第一步：点击“开始”->“所有程序”->“Outlook Express”，打开“Outlook Express”软件。

     第二步：在“Outlook Express”中，点击功能菜单条中的“文件”->“导入”->“邮件”，弹出邮件导入向导页面，具体见下图：

     
     在该页面选择“Microsoft Outlook”，点击“下一步”；进入到选择要导入Outlook Express中的Outlook 2003的邮件文件夹操作页面，具体见下图：
    

点击“所有文件夹”，点击“下一步”，系统就开始自动把Outlook 2003的邮件文件夹导入到Outlook Express，这些文件被保存成了.dbx格式。

第三步：打开“FoxMail”软件，点击功能菜单条中的“邮件”->“导入”->“Outlook Express信箱”，具体见下图：
    
    出现提示框时，点击“确定”，进入到选择导入Outlook Express邮件操作页面，选中要导入的Outlook Express邮件文件夹（注：文件是.dbx格式），点击“打开”，邮件就开始导入到FoxMail中，到此Outlook 2003邮件导入FoxMail操作完毕。

    总结：Outlook 2003邮件导入FoxMail，中间要借用Outlook Express做一个文件格式转换的二传手，才能成功导入。

    至于FoxMail邮件如何导入Outlook 2003，等下次要用到时，实践完在整理了。

本以为淮海战役打完后，整个团队和自己可以小休息一段时间，进行团队建设及改造；可是接踵而来的一堆需求、问题和年底业务高峰应对，不得已又打了1个多月的保卫战，才稍微缓了些，保卫战再打这么3个回合，就要开始迎接平津战役。搞IT的，这年头想过舒坦的日子真是不容易。

博客好久没有更新了，这两天刚好回海南休年假，可以好好整理这1年来的收获和教训，想想新的一年自己想要做什么，收获什么；发现人在畅想美好未来的时候，就会忘了曾经做事中的疲惫和艰辛，全身充满了动力。会写这篇文章，是想记录在2009年我和我的团队都做了什么，这些东西是我们不能够忘记和磨灭的记忆。

2009年工作记实

Ø         记得2009年的1月，同事、同行和朋友都很关心我，问我：金融危机来了，你被裁了，找到新东家了吗？我说：手头有好几份offer，正在头疼如何做正确的选择，过完年再考虑。

Ø         2009年2月，过完年，到了新东家报到后开始考虑如何在这个新的环境养育新的一个孩子。

Ø         2009年3月，开始了测试组团队人员的招聘工作，选择适合的徒弟。

Ø         2009年4月，一边制定测试组工作流程，一边继续进行人员招聘、一边带徒弟。

Ø         2009年5月，测试组人员招聘到位，工作流程制定完毕，基础入门培训完毕，开始为项目组服务，正式打响的第一个战役是：接口升级改造，没有给起个有意义的战役名字；在5月份，后来的战役分别命名为：阳春三月、雷霆行动；这个五月，团队的成员认识到了自己的价值和不足

Ø         2009年6月，我们一起经历了：地雷战、辽沈战役，这个六月，可以说很刺激。

Ø         2009年7月，我们一起肩负了：大团圆、星星之火、越狱第二季测试任务，开始准备淮海战役，这个7月，可以说很火热。

Ø         2009年8月，我们一起走过了：PKNBA、北伐战争测试任务，淮海战役持续准备着，这个8月，可以说很激动。

Ø         2009年9月和10月，我们开始了淮海战役，这两个月，可以说很煎熬，就像是个待产的孕妇。

Ø         2009年11月，我们一起面对了：世博会、淮海战役的测试任务，这个11月，是个特殊的月份，25号到27号，经过3天的折腾，迎来了系统的再次重生，为新业务的拓宽打下坚定基础。

Ø         2009年12月，为了能养好生下来的孩子，疲惫的我们仍然坚持的打响了保卫战，保卫战将持续到2010年的1月。

这就是我和我的团队一起走过的2009年，非常感谢团队中的每个成员，她们虽然没有丰富的工作经验，但有着强烈的责任心和正确的工作态度。大家一路走来，共同经历了风风雨雨，有时感觉就像是一家人：很温暖很团结但也会有争执，有开心也会有抱怨。很感谢我的现任老板，让我明白了很多东西并得到了成长，从他的言行举止中悟到了很多自己的问题。

2009过去了，它已经成为一段深刻的记忆，身心疲惫但甜蜜而美好；2010年已经开始，很期待也很喜欢北京的秋天，希望在美丽的秋天能让自己收获多多。

自6月18日辽沈战役胜利后，迎来了新的战役：淮海战役；这个战役从7月一直打到了今天，共计151天，在最后上线的这4天里，感受颇多，特写此篇博文发表心中的感谢，感谢战役中的每个人，感谢战役中给予帮助的每个人；淮海战役，生死决战，我们赢了！

请各位博友原谅我，大家发的邮件我都收到了，我会在接下来的2周里，认真看每个人给我的邮件和留言，并尽可能的回复。

在过去的151天里，特别是10.1国庆回来后，天天都在加班，加班加到大家都把周边的餐馆吃到要吐了，所有过去的辛苦，在今天看到它成功上线后，心里是开心的；在这4天上线的过程中整个团队共同经历了这样的心情：上线前心里是期待、兴奋；上线过程中遇到问题找不到原因心里是难过、郁闷、紧张；上线成功后心里是疲惫、欣慰。这种感觉让我再次想起了NCP，不同的是这次战役比那次的难度和规模都要大。

在过去的151天里，时间都投入在这次战役中，忽略了对家人的关心；在临近上线的这几个星期，北京下起了大雪，情流感袭击了大家，感冒、咳嗽、发烧；终于在24日晚上10：00开始了割接上线，在上线的这4天里发生了很多的故事，在这里通过流水帐进行回顾，回顾这段难忘的经历。

Ø         2009年7月到11月初，商城门户平台、管理平台开发完毕

Ø         2009年10月到11月初，系统数据割接开发并测试完毕

Ø         2009年8月31日到11月23日，商城门户平台、管理平台测试完毕

Ø         2009年11月2日到11月13日，系统进行了3次系统数据割接演练

Ø         2009年11月17日到11月23日，完成新系统老数据第一阶段割接工作

Ø         2009年11月24日到11月28日，完成新系统老数据割接上线的所有工作

Ø         11月24日22：00----2：30，系统开始割接数据操作准备工作，客户及各厂商都到现场

Ø         11月25日2：30---6：00，数据割接完毕，开始进行数据核对

Ø         11月25日6：00---8：00，数据核对完毕，开始割接后系统测试；性能测试，发现性能问题

Ø         11月25日8：00---12：00，开发联系厂商联调修改问题，QA割接后核心业务流程测试，

Ø         11月25日12：00---13：00，吃饭休息

Ø         11月25日 13：00---15：30，割接临时系统开放，进行割接系统权限分配及参数配置

Ø         11月25日 15：30---22：00，完成28个省系统联调

Ø         11月25日 13：00---26日2：00 开发修改问题并测试

Ø         11月26日 9：00---11：30 完成3个省系统联调，针对高优先级新需求和问题进行修改

Ø         11月27日 1：30---6：00 高优先级新需求和问题修改和测试

Ø         11月27日 6：00---8：00 系统割接上线完毕

Ø         11月27日 8：00---9：00 系统运行正常

Ø         11月27日 9：00---17：00 系统运行缓慢，出现性能问题，开始联系厂商查找原因

Ø         11月27日 17：00---22：00 查找问题原因，定位出是SQL大数据量查询导致数据库不响应，开始准备优化SQL并修改程序代码

Ø         11月27日 22：00---28日3：30 程序修改完毕，提交测试

Ø         11月28日 3：30---6：00 QA测试完毕，准备发布

Ø         11月28日 6：00---8：00 生产环境再次发布，再次出现性能问题，中间件服务频繁暂停并重启

Ø         11月28日 8：00---10：30查找问题原因，联系相关资深专家；收到客户频繁投诉，开始暂停服务

Ø         11月28日 10：30---12：00 相关资深专家及公司领导及客户领导到达现场，进行原因查找

Ø         11月28日 11：30---13：00 问题原因定位并进行修改

Ø         11月28日 13：00---13：30 QA测试完毕，准备发布

Ø         11月28日 13：30---14：30 发布完毕，再次开放

Ø         11月28日 14：30---16：00 业务正常运行，1个多小时产生1万多笔订单业务，成功上线

感谢我的客户，在出现问题的时候，及时协调相关资源进行问题定位分析；感谢现场支援的技术专家，让我们在身心疲惫的时刻，看到了胜利的曙光；感谢我所带团队的每个成员，为了能成功上线，坚持到最后；感谢我的老板，对团队给予更多的是理解和鼓励，让我们的团队变的更团结、更有默契；更要感谢此次上线中遇到的问题，让深陷其中的每一个人知道我们在做的事情是多么的重要和有意义；经历了这次生与死的体验，大家（客户、合作伙伴、公司高层领导）对自己和团队又增加了一份自我认知、信任和自信。

以上是此次上线完后的感想，后续将会对团队的每个成员进行录影采访留念，为此次战役的胜利印上深深的记忆和感受！！！2天2夜没能好好的睡觉、吃饭，现在终于可以回家做饭，好好安心吃上饭了！！！！！

----送给进入公司的应届毕业生

编写背景：

会有这篇随笔，是因为每个季度的季刊又开始征稿了，本期主题是“如何帮助新人融入团队”；由于我这边带的新人表现很好，小水滴让期刊负责人向我约稿，谈谈带新人的经验和体会，可以聊的方向有很多：技能、业务、沟通、相互熟悉等方面；想了想最终选择针对业务这块，说说怎么让新人快速入门，希望对后加入的应届毕业生有帮助。

每个人都是从新人走向老人

记得自己是在2003年，那个非典肆虐北京城的夏天毕业；可想而知当时的北京找个工作多么的困难，找到工作后，开始上班的那段经历至今难忘，刚毕业的学生步入社会参加工作，感受是：

期待的 年轻的心、满腔的热血，有的是精力、激情和勇敢；在工作中，每做成功一件事心情都high的不行，整个人就像一块海绵，想吸收更多的水分和知识，总觉的什么都不懂、要学的东西有好多好多；开始计划着自己踏入社会后的生活。

迷茫的 出了学校进入了社会，没有了宿舍、饭堂、教室和图书馆的四点一线；有的是租的房子、拥挤的公交车、繁忙办公室加班的三点一线；刚离开学校，踏入社会，突然发现学校学的在工作中用不上，社会是一个陌生的环境，一切都要从头学起和适应，心里是迷茫的、害怕的。

期待也好、迷茫也好，刚毕业的学生当经过社会工作和生活的洗礼后，人会变得成熟和有味道。

每个新人刚开始都必须要熟悉公司的业务

到至今，工作已经有6个年头；不管到哪一家公司，不管做哪一个工作；公司的新员工刚开始都必须要学习和了解公司的业务，特别是自己所要做的工作内容的业务。刚毕业的学生肯定会问：什么是公司的业务？业务重要吗？为什么要熟悉业务？如何熟悉业务？

什么是公司的业务？？？？

我是这么理解公司的业务，具体从这几个方面来看：

第1个是：公司的客户或用户是哪一行业的 打个比方：如果公司的客户是电信厂商，那么公司所做的业务是电信行业的；如果公司做的东西是给互联网用户用的，那是互联网行业的，互联网有（B2B、B2C、C2C）；如果公司做的东西是给保险公司用户的，那就是保险行业的；如果公司做的东西是给银行用户的，那就是银行业的等等。了解一个公司的业务是什么，从看公司服务的客户和对象就可以了解到。

第2个是：公司的业务是让公司盈利的东西 打个比方：公司的客户是电信厂商，公司给电信厂商提供服务或为客户解决问题，客户从中给公司money。公司的业务最终是通过为客户服务，从客户获取利润回报。

第3个是：公司的业务需要公司内部业务部门支持 为了实现公司的业务，公司要组建业务部门（即每个人所在的团队和部门），每个部门每年都有完成所背负的业务指标（即每个人所做的工作）；新人在进入公司招聘时，首先要明白这个公司是做什么的，自己来这个公司能够给公司做好什么事情，在这个公司做的这些事情是不是自己喜欢的。

上面说了我对公司业务的理解，从中可以看出，业务很重要；试想一下，如果在公司，你对业务不熟悉，你无法和身边的伙伴沟通配合完成工作；你无法理解同事、客户和老板说的是什么；你更不知道自己在做的东西是什么，只是一个机器，别人让你做什么你就做什么；你无法体会自己所做的工作重要性和意义；时间久了，会慢慢的变成个废人，变成一个没有思想的人。

既然业务那么重要，作为刚踏出校园的应届毕业生，作为公司的新员工，如何熟悉业务？更疯狂的是，如何在最短的时间内快速熟悉业务？

我的观点如下：

主动学习，掌握学习的方法 

对于刚毕业的学生，公司的老员工都会理解，因为大家都是这么过来的；所以刚开始一定要把自己所在部门的组织结构熟悉了，先学习熟悉环境，便于日后找人沟通能找对人；再就是学习做好你的导师交给你的工作，学习做好这个工作需要具备和掌握哪些知识，脸皮一定要相当的厚，不会的一定要在自己脑袋里多问个为什么，然后想一想，然后一定要去问你的导师或交给你工作任务的人；千万不要不懂装懂，那会害死人的；工作做的过程中，主动告诉你的导师或交给你工作任务的人，工作进度情况如何，有好的想法一定要多征求导师和交给你工作任务的人的意见。做完工作要做个总结，作的好和不好的地方都是自己的成长，日后回头来看会受益匪浅。

有机会多参加新员工培训 

每进入一个新的公司，3个月的试用期间，有机会，可以多多参加新员工培训，特别是对自己工作非常贴近的业务介绍。如果没有培训的话，一定要找相关人员要业务介绍相关文档进行学习，具体的有：系统需求说明书、系统设计说明书、用户使用说明书等等，最好是结合这些手册，到实际系统中站在用户的角度去使用，理解会非常的快。

主动多听多做，少说话 

作为一个新人，刚开始什么都是不懂的，要想快速学会做事，一定是通过多做才能学会；相信任何一家公司的老员工在看到新员工做的不多、说的很多，是很不爽的；不是多了个帮忙的人，而是来了个大爷；大家都喜欢和勤劳、努力、有责任心和上进的人一起工作。因此新员工一定要勤劳、努力和虚心请教的多做事，这样老员工会更乐意教会你很多东西。

写了这么多、不知道是不是废话，感觉还有好多好多，可惜组织不上语言了；突然感觉自己像个大妈似的，滔滔不绝的把心里想到的都说了，这次就写到这，希望对大家有所帮助。

最近两周都非常大忙，忙到做梦都在上线，一周5天上了8次线，是工作有史以来遇见上线频度最多的一次；团队每个人都很累，我也很累；好在终于告一段落，这周末就可以适当休息了，下周末决定和大家一起去十渡放松放松。

在繁忙的日子中，能去听听培训是件很开心和幸福的事情，可以暂时让自己好好思考一些东西，同时又学习新的东西；公司提供的培训，老大每次都会争取机会让我去参加，我非常开心、感激和珍惜，这是我在别的公司所得不到的学习机会；因此每次一想到公司某些方面的XXXX让我不满意，但一想到培训心里就平衡很多。今天去参加的培训是：驻足思考：瞬间整理思路并有力表达，对我触动非常深刻，特别想写点什么，因此便有了这篇随笔。

这个培训是2天的课程，今天是第1天，去听这个课，是想让自己在和客户沟通表达一些问题和观点时，能思路清楚并有力表达，同时听完后要回来给组内人员进行培训；因为发现大家的沟通表达能力有待提高。

谈谈今天的收获，首先影响非常深的是第一个互动：30秒的自我介绍，老师要求：不需要介绍名字，不需要说我是哪里人，要把自己的一个特点给介绍给大家。

虽然是短短的30秒的自我介绍，但是要想给陌生人留下深刻的记忆，不容易；先介绍的7个人，暂停后，大家互相去想每个人介绍的特点，发现有的是记不住。。。。如果一个人做了自我介绍，但是没有人能记住这个人，是有些悲哀啊；想要在短短的时间内，让别人深刻记住你，需要组织好自己的语言，如：特点要鲜明并突出，不能是多个；要有事例来衬托这个特点，让人更容易记忆等等。

接下来的环节，对我影响最大的就是如何接话，就是如何去衔接和回答客户或他人提出的问题，非常有学问，一一举例如下：

问题一：家里老婆埋怨丈夫说：“怎么老加班、老出差，家里都是我一个人管。。。。”

这时候老公该怎么去接这个问题和回答这个问题比较好，现场出了很多方法，最终老师告诉我们要这么去分析问题，先去思考老婆在埋怨什么，原来是埋怨放在工作上的时间太多了，关注家里的时间太少了。找到了原因，那么可以这么回答这个问题，首先承认自己并点醒老婆问题是出在时间分配上，为什么把时间大多放在工作上，是为了养家啊，这么和老婆解释，相信这个答案会非常满意。

问题二：有一天老板对其中一个业务主管说：“XXXX，XXX业务最近效益很好啊”

这时候该怎么去接老板这个话比较好呢，老师告诉我们学习着用时钟法来解答，可以这么说：在过去的XXXX个日子里，我们做了XXXX努力，才会有今天XXXX的结果；现在我们在做XXXXX，计划在未来的XXX时间段能XXXXX；通过三个时间段，把要说的内容进行层次感划分讲述，会让人听起来很舒服

问题三：当客户在说某些观点，但这些观点不一定是合理的时候，该怎么去沟通？

问题四：当系统出现问题，客户非常着急和生气，这时候该怎么去沟通？

问题五：当下属要求上司加薪水，该怎么和下属沟通？

。。。。。。。。。。。。。

一下午做了一系列的话题练习，让自己的思维模式在潜隐末化的影响着，最后得出如下感悟：

1.       针对问题和话题，经过有条理的思考后，应用技巧组织合适的语言进行沟通，得到的效果非常明显，更进一步感受了中国语言的魅力和自身沟通上存在的问题

2.       针对一些人抛出的疑难问题，一定要先搞清楚问题背后的原因，在寻找这个原因的过程中，不能用质问的口气去问别人，千万不能用类似语气：你为什么这么问？你凭什么这么问？等等

3.       针对一些人抛出的恶意问题，要学会用升级、下降、调整或分级等技巧进行回答

4.       有效的表达语言，在沟通的过程中会提高个人的影响力

最后，老师建议我们回去多看看电视节目，特别是名人访谈节目，通过看这些人的沟通表达方式，可以学习和积累沟通表达的技巧。

有1个月没有更新博客了，每次看到大家的留言，心中很是感慨该抽些时间把最近收获的心得放上来；今天终于有空，借着团队活动，在北京展览馆附件的咖啡店里，上网把临时紧急工作事情处理完，可简单整理整理。

这次想和大家分享的是工作的主动性，这是前两周小组每周例会上讨论的话题，会讨论这个话题是因为组内的成员在工作主动性上不积极、不够用心。

浅谈如何提高工作的主动性

自从做了带有管理者职位的工作，开始学习管理自己从没有管理过的人和事；才发现想管好人、带领一帮人做好事情，真是不容易啊！！！！！这回真是深刻体会了，做一个合格的管理者有多操心，肩膀上的责任有多重，要给团队创造一个和谐的工作环境；要让团队中的每个人感觉自己的工作有成就感并得到认可；要让团队中的每个人能够吃好、喝好、穿好；要让团队中的每个人能力发挥到极致；要给团队招聘合适的人并进行合理有效的培养；时不时要检查大家的工作进度情况、问题和表现，还有一堆的会议，突然发现工作上留给自己思考和学习的时间越来越少，同时逼迫自己快速对事情做出有效判断、决策和处理。。。。。。。。。。

当自己很忙时，把一些事情分配出去后，非常期望分配的事情能够得到有效处理和主动反馈，可是有时候，团队的新员工通常都不会主动反馈工作的进度情况和问题，总让自己去check和提醒，让我非常的不满意，因此便组织团队的组员对工作的主动性进行探讨，对于如何提高工作的主动性，最终得出了下面这些结论：

Ø         对于应届毕业生入职后，工作上有导师提醒，主动性会有所提高，多次提醒后会变为习惯

Ø         对于应届毕业生入职后，工作上遇到问题后，导师要及时指出并深刻教育会记忆的更深刻

Ø         思想的转变，对做一件事情的观点是责任不是做一件事情，主动控制管理所做的事情

Ø         做好工作任务的计划，在执行计划过程中遇到问题就会主动沟通（通过计划来驱动事情的执行，通过执行驱动沟通遇到的问题）

Ø         这是一种技能，需要注意主动性度的把握，那些该主动，那些不该主动

Ø         主动性和企业文化有关系，需要通过某些形式或行为进行洗脑，通过固化的形式，制定一些制度

Ø         沟通的主动性分两类：工作进度情况沟通（目的是确认方向是否和团队一致）；工作问题沟通（先是思考解决办法，想不出解决办法寻求团队的帮助）

Ø         主动性是和个人的性格、压力和惰性有关，这种情况需要人提醒和指导，需要目标来驱动

Ø         主动性和工作态度和兴趣有关系，需要明白自己喜欢做什么、要什么

通过此次组内每个人热烈的发言讨论，相信对每个人接下来的工作热情会有些影响，希望团队里的每个成员都能快速成长，独当一面。

----纪念在这次战斗中英勇奋战的同志

编写背景：

所负责的测试任务：辽沈战役，在克服重重困难和阻力下终于艰难的完成了做战任务，为了纪念此次战役，为了记录此次战斗中的英雄，特写下这篇文章留做纪念。另：放在blog上是想和大家一起来分享心情。

                     记录辽沈战役---我们一路走过的脚印

中央电视台，中央电视台，各位观众，大家晚上好，我是电台主持人：小蚂蚁，你现在收看到的是中央电视台现场特别专题报道：XXX项目-----辽沈战役---系统上线，现在是2009年6月18日晚上9点50分，我们目前所在的位置是：北京xxxx项目组的办公地点，等一下在这里将发生一件非常重要的决战，就是辽沈战役最终是否可成功拿下。

我们将在现场向观众直播这个战斗的过程，这个战斗将从今天晚上10点开始一直持续到第二天凌晨早上7点，共计：9小时。现在从窗户看外面是黑漆漆的一片并下着小雨，但我们看到目前现场的气氛和外面是截然不同，大家都在积极的做着战前准备；接下来我们会分段给大家报到整个战斗的过程。

现在我们先去看看这次参战的各个成员情况。

我们先来看看测试组人员：

   测试工作人员XXX正在测试环境部署最新开发提交的程序包，从表情上看，对此次战斗充满了很多期待

   测试工作人员XXX正在测试，从表情上看意思是：我们对此战斗充满着信心。

   测试工作人员xxxxx正在专注的验证新版本解决的问题，看她十分的专注，我们的拍摄她都没有感觉到。
   现在我们来到了运维组：

   运维工作人员XXX正在查看生产环境系统的情况，做着系统上线前的准备，从表情上看：心里那个美啊，可惜他不愿透露为什么这么高兴。

我们在看看运维工作人员：星仔，很遗憾，他本人现在不能接受摄像和采访，正在做着非常重要的事情，我们找到了他之前的一个加班工作照片。

   看，他是多么的专注。

下面我们来到了这次战斗主力之一的团队：开发组

    他是：pig朱，正在调试辽沈战役的程序。

    从近到远看，他们依次是：XXX，穿着粉色衣服的这位，正在做着淮海战役的开发工作；穿着白色衣服的这位叫XXXX，他旁边的人是：XXX；他俩正在对此次战役QA发现的bug进行分析。

   神情专注的这位是：XXX，他正在做着淮海战役的开发工作。

接下来，我们想采访一下这次辽沈战役的开发具体负责人：XXXX，可惜他人现在不方便露面，我们找到了他日常工作中的照片。

    呵呵，真是一表人才，他可是此次辽沈战役开发的主力。

   他是：XXXX，此次战役的开发总体负责人，正在看目前开发的战况情况

   他是：XXXX，此次战役的总司令，从表情上看，我们这次的战役肯定会赢。

刚才给各位观众介绍了辽沈战役现场工作人员的情况，就在介绍的过程中，我们的客户冒着大雨亲自来到了现场了解此次战役情况，可见此次战役对客户来说有多么多么的重要。现在我们看看时间，现在时间指到了10点50，刚从测试人员那边得到最新消息：系统在测试环境已经封版本成功，发现的问题都已经解决，已经可以部署到生产环境。

现在等待运维组工作人员xxx开始部署程序到生产环境，现在我们稍待休息15分钟，广告之后，继续回来给大家报道具体情况。

中央电视台，中央电视台，各位观众晚上好，你现在收看到的是中央电视台现场特别专题报道：XXXX项目-----辽沈战役---系统上线，我是现场主持人：小蚂蚁，现在是2009年6月18日晚上11点30分，现在辽沈战役已经到了最关键的环节：在生产环境部署新版本程序，刚收到最新消息，在生产环境部署中发现了一个很严重的问题：前端程序调用服务层的EJB失败，目前开发负责人XXXX正在查找原因；我们不方便打搅他们，正在等待结果。

现在看看时间已经指向了2009年6月19日凌晨的1点，这时传来消息，问题原因还是没有找到，但已经联系上了开发EJB服务工具的厂家维护人员，并且该人员正在进行远程+电话协助定位问题；测试人员这时正在处于等待状态，等待问题解决后可以在生产环境进行冒烟测试。

现在时间指向了凌晨2点半，刚收到最新消息，问题已经找到并进行了解决。可以在生产环境测试了。这时测试人员反馈有问题：调用XXXX的接口不通。赶紧联系在场的xxxxx工作人员，原来XXXX今天晚上要切换机器硬件，还没有切换好。过了半个小时xxxxx切换机器硬件工作完毕，测试人员可以开始在生产环境进行冒烟测试，在冒烟测试的过程中发现还存在问题，这个问题是有个功能无法在测试环境测试只能在生产环境测试时发现了的，同时部署的程序版本不正确。运维组的xxx，开发组的xxx正在查看；经过20分钟的重新部署，版本不正确的问题解决，但无法在测试环境测试的功能在生产环境冒烟测试后发现还有问题，xxxx正在进行修改。部分开发人员和负责人都已经回家休息了，客户在外面大厅的沙发上睡着了。

现在时间来到了凌晨4点半，放眼望去，测试人员累的都已经趴下了，运维人员也已经趴下了，其中还听见星仔打呼噜的声音。很想把他们疲惫的样子给拍下来，但实在不忍心。在来看看时间，现在已经指向了5点，xxx还在修改着剩下的这么一个bug，QA负责人建议XXX，如果在半个小时内如果解决不了这个问题就先不上这个功能。

时间指向5点半，突然传来好消息，问题已经解决了，叫醒了测试人员xxxx进行测试环境部署，叫醒了xxxx进行生产环境部署。在测试环境验证改这个问题是否会影响其它主要功能的使用，其他测试人员在生产环境验证这个问题是否被解决。时间来到了6点，测试组人员传来好消息，问题已经解决，在生产环境冒烟测试通过，可以全部部署到生产环境各台机器。

时间指向6点15分，程序已经部署到生产环境的第一台机器，突然传来消息，登录验证码的域名跳转没有做配置，xxxx说这个需要联系第三方厂家的负责人才能解决，现场工作人员都没有联系通讯录，先电话联系现在第三方厂家沟通负责人：xxxx，发现对方电话关机，估计是没电了。接下来电话联系之前的负责人：xxxx，大清早的人还没有睡醒，电话通了，可惜信号不好断了；再次拨通电话，终于联系上了xxxx，xxxx说已经给了xxxx；赶紧电话联系xxx，xxxx立刻提供了联系人方式；赶紧联系第三方厂家的负责人，第三方厂家负责人提供了相应的技术负责人联系电话；赶紧联系第三方厂家技术负责人联系电话。看看表，现在时间到了6点半，距离7点就剩下半个小时；好在第三方厂家技术负责人的电话打通了，通过电话进行了相应指导操作。

6点45分，第一台机器部署成功，测试人员全体开始访问外网，查看新版的页面，这时客户也已经醒了，期待着第一时间看到。7点整，外网所有机器进行全面部署，向所有互联网用户开放，同时宣告着此次战役的胜利。

现在我们可以看到在场的人终于松了一口气，整个人的状态是：开心、疲惫、饥饿。QA人员去外面买早餐，xxx和xxxx对上线情况进行监控，xxx对客户现场反馈的问题进行记录和修改。时间指向7点半，QA和运维人员开始吃早饭，开发人员xxx已经疲惫的睡着了连饭都顾不上吃，只喝了杯豆奶。时间指向8点，测试组人员已经回去休息。时间指向8点半，剩下的最后人员：xxx、xxx、xxx清理完现场，准备回家睡觉。到此，辽沈战役整体现场报道完毕，感谢各位观众的收看，同时祝贺辽沈战役取得的胜利，这是中央电视台，现场主持人“小蚂蚁”发回的报道。^_^。

 最近这段时间很忙很忙，忙着上驾校、忙着招聘新员工、忙着找房子搬家。。。。。。。。想要做的事情很多，回到家里洗洗看上几页书听听收音机就很困很困了，我的blog很想更新实在是没空。很快就搬家了，搬了家每天可以节约3小时，也不用做拥挤的地铁了。

想写这篇文章是因为最近在招聘大学研究生实习生时，心中突然有的一次感慨。

招聘感想之请学会抓住每一次成长的机会！！！！

到了新公司工作有1个多月了，有机会给自己的测试组招聘实习生，对象都是北京知名高校的在校研究生。

金融危机下的09年，大学应届毕业生找工作那是困难重重，让我想起以前在校园里大家流传的一句话：毕业等于失业。公司在发布了招聘信息后，我的邮箱被应聘简历邮件塞的满满的，周六日全拿来筛选简历了。

应聘简历很多，几百封邮件，我每个都要一一看，看多了总结出一些心得和感慨。

心得就是：

1.       北京市以外的大学研究生不考虑，因为考虑到外地学生来北京住宿和学习问题

2.       简历排版不合理，内容描述不简练不要，因为都读到研究生了连个简历都不会写有点说不过去

3.       专业不对口不考虑

4.       从简历上看，只是来找找实习工作的感觉挣点生活费的不考虑

5.       简历中和发布的招聘职位信息需求不匹配的不要

从上面5点开始进行一层层的筛选，最后在几百封邮件中选出了20份简历。

然后一一通知这些同学来公司进行面试，在通知的过程中，会发现有的人会问面试流程，问的这些同学说明做过找工作的功课，我对这些人进行了记录。

接下来就是面试，第一轮是笔试，我出的题不难，只要用心准备很容易就答上；可惜的是来面试的这些人中，只有这么几个人有做面试准备，最后这20多人笔试完，就剩下3个人进入复试。让我很是为这些同学惋惜，没有抓住机会。

在后来的面试中，还出现搞笑的一幕，测试和开发组都在招实习生，都同一天笔试，一个来应聘开发的学生尽然做起了测试的考题，他一进笔试的门也没问是应聘测试还是开发职位，看到别的同学在拿题做，自己主动也拿个题来做，结果就是：一道题都不会，看我进来了，用疑问的眼光看着我，然后不得不说，我是来找谁谁谁的；然后带他到开发组。

此次招聘在校研究生实习生，得出的感慨就是：

1.         大学生不停的说找工作很难很难，不知道他们有没有用心的学习如何找工作、如何应聘。

2.         刚毕业的学生主动沟通意识很弱，看着简历上写着参加XXX活动，获得XXX奖学金；但是为何在面试中让人感觉是那么的没有自己的观点。

3.         中国的教育都让人读书读的越来越傻了。

4.         最后一个就是：我要告诉自己和招聘进来的每一个同学，一定要学会抓住每一次成长的机会！！！

最近很懒惰，生活过的非常没有激情和动力，有些像70岁老太太过的生活；blog也懒的写，原先计划好要整理的知识，动了一半就处于挂起状态。不知道自己是那根筋出了问题，也许是烦恼找BF的事情；也许是突然间对工作厌倦了；感觉自己好老好老，呼呼，这样的心态继续下去就要变成老太婆了。

这两天网站在进行导航条改版，进行了测试，发现导航条测试有这么些测试点，今天想想记录一下吧，兴许可以唤醒写blog的动力。导航条到底有哪些测试点呢？期待各位同行补充各自的观点。^_^。

小小的导航条，有啥好测试的呢？通常你测试的时候会发现什么问题和特点吗？我这两天测试了导航条，产生了如下感想，各位同行，你想到的和我一样吗：

1、 导航条测试分两类：应用软件类、门户网站类

2、 导航条的价值：

对于应用软件类

Ø         让用户快速的找到要操作的功能；

Ø         让用户清楚的知道自己在什么地方；

Ø         指导用户如何去使用该软件；

Ø         好的导航条名称让用户能快速的自学学习软件；

对于门户网站类

Ø         导航条可以让用户知道要找、要看的东西在哪个大分类里；

Ø         让用户知道自己目前在网站的那个地方，不会迷失方向

3、 由于这次测试的是门户网站类导航，因此这次把门户网站类的导航条测试点记录如下：

功能方面：

1） 一、二级导航中的文字链接页面打开方式一致；要么新页面，要么当前页面；

2） 各链接页面正确显示，不出现错误；

   UI方面：

1） 一、二级导航中的文字颜色、大小、风格显示一致；

2） 每选中导航中的页面，相应的该页面的导航文字为选中显示状态；让用户知道自己在看的是那一页；

3） 导航条中的页面文字显示正确，无错别字；

4） 同一导航在不同地方显示的内容和排列的顺序一致；

兼容性方面：

在不同的浏览器下查看页面显示是否正确；

易用性方面：

1）导航名字容易明白，见名知道其意思；页面内容和其名字表达内容相呼应；

2）导航栏排列方式符合用户使用逻辑，查看简单，分类级别层次不超过2层；

4、 至于应用软件类的导航条，先暂时不写了，等那天心血来潮，想写了再把它补上。大家如果有想写的也可补充补充。^_^。

天色已晚，要睡觉了，就写到这里了，就到这里了。有问题，欢迎留言和来信。^_^。

     时间过的真快，北京炎热的夏天开始了，在新公司工作已经有3个月了。

     有一天，和徒弟一起吃了顿饭，沟通了我们在新公司上班的感受，总觉的把我们的感受该记录下来，等那一天我们都老的时候，再回想我们的这次谈话，会有另一翻的回味。

     今天是周五，工作的环境空调坏了，非常的闷热，就要下班了，刚好写写blog放松心情。

                                                                 公司大小与测试是否规范无关

       这是我和徒弟分开后的第一次见面，大家都互相的想念和牵挂。饭还没有上，便各自聊起了在新公司的体会。

       徒弟在新的公司碰上了和我同样的现象：

1、同事都问到了这么个问题：你的上一个公司是？？？

      徒弟的同事会问这个问题，是因为它们从徒弟的一些工作风格、工作结果及思想，还有工作作风让它们感觉非常的正规，于是便想知道是哪个公司培养的，肯定是个大公司。

      我呢，有2个同事问了我这个问题，一个不知道是什么原因问的我，另一个同事也许是在我说出了如下的话问的我：

我把我做的每一个测试的东西当成是自己的一个宠物。

我的薪水是客户给我发的，只有我们的产品客户认可了，才会用公司的产品，公司才会挣钱。

2、和之前我们做事情相比，目标都不明确，具体表现：产品需求描述的不够明确和准确；工作的安排及要求不够清晰!

      提到这个我们彼此都笑了笑，大家在新的工作环境都不是很习惯，都在适应中。这就是在锻炼我们的适应能力；对于徒弟来说这点有些难度，毕竟她没有经历过。除此之外都很怀念我们以前的团队、工作氛围。

3、和之前我们做事情的工作量相比，工作效率都不高，具体表现：我们之前一个20个功能模块内的系统2个人配合1个星期就可以走1到2轮测试，而现在一个10个功能模块内的系统，3、4个人要测试2个星期甚至1个月。
      聊到这个现象我们又笑了笑。分析了一下原因：也许是我们之前的团队工作目标非常明确、工作计划制定的合理、工作执行非常努力。

      我们的领导21克 给我们的入职培训让我映像很深刻，他说过：我们是个创业中的公司，我们要像狼一样生存；我们是一个特种部队，目前公司不能提供给我们足够的人力资源，我们要想成功，每个人除了要做好自己的工作角色，还要可以互相监督和帮助，就比如我们在一起攻打一个山头，每个人拿着枪站在不同的角落，只要任何一个人松懈，其中的其它人就会有危险。

      又让我想起了，每次为了工作上的事情和21克发生争执时，21克给我的教导：以后在一起工作的时候，不要说你们，要说我们。测试和开发不要分你们、我们，我们是一个团队，只是分别担任不同的工作，但我们的目标都是一致的，只有我们的目的都是一致的，只有我们互相协助的，我们才能更快、更准确的完成我们的任务。

     写到这里好想有些文不对题了。嘿嘿。^_^

     每个公司都有不一样的管理模式、经营模式、用人模式，这样就会有不一样的结果。

      测试新手曾经问过我：去大公司做测试，肯定正规，这个是不一定的。公司大并不代表一定正规，公司小就不正规。测试的工作流程是否正规每个公司都有自己的规则，这个规则是领导定的，因此领导如果对测试不了解，那可想而知情况如何了，让我想起了袁林的MSN标题，好像是这么描述的：更深层的问题出现在管理当中。

      测试新手也曾经问过我这么个问题：黑盒测试没有技术含量，测试没有技术含量。每每想到这样的问题，就让我想起某位同行的一篇随笔：你为测试做了多少。

      黑盒测试有没有技术含量，主要还是看个人有没有去发现其中的宝贝，去领悟到做好黑盒测试有多难。一件事情，“做”和“做好”是不一样的；一件事情，因为“钱”去做和因为“喜欢”去做，结果是不一样。

      公司大也好，小也好，测试管理做的是否正规，最终取决于身在其中的每一个人。
     
很感恩老天爷让我从事了测试工作，让我从中学习到了、领悟到了很多美好的东西，这些东西可以在我老了以后留下美好的回忆。

编写背景：

     自从上次自己写的文章被转载没有说明出处，就打算停写 BLOG 半年， 7 月份再回到这里描述我测试工作上的一些感想。对于文章转载一事，我在公告栏中说的很清楚，允许转载，但请说明文章出处。

很感谢各位同行在 BLOG 上的留言，谢谢你们也喜欢我的 BLOG 。非常的感谢你们。

     也许是近一年半以来，工作上很开心也很有收获，老天爷也许是觉得我该再多一些磨难，让我再一次面对选择。所在的公司业务转型了，重心为：技术支持；我的好领导（我们团队的灵魂人物）在今天将辞职离开这个我们奋斗了 1 年多的团队，我的心情很伤感。在不久的时间里，我也将会离开这个团队，面对领导的离职、面对公司的转型、面对自己喜爱的测试职业、面对我的徒弟，思考了很多，大脑很累。累到我不得不到这里来述说，便有了这个随笔。

  很怀念过去一年多里，在这个团队工作开心的日子。

  公司虽然很小，虽然没有名气；

  我们做的项目不像大公司所说的工期是 1 年或 2 年，接的都是大型项目；

  我们都是所谓的小项目工期是 3 个月或 4 个月；

  但我们工作很认真、很负责、很严谨，力求完美和专业。

  在这个团队里工作很开心，很有成就感；

  团队的领导很重视软件质量，很重视测试；

  团队的管理很人性化，也很严格，这是我喜欢的一个工作环境和氛围。

  可惜这一切都即将消失，很是怀念和伤感阿！！！！！

   记得刚来时，管理和测试都不规范；经过 1 年多的奋斗，建立了测试组，并完善了测试工作流程；还带出了一个很好的徒弟；领导很认可我的工作；往回看，我们测试组的战绩很值得我们骄傲和自信。 ^_^ 。

   站在管理这个层次和角色上去看待测试这个职业，从中学习到了很多东西，开阔了思想。这一切将会成为我工作生涯中最美好的回忆。想一想，突然感觉，工作了这么几年，又回到了测试的原点。下一站将会如何，真是不知道，听老天爷安排吧！！！

   任何东西都不可能是十全十美的，只能是相对的；工作的道路也不可能是直直的，它也会有山坡，爬山的过程很辛苦、很辛苦，但爬到山顶看到下面的风景，感受爬的过程，是非常的开心；很可惜，老天爷总是不让人永远的停在这个山顶，总是催着你向前走。前方的道路如何，掌握在自己手中。祝福我的领导在将来的工作道路上能走的开心，也希望我能找到适合我的公司。

   今天写的随笔，思路比较乱，也许是今天的心情比较乱、也比较忧郁！！！！！

5 月份测试的一个项目由于需求变更频繁，修改新需求出了些小事故，一直很想记录这件事情，但由于 6 月份忙于找合租房子，就一直没有记录；如今回忆这个小事故，想记录记录，让我想起了收费系统；好快， 8 月份来了，今年的收费系统的性能能否经得住考验，心中有些牵挂。离开这个系统就快一年了，不知道它运行的好不好。

也许有的人认为用这个题目来形容测试工作有些夸张， ^_^ ，之所以会起这个题目，是因为我当时有这样的感觉。

回头看，事情是这样的，这个系统业务、功能不是很复杂（嘿嘿，对于我来说），但需求给的不够细（应该说用户不知道这个系统具体能帮他们实现什么，但是他们需要这样的系统来便于管理），等到系统做出来后，刚测试好，就马上要上线了。期待啊，这是大家的心血，加班那么多天赶出来的软件，就要开始用了，这是部门内所有成员的第一次合作成果。第一步的业务功能用的反馈效果还可以，用户提出的多是字面描述上的修改。第二步的业务功能在使用的前两周，用户突然提出了很多新需求，并且要求在短时间内修改好，不影响上线使用。

就这样在短时间内，在开发人员人力紧缺的情况下，解决这个新需求后的程序提交测试后，出现了很严重的问题。离上线的时间越来越近，开发人员、测试人员就像医生在手术室里抢救生命，过了用户的使用期，这个系统做的再好那也用不上了。终于在早上的凌晨，系统的严重问题都已经解决，可以顺利上线使用，身心很是疲惫，还好的是大家辛苦的付出，软件还是活过来了。

出现这样的现象，原因是：新需求的修改策略出现了失误，开发人员过分的修改了程序。这更一次提醒了我，工作一定要把握和认清楚自己的目的和范围，一定要做适用的工作计划；只有这样工作才是有效率的。对于领导安排的没有做过的高压力工作，可以接受，但是要提醒领导自己的能力和情况，不要对结果抱乐观，自己只能是全力以赴的去做。

做测试工作很累，因为要站在不同角色来思考和测试所开发的软件；站在技术支持人员的角色，就希望软件容易维护；站在用户角色，就希望功能使用简单、好用；站在测试人员的角色，就想知道这样的设计会出什么样的问题等等。除此之外还要想办法使用有效的方法快速测试软件。

做测试管理工作也很累，因为想要带好队伍，把队伍发展好、管理好；要做决策，要承担决策的风险；心里压力比较大。

其实干哪一行，想干好，都很累，为什么那么累了还一直充满热情的做下去，也许就是因为爱好，它能激发人本身所不知道的潜能。

编写背景：

工作所在的部门启用了新的绩效考核制度，也开始了我参与对测试人员的工作进行绩效考核这一管理活动，第一次的考核结果让我有很多的感想，因此今天把它记录下来，也许突然有一天回头看这一感想，又会是另外一份心情。

思考：给测试人员进行绩效考核的目的是什么？

经过思考，我总结的答案是：

1、  为了了解工作情况，如：工作进度、工作状态。

2、  对每个人的工作进行评比，夸奖好的，批评差的。这个看起来有点像在学校上学时候的考试。

思考：有了这样的绩效考核目的，要用什么样的方式、方法去实现呢？

怎么样的绩效考核方式是最有效的呢？

对于现在的我，在现在这个小公司要想做好这个绩效考核，真是要好好思考。

1、  不同的工种，不能用同一种考核方式。如：测试人员的考核方式就不能和开发人员的考核方式相同。

2、  不同工种的考核结果是没有可比性的。如：测试人员的考核结果和开发人员的考核结果进行对比是没有意义的。

以上这两点不知道我的领导是否认同，还需要等到下一次考核的时候和他沟通沟通。

这是工作以来，第一次站在一个管理角色去思考、去做绩效考核这个工作。这第一次的考核工作让我不知道用什么语言来描述我的感受。

考核的结果是：测试组整体的分数都比开发的低，从排名和等级划分上可以说是包尾了。从分数上看，我的第一感觉是：难受。第二感觉是：生气。在和领导进行一系列沟通后，在回家的路上一直在思考、分析着这个结果，问题出在那里呢？问题出在那里呢？？？？？冷静的思考后，自己安慰自己，原因应该是这些吧：

1、  这次开发人员和测试人员使用的工作考核方式是同一种考核方式。

2、  这次把开发人员的考核分数拿来和测试人员的进行排名对比。

很显然，一直这样下去，测试人员的工作即使在怎么努力、分数超过开发人员的机率会很低很低，这样的对比规则，对测试人员来说，很不公平。这样的对比规则，很没有意义。更让我郁闷的是，面对这样的现象，我想不到很好的解决方法，目前只能鼓励测试人员加强自己的综合能力，自己给自己争气，对我来说，在测试人员的管理工作上，无形中出现了一个困难，只能是乐观面对了。

唉，工作种类不一样，放在一起作对比，永远说不清。

测试人员的工作，开发能作么？开发人员能写好测试需求、测试计划、测试用例、测试分析报告文档么，先不说写好，先说会写么？开发人员知道怎么样去执行测试么？知道发现 bug 应该怎么有效正确的去描述么？怎么快速有效的发现程序的问题么？能把握好整个软件测试的质量和进度么？测试，说的简单，真正做好没有这么简单。就拿黑盒测试举例，测试项有：业务流程测试、功能测试、安全性测试、性能测试、数据测试、用户友好性测试、配测试、兼容性测试。这些测试项所使用的测试方法、测试点，都能想全了、想到重点了么，想到了还只是第一步，真正要去执行测试的时候，测试环境的搭建、测试用例的编写与执行、 bug 的描述以及错误等级的正确划分、 bug 的回归、用测试工具进行测试，对测试工具正确有效使用的把握，这些对开发人员来说，会做么，能做好么？测试工作也有很大的工作压力，面对一个不熟悉的软件，面对一个什么说明文档都没有的大软件，要在最短的时间内，最有效的完成测试，要保证产品在发布后，不出现严重的问题，想尽一切办法的发现严重问题。这种对软件质量上的责任压力是很重的，还有其它我就不举例了。

开发人员的工作，测试能作么？测试能看懂开发人员的代码么？测试能写代码测试开发人员的程序么？测试能明白理解开发人员是怎么开发的么？测试能明白开发人员所说的工作术语么？测试能看明白开发人员的开发成果么？开发人员的工作也有很大的压力，要在最短的时间内编写出质量高的代码，实现功能，还要进行一遍又一遍的调试，需求一变，又要修改代码，自测时，发现问题，要进行调试找原因和解决方法，容易么？不容易。测试人员发现的问题，还要去找原因要想最好的解决方法。容易么？不容易。

我很同情那些把测试和开发放在一起作对比行为的人，因为他们对这两个工作中的其中之一理解有所欠缺从而导致这样的结果。说了那么多，好像扯远了。

最后，我得出这么个结论：这样的绩效考核方式，对测试人员来说，起不到激励作用。如果碰到不能正确心态去理解的测试人员，反而会起反作用，很打击工作积极性。因此领导在问我意见的时候，在不适合的说话时间、说话场合我只能说“无所谓”，心不甘情不愿的无所谓！！！！！！！！！！！！！！

自从10月份换工作到现在，工作心情发生了很大的变化，工作总结都没有整理，原因之一是没有安静的心情，二是没有很完整的时间来写。本来不打算写这个工作总结了，但还是不自觉的敲起键盘来，也许是因为这个周末就要回家过年了，在回家之前，还是想写下一些东西，记录下一些东西，因此便有了这篇随笔。

我的2005年10到12月份个人工作总结

一、工作内容

2005年10月份：

第二周：整理武汉出差回来的文档，写出差总结报告。

第三周：完成二代身份证读卡器回归测试，编写最终的测试分析报告。

第四周：办理辞职交接手续，到新公司报到，了解新公司的国内酒店预订系统。

2005年11月份：

第一周：熟悉国内酒店预订系统，编写相应的测试需求文档。

第二周：编写国内酒店预订系统的测试计划，测试国内酒店预订系统，提交简单的缺陷报告。

第三周：回归测试国内酒店预订系统，提交简单的缺陷报告。

第四周：办理辞职交接手续，到新公司报到。

第五周：起草知识共享平台建设规划，参与审核项目开发部建设规范文档，bugzilla培训文档。

2005年12月份：

第一周：

1.         完成部门质量记录文件编写：项目申请、变更、完成单格式。

2.         修订bugzilla培训文档。

3.         编写部门软件测试规范文档。

第二周：

1.         完成《食品标签证书影像管理系统使用说明书》的修订。

2.         完成用VSS搭建知识共享平台，并归档相应内容文件。

3.         完成软件测试规范文档的编写，提交内审。

4.         组织相关文档的内审。

5.         参加公司相关培训

第三周：

1.         审核食品标签影像管理系统的质量文档并归档。

2.         根据评审意见，修订软件测试规范文档。

3.         管理部门质量记录文件。

4.         审核母婴频道的质量文档。

5.         数字认证服务系统测试准备。

第四周：

1.         食品标签证书影像管理系统文档归档，进入质量管理。

2.         母婴频道文档归档，进入质量管理。

3.         修订数字证书的测试需求。

4.         数字认证服务系统前台测试。

二、经验和教训

关于测试工作：

这四个月，测试的主要工作有：

1.         二代身份证读卡器的回归测试，编写测试报告。

2.         国内酒店预订系统的测试，编写部分测试文档。

3.         数字认证服务系统的测试。

这段时间的测试工作，还是停留在原先的基础上，没有很大的突破。这就是换工作付出的代价。

关于质量管理工作：

1.         用VSS搭建了知识共享平台，等待审核。

2.         编写了部门的软件测试规范，等待审核。

3.         编制了部门项目开发的质量记录文件：项目申请、变更、完成单，已经审核通过。

4.         编制了使用说明书编写格式，等待审核。

5.         编制了质量管理记录文件：知识共享平台接收文件确认表。已经审核通过。

6.         完成食品标签影像管理系统现有质量文档、文件归档。

7.         完成母婴频道系统质量文档、文件归档。

第一次做质量管理工作，可以说是一头雾水，在学习、实践、摸索中。

优点：很有工作激情。

缺点：

1、没有系统的学习过，没有很好的理解全流程测试理念，没有很好的实践经验，想做个真正适合公司目前阶段的质量管理，怎么去管理好，真是思考了1个多月还是没有进步，书到用时，方恨少啊！

2、数字认证系统的质量管理有问题，表现在：

Ø         需求没有确定的情况下进行开发和测试，导致后期测试中发现的问题很多。

Ø         开发没有按照开发规范进行开发。

作为质量管理的我，没有及时向技术负责人反应，没有向部门领导反应，没有很好的提醒开发人员，很是失职。应了那句古话“吃一欠，长一智”。

关于公司：

离开了工作快两年的公司，心里的感激多于抱怨，对身份和收费这两个系统的测试经历时时还会回忆和想念，对这两个系统还会有着牵挂，毕竟投入的工作热情和感情太多，成为了我测试工作生涯中一段美好的回忆。离开了，只能祝福公司将来会好起来。

离开了工作快一个月的公司，心里最多的是对它的抱歉，这就是有缘无份。

现在的公司，我非常的珍惜，因为找到了志同道合的开发团队。心中有太多的感叹，看哪天有心情好好总结一下和大家一起分享。

关于自己：

引用同事的一句话“冲动是魔鬼”。我这次就是冲动的辞职，心情在这四个月里发生着变化，到现在的平和。

这段时间的心情就像“我要飞得更高”那首歌所唱的一样。

写到这里，感觉这都不像总结了，有些分心了，就写到这吧。

   到新公司工作有1个半月了，在这里工作很有趣，每次做完的工作，部门内部负责人都会进行审核，指出其中的不足和问题，让我看到了自己的一些不良习惯，就在前几天，突然感悟到，在这里做工作就像学生写作业，因此就有了这篇随笔。

                      做工作就像学生写作业

    时间过的真是快，2006年来了。这段时间，虽然很忙，但过的很充实。2005年的最后一天，北京下雪了，在回去的公交车上，看着夜景，听着MP3中传来的歌声，回想2005过去的一年，回想着最近的工作，突然感觉到，现在做的每一项工作就像大学里写作业一样，对安排下来的工作，尽自己所能得去做。

    这次换工作，很担心自己担任不了新的工作岗位，现在想想自己的担心真是多余的。：）开始的前两个星期还不能适应从一个执行者转换到管理者的角色，在没来这里工作之前，我所做的测试工作成果，部门领导从来没有人进行审核，应该说是正确有效的审核。现在，做的工作都需要审核，这才发现自己工作上存在的问题，开始一点点改进，受益匪浅。

    领导审核工作，就像大学里老师改作业一样，每次都会发现问题，作业是不是认真做，作业做的是否正确，仔细审核就可以知道了。这是自己做测试以来，第一份和管理者角色最近的工作，现在既要带人，又要去执行工作。感觉和以前还真是不一样，当自己是一个管理角色时，就像一个老师，要给自己的学生安排合适的作业，要安排自己的时间去指导和审核作业，当一个老师真是不容易，光有理论，没有实践，还很难服人，只有实践，没有理论，又很难把工作质量往更高一层发展。没有好的沟通能力和表达能力，学生会听不懂你说什么，做一个管理者真是不容易，要很好的去把握时间+工作重点+有效的沟通+工作方法+责任。一个老师不能正确有效的批改作业，那么可以说这个老师不合格了，需要继续进修才行。

    相比之下，做一个执行者角色就像一个学生，轻松多了。只要认认真真的去做，不会不懂的时候，还可以请教老师，当然，能养成自学的能力那是最好的了，因为自学能力永远不会被淘汰。有更多属于自己的时间，承担的责任没有那么重。

    嘿嘿，我就在这两个角色中来回变化着，让我又体会到了测试工作中新的乐趣：

      1、作为老师，当学生在你的指导下取得进步，那是一种成就感。

      2、作为老师，在指导的过程中，学会了另一种知识，那是另一种收获。

      3、当老师和学生共同完成一项任务时，体会到了团队的力量。

    也许，正是因为体会到了工作中的乐趣，让我更加的喜欢自己的工作和职业，也许，就是因为喜欢，才会激发我心中的热情和激情。做测试两年了，我还是那么喜欢这个职业，2006已经向我走来，在这新的一年里，我能收获什么，真是让人期待！！！！！！！！！！

编写背景：

一直以来都不太想把技术方面的文章写出来给大家看，一个是怕写作功底不好误导哪些刚入门的测试同行，自己的表达能力有限，另一方面怕有的同行拿出去炒作，再者测试网站论坛上关于测试用例的资料已经实在是多。但是看到同行纷纷都在问我测试用例的问题，都很想知道我写测试用例的心得体会。我就抱着试试看的心态写写吧，希望测试的老前辈看见了，可以给我多提提建议。

　　　　　　　　　　编写测试用例方法心得体会

在我的个人邮箱和MSN上，通常同行都问我类似下面这样的问题：

１、一个测试用例要写到什么程度才比较好?

２、刚开始做测试的时候，你是怎么学习写测试用例的？

３、你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

对于测试用例，而我目前正在思考的问题是：怎么写出对公司有价值的测试用例，对公司来说，怎么测试才是最有价值的测试？

下面先来分析第一个问题吧：一个测试用例要写到什么程度才比较好？

这个问题，没有定语，没有说是在什么样的一个情况下，因此我这里只能就我工作中碰到的情况说说了。说起来比较长阿，大家要有耐心看才行哈。^_^

在我测试工作中，碰上的测试类型我自己划分成这么４种：项目的测试，产品的测试，产品个性化的测试，第三方验收测试。项目的测试指的是我所测试的软件是一个项目，是某一个具体用户使用的。产品的测试指的是我所测试的软件是一个通用产品，是供很多用户使用的。产品个性化测试指的是我所测试的软件是某一用户在使用产品时，提出了特殊的功能，针对这些新功能，对产品针对用户进行了个别修改。第三方验收测试大家都应该很熟悉了，这里就不需要做解释了。

对项目、产品的测试，测试的时候通常要考虑这个项目的周期和测试资源。我所在的公司，通常项目开发时间都很短４到５个月，然而测试通常都是在开发即将结束的时候才真正介入。测试就是１个人负责。因此时间和人力资源对测试来说是完成测试工作的一个风险。为此在这种情况下，我都是先熟悉系统的业务，把握重点业务和功能后，参考需求，把测试需求、测试计划和测试大纲给制定好。由于时间关系，测试用例都是先写重点的业务，也就是集成测试的测试用例。另外测试用例是根据测试大纲来的。通常都是先挑最重要的测试项和风险大的业务功能编写测试用例。由于测试用例是本人执行，所以测试用例可以写的简单些，但是一定要开发人员能够看明白。可惜我所在的公司，都没有人来看我的测试用例。测试用例对我来说是用来提示我不要忘记了要测试哪些项。一些很有价值的ｂｕｇ通常不是在写测试用例的时候发现的，而是在测试软件的过程中，我在家睡觉前的思考和回家的路上思考出来的。这就是手动测试的魅力，有些软件的缺陷是在你使用软件的一瞬间和思考的一刹那突然发现的。所以要我回答测试用例要写到什么程度才比较好，我觉的只要你所写的测试用例在你的公司能够顺利的执行，不影响你的测试执行工作就可以了。因为测试用例写的太详细，你要花费时间和人力成本，这样出来的测试用例是最好的也是最贵的，一旦需求变更，也需要修改，这时你会发现这种详细的测试用例是最不挣钱的。测试用例写的太粗，别人看不懂，不能执行，那你要花费你的时间去解释，这就加大了测试的工作量。这也不是好的方法。

第二个问题，刚开始做测试的时候，你是怎么学习写测试用例的？

我之所以选择测试这个工作是因为：我毕业后，在第一家公司做技术支持，产品的问题很多，导致技术支持工作很辛苦、很累。为了让用户买到的产品的质量是好的，我选择了做测试，到了现在的公司。我刚做测试的时候，对测试一无所知，什么测试流程阿、文档阿都不知道，公司的测试和管理也不规范。对测试，大家都认为不就是拿个鼠标点来点去，谁都可以来做。为此，我经常上网查测试的资料，看看自己到底适合不适合做测试，测试到底是什么样的一个职业，怎么去规划自己的个人发展。其实要做好测试，真是不容易。不喜欢，真是不能做这个职业。

现在想想自己刚开始写测试用例的时候，真是好笑。就像小孩子学习写字一样。先是在网上狂搜索了一把测试用例的模板，综合了几个，就形成了。我之所以不用公司原有的测试用例模板，是因为太不适用了。还好，公司没有严格要求必须要那个模板，只要适用就行。模板找好了，可是写就费劲了。对于刚做测试的新人，看似简单的一个填表工作，要写好真是不简单。一开始写的比较不自然，有些生搬硬套，而且还很慢。没有办法，那时候没有人指导我，全靠自己自学和领悟，所以那段日子很苦阿！多写几次后，就知道和领悟了，测试用例要根据测试大纲来写，测试大纲要根据测试计划来写。测试大纲更多的是把握住测试项的方向，而测试用例是指导怎么去执行测试。还好，我有编程的经验，所以对我熟悉软件帮了一个很大的忙。熟悉了软件的业务才能去写测试用例，才能更好的去测试。这也是我一点一点的领悟出来的。说了这么多，不知道这样的回答是否是回答了这个问题。

最后一个问题了，我尽量少写些，文字太多了大家看的也累，我写的也累。嘿嘿。^_^

你对黑盒测试用例的编写的体会是什么？有什么好的版本或者标准吗？

我的体会：

１、测试用例要根据测试大纲来编写

２、测试用例也要分测试项进行归类，这样比较好分析和阅读。如：业务流程测试、安装测试、功能测试、用户友好性测试、兼容性测试、性能测试、安全性测试等等。

３、编写测试用例要考虑各种情况，精力主要集中在软件的主要业务流程和风险高的地方。能分出测试优先级别就最好了。

４、熟悉系统，对编写测试用例很有帮助。

５、即使对测试很熟悉了，在时间非常紧的时候，编写测试用例还是很有必要和好处的。

今天就想到那么些了，以后想到了在补充上了。我把我用的模板给你们粘贴一份上来，只能给你们做些参考，具体还是要看对你所在的公司适用不适用。测试项的归类我就不列举了，因为每个公司的都不太一样。

关于工作：

这个月的工作主要是收费系统的现场用户技术支持。

在这些工作中存在如下优点和缺点：

优点：    面对用户，沟通能力、协调能力有了提高。表现在碰到问题时，解决的速度快了。

缺点：在工作中，外貌上看起来像学生，工作起来却不像学生。第一影像容易让人误解。

关于公司：
这个月，听说公司发生了翻天腹地的变化，可惜在这动乱的日子里，我还是在外地出差，还是没有感觉到公司的气氛如何。

关于自己：

工作还是那么的忙碌和辛苦，已经开始麻木了。还好，还是坚持到了最后，战争终于结束了。经历了这次出差，人变的成熟和现实了一些。

这个月，没有看书、也没有学习。就想好好的休息休息，调整好心态。

 三、下个月计划

1、武汉用户收费系统回归测试。

2、编写收费系统使用说明书。

3、学工系统测试。

4、更新个人的简历，公司不行的话，考虑换个环境开始新的工作。

----记录2005武汉出差

编写背景:

   在这繁忙的8月中旬,要去武汉出差了,这次任务很重,能尽力准备的都准备了,然而还是发生了我不想碰到的场景,工程在现场实施的时候出事故了.在这里记录下这段经历,自己以后有空还可以回忆当时的情景.

8月,又是一个繁忙的月份,刚升级完一个用户的系统后,就匆忙的赶往武汉对下一个用户进行系统升级,去之前,把能想到的,都想了,把系统能测试到的都测试到了,面临的就是用户的使用了.升级非常成功,试用也很正常.等到用户真正全面的使用时,前一个小时是那么的顺利,让我的心放下来了.然而在这一切看起来是那么的风平浪静的时候,突然系统出现问题了,50个用户开始出现相同的问题,业务处理开始缓慢,缓慢,缓慢,到最后系统不工作了.用户开始抱怨,开始紧张,这时的我只能打电话和负责人联系,其它人也开始给我打电话,现场气氛十分紧张和严肃,我的电话一直在响,用户一直在喊叫,真是头疼.大家都在问同一个问题:好好的系统,前一个小时,使用还正常的,现在怎么不行了呢?我的第一个反应就是让负责人查原因.赶紧查原因。最后才知道是系统的性能出问题了。这次事故，给公司的声誉造成了严重的影响，用户不在那么信任了，工程的验收将会受到影响。

最可怜的是我，在现场面对客户的质问和批评，无言以对。只能默默忍受和等待系统问题的解决，同时对她们道歉。我是一个做测试的工种，但是同时还要做技术支持。真是一个地道的民工。

事情发生后，我好好分析了一下，原因是公司不重视测试造成的。这次系统没有经过性能测试就直接到现场，其实公司也没有性能测试的环境。所以呢，当然是存在风险的了。我在来之前就已经声明和警告了，仍然不重视。发生这样的事情，也是件好事，让公司明白测试很重要。一直以来，公司没有专门的测试部门，没有完善的测试环境，其实说白了，对测试就是不看重，只有我自己看重我自己的职业，测试在公司的角色就是用来发现有几个严重问题。我一直在忍耐和期盼有所改进，如果这次还不重视，我看公司的测试将不会有所发展和改进了，我想，明年我也要考虑到其它公司去寻找新的发展了。毕竟，现在公司的测试对我来说已经不适合我了。一想到性能测试、测试团队建设和管理，公司没有这方面的资源，没有这方面的环境，主要还是没有意识到，没有重视到，只能靠我自己一个人，这样的力量太弱了，进步太慢了。等到那天公司重视了，明白了，我想测试才能发挥它真正的作用。嘿嘿，一向主动的我，我不想去等了，我对公司的测试已经不抱希望了。

事情发生后，让我又再一次的分析公司的管理机制，想想自己要选择的下一家公司要注意那些问题，想想自己目前的条件，那些公司适合自己能够更好的发展。要想到好的公司发展自己的职业，自己还需要学习那些东西。

这次出差非常的辛苦，每天都是8点出门10点进门，周末也没有得休息，现场项目的主要负责人又不负责人，只会欺下瞒上。刚开始，弄得自己的心情非常的不好，现在已经训练到了可以忍耐和应对的地步了。这都是被逼出来的。还好，客户看我那么辛苦和负责任，还经常会慰问我，关心我。虽然出现这样的事情非常生气，对我发了很大的火气，但是至少她们的关心多少让我心里暖和些，舒服些。

多碰些事情，多长些见识，自己心里的承受能力也在一点点的成熟，以前别人说我所测试的程序那里不好，我会很难过，很伤心。嘿嘿，现在不会了，现在我会分析为什么她们会说不好，出现的问题，我那里没有测试到，为什么没有测试到，找到原因后，是自己的就积极改进，不是自己的，心里知道就行了。

现在的我已经不是一年前的我了，对测试这个职业又有了新的认识和体验。

编写备注：
        7月份到8月初一直很忙，没有时间也没有心情来整理这个7月份的工作总结。直到这两天，刚把收费的升级程序测试完后，是该好好整理这个工作总结了，不然8月份很快就要过去了。这是一个迟来的工作总结。

一、       工作内容

工作时间：第一周

工作内容：

测试：

任务1：新版本收费系统第二轮测试。

其它：

会议：参加学工管理系统设计业务流程分析讨论会议。

工作角色：独立完成

完成情况：成功搭建测试环境，第二轮测试完毕，但没有出测试分析报告。

参加会议花费了一个半工作日，影响了收费系统的第二轮测试进度。

工作时间：第二周

工作内容：

测试：

任务1：提交收费系统第二轮测试分析报告。

任务２：进行新版本收费系统第三轮测试。

工作角色：独立完成

完成情况：提交第二轮测试分析报告。第三轮测试正在进行中。

工作时间：第三周

工作内容：

测试：

任务1：新版本收费系统第三轮测试。

任务2：提交收费第三轮测试分析报告。

工作角色：独立完成

完成情况：测试完毕，提交测试分析报告

工作时间：第四周

工作内容：

测试：

任务1：新版本收费系统项目组程序内部连调测试、圈存机测试。

其它：

电话支持：关于身份系统问题解答

工作角色：独立完成

完成情况：完成内部连调，圈存机只做简单测试。

二、经验和教训

Ø         关于测试工作：

这个月的测试工作主要是收费系统的回归测试：

在收费系统的测试工作中存在如下优点和缺点：

优点：

学会搭建收费系统的后台测试环境，表现如下：

Ø         会装Sco Unix 操作系统、收费后台程序的拷贝、安装。

Ø         收费后台程序的更新。

缺点：

1、收费系统第三轮测试中发现在第二轮测试中没有发现的问题。

原因：最根本原因是，没有充足的时间去完善收费系统的测试用例。１个人要做太多的工作，由于没有完善测试用例，导致有些问题应该在第二轮测试中应该就可以发现的问题，在第三轮才发现，大大增加了修改ｂｕｇ的成本。

对策：改进回归测试策略，尽可能的完善测试用例。

2、收费系统第三轮测试中发现开发人员修改ｂｕｇ代码的质量是下降趋势。

原因：进入第三轮回归测试后，开发人员处于疲惫状态，其中一个开发人员自测开始减少，修改好的代码多次覆盖，已经修改的ｂｕｇ在次出现，同时引发出新的ｂｕｇ。

对策：项目组内测试协同开发进行内部连接调试。

这种对策对测试人员的忍耐能力来说是一个考验，因为内部连接调试版本提交会很频繁，很难把握程序质量，人会很容易出现疲惫和厌烦状态。建议一般在ｂｕｇ错误数据不是有很多非常严重的错误的情况下进行。在ｂｕｇ数据趋于稳定，但开发人员修改缓慢的情况下，进行内部连接调试，以保证项目的工期。嘿嘿，说的更直白些就是测试追着开发的改ｂｕｇ。这个改天找几个同行聊聊这种情况下的对策，看有没有更好的方法。

3、面对这样的开发人员（碰到ｂｕｇ就先去分析责任，而不是查找原因，不会自测），实在是没有很好的能力去调教他。

对策：需要多多请教测试同行碰到这类问题，有什么高招没有。

Ø         关于公司

这个月，公司走了好几个开发人员，公司气氛很是不好，其中收费系统的项目经理是走还是留，成了我关注的焦点，因为我关心我所测试的收费系统。多少也影响了工作心情和效率。这是不可避免的，我是人，我不是神。嘿嘿，还好，最后还是没有走，还是把这个优秀的开发人员给留住了。

Ø         关于自己：

这个月被收费的回归测试弄的很是疲惫，回家就睡觉了，就没有很好的心情和精力看书。呼呼，所以看书的收获得了个超级大鸭蛋。

学会掩饰了自己的一点点情绪，多干活少说话。^_^

周围的朋友非常关心我，都认为工作太累了，是应该好好休息一段时间。

总体来说这个月收获的不大，上个月的学习计划全部都泡汤了。让我高兴的是，同行都非常的喜欢我的blog，而且看了都有收获。

三、下个月的计划

1、要在次温习《有效软件测试》和《软件测试技术概论》这两本书。

2、上班空余时间学习LR工具。

3、测试任务：收费系统回归测试、收费系统升级。

4、文档编写：收费系统新版本安装说明书和使用说明书。

5、其它：学工管理系统需求文档审核，并编写相应的测试需求文档。

编写背景：

7月份非常的忙，也非常的累，身边的测试同行、同事、好朋友都发生了一些事情，大家都感觉自己的精神面貌好差劲。有一天，一个刚开始做测试的同行，看了我的个人blog后问我，做测试，我的快乐是那些？她自己做测试找不到快乐，为了回答她，同时也想知道自己的这个答案，因此便有了这篇随笔。

                        做测试，我的快乐是那些？

刚开始，Susan问我的时候，我只是简单的回答了几点，今天考虑了好久才总结出我对这个问题的答案，不知道其它测试同行是否有和我一样的感觉。一起来看看咯：

做测试，我的快乐是

1、  当开发人员认可我发现的bug很有价值的时候。

2、  当和优秀的开发人员争论bug、分析bug原因的时候。

3、  当我一针见血指出bug错误的原因在那里的时候。

4、  当我能够让开发人员快乐的修改我发现的bug的时候。

5、  当我看见自己测试的软件越来越完美的时候。

6、  当自己测试的软件被客户得到很高的评价的时候。

7、  当自己发现其它人发现不到的有价值的bug的时候。

8、  当发现自己发现bug的速度和质量得到提高的时候。

9、  当发现自己写测试文档的水平在一步一步的提高的时候。

10、在完成了一个很艰巨的测试任务，提交测试分析报告的时候。

11、当发现测试领域里，有自己不知道的知识，拓展了自己思维方式的时候。

嘿嘿，大概就这些了，其它的都想不起来了。以后想起来了，在补充上。

   最近工作很忙、很累，北京7月的天气非常的闷热，就在这样的7月里，工作中碰到了很多事情，特别是在我工作中，沟通最频繁的开发人员，让我不得不在繁忙的时候挺下来思考一些问题，记录一些事情，让自己的心情透透气，呼吸新鲜的氧气，好继续努力。因此就有了这篇文章。

有时候，优秀的开发人员是被优秀的测试人员调教出来的

7月，北京的天气非常的闷热。就在这个闷热的天气，公司走了两个优秀的开发人员，高兴的是，公司把我现在所跟的这个测试项目的开发人员给留住了。经过这么长时间的测试工作，让我体会到：有时候，优秀的开发人员是被优秀的测试人员调教出来的。

记得刚到我现在的这个公司，试用期过后，我就开始测试A软件，这个软件的开发人员编写程序很细心，也很有责任感，心态态度也很好。因为，我在测试他的程序的时候，他设计的界面都很好，考虑到了用户使用起来怎么样会方便，当我发现他的程序的问题的时候，我告诉他，他第一反应是看我怎么操作出现这样的问题的，然后他回去分析程序，用程序进行跟踪，我也帮他分析，我俩配合沟通都非常的好。每次我发现的问题，他认同的会很快的改过来，他不认同的问题会向我讲解他的理由，理由非常的充分，让我很服他不修正问题的原因。我们的关系处的非常好，不像其它同行所说的测试人员是开发人员的敌人。这样一直配合到我们把A软件正式发布了。在这期间他还帮我写些小工具，方便我测试的时候好建造数据。一年半过去了，前不久，他在做其它用户的个性化程序，他都习惯性的先给我看看，看我能否给他找出问题，让我很高兴的发现，他的程序我无法在发现问题了，我只能提一些他有时忘记的用户操作的友好性问题。嘿嘿，他现在写程序的时候已经习惯注意到我测试时经常会发现他那些问题，他经常容易忽略那些问题。因此当他提交给我测试的时候，同样是在一段时间内，同样是个小功能的程序，但是我想尽我浑身招数我都找不到程序的一个bug了，当时，心里既是开心也是心酸，原因是：我不能在测试他的程序了，因为他对我太熟悉了，已经把我测试他程序中发现的问题在他写程序的时候就解决了。他已经在我这里顺利毕业了。以后有机会做白盒测试，兴许可以发现问题。^_^ 写到这里我还在回味着我曾经发现他的那些bug我们一起分析解决的场景。

然而，测试职业的工作不可能总是碰上这么好沟通和上进的开发人员，在工作的过程中，还是会碰上不是这一类的开发人员，那是2004年的7月底，我出差去现场测试B软件了，当时见到项目组新成员，彼此都不了解，第一次见面时，其中一个开发人员见我个子很矮，比较显小，就问我：你是从北京来的？，我说：是的。接着问：你来公司多长时间了？我说：快一年了。在接着问：你来这里是测试B软件的那个功能模块啊？我说：测试B软件的所有功能。他无语。当时给我感觉很是不好。在后来的工作中，我发现他工作很不负责任，自己写的程序不自测，问题很多；写程序不按照用户的需求写、不考虑用户使用怎么方便。所以那段时间，我让他改bug简直是要和他吵架，我可不喜欢和人吵架了，因为我从来没有赢过。嘿嘿，现在想想，当时是平生第一次碰上这样的人，这样的事情。没有经验，没有很好的做好调教这种类型的开发人员的工作，主要还是没有找到很好的方法。后来这个开发人员由于工作不负责任、不好好的干活，公司就让他离开了。当时我心里在偷偷的乐啊，以后不用测试他的程序了。那时候，测试他程序的日子里有时候好怀念测试A软件的日子。

现在测试的这个C软件有两个开发人员，嘿嘿，C1开发人员非常的优秀，沟通非常的好，和A软件的那个开发人员他俩不分上下。只不过他们的性格还是有些不太一样。然而C2开发人员心态就不太好、也没有很好的责任心。当我发现他负责领域的程序出现问题的时候，我告诉他，他第一反应就是没有问题啊，然后我复现给他，然后他分析是不是他的，而不是去找程序是怎么出错的，甚至让我在写bug的时候帮他定位问题出现在那里。在测试人员紧缺和时间有限的情况下，在我看不到原代码的情况下，我怎么去定位问题出现在那个地方。我们之间沟通的时间都花费在了谈论这个bug是谁的问题，这个bug要不要改，就这样花费在了这些没有价值的地方。还好，有了上一次的教训，这次面对C2的开发人员，我心态好好多，已经能平静和正常的对待这样的现象。

    现在经过请教有经验的人，思考采用的方法是：

1、把这种情况反馈给项目经理，尤其在出现争论是否是bug的时候，如果出现分歧可以让项目经理来做判断，或者找他们部长之间进行讨论，不要和他直接产生冲突，因为我们是直接面对的，冲突对日常工作不好。

2、关于他的态度我可以和他说，我们的目的是修改程序，并不是确定谁有责任的事情，告诉他，是不是他的责任，我并不关心，我只关心程序是否好用。让他感觉我们之间并没有什么利益性质的冲突。

   如果有那个同行看了这篇文章后有更好的方法，可以给我回信咯。嘿嘿，小女子在这里先谢谢了。

   休息一下，现在来谈谈最后关于上面这些事情我发出的感慨吧：

优秀的开发人员，当他在发现问题的时候，他会和测试人员一起探讨问题是怎么发生的，甚至测试人员也会问开发人员为什么会出现，这样可以积累双方的经验。下次当他们在进行新产品的研发和测试的时候，开发人员就会知道测试人员会发现怎样的bug，他提交程序前就会给提前改了。那样测试人员可以用更多的时间去考虑那些没有被发现的bug。这样给公司节约不少成本和风险，对开发和测试本身来说都留下了更多的时间去探索更深层的东西。

碰到不开窍的开发人员，测试就要花费很多成本在沟通上和重复验证老bug是否解决上。测试的价值就不能更进一步发挥，时间长了，测试会处于一种疲惫状态，发现的效率会降低，这样对开发和测试都不好。解决方法：只能从人力资源下手了，招人的时候要严格的考核这个人是否真正的符合这个岗位，不然的话，给公司和个人的成本损失太严重了。然而在实际工作中，对于一个开发人员的责任心往往很难一下子就了解，只有在项目中工作中逐渐的发现。

      最后我告诉自己：有度量去容忍那些不能改变的事，有勇气去改变那些可能改变的事，用智慧去区别上述两类事情。