狂想的世界 发表于 2011-5-27 13:26:55

测试用例的一点想法

最近新换了一家公司，刚好赶上重构测试用例，之前的都是写在excel中的一些功能点提醒，跟常规的用例差别是比较大的，这次重构就是从各个方面进行改变。
首先是选型，从excel和TD中进行选择，最终选择了TD，不管是从哪方面，TD还是专业的工具，excel主要在编写方面会比较方便。
关于本次重构用例，我把之前的工作经验拿过来提了一些建议，大部分被采纳，其实也很简单，是一些常规用例的写法和组织，但是也做了一些变通，今天主要想说下关于用例的一些东西：之前的经验，我们会把用例写的非常细，关于页面校验的、关于流程的、关于单个字段的，都分的很清楚，一个用例只有一个验证点，导致用例的数量非常庞大，写起来也会因为验证点不同而大部分步骤相同产生很多重复的步骤，但是好处在于大家对用例的理解和粒度是一致，无论是谁写出来都是一样的，比较统一；而这次改造中，我把这个想法也说了，大部分也是按照这样去做的，但是由于业务的不同，有些地方实在难以适用，通过讨论，大家得出的结论是大部分用例是根据我说的思想去做，但是部分难以做到的，回到列框架的方法上，列框架的意思就是把规则说清楚，可能更会同知识沉淀有部分类似，不是用例的形式，是描述的形式。那么这样做就必须有一些规定，到底哪些是以传统用例的形式来完成，到底哪些是用描述的形式来完成，定出一个规则，以此来执行。
其实我想表达的意思，测试用例是否真的必须统一？是否可以允许像我这样的形式存在呢？到底用描述规则的方式算不算测试用例呢？我自己的想法：测试用例最大的用途当然是指导测试执行，它还有更多的用途，比如指导新人熟悉业务、方便从需求、开发和测试角度一起来把关对需求的理解，既然是这样，我认为也不一定拘泥于某种形式，而是能达到这些目的就可以了。但是也不能无限制的不拘泥，至少在一个公司内部测试用例必须是统一形式统一管理的。
不知道坛子里的同学对此有怎样不同的观点没有？多谢大家指教！

Nio 发表于 2011-5-27 13:41:06

赞同楼上“用例是用来指导测试”的观点；

用例形式的统一，对于测试管理来说非常有必要； 好处有很多，不统一的的不利之处是一大堆。

你们对于如何编写测试用例，依然没有找到一套行之有效的方法。

月上百合 发表于 2011-5-27 13:53:23

其实可以把公用的模块，写一个公共用例，这样就不用每个用到它的功能都去写一遍了。

狂想的世界 发表于 2011-5-27 15:05:12

回复 3# 月上百合


    这个有做的！也都有想到！不过在当前业务下提取公共的东西真很困难！控件公共吧，但是又跟业务相关联！

狂想的世界 发表于 2011-5-27 15:06:01

回复 2# Nio


    大部分是统一了！但是有小部分真的很难写！是否一定要全部统一呢？这就是我的纠结之处！

Nio 发表于 2011-5-27 15:27:49

建议对这一小部分作下分析或分类，以指导在这些个情况下，该如何编写测试用例。

zhaobinhs 发表于 2011-5-27 15:42:53

我一直都是一个不怎么会写用例的人，虽然业务和功能的流程熟悉，但是写的用例总感觉少点撒，看了楼主和各位版友的谈论，有了一点启示。谢谢各位

愚人 发表于 2011-5-27 22:05:48

百合说的不错

月上百合 发表于 2011-5-30 09:53:19

回复月上百合


    这个有做的！也都有想到！不过在当前业务下提取公共的东西真很困难！控件公共吧， ...
狂想的世界 发表于 2011-5-27 15:05 http://bbs.51testing.com/images/common/back.gif


    我不知道你们具体是什么流程，但是我觉的如果只是在整个流程中都经过的模块，但这个模块并没有过改动，只是在其它功能改造时，走测试流程会通过的模块，这部分可以提取出来做公共，应该没难的吧，个人想法啊。可以讨论下

月上百合 发表于 2011-5-30 09:53:44

百合说的不错
愚人 发表于 2011-5-27 22:05 http://bbs.51testing.com/images/common/back.gif


    鉴定完毕后，来点建议哈

狂想的世界 发表于 2011-5-30 10:51:16

本帖最后由 狂想的世界 于 2011-5-30 10:56 编辑

回复 9# 月上百合


    那我说一个具体的吧：一个查询页面，有23个查询条件，大部分是下拉菜单形式的选择条件，这样一个查询功能模块可能很多地方都有类似的功能，但是可能有的地方是23个这样的条件；有的地方是20个另外的条件，或者有的地方跟a有一部分相同，又有部分不相同，还有同是一个查询条件在a和在b的可选择项又不同，但是总体都是查询功能模块，那么这个怎么抽取呢？

月上百合 发表于 2011-5-30 11:29:48

你这个问题的确是挺头大的哈
哪么献丑下下吧
首先，从大的角度来看，不管是有二十几个还是多少个，总之是做了一件事儿--查询
哪么先分四点：1、查出全部结果，不设任何条件查询；2、查询查询结果检验，即有效条件查询和无效条件查询；3、模糊查询校验
这个根据需求去校验；4、查询与排序条件，校验查询条件与排序是否正确。
在进行单个条件，多个条件组合查询的时候，MS有点复杂，因为在每一个查询页面上的查询条件不同，但是如果说所有的页面加起来的
查询条件最大值有23个，或者多于23个（找个总数）。哪么将最大化的用例写好后，其它页面就算是查询条件数不一样，查询条件不一样，可从你的描述中看A不管是与B，还是与C都是有是有交差部分的。哪把交差部分拿来做公共部分不是也可以吗？当然了，你说的查询条件一样，选项不一样的问题，是不是可以把可选项看成查询结果中去验证，用例中写方法，结果中去验一下可选项，因为我觉的主要还是通过查询条件中的可选项得出结果，然后对结果进行分析验证查询条件的，说的有点绕，不知道讲明白没有

狂想的世界 发表于 2011-5-30 12:26:44

收益了！可能主要问题在于将单个查询条件当做公共是可以的，但是组合可能就比较难做公共了！每个查询中可能组合的情况按照各种状况不一样而不一样，可以考虑只将单个查询条件提取成公共的部分！谢谢赐教~~

月上百合 发表于 2011-5-30 12:28:59

此处只是抛砖啊;P

sakuna 发表于 2011-5-30 14:00:22

一些公共的组件可以写一些公共的用例，但是涉及到具体业务的时候，公共的用例就不太好弄了，有点吃力不讨好的味道，不建议花大力气在这上面。
测试用例的统一是有必要的，但没必要限制太死，毕竟设计用例也是有一些创造性的工作，限制得太死，不利于发挥，至少框架和形式上是要统一的，至于粒度的粗细，其实也是可以控制得到的，比如在方案阶段，设计的工作已经做了相当大一部分，粗细就已经做了一个大致的导向。然后在评审阶段，做得好的话，也能够有效的控制一下粒度
至于TD和excel，我倒觉得excel写起来更快，我们以前就是用excel写好之后再导入QC的，把字段定义好就没有问题，我相信TD也是可以导入的吧:loveliness:这是题外话了。。。

lyliyang 发表于 2011-5-30 23:55:02

菜鸟飘过，看不太懂啊，要多加努力啊

greecewen 发表于 2011-5-31 09:28:55

还没有入门的飘过
页: [1]
查看完整版本: 测试用例的一点想法