1、Testing1目 录1. 测试组是助力研发软件质量还是拉软件周期后腿？ 22. 关于软件项目后期 Fix bug 的意义之我见 .23. 只会黑盒测试算专业的软件测试人员吗？ 44. PS 是什么意思 85. 软件测试员-你的路在哪里？ 86. 由“游戏测试” 引发“ 手机测试 ”的一些感想 107. 专业测试人员发展的未来 128. 软件测试工程师的分类从新手到专家 139. 在浏览器地址栏按回车、F5、Ctrl+F5 刷新网页的区别 1610. 从一个测试实验想到的 1711. 手机测试之详谈 1912. 软件测试之敏捷的质量 2113. PRD2314. 软件测试随想 2315. 要想
2、做好软件测试工作，就要学会思考并问为什么 2416. 浅谈软件测试用例编写及要点 2717. 什么是探索性软件测试 2718. 关于接口测试 2819. 由单元测试看功能自动化软件测试 2920. 从 BUG 的“ 一生”闲谈软件测试工程师面试 3121. 关于 API 测试 .3322. 软件开发中的破窗效应 3423. 软件测试管理之绩效考核 3724. 软件测试的 Bug 统计是在浪费时间 .3925. 聊聊自动化软件测试为什么推广难 4226. 回归测试的策略及方法 4327. 基于会话的探索性测试管理 4528. 软件测试人员的核心技术能力，应该是什么？ 4629. 如何入门软件测试
3、的职位 4730. 需求的来源 48Testing21. 测试组是助力研发软件质量还是拉软件周期后腿？软件测试团队作为软件研发部门的一个组成部分，一度听到的都是软件测试很重要，要重视软件测试。可在当下现实环境中，你有想过软件测试也会拉后腿？！当研发团队中开发人员资源比较紧缺，而任务比较重，项目比较急的情况下，若全部经过测试组，在软件质量保证的同时，必然出现了软件周期延长，项目上线延 迟的问题。倘若测试人员对任务周期安排不恰当，对很早提交的任务进行测试，发现问题让开发人员重新熟悉程序进行解决，又必然占用大量精力和时间。在开发人 员原本就很紧张的情况下，加剧了问题的严重性。这就出现了测试组测与不测
4、的问题。若测试，软件周期太长，影响项目上线和客户使用；若不测，软件质量没保证，影响上线维护和客户使用。这是一个很矛盾的问题。有一个解决方法，任务开发完直接升级到现场，由开发人员和设计人员进行测试验收。这样测试组干嘛？为什么会出现这种问题呢？很显然，开发人员紧缺是个很关键的问题，因为开发人员既要开发代码，也要改代码bug，还要支持现场代码版本等问题。所以开发人员可以不充裕，但是不能紧缺。可能目前还存在开发人员技术水平和业务经验的问题，这也影响了开发速度和开发质量。另外，说说测试组吧。曾经测试流程出现过问题，测试组在家里测过的程序升级到现场仍会出现不可用。后来改进流程，程序升级至现场测试环境进行测
5、试，增强程序运行环境真实性和程序版本兼容性。现在面临的上述问题，跟测试组本身也有很大关系。从两方面讲，第一缺乏技术含量。为什么开发人员不能缺，而测试人员可以没有。因为测试人员目前所做的大部分工作可以被开发人员和工程人员所取代，只是不那么全面专业罢了。测试人员没有自己特有的测试技术。有的话可以说是对业务逻辑的测试经验了，但是我仍然认为这不是真正的测试技术。不要怪我讲的这么露骨，我认为这是事实，不用掩饰的。第二不了解实际需求。尽管工程人员做的测试可能相对没那么全面，但是他们至少比我们更清楚客户的实际需求。他们可以避轻就重的进行测试，这样就可以满足 客户使用的主要功能没有问题，其他小问题慢慢解决了。
6、作为测试人员，要尽可能测试全面，不遗漏任何功能点，因为不清楚客户实际会怎么使用。这种方法和思想 是正确的，只是在项目中客户群体比较小和使用频度不高的情况下，相对花费了不少时间。2. 关于软件项目后期 Fix bug 的意义之我见众所周知：基本上所有的软件项目到后期必不可少的是 fix bug，一个软件在交付客户后或交给测试人员测试时都存在一些程序员意想不到的问题。现在有一些成熟的 bug 跟踪系统，譬如：bugzero，bugzilla， redmine 等等。Testing3解 bug 是很头痛的问题，一般是以下原因引起的：（1）设计上的缺陷；（2）写代码时考虑不周全；（3）测试人员无中生有
7、；（4）所依赖的插件，框架本身的缺陷。第一种情况：最棘手，需要修改程序架构，费时又费力，但是不改又不行总不能要客户该需求，按照你的程序来吧。没办法，改吧。第二种情况：还好，看看是那里出来问题，改改代码就可以了，但是改完后需要确认一下会不会对其他模块或功能造成影响。一般如果影响很大的话，那就是模块之间的耦合度太高，不是高质量代码，会越改越乱。第三种情况：a、撰写需求文档时，对软件需求设计模糊不清，让人产生歧义。譬如在编写需求文档时考虑不周留下让人发挥想象的空间，或前后矛盾。b、测试人员或者软件开发人员对没有真正理解需求，譬如文化差异导致理解不一致。c、测试跟你有仇。呵呵。第四种情况：软件越是开发
8、到最后，bug 的难度越大。因为这时你对代码一丁点的改动就有可能引发新的 bug，这里不管你的设计的如何如何好，模块与模块之间的耦合度 如 何如何低，都不可避免。深层次的问题也慢慢暴露出来，那就是你项目依赖的东西，譬如第三方的插件，框架本身的缺陷或者由于对他的不了解造成的误用。这些 bug 才是最头疼的。鸡肋鸡肋啊，弃之可惜，用之可悲。不过，作为一个执着的程序员或软件工作人员，基本的职业道德还是要有的，不能有了难解决的 bug 就退缩。实际上虽然解决 bug 学不到新东西，但是还是有好处的：（1）可以让你更加深入的了解你自己，了解自己一直以来被忽略的“缺陷”。（2）考验你的耐心和忍耐度，极限。
9、（3）增加程序员之间的沟通，促进感情交流。Testing4这个要说一下，遇到自己解决不来的 bug，可以请能解决的人帮忙看看，有了高人指点也能让自己多学点东西，学的不是这个 bug 这么解决的，而是人家遇到问题的思考方法为什么比你宽广，找到原因后，你就可以和他一样无所不能了。哈哈。（4）可以在闲暇之余给自己冲冲电。项目初期和中期都是比较忙的，任务满满的，基本没有闲暇时间。后期就不一样了，bug 少的人就可以多一点自己的时间。呵呵，就看你这么利用了。3. 只会黑盒测试算专业的软件测试人员吗？本文是写给测试新人及还未入测试行业的人。对已经有很多很丰富测试经验的人来说可以略过哈。在测试行业飞速发展的
10、今天，越来越多的人和企业重视软件测试。测试行业的发展掀起了大众学习测试的浪潮。很多新人，在各种论坛学习时，经常会看到的是大家在热火朝天的讨论着各种测试理论及测试工具，什么黑盒测试，白盒测试，功能测试，性能测试，回归测试，自动化测试，什么 winrunner，loadrunner，Testdirector，Quicktest pro可能也因为这个原因，导致有的人一听说别人是做测试，喜欢问的第一个问题就是，你们测试是做白盒测试还是黑盒测试？或者就是，你们测试用什么工具呢？也许他们认为：如果测试人员只会黑盒测试，而不会使用几种测试工具，不会用写测试脚本，不会做白盒测试，就算不上一名专业的测试人员。而
11、我要说得是，作为测试人员，功能测试是一切测试的基础，它就像 if 语句是开发的基础一样，做不好功能测试，不管你会使用多少工具，不管你的测试脚本写的多么出神入化，你的测试工作都是不可能做好的。而功能测试仅仅是黑盒测试。我大学毕业后在一家软件公司上班。从程序员开始做起。对应届毕业生刚进公司，这家公司的特点是不会马上安排你做开发工作，而是先从测试开始做。这个时候，我接触了软件测试。初期的测试很简单，给你一个产品，点点这个按钮，按按那个图标，从这边输入一些数据，在那边看看输出是否正确等等。也许没有真正做过测试，或者说没有做过一个项目完整的功能测试的人，就会片面的认为所谓的“功能测试”和“黑盒测试”就是
12、这样，给你一个产品，点点这个按钮，按按那个图标，这边输入一些数据，在那边看看输出是否正确。Testing5而功能测试仅仅是这样吗？上面描述的这种功能测试顶多能算个单元功能测试。功能测试的重点不在单元测试，测试人员做单元的功能测试顶多是帮助开发人员调试调试产品而已。功能测试的难点和重点都在项目的集成测试和系统测试。举个简单的例子来说明一下：一个客户需求：公司部门人员考核情况混乱，无法在月底得到每个人每一项绩效考核分数及总分数。希望解决的问题：建立公司人员管理。建立考核项管理。员工绩效考核分数查询。解决方案：建立公司人员管理，建立考核项管理，建立分数档案。将人员管理、考核项管理和分数管理关联起来。
13、设计：数据库：建 3 个主表，人员管理表，考核类型管理表，分数总结表，将 3 个表关联起来。数据访问层：对表的访问及处理方式（增加，删除，修改等）业务处理层：界面，数据的录入，各种业务处理。项目的功能测试一、首先设计项目测试计划。测试计划内容包括：1、测试时间，测试阶段划分2、测试进度及人员安排3、测试环境，测试资源（测试方法，测试工具等）二、然后设计项目测试用例。项目需求分析结束后，进行测试用例书写，用例内容包括以下部分：（功能测试重点）Testing6检查是否实现了公司人员管理。如果满足了人员管理，那么在这个人员管理中，是否所有的数据都能够正确处理。是否所有错误数据都能合理处理。如果没有满
14、足，那么还有哪些地方需要补充。检查是否建立了考核项的管理。如果有考核项的管理，那么是否所有的管理数据是否能够正确处理，是否所有的错误数据都能合理处理。如果没有满足，那么还有哪些地方需要补充。检查这个产品是否建立了分数档案管理如果分数档案进行了统一管理，那么所有的数据是否正确处理了，是否所有的错误数据也合理处理了。如果没有满足，那么还有哪些地方需要补充。检查各个模块之间的关联是否都正确。（难点）例如：当某一员工考核项里面分数变化后，员工分数统计表里面分数是否也重新计算了。当客户要求业务全面能够满足后。检查产品的各种业务流程中的输入输出是否都是正确，各种错误输入都能够正确处理。进入各个界面检查。检
15、查各个页面的布局是否合理，界面是否友好按钮等等是否能够正常使用输入输出是否正确操作是否简易等等Testing7三、按照测试计划，测试用例实施测试。首先根据测试用例检查产品的设计、实现是否能满足客户的要求，可根据需求追踪矩阵制作的 checklist 进行检查。然后实施测试用例：除了执行上面已经写好的测试用例外，实施测试用例还有个难点是设计测试数据。（因为测试数据等跟产品的设计，产品结构等有很大的关系，所以测试数据只能在产品已经成形后，才能具体设计。）四、发现问题后，记录 BUG，并跟踪，并根据修改及影响情况，进行回归测试。（这一点项，任何测试都是一样的。而且也是非常重要的，在这里我也不详细解释
16、了，详细对 BUG 记录及 BUG 跟踪进行讲解的文档也是非常多了，包括缺陷管理工具。）这就是一个项目功能测试的基本流程。上面所描述的也只是项目功能测试的冰山一角。真正实施起来时，还有很多的细节需要处理，比如：如何才能写一个合理的测试计划；如何合理安排测试进度；测试用例用什么形式写；发现了 BUG 怎么进行汇报和跟踪；什么情况下需要做大量的回归测试等等。举这个例子就是想纠正一些人的错误观点。功能测试这样的黑盒测试一点都不简单。它要求对需求和业务有非常深刻的理解。同时最好要有软件开发知识或编写代码的经验，能理解产品的设计，实现的过程。最后很重要的是，能够根据需求和设计实现，写出好的用例，构思出合
17、适的测试数据来找出产品中的错误。这些是测试的基础，方法和工具是测试的辅助手段。测试做的好坏也并不是你会写代码，你会做白盒测试，你会做使用好多好多种工具，你就能好测试了。测试的基础一定是功能测试，如果你连产品的功能，业务流程等都不能够完整的理解，那么你的测试是不可能做好的。当然，也并不是只要会做功能测试就一切 ok 了。如果永远只会做功能测试，只会做黑盒测试，不会白盒测试，不会写测试脚本，不会使用工具，那么你的测试道路只会越走越窄。写测试脚本，使用工具等都是提高测试水平很好的方法，但是前提是要有好的基础。最后建议一下测试新人，刚入行时，不要盲目的学习各种各样的工具及写漂亮的测试脚本。学这些肯定是
18、有用的，但是要分清主次。测试初期，首先要练 习自己的基本功：比Testing8如如何写“测试计划”，如何去理解一个产品的设计原理，业务流程，如何写“测试用例”，怎么设计测试数据。再学习些开发的知识，能理解 产品的一些重要设计和实现原理等。这些都学的比较扎实后，再去考虑学习工具和各种各样的测试方式来提升自己。相信通过这样的学习模式，你的测试道路会越走越宽，越走越好4. PS 是什么意思主要有两个方面，一：p.s 是 postscript 缩写，顺便说一下，补充一下。postscript 英音：pustskript美音：post,skrIpt 名词 n. C1.(信末的)附笔,又及(略作 P.S.
19、)She added a postscript to her letter. 她在信末又附了一笔。 2.(书等的)附录,跋二。是 PhotoShop 这个图像处理软件的缩写，当然，不是说这软件啦，是泛指用这类软件做的东西，像以前华南虎事件中，人们广泛怀疑，这个图是 PS 出来的。5. 软件测试员-你的路在哪里？之前，我中部的一个的城市，做着一个快乐的测试员，工作不太忙，对一切技术充满了好奇心。测试工作不专业，也不受重视。但我有自己的快乐。工作不忙的时候，我今天学学性能测试+loadRunner，明天学学自动动化 selenium。老大说，你对咱项目做个性能测试吧。然后，我就跑去问百度、谷歌和
20、群里的朋友，它他告诉我需要什么样的工具，什么环境，主要看哪些指标，然后再送我两个报告模板，照猫画虎的给做完交任务了。突然对自动化又产生了兴趣，找 视频、找资料、买书忙碌的不亦乐乎。发现要会语言，没事儿咱有的是时间，上电驴上下视频吧。当第一次用 struts2 写一个登录时还是很兴奋的。前台后台中间件数据库。噢！原来用户做一个登录，我们的系统是这么运行的。哈哈。很开心！再回到自动化上去，当第一次用 QTP 录制了一个脚本，运行的时候，看着屏幕真心的笑了，好像电脑被黑客操控了一样，各种操作都不用手的。Testing9后来，听说外面的世界很精彩，为一颗不安分的心，我还年轻，我不能局限在这悠闲的生活中
21、 消磨自已。有人说毕业的五年很重要，毕业的五年可以将会让同学之间的距离拉得很远。而且五年后的样子也基本可以看出你后半生的样子。所以，这五年不能输在 起跑线上。这才是真正人生的起跑线，学校的成绩与之相比一文不值。然来，我就来到了大城市，这里薪资比以前高一倍多。这里的有专业的团队，规范的流程，测 试与开发平起平坐。我应该感到高兴，我们受到的重视，找到了工作的价值。繁杂业务，因为刚来，我每天都在熟悉都各种被测系统的业务，各种文档、需求、用例。第一轮-第二轮-第三轮-报告-总结。你每天都很忙，有时为了赶系统上线，甚至需要加班。你无暇学习新 的技术。然后，习惯了这个薪水，你会发现他越来越不够用，等着每年
22、微薄的调薪，也许刚好够赶上物价的上涨，干了三到五年之后，你想到换一份工作来提高薪 水，你可以要高薪的资本是什么？规范的流程，对不起，我们公司流程和你上一家不同。对业务的熟悉程度。对不起，我们公司的业务和你上一家不同。你还需要重 新学新的流程和业务。噢！噢！我去面试测试主管和经理，请问你有管理经验吗？你如何去协调整个团队？噢！噢！那我在工作之余学学性能测试或自动化。这时你的尴尬就出来了，你已经快奔三十了。对于性能和自动化的理解，因为都没有太多的项目经验。而根据你的情况，你们只能应聘“初级”性能或自动化测试员。初级开的薪资也许还没你目前的薪资高。你是做呢？还是放弃呢？找一个比目前薪资低的职位，已经
23、不单单是你个人所决定的了（你背后有一个家）因为初到一个陌生的城市，第一份工作，要薪资也是参考年龄同工作经验，技术水平又差不多的朋友。所以，一直很好奇，当做测试快奔三的朋友处在一个什么价 位，大概对自己三到五年之后处在一个什么状态做一个评估。当然，决定价位会有各种因素，我只想知道一个比较普遍的现象。所以，问了一个大我几岁的朋友。测试进阶的三个阶段我把测试分三个阶段吧！以我的鼠目寸光目前只能看到三个阶段。刚入测试的朋友应该都属于第一个阶段，薪资 2 到 3K 都具多，当然也更低或偏高的。大概都属于第一阶段，而且大部分对进的公司测试这一块不专业。由于，初做测试，对各种测试技术充满好奇，热情很高。然后
24、，工作一到三年之后跳到第二阶段，薪资也会 5 到 6K 的样子，因为他们有了工作经验，再找到这个价位的工资应该不是特别困难。基本上所有人都可以从第 一阶段进级到第二阶段，只是所用的时间有长有短，资质好的一年，资质略差的三年。没有鄙视谁的意思，当然还要看机遇之类的。主要还是看你对测试技术掌握速 度和程度。我把第三阶段定位 1w 以上，从第二阶段往第三阶段走，不再与工作年限有太直接的联系，谁能告诉我工作八年的就一定比工作六年 有能力强，但工作三年的大多情况要比工作Testing10一年的优秀。这个阶段比较漫长。是第二阶段与第三阶段的一个沟。能给你这个价位的公司和岗位也不多。而且你需要在 这个行业里
25、独特的技能，大多人所不具备的。当然，我这三个阶段是三十岁之前的，测试技术在中国的发展也很短暂，有专业做了十年测试的人都很少。你想三十岁时是一个什么状态？6. 由“游戏测试”引发“手机测试”的一些感想基于当前智能手机的大盛世，出门见到的人十有八九拿的都是智能手机，不再是有按键的“砖头”-“诺基亚”，而且全触摸屏的智能手机。“火腿肠”-HTC、苹果、三星、摩托罗拉.不同的公司，不同的操作系统，在出厂之前都需要手机系统测试员的参与。不少人把这项工作看成是空手套白狼的好事-玩手机也能拿钱！实际上并非如此。虽然手机系统测试员确实能从工作中得到乐趣，但是它仍然是一份严肃的工作，远不像人们想象的那样轻松。如
26、果你想要成为手机系统测试员，本文将揭开这一年多以来我从事手机测试员的真实生活，为你揭开这项工作的帷幕一角。希望对你有些帮助记得刚出校门出来找工作的时候，我们老师都跟我们说，如果不想做编程开发这方向的工作，叫我们可以测试，数据库这方面的工作考虑考虑当时很多人的目标就是-软件测试。我就面试了现在这家公司的手机测试，成了一名手机测试员。其实在投简历之前，对软件测试真的很陌生，虽然上网查了很多的资料，知道测试分白盒测试、黑盒测试、单元测试、系统测试、回归测试什么的。可是脑海里还是没有测试的具体概念。面试的时候，面试官，也就是我现在公司的总监和我部门的经理，问了一个让我现在都印象深刻的问题“知道手机有什
27、么功用吧？”。我回答：“当然知道，上网，听歌，玩游戏啊什么的。”基本功能，打电话、发短信这些懂吧？“当下大红脸啊舍本逐末手机最基本的、最原始的功能不就是打电话和发短信嘛。我竟然不过现在很多人用手机更多的应该是上网、听歌、玩游戏什么的。不然直接买一个功能机不就得了。何必花那么多钱买一个高档货，只是用来打电话、发短信。脑子又没毛病，是吧？刚开始工作的时候，我确实不知道到底应该怎么测，每天到公司就是拿着那个手机在那里上上网，听听音乐，玩玩游戏，有时只是在那里插拔 USB 线，开机关 机，这样持续了差不多一个礼拜，搞得我都有点神经质了，后面才慢慢的在同事的帮助下，知道到底要做些什么事。也渐渐的步入正轨
28、。Testing111、手机系统测试员并不是总在上上网、听听音乐、玩玩游戏的玩手机公司主要做的是 android 源码的二次开发，测试的核心任务跟玩手机完全是两码事，测试员在整个系统测试过程中重复进行单调的测试工作，来检测系统的 bug。举个例子，手机系统测试员的一项普通测试工作可能是不断地切换相机和摄像机，然后记录报错的次数。另一项常见的工作是触摸屏的测试，不断的玩游 戏，记录出现定屏，死机，重启或者不灵敏等等的问题出现的次数和频率。或者不断的插拔 USB，检查端口是否会引起死机等重大问题。测试员的日常工作进度都是由项目组长来安排和调整的，还要随时配合做各种压力，性能测试，并随时受其监督；因
29、此，测试员很少有机会干预或者改变测试内容。工作中，测试员必须准确描述 bug 提交发生 bug 的 log 和截图，以便研发部能清楚的了解 bug 并修改它。此外，测试员基本上无权选择测试那些模块。即便你是一个网虫，喜欢上网，看视频，看小说。即便你是一个游戏迷，喜欢玩游戏。你可能每天面对的是不断的发 短信，发彩信，打电话，开机关机不过对于喜欢音乐的人倒是有点好处。智能手机都能后台播放音乐。可以边后台播放音乐，边测试。这个倒是挺对得起喜欢 音乐的人。不过对于旁边不喜欢ta 播放的音乐的人来说就是一场悲剧了不管测试何种模块，测试员很可能很长时间重复的同样的功能，同样的操作过程。所谓的玩手机很快就变
30、成了乏味的”工作”了。2、从事手机测试是一个进入手机软件产业界的极好途径对于想成为富有激情，充满干劲的手机软件、手机游戏设计师、美工和程序员的年轻人来说，首先成为一名手机系统测试员也许是开创事业的绝好途径。不过，工 作中测试员一般很少有机会与系统开发团队进行深入的交流。然而，开朗、外向的性格还是能让你有机会结识你想认识的人物。跟所有入门级的工作一样，系统测试 以外的上层职业空间非常广阔。但是留给你寻找机会的时间非常有限，并且你很难仅仅依靠这个职位获得更大的发展。尽管如此，测试仍然是进入 IT 产业最好的入门职业之一。通过它，你能了解系统开发的全过程，还能遇到你职业生涯中“贵人”。手机系统测试的
31、学习曲线上升很快，一个渴望成功的测试员，能在几周之内理解许多制作和开发过程。通过勤奋和刻苦的工作，少数测试员能赢得令人垂涎的地位。同时系统测试的经验也能让你的简历在竞争中脱颖而出。3、测试员的现状也是有喜有忧测试职位的门槛低，入门简单，基本上大专的都能胜任，也不一定需要什么玩手机的高手什么的，核心任务就是发现、重现 bug。了解、熟悉手机功能当然有助 于测试员完成这项工作，但这并不意味着测试员必须玩过很多的手机接触过很多的智能手机。某些优秀的测试员在此之前也没怎么深入的研究过手机的那些七七八八 的功能。新手观察模块功能跟老手或者系统开发工程师不同，他们经常会发现后者永远无法发现的 bug。当然
32、测试的Testing12工资也极低。某些项目要求超长的工作时间， 通常都要加班加点的。而且晋升也不是那么容易。测试员应该具有以下的职业素质：强烈的职业道德，卓越的沟通能力，良好的口语和文档表达能力，耐心和细心。换句话说，要求你对所有的功能模块一视同仁，而不是喜欢某一个模块，就死死的盯着那个模块天天在那里按4、大多数测试员都善于与人交往，而且在工作中容易相处测试员并不是你想象中的疯子，一直抱着那个手机在那里折腾，他们不会沉迷于手机某些功能，也不会一玩上瘾就不理不顾的。不可否认，总有一些测试员是沉迷 于某些功能的疯子；但是所有的行业中都有“疯子”，况且，这些人都做不了多久。这是因为测试员的成功须要
33、良好的沟通技能。更重要的，许多 bug 很难靠个人 的力量发现，这时测试员需要与同事一起来发现这些 bug。而且，测试员必须准确地将 bug 向同事描述清楚，以便他们能有效地解决出现的问题。最好你需要在狭小的工作间里进行长时间的工作。这时，你的同事就成了你的朋友和家人。每天 13 到 14 个小时的工作，你有大把的时间跟同事相处，因此你必须与他们交流。最终你必然疏远了自己的家人和朋友，因为他们并不了解你的工作；作为回报，同事会给你莫大的支持。7. 专业测试人员发展的未来根据 Google/微软一些大公司开发和测试融合分工新的趋势，未来的 IT 世界有可能会发展出一种新的场景和分工： 基本的功能
34、测试设计执行和白盒测试技能应该让所有开发人员都所具备，然后才能解放出专业的测试人员去做复杂的测试工作（非 功能测试、beta 测试、测试执行平台打造等），有时间去研究如何提高整个研发团队的测试质量与测试效率，更好地辅导开发人员掌握基本测试技能，当然开发 人员依然要通过交叉测试来解决测试心理学的问题（不能自己测试自己）。开发将对自己的局部代码质量负责，测试专注整体架构的质量与团队的整体测试体系建 设。这种模式的收益：团队中功能测试人员的数量会减少，研发中的很多低级 bug 会尽早在开发团队中被发现从而减少 bug 后期发现的成本和沟通成本，既减少研发成本又能加快研发速度。这样一种测试分工模式成为
35、现实后，测试人员的工作会更有创造性更有趣，更偏重脑力劳动，而简单的测试工作岗位会更少，市场会需要更多测试专家，简单的测试设计和部分手工执行会由开发人员担当，更多测试执行由自动化来实现，而这也正是敏捷开发模式中的现象。Testing13未来某些公司中 tester 会出现少而精的状况但是不会消失，当然由于各个公司组织能力建设的程度不同，吸引中高端人员的能力不同，现有的测试模式和新的 测试模式会长期共存，而那些能吸引中高端人才的公司则会出现更高效率的研发团队，结果是测试人员的工作更多是技术创新，开发人员测试工作的技术顾问和执行 复杂的测试任务。8. 软件测试工程师的分类从新手到专家两个重要的概念。
36、1、经验。不仅仅是我做过什么什么，做了多少多少次，多少多少年，更重要的是在一次次重复的过程中，发生了思维的改变。直白一些说就是在做的过程中不断的思考、学习、改进。否则就只是重复了 N 次，而并没有对等的经验。这个问题在一直以来的面试中经常遇到，很多声称有 4 年经验的 tester，其实只是重复了很多工作，而经验只能相当于2 年。2、情境。区分从新手到专家各个不同等级的重要标志，直白的说，就是一个人对当前所需要解决的问题认识的是否准确。这个不太好量化，牵扯到一个“怎么知 道自己认识的是否准确”的问题，所谓的“决策失误”之类的，就是这么个事情。作者的一个观点是“新手通常乐观而无畏，而专家就谨慎的
37、多”。-进入正题了，说说从渺小变强大的过程吧，在讨论的过程中需要反复的引用“经验”和“情境”这两个概念。NOTE： 新手 和 专家 不是绝对的。你可以在某个领域是专家，而在另外一个领域是新手。1、新手：对所需要处理的问题毫无经验。 作为一个新手，最大的期望是有一个 list 让他照着做就顺利的把事情搞掂，而不是给他一些建议让他自己去尝试悲观点估计，他会因为无法理解复杂的概念体系以及受挫而变得烦躁易怒、痛苦不堪，并可能随时放弃。所以对待新手的最好方法就是前面那个。 当新手手执一份 list 时，表现的会像个专家，因为你可能会发现他的思路很有条理、很靠谱这个典型的例子就是呼叫中心的座席，典型的 i
38、f.else.else.else.then.end 的模式 新手的最大特点，就是无法处理任何异常/例外的情况，哪怕是跟 list 上稍有差别当然，也有些胆子大的敢胡乱折腾。Testing14 专家可以写出完美的 list 供新手化装成专家，但如果专家自己用这个 list 来工作，则可能表现的还不如那个新手化装成的专家。很绕口，不过的确是这么个意思。 在公司里，常见的新手是应届生/实习生。2、高级新手 高级新手与新手的最大不同，在于有了一点经验（注意前面对“经验”的定义），并开始尝试着通过学习来独立解决一些局部的、具体的问题，但通常属于依葫芦画瓢，画得有点费劲，并且可能不太像。 高级新手开始有了
39、一些碎片化的知识和经验，但对需要解决的问题缺少系统化、结构化的认识。 例如一个 tester 能在文档的帮助下独立完成对环境的搭建和 test case 的执行以及 bug 提交等工作，并且最重要的是他开始能够借助 Google 解决一些技术上的例外情况；或者，一个初级开发人员能通过 Google 或 API 的学习编写一些小段的功能代码。 在公司里，通常我们把高级新手称为初级工程师。3、胜任者：团队中的中坚力量 对于自己所从事的工作，胜任者已经掌握了现有的一整套工作思路/方法，并能用来解决相同领域的各种不同问题。例如，一个测试工程师可以理解不同系统的需求，并根据用例设计方法设计出测试用例；同
40、时，他能够与不同的项目团队进行沟通，完成项目的各项测试工作。既是对于不同的业务领域，也能较快的学习上手。 胜任者掌握了处理解决类似问题的多种方法，并且有能力区分当前哪个方法更适用。 胜任者拥有完全独立工作的能力，而 新手 和 高级新手 通常需要 胜任者 的监督和帮助。 在公司里，通常胜任者是 中级工程师。4、精通者 相比 胜任者，精通者做到了“知其然，知其所以然”，不单单能根据当前的情境（参照上面对情境的定义），更有能力思考如何改进原有的解决方法/方式，以更高效的解决问题这依据的是其对技术、业务、过程的结构化、系统化的理解和思考。 精通者 能够理解一些抽象的信息，甚至从中吸收一些新的东西但未必
41、一定要通过动手实验，进而提出新的抽象模型/模式。Testing15 对于精通者来说，具体的技术/工具已经不是其完成工作的障碍。 对新手和高级新手的容忍度很低。5、专家 已经不再受任何规则/指南的约束，解决自己领域的问题对他们来说似乎不需要思考，如在前文中提到的，专家使用的是“直觉”，这种通过长期大量反复的实践、总结和思考/冥想以后，已经由意识层面进入了潜意识层面的东西。 专家可以把自己的解决思路/模式梳理成 list/指南，但是他深知无法将所有的细节和例外都包含其中，而这些细节和例外，就是“情境”中最重要的部分，甚至各种细节变化的累加，足以使一件事情 变成了另外一件事情，而专家总是能从容的处理
42、这一切。另外，因为专家深知这一切，在他未表现出来的内心中会对问题保持谨慎的态度，而相对的，新手或高级新 手有一种盲目的乐观。 如果你要专家使用自己编写的 list/指南去工作，他将无法施展出自己的才能，甚至表现的像个高级新手。所以，对于专家不要要求他像其他人那样工作。 如果你见过真正的太极高手，就能体会到什么叫“行云流水”一般，一切显得从容不迫，而这就是专家给人的感觉可以做到完美，并且感觉不到他是在处理那些胜任者无法想明白的难题。 据说人群中能成为专家的，只有 1%-5%，所以貌似不用强求自己一定要成为专家，做个精通者也挺好的。-讨论完了从新手到专家的过程，早来说点其他有趣的东西。1、专家应该
43、尝试编写指南供新手和高级新手操作，并为胜任者和精通者提供培训和指导，但应该避免直接培训新手和高级新手。2、精通者同样无法忍受新手和高级新手，所以最好去帮助胜任者把事情做得更好。3、胜任者是培训和指导新手和高级新手的最佳人选。但是，如果缺少了精通者和专家的指引和帮助，胜任者想突破自己将是一个非常痛苦和漫长的过程。4、新手需要“被驾驭”，别理解错了，他们需要在有明确指引的情况下快速的完成任务，快速收获成就感，否则很容易被挫折打败。5、高级新手需要更多的激励和实践，以帮助他正确的理解当前所从事的工作，并尽快成长为胜任者。Testing166、合理的人力结构并非金字塔结构，团队中新手和专家都不要太多。
44、据统计，大概是这样的（书中只有图例，我大概的估算了一下）：高级新手 40%，胜任者 30%，精通者 10%，新手 15%，专家 5%。7、但如果是一个 agile 团队，新手和高级新手都不要太多，因为 agile 中充满着各种“隐喻（oracle）”和“经验之谈”，这将大量依靠精通者和专家来解读和运作。8、在推动团队前进方面，精通者与专家有同样的价值。9. 在浏览器地址栏按回车、F5、Ctrl+F5 刷新网页的区别其中，在地址栏按回车又分为两种情况。一是请求的 URI 在浏览器缓存中未过期，此时，使用 Firefox 的 firebug 插件在浏览器里显示的 HTTP 请求消息头如下：Host
45、 192.168.3.174:8080User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language zh-cn,zh;q=0.5Accept-Encoding gzip, deflateAccept-Charset GB2312,utf-8;q=0.7,*;q=0.7Connection keep-aliveHTTP 返回状态显示 200
46、OK，但是，后台 Nginx 服务器的 access.log 并没有找到该请求的记录，说明请求并没有真正提交到 HTTP 服务器。而是被浏览器发现缓存中还有 未过期的文件，直接把请求拦截了，firebug 里面显示所谓的“请求头消息 ”、 “响应头消息”都是浏览器“伪造”的。这种刷新，使用的网络流量是最小 的，可以说完全没有，时间消耗也是最少的。就像你找到一盒没有过期的牛奶，觉得肯定没有问题，谁都没告诉就喝了。二是请求的 URI 在浏览器缓存中已过期，此时， firebug 显示的 HTTP 请求消息头如下：Host 192.168.3.174:8080User-Agent Mozilla/5
47、.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language zh-cn,zh;q=0.5Accept-Encoding gzip, deflateAccept-Charset GB2312,utf-8;q=0.7,*;q=0.7Connection keep-aliveIf-Modified-Since Mon, 04 Jul 2011 10:12:40 GMT多了一行 If-
48、Modified-Since，后台 Nginx 服务器的 access.log 也找到了该请求的记录，说明浏览器对这种情况的处理方法是：再 问一下服务器，请求的 URI 在某个时间之后有没有被修改过，而这个时间是由上次 HTTP 响应的 Last-Modified 决定的。服务器鉴定之后，没有修 改的话，返回 304 Not Modified，浏览器收到后，从缓存里读出内容；有修改的话，返回 200 OK，并返回新的内容。这种情况，就像你找到一盒已经过期的牛奶，于是问别人，Testing17还能不能喝，如果别人说可以，你就把它喝了，如果别人说不行，那你得就另外 找一盒新鲜的牛奶。至于 F5 刷
49、新，其 HTTP 请求消息头如下：Host 192.168.3.174:8080User-Agent Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0Accept text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language zh-cn,zh;q=0.5Accept-Encoding gzip, deflateAccept-Charset GB2312,utf-8;q=0.7,*;q=0.7Connection keep-aliveIf-Modified
