-
[转]职场“三好”吃力不讨好
applejuzi 发布于 2009-12-13 19:56:42
当“好人”前提是做好本分
“三好精神”到底是否适用于职场?人力资源专家、北大纵横高级合伙人王山认为，前提是要先做好自己的本分。
职场生存其实比宫廷还难一些。企业为什么会请你?因为你对企业有用，你和企业之间的关系是市场关系的延续，说的白一些是一种“交换关系”，能否在企业生存是看你的使用价值。职场中处理好人与人关系自然重要，做三好学生也是无可厚非。但现代职场更多考虑的是“任职资格”和“胜任力模型”，即把合适的人放在合适的位置上，而你要把你该做的事情做好，才对得起企业付给的工资，否则无论你人有多好，你的老板(上司)还是不得不请你走人。
职场人士对刘三好精神的反感与当今职场主力80后的强烈的自我意识有关。无论是许三多式的只做不说，还是余责成的左右逢源到大智若愚的刘三好这些榜样，也许代表的是70后的心态。正所谓吃的苦中苦，方为人上人。但对80后们来说，“三好”们只是一些不会干事只会做人的庸人。
“三好”们在企业还是能够生存的，但前提是先做好自己的本分。“三好精神”只能作为锦上添花，而不能成为你上班的主要工作。好事要做，不要影响企业运作;好话要说，但一定要有立场，存好心也对，只要不好心办坏事。
职场是非多，你要做好人?也未必受落!
有“翻版《金枝欲孽》+韩剧《大长今》”之称的热播剧《宫心计》，讲述一个毫无背景的小宫女，磕磕碰碰地走到宫中“高层”之位。主角之一“刘三好”备受争议———她是在宫廷斗争中
“出污泥而不染”的大好人，宣扬“三好精神”：做好事、说好话、存好心，并受到同事上司的赞赏。
获取职场成功之道的途径并不多，榜样中唐骏也好李开复也好，离普通打工仔似乎也太远。所以人们把眼光投向了荧屏上的小人物，从前段时间的《士兵突击》的许三多，再到《潜伏》中的余则成，或者是正在热播《宫心计》中的刘三好，似乎都有着职场精英的影子。做好人可以升职加薪?这一点又在职场上引起热议。在现实中，刘三好这种过于正面的“三好精神”，令在职人士们大为反感，纷纷数落起“大好人”们的种种“罪行”。看来，好人唔易做，往往还会遭遇“里外不是人”的尴尬。
戏说“三好”
王老师：刘三好的成功在勾心斗角的宫廷之中太过“非典型”了!因为非典型，也能给没性格的“老好人”、“非成功人士”有点幻想的空间罢了。
Angle：刘三好能在险恶的后宫生存，除了心地好之外，运气好有贵人相助也很重要。她的“三好”应该换成运气好、人缘好、样貌好才对，不然做多少好事也无法博得“领导”的赏识。
豆豆妈：“三好”其实是个厉害角色。首先她熟悉宫中上下各种人物关系，然后既要上至天文、下至地理略懂一二，又要有一门专业手艺，最后，找个有发展前途的好上司，就不一定循规蹈矩。在关键时候，运用起几样学识，才有“出口救人”的效果。
“做好事”———鹤立鸡群犯众憎
做好事本无错，但每次都大大超过“好”的平均水平，让自己显得鹤立鸡群，反而会变成众矢之的。
Anny在看电视剧的时候，特别讨厌“三好”，因为“她”会让她忍不住想起公司里的一个新同事。Anny是做销售的，每组人每个月会有一定的销售任务，平时各组都有“默契”，步速不紧不慢，反正到月底结算时，都有不同量的超额就好。那位新同事做事积极，样样争先，一进公司就督促组员半个月就完成了当月的销售量，令上司一下子质疑他们原有小组的工作能力。而且，凡是公司有促销活动，无论是否安排他去帮忙，他都会自动自觉跑去做“义工”。Anny抱怨说：平时工作已经够忙的了，结果因为他的“积极”，其他同事也不能“甘于落后”地跟着去促销场帮忙，变相加重了工作量。
有网友在“戏说三好“时认为：“同样毫无背景的宫女出身，三好的姊妹金铃的处事方式反而更加普遍，但因为有三好这样的人存在，对比之下就成了丑角的。”“三好”以做好事博出位，确实容易得到上司的称赞，不过就失去同事之爱，为以后工作埋下阻碍的伏笔。
“说好话”———假好人真小人
“说好话，谁不会呢?最怕是口是心非。”标准办公室女郎沫沫，当了几年经理助理，见过口蜜腹剑的小人太多，现在已经不再相信有“说好话”的好人了。
沫沫的上司相当受公司器重，随之而来巴结的人自然就多。不过，去年公司要裁员的时候，上司差点被“说好话”的同事“淘汰”了。当时公司宣称要适当裁员，要求员工之间互相评分，采取“末位淘汰制”。恰好沫沫上司做的一个较为重要的投标项目没中标，大家就以此为由，只给他很低的分数。讽刺的是，给低分的不乏平时常对着上司说好话的“马屁精”!沫沫感叹道：“平时给你一两句赞美，又没有成本，有什么所谓?但关键时候能‘出口相救’的少之又少。”
另外，常对你“说好话”的人，谨防是小人!跟沫沫一样当助理的小崔，刚入职时不熟悉对处理各种繁琐事情，只好去请教同样做文职的一个资深阿姨。阿姨一边教一边赞小崔天资聪颖之类，让小崔听得飘飘然的，不知不觉地把阿姨当成同事好友，无话不说。边做边学了一阵子，小崔的工作始终未见起色，上司不满意的时候越来越多。有一次偶然发现，阿姨背地里找上司投诉他办事不力，而最终目的是把她的小外甥推荐入公司、顶小崔的职位。
“存好心”———未必有好下场
存好心，最怕是好心做坏事。好事做不成，还让自己遭遇“里外不是人“的尴尬。
刚刚大学毕业的小宇找工作还算顺利。为了尽快与同事搞好关系，对同事们的要求几乎没有拒绝过，有时还主动为同事分担工作，结果在小宇还未能单独做项目的一个月内，他就迅速变成办公室里最忙碌的人。买早餐、吃饭订座、发快递……琐碎工作让小宇自动升级成高级打杂，完全没有时间做他的正职———设计图样。上周日有同事因为要去相亲，想和小宇代班，小宇家里不巧有事就拒绝了她。之后，女同事明显冷落他，甚至背后议论他说：“领导的要求有求必应，同事的请求就摇头拒绝”。小宇觉得委屈：“我帮她是人情，不帮他是道理!”当习惯成自然的时候，你想改变角色定位、不再当老好人就难了。
因为好心而没有了主见的人，更有可能成为裁员的首要目标。在公司里出了名的“老好人”阿辉，工作中他与大家共进退，有困难与大家一起扛;别人说好，他就说好;别人说坏，他就不作声，默默隐匿在大家之中，久而久之他成了老板视而不见的隐形人。公司不景气，老板有意裁员，却首先想到了他。有星级酒店的人力资源人士表示：职场中的“老好人”，事实上最终将成为一个碌碌无为的人，他们在职场中总是因为分担了别人的工作而使自己职责范围内的工作一团糟，而且大部分人从来不敢表现出自己的想法，表达出自己的态度，相信这样的人在职场上是永远都不会有突破，永远都不会成功。 -
【转】测试的价值不仅仅是找bug
applejuzi 发布于 2009-12-06 20:48:21
在我测试工作的前5年，一直以为测试的目标和价值就是在黑盒测试活动中找bug，以找到bug越多越自豪。但当我随着商业意识的不断积累，跳出测试的视角，站在公司的角度看测试时，会发现测试的目标是商业成功，而不仅是找bug。商业成功的关键是什么？简单点说就是可以长期地稳定获得大量的客户并获得足够的利润。而要想长期稳定的得到客户的喜爱，就必须提供让用户满意的质量，这是测试找bug的初衷。可是商业成功要解决的“大量的客户”，“足够的利润”，如何由测试来保障呢？“大量的用户”的获得有时关键就是看谁的产品先推向市场，先占领市场。因此一个词“TTM——Time to Market”就是非常重要的，测试应该支撑项目在满足质量目标的条件下能及时地推向市场，而不是拖延产品的发布进度。“足够的利润”就要确保成本越低越好。减少研发人力：减少开发人力和测试人力；减少研发时间：减少开发修改bug的时间和减少测试活动时间；就能帮助产品减少成本，提高产品的利润。
项目成功的铁三角：质量，成本，进度。每一个关键因素都需要测试人员来做出贡献和支撑。如果仅仅只找bug，可能只支撑了质量，甚至有时也并未真正保障了客户想要的质量。那么测试如何支撑项目成功的成本和进度呢？这时需要的就不仅仅是自动化测试，虽然自动化测试能起到一定的效果。但更需要具有商业意识的测试领导者，站在公司的角度思考选择做正确的测试决策。
下面就以一个案例来证明测试如何更大地发挥其应有的商业价值：
如果一个项目有10个功能：3个功能支撑性能，3个功能支撑可靠性，2个功能支撑可用性，2个功能支撑基本功能。（客户最关心：可靠性，不太在意性能和可用性）
测试如何支撑项目获得更短的研发周期和更低的研发成本：
反面案例：
一个测试思考简单化的测试经理，可能要求10个测试人员进行10个功能的全面测试。1个测试人员的生产力为：1个功能需要10天测试完成，1天发现1个bug。10个测试人员用了10天时间完成了测试，并在每个功能发现了10个bug，一共100个bug。
1个开发人员的生产力为：1天修复1个bug。100个bug需要10个开发人员修改10天。
总结：重点功能50个bug，开发人力：100人天。测试人力：100人天，项目用时：20天。
正面案例：
一个真正了解客户需求，理解公司商业利益的测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，用时5天，每个功能发现10个bug，重点功能共发现50个bug。其余5个非重点功能的测试工作量可以减少一半，用时2.5天，每个功能发现5个bug，非重点功能共发现25个bug。开发人员10人，修改75个bug，用时7.5天。
总结：重点功能50个bug，开发人力：75人天，测试人力：75人天，项目用时：15天。
从以上数据可以看到，只需要测试经理或测试架构师多用一点时间来思考，以公司最终目标：“在保障满足客户需求质量的前提下成本更低，进度更快”为自己的工作目标。避免大而全的唯bug论，就可以发现在重点功能质量标准不下降的前提下，可以实现开发和测试都节省了25%的研发成本和25%的研发进度。
测试如何支撑项目获得更高质量的同时有更短的研发周期和更低的研发成本：
测试经理做了如下决策：用10个测试人员，2个人一组重点测试可靠性的3个功能和2个基本功能，每个功能发现15个bug，重点功能共发现75个bug，用时7.5天。其余5个功能的测试工作量可以减少为1/4，用时1.25天，每个功能发现2.5个bug，非重点功能共发现12.5个bug。开发人员10人，修改87.5个bug，用时8.75天。
总结：重点功能75个bug，开发人力：87.5人天，测试人力：87.5人天，项目用时：17.5天。
从以上数据可以发现在同样的测试人力和开发人力情况下，最应该保障的重点功能发现了更多的bug，为原方案的150％，必须重点关注的地方的相对质量得到了提升，而研发成本下降为87.5%,研发进度减少了2.5％。
本文通过一个简单的案例故事，说明了测试的价值不仅是找bug，只要我们测试工作追求科学的思考，而不盲目的干活，那么我们测试执行活动也能在提高关键质量目标的同时，帮助公司降低研发成本，减少研发时间，全面真正支撑公司商业成功所必须的：更快的进度，更低的成本，更高的质量。
希望我们广大测试人员能从平时的测试工具研究使用和测试脚本开发过程中多抬头思考，选择正确的事来做，做到事半功倍。要相信测试人员能创造更大的商业价值，而不仅仅是bug。
注：本文转自http://www.51testing.com/?uid-293557-action-viewspace-itemid-172908
-
2009-9月至10月面试经历
souchy 发布于 2009-11-29 00:34:13
8月初从原公司离职回杭州后，以办理户口迁移为“借口”给自己放了一个月的假。这期间原本想自己先回顾一下测试方面的理论知识，可最后不得不承认，自己不是主动学习的料。
9月初回到杭州，开始正式投简历，第一周磨磨蹭蹭地投了几家，只得到了一次面试机会，第二周开始大量投递简历，中间出现了一周的空档期（估计是投了简历后，目标公司需要一周时间消化和安排），第三周临近结束与第四周就是频繁的面试之旅了。
1. 浙江中控技术股份有限公司
环境状况：有独立的园区，办公环境有些阴暗，所用办公电脑显示器还以纯平为主，测试部门MM占大部分，据其介绍目前有软、硬件测试工程师30多人。
面试过程：首先填写了一份个人信息表，之后按要求在40分钟还是1小时内完成了一份200多道题的心理测试题（注：个人认为主要是测试面试者的性格及智力状况），随后开始了平生最大阵仗的面试（注：5、6个人一起面我）。
面试内容：主要被提问到，为什么离开原来公司？要求介绍以前的工作经历，并在过程中随机提问跟工作有关的问题。
结果/印象：出师未捷！估计主要是我的心理测试结果偏向于活泼（对该测试准确度抱怀疑态度）和跳槽频繁致使失败。
2. 阿里巴巴网络技术公司（滨江总部）【外包面试】
环境状况：有独立园区，而且面积挺大，建筑和设施很具现代气息，两个字形容：气派。
面试过程：首先做了1个小时（也有可能是90分钟，记不清了）的笔试题，然后面试。
面试内容：笔试部分主要是用例的设计、SQL、Linux方面的题目；面试部分主要轮番的被问及具体的工作中的测试设计，问的很细，细到要把所有可能情况都考虑进去。
结果/印象：简直可以用“狼狈”两个字来形容，笔试因准备不足，答的不好。面试中别问及的用例设计内容，又因为以前公司更本不会去考虑那么细，所以常被问的无语。个人感觉该部门在于质量方面的要求非常严苛，黑盒做到如此程度确实值得尊敬。
3. 淘宝网【外包面试】
环境状况：在一座高级的写字楼中，会客环境非常清新简约，两个字形容：时尚。
面试过程：首先是每个人1分钟的自我介绍，然后要求写下包括自己在内的所有面试者的名字（当时就懵了，一个也没写出来），之后按要求完成一份面试题，最后是即兴设计环节。
面试内容：笔试部分主要是平时与电脑相关的使用常识以及一些相关的知识，好些问题蛮偏门的；面试部分主要是一道即兴设计题，和测试没有直接关系，主要考验理解与反应能力，具体题目就不透露了，估计他们长期靠这道题选拔人才呢。
结果/印象：只能用“出乎意料”来形容这次面试，结果可想而知了。淘宝以这种面试来选取平时注意细节，而临场反应能力又较强的人，我可以理解，但是否真能选出测试方面的人才就很难说了。
4. 现在所在的公司
略
5. 恒生电子股份有限公司
环境状况：一座很有特点的写字楼，办公环境很宽广，工作环境很宽松，可以用两个字形容：舒适。
面试过程：首先在大厅填了一份个人信息表，然后被安排直接面试
面试内容：主要通过面试者的自我工作介绍，在其中随机提问，问的问题也相对尖锐，如果回答的不够清晰，面试官会一直抓住不放，直到你给出满意的答案或承认欠考虑为止。最后被问及是否有炒股，是否使用过电子商务购物。
结果/印象：没戏！估计还是老毛病，测试设计没有达到其精细度要求，并对其主要测试业务不了解。恒生给我最大的印象就是“舒适”，在等待面试官召见的过程中，发现他们有专门提供员工休息的场所，并还配有糖果、饼干、咖啡等食品。
6. 天格科技（杭州）有限公司
环境状况：在一座中高档的写字楼里拥有数个不连续的工作间，主要从事网站的开发与运营，据介绍有测试人员10个左右。
面试过程：首先给了一份所谓的笔试题（除了开发知识就是质量知识），拒绝作答之后，他们的一个主管安排我填了一份个人信息资料，然后安排了一个人对我进行测试知识面试。
面试内容：笔试部分只有两道，一道是用例设计，另一道是微软的智力面试题；面试部分被要求介绍了自己的工作内容及经历
结果/印象：只能说面试完之后，我心情很差，并不是因为面试的结果怎么样，而是觉得是浪费时间，连个健全的面试过程都没有，把面试当儿戏。
7. 聚光科技（杭州）有限公司
环境状况：有独立的园区，比较大，不过结构比较传统。据了解其软件测试部门有13人，到国庆之后扩展到15人。
面试过程：填写了一份个人信息表，一份性格测试题，一份测试笔试题，之后经过了测试组长、测试主管、开发主管这三面。
面试内容：笔试部分中的性格测试题挺有意思，如果如实填写，基本能够测试出面试者的性格状况（个人感受：挺准的）；测试相关的内容主要是测试知识、SQL、Linux知识；面试主要谈了以前工作的内容，回答一些与以前工作相关的问题。
结果/印象：通过。该公司主要做环保仪器，软件方面主要做环保系统，待遇不错，三年测试工作经验可以给到6万到7万一年。最后我拒绝了这家公司，一是因为工作地点在滨江，二是觉得在纯软件公司会更有发展。
总结：整个面试过程中，感觉杭州的软件公司对于测试人才的需求还是比较强劲的，不过也主要是面向3年测试工作经验与重点大学相关专业毕业的研究生。随着面试旅程的延续，容易产生妥协心理，所以最好不要选择离职后再找工作；如果已经离职了，也要相信自己，勇敢地坚持到最后。
心得：面试没有通过是因为你没有找到合适你的位置，而软件公司如此之多，必定有适合你的岗位。
-
实践反思更重于测试思想学习
架构师Jack 发布于 2009-10-25 00:20:06
有网友邮件问我，在blog中如此大规模的把自己的核心思想和案例免费分享出来，就不怕大家都理解和学会我的核心思想后，我就失去了竞争力了吗？
其实我并不担心。这些年工作的经验我有一个深刻体会，任何培训活动结束后，学员无论如何也无法在培训内容上超过实践过培训内容的导师。所以，我在辅导我自己的员工时，不希望做培训这种形式，而是用一个的任务实践来让员工们体会到我传授的方法和思想。只有在实战中得到的经验，员工们才会真正掌握。
在一次参加管理培训时，才得知一个人的提升：70％来自实践后的反思，20％来自周围人的影响（导师），10％来自培训活动。所以，古人有一句话：事非经过不知难。如果有某位学习能力很强的人，从我的blog中100％吸收了我的核心思想，那么他能获得10％来自培训的能力。但他要达到我的境界，还需要90％的实践努力。毕竟我从实践中解决各种问题后悟出的真理，是能在我身上举一反三运用，用于解决一个个未来的新问题。
而且我最核心的竞争力是：源源不断产生这些思想的发动机，而不是思想本身，毕竟思想本身还会继续演进的。
最后希望掌握了我目前思想的朋友，可以在自己的工作中多实践应用，不实践你就并未真正的学到了我的思想。也希望朋友们能在互联网上分享你实践后的新感受，大家一人贡献一个苹果，我们大家就能有许多苹果。测试全行业的价值和地位就都能得到大提升！
谢谢那位关心我的网友！
-
高手过招的乐趣---测试用例预演[收藏]
Jon 发布于 2009-11-30 13:58:47
摘要：高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便高下立判，胜者胜得痛快，输者也输得潇洒。然而，除了在武侠小说之内，恐怕很难有地方让你感受到这种“会当凌绝顶”的痛快。本文根据作者在测试工作中的体会，提出了一种被称为“测试用例预演”的方法，用模拟的测试用例执行发现程序中潜在的问题，这种方法究竟有何神奇呢？请见内文。
武侠小说中的高手大抵有三个层次，第一个级别是“静若处子，动如脱兔，身负成名绝技”的高手，印象中这一个级别的基本是杀手或是性情豪爽的江湖侠客，这种人一旦遇到，打杀的场面最为宏伟，刀枪之声不绝，各出奇招，直到一方倒地或是被制；第二个级别是“落叶飞花，片叶支花均可伤人”的高手，这个级别的高手相遇，少了宏伟的场面，却在看似不经意的凝重中展开残酷的厮杀，胜负只在一念之间；第三个级别的高手寥寥无几，多是成名已久、文武双修的名宿，已至“手中无刀，心中无刀”的最高境界，这种高手若是过招，全不闻金戈之声，全无杀伐之意，轻描淡写的以口代手，三两句话便高下立判，赢的赢得痛快，输的输得潇洒，在武侠中看到此，常不免心潮澎湃，艳羡不已，巴不得自己也能有这个机会一尝绝顶高手之间的这种至高默契。可惜身为开发或是测试工程师，又出生在这个真实的世界，恐怕实在是不太会有机会领会这种至高的境界。
所幸，我们虽不能飞进武侠小说尝试这种生活，却能在我们的测试工作中体会到这种乐趣。真耶？假耶？且与我一起，探究个究竟。
回到我们的题目“高手过招的乐趣 —— 测试用例预演”，这里我要提出的是一种可以让你体会到高手过招乐趣的方法：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词（申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的一种方法）。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和更多有高手梦的朋友能够感受得到。
测试用例预演是一种非正式的测试用例执行方法，概括说来，这种方法是无需通过测试用例的真正执行（静态或是动态执行），而只需要开发人员和测试人员之间的口头交流，就能发现被测系统中存在的问题。设想一下，无需动手（测试执行），通过以口代手（开发和测试人员之间的口头交流），就能实现我们的目标（发现缺陷），这不是高手过招是什么？
l 测试用例预演的一般步骤是：
测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候；
测试工程师根据测试用例进行提问，甚至可以临时扩展测试用例，但要注意三点：
1). 不要偏离测试用例太远，以免偏离实际的业务；
2).可以考虑一些在测试用例中没有明确写明的异常情况处理；
3).提问的方式是“如果我这么操作，你的系统会如何反应？”；
开发工程师根据测试工程师的问题，做出应答，对每个问题都只需要回答系统的响应即可，不需要描述具体的实现方法；
测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿不准的问题应该记录并需要马上验证；
双方继续预演直到预期的预演时间结束或是有一方感到疲倦；
记录预演过程中发现的问题到缺陷跟踪库。
当然，要说明的是，参与交流的开发和测试工程师不是比武双方，真正的敌人只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。
测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以FAQ的方式提供秘笈一部，各位请留意：
Q：测试用例预演可以取代测试执行吗？
A：这个问题是我捏造出来的，我想大概不会有人真的这么认为：），不过在这个问题的回答中，我希望能尽可能准确地描述测试用例预演方法的适用范围：如前面所提到的，测试用例预演是一种“虚拟”的测试用例执行方法，因为主要是通过口头交互的形式，也就限制了该方法适用的深度，一般来说，针对业务逻辑的较为直观的用例可以采用这样的方法，尤其是那些涉及大量用户复杂交互的用例，采用这种方法非常有效，测试工程师模拟用户或是设备提出各种可能的正常异常情况，很容易发现程序处理中的漏洞。但是，对于那些需要涉及大量地层处理的用例，测试工程师一般不太可能对其机制了解得十分清晰，因此采用这种方式也很难发现问题。
Q：测试用例预演可以在哪些场合下使用？
A：测试用例预演的应用场合没有特殊要求，但至少要保证是一个适合双人沟通的场合，没有过多的被打扰，双方都处在能积极思考的状态，这样就可以了。根据我的经验，一起就餐、双方暂时没有明确的工作内容，或是在对设计进行非正式评审的时候是一个比较好的时机，但还要充分考虑双方的喜好，譬如，有人不喜欢在吃饭的时候展开讨论。总之，一个适合双人沟通的场合是最低要求。
Q：测试用例预演方法可以用在其他地方吗？
A：中子炮刚发明的时候，科学家们狂热地将中子炮对准任何可以找到的东西；按照这种趋势，测试用例预演方法也必须要考虑是否可以应用在其他地方：）实际上，预演这种方法在评审或是思维游戏的过程中一直都是被广泛应用的，测试用例预演只不过将预演这种方法用到了以往需要真正执行的领域中，除了在测试执行环节，设计评审过程中我们也可以采用这种方法针对设计进行审查，关键在于提问的技巧：“如果我们这么做，你的设计将会怎样反应？”。
Q：好像我用测试用例预演方法很难达到预期的目标？
A：测试用例预演方法并非不需要前提条件，至少要保证以下条件才能使测试用例预演发挥较大的作用：
开发工程师具有良好的配合意识；
测试工程师对产品具有良好的熟悉程度；
提问者的提问必须从“如果我这样做，程序会怎样反应”开始；
参与预演的开发工程师对用于预演的用例涉及的模块要非常熟悉；
其中，测试工程师对产品具有良好的熟悉程度是非常必要的，测试用例预演的主要对象是针对业务逻辑的用例，这就要求测试工程师熟悉产品，熟悉业务。所谓“棋逢对手”，至少要能和开发工程师是一个级别上的。另外，参与预演的开发工程师必须对用于预演的用例涉及的模块很熟悉，如果参与预演的开发工程师是模块的开发者自然没有问题，如果不是，就要求开发工程师必须能够准确了解模块的行为和实现。
Q：测试用例预演发现的问题需要记入缺陷库吗？
A：答案是肯定的，测试用例预演是一种“虚拟”的测试执行，预演过程中发现的问题同样要被记录、跟踪。当然，为了标识测试用例的发现阶段，可以专门在缺陷管理系统中增设一个“预演”阶段，统计预演在缺陷发现方面提供的效果。
Q：如果开发人员不配合，怎么办？
A：这个问题……我只能说具体问题具体分析了。关键是弄清楚开发人员为什么不配合，可能是开发人员个性羞涩，不喜欢这样面对面的交流方式；也可能是开发人员觉得这种方式浪费时间；又或者是开发人员对测试人员抱有不信任的态度。不管怎样，发挥你的个人所长，让开发人员放下顾虑和成见，认识到这种做法能给他和项目带来的好处，自然可以解决这个问题。
Q：还有哪些在测试用例预演过程中应该主要的问题？
A：当然还有一些需要注意的问题，沟通的技巧、对对方反馈的及时分析等等，这些都可以在实际运用测试用例预演方法的过程中逐渐体会。我总结的几点需要注意的问题包括：
对每一个开发人员的犹豫都不能放过，一个犹豫很可能就是一个缺陷隐藏的地方；
如果可能，最好能和开发人员一起，确定那些不确定的问题，以防开发人员一时马虎放过了本来存在的问题；
预演的方式不适合在正式评审会议上应用，因为预演主要是两个人之间的协同思考，在正式评审会议上容易浪费其他人的时间；
预演时要注意记录，头脑风暴产生的火花如果不及时记录的话，很可能会在短时间后被遗忘。
文章出处：csdn.net 作者：关河 发布时间：2005-11-20【作者简介】 姓名：关河，真名:段念，测试时代成员；有数年软件测试经验，先后历任软件测试工程师、软件测试组长、软件测试经理等职。对软件测试技术、软件测试管理，以及相关的质量体系和流程都有较为深入的了解和认识，除测试管理外，目前专注于软件性能测试、白盒测试、开源测试软件方向。
-
google开源工具列表(与测试相关)
liangjz 发布于 2009-11-26 00:15:25
google公司对开源社区贡献了蛮多好用的工具，另外google code上也有一些不错的工程。
部份工具我们已经在应用或者试用。简单梳理下。
Java静态分析可测性工具 http://code.google.com/p/testability-explorer/
profile工具 google-perftools
http://code.google.com/p/google-perftools/
http://code.google.com/p/gperftools-httpd/
Google c++ test 框架 http://code.google.com/p/googletest/wiki/GoogleTestSamples
Google mock 框架 http://code.google.com/p/googlemock/downloads/list
c 语言单元测试框架 http://code.google.com/p/cmockery/
web安全审计工具 http://code.google.com/p/ratproxy/
代码规范 http://code.google.com/p/google-styleguide/
Firefox firebug页面速度测试插件 http://code.google.com/p/page-speed/
Google Singleton Detector http://code.google.com/p/google-singleton-detector/
Selective testing tool for Java
http://code.google.com/p/google-testar/
http://code.google.com/p/google-coredumper/
fuzzing http://code.google.com/p/bunny-the-fuzzer/
http://code.google.com/p/stressapptest/wiki/Introduction
http://code.google.com/p/google-collections/
http://code.google.com/p/powermock/
protobuf网络数据传输格式http://code.google.com/p/protobuf/
http://googletesting.blogspot.com/
http://googleonlinesecurity.blogspot.com
-
需求规格说明书评测规范
shenzhen2008 发布于 2008-06-03 17:58:02
需求规格说明书评测规范
填表说明：Y—是，TBD—不确定，N—否，NA—不适用。
编 号
评 测 项
评测结果
Y/TBD/N/NA
清晰性
1
系统的目标是否已定义
2
是否对关键术语和缩略语进行定义和描述
3
所使用的术语是否和用户/客户使用的一致
4
需求的描述是否清晰，不含糊
5
是否有对整套系统进行功能描述
6
是否已详细说明了软件环境（共存的软件）和硬件环境（特定的配置）
7
如果有会影响实施的假设情况，是否已经声明
8
是否已经对每个业务逻辑进行输入、输出以及过程的详细说明
完整性
9
是否列出了系统所必须的依赖、假设以及约束
10
是否对每个提交物或阶段实施都进行了需求说明
11
需求说明书是否已包含了主要的质量属性，例如有效性、高效性、灵活性、完整性、互操作性、可靠性、健壮性、可用性、可维护性、可移植性、可重用性和可测性（此范围比较广，包括性能指标、需求是否遗漏、重复或不一致的地方等）
依从性
12
该文档是否遵守了公司规定的文档编写标准
一致性
13
需求说明是否存在直接相互矛盾的条目
14
本需求说明书是否与相关需求素材一致
可行性
15
所描述的所有功能是否必要并充分地满足客户/系统目标
16
需求规格说明书描述的详细程度是否足以满足进行详细设计
17
已知的限制（局限）是否已经详细说明
18
是否已确认每个需求的优先级别
可管理性
19
是否将需求分别陈述，因此它们是独立的并且是可检查的
20
是否所有需求都可以回溯到相应的需求素材，反之亦然
21
是否已详细说明需求变更的过程
-
职业发展瞎谈－－跳槽篇
雪儿 发布于 2008-07-21 12:23:01
导演10:29:35
我同事说，人的价值要在跳槽中上升的
雪儿10:29:57
我跳的单位比你多吧。
导演10:30:08
是啊，所以你的价值比我高多了啊
雪儿10:30:48
哈哈，那是我能力比你强啊
哈哈，玩笑话，并不见得我比导演的能力强，或价值高，毕竟能力、价值是放在同等条件下才有得比较的，我们俩处地不同、工作内容不同，价值和能力都无可比性。
不过对于价值要是跳槽中上升，这句话有点不同意见吧。 可能大家都认为价值就是价格吧，价格就是给你的工资吧。 呵呵，资本论中不是提到过，价值和价格不是同一个概念吗？价格受供求的影响。在不同公司之间是如此，比如性能测试工程师，公司招不到，价格就高；同一公司内部也是如此，你在公司的位置是难以替代的，工资就高；如果性能测试工程师变的满大街都是了，我想价格也会相应地降低了。当然由于性能测试工程师本身需要掌握的知识、工具难度较大，价值也高些。这个我不讨论。我只想说说，价值相若的东西，如何价格才能高些。
第一种方式：跳槽。其实最主要的原因是因为公司的绩效考核、工资制度不完善。导致你的能力增加了，贡献大了，工资却一直不长。 这时候，你可能会考虑跳槽了。跳槽时，通过整理简历，面试，你和你的新东家对你的能力做了重新的评估，然后参照行业工资水平，给了你新的工资，应该比原来的高。 这里就引入了另外的问题，你知道自己的能力和贡献吗？你了解过同行业的工资水平吗？
如果答案是是，那你有没有去提过加薪呢？ 如果答案是否，那就现在去提吧。
第二种方式：加薪申请。 先把跳槽的事情放一放。当然，你可以先去面试，看看下家给你多少钱，然后做为加薪谈判的筹码。
你可以比较一下，那种方式更好。如果加薪和跳槽后的工资是一样的，无疑加薪是最好的方式。如果没有得到理想的薪水，你可以对比一下。我记得原来有同事做过这样的比较，列一个表格。
影响因素
旧公司
新公司
分数
备注
工资
5000（加后）
6000
+10
公司性质
私企
私企
0
公司业务
互联网
化工
－7
不熟悉的业务领域
测试部
有测试部（10人）
有测试小组（2人）
－5
测试可能不受重视
发展
1年内无管理、专业方向发展
测试组长
+15
可能会向更高的方向发展
出差。加班
无
有，不长期
－3
看个人了，有人喜欢加班、出差
上班时间
30分钟
1小时
－2
离家远了点
朋友
有好朋友
重新去适应
－5
也看个人是否喜欢了
最好，计算一下，可以比较客观地反应自己是否应该跳槽。呵呵，这是自己随便列的一个表格，举个例子，实际上项目管理中有更加专业的方法的。这里就不列了。
考虑跳槽要注意的几点：1、不要因为某一时刻不开心，就意气用事，走人了。这样往往会后悔，并且由于对旧东家全是牢骚，导致随便找个新东家。跳槽的理由一定要考虑了再考虑，尤其要和生活相结合。 就会婚姻一样，吵吵总是有的，但不能一吵就离吧。
2、跳槽一定要结合自己的职业规划，如果随意找了一家，与职业规划背离，你就要重新规划职业，可能会导致你原来的经历作用大打折扣；也可能做了一、两年后又回到了起点，浪费了一、两年的时间。
还要考虑跳槽太频繁的问题，看下面的对话：
雪儿
10年，不算我分配的单位（不是IT的）
有6家吧
一地风景
基本上 在1.5年
雪儿
其中一家做了不到3个月。
一地风景
那么你去面试时 面试人员对你频频跳曹 怎么讲呢
雪儿
三年－－－三年－－－3个月－－－一年－－－1.5年－－－现在
一地风景
呵呵 那这个你肯定没写到简历中了
雪儿
我没有频频跳啊
一地风景
哦 这么算的啊
雪儿
最少的都呆了1年啊
一地风景
那是 也不算 频频条例
雪儿
3个月的没有写到简历里啊，浪费3个月了。
一地风景
我现在如果工作少于一年 我都不知道怎么给面试管讲
呵呵 那你当时怎么说
对于这种短期的
雪儿
把再上家的离职期延长一点就行了。
一地风景
可是有离职证明的啊
那上边不是又时间的嘛
雪儿
如果你是刚刚从上家出来，又不满一年，就直接说了，总是有原因的嘛。
雪儿
如果是以前的事情，简历上就不写了
从上面的对话中，可以看到，我在一家公司做了未满3个月，还有一家公司做了1年，就走了，这是由于个人的原因，导致职业规划在这里有了停顿。也就是浪费了一些时间，结果在以后找工作的时候，还要花时间去解释为什么呆了这一年；至于3个月的经历，写都没法写。
我自己是不喜欢频频跳槽的人员的，因为无论你呆在哪个公司，都有2、3个月的实习期，业务熟悉了。你要学习和贡献自己了，你差不多却走了。所以较短的时间是很难积累自己的知识和经验的。 而还没有来得及贡献就说无用武之地的人更是说的早了些吧。
个人意见，欢迎板砖
-
静态代码分析工具Cppcheck实践
liangjz 发布于 2009-11-10 21:26:01
Cppcheck是一款开源c++静态代码分析工具,在检测源码时可根据规则就能挖掘出疑似缺陷, 帮开源项目发现的bug有:
http://sourceforge.net/apps/mediawiki/cppcheck/index.php?title=Found_bugs
功能比较强大, 使用很简单
下载安装cppcheck:
http://sourceforge.net/projects/cppcheck/files/
root安装
make & make install
试验环境
在32位linux , gcc 版本为
[liangjz@b2b_plat_1367 ~]$ cppcheck hummock
cppcheck: /usr/lib/libstdc++.so.6: version `GLIBCXX_
转移到如下环境:
[root@b2b_plat_1363 ~]# uname -a
Linux b2b_plat_1363
[root@b2b_plat_1363 ~]# gcc --version
gcc (GCC) 3.4.6 20060404 (Red Hat
可正常运行.
工程实践
cppcheck扫描3个工程发现的潜在问题,并抽部份简单解析,确认有几个bug
388 CDirectoryScan::~CDirectoryScan ()
389 {
390 if(m_findHandle != INVALID_HANDLE_VALUE) {
391 FindClose(m_findHandle);
393 }
394
395 if (m_pSearch != NULL) {
396 delete(m_pSearch);
}
}
402 void CDirectoryScan::generateSearchPath(void)
403 {
402 void CDirectoryScan::generateSearchPath(void)
403 {
generateSearchPath 函数m_pSearch 是new数组, 析构函数为 delete(m_pSearch),
可判断为缺陷.
二
39 bool CMasterHA::amIMaster()
40 {
41 char cmd[255];
42 sprintf(cmd, "/sbin/ifconfig | grep %s", m_serviceIP);
43 FILE *fp = popen(cmd, "r");
44 if (fp != NULL)
45 {
46 int len = fread(cmd, 1, 255, fp);
47 fclose(fp);
48 if (len == 0)
49 return false;
50 if (strstr(cmd, m_serviceIP) != NULL)
51 return true;
52 }
53 return false;
54 }
可看到fp是popen打开,但是关闭并不是采用pclose.
-
阿里巴巴面试问题
shiker2003 发布于 2008-08-25 21:44:18
1.自我介绍
2.介绍一个你所做过的测试项目
3.bug状态的转换，及各状态转换执行人是谁
4.介绍软件测试流程
5.如果你和开发人员出现分歧怎么办
6.如果第二天就到交付日了，回归测试还没有执行完毕，你该怎么办？
7.你有女/男朋友么？你未来如何打算？
8.你还有什么要问我的问题么？
9.我是做功能测试的，功能测试比较枯燥，你怎么认为？
-
软件测试人员应具备的几种思维方式
卧龙公子 发布于 2008-12-10 18:37:11
1、逆向思维方式● 逆向思维在测试中用的很多，比如将根据结果逆推条件，从而得出输入条件的等价类划分
● 其实逆向思维在调试当中用到的也比较多，当发现缺陷时，进一步定位问题的所在，往往就是逆流而上，进行分析
● 逆向思维是相对的，就是按照与常规思路相反的方向进行思考，测试人员往往能够运用它发现开发人员思维的漏洞
2、组合思维方式
● 很多东西单一的思考都没有问题，当将相关的事物组合在一起却能发现很多问题；如多进程并发，让程序的复杂度上了一个台阶，也让程序的缺陷率随之而增长
● 按照是否排序组合可以分为：排列（有序）和组合（无序）；针对不同的应用，可以酌情考虑使用“排列”或者“组合”
● 为了充分利用组合思维而不致于让自己的思维混乱，要注意“分维”，将相关的因素划分到不同的维度上，然后再考虑其相关性
3、全局思维方式
● 事物往往存在多面性，当我们掌握了越多的层面，我们对它的认识就越清楚，越有利于我们掌握其本质，全局思维方式就是让我们从多角度分析待测的系统；试着以不同角色去看系统，分析其是否能够满足需求
● 其实平常我们在软件开发过程中，进行的各种评审，就是借助全局思维的方式，让更多的人参与思考，脑力激荡，尽可能的实现全方位审查某个解决方案的正确性以及其他特性
4、两极思维方式
● 边界值分析是两极思维方式的典范
● 为了看系统的稳定性，我们采用了压力测试
● 两极思维方式，是在极端的情况下，看是否存在缺陷？
● 注意是两极，不是一极
● 测试人员做久了，往往容易走极端——职业病，不利于与人沟通51Testing软件测试网
5、简单思维方式
● 剥离一些非关键特征，追逐事物的本质，让事物简单的只剩下“根本”
● 针对事物本质（解决问题的本质）的测试，让我们不至于偏离方向
6、比较思维方式
● 认识事物时，人们往往都是通过和头脑中的某些概念进行比较，找出相同、相异之处，或者归类，从而将其加入大脑中的知识体系，可能的话，再建立好的搜索方式，以便以后使用
● 应用模式是“比较思维”很常见的例子，现在模式很火，有设计模式、体系结构模式、测试模式、等等，一些专家针对一些相关问题的共性找出来的解决方法，取完名字后，可以让大家方便的复用
● 让经验在这里发挥作用，测试中经验很重要，比较思维是使用经验的方式
7、动起来，更精彩
● 关注程序的运行时状态
● 传统的基于结构的程序可以更多的在代码中反映将来程序的运行方式；而面向对象将代码和运行时显著分离
● 让我们在关注代码静态结构（如类结构）的同时，也要谨慎关注其动态（对象交互网）表现
其实这些思维方式，大家都在有意识或者无意识的使用着，它们各自都有自己的妙处，将我们的思维发散，有意识的将他们用在问题的思考上，有时可以给我们一种“柳暗花明又一村”的感觉。
最后想说，只是知道这些原则意义不是很大，如果真能让它们成为思考的血液，才能发挥它的真正价值。那真的需要很多的历练，其实成为一名出色的测试人员，远没有那么简单，需要简单，需要（不断的学习＋不断的经历＋不断的思考）。
-
测试团队的建设(整理)
Jon 发布于 2008-11-19 16:56:32
有关测试团队的建设，这个话题很大。思考一下，查找一推，整理一把，让自己的工作更有序、更系统，做到有意识的去完成它，并收获工作中细微变化带来的快乐。1 、团队基础设施建设：让自己和其他人都强烈的感受到团队的存在、以及团队的力量，让团队中的每个人都从团队中受益
。我们是一个团队（ team ），并非一个组（ group ）： team 和 group 的最大区别在于“是否存在目标”，目标产生合力，让 1 ＋ 1>2 成为可能；首先确定自己的目标，成为我们建设测试团队的首要任务。我们为了生存，制定短期目标；我们为了发展，制定长期愿景。
－长期目标：
。长期目标让团队生存更长的时间，它能够打发我们的闲暇时间
。长期目标让团队的每个人都感受到希望
。一个设想：让我们成为业界认可的一支测试团队，一支受人尊敬的团队。（也许我们每个人都不是业界顶尖高手，也许我们需要改进的地方还有很多，但我们产生的力量足以漂亮的完成每个任务）
－短期目标：
。我们要独立，自己养活自己，尤其在队伍建设初期
。将眼前的任务完成，或者基于当前任务考虑短期目标
。在完成短期任务的同时，考虑长期目标，一个个短期目标的完成，最终实现长期的愿望，积累在这里显得十分重要
－－目标：是这支队伍存在的根本。
。个人的发展
－角色的划分，职责的确定
。分工的明确，让每个人都知道自己的工作范围，也为绩效考核提供依据
。角色的划分符合团队的长、短期目标，而且划分也需要随着目标的改变而改变
。减小角色划分后的盲区，消除个人的重复劳作
。有了“目标”和“工作内容”以后，每个人都可以发挥主观能动性，自己创造方法将事情做好
－个人发展路线
。确定角色之间的相互联系以及发展顺序
。提供每个角色对应的技能要求，并且给出获得该技能的方法参考
。考虑个人的特点和兴趣，如技术型人才、管理型人才等等
－绩效考核
。确定绩效考核的标准（得到大家的认可）
。确定绩效考核的时间间隔
。将绩效考核与薪酬挂钩
。让直接领导与薪酬支配者共同决定结果
。绩效考核的反馈，让每个人了解领导的意图
。绩效考核的目标：主要是为了其下一步发展，推行好的方面
。绩效考核的关键：公平
。淘汰：为那些停止进步的人准备的
。内部交流
－工具的使用（ RPM、wiki 、 blog 、Confulence、旺旺...）
。通过 web 的方式展示， wiki 方便更多人了解，让更多人参与
。 blog 记录并形成自己的知识库
－沟通模式化：一致的方法沟通，提高沟通的效率，减少沟通带来的误解
－让大家形成习惯
。定期的内部交流，有利于习惯的养成
－不要总是由领导发起
。组间接口（更大的团队中与其他 team 的合作）
－让其他人（包括领导）清楚的知道我们的职责
－和其他团队一起制定组间接口
－我们可以多做一点，帮助他们一起完成工作，但一定要让他们知道我们“在帮助他们”
－宣传我们的思想，赢得更多人的认可
－与领导协商，建立更广泛的沟通模式
。积累：让我们感受到自己的成长，让新人尽快的进入角色
－应用库的建设：我们在做什么，做过什么，让它留些痕迹；方便后来同类项目的完成
－问题库的建设：大量的问题出现，将其分门别类的记录下来，对这些问题的解决过程中，我们自己在进步
－知识库的建设：
。自己的随笔，团队的共同提高，处理某些问题的经验，犯过的错误
。关键要记录下这些知识的适用范围
－使用与维护：
。积累是为了使用，在建设的初期就要考虑到将来使用的方式、以及使用的方便
。一定要有人维护， 3 分建设、 7 分维护一点都不为过；尤其在大家养成习惯之前
。我们的文化，我们的风格
－我选择，我喜欢
。为了适用不同的环境，完成特定范围的任务，我们形成了自己的风格
。因为我们的不同，所以我们存在
。我喜欢轻松的氛围，喜欢能让我集中精力的地方
－让喜欢团队文化的人加盟：物以类聚、人以群分
2 、新人招募
。我们需要什么样的人？这取决于团队目标
。新人对我们的文化认可吗？
。能力与潜力是我们关注的
。沟通真的很重要
。也许也需要一个题库，让招聘规范一点
。告诉 hr ，我们需要什么样的人才
3 、新人培养：新人刚开始需要更多的关注
。培训：
－告诉他需要做什么，需要哪些技能，大家的工作方式，如何融入团队？
－技能让他自己去学，可以提供一些参考方法
－只是一个开始
。学徒与导师：相比培训，工作中的导师的指导更有意义
－让导师清楚指导的意义，认同这一点，并愿意做
－以学徒的成长速度为参考对导师进行考核
－学徒可以寻求其他人的帮助
。用人之长、理人之短
－帮助其认识自己，挖掘他自己的潜力
－帮助他找到自己的位置
－管理他的缺点，不要影响他人；适当的时候，提醒他注意一下
－扬善于厅堂，归过于私下：宣传的东西，大家都是学习的——所以一定要学好的
4 、改进——让我们做的更好
。改进的方向？来自于我们的目标
。每年一个主题
。推行团队学习、主题学习
总结一下，建设一支测试团队，考虑如下步骤：
。设定团队的目标
。考虑团队中的角色与职责划分
。确定队员职崖规划和绩效考核标准
。招募合适的人
。搭建组内沟通的平台，确定组件沟通的渠道
。建设各种知识库，并在工作中不断总结、不断积累，丰富库的内容
。日常管理，尤其注意新人
。形成自己的文化
。改进——永恒的话题
-
软件项目中的风险归纳
Jon 发布于 2008-11-03 20:40:31
软件项目的风险无非体现在以下四个方面：需求、技术、成本和进度。IＴ项目开发中常见的风险有如下几类：ü 需求风险
①需求已经成为项目基准,但需求还在继续变化;②需求定义欠佳,而进一步的定义会扩展项目范畴;③添加额外的需求;④产品定义含混的部分比预期需要更多的时间;⑤在做需求中客户参与不够;⑥缺少有效的需求变化管理过程。
ü 计划编制风险
①计划、资源和产品定义全凭客户或上层领导口头指令,并且不完全一致;②计划是优化的,是"最佳状态",但计划不现实,只能算是"期望状态";③计划基于使用特定的小组成员,而那个特定的小组成员其实指望不上;④产品规模(代码行数、功能点、与前一产品规模的百分比)比估计的要大;⑤完成目标日期提前,但没有相应地调整产品范围或可用资源;⑥涉足不熟悉的产品领域,花费在设计和实现上的时间比预期的要多。
ü 组织和管理风险
①仅由管理层或市场人员进行技术决策,导致计划进度缓慢,计划时间延长;②低效的项目组结构降低生产率;③管理层审查 决策的周期比预期的时间长;④预算削减,打乱项目计划;⑤管理层作出了打击项目组织积极性的决定;⑥缺乏必要的规范,导至工作失误与重复工作;⑦非技术的第三方的工作(预算批准、设备采购批准、法律方面的审查、安全保证等)时间比预期的延长。
ü 人员风险
①作为先决条件的任务(如培训及其他项目)不能按时完成;②开发人员和管理层之间关系不佳,导致决策缓慢,影响全局;③缺乏激励措施,士气低下,降低了生产能力;④某些人员需要更多的时间适应还不熟悉的软件工具和环境;⑤项目后期加入新的开发人员,需进行培训并逐渐与现有成员沟通,从而使现有成员的工作效率降低;⑥由于项目组成员之间发生冲突,导致沟通不畅、设计欠佳、接口出现错误和额外的重复工作;⑦不适应工作的成员没有调离项目组,影响了项目组其他成员的积极性;⑧没有找到项目急需的具有特定技能的人。
ü 开发环境风险
①设施未及时到位;②设施虽到位,但不配套,如没有电话、网线、办公用品等;③设施拥挤、杂乱或者破损;④开发工具未及时到位;⑤开发工具不如期望的那样有效,开发人员需要时间创建工作环境或者切换新的工具;⑥新的开发工具的学习期比预期的长,内容繁多。
ü 客户风险
①客户对于最后交付的产品不满意,要求重新设计和重做;②客户的意见未被采纳,造成产品最终无法满足用户要求,因而必须重做;③客户对规划、原型和规格的审核 决策周期比预期的要长;④客户没有或不能参与规划、原型和规格阶段的审核,导致需求不稳定和产品生产周期的变更;⑤客户答复的时间(如回答或澄清与需求相关问题的时间)比预期长;⑥客户提供的组件质量欠佳,导致额外的测试、设计和集成工作,以及额外的客户关系管理工作。
ü 产品风险
①矫正质量低下的不可接受的产品,需要比预期更多的测试、设计和实现工作;②开发额外的不需要的功能(镀金),延长了计划进度;③严格要求与现有系统兼容,需要进行比预期更多的测试、设计和实现工作;④要求与其他系统或不受本项目组控制的系统相连,导致无法预料的设计、实现和测试工作;⑤在不熟悉或未经检验的软件和硬件环境中运行所产生的未预料到的问题;⑥开发一种全新的模块将比预期花费更长的时间;⑦依赖正在开发中的技术将延长计划进度。
ü 设计和实现风险
①设计质量低下,导致重复设计;②一些必要的功能无法使用现有的代码和库实现,开发人员必须使用新的库或者自行开发新的功能;③代码和库质量低下,导致需要进行额外的测试,修正错误,或重新制作;④过高估计了增强型工具对计划进度的节省量;⑤分别开发的模块无法有效集成,需要重新设计或制作。
ü 过程风险
①大量的纸面工作导致进程比预期的慢;②前期的质量保证行为不真实,导致后期的重复工作;③太不正规(缺乏对软件开发策略和标准的遵循),导致沟通不足,质量欠佳,甚至需重新开发;④过于正规(教条地坚持软件开发策略和标准),导致过多耗时于无用的工作;⑤向管理层撰写进程报告占用开发人员的时间比预期的多;⑥风险管理粗心,导致未能发现重大的项目风险。
-
理解Linux 的处理器负载均值（翻译）
Jon 发布于 2009-11-04 19:32:42
Linux 负载均值到底是什么意思？ 这个数值究竟如何说明服务器是忙是闲？依据这个数值来决定是否需要添加服务器，靠谱么？在网上google了一篇文章描述的非常形象，当然也通俗易懂喔。可以收藏喔
你可能对于 Linux 的负载均值（load averages）已有了充分的了解。负载均值在 uptime 或者 top 命令中可以看到，它们可能会显示成这个样子：
load average: 0.09, 0.05, 0.01很多人会这样理解负载均值：三个数分别代表不同时间段的系统平均负载（一分钟、五 分钟、以及十五分钟），它们的数字当然是越小越好。数字越高，说明服务器的负载越 大，这也可能是服务器出现某种问题的信号。
而事实不完全如此，是什么因素构成了负载均值的大小，以及如何区分它们目前的状况是 “好”还是“糟糕”？什么时候应该注意哪些不正常的数值？
回答这些问题之前，首先需要了解下这些数值背后的些知识。我们先用最简单的例子说明， 一台只配备一块单核处理器的服务器。
行车过桥
一只单核的处理器可以形象得比喻成一条单车道。设想下，你现在需要收取这条道路的过桥 费 -- 忙于处理那些将要过桥的车辆。你首先当然需要了解些信息，例如车辆的载重、以及 还有多少车辆正在等待过桥。如果前面没有车辆在等待，那么你可以告诉后面的司机通过。 如果车辆众多，那么需要告知他们可能需要稍等一会。
因此，需要些特定的代号表示目前的车流情况，例如：
- 0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
- 1.00 表示刚好是在这座桥的承受范围内。 这种情况不算糟糕，只是车流会有些堵，不过这种情况可能会造成交通越来越慢。超过 1.00，那么说明这座桥已经超出负荷，交通严重的拥堵。 那么情况有多糟糕？ 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍，那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了，说明这座桥基本上已经快承受不了，还有超出桥负载两倍多的车辆正在等待。
上面的情况和处理器的负载情况非常相似。一辆汽车的过桥时间就好比是处理器处理某线程 的实际时间。Unix 系统定义的进程运行时长为所有处理器内核的处理时间加上线程 在队列中等待的时间。
和收过桥费的管理员一样，你当然希望你的汽车（操作）不会被焦急的等待。所以，理想状态 下，都希望负载平均值小于 1.00 。当然不排除部分峰值会超过 1.00，但长此以往保持这 个状态，就说明会有问题，这时候你应该会很焦急。
“所以你说的理想负荷为 1.00 ？”
嗯，这种情况其实并不完全正确。负荷 1.00 说明系统已经没有剩余的资源了。在实际情况中 ，有经验的系统管理员都会将这条线划在 0.70：
- “需要进行调查法则”： 如果长期你的系统负载在 0.70 上下，那么你需要在事情变得更糟糕之前，花些时间了解其原因。
- “现在就要修复法则”：1.00 。 如果你的服务器系统负载长期徘徊于 1.00，那么就应该马上解决这个问题。否则，你将半夜接到你上司的电话，这可不是件令人愉快的事情。
- “凌晨三点半锻炼身体法则”：5.00。 如果你的服务器负载超过了 5.00 这个数字，那么你将失去你的睡眠，还得在会议中说明这情况发生的原因，总之千万不要让它发生。
那么多个处理器呢？我的均值是 3.00，但是系统运行正常！
哇喔，你有四个处理器的主机？那么它的负载均值在 3.00 是很正常的。
在多处理器系统中，负载均值是基于内核的数量决定的。以 100% 负载计算，1.00 表示单个处理器，而 2.00 则说明有两个双处理器，那么 4.00 就说明主机具有四个处理器。
回到我们上面有关车辆过桥的比喻。1.00 我说过是“一条单车道的道路”。那么在单车道 1.00 情况中，说明这桥梁已经被车塞满了。而在双处理器系统中，这意味着多出了一倍的 负载，也就是说还有 50% 的剩余系统资源 -- 因为还有另外条车道可以通行。
所以，单处理器已经在负载的情况下，双处理器的负载满额的情况是 2.00，它还有一倍的资源可以利用。
多核与多处理器
先脱离下主题，我们来讨论下多核心处理器与多处理器的区别。从性能的角度上理解，一台主 机拥有多核心的处理器与另台拥有同样数目的处理性能基本上可以认为是相差无几。当然实际 情况会复杂得多，不同数量的缓存、处理器的频率等因素都可能造成性能的差异。
但即便这些因素造成的实际性能稍有不同，其实系统还是以处理器的核心数量计算负载均值 。这使我们有了两个新的法则：
- “有多少核心即为有多少负荷”法则： 在多核处理中，你的系统均值不应该高于处理器核心的总数量。
- “核心的核心”法则： 核心分布在分别几个单个物理处理中并不重要，其实两颗四核的处理器 等于 四个双核处理器 等于 八个单处理器。所以，它应该有八个处理器内核。
审视我们自己
让我们再来看看 uptime 的输出
~ $ uptime23:05 up 14 days, 6:08, 7 users, load averages: 0.65 0.42 0.36这是个双核处理器，从结果也说明有很多的空闲资源。实际情况是即便它的峰值会到 1.7，我也从来没有考虑过它的负载问题。
那么，怎么会有三个数字的确让人困扰。我们知道，0.65、0.42、0.36 分别说明上一分钟、最后五分钟以及最后十五分钟的系统负载均值。那么这又带来了一个问题：
我们以哪个数字为准？一分钟？五分钟？还是十五分钟？
其实对于这些数字我们已经谈论了很多，我认为你应该着眼于五分钟或者十五分钟的平均数 值。坦白讲，如果前一分钟的负载情况是 1.00，那么仍可以说明认定服务器情况还是正常的。 但是如果十五分钟的数值仍然保持在 1.00，那么就值得注意了（根据我的经验，这时候你应 该增加的处理器数量了）。
那么我如何得知我的系统装备了多少核心的处理器？
在 Linux 下，可以使用
cat /proc/cpuinfo获取你系统上的每个处理器的信息。如果你只想得到数字，那么就使用下面的命令：
grep 'model name' /proc/cpuinfo | wc -l - 0.00 表示目前桥面上没有任何的车流。 实际上这种情况与 0.00 和 1.00 之间是相同的，总而言之很通畅，过往的车辆可以丝毫不用等待的通过。
-
国内测试专业blog(部份),欢迎一起完善
liangjz 发布于 2009-10-29 01:40:15
偶对平常访问较多or有意思的专业测试blog做一个简单的分类,或许有错,也肯定有很多遗漏.呵呵,欢迎大家一起完善,给大家提供一些便利.
Webx朱少民—质量管理
陈绍英--- 性能测试
http://blog.csdn.net/chenshaoying段念---性能测试:
http://www.guanhe.cn/
http://guanhe.cnblogs.com/深圳oracle 朱波 –oracle测试,性能/自动化测试
http://www.rickyzhu.com/陈雷-- 性能,管理 :
http://jackei.cnblogs.com/柳胜(性能+自动化):
http://www.cesoo.com/
http://blog.csdn.net/namesliu/category/236043.aspx文斯(白盒):
http://blog.csdn.net/vincetest/
http://blog.csdn.net/wayne_chan/category/241332.aspx微软余正洋:
http://blog.csdn.net/rogeryu/jack-测试架构:
http://www.51testing.com/?uid-293557广东赛宝陈能技-自动化:
http://blog.csdn.net/Testing_is_believing刘艳会—c++工具:
http://www.51testing.com/?uid-10851于涌—性能测试:
http://tester2test.cnblogs.com/深圳金蝶杨学明:
http://mikeyond.cnblogs.com/秋阳-综合:
http://www.cnitblog.com/qiuyangzh/category/375.html
阳光:
http://blog.csdn.net/Test_sunny微软李和恒:
http://blog.csdn.net/papercrane
微软安全测试:
http://blog.csdn.net/goldcattle/楷子狐:
http://hi.baidu.com/higkoozee ---性能测试:
http://www.7dtest.com/
http://blog.csdn.net/zeeslo
http://blog.csdn.net/zeeslo/category/215291.aspx
盛大龚X—性能测试:
http://blog.csdn.net/jacky8024
http://blog.csai.cn/user1/37626/index.html成都四方辛凯:
http://blog.csdn.net/nilxin/category/144266.aspx安全测试:
http://www.51testing.com/?uid/5994351testing云层—性能测试
http://www.51testing.com/?uid-104
崔启亮---本地化:
http://blog.csdn.net/giltworld/mayingbao—测试管理:
http://mayingbao.cnblogs.com/贺炘:
http://blog.csdn.net/hxcat小布播客---性能:
http://wilson66.cublog.cn/
阿里云刘新宇:
http://blog.csdn.net/omomo/
阿里巴巴 SQA :
http://hi.baidu.com/jacob/blog/index/0阿里巴巴QA:
http://www.51testing.com/index.php?uid-159438
阿里云陈洪:
http://hi.csdn.net/linkyou淘宝QA:
http://www.51testing.com/?uid-84753阿里之家:
http://fafeng.blogbus.com/
陈卫俊:
http://www.51testing.com/?uid/553451testing朴春龙---LR:
http://blog.csdn.net/piaocl宋峰---QTP自动化:
http://www.51testing.com/?uid-35-action-spacelist-type-blog苏州风过无息---QTP自动化:
http://www.51testing.com/?uid-3528 -
老徐最新总结的“项目级自动化测试流程”
cloudxu 发布于 2007-03-04 00:00:06
-
初尝设计性能测试过程文档模板-《性能测试用例》
yantong 发布于 2009-03-02 09:29:57
根据本人所在公司可能有的性能测试目的，我定制了性能测试用例模板，包括三个页签：
1、《预期性能指标测试用例》——用户对系统响应时间提出明确的性能需求，性能测试以验证响应时间是否符合需求为目的，一般测试对象为一些查询、统计模块等（测试时有可能是一个用户，也有可能是多用户并发）。
2、《负载测试用例》——以系统调优为目的做性能测试,通过对系统不断施压,找出系统瓶颈作为调优的依据，包括负载测试（单业务）和负载测试（多业务），测试时必然是多用户并发操作。
3、 《评估系统性能测试用例》——用户未提出明确的性能需求,测试的目的仅仅是对系统做性能评估。测试时将利用LoadRunner的性能指标评估功能。
详细模板内容参见附件，同时也附上测试案例分析图
-
《软件测试求生法则》书摘
lemon_l_t 发布于 2007-07-07 11:42:45
1。“与软件开发流程相似，软件测试流程也可以从随意、极不标准到高度结构化、协调统一进行分级。软件测试流程的随意性越大，测试人员有效开展工作的难度也就越大”
2。“相对于意识到缺乏个人发展而言，人们更愿意使自己沉浸在日常工作之中，而不去了解它是否能有所提高”
3。“一个测试流程应该使可管理的、可衡量的和可重复的。没有测试流程指导的测试将会缺乏一致性、稳定性和可预测性。。。”
4。“戴明博士说得好：‘每个人都会涉及到质量问题，但其根本责任还是在领导层。’”
5。“准时交付不是衡量成功的唯一标准，QAI的座右铭：当准时交付的成功喜悦已消失殆尽时，才能体会到恶劣质量带来的长久苦恼”
6。“解决测试时间问题的唯一方法就是在‘完成不可能完成的任务的痛苦’和‘完全自由支配的满足’之间寻求平衡点”
7。“测试的质量并不取决于测试用例的数量或是测试执行的速度，而是测试的目的，当项目进度被压缩得很紧时，常用得方法就是减少测试。导致得结果通常时软件用户轻而易举就能发现问题。减少类似负面影响得最有效方法是以风险为基础确定测试范围和制定测试计划，而不是试图验证所有可能输入和动作组合。”
8。“正像一个高级经理所提到得‘当任何一个人告诉我什么地方有问题时，我最想听到得还是他对解决这个问题有什么建议”
9。“你的企业的成熟度不可能超越高级管理层的成熟度，这就意味这成熟的第一步是高级管理层的着眼点必须从产品转向流程”“如果听到了怀消息，可能是流程某些部分不适合实际需要，如果测试发现产品缺陷太多以致于无法准时交付使用，你考虑问题的出发点仍然是调整流程以适应现实。通过专注于流程，你可以有效的消除许多不利的人际因素，以便测试人员报告怀消息和经理们接受怀消息都变的步那么困难。”
10。“我宁愿选择被信任和被尊敬，而不是被喜爱。－－－巴比.鲍莱斯博士”
-
windows xp下安装Redhat Linux
starzuo 发布于 2009-08-11 22:28:08
windows xp下安装Redhat Linux2windows xp下安装Redhat Linux
windows xp下安装Redhat Linux
下载VMWare解压后根据提示正触安装VMWare到硬盘中
(1) 建立虚拟机
A.用鼠标左建双击桌面中的"VMware workstation"图标，运行虚拟机
B.建立一台虚拟机。点击“FILE(文件)”-“NEW(新建)”--“NewVirtual Machine(
新建虚拟机)”，弹出虚拟机创建菜单。
C.根据向导一步一步地创建虚拟机，首先选择安装方式是“TYPICAL(典型)”还是
“CUSTOM(自定义)”安装。 我这里选择典型。
D.因为这里是用于安装REDHAT，所以在Guest operating system(客户操作系统)“
中选择”LINUX“，点击下一步。
E.在Virtual machine name(虚拟机名字)中输入你想建立的虚拟机的名字
F.在Location(位置)中选择虚拟机的安装位置。因为会在虚拟机中安装操作系统
和应用软件，所以建议将虚拟机安装在一个有较大空间的磁盘分区中
G.如果你的电脑连接在网络中，那么选择一个合适的网络环境。我这里选择
Use bridged net-working(使用路由网络)
H.点击finish,返回VMWARE主界面，LINUX虚拟机就建好了。
2. 安装操作系统A. 选中LINUX虚拟机，点击VMWARE工具栏中的Power ON按钮，启动LINUX虚拟机
B.然后插入REDHAT7.3光盘，虚拟系统根据你选择的安装方式开始安装。
3.从硬盘安装REDHAT7.3
如果你认为从光驱中安装比较费时间，又不方便，那你可以将光盘文件转换成ISO文件拷
贝在硬盘中，然后从硬盘安装。
A.点击Settings(设置)--Configuration Editor(编辑配置)进入设置界面对虚拟机进行
配置。
B.在Hardware(硬件)选项中，选择DVD/CD--ROM[IDE 1:0]项，在左边的选项中进行设置。
C.在Connection(连接)选项选中Use ISO image(使用ISO镜像包)，然后点击Browse(预览)
按钮，找到放置ISO文件的目录。
D.在打开对话框中选择RedHat.ISO文件，然后点击打开，将ISO文件打开(如果第一个ISO
文件安装完后，计算机提示你插入第二张光盘，则在此选择RedHat.ISO，如此类推)
E.在Virtual device mode(虚拟设备模式)选择虚拟设备的接口方式，选择IDEO：0项
然后点击OK返回到虚拟机界面下，点击Power ON就可以直接从硬盘安装操作系统了
4 安装VMware Tools虚拟机安装REDHAT7.3时，在状态栏中一直提醒你安装VMware Tools.因为虚拟机是默认
使用自带的虚拟显卡，只有正确安装了VMware Tools后，才能在虚拟机中正确启动
REDHAT7.3操作系统，并正确设置显卡以及显示器的分辨率等参数。
注意：在安装好LINUX后再进行此项操作
A.重新启动虚拟机，点击Setting(设置)--VMware Tools Install(安装VMware工具)
在弹出的菜单中点击Install,安装VMware工具。
B.点击Devices(设备)菜单，你会发现光驱的菜单项由IDE ：0变成了IDE :0>F:\
program Files\VMware\Vmware Workstation\Programs\Linux.ISO，
这表示VMware将LINUX的ISO映像文件 作为了虚拟机的光盘。
C.其实这时并没有真正地安装上VMware Tools软件包，还须进一步设置。
进入文本登录界面中，输入管理员用户名(ROOT)和密码进入ROOT@LOCALHOST ROOT
目录下。
D.在命令行后面输入如下命令（注意大小写和空格，同时每行命令后记住回车）
mount -t iso9660 /dev/cdrom /mnt (加载CDROM设备，并且CDROM为只读属性。）
cp /mnt/vmware-linux-tools.tar.gz/tmp (将该软件包持拷贝到LINUX的TMP目录下）
umount /dev/cdrom （舍载CDROM）
cd /tmp (进入TMP目录）
tar zxf vmware-linux-tools.tar.gz (解压该软件包）
cd vmware-linux-tools (进入解压后的目录）
./install.pl (运行安装命令，系统开始安装vmware tools)
E` 在屏幕的提示下，连续回车两次后，系统安装完VMWARE TOOLS，在命令
行中输入STARTX命令，启动REDHAT7.3，进入图形界面。
5. 设置显示器的分辨率这时虚拟机显示器的分辨率高于本机，由于两机显示器的分辨率的不同将造成图形
窗口的大小不一致，在本机与虚拟机之间相互切换时就很不方便
所以要重新设置虚拟机显示器的分辨率。
A.在命令行中键入cd /etc/x11(X为大写）。进入配置文件所在的目录，同时输入
mc命令。
B.进入MC编辑器，用上下箭头将光标移动到XF86Config-4.vm文件，按下F4，这时将出
现一个文本窗口，里面显示了配置信息。
D.显示的配置信息一般在Screen Section标题后面可找到它。
E 找到显示器的分辨率之后，将Modes中高于本机的ms windows所用的分辨率全部
删除，删除务必从高分辨率向低分辨率删除，以免出现漏洞。
F.保存修改的信息，退到X11目录下，输入startx进入图形界面，虚拟机内的操作系统
的分辨率就发生了改变。
+++++++++++++++++++++++++++++++++++++++++++++
在VMWARE下用host-only实现Redhat linux-guest上网，并启动samba服务以下是在装完vmware，并装好vmware-tools
1,在windows下，连接外网的网卡，属性-〉高级-〉Internet连接共享-〉选中允许其他网络用户通过。。-〉家庭网络连接选VMnet1-〉确定
2,在linux下，配置静态IP
点小红帽-〉System Settings ->Network 打开Network Configuration
双击下面的Profile打开对话框，在静态ip地址下填上
Address：192.168.0.21 (最后一位除1可以随便写)
Subnet Mask： 255.255.255.0
Gateway：192.168.0.1
点OK
选DNS，填Primary DNS：192.168.0.1
选hosts，可以看见你的主机名和IP，下面需要改动
Save
3，编辑主机地址
新建一个终端，写vi /etc/hosts 打开hosts文件
把主机前的ip改为Address里面设的ip。（一般就在第一行）
4，重起网络服务
service network restart
5, 应该可以上网了
6，配置samba
vi /etc/samba/smb.conf 打开配置文件
找到hosts allow或在文件里加上 hosts allow = 192.168.0.(不要忘了最后的点)
在文件的最后加上共享的文件夹，下面是示例。（文件里有说明怎样加上共享文件夹）
[root]
comment = all for windows
path = /root
guest ōk = yes
writeable = yes
[data]
comment = data
path = /data
guest ōk = yes
writeable = yes
保存退出
7, 重起samba服务
service smb restart
8, 然后在windows下，就可以访问上面设置的共享文件夹了。
开始-〉运行->填上\\192.168.0.21
访问你的共享文件夹
9，最后，你可以用远程工具如putty.exe，在windows下用ip:192.168.0.21登陆linux
这样你就可以在windows下用命令行工作在linux下，而不用去切换到vmware下
10，如果以上设置好，不行的话，在linux下用下面的命令
ifconfig 看一下eth0是不是设的ip：192.168.0.21
如果不是
ifconfig eth0 192.168.0.21
service smb restart
service network restart -
申请加薪|申请离职---转
liujinkui 发布于 2009-08-11 19:47:58
加 薪 申 请 书
经理你好：
随着我公司的不断发展状大，我个人的能力也在不断的提升和进步。这段共同成长的岁月里，我对公司的同事们产生了深厚的感情，我喜欢公司的企业文化，喜欢公司的工作氛围，喜欢公司的每一个伙伴们。我给予了他们的同时，他们也给予了我更多。我感谢公司领导对我的栽培和帮助，我非常的信任你们。基于对公司的热爱和对领导的信任，鉴于现在的工作职责范围和工作强度，我希望月薪是XXXX元(在原基础上增加1000元)。
人追求的目标越高，他的才力就发展的越快，才能为企业创造更大的价值。如果对员工的工作没有一个明确的激励手段和考核标准，员工的素质高低、做多做少、做好做坏都只是拿基本工资，那对他们来说，为工作付出的满腔热情、牺牲的休息时间和身体健康来说是不公平和不值得的。
在这里我不用说自己工作做的怎么样、工作态度怎么样，因为您是我的直接领导，这些您应该非常了解，您甚至可以从员工们那里得到对我的评价。提出这样的薪金要求，并不是“居功自傲”，我所付出的谈不上“功”，所以请不要误会我的本意，我只是实话实说。我相信，只要付出，就会有收获！
如果公司领导认为我现在的工作内容及质量还未能达到XXXX元月薪的要求，我诚恳的希望您能提出诚肯的意见或建议，让我今后有一个努力的方向和目标，在提升自己能力的同时将工作做的更好，向更高的目标迈进。
也请您放心，如果公司不予考虑，我仍然会像以前一样，用积极的、认真负责的态度去做好每一件事，不会因此怠慢工作，这是我的知识和修养要求我应该做到的。
期待您的答复。XXX
祝好！
申请
尊敬的公司领导：
您好！
我自xxxx年xx月进入公司以来，至今已近x年，期间一直担任后勤管理员兼司机职务，本着以司为家的心情，一直努力工作，不敢有丝毫懈怠之心；加之公司近年不断发展壮大，对外业务不断增加,我的工作量不断增大.我个人能力也在不断的提升和进步，这段共同成长的岁月里，使我更加喜欢公司的企业文化、喜欢公司的工作氛围，感谢公司领导对我的栽培与帮助。
现本人已近而立之年，结婚、供房等所带来的资金压力，实如泰山压顶，但本人目前收入低薄，每月仅xxxx元，而xx市本就消费水平极高，每月收入仅能自给，心中不免哀伤，但想到公司一向爱护员工的传统，心中便有了一直走下去的希望。
基于对公司的热爱和对领导的信任，鉴于现在的工作职责和工作强度，我希望公司能将我的工资提高xxxx元左右，至此公司的深情厚意，不敢厚藏，尽表现于工作之中。
人追求的目标越高，他的才力发展的就越快，所以我正式提出申请，希望公司能将我个人工资提高到xxxxx元整。
也请公司领导放心，无论申请成功与否，本人仍会一如既往的、用积极的、认真负责的态度去做好每一件事，不会因此怠慢工作，这是我的知识和修养要求我应该做到的。
期待您的答复！
此致
敬礼
离职报告：尊敬的公司领导：您好！
我经过慎重考虑，决定辞去目前在厚和公司的所有职务。
在这里工作的７年时间里，我学到了很多新的东西，充实和丰富了自己。同时，我也很幸运，能够有机会在这样一支有实力，充满朝气的团队里工作和学习，更重要的是，认识了这么多好的朋友和同事。
但是，现在我感觉到自己不适合再继续担任这份工作。很遗憾，没有机会再为公司做更多的贡献。但是我对公司的感情还是会一如既往，希望公司能够蒸蒸日上，有更好的发展。
在过去的工作中，我自己也感到很欣慰的是，自己并没有给公司带来任何损失或者不好的影响。当然，如果我有做的不够的地方，希望您能够指正。
关于我的离职申请，希望您能够尽快批复。
谢谢！
标题搜索
我的存档
数据统计
- 访问量: 30716
- 日志数: 64
- 文件数: 1
- 建立时间: 2009-06-07
- 更新时间: 2011-01-06
