一朋友，他是项目负责人，下面三个测试团队，一个做功能测试，一个做系统测试，一个做解决方案测试。
现在碰到的问题是，他们并行在同一项目时进行测试，发现三个团队间，有在部分测试工作是重复的，然后和我讨论如何清晰的划分三个团队的工作边界，尽可能少的减少交叉性的重复工作，以提高效率。
三外团队职责如下：
功能测试团队，只负责验证单个功能是否正确；
系统测试团队，只负责业务流程性功能是否能正常流通；
解决方案团队，验证给客户提供的解决方案是否实现或是否合理。
主要的问题集中在功能测试团队和系统测试团队间，工作边界的划分上，常常做系统测试的人员，花不少时间在做功能测试，功能测试人员花不少时间在做系统测试。
用例在执行测试前，由另一团队来设计，执行测试的上面三个团队主要负责执行测试。我们拿一个场景来说明重复执行的问题, 医院挂号，对于做功能测试的人来说，他要执行的用你，除了能挂上号外(如输入必要的正常输入项提交成功)，还要测测页面校验，非法数据，关键数据不填写等；对于做系统测试的人员业说，他跑某个业务流程时，其中一个步骤要挂号，但对他来说，挂号只是一个造数据的过程，他的测试重点是验证业务能否正常流转，他在挂号这一步骤，只要保证数据可以正常存入系统，不需要在挂号上面做其他的测试。
现实情况是，功能测试人员，测试完挂号后，他都会不自觉的想要通过走一个完全的流程来验证，业务能不能继续跑下去，做系统测试的人，在用到挂号作为造数据这一步骤时，还全面的测试了挂号这功能，造成重复性测试。
在我看来，根本原因出在用例没做好分类，执行的时候就麻烦，这时也会有人反问，测试是需要发散思维的，完全按设计的用例来执行，肯定不行，不过设计用例时，方方面面都考虑全，覆盖全的话（不是说执行时，全都要执行所有用例，执行时可以根据不同的测试目的建不同的测试任务交由不同的人去执行，每个测试任务是一堆用例的集合），哪怕是完全按用例来执行，也不会出现质量上太大的偏差。
所以问题的源头还是得从设计上把控，根据测试目的（或者说测试侧重点）不同，把用例分为不同的类型。不同侧重点的用例，如存在操作步骤涉及向上面例子所说的，作为该用例的非测试重点的步骤，就是一个一句带过造数据过程，而不会在该步骤上重点测试，这样执行用例时，就可以尽可能减少重复测试。另外，用例评审时，除评审测试点有没有遗漏外，还要评审用例的分类是不是合理，且划分测试点的原则是不可再折分的功能单元，比如用户登录，就不是一个不可再拆分功能单元。
要设计出这样的用例，还有一个前提是对测试需求项（也有叫测试大纲的）做出合理的分解，以测试需求项为主干去设计用例，以保证功能项没有遗漏。然后在应用各种方法来设计用例，并分好上面说的分类。
当然这么划分后，并不是说测试人员执行用例时，只执行设计好的用例，但前提是先要执行，分派给自己的测试用例，随时发散出来的用例，视情况要不要立即执行，或是记下来以后执行。
上面只是我对这问题的个人看法，本身这问题就不好解决，且也不可能有一个两全的办法，不过我相信，通过一段时间人实践，整个团队在这上面的认识统一了，应该会改进很多，工作效率也会提高，欢迎大家讨论。
也有朋友说过，测试前应该先冒烟测试，这其实我认为是测试准入的问题，和上面说的关系不大。
