测试用例设计 - 基于页面、业务流程、技术架构

  前段时间回顾了测试用例设计的各个方法，例如：等价类、边界值、正交法、判定表、场景法等，发现要想用的丝滑，需要刻意在实战中调用各个方法实战总结，最终要追求的境界：丝滑

1、需求流程

1.1 需求分析

产品的UE、UI图指的是什么？

• UI是英文User Interface，用户界面，是指用户和某些系统进行交互方法的集合，这些系统不单单指电脑程序，还包括某种特定的机器，设备，复杂的工具等；
• UE是英文User Experience的缩写，翻译成中文就是用户体验。是指用户访问一个网站或者使用一个产品时的全部体验；
• 搞清楚为什么会有这个需求，决定着我们测试的核心点
• 分析测试点，测试用例设计，梳理出测试工作的风险点

1.2 需求实现

（1）测试：测试点分析、测试用例设计、测试点及测试用例设计评审、测试用例编写
（2）开发：代码流程图、时序图，设计接口、技术评审、编写代码、出系统概要说明书、转测前执行P0测试用例

一些注意事项：

• 流程图：面向业务逻辑，不涉及软件内部的组件和结构，不涉及业务逻辑处理的参与者，只考虑业务处理的步骤及流程。【注意：测试这里需要参加评审，因为使用场景法分析业务流程的基本流、备选流是要基于流程图实现的。有的开发流程图画的缺胳膊少腿】
• 时序图：通过业务处理的参与者的顺序协作来展示软件的不同组件如何协作来完成业务。
• 实现过程中，需求会有变动，需要提醒产品将更新内容及时更新到需求跟踪表中，防止产生沟通成本，浪费时间，降低我们的工作效率。

1.3 需求转测：

（1）执行P0用例，执行其他用例，超过一天开发不回复直接提单。

2、聊聊测试用例设计

1、小需求：某个模块内新增某个控件、新增某些数据、增加导出功能等
2、大需求：新增整个页面，页面涉及诸多功能

从以下3个维度展开测试用例设计

• 基于页面，关注某个控件的细节测试（常用的：等价类+边界值+判定表+正交，不常用的：状态迁移、错误推测、因果图），验证页面控件功能
• 基于业务流程，测试用设计方法（场景法），验证页面包含的业务流程
• 基于技术架构，思考点

  1、如果架构是采用微服务的话，一般从接口的url里面就可以找到对应的数据表，api后面是服务名，服务名后的路径一般就能猜测到数据库名
  2、有没有索引，有索引的是什么样的，索引是啥，解决了什么问题
  3、如果是 redis 【数据库】是用什么结构存储的，有性能问题吗，如何做持久化
  4、如果放到 es 【ElasticSearch】上，对应的index是怎么样的，跟接口的关系是啥。

3、基于页面 - 做测试用例设计

3.1 等价类+边界值

等价类方法概念：
（1）梳理出等价类表格，输入选取边界值数据（穿插使用边界值）；
（2）设计测试用例，覆盖有效、无效等价类；
测试用例设计原则：
（1）有效等价类用例尽可能覆盖多的有效编号，
（2）无效等价类用例一个无效编号一条用例。
测试用例评审：
（1）一般有效等价类的用例是P0，
（2）有效等价类用例的组合场景是 P1用例，
（3）无效类等价类的用例属异常场景，用例发划分 P2，

实例1、某城市的电话号码由三部分组成，分别是：地区码-空白或三位数字，前缀-非‘0’或’1’开头的三位数字，后缀-4位数字

1、梳理出等价类表格

关于无效等价类的设计考虑了边界值，无论是什么开区间还是闭区间，有效等价类的设计就是取如何条件的边界上的点。
无效等价类就是取不符合条件边界上的点

2、设计测试用例，覆盖有效、无效等价类

3.2 正交法

搜索符合条件的推荐专家，这部分测试用例如何设计？

传统方法：对于像远程专家这种搜索功能的测试用例，我不可能尝试所有变量的所有组合，因为那将是非常多的测试，因此，使用正交方法：用最少的测试用例使每个变量的每个值与其他每个变量得每个值至少配置一次。这将极大的减少了工作量
正交法实施步骤：
1、确定因素数、水平数（最上面是因素）

2、从常用正交表选择一个表，要求该表的因素数 >=4,水平数>=10，这里我们选取L12（）
在线正交表：https://www.york.ac.uk/depts/maths/tables/orthogonal.htm

3、将测试因素、水平数投射到表格中
4、使用正交法的测试用例设计工具：allpairspy库

from collections import OrderedDict
from allpairspy import AllPairs

parameters = OrderedDict({
    "是否推荐专家接单": ["是", "否"],
    "服务项目": ["xx", "SFDx", "保x", "改x", "防x"],
    "订单状态": ["服务中", "专家x", "已取消", "技师x", "已完成", "待支付", "专家x", "待接单", "超时x", "专家x"],
    "时间类型": ["创建时间", "达成时间", "取消时间", "推荐时间"]
})
print("测试用例如下:")
for i, pairs in enumerate(AllPairs(parameters)):
    print(f"用例编号{i+1}: {pairs}")

3.3 状态迁移法

功能点如果有状态的转变，比如远程专家的订单状态
实例：针对远程专家订单状态如何设计测试用例？

1、梳理订单状态
待接单
待支付
服务中
已完成
已取消

2、画出状态迁移树

3、输出测试用例4条

3.4 判定表法

针对场景：有多个输入、多个输出，且输入和输出之间有组合关系，可以正交法也可以判定表法，也可以等价类法设计。但我感觉正交法设计的更完善点，可以在不影响业务场景覆盖的前提下大大减少用例数量，既保证用例质量又降低测试时间成本。

实例1：自动售货机的控制软件如何进行测试用例设计？
1、明确需求
1.若投入5角钱的硬币，按下“橙汁”或“啤酒”的按钮，则相应的饮料就送出来。若投入1元钱的硬币，同样也是按“橙汁”或“啤酒”的按钮，则自动售货机在送出相应饮料的同时退回5角钱的硬币。
2、制作判定表
1、明确输入：输入5毛、输入1元、按下橙汁、按下啤酒
2、明确输出：啤酒、橙汁、找零、错误提示
3、生成测试用例

4、等价类设计一下这个场景

5、正交法设计测试用例

a = {
    "投入硬币": ["1元", "5角", "空", "投入圆形异物"],
    "按下物品": ['啤酒', "橙汁", "空"]
}

parameters = OrderedDict(a)

for i, pairs in enumerate(AllPairs(parameters)):
    print(f"用例编号{i+1}: {pairs}")

用例编号1: Pairs(投入硬币='1元', 按下物品='啤酒')
用例编号2: Pairs(投入硬币='5角', 按下物品='啤酒')
用例编号3: Pairs(投入硬币='空', 按下物品='啤酒')
用例编号4: Pairs(投入硬币='投入圆形异物', 按下物品='啤酒')
用例编号5: Pairs(投入硬币='投入圆形异物', 按下物品='橙汁')
用例编号6: Pairs(投入硬币='空', 按下物品='橙汁')
用例编号7: Pairs(投入硬币='5角', 按下物品='橙汁')
用例编号8: Pairs(投入硬币='1元', 按下物品='橙汁')
用例编号9: Pairs(投入硬币='1元', 按下物品='空')
用例编号10: Pairs(投入硬币='5角', 按下物品='空')
用例编号11: Pairs(投入硬币='空', 按下物品='空')
用例编号12: Pairs(投入硬币='投入圆形异物', 按下物品='空')

结合pytest

import pytest
from allpairspy import AllPairs
 
def function_to_be_tested( sex, grade, age):
    if grade == "一年级" and age == "10-13岁":
        return False
    return True
 
class TestParameterized(object):
 
    @pytest.mark.parametrize(["sex", "grade", "age"], [
        value_list for value_list in AllPairs([
            [u"男", u"女"],
            ["一年级", "二年级", "三年级", "四年级", "五年级"],
            ["8岁以下", "8-10岁", "10-13岁"]
        ])
    ])
    def test(self, sex, grade, age):
        assert function_to_be_tested(sex, grade, age)

实例2：新增一个软件提示升级的需求

4、 基于业务流程 - 做测试用例设计

1、概念

针对需求模拟出不同的场景进行所有功能点及业务流程的覆盖，目的是用业务流把各个孤立的功能点串起来，为测试人员建立整体业务感觉，从而避免陷入功能细节忽视业务流程要点的错误倾向。这个也是用例评审的关键点：

• 基本流：按照正确的业务流程来实现的一条操作路径
• 备选流：错误操作或者异常输⼊，导致流程存在反复，但是最终能够完成期望业务的流程

2、实施步骤：

1、获取业务流程图，核心关键的业务，建议我们自己画一遍核心业务的代码流程图，难点在于流程图的构造；
2、.根据业务流程图，抽取测试路径，每次路径需包含⼀个从未⾛过的路径；
3、细化路径，穿插单个功能的等价类、边界值、正交法，最终抽取测试用例；