测试有例设计方法有：1. 等价类划分；2. 边界值分析法；3.错误推测法；4. 因果图方法；5. 正交试验设计法；6. 判定表法。其中，等价类是指某个输入域的子集合，在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。
一、测试有例设计方法
1. 等价类划分
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试。因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据。取得较好的测试结果。等价类划分可有两种不同的情况：有效等价类和无效等价类。
举例：我们要测试一个用户名是否合法，用户名的定义为：8位数字组成的字符。我们可以先划分子集：空用户名，1-7位数字，8位数字，9位或以上数字，非数字。然后从每个子集选出若干个有代表性的值。
2. 边界值分析法
边界值分析方法是对等价类划分方法的补充。测试工作经验告诉我，大量的错误是发生在输入或输出范围的边界上，而不是发生在输入输出范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。使用边界值分析方法设计测试用例，首先应确定边界情况。通常输入和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。
举例：假定 X 为整数,10≤X≤100,那么 X 在测试中应该取的边界值为：10，11，99，100。
3.错误推测法
基于经验和直觉推测程序中所有可能存在的各种错误,，从而有针对性的设计测试用例的方法.错误推测方法的基本思想：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据他们选择测试用例-例如，在单元测试时曾列出的许多在模块中常见的错误-以前产品测试中曾经发现的错误等,，这些就是经验的总结。还有，输入数据和输出数据为0的情况。输入表格为空格或输入表格只有一行-这些都是容易发生错误的情况。可选择这些情况下的例子作为测试用例。
举例：错误推测法没有固定的形式，依靠的是经验和直觉，很多时候，我们都会不知不觉的使用到。
4. 因果图方法
前面介绍的等价类划分方法和边界值分析方法，都是着重考虑输入条件，但未考虑输入条件之间的联系，相互组合等-考虑输入条件之间的相互组合，可能会产生一些新的情况-但要检查输入条件的组合不是一件容易的事情， 即使把所有输入条件划分成等价类，他们之间的组合情况也相当多-因此必须考虑采用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来考虑设计测试用例-这就需要利用因果图（逻辑模型）-因果图方法最终生成的就是判定表-它适合于检查程序输入条件的各种组合情况。
举例：某软件规格说明书包含这样的要求：名列前茅列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改，但如果名列前茅列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
5. 正交试验设计法
有时候，可能因为大量的参数的组合而引起测试用例数量上的激增，同时，这些测试用例并没有明显的优先级上的差距，而测试人员又无法完成这么多数量的测试，就可以通过正交表来进行缩减一些用例，从而达到尽量少的用例覆盖尽量大的范围的可能性。
举例：某所大学通信系共2个班级，刚考完某一门课程，想通过“性别”、“班级”和“成绩”这三个查询条件对通信系这门课程的成绩分布，男女比例或班级比例进行人员查询。按照传统的方式，我们将会穷举所有的组合，来编写测试用例，组合个数是2*2*2=8。当组合条件不多的时候，穷举暂时没问题，但是，一旦条件多了，组合个数就会以指数形式增长。这个时候，就要用到正交表了，通过选出有代表性的测试实例，达到以少数代替全面的效果。
6. 判定表法
判定表法又称为策略表，基于策略表的测试，是功能测试中最严密的测试方法。该方法适合于逻辑判断复杂的场景，通过穷举条件获得结果，对结果再进行优化合并，会得到一个判断清晰的策略表。
举例：某公司的对客户分类标准如下：顾客每次订货额在 1000元以上（含1000元），信誉好的，订单设“优先”标志；信誉不好，但是老客户的，订单设“优先”标志；信誉不好，但是新客户的，订单设“正常”标志；每次订货额在 1000元以下，订单设“正常”标志。因为穷举了所有条件，所以可以说这个判断是100%正确的。下一步是对这个表进行合并优化。例如，从编号为1，2的列可以看出，顾客订单>=1000，信誉好，不管是新顾客还是老顾客，都设为优先，这样一来，我们就可以得到更清晰的逻辑判断，也可以更好的协助我们编写测试用例。而决策表，对于开发人员来说一样有用。
延伸阅读：
二、测试用例应注意的问题
测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试用例。在测试执行中需要注意以下几个问题：
1.全方位的观察测试用例执行结果：
测试执行过程中，当测试的实际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用情况，来判断测试用例是否执行成功了。
2.加强测试过程记录：
测试执行过程中，一定要加强测试过程记录。如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人员重现问题。
3.及时确认发现的问题：
测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷，测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录重现问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续定位问题。
4.与开发人员良好的沟通：
测试执行过程中，当你提交了问题报告单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则，那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自己的前提下，再开始与开发人员交流。
以上就是关于测试用例的有关内容希望对你有帮助。
