测试场景/测试用例
在敏捷的项目中，大家一讲到测试，就会联想到测试用例，就是一大堆很繁杂需要追踪的用例，编写耗时，很难维护，费人费时
目前还有一种在敏捷的项目中，衡量时间和人力成本，去实现软件质量把控的方式，就是书写测试场景
一、Test Scenario VS Test Case
- Test Scenario: 测试场景
- Test Case：测试用例
- 它们的关系：
Use Case -> Test Scenario --> Many Test Cases
1.1 它们有什么区别？
| 测试场景 | 测试用例 |
|---|---|
| 测试方案包含高级文档，这些文档描述了要测试的端到端功能。 | 测试用例包含确定的测试步骤，数据，用于测试应用程序所有功能的预期结果。 |
| 它侧重于“测试什么”而不是 “测试方法”。 | 完全强调“要测试什么” 和 “如何测试”。 |
| 测试方案是单线的。因此，在测试过程中始终存在歧义的可能性。 | 测试用例定义了一个步骤，先决条件，预期结果等。因此，此过程中没有歧义。 |
| 测试方案源自BRS，SRS等测试工件。 | 测试用例主要来自测试场景。多个测试用例可以从单个测试方案中得出 |
| 它以敏捷的方式测试端到端功能 | 它有助于对应用程序进行详尽的测试 |
| 测试方案是高级操作。 | 测试用例是低级操作。 |
| 使用方案创建和测试所需的时间和资源相对较少。 | 需要更多资源来记录和执行测试用例。 |
对比DEMO-什么是测试场景，什么是测试用例：
一个场景包含了一系列的测试用例，场景与需求点映射，无需关注太多的用例输入(正例/反例)，更注重操作流程
- 测试场景：验证登录功能，一句话简单描述功能
- 测试用例：可能包含许多例子，比如输入用户名密码字段验证输入正确是否能提交表单/输入用户名密码字段错误是否能给出提示，是否阻止提交等正例与反例
1.2 为什么要编写测试方案
- 编写测试方案的主要原因是要验证软件应用程序的完整功能
- 它还可以帮助您确保业务流程和流程符合功能要求
- 测试场景可以由业务分析人员，开发人员，客户等各种利益相关者批准，以确保对被测应用程序进行全面测试。它确保该软件适用于最常见的用例。
- 它们可作为确定测试工作量的快速工具，从而为客户提出建议或组织工作人员。
- 它们帮助确定最关键的端到端事务或软件应用程序的实际使用。
- 一旦完成这些测试方案，就可以轻松地从测试方案中得出测试用例。
1.3 为什么要编写测试用例？
- 测试用例有助于验证是否符合适用的标准，准则和客户要求
- 帮助您验证期望和客户要求
- 增加控制，逻辑和数据流覆盖范围
- 您可以模拟“实际”最终用户方案
- 暴露错误或缺陷
- 编写测试用例以进行测试执行时，将更好地简化测试工程师的工作
二、测试场景Test Senario 填写内容
- 了解系统模块需求
- 针对需求，找出可能的用户操作和目标
- 列出不同的测试场景已验证软件的每个功能
- 建立需求和测试方案的对应关系，确保每个需求都有对应的测试方案
- 审核测试场景组合而成的测试方案
- 每个测试方案需要至少于一个需求或者用户案例相关联
- 在创建一次验证多个需求的测试方案之前，请确保您具有一个测试方案，用于单独检查该需求。
- 避免创建跨越多个需求的过于复杂的测试方案。
- 方案的数量可能很大，并且全部运行这些方案的成本很高。根据客户优先级，仅运行选定的测试方案
2.1 表格内容描述：
- 场景编号
- 模块名称：具体测试场景的名称，如：登录页面。
- 测试场景描述：场景内容，例如验证“登录”页面上是否存在所有标签和控件，包括文本框，按钮和链接。
- 测试用例数
| 模块名称 | 场景编号 | 测试场景描述 | 对应测试用例数 |
|---|---|---|---|
| 登录模块 | TS_1.1.1 | 验证登录功能 | 3 |
| 个人信息模块 | TS_2.1.1 | 验证用户信息修改 | 2 |
三、测试用例Test Case 填写内容
3.1 如何编写?
- 将需求文档描述的内容，重新按照用例的格式编辑一次，把能想到的各种可能性添加进去
- 如果用一条用例覆盖一个功能点在实际操作中有很大的缺陷，每个用例覆盖一个功能点，是最佳的理想状态
- 从功能、性能、可用性、客户端兼容性、安全性着手，设计测试用例
- 功能性测试：链接测试，表单测试，Cookies测试，设计语言测试，数据库测试
- 非功能性测试： (1)性能测试（连接速度测试，负载测试，压力测试）, (2)可用性测试（导航测，图像测试，内容测试，整体界面测试）， (3)兼容性测试（平台测试，浏览器测试）， (4)安全性测试（先注册后登录，登录超时限制，日志文件可追踪，服务端脚本安全性，Https通信）
- 主要包含：功能测试用例设计-functional，接口测试用例设计-api，性能测试用例设计-performance
3.2 表格内容描述：
- 用例编号
- 用例名称：具体测试用例的名称。如：输入账号、输入密码、密码不合规等等。
- 所属模块：该功能点具体属于哪个模块的，填写这个主要是方便查找，如：注册/登录模块。
- 用例类型：记录用例类型，功能/接口/性能
- 维护人：记录维护人
- 用例等级：描述重要程度
- 测试方式： auto-自动 ，manual-手动（选择这个）
- 前置条件：指要达到预期测试结果，需要满足那些条件才能达到。如：账号密码不一致时，就需要登录失败，那么此时就得保证账号正确或密码正确以及账号正确时是存在的。
- 备注：给出相关提示说明
- 步骤描述：指要达到预期测试结果，需要按这些步骤来。最好说明在什么页面，点击或操作什么内容，输入什么内容。
- 预期结果：说明按照前面写的应该呈现出怎样的结果。
| 用例编号 | 用例名称 | 所属模块 | 用例类型 | 维护人 | 用例等级 | 测试方式 | 前置条件 | 备注 | 步骤描述 | 预期结果 |
|---|---|---|---|---|---|---|---|---|---|---|
| TC_1.1.1 | 测试用例1 | 登录模块 | performance | 人1 | P0 | 手动 | 具备用户名密码 | 无 | 1.步骤前可标序号 2.步骤前可标序号 | 登陆成功 |
