测试用例 编写 高手看哈

chb447

测试用例请求高手帮忙看看
这是个电子钟   比如现在是  晚上10：20  日期是2010.7.6  星期一

10		Pm :	20
2010	july	6		MONDAY

即
                  

小时		上午 /下午 :	分钟
年	月	日	星期

这个测试用例应该怎么写   高手指点   具体一点

shark_jr

强烈建立斑竹将帖子置为精华贴。

shark_jr

2楼的测试设计功力相当深厚啊。

佩佩和群群

学习了

freedom_me

• Jackc 乐于助人 好棒啊         结构化的设计测试用例思路 我辈真是要好好锻炼

Jackc

6、生成最终case
按照整理出的正交表（注意整理的时候查看是否涵盖了W1~W7，如果没有，可增加特殊日期case），逐条生成case。
比如：
Case1
Input：输入2050年1月1日00：00 AM ，等待1分钟
Output：界面显示2050年1月1日00：01 AM，星期六

PS:错误推断和性能case这里就不说明了，错误推断case需要更细致的需求信息（比如哪些编辑框用户可以编辑等等）；性能case往往与平台挂钩，web时钟和终端时钟的性能case区别还是很大的。

小结：
1、拿到模块后，先划分测试单元并分类，分析过程除了正交表以外，判定表、因果法也是不错的选择。

2、无论哪种方法，都需要增删case来满足最终的要求，平时业务知识的积累可以更好帮你完善你的设计。

[ 本帖最后由 Jackc 于 2010-1-25 14:49 编辑 ]

Jackc

4.生成最终测试元素
Y1 =  1901、1999、2050（考虑到千年虫问题，增加一个1999，如果支持3000，

也可以换成2999）
Y2 = 1900、2048
M1= 1、12
M2= 4
M3= 2
D1=1、28
D2=29
D3=30
D4=31
H=0、11
Min=0、59
AP=am、pm

5、生成正交表



1.化简前：


其中粉红色部分是通过等价法，确认需要删除的case；  黑色部分是输入条件非法而删除的case（黑色部分在输入允许的条件下，可以作为错误推断测试的输入条件）；  红色部分是确认需要采用的case。

2.化简后


最终生成上表，一共有22*2*2*2=176个case，但是其中还有一些case需要删除（比如1999是专门为“千年”设计的case，所以1999年12月31日AM 00:00这样的case就没意义，需要删除，又比如12月31日这样的case也是为了设计PM 11：59而引入的，所以，2050年12月31日PM00：00也是没意义的），大约估算了一下，最终应该在130个case左右。

[ 本帖最后由 Jackc 于 2010-1-25 14:15 编辑 ]

Jackc

1.测试目标：
手工部分完成基本功能的覆盖，自动化部分设计N条（1000~5000）数据测试。
假设用例最终执行者为有经验的Tester，测试用例粒度可适当放宽，这样在CASE跑完后可以充分发挥tester自动性，增加case外的测试。

2.提取测试元素：
测试元素有：年/月/日/星期/小时/分/时间段（时间段包括AM和PM）

3.根据实际情况分类：
因为年/月/日存在多种情况，所以分类为：普通年/闰年/大月/小月/2月/1~28号/29号/30号/31号/星期/小时/分/时间段
然后形成初步的测试元素类：
Y1 = 不是闰年 & 1900~2050
Y2 = 闰年 & 1900~2050
M1= 1、3、5、7、8、10、12
M2= 4、6、9、11
M3= 2
D1=1~28
D2=29
D3=30
D4=31
W=1~7
H=0~11
Min=0~59
AP=am&pm

PS：W=1~7 不是输入条件，而是预期结果，所以在设计用例时，需要单独设计日期。

[ 本帖最后由 Jackc 于 2010-1-21 17:36 编辑 ]

Jackc

写用例，除了书上说的几种设计方法，每个人也有自己偏好的套路。比如某些人喜欢用先用边界再用等价，有些人喜欢先等价后再用边界，这些套路都是没有大的区别的，只是个人的逻辑思维方式不同而已。

我说说自己的套路吧：确定测试目标（其实就是确定测试用例的粒度）——提取测试元素——分类（其实就是一个整体的等价法）——针对各类进行分析（主要还是使用等价和边界）——正交表生成用例——根据实际测试环境情况删除部分case——增加错误推断和性能测试用例——使用场景法验证覆盖率（有时不偷懒不做这步）——生成初步测试用例报告——同行评审——归档