测试工程师的光荣与梦想(三)-老骥伏枥
水之积也不厚，则其负大舟也无力。－庄子前两篇主要谈了谈测试的成长与瓶颈，并未涉及到测试工作本身的内容，从本篇起，笔者将与大家就测试的实际工作内容与大家一起交流与探讨。
测试的实际工作千差万别，各个细分领域差别非常大，比如自动化测试，性能测试，客户端测试，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） 注意备份，遇到用例丢失或者被误删除，那简直生不如死啊
以上笔者就用例的书写环节与大家做了简单沟通，欢迎大家批评指正。下一篇笔者会就执行环节跟大家继续探讨。
谢谢分享 测试行业做了快五年了，感觉接触的公司测试流程都很不完善，自身提高不大，学习了，谢谢分享 好帖子。测试用例的设计才是手工测试最好玩的地方。目前我们很多公司的软件研发流程都比较滞后，共勉之。 很好的帖子，对于一个新人来说，提供了很大的帮助，谢谢LZ 不错，受教了
页:
[1]
