首先介绍一篇文章，是关于测试的问与答：http://www.51testing.com/html/63/n-217263.html，作者用类似圣经的笔调阐述了自己对软件测试的认识。

　　在这篇文章里，以下一些观点我相当的赞同，我再按照我自己的理解为自己也为各位读者做一个总结

　　首先一点，测试只是在反馈信息。换个方向来说，测试不是用来做其他事比如排错什么的。这个观点在原文里用了一个非常好的比喻：测试就好比是在体检，他只会给你一个身体的状况报告，至于你是否健康，跟体检没有任何的关系。这个问题的实质其实是牵涉到一个责任的问题。在我目前的项目中，最后都会有一个流程，项目组长问测试人员是否还有问题，可不可以上线。表面上看测试是质量把关的最后一道关卡，但这道关卡不应该有责任说产品是否能上线。还是以体检为例子，测试人员的主要职责是告诉你身体的一个状况，但身体是否健康，到最后还是由自己说了算，体检人员不会也不能帮你做决定说你是否需要治疗，他只能给你体检数据让你作为参考。回到软件开发来说，最后的流程应该是项目组长决定是否能上线因为这本来就是他自己的责任，测试人员也不应该给出是否能上线的意见，只用反馈测试结果就行。

　　第二点，测试要跟随着开发进度走，从一开始开发甚至开发还没开始，测试就应该开始了。我目前的项目就有这么一个问题，因为测试人员不够的原因，测试只能被安排到最后，这样做有个最大的缺点，原文说得很好我直接引用一下：如果开发的产品本身就质量低劣，进行测试你不觉得是浪费大家的时间吗？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而是意味着会出现更多的缺陷。公司目前重做之前做的一个项目。这个项目在重做之前，测试回馈的错误很多，但都有计划得在修改，但是测试回馈的bug，并没有随着时间减少，这个项目组的开发人员压力相当得大，却始终做不出完全合格的产品来，加上需求也不固定，整个项目就是混乱两字。后来实在受不了排错的压力，上层决定将其重做。这个项目照理说不会有这么多问题，一开始规划都定得很好，但还是难免会出现这种情况，除了跟程序员的素质有关，跟需求的变动有关（这个说起来应该算是公司常犯的问题），最大的原因我想还是出测试的安排上。项目开始的时候，如果没有测试的规范，程序员就会开始有不自信的感觉，这种不自信会导致更严重的失去信心，导致敷衍完事，反正最后有测试嘛。这样做出来的程序，说出去能让用户安心使用吗？

　　第三点是属于我自己的认识，重视测试，重视自动化测试，重视TDD。这个观点我接着上个观点说：很多公司都有一个毛病（从我自己的角度来看），需求爱变动，不喜欢按照以前定好的计划实施。但是我们必须承认，变化总会是有的，我们应该时刻拥抱变化，这里又会说到敏捷开发了，我会在以后的文章里分享一下我对“敏捷”的认识。回到变化这个问题。变化意味着代码的变动，代码的变动意味着出错的风险，风险会给程序员以及整个项目组带来不自信。而测试正是带来自信的良药。所以一定要重视测试。但在目前公司，由于以上说的各种原因，另外加上测试都是人肉式手工测试，导致测试人员压力颇大。任何人在这样的团队，谁不会担心“我还有什么没有测到？”，谁又能给测试人员带来自信呢？我觉得作为一个程序员，忽视自动化测试是一个很愚蠢的行为。程序员是什么？程序员就是利用电脑给人类带来劳动解放的职业。如果不进行自动化测试，那就是程序员连自己都不知道怎么利用电脑为自己解放劳动力，这样的程序员又哪来的素质去想着帮别人解放劳动力呢？当TDD这个概念出来的时候，所有的程序员都应该兴奋，团队需要的自信，团队需要的劳动力解放，都在里面体现了。当我们面对更快的变化，当我们重构更多的代码的时候，请一定要想起使用TDD。

　　我们是程序员，我们在用电脑改善别人的生活前，一定要先学会用电脑改变自己的生活。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　职业病

　　踏入软件测试这个行业后，我越来越注意到自己从性格到习惯上都不知不觉地发生了一些微妙的变化。调侃地说，这些变化，也许就是软件测试员的职业病吧！

　　症状一：

　　看到什么事情，第一感觉总是这件事一定存在缺陷。由于软件测试员每天的工作就是挑bug，找bug，天天都在和bug打交道，所以，测试员每件事首先想到的就是bug，再加上测试员不断追求完美的思想越来越受到领导和客户的重视，这一症状表现得越来越明显了。

　　症状二：

　　将刨根问底的精神发挥得淋漓尽致。测试员的一个基本要求是：不要让开发人员随便地驳倒你，你应当告诉开发人员，这种情况是很可能发生的。所以，测试员就会把这个工作作风带到生活当中，有时被人家笑话之后，自己想想还会情不自禁地笑笑。再者，一但发现一个不正常的现象，就要打破砂锅问到底，一定要把程序的这个十分隐蔽的bug找出来，这不是倔，而是执着！

　　症状三：

　　遇到任何事都喜欢先用逆向的思维考虑问题。由于测试员在测试的过程中，为了找出更多的bug，他们会用逆向的思维快速地找出程序中的bug，久而久之，这一工作习惯也被带到了生活当中。

　　职业误解

　　本人2000年毕业，做软件测试有8年多了。从2002年开始走上管理岗位，分别担任Test Leader / Test Manager / QA Manager 等职位。任职期间，发现极个别软件测试人员工作久了，有些极端、走火入魔了。我们将其称为软件测试职业病吧。

　　典型病例：

　　2003年的时候，任职深圳某知名企业Test Leader. 那时遇到一个很奇怪的同事，她总是找我的问题（Bug）。几乎两、三天提一个，并表现出不满。自己做为年轻的Leader, 比较在乎别人的意见，想着如果是自己做的不好，就改。但是认真的分析了这些问题，并不是自己的错误，心里很纳闷，又没办法（或不好意思）说。

　　直到项目进行到测试执行阶段，终于明白了她为什么总是找我的Bug. 她做软件测试已5年多，每次都在拼命的找BUG. 后来发展到找人的Bug,  已经走火入魔。我离她最近，近水楼台先得月，自己被找Bug理所当然。举几个例子：

　　1. 让她Review 一份文档，她觉得4/5的文档写的不合适，全部加上批注或修改，并监督别人去修改。

　　2. 她发现一个Bug, 执意让别人修改，快哭着、闹着了。快使用上辣椒水、老虎凳去逼了；

　　3. 在她的眼里，自己的职业最崇尚。找人的Bug, 是在帮助、提高、挽救你；

　　4. 把“对事不对人”绝对化，铁面无私，不断的跳级提出问题；

　　5. 还有一个因素，当时软件测试并不成熟，许多知识来自网络。她阅读了许多网上的文章，并把它们捧为“圣经”，批评别人的“利剑”。

　　病症分析：

　　以上1、2点，出发点是好的，但做的过头了，主次不分。

　　1）. 别人是文档的Owner，你Review, 提出意见，最好基于尊重别人观点的基础上。不要一棍子打死，这样别人无法工作了。上级能让他写文档，说明他能承担起这个责任,也是责任人。你和他是协作的关系，不是敌人。他改不改是他的事，不要反客为主。

　　2）. 你的责任是发现Bug. 修改Bug、给Bug定性，是开发团队的事。不要越界，要学会协作。不然，自己成了“火神”“讨人嫌”、“神经病”（走火入魔）

　　关于第3点，分不清做事、做人、现实。

　　3）. 软件测试仅仅是一种职业，大家在工作期间发现软件中的Bug, 保证软件质量。不要把这种职业神圣化。在一个团队工作，人都有自己的优缺点。在软件测试中找出Bug,是一种善意。适当的方式指出同事、上级的错误，也是一种善意。钻牛角、职业化的找同事、上级的错误，属于恶意。是在扰乱公司秩序，捣蛋鬼的表现

　　关于第4点，过分的强调自己，就是把别人当傻子。

　　4）. 越级，是不得以的事情。在万不得已的情况下，才能使用。俗话说：先礼后兵。大家坐下来认真的谈，是在谈不来再和上级说。不考虑别人的感受，是自大的表现。

　　关于第5点，过于相信网络，就是傻子。

　　近几年，发生青少年痴迷于网络游戏的人数激增；由于网恋、发生抢劫、命案的也在增多。这些人大部分自控能力较差，模糊了网络与现实。这种情况同样在软件测试行业表现出来，痴迷于网络的软件测试文章。这些文章也是人写的，过滤性的选择尚可。捧为圣经，是网络疾病的表现，和痴迷于网络游戏的青少年没什么区别。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

问题描述：提取测试需求是软件测试活动中的基础工作，是测试活动展开的前提条件。

那么该如何提取测试需求呢？

精彩答案：

会员tengmy：

　　提取测试需求一般是测试项目的开始。

　　必要的前提是有足够充分的行业了解和完备的客户需求文档，开发文档和开发&需求关于功能的若干细化解析。

　　但是实际情况下，介于某些文化氛围和合作者的工作习惯，一般很难这么完美。

　　那么就只能从你能够拥有的客户资料开始。

　　首先要知道自己要负责测试的范围（scope）在哪里。

　　然后要从客户文档里面去寻找相关的功能描述，功能点。以及和其他的功能交叉的点。

　　根据功能点的初步筛查，做出一张功能清单列表备查。

　　然后就是一个校对，理顺，清查的过程。

　　务必保证所有需要测试的功能都包含在你这张清单当中，事无巨细，绝无遗漏。

　　然后就是研讨的过程，就要跟开发，需求进行核对，确认清单以及功能的完整性。

　　接着就是需要制作需求说明书以及涉及相关的功能测试框架。

　　经过评审之后，就可以让相关的测试人员参与，搭建测试环境，准备测试数据和根据测试需求说明书来书写测试用例了。

　　其实无论功能还是性能测试，需要注意的就是测试范围要划好，相关的监测点/测试场景要设计的真实有效。不要想当然的认为哪些功能是客户会关注的，常用的。因为对于不了解行业信息的人来说，很多时候，你的判断未必是对的。

　　这个时候，需要向业内人员，最好是用户虚心求教。否则一旦测试重点在一开始就发生了偏移，这个测试项目的结果就可想而知了。

　　这也是为什么很多项目的参与人觉得自己辛辛苦苦的在项目里面努力，但是到最后却得不到好的评价的一部分原因。

　　我们需要站在客户的角度上来考虑问题，但是不要把自己想当然的当成客户。或许你以及开发团队认为无足轻重的一个小小的点，足以让影响整个项目的成败。

原帖地址：http://bbs.51testing.com/thread-324102-1-1.html

版权声明：本文由会员tengmy首发于51Testing软件测试论坛每周一问活动（10-11-02）。

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。

　　1、常见的测试用例设计方法都有哪些？请分别以具体的例子来说明这些方法在测试用例设计工作中的应用。

　　1）等价类划分

　　常见的软件测试面试题划分等价类: 等价类是指某个输入域的子集合.在该子集合中，各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

　　2）边界值分析法

　　边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例，可以查出更多的错误.

　　使用边界值分析方法设计测试用例，首先应确定边界情况.通常输入和输出等价类的边界，就是应着重测试的边界情况.应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据.

　　3）错误推测法

　　基于经验和直觉推测程序中所有可能存在的各种错误， 从而有针对性的设计测试用例的方法.

　　错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例. 例如， 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等， 这些就是经验的总结。还有， 输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例.

　　4）因果图方法

　　前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系， 相互组合等. 考虑输入条件之间的相互组合，可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）. 因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

　　5）正交表分析法

　　有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。

　　6）场景分析方法

　　指根据用户场景来模拟用户的操作步骤，这个比较类似因果图，但是可能执行的深度和可行性更好。

　　2、您认为做好测试用例设计工作的关键是什么？

　　白盒测试用例设计的关键是以较少的用例覆盖尽可能多的内部程序逻辑结果

　　黑盒法用例设计的关键同样也是以较少的用例覆盖模块输出和输入接口。不可能做到完全测试，以最少的用例在合理的时间内发现最多的问题

　　3、详细的描述一个测试活动完整的过程。

　　1）项目经理通过和客户的交流，完成需求文档，由开发人员和测试人员共同完成需求文档的评审，评审的内容包括：需求描述不清楚的地方和可能有明显冲突或者无法实现的功能的地方。项目经理通过综合开发人员，测试人员以及客户的意见，完成项目计划。然后sqa进入项目，开始进行统计和跟踪

　　2）开发人员根据需求文档完成需求分析文档，测试人员进行评审，评审的主要内容包括是否有遗漏或者双方理解不同的地方。测试人员完成测试计划文档，测试计划包括的内容上面有描述。

　　......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/08/n-226208.html

　　没有明确的性能测试目标，没有测试需求，没有测试策略。但这却偏偏又是性能测试，所以称之为尴尬的性能测试。性能测试，在很多人眼里，就是扔给你个LoadRunner，给你的URL链接，然后再给你个性能测试报告的模板，最后告诉你，给你一个星期，或者说在XX号前把报告交给我。

　　于是乎，我们的性能测试工程师一拿到LoadRunner和URL就开始性能测试的旅程。这趟旅程不知道终点在哪（没有明确的测试目标），也不知道该怎么走（没有测试策略），既然开始了这趟旅程（老板任务已经下来了），就硬着头皮上吧（反正手里有这个万能的LoadRunner）。

　　脚本篇-我们的性能测试工程师虽然是初出茅庐，但是由于经常逛论坛和看资料，还是懂一点LoadRunner的测试流程。于是就用LoadRunner强大的录制功能，录制了基本脚本。接下来在脚本中参数化参数，插入事务，插入集合点，等等增强脚本，忙得是不亦乐乎。在迭代了几次回放后，没有报错。脚本就这样完成了。

　　场景篇-脚本完成后，开始准备设置场景的参数。没有做任何的基准测试和容量测试（这两者的概念还是后来得知的），测试报告上说要求多少个用户，持续多少时间，就填上相应的参数。作为性能测试，总归要监控服务器的性能，一开始我们的性能工程师是用他们的头儿推荐的方法：用操作系统自带的性能工具来监控服务器的性能。他的理由是：LoadRunner是装在测试机的，用测试机来监控服务器的数据，会存在网络上的延时而不准确。“用了LoadRunner，为什么不相信LoadRunner？如果用系统自带的性能工具来监控，为什么不请100个民工一起点，或许这样的效果更好，更真实。”一位测友的的原话，有点嘲。

　　分析篇-其实对这位性能工程师来说，根本就不存在着分析这个环节，他所要做的工作就是把平均响应时间，90%的平均响应时间，和服务器的一些性能数据，比如CPU %processor time等等全部塞进他们头儿给的性能测试报告中，点下了邮件的“发送”。完成了一次尴尬的性能测试的旅程。

　　后记：用自嘲的语气回忆了自己一开始做性能测试时的经历。有点嘲，有点尴尬。不过我觉得这种尴尬的性能测试存在于很多公司，或许你就有和我一样的经历，一样的体会。尴尬的性能测试，究竟是谁之过呢？没有明确的测试目标的性能测试，我们究竟该怎么做呢？值得我们深思……

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

继成功开展2007、2008、2009三届中国软件测试从业人员调查活动的基础上，51Testing秉着从软件测试从业人员角度出发的理念，于即日起发起2010年第四届中国软件测试从业人员调查活动，对测试从业人员现状及行业现状进行调查。

您的参与将帮助企业和测试人员了解目前测试领域的现状，测试人员可对比自身情况了解自己在这个领域所处的位置；企业也可以依据调查数据为企业决策提供有力的数据支持。

对于问卷中有关个人、公司的信息我们将严格保密，并且不向任何第三方透露、给予、传达该信息。

欢迎广大软件测试从业人员参与，与51Testing携手打造中国软件测试领域最具广泛性、权威性和实用性的产业调查。

本调查问卷不带任何商业性质，纯属研究活动。51Testing将会根据调查所得数据撰写、发布调查报告。请您认真填写，感谢您的积极支持和参与。

在线参与：http://bbs.51testing.com/vote/index.php
调查名称：中国软件测试从业人员调查
参与方式：在线参与、线下填写纸样问卷、电话咨询等，以求此次调查覆盖面达到最广。
调查对象：现职为软件测试从业人员
调查时间：2010年12月6日起至2011年3月1日止。

　　对测试用例的投资：

　　改进测试用例有什么价值呢？当你集中精力于更好的用例时，你会遇到什么样的风险呢？之前的用例已经覆盖了软件需求，那还不够好吗？这些问题的答案是，粗糙的测试用例会将你置于相当大的风险中。他们能从理论上覆盖需求，但是很难执行测试，预期的结果也是模棱两可。好的测试用例包含更可靠的测试预期并且能从三方面降低测试成本。

　　1、生产力：更少的时间来编写和维护用例

　　2、可测性：更少的时间啦执行这些用例

　　3、调度的可靠性：更可靠的测试预期

　　本文介绍了如何避免由于粗糙的用例设计所带来的风险。我们将更底层地从不同类型的测试用例分析，并展示在何处及如何建立质量来控制风险。它会就如何提高生产率，可用性，调度的可靠性和资产管理提供切实可行的建议。一旦你了解了用例的“什么”和“为什么”，你可以使用一份标准的检查点清单来确定风险领域以改善当前和未来的测试用例。

　　为测试软件所做的最多的工作就是编写测试用例。激励大家编写强健的测试用例的是维护版本成本减少的可能性。半数以上的软件项目都是需要长期维护的项目。那么你怎样擦能写出既经济，有能在回归测试中再次使用的高质量的测试用例呢？让我们开始寻找答案，撩起测试用例的面纱，看看里面究竟有什么。

　　展望测试用例内部：

　　测试案例的要素：

　　对我们而言，一个测试用例建立在系统需求之上的一系列动作和预期结果的集合。测试用例包括下面这些内容：

　　◆ 测试目的或者对于所测试内容需求的描述

　　◆ 测试方法

　　◆ 测试计划：应用程序版本，硬件环境，软件环境，操作系统，数据文件，

　　安全访问，测试时间，逻辑或物理的日期，测试先决条件(比如其他测试)，以及其他任何与被测软件系统需求相关的测试信息。

　　◆ 步骤和预期结果，或者输入输出

　　◆ 任何检验或附件（可选）

　　这些相同的元素，需要在每种级别测试的测试用例中体现：集成，系统，或 验收测试，对于功能，性能和可用性测试同样适用。“预期结果“标准不适用于诊断或其他探索性测试。诊断测试需要在他的用例中添加其他因素。不过，如果我们测试的结果应该属于一个范围，那么这也是“预期的结果”。测试用例的一个替代描述是说明，目的和设置情况或详细说明书。完成这些的步骤被称为脚本。然而另观点是将目的或者描述称为测试场景或者测试用例。所有这些观点在本文中对于质量评估和改进建议都是一致的。

　　测试用例的质量：

　　有一种误解，用例的编写质量是就跟欣赏一幅画一样，是主观的，就如情人眼里出西施。其实，用例的编写质量是客观的和可衡量的。如附录A中所示，我们能建立一个清晰的检查点列表，包含测试用例的结构性因素- -测试目的，测试方法，测试计划，输入和输出。然后遍历每条用例，元素是有或没有？此外对它们的结构，测试用例也必须符合下面这些质量标准。

　　◆ 精确的，他们只测试在他们的说明中需要进行测试的。

　　◆ 经济的，他们只有为了测试目的所必须的测试步骤说明，而不是为软件写一个手册

　　◆ 可重复，自立式的，测试用例是一个对照实验。不管是谁在什么时间执行测试，都应该得到完全相同的测试结果。如果只有测试编写者能够执行测试并获得结果，或如果不同的测试人员得到不同的测试结果，那么我们需要在测试步骤及动作设计上做更多的工作。

　　◆ 适当的，测试用例要对测试人员和的环境都应该是合适的。如果所设计的测试用例只是理论上的，实际执行需要的技能没有一个测试人员拥有，那么这只是一个空架子而已。当你知道谁是将第一次执行测试，你需要为他的测试执行铺好路：用例维护和回归。

　　◆ 可追踪性，你需要知道你用例所测试的软件需求是什么？它可能符合所有其他标准，但如果其结果，及格或不及格，不打紧，何必呢？

　　◆ 自我清理，执行完后将环境清理干净，测试环境返回测试前的状态。例如，不在错误的日期离开所测试的测试系统。自动化脚本，可通知其它脚本来做到这一点。不要将这个标准和破坏性混淆。测试应具有破坏性，包括通过一些可控制的，可重复的方法模拟一个生产环境。

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/64/n-225564.html

　　一直在做功能测试工作，负责过三四个不大不小的项目的功能测试工作，却很少静下心来总结工作中的得失。

　　很多不了解测试的人，认为功能测试不过就是拿鼠标点来点去，没有什么技术含量，随便招个应届毕业生就能干的工作。我也曾经认为功能测试没什么前途，现在看来觉得自己太浮躁了。功能测试的门槛可能比较低，做测试工作的人大多都是从功能测试开始，但要做好功能测试却不容易，需要学习的知识还很多，比如操作系统、数据库、网络。下面主要结合工作实践谈谈我对功能测试的一点总结。

　　功能测试最重要的是理解业务和需求。知道系统要实现什么功能，业务流程是怎样的，然后就可以根据需求编写测试计划和测试用例了。测试书籍上介绍常用的编写测试用例的方法有：等价类、边界值、因果图、判定表等，在实际工作中，我使用较多的有等价类、边界值、场景法和错误猜测法。在这里需要提一点，将测试用例按测试目的进行分类，比如用户界面、功能点、业务场景等，会让测试用例的结构看起来更清晰，执行测试用例的效率也更高。

　　要做好功能测试，还需要对整个系统的数据库结构比较清楚，每个功能点涉及哪些数据表，对数据的操作方式是怎样的。这样就不单从前台页面来进行测试，通过对数据库中数据的验证，可以发现隐藏的一些bug。比如库表没有进行关联删除，从前台页面是看不出来的，但实际可能导致程序出现问题。对一些比较复杂的组合查询或数据排序，也可以自己编写sql语句对结果进行验证。

　　除此之外，了解程序的框架结构和一些开发知识也有助于更好地测试程序和定位错误。做完一个业务，可以通过系统日志来查看错误原因，结合数据库结构，可以更好帮助开发人员定位错误。比如日志记录执行哪条sql语句出错了，错误的原因是字段长度设置不够。我在这方面做得不太好，现在在努力学习一些开发知识，期待在以后的工作能做得更好。

　　最后，对bug的分析和总结有助于积累测试经验。比如哪种类型的bug数量多，哪些测试用例发现的bug较多，有助于测试用例的编写和修改。在探索测试时，发现bug的测试过程也要加入测试用例库中。通过测试用例的累积，可以更好地了解系统常出现的错误，积累更多的测试经验。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html

　　白盒测试作为软件质量保证中的重要一环，对产品稳定性起到至关重要的影响，不幸的是，由于实施白盒测试有较高技术难度，该软件过程常被嵌入式厂商忽略，因为难于实施，所以容易失败，失败后产生畏惧心理，就更不愿意进一步去尝试，如此形成恶性循环。更令人担忧的是：产品进度很少有不紧张的，大家习惯于在产品发布前补做测试，甚至把测试留给用户，成天陷于紧张的救火工作。研发进度总会被许多意外打断，在最终交付日要严防死守的前提下，白盒测试自然最先被喀嚓掉了。

　　本篇总结实施白盒测试的几个主要误区，我们先从认识上端正对白盒测试的看法。

　　误区之一：白盒测试太耗时间，不值得一做

　　这是救火式团队对白盒测试的最典型看法。

　　评估白盒测试值不值得去做，不只要看白盒测试能发现多少问题，还要看白盒方式下发现问题并解决它的工作效率。另外，在确定的质量标准下，还要分析不做白盒测试，以其它测试方式（如系统测试）代替是否能达到目标，也即：让产品达到能满足市场的稳定程度，只做系统测试需要多少时长，若改成一半时间做白盒测试，另一半做系统测试，看看这两种方式的测试总投入差别有多大？

　　依据实际经验，成功的白盒测试与不做白盒测试相比，测试投入应节约1/3以上。当然，这个对比是产品要保证较好发布质量的前提下才成立的，如果不做测试，产品一调通就发布，那没得比了，这样测试投入是最节约的。

　　以上观点的详细论述请参考《为何进行白盒测试 从“清洗面包机”讲起》。

　　误区之二：系统测试可以发现所有问题，不必做白盒测试

　　从理论上讲，系统测试是可以代替白盒测试的，但现实操作中，让系统测试代替白盒测试的代价太高。白盒测试直接面对函数内的各个分支，如果在系统测试阶段设计用例，也让每个分支情况都能覆盖到，恐怕要付出数万乃至数百万倍的测试投入，现实情况是不可能这么操作的。

　　白盒测试不可或缺，不仅因为白盒测试的发现与解决问题效率很高，也因为白盒测试独具特点，能发现其它测试手段很难发现的问题，比如逻辑问题、边界条件、变量未初始化、内存越界等问题。

　　更详细内容请参考《为什么要做白盒测试》一文。

　　误区之三：白盒测试必须在真实环境下进行

　　近代量子力学有一个海森堡测不准原理，讲的是某个粒子的位置与动量不能同时被测量出来，由测量存在干扰，对其中一个参数测量越准确，另一个参数就越不准确。测不准原理在我们日常生活中很常见，比如要测试某物质的导电性，我们串联接上一个安培计来观察电流，但是，安培计本身也带电阻，导致测不准，测量值会偏小。

　　在软件测试领域也存在类似情况，比如要测试系统的CPU占用，于是添加代码统计CPU占用率，但添加的代码运行时，它本身也会消耗CPU。再如，为了实施白盒测试，必然追加测试代码，比如：构造特定运行环境、替换桩函数使之在特定情况下返回特定值，这些都改变了被测对象自身的特性，追求完全准确的测试非常困难。所以，我们并不是一定要追求在真实环境下做测试，而是要评估非真实环境（或仿真环境）下的测试对最终结果能产生多大偏离。

　　本人曾辅导过一个白盒测试项目，该项目是一个中间件系统，支持Windows与RT-Linux跨平台运行，当时本人竭力推荐在VC环境下做测试，但产品经理断然否决了这个提议，原因是他们有重要客户要跑RT-linux，测试就必须在RT-linux下进行。这下可好，也怪他们的调测环境不争气，且不论RT-Linux下缺乏测试手段，单单下载程序到驻留实时linux系统的单板，一次就要5分钟，如此测试完全可以想见最终结果是什么！后来我们统计该产品与RT-Linux平台相关的API总共不到15个，基本上都与任务调试、内存申请分配相关，完全可以改用Windows测嘛，整整两万多行源码，仅仅担心几个API不真实，而最终导致白盒测试做不下去，可悲呀。

　　根据我们多年实践经验，嵌入式产品的白盒测试大可不必非得在真实环境下进行，而且，绝大部分情况下，只有移到仿真环境下白盒测试才能做成功。这方面我们有太多经验教训了，众多坚持上单板做单元测试的尝试都失败，而在仿真平台下的白盒测试，成功率接近百分之百。

　　我们先看看上单板做测试的几个致命问题：

　　1、测试成本高

　　上单板做测试，搭建测试环境的成本比较高，调试与测试都很麻烦，上面提到的每次测试都要花5分钟下载程序就是一个例子。

　　2、面对初始代码，导致工作效率低下

　　因为白盒测试经常要面对初始代码，尤其是单元测试，刚写完的代码很不稳定，就要做单元测试，测试中代码跑飞是常事，更加剧了测试成本飞涨。而且，目前多数在单板运行的实时系统，都不具备像个人PC那样拥有完善的异常捕获与处理的能力，测试支撑手段必然不够稳健，经常要复位重起，严重影响测试效率。

　　3、上单板做测试的起点是多任务集成测试

　　要上单板能做测试，至少加载任务要起来，下数据配置的任务也起来，另外任务调度模块也要正常启动，这已经是复杂的运行环境了。让这种环境稳定运行就需要一个测试过程，这加大了上单板做测试的难度。而且，许多不依赖多任务调度环境的测试项，容易受单板任务调度影响，增加了调测难度，若改在仿真环境下在单机桌面系统中做测试，孤立的一个代码片断是很容易把单元测试做起来的。

　　......

本文转载自51Testing软件测试网，查看全文：http://www.51testing.com/html/72/n-223672.html

　　针对本文探讨的软件自动化测试项目，挑选工具的重要评判标准有如下几点：

　　1.工具成熟性，复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术基础成熟性指工具是否有着足够广泛的使用度，是否经历过足够的时间考验，是否经过足够实践的检验。

　　由于WOA软件自动化测试项目并非一个短期的、试验性的项目，而是一个需要长期进行并推广的项目。因此，冷门或是新颖的工具并不合适此项目。此类工具的稳定性以及未来的发展性没有保障。对于长期的软件自动化测试项目，风险过大。

　　2.资料全面性，由于在软件自动化测试项目的进行过程中，必然会遇到各类问题。若工具的资料不够全面，没有足够好的产品服务，没有强大的社区交互支持，那么，每次问题的解决过程都将变得非常艰苦，容易造成时间的大量浪费。项目进度难以评估，成本难以控制。

　　3.工具对象识别能力，虽然自动化工具未必是基于Gu一 (Graphieuser，s一nterfaee，用户图形界面)进行的，但基于GUI进行的自动化测试有其明显的好处—能够更好的模拟真实的用户操作。不但可以测试到底层的问题，还能测到表层问题，如页面的巧错误等。

　　因此，一个自动化测试工具的识别对象能力非常重要。一个优秀的自动化测试工具应当拥有良好的控件识别机制，并有快速准确的识别能力。自动化测试工具不但应该能够良好识别页面上的各种常见对象:如文字、超链接、图片、文本框、密码框、单选框、下拉框、页面弹出框等等。对于一些系统自定义控件，也应该支持自定义描述，提供对象映射功能等。由于对象在页面上的表现不同，并不是所有的工具和框架都能处理好各种情况，因此控件识别方面需要进行仔细的评估。

　　4.脚本语言支持能力，不同的自动化工具使用的编程语言不尽相同，常见的有vBseriPt、Javaseript、Java、e#、Rubv等。

　　对于脚本语合首先应考虑其功能是否可以满足需求，是否足够强大。Java、c#之类的高级语言功能上优势明显，vBscriPt、」avascriPt等脚本语言则需进行仔细评估。

　　5.工具的集成开发环境，(Integratedoeve一oping〔nvironment，集成开发环境)对于脚本开发非常重要，一个良好的旧〔对于生产效率的提升是巨大的。旧〔应提供智能提示、自动完成、快速编译查错、方便而又强大的调试等基本功能。

　　6.团队协作与版本控制，复杂工作流软件自动化测试方法的研究第二章软件测试理论与技术纂础在软件自动化测试过程中，需要团队协作。因此，一个良好的版本控制环境非常重要。能够使用迁出、迁入机制将自动化内容管理起来。保存每个迁入的版本，在需要回退的时候能够方便的找到历史版本并进行回退。这样能避免误操作带来的损失，才能让工作中的协作更为出色。

　　7.执行控制与执行报告，自动化测试与功能测试一样，需要进行多次的“执行”，测试执行能力对于自动化测试工具而言非常重要。由于自动化测试的优势之一便是可以进行无人值守的“自动”执行。因此，工具提供的执行方式应当多种多样，不但需要能够方便的进行手动驱动，还需提供自动驱动，定时驱动等功能。此外，自动化工具还应一记录每次运行的详情，能够自动生成内容详细的，可以定制的测试报告。

　　8.工具容错处理能力，自动化脚本运行中，会有多种不确定的因素的干扰，如常见的网络和服务器稳定性问题等。工具应提供恢复机制，能够让测试人员对于意外情况进行自定义配置，关联特定的恢复清理脚本。测试用例的编写与自动化工具的选择都是决定软件自动化项目成败的重要环节，下一章将结合本文着重介绍的WOA项目，具体阐述该项目的需求、工具选择、设计与具体实现。

本文转载自51Testing软件测试网，查看更多：http://www.51testing.com/html/news.html