怎么写测试用例是老生常谈了，网上也有很多正式的教程，什么正交法、等价类、因果图、场景法等等，这些方法推荐都深度学习和掌握。本文不是新手教程，不会系统地讲述如何一步步进行，本文主要从不同的切面去分析测试用例设计的工艺和过程，以测试用例设计为起点，但又不止于用例设计，涉及到一些过程控制和项目管理的理念。从微观上分享了用例颗粒度的一些经验，又在宏观上站在团队管理的立场上分析了测试用例库的维护方法。若能对读者有些许的帮助，或者引发更多的思考，已经是非常值得开心的事情了。
如何把握测试用例的颗粒度
作为一线的测试人员，测试用例是每天都要写都要看的，每个人都会有写测试用例的方法和习惯，此处不具体展开讨论方法的优劣，只谈测试用例颗粒度的理念。测试用例颗粒度越大，即每个用例覆盖的feature范围越大，明面上测试的工作量会变小，测试人员会有更多自由发挥时间，例如进行更多的ad hoc测试，但是会有较大的风险，项目质量将严重依赖于测试人员的能力和责任心。测试用例的颗粒度分得越小，测试用例编写和执行的工作量就越大，测试人员容易陷入呆板的机械的执行过程，但是开发越容易复现bug，所以颗粒度需要针对不同场景，具体研发流程，采用不同策略。比如某个项目的人员小李是远近闻名的粗心篓子，那么在测试这个项目时，设计测试用例的时候就要越细越好。另一方面，如果测试用例写的细，开发也认真按照用例写代码（TDD），那么bug就会比较少，产品交付质量会较高，维护成本也会很大，甚至大到无法维护的成本，需要辩证的去看这个事情。
测试用例库是一个持续完善的过程
测试团队需要有一套或者多套持续维护的用例库来对应各种业务测试场景。例如当app常规发布时，需要回归主流程，这样的一套用例库不需要很多。但是假如微信sdk发生变更时测试需要回归全部涉及到微信的场景，这样的用例库势必变得非常庞大，以上两个例子说明，常用的回归用的测试用例库是必要的，也是需要提前做功课准备的。理论上测试用例和bug是相对应的，但有时候也会发现意外的bug，最好能跟开发同学一起排查直到最后确认问题，然后告知对方这个bug需要提交到系统中记录，让对方修复后改状态，然后再去做验证，全部完成后将这个bug的场景补充录入到测试用例库，再根据优先级判断是否排进每次回归的用例集合以及自动化用例集合。在项目不断迭代的过程中，也会有需求变更，那么跟随需求的不断迭代，测试用例也要及时更新，新增和删除，保持“测试用例新鲜”。
利用碎片时间梳理测试用例
测试的时间往往是被各种紧急项目切割的支离破碎，因此需要将各种碎片时间充分利用起来，梳理测试用例或者学习一些自动化知识。梳理测试用例的过程有点类似于打造不同的解决方案。根据不同的场景切面，把分布在各处的测试用例整合在一起。为什么不在项目中进行这些工作呢，因为许多项目往往没有大段的时间让你去梳理测试用例，尤其是一些开发没有工作量，仅需要测试进行回归的项目。所以，提前准备这些测试用例集合，打造你自己的测试解决方案，以备不时之需。
尽量达成完美交付
测试用例要尽量避免错别字，认真对待自己交付的作品，这种低级别的问题要尽量避免，尤其需要当众评审的部分，自己应该反复检查几遍，避免出现纰漏。测试步骤的描述应该条理清晰容易理解，即使换一个人也能按照步骤去执行。最后，测试交付的产出物有测试计划、测试用例、缺陷报告、不同阶段的测试报告，这些就是测试的作品，应该力求完美，换句话说，上级领导能看到的就是这些东西，想要在职场上不断发展，这些东西必须扎扎实实的。
源自公众号 三国测