第一种情况，程序员修改了（制作了）一个新软件，让你测试，你明知该软件也许存在风险，但很长时间的测试后并未发现问题，提交测试通过，但在后期测试中又发现该软件的问题．
第二种情况，程序员修改了（制作了）一个新软件，测试过程中问题无数，随便怎么测试都能发现问题，但要求你把该软件全面测试，需要尽量多的发现问题，还需要跟踪测试．

哪种情况你更头痛？？？

第一种

第一种：存在风险但未测试出来，但在后期的测试中发现问题。这类问题说明随着对系统的不断深入理解，把以前的一些不明确的问题明确化后，可以测试出其中的问题。对该类情况，应该从整体上进行考虑，必要时可以要求需求、设计等相关小组对测试人员进行培训工作，加大对系统认识的深度；

第二种：bug无数，可以简单规避此类问题。测试组可以通过项目小组强制性的手段，要求增加测试阶段准入条件，将重点功能、关键流程列为冒烟测试必须通过的内容，否则不予进入测试，避免浪费人力、物力和时间。否则，可以要求项目组对bug进行统计，我本人不赞成这种做法，但如果项目组不能有足够威信力，可以促成第一类结果，则直接采用此方法，直接上报高层决策。从过程上杜绝或减轻此类现象。

第一种更头痛，发现不了问题是比较痛苦的。

第二种吧
这样简直没办法测试嘛

第一种，测试的工作是尽可能的预防bug。发现bug，修改bug。以达到用户的需求。不能发现的bug却又真正存在的问题才是最头疼的。最近公司的一个项目。已经是试运行期了。结果发现一个比较严重的问题。问题出现。但就是找不到出错的原因。因为真实的运行环境和开发测试的环境有差别。开发和测试的时候。问题怎么也不出现。折腾了一个多月。都以为是环境的原因导致。结果最后发现是session的问题。所以。我觉得第一种问题是最头痛的。
而相对于第二种。对于无法测试。用眼睛看看就能发现一堆问题的程序。测试员可以要求不测试。其实开发人员不仅仅只是开发。他还应该对自己写的程序有个基本的把关吧。他的程序如果一运行。就出n多错误。这样的程序就算提交上来。增加了大家的工作量。还不如对自己的组长说NO.

当然是第一种情况，没有测出bug，如果后来此bug被发现就会骂的很惨，还说是工作不负责，而后一种情况起码还说明我们工作是有成效的。

唉。。。测试的真命苦啊

当然第一种了！
问题多不怕，怕的就是找不到问题！找不出bug要测试做什么？

第一种：发现不了问题，不证明没有问题。所以还是很头疼的，证明这个软件的问题隐藏得很深，或是你没有找到正确的测试方法。需要费一些脑筋。
第二种：如果真像lz所说，问题到处都是。如果要是我，我会将该版本打回，拒绝测试。因为正中情况下测试几乎没有意义。纯粹是为自己的bug数增加指标。

第一种，毕竟发现不了问题是很头疼的事
第二种，如果基本功能都无法使用，就直接打回给开发吧

第一种情况：是测试的责任比较大，到后期才发现问题，说明测试人员不是业务不熟悉就是测试技术不过关，所以公司要有相关的培训。
第二种情况：这很浪费测试员的精力，测试应该有个准入制度。
所以第二种情况会好一些。

第一种是测试的责任,第二种是开发的责任,相对而说还是第一种最痛苦,测试人员找不到BUG的所在才是这个世界上最痛苦的事情

第一种头痛啊
第二种直接打回