偶然性不可重现BUG怎么处理（整理）

上一编转的日志的源头，整理一下。pyp（鹿鸣）和doer_ljy（可战）的对话雨十分精彩。

---

楼主kasad（）2005-03-21 10:21:16 在 软件工程/管理 / 质量管理与控制版 提问各位大侠：  
  　　偶然性不可重现BUG一般怎么处理？  
  　　怎样才能这种ｂｕｇ重现？  
   
  　　我们公司遇到偶然性不可重现BUG竟然视为操作错误！（无赖的苦笑）

 

1 楼pyp（鹿鸣）回复于 2005-03-21 10:33:03 得分15

一定要提交！！  
   
  1。记得有这么个缺陷，以后遇到的时候可能就会了解发生的原因。  
   
  2。尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。  
   
  3。程序员对程序比测试人员熟悉的多，也许你提交了，即使无法重新，程序员也会了解问题所在。  
   
  4。无法重现的问题再次出现后，可以直接叫程序员来看看问题。  
   
  5。对于测试人员来说，没有操作错误这条.既然遇到，就是问题。即使真的操作错了，也要推到程序员那里，既然测试人员犯错误，用户也可能会犯同样的错误。错误发生的时候，Tester最大，哈哈。  
   
  6。等待想到的时候再接着说。

 

2 楼notyy（notyy）回复于 2005-03-21 10:41:35 得分3

感觉只有4可行啊  
  没法重现就提交会被程序员骂的

 

3 楼pyp（鹿鸣）回复于 2005-03-21 10:50:09 得分 0

程序不是测试人员写的，出问题也不是测试人员的原因。  
   
  至于无法重现，可能的原因很多，因为测试人员看到的只是程序的外部，无法深入程序内部，所以把责任推给测试人员是不对的。  
   
  测试人员的任务只是尽力重现问题，而不是必须重现！！  

 

4 楼kasad（）回复于 2005-03-21 11:02:32 得分 0

痛苦阿！  
  我们公司只要开发人员最大，虽然我们经理说下放权力给我们测试人员，但实际上没有任何权力，只有当客户报的BUG才是真的BUG，他们那些人才会去解决。  
  愁  
   
  提交的BUG，回复竟然是操作错误，晕死了。

 

5 楼pyp（鹿鸣）回复于 2005-03-21 11:23:01 得分 0

下次再遇到的时候，拉他们来看就可以了。  
  因为问题如果无论如何无法重现，程序员确实也没有什么好的解决方法。  
  而且此类问题即使程序员说修改了，测试员也没有好的方法去验证是不是。:)

 

6 楼kasad（）回复于 2005-03-21 11:30:12 得分 0

确实没有什么好解决的，也没有什么好验证的  
  但是他们老是认为是测试错误就很不是滋味  

 

7 楼pyp（鹿鸣）回复于 2005-03-21 11:43:02 得分 0

你可以告诉程序员，测试过程是没有错误的。  
  测试人员只是检查程序中可能存在的问题，虽然测试人员使用一定的手段方法努力去覆盖所有的情况，但这些都是理论的推测。在实际中，可能因为人员、环境、配置等种种原因出现各种各样的问题，在测试人员这里发现问题是公司内部的事情，程序发到外面可就是公司的形象问题了。  
  需要让程序员理解，测试人员是帮助他们的，不是害他们的。  
  客户那里发现问题比测试员发现问题结果要严重的多。

 

8 楼doublefalse（散诸怀抱）回复于 2005-03-21 12:55:18 得分10

如果不能重现的bug确实比较麻烦，但最好在测试过程中注意干净环境、正确的操作、相同的数据源，只要真的有问题，一定能否复现的。呵呵，多试试！！！  
  我们以前一直有客户反映入库的数据经常有无关数据，但在家里测试没有问题，后来才发现是汉字编码错位，这样同样的字，错位后就变成另外的东西了

9 楼kasad（）回复于 2005-03-21 13:03:26 得分 0

其实那些厉害关系，他们比我们测试人员知道的还多，但是。。。  
   
   
  但测试过程没有错误，即使是我们测试组的人也不会认同我的（个中理由没有办法说）  

 

10 楼kasad（）回复于 2005-03-21 13:07:17 得分 0

但有时我们的测试环境会被开发人员做编译环境  
  这也可能影响到重现  

 

11 楼redguardtoo（）回复于 2005-03-21 15:33:58 得分3

对国内的大多数公司来说，只要做到一点就够了。  

 

12 楼sycnick（李小虾）回复于 2005-03-21 16:14:25 得分5

编写特定测试用例

13 楼liuxiaoyuzhou（蟀哥）回复于 2005-03-21 16:26:52 得分5

遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!  
   
  在我们这里不能从现的BUG,是测试人员的工作不到位!  
   
  我们这里程序员比测试人员说话有力度!   
  
  郁闷呀!

 

14 楼pyp（鹿鸣）回复于 2005-03-21 16:37:36 得分 0

测试部门是独立与开发部门的呀，真的打交道，也是经理对经理。  
  在我们这里，工作上面的事情，和程序员相互只能商议解决，并没有谁高谁低。  
  问题无法重现，也要提出，程序员那里可能回复无法再现。  
  可以放在那里，等到再次出现的时候，叫程序员过来查看。  
  实在没有出现，最后可以写到报告中，说出现了什么现象，但无法再现（比较严重的问题才如此处理，小问题经理之间商量商量可能就算了）。  
  至于测试人员必须重现bug，你杀了我好了，我每次测试项目都有无法重现的问题，很多我能找到大概的原因，有些根本无法重现（仅仅出现一次）。  
  这种事情是无法避免的，并不能说测试人员无法重现问题，就是工作不到位（哼，程序有bug，是否可以说程序员工作不到位的呀）。

 

15 楼kasad（）回复于 2005-03-21 18:06:20 得分 0

我们公司只有一个测试组，而且只有三个人，其他两个还兼职  
  只有我算正职  
  连个主管都没有，何况经理！  

 

16 楼ericzhangali（另一个空间）回复于 2005-03-21 18:25:06 得分8

首先一定要提交bug；  
  其次不要企图RD一定去解这个bug；  
  某些时候还得关闭这个bug。  
  如果RD认为是测试错误，（不明白什么叫测试错误，是不是说他从测时要告诉你千万不要怎么怎么做，否则后果自负啊，）那也没什么办法，如果沟通解决不了，爱咋认为就咋认为吧。

 

17 楼pyp（鹿鸣）回复于 2005-03-21 21:18:53 得分 0

RD是什么呀，怎么个拼法。  
   
  测试部门要独立，最好不受开发的制约。其实真正要重视，就应该有否决的权利。  
   
  我们公司就是项目承包，要拿最后的项目尾款，就要测试部签字通过（），这样就避免了很多的问题存在。  
   
  其实只要自己尽到心就可以了，管别人怎么说呢。

 

18 楼kasad（）回复于 2005-03-22 11:17:56 得分 0

什么叫RD？  
  我也不清楚什么叫测试操作错误，呵呵  
  这个还是我们测试组定义上去的  
  真是晕！  
   
  我现在也是尽责的去做我的测试，其他开发人员怎么说随他去了

 

19 楼pyp（鹿鸣）回复于 2005-03-22 11:36:14 得分 0

我们使用的状态有：  
  程序员处理的状态（由测试员提交的Action）：等待处理的，再次出现的。  
  测试员处理的状态（由程序员提交的Action）：已经修改的，暂不修改的，系统限制的，使用错误的，无法再现的。测试员可以修改记录。  
  经理处理的状态（由测试员提交Action）：管理员处理的。经理还可以删除记录。  
   
  按照比较标准的说法，其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态，我们为了省事，都使用了“等待处理的”。  
   
  最后截项的时候，缺陷的状态对我们来说有两种，“已经关闭的”（由测试员或经理确认）和“暂不修改的”（比如下一个版本处理等）。  
   
  呵呵，状态多，有些烦琐，特别是程序员很多的时候都不清楚应该回复什么状态，但我个人觉得对测试人员来说，这些状态比较清晰明了，容易处理。

 

20 楼kasad（）回复于 2005-03-22 12:56:34 得分 0

解决方案一般定义那几种？

 

21 楼pyp（鹿鸣）回复于 2005-03-22 13:21:32 得分 0

解决方案？  
  在我们这里，解决方案是自己填写的，主要是修改了哪里；或者说明状态的原因等等。

 

22 楼oyljerry（【勇敢的心】→ ㊣提拉米苏√㊣）回复于 2005-03-22 15:52:57 得分4

所以测试时一定要填写详细的测试报告，记录出现bug的情况，至少可以备份，说不定就有可能重现了

23 楼darkcat_c（错了重来）回复于 2005-03-22 18:07:23 得分10

没有bug是不可以重现的，bug本事是建立在标准的规程上所出现的异常，如果你按test   case步骤做的话不太可能出现此类bug。  
  作为测试人员一定要具备良好的记忆能力，一旦出现一些不知如何产生的bug，至少你要知道刚才你大致进行了那些操作。良好的分析能力，尽管你只是测试，但你应该全面的了解程序的架构，和一些重要的内部细节，不然你这个测试就是不合格的。定位bug是开发的事情，而重现一个bug是测试的本职工作，不要把所有的事情推给开发，不然你的确比开发要低一等。

 

24 楼dosig（程序员只是我的表面工作）回复于 2005-03-22 21:51:55 得分 5有些问题确实很难重现，但是如果出现了这种问题就一点记录下问题的表现，当时的环境：操作系统、cpu、内存、日志信息。  
  很同意pyp的说话，有问题就要提
Top

25 楼liyan_1014（雁子）回复于 2005-03-23 09:43:17 得分 10我觉得应该是这么处理：  
  1、一定提交bug，必须由负责bug的tester详细描述测试操作步骤，bug发生的症状，并将bug发生的具体环境也描述清楚；这样对于再次重现也有一定的参考性。  
  2、测试和开发之间是需要良好沟通的，如果得到的回复是操作错误，那么请开发人员解释，为什么会允许存在操作错误，一般来说，对于错误控制，开发那边应该能很好的把握。  
  3、沟通方面是需要方式的，开发人员对于自己完成的程序有一种满足感，一般来说是不允许别人来破坏他的这种感觉，如果沟通的时候尽可能是一种建议的形式，让开发人员自己指出自己的程序缺陷，这样对于开发人员来说是可以接受。  
  以上仅是个人工作中的经验，呵呵~~~~
Top

26 楼kasad（）回复于 2005-03-23 10:44:53 得分 0 你们都说的很有道理，但在我们部门还是不行，测试工作还很不完善，对测试也不怎么重视。  
   
  我们的测试文档都是很简单，都没有具体的ｔｅｓｔ　ｃａｓｅ  
   
  我们测试环境有时被用来做编译环境，有时同样的步骤，不能使ｂｕｇ重现。
Top

27 楼ericzhangali（另一个空间）回复于 2005-03-23 11:52:01 得分 0 测试环境并不干净
Top

28 楼wzb99447227（九哥）回复于 2005-03-23 12:35:55 得分 3用上测试管理工具，他们不认为是BUG的，可以作废掉，至少这是你的劳动成果。  
   
 
Top

29 楼shuibo（波芷）回复于 2005-03-23 13:27:10 得分 10以上的人，说得太好了，学习
Top

30 楼doer_ljy（可战）回复于 2005-03-23 15:10:53 得分 9关于“无法重现”我看是有这么个问题存在。  
   
  首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。  
   
  其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG法师之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。  
   
  最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.
Top

31 楼pyp（鹿鸣）回复于 2005-03-23 16:04:30 得分 0 关于“无法重现”我看是有这么个问题存在。  
   
  首先如果你在测试之前有严格的测试计划，就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。  
  -----------无---敌---分---割---线------------  
  不清楚你是否是测试人员。“计划外”的，这个对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题，测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例（说白了，只要一个识字的，按照测试单做，就能发现所有的问题，呵呵，有软件蓝领的感觉了）。即使真的有，意义也不大，测试很多的时候，是发散性的思维，带点创造性，想事先考虑完全，很难。所以更多时候，是在测试过程中逐步对用例等进行完善，所以说“计划外”最好不要提。  
  说说我现在测试的一个项目，有一个业务，首先查询出人员，有关“全选”按钮，“全选”后，再用鼠标一个一个取消选择，这个时候进行业务办理的时候，就会提示“没有选择人员”至今为止一切都正常。但是这个时候选择再次选择人员，再进行业务处理，仍然会提示“没有选择人员”。这个问题我想一般人都不会在测试用例中写吧，因为发生的条件很苛刻：不用全选的时候不会发生；全选后点击“取消全选”按钮也不会发生；全选后，先点击人员再办理业务也不会发生。  
   
   
  其次，成熟的测试人员及时无法再现BUG，也能准确的描述出BUG发生之前几个步骤的操作方法，测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。  
  －－－－－－－我－－又－－出－－来－－了－－－－－－－  
  呵呵，看来我不是成熟的测试人员。手工测试，比较熟练的时候，和打字可以说差不多，应该进行到哪里，心中是有数的，但让我完全从头到尾的重复，不容易呀。写测试缺陷报告单的时候，也只是说明操作步骤和发生的现象。其实无法重现的问题，既然说“无法重现”，也就是测试人员已经对这个现象进行了多次的验证，一般从程序外部来说，测试人员的操作比程序员要熟练的。  
   
   
   
  最后，我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作，目标是一致的。测试人员总是处在BUG发生的第一现场，应该帮助分析出现问题的原因。确认是不是自己的此时Miss.  
  －－－－－－－－－还－－－－－是－－－－－我－－－－－－－－  
  测试人员提交任何一个问题，都会经过反复的验证，如果容易重现，早就提出来了。绝对不是在推脱责任，还是那句话，对程序的结构，做的人比不做的人当然要清楚。另外，除非程序员询问，否则我不会给程序员提出修改分析和建议！！测试人员的任务是发现问题，解决问题是程序员的事情，这么做可能会影响程序员思考问题的思路；而且测试人员做的多了，程序员不但不感激，可能反而会反感（好像程序员对测试人员有好印象的不多）。  
  在说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后，在其它的业务，此数据将不能再使用。我当时发现这个功能无效，而且经过了几次的验证都不行，我当然就提出了，但是程序员那里说此功能好使，我再验证的时候，就没有问题了，这个问题当时可以重现（但是我不可能遇到问题就拉程序员来看吧），后来却没有了，只能放在那里，最后关闭掉。第二个就是在一个界面中，录入有顺序要求，必须先选择一个ListBox（必填）再进行Edit的录入，但一次操作我没有选择ListBox就录入的Edit，也正常保存了。后来无论我怎么操作此问题都没有出现（不够成熟呀），我就放弃了，也没有提交记录（为了避免麻烦）。  
  测试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间发现“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就放弃。
Top

32 楼kasad（）回复于 2005-03-23 17:55:18 得分 0 哈哈  
  “试人员的时间是有限的，进度给的都很少，一般连用例都没有时间写，还要去花很多时间发现“无法重现”的问题？反正10分钟如果试验不出来，我就会放弃。严重的就提交，不影响的就放弃。”  
   
   
  这个和我们公司的差不多  
  根本就没有正规的测试文档可依  
  完全靠测试人员测试时候发挥。  
 
Top

33 楼kasad（）回复于 2005-03-24 12:32:19 得分 0 谢谢各位！！！
Top

34 楼kasad（）回复于 2005-03-24 12:39:55 得分 0 呵呵  
  本来想给各位加多些分  
  发现最高只能是100  
  ｓｏｒｒｙ  
  下次给大家多一些！！
Top

35 楼doer_ljy（可战）回复于 2005-04-25 19:34:50 得分 0 呵呵，本来已经是结过贴的了。  
  不过我看PYP好像意见挺大，交流一下。  
  测试没做多长时间一年多的测试负责人吧，后面就是项目控制的时候做过结合测试。肯定不如你经验丰富。  
  我们这里所有的测试都要有文档，测试数据。  
  我不是贬低你的工作，可是你那样实在没有效率。也没有办法很好的保证程序的质量。  
  也许我太理论化了，不过几十个人合作没有文档简直是灾难。这一点却深有体会。  
  同时，我不喜欢你的工作态度。这样好像没有办法让别人信任你的工作结果。  
  不过你说的测试时间不足等等，确实存在。有时会很严重。  
  但这个问题可能是你们PM需要解决的吧。  
  在时间紧的时候有些做法可以谅解，但是不能拿出来作为理论讨论是吧？
Top

36 楼pyp（鹿鸣）回复于 2005-04-26 11:42:55 得分 0 理论是理论，实际是实际，理论方面我看的应该也不少了。  
  我做测试3年多了，原先每个月都基本会去买测试的书籍，多了不敢说，市面上一半以上关于测试的书都看过了还是敢说的。  
  还有各个测试论坛也常去，都是中文的，我的E文不是很好。  
  但大家说的都很好听，如果想，我也可以去说很多这样的理论，但实际至少在我们这里用不上。  
  所以我这里说的只是经验而不是理论。  
  虽然你做过测试，但看来对测试你并不很满意，否则就不应该用那种口气说话。  
  你可以把你的话发到51testing去，看看是否有测试人员会满意。  
  不清楚你说的测试文档和测试数据说的是什么，即使再好的文档和数据，也只能起一个指导的作用，真正发现问题的还是干活的人。  
  对测试人员的尊重是最基本的，但在你的话中我实在无法看到，也许做领导的和干活的是不同的想法和侧重点吧。  
  我并不认为我的观点和想法有什么问题，文档我也写，测试计划是我们经理写，但用例和总结基本都是我写以后我们经理进行确认。  
  也许是因为我们的规模小，所以并不很正规，但实际就是实际，我不会用好听的理论去告诉别人，我只会说我的经验而已。  
  就是这样。   
    
    
 

37 楼pyp（鹿鸣）回复于 2005-04-26 11:52:48 得分 0 对于测试人员辅助开发的想法，一直都存在，最新的《测试员》上面也说到了这个问题（不知道你是否还做测试工作，如果还在做，可以看看这电子杂志）。  
   
  我个人不是很赞同这种观点，本来也想写东西进行反驳，但后来看到有人说的已经很好了，下面是一位叫“叶子”的朋友的回复，观点我完全赞同。  
   
  “非常赞同前面“不要给开发建议怎么改错来限制他的思路”  
  这个很重要，而且，实际中也碰到一些，毕竟测试人员对程序构架及内部结构没有开发人员那么熟悉，比较有深度或关联比较复杂的bug，测试人员其实是很难定位到的，而测试人员能够定位到的，也不过是些相对独立或简单的问题，而这些问题开发人员是很容易定位到的。（这并不强调测试人员水平不如开发人员，只是强调，测试人员对内部结构和关联并不清楚），所以并没有起到太多作用。这样做除了限制开发人员的思路，还有比较大的一个负面效果是：容易引起开发人员的反感-------他会觉得你有点指手划脚的意思，当然如果某次定位正确了，他没什么话说，但如果一旦定位错了，他就有我刚才提到的想法了，几次不正确的定位描述下来，很容易降低开发人员对测试人员的重视和信任。  
  也有同学说，开发，测试是一个整体，应该协调合作，不分彼此。。。。。这话我觉得对一半，错一半，作为一个项目团队来说，的确是一个整体的，需要协调合作，但并不意味着就不分彼此，否则也就不用分职责分类了，所谓的协调合作应该是各尽其责任，而不是不分彼此。虽然目的一样，但责任还是不一样的，工作重点也是不同的。---------为了累计经验，比较有意思的bug，测试人员自己可以定位，自己记录，等开发人员回复之后，看看跟自己当初的想法是否一样，长期积累，也许以后碰到类似的问题就可以提点有建设性的意见了，也能让别人信服。所以我的建议是不太确定的就不要轻易给定位了，如果能明确当然定位最好了。  
   
  无需定位问题，并不等于测试人员发现问题就一锅端上去，描述也不是越多越好，有时候可能操作很多步骤或输入很多内容后出现某个bug，但真正引起bug的却只是其中一步和一项内容不对，测试人员要做的应该是，尽量精炼步骤和输入内容，找出那一条，精准描述问题是对开发人员最好的帮助。”

38 楼doer_ljy（可战）回复于 2005-04-29 10:33:23 得分 0

首先祝贺你升星星，然后生命一下我对测试的态度。我自认从未对测试工作有过任何偏见。不止我的发言中哪一点让你觉得“看来对测试你并不很满意”。我觉得这里面有一个问题，就是看问题的角度。从工程的角度（我在这里说的也是经验，既然你并不喜欢谈理论，我也不再谈理论。虽然我一直认为理论不一定都是无聊的人编出来骗人的），任何一个项目管理者都虚妄自己的项目是：有序的、易于调整的、可评估的。这首先需要项目进行的计划足够细化，这个细化的程度，我个人认为是一个最小的可评估单位。一个项目经过几次划分，最终成为若干个这样的单位。对于每个单位，我们有它的设计者、实现者、质量保障者。他们各司其职，但协同工作。那我我们如何保证“质量保障者”的工作质量呢？从项目管理者的角度，两点：一、他必须有完备的测试计划（这里包括测试者自己编制的、以及从设计者那里引用的若干文档）。二、他要有准确的测试实施报告。这两份东西都是可以评估的，同时具有责任的约束力。你提到的前面提到过测试人员自己的发挥，我的感觉很有效但是不保险。也就是说我不能靠测试人员的即兴发挥来保证我的系统的质量和稳定性。因为里面有太多的不确定性。比如测试者经验会参差不齐，比如他们的技术能力和对BUG的预见能力不一样，甚至他们的心情等等。我相信他们能做好，但是这不能作为我保证自己系统质量的手段。

39 楼doer_ljy（可战）回复于 2005-04-29 10:49:06 得分 0 写到这里我忽然有点明白PYP老师为何觉得我“不尊重”测试者了。的确，我的口气可能有点重了，但是不是对测试者而是对软件工程（这里不是指软件工程理论，而是指它本身）不重视的人。任何事情，想要完成好必然要有他一套成型的方法和思路。不只是软件测试，简单一点的一块饼干我们测试质量是否合格首先要做什么？无论是厂家还是食品监督局，他们检验者块并盖有有自己的标准和检验流程。你说他们是通过流程和方法来保证的质量还是通过人来把握的质量？对于一个工程，我们要努力作的是弱化个人在其中的作用，而强调团队和科学管理。我们中国软件业铺天盖地，却难成大气跟这个很有关系。谁都喜欢英雄力挽狂澜，但是在“没有英雄的年代”我们不是还得好好的活下去嘛。

40 楼doer_ljy（可战）回复于 2005-04-29 11:06:13 得分 0 然后关于“辅助开发的想法”的问题，我觉得可能是个误会。你说得挺好，我觉得也是应该做到那一步就足够了。我觉得让测试人员帮开发人员发现“BUG是在那句代码里出现的”这事儿是万万不能的。毕竟大家各司其职。如你所说的，提供线索也就足够了！  
   
  最后，有个有点失礼的问题：你所在的公司对测试人员是怎么看的呢？  
   
  我先说我们公司，项目组中测试人员有统一的专注测试的leader，他们只对测试Leader和自己负责的程序负责，不受开发组的任何“领导”指挥。在选人上，基本用两种人：1、“工作仔细”，这是女生的特性。2、思维严谨，有时候是技术也要比较好的。所以，没有人“瞧不起”测试工作和作测试的人。

41 楼pyp（鹿鸣）回复于 2005-05-07 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（可战）回复于 2005-06-01 09:41:05 得分 0 个人原因，久未能上线。  
  看了你提到的帖子，发现我的认识确实以偏概全。不过我想你我可能都是从自己所在的为基准看待这个问题的。最多加上我们身边的一些公司。所以，不能代表全部的情况。  
  说说我所在公司的情况吧，客户往往是外国人他们不但会要求提交完整的代码。也会要求提供完整的文档。当然包括测试用例和测试结果报告，有时甚至是每一张BUG票。所以我们在座项目安排的时候都给测试留有相对充分的时间，所以我认为测试是可以XXXX样的。但是看了你的工作状况，我发现这个想法确实有点偏颇。实际上，我所做过的项目很少站对国内，不过我想在理论与实践的结合上。我们还应该有探讨的余地。  
          很多时候我都提到了领导对测试工作的认识。为什么要提这个，因为这个决定了测试工作的可利用资源的厚薄。这个不是一个测试者自己利用自身的技术理论能力所能解决的。我们打个比方吧，一座大楼的质量控制：当你发现地基不牢的时候，像盖楼的资方（我们的boss）提出，这个楼的地基不牢，以后会出问题。结果她不以为然。然后根据你说“你不是搞质量检验的吗？楼盖好了再来吧”。OK，楼盖好了，你来了，被告知随便看看，给你一天的时间。我要验收合格的报告（呵呵，说实话归根到你你干提交一份测试不合格的报告吗？）。你能怎样，纵你三头六臂你又能怎样？没有办法，还是那句话测试是一个系统工程，应该和软件开发的过程有机的融合起来。这需要上至PM下到testor都对测试工作有一个全面的认识才可以。所以，你说的"实际当中很难实现"我能明白。  
  最后谈点感想，随着中国软件开发能力的提高和规模的扩大。很多公司的已经开始对QA的重要性有所认识，并逐渐重视。我还是觉得这条路走下去，最终会走到测试理论中描述的那样。当然会比理论灵活和复杂的多。   
 

43 楼pyp（鹿鸣）回复于 2005-06-01 17:00:42 得分 0 实际上，我想国内大部分的公司都处于我们公司的阶段甚至更低，至少我们公司过了CMM2，至少有独立的测试部门。  
  规范的公司，还是比较少的，一般对外的公司比较的规范，所以才可以施行CMM等比较大的软件工程。  
  另外说一句，我们有的时候会发测试不通过的报告给他们，至于他们如何处理，我们测试部就无法掌控了。  
  还有一点，硬件和软件的规则不同，他们的经理认为程序不应该有任何的错误（也许硬件的理念就是这样），所以测试硬件部分附带软件的时候，比测试纯软件轻松的多，一是程序都比较简单，二是他们不敢不修改程序，呵呵，哪怕一个轻微的错误，他们经理也要开会让他们解释，所以一般小问题不好解决的我们都帮他们隐瞒。  
  据说在我们公司过CMM的时候，有质量保证部门，但我来的比较晚，等我到公司的时候，因为种种原因，质保部门解散了，所以现在公司都是项目组独立，没人负责流程，只要到时候把程序做出来就ok了，测试部只是一个最后把关的作用而已。  
  中国的测试，任重而道远，我在北方一个中型城市，和北京、上海、深圳等无法相比。  
  我只能在可能的范围内做好自己的工作。