Being productive is of course a very important thing. Using separate testing processes while doing the same job has some advantages and disadvantages. Here are some of the disadvantages:
No code reuse / mindshare. If you learn something, develop something, it will probably not go beyond your tool.
If there are fixed costs involved with these tools, those are duplicated
Management may not like it because there is duplication at some level.
All parties need to be in agreement that it's a good thing that two tools are in use, or management won't like it.
If your tools satisfy two different techniques of testing, they will naturally be useful in their own right. Just because two things both "test" doesn't mean they are the same thing. I would probably structure my response to management tailored based on what I thought was best for the project.
The obvious answer is that separate tools testing common areas where possible are probably going to tickle different code paths through the code.
I would definitely approach it as you have where you have a deeper testing effort, as in testing deeper into the code directly below the GUI, along with a WinRunner type GUI approach where you are exercising the code through the presentation layer as well.
OTOH, if you're running different tests, and one of you is telling management "tests pass, everything's fine," and the other says "we still have twelve defects," then you have a problem.
I see it as there is an inherent difference between the types of test a developer needs to run to ensure his code is correct and the tests a tester runs by exercising the user interface. There is much that isn't exercised from the user interface but still has to work correctly and as a dev, you are not exempt from unit testing the code before sending it to test. No reason why these two types of tests can't be done using separate tools as they are not testing for the same thing. What works for a group of testers won't work for a group of developers.
Sit down with the tester and go through an example of the tests you write to test a feature and the ones he or she would create using the other tool. Together create a presentation to management that shows why the two tools are both needed and how using two tools increases the chances of finding more bugs before going to production.
发布评论
评论（4）
富有成效当然是一件非常重要的事情。在执行相同的工作时使用单独的测试过程有一些优点和缺点。以下是一些缺点：
如果您的工具满足两种不同的测试技术，那么它们本身就会很有用。仅仅因为两个事物都“测试”并不意味着它们是同一事物。我可能会根据我认为最适合该项目的内容来构建对管理层的回应。
Being productive is of course a very important thing. Using separate testing processes while doing the same job has some advantages and disadvantages. Here are some of the disadvantages:
If your tools satisfy two different techniques of testing, they will naturally be useful in their own right. Just because two things both "test" doesn't mean they are the same thing. I would probably structure my response to management tailored based on what I thought was best for the project.
显而易见的答案是，在可能的情况下测试公共区域的单独工具可能会在代码中触发不同的代码路径。
我肯定会采用这种方法，就像您进行更深入的测试工作一样，例如更深入地测试 GUI 正下方的代码，以及 WinRunner 类型的 GUI 方法，您也可以通过表示层来执行代码。
华泰
The obvious answer is that separate tools testing common areas where possible are probably going to tickle different code paths through the code.
I would definitely approach it as you have where you have a deeper testing effort, as in testing deeper into the code directly below the GUI, along with a WinRunner type GUI approach where you are exercising the code through the presentation layer as well.
HTH
OTOH，如果您正在运行不同的测试，其中一个告诉管理层“测试通过，一切都很好”，而另一个则说“我们仍然有十二个缺陷”，那么您就有问题了。
OTOH, if you're running different tests, and one of you is telling management "tests pass, everything's fine," and the other says "we still have twelve defects," then you have a problem.
我认为这是因为开发人员需要运行以确保其代码正确的测试类型与测试人员通过使用用户界面运行的测试之间存在固有的差异。有很多内容没有从用户界面中执行，但仍然必须正常工作，并且作为开发人员，您不能免除在将代码发送到测试之前对代码进行单元测试。没有理由不能使用单独的工具来完成这两种类型的测试，因为它们不是针对同一事物进行测试。适用于一组测试人员的方法不适用于一组开发人员。
与测试人员坐下来，查看您为测试功能而编写的测试示例以及他或她将使用其他工具创建的测试示例。一起向管理层创建一个演示文稿，展示为什么需要这两种工具，以及使用这两种工具如何增加在投入生产之前发现更多错误的机会。
I see it as there is an inherent difference between the types of test a developer needs to run to ensure his code is correct and the tests a tester runs by exercising the user interface. There is much that isn't exercised from the user interface but still has to work correctly and as a dev, you are not exempt from unit testing the code before sending it to test. No reason why these two types of tests can't be done using separate tools as they are not testing for the same thing. What works for a group of testers won't work for a group of developers.
Sit down with the tester and go through an example of the tests you write to test a feature and the ones he or she would create using the other tool. Together create a presentation to management that shows why the two tools are both needed and how using two tools increases the chances of finding more bugs before going to production.