Tag/
共1761个网摘 [
1 2 3 4 5 6 ...
59 ]
下一页 |
understandwho收录，使用标签：软件开发, 软件测试, 数据库, java, j2ee, asp, asp.net, 信息安全, 黑客，时间：2008-9-26 1:59:14 | 相关网摘，我也收藏
专注于j2ee,asp.net的web开发技术,数据库技术以及互联网信息安全技术。
http://www.ineeke.cn
lizhe1985收录，使用标签：软件测试，时间：2008-8-25 14:06:57 | 相关网摘，我也收藏
来源：http://www.blogjava.net/xiaodu/archive/2008/08/23/223898.html
程序在实际应用当中，大数据量时对系统本身的影响是一个不得不面对的问题。
什么是tptp
Eclipse Test and Performance Tools Platform（TPTP）用它可以监测运行的并发线程数据、内存的使用情况等，是不款非常不错的性能测试工具,它是eclipse官方的一款插件项目.可以进行程序执行时间的统计分析、内存的监控、对象调用的分析等。
环境
本次用的tptp版本是4.4.0.2是当时比较稳定的版本,再多说一句,本想下载tptp的4.4.1 但是下载所有eclipse官方所有依赖的插件运行后一直都启动不了agent controller(tptp依赖的一个非常重要的服务项目),所以请大家注意,我是浪费了整两天时间也没搞懂为什么启动不了,所以用了 4.4.0.2.
jdk1.6
Business Intelligence and Reporting Tools (BIRT) 2.2.2
tptp.platform.runtime-TPTP-4.4.0.2
tptp.trace.runtime-TPTP-4.4.0.2
Data Tools Platform (DTP) 1.5.2
Graphics Editor Framework (GEF) 3.3.2
Eclipse Web Tools Platform (WTP) 2.0.2
Eclipse Modeling Framework (EMF and XSD) 2.3.2
eclipse3.3.2
以上是我的运行环境供大家参考,还可下载许多tptp相关的插件工具,具体的网址是:http://www.eclipse.org/tptp/home/downloads/?ver=4.4.1
注意相关的工具可能也有他依赖的插件工具.
运行tptp
安装tptp后启动eclipse将出现如下界面:
如果你的eclipse工具栏的位置将出现profile按钮(上图红色标记的按钮)说明tptp安装成功.
如果想测试你的程序,右键点击类文件选择Profile as--->Java Application将打开如下界面:
在打开此界面过程中系统进程中将多一个ACServer服务项,这也是tptp所依赖的一个非常重要的服务,在tptp4.4之前的版本agent controller(ACServer服务)
是需要用户手动打开此服务,agent controller可以在tptp的网站下载,注意要下载与你系统相符的agent controller版本,tptp4.4不需要另外下载agent controller
tptp自动启动agent controller,此服务的默认的端口为10002,使用时要查看端口是否被占用,再看上图,如果你的jdk是1.5可以选择jre1.5,如果jdk1.6需要选择jre1.5
or new来运行tptp,如果成功eclipse将改变为Profile and Logging透视图,如下图:
左侧将出现统计项,双击此项在右侧出现统计信息,如果eclipse中安装有mdt-uml工具插件,当右键点击统计项时会出现uml统计项,将出现uml的序列图.
此上只是tptp的基本应用,仅供参考,tptp的配置及应用还有很多,并且也可以测试web工程的应用,如果有兴趣大家可以去eclipse网站查看资料.
http://www.blogjava.net/xiaodu/archive/2008/08/23/223898.html
futurelight收录，使用标签：软件测试，时间：2008-8-19 20:49:24 | 相关网摘，我也收藏
【InfoQ中文站】8月12日InfoQ中文站发布的“用数字沟通——来自敏捷精灵的忠告”一文，在敏捷中国社区里引起热烈讨论，发言者大多认为数字很重要，但是单纯地强调数字对敏捷开发并没有太多用处。
讨论由熊节首先发难，对“用数字沟通——来自敏捷精灵的忠告”文中所述的观点，他不甚赞同。原因在于他认为一个对敏捷没有深入理解的开发人员，在敏捷项目中如果依然沿袭传统的开发方法，结果会让自己更加辛苦。随后，讨论针对精确的数字是否有益于软件开发继续进行，来自ThoughtWorks的钱安川认为：
要求精确的数字，确实很扯淡。
但是，[很]明显，数字最有说服力。特别是业务人员和管理者，有了数据就可以放心大胆地做所谓的决策。当然，也明显是把责任推卸给了开发人员。
项目管理中，项目的估算和进度的统计数据都很重要。但是，如果只是一味追求数据，那么这样的数据就会不停的偏离真实的轨道。
起步停车对钱安川的关于数据会让项目不停地偏离真实轨道的说法表示赞同，同时以自己的实际情况进行解释：
http://www.infoq.com/cn/news/2008/08/numbers-communication
lizhe1985收录，使用标签：软件测试，时间：2008-8-6 16:24:13 | 相关网摘，我也收藏
来源：中国IT实验室
Usability的概念在中国开始逐渐为企业所认识，但是作为这个领域的核心词汇，usability的中文翻译仍未统一。目前存在着两个主流版本：“可用性”和“易用性”。这两个译法虽然只有一字之差，但它们所传达的含义却大相径庭。对这两者的取舍已经不仅仅是哪个更好一点的锦上添花的问题，而是哪个对哪个错的是非原则问题。“易用性”的使用对于正确理解usability具有极大的片面性和误导性，非常不利于其在中国的开展。
从英文原词上分析，usability是由use（动词）变化到usable（形容词）然后再转变为usability（名词）。Use这个词从动词到名词的过程还有另一种变化，就是从use（动词）到useful（形容词）再到usefulness（名词）。后者要比前者更“单纯”，变化的过程只是词性的改变而不涉及意思的转化。这些变化都围绕着use这个核心展开，因此在意思上都离不开“用”这个概念。-ability这个词根代表“具备某种行为特性”这样一个抽象的概念，故而在中文翻译中通常译为“可…性”，例如：readability（可阅读性）。因此，“可用性”这个译法是在严格遵从语言和翻译习惯的基础上形成的。“易用性”虽然也保留了这个“用”这个核心意思，但是其中的“易”字却完全是无中生有，因为在英文单词的整个变化过程中始终没有任何一丝“易”的意义出现。
对于为什么要人为加上“易”字，一个看似合理的解释是这是意译。那么usability是不是就是“易用”呢？不妨先看看usability的解释。世界标准组织对于usability的定义是“The extent to which a product can be used by specified users to achieve specified goals with effectiveness， efficiency and satisfaction in a specified context of use.”这个定义采用了effectiveness（效果）、efficiency（效率）和satisfaction（满意）三个维度来说明usability.尽管这三个维度并不构成usability的全部，但是在测量usability时它们是被最广泛采用的指标。如果说efficiency和satisfactory这两个维度还可以和“易用”扯上关系的话，那么effectiveness这个维度显然和“易用”是互相独立的两个概念。因此，意译这个说法同样是无法成立的。
事实上，“易用”在usability领域是有一个专门用语的，那就是ease of use.在英文文献中，没有人会简单地将ease of use与usability划等号。但是当usability进入中国以后，“易用性”却堂而皇之地以代言人的身份四处出现。也许有人认为“易用性”这个词比较直观，容易被大众理解和接受。殊不知这正是“易用性”的危害。如果放任“易用性”的使用， usability这个概念在中国恐怕将被局限在ease of use这个狭窄的范围之中。作为一个术语，是不是很容易从字面上理解其含义并不是第一重要的，“递归”这个术语就是一个很好的例子。对一个术语的翻译，在艰涩与误导之间永远都不应该选择误导。更何况“可用性”的译法远没有达到艰涩的地步。
让我们向“易用性”说不！
http://softtest.chinaitlab.com/kyx/758811.html
lizhe1985收录，使用标签：软件测试，时间：2008-8-6 16:20:47 | 相关网摘，我也收藏
来源：中国IT实验室
软件缺陷的描述是是软件缺陷报告的基础部分，也是测试人员就一个软件问题与开发小组交流的最初且最好的机会。
一个好的描述，需要使用简单的、准确的、专业的语言来抓住缺陷的本质。否则，它就会使信息含糊不清，可能会误导开发人员。准确报告软件缺陷是非常重要的，因为：清晰准确的软件缺陷描述可以减少软件缺陷从开发人员返回的数量提高软件缺陷修复的速度，使每一个小组能够有效的工作提高测试人员的信任度，可以得到开发人员对清晰的软件缺陷描述有效的响应加强开发人员，测试人员和管理人员的协同工作，让他们可以更好的工作在多年实践的基础上，我们积累了较多的软件缺陷的有效描述规则，主要是：
1. 单一准确每个报告只针对一个软件缺陷。在一个报告中报告多个软件缺陷的弊端是常常会导致缺陷部分被注意和修复，不能得到彻底的修正。
2. 可以再现提供缺陷的精确操作步骤，使开发人员容易看懂，可以自己再现这个缺陷，通常情况下，开发人员只有再现了缺陷，才能正确地修复缺陷。
3. 完整统一提供完整、前后统一的软件缺陷的步骤和信息，例如：图片信息，Log文件等。
4. 短小简练通过使用关键词，可以使软件缺陷的标题的描述短小简练，又能准确解释产生缺陷的现象。如“主页的导航栏在低分辨率下显示不整齐”中“主页”、“导航栏”、“分辨率”等是关键词。
5. 特定条件许多软件功能在通常情况下没有问题，而是在某种特定条件下会存在缺陷，所以软件缺陷描述不要忽视这些看似细节的但又必要的特定条件（如特定的操作系统、浏览器或某种设置等），能够提供帮助开发人员找到原因的线索。如“搜索功能在没有找到结果返回时跳转页面不对”。
6. 补充完善从发现bug那一刻起，测试人员的责任就是保证它被正确的报告，并且得到应有的重视，继续监视其修复的全过程。
7. 不做评价在软件缺陷描述不要带有个人观点，对开发人员进行评价。软件缺陷报告是针对产品、针对问题本身，将事实或现象客观地描述出来就可以，不需要任何评价或议论。
http://softtest.chinaitlab.com/qxian/758809.html
lizhe1985收录，使用标签：软件测试，时间：2008-8-6 15:55:51 | 相关网摘，我也收藏
来源：希赛网
通常采用以下一些方法进行源程序的静态分析。
① 生成各种引用表
直接从表中查出说明/使用错误等。如，循环层次表、变量交叉引用表、标号交叉引用表等。
为用户提供辅助信息。如，子程序(宏、函数)引用表、等价(变量、标号)表、常数表等。
用来做错误预测和程序复杂度计算。如，操作符和操作数的统计表等。
② 静态错误分析
静态错误分析主要用于确定在源程序中是否有某类错误或“危险”结构。
类型和单位分析：为了强化对源程序中数据类型的检查，发现在数据类型上的错误和单位上的不一致性，在程序设计语言中扩充了一些结构。如单位分析要求使用一种预处理器，它能够通过使用一般的组合/消去规则，确定表达式的单位。
引用分析：最广泛使用的静态错误分析方法就是发现引用异常。如果沿着程序的控制路径，变量在赋值以前被引用，或变量在赋值以后未被引用，这时就发生了引用异常。为了检测引用异常，需要检查通过程序的每一条路径。也可以建立引用异常的探测工具。
表达式分析：对表达式进行分析，以发现和纠正在表达式中出现的错误。包括：在表达式中不正确地使用了括号造成错误。数组下标越界造成错误。除式为零造成错误。对负数开平方，或对π求正切值造成错误。以及对浮点数计算的误差进行检查。
接口分析：关于接口的静态错误分析主要检查过程、函数过程之间接口的一致性。因此要检查形参与实参在类型、数量、维数、顺序、使用上的一致性;检查全局变量和公共数据区在使用上的一致性。
http://se.csai.cn/testtech/200808051155131216.htm
lizhe1985收录，使用标签：软件测试，时间：2008-8-6 15:53:46 | 相关网摘，我也收藏
来源：希赛网
终于明白了何谓“忙忙碌碌”，除了感叹古人造词的高深之外，也深刻为自己近期因为工作繁忙而没有积累而检讨。正所谓不积跬步，无以至千里。繁忙之余，还是决定和大家一起讨论一下最近接触的一个新的概念——专家评估。
这是近期用户体验测试引入一个新方法。整体的流程是邀请交互设计专家当场使用产品，产品设计、开发相关人员观察专家使用产品的全过程，在遍历整个产品细节后，由专家当场分享产品的使用体会。
单从这一流程就不难看出，专家评估与普通的用户体验测试的一个很大不同就是专家评估直接产出分析报告，并提供改进建议。就这点而言，专家评估更节省时间、更为有效。因为我们都知道，整理、分析用户行为需要大量的数据和前期的准备工作。
那么这是不是就意味着专家评估可以替代所有的一般用户体验测试?答案显然不是。专家评估的一个应用前提就在于它更适合功能简单的产品，因为只有满足这一点，参与评估的专家的行为才能更为真实的反映一种用户的习惯，而非凌驾于用户之上。
以我参与的这次评估活动为例，仔细观察，很容易发现，参与测试的专家由于自己的工作范围决定了其关注点有很大的不同。即专家的背景与结果的真实性仍然有很大的耦合。另外，由于专家的结果为现场分享，所以很容易产生“共鸣”，这就有可能将问题“放大”。因此，产品设计、开发人员不能盲目的接受这些分享，必须进一步的分析问题和建议，并将最终的结果反馈给专家评估小组，以供整个流程的改进。
当然以上仅仅是我的一些感受和看法，期待我们将产品越做越好，让测试更加有效。
http://se.csai.cn/testexe/200808061035161145.htm
lizhe1985收录，使用标签：软件测试，时间：2008-8-6 15:52:00 | 相关网摘，我也收藏
来源：希赛网
关于代码覆盖率，之前6年的工作经历中，只是依稀听闻过。之前的组织里，从未关注过这个指标，只是有一段时间用NUnit做了单元测试，主要是测试一些关键类关键方法是否正常，对代码覆盖率的印象就真的一直是停留在听闻的程度。汗一个!
前些时日，关于自动测试的讨论中有人提及到代码覆盖率，激发了我的好奇，到底什么是代码覆盖率?最重要的是于测试工作而言有怎样的价值呢?今天花了一点时间查了一下，有了初步的认识。大致归纳如下：
一、基本概念
代码覆盖率是单元测试活动任务之一；
覆盖率分语句覆盖率(即通常所说的行覆盖率)和分支覆盖率。
二、价值
代码覆盖率的分析能在一定程度上评判代码质量，一般覆盖率高的代码出错的几率会相对低一些。但是高覆盖率只是表示执行了很多的代码，并不意味着这些代码被很好地执行了。所以，似乎覆盖率测试结果出来并不能帮我准确的评价代码质量。那么我们为什么要做覆盖率测试呢?如何让它给我们带来价值呢?
1. 尽早评估代码质量
比如在开发的过程中，定时的去看整个项目的代码覆盖率，监控覆盖报告可以帮助开发团队迅速找出不断增长的但是没有相应测试的代码。例如，在一周开始时运行覆盖报告，显示项目中一个关键的软件包的覆盖率是 70%。如果几天后，覆盖率下降到了 60%，那么您可以推断：软件包的代码行增加了，但是没有为新代码编写相应的测试(或者是新增加的测试不能有效地覆盖新代码)。能够监控事情的发展，无疑是件好事。定期地查阅报告使得设定目标(例如获得覆盖率、维护代码行的测试案例的比例等)并监控事情的发展变得更为容易。如果您发现测试没有如期编写，您可以提前采取一些行动，例如对开发人员进行培训、指导或帮助。
2. 为功能测试关注点提供情报
假设覆盖报告在指出没有经过足够测试的代码部分方面非常有效，那么质量保证人员可以使用这些数据来评定与功能测试有关的关注区域，可以更有针对性地加强这些区域的测试，因为没有被测试代码覆盖到的区域，出错的几率应该相对更高。
3. 估计修改已有代码所需的时间
对一个开发团队而言，针对代码编写测试案例自然可以增加集体的信心。与没有相应测试案例的代码相比，经过测试的代码更容易重构、维护和增强。测试案例因为暗示了代码在测试工作中是如何工作的，所以还可以充当内行的文档。在另一方面，没有经过相应测试的代码更难于理解和安全地修改。因此，知道代码有没有被测试，并看看实际的测试覆盖数值，可以让开发人员和管理人员更准确地预知修改已有代码所需的时间。
当然，这样的理解还是比较浅层的，我想实际应用中除了以上三点之外，还有一个很重要的工作就是提高测试代码的质量来更好的体现代码覆盖率的价值。
http://se.csai.cn/testtech/200808041503091599.htm
lizhe1985收录，使用标签：软件测试，时间：2008-7-30 15:56:30 | 相关网摘，我也收藏
来源：51Testing软件测试网
多数人从用例开始就走入了迷途，也许是用例图和数据流图的相似性导致人们把用例定义为简单的功能或者菜单项。不论原因是什么，这都是新手最容易犯的错误。
图 1 错误的方式：用例是菜单项或者功能
这幅图有什么错误？用最简单的定义，我倾向于把用例看作是关于使用系统作某些有用的事情的方式的故事。利用这个定义，是不是所有的“用例”都是独立的有用的呢？
答案当然是不是，在这个例子中，用例表示了系统需要做的所有的事情，但是他们也描述了用户需要通过系统去做的一件单独的事情：定购。所有保留的元素都是这一个用例的备选支流，它们是在定购时可能发生的步骤。在只做一件有用的事情的地方，只应该有一个用例。图1就是一个功能分解的例子，或者“四轮马车”格式的例子――一个参与者在中间，周围是一圈用例。
这是一个常见的问题，为什么人们会陷入这个陷阱呢？我们有一个有对定购的内在需要，并且在不存在的地方如果我们需要那么就利用它。在功能分解的情况下，我们有一种自然倾向把问题分解为越来越小的块。有一种天真的想法那就是把用例分解为越来越小的单位会简化问题。这种理解是完全错误的。当我们分解用例时，实际上会把问题复杂化。
问题在这里
用例的目的是描述某人某物如何使用系统来完成对他们有价值的事情，它描述了系统在概念层次上做什么，使我们足够理解系统以便决定系统是否要做恰当的事。用例是我们能够形成一个系统的概念模型。
再看看图1，现在问你自己，如果我从来没有定购过，我想通过系统查询定单的状态吗？这是不太可能的。或者如果我从来没有定购过，我想变更订单吗？不，也许不。通常这些东西只有当我订购过的时候才对我有用。然而，为了系统能够允许我订购，这些都是必要的。
把系统分解为越来越小的用例模糊了系统的真实目的，极端情况下，我们将以得到一堆隔绝的行为的细致末节而告终。结果我们不能说明系统做什么。这就像看到一辆被拆解为零件的汽车，或许你会说这是辆汽车，你也知道零件们是有用的，但是你确实不能说明他们如何组装在一起。
当使用用例的时候，记住用例是考虑整个系统的一种方式，并且要组织成可管理的功能块，这些功能块完成一些有价值的事情。为了得到正确的用例集合，问你自己一个问题：“参与者实际上想使用系统做什么？”
如果你在想图1的改进后的版本是什么样的，图2展示了改进后的版本。
图 2一种更好，更加简单的方法: 合并功能以反映对参与者的真正价值
这一个用例包含了以前的图中所分解为用例的所有“功能”。你也许会问为什么这样做比较好，答案很简单：它关注于客户想要系统提供的价值，而不是我们在系统内部如何细分和构造的。如果把所有的功能分解成单独的用例，你将迫使客户（为系统付钱的人）把分解过的用例装配成一件对他们有意义的东西，以便理解系统所描述的是不是他们所想要的（即他们想为之付钱的）。
关注价值
很多小用例是常见的问题，尤其是在一个习惯于功能分解的团队中，他们的用例名称读起来就象是一个系统所执行的功能的列表，如“输入订单”、“审查订单”、“取消订单”、“履行订单”，这起先听起来也不是很坏，但不仅仅这些。即使对于一个小规模的订购系统，用例列表也很容易达到上百个，如果谁走到了这一步，他们不久就会淹死在用例的海洋中，尤其是当系统规模确实比较大时，在这种情况下，你最终也许会有几百个，甚至上前个用例。
这么做有什么错呢？
这些用例的价值将会被错过。用例的唯一目的是为参与者产生价值。在一定层次上能够输入订单也是某种有价值的事情，但是，如果这些订单从来不被履行，那还有价值吗？也许没有吧。
怎样输入订单、修改订单以及取消订单等等，所有这些事情都是与客户真正想要做的事情有关的，那就是接受订购的货物。这些活动对公司想要的事情是必须的，那就是收到货款。
这种看起来是支离破碎的没有任何明显关系的功能集合的另一个问题是导致难以使用的系统。很多系统跟这个很类似，它们只是一堆杂乱的特性。记住，用例帮助我们关注与什么是真正重要的，也就是具有真正价值的事物，并且使我们能够围绕那些元素来定义系统。用例不要是系统按照功能分解的蓝图。
举例
考虑一个你在互联网上用过的一个电子商务系统，当你登录这个站点的时候，你的目标可能是查找产品相关的信息、选择要购买的产品、安排支付及送货约定。在做这些事的过程当中，你可能会改变主意、输入错误的信息以至不得不修改它、改变邮递或送货地址，以及其他的一些东西。如果这个网站不允许你通过一种吸引人的方式来找到并订购产品，你也许不会完成你的订购，更不用说再次来到这个网站。
当建造一个系统时，始终要记住用例的核心定义：关于采用某种方式使用系统来做有价值的事情的故事。如果你能够实施这个定义，展示用户希望通过系统获得的价值，然后创建反映这些价值的用例的时候，你的系统将会更好地满足用户的期望。
http://www.51testing.com/html/200807/n89086.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-30 15:53:27 | 相关网摘，我也收藏
来源：51Testing软件测试网
讲到测试，人们脑海中首先浮现的是针对软件正确性的测试，即常说的功能测试。但是软件仅仅只是功能正确是不够的。在实际开发中，还有许多其它的非功能因素在起着决定性作用。比如软件响应速度，影响软件响应速度的因素很多，有些是因为算法不够高效，有些可能受用户并发数的影响。
在我所负责的测试项目中，程序功能能够满足客户需求，但当把程序交付客户使用时，由于客户网络应用环境复杂，而我们在压力测试时没有周密考虑各种可能发生的情况，软件程序在巨大负载下频繁崩溃，使测试团队饱受客户和老板的抱怨。由此，我认识到随着网络环境的复杂性和多样性，压力测试是软件质量保证的重要元素之一，绝对不能马虎了事。
什么是压力测试？
在软件功能测试中，白盒和黑盒技术用于对正常程序功能和性能进行详尽的检查和测试。而压力测试（Stree Testing）则是用来对付非正常的情况。
（1）什么是压力测试
压力测试是指模拟巨大的工作负荷来测试应用程序在峰值情况下如何执行操作。例如模拟实际软硬件环境，在超出用户常规负荷下，长时间运行测试工具来测试被测系统的可靠性，和测试被测系统的响应时间，目的是在极限负载下识别程序的弱点。
在众多类型的软件测试中，压力测试主要是以软件响应速度为测试目标，尤其是针对在较短时间内大量并发用户访问时软件的抗压能力。因此，压力测试是在一种需要反常数量、频率或资源下运行系统。由于我们之前对“反常”这个关键词没有理解好，只进行了常规的测试，在这一点上客户的批评让我们感到非常汗颜，说我们是“头发长，见识短”。
（2）压力测试和负载测试的区别
在这次项目测试前，我一直对压力测试和负载测试存在着一定程度的混淆。经过这次系统崩溃后，我对压力测试和负载测试的区别有了新的认识。压力测试是在超常规负荷条件下，长时间连续运行系统，检验应用程序的各种性能表现和反应。负载测试是指测试应用程序在常规负荷下，确认响应时间和其它的性能和表现。
实际上，压力测试也是从比较小的负载开始，逐渐增加模拟用户的数量，直到应用程序响应时间超时。压力测试的特点是长时间连续运行，增加超负荷（并发，循环操作，多用户）来测试什么时候系统会产生异常，以及异常处理能力，找出瓶颈所在。现在的我终于明白到其实压力测试实际上就是超常规的负载测试。
（3）压力测试的核心原则
一个有效的压力测试需要遵循一些核心的基本原则，这些原则可以让我们在测试过程中时刻提醒我们压力测试是否还有更多的极端可能。
①重复:最明显且最容易理解的压力原则就是测试的重复。换句话说，重复测试就是一遍又一遍地执行某个操作或功能。功能测试是验证一个操作能否正常执行，而压力测试则是确定一个操作能否在长时间内每次执行时都正常。
②并发:并发是同时执行多个操作的行为。换句话说，就是在同一时间执行多个测试用例。功能测试或单元测试几乎不会与任何并发设计结合。因此，压力系统必须超越功能测试，要同时遍历多条代码路径。
③量级:压力测试另一个重要原则就是要给每个操作增加超常规的负载量。就是说压力测试可以重复执行一个操作，但是在操作自身过程中也要尽量给程序增加负担，增加操作的量级。一般来说，单独的高强度操作重复自身可能发现不了代码错误，但与其他压力测试方法（如并发和量级）结合在一起时，将可以增加发现错误的机会。
④随机:意思是任何压力测试都应该多多少少具有一些随机性。例如随机组合前面三种压力测试原则，然后变化出无数种测试形式，就能够在每次测试运行时应用许多不同的代码路径来进行压力测试。当一个压力测试结合的原则越多，测试执行的时间越长，就可以遍历越多的代码路径，发现的错误也会越多。
压力测试对系统的重要作用
我们对应用程序进行压力测试时经常会出现这种情况，就是测试到了最后却发现不明白测试结果有什么意义？实际上，当我们都不明白压力测试的意义时，我们就不能设计出各种极限测试用例。
压力测试不同于功能测试，软件的正确性并不是它的测试重点，它所看重的是软件的执行效率，尤其是短时间内访问用户数爆炸性增长时软件的响应速度。因此，明白压力测试的作用，对我们高效完成压力测试有至关重要的指导意义。
（1）测试应用程序的可靠性
在系统崩溃后总结之前失败的压力测试时，我忽视的第一个要点就是没有测试出应用程序在压力下的可靠性。压力测试除了对每个单独的组件进行压力测试外，更应该对带有其所有组件和支持服务的整个应用程序进行集中压力测试，以检查在巨大的工作负荷时，应用程序在峰值情况下是否可靠的执行操作。例如，当实际情况是平均每秒出现1个或2个中断的情形下，应当对每秒出现10个中断的情形来进行特殊的测试；又或者把输入数据的量提高一个数量级来测试输入功能是否可靠的响应。从本质上来说，压力测试是想要看在最大极限时程序是否可靠的运行。
（2）测试应用程序的并发性能
进行压力测试需要对实际的并发访问量有一个正确的预期估算，否则在负载远远大于事前预测的压力下系统将脆弱得不堪一击。导致系统崩溃的因素有很多，处理能力、存储速度、响应时间、网络带宽等无论哪部分出现短板拥堵、后果都可能导致全盘崩溃。
现在我明白，哪怕硬件条件达到了，如果软件的并行处理能力不足将会导致等候队列过长，响应时间变慢，系统崩溃也只是时间问题。简单说就是：压力测试是考察当前软硬件环境下系统所能承受的最大并发负荷，并帮助找出软件程序的瓶颈所在。
（3）测试应用程序的最大负载能力
压力测试的目的之一是找出应用程序能够支持的最大客户端数。通过多次的运行和对测试结果中正在运行用户数与错误用户的对比，然后根据可接受错误率就可得到该功能的最大负载访问的用户数。最大负载压力测试用来评估在超越最大负载的情况下系统将如何运行，这时的目标是要发现在高负载的条件下应用程序的缺陷(Bug)，例如内存泄漏等。因此，最大负载能力不但是应用程序一个重要的技术指标，也是客户评估和验收软件的一个关键指标。
如何进行高效的压力测试？
软件测试有两句通俗的话：开发是尽可能地让程序通过；而测试则是尽可能地让程序通不过。对于压力测试而言，测试效果好不好，测试计划的好坏是关键。所以，针对不同的情况，分析后有针对的进行测试，比起拿枪乱打、无的放矢显然要高效得多。
进行一次切实可行的压力测试并不像乍看之下那么简单，遇到的问题也可能非常微妙。例如，我的测试团队就经常遇到诸如“客户端每小时将要处理100个客户订单请求”等此类的需求，于是测试团队就试图把该需求转化为某种测试需求，执行这种测试需求的常见方法就是以死循环的形式对服务器进行反复请求，然后静观其效。然而，通常事情进行得并不顺利，原因在于这只是把需求表面化了，没有分析出测试需求的本质。高效的压力测试应遵循以下这几个步骤：
（1）确定测试目标
在确定压力测试目标中，我们要定义测试的对象，并对每一个测试对象给出清晰说明，也要定义测试结束的目标。为控制测试的有效性以及完成程度，必须定义准则和策略。准则必须是客观的，可量化的，而不能是经验或感觉。例如压力测试目标可能是测定终端用户处理事务的响应时间，它可能随用户的增加而增加，但要定义一个可接受时间。在确定压力测试目标过程中，最好能邀请客户、设计人员等一同对测试目标进行评审。
（2）制定压力测试计划
测试计划内容包括：定义测试资源、制定测试进度表、选择测试工具等。制定测试计划的目的是使压力测试有章可循并得到人力、物力等各方面的保证；在制定测试进度表时应考虑和开发进度相互协调；对于测试工具的选择应以满足测试目标为前提。所以，这并不是说测试工具提供的功能越多就越好，在实际的选择过程中适用才是根本。
（3）编写测试案例和设置测试数据
测试人员一般是根据测试案例进行实际的测试工作，因此测试案例的编写应做到客观全面、重点突出，也就是要求编写的测试案例应该尽可能模拟真实的负荷，不遗漏重要的测试内容。为了让所有的测试顺利执行，可采取数据驱动方式进行，同时应该对测试数据进行参数化。另外，一般不提倡在开发环境中进行压力测试，最好是另外构建测试环境。
（4）结果分析及测试报告
压力测试运行结束后，应把所有的数据汇总并记录到文件中，以方便对测试结果进行分析和得出结论。若测试失败，应先分析失败原因，如果是软件系统造成的，应返回给设计人员修改。如果测试结果不满足预期需求，应先对软件程序进行优化调理，然后再次运行测试，直到可以满足预期需求或调整已无法改善结果。
最后需要注意的是测试报告。报告应包括测试提要、测试环境和测试结果。提要应简单说明测试方法、策略、范围、内容；测试环境应包括资源开销、环境配置等；测试结果必须包括测试是否通过或拒绝，并要对测试结论进行说明，并对软件程序的性能做出评价。
http://www.51testing.com/html/200807/n89095.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-30 14:35:19 | 相关网摘，我也收藏
来源：http://www.blogjava.net/BlueDavy/archive/2008/07/25/217514.html
不是专职做压力测试这行当的，只能是以自己的经验来以外行人的眼光来说说压力测试，压力测试并不仅仅是个压力测试的过程，而是一个相当系统和复杂的工程，我认为压力测试是为了让系统达到所期望的运行效果以及承受所期望的压力，这也就要求压力测试应该帮助性能调优团队，为其提供一定程度的指导，在这里我不将压力测试和性能调优分的那么清楚了，在我看来，压力测试过程包括了：明确压力测试的目标、制定压力测试方案、进行压力测试、分析压力测试结果、寻找瓶颈并进行调优以达到目标，在这篇blog中来细看下这几个过程以及常用的方法。
明确压力测试的目标
通常来说（注意是通常），压力测试的目标有这么几点：
1、评测系统是否满足压力支撑的要求
要评测系统是否满足压力支撑的要求，同样要做的就是需要明确定义系统需要支撑多大的压力，例如：
机器的配置：CPU、内存、硬盘、etc.
网络条件：100M
操作系统：Linux core: 2.6
当并发数为10用户时，系统应能在20ms内响应完毕（这个时候的TPS为500），系统的load需在2以下；当并发数为100用户时，系统应能在50ms内响应完毕（这个时候的TPS为2000），系统的load需在4以下；当并发数为200用户时，系统应能在80ms内响应完毕（这个时候的TPS为2500），允许其中有千分之一的出错率，系统的load需在6以下，在压力测试的过程中，只要其中的任何指标未达到，均可判定系统尚未达到压力的目标。
实际的压力测试的这个指标会比我这里举的例子复杂很多，例如还需要考虑网络流量、内存消耗、IOPS、连接数等等。
这里面压力测试隐藏的目标是为容量规划提供一定的指导，例如目前的系统在某种配置的情况下单台机器能承受的最大并发数为100用户，那么如果系统的高峰压力是1000的话，如果系统支撑无损水平扩展的话就意味着需要10台这类配置的机器，这一步同样是经过测试的。
2、预估系统上线运行的状况
毕竟通常压力测试环境和线上的环境是会有很大的不同的，压力、数据量、硬件环境等，基本上只能是根据线下的环境的情况进行一定比例的对比后计算来预估，这里面很重要的是要预估系统上线后正常情况下的表现状况、一定的增长比率后的运行状况以及风险点（例如当并发用户数增长到多少时、系统load到多少时可能会出现问题）。
这一个目标我觉得非常难达到，但随着经验，我相信是可以做到的，如果能做到这种效果的话是会有很大的帮助的。
以上这个两个目标基本是压力测试都要达到或希望达到的，而具体有可能会因为系统的业务的具体情况会制定其他不同的目标。
制定压力测试方案
这步是压力测试整个过程中最难的步骤之一，为了能够测试出系统是否符合压力支撑的要求以及评估上线的表现，通常我们会希望搭建出和生产环境完全相同的环境，但这就是最麻烦的一点了，基本上是不太可能的，因此通常能采取的方法会是：
1、做等比例的缩放
按照生产环境的情况做一定比例的缩放，例如生产环境的数据量为1亿条，那么测试环境等比缩放到5000w条，生产环境的处理速度的情况...；
2、更差环境、更高压力的测试
采取比生产环境更差的机器配置、网络环境来进行测试，例如ebay的要求是能够承受10x的压力。
3、仿真测试
据资深人士而言，仿真测试要做到基本是不太可能的，仿真测试首先要求的是收集到生产环境中的运行状态的数据，然后在测试环境中编写程序来做到模拟生产环境运行的效果，这个难度基本是非常高的。
我自己现在做压力测试更多采取的做法是以上三种方法的合集。
在确定了测试方法后，就基本可以确定压力测试的环境了，环境确定好后需要做的是压力测试的案例或场景了，在压力测试的案例中需要涵盖正常场景以及异常的场景，正常场景是非常容易做出来的，只是需要根据生产环境收集的数据（例如不同级别的用户比例通常是7:2:1）或预估的数据来搭建相应的测试案例，异常场景则是比较复杂的，需要考虑很多的因素，例如数据库出现异常、网络出现异常等，这里我觉得通常的做法是画出正常场景的处理流程，然后划分交互边界的信任边界，对于所有的第三方交互都认为是不可信任，例如不能信任调用数据库是一定会快的，或一定会成功的，在异常场景中应涵盖这些信任边界的异常状况的测试，这些对于高可用性的系统而言是非常重要的，几个9的成败就在此了，^_^，当然，高可用性又是个更复杂的话题，不在这里讲。
在压力测试方案中还需确定的是考评的指标，通过会包括：tps、系统load等等。
进行压力测试
相对来讲，在有了压力测试方案后，这一步并不是什么太复杂的事情，只是需要选择一个和压力测试方案比较符合的工具来执行，例如jmeter、loadrunner等，当然，这些工具相对来说也是比较复杂的，而且之间的差距也是比较大的，至少目前来看，jmeter和loadrunner的差距还是不小的，尤其是需要进行高压力的测试时。
分析压力测试结果
这步同样是压力测试中很难的一步，在这一步需要做出的根据压力测试的结果分析出系统的具体表现情况，判定系统是否能够满足压力指标。
以loadrunner产生的分析结果图而言，通常需要分析以下图：
1、Total Transactions per Second
这张图中显示了系统在进行压力测试过程的TPS的变化情况，从这张图中我们可以看到系统的TPS的情况，通常来讲，随着用户数的增加，TPS应该是呈一定比率的增长的，等增长到一定程度后会达到瓶颈，甚至开始下降，这也是TPS的瓶颈值了，这张图可以帮助我们评估系统的TPS是否符合要求。
另外，在这张图中，我们可以看到系统从什么时候开始出现出错的transactions，从而判断出错率是否在可接受的范围。
2、Transaction Response Time Under Load
这张图非常的重要，借助这张图我们可以分析随着用户数增加的情况下，系统的劣化状况，最佳状况当然是一条直线，但这基本是不可能的，毕竟资源是有限的，需要判断的是劣化的程度是否为可接受范畴。
另外就是需要关注数据中90%的用户的响应时间的状况，如果少量用户响应慢是可接受的话，那么有可能在之上指标不达标的情况下仍然满足了压力指标。
3、Unix Resources
这张系统load图自然是非常的重要，借助这张图大致可以判断系统随着用户数的增长消耗的资源的变化情况，这对于调优以及容量规划而言是很重要的，但还是得取决于应用本身，:)。
loadrunner还提供了其他方面很多的图，可以根据考评的要求来自行进行分析。
寻找瓶颈并进行调优以达到目标
这步不属于压力测试范畴，但还是在这里稍微讲讲，毕竟压力测试结束后如果系统没达标的话就必须进行这步了。
寻找瓶颈，这自然是非常难的事了，通常系统达不到要求的状况都会是随着用户的增长，响应时间劣化的过于厉害，在这样的情况下首先得观察系统硬件资源的变化情况，如果是硬件资源耗尽的话，需要查查为什么资源被耗尽，假设最后判断确实需要耗费这么多的硬件资源的话，也许需要考虑增加硬件资源或是水平扩展，否则的话可能需要从软件层面相应的优化系统了，这样的话可以进入下一步了。
如果不是硬件资源的限制的话，得在系统中从头到尾设置时间跟踪filter，从而判断响应时间劣化的原因，看看是系统中哪些步骤造成的，这个是细致活了，有可能要查非常久。
其实这里说的还是相当的简单了，在寻找瓶颈的过程中是个非常繁琐的过程，需要不断的尝试，硬件的增加、OS的调优、jvm的调优以及软件系统本身的调优等等，这些很多时候需要的是经验，因此某知名人士曾经说过如何寻找瓶颈和调优，其中依靠的一点就是直觉，^_^。
当然，在寻找瓶颈的过程中，可以借助os的工具、java的工具（例如gc打印、jprofiler等）来进行查找。
（ps: 不过感觉很多情况下都是应用本身造成的性能瓶颈，在写程序时稍不注意用错一个数据结构都有可能会导致比较大的问题，所以我现在查找瓶颈的时候更多的还是先从软件本身下手，只是软件性能要做到提升通常来付出较大的代价，这个时候需要权衡）
调优基本上要求对硬件、OS、JDK、数据库甚至软件的实现方式等都要有非常深入的理解，至少要能做到判断出瓶颈因素，然后找相应领域的专家来解决，因此要求是非常高的。
关于性能调优的知识体系这里有篇不错的文章：
http://www.cnblogs.com/jackei/archive/2008/06/27/1231307.html
话题太大了，写到最后发现基本上还是有些泛泛而谈了，后面会针对这里的每一步来做更为细致的实例的讲述吧，不过毕竟是外行人，肯定有很多不对的地方，欢迎大家指正、拍砖。
http://www.blogjava.net/BlueDavy/archive/2008/07/25/217514.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-22 15:22:21 | 相关网摘，我也收藏
来源：51Testing软件测试网
项目的开发风险来自于对需求的误解，来自于设计与开发过程及产品的缺陷，只有尽早发现这些缺陷，才能降低并控制项目风险。基于这种思想，软件业出现了一些新的测试思路，主要有二：
1、测试驱动开发（Test-Driven Development，简称TDD）。这种测试思想被最近流行的XP（Extreme Programming）极限编程方式所大力提倡。它的基本思想是，通过测试来为编程做指导，在某个要开发的需求对象明确之后，在编码之前，先进行相关测试代码（测试代码的内容和需求规格说明书描述是相同的，有人把它称为“可执行的需求规格说明书”）的编写工作，完成之后针对测试代码进行编程，然后再用测试程序对开发代码进行测试，验证其正确性，若程序通过了测试，就说明它是符合需求规格说明书要求的。周而复始，通过这样的过程，开发进程得以层层深入，直到开发完成。而这时单元测试也基本完成了。
这种测试方式的最大的好处是，尽早地发现设计、开发中存在的问题，避免传统开发模式中的“测试过程中发现代码不能满足需求而导致的大量返工”。降低项目风险；同时可以尽早地将“半成品”展示给客户，使客户对需求进行验证、补充及完善，另外测试代码的表达方式相对准确、无二义性，可以降低因需求理解错误而导致的项目风险。
2、迭代测试。这种测试是IBM所推崇测试方式之一，它从迭代式开发模式演变而来。在迭代开发模式中，每个迭代都包含需求、设计、编码、集成、测试等过程。在每一次迭代完成之后，便会开始新的迭代过程。通过一次次迭代的累进，系统会增量式集成一些新的功能，直至整个系统功能的完成。其中，每个迭代周期的测试工作由两方面内容构成：
• 对当前迭代周期产品的增量测试。
• 对前迭代周期已完成功能的回归测试。
随着迭代周期的累进，测试工作内容随之不断变化。早期迭代测试重点在于新功能的测试，后期迭代测试重点在于累积功能的回归测试。
有的人不喜欢XP编程的开发方式，认为其没有明确的阶段性划分，不利于计划管理，模式过于灵活，不好掌握。迭代式开发模式为这些人提供了新的选择。这种开发方式继承了瀑布式开发模式的优点――全面、严谨、有计划性、易管理，更重要的是，这种模式将测试工作分布到每个迭代周期中，使测试工作提前进行，从而使将发现软件缺陷的周期提前，大大降低软件风险及开发成本。
它将软件开发比喻成制作一桌盛宴，项目经理比作大厨，测试人员比作品尝师，用户则比作就餐者。为保障饭菜质量，上菜之前，先由品尝师对满桌的半成品、准成品逐个品尝，发现不足的地方要及时通知大厨进行改进，完善质量，直至品尝师觉得：全部的饭菜已经色、香、味俱佳，满足用户要求了，才通过审查，允许饭菜上桌，供就餐者品尝。我想说的是：饭菜质量靠品尝师的监督，但主要靠的是大厨的技术，同理，软件的质量则是靠各个项目管理过程的互相配合及项目经理的整体控制和把握，测试只是其中的一份子。所以，请不要将软件的质量都交给测试过程来承担，那样将是“生命不能承受之重”。
http://www.51testing.com/html/200807/n88394.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-22 14:52:59 | 相关网摘，我也收藏
来源：中国IT实验室
摘要:我提倡使用最小化资源的方式做一次压力测试，排除大部分浅显的应用问题。最小资源的意思，即在pc环境，使用应用可以运行的最小资源状态下，进行压力测试和性能问题侦测的工作。
前面看到有人讲j2ee的性能调优，虽然这块不是自己的专长，但是猪养多了，也忍不住跳出来说几句。
虽然几乎每本讲性能调优的书籍开篇都会提，没必要的情况下就不要做调优，但是我个人还是认为，所有系统在上线前，都应该做一次基本的压力测试并对相关的性能问题进行检测， 但是迫于资源压力，很多项目都无法做正规的压力测试，一直到系统上线出现问题，才倒回来找原因。 而正规的压力测试，往往因为需要严格模拟生产环境，需要耗费大量的资源，各类专家配合解决问题，并不是那么轻松的可以做下来的。
而j2ee应用的特点就是以复杂性来回避传统问题，所以任意一个j2ee的部署，相对于php那样的结构都是比较复杂的。系统一旦发生性能问题，必须在程序、数据库、应用服务器、jvm、操作系统几大块中交叉进行考虑，根据实际情况问题，问题的原因可能异常复杂。我们可以想象一个项目，从来不做UT不做IT ，只做一次UAT，然后直接提交给用户上线以后，修补错误的困难度和成本。
经常看到一些调优的最后解决方案，可以肯定，几乎80%以上都是一些低级的程序错误导致的，剩下的20%虽然可能是用硬件，os参数调整等等问题解决了，但是其中很大一块，归根到底也是程序的问题。 而在我们回顾这些错误的时候可以很惊人的发现，大部分都是一些低级错误。
我提倡使用最小化资源的方式做一次压力测试，排除大部分浅显的应用问题。最小资源的意思，即在pc环境，使用应用可以运行的最小资源状态下，进行压力测试和性能问题侦测的工作。这种做法的优点如下。
1. 环境容易搭建， 特别是不需要考虑大型硬件和网络条件等等，也回避了开发人员可能不熟悉unix和特定应用服务器等问题
2. 不需要特别的数据库，操作系统和应用服务器专家配合，开发人员自身即可完成。
3. 不需要特别的依赖os和应用服务器，jvm的监测工具。选择自己最熟悉的即可。
4. 开发人员在熟悉这种过程以后，再转到正式的生产环境工作时也更有经验，更容易解决问题。
对测试过程做一点简单介绍。
工具准备：
得益于开源技术的发展，大部分工具都可以免费获得，使用也比较简单。
1. jvm 监控： 对jvm的运行状态进行分析， 可以使用jvm自身带的特性输出日志，结合hp的jmeter profile进行分析。也可以使用jrockit自带的图形化工具mession control。
熟悉什么用什么，越简单越好，目的主要是观察内存堆的变化，线程资源变化，gc情况等。
2. 数据库监控工具： 熟悉数据库的使用数据库自身的特性，不熟悉的可以使用第三方工具，主要目的是观察数据库的锁，连接数信息， 对于db2我比较喜欢使用quest central。 oracle使用OEM或者自身的数据字典已经可以。
3. 应用服务器监控： 主要目的是记录方法的调用情况和执行时间 ，找出频繁调用的方法和执行时间过长的方法。使用jprobe和jprofile都可以很轻松的做到。 如果使用的应用服务器比较偏门，那么可以换一个支持这种检测工具的应用服务器。反正主要目的只是在找问题。
4. sql执行监控：跟踪找出执行时间过长的sql。 我喜欢使用p6spy。
5. 压力工具： jmeter+badboy , 有条件的可以用loadrunner， 和loadrunner近似的还有一个免费的开源产品。 另外web 应用的话， 也可以使用selenium这样的ff扩展来做。微软vs自带的也不错，反正是什么简单用什么。
6. 记录表格： 对问题和资源配置的变更进行记录和对比。
我发现有些人做压力测试，只用压力工具来跑，不肯用各类proile工具来跟踪应用和数据库使用情况，加上经验又不足，结果测来测去都是瞎猜。
设置：
1. 数据库： 如果未使用连接池， 则尽可能的将数据库允许连接设置成最小数字，推荐是从1开始。如果使用连接池，则设置为1.
随着并发模拟数的增加也可以适当上调，但是一定要低于压力工具模拟的并发用户数。数据库环境尽可能接近生产环境，至少要有足够的测试数据。
2. 应用服务器： 对jvm启动堆做最小化设置。比应用服务器要求的最低内存略高，保证应用可以正常启动即可。根据模拟用户数增加可以小步适当上调，但是以保证应用基本运行即可。千万别来大内存。
3. 压力模拟并发数，从1开始逐步往上加。一次加1，2个，上限不要太高，5-10个足以。
步骤
1. 按1用户1连接的方式进行检测
* 找出系统是否存在明显的资源泄露，比如数据库连接，如果存在泄露此种情况下服务器很容易就hold。
* 找出执行时间过长的java方法和sql。进行分析修改。
* 找出那些调用过多的方法和sql，对程序进行分析，看是否做了不必要的调用。 这个问题尤其在使用了第三方包的情况下要小心，我曾经监测出某人写的东西一个方法间接的调用了数据库操作近200次。
有些人做测试喜欢从5以上的数字开始，实在不是什么好习惯，比较明显的问题都容易回避了。
2. 适当增加并发用户，尽可能不调整应用内存，对系统进行长时间的压力测试，比如2-4个小时。 重点观察是否存在内存泄露问题。 内存泄露的问题比较复杂，有时候还依赖于jvm和os，另外有些内存泄露只能在大并发的多线程环境下才会出现。 但是这种测试可以排除掉一些明显的问题，主要是缓存和队列之类的东西。内存泄露一般jvm会有报错和相关的日志dump文件。
3. 逐步增加并发用户和连接数，观察是否存在sql锁 和线程锁的问题。另外并发情况下也可能存在其他一些资源冲突，比如读写文件的情况等等。
线程情况可以使用监控工具观察，比如jrockit带的mc， 也可以直接dump jvm 内存快照找工具分析。
4. 尽可能增加并发用户数，以当前应用能承担的上线进行长时间测试，比如半天到1天，观察是否会存在内存泄露，是否会存在线程资源消耗的问题。也需要检查一下数据库的连接数情况，看是否会一直持续增加，这说明连接池实现有问题，或者设置过大，也可能是jdbc的问题。
5. 其他： 对jvm 可以使用sun和bea的都对比跑一下， 两个实现情况大不同。 jr大并发支持好，所以可能jr上没问题，但是sun的就有问题了。
大部分的问题应该都可以在步骤1，2能得到暴露。在完成了这样的初步测试以后，正式的测试就省心不少了，如果客户有钱，性能不好也可以直接更新硬件了，省事又创造GDP。
http://softtest.chinaitlab.com/xn/757201.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-22 14:50:14 | 相关网摘，我也收藏
来源：中国IT实验室
测试用例是有一定的分类的。要是没有科学分类的用例，是不便于维护和阅读。
最好按标准写：接口测试用例、路径测试用例、功能测试用例、容错能力、性能测试用例、用户界面测试、信息安全测试、压力测试用例、可靠性测试用例、安装／反安装测试用例。
测试用例与软件质量特性有对应关系。
软件质量特性：
功能性：一组功能（能满足明确的或隐含的需求）及其指定的特性。
适合性：软件能否提供一组功能及这组功能的适合程度。
准确性：能否得到正确或相符的结果或效果。
互操作性：和其它指定定进行交互的能力。
依从性：使软件服合相关的法规、标准、约定、规定的软件属性。
安全性：防止对程序及数据的非授故意／意外访问的能力。
可靠性：在规定的一段时间和条件下软件维持其性能水平的能力。
成熟性：由软件故障引直的失效的频度。
容错性：在软件故障或违反指定接口时，维持规定的性能水平的能力。
易恢复性：在失效发生后，重建其性能水平并恢复直接受影响数据的能力，达到此目的所需要的时间和努力程度。
易用性：用户为使用软件所需作的努力及其对使用所做的评价。
易理解性：用户为认识逻辑概念及其应用范围所需的努力程度。
易学性：用户为学习软件应用所需的努力程度。
效率：在规定的条件软件的性能水平和所使用资源量之间的关系。
时间特性：软件执行其功能时，响应和处理时间及吞吐量。
资源特性：软件执行其功能时，所使用的资源数量及使用时间。
可维护性：进行指定的修改所需的努力。
易分析性：为诊断缺陷或失效原因及为判定待修改的部分所需的努力。
易改变性：进行修改、排除错误或适应环境变化所需的努力。
稳定性：修订所造成的未可预料结果的风险程度。
易测试性：确认已修改软件所需的努力。
可移植性：软件可以某一环境转到另一环境的能力。
适应性：软件无需额外的特殊动作就可适应不同的规定环境的能力。
易安装性：在指定环境下安装软件所需的努力程度。
遵循性：使软件遵循与可移植性有关的标准或约定的软件属性。
易替换性：软件 在该软件环境中平替代指定的其他软件的机会和所需的努力程度。
http://softtest.chinaitlab.com/bug/757200.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-22 14:48:18 | 相关网摘，我也收藏
来源：中国IT实验室
摘要：
测试活动作为IT项目和产品开发一个重要的环节，通过发现产品或组件的缺陷，并反馈给开发组修复验证这些缺陷，从而在一定程度上保证了外发产品的质量。对这些测试活动发现的缺陷进行深入的分析，可以有助于我们进行质量预测、进行过程改进、量化的衡量产品质量。
关键词：
测试分析、过程改进、质量预测、过程能力、缺陷
正文：
项目研发过程中，我们通过单元测试、集成测试、系统测试发现了大量的缺陷。我们把这些Bug输入到Excel或者其他测试管理系统中，跟踪其解决。一旦Bug fix完成后，大多数情况下我们就把这份bug list束之高阁，偶尔能想到的用途就是拿出来衡量测试组的绩效，或者用来评估开发组的质量表现。
一般来说质量分析有以下集中情况
利用缺陷引入-发现矩阵分析
缺陷有发现阶段和引入阶段两个重要指标，发现阶段和引入阶段可以是软件生命周期的各个阶段，根据这两个阶段可以绘制出一个矩阵，从而分析出软件开发各个环节的开展质量，找到最需要改进的环节。
开始例子分析之前先解释一下缺陷引入-发现矩阵的一些概念。
矩阵的每行表示该阶段或活动发现的各阶段产生的缺陷数；矩阵的每列表示该阶段或活动引入的缺陷泄露到后续各环节的缺陷数。
缺陷移除率定义为：缺陷移除率=(本阶段发现的缺陷数/本阶段引入的缺陷数)*100%。如需求阶段一共引入了15个缺陷，需求评审时候只发现了2个，设计过程中发现了10个，编码和单元测试阶段发现了两个，还有一个直到系统测试阶段才被发现。这样，需求阶段的缺陷移除率=2/15*100%=13%。它反映的是该活动阶段的缺陷清除能力。
反过来还有一个概念，缺陷泄露率，就是有多少本阶段引入的缺陷没有在本阶段发现而是被泄露到后阶段环节才被发现。其计算公式为：缺陷泄漏率=（下游发现的本阶段的缺陷数/本阶段注入的缺陷总数）*100%。显然，它等于[1-缺陷移除率]。它反映的是本阶段质量控制措施落实的成效。
下面是一个分析例子：
从上表可以看到，编码过程的缺陷大部分依赖系统测试发现。单元测试和集成测试活动开展不够深入。我们可以进一步分析这些系统测试出来的测试缺陷，是不是可以被更前端的评审/测试/设计讨论活动所替代。详细见“四、利用泄漏的下游缺陷回溯过程有效性”
另外，我们看到，需求阶段引入的缺陷绝大部分是在设计阶段发现的。这可能是我们大部分项目的一个现实，需求不稳定、需求不明确，很多东西需要在设计过程中才能明确下来。也许从这个分析结果中给我们一个启示，我们在设计评审时候，也需要重新审视我们的需求规格说明书，必要时候利用需求追踪矩阵这样的规矩方法来辅助我们发现上游需求的缺陷。把这样的机制固化起来，作为我们标准研发过程的一个要素或者过程指导书。
当然，实际规划“缺陷引入-发现矩阵”时，可以依据自己的管理要求，对缺陷的发现活动和引入阶段进行细分或初分，并且在Bug系统中提交时，需要准确的填写这些属性字段。
利用缺陷的分布进行分析
可以选某个阶段的测试缺陷进行分析，按照这些缺陷对应的产品组成部分来汇总这些数据。利用这样的分布，可以找出我们产品/项目的高危模块来。这些模块导致了我们产品的主要缺陷。主要用到的分析手段是数据透视表和柏拉图。让我们看看下面的例子：
这是一个简单的OA系统，它只有5个子系统。我们把这些子系统各有多少缺陷列出来，找到了改善质量的关键模块是后台交易模块。
像上图，这是一个较为复杂的MIS系统，有近20个功能块。这个时候，可以利用柏拉图识别出占80%问题的那少数模块，针对其采取强于其它产品组成部分的质量控制措施。
需要指出的是：采用缺陷分布只是分析的第一步。它只不过提供了你分析影响产品质量的那些重点模块，其信息不足以给出更深层次的原因。需要针对这些高危模块进行进一步的分析，识别缺陷的产生根源。
当然，也有人认为绝对数去衡量缺陷的分布并不合适，所以有些人也会把缺陷按照严重程度对应一定的权重系数折算成分析意义上的标准故障。如上表，折算系数为，严重*10，关键*5，一般*3，次要*1，优化*0。
这种分析需要我们的bug系统建立产品组件的概念，使得缺陷填报人能够正确的填报每个缺陷的产品组件位置。
利用缺陷的阶段分布模型进行质量预测
假设我们为bug管理系统建立了“一、利用缺陷引入-发现矩阵分析”中描述的缺陷引入-缺陷发现阶段信息，那么我们可以对相似的项目的缺陷阶段分布进行度量，形成该类型项目的缺陷分布的过程模型。它给予我们的信息是：只要是这种类型的项目，按照相似的过程方法进行研发，那么其质量表现也是相似的。
我们之所以作这样的假设，是有一个前提，就是我们研发过程是高度一致的，并且过程的表现也是稳定的。这样，我们得出的过程能力模型才具有可信度。
下面是一个如何运用测试分布模型进行质量预测的例子：
如果需求阶段发现了10个缺陷，就可以预计到设计阶段我大概要清除70个缺陷，依次可以估计到后阶段各个环节的缺陷数，作为我们该阶段工作的交付准则。并且，可以预测到产品发布后的使用表现会出现大约2个故障泄露到用户手中。
这种分析预测模型的建立，要求组织的测试/评审过程比较稳定。即组织整体达到CMMI三级成熟度，同时在VAL和VER（验证和确认）过程域的达到CMMI四级的成熟度级别，即量化管理级别。
利用泄漏的下游缺陷回溯过程有效性
经验告诉我们，越到后端发现的缺陷，用于问题复现、问题定位和bug修复的时间就越多。那么我们是不是可以在项目研发的更前端发现这些缺陷呢？有什么方式让我们识别项目研发前端哪些活动没有充分投入、或者没有运用合适的工程/技术方法导致这些问题被泄露到下游呢？
其实，我们有很简便的方法可以达到这个目的。从团队的典型项目中运用一定的抽样原则抽样出某个阶段的若干个缺陷，从技术、流程、工程方法、费效比方面去分析其更适合、更经济的清除方法。然后把这些方法固化到我们日常的项目实施过程中，逐步就可以降低上游对后端的缺陷泄露。
下面以对一个项目的系统测试阶段发现的故障为例进行过程有效性回溯分析：
从上表可以看出，真正需要遗留到系统测试阶段才能发现的故障只有7%，大部分故障应该在集成测试和设计评审过程中就应该发现的。
导致在集成测试过程中未能充分发现这些缺陷的原因主要有：
1、测试环境不具备，导致部分测试项必须到系统测试阶段才具备测试条件；
2、测试设计中某些测试项的缺失，需要加强测试设计的评审工作；
3、回归测试过程中，开发部只是对测试故障进行验证，而对bug fix波及的范围缺乏分析和验证；
这样，针对这些分析结论，我们就可以制定针对性的整改措施。如：
加强开发部的故障波及分析及波及分析验证工作；
项目计划中加强对测试需求的关注，提前采购和协调必要的测试环境；
每次回归对泄露的缺陷开发部都作相应的复盘，并根据复盘结果，完善单元测试和集成测试的测试设计；
利用缺陷分类来进行缺陷的根源分析
对于测试出来的BUG进行缺陷分类，按照BUG的类型分布，找出那些关键的缺陷类型，进一步分析其产生的根源，从而针对性的制定改进措施。
下面以一个项目的系统测试故障为例进行分析：
从系统测试故障来看，有较多故障是由接口原因造成的，细分有以下几种原因：
1、跨项目间的接口，接口设计文档的更改没有建立互相通知的机制，导致接口问题到系统测试时候才暴露出来；
2、部门内部跨子系统的接口，由于本项目设计文档按功能规划编写的，而不是按照产品组件，一般由主要承接功能工作的组编写该文档，接口内容可能不为其他开发组理解并熟悉，导致因接口问题而出错；
3、系统设计基线化后，更改系统接口，没有走严格的变更流程，进行波及分析，导致该接口变更只在某个子系统中被修改，而使错误遗漏下来；
那么我们可以针对性的制定改进建议：
1、对接口文档的评审一定要识别受影响的相关干系人，使他们了解并参与接口设计的把关；
2、对基线化的接口设计文档的变更一定要提交变更单给ＣＣＢ决策，并做好充分的波及影响分析，以便同步修改所有关联的下游代码；
3、概要设计文档按子系统规划，详细设计文档按模块规划，通过相关组参加评审协调接口设计；
以上例子的缺陷分类只是为了描述方便，本身描述并不尽合理。实际定义缺陷分类可能有很多个维度，如发现活动、引入活动、缺陷来源、缺陷类型、严重程度等。只要满足自己的缺陷管理、缺陷分析需求即可。
缺陷收敛趋势分析
项目管理中一项非常重要但也十分困难的工作是衡量项目的进度、质量、成本等，统称为项目的状态，以确定项目是否能按期保质完成。这方面，测试提供了两个非常重要的参数，一个是缺陷数量的趋势，另一个是缺陷修复的趋势。（注：此节所说的测试均指代系统测试）
缺陷趋势就是将每月新生成的缺陷数、每月被解决的缺陷数和每月遗留的缺陷数标成一个趋势图表。一般在项目的开始阶段发现缺陷数曲线会呈上升趋势，到项目中后期被修复缺陷数曲线会趋于上升；而发现缺陷数曲线应总体趋于下降；同时处于OPEN状态的缺陷也应该总体呈下降趋势，到项目最后，三条曲线都趋向于零。如：
项目经理会持续观察这张图表，确保项目健康发展，同时通过分析预测项目测试缺陷趋于零的时间。在一定的历史经验的基础上分析使用这一图表会得到很多有价值的信息，比如说，可分析开发和测试在人力资源的配比上是否恰当，可以分析出某个严重的缺陷所造成的项目质量的波动。对于异常的波动，如本来应该越测试越收敛的，却到了某个点，发现的故障数反而呈上升趋势，那么，这些点往往有一些特殊事件的发生。如：
在该时间段送测的回归版本增加了新的功能，导致缺陷引入；
该回归版本开发部没有进行集成测试就直接送测？等等。
当然，这个统计周期也可以根据我们的项目实施情况进行。如按照回归版本的版本号进行统计、按周进行统计等。也有公司把缺陷收敛情况当作判断版本是否可以最终外发的一个标志。
小结：
通过对测试缺陷分析，能够给予我们很多改进研发和测试工作的信息。
当然，这种分析来源于一个前提，我们需要规划一个好的Bug管理系统，满足我们这些分析的信息需要。另外，我们的研发过程是稳定的，其质量表现大体是一致的，这样数据反映的趋势才具备可信度。
http://softtest.chinaitlab.com/qxian/757066.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-22 14:43:41 | 相关网摘，我也收藏
来源：中国IT实验室
通常大家发现软件缺陷时会对软件缺陷进行分类，可分类的方式只有一种，就是严重极别,难道没有其它的分法吗。比如我们碰到下面这种情况，测试人员发现有一种功能是必需加入进去的，这时他与程序员说，程序员说没有时间或是不必要，这时这种情况则会形成两者的扯皮，最终的结果也就不了了知了，这样会戳伤了测试人员的积极性，下次他们再也不会尽心的考虑产品的问题，只要可以运行就可以了。其实这种情况是可以解决的,下面我会提到一个新的软件缺陷分类概念，从而有效的解决这个问题。
在软件缺陷中不仅仅只是严重极别，更多的则是功能没有做到。说到这里也许大家都理解了，就是需求没有考虑到，可需求不会一次就很完美的，需要大家的共同努力，来不断的完善。那么怎样才能让测试人员提出的好的建议得到有效的执行？这就是我下面想说的。在软件缺陷中还有一种分法，跟据缺陷内容来分，主要分为需求Bug与程序Bug，对于这种分法的好处就是明确了Bug处理的责任人。对于程序Bug我们都知道是由相关开发人员进行处理。下面主要讨论一下需求Bug,需求Bug从名称上来就知道是要交由需求人员进行处理，可怎么处理，怎样在处理的过程中有效的让这些创意得到体现。现在我们都有Bug管理系统，这时我们的测试人员将需求Bug不是提交给程序员，而是提交给需求分析人员，由他们进行处理，不过这里我想强调的是对需求Bug的定位，如果这个Bug在软件需求说明书中明确提到了，这时就不可能定位它为需求Bug，它是必需让程序员实现的，称为软件功能缺陷，提交由程序员进行处理。但如果需求说明书没有明确提到的，我们则可以定位为需求Bug，处理的流程如图。
图1
这样处理有以下好处，首先需求Bug再不象以前，没有人进行确认，需求的处理人员本来就是需求人员，由他们确认与跟踪是最好不过的，因为他们对需求有绝对的权威。同时测试人员其实就是最早的用户，他们的需求就是用户的需求，这种方法加强了需求人员与测试人员的沟通，使需求得到有效的补充，从而让产品更加完善。还有测试人员从本质上来说与程序员还是对立的，这里如果为了这样一个不是软件本身问题的问题形成与开发人员的对立，则会出现赢得战役而丢失整个战争的情况，测试人员协调好与开发人员的关系，让他们更有效的对软件本身的缺陷形成有效的关注是最好的。还有最为关键的一点，测试人员的激情是最重要的，如果他们的想法没有得到体现，这时会渐渐的失去对测试的兴趣，从而软件的质量则会无法得到保证，通过这种方法可以让他们看到自己的建议可以通过对需求人员的反映得到实现，让他们时时觉得自己的想法是可以通过这种方法来有效的推行，这样工作的积极性才会有保障。
不过从实施的角度来说，还是有一定的困难的，首先要让大家改变以前那种凡是Bug就是由开发人员负责的观念，其次需求人员的工作量要加大，不过广泛的了解需求是他们的本份工作，想来不会很困难，还有必需要有有效的Bug管理工具，比如BugManage等等，不要出现那种对需求人员说了，可过两天就忘的情况出现，这时需求Bug的生命周期会出现跨越两个软件开发周期，因为有些需求会在下一版实现，这时测试人员需要延长对这些需求Bug的管理，不过我想这些需求是他们提出的，会有兴趣对这些Bug进行管理的。
http://softtest.chinaitlab.com/qxian/757072.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-21 15:44:38 | 相关网摘，我也收藏
来源：中国IT实验室
大型本地化软件测试需要进行充分的测试准备，需要科学的测试流程管理。为了跟踪和控制测试质量，便于管理测试发现的Bug，需要为每一个测试项目配置一个专用缺陷跟踪数据库，以便报告、查询、分类、跟踪、处理和验证错误。
为了保证发现和报告的错误质量，需要首先由经验丰富的测试人员，在缺陷跟踪数据库中对新发现的错误进行确认，如果确实属于错误，再由错误修复工程师进行修复处理。
1、软件错误的状态
*新错误(New)：测试中新报告的软件缺陷。
*更多新信息（New More Info）：错误修复工程师认为报告的错误信息不完整，要求错误报告者添加更准确的错误信息。
*打开 (Open)：错误被确认并分配给相关错误修复工程师处理。
*拒绝(Declined)：拒绝修改缺陷。包括两种情况：
*拒绝-不是错误（Declined-Not Bug）：报告的错误不术语错误。
*拒绝-重复（Declined-Duplicated）：以前已经报告过这个错误，需要指出已经报告过的错误标识编号。
*修正(Fixed)：错误修复工程师已完成修正，等待测试人员验证。
*重新打开（Reopen）：没有正确修复的错误，需要进一步修复。
*延期(Deferred)：不在当前版本修复的错误，以后的版本修复。包括两种情况：
*延期-下个版本（Deferred –Next Build）：本项目的下一个新版本修复。
*延期-下个主要版本（Deferred –Next Main Release）：本项目不修复，本软件下一个项目的版本修复。
*关闭(Closed)：错误已被修复。
2、Bug管理的一般流程
测试人员提交新的错误入库，错误状态为New。
高级测试人员验证错误，如果是重复报告的错误，则设置为Declined-Duplicated状态，并指出与哪个已经报个错误重复（注明标识编号ID#）。否则，如果确认是错误，分配给相应的修复工程师，设置状态为Open。如果不是错误，则拒绝，设置为Declined-Not Bug状态。
错误修复工程师查询状态为Open的错误，如果因为错误的信息不完全，没法重现错误，则设置状态为New More Info；如果不是错误，则设置状态为Declined-Not Bug；如果是错误则修复，设置状态为Fixed。对于当前版本不能解决，准备本项目的下一个新版本处理的错误，要留下处理注释，设置错误为Deferred –Next Build状态。如果只能在软件的下个新项目才能解决，要留下处理注释，设置错误为Deferred –Next Main Release状态。
对于不能解决和延期解决的错误，不能由软件修复工程师自己决定，一般要通过某种会议（评审会）通过才能认可。
测试人员查询状态为Fixed的错误，然后验证错误是否已修复，如果已经修复，设置错误的状态为Closed，如没有解决置状态为Reopen。
下面以一个错误的处理过程为例，给出一般的处理流程图。
3、软件错误流程管理要点
*为了保证错误的正确性，需要有丰富测试经验的测试人员验证和确认发现的错误是否是真正的错误，测试步骤是否准确、简洁、可以重复。
*软件错误的确认并不总是轻而易举的事情。由于对软件设计具体要求的不了解，对测试报告的个别软件错误，可能无法确认是否属于真正的软件错误，本地化服务商需要与软件供应商交流并确认。
*每次对错误的处理都要保留处理信息，包括处理者姓名，时间，处理方法，处理步骤，错误状态，处理注释等。
*对错误的拒绝不能由程序员单方面决定，应该由项目经理，测试经理和设计经理共同决定。
*对错误延期处理不能由本地户服务商决定，应该由软件供应商决定。
*错误修复后必须由报告错误的测试人员验证后，确认已经修复，才能关闭错误。
http://softtest.chinaitlab.com/qxian/757073.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-21 15:40:39 | 相关网摘，我也收藏
来源：中国IT实验室
1．引言：
生产软件的企业安排很多人来测试它们的软件产品。测试的目的就是发现bug（缺陷，defect）以便修正它们。正常情况是尽快处理可能的bug，从而减少修正bug的成本。因为，众所周知，bug越早被发现并修正，所消耗的资源越少。
问题是在很多情况下，由于修正已发现的bug，测试过程不得不停顿下来。
那么，以目前正忙于软件产品测试的同样资源来促进组织长期的质量目标不是更好？为了做到这一点，我们应该尽快地提前发现可能的bug。就像克劳士比（Philip Crosby）几年前所说的那样，我们应该努力预防bug，而不仅仅是修正它们。这就是真正的质量。
2．目标：预防bug
预防的重要性
正如我们所知，bug应该尽早地在开发过程中被发现。修正处于开发阶段的产品的bug的成本远远低于修正处于QC（Quality Control，质量控制）阶段的产品的bug，而相对与修正已经发布给客户的产品的bug的成本更是可以忽略不计。原因就是当你修正一个bug的时候，相当于把你之前做的事情重做一次。因此，越晚修正bug，你所重做的事情就越多。如果bug修正是在产品测试之前，那么重做的工作只有代码实现。如果bug修是在测试阶段，那么重做的工作就包括代码实现和测试。另一个导致成本增加的因素是依赖的组件和流程（process），随着项目的进行，产品依赖的组件和流程也会随之增加。
接下来，从另一个层面来讨论这个问题。如果bug发现和修正越早，开发成本越少，那么在第一时间就避免bug引入是不是成本消耗得更少？如果bug可以被完全预防，那么在开发过程中就不会出现重复工作的情况。这个被克劳士比极力推荐的观点非常有意义，而且在很多情况下已得到严密的证实。然而，并不是所有的生产软件产品的组织都试着去避免bug。它们花费了大部分的精力在产品发布给客户之前发现和修正其中的bug。在某些情况下，软件企业并不试着去达到这样的目标。在产品发布之后，企业通过迅速修正产品中的bug来处理客户的抱怨。这是因为，这样的企业始终处于“问题解决模式”，它们并不试图发现问题的根本原因，而只是把局部的大火扑灭。
这种模式并不仅仅导致重复工作直接带来成本的增加，而且会带来一个长期效应，而这将影响企业的业务。首先，发布带有bug的产品将给企业的声誉造成影响，并可能造成对潜在客户的影响——他们在是否建立合作关系上拿不定主意。另外，由于企业需要资源来不断解决现有产品中的问题，那么开发新产品的资源势必减少。
对很多人来说，零缺陷的软件产品似乎是不切实际的。我们总是听到软件开发者说：“软件永远有bug”。产品进入QC阶段时含有bug并不奇怪，因为我们“期望”开发人员制造bug。不幸的是，发布一个包含很多bug的产品给客户仍然不令人感到惊讶。甚至连客户本身也不再感到惊讶。
事实上，每个软件企业都可以通过一些简单的方法，在不增加任何额外资源的情况下预防bug。bug预防在于一个简单的道理：最好的方法是适当借鉴我们自己的经验。
今天的发现就是明天的预防
为了能够预防bug，我们必须首先了解bug的来源。软件bug可以分为几个类别（可能相互之间有所重叠）。第一类bug可能是随机的，它们通常是因为一时的疏忽造成的。尽管这些bug可能由于其随机性很难预防，但是，适当的分析将有助于避免这些bug。
另一类的bug来自于需求的误解、开发环境的错误或者纯粹由于缺乏解决问题的相关技术。这类bug共同的特点是都来自于开发人员。除非被发现，否则这些bug将一直存在。例如，一个还不完全理解需求的开发工程师在单元测试阶段可能无法发现这些问题，只有当产品被其他组织（如QC组）测试时才会发现产品实现与需求不一致。这使得在前期避免类似问题的出现更加重要。
一个好消息是，软件中的bug往往倾向于重复出现，即使是一个随机出现的bug。软件bug的不断出现不仅表现在同一个开发人员的工作上，而且表现在一个项目甚至是企业的层面上。这当然不是说公司中的每一个开发人员都会犯同样的错误。但是，至少其中一些的错误足以成为经常性出现的问题。所以，为什么我们认为重复的错误是一个好消息？因为可以预见的bug更容易预防。事实是我们可以找到一些常见的问题，并采取相应的措施去预防它（或至少减少类似错误出现的次数）。
人为bug的子集？那么这些bug被预防的可能性更大。域bug？域bug和产品的问题域或解决方案域紧密相关。这样的bug有更大的机会重现，因为开发人员、项目组甚至企业不断地在这个域上工作。
现在的问题是如何预防各种bug的产生。基于这次讨论的目的，我建议我们设定一个更加实际的目标。让我不要考虑完全预防某个bug，而是将目标设为——预防我们已经知道有一定可能性产生的Bug。这意味着我们可以通过我们各种发现bug的活动来促进将来的bug预防。当某个bug被发现时，我们就有了一个很好的机会来阻止类似问题的发生。
前提：记录bug
前提条件是持续跟踪发现的bug并正确地记录它们，离开了这个前提条件将不能将bug发现作为一个工具来预防bug。不论你使用bug跟踪系统,还是只手写了一个报告总结测试的结果，重要的是保存这些数据以便用于后来的分析。
在分析bug时，bug记录的问题值得注意。bug的定义越广泛，bug分析的数据越有用。报告bug的测试人员应该明白这一点，并不限于狭义上的bug。可能的话，测试人员应该运用他们的经验对bug产生的原因做最初的假设。我们将稍后在阐述分析过程时讨论这个问题。
和记录bug同样重要的是bug分析的第一步。仅仅跟踪过去的bug不能预防bug的发生，因为许多不同的bug可能来源于同一个核心问题。不同于信息收集，适当地分析bug的原因对bug预防非常有用。
3．缺陷分析
目标
在上一节，我们说明了bug分析的理由。如上所述，最终目标是预防bug
而不是修正它们。然而，我们可以定义一个重要的子目标，这就使不断提高整个开发团队（包括QC组）的技能和实践经验。当然，这两个目标是息息相关的。离开了不断的知识累积，也不能实现bug预防。不过，我觉得有必要提及这个子目标以强调持续性的过程。bug预防并不是一个不切实际的目标。但是，你不能期望它在一夜之间发生。你应该为开发小组提供教育和知识，以使他们逐渐改善他们的工作。
策略
本次讨论的焦点——bug预防策略非常简单和容易实现。秘诀就是使用在大多数开发环境中已经存在的过程元素。我们不会介绍任何新的花费昂贵的活动，也不会引入一些新的角色到开发过程中。
我们的策略是发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。
分析过程
(1) Bug发现和初步分析
如前所述，bug分析的第一步是发现bug。然而，发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码，QC工程师就可能推测出bug的根本原因。
我要强调是下面这个短语的本质：bug的根本原因？bug的根本原因并不是产生这bug的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。
让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下，应用程序尽管没有Crash，但是会停止响应。正常的QC过程是，这个bug被记录在bug跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个QA工程师熟悉源代码，就可以进行bug产生原因的初步分析。例如，这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex，从而造成了冲突。这些分析可以记录在bug的详细说明中，作为bug分析的一个基础。
(2) Bug修订和进一步分析
一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。
除了修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。
在线程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放mutex（注：Mutal Exclusion = 互斥锁，保证了共享数据不会同时被多个线程访问，只向一个线程授予对共享资源的独占访问权）。反之，开发人员应该找出没有释放mutex的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代码。
这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放mutex。但是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮助在将来避免类似bug的发生。
(3) bug预防分析
分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员。
这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中，可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践 （不一定适合所有编程语言）可以指导开发人员用一个类（class）封装资源, 这样构造(constructor)函数容易分配和而与析构(destructor) 函数释放资源。如果遵守这样的约定, 当程序结束这方法时，不管控制路径是怎样的，资源（上述例子中获得的mutex）总能被释放。
Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体问题的投入将很容易被收回。
非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时，这样的bug是随机产生的，但是类似bug产生的几率却非常高。所以，尽管这一类bug是随机的，但仍然可以被预见并防止发生。
(4) 发布经验
分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。
如果不将分析结果传达给组织内相关的其他人员，那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它，并鼓励他们这么做。
Bug分析实例
让我们研究另外一个例子，以便更好地理解bug分析的益处。在这个事例中，QC工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析，但这个QC工程师并不满足于这样的分析，进一步研究了相关的代码，发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中，而这个数组有时候显得太小了。
和线程同步的例子一样，QC工程师的初步分析带来了很大的价值，开发可以更容易的发现和修正这个bug。此外，记录缺陷的真正原因而不是表象，将帮助其他人避免类似的bug。
接着，开发人员开始修正这个bug。当修正的时候，她不仅记录了解决措施，并说明了导致缺陷产生的原因。在这个例子中，造成bug的原因是在操作未经处理的C/C++缓冲区时，没有经常检验缓冲区的大小是否不够。然而，这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以，在分析的最后阶段，开发人员在组内更资深的开发人员的帮助下，得到了下面的实践经验：避免使用未经处理的C/C++缓冲区，尽量使用安全的collections和strings，如标准模版数据库中提供的可用collections和strings。这样就完全可以避免前面发现的这个bug。
益处
Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验，并使他在将来避免类似的错误。有时，只修正一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。
更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生，这样的知识在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。
从更一般的角度来看，发布最佳实践（如bug分析总结的实践）促进了组织内成员的学习和自我提高。这样看来，Bug分析的价值还不仅仅是缺陷的预防。
另一个好处是通过从更广的角度上记录bug，组织内的其他QC工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验，bug分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的bug。所以，就算缺陷没有被完全预防，也能更容易被发现。
作为上面所有好处的结果，QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生，而且QC都有更好的技术来发现类似的bug，就有了更充裕的时间来进行更高级的测试。当然，组织所生产的产品的质量也将得到提高。
最后，我想强调的是bug分析不仅收集了执行中的问题，而且从这些问题中总结了实践经验。举例来说，导致一个bug产生的原因可能是需求不够清楚。这样，通过bug分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管QC工程师开始验证开发人员的实现结果，但是还需要改善开发流程，如需求收集、设计流程等。
4．总结
真正的质量是生产没有bug的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以，第一步就是防止相同的bug再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个bug提高整个组织的实践经验。
通过深入产品分析一个bug，我们可以明白这个bug的机制：为什么会产生？如何去预防它？下一次我们如何更容易地发现它？只要花一点时间去理解我们的bug，而不是仅仅是尽快修正它，我们就可以从中得到经验。这样，因为一个缺陷所浪费的时间也可以转化为投入：确保类似的错误永远不会再发生。
http://softtest.chinaitlab.com/qxian/757065.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-21 15:37:02 | 相关网摘，我也收藏
来源：中国IT实验室
很多朋友都问我，为什么那么喜欢研究bug报告，其实个人一直觉得bug报告高于一切，它是测试人员价值的终极体现。也许是工作的性质，我经常将香港的同事和深圳同事做比较，发现他们一个优点特别值得我们学习：做什么事一般不会去衡量事情的最终利益，更多的是决定后考虑如何更好地把事情做好。
脚踏实地，希望我自己也能够这样努力下去。
·尽量减少重现的步骤以达到用最少的步骤来重现问题；这对编程人员来说是很有帮助发现问题根源的。
·最好由报bug的人验证bug是否可以关闭。任何人都可以修复bug，但只有那个发现bug的人才能够确信bug是否真正的已被修复。
·在将bug解决时要分清楚解决的方式。一般的bug系统允许你通过例如“fixed(已修复)”, “won't fix (不打算修复)”, “postponed(以后修复)”, “not repro(不可重现)”, “duplicate（重复）”或“by design(设计如此)”方式来解决bug。同时最好写上解决的方式或非正常解决问题（如以上几种类型）的原因。
·当你的bug报告以“not repro(不可重现)”打回给你时，先检查一个步骤是否有遗漏或清晰，再去找编程人员。编程人员通常是在无法用bug报告中的步骤重现bug时才选择这个选项。
·仔细地追踪版本信息。你给测试人员的每一个build都应该有一个build ID编号，这样刚入门的测试人员就不会重新测试压根就没有修复的那个版本。
·如果你是个编程人员，并且正陷入让测试人员使用bug管理库的苦恼中，你只要不用其他方法接受bug报告。如果你的测试人员习惯将bug报告用邮件的形式发给你，你只需用一个简短的消息回复他们：“请将它们输入到bug库中，因为我无法追踪邮件。”
·如果你是一个测试人员，并且正陷入让测试人员使用bug管理库的苦恼中，你只要不和他们说任何有关bug的事――将bug输入到数据库中，数据库会自动发送email给他们。
·不要添加太多的新字段。有些人喜欢添加一些新的字段来追踪他所需的信息。试想一下，测试人员要花多长的时间去填写一个几十个字段的表单，而且又有多少人还愿意填写下一个bug呢。
·如果知道bug出现模块的负责人员或将解决bug的开发人员，请在标题中明确的指出，例如你发现的bug是有关增加人员的，那么在标题中可以指出“增加人员时出现xx错误”。
·如果用英文报bug，最好使用现在时或过去时，例如用"appears"而不是"will appear"。
·不要使用完全的大写形式，那样会让人感觉象控诉。不要使用感叹号或其他表现个人感情色彩的词语或符号。
·不要使用含糊的词语（例如，好像，似乎）来描述发现的现象。
·请考虑如下问题：
1.同一软件中的相似功能是否有相同的问题？
2.其他的浏览器是否有相同的问题？
3.其他的软硬件配置是否有相同的问题？
4.其他的区域（locales）是否有相同的问题？
5.不同的安排设置是否有相同的问题？
6.以前的版本否有相同的问题？
·编写bug report没有什么定式，没有绝对的范本，最基本的是能够让客户或目标修改，浏览bug report人员看懂，而且在短时间内，而不需反复思考的。其他有时要考虑目标读者的一些喜欢。例如有些类似的bug到底是合并还是单独提交，bug的步骤划分（到底是每一步都为一点，还是有些点可以合并）。在这一点上我觉得“灵活和适应”是很关键的。
·在发现一个Bug并填写完bug report之后，在review的时候，需要特别注意的一点是：这个bug report会不会让其他人还有联想或发挥的空间。一个好的bug report是不可以细分的, 换句话说就是这个bug是不会让他人觉得你还有些地方需要在测试一下，或许还有其他的问题。例如，有个测试人员发现在输入16这个数字（允许范围内）且提交时系统会返回一个错误：不能输入48以下的数字。这确实是一个错误，但是如果就只按现在的步骤提交，另一个可能会有这样的想法：是不是输入48以下的数字都会有这样的问题呢？这样他有可能要求你在测试其他的数据。这样就延长了这个bug的生命期，而且浪费了大家的时间。
http://softtest.chinaitlab.com/qxian/757068.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-21 15:31:12 | 相关网摘，我也收藏
来源：51Testing软件测试网
每年春夏之际的多场大型招聘会往往成为当年才市的风向标。在近期举办的多次大型招聘会现场不难发现：软件工程师的需求量仍然居高不下，且软件测试工程师、咨询工程师等行业继续走强，部分用人单位甚至对应聘人数也不加限制，符合条件即“来者不拒”。
据调查数据显示，目前国内120万软件从业人员中，真正能从事软件测试职位的不超过5万，而软件测试人才的缺口已高达30多万。几乎所有的IT企业均不同程度地存在测试人才的缺口，软件测试工程师成为了亟待补充的关键技术工种之一。在近期的多场大型招聘会上，IBM、百度、华为、惠普、盛大网络、联想集团等国内外大型IT企业均表现出对成熟软件测试人才的期盼，而微软、三星、西门子、思科、华为3COM等多家国内外IT巨头则相继在全国各大高校招兵买马，并把软件测试人才的招聘放在了突出的位置。
鉴于今年大、中型企业对软件测试人才需求的持续升温，沪上知名软件测试培训机构51Testing年初在北京开设分公司，并在上海继续扩大招生规模，从原来的月均培养30名合格软件测试工程师，增涨到月均培养60－70人，但是对于企业用人需求来说这样的数字只是杯水车薪而已，这些学员往往在毕业不到一个月的时间内就会被企业抢购一空。
软件行业资深HR表示，目前国内软件企业中的软件测试人才，一部分来自专业的软件测试培训机构，另有一部分从软件开发转行而来，由于高校没有设置相关专业，刚毕业的应届生很难适应企业需求，而软件测试工程师爆炸性的人才需求增长令大部分的企业都措手不及，造成现在企业无人可用的局面。
与此形成对比的是在此前较长的一段时间内，由于国内软件企业对测试人才的不重视，导致了目前国内软件质量“健康”堪忧，因此如何保证完善软件测试人才的供应体系，从而提高软件质量，将成为国内软件企业持续关注的重点之一。
http://www.51testing.com/html/200807/n88290.html
lizhe1985收录，使用标签：软件测试，时间：2008-7-21 15:30:06 | 相关网摘，我也收藏
来源：51Testing软件测试网
主要是通过测试框架的有无与多少来划分的。
测试框架：是由一些假设，概念和为自动化软件测试提供支持的实践组成的一个集合。
第一代：无测试框架:目录级测试管理
几乎没有起到自动化测试管理的作用，测试需求与测试用例的关联非常弱，若要成功的实施自动化测试，需要自己编写许多的小程序来支持，对自动化测试人员的编程水平以及对测试方面的整体把握要求非常的高。
第二代：部分的测试框架
可以完成部分的自动化测试管理，已经可以实现对于测试用例的管理，缺陷跟踪，也有了面向业务流的概念，但若要成功的实现自动化测试还需要一些自己编写一些小程序来支持工具的运行。
第三代：完整的测试框架
1. 基于完整的BPT的测试框架；
2．拥有数据场景管理；
3．企业级的面向工作流的缺陷管理；
4．业务流复用框架，轻松完成；
5．高伸缩的自动执行框架，可自动分配；
这些特质使得对于有编程基础的和编程基础的测试工程师与业务测试人员都可以轻松实施自动化测试，降低了自动化测试的入门门槛，且为成功实施提供了强有力的保障。
在某些方面使用别人成熟的框架，就相当于让别人帮你完成一些基础工作，您只需要集中精力完成系统的业务逻辑测试。
Test Center就提供了这样的框架,您只需按部就班的完成测试计划,测试需求,业务组件,测试案例,测试集的建立与添加就可以轻松的实施自动化测试.
http://www.51testing.com/?action_viewnews_itemid_87996.html