最后一周的测试啦，看看大家对这个项目的想法，我是个QA

你们这项目估计顺利不了.
如果要改造升级原来的系统,用的技术完全变了,却希望做出完全一样的效果和功能出来,这个思路本身就是有问题的.
象use case这些东西,是在掌握需求时候的一个工具,明明项目没有这一过程,却生生画一堆use case出来,画出来以后又能对系统开发起啥作用呢?
产品的配置很多,以后必然出现的结果就是谁也不知道全部的可选配置方式,再以后就是各种配置之间的冲突,覆盖.
这些是单纯的测试很难测试出来的,上多少个用例都解决不了这问题.

用户的实际使用情况,是根本无法穷举的.

你们有没有制定Bug严重级别和优先级别的标准？根据这个来分配工作就合理多了。
我不太搞得懂“回归测试”，每个测试用例在撰写的时候不是已经制定了测试次数吗？

两个方面：
一方面是自动化测试的应用，是决对必要的，特别是性能测试和回归测试（楼上，如果改了代码，当然要重测一下喽，如果鉴于你也不太清楚可能的相关性，最好所有用例都测一遍，所以就回归了），用例的个数，直接决定测试的效果，所以最好以自动化方式进行。
另一方面，你要分层进行，单元测试，功能测试，集成测试可不是混在一起的，更不要说细的页面测试、数据库测试了。另外，你也得性能测试呀。

还有就是总体把握，就是你认为怎么样的测试过程和结果可以认为满足质量要求了，像是CMMI或ISO9000，能不能确认或估计到，估计准，还是你自己的主观猜测，没什么科学依据。

一周已经过了，不知道产品有没有发布。。

Bug蜂拥而出，最后一周似乎都不会和DEVELOPER沟通了，只管报BUG，数量一下子相当可观，BUILD中间做了个新的，不过BUG还没有少反而更多了，功能好了这个坏了那个，感觉这周没有机会发布了。。。。。。。。。，这个时候感觉QA就是为了阻挡BUG正常交付存在的，一个好玩的角色；同样给客户做的实施，DEVELOPER做好了，结果我发现和需求不符合，感觉是在时间紧张情况下，先发布了了一个再说，明明看起来很复杂的逻辑，结果没有几句代码就交代了，返工啦！拖拖拖，再重测。。。。。。。功能越改越乱，感觉基本功能都开始出现混乱了，之后都要FREEZE CODE了，居然还有会有影响很多功能的改动，感觉前几天的Regression基本无用。。。。。。。。。。，再有一个月，感觉也不一定能发布。。。。。。。。。，最后关头感觉就是书到用时方恨少，尤其是DEVELOPER,在功能都不是很熟悉的情况下，还是进行很大的改动，虽然有Code Review感觉就是走过场，我实在有点相像不出很大功能的改动几乎只用了几个小时修改完，还要发布；最后重担看起来都压在QA身上了。。。。。。。。。。好像开始了经典软件工程里面的描述的循环了！不知道一个月之后搞不搞的定！重复的工作重复的工作，重复的场景，重复的场景！人生呀！

没太明白，为什么这么说呢？
那怎么控制软件质量呢？全部可选的配置完全可以整理出来啊，然后就是用户的实际使用情况，为啥无法穷举呢？

呵呵，测试和开发直接交流是最重要的，什么Leader、PM，在这种场景下都应该靠边站。项目过程是两条主线，一条是围绕产品本身的，另一条是围绕交付时间的，前者的核心人物是测试和开发，两者的关系应该是齐心协力保证产品质量，而不是一方以找bug为乐，另一方以掩盖bug为乐~~
从现在你面临的情况看来，产品在代码层面存在着严重的缺陷，极可能是功能/代码划分不清晰造成的，这个和QA怎么去保障产品质量已经无关了，积累点经验教训也是不错的，去年我也整过一个返工超过150%的项目~

不管项目进行的多么不顺，至少还能按时发的出来工资。。

不是吧，测试和开发就应该减少直接交流。
一方面，作为QA，他必须得把Bug描述写清楚，决不能说：我跟他说了。这也有利于产品上线时的回归测试（到时候难道要找测试人员，让他再说一遍？如果报那个bug的测试人员走了呢？那就重新测一遍，操作的流程可能都不一样了）。测试人员和开发人员交流就是bug描述，描述的不清楚的再面对面沟通。但沟通完之后，测试人员仍然要把bug描述改清楚。

另一方面，按你的说法“什么Leader、PM，在这种场景下都应该靠边站”，那由谁来整体管控开发进度？测试人员只管催着改bug，然后开发人员自作主张的说：“那个问题先不管”，或“我改好了，你赶紧测一下”？没有版本的概念？开发人员和测试人员捉对厮杀，内部协商？？？

当然，程序设计和实现就有问题，不可能硬测给测好了。这更说明了Leader对bug情况有所了解的重要性了。他可以决定哪些bug优先修改，哪些bug不要改了，得重新设计，或者推到下一个版本再解决。
其实就算是小团队，也应该尽量减少开发人员和测试人员之间扯皮。


我认为啊，没有哪个开发人员或测试人员原本就这么变态，就想盖住bug或是挑刺儿。这道理谁都知道，问题是怎么避免产生这种状况？就是分别找两边儿人谈话，说“你们要齐心协力，不以挑毛病为乐，不要以盖bug为乐”？？

你们的开发和测试之间缺乏信任
要让开发知道，他们的开发目标就是要通过测试人员写的用例，两者之间不交流还搞个啥产品啊？开发人员不知道对方会有哪些测试路径，如何去测试，怎样才算达标，两者之间的思维方式是完全不一样的，开发只知道实现功能，但不知道他提供的功能实现会有很多种操作方式及数据约束，这些模块集成起来又会有哪些冲突，如何才是最佳的用户使用体验，这些都是需要测试来给他清楚限制的
很多时间引发这种扯皮和危机的原因是开发和测试没有同时在需求阶段一起加入项目，而是开发在进行N项目时，测试正在进行N-1项目，然后测试版本发布，测试才结束N-1项目，开始投入N项目，这时候，需求被测试推翻了一半甚至以上，设计在一个一个的BUG面前被全面的否定，最后开发人员的信心被彻底打击
PM是干嘛的？他的责任是制定时间点及检查，调动人力资源，基于产品本身的东西和PM没什么关系，你说的只是关系协调。