水之积也不厚，则其负大舟也无力。－庄子

　　前两篇主要谈了谈测试的成长与瓶颈，并未涉及到测试工作本身的内容，从本篇起，笔者将与大家就测试的实际工作内容与大家一起交流与探讨。

　　测试的实际工作千差万别，各个细分领域差别非常大，比如自动化测试，性能测试，客户端测试，web测试等等，同为测试中人，如果一个测试工程师接触面不够广，基本上听不懂对方说什么，更别谈融会贯通了。如果非要找出一个关键点是所有测试工程师都很熟悉和绕不过去的，那无疑就是测试用例了。

　　笔者从事一线测试多年，对测试用例也有比较深刻的思考与实践，在不同的公司也见过五花八门的用例，可谓是求同存异，雅俗共赏。

　　下面我们就逐一来分析下用例的几个关键节点：

　　1，格式

　　一个用例如果在格式上乱七八糟，让人一看就就天然的厌恶感，执行起来自然不会有很好的效果。有人会问，我用例写完了，覆盖度完整了就行呗，强调格式有什么用？那么我们就来看看格式的作用，笔者认为至少有以下几点重要性：

　　01） 让用例变的脉络清晰，富有美感，让执行过程不至于过于枯燥。

　　02） 方便执行人员的认知和理解

　　03） 方便需求变化后的更新维护

　　04） 方便用例的统一管理

　　那么问题来了，什么样的格式才是个好格式呢？这个就是见仁见智了，但是以下几点至少是应该做到的：

　　01） 脉络清晰且有逻辑性，不能想怎么写就怎么写

　　02） 尽量保持输入和输出的单一对应，一条用例中包含多个输入或输出，会给执行人员带来巨大困扰

　　03） 要能够被维护，这个是常见的问题所在，有时候维护一个旧用例的痛苦超越人类忍受极限，还不如重新写一份

　　04） 同一个用例的不同模块之间尽量保持统一格式，举个例子，不能一会a代表a,一会a代表b，这样会严重损害执行人员的身心健康

　　2，需求分析

　　笔者遇到很多测试工程师拿到需求文档后都没通读和深入分析，就直接上来写，遇到这种情况，笔者只能说，哥们还是回家卖红薯吧，比较有前途一些。。。 笔者认为至少经历4个阶段才能动手去写，即详细阅读->沟通探讨->逻辑梳理->拓展思考。

　　第一个阶段：阅读。让我们来看看如何阅读才能在我们真正动手时有如神助

　　01） 详细阅读至少2－3遍

　　02） 尝试站在需求人员的角度去理解其设计意图和思路

　　03） 推敲逻辑，关注细微，有些需求隐藏在一些不起眼的语句中，或者是需求人员想要的但是没有写明的，都可以在阅读的过程中推敲出来。

　　04） 超越需求，如果让你来设计，有没有可以设计的更好的地方

　　05） 记录问题，阅读过程中记录不理解的地方，及时与需求方核实并做备注

　　这样阅读，我们才能深入到设计核心，理解为什么这样设计及当前存在哪些误区或不理解的地方。

　　第二个阶段：沟通探讨。这个阶段可能很多人都忽视，等动手写用例的时候才会去与需求方探讨，这样不仅会打乱双方的工作节奏，也会增加很多没必要的沟通成本。让我们看看在阅读需求阶段，怎样做好沟通。

　　01） 遇到拿不准的地方，及时跟需求方沟通探讨，还是那句话，不要以为你以为的就是你以为的

　　02） 探讨问题时最好与需求人员，开发人员一起探讨，不要让沟通出现断裂或增加二次沟通

　　03） 关注变更，要思考变更对上下文的影响

　　第三个阶段：逻辑梳理。文档我读了，也理解了，为什么还要梳理逻辑呢？笔者认为主要基于以下几点原因：

　　01） 需求文档不一定是按照流程顺序书写的。尤其是不同模块之间出现功能交叉的时候，可能一会描述a模块，一会描述b模块。如果我们不梳理，按照文档顺序写，一会就写乱了，会出现完全写不下去的情况。

　　02） 去除冗余，面对复杂的需求，覆盖度是一个层面，冗余度也是一个层面，逻辑不梳理清晰，冗余太多会导致执行过程效率低下，甚至拖累项目周期。

　　第四个阶段：拓展思考。软件实际运行的情况太过复杂，稍有不慎就可能酿成大错。这个阶段也是考察一个测试人员功力的地方，毕竟大家练的套路看似都差不多，至于内功如何，就只能呵呵了。在这一阶段，我们主要应该关注以下几点：

　　01） 设计缺陷思考：我们知道在一款游戏中，功能与功能之间的藕合度比较高，牵一发而动全身。有时候设计人员考虑的并非完善，这就需要我们要整体考虑，把跟本次需求有关的旧有功能梳理一下，看看是否有需要一起调整的地方。

　　02） 测试难点思考：阅读过程中要思考每个点怎样才能测到，是否有以现有技术手段无法测试的地方，如果有则需要及时提出让开发人员提供技术支持。

　　03） 兼容性思考：兼容性的注意点比较多，比如数据兼容，版本兼容，功能兼容，操作系统兼容，分辨率兼容等等，尽量要提前考虑到可能遇到的问题，毕竟用户的实际情况非常多。

　　04） 特殊情况思考：比如断网，断电，低网速，重启等等

　　3，模块划分

　　笔者经过多年的实践和总结，整理了下模块划分的原则和方法，不一定全，供大家参考。

　　模块划分原则：

　　01） 高内聚。指的是单一模块划分后，模块内部之间要在逻辑上有紧密的关联度，也就是说这个模块不能继续被拆分下去。举例，比如邮件中的附件功能，虽然它包含各种类型的附件都需要测试充分，但是这个功能本身作为独立模块就不能继续拆分了。

　　02） 低耦合。指的是模块与模块之间的关联度比较低，不能合并为一个模块。举例，邮件中的收件功能和发件功能，这2个功能关联度很低，不能合并为一个模块来梳理。

　　03） 重整体轻局部。指的是要有大局观，从整体层面去关注模块之间的构成和联系，不纠结于具体的细节。举例，测试UI的时候经常会与具体功能相掺杂，这时候就要从整体层面来看怎么拆分逻辑更清晰，不要扎在细节泥潭里不能自拔。细节问题可以在模块划分完毕后细化模块的过程中再具体分析。

　　常用的模块划分方法：

　　01） 功能流程法：将功能的基本流程图画出来，根据流程走向来划分模块。举例，银行的ATM取款功能划分就比较符合这种方法，我们可以粗略的划分为一下几步流程：插卡环节->密码登录环节->输入金额环节->取走钱币环节->取卡环节，这样我们根据不同的环节流程来划分不同的模块，基本能使整体结构看上去逻辑清晰，简单易懂。

　　02） 层次划分法：按照逻辑层次逐层细化出模块的过程。以大家比较喜欢玩的dota游戏来举例，第一层我们可以分为战斗外内容和战斗内内容2部分，第二层的战斗外内容又可以分为账号登陆，按键设置，外部链接等内容。。。依次类推，我们就可以逐层细化，从而将整个游戏的模块划分清晰。

　　03） 类型划分法：按照功能包含内容的不同类型来划分。还是以dota举例，比如测试英雄系统，我们就可以先根据英雄类型来划分成，物理攻击类和魔法攻击类或者近程攻击类和远程攻击类。然后可以继续根据小类型来划分。

　　类型的划分原则和方法有时候不会单一出现，更多的时候要结合使用，最终目的是使得模块划分的清晰、全面。

　　4，用例编写方法

　　这个过于老生常谈，笔者没什么原创跟大家分享，网上的内容比较全面，比如常用的边界值，等价类，判定表等，笔者就不班门弄斧了，大家可以自行求助百度大神。

　　5，整理与维护

　　很多人认为用例编写完毕后，任务就完成了，实际还有后续的问题需要大家关注，常见的有以下几点：

　　01） 需求变化后需要及时更新旧用例，并就更新做详细的注释，方便执行人员理解和执行

　　02） 测试用例应该在保证覆盖度的情况下尽量避免冗余

　　03） 注意备份，遇到用例丢失或者被误删除，那简直生不如死啊

　　以上笔者就用例的书写环节与大家做了简单沟通，欢迎大家批评指正。下一篇笔者会就执行环节跟大家继续探讨。