浅谈测试用例的编写

下午忽然收到合作方的消息。对我写的[b]测试用例[/b]一顿打击。我当然是不服的，毕竟我也工作了两年有余。这样劈头盖脸的打击，完全是对我工作的否定嘛。

可是，想想也确实没什么不服的。确实是自己的问题。
前面我分享了移动APP测试经验里有写到用例的编写，我自己也发现写的太模糊了。在这里和大家聊聊测试用例编写的问题。
做一名测试人员，最基本的就是测试用例的编写。文档功底一定要有。我们来说说用例的编写需要的东西。
首先，用例的模板网上有很多。这些都是根据个人习惯的，但是再变，其核心内容是不变的。
一份测试用例一定会包含的东西有‘测试模块’、‘测试标题’、‘前置条件’、‘执行步骤’、‘预期结果’、‘实际结果’；在这里就不详细和大家讲这几个模块了。今天我们要说的是，怎样才能算是一份合格的测试用例。
1、逻辑性
有些同学问我，你的测试用例怎么写的，是按UI界面，还是按功能点。最初我给出的答案是功能点，因为我没试过去按UI界面去写用例。我也思考了这个问题。能不能按照UI界面来写用例。其实我觉得也是可以的。我之所以按照功能点来写测试用例，无非就是想保证功能的逻辑贯通，易于测试的执行和理解。如果我们通过UI界面还能保证业务的逻辑、流程贯通的话，也是可以的。
如果我按照功能点和UI界面去写用例。就拿登录这个功能来说，可能写出来的用例会有所不一样，但是这并不会影响到测试人员对它的理解和执行。但是如果我毫无逻辑可言的写的用例，那么测试人员可能就一脸懵逼，不知如何是好了。
2、条理性
一定要循序渐进，有条理，清晰。什么叫有条理呢？就是能够有规律、有顺序、知轻重的去工作。如果没有条理性的话，那么测试人员可能会在一个小东西上，浪费很多时间，从而导致重要的东西没有时间完成测试。或者说导致项目的延期。如果说，逻辑性是告诉测试人员是按什么顺序去做的话。那么条理性就是告诉测试人员，你需要先做什么在做什么。
3、易用性
用例不仅仅需要有逻辑，有条理。更要别人能够看懂，容易看懂。你的用例写的很好，逻辑完美，条理清晰，但是我看不懂，那也没有什么作用。不要抱着用例是给测试内部看的这种想法，这种想法很危险。
4、可执行性
OK，我能够看懂你的用例。那么接下来就要开始Run Case了。这个时候，我能否依据一份用例，完成对这个项目的测试，就是衡量用例是否合格的标准之一。因为测试员，在进行Run Case的时候，可能不是他自己写的用例，可能他没看过需求。可能的情况有很多。所以我们尽量去保证，就算是一个完全没看过需求的人，也能够按照我的用例完整的执行一遍测试。

如果出现不知道怎么写的时候。一定要明确需求。不知道怎么写无非就是需求不明确或者是需求理解不透彻，在这个时候就要用到我们的产品了。

好了，这次的分享就写到这里。晚上给大家写一篇弱网测试的文章。那个忘了在之前的经验分享里给大家介绍了。
顺便告诫大家一句：不肯否定自己，承认自己的错误，去修改，永远都无法进步