总结金蝶测试用例的编写

2012-12-13  唐龙远 

     从毕业一直到公司,一直都在做金蝶外包测试,但距离毕业两年的时间里,我好像都在原地踏步,从未想过记一些有用的文档,或是总结一些实际遇到的问题,所以趁这几天时间比较悠闲,总结一下,金蝶测试用例编写的一些具体功能点,以便日后之需。
    
大点一:一个模块的显示内容顺序的编写

1:首先根据需求写出这个模块的路径

2:判断用户是否有权限进入该模块

3A:有权限的用户进入模块后,界面显示的是否与需求显示一致

3B:先写菜单栏,标题栏 显示的内容(注:如用快捷键,访问键,要一并写进去)

3C:如果该界面应显示出左树右表,也应写出各自显示的内容

3D:如果该界面有快速查询字段,也应写出

3E:然后应写序时簿中依次显示的字段

3F:界面中有高级查询按钮的话,也要写出里面的(自定义,排序,表格设置,保存和另存方案及默认方案显示的正确性)

3G:界面中有全选,全清按钮也应写出

3H:界面左下角如要求显示选中笔数,也应写出

大点二:快速查询功能点

     该字段默认值为空,F7按钮,多选

1:用户进入界面该字段应显示为空

2:点击F7,F7显示的正确性

3:选择一条数据后,点击查询,查询出来数据的正确性

4:选择多条数据后,点击查询,查询出来数据的正确性

5:该字段与其他字段共同查询的正确性也应写出

大点三:工具栏上的各个按钮(基本的增删改查),其他按钮应根据具体模块进行编写

新增

1:鼠标点击新增按钮,弹出界面与需求中的界面一致(弹出框,还是标签也应写清楚)

2:根据需求写各个字段的功能点

2A:账号(编码规则启用 、未启用)

a: 当编码规则启用时,账号的显示情况(应擰编码规则里设置的情况显示),当保存后,是否与编码规则设置的一致

b :当编码规则未启用时,账号应默认为空,字符长度,为空时保存,系统的提示(必录项)

2B:F7框

a:新增时,界面是否有默认值,如有,应写出默认值

b:点击F7,F7的过滤条件

c:选择一条(多条)数据后,F7框显示是否正确

d:模糊查询(根据名称,账号)

e:字符长度控制(大于规定长度时,不允许输入,还是保存时再判断)

f:是否必录,点击保存时,系统提示情况

2C:下拉框

a:新增时,界面是否有默认值,如有,应写出默认值的背景色

b:下拉框的取值是否正确

c:是否必录

保存

1:保存时,必录项顺序是否判断正确

2:点击保存时,序时簿字段显示的是否与新增的一致

修改

1:点击修改按钮,界面上显示的是否与保存的一致

2:选择修改一个内容,点击保存,数据是否能保存成功

3:如果修改的内容是否对后面的有影响,也应重点描述

查看

1:选择一条数据,点击查看,数据是否与保存的一致且是否可以修改

2:如果修改后的数据,点击查看,应查看保存的数据是否与修改后的一致

删除

1:删除时,应判断数据是否被引用,被引用的话,弹出提示“数据被引用,不能删除”

2:未被引用,则弹出提示,是或否,点击是,是否删除了,点击否,是否,数据是否还在

大点四:权限,日志,网络互斥

权限

1:权限的路径

2:用户有无该模块,该功能点的权限时,表现情况

日志

1:日志的路径

2:当用户的操作,新增,修改,删除,等等 功能点是否都已被记录,且记录是否正确

网络互斥

1:当一个用户操作修改功能,另一个用户操作该功能时,系统是否提示2:当一个用户释放修改功能后,另一个用户是否能对该功能进行操作

   由于本文是自己总结的,文中有许多不足的地方,还请各位多多指点,嘿嘿

 

 

 

 

 

 

 

 

374°/3724 人阅读/2 条评论 发表评论

庄桂娜  2012-12-18

感觉都是完全按照需求文档来写的用例,其实需求文档只是测试用例的参考,把需求文档拿到手后,你要有测试的一个思维,把需求文档拆分成多个测试粒度,然后以测试方法再设计测试用例,当然测试最好覆盖所有需求,但是需求是需求,开发又是用代码重新诠释了整个需求,里面内在的逻辑,也可跟开发沟通,对测试用例的编写也大有好处的。纯属个人意见,哈哈,请问你是在北京还是深圳的测试


唐龙远  2012-12-28

把需求文档折分成多个测试粒度,总感觉这个粒度不好控制,嘿嘿,我是在重庆工作的!


登录 后发表评论