用例设计与管理
如果前面说的缺陷管理是作为测试最基本的要求的话，那么用例的设计与管理就是真正成为测试工程师的核心技能。
为何说用例设计与管理是测试工程师的核心技能的，而不是大家所关注的什么技术方向。首先技术方向是手段，但是任何的技术手段都是为了测试目的而服务的，如果这个目的出了偏差，那么所有的手段都无法达到预期的目的，或者就算达到了目的也并没反馈你所希望的效果。
例如我们需要测试登月车在月球上能否正常工作，那么你拿什么技术去测试呢？本质上还要换个角度从测试的思路上改变，在地球上模拟一个类似月球的环境。
那么测试用例的测试与管理主要分为下面三块：
1.测试用例的格式
2.测试用例的设计
3.测试用例的管理
测试用例的格式
用例的格式其实并不是非常复杂的东西，但是这里提出来还是希望和上一章的缺陷同样的概念，就是用例写作时候的要素。
相对缺陷看不懂来说用例更容易看不懂，一个没头没尾的文字让别人看了完全不知道想说明啥或者到底对错在哪里。一般功能型黑盒测试用例由7个要素组成，主题-预置条件-输入数据-操作步骤-预期结果-实际结果-优先级，他们规范了用例的组成部分，以便有效地避免歧义性等问题。对于一个用例来说最重要的就是要让执行的人看了之后知道：
1.到底怎么操作
操作的步骤是一个相当复杂的东西，因为它涉及了操作步骤、后台环境，很多缺陷不能重现或者不能准确定位都和操作的背景有些关系。整个用例不能有效的完整的重现制造缺陷的流程，测试的目标不是很精细，就会导致一个用例对应了大量的覆盖点。
2.怎么算是错误
作为缺陷提交的参考基础，错误的判定标准，也就是期望值是非常重要的。通过前面的测试用例操作过程后，到底什么结果算是正确的，必须要非常明确正向的表达。而中文在这里又具备一点二义性，在表达上就会更加容易出问题。
这里需要重新强调一点，执行用例的人未必是写用例的人，写用例的是设计人员，执行用例的是执行人员，设计人员必须要保证执行人员能够按照自己的思路准确的完成测试。
测试用例的设计
测试用例设计是测试设计人员从写好基本步骤的基础上更深层次的要求，所谓的测试用例的设计只是通过某种方法准确的覆盖被测对象的各个方向角度，达到一定的覆盖率，从而提高软件质量的手段。
为什么要使用测试用例的设计方法呢？首先我先举个简单的例子，就是当你要出门旅游，你要考虑你需要携带的内容，有哪些呢？（这里大家可以先思考2分钟想想）然后就会出现一个问题，就是每次出门到了景点总会遇到点问题，然后发现少带了点啥，慢慢的多来几次就会做这样的一件事情，写一个外出携带物件表。
1.重要证件（护照、身份证、机票、手机、钱包、银行卡、现金等）
2.必备生活用品（充电器、剃须刀、毛巾、换洗的衣服、睡衣、拖鞋等）
3.别的（雨伞、地图、紧急联系人、部分急救药物等）
4.出门前家里要检查的内容（水电气、门窗）
以后每次出门都按照这个流程检查一遍，那么就不太会出现因为遗漏而导致的某些意外了，特别是经过多次的反复测试后会发现这个用例会越来越完美。
同样对于软件来说也是这样的，直接每次测试前空想一下哪里要测试，这个效果会非常的差，很依赖于当时设计人员的状态和经验。通过科学的方法可以帮助我们有效的将测试用例的设计从感性思考变成理性设计，比如上面写得出门常备内容其实就用到了等价类的方法来进行分割。
关于测试用例设计方法我这里就不具体说明了，大家可以自己上网搜索一下，我这里做一点点补充就是，无论是黑盒测试用例设计方法还是白盒测试用例设计方法，本质上都是从各个角度有效的覆盖其各个分支流程。在做测试用例设计的时候如果能做到黑盒用例设计能看到白盒，白盒用例设计能看到黑盒，那么就非常厉害了。
测试用例的管理
既然前面我们都提到了测试用例的设计，那么接着就会涉及到管理的问题。那么用例的管理到底管理什么呢？首先用例是有层次的，用例设计其实分两部分（用例分析，用例设计），用例分析指从某一块入手（先用等价类切，可以用软件质量模型或者别的巴拉巴拉的方式），得到了每一类后再对这一类进行详细的设计覆盖这一类情况下的各种分支。这样说吧我有一个页面有一个登陆功能，那么登陆功能我可以从安全性考虑这就是分析，安全性下面会有注入型攻击，这还是分析，那么到了设计做什么呢？开始根据注入的不同输入来覆盖过滤机制证明这类注入都是不可行的。
在上面这些内容中，就涉及到了层次管理，大家所用的所有测试管理工具中对于用例管理都提供了层次管理的功能（有点需求管理的感觉），关于需求和用例的关系我们等到需求部分再来提。我们通过工具将用例进行层次化管理，这样就可以分门别类，进行维护统计分析，最终得到覆盖率的数据（在系统测试中一般是用例对需求的覆盖）。但是这里我也要补充一句100%的覆盖率并没有什么太大的意义，因为针对需求的100%覆盖并不能代表什么，一个需求一个用例是没法保证质量的，要做的好是能做到系统测试用例跑出白盒覆盖的效果。
用例的设计与管理其实是一个很大的话题这里寥寥几笔也只是将我心中的一些主干说了出来，而要做好这块事情没有1-2年的业务和技术背景是不太可能的。虽然大家都会觉得写用例不是什么技术，但是这却是做测试最厉害的技术。
测试用例是测试人员的灵魂，切莫为了项目进度及个人态度等原因而忽视了测试用例的重要性。设想一个人连灵魂都没有了，那还能留下点什么呢？