关注51Testing
如何彻底回归BUG？
发表于： 14:56 &作者：aux0 & 来源：51Testing博客
推荐标签：
　　开发解决了一个BUG，但同时引入了新BUG，人员在回归BUG时没有及时发现，这就叫回归不充分。这种现象不管对开发人员，还是测试人员都是相当痛心疾首的事。该如何彻底解决此类问题呢？有如下建议：　　开发人员：　　1、 首先开发解决问题时，须全面考虑，把更改方案记录来，并作好更改的影响分析，包括此更改对本模块、模块的影响，提出对测试的建议。　　2、 在故障库上的BUG解决说明中附上更改说明及对测试的建议，对测试很有用，时间长了，需要时追溯起问题来特别有用。　　3、 开发人员在修改bug状态的时候，要注明修改了哪个模块的哪些函数，这些信息有助于懂代码的测试人员去分析判断该bug是否真的修复好并对系统产生哪些影响。　　4、 开发改好BUG后，先在开发环境下自行调试，然后安装版本到真实环境下，对更改点进行确认及按更改点影响到的功能点进行smoking 。控制好提交测试的版本，不出现影响测试进度的低级问题，如执行正常功能时失效，死机等。　　测试人员:　　1、 熟悉系统，各模块的关联关系，更改点会影响到的地方作好用户层的影响分析；　　2、 及时更新测试方案与测试用例，严格按用例执行；　　3、 回归与更改点有关的基本功能，用户常用功能或操作；　　4、 在故障库的“验证记录”中列出所有回归的路径及内容（即bug回归路径的测试用例简述）；　　5、 测试人员主动找开发人员、需求人员沟通，加深对系统业务，设计原理的理解，可以就回归BUG的测试点或测试路径与开发一起交流，扩展或缩小回归路径；　　6、 经理或主管对测试回归充分性进行监督与审核（回归不完善可能引发出系统严重问题，,故障库上留下的回归信息也方便项目组其他相关人员分析）。　　以上步骤都已完成，问题不再出现，验证通过，关闭此问题，置“关闭”状态。　　关键点：解决BUG的彻底性，回归BUG的全面性，与解决BUG的开发人员，回归BUG的测试人员对系统业务、软件系统逻辑的熟悉程度有很大关系。版权声明：原创作品，时请务必以超链接形式标明文章原始出处、作者信息和本声明，否则将追究法律责任。本文出自的51Testing软件测试博客：
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道相关文章推荐
A类：致命，基本功能无法实现
手机无法正常开机/关机。Android开发
正常操作时手机出现程序崩溃、死机、重启或者掉电等。
正常情况下基本功能无法正常工作，...
摘要：相信开发人员一定对初级、中级、高级软件工程师这类词汇很熟悉吧！你们是否对编程进行过等级划分？这个又是如何划分的呢？本文作者把编程复杂性从简到难化成27个等级，你同意这样的划分吗？
通常来说...
read uncommitted
--读未提交，解决了更新丢失，产生脏读
read committed--读已提交，解决脏读，修改中的数据不可读，不可重复读。默认级别
...
Android系统会尽可能时间长的来维持一个程序的进程，但当系统资源紧张的时候，系统终究会为一些新的或者更重要的进程杀死一些旧的进程来释放内存。系统主要是根据进程中组件的运行状态，来决定每一个进程的重...
石的颜色(Colour)等级介绍（戴维尼网站）
钻石颜色分为两大系列，常见的无色系列包括无色、浅黄、浅褐色；彩色系列包括深黄、灰色、粉红等。无色钻石色泽通常以美国宝石学院GIA...
他的最新文章
讲师：董晓杰
讲师：姚远
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)相关文章推荐
所有软件开发过程的目的都是为客户（软件产品的终端用户）提供一个解决问题的方案（软件产品），以帮助客户更加高效地工作或生活（从时间和费用上来讲）。一个成功的软件开发过程就是为客户提供了所有他所要求的需求...
Introduction:引言
Bug can bedefined as the abnormal behavior of the software. No software exists with...
本文档定义bug的整个生命周期，规范bug的解决方案及管理流程。Bug在流转的过程中有章可循。 规范bug严重等级与bug解决优先级，使开发人员与测试人员能根据此文档准确判断bug...
1 短信设置
　　（1） 测试项目：短信中心号码 （编辑，删除，修改）
　　（2） 测试项目：语音中心号码 （编辑，删除，修改）
　　（3） 测试项目：状态报告 （开关）
由上图，我们可以看出Android系统架构由5部分组成，
分别是：Linux Kernel（linux内核）、Android Runtime（运行...
由于项目的需要, 在MainActivity中利用ViewPager和FragmentPagerAdapter实现主界面的4个fragment切换, ViewPager 设置setOffscreenP...
他的最新文章
讲师：董晓杰
讲师：姚远
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)关注51Testing
如何高效进行回归测试
发表于： 15:16 &作者：hjjlearning & 来源：51Testing论坛
推荐标签：
　　很久没有写东西了，都是金融危机惹的祸，说说个人想法，最近正在整理一些流程规范的东西，正是需要考虑的部分。　　说到回归测试，可以说每个做测试的人都做过，重复，无聊，消耗时间等可能是大家做回归测试的记忆。也许实施可以解决一部分回归测试，但不是所有的测试都可以自动化，也不是所有的公司都有能力实施自动化，下面写的内容不涉及自动化内容。　　从三方面来讨论做回归测试：　　一、测试流程方面　　一般通用的测试流程都是“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”，贯穿与整个项目，和开发流程相对应。由于本人做游戏测试方面，需求变更对游戏行业来说是很频繁，很正常的，在做游戏行业测试不能和通用流程一样，游戏测试流程应该是螺旋式的，，模块，集成测试，，，压力测试等是测试的一个过程，“测试计划”—“测试设计”—“测试执行/分析”—“测试报告”应该实施在每个阶段，实施在单元测试阶段，实施在模块功能测试阶段等，这样才能达到螺旋效果。而在每一次螺旋测试结束后，实施下一次螺旋测试前都应该进行回归测试，回归测试在螺旋测试中应该贯穿与每个螺旋阶段，而不是只贯穿与项目测试。　　二、测试用例设计方面　　有了上面的回归测试流程计划，下面要实施的就是回归测试的重点——测试用例。在设计测试用例中就应该把回归测试用例考虑进去，可以通过设置用例优先级做为后期回归测试用例的挑选条件，也可以是的。　　测试用例一般在项目中分为三种，单元测试用例，功能测试用例，性能测试用例。　　1、 在不能阶段设计测试用例，挑选回归测试用例是不同的，单元测试用例设计一般选择具有编程能力的测试人员设计，功能测试用例设计选择熟悉业务知识的测试人员设计，性能测试用例设计一般需要与开发人员商讨才能设计。也就是说只有选对设计测试用例的人员，才有可能在后期挑选出好的回归测试用例。　　2、 项目中的拳头功能，亮点，用户大量使用的功能应该是重点保护的地方，这方面可以交给小组核心人员进行设计。　　3、 测试用例设计一定要设置优先级(依靠测试人员个人水平，用例评审等进行设置)。　　三、测试管理方面　　现在的团队都讲究团队精神，可以说，一个测试团队的水平发挥，一半以上可以说和管理的好坏有关，这也就是为什么回归测试会和测试管理有关系了，也就需要一个好管理者来进行管理了。　　1、 单单有计划还不行，还得靠执行，上面的测试流程应该在制定后严格执行，每一轮的螺旋测试后和下一轮螺旋测试之前都应该进行回归测试，如单元测试之后，模块功能测试之前，应该挑选单元测试用例进行回归测试，只有保证单元测试通过才能进入下一轮螺旋测试。　　2、 测试管理人员在测试开始之前要非常熟悉项目，才能在后期安排任务时把不同的测试安排给合适的人选，发挥最大的力量，这就需要管理者具备良好的沟通力和分析能力　　3、 执行测试用例评审——重点模块，亮点模块的测试用例必须经过评审　　4、 回归测试重点地方——BUG修改，关联功能，新增加，修改功能，上一轮测试BUG多的功能。　　5、 做好每轮螺旋回归测试——分析上一轮螺旋测试缺陷，找出缺陷比较多的地方是下轮回归测试重点，需要重新挑选回归用例。　　6、 编写每轮螺旋测试报告——分析缺陷，测试方法等，为下一轮螺旋测试做修改，准备。　　7、 持续改进——每一轮的螺旋测试后都应该分析，计划，团队，用例设计等是否需要改进，做到螺旋测试持续改进。　　脑袋有点乱，思路可能没表达清楚，以后再修改，个人认为回归测试方法不是一成不变的，也应该是持续改进。不同阶段需要的回归测试都是不一样的。回归测试不能仅仅只和测试用例相关。版权声明：原创作品，转载时请务必以超链接形式标明原始出处、作者信息和本声明，否则将追究法律责任。本文出自，感谢会员hjjlearning在每周一问（08-12-01）中的精彩回答。相关阅读：
搜索风云榜
51Testing官方微信
51Testing官方微博
测试知识全知道偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具
偶然性不可重现BUG一般怎么处理？
怎样才能这种ｂｕｇ重现？
我们公司遇到偶然性不可重现BUG竟然视为操作错误！（无赖的苦笑） &
一定要提交！！
1。记得有这么个缺陷，以后遇到的时候可能就会了解发生的原因。
2。尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。
3。程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。
4。无法重现的问题再次出现后，可以直接叫程序员来看看问题。
5。对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大，哈哈。
6。等待想到的时候再接着说。
2楼& notyy
& (notyy) <img ALT="四级用户 该版得分小于等于2000分，大于1000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
感觉只有4可行啊
没法重现就提交会被程序员骂的
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
10:50:09 &得分 0
程序不是测试人员写的，出问题也不是测试人员的原因。
至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。
测试人员的任务只是尽力重现问题，而不是必须重现！！
4楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:02:32 &得分 0
我们公司只要开发人员最大，虽然我们经理说下放权力给我们测试人员，但实际上没有任何权力，只有当客户报的BUG才是真的BUG，他们那些人才会去解决。
提交的BUG，回复竟然是操作错误，晕死了。
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:23:01 &得分 0
下次再遇到的时候，拉他们来看就可以了。
因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。
而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。 & :
6楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:30:12 &得分 0
确实没有什么好解决的，也没有什么好验证的
但是他们老是认为是测试错误就很不是滋味
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:43:02 &得分 0
你可以告诉程序员，测试过程是没有错误的。
测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。
需要让程序员理解，测试人员是帮助他们的，不是害他们的。
客户那里发现问题比测试员发现问题结果要严重的多。
8楼& doublefalse
& (散诸怀抱) <img ALT="二级用户 该版得分小于等于500分，大于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！
我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了
9楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
13:03:26 &得分 0
其实那些厉害关系，他们比我们测试人员知道的还多，但是。。。
但测试过程没有错误，即使是我们测试组的人也不会认同我的（个中理由没有办法说）
10楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
13:07:17 &得分 0
但有时我们的测试环境会被开发人员做编译环境
这也可能影响到重现
11楼& redguardtoo
& () <img ALT="三级用户 该版得分小于等于1000分，大于500分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
对国内的大多数公司来说，只要做到一点就够了。
补上断言！
12楼& sycnick
& (李小虾) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
编写特定测试用例
13楼& liuxiaoyuzhou
& (蟀哥) <img ALT="二级用户 该版得分小于等于500分，大于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!
在我们这里不能从现的BUG,是测试人员的工作不到位!
我们这里程序员比测试人员说话有力度!
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
16:37:36 &得分 0
测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。
在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。
问题无法重现，也要提出，程序员那里可能回复无法再现。
可以放在那里，等到再次出现的时候，叫程序员过来查看。
实在没有出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。
至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。
这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。
15楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
18:06:20 &得分 0
我们公司只有一个测试组，而且只有三个人，其他两个还兼职
只有我算正职
连个主管都没有，何况经理！
16楼& ericzhangali
& (另一个空间) <img ALT="五级用户 该版得分小于等于5000分，大于2000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
首先一定要提交bug；
其次不要企图RD一定去解这个bug；
某些时候还得关闭这个bug。
如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
21:18:53 &得分 0
RD是什么呀，怎么个拼法。
测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。
我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过（），这样就避免了很多的问题存在。
其实只要自己尽到心就可以了，管别人怎么说呢。
18楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:17:56 &得分 0
什么叫RD？
我也不清楚什么叫测试操作错误，呵呵
这个还是我们测试组定义上去的
我现在也是尽责的去做我的测试，其他开发人员怎么说随他去了
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:36:14 &得分 0
我们使用的状态有：
程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。
测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。
经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。
按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，都使用了“等待处理的”。
最后截项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。
呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。
20楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
12:56:34 &得分 0
解决方案一般定义那几种？
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
13:21:32 &得分 0
解决方案？
在我们这里，解决方案是自己填写的，主要是修改了哪里；或者说明状态的原因等等。
22楼& oyljerry
& (【勇敢的心】→ &#12963;My Ticket√&#12963;) <img ALT="四级用户 该版得分小于等于2000分，大于1000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
所以测试时一定要填写详细的测试报告，记录出现bug的情况，至少可以备份，说不定就有可能重现了
23楼& darkcat_c
& (错了重来) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test &
case步骤做的话不太可能出现此类bug。
作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。
24楼& dosig
& (程序员只是我的表面工作) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
有些问题确实很难重现，但是如果出现了这种问题就一点记录下问题的表现，当时的环境：操作系统、cpu、内存、日志信息。
很同意pyp的说话，有问题就要提
25楼& liyan_1014
& (雁子) <img ALT="二级用户 该版得分小于等于500分，大于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
我觉得应该是这么处理：
1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。
2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。
3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。
以上仅是个人工作中的经验，呵呵~~~~
26楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
10:44:53 &得分 0
你们都说的很有道理，但在我们部门还是不行，测试工作还很不完善，对测试也不怎么重视。
我们的测试文档都是很简单，都没有具体的ｔｅｓｔ　ｃａｓｅ
我们测试环境有时被用来做编译环境，有时同样的步骤，不能使ｂｕｇ重现。
27楼& ericzhangali
& (另一个空间) <img ALT="五级用户 该版得分小于等于5000分，大于2000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:52:01 &得分 0
测试环境并不干净
& (九哥) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
用上测试管理工具，他们不认为是BUG的，可以作废掉，至少这是你的劳动成果。
29楼& shuibo
& (波芷) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
以上的人，说得太好了，学习
30楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
关于“无法重现”我看是有这么个问题存在。
首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG法师之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
16:04:30 &得分 0
关于“无法重现”我看是有这么个问题存在。
首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。
-----------无---敌---分---割---线------------
不清楚你是否是测试人员。“计划外”的，这个对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个识字的，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。
说说我现在测试的一个项目，有一个业务，首先查询出人员，有关“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”至今为止一切都正常。但是这个时候选择再次选择人员，再进行业务处理，仍然会提示“没有选择人员”。这个问题我想一般人都不会在测试用例中写吧，因为发生的条件很苛刻：不用全选的时候不会发生；全选后点击“取消全选”按钮也不会发生；全选后，先点击人员再办理业务也不会发生。
其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。
－－－－－－－我－－又－－出－－来－－了－－－－－－－
呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。
最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
－－－－－－－－－还－－－－－是－－－－－我－－－－－－－－
测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人比不做的人当然要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情，这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。
在说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了，但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。
测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间发现“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就放弃。
32楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
17:55:18 &得分 0
“试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间发现“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就放弃。”
这个和我们公司的差不多
根本就没有正规的测试文档可依
完全靠测试人员测试时候发挥。
33楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
12:32:19 &得分 0
谢谢各位！！！
34楼& kasad
& () <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
12:39:55 &得分 0
本来想给各位加多些分
发现最高只能是100
ｓｏｒｒｙ
下次给大家多一些！！
35楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
19:34:50 &得分 0
呵呵，本来已经是结过贴的了。
不过我看PYP好像意见挺大，交流一下。
测试没做多长时间一年多的测试负责人吧，后面就是项目控制的时候做过结合测试。肯定不如你经验丰富。
我们这里所有的测试都要有文档，测试数据。
我不是贬低你的工作，可是你那样实在没有效率。也没有办法很好的保证程序的质量。
也许我太理论化了，不过几十个人合作没有文档简直是灾难。这一点却深有体会。
同时，我不喜欢你的工作态度。这样好像没有办法让别人信任你的工作结果。
不过你说的测试时间不足等等，确实存在。有时会很严重。
但这个问题可能是你们PM需要解决的吧。
在时间紧的时候有些做法可以谅解，但是不能拿出来作为理论讨论是吧？
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:42:55 &得分 0
理论是理论，实际是实际，理论方面我看的应该也不少了。
我做测试3年多了，原先每个月都基本会去买测试的书籍，多了不敢说，市面上一半以上关于测试的书都看过了还是敢说的。
还有各个测试论坛也常去，都是中文的，我的E文不是很好。
但大家说的都很好听，如果想，我也可以去说很多这样的理论，但实际至少在我们这里用不上。
所以我这里说的只是经验而不是理论。
虽然你做过测试，但看来对测试你并不很满意，否则就不应该用那种口气说话。
你可以把你的话发到51testing去，看看是否有测试人员会满意。
不清楚你说的测试文档和测试数据说的是什么，即使再好的文档和数据，也只能起一个指导的作用，真正发现问题的还是干活的人。
对测试人员的尊重是最基本的，但在你的话中我实在无法看到，也许做领导的和干活的是不同的想法和侧重点吧。
我并不认为我的观点和想法有什么问题，文档我也写，测试计划是我们经理写，但用例和总结基本都是我写以后我们经理进行确认。
也许是因为我们的规模小，所以并不很正规，但实际就是实际，我不会用好听的理论去告诉别人，我只会说我的经验而已。
就是这样。
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:52:48 &得分 0
对于测试人员辅助开发的想法，一直都存在，最新的《测试员》上面也说到了这个问题（不知道你是否还做测试工作，如果还在做，可以看看这电子杂志）。
我个人不是很赞同这种观点，本来也想写东西进行反驳，但后来看到有人说的已经很好了，下面是一位叫“叶子”的朋友的回复，观点我完全赞同。
“非常赞同前面“不要给开发建议怎么改错来限制他的思路”
这个很重要，而且，实际中也碰到一些，毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉，比较有深度或关联比较复杂的bug，测试人员其实是很难定位到的，而测试人员能够定位到的，也不过是些相对独立或简单的问题，而这些问题开发人员是很容易定位到的。（这并不强调测试人员水平不如开发人员，只是强调，测试人员对内部结构和关联并不清楚），所以并没有起到太多作用。这样做除了限制开发人员的思路，还有比较大的一个负面效果是：容易引起开发人员的反感-------他会觉得你有点指手划脚的意思，当然如果某次定位正确了，他没什么话说，但如果一旦定位错了，他就有我刚才提到的想法了，几次不正确的定位描述下来，很容易降低开发人员对测试人员的重视和信任。
也有同学说，开发，测试是一个整体，应该协调合作，不分彼此。。。。。这话我觉得对一半，错一半，作为一个项目团队来说，的确是一个整体的，需要协调合作，但并不意味着就不分彼此，否则也就不用分职责分类了，所谓的协调合作应该是各尽其责任，而不是不分彼此。虽然目的一样，但责任还是不一样的，工作重点也是不同的。---------为了累计经验，比较有意思的bug，测试人员自己可以定位，自己记录，等开发人员回复之后，看看跟自己当初的想法是否一样，长期积累，也许以后碰到类似的问题就可以提点有建设性的意见了，也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了，如果能明确当然定位最好了。
无需定位问题，并不等于测试人员发现问题就一锅端上去，描述也不是越多越好，有时候可能操作很多步骤或输入很多内容后出现某个bug，但真正引起bug的却只是其中一步和一项内容不对，测试人员要做的应该是，尽量精炼步骤和输入内容，找出那一条，精准描述问题是对开发人员最好的帮助。”
38楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
10:33:23 &得分 0
首先祝贺你升星星，然后生命一下我对测试的态度。我自认从未对测试工作有过任何偏见。不止我的发言中哪一点让你觉得“看来对测试你并不很满意”。我觉得这里面有一个问题，就是看问题的角度。从工程的角度（我在这里说的也是经验，既然你并不喜欢谈理论，我也不再谈理论。虽然我一直认为理论不一定都是无聊的人编出来骗人的），任何一个项目管理者都虚妄自己的项目是：有序的、易于调整的、可评估的。这首先需要项目进行的计划足够细化，这个细化的程度，我个人认为是一个最小的可评估单位。一个项目经过几次划分，最终成为若干个这样的单位。对于每个单位，我们有它的设计者、实现者、质量保障者。他们各司其职，但协同工作。那我我们如何保证“质量保障者”的工作质量呢？从项目管理者的角度，两点：一、他必须有完备的测试计划（这里包括测试者自己编制的、以及从设计者那里引用的若干文档）。二、他要有准确的测试实施报告。这两份东西都是可以评估的，同时具有责任的约束力。你提到的前面提到过测试人员自己的发挥，我的感觉很有效但是不保险。也就是说我不能靠测试人员的即兴发挥来保证我的系统的质量和稳定性。因为里面有太多的不确定性。比如测试者经验会参差不齐，比如他们的技术能力和对BUG的预见能力不一样，甚至他们的心情等等。我相信他们能做好，但是这不能作为我保证自己系统质量的手段。
39楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
10:49:06 &得分 0
写到这里我忽然有点明白PYP老师为何觉得我“不尊重”测试者了。的确，我的口气可能有点重了，但是不是对测试者而是对软件工程（这里不是指软件工程理论，而是指它本身）不重视的人。任何事情，想要完成好必然要有他一套成型的方法和思路。不只是软件测试，简单一点的一块饼干我们测试质量是否合格首先要做什么？无论是厂家还是食品监督局，他们检验者块并盖有有自己的标准和检验流程。你说他们是通过流程和方法来保证的质量还是通过人来把握的质量？对于一个工程，我们要努力作的是弱化个人在其中的作用，而强调团队和科学管理。我们中国软件业铺天盖地，却难成大气跟这个很有关系。谁都喜欢英雄力挽狂澜，但是在“没有英雄的年代”我们不是还得好好的活下去嘛。
40楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
11:06:13 &得分 0
然后关于“辅助开发的想法”的问题，我觉得可能是个误会。你说得挺好，我觉得也是应该做到那一步就足够了。我觉得让测试人员帮开发人员发现“BUG是在那句代码里出现的”这事儿是万万不能的。毕竟大家各司其职。如你所说的，提供线索也就足够了！
最后，有个有点失礼的问题：你所在的公司对测试人员是怎么看的呢？
我先说我们公司，项目组中测试人员有统一的专注测试的leader，他们只对测试Leader和自己负责的程序负责，不受开发组的任何“领导”指挥。在选人上，基本用两种人：1、“工作仔细”，这是女生的特性。2、思维严谨，有时候是技术也要比较好的。所以，没有人“瞧不起”测试工作和作测试的人。
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
10:46:23 &得分 0
首先说明，我绝对不是什么老师，没有做过领导，一直都是工作在第一线的小兵兵。
我做测试也三年多了，从工作就开始做测试，做到现在。理论我一向都很关注，所以市面上有什么测试书籍，我都会买来看，网上的测试资料和测试论坛也每天都要看的，测试有什么新东西我想第一时间我就会去注意。
现在我发现自己到了一个瓶颈，工作成为了一种习惯，很久没有太大的提高。所以才努力的总结自己已有的经验，希望能找到一条出路。
你说项目管理者希望项目是有序的、易于调整的、可评估的。但这些对需求、设计、编码阶段都比较容易，到测试这一块，却容易发生一些问题。
说说测试的一些事情。按照习惯上的测试理论，测试应该早期介入软件开发过程，并进行详细的测试计划和写测试用例。这里其实隐含这很多的东西，主要是人力、时间还有开发流程的问题。
好像国外的大公司，对测试比较的重视，测试和开发的比例都很高，当然了，他们的测试要深入代码级，所以需要的人也多一些。现在国内测试和开发的比例能有1：10我想就很不容易了，而且测试需要有小组的形式，单人做的效果和效率都不一定太好，所以一般正规点的测试都独立于开发。我想这是一个基本的共识。这样实际涉及项目组间配合的问题，现在国内的测试部门，由于水平能力等关系，实际大部分都在黑盒阶段。这样如果要写测试用例，就必须需要想当长的时间和详细的文档。我想没有文档，光想像软件会是什么样子，应该没有人能写出测试用例来的吧。特别是详细的带数据的测试用例。
这样就涉及到一个前期文档的问题。现在中国的软件工程程度，我想做过开发的都知道，文档在哪里？？在程序员的脑子里。很遗憾的是，测试人员无法把程序员的脑子橇开看里面到底有什么，也许程序员在没有开发出来之前，对程序本身也可能只有一个模糊的印象而已。在这种情况下，要求测试人员写用例，好像困难些了吧。
这样一般来说，用例的编写就需要在程序开发到差不多的时候进行。现在开发的产品，实际时间都不多，3个月、半年，能成年的软件很少吧。除去需求、设计，给程序员写代码的时间都不多，留给测试人员的时间能有多少呢？
真正详细的测试用例，写几万条是很正常不过的事情，因为要覆盖很多的情况（写过一次，3个月，4个人，总共2万多条）。但这样的一个问题就是需要很多的人去写，周期也比较长，还需要花很多的时间维护（需求变动、程序修改，用例可能也要修改，而且可能几百上千的修改用例，很容易进去几个工作日），这些人和时间去哪里找？
当然了，我不否认有做的好的公司，大家的文档都做的很好，测试人员很早就可以进入，很早就可以规划和写用例，但我想这样的公司应该是凤毛麟角吧。
现在软件工程的一个趋势其实是弱化文档，比如XP，追求快速开发，对编码有利，到测试这里是很麻烦的。
我同意一种观点，做到最后，应该是不需要测试，也就是说，程序本身没有问题，问题的关键在业务流程上，换句话，测试最后需要的是业务专家，而不是测试人员。但现在至少我测试过的程序还无法达到这种程序，软件本身的问题还是成堆，所以还是需要我们测试员的。
在现阶段，可度量的测试过程还很不容易，因为无法用bug数去考核测试人员，测试用例也不可取，因为要评审，所以会很麻烦。
你的观点我明白，像CMM一样，弱化人，强化流程和管理，一切要求可控。但实际执行太不容易了。
我们公司是CMM2，测试部门是完全独立的，很独立很独立的那种。我们公司的集团下面分为两个公司，测试部有两个部分，软件测试和硬件测试，分属两个公司，但是都是一个经理在领导。我们软件测试这边，算上我们经理4个人，一般大的程序给的测试时间是2周左右，小的就2、3天，嗯，测试都不够（因为要算上提交缺陷、修改、再验证等时间），所以用例有时间就去补，没有时间就算了。写了也是很简单的，可以说只是测试思路和流程而算不上具体的用例。可以看看这个帖子，就知道我的工作大概是什么样子的了。http://community.csdn.net/Expert/TopicView3.asp?id=3671025
我们的人么，呵呵，1个原先做配置管理、1个原先做QA的，所以小活一般都我自己做了，也有人多的时候，但公司给的money太少（500～700），全部跑掉了。
对于测试，我认为男女不重要，最关键的是想做测试。现在测试待遇不很好，所以很少想做测试的人。只要有心做测试，所有的都可以学习，不会有什么问题。
42楼& doer_ljy
& (可战) <img ALT="一级用户 该版得分小于等于100分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
09:41:05 &得分 0
个人原因，久未能上线。
看了你提到的帖子，发现我的认识确实以偏概全。不过我想你我可能都是从自己所在的为基准看待这个问题的。最多加上我们身边的一些公司。所以，不能代表全部的情况。
说说我所在公司的情况吧，客户往往是外国人他们不但会要求提交完整的代码。也会要求提供完整的文档。当然包括测试用例和测试结果报告，有时甚至是每一张BUG票。所以我们在座项目安排的时候都给测试留有相对充分的时间，所以我认为测试是可以XXXX样的。但是看了你的工作状况，我发现这个想法确实有点偏颇。实际上，我所做过的项目很少站对国内，不过我想在理论与实践的结合上。我们还应该有探讨的余地。
很多时候我都提到了领导对测试工作的认识。为什么要提这个，因为这个决定了测试工作的可利用资源的厚薄。这个不是一个测试者自己利用自身的技术理论能力所能解决的。我们打个比方吧，一座大楼的质量控制：当你发现地基不牢的时候，像盖楼的资方（我们的boss）提出，这个楼的地基不牢，以后会出问题。结果她不以为然。然后根据你说“你不是搞质量检验的吗？楼盖好了再来吧”。OK，楼盖好了，你来了，被告知随便看看，给你一天的时间。我要验收合格的报告（呵呵，说实话归根到你你干提交一份测试不合格的报告吗？）。你能怎样，纵你三头六臂你又能怎样？没有办法，还是那句话测试是一个系统工程，应该和软件开发的过程有机的融合起来。这需要上至PM下到testor都对测试工作有一个全面的认识才可以。所以，你说的"实际当中很难实现"我能明白。
最后谈点感想，随着中国软件开发能力的提高和规模的扩大。很多公司的已经开始对QA的重要性有所认识，并逐渐重视。我还是觉得这条路走下去，最终会走到测试理论中描述的那样。当然会比理论灵活和复杂的多。
& (鹿鸣) <img ALT="一星用户 该版得分小于等于10000分，大于5000分"
TITLE="偶然性不可重现BUG怎么处理？怎样才能这种ｂｕｇ重现？&回归测试，c++test测试工具" />
17:00:42 &得分 0
实际上，我想国内大部分的公司都处于我们公司的阶段甚至更低，至少我们公司过了CMM2，至少有独立的测试部门。
规范的公司，还是比较少的，一般对外的公司比较的规范，所以才可以施行CMM等比较大的软件工程。
另外说一句，我们有的时候会发测试不通过的报告给他们，至于他们如何处理，我们测试部就无法掌控了。
还有一点，硬件和软件的规则不同，他们的经理认为程序不应该有任何的错误（也许硬件的理念就是这样），所以测试硬件部分附带软件的时候，比测试纯软件轻松的多，一是程序都比较简单，二是他们不敢不修改程序，呵呵，哪怕一个轻微的错误，他们经理也要开会让他们解释，所以一般小问题不好解决的我们都帮他们隐瞒。
据说在我们公司过CMM的时候，有质量保证部门，但我来的比较晚，等我到公司的时候，因为种种原因，质保部门解散了，所以现在公司都是项目组独立，没人负责流程，只要到时候把程序做出来就ok了，测试部只是一个最后把关的作用而已。
中国的测试，任重而道远，我在北方一个中型城市，和北京、上海、深圳等无法相比。
我只能在可能的范围内做好自己的工作。 &
Table of Contents
回归测试是一套复杂完整的测试， 用来测试嵌入在 PostgreSQL 里的的 SQL 实现。
它同时测试标准 SQL 操作和PostgreSQL的扩展SQL。
回归测试可以就一套已经安装好并且在运行的服务器进行测试， 也可以就制作树里面临时安装的服务器进行测试。
详细些说，有"并行"和"串行"运行测试之分。
串行模式顺序运行每个测试，而并行模式启动多个服务器进程，并行地运行一组测试。 并行测试使我们对进程内部通讯和锁的正确工作有足够的信心。
由于历史原因，串行测试通常对一个现存的安装进行测试，而并行测试是"独立"的，不过这么做没有什么技术原因。
制作之后和安装之前运行回归测试，你可以在顶级目录键入
gmake check
（或者你可以进入 src/test/regress 然后在那里运行命令。）
这样将先制作几个辅助文件，比如一些用户定义的触发器函数，然后再运行测试驱动脚本。 最后你会看到类似下面的东西
======================
All 96 tests passed.
======================
或者是一些关于某项测试失败的信息。先看看下面的
然后再想想一个"失败"是否代表严重的错误。
因为这个测试方法运行临时的服务器，所以如果你是 root 用户， 那这个方法不能运行（服务器不能以 root 身份启动）。
如果你已经以 root 身份制作了，你就什么也干不了。 这时候你应该把测试目录的权限变成某个用户可以写，
然后以那个用户身份登陆，再开始测试。比如
root# chmod -R a+w src/test/regress
root# chmod -R a+w contrib/spi
root# su - joeuser
joeuser$ cd top-level build directory
joeuser$ gmake check
（这里唯一可能的"安全隐患"就是那个用户可能会背着你修改回归测试的结果。用你的常识管理用户权限。）
如果不是上面那样，安装后就可以运行测试．
如果你配置 PostgreSQL 安装到一个原来安装有老的
PostgreSQL 的目录里，然后在安装新版本之前执行 gmake check，
那么你可能发现测试失败，因为新程序试图使用已经存在的共享库。 （典型的症状是抱怨未定义的符号。）
如果你想在覆盖老版本之间运行测试，那么你需要带着 configure --disable-rpath 制作。
不过，我们不建议你使用这个选项编译作为最终安装的数据库。
并行的回归测试会在你的用户 ID 下启动相当多的进程。 目前，最大的并发数是 20 给并行测试脚本，这意味着 60 个进程：
一个服务器进程，一个psql以及通常还有一个 shell
父进程用于每个测试脚本的psql。 因此，如果你的系统有每用户的进程数限制，那么请确保这个限制至少是
75，否则你就可能在并行测试时看到随机出现的失败。 如果你没有办法提升该限制，那么你可以通过设置
MAX_CONNECTIONS 参数，把大的并行测试程度降低。
在某些系统上，缺省的 Bourne 兼容的 shell（/bin/sh）在管理太多并行的子进程的时候会出乱子。
这可能导致并行测试锁住或者失败。 出现这种情况时，请在命令行上声明另外一个 Bourne 兼容的 shell，比如：
gmake SHELL=/bin/ksh check
如果没有可以替换的 shell，那么你可以象上面那样通过限制连接的个数来绕开。
安装后（（参阅 ）运行测试， 初始化一个数据区然后启动服务器，像我们在
里面描述的那样，然后键入
gmake installcheck
或者是跑一个并行测试
gmake installcheck-parallel
该测试将与在本地主机和缺省端口号上运行的服务器进行联接，
除非你用PGHOST和PGPORT环境变量设置为其它值。
源代码发布还包含给一些可选的过程语言和一些 contrib 模块的回归测试。
目前，这些测试只能用于对一个已经安装的服务器进行测试。要给所有制作并安装的过程语言运行测试， 我们可以进入源代码树的
src/pl 目录然后键入
gmake installcheck
你还可以在 src/pl 的任何子目录里只针对一种过程语言进行运行。 要为所有
contrib 模块运行现有的测试，进入 contrib 目录，然后键入
gmake installcheck
必须首先制作并安装 contrib 模块。你也可以在 contrib
的子目录里只针对一个模块运行测试。
Parasoft C++ Test简介
作者：贺炘（来源：不详）&&&&日
Test是Parasoft公司出品的一个针对C/C++源代码进行自动化单元测试的工具。它可以对源代码进行三种测试：白盒测试、黑盒测试以及回归功测试。
Test对C/C++源代码进行分析，针对所有的类的成员函数（包括：公共的、保护的以及私有类型的）进行测试。测试的方法是判断当输入一个非法的参数时，有关函数能否正确处理。（Record命令）在此状态下软件针对指定的文件、类或者是函数自动生成测试用例。
　　不对源代码进行分析，并且只针对类的公共接口函数进行测试。（Play命令）
在此状态下软件不自动生成测试用例，而是直接运行在"测试用例编辑器"中当前已有的测试用例（手工添加的）。
回归功测试
　　在修改源代码后用原有的测试用例进行重新测试。（Play命令）
　　建议在实际使用中首先用Record命令执行一遍白盒测试，让软件根据函数自动生成相应的测试用例，然后再根据需要手工添加一些测试用例，最后再通过Play命令执行一遍黑盒测试。
　　假设我们要测试如下一个类的成员函数：int mode2(int
nParam)，则在进行白盒测试时软件会自动为我们生成如下6个测试用例：
　　nParam = 1, 0, -1, , -, 230
　　可以看出，软件测试用例的生成主要还是测试一些边界值，例如最大值、最小值、0等。
　　假设我们要测试如下一个类的成员函数：void strcpy(char* dest, char const *
src)，则软件会自动生成如下9个测试用例：
　　(1) dest = NULL, src = NULL
　　(2) dest = "yPqKIJ!u_", src = NULL
　　(3) dest = "", src = NULL
　　(4) dest = NULL, src = "h)zn9b"
　　(5) dest = "BsmC,/i=zI6CT}pX", src = "HcI{BeP(J"
　　(6) dest = "", src = "% i?~TnON"
　　(7) dest = NULL, src = ""
　　(8) dest = "($MN&n;^", src = ""
　　(9) dest = "", src = ""
　　可见，如果我们的代码在实现时没有对各种可能情况（尤其是边界条件）进行特殊处理的话，则通过C++Test可以方便地发现这些潜在的问题。此外，对于一些特殊的测试情况，我们还可以手工创建测试用例。此外，采用C++
Test也可以帮助我们检查程序的编码情况，判断是否严格按编码规范进行开发。
　　C++ Test的使用比较简单，即可以针对一个VC工程进行全面的测试，也可以一次只对一个C/C++源文件进行测试。
在试用中发现，如果项目比较大时，最好不要直接对一个工程进行自动测试，而应按文件一个一个地测试，否则可会会导致程序死掉。由于其是采用JAVA技术开发的，所以在使用时最好使用运算速度较快的机器。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。}