认识达内从这里开始

测试用例是软件测试程序员在日常工作中经常会用到的一个测试工具，今天我们就通过案例分析来简单了解一下，测试用例应用都需要注意哪些问题。

一、问题产生的原因，它的频率是什么?

EX1——如果问题是因为开发人员错手把一段代码注释，或者因为各种笔误产生的缺陷，发现之后修改代码重新编译，问题解决。

那么这种问题的概率就是一次性的。这个缺陷修复后，再次出现的概率就非常小——除非这代码是别人留下来的，然后换个开发，又胆大的修改了一些老代码。然后自己的组长还没有代码审核，直接提交了。那么这问题才有可能重见天日。正常针对这种情况，是没有必要写上几条case，后续的项目每次都执行的。

EX2——有一个资源，多个模块都会调用，而且这几个模块业务逻辑耦合的较为紧密，而且联调一直做的不好，甚至因为解决缺陷还发生过多次扯皮到底是你的我的他的等破事儿。

那么这种问题应该是有概率出现的。这个缺陷修复后，不仅仅这条缺陷产生的操作后续要增补，甚至这几个模块调用资源的一些方法，之前没有太过注意，后续也要适当的加强测试设计。

二、问题涉及的组件、分支流、版本多少情况?

EX3——在嵌入式设备中，“兖”字无法显示，显示为“口”。问题的原因是在嵌入式设备内存较小时，可能字库采用的是一级字库，那么可能所有的二级字库的文字都会显示异常。

2.1、具有性：

如果全公司使用的都是统一的font字库。那么只更新这个font，所有嵌入式设备的二级字库问题都会得到解决，这个缺陷一次性修复后，就不需要纳入到测试用例。

2.2、存在多分支：

有好多的外包项目，要显示不同字体、不同国家的语言，简而言之就是有好多的分支font存在。

2.A、如果有好的全面的缺陷分析和波及通知方式，大家各自修复，也不需要写到测试用例中，因为是一次性的行为。

2.B、如果有一定的缺陷知会方式，不同的分支流可以感知，但是时效性较差，那么这事儿就要固化在测试用例中，执行上一段时间。

2.C、如果没有一定高度的缺陷知会方式，大家基于一个流，后续各自开发维护，那么肯定要写在测试用例中，甚至要组织小的专项测试，来集中暴露不同版本的问题。

三、是否有强顺序依赖关系?

EX4——如果一个问题，和业务逻辑顺序强相关，需要经过必须的1、2、3、4、5等步骤，才会导致一个必然的bug。从测试人员的本职工作来说，能发现这样的bug(俗称神级bug)，简直是自己对业务知识了如指掌的好表现，甚至可以作为自己的江湖轶事不断的吹嘘下去。

但是，这种bug，回归测试之后，真心不用把它形成测试用例，让后面每一个项目，都去反复的执行——强业务顺序关系修复了，后续自然不会出现。至于是否有其他隐含的逻辑，是否需要进行其他的分支状态测试，那是另外一回事儿。

四、验证条件具不具备?

EX5——各种复杂的外厂商对通问题。

此类的bug，多是在现场，通过抓包分析、码流分析，然后不停的替换临时版本才能修复。如果是协议标准化方面，可以在测试环节加强，如果是各厂家飞速发展中产生的非标协议，谁也没办法，只能现场解决。

所以，你可以写一条，A设备，需要接入甲厂家的XXX产品/乙厂家的YYY产品，进行ZZZ功能测试。但是，这些测试用例，不具备可执行性。

对于此类的互联互通问题，好的解决方案是，找到一个设备型号很多的客户，维系好客户关系，发布新产品的时候，自己带台设备过去，联调就搞定了。

这个例子需要的是此类问题的测试策略和方案，而不是生硬的补充无法执行的测试用例。

EX6——长时间运行后导致的问题，比如XX设备运行三年后，器件老化，或者版本、文件无故丢失。

这就分别涉及了可靠性和flash反复读取，碎片和黑天鹅事件等。

测试这类的问题，要在短时间内模拟三年的效果，只能是通过上测试设备量，以及通过公式推导大概的稳定性。写在测试用例里面，在日常的工作中，显然是无法实现的，还不如老老实实的做专项测试，集中人力、设备等等。把此类问题一次性搞定。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。