最近开始整理自动化平台上面的测试用例，自己也写了很多的表格去与手工测试用例进行对照，想总结一下这两年多的测试用例编写方法。
手工测试用例编写
现在还记得刚开始进入现在的公司面试的时候，当时的面试官叫我写一个登录页面的用例，他说给你五分钟的时间，你看看你能想到多少。我当时就觉得这很简单呀，在面试官出去的那五分钟里，奋笔疾书写了大概十几二十几条吧，然后面试官回来了，没错，他嘲笑了我。。。。。。
首先，我的用例全部都是功能性用例（黑盒测试嘛），等价类，边界值划分什么的；
其次，用例写的毫无章法，乱七八糟（现在想起来真的是自己都想嘲笑自己）；
最后，即使是黑盒测试用例，我也没能写完整，全部都是只看到字面意思那样去写。
谢谢当时的面试官也就是现在的老大，给我指出了当时的问题，在这里想要记录一下，希望其他去面试的小伙伴不要犯我当时的错误。
测试用例不要上来就写
很多人可能都有这种习惯，习惯不管什么时候，拿到一个需求或者页面就开始着手写用例，把一些简单的用例直（hu）接(luan)写出来，可是简单的用例也都没能写好，东一句西一句去拼凑，最后还不清楚哪个需求点没能写好，测出来的产品也就没有预期的样子。
（1）熟悉并仔细阅读需求说明书，但是现在很多互联网公司都是敏捷测试，可能需求说明文档就没有传统测试难么详细，很多细节都需要主动去沟通和确认的。
（2）编写过程中需要仔细思考，产品的用户群是什么样的，到底用户想要的结果什么，也就是用户思维。
（3）用例编写过后，需要给组内人员进行评审，一个能可能不能兼顾那么多点，但是组内人员大家一起讨论，会产生不一样的效果哦。
拿现在公司的 APP（互联网金融，P2P 行业）来说，如果要求写一个登录页面的测试用例，需要从功能、性能、安全性、易用性、兼容性、界面是否美观和可维护性这几个主要方面进行编写测试用例。
编写测试用例的方式
在编写测试用例的过程中，虽然清楚需要侧重的点是什么，但还需要用例思维，我之前用过这三种方式进行编写。
（1）传统的用例编写模式：Excel 表格（或者是测试管理工具）中，输入编号，用例名称，前置条件，输入数据，用例步骤，优先级，预期结果，编写人员，复审人员、日期等等一系列的条件。
（2）脑图思维方式编写：在 Excel 表格中，从一级开始向外延伸，一级、二级、三级……八级这样去思考，比较不容易丢下测试重点，也利于大脑进行思考，掌握全局观念。
（3）思维导图方式编写：在 Xmind 中进行编写，这种方式其实和脑图思维比较像，都是依靠一个功能点或者中心点思维慢慢向外延伸进行编写用例，而且思维导图中还可以添加一些任务进度和优先级这种标志，比较方便测试人员进行标记记录。
自动化测试用例编写
自动化测试用例与手工测试用例比较起来可能比手工测试用例要简单许多，因为自动化测试用例大部分都是适用于软件测试的回归和通用性比较强的用例测试。在当前的互联网金融公司中，大部分都选择在自己做的平台进行自动化用例的编写，使用一些封装方法，将动作封装成关键字进行编写，可能需要到的知识也就是 Xpath 定位方式一类的。
自动化用例需要评审
自动化工具不可能完全替代人手工操作，所以在进行自动化用例编写之前，需要进行了解哪一部分是自动化工具可以执行的，哪些是必须手工去执行的。比如一些不好获取到的控件、解绑银行卡之后重现上传照片、使用电话进行联系客服等这样的情况都是需要手工测试区判断的。在编写好的手工测试基础上，对自动化测试用例进行筛选或者评审，或者也可以根据之前制定的回归计划进行编写自动化测试用例。
用例编写感悟
2016年的时候，大部分时间都是在进行功能测试，没有任何自动化或者性能方面的经验，所以用例设计的也比较简单，形成的思维方式也比较固定，原因就在于自己太不注重去多了解外面的测试情况，属于比较故步自封的那种类型。在之后的很多次面试中，面试官之前就要求需要写一些或者讲解一些自己之前写过的测试用例，这样说起来就比较 low 了。还是需要自己多去了解多去增加自己的知识图库，现在记录下来，给自己提个醒吧。