前言：
测试工作最为基础核心的内容就是设计测试用例，什么样的测试用例是好的测试用例？我们一般会认为数量越少，发现缺陷越多的用例就是最好的用例。
那么我们如何才能设计出好的测试用例呢？
一份好的用例是设计出来的，是测试人员思路和方法的集合，而非测试逻辑和需求的罗列。
一、测试用例设计的几个准则
1、用例设计=思路
强调测试的场景，测试方法。
2、测试步骤化
此处说的测试步骤，不是说每条测试用例都要写明测试步骤，而是指那些通过测试步骤的调整会出现缺陷的地方需要重点关注测试步骤，比如添加操作，单纯的添加功能是OK的，但是先删除一条数据，再添加相同的数据就失败了，这个就涉及到操作步骤了。
3、用例流程化
此过程依托于完整的业务流程图，每个分支就是一条支流，通过业务端发起的请求，最终都会流向一条分支，而流程化就是将这些分支梳理为测试场景，通过覆盖测试场景来覆盖业务逻辑。
二、测试用例设计的步骤
1、明确原始需求
原始需求是软件的使用者（客户）的需求，在需求文档基础+本质理解才能真正理清楚需求要实现什么样的目的，以此为出发点才能不偏离需求本质；
2、拆分原始需求
在需求测试阶段，如果按照需求测试策略对需求梳理一遍之后，对于所有的需求点应该都已经很清楚了，将这部分的需求点罗列出来，就可以作为需求粗略的测试点；
3、梳理业务逻辑
现在比较多的前端业务都来源于接口所返回的数据，前端最多的时候也就是根据返回数据做一些相应的显示和计算，所以如果对页面设计测试用例，那么需要关注接口数据的完整性和正确性对页面的影响，而接口本身的测试则要归纳到接口测试用例设计环节。
• 接口没有返回数据时，页面如何处理；
• 接口返回的参数不完整，比如返回包有list结构，此作为前台展示列表数据的依据，但是list为空；
• 接口返回包中没有需求的参数名称
这个地方有一个原则，需要注意，即前后端分离和前后端测试集合。
• 前后端分离，有专门的接口测试人员来保证接口功能的正确性。此时作为前端测试人员，只需要保证接口返回数据正确时，页面显示正确；接口返回数据异常时，页面显示正确；调用接口的数据正确即可；
• 前后端半分离，接口也做测试，但是是使用自动化工具，保证基本的参数正确性与通畅性，而对于接口的逻辑需要前端配合测试。
此时作为前端测试人员，就需要了解接口的实现逻辑，如数据的处理逻辑，存储结构等。据此来设计前端测试用例，必要时也要绕开前段，直接调用接口模拟前段测试。
综上所述，对业务逻辑的理解程度，取决于业务的结构，在理解了业务逻辑后，补充对应需求点的业务逻辑测试点。
4、区分页面测试和业务逻辑类测试
页面层级的测试遵循以下的方法：
• 整体界面测试：就是去验证整体的界面是否和设计图一致；
• 界面元素测试
• 控件操作验证：如对控件能否操作、操作是否正常的验证；
业务逻辑（功能）等级的测试遵循以下方法：
• 任何情况下都必须使用边界分析法，出问题最多的就在边界值；
• 必要时用等价类划分方法补充一些测试用例；
• 用错误推测法再追加一些测试用例；
• 对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例
三、测试用例的方法
用例测试方法：基于需求的设计方法、等价类划分法、边界值分析、场景法 、错误推断、因果图、正交排列、探索式测试
1、需求分析法
RBT( Requirements-Based Testing)是基于需求的测试方法，按照需求去设计测试用例。有多细致的需求就有多细致的测试用例. 基于需求的测试是一种最根本的软件测试，重点关注以下两大关键问题。
（1）验证需求是否正确、完整、无二义性，并且逻辑一致。
（2）要从“黑盒”的角度，设计出充分并且必要的测试集，以保证设计和代码都能完全符合需求。
2、等价类划分法
等价类划分法将所有可能的输入数据（有效和无效）划分成若干个等价类，然后找中找出具有代表性的数据进行测试。
a.定义有效类和无效类：
（1）数据划分
（2）数据类型
（3）是否为空
b.等价类划分原则：
（1）有效类尽可能多覆盖
（2）无效类只覆盖一个
c.使用场景:输入条件（取值范围/值个数；必须值集合；布尔值；一组处理值；必须遵守的规则；再细分更小等价类；）
d.举例：
3、边界值分析法
a.边界值是对等价划分的一个补充，边界值一般是去等价类的边缘去寻找。
b.取值原则：正好等于、刚刚大于、刚刚小于边界值的数据作为测试。
c.需特殊考虑0和负数。
d.使用场景：输入+输出都需要考虑（值的范围；值个数；有序集合；内部数据结构；分析规格说明；）
e.举例：
4、场景法
a.将业务流程场景化，测试用例遍历场景，验证系统功能的正确性；
b.场景法的原则（正常流+分支流）：
正常路径；
根据每个判断，去找另一个出口；
确定出错之后还能正常操作，再多走一个步骤；
c.注意事项：场景法的重点是流程测试，每个流程一个测试用例验证即可，还需对单个功能进行测试。
d.使用场景：
e.举例：
5、错误推断法
错误猜测法是经验丰富的测试人员喜欢使用的一种测试方法。错误猜测法只适用于其他测试用例设计法，设计完测试用例之后，进行测试用例的补充。
（1）基于经验和直觉，找出程序中你认为可能出现的错误，有针对性地设计测试用例。
（2）经验可能来自于在对某项业务的测试较多，也可以来自于售后用户的反馈意见
（3）从故障管理库中整理bug。
使用场景：任何测试、任何情景下都会用到的方法。
举例：数字输入验证，分别输入数字(正数、负数、零值、单精度、双精度)、字符串、空白值、空值、临界数值；不合法的输入，系统给出必要的判断提示信息；
6、判定表法
定义：分析和描述若干条件下 ，被测对象针对这些输入所做出的一些回应，在遇到复杂业务逻辑时可以利用该表理清业务逻辑关系
重要概念：条件桩：需求规格说明定义的被测对象输入、条件项
动作桩：输入所做出的回应、动作项
规则：动作项和条件项组合在一起，形成的业务逻辑处理规则。
使用场景：控制类和游戏。优点是能把复杂的问题按各种可能的情况一一列举出来，简明而易于理解，也可避免遗漏。缺点是不能表达重复执行的动作，例如循环结构。
7、因果法
表示输入和输出关系的一种逻辑图.使用场景：当需求有多个输入时候，并且需求的输出和输入相关，我们就用因果图法。
恒等：如果原因为真，那么结果必定为真。
与：只有两个原因都为真，结果才为真。
或：只要有一个原因为真，结果就为真。
非：原因为假，结果为真。
因果图设计测试用例的步骤：
分析所有输入输出的可能
找出输入和输出之间的对应关系、
画出因果图
把因果图转为判定表
把判定表对应到每一个测试用例
使用场景：必须考虑输入条件的各种组合（一种适合于描述多种条件的组合、相应产生多个动作的形式来进行设计）；
8、正交实验法
就是在各因素互相独立的情况下，设计出一种特殊的表格，找出能以少数替代全面的测试用例（查询条件）虽然说是特殊的表格，实际表现形式跟一般的表格没有什么区别，正交表的主要特征是，“均匀分布，整齐划一”，正是因为“均匀”的，所以才能以少数代替全部。
正交法设计测试用例的步骤：
有哪些因素（变量）
每个因素有哪几个水平（变量的取值）
选择一个合适的正交表
把变量的值映射到表中
把每一行的各因素水平的组合作为一个测试用例
加上你认为可疑且没有在表中出现的用例组
使用场景：必须考虑输入条件的各种组合（从大量的数据中挑取适量、有代表性的点，合理有效的测试
9、探索式测试法
探索式测试法：无限创意的测试点，永无止境的探索测试；我们要在测试的最前沿发挥洞察力、技术及应变措施，找出产品的缺陷；
分析思路：
局部探索式测试；全局探索式测试；混合探索式测试；
使用场景：任何测试、任何情景下都会用到的方法。像漫游一样，自由地寻找软件中的缺陷，软件测试的未来必然有探索式测试。
四、测试用例方法的选择
等价类划分法，输入条件的划分（提高测试最有效的方法）；
任何情况都使用边界值分析法（发现程序错误的能力最强）；
用错误推断法去追加测试用例；
使用场景法尽可能覆盖用例.
标签：需求,场景,接口,测试用例,测试,设计 来源： https://www.cnblogs.com/xiaohuanpython/p/16054862.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。