问题描述：

　　如何弱化因不同测试人员测试而引发的BUG率上涨的现象？

　　精彩答案：

　　会员 livexmm：

　　想了想，如果测试人员变更导致BUG数量增加主要也就2个原因：

　　1、提交了重复的BUG报告。

　　这主要和任务分配，缺陷管理等有关系。

　　任务分配出现的问题一般是测试用例审核不严格，导致用例有效性下降，从而测试部门本身对自己的用例没有信心，最终导致换个人测试就要换用例。最后结果么就是测试了重复的模块，如果缺陷管理也不过关么就会出现提交重复BUG的情况。

　　解决办法：

　　● 增加用例的审核力度，加强用例的可用性、合理性与可重复性。

　　● 加强缺陷管理。这是建立在测试用例合理可用的情况下，确保每一个缺陷都有对应的来源于测试依据。像很多测试工具（比如CQ）都有这种测试思路，不要因为图方便而让自己增加更多的工作量。

　　2、软件确实有这些BUG。

　　这里也包含一些无效BUG的情况我放在一起说。

　　一般情况下测试是无止境的，总归能测出各种缺陷，这个主要是和测试阶段和测试方式有关。

　　比如你的软件经过了严格的功能测试，能够保证所有的功能有效并且没有任何业务逻辑上的缺陷。但是说不定一个简单的画面验证就能发现画面上输入金额的地方能够输入汉字。

　　如果2个测试人员，一个进行了很严格的功能测试，而忽略的画面测试的话，那自然换个人就能测出一堆问题。从测试原则上来说这确实没错，但是从开发计划上来说这就是无法忍受的。开发或者领导就会认为测试部门没有认真测试，而测试人员却觉得很冤枉。

　　解决办法：

　　想减少这方面的BUG最好能先分清楚该软件不同的测试阶段，由此来分配测试任务。尽早的规划出自己的测试目标，并且在测试用例和测试计划中体现。

　　所以负责设计测试计划的人一定需要对软件工程有一定理解。这样在设计自己的测试计划时心里才有谱，哪些测试我们需要做，哪些不需要做。根据开发模式还得考虑在哪个阶段做哪些测试。

　　举个例子，比如开发部门刚把一个软件的基本功能做好，想让测试部门测试一下功能方面的问题，然后画面就随便做了个让测试能先用起来。结果测试部门重点测了画面，发现一堆问题。你说这些缺陷开发会认吗？

　　如果能够很清楚的分清楚该阶段我们应该做什么类型的测试，还出现换个人就发现大量BUG，那就得好好检讨一下自己是否有认真的审核了之前哪个测试人员设计的测试用例了。

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

版权声明：本文由会员livexmm首发于51Testing软件测试论坛每周一问活动。

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

字体:  小  中  大  | 上一篇 下一篇 | 打印  | 我要投稿  | 推荐标签： 软件测试 测试工具

基准测试（benchmarking）是一种测量和评估软件性能指标的活动。你可以在某个时候通过基准测试建立一个已知的性能水平（称为基准线），当系统的软硬件环境发生变化之后再进行一次基准测试以确定那些变化对性能的影响。这是基准测试最常见的用途。其他用途包括测定某种负载水平下的性能极限、管理系统或环境的变化、发现可能导致性能问题的条件，等等。

　　基准测试的具体做法是：在系统上运行一系列测试程序并把性能计数器的结果保存起来。这些结构称为“性能指标”。性能指标通常都保存或归档，并在系统环境的描述中进行注解。比如说，有经验的数据库专业人员会把基准测试的结果以及当时的系统配置和环境一起存入他们的档案。这可以让他们对系统过去和现在的性能表现进行对照比较，确认系统或环境的所有变化。

　　基准测试通常都是些功能测试，即测试系统的某个功能是否达到了预期的要求。有些性能测试工具可以对系统几乎所有的方面（从最常见的操作到最复杂的操作，从小负载到中等负载到大负载）进行测试。

　　大部分程序员只在系统发生了奇怪的事情时才考虑进行基准测试，但我认为定期进行基准测试，尤其是在重大事件（比如系统或环境发生变化）之前和之后进行基准测试更有意义。一定要首先进行一次基准测试以创建基准线。如果没有基准线作为参照物，在事件发生之后进行的基准测试是不会对你有多大帮助的。

　　1、优秀基准测试的指导原则

　　在进行基准测试的时候，有许多好的实践方法。在这一节里，我将向大家介绍几个我认为对大家最有帮助的基准测试原则。

　　首先，应该牢记“事前快照”和“事后快照”的概念。不要等到你对服务器做出修改之后才想起应该进行一次基准测试并把测试结果与你在六个月前建立的基准线进行对比。六个月的时间会发生许多事情！你应该在做出修改之前进行一次测试，做出修改，然后再对系统进行一次基准测试。这可以让你对三组性能指标进行对比：系统的预期性能、它在修改前的实测性能以及它在修改后的实测性能。你可以发现所发生的事情让你的改变多少会明显一些。比如说，假设你的基准测试有一项是度量查询时间。你在六个月前为某个特定的测试查询建立的基准线需要花费4.25秒才能完成。现在，你决定修改受测表的某个索引。你在修改之前进行的基准测试得到的结果是15.5秒，而你在修改之后进行的基准测试得到的结果是4.5秒。如果你没有拍摄事前快照，就不会知道你的修改让系统的性能有了很大的提高。说不定还会以为你的修改降低了查询的速度--你也许会因此撤消这次修改，结果返回到执行速度慢的查询。

　　虽然这是一个假想的例子，但我希望大家能够从中注意到以下几点。首先，如果你是在对某个系统的数据检索性能执行基准测试，而这个系统的数据量会随着时间的推移而增长，你必须更频繁地运行你的基准测试工具才能准确地把握数据量的增长对系统性能的影响。在刚才的例子里，你应该把有关性能指标（比如数据负载量）在事前的测量值当作系统的“正常”指标。

　　其次，必须保证你的测试对你测量的东西有效。如果你在对某个表的查询性能进行基准测试，你得到的测试结果只限于应用程序级别，不足以从一般意义上预测系统的性能。一定要把应用程序级别的基准与全局性的性能指标区分开来，这样才能保证不会得出错误的结论。

　　另外一个与事前概念和事后概念有关的好的实践方法是，在活动（负载量相对稳定）的有限时间内尽可能多做几次基准测试，这是为了保证你的测试结果不会受到局部活动（比如临时出现的进程或高资源占用任务）的影响。我发现重复进行几十次同样的基准测试可以把各次测试结果的平均值作为最终的性能指标值。有许多技巧可以得到这些统计结果。有条件的话，你甚至可以使用一个统计包或是你喜欢的适用于统计的电子表格应用程序 来得出基本的统计数字。

　　注解：有些基准测试工具有自己的统计分析包，但MySQL Benchmark Suite没有。

　　我认为最有用的建议是每次只修改一个地方。一次修改多个地方并不是不可以，但这样你就不能期望从基准测试结果里得出什么有意义的结论。经常会发生这样的事：你修改了6个地方，其中之一产生的负面影响掩盖了另外几个的正面效果，剩下的一两个对性能没有任何影响。只有每次修改一个地方，你才能准确地判断出它对系统性能的影响是负面的、正面的还是没有影响。

　　还有，只要有可能，就应该使用实际数据来进行基准测试。人工生成的测试数据怎么说也会有一些规律可循，那样得到的测试结果往往不能反映实际情况，某些特定的功能（比如边界值和范围检查等）可能永远也得不到测试。如果你的数据变化很频繁，你应该选择某个时刻为它们“拍摄”一张快照，然后使用这张快照来进行每一次测试。不过，这么做虽然能够保证使用真实的数据来测试性能，可是随着数据量的增长也许无法测试出系统性能的下降。

　　最后，在解读基准测试结果和管理预期目标时，一定要让你的目标有现实意义。如果你想改善系统在某种特定条件下的性能，在确定目标前首先要把已知的后果弄清楚。比如说，如果你想知道把网络接口的传输速度提高100倍对系统性能会产生哪些影响，就必须先弄清楚你的服务器将不能按照比现在快100倍的速度发送和接收数据。在这类场合中，你必须综合考虑硬件的性价比和硬件可能带来的性能改善。换句话说，你的服务器的执行速度应当提高几个百分点，这样就为你省了钱（或说增加了收入）。

　　如果在做过仔细评估之后预计你的网络性能只要提高10%就可以做到收支平衡甚至赢利，那就把这个数字作为你的目标好了。如果基准测试结果表明你得到了这么大（或更好）的改善，就去找老板谈谈加薪的事吧；如果基准测试结果表明你没有得到这么大的改善，去建议老板把新硬件退回去（也可以顺便谈谈加薪的事，因为你让他省钱了）。不管是哪种情况，你的报告都有充分的依据，即你的基准测试结果。

　　2、对数据库系统进行基准测试

　　基准测试在很多领域都非常重要。但基准测试与数据库服务器到底有什么关系呢？答案包括很多方面。

　　对数据库服务器进行基准测试可以在许多不同的层次上进行。最常见的是针对数据库模式的改动而进行的基准测试。专门针对某个表的基准测试比较少见（虽然你可以这么做）。人们更感兴趣的是在改变了数据库的结构之后，其性能会受到什么样的影响。

　　人们的这种关心在刚开始使用一个新的应用程序或一个新的数据库时表现得尤为明显。此时，你可以设计好几种数据库模式并填充数据，然后编写一些基准测试程序来模仿所推荐的系统。嘿，这也是一种测试驱动的开发行为！通过创建多个数据库模式并进行基准测试，甚至可能会多次重复这些改动，你很快就可以确定哪套模式最适合你设计的应用。

　　有时候，对数据库系统进行基准测试还有一些特殊的目的。比如说，你想知道数据库系统在不同的负载情况或不同的系统环境下会有怎样的性能表现。那么，除了进行事前和事后的基准测试去了解对环境所做的改变会产生多大的不同，还有什么方法更能证明你新安装的RAID设备将大幅改善系统的性能呢？是的，一切都是围绕成本进行考虑，基准测试工具可以帮助你管理好数据库系统的成本。

　　针对性地对一些耗资源严重的具体应用进行优化

　　出现效能问题时，首先要做的是什么？这个问题我问过不少同事，有人说凭经验对出问题的sql进行优化，如我们一般说的要合理使用索引，尽量不要使用前面带*号的Like语句，不要再比较操作符前边进行计算或使用函数等等，这些道路都是对的，但经验有时候不一定能解决问题。问题出现时，首先要做的是确定问题点是什么，只有正确的找到问题后才能有针对性的解决问题。下面简单介绍我们一般从哪些角度入手，来确定问题所在。

　　1、首先从业务上理解该处功能，理解用户的真正意图，用户真正关注的是什么，想要的是什么数据，是否有变通简洁的方法达到用户要求。而非使用复杂sql查询。其实有些时候进行变通的修改，同样能达到目的，但是采用的sql语句已经极大地简化了。这是解决效能问题的优先要考虑的。

　　2、对固定的sql进行优化时，一定要关注查询相关的数据量，关注数据量的大小，有些时候用户进行一个查询，若没有处理好查询条件的话，返回的记录集合太大，这对用户来说，其实意义不大，关键是这样必然会导致较多的磁盘IO，效能问题是必然的。除非是用户真的需要这么多数据，但事实证明，多数都不是的，所以着眼点是怎样限制返回的记录集的大小或查询中使用的临时中间数据集合的大小。这样才能使你的优化达到效果，起到作用。

　　下面简单介绍几种常用的检查问题sql的方法。

　　当然其中是有些技巧的，如：

　　1、使用 set statistics io on 检查实际的磁盘IO信息，物理读、逻辑读等信息，这个是一个简单有效的参考数据，在笔者以往的经验中，也是主要的参考数据。

　　在查询分析器中贴出问题sql，使用set statistics io  为on，也可以在空白处点击右键，选择<查询选项>，

　　选择<高级>

　　勾选Set Statistics Io 。

　　运行查询，除了得到结果集合以外，还可以得到本次查询相关的IO信息，如下图：

　　1、没有对UTF-8的支持

　 　SQL Server有对Unicode的本地支持，使用过nvarchar和ntext字段类型的任何人都知道。它通过映射每个字符为双字节实体来内部处理 Unicode。如果你只是处理SQL Server实例之间的数据，那么不会有任何问题，因为它们都以相同的方式存储。

　　不过，如果你 试图使用BCP从把Unicode导出为UTF-8的数据来源导入数据，那事情就有点复杂了。UTF-8是Unicode的一种子变体，专门设计支持与八 位ASCII文本的向后兼容，所以默认使用八位ASCII编码的网页、电子邮件和其它格式可以用于存储Unicode数据。

　　如果你从UTF-8源导出数据，不要指望对这些数据使用BCP；它一直不支持UTF-8。你必须考虑数据问题，以完整双字节Unicode导出使数据形成可接受格式。具有讽刺意味的是，另一个普通的编码可以通过“-C”开关（ISO 1252，ANSI/微软公司Windows）被BCP接受。不过，就整体而言，你最好把数据导出为双字节Unicode，以保持对BCP的最大兼容性，尤其是如果你处理的数据可能包含与ASCII不兼容的字符。

　　2、注意导出的行顺序

　 　使用BCP通过查询导出的数据对于导出顺序遵守相同的规则，会应用于任何其它情况的查询。换句话说，如果你的查询没有明确的“ORDER BY”从句，你获得的数据看起来就是完全任意的顺序。它通常是基于隐含索引中的顺序形成的，但是我已经学会甚至连经验法则也不相信了——尤其是如果该查询 在多个表之间执行“JOIN”或者一些其它聚合函数。

　　数据是按什么顺序导出的通常并不重要，但是数据以什么顺序导入是非常关键的。如果你使用的数据库是后来导入行的正确性决定于早先存在的行，而且你是批量导入数据的话，那么导出的顺序就很重要，你需要相应地建立你的BCP语句。这一点似乎显而易见，但是我经常惊讶有那么多人，甚至包括一些资深的SQL Server专家都没有意识到这一点。

　　3、从BCP激活的存储过程不能接收参数

　　如果你使用带有参数的存储过程，作为BCP动作Transact-SQL（T-SQL）语句的一部分，几乎可以肯定它不能用，而且会在命令行抛出函数顺序错误。

　　当T-SQL语句传递给BCP时，它将被使用“SET FMTONLY ON”机制进行分析，来判断结果集的柱状格式。这意味着动态构造语句（比如带参数的存储过程）将不能正确分析，而且也不能在BCP下编译。

　　如果你想解决这个问题，有几种方法可以选择：

　　创建不带任何参数的存储过程，用问号激活存储过程并传入需要的参数（可能通过数据源而不是命令行接收参数）。

　　用sqlcmd替代BCP。

　 　MSDN博客中提到了一个处理技巧，需要使用称为“openrowset”的技巧。如果你通过“OPENROWSET ”函数运行“SELECT”，你可以以临时方式传递一个T-SQL语句，从而解决调用带参数存储过程的限制。然而，这种处理技巧也有局限：例如，与语句连 接时不应该使用，因为运行会对数据库造成消极变化，而且该语句可能需要运行不止一次。

　　4、导入时要注意表定义

　　当你使用BCP从一个SQL Server源导出数据，并导入到另一个SQL Server时，你导出时的列定义和导入时的列定义必须相匹配。这也包括诸如NULL或者NOT NULL这类定义，在目标表缺少它们会引起静默数据损坏。

　　5、在目标数据库上的触发器不能被BCP触发

　　不管什么时候运行导入操作，BCP的本地行为在目标数据库上都会禁用触发器。因为BCP导入操作通常很大，如果按默认启用触发器的话，导入操作会很混乱。因此，你需要在BCP上使用命令选项“-h FIRE_TRIGGERS”，这样触发器才会被触发。

　 　要注意，当选项启用时，触发器会为每个批量操作运行一次，——也就是说，每次你运行BCP时执行一次。另外还要注意，在SQL Server 2005和以后的版本中，触发器使用了“行版本”，在导入操作时用tempdb来存储行版本信息。如果你的tempdb不能容纳触发器生成的大量数据涌 入，该操作将异常终止。

　　6、BCP不能给本地附加文件输出

　　如果你使用BCP导出数据到文件，该文件必须是新创建的。你不能选择现存文件，并把导出结果追加到文件。幸运的是，解决办法并不困难，您可以简单地导出到任何多个文件，然后使用COPY命令来整合这些结果。命令如下：

　　COPY export1.dat + export2.dat export.dat

　　作为技术人员，我们以往更多的关注的是技术，但是在做个多年后，发现做正确的事比正确的做事更重要，而软件中需求的好坏就很大程度决定了你这个 软件是否正确，需求确定后不管你如何实现，功能给客户直接带来的价值远远比技术直接带来的价值要高。但是需求带来的问题一直是各个软件公司项目失败的首要 原因，因此需求是很复杂的，我们希望能在不断地学习和实践中不断地理清需求、提高需求分析能力。

　　软件需求包括3个不同的层次：

　　【业务需求】

　　描述组织或客户的高层次目标，通常问题定义本身就是业务需求。这种目标通常体现在两个方面：

　　问题：解决企业/组织运作过程中遇到的问题，如物资供应脱节、用户投诉量大、客户流失率高等。

　　机会：抓住外部环境变化所带来的机会，以便为企业带来新的发展，例如电子商务、网上银行等。

　　业务需求就是系统目标，它必须是业务导向的、指导软件开发的 高层需求。这类需求通常来自与高层，例如项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求从总体上描述了为什么要开 发系统（why），组织希望达到什么目标。一般使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。组织愿景是一个组织对将使用的软件系统所要达成的目标的预期期望。比如“希望实施CRM后公司的客户满意度达到80％以 上”就是一条组织愿景。

　　【用户需求】

　　用户需求是指描述用户使用产品必须要完成什 么任务，怎么完成需求，通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。用户需求必须能够体现软件系 统将给用户带来的业务价值，或用户要求系统必须能完成的任务，也就是说用户需求描述了用户能使用系统来做些什么（what），这个层次的需求是非常重要 的。

　　作为需求捕获阶段的主要产物，主要具备以下特点：

　　零散：用户会提出不同角度、不同层面、不同粒度的需求，而且常常是一句话形式提出的，如通过电话、短信等非正式方式提出的需求。

　　存在矛盾：由于用户处于企业/组织的不同层面，因此难免会出现盲人摸象的现象，而导致需求的片面性。

　　因此，我们还需要对原始需求进行分析和整理，从而得出更加精确地需求说明。用例、用户故事、特性等都是表达用户需求的有效途径。

　　【软件需求】

　　由于用户需求具有零散、矛盾的特点，因此需求分析人员还需要对其进行分析、提炼、整理，从而生成指导开发的、更准确的软件需求，软件需求是需求分析与建模的产物。

　 　软件需求是需求的主体，它描述的是开发人员如何设计具体的解决方案来实现这些需求（how），其数量往往比用户需求高一个数量级。这些需求记录在软件需 求规格说明（Software Requirments Specification）中。SRS 完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工 具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到SRS。

　　Error = 0 的程序是不存在的，怎样收集和处理程序中的错误？怎样更好地利用错误信息的收集和反馈来协助程序的调试？怎样让产品发布后，用户能够反馈出更有价值的问题 信息？这些问题是本文将要涉及的，最近对自己所做项目中的错误处理机制做了一些总结与思考，故在此讨论，希望对大家有所帮助。

　　目前，按照我个人的理解，软件中的错误收集和反馈方式主要有如下几种：

　　第一种方式：使用常用的信息输出语句。

　　对于控制台程序，可以使用 printf 语句或者 std：：cout 将错误信息打印出来；对于MFC程序，可以使用 TRACE 宏，将错误信息输出到 output 窗口，或者使用 MessageBox直接弹出对话框将错误信息告知用户 。

　　这些处理策略往往针对于 “交互性” 的代码段，可以实现 实时反馈错误信息，以供用户实时地进行处理，以免后面产生更大的错误。

　　第二种方式：使用错误日志方式

　　思想：将程序中的所有错误信息输出到错误日志文件中，这样有以下这些好处：

　　1、当程序发布后，客户在使用中遇到问题后，可以直接将错误日志发送给程序员，将极大地方便了问题的定位及原因的分析。

　 　2、便于调试多线程或者涉及网络通信等复杂的程序，因为在这样的程序中，设置断点的调试方式非常地不方便，一旦暂停在断点处，往往为引起线程异常或者 网络连接断开等问题，极大影响了调试的效率。如果将错误信息打印到文件中，错误描述详细丰富一些，可以极大地提高调试的效率。

　　3、便于程序进行大规模的性能测试。例如：C/S模式的系统，进行100个客户端对服务器的访问测试，使用这种错误收集策略可以方便地通过分析错误日志文件来推测系统的性能。

　 　下面思考这样一个问题：很多软件的设计上都有一个类似TCP/IP协议的应用层的模块，该模块一般是直接与客户端交互的一层，它隔离了核心代码模块与客 户端的耦合，那么，对于这样一种层次结构比较深设计方案，最底层发生的错误信息怎样传递到最上层？每一层都提供获取错误信息的接口？这样开销太大，也往往 不够理想，那该怎样处理呢？

　　我想应该主要有以下两种处理策略，也就是我即将引出的错误收集和反馈的第三种和第四种策略：

　　第三种方式：C++异常机制

　　C++异常处理机制是一个用来有效地处理运行错误的非常强大且灵活的工具，它提供了更多的弹性、安全性和稳固性，克服了传统方法所带来的问题.

　　异常的抛出和处理主要使用了以下三个关键字： try、 throw 、 catch 。

　　抛出异常、捕获异常 ，这些是C++提供的极其方便地处理异常策略，可以实现在最底层抛出异常，由最上层捕获，并且处理。

　 　说实话，C++异常机制的确是一种处理错误和异常的很好的策略，如果需要使用该机制，需要从软件架构和设计时就要开始考虑，一旦软件结构和代码写到一定 程度后，再引入异常机制将很难达到很好的效果。其实，要想用好c++异常机制，不是一件很容易的事，特别是对于项目组里面有大量新人的时候，故使用成本还 是挺高的。

　　关于C++异常机制很多C++书籍都有介绍，我也不在此赘述，本博客也有一篇C++异常机制的入门示例代码，有兴趣可以看看http://www.51testing.com/html/17/n-209117.html。

　　第四种方式：GetLastError模式

　　经常开发windows程序的人应该都了解，windows程序有一个API：GetLastError，它其实代表着一种错误收集处理机制。

　 　当一个Windows函数检测到一个错误时，它会使用一个称为线程本地存储器（thread-localstorage）的机制。当函数返回时，它的返 回值为flase就能指明一个错误已经发生。若要确定这是个什么错误，可以调用GetLastError函数来获取：该函数只返回线程的32位错误代码。

　　WinError.h头文件包含了Microsoft公司定义的错误代码的列表。

　　当Windows函数运行失败时，应该立即调用GetLastError函数。如果调用另一个Windows函数，它的值很可能被改写。

　　Visual studio还配有一个小的实用程序，称为Error Lookup.

　　如果在编写的应用程序中发现一个错误，可能想要向用户显示该错误的文本描述。Windows提供了一个函数，可以将错误代码转换成它的文本描述。该函数称为FormatMessage。

　 　以上就是GetLastError模式的介绍，可以简单地把它想象成为这样一种模式：有一个全局的变量，可以用来存放32位错误代码，一旦 Windows函数运行失败，就将错误代码赋值给这个全局的变量，每当调用GetLastError，则将该错误代码返回出来以供外部分析原因。

　 　其实，我们自己也可以实现这样一个GetLastError模式的错误收集机制，收集整个程序中最新的错误信息，供上层及时调用查询，定义自己的错误代 码和错误描述信息串，那么，怎样才能更好地实现属于自己的类似的错误收集反馈机制呢？怎样使它具有更好地移植性、健壮性（支持多线程等）和易扩展性（加入 新的错误代码和信息）呢？我将在后面的文章中介绍我的思考和设计。

　　以上就是我对软件中的错误收集策略的思考和总结，希望对各位有所帮助，也欢迎大家提出意见和建议。