我觉得我们应该换个角度思考：这些体现的是我们测试人员的专业能力和基本素养，没有惰性可言，必须做到。

说白了一切靠人，流程需求再清晰 人不执行到位 都白搭

那就不算上恒温说的 “惰性”，测试时间经常被无故压缩，领导不重视测试，这些怎么执行到位？

说是这么说，那项目紧急，测试时间压缩，研发延后，需求问题等等，等详细的写完测试用例，黄花菜都凉了

百分 99% 的公司做不到，就一个不给你测试分析排工作量就够了

道理大家都懂，给点实战案例、用例模板

之前团队会给排时间做用例优化的工作，版本迭代间隙，除了做下个迭代的需求分析用例设计，也还可以有时间做用例优化，产品用例的质量一直都不错。但是随着任务越来越多，这个时间就被压缩了，用例的质量也越来越差。后面领导也不提用例优化了，能把版本测试任务干完就不错了。有时候不是不想做，而是没有时间做。

可以用代码覆盖率来限制

理想主义者

晚点我开一个新话题。

是靠人，所以我们更要体现我们的专业，这些都是保障质量的基本要求，质量好了，测试才有地位。

第 5、6、7 点就是为我们争取时间的。现阶段不需要所有点都要做到，最佳实践是我们的目标，想办法达成，一项一项地落实，测试会慢慢提升地位的。

不需要详细，反而需要力求简洁，只要求清晰、覆盖，第 5、6、7 点就是为了节约时间。

先争取做到专业，提升质量，再慢慢给团队宣传质量思想，稍微有点质量意识的团队不可能完全不给时间写用例。

如果我说我已经几年没写过测试用例了， 大家是什么感觉 。 一个是我一直测试的模块比较特殊，都是可以自动化的，所以我的代码就是测试用例。 再一个也是因为忙起来没那个功夫和心情老老实实的写用例， 直接就上手写代码。

我看高职级的测试或者测开都基本没有写用例的吧，大部分都是写测试策略定测试方案，把控一些大方向，或者带一个测试小团队承接一个大的专项测试之类的

也不全是， 只要不是纯管理岗， 就还是需要去执行一些测试工作的。 现在一些难度比较大 ，或者很底层的一些测试， 都是找高阶的测试开发人员去测的。 等把平台工具都建设好了， 才会交给其他人。

这些不是规矩，是测试人的工作方法。

承接上面的用例设计话题。

用例设计是给自己看和给别人看的（保证思路和场景正确，没有明显漏覆盖），而具体的用例细节可能只有测试自己知道。我还是很支持提前做用例设计，如果上手就是直接开测，那大概率是场景逻辑的分支不会很繁乱，这种情况下不设计其实也没事。

我是低级测试，我也不写用例，都是熟悉需求直接转化成代码自动化

哎，有点破防了。
想我第一年，被领导要求一周要测 500 条历史用例，其实 P 问题都测不出来。

还好，我现在跳出来了。我一年连代码都没写，就写了几篇 PPT，提了不到 10 个需求。
偶尔去 DISS 研发不够卷，做的东西不够完善。
不用再在这些无关紧要的 P 事上再浪费时间了。

这个世界有太多不确定的问题值得去看去学习去研究，为什么非要自己把自己变成工具人。。。

现在很多人都这样吧， 虽然我在大厂但流程也没那么规范。 都是怎么快怎么来， 用例评审都很少别说写用例了。 直接写代码更符合我们的喜好。 而且一个人可能对着十几二十几个研发的， 哪有时间写用例。

这个用例的含义可以更宽泛一点，比如说测试思路，测试范围，编辑用例的时间其实很难有保证。可能是我的工作没有那么理想，多数情况下，我都很少有时间可以去写用例，希望你能坚持执行，落实下去。能够一直落实下去我觉得确实是很了不起的。

我来说点我实际工作中的：

无论功能大小，能不写测试用例就不写。
测试用例一般没时间严格和完整的执行。
长期的项目，测试用例也没有持续维护。
压根儿不使用版本控制软件对测试用例进行版本控制。
一切为了统计需要。
测试点列列就差不多了，规则穿肠过，用例心中留。
能录制就不代码，能代码就不再写一遍用例。
根据优先级和风险应对紧急发布。

无脑用爱发电义务免费加班是吧？然后完事后找更便宜的来替代你

现在主流大厂是这样的吗，我自己算个中厂测试吧好像也没说不需要写用例了，绝大部分还是围绕用例进行测试的

你体会一下一个人同时负责几个产品，对着 20 几个开发就明白了。 根本没那个心情和时间写用例，就是直接上。 或者简单写写 checklist 或者思维导图。

而且我自己也比较特殊， 现在需要我动手测试的都是很底层的东西， 没有图形界面，都是用代码测的。 所以写个鬼的用例， 我的代码就是用例。

我们先明确，这些是工作方法，是要帮助测试这个岗位做得更好的。你不用也可以，但大概率你的工作也会做得不好，对团队、对自己都没有什么好处。不写测试用例，你绝不可能保证测试的充分性，也就无法保证质量，结果就是工作没做好，相关联的就是绩效不好。就好比期末考试，掌握方法才能复习得更快更好，才能考高分，结果你说我从来不复习，那怎么能考得好呢。

需要协作就写，不需要协作就随意，这有啥对错好争的

目前从业经历，写用例只在时间充分的时候写过，占比可能不到 10%。想快速上线，用例只在大脑里快速设计，写到一个文本里把控大方向，细节测试的时候考虑。楼主 “最佳实践” 做标题，可是落地执行了个一年半载？

有理想是对的，
可是当你有像我一样的经历，
任务越来越多 测试时间却越来越少，
而我什么都不能拒绝什么都得妥协时，
你就知道随机应变有多么重要

这东西，说白了，就是在测试有话语权的时候可以执行，对保障项目质量、新人快速熟悉项目以及体现测试专业性有那么一点用处。
一旦业务不行了，或者上面换了不重视质量的领导，根本不给时间，再想在测试团队推这些东西，下面的人就想把你干掉了。

我的一些经历和现状：很多都是测试接到需求，到交付的时间，只有一周的时间。而且这样的测试任务并行多个；迭代频率高，测试交付周期短，实际测试工作用思维导图做下测试分析，明确测试的范围、测试点、标注侧重点。所谓的最佳测试用例实践，没有统一答案，实际情况不同，最佳测试用例实践就不同。就像有人说 php 是最好的编程语言，也是一样的道理。

“应该尽量设计通用的测试用例，避免过于细致的描述。”
这条就不对，测试用例是根据需求容量和测试投入来确定范围的，而不是尽量设计通用的测试用例，不知道是啥意思。
避免过于细致的描述也不对，测试用例应该是具体可执行的，最理想的情况是在多人协作场景下，写用例和执行用例可以不是同一个人，而且比同一个人完成写用例 + 执行用例的工时不会显著增加。这才是写测试用例的价值之一。

针对你提到的这一条，可以举一个简单的例子说明。比如现在要测试销售订单列表的搜索功能。
其中的一条用例，操作步骤可以这样写：
点击销售订单图标，进入销售订单列表，点击搜索框，输入订单编号，回车，观察结果是否正确。

上面这种写法就是没有通用性、描述过于细致的写法。

如果采用通用的、避免描述过于细致的写法，可以这样写：
进入单据列表，点击搜索框，输入单据编号，回车，观察结果是否正确。

使用这种写法，屏蔽具体的单据类型，对执行用例并无影响，但是用例具有通用性。比如下次你要测试采购订单列表的搜索功能的时候，这条用例是可以直接复制、不做修改就可以直接使用的。

这种方式本质上也是写测试用例，只是写的程度不同，而不是不写。最佳实践只是目标，比如最佳成绩是全科满分，但是做不到，可以取舍，但是要朝着这个目标前进。

争论没有多大的意义，针对于当时当下，在各种条件下，处理的方式都不一样，所要达到的目的也可能不一样，纠结于某项内容过程中的产物，没有多大的意义，最终在规则之下可以 “贪婪” 的达到最后的目的（结果）才是王道

针对第一条，无论功能大小，必须写测试用例，我理解是针对复杂度低的功能，走下流程就行，复杂度高的功能，就需要做用例设计。那怎么评价功能的复杂度，这就需要做测试设计，所以个人理解，无论功能大小，必须做测试设计。而测试设计是为了解决两个问题，1，测试范围是什么？2，怎么测？

测试用例写的详细自己都不想看，感觉臃肿，写的简洁了，协调人员来进行测试的时候表示写简单了看不懂

我说的就是这个问题，实际上应该更为具体，比如写明具体的订单编号（通过这个订单编号依赖于之前的用例生成），或者指明订单的特性，比如 “最近一周的订单”。只有这样具体的测试用例才是有可能把用例编写和执行解耦的。

为什么要强调编写和执行解耦？这会带来很多收益，例如：

1. 可以把用例编写和执行拆分更小的工时单元，可以更灵活的安排排期。避免忙的时候忙死，闲的时候没事干。
2. 用例编写执行可以分给不同的人做，典型的是正职员工写用例，外包执行。

这就是大厂里面重业务逻辑测试部门在推进的事情，也是为了降本增效。当然客观的讲这个事情实际不是这么理想的，执行用例的人还是会有熟悉需求的成本，意愿上也不太愿意纯执行别人写的用例。但这个事情在领导层面看来有上面提到的收益，就会推进。

其实写不写用例也是一个看 ROI 的事情，写用例无疑会有很大的成本，只有尽可能多的扩充收益，才能把这个事情推动下去。

更为具体的代价是更大的成本，得不偿失。以我举的例子来说，这样写并不影响执行人对用例的理解，用例依然是可理解的、可执行的。

说的很好,但是实际就是压根不可能,首先,通用用例这个东西就很难评,仔细被嫌冗余,简单看不懂;再者测试时间不够,除非公司测试地位高不然不显示

永远不要自说自话，多问几个人，问问他们测试任务充足的情况下是否还愿意持续性付出额外精力去实现这 8 条规则（现在还仅是用例范围），规则也是需要适应现实的

题主从业时间多久？大大小小的公司经历过几个？不同业务类型的项目是否有亲身接触？
首先肯定用例的重要性，其次还是得认可测试在产研侧的弱势，
题主的最佳实践我想各位从业十来年的多多少少都经历过，最后能从一而终的能有几个？

通用用例不用评，是指导方法，指导我们应该这样去做，因为这样可以节约我们的时间。通用用例、使用模板、抽象出公共用例，这些都是方便我们写测试用例的，不用谁来评价。

我从业五年了，呆过三家公司，做过手机这样长周期的项目，也做过敏捷迭代的 Web 项目，名下挂的需求从不少于 50 个的情况也经历过。很庆幸，我呆的三家公司，没有哪一家不重视用例的。我只是谈我的经验总结，不管我在哪家公司，我都会这样去做。用例都不写的团队，我觉得不可能有长期的高质量。

我们不要单纯地去看这些规则，好像规则是要束缚我们。作为测试人员，我们的终极目标是保证质量，我的原意是这些规则是为高质量服务的，遵守这些规则，我们能更快地编写用例，而用例是持续高质量的保证。也不是 8 条规则必须完全遵守，也不是只有 8 条规则，大家可以交流补充，根据具体情况有所取舍。但是这些规则，总归是能帮助我们更容易地实现目标。