TestCase长这个样子, 是不是比较合理?

lifr

简单说来, Testcase就是描述了"步骤"和"期望结果". 但是在具体应该是什么格式, 步骤详细到什么程度, 在各个公司还是很不统一的.

有的重意, 侧重于描述抽象的步骤. 好处是界面变化不太会影响到testcase.
有的重形, 注重步骤的准确和具体, 好处是新手也能很快会测试.

当然, 这两种并不存在某一种是"更好更先进". 到底选用哪一种, 很大程度是testcase 部门的开创者决定. 后来者只有follow的份了, 没有谁会亢奋到把堆积如山的testcase都按照自己喜欢的格式重写一遍.

其实到底选用哪一种对软件测试的效果影响也相当有限, 至少我是这样认为的. 软件测试的效果更大程度上还是由"testcase结构"和"测试人员的能力"决定. testcase形式神马的都是浮云....

但是, 讨论Testcase长什么样我觉得也不是没有意义, 我的意思是如果testcase能够"形意"兼备岂不是更好.

传统的testcase大概是这个样子(  不影响讨论的地方我都省略了, 比如precondition等)
Title: XXXXX

Steps:  
steps                    |checkpoints
-----------------------------------
1. xxxx                 | checkpoint 1
2. yyyy                  | N/A
3. zzzz                  | checkpoint2


如果要testcase做到"形意兼备", 只需要一个小小的变化

Title: XXXXX

Steps:  
steps       |Operation             |checkpoints
---------------------------------------------
1. xxxx    |opt1,2,3               | checkpoint 1
2. yyyy     |opt1,2,3               | N/A
3. zzzz     |opt1,2,3               | checkpoint2

只需要增加一个column "Operation"来表述具体的操作步骤. 而以前的steps只用来描述抽象的操作步骤.
而且并不是每一个步骤都有Operation, 如果足够简单的步骤, 完全可以省略

这种形式有下面一些好处
1. 形意兼备
2. 不会显著增加testcase创建者的负担
因为简单的步骤是可以不写具体步骤的, 一般来说复杂的需要些具体步骤的只是一小部分.
3. 在阅读的时候即能一目了然, 也能了解细节
比如老手可以把Operation这个column隐藏. 新手打开这个column也能获得自己需要的操作步骤


总的来说, 这个变化没有什么神奇之处, 任何人只要稍一琢磨也能想到. 但奇怪的是, 我还没有看到某个公司使用这种格式(如果你正在使用这样的格式,请恕我孤陋寡闻, 我看过的应该不超过10个样本). 或许是不需要改变, 或许是难以改变固有的习惯, 或许是这种方式本身会带来问题...

希望听到你的意见.

Jackc

LZ的见解的很新颖，赞一个。

首先，用例的设计出发点是“使用”. 怎么使用用例，决定用例怎样设计，自然用例格式也在其中。

LZ的方法中涉及一个问题：单个用例单元的定义

传统的用例设计思想是“测试目的决定用例单元划分”。而测试目的不可能盲目扩大，所以常使用前置环境来规范。即前置环境不同，则属于不同用例。

但是目前，随着用例的实践使用，用例设计者也根据实际情况对原有的基本用例设计格式做了一些修改。如，将测试数据从测试步骤中提取出来，组成独立的用例属性。

————————————————————————————————

其实LZ的设计思想和公共用例设计差不多。只改变前置环境，而其他部分则套用相同的用例其他属性（如步骤或预期输出）。
——————————————————————————————————
最后，LZ的用例格式是否合理，取决于LZ实际的测试目标。
若LZ测试目标的环境搭建比较复杂，则LZ新的用例模板具有可行性。若测试目标只是简单的环境搭建，则显得较为臃肿了。

Yr-Test

用例模板只要大体不变根据不同软件性质设置不同格式是有必要的。不需要有固定的标准，适合测试提高效率是最好的。

Yr-Test

用例模板只要大体不变根据不同软件性质设置不同格式是有必要的。不需要有固定的标准，适合测试提高效率是最好的。

lifr

我赞同用例模板"适合的就是最好的". 有些测试案例复杂, 有些简单, 不能一刀切.

不过从一个更普遍的角度, 或者说从"测试管理工具提供者"的角度, 应该可以有一种更灵活的"机制"来适应对测试步骤描述的要求.

之所有有这样的想法. 是由一个testcase的设计引起的.

现有的testcase步骤描述部分是excel里的一个cell.所以它引导这样来写testcase的步骤
1. 创建用户
2. 修改某一个设置
3. 转到dashboard页面
4. 检查某个view的现实是这个样子的

当然你也可以写得很详细
1. 点击"xxx"按钮, 进入yyy页面, 输入zzz...
2. 点击"edit"按钮, 在mm控件, 输入值"nnn"
....

这里的问题是, 到底是详细好还是简略好? 我的想法是testcase管理工具应该提供这种灵活性. 具体选用哪一种由testcase的设计者来决定.

Yr-Test

to 5楼
个人觉得设计者有必要考虑下针对的执行人。

mazhaohui

回复 6# Yr-Test

mazhaohui

赞同一楼的观点

biaoge0

自己设计自己执行就简略一点，别人或新手执行就详细点比较好

凤凰山

貌似有些简洁