本节书摘来自华章出版社《移动App测试实战》一 书中的第1章，第1.2节，作者：邱鹏 陈吉 潘晓明，更多章节内容可以访问云栖社区“华章计算机”公众号查看。
1.2 测试用例设计和评审
测试人员的一个基本工作，或者说是基本功，就是测试用例的编写。对于一些快速迭代的互联网产品，关于是否需要编写测试用例，也有一些讨论和争论。
就我们的观念，觉得还是需要，特别是对于App这样的产品，很多功能有一定的稳定性。类比来说，测试用例相当于电影的剧本，有场景、动作、台词，规划出一个基本的框架。测试用例也是一样，针对什么功能，在什么情况和使用场景下，做什么操作，用什么数据，期望有什么样的结果，进而和实际结果对比判断是否合理。
如果完全没有这样的剧本，测试会比较盲目，更重要的是，参考上面SDK测试用例的例子，如果不系统地把这些测试点提前记录下来，等到测试人员拿到可测的版本，如何保证能想起上面所有这些情况，并系统化地覆盖？
对各种场景和路径比较系统化的覆盖，是对一个专职或者专业测试人员的基本要求，这一点使他们和普通用户的使用区分开来。也体现了测试的系统性、深度和效率，在很短的时间里覆盖足够多的场景。另外，还有很重要的一点，当我们把这些测试点记录下来，也可以请其他测试人员，以及产品和开发等一起来评审，确保测试用例的正确性和全面性。缺少用例，也不便于知识的积累和传递，因为现实中会有具体模块负责人员的变更和交接。
当然，虽然有了测试用例，实际执行过程中还是有一些临场发挥的成分在里面，就像电影剧本一样，对于同样的剧本，不同的人来演绎效果会非常不同。测试用例的执行也是一样，同样的用例，不同的人还是会发现不同的问题，因为人在执行的过程中观察的点会不同，操作的方式也会有些差别。
在是否编写用例上我们给出了自己的建议，这一点和传统的软件研发流程一样。但是细节的做法有差异，主要体现在以下几个方面：
1）用例设计上的投入。在我们曾经工作过的企业级产品的测试中，因为一个发布的版本是6个月以上的时间，所以测试用例设计的流程会做得比较严谨，或者以互联网的观点来看，比较重。之前的做法是对于每一个模块需要编写测试设计文档，讨论需要考虑的测试场景，然后进行开发测试内部评审。修订完了之后开始编写正式的测试用例，然后再召开测试用例评审会。这些固然严谨和全面，但对于互联网产品，很多模块只有几天的测试时间，无法负担，所以通常省去了测试设计思路的文档化过程。
2）用例编写的详细程度。严格来说，测试用例应该至少包括下面的这些要素：
用例的题目，一句话描述。
测试步骤，逐个写下，详细程度需要有少量经验的人也可以执行。
前置条件，此用例的执行需要哪些前置条件或者在什么条件下才会有预期的结果。
测试数据，此用例的执行需要什么样的测试数据，比如无货的商品，特殊的优惠券等，需要提前准备好并附上。
期望的测试结果。
同样，如果每个用例写到这样的程度，实际上对于很多项目来说也是无法承受的。对于上面给出的测试用例示例可以看出，里面每一个叶子节点其实对应的是一个用例，但是非常的概要，或者只能算是一个提示，告诉对应的测试人员需要考虑这样的情况。但是并没有详细地给出测试的步骤、数据和期望的结果。
某种程度上，这是一种妥协，但也是另一种工作方式，用例就是一个故事梗概，需要对应的测试人员了解需求的上下文，以及基本的实现方式，进而来执行。这一点上，有点像演讲时用的PPT，可以把要说的话全部写在上面，也可以只写几个关键词，其他需要说的自己补充和发挥。
可以看出，这种方式的可行性，其实对测试人员提出了更高的要求，需要对负责的业务功能细节非常了解，并且对测试环境和数据等方面也能把控。所以在人员的分工上，一段时间，对于一个功能模块，会有一个具体的测试负责人来跟进。
图1-4所示用例是针对Android App增量升级功能，也是类似的方式，非常简洁，对这个功能有一定了解的人会知道每一条用例代表的场景和如何执行。
3）表现形式。这个差异主要是因为引入了思维导图的表现形式，基于常用的Xmind、Freemind等工具，上面两个示例都是在Xmind中编写的。传统上测试用例主要的载体是Excel表格，或者基于Web的测试用例管理平台。这两种形式都可以比较完整地表达上面提到的测试用例的各个要素。遇到的问题是：一方面编写的工作量比较大，考虑一个功能模块有超过100个用例是很普遍的；另一方面缺少逻辑关系，这一点也是思维导图的优势。
以上几种形式我们在不同的项目中都实际应用过，包括也试验过先用思维导图来编写用例，然后导出成Excel或者导入到平台等方式。实际应用下来，转换的过程体验并不好，也会存在变更后双向同步的问题。在目前实际项目的做法中，我们并没有严格要求测试人员编写用例的形式。
关于常用的测试用例设计方法，这里不准备展开来讲，因为那需要写一本独立的书，另外业界也有很好的参考，包括但不限于下面几本：
《软件测试》（Software Testing：A Craftsman抯 Approach, Second Edition），作者是Paul C.Jorgensen。这本书介绍了很多经典的测试设计方面的方法，非常的详细，很多思路依然有效。
《微软的软件测试之道》（How We Test Software at Microsoft），作者是Alan Page、 Ken Johnston和Bj Rollison。介绍了一些测试的基本概念，以及等价类划分（Equivalence Class Partitioning）、边界值分析（Boundary Value Analysis）、组合分析（Combinatorial Analysis）等经典测试方法，以及Model-Based Testing的案例。
《探索式软件测试》（Exploratory Software Testing），作者是James A.Whittaker。这本书给出了很多可操作的探索性测试的方法，其中有很多方法已经沉淀下来变成可以借鉴的测试设计思路，而不再只是探索了。
除了以上的资料，以及个人的尝试和琢磨，最快速提高测试设计能力的实践是参加测试用例评审，特别是参加一些有丰富测试经验的人在场的用例评审，可以很快地打开思路，考虑得更加全面。
从项目和测试质量的角度，测试评审的帮助也会非常大，以实践的经验来看，这个实践除了能让测试人员考虑更加充分，覆盖更多必要的场景，也能帮助大家提前理清很多产品功能的细节和注意事项。在测试用例评审的时候，需要鼓励大家打破思维的局限，敢于思考各种可能会出现的复杂场景，以及异常情况。对于需求和实现模糊的地方，尽量不要做假设，而是需要和对应的人去确认。也是因为这个原因，往往还会发现很多需求和功能设计上考虑不周全的问题。因为当我们深入讨论一个测试场景的时候，就会发现我们不知道我们的产品经理和开发人员是怎么处理的，也可能他们还没有考虑到这种情况，也可能相关的信息没有同步导致大家理解不一致。
针对这样的情况，我们尝试过觉得比较好的做法是，把这些问题逐个记录下来，然后通过邮件集中发出来给对应的产品经理和开发人员来确认，进而让大家的理解达成一致。
对于团队成员测试设计能力的考察和提升，还有一个可以实践的方式是用例设计的Workshop。就是让所有测试人员都集中在一起，然后给出一个功能场景请大家来写出自己认为需要的用例。选取的场景最好比较通用、大家都比较容易理解，比如上传用户头像，登录注册，电商里面的发表用户评论送积分等。现场让每个人写下用例，只需要简略地写出每个用例希望覆盖的测试点。
接下来请每个人讲解自己的用例，并在白板上记录，多个人考虑到的测试点可以记录次数。
通过这样的活动，可以看出每个人对测试设计考虑的维度、深度以及全面性。因为是同一个功能，所以大家可以互相借鉴和参考，并发现自己考虑上的不足。通过这样的实践，可以不断提升测试设计的质量。
