每次一说要对比或者评价的时候,我都很担心,怕评价的方面或者结果是”我以为的就是我以为的“这种结果。因此我都查了很多的资料,然后才敢写点东西,我尽我最大的努力让每一篇文章不会又臭又长,我希望花费在我写的文章上的时间也就3分钟,但是我希望这一个内容主题我能说得清楚,讲的明白。
众所周知,测试用例就是用来评估软件系统是否满足了一系列的商业需求而存在的。那么,如果使用了不好的或者是冗余的测试用例无疑就浪费的宝贵的工期,也浪费了公司的成本。所以,好的测试用例应该既能完美的评估商业需求并能达到最小成本消耗。
那么,怎么评价一个测试用例是好的测试用例呢?我告诉你十条准则,通过这十条准则设计的测试用例就会是好的测试用例。
测试用例设计使用了一种科学的测试用例设计方法,例如边界值、等价类、因果图、场景法等方法。这能保障你的测试用例能够更好的接近于最少的测试用例条数达到更大的覆盖结果。
测试用例的简述、描述、测试步骤、期望等都应尽量用简练的语言描述清楚,这样任何一个测试工程师都能使用你的测试用例完成测试并且在阅读测试用力的时候使用了最少的时间学习你的用例流程。
在团队内部建立一套内部统一的命名方法,例如系统简称、方法简称、系统简称、团队简称等,方便团队内部无障碍的传递文档。
测试用例尽量保持原子性,这里所指的原子是指在不合并或重叠多个可测试部分的情况下测试单个功能。
这里所说的是在写测试用力的时候,不要写一个放到哪里都可以使用的测试用例,要写的清晰明了,例如”打开博客首页“最好携程“打开crisschan的博客首页:在浏览器中输入https://blog.csdn.net/crisschan后回车。
没有自以为的前提条件所指在编写测试用力的时候,要站在没有任何自我假设条件的基础之上撰写测试用例,我们不能假设我们被测系统已经有了什么功能或者能力,也不能假设最终用户使用者有了一些假设的知识积累和储备。
不要重复设计测试用例,否则就会到时大量的资源和时间的浪费。
保持测试用例的每一条都是可追溯的,这样我们就可以通过建立测试用例和被测系统的功能之间的映射来查看测试系统的功能是不是都被测试覆盖了。
保持测试用例覆盖被测系统的多个方面,这里既包含了功能正确性,可用性等还包含了性能测试用例、兼容性测试用例等等。
测试中使用的测试数据应尽可能多样化,并尽可能接近显示系统中的使用情况。在测试过程中,使用多样化的测试数据可以使测试用例更加可靠。
以上就是一个好的测试用例评价标准,并且这些是一个基本的标准并不是一个最高标准。十条准则看着很多,但是绝大部分的内容都是我们在测试用例设计中都会遵守的,但是全部遵守的测试用例却并不多,因此我希望这些准则对你来说有一点帮助。