开发团队关于测试的两个问题

刚才旁听一个组建时间不长的开发团队的周例会，团队大致有20多人，分多个小组，注意到了两个问题：
1、指定几位开发人员作为测试人员：
由于暂时没有专业的测试人员，指定了几个对业务熟练的开发人员（或小组长）做测试，测试结果提交TD。对于业务复杂的庞大系统，在模块开发阶段没有专业测试人员的情况下，我比较倾向这种方式。
2、开发过程中的测试数据准备：
记得以前模块开发过程中，对于junit单元测试所用数据，是自己创建、自己应用、自己删除的；
在通过界面测系统模块功能时，则没有什么规则，经常会发生甲做了一批测试数据，今天测了一部份，明天数据就被乙删掉了的情况，测试数据相护使用。
我在想在一个团队里有多个小组如何合理有效的建立模块测试数据：创建数据不做重复劳动，数据可充分“复用”、“共享”、不产生冲突。单独成立一个测试数据构造组？是不是有点投入过大？

测试库就不要复用了.....
复用的东西不好改大家都知道...
这与TDD的理念不同.

个人认为由开发人员测试有种倾向：测试时倾向于走正常的业务逻辑，不太重视异常逻辑。由专门的测试人员（甚至是对系统不熟悉人员）来测，他们会采用“踩地雷”的方式测试，反而会发现一些看起来很低级的错误

个人认为软件系统根本就没有什么正常逻辑和异常逻辑的区别，只有你想到的逻辑和你没想到的逻辑。开发人员做的测试用来保证你想到的东西做得和你的想法一样，测试人员做的测试用来检查有没有应该想到但没有想到的东西。

re。

一般的，开发人员要保证能够自圆其说。

一般的，测试人员要保证能够合乎需求。

“合乎需求”这事也很奇妙。如果一种异常情况从来就没有出现在需求里以致于开发人员在编程的时候都没有考虑它，测试人员从这里测出问题来应该算什么？

maybe这不是这个项目范围内的事
maybe需求bug

对于开发人员作为测试人员这个,我更倾向于从公司借调几个同事来进行一次测试,当然,这需要在开发结果到了一定的可操作程度时才可以.
测试数据一般采取定期清空的方式,在早期的时候,建议大家非必要交叉数据尽量不要产生交叉,如果有需要,可以尽量自己创建相关数据,在中后期的时候,一般不会清空测试数据,测试数据会定时分版本保留,因为有相当多的BUG可能是由于某些数据差生交叉之后才引起的,这个时候如果要重现的话,就需要.
还是提倡在需求分析阶段就有测试工程师的跟踪和介入

呵呵,走一个极端,复用的东西大家都不去改..在一定程度上可以解决利用的东西不好改这个问题

踩地雷是一种方式
但如果要保证测试覆盖率,可能需要踩无数的地雷,这个工作量是很大的