银行测试用例设计经验总结，应该怎样去设计测试用例？

测试用例是软件测试核心，好的测试用例会提高测试效率和软件质量，并指导测试人员的行为，避免遗漏掉测试的功能点。所以在测试之前必须设计好测试用例是非常重要的。

下面我来分享下银行测试用例设计的一些经验，希望可以给大家一些新的启发：

经验1：要参与需求评审，评审需求的过程实际也是熟悉业务需求的过程。只有对产品的业务理解到位，才能更好、更充分地设计出高质量的测试用例。

经验2：对于业务需求比较复杂的交易，最好逐条梳理出对应的测试点，一条测试点对应多条案例。

经验3：测试用例的级别要划分清楚，这样在测试执行时有主次之分。比如冒烟测试时，要写把重要的分支流程测到，确保能够优先发现和解决重要的问题。

经验4：评审用例很关键，经过评审可以发现：

（1）用例设计的结构安排是否清晰合理；

（2）是否覆盖所有功能点；

（3）是否存在冗余用例；

（4）是否存在需求理解上的差异；

经验5：测试用例的设计需要不断的更新维护。即使在测试用例设计完成，进入测试执行阶段时，也需要利用发散的思维不断构造和完善用例。预设条件要明确并且丰富，包括测试数据、测试场景。因为许多缺陷只有在特定的场景下才可以引发。

如何编写用例？

1、测试需求分析，得到测试点

在测试需求分析阶段，我们只有需求文档，所以编写测试用例的唯一依据就是需求文档，因此在进行用例编写之前一定要进行需求分析，需求分析的主要工作就是：了解需求的整个实现背景；分析需求的合理性；明确需求的范围，挖掘需求文档中隐藏的需求；在通过需求交底的过程，确定开发的初步实现思路和方法，随着测试需求分析的深入，列出需求的框架，包括测试范围即各个功能点，测试的场景等；确定一些测试可以提前介入的工作等；需要说明的是对于需求中的问题一定要记录下来，找需求确认，需求漏掉的或者存在问题的地方，开发和测试更容易漏掉，而且遗漏的需求很有可能会使得项目整体业务逻辑发生变化，一定要及时提前确认。

2、分析得到用例优先级

得到了需求的各个测试点后，应该先将这些测试点简单的分配一下优等级，一般分为高中低三个优先级，我认为得到优先级后可以让需求用例的设计更有侧重和着重点。

3、细化测试点变成可执行case

根据测试需求分析得到的需求框架，梳理细化测试点，这里的测试点虽然粗，但是不应该有遗漏，这是进行测试点细化的前提。根据测试点，细化出具体的测试用例，要注意各个点的组合测试的情况，还要注意各个测试点的反向测试的情况。

在细化测试点的时候，我们可以要参考以前写好的公共测试用例，甚至可以直接引用，这样既可以避免一些不必要的时间浪费，但是参考不等于照搬，在引用的同时，也一定要思考本次需求自己特有的测试点。

4、及时更新测试用例

需求分析和用例编写阶段，是主要的细化用例时间，这段时间的目标是梳理出可指导执行测试的用例，但是需求会有变动，需求会有维护，用例也一样，所以用例是需要持续维护的，所以在需求变动的同时，我们也要及时维护测试用例，否则的话，测试用例很可能成为一个错误的指导。

另外测试用例完成后就会进入一个用例评审的阶段，在用例评审阶段，会有用例评审人，针对你的用例作出的评审，主要检查你的用例是否有测试点遗漏，场景遗漏，测试case描述模糊，测试结果输出模糊等问题，针对用例评审人提出的问题，我们也要及时的更改我们的用例。

5、及时维护通用测试用例

通用测试用例就是：项目中或者跨项目中很多的公用业务，固化模块，这些功能基本上是趋于稳定不变的，因此可以梳理出通用的比较全面的测试点，作为指导和规范业务和模块的规范，这些生成的规范即通用的测试用例。当我们针对某一模块或者业务持续维护时，就发现我们需要持续维护这的用例，就会发现有些用例业务类似、执行步骤一致、验证项属性一致等等，这个时候通过梳理业务的通用属性，通用用例梳理梳理成章。

测试用例设计时的分层依据？

7种划分依据是对每个层级的划分依据，通常情况下，测试设计需要多个层级，根据业务特性，可自由组合。

一、按照子模块划分　