标签：数值 理解 控制 功能 结果 消息 www 部件 概率
测试用例包含：
项目名称，测试环境，设计人，更新日期
用例编号，功能模块，子模块，用例标题，前置条件，测试步骤，预期结果，实际结果，用例优先级，软件版本，是否自动化
1)、系统基本功能，设置时1级用例的数量应受到控制、
2)、划分依据：执行的失败会导致重要功能无法运行的，如：表单维护中的增加功能、最平常的业务使用等。可以认为是发生概率较高的而经常这样使用的一些功能用例。
3)、该级别的测试用例在每一轮版本测试中都必须执行
1)、系统的重要功能。2级用例数量较多。
2)、划分依据：主要包括一些功能交互相关、各种应用场景、使用频率较高的正常功能测试用例
3)、在非回归的系统测试版本中基本上都需要进行验证，以保证系统所有的重要功能都能够正常实现。在测试过程中可以根据版本当前的具体情况进行安排是够进行测试。
1)、设计系统的一般功能，3级用例数量也较多。
2)、划分依据：使用频率较低于2级用例。例如：数值或数组的便捷情况、特殊字符、字符串超长、与外部件交互消息失败、消息超时、事物完整性测试、可靠性测试等等。
3)、在非回归的系统测试版本中不一定都进行验证，而且在系统测试的中后期并不一定需要每个版本都进行测试
1)、该级别用例一般非常少。如果没有可以不使用该级别
2)、划分依据：该用例对应较生僻的预置条件和数据设置。虽然某些测试用例发现过较严重的错误，但是那些用例的条件非常特殊，仍然应该被植入4级用例中。如界面规范化的测试也可归入4级用例。在实际使用中使用频率非常低、对用户可有可无的功能。
3)、在版本测试中有某些正常原因（包括：环境、人力、时间等）经过测试经理同意可以不进行测试。
常见的方法：
等价类，边界值，因果图，判定表，正交实验法，功能图法，场景实验法， 错误推断法，需求转化，探索式测试，设计文档，用户体验
具体方法怎么使用可参考博客：
https://www.cnblogs.com/fuxinxin/p/8991703.html
使用各种编写方法的综合设计策略；
1)编写时按照模块-子模块-功能点的原则覆盖功能，由面到点全面覆盖功能
2)边界值分析：使用边界值设计出测试用例发现程序错误的能力最强。
3)等价类划分：必要时用等价类划分方法补充一些测试用例，尤其注意无效等价类情况。
4)因果图法：多种条件组合时，优先选用因果图法（或判定表法、正交试验法）。
5)错误推断法：用错误推测法再追加一些测试用例，主要是利用测试经验。
6)逻辑覆盖：对照程序逻辑，检查已设计出的测试用例的逻辑覆盖程度，如果没有达到要求的覆盖标准，应当再补充足够的测试用例；参照白盒用例编写。
7)用户场景测试：对程序的应用场景进行研究和思考，设计不同场景下的测试用例；用户场景测试必须重视，很大一部分程序错误就是因为测试场景与用户真实场景的差异性带来的。
8)探索式测试：对业务和程序有更深的理解之后，可以充分发挥发散思维和探索式想法；大家不要误解探索式测试就是漫无目的的测试，其实探索式测试有非常详细的测试指导思路。
9)用户体验测试：可以模拟用户使用习惯，增加用例
标签：数值 理解 控制 功能 结果 消息 www 部件 概率
原文地址：https://www.cnblogs.com/leslie12956/p/12204788.html
