好用例Vs坏用例

测试用例是测试部门应该输出的最关键文档之一。敏捷开发提倡轻文档重交流,很多传统流程中的文档都可以省去,但我认为测试用例不在这个可以省去的文档之列。相反,测试用例在某种程度上可以替代详细设计和概要设计文档,作为一个接口性质的文档。


相比于可以运行的代码,文档的优势是可读性,换个词就是用户体验。好的文档可以帮助人更好的思考,老话说的好,好记性不如好文档。测试用例文档的写作目的一定是为了帮助你和你的团队更好的思考。因此,这里提出第一个观点好的测试用例一定是以用户为中心的;坏的测试用例通常是以技术为中心的。

如何定义用户呢?用户可分为公司内部用户及外部用户,鉴于顾客是上帝的道理,测试部应该以最终用户的代理定义部门功能。因此,我的第二个观点好的测试用例基于产品功能的用户体验;坏的用例通常基于功能的代码实现。

如何在用例中体现出用户体验呢?一个测试用例的基本骨架由3部分内容组成:{测试步骤,输入数据,观察点}。在测试步骤的设计中,首要需要考虑的是用户的使用场景。因此,我的第三个观点:好的测试用例应按照使用场景来组织;坏的测试用例通常按照程序员的修改点组织。


一个优秀的团队一定是一个有积累的团队。打造一个后辈可以站在前辈肩膀上不断攀登的团队,组织才能够冲刺更高的目标。优秀的组织应该是开放竞争的,激励先来着人不断探索和开拓新工具新方法,帮助后来者迅速融入和接受现有工具和现有方法。因此,我的第四个观点:不应该以是否可以脚本化来取舍测试用例,不能因为测试条件艰难而故意漏用例,好的测试用例按照需求挑选工具;坏的测试用例按照工具规避用例。

测试用例作为一篇文档,必须注意格式和可读性。文档格式不但要统一,而且应该要体现规律和逻辑,详简安排得当,测试点均匀的分布,冗余少。因此,我的第五个观点:好的用例结构是平衡的,层次清晰;坏的用例忽长忽短,整篇文挡组织无规律可循。

测试环境的搭建,往往是测试执行过程中最耗时最麻烦的一个环节,用例作为一个测试执行的指导说明,必须考虑测试执行过程中环境的易得性。因此我的第六个观点:好的用例测试按照深层的技术实现,搭建至简最优的测试环境;坏的测试用例照搬用户环境。

测试用例是一个寻需要保持更新的文档,应该定期将修改点,网上问题,测试中发现的问题等内容补充进去,并保持自动化甲苯和用例的同步。因此我的第七个观点:好的测试用例容易维护,可以持续发现问题;坏的用例维护困难,很快会失去价值,变成垃圾文挡。


原创文章,作者:3628473679,如若转载,请注明出处:https://blog.ytso.com/tech/opensource/192128.html

(0)
上一篇 2021年11月14日 23:06
下一篇 2021年11月14日 23:06

相关推荐

发表回复

登录后才能评论