一、测试方法总概
谈到测试用例设计方法,大多数人会说我知道或我理解了而且会用,而且知道各方法设计用例有何好处,并且告诉我很多设计方法什么等价类、边界值、因果图、判定表、正交实验法、功能图法、判定表等各种设计方法,但要做到灵活而且有效的应用,还是经过千锤百炼的,否则修炼出来的都不会是真经,甚至说还停留在套用方法的基础上,所以能做到思路清晰且有效的设计完整的测试用例,其实真不是一件简单的事情。
二、怎样根据实际需求选择合适的设计方法
说到这里,很多人很自豪的说,我在用例设计时用的方法真多,而且每个点都去用,而且写的用例真全,但你可能么仔细思考过,是否方法都做大了有效应用,尤其是等价类、因果图、正交试验法的应用在选择上要特别注意,像正交表这种可供针对多因素多水平的正交表有多张,这就需要你通过仔细思考才能做出选择,随心所欲是不可能得到最佳用例的,在我所做的项目中,针对出现的bug做分类整理,发现某个bug缺乏对应用例,如果是你这样,你会联想到什么,是思路不清晰还是方法用了但没用好,如最简单的用户名、密码、邮箱3个输入框让你设计登录用例让你设计用例,你会用什么方法,正交试验法、还是功能图法,如果用正交实验法,结果如下表:
因素实验号 | 用户名 | 密码 | 邮箱 |
1 | 1 | 1 | 1 |
2 | 1 | 2 | 2 |
3 | 2 | 1 | 2 |
4 | 2 | 2 | 1 |
说明:
x 1、x2、x3分别代表用户名、密码、邮箱3个因素;
1、2代表填与不填;
从理论上讲你这样设计没有问题,针对多输入情况使用这种方法没错,但是从实际出发,没有考虑完全输入为空情况,另外有效用户名和无效用户名,如果这样设计又要划分等价类,即有效和无效等价类,无效等价类又可细分为英文无效用户名和中文无效用户名,层层细分出现无限多个用例,针对上面提出的问题,你会说是测试思路问题还是方法应用问题了,如果你用例正交法没有等价类划分说明是方法应用问题,而方法都应用还是有问题,说明是你思路问题,没考虑足够完善,所以说要设计完整且有效的用例真是一件不容易的事情,在当今软件界没有哪个系统没有权限管理,权限管理是很复杂的,存在多因素多结果的情况,这个时候你会想到因果图或判定表,需求如下,根据角色、资源类型、操作为用户授权,角色分策略又可以分当前角色及当前及上级角色,这里很显然你会用因果图或判定表去做,这里用判断表来做,因果图会转化为判定表的(要不要因果图看实际情况),结果如下:
动作桩 | 角色策略 | 本角色 | 本角色及上级 |
资源 | B | B | |
操作 | 修改 | 修改 | |
操作桩 | 本角色修改 | yes | yes |
本角色上级角色修改 | no | yes | |
本角色下级角色修改 | no | no | |
本角色修改 | no | no | |
本角色上级角色其它操作 | no | no | |
本角色下级角色其它操作 | no | no | |
本角色操作其它资源 | no | no | |
如果考虑操作级别用例会更多,示例 |
以上,希望大家提出宝贵意见,如果有更新颖的实际方法,欢迎交流,毕竟吸取别人的长处补充自己的短处才能前进,做在井里看到的天空毕竟是有限的,这里只是结合个人实际经验,谈一些实在的,理论是不变的,思维是变化的;
三、浅谈测试套件的用法
有时在设计用例时,针对单个需求用例设计没有问题,但如果出现多个需求交错,会发现用例的组织相对比较混乱,尤其是针对功能用例,怎么样避免混乱给自己清晰的思路,这里推荐大家用测试套件这个东西,它能有效的组织测试用例,在功能测试中可能是以模块或功能相对独立的一起划分一个小单元,你可以安照模块或单元来组织你系统的测试套件,保持你的思路比较清晰,在每个小单元下去再细分,按照一定的思路去组织用例,思路清晰应该会降低问题的出现频率;
四、总结
理论学习是首要的,把理论变为实际才是最重要的,在工作中做到理论的有效应用,同时把理论升华,抽象出自己的东西,再次应用到工作中提高工作效率,提高质量!
(以上言论仅代表作者的个人观点,不代表51Testing观点)
版权声明:本文出自zoulunbing的51Testing软件测试博客:http://www.51testing.com/?78859
原创作品,转载时请务必以超链接形式标明本文原始出处、作者信息和本声明,否则将追究法律责任。