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

软件白盒测试是一个与黑盒测试相对的概念，是指测试者针对可见代码进行的一种测试。白盒测试通常再划分为单元测试、集成测试两大类，但依据不同的流程，对白盒测试细分的 标准 也不尽一致，比如在 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"

以下为个人观点，如有不赞同者，大可以拍砖指点。


昨天有一个网友问我是选择开发好还是测试好。
偶是这样回答的：
我一直不明白为什么会有人把职业来相比较。
我想可能是这两个职业的距离太近了。
但是，要说测试人员的开发经验。我觉得这个最不需要问的问题。肯定是有越多的开发经验
就越好的。

有人说了，我开发经验多，我还做测试干什么？
我不明白这种说法是从哪来的？
大概是由于一些不成熟的“开发地位或者薪水比测试高”的观点。

首先，我想说明一件事情，开发和测试是不同的职业。纵然有很多的相似性，我还是认为他
们是不同的职业。
但是因为相似性，所以很多人同时有进入这两个职业的机会。而在这机会面前他们开始犹豫
不断了。
到底是哪个更好，更适合自己？在一个刚出道的人眼里看来，判断是那么的困难。
换个角度，就算是工作几年的人来断言哪个更好？谁敢如此说呢？
我觉得职业没有可比性，不管是什么时候。

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

而做出选择是不容易的。最难的却不是做出选择，而是选择后是不是能坚持下去。别找借口
来说时间不够之类的傻话。这些东西对一个意志不坚强的人来说是致命的东西（如果因为情
绪的因素，我倒是觉得可以理解）。

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

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

今天并不是什么特殊的日子，只是最近郁闷，至于何来，并没有太多的出处。可能是技术上的不服，也可能是人际关系上的问题。总之，自己也是新手，亦想早日成为高人，在职场上早日立足。至于这些凌乱繁琐的关系，有必要和朋友们分享一下自己的经历和感触。

为什么选择学测试？你最好搞清楚这个问题，否则会很容易迷失方向。我的朋友圈子中，有很多，才开始自己的测试生涯，却已经被其他的旁支所迷惑，比如最终投身去做开发。我尊重他们的选择，也理解他们无法在短期内整理出自己的思路，不能怪他们。但是我想说，无论你选择什么道路，都必须坚持走下去。毕竟，世界上捡芝麻丢西瓜的事情谁也说不准。 当然，反过来，可能是你的造化。当然，造成你无法确定做测试还是做开发的根本原因无异于一句话：“测试人员跟在开发人员后面，没有前途的，技术上也被开发鄙视。” 对于不了解行情的新手来说，这是一句迷惑，答案只有自己投身之后才知道。却因此而放弃走测试的路，我认为，很不值。我可以说，测试行业正在日趋规范化，前途是光明的。只要有自信和技术，你怕什么呢? --还有人说，测试不需要动脑子，简单，做不下开发了，来做测试。这的确是一条出路，不过往后你会发现，一旦你这么想了，成功也就越来越远了。很显然，缺乏激情和想象力，促使你放弃了做开发，那么什么保证你将来不放弃作测试呢？测试很简单？如果是，那么你就是被开发鄙视的测试人员，也没有什么目标可言了。结论：既然选择了，就要为了自己的目标走下去。

测试需要什么技术？很多。相对于开发而言，新手做测试，对于狭义理解的技术要求相对比较低。狭义的技术是指计算机技术，编程技术，数学运算技术等一些硬技术。要求虽然低，但是不是没有要求。不过，这些硬技术绝对是不够的。扎实了这些技术，你能够获得一个饭碗，是你生存的工具。至于你能吃上什么菜，完全需要广义的技术来决定。凡事都是2/8原则的，交流和做人无异于其他行业的职场。这些技术，你自己去体会和累积，没有人能帮你。至于有些人喜欢背后议论，职场上有些表面上喜欢说好话，却不做实事的人而言，你自己的心态显然没有放端正。仅仅只知其一不知其二的臆断会令你丧失判断力和交际能力。有些人就是天生讨人喜欢，我们无法去嫉妒他们。因此，我也希望，我能和论坛上的朋友，一起努力，做一个有技术的人。免得出现电影中的台词：“一点技术含量都没有。”想想就可笑啊。。

怎样建立良性循环的交流圈？ 这里，我有时候忍不住想说，我们的论坛还不够活跃。难道这不是一个很好的平台么？说废话也没用，希望大家多多发帖讨论吧。技术上的争论，没有什么可以保留的。虽然，我也知道，身为版主，有时候说话很激进，但是，我同样也希望各位能共同促进技术上的交流和发展。Improve together. 测试，是团队项目，相信大家都明白。说这些，仅仅因为发现，新手园地每日的报道新兵很多，发话和提问的很少。我会把责任归在自己办事不利的身上，希望我的公告能起到积极效果。

最后，说点实际的内容。想学东西，每个人都有过的念头。至于新手如何才能更快更有效率的学习，我有几点方法和大家共享一下：

1.不要试图自己是牛人，一下子什么都要学，给自己个宽恕和计划，半年能精通一门技术，已经很值得羡慕和崇拜了。

2.不要去买很多书，尤其是中文书，太误导人了。 英语好的，多看看原版，思路清晰易解。英语不好的，去借鉴朋友的经验，比看书学的快得多。所以，交流比什么都重要。

3.学测试，入门的，从纯黑盒的理论和测试用例的编写学起。

4.做测试，数据库非常重要，至少要强迫自己能非常熟练一门数据库平台。

5.所谓学技术，拿台电脑，摸几下鼠标，点几下键盘，自己操作，别光看别人演示，看会了，立即就会忘的。

6.学编程，新手自己动脑子，别总是想着改代码，改不出高手的。想看资料的，请在WINDOWS环境下按F1，看懂了，自然成高手了。

不多说了，大家一起努力。

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

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. 乐于与人交流.

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

1. 测试人员与开发人员的人际关系

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

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

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

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

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

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

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

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

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

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

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

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

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

一、根基不牢

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

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

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

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

★ 小结：

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

二、专业不精

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

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

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，选择和修改产品中最重要的错误，决定相应解决方案，尽量使大部分的用户在大部分的时间内都能够使用愉快。

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

个人意见，希望和大家共同探讨测试技术。
联想到国内产品很多人都会想到国内产品质量差，除了公司或厂家自身不重视测试质量保证或难道我们的测试工程师自身不存在问题吗？
我想咱们的测试工程师是否应该想想呢？

 

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