用例设计主要问题

主要问题存在于：

1、测试点分析：逻辑性不强

                      对于整个页面功能划分不清晰；
                      不同测试点归类不清晰；
                      不能形成相对固定的套路，书写耗费大量时间...

2、测试用例：关于，要细致到什么程度，不太明确

                  对于UI效果等的检查也要写进初次测试的用例吗？

3、测试用例设计时是依据需求说明书还是系统？

• 流程规范的公司，一定是基于需求说明书（或原型图）来设计测试用例

• 进入项目的时间节点来看

• 项目初期介入，依据需求说明书

• 项目中后期介入，依据还是需求说明书

• 有可能在实际测试过程中，没有需求说明书，可以参考当前的系统，同时需要结合自身测试经验进行结果的甄别

• 项目维护阶段介入，依据需求说明书

• 有可能在实际测试过程中，没有需求说明书，可以参考当前的系统、用户手册、bug清单等

4、这个用例没啥问题 就是时间问题 没写完

测试数据：

• 注意测试数据的时效性（测试准备）

• 如注册时的手机号在第一次注册时是未注册的，第二次再注册时就变为已注册了，所以不是特定的数据场合下，我们可以省略这些测试数据。

• 标题与预期结果要明确

• 注意：如果需求中没有说明类似的错误提示消息，我们应该借助于其他同类型产品的处理方案或消息来设置用例的预期结果。

测试标题：

• 直接点明测试的目的

• 简明扼要，不要太冗长

• 比如异常类测试时，重点关注导致异常的条件即可，（其他正确参数可以放在预置条件里面、实际工作中约定的规则下可以不写其他正常的参数）

• 如果是正常类测试时，可以依据有效等价类的类别（如登录时，qq、手机号、邮箱等）来细分设计测试用例

• 标题一般来说不重复

优先级：

今日目标

• 掌握状态迁移法的使用

• 掌握订单的状态测试

• 掌握流程图主要元素及画法

• 能够绘制tpshop下单及发货流程图

• 掌握tpshop业务流程测试用例的编写

1、状态迁移法

• 概念：

• 基于系统中模块或节点之间的状态。来描绘状态与状态之间的关系，从而找到状态之间转化的路线设计测试用例的一种方法。

• 适用场景

• 需要针对复杂业务场景设计测试用例时

• 使用步骤：

1. 找出系统所有的节点

2. 绘制状态迁移图

3. 绘制状态迁移树

4. 找出状态之间的转换路径

• 案例分析——飞机售票系统

飞机售票系统：
（1）客户向航空公司打电话预定机票，此时机票信息处于【预定】状态。
（2）顾客支付了机票费用后，机票信息变为【已支付】状态。
（3）旅客当天到达机场，拿到机票后，机票信息变为【已出票】状态。
（4）登机检票后，机票信息变为【已使用】状态。
（5）在检票之前任何时间都可以取消自己的订票信息，取消后，订单信息处于【已取消】状态。

1. 明确状态节点:【预定】、【已支付】、【已出票】、【已使用】、【已取消】

2. 绘制状态迁移图

3. 绘制状态迁移树

4. 抽取测试路径设计用例

2、订单测试

需求说明：
1.用户在网站完成下单后，订单状态为“等待付款”
2.用户完成付款后，订单状态变为“待发货” 
3.管理员对订单进行确认并发货后，订单状态变为“待收货” 
4.用户收到商品后，在系统中进行确认收货，订单状态变为“待评价” 
5.用户使用商品后，对商品进行评价，评价提交后，订单状态变为“已完成” 
6.商品发货前，用户可以对订单进行取消操作，取消后订单状态变为“已取消” 
7.用户付款前，管理员可以认定订单无效，此时订单处于“已作废”状态

1. 找出流程节点与状态

【等待付款】、【待发货】、【待收货】、【待评价】、【已完成】、【已取消】、【已作废】

2. 绘制状态迁移图

3. 绘制状态迁移树

4. 找到状态之间转换的所有路径

路径1：【等待付款】==》【待发货】==》【待收货】==》【待评价】==》【已完成】

路径2：【等待付款】==》【已作废】

路径3：【等待付款】==》【已取消】

路径4：【等待付款】==》【待发货】==》【已取消】

3、业务流程测试

3.1 流程图介绍（复习）

流程图：

流程图是对过程、算法、流程的一种图像表示，在技术设计、交流及商业简报等领域有广泛的应用。
通常用一些图框来表示各种类型的操作，在框内写出各个步骤，然后用带箭头的线把它们连接起来，以表示执行的先后顺序。用图形表示算法，直观形象，易于理解。有时候也被称之为输入-输出图。

• 椭圆：开始/结束

• 箭头：路径，流程的走向

• 平行四边形：数据的输入/输出

• 长方形：处理/步骤/过程

• 菱形：判定/判断

3.2 绘制流程图

绘制原则：

• 不要漏掉流程路径

• 现有判断，再有判断结果

• 推荐讲主业务流程放在最中间，便于阅读

案例1：ATM取款流程

案例2：缺陷管理流程

3.3 业务流程测试

• 业务流程测试的关注点：

• 关注点在核心业务是否能够跑通

• 重点不是关注单个功能模块的细节点

• 业务流程测试的价值：

• 客户角度：对客户最有价值的是业务的实现，不是单功能模块的质量

• 测试人员角度：分配任务往往是针对功能模块划分，业务流程的测试容易遗漏

• 进行业务流程测试的时机

• 上线前进行业务流程测试的确认

• 单功能模块基本可用的情况下，尽早进行（冒烟测试）

3.4 业务流程测试用例设计

• 需求分析，明确流程

• 画出流程图

• 编写测试用例，一条路径对应一条测试用例

• 路径比较多时，可以对所测业务路径设置优先级

3.5 测试团队中体现专业价值，个人价值

• 熟悉项目阶段，画出组织架构图，展现工作成果

• 进入项目，进行一段时间的测试之后，画出项目的业务流程图

• 体现个人对项目业务的深入理解

• 业务流程图可以作为整个团队的知识积累

4、tpshop业务流程测试

4.1 绘制tpshop下单流程

4.2 绘制tpshop发货流程

4.3 设计tpshop业务流程测试用例

• 前台下单

• 后台发货

今日总结

• 掌握状态迁移法的使用

• 掌握订单的状态测试

• 掌握流程图主要元素及画法

• 能够绘制tpshop下单及发货流程图

• 掌握tpshop业务流程测试用例的编写

作业说明

1.用xmind梳理今日知识点。
2.绘制tpshop业务流程图，完成业务流程用例设计与执行、并提交缺陷。