《测试自动化》遇到这些问题应该怎么解决？

说实话，我几乎没见过哪个项目不适合采用自动化测试。
测试的工作量总是非常大的，除非你为了偷懒而放弃绝大部分的回归测试。
人力总是宝贵的。

我现在准备测试一个j2ee的项目。项目组2、30个人。内部有自己的测试，自己的QA，自己的配置管理员等。准备通过此项目过CMMI3。
但是，从我测试这里，对此项目并不了解，周会等我不参与，都是经理负责，我现在负责前期的一些准备工作，比如用例、做哪些方面的测试等。前一段帮忙测试了他们的一个jms插件，其他都没有参与。
只能说说自己对你的问题的一些看法。

1.自动化脚本我用的也不算多，原先用过robot，其他loadrunner、winrunner等都做研究使用。现在感觉selenium比较有意思，所以想学习学习。
其实自动化测试如果只有一个人，是很难做的，如果做功能这里的自动化，需要的人力很多。自己可以做的是性能方面的自动化。无论测试还是开发，都要求快速学习的能力的。边学边做，能做到什么程序就做到什么程序。测试对于此方面的压力感觉比开发要小些。
而且很多自动化测试，测试本身很难做的，因为需要开发从代码级别进行支持。所以很多情况只有遇到的才能了解、知道、解决，前期很难预测。

2.单元自动化，是开发人员的事情。和测试有什么关系？？微软的开发和测试比例大概在1：2甚至1；3，所以他们有人力做单元测试。1个测试人员做7个开发人员的单元测试工作，本来就是在开玩笑。而且如果开发人员本身不做单元测试，需要测试人员单作，那么对测试人员的要求其实很高的，国内的企业有多少测试人员的待遇比开发人员高的呢？待遇差如何能有好的测试人员。这样的测试人员做单元测试，企业真的能放心吗？而且独立的单元测试需要了解很多的东西，需要很多的文档支持，开发人员会提供的吗？
所以告诉他们，要不给我加很多厉害的测试人员，要不就让开发人员自己做单元测试。做不做都两码说呢。

3.为什么要测试给开发做单元测试的培训？单元测试本来就是开发应该具有的技能。至少我见过的大部分测试，都做的后期的系统测试，顶多集成测试。测试人员做单元测试的国内应该不多的吧。

4.robot和winrunner现在都在淘汰边缘了。因为此两样都没有新的版本，对大部分新的开发语言支持也不很好。感觉IBM新的主推功能测试工具是IBM Rational Functional Tester ，MI主要资源用在了QTP上。不妨试验一下这两个工具，看看如何。甚至还可以用用selenium，个人感觉也比较好。

5.又见合理的bug跟踪。感觉bug跟踪没有合理，只有是否合适自己公司情况使用。现在大部分的缺陷管理软件都可以很容易的根据需要自定义流程。看看大家喜欢用哪种，就用哪种好了。这个不能一概而论的。

6.测试人员太少了。手工测试，最好用测试小组的方式。如果写测试用例，一个人会忙死的，还有性能测试，没人带会很痛苦。测试工程师和项目经理打交道也不公平。我个人认为，测试和开发应该独立分离。有任何的事情，由开发项目经理和测试经理商讨，这样有一个缓冲的过程，对双方相处都有好处。还有文中说的迭代，真的太广泛了。因为迭代感觉测试并不太好切入。开发人员并不需要了解测试，测试的工作是发现软件过程中因为各种原因产生的缺陷，开发的责任是按照需求生产出合适的软件，目的并不相同。当然了，开发了解测试也有一定的好处，比如可以生产出更利于测试的软件，但需要很好的考虑投入和产出的问题。
顺便说说，测试并不保证软件的质量问题。问题更多又流程决定。测试更多是发现问题、拾遗补漏。呵呵，也许我消极了些。

上面仅仅是一个工作在一线的测试人员的一点点不成熟的看法，不要太较真。

1.自动化脚本我用的也不算多，原先用过robot，其他loadrunner、winrunner等都做研究使用。现在感觉selenium比较有意思，所以想学习学习。

—— 我觉得，想做好测试，一定要掌握一种脚本语言，比如ANT，PYTHON。

其实自动化测试如果只有一个人，是很难做的，......

—— 这个……自动化测试，应该是不需要人的吧？脚本写好了，Cruise Control就一直运行测试了。

2.单元自动化，是开发人员的事情。和测试有什么关系？

—— 我觉得只要是测试，就跟测试人员有关系。程序员写的 Unit Test, 肯定没有测试人员经手的UT有保障。

如果写测试用例，一个人会忙死的，还有性能测试，没人带会很痛苦。

—— 这个……前半句我觉得哪里隐约有点不妥，后半句不太认同。性能测试跟使用的工具有很大关系，跟有无人带没啥关系吧？


一点很不成熟的意见。

嗯~。。。楼上几位兄台的见解对小弟很有启发性，在此谢过了
思考中。。。~

你的测试项目有这么大如果一个人做测试，想做的这么好，是很有难度，selenium 的确不错，但是对于WEB项目有大量的UI更改，这个对测试脚本的维护是很费工作量

我不知道别的项目怎么样，反正我经历过的项目，某个方面做的好坏与否，跟人数的关系不大。

比如开发方面， 有一个经验丰富的开发人员，10个刚入门的新手都比不上。遇到个问题，前者找出库中的代码半个小时解决，后者还要从头学习基础知识，找第三方包，运行DEMO，集成到系统，调试，====，没两天搞不下来。

比如测试方面，有一个思维缜密，流程老道的测试专家，将大家的UnitTest写到一个TestSuite中，然后配置Cruise Control实现测试自动化，有点条件的再弄个专门的测试服务器，邮件发送服务器，短信发送服务器，遇到个BUG就将信息发到相关人员的手机上。再牛B一点的弄个红绿灯放在饮水机前，测试通过绿灯亮，失败红灯亮。—— 再想想国内招的测试人员都是毕业生，想做完这些事情，没半年下不来。


当然，这两个情况指的都是专家与新手的区别。如果项目组中有两三个这样的牛叉人物，项目是肯定不容易失败的。可惜我的经历告诉我，公司有足够的资金，却无长远的眼光，来留住人才。哎。

大部分公司对技术的重视程度不高

微软的比例是1:1，而且单元测试也是开发人员做的。

我也觉得7：1是个笑话，如果想要软件稳定，3：1是可以接受的底线，考虑到是第一个迭代，feature set可以小一些。搂主说的情况大概可以尝试一下简单版TDD,大致要求开发人员按照SPEC把单元测试写了就好了，不过因此增加的时间需要计算好。按照文中3个月的周期计算，能够留给写代码的时间，从CODE START到D-CUT，也就中间那一个月。可以第一个月由唯一的测试工程师来搭建相关的平台，诸如CRUISECONTROL等等，7个开发分下工，四五个写一下单元测试，架构师和剩下的写build scrīpt和mock等。开发过程中由测试工程师撰写FVT,SVT等，过了D-CUT抽调一些开发来帮忙找DEFECT。这样一来实际开发测试比大概能到3：1。