目录：
一.测试用例设计的两个基本方法
二.如何编写测试用例
三.如何提升用例编写能力
（前提：已知测试用例是什么，以及基本的用例格式。）
一.测试用例设计的两个基本方法
即，等价类划分和边界值分析。
这里要强调一句，等价类和边界值是每个Tester深入骨髓的最基本的用例设计方法。应该像条件反射一样，每当一个正面用例写出来，与之对应的一堆反面用例就应该立马出现。
而边界值分析，提升测试覆盖率的效果特别明显。边界值的使用范围很固定，只要有边界的地方就想着去应用。
二.如何编写测试用例
1、测试需求分析，得到测试点
在进行用例编写之前一定要进行需求分析，需求分析最好是根据需求文档。
需求分析的主要工作就是：了解需求的整个实现背景+分析需求的合理性+明确需求的范围+挖掘需求文档中隐藏的需求。在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等，确定一些测试可以提前介入的工作等。需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。
2、分析测试点优先级
得到了各个测试点后，应该先将这些测试点分配优先级，一般分为高中低三个优先级，得到优先级后可以让用例的设计更有侧重点。
3、细化测试点变成可执行case
根据需求分析得到的需求框架，进而得到测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。
在细化测试点的时候，可以参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。
另外需要考虑的就是测试点细化到什么程度的问题，也就是一个度的问题，我们要把握好测试点细化的一个度的问题，太粗的测试点没有指导意义，太细的测试点容易让我们纠的太细，忽略整体的测试，反而也起不到一个指导的效果，所以一定要把握好测试点细化的度。
4、及时更新测试用例
需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的， 所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。
另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改用例。
三.如何提升用例编写能力
1、熟悉业务，了解系统
任何系统都有大的业务背景，只要熟悉了业务知识才能更有效的使用系统。任何系统在使用过程中，都有一个熟悉的过程，对系统越熟悉，越容易发现系统问题和业务问题。
2、用客观的思考方式站在用户的角度分析
作为测试人员如果想提升测试用例的编写能力，首先应该做到的就是站在客户的角度分析客户需要什么和客户想要什么，客户不想要什么，也就是所谓的客户的使用场景，这样有利于我们更好的挖掘和思考隐含的需求。至于这个需求该不该做，那是需求人员的职责，这个需求做起来复不复杂那是开发人员的事情，作为测试人员需要考虑的事就是你所设计的正向和反向测试用例是不是用户常用到的场景，以及一些客户基本不会用到的场景有哪些。
3、多思考，不要拘束于惯性思维
一个人做一个工作时间越久，也就是我们说的经验越丰富，可能这个思维方式就会固话。比如，测试的统计表多了，当拿到一个新增的统计表的时候，首先想到的是公用用例上所列的测试点基本上就是最全的了，我都不用思考，直接用就行了。
其实这是一个误区，公用用例的目的是帮助我们减少一些不必要的内耗，但是我们的思维不要被它所限定，如果公用用例中某个点是错的，那我们岂不要一错再错了。所以作为一个测试人员如果想要提升自己的测试用例设计能力，一定要多思考，不要被这种惯性思维束缚，不要被所谓的经验束缚。