首页 - 通讯 - 浅谈优秀的测试用例

浅谈优秀的测试用例

2023-10-06 12:23
测试工程师有一项非常重要的工作:编写测试用例。测试用例是需求的另一种描述。它可以引导大家进一步加深对系统的理解和对特性的全面关注,从而帮助产品和开发重新审视需求的合理性和一致性,所以测试工程师应该是最重要的一个输出。 一般测试用例分为三部分:输入、行为和预期结果。普通的测试用例可以满足这三部分,但是什么样的测试用例才能算优秀的测试用例呢?根据以往的测试经验,我总结了优秀测试用例的几个特点。 1.正确性:毫无疑问,测试用例必须是对需求的正确描述。但我们经常忘记采取另一步:这是用户正确的需求吗?我曾经有过一个失败的测试用例。当条件输入异常时,系统向前端接口返回-1,然后前端返回错误信息。这就是当时异常处理的需要。但是,如果再想一想,当某个条件出现异常时,我们是不是不能将满足某些条件的结果返回给用户呢?让用户体验更好? 2、完整性:就测试用例本身而言,是无穷无尽的。任何键盘组合都可以算作一个测试用例。一个优秀的测试工程师就是从无穷大中找到最能保证质量和找到bug的测试用例,找到无穷小的集合。通常,查找功能测试用例的最简单方法是等价类和边界值。 ,建议组合使用,先划分等价类,然后在等价类中求边界值。我见过很多在 = 和 >= 之间徘徊的错误。通常正交方法产生的用例太多,因此测试工程师需要组合正交方法的结果。建议结合错误定位方法来减少用例的执行。状态图在数据统计和结算中使用的概率最高。 每个状态和进程都需要一一考虑正常分支和异常分支。可靠的开发本身可以保证流程的正常进行,但异常分支却很少被开发人员考虑清楚。这就是测试工程师价值的体现。但完整性不仅仅是功能测试。除了功能测试之外,还有性能测试、安全测试、兼容性测试、安装友好性测试、区域语言测试和用户体验测试(可用性)。 3、具体输入:对于这三个部分,我们希望是固定的、具体的。例如,对于输入框中的输入,我们可以写具体的“诺基亚”,但不要写“正确输入”或“中文输入”,这些都会导致测试用例的不确定性。模糊输入应该用在具体输入的上层结构中作为测试思路和分类。4. 使用明确的词语:许多词语在不同的场景中有不同的含义。例如,价格一词代表不同表中的不同价格。同一张表中甚至还有原价和售价,所以你应该尽可能具体。描述关键字的具体信息,如果能把原表中的专用id和item粘贴上去,对于避免歧义会有很大帮助。 5. 用例细化:输入的组合,或者一条流程线对应于一个测试用例。尽量不要在一个用例中组合多种情况。为了提高自动化测试脚本的效率,我们会将各种场景合并到一个自动化脚本中。每种情况的输入,然后一个动作,所有的输出都会立即生成。针对这种情况,建议在脚本中将各种输入对应的情况一一记下。这样也方便新人在操作失败时定位问题。 6、判断点准确、明确:我经常看到这样的检查点:“结果正确”和“速度合理”。这些检查点对其他人来说根本没有帮助。因此,应该尝试制作机器可以识别的检查点,例如输出“8”或“rt<30m”。 7.合理划分优先级:Bugfree中有4个优先级,从1到4,其中1表示最重要的测试用例,4表示最不重要的测试用例。不同的缺陷管理平台对优先级的定义不同,但都有优先级的概念。当时间紧迫时,优先级就显得尤为重要。我们会优先执行更重要、对系统功能和用户体验影响更大的测试用例,而将较低级别的测试用例留到以后执行或分配给新人。实施。 奖励积分: 1、用例自动化:自动化脚本的地址可以一一对应。对于淘宝的bugfree,已经接入了自动化框架mmt。测试用例可以直接链接到脚本,以方便对用例的理解。 2.记录每轮的测试结果:对于一些功能测试用例,结果只是简单的通过,我们不需要记录它。然而,对于性能测试结果不确定的测试用例,如果每次测试的结果都能够保留下来用于后续的测试,是非常有帮助的。对于一些fail的用例,如果能和bug有一一对应,对于后续的回归也会非常方便。 3. 提供检查点的逻辑解释:许多用例都有带有结果的检查点,但对于新手来说,他们必须重新阅读需求或设计文档才能理解为什么是这个结果。尤其是对于算法测试来说,理解需求和逻辑是一个比较痛苦的过程。如果你能为每个结果提供一些注释和逻辑解释,这将使你和新人将来更容易理解用例。以上是对测试用例特点的总结。在实际编写测试用例时,mm图自上而下的树形结构对于测试用例的结构和思路会有很大的帮助,同时也方便测试用例评审时的展示。和说明,因此强烈建议将其作为附件上传。而且,对系统的理解越深入,测试用例就能写得越好。很多开发错误导致了这样的认识:测试工程师只需要知道需求,不需要对程序有代码级的理解。然而无数的实践证明,测试工程师更有能力了解系统设计和编码逻辑,有助于发现潜在的bug和风险。 单元测试通常由开发人员完成效率更高,但测试工程师必须在集成测试开始时就开始真正介入。在此期间,可以发现很多潜在的问题。如果把所有的风险都留给系统测试阶段,风险就很大,而且会出现大量的案例。回归和问题定位会变得更加复杂,成本也会更大。因此,如果时间允许,毫无疑问,前期测试越完整,整体效率就越高。 【编辑精选】 牢记测试用例结构 为新模型做准备 浅谈测试用例分析与设计 如何有效减少测试用例数量 软件测试接口测试的测试用例类型