作为一名测试工程师，写测试用例作为一项最最基本的技能谁不会啊！但就是这最基本的技能也会存在很多问题，今天就跟大家分享下写测试用例这件事情上存在的的一些问题和对应的思考：

1. 为什么要写测试用例啊，测试用例有那么重要吗？
2. 写测试用例一般会落入什么套路和陷阱呢？
3. 什么样的测试用例才算是好的？
4. 怎么才能写好测试用例？

首先说下我对测试用例是什么的看法。设计编写测试用例类比于开发编写代码，是一个测试工程师最基本的技能输出。一个测试用例都写不出来或者写的乱七八糟的测试工程师肯定不是合格的。套用一句老话“字是门面”，同样测试用例也是体现一个测试工程师基本功是否扎实的门面。在负责测试工程师招聘面试和培训的这几年里，我的面试套路是首先考察应聘者的也是测试用例编写的能力，一般都在面试的当场就会考察应聘者在需求理解、测试用例设计和编写方面的临场应变思考和梳理能力。扎实的测试用例设计能力是通过面试的基础。

其次说下测试用例有哪些重要的作用。还拿开发写代码对比下，没有代码需求功能肯定是无法实现的，但是没有用例测试同学一样可以执行测试操作。那是不是测试用例就无关紧要了。不！没有经过测试用例编写的测试执行和写了测试用例的测试执行的不同点在于：

1. 测试用例设计和编写是一个对需求理解和思考测试点方方面面的一个过程。经过这个磨炼的过程后并落地于纸笔之上，在测试执行的过程中才能有条不紊。做到执行有可依。没有经过用例编写磨炼的测试执行也是乱糟糟的，思考没有落地，执行必然有损。
2. 测试用例是项目需求迭代变更的积累和沉淀。在一个周期持续长、迭代多的项目里，你能很快的回答出某两个迭代之间某个需求功能的变更是什么吗？怎么快速的对比出这两个迭代的差异呢？相比于不断更新的设计文档和交互文档，测试用例是最能反映迭代版本需求变更的材料。因为测试同学必须要关注不同迭代版本的需求变更才能更准确的把握功能测试点，才能更好的执行变更点的测试。而且在规模比较大的项目上，如果测试执行又牵涉到其他的部门或者组织（比如：部分或者全部外包类的项目），那么就更需要测试用例来进行测试执行分工协调、测试结果考核。
3. 测试用例是测试策略优化和自动化测试的必要条件。在规模稍微大点的有单独测试部门的公司，测试负责人都避不开测试策略优化和自动化测试。测试策略优化一般的要求就是如何在非理想状况下如何能很好的执行测试并有效保障测试的质量。如：大家最常见的测试时间被压缩到了很短的时间但是要测试的内容又很多发布又要高质量要求，你怎么有效的解决这个问题呢？其次是自动化测试，自动化测试不是凭空想象然后各种脚本编写就搞定的，它肯定要依据当前积累的所有测试用例甄选出来的，不是所有用例都能自动化，也不是所有用例都必须自动化。

第三总结下我碰到的很多测试同学在编写测试用例过程中容易陷入的坑。这些坑都是我们在写测试用例的过程中和在执行用的过程中都不自察的。主要是：

1. 形式上完全或者基本上照搬交互设计或者需求文档。测试用例编写肯定是要先看功能需求和交互设计文档的，但是很多测试同学都是一看就陷进去了，写用例的时候也还是沉浸在需求或者交互文档的思路之下，一路狂奔字如泉涌，洋洋洒洒写了很多的用例出来，看起来成果满满，其实只是变相的把需求和交互设计文档抄了一遍。这种用例用起来的效果：①首先就是看起来全是描述性的话术。也不知道怎么执行或者需要二次思考才能慢慢执行起来。②其次是会缺失很多测试点。编写需求和交互文档站在的角度和测试工程师编写测试用例的角度肯定是不一样的，前者思考这个特定的功能是什么样的，后者需要全面思考这个功能点的操作在整个业务或者整个系统中的影响是什么。照着需求和交互设计文档走的结果必然是缺失很多同其他相关联功能模块的影响是什么。
2. 测试用例输出展现臃肿，结构混乱。测试用例非常考验测试工程师对需求功能点的结构把控能力，把控得好的同学一般都知道如何组织整个用例的结构，知道如何把什么的测试点放在什么样的结构下。把控得不好的效果就是全部用例混杂在一起，到处可见相同或类似操作。
3. 用例写的很辛苦，但是执行的时候没人看。可能很多同学都不知道自己辛辛苦苦写出来的用例成果，竟然在执行的时候没一个人或者极少的人去看。如果你不信的话可以尝试在自己所在的测试组里做个小调查，在测试执行的过程中真的是按照测试用例执行的有多少，然后再追问调查下为什么。相信你会得到让你心里落差很大的回答。别人不看你的测试用例无外乎你用例写的不好，具体不好在哪些方面，其实是可以寻根问底的。

第四谈下我认为的一个写的好的测试用例是什么样的。相比于以上我们在写测试用例的过程中出现的问题和容易陷入的坑，我觉得一个好的测试用例应该具有下面这些气质：

1. 测试用例结构清晰，能看出编写者是经过了思考和精心梳理了的。这种用例一般给人看到的效果是：结构形式上就很清爽，内容上能看出整个需求功能点测试覆盖了哪些方面，有较强的层次感。
2. 测试执行无需二次思考，执行效率高。有这种特质的用例一般大家都喜欢用，因为参考用例执行的时候不需要执行者二次思考这个点在讲什么、怎么执行、预期是什么，按照用例操作即可，大大提升用例执行的执行转化效率。
3. 极简主义。用例条数和需求功能覆盖度不是正相关关系，如何用尽量少的用例条数覆盖尽量多的需求功能路径是非常有挑战的一件事情。做好这件事情的前提是对需求功能点结构的深入理解，甚至是对实现层面代码架构的深入理解。

最后怎么才能写得一手好测试用例呢？我不能说按照以下方法就肯定能写得好，但是至少从我这几年的实践经验看是在往越来越好的方向进步。主要是：

1. 理解透需求功能。这个前提下，再让你去写用例，一千个人有一千种写法，但是至少不会只能照搬需求和交互设计文档了。这么多的发挥空间下必然有你游刃有余的那一个。大道至简的前提是理解透大道。只有理解到位了才能更用更简洁、精准的话术来描绘你的测试用例。
2. 不拘泥于测试用例的表现形式。写用例不一定必须要用excel。承认excel表格的在表现用例4要素（名称、前置条件、操作步骤、预期结果）结构上便捷性上，它也有其局限性。面对树形发散场景类的需求功能思维导图（如Xmind）也许更能表现出用例设计的思路。面对有限定状态流转的需求功能流程图似的用例也许更能完美的体验。总结一点就是：编写用例形无定式。
3. 有发散思维但非散而不收。发散思维对测试工程师很重要，写测试用例时更是要用到发散思维。但是测试工程师会走两个极端：一是对需求功能理解不到位发散不出去导致的结果便是用例编写思考面不足，另一个是太发散了导致收不起来了导致的结构便是发散了太多的无效测试点且用例整体表现混乱没有结构。

总结今天的主题理论居多，也是我个人在测试管理上对测试用例这一方面的一些思考和感悟。上面的内容全部是有经历过而且还在经历中、有优化实践过而且还在继续实践优化中的。希望能给予同在测试工程师岗位的你有些帮助和思考。

欢迎进入我的微信公众号：ThinkingInTest 一起探讨更多测试话题！