项目款项的时间管理

    企业投资的最主要动机是取得投资收益，也是企业活动的最终目的，收益的产生来自于现金的流出，再经过一段时间后产生的现金的流入，现金流入与现金流出的差额，就是收益。在实际现金流入的过程中，流入并不是一次性的，而是在不同的时点进行流入的，这样就产生了货币的时间价值。
　　货币的时间价值是现在企业管理中是一个非常重要的概念，合理的运用货币的时间价值不但可以使企业获得充足的用于再投资现金流入，而且能够使资金在周转过程中发挥更大的经济效益。
从项目管理的角度来说，每个项目的收款一般条件下都不是一次性付清，而是分次付款，作为管理者需要了解现金流入的情况；从财务管理的角度来说，都知道“cash flow is king”.由此可见及时的现金流入的重要性；从货币管理的角度来说，便产生了货币收款的时间管理需求和要求。
　　那么是什么货币的时间价值？它又该如何计算？以及在项目收款的如何合理运用？
　　货币时间价值是指一定量资金在不同时点上价值量的差额。它反映的是由于时间因素的作用而使现在的资金高于将来某个时期的同等数量的资金的差额或者资金随时间推延所具有的增值能力，在理解货币时间价值时，我们要注意两点：第一，货币时间价值是在没有风险和没有通货膨胀条件下的社会平均资金利润率，如果社会上存在风险和通货膨胀，我们还需将它们考虑进去。第二，不同时点单位货币的价值不等，不同时点的货币收支需换算到相同的时点上，才能进行比较和有关计算。因此，我们不能简单地将不同时点的资金进行直接比较，而应将它们换算到同一时点后再进行比较。
　　货币的时间价值在企业的财务管理中直接体现为利息或纯收益形态的增值，那么，客观上必然存在一个资金随时间增值的速率，可以用来作为不同时间点上资金的换算率，这种换算率就是计算资金时间价值的尺度。这方面的尺度有两种：1、银行利率；2、动态投资收益率。
　　由于货币时间价值是客观存在的，因此，在企业的各项经营活动中，就应充分考虑到货币时间价值。货币如果闲置不用是不会产生时间价值的，同样，一个企业在经过一段时间的发展后，肯定会赚得比原始投资额要多的资金，闲置的资金不会增值，而且还可能随着通货膨胀贬值，所以企业必须好好地利用资金时间价值，最好的方法就是找一个好的投资项目将资金投入进去，让它进入生产流通活动中，发生增值。企业的投资需要占用企业的一部分资金，这部分资金是否应被占用，可以被占用多长时间，均是决策者需要运用科学方法确定的问题。也就是说企业在投资活动中的投入，取决于公司良好的现金流入。从这个角度来说，项目款项的时间管理就显得十分必要和重要了。
　　上面提到了货币时间价值的衡量的2种尺度。在完全市场经济社会中，由于自由竞争和价值规律起着充分的作用，各部门、各行业之间有一个平均的动态投资收益率，而银行利率就在接近该平均的动态投资收益率的上下浮动。在现实市场中，由于各种因素的综合影响，银行利率实际上作为企业投资活动的一个参考值。银行利率属于一个企业投资收益的最低的投资收益率；同时也需要说明这种投资收益率也是一个无风险的投资收益率。当然了，企业的收益率应该是要高于这个利率，否则企业也不会产生投资行为。
　　在对项目款项的算法中，贴现法是比较好用的一种方法，其主要的算法是把资金的不同时间点的实际货币价值进行计算简单点说就是一个今天获得100元和在一个月以后获得的100元是不同的，这个时间的差距就是货币的时间价值。也就是对一个月以后的100元在用贴现处理以后，他的实际价值是小于100元的。在具体的计算过程中就涉及到一个贴现率的问题，如何计算和估计贴现率是一个非常复杂的过程，但是还是可以进行一些简单的估算。
　　一般可以用银行的利率作为一个基准的贴现利率，一般情况下，银行利率是一个无风险利率，即公司把钱存入银行以后他的收益是固定和可以保证的，现在设银行的月利率为a那么100元的一个月以后的价值是100（1+a），即100=100（1+a）。换句话说，如果公司在某个月末的需要收入一笔资金100（1+a） ，那么如果客户提前还款100元，根据基准的时间价值计算：100（1+a）=100，但从公司的角度来说，公司提前一个月就获得了100元的现金流入。
　　当然上面的计算只是一个简单的例子。在实际管理中，一般简单的使用银行利率作为贴现利率，并不会引起客户的提前还款的欲望，因为这种简单的利率贴现在实际管理也没有特别的意义，从公司管理的角度来，公司需要从自己的实际投资的行为和相关的社会宏观经济的角度等来仔细计算自己的动态投资收益率，然后根据这个来管理项目款项的回款的时间管理，从而为公司及时获得足够的现金流入提供更为有力的支持。
　　实际上，在现代企业的管理中，对货币的时间管理已经成为公司管理的一个重要的管理手段，企业经营活动中的委托代销、应收应付、租赁寄售、股利分红、企业兼并收购、固定资产折旧及对外经济贸易等方面，都应充分考虑货币的时间价值，以使资金在周转过程中发挥最大的经济效益。

 

哲理小故事

1、断箭
　　不相信自己的意志，永远也做不成将军。
　　春秋战国时代，一位父亲和他的儿子出征打战。父亲已做了将军，儿子还只是马前卒。又一阵号角吹响，战鼓雷鸣了，父亲庄严地托起一个箭囊，其中插着一只箭。父亲郑重对儿子说：“这是家袭宝箭，配带身边，力量无穷，但千万不可抽出来。”
　　那是一个极其精美的箭囊，厚牛皮打制，镶着幽幽泛光的铜边儿，再看露出的箭尾。一眼便能认定用上等的孔雀羽毛制作。儿子喜上眉梢，贪婪地推想箭杆、箭头的模样，耳旁仿佛嗖嗖地箭声掠过，敌方的主帅应声折马而毙.
　　果然，配带宝箭的儿子英勇非凡，所向披靡。当鸣金收兵的号角吹响时，儿子再也禁不住得胜的豪气，完全背弃了父亲的叮嘱，强烈的欲望驱赶着他呼一声就拔出宝箭，试图看个究竟。骤然间他惊呆了。
　　一只断箭，箭囊里装着一只折断的箭。
　　我一直刳着只断箭打仗呢！儿子吓出了一身冷汗，仿佛顷刻间失去支柱的房子，轰然意志坍塌了。
　　结果不言自明，儿子惨死于乱军之中。
　　拂开蒙蒙的硝烟，父亲拣起那柄断箭，沉重地啐一口道：“不相信自己的意志，永远也做不成将军。”
　　把胜败寄托在一只宝箭上，多么愚蠢，而当一个人把生命的核心与把柄交给别人，又多么危险！比如把希望寄托在儿女身上；把幸福寄托在丈夫身上；把生活保障寄托在单位身上……
　　温馨提示：自己才是一只箭，若要它坚韧，若要它锋利，若要它百步穿杨，百发百中，磨砺它，拯救它的都只能是自己。

　　2、生命的价值
　　 不要让昨日的沮丧令明天的梦想黯然失色！
　　在一次讨论会上，一位著名的演说家没讲一句开场白，手里却高举着一张20美元的钞票。
　　面对会议室里的200个人，他问：“谁要这20美元？”一只只手举了起来。他接着说：“我打算把这20美元送给你们中的一位，但在这之前，请准许我做一件事。”他说着将钞票揉成一团，然后问：“谁还要？”仍有人举起手来。
　　他又说：“那么，假如我这样做又会怎么样呢？”他把钞票扔到地上，又踏上一只脚，并且用脚碾它。尔后他拾起钞票，钞票已变得又脏又皱。
　　“现在谁还要？”还是有人举起手来。
　　“朋友们，你们已经上了一堂很有意义的课。无论我如何对待那张钞票，你们还是想要它，因为它并没贬值，它依旧值20美元。人生路上，我们会无数次被自己的决定或碰到的逆境击倒、欺凌甚至碾得粉身碎骨。我们觉得自己似乎一文不值。但无论发生什么，或将要发生什么，在上帝的眼中，你们永远不会丧失价值。在他看来，肮脏或洁净，衣着齐整或不齐整，你们依然是无价之宝。”
　　温馨提示：生命的价值不依赖我们的所作所为，也不仰仗我们结交的人物，而是取决于我们本身！我们是独特的——永远不要忘记这一点！

　　3、昂起头来真美
　　别看它是一条黑母牛，牛奶一样是白的。
珍妮是个总爱低着头的小女孩，她一直觉得自己长得不够漂亮。有一天，她到饰物店去买了只绿色蝴蝶结，店主不断赞美她戴上蝴蝶结挺漂亮，珍妮虽不信，但是挺高兴，不由昂起了头，急于让大家看看，出门与人撞了一下都没在意。
　　珍妮走进教室，迎面碰上了她的老师，“珍妮，你昂起头来真美！”老师爱抚地拍拍她的肩说。
那一天，她得到了许多人的赞美。她想一定是蝴蝶结的功劳，可往镜前一照，头上根本就没有蝴蝶结，一定是出饰物店时与人一碰弄丢了。
　　自信原本就是一种美丽，而很多人却因为太在意外表而失去很多快乐。
　　温馨提示：无论是贫穷还是富有，无论是貌若天仙，还是相貌平平，只要你昂起头来，快乐会使你变得可爱——人人都喜欢的那种可爱。

　　4、为生命画一片树叶
　　只要心存相信，总有奇迹发生，希望虽然渺茫，但它永存人世。
　　美国作家欧;亨利在他的小说《最后一片叶子》里讲了个故事：病房里，一个生命垂危的病人从房间里看见窗外的一棵树，在秋风中一片片地掉落下来。病人望着眼前的萧萧落叶，身体也随之每况愈下，一天不如一天。她说：“当树叶全部掉光时，我也就要死了。”一位老画家得知后，用彩笔画了一片叶脉青翠的树叶挂在树枝上。
　　最后一片叶子始终没掉下来。只因为生命中的这片绿，病人竟奇迹般地活了下来。
　　温馨提示：人生可以没有很多东西，却唯独不能没有希望。希望是人类生活的一项重要的价值。有希望之处，生命就生生不息！

　　5、飞翔的蜘蛛
　　信念是一种无坚不催的力量，当你坚信自己能成功时，你必能成功。
　　一天，我发现，一只黑蜘蛛在后院的两檐之间结了一张很大的网。难道蜘蛛会飞？要不，从这个檐头到那个檐头，中间有一丈余宽，第一根线是怎么拉过去的？后来，我发现蜘蛛走了许多弯路－－从一个檐头起，打结，顺墙而下，一步一步向前爬，小心翼翼，翘起尾部，不让丝沾到地面的沙石或别的物体上，走过空地，再爬上对面的檐头，高度差不多了，再把丝收紧，以后也是如此。
　　温馨提示：蜘蛛不会飞翔，但它能够把网凌结在半空中。它是勤奋、敏感、沉默而坚韧的昆虫，它的网制得精巧而规矩，八卦形地张开，仿佛得到神助。这样的成绩，使人不由想起那些沉默寡言的人和一些深藏不露的智者。于是，我记住了蜘蛛不会飞翔，但它照样把网结在空中。奇迹是执着者造成的。

　　 6、阴影是条纸龙
　　人生中，经常有无数来自外部的打击，但这些打击究竟会对你产生怎样的影响，最终决定权在你手中。
祖父用纸给我做过一条长龙。长龙腹腔的空隙仅仅只能容纳几只蝗虫，投放进去，它们都在里面死了，无一幸免！祖父说：“蝗虫性子太躁，除了挣扎，它们没想过用嘴巴去咬破长龙，也不知道一直向前可以从另一端爬出来。因而，尽管它有铁钳般的嘴壳和锯齿一般的大腿，也无济于事。
　　当祖父把几只同样大小的青虫从龙头放进去，然后关上龙头，奇迹出现了：仅仅几分钟，小青虫们就一一地从龙尾爬了出来。
　　温馨提示：命运一直藏匿在我们的思想里。许多人走不出人生各个不同阶段或大或小的阴影，并非因为他们天生的个人条件比别人要差多远，而是因为他们没有思想要将阴影纸龙咬破，也没有耐心慢慢地找准一个方向，一步步地向前，直到眼前出现新的洞天。

　　 7、永远的坐票
　　生活真是有趣：如果你只接受最好的，你经常会得到最好的。
　　有一个人经常出差，经常买不到对号入坐的车票。可是无论长途短途，无论车上多挤，他总能找到座位。
　　他的办法其实很简单，就是耐心地一节车厢一节车厢找过去。这个办法听上去似乎并不高明，但却很管用。每次，他都做好了从第一节车厢走到最后一节车厢的准备，可是每次他都用不着走到最后就会发现空位。他说，这是因为像他这样锲而不舍找座位的乘客实在不多。经常是在他落座的车厢里尚余若干座位，而在其他车厢的过道和车厢接头处，居然人满为患。
　　他说，大多数乘客轻易就被一两节车厢拥挤的表面现象迷惑了，不大细想在数十次停靠之中，从火车十几个车门上上下下的流动中蕴藏着不少提供座位的机遇；即使想到了，他们也没有那一份寻找的耐心。眼前一方小小立足之地很容易让大多数人满足，为了一两个座位背负着行囊挤来挤去有些人也觉得不值。他们还担心万一找不到座位，回头连个好好站着的地方也没有了。与生活中一些安于现状不思进取害怕失败的人，永远只能滞留在没有成功的起点上一样，这些不愿主动找座位的乘客大多只能在上车时最初的落脚之处一直站到下车。
　　温馨提示：自信、执着、富有远见、勤于实践，会让你握有一张人生之旅永远的坐票。

 

     孙峻涛CES销售理论全接触

今天我和大家交流一下关于“解决方案式销售”的问题

解决方案式销售卖什么

“解决方案式销售”不等同于“销售解决方案”……

欲明其理，先明其意。也许很多人一看标题就不会再继续看下去了。原因很简单，他们认为自己卖的是商品，没有什么叫做“解决方案”的东西。这是第一个误区，也是很多人会陷入的一个误区。优秀的销售人员应该懂得，在今天的“买方趋向”的市场面前，单纯的出卖商品使用价值的时代，早已是“古道西风瘦马”的日落黄昏时了。

我们说的解决方案式销售是“以客户的问题为销售核心，凭借销售人员各种能力帮助客户拿出合理、合适的解决方案的顾问式销售模式”。它也可称为“顾问式销售”、“大客户式销售”，但是绝不能等同于“销售解决方案”，甚至从某种角度上来说他们是对立的。调换一下语序就会造成反向局面吗？是的。解决方案式销售是要完全站在客户的角度考虑问题，从而充分利用自身能力帮助客户解决难题；而销售解决方案是站在产品的角度上，利用商品的特性去直接卖给客户的。提出“解决方案式销售”，就是要区别于“销售解决方案”的销售模式的。

究其两者关键字，前者是“客户”二字，而后者更注重于商品。前者的目的是为客户解决问题，从而让客户自然选择你所为其定制的解决方案（商品）；后者则是为了直接销售出商品，把商品的价值转变成使用价值。　　

解决方案式销售的优势　　

《爱情呼叫转移》中的销售启示……

前一阵热播电影《爱情呼叫转移》，里面售楼小姐推销楼盘的片段给我留下了很深的印象。在电影中，销售小姐不断向潘文琳介绍自己的楼盘有多好，“空间宽敞”、“精装修”、“奉送家具”、“优美园艺”，却都被顾客报以了“傍名牌”、“掩瑕疵”、“面子工程”的回应。售楼不成不说，还被客户的风眼冷雨无情打击，郁闷至极。

笑过后，我们回想一下平时购房时我们所听到的声音。来到售楼处，售楼小姐热情接待，给我们讲述“您看这个房子地理位置多好，周边教育医疗多配套，性价比多高”等等，一上来就不停地讲述，告诉客户自身所具有的种种优势如何如何。我们再来看看另外一种销售方式。售楼小姐会问您卖房打算住几个人。客户说，准备住5个人，我和妻子还有父母、孩子。又问，您的孩子多大了呀？客户说刚四岁。这时，售楼小姐才会娓娓道来，我们的楼盘周围有幼儿园，还有不错的小学，您的父母在帮助您照顾孩子的同时，还可以到我们优美的花园遛弯。

这两种销售方式，他们背后所拥有的资源都是相同的，但是显然后者的方式让顾客更加受用。第一种销售方式我们通常称之为“产品销售”。它的出发点是产品的性能、价格、灵活性等方面。第二种销售方式就是我们今天谈到的“解决方案式销售”，他的出发点在于客户需求，利用手中资源拿出一套适合客户的解决方案，以达到销售目的。“产品销售”和“解决方案式销售”虽然在产品性能上的资源都是一样的，但其本质是完全不同的。区别在于销售人员是站在自身角度上考虑问题，还是站在客户的角度上考虑问题。

相同的产品，但是由不同的销售人员来销售，带给客户的感受是完全不同的，在所有关于买卖的市场关系中都存在这种问题。也许有人认为“解决方案式销售”应该是复杂的，他的周期长、金额大、相关人员多等等。但实际上，买一个很简单的东西也可能是“解决方案式销售”，买一个很复杂的东西也可能是“产品销售”。这里我们举一个系统集成商的例子，在亚信他们的产品中有一套为网通、电信等运营商所专门设计的“用户计费”软件，众所周知这种软件是非常复杂的。如果销售人员是基于这套软件的性能指标、稳定性等这些优势来销售的，即使这套东西很复杂甚至卖的就是一套完整的解决方案，但是我们依然认为这还是一种产品销售。反之，“解决方案式销售”的销售人员，是基于运营商计费中实际出现的一些问题，再针对问题与研发、技术部门沟通，进行二次开发，而不是基于商品化。如果进行了二次开发，脱离了商品化，满足客户的需求，那么即使卖的东西很简单，它也是一种解决方案式销售模式。

解决方案式销售如何体现优势

资源固定不变，产品何以附加价值……

这里我们要明确，并不是产品销售不好，而是不同的产品要采用不同的销售方式。但是销售产品的模式还是从客户的采购模式引申来的。客户的采购流程决定了，销售人员才可选取恰当的销售模式。

狭义地说，解决方案式销售的初衷定位是IT业系统集成商（SI），或者说是具有“所需要销售的产品或服务往往难以描述、技术含量高、无形性内容较多、产品更新快、有使用风险、价格昂贵、销售周期长、参与采购决策的成员多和销售价格不再是赢单主要因素”等特征的销售定制的销售理论。

但有意思的是随着时代的进步，解决方案式销售“以客户为核心”的理念逐渐深入人心，渗透到终端行业。现在越来越多的其他行业的销售人员，也在争相学习、效仿CES理论，诸如现在我们在超市内购买牙膏，导购人员都会首先站在客户的角度，来询问我们需求什么功能，是抑制口腔溃疡还是防止牙龈出血，然后导购们才会为我们推荐带有类似功能的产品。从某种角度上来说，虽然他们拿出的“牙膏”并非“解决方案”，但是他们的这种销售理念的确属于“解决方案式销售”。

那么站在客户的角度考虑问题，解决方案式销售如何体现自身优势呢？我们知道在采购过程中，客户总是有“心理成本”。不知大家有否注意到，我们去麦当劳购买食品，时常会听到柜机小姐在我们选购完食品后，附上一句“您要不要尝尝我们新出的某某食品”。几年前，这种赢取客户“计划”外购买欲望的方式的确有效，但近年来，客户仿佛已经对此销售方式感到厌烦，往往在未思索的情况下就明确告知“不用了”。　　究其原因，是因为这超出了客户的“心理预期”。我预计30元搞定的这顿饭已经购买，而你却要在我已经能吃饱的基础上，再让我花上10元钱，显然我不能接受。

解决方案式销售不同于其他销售方式的地方，就在于它能提高客户的“心理成本”，而就同时提高的所售产品的利润率。那么我们是怎么做到的呢？换到麦当劳的例子上，我们在了解客户所需商品后，在顾客所需食量不变的基础上，推销我们利润率更高的食品，为客户献上一套在客户看来更加营养、实惠的“快餐解决方案”。形象一点说，现行的销售模式和解决方案式销售的区别就在于，前者是在客户已经能够吃饱的基础上，让客户再吃点好的；而后者是在了解客户需求的基础上，为客户选取更好、更加营养合理的套餐。

在生活中，这样的例子更是不胜枚举。我们在购买手机配件的时候，卖家经常在我们告知其品牌后，寻问我们手机的具体型号。别小看这一句话，卖家在了解我们型号为我们选择匹配商品的同时，在无形中对顾客的购买能力进行了定位。如果你所持有的手机是高端手机，相信商家的开价要远比低端机高得多。虽然相同品牌的配件匹配度、价格大多相同，但是他们摸准了客户的“心理成本”。同样，如果我们按照解决方案式销售为客户定制他们的专属方案，那么往往客户会提高预期心理价格。这也就是解决方案式销售合适“增值销售”的重要理由之一。

采购者“顾虑”的变换

不同时期介入，该主打什么“牌”……

我们上面提到了无论是产品销售模式，还是解决方案式销售模式，都要依靠客户的采购流程来定。那么，客户在采购流程中，不同阶段的需求都是什么呢？换句话说，我们的销售人员在不同时期介入项目，应主打什么牌，来应对客户不同时期关注度的转移呢？
　　在现实中，客户的一套采购流程可以分为前中后三个时期。前期决定需求制定初步预算、中期评价选择解决方案、后期评价实施风险3个基本历程。而客户的忧虑主要源自Needs(需求)、Cost（预算）、Proof（解决方案）、Risk（附加风险）四方面。客户在这四方面的顾虑始终存在着变化。这种变化显然不是随机的，而是随着采购的进展推动，在有规律的变化。

在决定需求的第一阶段，需求能否解决显然是客户最为关心的问题。随着采购流程的深入，需求依据现实条件逐步被淡化，甚至在某些时候，客户还会依据实用性而放弃初期制定的一些特殊需求。

在采购流程中，Cost前期被称为预算，而在后期就变成了（Price）价格。它在采购的第二阶段往往可以被忽略，也就是客户不会过多的去关注此问题。如果你在此时期介入，却主打“价格牌”显然是不合时宜的。到了流程的后期，价格问题重新会回到谈判桌前，变成双方谈论的焦点，成为一个美丽的“U”字形。

解决方案刚好跟Cost相反，它是一个“桥”型的变化曲线。在第二阶段，一个好的解决方式才是客户最为关心的问题。而“风险”这个顾虑会随着客户的采购流程，逐步被强化，以至于到了第三阶段变成了所有客户顾虑中，最为关键的一个。降低风险，当然是要在能够满足客户基本需求的基础上的，关键在于“度”的把握。一个好的风险控制方案，在企业信息化进展中更显得尤为重要。

 

     刚刚申请了个人空间，还请各位多多指教。对于测试本人也是新手，希望今后能得到各位的指导。。。。。。

     在这里先向各位大虾们问好了

这里主要是以赴IBM测试工程师为例，微软，HP等其他外企的测试外包也都大同小异。

　　1.测试外包的分类

　　测试外包可以分为两种：

　　一种是甲方公司将项目完全包给乙方公司，由乙方公司完全出人力物力，在乙方所在地完成项目;

　　一种是甲方公司“借用”乙方公司的员工，同甲方员工一起在甲方公司完成项目项目。

　　凡是赴某某外企工程师的职位都是属于后者。

　　2.IBM为什么要做测试外包?

　　可以降低成本和风险，在IBM工作的人分为Regular和Contractor(也称为Vendor)，Regular是IBM正式员工。Contractor是合同工，就是我们所说的外包。Contractor不按IBM工资标准，也不享受IBM薪酬福利。假如08年的经济危机真的影响到了中国，IBM大可以释放一部分Contractor来降低成本，而不需要裁自己的正式员工。(好在这件事情对IBM China并没有任何影响)，此外，Contractor的各种保险都是由乙方公司也就是外包公司负责的，所以出现什么事情的话，也是由外包公司负责，IBM不需要承担风险。

　　3.Contractor属于IBM员工么?

　　完全不属于，跟Contractor有关的只是外包你到IBM的外包公司。

　　4.薪酬

　　其实无论你去哪家外包公司，IBM给外包公司的钱都是固定的。你的薪水和福利待遇，完全看外包公司对你的“剥削程度”。外包公司扣掉给你交的四险一金，运营成本，想要的利润以后，剩下的就是你的工资了。所以，只要你会侃价，去哪家外包公司都一样，工资都会达到一个统一的水平。大概范围是：6500+ 到 8500+，至于怎样从6到8，就全评你个人的专业技术和经验了，这点还是相当的公平。

　　5.福利

　　在此说明一点，无论去哪家外包公司，4险一金的基数也不会是按照100%来交的，比如你的薪水是7k，那么公司会按照一定的系数来给你交4险一金，有的是按照30%，有的是按照50%。这个才是挑选外包公司的关键。因为有些公司表面给的工资很高，但实际上，4险一金给上的很少，这样的话，其实未必有工资低但福利待遇好的公司划算。因为工资高的话，相应的扣的个人所得税也多了，而如果公司将这部分钱交了住房公积金医疗保险等，这些钱是不需要缴税的，并且你交个人住房公积金医疗保险的同时，公司也是要按照比例交这部分钱的。

　　6.做外包测试的优点

　　做外包测试的优点不少

　　第一，你可以接触到很多其他公司接触不到的软硬件产品。比如在IBM，所有的软件我们都是可以在内网中使用的，而AIX，IBM小型机等等，也都很容易搞到。而在微软，我的一个朋友是做Windows7测试的，在微软还没正式发布以前，这些很玄的东东他们就可以上手，这个真是让人羡慕。

　　第二，可以跟同事学到很多技术。在这种大型外企中，你接触到的同时不是名校的博士就是名校的硕士，海归等等，如果想跟他们学点什么的话，没有人会对知识吝啬。

　　第三，会有一些培训。先不说Team的内部同事之间的互相培训，在平时每隔一段时间，也会有很多其他Team的同事会做一些新技术的培训讲座，这些讲座只要你有时间，都是可以去听的。

　　7.做外包测试的缺点

　　缺点一：做任何事情不可能没缺点的，做外包测试，最大的缺点就是缺少所谓的归属感。因为打你入职那天起，就是在甲方公司工作的，平时根本不需要回外包公司。很多人说看着旁边不是Regular就是其他外包公司来的Contractor，会觉得没有归属感。很多外包公司在这方面做出了努力，比如在你过生日的时候，外包公司会给你订一个大蛋糕送过来;每逢过节都送一些礼品和购物券;组织春游秋游等等。至于这些事情能不能增加归属感，就是仁者见仁，智者见智的事情了。

　　缺点二：很多开源产品在公司是不允许使用的(例如Hibernate，主要就是因为它需要遵循的开源协议)，而很多外面平时很常用的软件也没机会再使用(比如MySQL，在IBM一般都用DB2 or Derby)

　　缺点三：对IBM产品产生依赖性会比较麻烦。很多Contractor在IBM都会用Rational Application Developer或者是Rational Softeware Architect，因为它们的功能实在是太强大了。不过我一般还是选择用Eclipse，因为我怕离开IBM的时候，外面没公司买得起这些软件。

　　缺点四：很少有白盒测试。如果你一心想来这些外企做白盒测试，我觉得希望会比较渺茫，因为China这边很少有代码，所以做白盒测试的可能性就小了很多。最多是有时会针对一些API来用JUnit来写一些代码。

　　缺点五：做性能测试的不多，如果你以前是用LR等工具做性能测试的，那么来到这里会没用武之地(可以去HP做外包，LoadRuner是属于它的，我朋友在那里不但会常用，还会有免费培训)，因为IBM的性能测试要么是自己写一些脚本，要么就是用Rational Performance Tester。

　　缺点六：不要以为在IBM就会都用功能自动化测试，其实大部分工作都是黑盒手工测试。Rational Function Tester用的机会很少。不过每个Team发展都后期，都会自己写一点Automation Tools，来尽量简化自己的劳动，Shell，Bat脚本，Java程序等等。

　　8.加班

　　这点是我觉得做外包测试做爽的事情，因为在外企，根本很少加班。(强烈推荐那些加班加得伤心的人来这里疗伤)更爽的是早晚上下班并不需要刷卡，虽然我们也有门卡，但是纯粹是用来开门的，早晚都不需要太在意时间，当别人8点55分在马路上狂奔的时候，你可以悠闲的走着。

　　加班的情况也有两种：

　　一是项目特别特别紧，而你又没办法按时干完活，这个时候你就可以选择晚上晚走一点，加一会班。(其实每天需要干多少活是从项目一开始Leader就分配好了的，每天需要自己安排，Leader只会在项目快结束的时候才会关注你剩下多少活没有干，所以一般我都选择第二天多干点，坚决按点吃饭呵呵)

　　再就是跟老外开电话会议，而开会时间是他们的早晨。这种情况的话，需要在公司等到8点半(这段时间是自由的)，也就是他们上班，然后开1个小时的会。不过这种电话会议完全可以回家用家里的电话拨免费400上去去听。

　　9.技能要求

　　不要瞧不起我们这帮被“人贩子”卖掉的人，其实做外包测试，需要的技能还是很高的。很多自称“精通SSH的高手”，就连外包公司的笔试第一关都过不去。但也不要将测试外包想得太难。想做外包测试工程师，无外乎需要满足一下几个条件：

　　(1)本科学历(这个是最低要求，如果是硕士被录取的希望更大点)

　　(2)2年以上Java开发或者Java相关项目测试经验

　　(3)Java基础(相信混Javaeye的这个都没问题)

　　(4)有测试相关的经验

　　(5)最好会使用一些Linux基本命令

　　10.是否有转正的机会

　　很多人都关心这一点，问是否干了一段时间之后，就转为Regular。转是肯定有转的，但不是每个人都能转，主要看个人的机遇和能力。一般干外包干个2，3年，都会考虑这件事情，要么Team觉得你是有用之才，就留下转了，要么就继续晃荡着，直到你自己选择走人。

　　11.为什么是外包测试，不是外包开发

　　其实也是有外包开发的职位的，只不过比较少而已。这种大型外企，一般的coding都放在的国外，所以即使是Regular，也是测试工程师居多。

　　一时间只想到了这么多，如果有朋友对哪些问题还有疑问，欢迎回帖，我会以Q&A的方式贴到原文中补充。

今天看到一个帖子,大体意思是:我想参加测试培训,在一年时间内学好测试,拿高工资(7000-8000)…那么对于做测试1年(包含培训时间,实际工作只有半年)的朋友来讲,究竟能拿怎样的工资呢?会有那么高的工资吗?下面说一下我自己的一些看法:
       测试行业刚入行就拿高工资的，通常会有两种情况：一、精通一门以上外语（口语和阅读能力要求很高）且沟通能力很强。入职或外包到外企(比如:日、美等) 二、沟通能力很强，有编程基础，精通一门以上编程语言（具体要看公司要求），入职白盒测试（很多公司白盒都是由开发做的，可见对编程的要求比较高）或性能测试（自动工具使用和测试结果分析能力要求比较高,还要求会编写脚本）当然其他非正常的情况这里就不考虑了，比如有关系等
       那么请问，你的特长是什么？外语？编程？性能测试工具？
       如果你有特长（比如英语6级，口语好，日语好等），一年8千不是梦，08年有个朋友（没有测试工作经验），掌握双外语（英语（6级）+日语（不知道几级）），参加软件测试工程师培训5个月,还没毕业就于08年5月中旬被印度阿普泰克公司录取，试用期8000/月，一个月后转正12000/月,另外我现在的公司有个同事(2年多工作经验),08年8月份去大连的一家软件公司面试(试用期:月薪12000),公司明确承诺,如果测试技术不好,公司可以提供培训,但是英语一定要好,前面技术方面的面试、笔试都通过了,最后一关,和面试官用英语聊天的时候,被淘汰了,原因是哑巴英语,很多都说不出来……
       如果你没有特长：也有两种情况可以拿高工资，不过要付出的会比别人多的多（还和运气有关，不排除会有怀才不遇的情况）：一、创造特长：利用业余时间学习外语和编程（但是短时间学好很困难，因为外语学习是一个长期积累的过程还要有个良好的外语环境(哑巴外语是没有用的)，编程学习是经验的积累过程，假如都很容易学，那么谁都学的很好，那也不会有高工资了）而同时还要学好测试知识以及了解测试相关知识（比如：系统知识、硬件知识等）二、学好培训的每种技能的同时，在性能测试工具上下工夫，着重性能测试结果的分析上，因为工具用起来并不困难，难的是出了测试报告，怎么分析结果找出系统瓶颈。如果你做到了,那么我想,不久的将来,你会拿到你想要的待遇.
        对于只想通过培训，学好培训机构培训内容，就想拿高工资的人，那么一年7000-8000，只是个徐徐飘起的肥皂泡,虽然会越飘越高,但终有破灭的一天(找到工作的那天)，参加软件测试工程师培训要6个月左右时间（说明：培训的知识都是比较皮毛的知识（比如：性能测试（LR用起来并不难，难的是对测试结果的分析上），对测试结果分析讲的很少，而且自动工具放在最后快毕业的时候讲的,那时候面临找工作面试、毕业考试等,所以可能也没那么多精力去学习了.另外有很多地方连讲师都将不明白(要是比较一下一个高级讲师和高级性能测试工程师的待遇,也许你就会明白为什么讲师都有的地方会搞不清楚了)，功能自动测试工具（QTP比winrunner多了个关键字视图,所以对于不懂编程的人,比较好用一点）只能学到关键字视图下的脚本录制回放（脚本参数化，action分割，设置检查点，输出值等），而不能自己通过专家视图根据实际需要编写需要的脚本(因为要有编程基础)，实际工作中很多脚本是没有办法通过关键字视图进行‘傻瓜式’的录制回放的，所以，除非你有编程基础，不然学习编程语言又要花很长时间.完成一个系统的软件测试工程师培训，只能说明你有可能对测试已经入门（因为一般培训机构都是承诺推荐工作直到找到工作为止的，所以不排除没用心学习的人），学到的只是测试的基本思想和一些方法罢了，向实践转换还需要一个过程。找工作一般要半到一个月左右时间（因为测试通常有3次面试（有的公司会更多，比如：华为有6次面试）,第一次笔试,第二次技术部门面试,第三次人事部门面试。这样一轮面试下来也要一个多星期时间。）运气不好，可能要2个月甚至更长，拿北大青鸟为例（因为我参加的是北大青鸟的培训费16900，感觉蛮贵的，本来也考虑去51testing，因为51testing有个先就业后付款的优惠政策，而且性价比比较高，但是因为那时候在南京，南京还没有51testing培训点，所以去北大青鸟了），现在他们一个月开一个班，（08年10月份以后）一个班级30多人（07年一般都是10-15人左右，（我是07年参加培训的，所以用了那时的数据和现在的数据对比一下）现在每期都爆满，可能是受金融危机的影响吧），那么你想想6个月又出来多少跟你一样甚至比你优越的竞争者，再加上别的培训机构，比如51testing、NIIT），再加上5个月的工作经验（如果运气好一点的话，找了一个比较好的公司，员工之间没有隔阂，大家都很乐意帮助新人，那么你可能学到很多知识，当然那只是理想状态，现实中理想状态毕竟很少），找了好一点的公司（要看运气）4500-5500，一般的公司3500-4000（这个工资是在上海的，要是消费比较低的城市可能还没这么高的工资，要是在南京要减去1000左右，我以前在南京一起培训的朋友，刚毕业基本是2500-3000左右（南京））
      上面的分析都是根据实际情况分析的，涉及的数据都是相应时期的真实数据，
金融危机的影响
       裁员与失业，数据我就不统计了，大家可以在新闻报纸上看到很多这样的数据。那么我想问一个问题:
失业的人会甘愿永远失业吗？
      显然不会,他们面对自己的失败,大多数会反省和思考,会重新拟定自己的职业规划,淘汰是因为有不足,那么怎样弥补自己的不足呢?很多人自然而然的想到参加培训,充实自己,培训是种投资.那么他们会甘愿自己的付出得到的只是少的可怜的回报吗?显然不可能,每个人都希望自己的投入能够得到最大限度的回报,这时很多人把目光投向了目前的黄金行业IT行业尤其是软件行业….软件开发：培训费用高,而且需要周期长,刚培训完没有工作经验工作超难找(公司的好几个开发都这样和我讲过),而且一年内工资会很低（据同事讲05年的时候，才1000左右）.软件测试：随着国内测试行业的发展,和测试培训机构铺天盖地的宣传,使得很多人相信,这是个黄金职业,进入了就能有高工资(虽然这是个错误的想法,51testing有个帖子的楼主,好象是在苏州还是杭州的吧,2年WEB测试经验,现在工资降到1000多,还有其他很多面临裁员的测试员也不在少数)所以很多人踏上了,测试培训之路,这就大大增加了测试学员的就业竞争。
        测试岗位就那么多,甚至在减少,那么那么多测试学员怎样就业,怎样拿高工资呢?
        首先要做的不是分析目前的就业形势也不是分析哪家培训机构的性价比更高，而是要分析一下自己：你适合学测试吗?你学习测试的优越性在哪？你能忍受进入测试工作中，每天都做重复的事情吗？
        其次参加培训的时候，你要做的是怎样学好测试，而不是想我能学好吗？别人都有基础，我会超越他们吗？而是相信自己一定能学好。在测试学习过程中关注测试相关知识的学习.比如：操作系统、硬件知识等另外就是要重点学习,什么都会一点,没有突出的技能,别人认为你很平庸,有句俗话:一白遮三丑,那么假如你有一个技能掌握的很精,那么即使你某些方面做的不够好,也没有人会在意的
        再次参加工作以后，要将理论在最短时间内转化为实践,做好再学习的准备（毕竟培训的内容有很多都是理论上的，实际工作中难免会有所脱节，比如：写测试用例，写测试计划等）

个人认为软件测试人员在初期选择软件测试职业的时候，重点应该放在软件测试的能力锻炼和软件测试项目经验的积累上。这个时间应该在开始软件测试职业后的1年到1年半左右。

   当你进入软件测试岗位后，在当前的行业背景下，你的工资可能在2000～3000左右。建议你在这个阶段不要把心思放在如何如何增加你的工资上，而是集中你的所有精力如何快速的打好软件测试的基础、多参加项目、多经历。1年半后，你的工资大概在4000左右。

   同老徐共事过的软件测试人员大概在300人左右，在测试人员的工资情况上老徐还是有一定的发言权的。

   如果你选择的是性能测试这一个软件测试职业工种时，而你又具备了非常强的软件开发能力，你的最佳成长方式就是多多的参与各种软件测试项目，当然这个“各种软件测试项目”指的是大型的软件项目的性能测试工作，例如银行的各种大型应用系统、移动的大型应用系统、税务的大型应用系统、网通/电信的中大型应用系统等，在这个成长过程中还要发挥你的自学和刻苦精神，不断的学习诸如不同类型的操作系统（包括HP UNIX、Windows、Linux、IBM AIX等）、应用平台（包括Bea WebLogic、IBM WebSphere、Oracle IIS等）、数据库（Oracle、SqlServer、Sybase），对于这些，你不需要精通，但是要熟悉它，了解在性能测试中监控它的方法，掌握它的基本性能诊断方法，能向软件开发项目组提供有建设性的调优意见。

   我见过很多软件性能测试人员的发展历程，这当中有几个符合上面的最佳成长方式的人员，他们的工资在三年间从3000多快速的增加到了12000以上。

例一:(来自测试者家园)

如果你是测试员或是高级测试员，有志转向管理发展，那么需要加强以下内容，至少要做到几点：

　　1. 测试计划的编写（要结合测试的项目，能以此来控制和确定测试所需人员，设备及时间来管理测试时间）

　　2. 要熟悉BUG跟踪工具及软件测试流程（如: TD， Bugzilla， CQ等）

　　3. 要熟悉配置管理工具（如:TestCenter ，CVS， VSS等）

　　4. 要熟悉自动化工具（例如:WinRunner， QTP， Robot， RFT， Automation等，能结合录制完的脚本编写代码）

　　5. 要熟悉压力及性能测试工具（例如: AutoRunner，LoadRunner，webload， silkperformance等，能结合相关数据，分析出性能瓶颈）

　　6. 要熟悉或精通一门语言 （例如:Java，C++）

　　7. 要熟悉数据库（例如:Oracle， DB2， SQLServer， MySQL）

　　8. 要熟悉主流操作系统（例如: HPUnix，IBMAIX， Sun Solaris， Red HatLinux， SuSE Linux，Windows）

　　9. 能用英文流利的和老外交流以及往来Email

　　10. 语言表达能力强，表达问题清晰明了

　　11.沟通能力强，能和上级/开发经理很好的达成测试相关/BUG事宜

　　12. 学习技术的能力要强，能快速上手一个新的技术

　　13. 乐于与人交流

   对于应用系统的性能测试，测试模型的建立至关重要，性能测试模型要以实际生产环境为标准搭建，只有模型符合实际的生产环境，性能测试的结果才能真实有效的反映将来上线的生产环境的实际性能情况。根据长期测试关键核心业务系统的经验，应用系统系统的性能测试模型分析应当按照下面几个步骤来实施：

　　●        业务模型建立

　　全面分析应用系统系统上线后所面临的性能压力的来源和类别，并且通过分析历史交易数据来确定各种性能在整个系统压力所占比例。例如确定前台应用子系统的业务类别和并发比例，后台批处理业务的数据规模和类别等。最终目的是建立一个能够逼真模拟应用系统系统实际运行场景的业务模型。

　　●        测试数据模型建立

　　根据业务模型准备测试数据和基础数据，确保系统数据库中数据容量和真实性符合实际运行情况。

　　●        监控模型建立

　　性能测试的目的不仅仅是获得关键业务的性能指标，同时也要通过性能测试监控主机、数据库、中间件的各个性能指标，从而发现性能瓶颈，为进一步的性能调优提供准确的参考数据。

　　●        测试模型建立

　　对应用系统系统的测试，因该采取基准测试、单业务负载测试、混合负载测试的顺序来执行。这样做的好处，在单业务负载测试是就可以发现各个系统本身的性能缺陷，而混合负责测试时将重点检查各个业务相互影响导致的性能缺陷。

　　●        执行模型建立

　　应用系统系统的性能测试必须要局方客户、系统开发商、第三方测试服务商紧密配合，才能保证整个测试工作的成功。因此，只有建立一套规范的性能测试流程，明确各个角色的工作职责，才能使性能测试工作有序、高效的开展。

　　●        风险模型建立

　　由于性能测试的特殊性，因此在整个测试过程中，会遇到很多导致整个性能测试失败的风险。丰富性能测试经验是必须的，能够提前分析可能遇到的各种风险并制定相应的规避措施。这样才能将性能测试的风险降到最低，最终圆满完成应用系统系统的上线性能验收测试。

　　上面的步骤或者说方面只是性能测试项目实施中要完成的工作方面的的概述，不同的项目可能有不同的实施方法或步骤要视项目而具体实现。要完成一个有效的应用系统的性能测试，从需求调研到测试分析的各个阶段，有很多工作需要完成，在以后的文章中，会对性能测试项目的分阶段工作进行讲解，适当的时侯会搭配一些项目实施的例子来进行讲解。

项目基本情况：联结手机和website的C/S系统，在client端和server端都已上线的情况下对现在的软件进行升级，增加新的功能。

　　项目最大风险：在发布新功能的同时必须保证旧的client端能配合新的server端正常使用以前的功能。

　　项目时间控制方式：项目开始之前有要做的feature list，针对每一个feature制定一个due date,当有新功能点加入，往后顺延相应的时间。

　　项目目标实现：项目达到预期目标并且顺利release。

　　关于测试的体会：

　　1、需求理解

　　a）带着solution问问题比盲目地去向客户要答案效果要好得多,在问一个问题之前，想想可能的解决方案以及它们的优缺点，一方面可以帮助自己理清思路，另一方面，可以节约双方的时间，减少沟通成本。

　　b）对讨论的问题，尽量做到百分百understanding，即使是需求讨论中确认过的东西，大家的理解到后期也可能也会有所偏离，所以如果是图例，格式方面的需求，最好是有简单的样本可以参考，如果是概念性的东西，最好是交流的双方用流程图或者复述的形式来加深印象。

　　c）随时更新详细的新需求到需求跟踪软件或需求说明文档当中去，做到有据可查。目前项目中用jira的跟踪方式，把需求以comments的形式附加在每一个issue之后，当针对单个功能点有疑问的时候，可以快速找到需求，解决问题。缺点在于没有集中的需求文档，需要凭记忆来找到对应的jira号，所以在大型的项目里，可以采取jira记录为主，不断更新初始的需求文档为辅的方式。

　　2、测试执行

　　a）测试过程中注重所用条件是否涵盖真实用户的使用情况，在测试开始之前，了解待测项目中各种数据的含义，并且有意识地模拟产生用户有可能用到的数据，有利于在后期的测试过程中发现问题。

　　b）做任何判断之前，重新确认一遍需求，避免无意识的遗忘，特别是那种自认为需求烂熟于心的地方，花十秒钟时间回顾一下，说不定会有意外发现。

　　c）即使对项目当前的功能点很清楚，也还是应该有一份测试参照表格，比如一份简洁明了的测试点分析表格，在测试的时候可以帮助自己整理思路，有效提高测试效率。

　　d）重视兼容性测试，定期备份重要数据。在产品已上线的情况下发布新版本，为了不影响以前用户的使用，开发人员在开发新功能的时候必须确保新的Server端版本可以向下兼容。作为测试人员，需要在每一次版本发布的时候，用新的Server端代码来匹配以前的Client端版本，来确定确认开发人员所提交的东西不会影响以前的功能。同时，在同步开发修改的东西之前，应该对重要的数据做一些备份，比如DB，以防同步时不恰当的不可逆操作破坏现有的数据。这种做法可以保障测试工作在安全的前提下进行。

　　3、时间控制方式

　　本项目中，预留了足够的时间做estimation，为每一个issue确定最终的due date，并且严格按计划进行。

　　好处：透明地控制项目进度，项目组的成员都可以对当前项目进展有自己的度量。

　　弊端：每一个issue里都包含了Test时间，如果开发方面有Delay的话，直接影响测试时间，另外，公司实行弹性工作制，项目组成员工作时间的不固定，会加重这一矛盾。

　　可试行的解决方案：明确划分项目组中不同角色各自的时限。当然，这种方式在某种适度上是很难做到的，因为很少有时候可以完全正确地估计开发者的时间，测试可以在需求分析阶段积极寻找可能出现的问题，降低后期陷入被动状态的机率。

　　4、测试风险回顾

　　在本项目的测试过程中，主要出现过以下几方面的风险：

　　a）开发人员无法按时提交代码，导致测试工作无法按时开展。

　　b）客户在临近发布时提出功能性的修改，需要在压缩的时间内执行测试。

　　c）测试过程中发现高优先级的bug,需要超出预计的时间返工修改。

　　可借鉴的经验：

　　a）开发人员调整任务优先级，可以相互帮忙，先解决高优先级的issue，尽量按时release。

　　b）如果没有办法按时完成，尽早通知客户。

测试如何尽早介入
        基于以前的测试经验，我们也越来越认识到测试人员应该尽早介入项目的重要性。简单地沿用测试V模型往往出现很多问题，特别是在项目进度拖延的情况下更是如此。如果测试人员一味固执地被要求严格案照V模型定义的标准来开展测试工作的话，则结果往往是在项目初期测试人员工作量极度不饱和(很多测试人员无所事事)，而到了项目后期，一旦项目经理决定压缩测试时间，测试人员就不得不加班加点工作。
        但是，不少朋友实践“测试人员尽早介入”的效果并不理想，例如：

 1.测试人员参加项目前期的各种会议，会被当作“专职的”会议记录员。
 2.测试人员参加代码评审，又不甚了解程序开发语言，浪费了时间其丢失了自信。

实际上，在项目开发初期，测试人员可以开展很多有价值的工作，例如：

1.评审需求文档的正确性和可测试性；根据需求文档整理和分析测试需求，清晰明确的测试需求事测试设计的基础。
2.在开发设计过程中，根据需求文档和设计文档进行测试设计，测试设计方案事测试用例的保证。
3.和项目团队中的集成组和开发组协商软件版本的编译方式和编译进度以及测试人员提取版本的方式和进度。
4.开发人员每天下午4：30前提交所有可编译的代码，每天晚上进行日编译；
5.开发经理根据版本稳定情况，每周提交测试申请单。
6.测试人员根据测试进度需要，提取测试版本。
7.提前准备测试环境，包括数据库环境，操作系统和Web一用服务器，以及复杂集群环境。
8.如果项目需要，还可以在此阶段研究一下自动测试工具，包括一些准备外包测试的工作。


根据产品的成熟度调整测试策略
       开发测试一盘棋。测试经理应该有大局观，保持测试策略总与开发的进展相一致，保证最终的软件成果最佳（而不是测试部发现Bug最多）。合理制定不同阶段的测试策略，会收到不错的效果。

产品开发期同情的测试
       要忍！要在这个能够发现大批Bug的黄金时段学会做减法。就现实而言，这个阶段的产品，大多难以满足系统测试的条件。如果进行追杀式的测试，无疑会加重开发人员的焦虑心情，甚至对测试产生逆反心理。
       另一方面，测试工作部应停滞，特别式不少测试人员对产品的了解还流于皮毛，抓紧时间进行“测试练兵”非常有必要。因此，，“产品开发期”的测试切忌生硬。其实，此时程序人员也知道产品还不成熟，所以要测试经理要告诉测试执行人员：

1.这个阶段不要提交界面简单错误和易用性方面的Bug（可以先记录下来到项目末期提交），否则会使开发人员质疑测试人员发现简单的Bug。
2.换位思考，了解此时开发人员最关心的功能是否能正确运行，多对基本功能进行测试。

产品成熟期积极的测试
        随着产品的不断成熟，主要功能的实现已经趋于完善，关键路径的测试已经不成问题。此时的程序员们，压力已经大大减轻，他们的工作重点也从“构建”转移到了“修复Bug”，这个阶段程序员对于Bug的接受程度是最高的，对Bug的修复和反馈也非常积极。于是，此时的测试工作应对整个产品的细节和所有路径进行覆盖测试，保证测试的全面性，层层深入地测试产品值得测试的各个部分，尽可能多的发现并报告Bug。

产品稳定期多样的测试
       在这个阶段，可以尽情的向开发人员报告产品易用性和界面的Bug；可以充分发挥每个测试人员的想象力，根据以往的测试经验来搭建测试场景，构造测试数据；可以通过不同业务场景的不同操作，通过特殊的测试数据，以及相对复杂的集群测试环境来进行多样化测试。
       为什么？因为测试必须测试得更加深入，才能发现更深层次得Bug，于是多样性的测试、探索式得测试必不可少。

产品发布期谨慎的测试
        在临近产品发布的日子，包括测试在那的很多工作都变得谨慎起来：代码的提交权限受到了控制，只保留开发经理一个入口；测试的重点更加具有防御性，要仔细测试每个变更，还可以组织“结对测试”来增加测试的保障。

知己知彼，合力制胜
1.获取程序员信任，及时沟通
         不要与被测程序的开发人员形成不必要的敌对关系。如果能与打交道的程序员共享信息，比如他们的计划、设计文档的早期草案合早期原型等，测试工作会更加有效。越早提出你的意见和反馈，了解程序员提交前完成的工作。

2.主动出击，提供服务
 
》在测试前期，直接向开发人员提供服务；这不仅可以建立信任，而且还可以证明测试人员使能够与之合作的人。我们在项目过程中提供给开发人员的服务：
对工作流的运算逻辑构件进行了测试，方便了后期开发工作流客户端应用的使用。

对内部版本和原型进行测试。

对需求文档的可测试性进行评审。开发人员和测试人员一样，对模棱两可的要求很头疼，他们非常希望测试人员的介入。

帮助程序员建立测试环境，方便程序员进行测试。

3.耳目作用
在项目过程中，测试人员有机会能够发现很多存在的问题，比如：需求和设计以及开发的不一致性，项目计划中工作任务的缺失等等。测试人员不要仅局限与测试命令链本身，及时验证和发现项目环节中的问题。

测试项目能否成功，与整个项目组的精诚合作是密不可分的。测试人员是一种服务角色，要乐于接受这种角色，只有这样，才能得到被服务的人帮助和支持，以及认可。

鉴于我作为招聘者的身份，给应聘者一些中肯的建议：

　　1、简历具有针对性

　　经常会收到一些简历，注意其应聘职位一栏，什么软件工程师、硬件工程师、测试工程师、网络维护等等，凡是51job上能选的全选了，我就在想，这位真是全才呢？还是对自己定位不清呢？再看看其工作时间，不过就一半年的样子。看到这样的简历，多半不会看完就直接删除了。

　　建议：一定要对自己的职业有个定位。记住，你不是全才！如果你是全才，你的简历不会出现在我的邮箱。

　　2、技能突出

　　突出描写出自己在这个行业所掌握的技能，吸引招聘者的注意力。

　　3、经验突出

　　详细描写自己的项目经验，尤其在项目测试工作中遇到关于技术/技能问题，你是如何通过怎样的技术/技能解决这些难题！这个一般的简历中很少看见，可以简单的加进去，作为你简历的亮点。

　　总结一下我作为一个技术招聘者的筛选心理，首先：

　　第一，是否明确自己要应聘测试职位。

　　第二，技能是否满足当前职位的要求。

　　第三，项目经验中有没有过待聘职位的经验。

　　其后的事就是人力资源部的了，看你怎样发挥了。

    集成测试，也叫组装测试或联合测试。在单元测试的基础上，将所有模块按照设计要求（如根据结构图〕组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。

集成测试方法

　　集成测试应该考虑以下问题： 　　1、在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失； 　　2、各个子功能组合起来，能否达到预期要求的父功能； 　　3、一个模块的功能是否会对另一个模块的功能产生不利的影响； 　　4、全局数据结构是否有问题； 　　5、单个模块的误差积累起来，是否会放大，从而达到不可接受的程度。 　　因此，单元测试后，有必要进行集成测试，发现并排除在模块连接中可能发生的上述问题，最终构成要求的软件子系统或系统。对子系统，集成测试也叫部件测试。 　　任何合理地组织集成测试，即选择什么方式把模块组装起来形成一个可运行的系统,直接影响到模块测试用例的形式、所用测试工具的类型、模块编号和测试的次序、生成测试用例和调试的费用。通常，有两种不同的组装方式：一次性组装方式和增值式组装方式。 　　集成测试的实施 　　集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素： 　　1、是采用何种系统组装方法来进行组装测试； 　　2、组装测试过程中连接各个模块的顺序； 　　3、模块代码编制和测试进度是否与组装测试的顺序一致 　　4、测试过程中是否需要专门的硬件设备； 　　解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。 　　在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应测试应安排在这些设备能够投入使用之时，并需要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。

集成测试完成标准

　　怎样判定集成测试过程完成了, 可按以下几个方面检查: 　　1、成功地执行了测试计划中规定的所有集成测试； 　　2、修正了所发现的错误； 　　3、测试结果通过了专门小组的评审。 　　集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。 　　在完成预定的组装测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果、在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。 　　集成测试 　　集成测试（也叫组装测试，联合测试）是单元测试的逻辑扩展。它的最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层意义上讲，组件是指多个单元的集成聚合。在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合，并最终扩展进程，将您的模块与其他组的模块一起测试。最后，将构成进程的所有模块一起测试。此外，如果程序由多个进程组成，应该成对测试它们，而不是同时测试所有进程。 　　集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别。 　　集成测试是在单元测试的基础上，测试在将所有的软件单元按照概要设计规格说明的要求组装成模块、子系统或系统的过程中各部分工作是否达到或实现相应技术指标及要求的活动。也就是说，在集成测试之前，单元测试应该已经完成，集成测试中所使用的对象应该是已经经过单元测试的软件单元。这一点很重要，因为如果不经过单元测试，那么集成测试的效果将会受到很大影响，并且会大幅增加软件单元代码纠错的代价。 　　集成测试是单元测试的逻辑扩展。在现实方案中，集成是指多个单元的聚合，许多单元组合成模块，而这些模块又聚合成程序的更大部分，如分系统或系统。集成测试采用的方法是测试软件单元的组合能否正常工作，以及与其他组的模块能否集成起来工作。最后，还要测试构成系统的所有模块组合能否正常工作。集成测试所持的主要标准是《软件概要设计规格说明》，任何不符合该说明的程序模块行为都应该加以记载并上报。 　　所有的软件项目都不能摆脱系统集成这个阶段。不管采用什么开发模式，具体的开发工作总得从一个一个的软件单元做起，软件单元只有经过集成才能形成一个有机的整体。具体的集成过程可能是显性的也可能是隐性的。只要有集成，总是会出现一些常见问题，工程实践中，几乎不存在软件单元组装过程中不出任何问题的情况。从图1可以看出，集成测试需要花费的时间远远超过单元测试，直接从单元测试过渡到系统测试是极不妥当的做法。 　　集成测试的必要性还在于一些模块虽然能够单独地工作，但并不能保证连接起来也能正常工作。程序在某些局部反映不出来的问题，有可能在全局上会暴露出来，影响功能的实现。此外，在某些开发模式中，如迭代式开发，设计和实现是迭代进行的。在这种情况下，集成测试的意义还在于它能间接地验证概要设计是否具有可行性。

集成测试的目的

　　是确保各单元组合在一起后能够按既定意图协作运行，并确保增量的行为正确。它所测试的内容包括单元间的接口以及集成后的功能。使用黑盒测试方法测试集成的功能。并且对以前的集成进行回归测试。 　　一、集成测试过程 　　二、单元测试工作内容及其流程 　　三、集成测试需求获取 　　集成测试需求所确定的是对某一集成工作版本的测试的内容，即测试的具体对象。集成测试需求主要来源于设计模型（Design Model）和集成构件计划（Integration Build Plan）。集成测试着重于集成版本的外部接口的行为。因此，测试需求须具有可观测、可测评性。 　　1． 集成工作版本应分析其类协作与消息序列，从而找出该工作版本的外部接口。 　　2． 由集成工作版本的外部接口确定集成测试用例。 　　3． 测试用例应覆盖工作版本每一外部接口的所有消息流序列。 　　注意：一个外部接口和测试用例的关系是多对多，部分集成工作版本的测试需求可映射到系统测试需求，因此对这些集成测试用例可采用重用系统测试用例技术。 　　四、集成测试工作机制 　　软件集成测试工作由产品评测部担任。需要项目组相关角色配合完成。如图示： 　　软件评测部： 　　软件项目组： 　　集成测试工作内容及其流程工作流程： 　　五、集成测试产生的工件清单 　　1、 软件集成测试计划 　　2、 集成测试用例 　　3、 测试过程 　　4、 测试脚本 　　5、 测试日志 　　6、 测试评估摘要 　　六、集成测试常用方案选型 　　集成测试的实施方案有很多种，如自底向上集成测试、自顶向下集成测试、Big-Bang集成测试、三明治集成测试、核心集成测试、分层集成测试、基于使用的集成测试等。在此，笔者将重点讨论其中一些经实践检验和一些证实有效的集成测试方案。 　　•自顶向下集成测试 　　自顶向下集成（Top-Down Integration）方式是一个递增的组装软件结构的方法。从主控模块（主程序）开始沿控制层向下移动，把模块一一组合起来。分两种方法： 　　第一：先深度：按照结构，用一条主控制路径将所有模块组合起来； 　　第二：先宽度：逐层组合所有下属模块，在每一层水平地沿着移动。 　　组装过程分以下五个步骤： 　　步骤一：用主控模块作为测试驱动程序，其直接下属模块用承接模块来代替； 　　步骤二：根据所选择的集成测试法（先深度或先宽度），每次用实际模块代替下属的承接模块 　　步骤三：在组合每个实际模块时都要进行测试； 　　步骤四：完成一组测试后再用一个实际模块代替另一个承接模块； 　　步骤五：可以进行回归测试（即重新再做所有的或者部分已做过的测试），以保证不引入新的错误。 　　•自底向上集成测试 　　自底向上的集成（Bottom-Up Integration）方式是最常使用的方法。其他集成方法都或多或少地继承、吸收了这种集成方式的思想。自底向上集成方式从程序模块结构中最底层的模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）事前已经完成组装并经过测试，所以不再需要编制桩模块（一种能模拟真实模块，给待测模块提供调用接口或数据的测试用软件模块）。自底向上集成测试的步骤大致如下: 　　步骤一: 按照概要设计规格说明，明确有哪些被测模块。在熟悉被测模块性质的基础上对被测模块进行分层，在同一层次上的测试可以并行进行，然后排出测试活动的先后关系，制定测试进度计划。图2给出了自底向上的集成测试过程中各测试活动的拓扑关系。利用图论的相关知识，可以排出各活动之间的时间序列关系，处于同一层次的测试活动可以同时进行，而不会相互影响。 　　步骤二: 在步骤一的基础上，按时间线序关系，将软件单元集成为模块，并测试在集成过程中出现的问题。这里，可能需要测试人员开发一些驱动模块来驱动集成活动中形成的被测模块。对于比较大的模块，可以先将其中的某几个软件单元集成为子模块，然后再集成为一个较大的模块。 　　步骤三: 将各软件模块集成为子系统（或分系统）。检测各自子系统是否能正常工作。同样，可能需要测试人员开发少量的驱动模块来驱动被测子系统。 　　步骤四: 将各子系统集成为最终用户系统，测试是否存在各分系统能否在最终用户系统中正常工作。 　　方案点评: 自底向上的集成测试方案是工程实践中最常用的测试方法。相关技术也较为成熟。它的优点很明显: 管理方便、测试人员能较好地锁定软件故障所在位置。但它对于某些开发模式不适用，如使用XP开发方法，它会要求测试人员在全部软件单元实现之前完成核心软件部件的集成测试。尽管如此，自底向上的集成测试方法仍不失为一个可供参考的集成测试方案。 　　•核心系统先行集成测试 　　核心系统先行集成测试法的思想是先对核心软件部件进行集成测试，在测试通过的基础上再按各外围软件部件的重要程度逐个集成到核心系统中。每次加入一个外围软件部件都产生一个产品基线，直至最后形成稳定的软件产品。核心系统先行集成测试法对应的集成过程是一个逐渐趋于闭合的螺旋形曲线，代表产品逐步定型的过程。其步骤如下: 　　步骤一: 对核心系统中的每个模块进行单独的、充分的测试，必要时使用驱动模块和桩模块; 　　步骤二: 对于核心系统中的所有模块一次性集合到被测系统中，解决集成中出现的各类问题。在核心系统规模相对较大的情况下，也可以按照自底向上的步骤，集成核心系统的各组成模块。 　　步骤三: 按照各外围软件部件的重要程度以及模块间的相互制约关系，拟定外围软件部件集成到核心系统中的顺序方案。方案经评审以后，即可进行外围软件部件的集成。 　　步骤四: 在外围软件部件添加到核心系统以前，外围软件部件应先完成内部的模块级集成测试。 　　步骤五: 按顺序不断加入外围软件部件，排除外围软件部件集成中出现的问题，形成最终的用户系统。 　　方案点评: 该集成测试方法对于快速软件开发很有效果，适合较复杂系统的集成测试，能保证一些重要的功能和服务的实现。缺点是采用此法的系统一般应能明确区分核心软件部件和外围软件部件，核心软件部件应具有较高的耦合度，外围软件部件内部也应具有较高的耦合度，但各外围软件部件之间应具有较低的耦合度。 　　•高频集成测试 　　高频集成测试是指同步于软件开发过程，每隔一段时间对开发团队的现有代码进行一次集成测试。如某些自动化集成测试工具能实现每日深夜对开发团队的现有代码进行一次集成测试，然后将测试结果发到各开发人员的电子邮箱中。该集成测试方法频繁地将新代码加入到一个已经稳定的基线中，以免集成故障难以发现，同时控制可能出现的基线偏差。使用高频集成测试需要具备一定的条件: 可以持续获得一个稳定的增量，并且该增量内部已被验证没有问题; 大部分有意义的功能增加可以在一个相对稳定的时间间隔（如每个工作日）内获得; 测试包和代码的开发工作必须是并行进行的，并且需要版本控制工具来保证始终维护的是测试脚本和代码的最新版本; 必须借助于使用自动化工具来完成。高频集成一个显著的特点就是集成次数频繁，显然，人工的方法是不胜任的。 　　高频集成测试一般采用如下步骤来完成: 　　步骤一: 选择集成测试自动化工具。如很多Java项目采用Junit+Ant方案来实现集成测试的自动化，也有一些商业集成测试工具可供选择。 　　步骤二: 设置版本控制工具，以确保集成测试自动化工具所获得的版本是最新版本。如使用CVS进行版本控制。 　　步骤三: 测试人员和开发人员负责编写对应程序代码的测试脚本。 　　步骤四: 设置自动化集成测试工具，每隔一段时间对配置管理库的新添加的代码进行自动化的集成测试，并将测试报告汇报给开发人员和测试人员。 　　步骤五: 测试人员监督代码开发人员及时关闭不合格项。 　　按照步骤三至步骤五不断循环，直至形成最终软件产品。 　　方案点评: 该测试方案能在开发过程中及时发现代码错误，能直观地看到开发团队的有效工程进度。在此方案中，开发维护源代码与开发维护软件测试包被赋予了同等的重要性，这对有效防止错误、及时纠正错误都很有帮助。该方案的缺点在于测试包有时候可能不能暴露深层次的编码错误和图形界面错误。 　　以上我们介绍了几种常见的集成测试方案，一般来讲，在现代复杂软件项目集成测试过程中，通常采用核心系统先行集成测试和高频集成测试相结合的方式进行，自底向上的集成测试方案在采用传统瀑布式开发模式的软件项目集成过程中较为常见。读者应该结合项目的实际工程环境及各测试方案适用的范围进行合理的选型。 　　集成的验证 　　《集成测试设计用例》中所设计的功能测试用例必须全部通过，性能及其他类型测试用例通过90%以上。在未通过的测试用例中，不能含有 ‘系统崩溃’和‘严重错误’错误，‘一般错误’小于5%。

   压力测试（Stress Testing）是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的工作负荷的，再次压力测试是要使应用程序的使用达到峰值。

一、压力测试（Stress Testing）的概念

   概念之一【压力测试】来自Visual Studio .NET 设计分布式应用程序可靠性测试：是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。对每个单独的组件进行压力测试后，应对带有其所有组件和支持服务的整个应用程序进行压力测试。集中测试从最基础的功能测试开始。您需要知道编码路径和用户方案、了解用户试图做什么以及确定用户运用您的应用程序的所有方式。测试脚本应根据预期的用法运行应用程序。例如，如果您的应用程序显示 Web 页，而且 99% 的客户只是搜索该站点，只有 1% 的客户将真正购买，这使得提供对搜索和其他浏览功能进行压力测试的测试脚本才有意义。当然，也应对购物车进行测试，但是预期的使用暗示搜索测试应在测试中占很大比重。
   概念之二【压力测试】来自.net应用程序性能测试：压力测试用来评估在超越最大负载的情况下系统将如何运行。压力测试的目标就是发现在高负载的条件下应用程序的缺陷(BUG)。包括： synchronization issues, race conditions, and memory leaks（内存泄漏）。压力测试能让您识别程序的弱点和在极限负载下程序将如何运行。
   概念之三【压力测试】压力测试主要是为了发现在一（任意）定条件下软件系统的性能的变化情况。通过改变应用程序的输入以对应用程序施加越来越大的负载（并发，循环操作，多用户）并测量在这些不同的输入时性能的改变，也就是通常说的概念：压力测试考察当前软硬件环境下系统所能承受的最大负荷并帮助找出系统瓶颈所在。其实这种测试也可以称为负载测试，但是负载测试通常描述一种特定类型的压力测试——增加用户数量以对应用程序进行压力测试。

   网上可能还有多于以上三种所描述的对压力测试这个名词的定义。

   我比较赞同第一种概念，压力测试应该是指模拟巨大的工作负荷以查看应用程序在峰值使用情况下如何执行操作。扩展开来说，其一压力测试应该是较短时间的，其次是模拟巨大的工作负荷的，再次压力测试是要使应用程序的使用达到峰值。对这三点继续补充，对第一点长时间的压力测试就转变成了负载测试；对第二点，对应用程序施加的压力是超负荷的，所以要不断地加压；第三点，使应用程序的使用达到峰值，如果超过这个界限则应用程序会崩溃或错误率激增，这个峰值是针对某一时刻来说的，也是针对某个临界的压力来说的，转变为场景设置中的说法就是能够支持的最大并发用户数。

二、如何进行压力测试51Testing软件测试网 

   在最近的一次测试中定义了测试的目的是：需要了解AUT（被测应用程序）一般能够承受的压力，同时能够承受的用户访问量（容量），最多支持有多少用户同时访问某个功能。在AUT中选择了用户最常用的五个功能作为本次测试的内容，包括登录。大概的需求就是这样。

   接下来我AUT的登录说一说怎么用LoadRunner和Jmeter来实现场景的设置达到测试的目的。（注：对服务器的检测不是本次测试的重点，本次测试主要收集并发访问用户数和发生错误用户数）

首先是对脚本的要求：
1、录制脚本（注意所有的脚本都应录制到Action中），自定义事务，事务从提交用户名和口令的脚本之前开始；
2、在定义事务开始的脚本前加入集合点；
3、在脚本中加入检查点，以登录成功的页面出现登录用户的ID即可；
4、参数化登录用户的身份；

其次是对场景设置的要求：
1、因为事先我们不知道将有多少用户访问是临界点，所以在测试过程中需要多次改变用户数来确定；
2、建议修改运行时设置，优化对服务器的访问；
3、计划的设置，每x时间后加载10用户（根据总用户数设置），完全加载后持续运行不超过5分钟（根据需要设置）；
4、集合策略，当运行中的用户数100%达到集合点时释放；
5、注意事项，需要注意几个时间：1）服务器响应超时时间；2）登录事务迭代一次所使用的时间；3）集合点等待超时时间；4）计划中设置的间隔时间。在我的测试中事务运行一次的时间不超过30秒，通过修改脚本使它的运行时间达到一分钟左右，服务器响应超时时间、结合点等待超时时间、计划中设置的间隔时间都设置为了2分钟。

   这样场景开始运行后运行用户数呈阶梯增长，另外在每个上升点新增的用户都会随原来已经运行的用户并发访问服务器。
   通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据定义可接受错误率就可得到该功能的最大并发访问的用户数。
   以上测试中排除了对网络、客户端等的要求。在实际测试中首先要保证这些资源是足够的。
   使用Jmeter也能够达到上述描述的场景的测试，并且更加的便捷。

   测试（Load testing）、压力测试（Stress Test，应称为强度测试）和性能测试，这三个概念常常引起混淆，难以区分，从而造成不正确的理解和错误的使用。之前，也有不少讨论，比较有名的，应归为Grig Gheorghiu's的两篇博客：

Performance vs. load vs. stress testing
More on performance vs. load testing
     负载测试、压力测试和性能测试的测试目的不同，但其手段和方法在一定程度上比较相似，通常会使用相同的测试环境和测试工具，而且都会监控系统所占用资源的情况以及其它相应的性能指标，这也是造成人们容易产生概念混淆的主要原因。
     我们知道，软件总是运行在一定的环境下，这种环境包括支撑软件运行的软硬件环境和影响软件运行的外部条件。为了让客户使用软件系统感到满意，必须确保系统运行良好，达到高安全、高可靠和高性能。其中，系统是否具有高性能的运行特征，不仅取决于系统本身的设计和程序算法，而且取决于系统的运行环境。系统的运行环境会依赖于一些关键因素，例如：

系统架构，如分布式服务器集群还是集中式主机系统等。
硬件配置，如服务器的配置，CPU、内存等配置越高，系统的性能会越好。
网络带宽，随着带宽的提高，客户端访问服务器的速度会有较大的改善。
支撑软件的选定，如选定不同的数据库管理系统（Oracle、MySQL等）和web应用服务器（Tomcat、GlassFish、Jboss、WebLogic等），对应用系统的性能都有影响。
外部负载，同时有多少个用户连接、用户上载文件大小、数据库中的记录数等都会对系统的性能有影响。一般来说，系统负载越大，系统的性能会降低。
     从上面可以看出，使系统的性能达到一个最好的状态，不仅通过对处在特定环境下的系统进行测试以完成相关的验证，而且往往要根据测试的结果，对系统的设计、代码和配置等进行调整，提高系统的性能。许多时候，系统性能的改善是测试、调整、再测试、再调整、……一个持续改进的过程，这就是我们经常说的性能调优（perormance tuning）。
    在了解了这样一个背景之后，就比较容易理解为什么在性能测试中常常要谈负载测试。从测试的目的出发、从用户的需求出发，就比较容易区分性能测试、负载测试和压力测试。性能测试是为了获得系统在某种特定的条件下（包括特定的负载条件下）的性能指标数据，而负载测试、压力测试是为了发现软件系统中所存在的问题，包括性能瓶颈、内存泄漏等。通过负载测试，也是为了获得系统正常工作时所能承受的最大负载，这时负载测试就成为容量测试。通过压力测试，可以知道在什么极限情况下系统会崩溃、系统是否具有自我恢复性等，但更多的是为了确定系统的稳定性。
     那么，如何给负载测试、压力测试下个定义呢？根据上述讨论，我们可以给出如下的定义：

负载测试是模拟实际软件系统所承受的负载条件的系统负荷，通过不断加载（如逐渐增加模拟用户的数量）或其它加载方式来观察不同负载下系统的响应时间和数据吞吐量、系统占用的资源（如CPU、内存）等，以检验系统的行为和特性，以发现系统可能存在的性能瓶颈、内存泄漏、不能实时同步等问题。负载测试更多地体现了一种方法或一种技术。
压力测试是在强负载（大数据量、大量并发用户等）下的测试，查看应用系统在峰值使用情况下操作行为，从而有效地发现系统的某项功能隐患、系统是否具有良好的容错能力和可恢复能力。压力测试分为高负载下的长时间（如24小时以上）的稳定性压力测试和极限负载情况下导致系统崩溃的破坏性压力测试。
     压力测试可以被看作是负载测试的一种，即高负载下的负载测试，或者说压力测试采用负载测试技术。通过压力测试，可以更快地发现内存泄漏问题，还可以更快地发现影响系统稳定性的问题。例如，在正常负载情况下，某些功能不能正常使用或系统出错的概率比较低，可能一个月只出现一次，但在高负载（压力测试）下，可能一天就出现，从而发现有缺陷的功能或其它系统问题。通过负载测试，可以证明这一点，某个电子商务网站的订单提交功能，在10个并发用户时错误率是零，在50个并发用户时错误率是1%，而在200个并发用户时错误率是20％。
    负载测试是为了发现系统的性能问题，负载测试需要通过系统性能特性或行为来发现问题，从而为性能改进提供帮助，从这个意义看，负载测试可以看作性能测试的一部分。但它们两者的目的是不一样的，负载测试是为了发现缺陷，而性能测试是为了获取性能指标。因为性能测试过程中，也可以不调整负载，而是在同样负载情况下改变系统的结构、改变算法、改变硬件配置等等来得到性能指标数据，从这个意义看，负载测试可以看作是性能测试所c的一种技术，即性能测试使用负载测试的技术、使用负载测试的工具。性能测试要获得在不同的负载情况下的性能指标数据。
    通过负载测试和压力测试都可以获得系统正常工作时的极限负载或最大容量。容量测试，自然也是采用负载测试技术来实现，而在破坏性的压力测试中，容量的确定可以看作是一种副产品——间接结果。
    综合所述，负载测试、压力测试和性能测试的概念可以概括如下：

负载测试是通过改变系统负载方式、增加负载等来发现系统中所存在的性能问题。负载测试是一种测试方法，可以为性能测试、压力测试所采用。负载测试的加载方式也有很多种，可以根据测试需要来选择。
性能测试是为获取或验证系统性能指标而进行测试。多数情况下，性能测试会在不同负载情况下进行。
压力测试通常是在高负载情况下来对系统的稳定性进行测试，更有效地发现系统稳定性的隐患和系统在负载峰值的条件下功能隐患等。