软件测试-测试用例设计
软件测试中的需求与用例设计
软件测试中的需求与用例设计在软件开发过程中，需求与用例设计是至关重要的环节。
需求定义了软件系统的功能和性能要求，而用例则是对这些功能需求进行详细描述和验证的测试用例。
本文将从需求分析和用例设计两个方面进行探讨，以便更好地理解软件测试中的需求与用例设计。
一、需求分析1. 需求的定义需求是对软件系统功能、性能和约束条件的描述。
它应该具备明确、一致、完整、可验证等特点。
在需求定义阶段，需求工程师需要与业务方进行充分的沟通与交流，了解用户的真实需求，并将其转化为可执行的软件需求规格。
2. 需求的分类需求可以分为功能需求和非功能需求两种类型。
功能需求描述了软件系统应该具备的功能特点，如输入、输出、计算等。
非功能需求则描述了软件系统的性能、可靠性、安全性等方面的要求。
3. 需求的分析方法在需求分析的过程中，我们可以使用多种方法，包括故事板、用例分析、场景分析等。
其中，故事板方法常用于敏捷开发中，通过讲故事的方式描绘用户的真实场景；用例分析则是以用户视角描述系统的功能特点；场景分析则通过场景的刻画来分析用户的需求。
二、用例设计1. 用例的定义用例是对软件系统功能需求的详细描述，它包括了输入、输出、前置条件、后置条件等元素。
用例的编写应该具备可重复、可验证、完整性、一致性等特点。
2. 用例的结构用例通常由以下几个部分组成：用例标识、用例名称、参与者、前置条件、正常流程、异常流程和后置条件。
其中，正常流程描述了用户按照预期使用系统的场景，异常流程描述了用户可能发生的错误操作或系统异常情况。
3. 用例的设计原则在进行用例设计时，我们需要遵循一些设计原则。
首先，用例应该具备可读性，以方便开发人员和测试人员理解和修改。
其次，用例应该具备可扩展性，能够应对需求变更和系统扩展。
此外，用例还应该足够详细，以便于测试人员能够准确执行测试。
三、需求与用例的关系1. 需求与用例的衔接需求和用例是相互依存的，需求定义了软件系统的功能，而用例则是对这些功能的详细描述。
软件测试测试用例范文
软件测试测试用例范文测试用例1：用户注册功能测试测试目的：验证用户注册功能是否能够正确地注册新用户。
测试步骤：1. 打开应用程序。
2. 点击注册按钮。
3. 输入有效的用户名、密码和电子邮件地址。
4. 点击确认按钮。
5. 检查是否成功显示注册成功消息。
6. 尝试使用相同的用户名和密码进行注册。
7. 检查是否成功显示注册失败消息。
预期结果：- 在步骤5中，应成功显示注册成功消息，并将用户跳转到登录页面。
- 在步骤7中，应成功显示注册失败消息，并保留用户在注册页面。
测试用例2：用户登录功能测试测试目的：验证用户登录功能是否能够正确地验证用户身份。
测试步骤：1. 打开应用程序。
2. 输入已注册的有效用户名和密码。
3. 点击登录按钮。
4. 检查是否成功显示登录成功消息。
5. 输入未注册的用户名和密码。
6. 点击登录按钮。
7. 检查是否成功显示登录失败消息。
预期结果：- 在步骤4中，应成功显示登录成功消息，并将用户跳转到主页面。
- 在步骤7中，应成功显示登录失败消息，并保留用户在登录页面。
测试用例3：商品添加功能测试测试目的：验证商品添加功能是否能够正确地添加商品。
测试步骤：1. 打开应用程序。
2. 登录用户账号。
3. 点击添加商品按钮。
4. 输入有效的商品名称、价格和描述。
5. 点击确认按钮。
6. 检查是否成功显示商品添加成功消息。
7. 尝试添加相同的商品信息。
8. 检查是否成功显示商品添加失败消息。
预期结果：- 在步骤6中，应成功显示商品添加成功消息，并将用户跳转到商品列表页面。
- 在步骤8中，应成功显示商品添加失败消息，并保留用户在添加商品页面。
请根据实际情况自行调整、修改测试用例内容。
软件测试用例范文
软件测试用例范文全文共四篇示例，供读者参考第一篇示例：软件测试用例是软件测试过程中非常重要的一环，它用于描述对软件系统进行测试的情况、步骤和条件。
软件测试用例可以帮助测试人员确定在不同情况下软件系统的性能是否符合要求，发现潜在的缺陷并确保软件质量。
一份优秀的软件测试用例需要具备清晰的目标、详细的步骤、准确的预期结果和良好的可重复性。
下面是一份关于登录功能的软件测试用例范文：测试用例名称：登录功能测试测试目的：验证用户可以成功登录系统前提条件：用户已经在系统中注册账号测试步骤：1. 打开系统登录页面2. 输入正确的用户名和密码3. 点击“登录”按钮预期结果：1. 用户成功登录系统2. 系统显示用户个人信息页面3. 用户可以正常使用系统功能用例覆盖范围：该测试用例覆盖了登录功能的基本操作，包括输入账号、密码和点击登录按钮等操作。
在编写软件测试用例时，需要考虑系统的功能模块、用户需求和系统设计等因素。
测试用例要尽可能覆盖系统各个功能点，保证测试的全面性和准确性。
除了基本的功能测试用例外，还可以编写一些边界测试用例、异常情况测试用例和性能测试用例等，以更全面地评估软件系统的性能和稳定性。
软件测试用例的编写是软件测试工作中非常关键的一部分，它直接影响到测试结果的准确性和软件质量的提高。
通过编写高质量的测试用例，可以有效地发现和解决软件系统中的缺陷，减少系统风险，并提高用户体验和满意度。
【字数已达要求，建议补充内容】第二篇示例：软件测试用例是软件测试中的重要组成部分，它是在软件开发过程中用于验证软件功能是否符合设计要求的一种测试方法。
软件测试用例作为软件测试活动的基础，其质量和有效性直接影响软件测试的效果和成本。
在软件测试中，测试用例旨在检测软件的错误和缺陷，以确保软件质量，提高软件可靠性和稳定性。
软件测试用例的编写需要遵循一定的规范和原则，以确保测试用例的全面性和有效性。
一般来说，软件测试用例可以分为详细测试用例和冗余测试用例。
软件测试-测试用例的设计-黑盒测试方法
件存在的缺陷，而不是简单的复制软件设计规格说明文档 既要设计正面的测试用例，也要设计负面的测试用例
中软国际（天津ETC)
ChinaSoft International 中软国际
Logo
测试用例-黑盒测试用例的设计
产品说明书术语检查清单：
在审查产品说明书时，作为前一个清单的补充，还有一个问题用 语检查清单。
总是、每一种、所有、没有、从不。 当然、因此、明显、显然、必然。 某些、有时、常常、通常、惯常、经常、大多、几乎。 等等、诸如此类、以此类推、例如。 良好、迅速、廉价、高效、小、稳定。 处理、进行、拒绝、跳过、排除。 如果„„那么„„（没有否则）。
•软件功能需求规格说明书、产品设计文档。
•测试方法对测试用例的设计影响非常大。 •测试对象。客户端软件和服务器端系统、分布式系统和集中式系统等。 •软件实现所采用的技术。
8
Logo
测试用例-测试用例的概念和作用
设计测试用例的基本原则如下：
• • • • • • •
利用成熟的测试用例设计方法来指导设计
6
Logo
测试用例-测试用例的概念和作用
好的测试用例的特征
• • • • •
可以最大程度地找出软件隐藏的缺陷
可以最高效率的找出软件缺陷 可以最大程度地满足测试覆盖要求
既不过分复杂、也不能过分简单
使软件缺陷的表现可以清楚的判定
– 测试用例包含期望的正确的结果
– 待查的输出结果或文件必须尽量简单明了
软件测试用例设计考核试卷
5. 以下哪些情况下可能需要回归测试？（ ）
A. 软件修复了一个bug
B. 软件添加了新功能
C. 环境发生变化
D. 代码重构
E. 更新了测试用例
6. 以下哪些工具可以用于自动化测试？（ ）
A. QTP
B. Selenium
C. JMeter
D. LoadRunner
E. Microsoft Word
D. 回归测试
10. 以下哪个不是软件测试的主要类型？（ ）
A. 功能测试
B. 性能测试
C. 安全性测试
D. 编码测试
11. 在软件测试用例设计中，以下哪个方法主要用于测试输入的有效性？（ ）
A. 等价类划分
B. 边界值分析
C. 错误推测法
D. 因果图法
12. 以下哪个测试主要用于检测软件的编码错误？（ ）
10. 在软件测试过程中，______是测试人员根据测试用例执行测试并记录测试结果的活动。
四、判断题（本题共10小题，每题1分，共10分，正确的请在答题括号中画√，错误的画×）
1. 软件测试的目的是证明软件是正确的。（ ）
2. 单元测试主要是由开发人员来执行的。（ ）
3. 测试用例设计完成之后，无需根据项目的变化进行更新。（ ）
2. 功能
3. 代码
4. 测试工具
5. 不能替代人工测试
6. 响应速度
7. 单元测试
8. 用户
9. 兼容性测试
10. 测试执行
四、判断题
1. ×
2. √
3. ×
4. √
5. ×
6. √
7. √
8. ×
9. √
10. ×
测试用例设计的方法
测试用例设计的方法测试用例设计是软件测试中的重要环节，它旨在验证软件系统的正确性和稳定性。
一个好的测试用例设计可以帮助测试人员高效地发现和修复软件中的缺陷，确保软件质量。
下面将介绍几种常用的测试用例设计方法。
1. 边界值分析法边界值分析法通过测试边界值来检验系统的健壮性。
该方法假设错误往往发生在边界上，因此对于特定输入条件，测试用例应包括最小值、最大值以及接近最小值和最大值的临界值。
例如，一个接受年龄输入的系统，可以设计测试用例包括负数、0、1、100、101等边界值。
2. 等价类划分法等价类划分法是将输入条件划分为多个等价类，然后从每个等价类中选择一个测试用例进行测试。
等价类划分法的基本原则是：一个等价类中的数据具有相同的功能和行为，无论选择其中的哪个值作为输入，系统的行为都应该是一致的。
例如，对于一个接受月份输入的系统，可以将月份划分为等价类：1-12个月是有效的输入，其他数字和非数字是无效的输入。
3. 成对测试法成对测试法是一种组合测试方法，它通过组合两个或多个输入条件来设计测试用例，以验证系统对不同条件的组合是否正确处理。
该方法适用于系统具有多个输入条件的场景。
例如，一个在线商城系统，会有多种支付方式和配送方式，可以设计不同的测试用例来测试各种支付和配送方式的组合效果。
4. 状态转换法状态转换法适用于测试有状态的系统，例如有限状态机、状态驱动的系统等。
它通过设计测试用例来验证系统在不同状态下的行为是否符合预期。
测试用例应包括系统从一个状态转换到另一个状态的过程，以及在每个状态下系统的行为。
例如，一个电梯系统的状态可以包括：停止、上升、下降等，可以设计测试用例来测试系统在不同状态下的响应和行为。
综上所述，测试用例设计是软件测试中非常重要的一环。
通过边界值分析法、等价类划分法、成对测试法和状态转换法等方法，可以设计出全面、有效的测试用例。
测试人员可以根据具体的系统特点和需求，选择合适的方法来进行测试用例设计，以提高测试效率和发现软件中的缺陷。
测试用例设计的常见方法总结
测试用例设计的常见方法总结测试用例设计是软件测试过程中的重要一环，它决定了测试的覆盖范围和测试的质量。
合理有效的测试用例设计可以发现更多的错误，提高软件质量。
本文将总结常见的测试用例设计方法，包括黑盒测试方法、白盒测试方法和灰盒测试方法。
1. 黑盒测试方法黑盒测试方法是基于软件系统的功能需求和规格说明，而不考虑内部结构和实现细节的测试方法。
黑盒测试的目的是检验系统功能是否按照需求规格说明书的要求工作。
常见的黑盒测试方法包括：1.1 等价类划分法：将输入和输出的数据分为等价类，从每个等价类中选择一个或多个有效和无效的数据作为测试用例。
1.2 边界值分析法：选择输入数据的边界值和边界值周围的值作为测试用例，以发现潜在的错误。
1.3 决策表测试法：生成决策表，根据决策表的规则设计测试用例，以覆盖所有可能的条件和结果组合。
1.4 直觉法：依据个人的直觉和经验设计测试用例，对于特定的软件系统或特定的功能点可以提供较好的测试覆盖。
2. 白盒测试方法白盒测试方法是基于软件系统的内部结构和实现细节的测试方法。
白盒测试的目的是检验程序的逻辑结构是否正确，是否有遗漏的代码路径。
常见的白盒测试方法包括：2.1 语句覆盖：确保每个语句至少被执行一次。
2.2 判定覆盖：确保每个判定（条件）的所有可能取值至少被覆盖一次。
2.3 条件覆盖：确保判定的每个条件的所有可能取值至少被覆盖一次，包括真值和假值。
2.4 路径覆盖：覆盖所有可能的路径，包括正常路径、异常路径等。
2.5 边界值覆盖：选择边界值和边界值周围的其他值作为测试用例。
3. 灰盒测试方法灰盒测试方法综合了黑盒测试和白盒测试的特点，既考虑功能需求，又考虑内部结构和实现细节。
常见的灰盒测试方法包括：3.1 因果图测试法：通过分析系统功能和数据之间的因果关系，设计测试用例，以覆盖各种情况下的因果关系。
3.2 正交实验设计法：通过正交表设计测试用例，以尽可能减少测试用例的数量和重复覆盖的情况下，达到最优的覆盖率。
软件测试——用例设计3（其他）
软件测试——⽤例设计3（其他）错误推测⽅法：⼀. ⽅法简介1. 定义：基于经验和直觉推测程序中所有可能存在的各种错误, 从⽽有针对性的设计测试⽤例的⽅法。
2. 错误推测⽅法的基本思想：列举出程序中所有可能有的错误和容易发⽣错误的特殊情况,根据他们选择测试⽤例。
1) 例如, 输⼊数据和输出数据为0的情况；输⼊表格为空格或输⼊表格只有⼀⾏。
这些都是容易发⽣错误的情况。
可选择这些情况下的例⼦作为测试⽤例。
2) 例如，前⾯例⼦中成绩报告的程序，采⽤错误推测法还可补充设计⼀些测试⽤例：I. 程序是否把空格作为回答II. 在回答记录中混有标准答案记录III. 除了标题记录外，还有⼀些的记录最后⼀个字符即不是2也不是3IV. 有两个学⽣的学号相同V. 试题数是负数。
3) 再如，测试⼀个对线性表（⽐如数组）进⾏排序的程序，可推测列出以下⼏项需要特别测试的情况：I. 输⼊的线性表为空表；II. 表中只含有⼀个元素；III. 输⼊表中所有元素已排好序；IV. 输⼊表已按逆序排好；V. 输⼊表中部分或全部元素相同。
⼆. 实战演习暂⽆：因果图⽅法：因果图⽅法⼀. ⽅法简介1.定义：是⼀种利⽤图解法分析输⼊的各种组合情况，从⽽设计测试⽤例的⽅法，它适合于检查程序输⼊条件的各种组合情况。
2.因果图法产⽣的背景：等价类划分法和边界值分析⽅法都是着重考虑输⼊条件，但没有考虑输⼊条件的各种组合、输⼊条件之间的相互制约关系。
这样虽然各种输⼊条件可能出错的情况已经测试到了，但多个输⼊条件组合起来可能出错的情况却被忽视了。
如果在测试时必须考虑输⼊条件的各种组合，则可能的组合数⽬将是天⽂数字，因此必须考虑采⽤⼀种适合于描述多种条件的组合、相应产⽣多个动作的形式来进⾏测试⽤例的设计，这就需要利⽤因果图（逻辑模型）。
3.因果图介绍1) 4种符号分别表⽰了规格说明中向4种因果关系。
2) 因果图中使⽤了简单的逻辑符号，以直线联接左右结点。
左结点表⽰输⼊状态（或称原因），右结点表⽰输出状态（或称结果）。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
•针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同
–系统测试重点测试3、7、10、11、12、14，其中压力测试和可移植性测试 如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试 即可
1. 正确性测试
8. 等价划分测试
2. 容错性(健壮性)测试
9. 错误推测
3 点击‘登录’ 登录进系统。 按钮
17
17
8.4.2 测试用例要素与模板
测试用例编写实例--page341
测试用例标识符 Login_1
创建者
测试环境
操作系统、浏览器、网络
前提 条 件
应用服务器正常启动，测试数据准备齐全。
用例描述
通过输入正确的用户名、错误的密码，查看是 否给出登录异常提示信息，验证登录功能实现 的正确性。
操作系统、浏览器、网络
能够进行测试的软硬件条件数据准备。
用例 描述
简要描述测试的对象、目的和所采用的测试方法。
操作步 测试步骤 骤
期望 结果
实际结果
1 具体的操 对应测试步骤的期望值。 执行测试用例所得
作过程。
实际值。
2
3
16
16
8.4.2 测试用例要素与模板
测试用例编写实例--page341 测试用例标识符 Login_1
创建者
测试环境 前提 条 件 用例描述
操作步 测试步骤 骤
操作系统、浏览器、网络
应用服务器正常启动，测试数据准备齐全。
通过输入正确的用户名和密码，查看是否登录成功， 验证登录功能实现的正确性。
期望 结果
实际结果
1 输入用户名 页面上没有红色文字提示。 （正确）
2
输入密码 页面上没有红色文字提示；
（正确） 密码显示为‘*’号。
数据输出
1、正确率 2、输出格式 3、预期结果 4、实际结果
8.4.2 测试用例要素与模板
编写测试用例注意事项 - 软件流程测试
1、反流程操作 2、反逻辑操作 3、重复操作 4、反业务流程操作以及违反流程操作 5、打乱流程操作或不按操作手册操作
23
8.4.3 测试用例设计步骤
设计测试用例的时候，需要有清晰的测试思路；对要测试什么，按照什么 顺序测试，覆盖哪些需求做到心中有数； 测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设 计、功能规格说明、用户使用场景以及程序/模块的结构都有比较透彻的理解
13
8.4.1 测试用例设计概念
测试用例主要元素
测试环境 测试输入数据 测试执行步骤 测试预期结果
8.4.2 测试用例要素与模板
测试用例编写要素 名称和标识
测试追踪/来源
用例说明 测试的初始化要求
测试的输入 测试结果 评价测试结果 操作过程 前提和约束 测试终止条件
唯一的索引标识（序列号），用例名称
3. 完整(安全)性测试 4. 接口测试 5. 数据库测试
6. 边界误推测
10. 效率 11. 可理解(操作)性测试 12. 可移植性测试
13. 回归测试
14. 比较测试
10
8.4.1 测试用例设计概念
测试用例的覆盖内容 •针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同 –单元(模块)测试(组件、控件)测试要重点测试5 –集成测试重点进行接口数据输入及逻辑测试，即4
8.4.1 测试用例设计概念
测试用例的覆盖内容
1. 正确性测试 2. 容错性(健壮性)测试 3. 完整(安全)性测试 4. 接口测试 5. 数据库测试 6. 边界值测试 7. 压力测试
8. 等价划分测试 9. 错误推测 10. 效率 11. 可理解(操作)性测试 12. 可移植性测试 13. 回归测试
14. 比较测试
针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同
8.4.1 测试用例设计概念
测试用例的覆盖内容
•针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同 –其中1、2、6、8、9、13为模块(组件、控件)测试、组合(集成)测试、系统 测试都涉及，要重点进行测试
1. 正确性测试 2. 容错性(健壮性)测试
3. 完整(安全)性测试
10. 效率
4. 接口测试
11. 可理解(操作)性测试
5. 数据库测试
12. 可移植性测试
6. 边界值测试
13. 回归测试
7. 压力测试
14. 比较测试
12
8.4.1 测试用例设计概念
测试用例的覆盖内容 针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同 • 在基础的功能测试用例设计完成后，其他的测试项目只编写设计与之 不同部分的测试用例 • 每个测试项目的测试用例不是一成不变的，随着测试经验的积累或在 测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测 试项目的测试用例
➢ 测试用例的主要组成部分 ➢ 为什么设计测试用例 ➢ 什么样的测试用例是好的测试用例 ➢ 编写测试用例，需要考虑那些方面 ➢ 测试用例的设计过程 ➢ 测试用例为什么需要更新
28
作业
1. 测试用例设计的原则和要素是什么？ 2. 我们如何进行测试用例的设计？ 3. 简述测试用例分级及测试用例优先级的概念
• 批量增删改查操作或大数据量较多 的页面，是否支持全键盘或全鼠标 操作，并支持通键切换
20
8.4.2 测试用例要素与模板
编写测试用例注意事项 - -面向用户的考虑 操作是否符合用户习惯 各种选项可用或禁用是否合理 某些相似操作能否成通用模块
21
8.4.2 测试用例要素与模板
编写测试用例注意事项 - -数据处理
8.4.1 测试用例设计概念
测试用例设计原则
• 基于测试方法（不同的测试方法） • 基于测试需求（单元、集成、配置
项、系统）
• 兼顾测试充分性和效率
• 测试用例代表性
• 测试结果的可判定性
• 测试执行可再现性
• 一个测试用例对应一个功能点 • 测试用例易读 • 测试用例的执行粒度越小越好 • 步骤清晰 • 结果明确 • 测试用例抽象并归类
26
8.4.5 软件测试用例设计的误区
测试用例设计的错误看法 能发现到目前为止没有发现的缺陷的用例是好的用例 测试输入数据设计方法等同于测试用例设计方法 强调测试用例设计得越详细越好 追求测试用例设计“一步到位” 测试用例不应该包含实际数据 测试用例中不需要明显的验证手段 让测试新人设计测试用例
8.4 小结
操作 测试步骤 步骤
期望 结果
实际结果
1 输入用户 页面上没有红色文字提示。 名（正确）
2 输入密码 页面上没有红色文字提 （错误） 示；密码显示为‘*’号。
3 点击‘登 不能登录进系统；红色文 录’按钮 字给出用户名与密码不符 提示信息。
18
8.4.2 测试用例要素与模板
测试用例注意事项
功能检查 面向用户的考虑 数据处理 软件流程测试
3
3
Introduction
8.4.1 测试用例设计概念
为什么设计测试用例
测试用例复用 测试用例覆盖度（有效测试的最核心的目） 评估测试工程师工作 测试过程文档
8.4 测试用例设计
5
8.4.1 测试用例设计概念
高质量测试用例特点
• 正确性 • 完整性（涵盖功能、性能、压力等） • 准确性 • 清晰、简洁 • 可重用性 • 可维护性（根据需求更新、增加、删除）
29
Q&A
30
第8章 动态测试
本节教学目标及重点
教学目标
–介绍动态测试的相关知识和概念 –讲解白盒测试的要求和方法 –讲解黑盒测试的要求和方法 –讲解灰盒测试的要求及方法 –讲解其他测试方法 –讲解测试用例概念以及设计方法
重点
–黑盒测试和白盒测试 –其他测试方法 –测试用例
2
2
本章安排
8.1 “白盒”测试 8.2 “黑盒”测试 8.3 “灰盒”测试 8.4 测试用例设计 8.5 单元测试 8.6 集成测试 8.7 确认测试 8.8 系统测试 8.9 动态测试工具介绍
1. 正确性测试 2. 容错性(健壮性)测试 3. 完整(安全)性测试
4. 接口测试 5. 数据库测试
6. 边界值测试 7. 压力测试
8. 等价划分测试 9. 错误推测 10. 效率 11. 可理解(操作)性测试 12. 可移植性测试 13. 回归测试
14. 比较测试
11
8.4.1 测试用例设计概念
8.4.1 测试用例设计概念
测试用例更具体的设计原则 • 测试用例考虑单次投入成本和多次使用成本 • 总体思路是先进行基本功能测试，再进行复杂功能测试； • 先进行一般用户测试，在进行特殊用户使用测试； • 先进行正常情况测试，再进行特殊情况测试； • 用测试用例文档替代产品文档 • 避免冗长和复杂的测试用例
涉及的参考资料，如用户的需求、涉及文档等
测试对象，采用的方法 哪个测试对象？在什么硬件/软件—平台？
输入数据 期望测试结果 精度等 测试步骤 约束 正常终止或异常终止
15
15
8.4.2 测试用例要素与模板
测试用例编写实例--page341
测试用例标识符
测试环境 前提 条 件
功能模块+业务流 创建者 程组合（前几个字 母）
24
8.4.3 测试用例设计步骤
测试用例更新完善 • 软件产品功能新增或更新需求 • 测试执行过程中，测试用例考虑不周 • 软件交付后，客户反馈缺陷 • 软件上线后，测试人员自己发现的缺陷 • 维护阶段，其他人员反馈的缺陷
25
8.4.4 测试用例分级
重要性：1 基本、2 重要、3 一般、4 特殊 优先级：1 高、2中、3低