自动化测试用例设计杂谈
某天在QQ群里吹水扯淡，谈到现在全民自动化的现象，现如今好多公司连最基本的测试用例设计维护管理等都还未做好，就已经开始喊口号直奔自动化（好还是不好呢？）。当然同理可得，有好多人连测试用例都还没写好，就已经开始投奔“自动化”，原因显而易见 —— 工资高 ? 有技术含量 ? 提高效率 ? 呵呵哒。因为我自己也在这个圈子里挣扎，今天好好整理下，老王跟我说过的测试用例设计。希望自己的测试用例设计上可以做好来（真的! 做测试的基本功）
用例设计四要素
- 用例要原子性
- 用例要复合单一责任原则
- 用例要具备高度的抽象
- 用例要直接映射需求
1. 原子性
用例本身不应该依赖于其他用例
2. 单一责任原则
用例仅验证一个feature
3. 高度的抽象
用例关注的点应该在feature和scenario的层面上,而不是细节（后面举例说明）
4. 映射需求
按照书上说的就是：
- 应该做的要有
- 不应该做的不应该有
- 做了不知道该不该有的（关于这一点也有可能是产品需求的疏忽，测试人员要多注意）
其余的就是做的正确与做的错误的辨析 blahblahblah
带着代码的思维设计用例
老王：“其实本质上，写代码和我们日常交流的时候一样我们日常交流，更多的细节都会在抽象层，而不在细节。”
举个栗子：
事件：米总,你让小黄帮你买个汉堡
指令：米总只会告诉小黄说,小黄,你中午吃饭的时候,路过麦当劳帮我买个汉堡
执行：但实际上小黄执行这个买汉堡的动作,干了很多事
1. 她要下楼
2. 她要找到麦当劳
3. 她要进去购买
4. 她要付款
5. 她要等待汉堡做完
6. 她要回到公司
1.1 然后下楼这个动作又可以拆分成数个行为
2.1 ...
3.1 ...
... ...
"我们在写代码的时候精力着重的关注在"抽象" --> 买汉堡，而不是小黄要从座位上起立,然后往左转,走多少步到电梯口,然后进电梯,按1楼这类的细节上。很多时候,我看到很多做的很差的自动化测试用例,是把精力都放在细节上了。"
我们focus的重点应该是抽象的事件上，也就是最终的需求点，其他的细节只是辅助。
总结反思
老王：“一个好的程序员和差的程序员, 最主要的差别不在代码上,而在这个思维的抽象层次的提炼和现实业务的映射中。”
好的程序员：
可以很容易的在代码的模型世界里和现实的业务世界里做好抽象层次足够高的映射
差的程序员：
则会太过关注细节,少了很多抽象层的提炼和思考
老王：“本身代码就是让计算机帮助人类解决现实世界中的问题, 怎么做好代码到现实映射, 这就是OOP设计了。”