公司是否需要提供用例框架？

yezhaohui520

下面是我们公司要求我们在写用例时的框架，就是我们写用例时就按照下面8条来分别进行考虑，你们觉得有必要吗？或者这个框架合理吗，比如UI测试、功能测试分得那么开做什么啊，还有就是关联测试，因为我们公司产品的耦合性巨高，修改一个地方关系N个地方，所以加个关联测试，其实与修改项关联的地方本来就是要测的地方，干嘛还要把它分出来？我在实际写用例的时候感觉很不爽，感觉思维受到限制，有的用例觉得是UI同时又是功能同时又是关联的东西，搞得不知道往哪里放，为什么要这么个框架？

yezhaohui520

自己下坐个沙发！！望大家回答下我的疑问啊?或者说下你们公司要你写用例的流程是怎么样的？谢谢了！！！

Jackc

回复 1# yezhaohui520

首先，这个框架本身没有什么问题，也算是用例分类的基础框架之一。通过细致地分类用例组，让其更好的与用例评审/测试策略结合。
如，不同测试阶段选择的用例组不同。如，测试初期只需使用UI测试和基本功能测试用例组，而随着产品开发成熟，逐步加载关联测试、容错测试等用例组。

所以，若考虑此种用例分类存在 问题，还需结合你们公司的开发流程和实际项目需求。
————————————————————

接下来逐个说说你提出的疑问：

1.UI/功能 用例组
通常用例分类不会严格区分这两类用例，因为功能操作的实现本身就得依靠UI上的各个控件实现。所以，严格意义上，完美的功能测试用例组完全可以覆盖UI覆盖用例组。

但是在实际设计过程中，有多少团队能在功能用例中覆盖完UI检查点？
所以，你们公司分开UI/功能，其实是为了防止UI检查点漏测而已。

话虽如此，但是通常情况下，还是会将这两点组合在一起。究其原因，无非是两者都同属于最基础的测试。

故，若能保证基础功能测试用例对UI的覆盖率，则可考虑合并两者；否则，还是老老实实的细分他俩吧。

***********

2.关联用例组
针对你们项目实际耦合度高的情况，这个类别是有必要的。

若无此分类，将会导致1个问题：如A,B交互用例，应该把它放到A的功能用例组，还是放到B的用例组？
通常，系统用例由多个测试员共同设计，这类分工不清晰的用例，很有可能造成已知泄漏和冗余用例。

**********

3.复合用例组
“有的用例觉得是UI同时又是功能同时又是关联的东西”
LZ能举一个实例么？通常，这个问题的原因是此用例未在设计时未进行细分类，也就是用例本身存在问题。

**********