测试工作要适度，不要过度

最新推荐文章于 2024-09-25 17:00:10 发布

软件测试君

最新推荐文章于 2024-09-25 17:00:10 发布

阅读量136

点赞数

分类专栏：职场经验程序员软件测试文章标签：自动化测试软件测试测试工具 python pytest

本文链接：https://blog.csdn.net/AI_Green/article/details/129390204

版权

软件测试同时被 3 个专栏收录

2091 篇文章 117 订阅

订阅专栏

程序员

2067 篇文章 51 订阅

订阅专栏

职场经验

797 篇文章 1 订阅

订阅专栏

文章探讨了互联网项目中产品需求文档（PRD）的三种形式，指出详细文档的维护成本高，而过于简化的文档可能导致信息不足。对于测试用例，作者认为过度详细的用例维护繁琐且不一定有助于新人理解业务，提倡简化用例并优化目录结构。此外，文章还讨论了过度回归测试和过度自动化的问题，建议根据功能依赖性选择回归范围，并谨慎选择自动化测试的对象，以提高效率。

摘要由CSDN通过智能技术生成

我所经历过的项目中有过几种很有代表性的PRD(product requirement document的简称，即产品需求文档)：

1、很详细的文档，详细到会定义一个链接是新开一个tab还是在原tab打开，告诉你你想知道的一切信息；

2、包含了产品主要功能流程的文档，会以流程图辅助说明，不会太细化，细节性的内容更多要通过交流和讨论获取；

3、一封邮件说明或直接几个人讨论决定。

特别对于互联网项目，需求变更频繁，需求信息巨多，对于PM(产品经理)来说，完成一篇很详细的文档需要的时间不说，每次的需求变更或评审后的需求漏洞都需要更新到PRD中，对于测试人员而言，需要重新阅读PRD中改动的部分，而且详细的需求就需要更详细的用例来覆盖，是否有必要这么详细的文档呢?对于互联网项目能保持一年不大改都是少有的了，我们是否有必要考虑下不为文档所累呢。

详细的测试用例会拖累我们

以前我的观点一直都是秉承着一个基准来要求我自己和团队其他人来写用例：让不懂业务的人也能顺手拈来执行用例。而在后来的一段时间，用例维护起来竟是如此头疼，每次更新详细的测试步骤和结果都需要大量的时间，而且发现项目中很少有让一个不熟悉业务的人来执行这些用例的时候，即便是新人来了看着用例仍然比较迷惑，仍然会多次询问详细的业务，发现还是PRD看着更系统更有逻辑条例，能更快的了解业务内容。毕竟看着用例，我们仿佛执行了40，50条用例仍然在一个功能上，根本不能跟其他功能串起来，对于业务的熟悉是多大的阻碍啊。我觉得从宏观到微观再到宏观才是正确之道。而对于测试技能则更需要导师指导，并不能从用例中掌握太多东西，除了考虑问题的周密性外。

之前在维护用例的目录时也有过度维护的情况，比如有AB两个页面都有一个子功能C，每次回归测试时需要对AB两个页面上功能进行回归，避免遗漏，就把C对于的用例都copy到AB两个目录下了，那么每次更新维护时也都需要维护多份，重复的工作可想而知。

在这里插入图片描述

如何让用例不拖累我们呢？

标题能说明的就无需步骤和结果，内容太多实在是放不下的时候再有详细步骤和结果说明，可以以附件形式上传excel表格的多条用例，不要为了规范而规范，而且用例多是给测试执行人员使用的，不是为了让新人了解业务而存在的。目录结果过于臃肿的再优化，比如C有专门的目录存放用例，AB下建个目录仅说明有C这项功能，好比是linux下的软链接，原来那种方式连硬链接都不如，它不能同步更新(PS.我们使用的是QC管理用例)。

过度设计的用例会降低我们的效率

你是否遇到过这样的情况，比如有三个输入框，但是没有很强的逻辑关联，只不过他们是必填项决定着是否能成功提交，如果设计出8个case来覆盖是必填项这个条件才够放心的话，对于有更多的输入框时我们是否会崩溃掉呢？

另外一种情况，比如需要调用第三方分享，就说微博吧，我们是否需要覆盖含有特殊字符的文字内容能否成功分享，超长文本内容能否成功分享？

上面这两种很显然是过度设计，我们完全没有必要为了这类等价类边界值的case用判定表方式来完成，像这类型很简单的页面控件，应该编写好统一的测试用例集，不同的也就是字符长度限制了。我们也没有必要花心思来测试第三方软件。当然工作中可能还有很多类似这样过度设计的案例，工作经验比较足的人都能从过往中总结出我们更有效的测试思路。