零基础学软件测试 2019-08-16
一、什么是一份好的用例
能和客户达成需求共识,就是一份好的用例!
二、避免用例驱动的常见坑
1.客户没有能力阅读用例
解决方法:放弃编写用例,改回用户容易看的传统方式。例如做原型图
2.团队没有能力实现用例驱动
如果开发团队在设计与测试时,根本不依照用例细节驱动,那用例对开发团队就只是个摆设,花瓶。
解决方法:对设计、测试人员进行用例驱动的培训,如果事不可为就干脆放弃,怎么省事怎么做。换用户故事?
3.在用例中描述系统内部工作
开发人员常把用例当作设计文档来写,如“系统将销售信息写入数据库”,实际上应该写的是“系统记录销售”。
解决方法:站在客户的角度,把系统视为黑盒,删除所有内部设计描述。
4.在用例中描述界面
如果在意用户信息包括了姓名和密码,可以在词汇表里记录,而用例写成--显示<用户信息>。
5.在用例中越出系统边界描述整个业务流程
要建立的系统只是整个业务流程里的一部,善良的需求人员为了大家清楚来龙去脉,将系统外的处理步骤也写进了用例的情景。
解决方法:开户的描述应该放到用例的前置条件中。前置与后置条件是说明系统边界外的业务流程的好地方。
6.过多的扩展事件和异常事件流
即使是受过训练的程序员,2a,3b1看多了也要晕掉,记住阅读者是人而不是机器。
解决方法:
1.如果逻辑不多,可以一句话讲完,不影响主场景的,不建议新起一个事件流。
2.可以使用活动图来辅助说明。在RSM7.0的模版里,每个用例都会带上一个活动图。
7.过多的关系
“不要花一个月的时间去讨论应该include还是extend”。大家对include,extendandgeneralize都不熟悉,那就干脆都不要用了。
一个正交法设计测试用例的案例研究1992年AT&T发表了一篇讲述在测试过程中使用正交表一个案例研究。据测试负责人估计,如果AT&T采用1000个测试用例的 测试计划,可能仅仅只发现这些缺陷中的32个。