从事软件测试这项工作算起来正好一年了，对工作慢慢熟悉之后，也对日常工作中需要接触的一些事和物有了一些想法，今天就测试用例简单谈谈我在工作中的看法。
首先我们要明确，什么是测试用例，它存在的意义又是什么？在我看来，测试用例就是一份能够帮助我们完成测试的文档，它可以对我们的测试覆盖度进行保障，也可以对我们的测试起到启示的作用。它存在的主要意义我认为有两方面，一是引导协助我们完成日常工作中的测试任务；二是在产品发布后，提供产品功能上乃至性能、兼容性上的判断标准。
那么如何去判断一份用例写的究竟是好是坏，这是一个没法完全保证的问题。每个人都有自己的做事方法，对应的他的用例执行、编写都有自己的特色。我们只能从客观的方面去判断这份用例是否达标乃至优秀，判断标准无外乎两点：一，测试覆盖度；二，发现缺陷效率。这两者是相辅相成，但又相对独立的，我们可能会发现一份用例在某一项上表现的特别突出，但是另一项则很失败。举个简单的例子，一个包含4个条件的搜索功能，我们可以用穷举法对这一个功能写出上百条用例，覆盖度非常高，但是缺陷发现效率则会非常低。也就是说，在判断用例是否达标上，单项的标准是不准确的，更多的应该综合考虑。但用例编写完成初期，没有人能够衡量出来这份用例的发现效率，这是一个无法解决的问题，我们更多的只能通过经验、不断的维护才能逐渐将用例完善好。
以上内容是我对用例的一些看法，下面重点说下我在这段时间中，在用例编写过程中的一些想法，这里需要说明的是，每个人的想法、风格不同，以下内容仅供参考，但希望能对大家有所帮助！
一，关于用例框架
这里必须得强调，用例框架的搭建是一个必不可少的过程，一份用例好不好，很大程度上取决于框架的搭建效果。框架最能体现出一个人的用例设计思想，它不仅能帮助我们完成用例设计，同时也会帮助我们节省很多时间！
先说下框架在我看来有哪些优势，①框架是思路的表现，对照框架更容易将产品中各个需求、功能理清；②便于修改，用例设计不是一蹴而就的，在设计过程中我们面临这各种各样的问题，随时可能需要对框架、用例进行补充，除此之外，在设计过程中，我们自身也会存在思考不全面，需要补充、调整的情况；③便于查看，毫无疑问，一份Mindjet MindManager设计出来的思维导图远比一份excel来的清晰，也更方便检查。
接下来简单说下我个人框架搭建的方式，首先我会先思考，将一份需求或者功能分割成哪些模块（彼此影响小且全部涵盖）比较合适，这些被分割后的模块或功能就成为了我们的一级模块；接下来是分别对各个一级模块进行设计，正常情况下，一级模块对应的就已经是具体的功能点了，这时我会将这个功能实现的过程进行分解，简单来说就是实现这个功能的前置条件、功能实现的过程、功能实现后的结果及操作中的异常场景，之后根据具体的功能进行措辞，将这些内容作为二级模块；再之后就是对每个二级模块进行测试点的分析，那么这些测试点就可以最终转化为我们的用例。在以上三步过程中，第二步相对来说是最难的，也是调整最多的，那么在这里就要说明下，为什么前文提到搭建框架会对用例设计节省时间，主要原因就是在这里。在我编写用例的过程中，从来没有一次是框架搭建完成后可以直接使用的，总会在第一次搭建后再进行调整，面对mindjet，我们调整起来会非常方便，并且基本不会出错，但如果是面对一份完整的excel用例，所面临的困难及花费时间都是非常大的。
二，关于用例编写
上文已经说过了，框架搭建的主要意义就是帮助我们完成用例设计，那么在框架搭建完成后，我们用例是不是就可以完全按照框架来写了呢？结果是必然的，当然可以，但是在写用例的过程中我们仍然需要思考，需要对框架、用例进行补充完善。我的习惯是先将框架中的内容完全迁移到excel中，再进行具体用例的填写，这样一方面可以避免频繁切换屏幕导致的工作量浪费；一方面是可以及时对框架、用例进行完善。
那么在这里需要注意一点，也是我们不论是在设计还是执行过程中都需要关注的一点，情况大致可以这么描述，一个测试点中包含了A、B两个功能或者更多功能，并且在操作B功能的时候，其实A功能也必然需要操作，那么这时，我们是否还需要单独将A功能测试写出来？实际点的例子就是一个输入框的测试，系统限定字符输入限制是20个以内，我们是否需要将能否输入20个以内的字符作为一条用例？我相信很多人都会认为没有必要，因为我们后面会写一条输入超过20个字符的用例，其实这条用例已经包含了之前所描述的检查点。类似于这种情况的会很多，框架搭建时我们需要写出来，但是当具体填用例时，我们则需要进行过滤。
一份用例的好坏标准在文章之初已经说过，在一定程度上可以说，用例的覆盖度和发现效率是成反比的，如何让两者平衡，这就需要我们在用例编写过程中将一些没有意义的、冗余的用例给去除掉，也许从理论上它是应该存在的，但从实际角度出发，它的存在完全多余。
接下来简单说下我在用例设计中，怎么去结合所学的用例设计方法。和前面说的类似，完全的照搬理论知识，只会让用例变得冗余！首先说下流程法，这个是最容易解释的，这个方法贯穿了我们整个用例设计，框架搭建过程中的1、2、3级模块划分主要采用的就是这种方法，它的优势主要就在于能够清晰的让别人明白你的测试流程，从哪到哪，一目了然；其次是边界值，这个用例设计方法是非常好用的，但是稍不注意，它也是造成用例冗余的罪魁祸首，这点前面已经解释过了，这里就不多赘述，只能说在使用时需要考虑、结合实际功能；最后是正交法，关于正交法，我们在学习这种方法的时候所了解的就是在保证用例覆盖度的同时提升用例的缺陷发现效率，但是在实际过程中，正交法的使用是最复杂的，正交表也仅仅是一张数学表格，它代表的也只是理论，对于一份用例来说，正交表中所给定的场景还是太多了，所以我们在实际过程中需要做的是删减，而不是补充，至于如何删减，文字描述过程会比较繁琐，总结的来说，就是每个条件的每个场景出现次数控制在1-2次内就可以了。对于其他的用例设计方法如图表法和因果图，更多的是体现一种测试思想，实际用例设计中并未接触及使用过。
三，用例覆盖度及缺陷发现效率的衡量
我认为，用例的覆盖度在于你是否将所有功能及特定的异常场景均表现在用例中，发现效率则表示我们在执行用例中会发现的缺陷数量。
首先说关于覆盖度，就像前文所说的，在我写用例过程中，我非常反感出现重复、冗余、无意义的用例。在我看来，用例的覆盖度不应该用具体写了多少用例去衡量，更多的应该是写了多少功能点、写了多少场景来衡量。为什么这么说，原因在我看来很简单，用例写出来之后是由测试人员去执行的，我一直以来的想法是，一份用例的作用不应该是指导完成测试，而应该是引导完成测试。一字之差所代表的含义完全不一样，前者是傻瓜式的执行，后者是带着想法去工作，孰优孰劣，一目了然。那么这就要求我们的用例具有一定的扩散性，而一份冗余的用例是绝对没有这种效果的，至于什么样的用例能带让我们在执行过程中起到引导作用而非指导，关于这点还有想到具体好的方法，这里就阐述下我对用例覆盖度的观念。
接下来说用例的缺陷发现效率，怎么去衡量用例的缺陷发现效率，在我看来，衡量缺陷是不是用例发现的，看的不应该是用例所描述的内容及预期结果，一切在执行用例过程中发现的问题均属于用例发现缺陷！为什么要这么说，前面已经说过了，用例在保证覆盖度的同时要精简，如何去精简，我认为就是将一切无用、重复、冗余的用例都给去除掉。在学习用例编写初期，导师要求我们的是一条用例对应一个检查点，同样这在我看来也只是理论。实际工作中，任何一个步骤做完，它对应的检查点都不可能只有一个，我们所写的预期结果，往往是我们认为最重要或者是更容易出现缺陷亦或者是容易被忽视的情况，但就这些操作本身，所完成的测试点要远远不止一个预期结果。也就是说，如果一条用例执行完了，出现了缺陷，但是这个缺陷与预期结果其实没有多少关系，我们同样应该将其归类于用例发现的缺陷。简而言之就是，用例执行过程中发现的缺陷均属于用例发现缺陷。
对用例的想法基本就全在这里了，絮絮叨叨的说了这么多，在这里我想用一个场景来描述我所想表达的意思。我们所做的工作大多数情况下是黑盒测试，假设我们要对这个盒子进行测试，往往我们所做的是从外向内测试，保证了深度和基本的覆盖度，但实际上，我们更应该做的应该是从这个盒子里面向外测试，也就是说由已有功能对场景进行测试。看似是一样的，但实际意义则完全不同，当我们对内测试时，再深入，所测的也有限且局限性很大，因为我们只能看到我们自有的功能。但我们由功能向外去扩展测试时，所能达到的空间是无限的，这样的测试才能更好的帮助我们提升产品质量！
最后回归到本源，没有人愿意和有耐心重复的去一件无意义的事，这是毫无疑问的。一份用例写出来后最本质的目的其实就是为了让人执行，所以如何让执行人员愿意去执行，并且在执行过程中能够发现足够全面的缺陷，这点才是一份用例的本源。这也是为什么我在文章之初写到，一份用例不应该是指导工作人员完成测试，而应该是引导！