前言
我从来没有好好的写过一个测试用例，之前做开发虽然写单元测试和流程测试，基本上都是基于自己的代码，而且单元测试和流程测试的框和规范已经非常完善，你只需要填空就行，后来转做自动化测试，但我的做事的方法和思维还停留在开发层面，用例基本上是从手工业务功能测试集抽取，我只要按照这个子集给转换成脚本代码去运行就好了，并没有系统地完完整整的根据业务需求去手工写个一个用例。闲暇的时候，我们也会聊什么才算是一个好的测试用例，在深入了解这个之前，我去系统的看了下测试的基础。
测试也是有很多方法的。从网上也能搜到这方面的很多资料，我也是总结前辈的知识。
测试的方法
作为测试，我们的主要目标就是保证系统在各种应用场景下的功能是符合设计要求的，所以你需要考虑的测试用例就需要更多、更全面。那怎么设计测试用例呢，我们通常会根据所测功能的业务需求，一般使用等价类划分和边界值分析方法等来设计一系列的测试用例
等价类划分方法
是将所有可能的输入数据划分成若干个子集，在每个子集中，如果任意一个输入数据对于揭露程序中潜在错误都具有同等效果，那么这样的子集就构成了一个等价类。后续只要从每个等价类中任意选取一个值进行测试，就可以用少量具有代表性的测试输入取得较好的测试覆盖结果。
举例说明
一个很常见的例子：学生的考试成绩，成绩的取值范围是 0 到100 之间的整数，60分及格。为了测试这个输入项，显然不可能用 0到100 的每一个数去测试（排除那种规格容量测试，有的就是要遍历所有，这时候可以考虑用脚本去执行）。
那么我们就可以根据这个成绩是否及格这个需求来划分等价类， 及格类和不及格类那么这就可以在 0到59 和 60到00 之间各随机抽取一个整数来进行验证。这样的设计就构成了所谓的"有效等价类"。
这里还没有结束， 因为等价类划分方法的另一个关键点是要找出所有"无效等价类"。显然，如果输入的成绩是负数，或者是大于 100 的数等都构成了"无效等价类"。在考虑了无效等价类后，最终设计的测试用例为：
有效等价类 1：0~59 之间的任意整数；
有效等价类 2：59~100 之间的任意整数；
无效等价类 1：小于 0 的负数；
无效等价类 2：大于 100 的整数；
无效等价类 3：0~100 之间的任何浮点数；
无效等价类 4：其他任意非数字字符。
边界值分析方法
是选取输入、输出的边界值进行测试。因为通常大量的软件错误是发生在输入或输出范围的边界上，所以需要对边界值进行重点测试，通常选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。边界值分析方法其实是对等价类划分的补充。那么结合上述学生成绩的例子选取的边界值数据应该包括：-1，0，1，59，60，61，99，100，101。
错误推测方法
错误推测方法是指基于对被测试软件系统设计的理解、过往经验以及个人直觉，推测出软件可能存在的缺陷，从而有针对性地设计测试用例的方法。这个方法强调的是对被测试软件的需求理解以及设计实现的细节把握，当然还有个人的能力。
错误推测法和目前非常流行的"探索式测试方法"的基本思想和理念是不谋而合的，比如被测模块之间的联系和影响，当一个地方有需求变更的时候，其他地方是否会受影响等
如何才能设计出"好的"测试用例？
除了以上三种方法，还有其他的测试方法，掌握其中最常见的，基本上就可以设计测试用例了。
对于功能测试来说，最核心的测试点就是验证软件对需求的满足程度，这就要求测试工程师对被测软件的需求有深入的理解。那么需求分析和设计阶段就要和开发产品一起参加需求分析评审会，开始设计测试用例，因为这个阶段是理解和掌握软件的原始业务需求的最好时机。只有真正理解了原始业务需求之后，才有可能从业务需求的角度去设计针对性明确、从终端用户使用场景考虑的端到端（End-2-End）的测试用例集。这个阶段的测试用例设计，主要目的是验证各个业务需求是否被满足，主要采用基于黑盒的测试设计方法。
在具体的用例设计时，首先需要搞清楚每一个业务需求所对应的多个软件功能需求点，然后分析出每个软件功能需求点对应的多个测试需求点，最后再针对每个测试需求点设计测试用例。以"用户登录"功能的测试用例设计为例，如下图来理清这些概念之间的映射关系。图中的业务需求到软件功能需求、软件功能需求到测试需求，以及测试需求到测试用例的映射关系
设计用例需要注意的点
具体到测试用例本身的设计，有两个关键点需要注意。
从软件功能需求出发，全面地、无遗漏地识别出测试需求是至关重要的，这将直接关系到用例的测试覆盖率。 比如，如果你没有识别出用户登录功能的安全性测试需求，那么后续设计的测试用例就完全不会涉及安全性，最终造成重要测试漏洞。
对于识别出的每个测试需求点，需要综合运用等价类划分、边界值分析和错误推测方法来全面地设计测试用例。 这里需要注意的是，要综合运用这三种方法，并针对每个测试需求点的具体情况，进行灵活选择。以"用户登录"的功能性测试需求为例，你首先应该对"用户名"和"密码"这两个输入项分别进行等价类划分，列出对应的有效等价类和无效等价类，对于无效等价类的识别可以采用错误猜测法（比如，用户名包含特殊字符等），然后基于两者可能的组合，设计出第一批测试用例。等价类划分完后，你需要补充"用户名"和"密码"这两个输入项的边界值的测试用例，比如用户名为空（NULL）、用户名长度刚刚大于允许长度等。
结语
优秀的测试用例一定是一个完备的集合，它能够覆盖所有等价类以及各种边界值，而能否发现软件缺陷并不是衡量测试用例好坏的标准。其次，设计测试用例的方法有很多种，但综合运用等价类划分、边界值分析和错误推测方法，可以满足绝大多数软件测试用例设计的需求。再次，"好的"测试用例在设计时，需要从软件功能需求出发，全面地、无遗漏地识别出测试需求至关重要。最后，如果想设计一个"好的"测试用例，你必须要深入理解被测软件的架构设计，深入软件内部的处理逻辑。
这样不仅是手工测试还是自动化化测试，有了完善优秀的测试用例集做支撑，才能更好的保障产品的质量，另一方面在开发自测阶段其实也是可以参考测试用例去做一些测试的。
开发和测试从来就不是一个对立面，手工测试和自动化测试也不是。大家都是在整个开发流程中必不可少的一环，相辅相成，最终目的都是把这个东西做好。但实际的项目中，总会有各种各样的问题，这讨论的又是另一回事了。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！