【转】关于测试方面的一些文章

• 为何要进行白盒测试

  2008-04-01 21:26:30

  软件白盒测试是一个与黑盒测试相对的概念，是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类，但依据不同的流程，对白盒测试细分的 标准 也不尽一致，比如在 IBM 的IPD流程之下，白盒测试可能划分为如下几类： 模块 单元测试、模块集成测试、模块系统测试、渐增Build集成测试、系统集成测试等。而在XP实践中，单元测试与集成测试之间的界限并不明显，统称为渐增迭代测试。

  　　一、从一个比喻开始

  　　为什么要做白盒测试？这个问题比较复杂，我们先从一个比喻开始讲起。

  　　假设有一台的面包机，从上面倒入面粉与水，开动机器后从下面出来的就是烤好了的面包，这个机器的功能比较单一，接口很清晰，输入是面粉与水，输出是面包。现在假定这个面包机多年未用，内部都生锈了，现在要清洗它，类似于我们 开发 的软件，软件有Bug，那得通过测试来清理。
  　　　　　　　　　

  　　那如何更快速的清洗这台面包机呢？有两种洗法，一是拿水从上往下灌，这是系统测试的方法。另一种是拆开来洗，拆开机 器后，拿抺布沾点清洁剂，把各零件的坑坑槽槽擦洗一遍，然后组装回来，再用水从上往下冲一遍，拆开来洗是白盒方法，组装回来用水冲是黑盒方式，相当于白盒 测试之后再追加一次系统测试。

  　　无疑，上面第二种方法是正确的，我们的前提是：清洗多年未用的面包机，铁锈够多，如果洗不干净，造出的面包都是致癌物质。当然，清洗面包机还只能算简单劳动，清理软件中的Bug要复杂得多，一个if语句有两条分支，一个while循环判断也是两条分支，还有break、continue、return等，想想看，一个1万行规模的软件能有多少个分支！一个分支就是一条坑坑槽槽，而且软件Bug还具备动态特性，不是静止的明摆在哪儿。

  　　所以，软件的白盒测试不可或缺，因为遗留Bug的影响很大，就像面包机没洗净留铁锈会致癌，还因为软件系统远比面包机复杂，不拆开来怎么能洗干净！

  　　二、白盒测试是高效测试

  　　尽管白盒测试如此重要，为什么还有许多 企业 不愿做白盒测试，有一个很重要的原因是：认为白盒测试太低效，不值得去做。

  　　实际上这种观点有许多误解成分，首先，决策者评估各阶段测试的有效性，仅以发现问题的数量为依据，这好比锈蚀斑斑的面包机，第一次冲水下去，看到大量浊水流出就很有成就感，其实这只是表象，思维方式有不足：把发现问题与解决问题割裂开来了。

  　　我们测试的目标是按既定质量标准稳定推进产品 研发 进度，只做系统测试的结果是：第一次冲水，很有成效，第二次冲水， 还能冲出点铁锈，第三次就没什么效果了。采用该手段并不能有效的达成既定质量目标。其次，研发质量改善，不只发现问题，还要定位问题、解决问题。白盒测试 是拆开来洗，发现、定位与解决问题不仅是彻底的，也是直接的，效率非常高，所以，单以发现问题数评估一个测试过程是否有效不尽准确，我们应该综合评估一个问题从被发现，到定位、解决，以及针对它完成回归测试的总效率。

  下图来源于Capers Jones与McGraw-Hill的“Applied Software Measurement”文章，从该统计数据可看出，针对一个功能点的测试，若将问题发现、定位与解决都计算进去，单元测试效率最高，是集成测试的2倍，是系统测试的3倍。
  　　　　　　　　　　

  　　认为白盒测试低效的另一个误解是，决策者并未认清一个bug若遗留到下一阶段须多付出多少代价。经验数据表明，编码阶段的一个问题遗留到验收测试去解决，所须费用将 增加 5倍，如下图，一个问题越遗留到后面阶段解决，付出代价就越高，而且是成倍递增关系。

   

  　　所以，越早测试就越能节约成本，白盒测试作为早期测试，跳过不做是得不偿失的。

  　　依据上述原因，我们评估白盒测试效率时，通常将发现问题总数乘上一个系数K，以此为据再与其它测试方段的发现问题效率做对比，来权衡白盒测试值不值得去做。系数K取值与产品形态相关，按照实际经验，系数K取值区间为1.5~2.5，产品越复杂，出现问题越不容易解决的，K值要往大调。

  　　三、白盒测试能彻底解决编码阶段引入的问题

  　　前面我们分析了白盒测试是高效的测试，值得一做，下面我们要接着说明白盒测试必须要做，不可或缺。

  先看一个案例，在某交换机产品的系统测试中，发现ISDN话机拨打某新业务号码时，在特定线路上，若一位一位的拨至18位，不会有问题，但如果先拨完号码再成组发送，会导致系统死机。这是一个导致死机的致命问题，最后定位出问题所在：呼叫处理的某段代码判断有误，本应小于18的判断，错写成小于等于18。

  　　这个问题本该在单元测试去发现，由于单元测试没做，问题就遗留到系统测试，庆幸的是没把它遗留到网上，否则问题就大 了。我们从另一个角度去反思，这个问题是特定线路下的特定终端，按特定方式拔打特定业务才暴露，在系统测试好不容易把它揪出来，但类似的其它问题呢？如何 保证在系统测试阶段都能测得出来？

  　　不同阶段的测试发现问题的特点各不相同，比如：单元测试阶段，容易发现逻辑问题、边界条件（如上例“小于18” 的错误）、变量未初始化、内存越界等问题，而集成测试容易发现接口错误、任务配合问题等，系统测试容易发现业务流程问题、界面操作问题等。如果某阶段的测 试没做，把问题遗留后面阶段，又如何能保证查错的彻底性。比如使用非法内存，出问题是否表现出来是随机的，如果操作非法内存当前被系统还认为是有效的，系统并不死机，但某些情况下，操作非法内存会死机，而另一些情况，非法内存操作将不期望变化的变量改写了，会导致其它莫名其妙的问题。类似这样的问题，在白 盒测试阶段很容易发现，也容易定位解决，但遗留系统测试阶段，就很难去发现、去定位。

  　　在V模型中，软件开发过程与测试行为具有不同层次的对应关系，如下图：
  　　　　　　　

  　　单元测试针对编码阶段引入的问题，集成测试与功能测试针对软件设计中引入的问题，验收测试针对需求与规格。单元测试不要或缺的重要原因是：编码阶段引入的问题占很高比例，不进行单元测试就难以保证系统最终的稳定性。

  我们再来看一个实际案例：有两个产品形态接近的项目，A项目正式实施单元测试与集成测试，另一个项目B项目没正式做白盒测试（简单的拿调试当测试）。最后项目结束时对研发全过程的全部问题进行缺陷分析，如下图：
  　　　　　　　

   

  　　　　　　　　　　　　A项目的缺陷类型分析
  　　　　　　　　
  　　　　　　　　　　　B项目的缺陷类型分析

  　　A项目的所有问题中，应该发现问题的阶段是白盒测试（单元测试与集成测试）的占50%，而B项目所有问题中，应在白盒测试阶段发现的仅占33%，另外，A项目发现逻辑错误占13%，而B项目只占8%。由这个统计数据表明，不做白盒测试必然导致大量问题漏测。 

  　　四、白盒测试要做到什么程度才算合适

  　　既然白盒测试不可或缺，那么，白盒测试应做到什么程度才算合适呢？具体来说，白盒测试与黑盒测试应维持什么样的比例才算合适？

  　　一般而言，白盒测试做多做少与产品形态有关，如果产品更多的具备软件平台特性，白盒测试应占总测试的80%以上，甚至接近100%，而如果产品具备复杂的业务操作，有大量GUI界面，黑盒测试的份量应该更重些。根据经验，对于大多数嵌入式产品，白盒方式展开测试（包括代码走读）应占总测试投入的一半以上，白盒测试发现的问题数也应超过总问题数的一半。

  　　由于产品的形态不一样，很难定一个标准说某产品必须做百分之多少白盒测试，但依据历史经验，我们还可以进行定量分析的。比如，收集某产品的某历史版本在开发与维护中发生的所有问题，对这些问题进行正交缺陷分析（Orthogonal Defect Classification，ODC），把“问题根源对象”属于概要设计、详细设计与编码的问题整理出来，这些都是属于白盒测试应发现的问题，统计这些问题占总问题数的比例，大致就是白盒测试应投入的比例。

  　　通过正交缺陷分析，还能推论历史版本各阶段测试的遗留缺陷率，根据“发现问题的活动”，能统计出与“问题根源对象”不相匹配的问题数，这些各阶段不匹配问题的比例就是该阶段的漏测率。

  　　参考文献：

  　　1. IPL, "Why Bother to Unit Test? "

  　　2. Wayne Chan, 《第4代白盒测试方法介绍》

  　　3. Yang Gu, from IBM, "Adopting ODC to improve software quality: A case study"

  
  

  查看(94) 评论(1) 收藏 推荐

• 理解并选择测试[转]

  2008-03-24 21:03:43

  以下为个人观点，如有不赞同者，大可以拍砖指点。
  
  
  昨天有一个网友问我是选择开发好还是测试好。
  偶是这样回答的：
  我一直不明白为什么会有人把职业来相比较。
  我想可能是这两个职业的距离太近了。
  但是，要说测试人员的开发经验。我觉得这个最不需要问的问题。肯定是有越多的开发经验
  就越好的。
  
  有人说了，我开发经验多，我还做测试干什么？
  我不明白这种说法是从哪来的？
  大概是由于一些不成熟的“开发地位或者薪水比测试高”的观点。
  
  首先，我想说明一件事情，开发和测试是不同的职业。纵然有很多的相似性，我还是认为他
  们是不同的职业。
  但是因为相似性，所以很多人同时有进入这两个职业的机会。而在这机会面前他们开始犹豫
  不断了。
  到底是哪个更好，更适合自己？在一个刚出道的人眼里看来，判断是那么的困难。
  换个角度，就算是工作几年的人来断言哪个更好？谁敢如此说呢？
  我觉得职业没有可比性，不管是什么时候。

  
  观点一：开发和测试是不同的职业。
  其次，选择是因为什么。
  工资如果是第一考虑要素，无可厚非。对持有此观点的人，我是没有任何负面评价的。因为
  我也在为生存不断的挣扎着。那看现在的开发和测试行业。
  哪个行业的工资更高？我想从大背景来看还是开发吧。
  我的朋友和我同一年出来的（05年7月毕业），做开发，成教毕业，无四六级证，无其他相
  关证件。现在找工作6K以下不考虑（另：他本人是很努力的）。敢要这个价位，并且能找到
  这样的工作，对一个工作不到两年的如此背景的人来说，我想也算是很不错的了吧（不排除
  有更好的，我只说大部分人）。
  那回头再来看测试，工作一年多，这个价位，我想也是有人能拿到的吧。我觉得这两个职业
  的薪资水平没有太多的差距。而从技术角度来说。现在很多人的测试还只是在点点点的阶段
  ，脑力劳动并不多。而大家都应该知道，脑力劳动不多的工作一般不会有太多的薪水。
  所以测试现在做的不够深入和做的人的素质有关系。基础知识等方面。在这样的素质下，我
  觉得没有什么可报怨薪水的。如果你一个人能搭建一套完整的自动化流程，看你还是不是手
  工测试时的薪水？
  所以我认为，考虑工资是对的，不过要先要求自己的能力（这个我在以前写的东西里也说过
  ，由此证明，我还没有改变观点）。
  有人说应该先做开发后做测试，对于这样的观点我不否认。但也不盲目赞同。
  我想说的就是测试和开发没有可比性。你想要什么，你喜欢什么，就去做什么。至于选择了
  之后，一些基础的技术能力。那是必备的。应该锻炼。
  对于应该锻炼的东西，是不需要问它的重要性的。它是肯定重要的。至于会不会影响职业的
  发展，我说：一定有深刻的影响。所以学就对了。
  
  而做出选择是不容易的。最难的却不是做出选择，而是选择后是不是能坚持下去。别找借口
  来说时间不够之类的傻话。这些东西对一个意志不坚强的人来说是致命的东西（如果因为情
  绪的因素，我倒是觉得可以理解）。

  
  观点二：要知道自己想选择什么，然后就是埋头苦干。
  最后，关于测试的综述。
  测试的基础知识只是一种常识性的东西，千万要记住的是：不要把常识当成技能。做测试要
  对业务有很深刻的理解。纵然做很简单的测试。看到很多人在叫着：“手工测试学不到东西
  呀”、“浪费时间呀天天点来点去的”。我不知道这样的人的工作状态是什么样的。先说一
  件小事吧：有一个朋友以前做平面的，然后想做测试，后来一直与我交流。现在在做网络设
  备方面的测试。有一天他上线跟我说，他的工作没有一点技术含量。整天就是点个按钮，看
  结果有没有错的，最多的是改几个参数。我就问了几个问题（有些问题我自己也不能完整的
  回答）：那你知道你点了按钮之后，到出来结果之前这一段时间程序在做什么？你知道为什
  么从100M改到10M再重新测试一遍，这有什么差别？等等。后来他说不知道。我说：你这样
  测试下去，三四年一点长进也不会有。就算给你其他的工作也是一样。所以尽量多想想为什
  么如此做的问题。
  说这件事情就是要表达我的一个想法，就是要知其然的做事情（我现在也是在学习之中）。
  我觉得做系统测试考虑的东西不仅仅是功能的实现与否。如果出了问题，定位如何来定位？
  就需要很多的知识了。而有些测试人员把出现的问题描述一下就扔给开发了。当然知识体系
  不同，如果要求定位也有点不太现实。但我认为测试人员至少有个大致的概念。这个问题可
  能会出现在什么位置。不过这要前面做大量的工作，具体的就不描述了。

  
  观点三：不要浮于表面的理解测试。
  希望各位同仁越做越好。

  查看(117) 评论(0) 收藏 推荐

• 致所有致力于测试的新手[转]

  2008-03-24 21:00:08

  今天并不是什么特殊的日子，只是最近郁闷，至于何来，并没有太多的出处。可能是技术上的不服，也可能是人际关系上的问题。总之，自己也是新手，亦想早日成为高人，在职场上早日立足。至于这些凌乱繁琐的关系，有必要和朋友们分享一下自己的经历和感触。
  
  为什么选择学测试？你最好搞清楚这个问题，否则会很容易迷失方向。我的朋友圈子中，有很多，才开始自己的测试生涯，却已经被其他的旁支所迷惑，比如最终投身去做开发。我尊重他们的选择，也理解他们无法在短期内整理出自己的思路，不能怪他们。但是我想说，无论你选择什么道路，都必须坚持走下去。毕竟，世界上捡芝麻丢西瓜的事情谁也说不准。 当然，反过来，可能是你的造化。当然，造成你无法确定做测试还是做开发的根本原因无异于一句话：“测试人员跟在开发人员后面，没有前途的，技术上也被开发鄙视。” 对于不了解行情的新手来说，这是一句迷惑，答案只有自己投身之后才知道。却因此而放弃走测试的路，我认为，很不值。我可以说，测试行业正在日趋规范化，前途是光明的。只要有自信和技术，你怕什么呢? --还有人说，测试不需要动脑子，简单，做不下开发了，来做测试。这的确是一条出路，不过往后你会发现，一旦你这么想了，成功也就越来越远了。很显然，缺乏激情和想象力，促使你放弃了做开发，那么什么保证你将来不放弃作测试呢？测试很简单？如果是，那么你就是被开发鄙视的测试人员，也没有什么目标可言了。结论：既然选择了，就要为了自己的目标走下去。
  
  测试需要什么技术？很多。相对于开发而言，新手做测试，对于狭义理解的技术要求相对比较低。狭义的技术是指计算机技术，编程技术，数学运算技术等一些硬技术。要求虽然低，但是不是没有要求。不过，这些硬技术绝对是不够的。扎实了这些技术，你能够获得一个饭碗，是你生存的工具。至于你能吃上什么菜，完全需要广义的技术来决定。凡事都是2/8原则的，交流和做人无异于其他行业的职场。这些技术，你自己去体会和累积，没有人能帮你。至于有些人喜欢背后议论，职场上有些表面上喜欢说好话，却不做实事的人而言，你自己的心态显然没有放端正。仅仅只知其一不知其二的臆断会令你丧失判断力和交际能力。有些人就是天生讨人喜欢，我们无法去嫉妒他们。因此，我也希望，我能和论坛上的朋友，一起努力，做一个有技术的人。免得出现电影中的台词：“一点技术含量都没有。”想想就可笑啊。。
  
  怎样建立良性循环的交流圈？ 这里，我有时候忍不住想说，我们的论坛还不够活跃。难道这不是一个很好的平台么？说废话也没用，希望大家多多发帖讨论吧。技术上的争论，没有什么可以保留的。虽然，我也知道，身为版主，有时候说话很激进，但是，我同样也希望各位能共同促进技术上的交流和发展。Improve together. 测试，是团队项目，相信大家都明白。说这些，仅仅因为发现，新手园地每日的报道新兵很多，发话和提问的很少。我会把责任归在自己办事不利的身上，希望我的公告能起到积极效果。
  
  最后，说点实际的内容。想学东西，每个人都有过的念头。至于新手如何才能更快更有效率的学习，我有几点方法和大家共享一下：
  
  1.不要试图自己是牛人，一下子什么都要学，给自己个宽恕和计划，半年能精通一门技术，已经很值得羡慕和崇拜了。
  
  2.不要去买很多书，尤其是中文书，太误导人了。 英语好的，多看看原版，思路清晰易解。英语不好的，去借鉴朋友的经验，比看书学的快得多。所以，交流比什么都重要。
  
  3.学测试，入门的，从纯黑盒的理论和测试用例的编写学起。
  
  4.做测试，数据库非常重要，至少要强迫自己能非常熟练一门数据库平台。
  
  5.所谓学技术，拿台电脑，摸几下鼠标，点几下键盘，自己操作，别光看别人演示，看会了，立即就会忘的。
  
  6.学编程，新手自己动脑子，别总是想着改代码，改不出高手的。想看资料的，请在WINDOWS环境下按F1，看懂了，自然成高手了。
  
  不多说了，大家一起努力。
  

  查看(153) 评论(0) 收藏 推荐

• 如何从测试员转型为测试管理人员[转]

  2008-03-24 20:56:42

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

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

  2. 要熟悉BUG跟踪工具及软件测试流程.(如: TD, Bugzilla, CQ等)

  3. 要熟悉配置管理工具. (如: CVS, VSS等)

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

  码)

  5. 要熟悉压力及性能测试工具.(例如: LoadRunner, webload, silkperformance等,能结合相关数据,分

  析出性能瓶颈)

  6. 要熟悉或精通一门语言. (例如: Java, C++)

  7. 要熟悉数据库.(例如: Oracle, DB2, SQLServer, MySQL)

  8. 要熟悉主流操作系统. (例如: HP Unix, IBM AIX, Sun Solaris, Red Hat Linux, SuSE Linux,

  Windows)

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

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

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

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

  13. 乐于与人交流.

  查看(182) 评论(0) 收藏 推荐

• 软件测试的人际关系[转]

  2008-03-24 19:23:15

  软件测试是一项技术工作，测试者不是市场公关人员，之所以单独讨论软件测试的人际关系，是因为软件测试不是孤立的实施过程， 软件 测试的每个过程都要与软件开发人员（程序员）和软件测试人员相联系。另外，如果软件实行外包测试，则软件测试外包的人员还要与软 件开发商的技术人员紧密联系。软件测试中处理好与不同人员的工作关系，建立彼此的信赖，可以提高测试的效率，减少测试失败的风险 。因此，软件测试的人际关系不仅要讲，而且要找出行使有效的方式。
  
  1. 测试人员与开发人员的人际关系

  
  　　与软件开发具有天然的联系。软件测试的输入是软件开发的产品，测试输出的结果需要开发人员相应处理，处理后的结果再次需要测 试人 员的验证。因此，软件测试与软件开发如影相随，互为服务对象。

  
  　　软件测试人员和软件开发人员要多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加 强和 开发人员的沟通，让他清楚地认识到测试工作对开发工作的价值，发现的每一个Bug的重要性。

  
  　　软件测试人员对于软件缺陷的报告要就事论事，只报告软件缺陷的客观事实，不对软件代码本身的质量优劣进行评判，不搞人身攻击 。软 件开发人员要理解软件测试的工作职责就是寻找软件缺陷，而不是故意和自己的代码“过不去”，也不要认为软件测试是动动鼠标，敲敲 键盘的低水平工作，软件测试也是一门技术和艺术。测试和开发只是软件工作的分工不同，都是软件项目团队不可分割的成员，而且软件 测试人员发现的Bug，可以帮助开发人员尽早修正，避免软件发布后造成更大损失。

  
  2. 测试人员与质量保证人员的人际关系

  
  　　不同的软件公司对质量保证（QA）人员的职责和功能存在不同的理解。有些公司QA人员等同于测试人员，负责具体的软件测试工 作。 也有的公司QA人员只负责软件项目的过程检测和跟踪，不参与具体的测试工作。

  
  　　这里所说的QA人员是指对软件测试的质量和过程进行评估的人员。QA人员通过抽查测试用例的执行结果，或根据测试发现的软件 缺陷 数据信息对软件测试的质量和过程进行评估。QA人员一般需要熟练掌握软件测试的技能，熟悉软件产品。

  
  　　软件测试人员与QA人员都是软件质量控制团队的成员，只是二者的职责不同，但是际蔷哂邢嗤 墓ぷ髂勘辏 匆磺行形 际俏 ? 提高 和保证软件质量。软件测试人员可以从QA人员的测试评估报告，发现测试存在的不足和取得的成果，因此，需要理解和尊重QA人员， 加强交流，相互信任和支持。QA人员要注意对软件测试的效果进行评估时，一切以客观数字为基础，对事不对人，关键是发现影响软件 测试质量的问题，并且提出可行的改进建议。

  
  3. 外包测试服务商与软件开发商的关系

  
  　　软件测试外包成为新的软件测试形式，由于软件测试活动的复杂性和长期性，软件开发商与提供软件测试服务的服务商之间的交流变 得非 常重要，处理好测试外包服务商和开发商之间的关系将对软件测试具有决定性的影响。

  
  　　软件外包测试是一种软件技术服务，外包测试服务商的价值在于通过提供专业的测试服务为客户创造附加价值。软件开发商通过测试 外包 ，集中人力和物力从事软件核心技术的开发，增强产品的竞争力。因此，外包测试服务商与软件开发商之间是业务合作关系。

  
  　　信任关系成为外包测试服务商和软件开发商最重要的内容。测试外包服务商要赢得软件开发商的信任，需要提供优质、高效、及时地 软件 测试服务，需要理解、达到甚至超过客户的期望，树立一切为客户服务的思想和意识，并且贯彻于整个软件外包测试的全过程。

  
  　　软件开发商要选择符合项目需求的外包测试服务商，为他们提供充分的项目信息和必要的技术支持，因为只有软件开发商真正熟悉要 测试 的软件。通过对外包测试服务商测试项目的执行过程和结果

  查看(132) 评论(0) 收藏 推荐

• 浮躁的国内测试界[转载][看后暴汗~~]

  2008-03-24 19:03:59

  我面试的测试应聘人员大多是有一定从业经验的测试人员，其中不乏优秀者，但是也有相当多的应聘人员反映出这样那样的问题，概括说来就是“浮躁”，具体拆解来看主要表现在以下几点。

  一、根基不牢

  问题：利用等价类划分的方法，对某问题设计测试用例。

  分析：98%以上的应聘者只知道按照有效等价类和无效等价类进行划分，殊不知此种分类方法只是等价类划分的一个典型应用而已，等价类划分远非只能划分为有效和无效两类。根据种种划分依据，还可以进一步划分很多其他类别。

  问题：根据事件描述，画出对应的因果图。

  分析：标准答案中只画了“两条恒等，两条非，一个与，一个或”。如此简单的问题，上百名应聘者中竟然无一人答对，痛心啊。黑盒测试方法就那么几种，既然你已知这个名，怎么就不知道多看几眼。

  ★ 小结：

  上面提到的是软件测试的最基本的方法，作为从业测试实际工作已经有1-2年的应聘人员，未能真正领悟，实属不应该，心浮气躁，忽视了你身边最简单，也是最厉害的技能。根基不牢，怎么可能把测试做深。

  二、专业不精

  问题：音视频文件都有哪些格式，这些格式之间有什么差别？

  分析：此问题是问那些做过多媒体方面测试的，但是我们的应聘者向来都是拿来主义，别人给我什么媒体文件我就用什么做测试，而根本不管不问。“为什么MIDI文件比WAV文件小那么多？我们如何知道扩展名是.Mpeg的文件是Mpeg1格式的还是Mpeg2格式

  
  

  的？”，面对这些问题，应聘者默默无语，只是无奈的笑笑。不去看别人，想想自己测试涉及的专业，是否把那个行业知识搞清楚了呢？

  问题：测试脚本运行不畅如何调试？

  分析：此问题是问那些标明自己熟练掌握WinRunner、Robot、QTP等测试工具的应聘人员，但是当真正问到他们关于脚本的具体调试时，有7成以上人员表示他们只是参加测试培训 时 老师讲过，或者自己在网上看过相关资料，另外有2成以上人员表示他们虽然用过，但是只是简单的录制回放，根本不会自己调试。可能是迫于无奈吧，简历里面什么都不写，可能面试的机会都没有，但是简历如此夸大的来写，终归是浪费自己的面试时间和路费。

  ★ 小结：

  从事测试仅1-2年时间，要想测试也精通，专业也精通确实不易，但是不说精通，至少也该知道个60%才对的起你的测试工作。一两年时光如此荒废，静下心来反思一下，身边还有哪些技能我们应该掌握扎实一点呢。

  三、无测试体系概念，忽视理论

  问题：请说出软件测试的定义，BUG的定义。

  分析：99%的人不能说出这两个测试名词的定义，只是在给我解释测试是为了发现bug之类的片面理解，残留的几个人也说得不够准确。这两个词目前尚不能说业内已经有了成熟统一的定义，但是无论是对是错，身为测试人员已经数年，自己竟然说不出这两个词的概念，多少也说不过去啊。有些人和我说，理论名词概念不重要，我会做测试就是了。想想 金庸老 先生早就告诉我们，武功仅有招式是不够的，必须配合上什么心法口诀才能行。你只会测试执行的招式，却不懂测试理论的心法，怎么能够修炼成上乘的软件测试呢？

  问题：请介绍一下你们的测试流程，流程和过程有什么不同，为什么好的测试需要好的流程？

  分析：但凡做过1、2年测试的人都能给我说出他们先做什么后做什么，但是当我继续问“这是否可以叫做过程？流程和过程有什么差别”，应聘者一棒子被打晕，继续追问“为什么好的测试需要好的流程”的时候，早已经找不到东南西北了。每天公司各项制度叫你做什么你就做什么，让你怎么做你就怎么做，完全不管不顾为什么，那么自己岂不成了没头脑的工具。这样你能干的工作别人也能做，自己的优势不就没有了吗。

  
  

  ★ 小结：

  目前测试业内流传着学院派和实践派的说法，学院派的理论给人的感觉往往是好听但不实用，而实践派的知识，往往能够立即见效。所以眼下测试培训往往实践派的更受欢迎。继续引用 金庸 先生的观点，练武分练内气宗，练外剑宗，但是真正的高手是内外兼修。如果我们不想只做普通的测试小弟子的话，就要理论实践并重，方能有所作为。

  四、周边知识知之甚少

  问题：能给我介绍一下软件工程中的瀑布模型吗？

  分析：又是8成应聘者不会回答，都是曾在遥远的学生时代有所耳闻，现今早已忘得一干二净了。软件测试因何而生——软件危机，软件危机导致软件工程的兴起，软件工程中又包含软件测试，就好像鱼儿活在水里，如果没有软件工程这个水，哪里能够养活这软件测试的鱼，如果我们对于身边的软件工程不够了解，怎么可能在里面自由的畅游呢。

  问题：用你最熟悉的开发语言实现sum=1+2+3+…+100

  分析：保守统计7成以上的应聘者写出来的程序无法执行或者运行结果错误，更少有人能够一气呵成，而且精准。这道编程题难吗？肯定不难，那么为何答错，自己没有真正写过程序，即使写过几行，也早就是如烟往事了。做测试一定需要懂开发吗？这个问题讨论以久，当然不一定，但是如果要做好测试，做深测试，分析问题原因，提出问题解决方案，编写测试脚本或工具，哪一个又能离开软件开发呢？

  ★ 小结：

  我们学习测试也应该有个先后顺序，有步骤。掌握周边知识的紧迫程度可能不如测试知识和行业知识。但是对于我们已经从业1-2年的测试人员来说，学校里面学到的知识不应该丢，之后的发展中，周边知识的学习也应该开始了。周边知识的范畴其实很广，还包括各种其他测试理念的学习，机械工业出版社翻译的那套测试丛书就很不错，观点众多而新颖，博众家之长，集大成，向来都是大家风范。

  五、缺乏必要的责任心、细心、耐心、虚心等

  问题：请数出下图中三角形的个数（平面图，有几根弧线做干扰）

  分析：我总是问自己，这道题真有这么难吗？连中小学生都能数对的十几个三角形，到了我们这二十几岁的年轻人手中，正确率才1%，为什么？其实就是现在我们已经很少有人能够静下心来，耐心细致的去做事情了。很多应聘者告诉我她的优点就是“踏实，坐的住，正适合这繁琐的测试工作”。我需要的不是坐在那里不做事或者做错事的人，而是需要能够按时保质量完成测试工作的测试人员。

  问题：你离职的原因？

  分析：这是面试中最常见的问题了。应聘者往往也是充分准备，理由多种多样，但是看看应聘者的工作记录统计，70%应聘者平均跳槽频率是1年/次（实习情况除外），不会都那么凑巧吧，赶上什么公司倒闭，每隔一年就会想一次自己学不到东西，需要去外面看看。而在我看来，真正的原因更多的应该是希望通过跳槽提高工资，或者因为自身水平不足被公司炒鱿鱼吧。

  ★ 小结：

  我并不认为所有的人都适合做测试。非技术素质方面，这点或者那点不足够优秀也很正常，心浮气躁也可以理解。但是作为用人单位，理解归理解，却也不会用不胜任岗位，或性价比不高的人员。那么对于此类应聘者，我的忠告就是，要么你另谋高就，要么你就放低姿态，培养好你必备的素质后再谈。

  六、缺乏诚信

  这一点本应该被归在上一条素质中，但是这点的重要性我认为远超过了上一条所列各项，因此单独提出。相关表现主要体现在：

  ○ 报自己历史工薪；

  ○ 笔试题目作弊；

  ○ 编造离职原因；

  ○ 虚报学历，工作经验；

  ○ 夸大自己工作技能等。对于严重缺乏诚信的，一旦发现，其他表现再好，也无济于事了。

  查看(318) 评论(6) 收藏 推荐

• 微软企业方法——以测试为核心[转载][似乎很多公司也是这么做的]

  2008-03-18 21:02:14

  Bug“指挥棒”
          一个优秀软件产品的成功，除了其先进的技术含量之外，产品开发过程的有序和有效科学的管理也是另一个不可或缺的重要因素。微软的产品开发基本上遵循一个完整的开发周期，其间包括规划阶段、开发阶段、测试阶段（也叫稳定化阶段）和产品发送/出品四个阶段。

          在软件开发过程中，开发人员的作用不言而喻，其实，真正保证软件项目高质量地如期完成的不仅有开发人员，而且还有测试人员。在一切都不确定的软件开发过程中，测试人员的“Bug指挥棒”来让大家什么时候知道该表现，什么时候知道该退后一点，正是微软将软件开发过程带向高潮的不二法则！

  测试组与开发组并驾齐驱
          对于一个具体的软件产品的开发过程来说，测试与软件成本的关系是，发现产品中存在的问题越早，开发费用越低，产品质量越高，软件发布后维护费用越低。 
          具体来说，测试的具体任务包括五个方面：首先，试图在产品开发过程中找出所有的BUG；其次，系统、深入、广泛的测试以保证质量；第三，既测代码，也测设计；第四，关心产品的规格、进度、资源以及产品开发后期的任何变化；最后，负责最终的发布认可。

          在开发过程中，开发人员很可能会偶尔偏离了事实的需要，暂时忘记了什么才是产品最该有的功能，把他们拉回原定轨道的正是测试工程师。测试人员的职责是配合整个项目组，保证按照预定的时间表完成预定设计目标；独立地完成测试任务；定期给出测试报告，包括BUG趋势、测试的覆盖面等等。测试人员的工作是一项具有整体性、持续性的软件开发活动中的一环，它是产品质量的重要保证。

  软件测试的阶段性
          在微软产品开发的规划阶段，测试人员应当研究规格说明，编写测试计划；在开发阶段，测试人员则开始设计测试用例，开发自动测试工具和程序，熟悉必需的环境、工具、软件和硬件，不断地丰富测试用例，直到达到CC（代码完成）里程碑。此时的软件可以进行一个整体测试，用户界面虽不完美但能工作，还可能有很多明显的BUG。

          进入开发周期的第三阶段，测试人员大显身手，展开大规模的测试，如系统级整体测试，交互性和深层测试，这个事后的测试人员应当对新增的功能说“不”，直到达到Bata测试里程碑，达到这个里程碑，意味者所有的Beta致命问题已经被修正和关闭，所有计划的功能都已经在软件中并能工作，产品稳定，可以供用户试用，大部分界面还可以，尽管可能只是一部分，但已经有了在线帮助，可能还有用户手册，即使是发布了也不会引起负面的影响。

  秘密武器：测试用例和测试计划
          总之，微软测试的精髓是：基于产品规划、产品设计规格的测试计划；系统可重用的测试用例；以问题（BUG）发现和跟踪为核心的测试活动；独立的测试人员；与整个项目配合的基于里程碑的软件测试周期。而基于产品规划、产品设计规格的测试计划和系统可重用的测试用例则是微软的“秘密武器”。

          在微软，测试计划是帮助测试人员管理测试项目和发现BUG的重要工具，是纲领性文件。测试计划明确了项目的测试任务、测试内容清单，这些内容不能只存在于测试人员的脑海里，而必须被项目经理、开发经理所了解，测试计划必须增强测试任务和测试实施过程的沟通，具有指导性。测试计划还必须提供组织管理测试项目的框架结构，帮助控制进度。测试计划涉及的范围应当有产品概述、测试策略、测试的方法学、测试区域、测试的配置（软件环境、硬件环境、网络环境）、测试周期（与项目的里程碑配合）、测试资源的规划、风险分析和案例等。

          测试人员设计测试用例时应当遵循以下原则：在人员变化和新项目中能够重用；能够分类； 测试的内容不重复；保存在测试用例的数据库中；在项目进行过程中可不断增强。

          设计测试用例时的一些通常考虑“点”是：根据产品规格测试基本功能；设计普通用户的使用方案；设计稀有或特殊的使用方案；与系统其他组成部分的配合（如FAX和上网可能都要用到调制解调器，测试中要考虑对设备的共享）；考虑特殊情况（比如内存和硬件的冲突等）；设计极端情况（比如内存泄漏、破坏性测试等）。

  BUG的发现和管理
          微软把软件中常见的BUG分为以下几种类型：功能错误；用户界面错误；边界值相关错误；初始化错误；计算错误；内存相关错误；硬件相关错误和文档错误。

          测试工程师发现BUG之后，首先应验证是不是自己的偶然失误造成BUG出现，如不是则立即建立每一个新的BUG记录；尽可能地分析产生BUG的原因；设计合适的优先级和严重级别。测试人员的目标不是找出更多的BUG，而是改进产品的质量；依据BUG的优先级和严重级别分派给某一个相应的人；BUG记录要清楚、明白。

          一般来说，BUG在数据库中有三种状态：活跃（Active）、被解（Resolved）、关闭（Closed）。活跃状态指的是测试人员新建一个BUG时的状态，必须分派给相应的设计人员、开发人员或者是用户教育人员，表明BUG的状态是等待纠正的。被解状态指的是设计人员、开发人员或者用户教育人员修正BUG后的状态，必须重新分派给报告BUG的测试人员，表明BUG已经得到修正，但等待较验。关闭状态指的是测试人员较验完成并关掉之后的状态，表明BUG已经得到修正，并完成了较验，如果再次出现同样的问题，还可以重新激活成活跃状态，此时又开始了另一轮的状态循环。活跃BUG数量的趋势，一般在代码完成前很少，代码完成后增长很快，接近Beta测试时会下降，接近RC时奔向零。因此由此亦可判断产品质量和里程碑的信号——每天新建的BUG数量与修正的BUG数量相比较；活跃状态的BUG数量。

          永远有缺憾是所有智力活动的特征。软件一定有数不清的缺点，问题不在在于判断这个产品好与不好，而是决定修改哪一部分使产品比较能被用户接受或喜爱。微软有“BUG法庭”，审查每一个BUG，选择和修改产品中最重要的错误，决定相应解决方案，尽量使大部分的用户在大部分的时间内都能够使用愉快。

  微软研发的交响乐章
          软件研发需要先进的技术和科学的管理。纵观微软对软件开发周期过程的管理，其精髓的做法一是是将大项目划分成若干个子项目的里程碑式的开发模式；其次，通过对产品组各人员角色对职责的承诺来控制产品的开发过程，保证产品的进度和质量。经过多年的积累，团队合作一直是微软软件开发的基础。

          在微软，既鼓励创造性，又最大限度地实现科学管理；同时，每个员工都能互相分享自己的经验和教训，彼此合作。 而这，正是微软的文化（最大的成功）。

  查看(74) 评论(0) 收藏 推荐

• 我对软件测试的看法[转载][我觉得很经典]

  2008-03-18 18:23:55

  做了多年的 测试 工作 ，也 面试 了一些公司。经常有些人上来就是问，你会用什么 测试工具 。从这个角度看，似乎测试工具比起扎实的测试知识、手工测试经验等更为重要。实际上我不这么认为，这里说说我对于测试的看法。我不赞同下面三种说法：

  1.测试人员不需要懂得如何写文档
  2.测试工具比手工测试重要

  3.测试人员不需要懂业务

          软件测试在整个软件开发过程中占有很重要的地位这点毋庸置疑。但是测试并不单纯是测试代码，而应包括在开发过程中生成的文档。既然要测试开发过程中生成的文档，那么测试人员自己写的文档是否也要经得起推敲呢。但是看看有的测试人员提交的测试计划、测试报告等文档，说不上专业外，连起码的美观和规范都称不上。这样的测试人员怎么去测试开发人员提交的文档呢。

          目前，很多人追求使用测试工具进行自动化测试等。诚然，使用测试工具进行自动化测试，可以提高测试人员工作效率，增大测试覆盖率。但是我个人认为，如果一味追求测试工具，那么，则会将测试引入歧途。测试仍不能忘本，手工测试仍是根本，很多手工测试的技巧仍是要求掌握的。如果测试人员没有具备手工测试技巧与经验，他怎么可以设计出好的自动化测试用例和脚本呢。从另一方面讲，如果系统没有经过完备的手工测试，而立即引入测试工具进行自动化测试，这些测试脚本的维护将需要占用测试人员大量的工作量，这是引入测试工具进行自动化测试时需要考虑到的，因为不是所有的项目都适合引入自动化测试。

          最后，要做好一个专业的测试人员，自已应有能力和业务专长。除测试理论知识及技能外，应了解一到两门开发语言，这里提到的是了解，而不是精通。了解开发语言，至少能看懂代码的意思，能和开发人员就碰到的问题有共同沟通方式，免得开发人员说一个专业术语时，你愣是听不懂，那就很糟糕了。另外，测试人员需要有自己的擅长的业务领域知识，这对于业务测试是很重要的，并且让你能从系统表面发现更深层的业务问题。发现别人不能发现的缺陷，是测试人员价值的体现。在我呆过的测试团队中，我们对于不同的测试人员就有不同的业务领域分工，同时经常安排测试人员参与公司业务方面的培训。

  查看(226) 评论(0) 收藏 推荐

• 测试行业的发展趋势[转载]

  2008-03-13 19:17:03

  软件测试工程师已经成为2006年最紧缺的人才，该类职位的需求主要集中在沿海发达城市，其中北京和上海的需求量分别占去了33%和29%；而从企业分布来看，民企需求量最大，占了19%，外商独资欧美类企业需求排列第二，占15%。中国青年报2005年12月22日报道： 　　据了解，目前我国软件从业人员的缺口高达40万之多，其中软件测试人才的缺口将超过20万，在未来5-10年中这一数字还将继续增大。目前，在软件企业中，软件测试人员的薪水主要看其工作经验及能力，有两年工作经验的软件测试人员的月薪一般都能达到5000--7000元。中国软件行业协会游戏软件分会副会长刘金华在接受记者采访时说，在企业内部，软件测试工程师基本处于“双高”地位，即地位高、待遇高，有的人月薪可高达上万元。可以说他们的职业前景非常广阔，从近期的企业人才需求和薪金水平来看，软件测试工程师的年工资有逐年上升的明显迹象 　  根据以上分析，我们无庸置疑软件测试行业的职业发展前景。从当今大学计算机专业的知识结构来看，软件测试只占其中很少的章节，是作为计算机专业主要技能辅助知识设立的。系统化的软件测试专业只是在近两年才被分离出的，而且只在屈指可数的几个院校设立，一方面是需求骤增，一方面是供应有限，由此造成了软件测试人才极度“抢手”的局面。         在一个人博客上读过这样一篇文章： 1、测试有前途么？    通常问问题的，有这么几个类型的人： 一、测试新人     一般是想从事测试行业的新人，对测试行业不了解，想了解测试的发展前景。更准确的应该说他们想问的问题是“如果他本人去做测试，他本人是否会有前途？”，如果测试有前途，就想着怎么进入这个行业，在这个行业发展。往往忽略了这个行业是否适合自己，自己能否会慢慢喜欢这个职业。对于这类人，本人觉的还是多看一些测试的工作内容是什么？测试包含那些技术？测试的职业规划是什么？软件开发模式是那些？这些资料，对这个职业，对自己的知识结构理解清楚后，自己就可以回答自己提出的这类问题了。 二、做测试不到半年的人     做测试刚做几个月的新人，常常也会问这类问题。刚开始做测试都是从最基础做起，要有耐心的对付软件的回归测试和BUG的跟踪。看似简单的问题，但要认真做好不简单。有的人做不到3个月，就会开始浮躁起来，想像着做着这种重复的工作能有什么前途。并没有去体会在一遍又一遍的测试过程中，软件在改进的那种喜悦和艰辛。 三、做测试工作不足2年的人     做测试做一段时间后,个人在测试这个职业已经厌倦了,对这个职业没有更多的工作激情和热情,没有了测试工作的动力,因此会发起这个问题,想了解同行是怎么看的.想寻找着自己的奋斗目标.对于这类人,本人觉的是由于在选择测试这个职业时,没有好好的了解这个职业和根据自己的情况制定合理的个人发展规划造成的. 我对这个问题的看法： 1、我很喜欢测试这个职业，我把它当做我的一个事业来做，因此对我来说，我认为它很有前途。因此对于这类话题，在论坛上我都不想参与过多的讨论，但是很关心国内测试行业的发展状况。 2、关于“测试有钱途么？”这类话题，我通常不参与讨论，对于个人来说没有什么意义，浪费时间。因为这个职业是否有钱途，最终是取决于个人本身。     曾经在testage论坛上有个名字叫luckyboy2008的同行提出个疑问“测试行业的延伸？”，对这个问题真是不清楚，只能说，就目前国内测试行业，非常的火，不管是外包还是软件公司，招聘测试人员的公司比往年都多，我个人分析原因可能是：            1）研发人员能力和水平低了，导致开发出来的软件需要测试人员去测试，才能把握软件的质量。追究这种现象的根源就是公司降低了研发成本，不肯花钱去聘请优秀的研发人员。           2）公司开始重视产品质量，把产品质量做为商业目的一种手段。          3）公司的产品质量实在是太差了，受不了客户的投诉。          4）公司想过认证，如：CMM、ISO等等。          5）软件项目质量有问题，需要测试人员去测试，把握产品质量。     测试行业太快的火起来是好事也是坏事，越火水分就越大。国内对测试行业状况评论的新闻可信度让人怀疑，缺少太多的真实数据。

  查看(108) 评论(0) 收藏 推荐

• 与开发人员沟通的五要与四不要

  2008-03-13 19:13:03

   

   

  作为测试工程师，在日常工作中接触最多的当然是团队中的开发工程师，如何和开发工程师进行有效的交流是测试工程师面对的 重要问题。一般来说，在一个团队中，总是有开发人员喜欢和不喜欢的测试工程师，这两者之间的工作效率和效果都有很大的差异。当然，不能武断地说测试人员不 喜欢的测试工程师就一定是效率低下的测试工程师，或者说是不合格的测试工程师，但一般来说，那些容易得到开发人员认可的工程师在测试时总能够更好地发现缺陷和敦促开发人员解决缺陷。 测试工程师和开发工程师承担的是开发工作的两个不同方面，说得极端一点，一个是创建，一个是破坏，虽然两者的 最终目的都是一样的，但在达成目标的方式上却有很大的差异。因此，在为同一个目标奋斗的过程中，发生冲突也是难免的，但通过下面的一些建议，换个视角看看开发人员的生活和工作，可能很多的冲突就能化解于无形了。 Cem Kaner在《Testing Computer Software》书中有一段话: “The best tester is not the one who finds the most bugs or who embarrasses the most developers. The best tester is the one who gets the most bugs fixed.” （最好的测试人员不是发现最多BUG或是使得最多开发人员不自在的人，而是能够[说服开发人员]修正最多BUG的人），建议大家好好理解这句话。 至于我个人，是从开发工程师转为测试工程师的，对于开发工程师的处境和想法也曾有过切身的体会，或许是这个原因，让我在和开发工程师交流的过程中还算是比较 顺利，和他们相处得也还不错。在我的测试经历中，也接触过相当多的开发工程师，这里我把和开发人员交流的经验归结为“五要四不要”： 1、要耐心和细心 细心是测试工程师的一个基本素质，测试工程师是对质量负责的人，涉及到质量问题，就不能含糊，因此一定要细心，细心对待每一个可能的BUG、细心对待每一段 被你检查的代码，细心对待每一个你撰写的BUG报告，细心对待你发出的每一封邮件。细心是一种态度，你的态度迟早会感染和你合作的开发人员，而这往往是合作愉快的基础。 至于说到耐心，在我的工作经历中，不厌其烦地向开发人员解释一个BUG，让他认识到BUG的重要性是经常的事情，其实想想也很正常，对任何人来说，被人指出自己的缺点和不足都不是让人舒服的事情，因此，一点不耐烦的情绪就可能引起对方很大的反感，给自己的工作带来不必要的麻烦。 2、要懂得尊重对方 开发是一件需要全面和综合考虑的工作，开发工作中，由于各种原因导致程序中出现问题是很正常的现象，作为测试工程师，发现了这些问题并 不值得 你夸耀，也不能 说明你比开发工程师聪明。一个好的测试工程师一定是懂得尊重开发工程师的人，尊重对方的技术水平，尊重对方的代码。我接触过的开发人员都是挺和善的，一般来说，对他们最大的尊重就是承认他的专业水平，承认他的代码。对他们来说，代码就像是自己的孩子一样：）因此，记得在合适的时候表达你对他的尊重，赞扬一下他代码的精妙之处。 3、要能设身处地为对方着想 开发工程师一般都处在较大的工作压力下，他的上司直接考核他们的指标很大程度上是已完成的代码，所以在工作任务紧张的时候，对于测试工程师报上来的BUG会 拖延解决甚至是推脱，给测试工程师的感觉就是很不合作。那么在这个时候，就需要设身处地的为对方着想了，每个人都会为自己的工作在内心排定优先级，如果他 认为解决你发现的BUG不是重要的事情，那么最大的可能就是你并没有向他解释清楚这个BUG的严重程度。 发现BUG是我们的责任，敦促BUG得到解决是我们更重要的责任，因此，我们可以心平气和地和开发人员坐下来讨论一下BUG的严重程度，和他一起排定BUG的优先级别并确定解决的时间。 4、要有原则 不要忘记，测试工程师需要对产品的质量负责，在这一点上一定要有原则。测试工程师可以和开发工程师建立良好的个人关系，但在具体的事情上，一定要按照公司的 相关流程来处理。当然，在坚持原则的同时，可以采用一些委婉的表达方式，可以在允许的情况下尽量体谅开发工程师，但请记住，一个有原则的测试工程师才能真 正帮助开发工程师，才能赢得开发工程师的尊重。 5、要主动承担 如果开发工程师要求你承担部分不属于你的责任，比如，定位你发现的BUG到代码一级，或者是帮助他编写部分文档和代码（不要不相信，真的有这样的事情），那 么你会怎么做呢？在我的测试经历中，这些事情都遇到过，我的原则是在可能的情况下尽量多承担。其实都是工作上的事情，有能力的话，多做一点也无妨。当然， 肯定有人不同意我的意见，在这里我也不想争辩，个人意见而已，仅供参考：） 在我的测试经历中，我会根据自己的进度和时间安排尽可能地提供更多的关于BUG的参考意见，甚至是定位到代码一级，这种方式不是正规的方式，但对于提高自己被信任的程度是非常有益的。但在主动承担时，一定要明确是在自己确有余力的情况下才能去承担，否则，婉拒是最好的对策。 【四不要】 1、不要嘲笑 不要嘲笑你所发现的BUG，即使是非常愚蠢的错误也绝对不要嘲笑，说不定那个错误是因为开发工程师联系加班24小时犯下的，对别人的工作始终应该尊重。如果 你觉得有必要提醒他不再犯一些经常犯的错误，可以采用这样的方式：编写一份测试过程中发现的开发人员常犯错误的文档（记住，千万不要写上谁犯了这些错 误），用轻松的口气调侃一下，发送给开发人员。这种方法我采用过，开发人员都能很快接受。 2、不要在背后评论开发工程师 永远不要在背后评论开发工程师的技术能力，这个绝对是非常忌讳的事情，一时的口舌之快或许会使你永远不再能同他良好地合作，要知道，开发工程师最在意地就是别人对他的技术能力的评价。其实这个不仅仅是作为测试工程师的准则，也应该是做人的准则。 3、不要动辄用上层来压制对方 在出现和对方的意见分歧的时候，应该采用什么方式说服对方呢？直接向上层求助当然是一个办法，但这种办法带来的负面左右也是很明显的，首先是作为上层的处理 结果可能不一定符合你的愿望（在很多公司，开发工程师的地位高于测试工程师的地位，这种地位的不平等导致上层在处理分歧时会有一定的偏向性）；其次是动辄 拿出上层来压制对方只能给他人留下无用的印象。所以在出现分歧时，尽量尝试通过沟通解决吧，实在不行，再动用最后的手段。 4、和开发人员的沟通不要只有BUG 除了在BUG记录单上，在其他的地方也让和你合作的开发工程师接触到你吧：），午餐或是集体活动的时候多和对方聊聊天，一方面可以增进彼此的感情，混个脸 熟，打交道的时候也方便；另一方面，从他那里了解业务的知识和他负责模块的方方面面，对自己也是提升。我个人就很喜欢和开发工程师沟通，开发工程师其实一 般都是比较健谈的，尤其是对自己程序的精妙之处，多了解一些，多接触一些，对自己总是有益的。 写了这么多，其实关键的就是两点：多从别人的角度去想想，所谓“换位思考”，多尊重对方就一定能得到对方的尊重与配合；其次是加强和开发工程师的沟通，让他清楚地认识到你的工作对他的价值，你发现的每一个BUG的重要性。 我一直认为，一个好的测试工程师一定是在公司里被所有人尊重的快乐分子，而不应该是一个“铁面判官”：）当然，作为我个人来说，绝对不敢说自己做的已经很好了，不过，我经常都记得提醒自己：尊重对方。 来自：CSDN    2007.08.14

  查看(100) 评论(0) 收藏 推荐

• 成功的测试工程师就得会想[转载]

  2008-03-13 00:12:08

  成功的测试工程师就得会想

   

  最近在做一个机票的电子购票时,突然想到了这么个问题------在测试的过程中对某个功能想得越开,测试就完整,就越彻底!

          当然我们在产生与该功能相关的想象时,其中最关键的是不能脱离需求,不能脱离该软件本身;不然这样的测试就适得其反了.

          我们在测试某个功能时,1:想到在该软件中与该功能相关的功能;2:想到在该软件中与该功能相似的功能;3:站在客户或者用户的角度想,自己会用的很舒服吗?习惯大多数人的使用吗?如果在该功能上添加某个细节会让客户或者用户使用的更顺手.可以给项目经理和做需求的讨论,以便确定(切记:不要私自做主);4:与自己曾做过软件中有该功能或者网上类似的功能做对比,看怎样更适合使用(前提是不脱离需求);5:产生下联想下,如果该项目有2期或者后续的话,还应该考虑该功能的可延伸性,以便为后来做准备(我以前做过一个项目外网和内网都是同一组开发人员做的,但是统一个功能却不能相互导数据~~气愤呀)

          想是不犯法的,只要不乱想! 所以一名好的测试工程师,他/她的思维一定是很活跃的很会联系其他东西的.

  作为一名合格、高级的测试工程师至少应该拥有如下几点。
  在测试的时候应该从：
  1、用户的角度，也就是上面文章中提到的；不过更应该从用户体验性、操作方便性、业务逻辑性来考虑一个功能或业务的合理性程度；
  2、从测试的角度，测试人员应该有丰富的测试知识应该考虑程度的安全性，如输入特殊的字符串验证一个输入框；或通过特殊手段传输一些特殊的参数观察程度是否会异常；当然验证功能或业务是否达到项目的需求这是必然的。
  3、从开发的角度，需要懂代码的简单编写或能够读懂代码；考虑代码的逻辑、代码中注释信息是否齐全。如新创建一个类或方法后是否增加了注释说明，以便后面的开发人员维护代码。
  4、从第三者的角度来看这个项目或产品的合理性，俗话说的好旁观者清。应该站在第三方的角度来看待这个问题是否存在风险或市场的价值。
  
  个人意见，希望和大家共同探讨测试技术。
  联想到国内产品很多人都会想到国内产品质量差，除了公司或厂家自身不重视测试质量保证或难道我们的测试工程师自身不存在问题吗？
  我想咱们的测试工程师是否应该想想呢？

   

  本人观点：我认为软件测试的人必须要有与常人不同的思维，要懂得创新才行

  查看(204) 评论(1) 收藏 推荐

• 测试乱想[转载]

  2008-03-07 19:52:08

   

  一:自己测试最多的模块是CDMA短信。归纳一下：

  1.发送接收符号：特别是不同网络之间的传递。同网络之间一般不会出现问题，但是C网对G网之间有几个半型的符号总是有问题：~<>()`.我在测试是对比的nokia的机型，同样存在此类符号显示问题。最后归纳为网络问题。

  2.常用语：目前我测试的平台都是一个平台，这个平台上问题比较多，特别是一些快速的操作，很容易暴露出这个平台的弊端。常用语是目前出现问题最多的一个模块。常常一些快速或者错误操作，就会引起手机的reset.

  3.UTK中的短信群发:这个模块中的短信很大程度上取决与你使用的UIM卡.现在很多卡都不规范,导致了一些异常问题,比如发送70,100,120,140字,不同的卡,会直接影响对方收到的内容.

  ......

  二:我是手机黑盒测试,所以目前做的最多的事情就是按手机发现问题,不需要更深入的测试.虽然工作内容简单,但是还是学到了很多知识.很多问题需要自己静心想想测试的流程,可能你操作顺序不同,就会导致截然不同的结果.所以这就需要全面的总结可能的步骤.

  公司和我关系还可以的RD无意间鄙视过我们这些手机黑盒测试人员:'就像机器一样,按来按去'.也许放到以前,听了这话,可能立即反驳,甚至大动干戈,我无法忍受别人歧视我的工作,但是现在释然了,这么说就意味着她不了解我们的工作,虽然工作就是按手机,但是每次按下去前都是用脑子想过的.只不过我用的脑细胞和他的不一样而已,所以我告诉自己'就是机器,也要做一个你离不开的机器'.

  三:最近公司在做一些测试规范化的动作,虽然烦琐,但是仔细想想,对于自身还是有很大的提高.以前自己填写BUG单的时候,只要描述出现的问题，但是现在我开始去思考自己填写的方式,自己描述的语言,以及这种描述能否让别人清楚.以前写一个BUG单可能不到一分钟,现在一个简单的界面问题,我都会思考再三.下班的时候对比了一下自己现在和以前的BUG单,发现自己的确进步了.就象公司一位测试经理说的话"好的测试是逼出来的".

  四,自己现在还很年轻,不论工作还是年龄,呵呵所以自己要努力:

  1.不要小瞧任何一个人,因为每个人都有自己的优点;

  2.不要小看任何一件事情,因为从每件事情上,都可以学到知识,只是大和小的区别;

  3.不要放弃任何一次进步的机会,因为小小的一步会攒成一大步.

  五,自己需要提升的一些地方:

  1.我打算主攻短信模块.现在的手机不论发展多快,短信这个模块都将和通话一样是最重要的功能.自己在协议测试上基本上是一窍不通,只知道用平台工具去查看一些参数,所以以后将多了解一下短信协议方面;

  2.语言表达能力.部门有位同事,`工作语言表达能力很让我欣赏.我要像她学习;

  3.协调能力.有个项目负责人准备让我帮他带一个项目,现在还没有开始,我觉得这是一个很好的学习机会.但是我对自己的领导能力还是很担心,我不是一个爱领导别人的人,自己的协调能力也很差,所以希望借此机会,能让自己得到提升.

  4.将自己的精力放在工作上.作为我这样的女孩,可能再过几年,自己将会很多精力放在家庭上,所以现在我将在年轻的几年中,努力的工作,不让未来的自己为这几年后悔.

  [转载地址] http://www.51testing.com/?168746/action_viewspace_itemid_75327.html