测试理论（2） 敏捷、测试用例、用例设计方法
小步快跑的模式（快速迭代、快速交付、快速试错）
人数：
项目经理（pm）：1
测试：4
前端：2
后端：5
产品：1
总人数:13
两周一迭代：
第一周：
周一：熟悉需求，评审需求，列计划
周二：编写测试用例
周三：评审测试用例，完善测试用例
周四&周五：编写自动化测试case，等待开发转测，进行冒烟测试验证
第二周：
周一：开始第一轮的测试
周二：回归所有的bug，开始第二轮的测试（回归测试）
周三：开启系统测试，准备提交验收测试
周四：编写测试报告，准备上线前的工作
周五：跟踪上线后的产品情况，然后项目内容复盘（由项目经理来主持）
pm:60%
测试负责人:
测试经理:40%的参考意见来自测试负责人
迭代：2周
复盘：
1、哪些方面做的好
2、哪些方面做的不好，怎么改进
敏捷模型是持续改进的一个过程
如何做软件测试需求分析
为什么要需求分析
-
软件测试需求是设计测试⽤例的依据。
-
有助于保证测试的质量和进度
-
软件测试需求是衡量测试覆盖率的重要指标
（了解本次迭代要做什么，本迭代功能是否 影响之前的功能，提出疑问点。）
软件测试需求分析步骤（工具：思维导图xmind/ process on）
-
列出需求⽂档中的具有可测性的原始需求
-
对每⼀条需求进⾏细化分解，形成可测试的分层描述的测试点
-
对形成的每⼀个测试点，从软件产品的质量需求来分析，确定测试执⾏时需要实施的测试类型
-
建⽴测试需求跟踪矩阵，对测试需求进⾏管理
测试需要分析的主要⽬的：获取测试点，根据测试点来编写测试⽤例
√需求文档中的内容包括：
1、业务逻辑以及流程图
2、页面交互图
3、文字描述具体的逻辑过程
测试点分析
（每个场景都是一条用例、具体的逻辑要梳理需求设计文档，基本上需求设计文档中都有，还是不清楚的可以和产品核对）
输入输出、逻辑处理、业务场景
-
通过分析需求描述中的输⼊、输出、处理、限制、约束等，给出对应的验证内容（功能测试）
-
各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）
-
考虑到需求的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，⽐如界⾯的验证，异常情况（界⾯、易⽤性、兼容性、安全性、性能）
测试需求相关⽅影响
开发约束
-
由于了解需求不明确，功能研发不合格导致很多BUG
-
对于BUG反复修改，影响进度和团队情绪
-
进度影响，很可能使公司产品失去市场先机
测试约束
-
与开发是相互制约的关系，如果不了解需求，会⼤部分时间都被开发牵着⿐⼦⾛
-
不能及时发现开发的偏差，影响进度和团队情绪
-
没办法保证测试质量
√解决方案：
1、逻辑不清晰，找开发同学多讨论
2、开发与测试意见不一致的情况下，找产品经理
测试用例
测试⽤例概述
测试⽤例步骤
测试⽤例编写特征
- ⼀致性：主要包括⽤例模板⼀致；各同事的编写⼿法⼀致；以及⽤例的细腻度⼀致。
- 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产⽣影响的覆盖；对各种场景的覆盖等 。
- 可执⾏性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。
- 执⾏准确性：是指⽤例执⾏的准确度，本身没什么技术含量。但这⾥需要注意的是执⾏⼈对待执⾏⽤例的态度。不要因为⽤例简单或者⼀些外界的因素，导致部分⽤例未实际执⾏标为通过的情况。
- 持续更新：要及时不断的更新，要尽量减少⽤例库中失效的⽤例 。
- 复⽤性：主要⽤例可以被不断的复⽤，从⽽减少维护成本
√测试⽤例组成元素（测试用例的要素）
- ⽤例ID； （根据公司规定，用来区分测试用例）
- ⽤例名称； （一目了然：预期结果（测试点）。方便评审、方便执行）
- 测试⽬的；
- 测试级别； （正向或核心业务级别高。具体根据公司规定）
- 参考信息；
- 测试环境； （硬件环境和软件环境，硬件：计算机配置 软件：操作系统 数据库 中间件..)
- 前提条件；
- 测试步骤； （清晰明了、通俗易懂）
- 预期结果； (你预计输出什么结果）
- 设计⼈员。
测试用例编写的三种方式：（根据需求）
1、excel/csv 或者WEB平台编写，特点：非常详细，步骤非常明确，缺点：写起来很慢。
2、思维导图（process on \ xmind) 特点：使用一句话描述测试场景 。特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构。测试用例要十分具体，步骤详细，有数据就写出数据，简洁明了，清晰易懂。（工作中常用。一句话中尽量包括用例名称、前提、步骤、结果） 思维导图思路：需求→测试点→测试类型
3、checklist 特点：记事本上写的。
场景一：比如早上出需求，晚上上线，那么就使用这种方式
场景二：使用该方式梳理出测试的思路
场景三：和开发单独去对一些复杂的逻辑
1、发起会议邀请
2、到约定的时间到会议室评审测试用例（先说测试的思路、再说测试点）
3、评审结束后，完善测试用例
4、完善之后，再次发出来
参与者：
产品、开发、以及其他的测试
主持：
谁发起的，谁主持
注意：
-
QA（测试环境）
-
预发布环境
-
生产环境（线上环境）
测试和开发环境是分开的，否则开发写代码会影响测试
测试⽤例七大设计方法
story 故事：有开始有结束 task 任务
等价类测试用例设计方法
定义：等价类是把所有可能的输⼊数据,即程序的输⼊域划分成若⼲部分（⼦集）,然后从每⼀个⼦集中选取少数具有代表性的数据作为测试⽤例。就是针对被测对象输入的数据，可以分为有效数据与无效数据。
逻辑学的角度而言：
输入 → 中间处理 → 输出
被测对象可以分为两个维度的测试：
1、正常流程 需要测试的数据可以理解为有效数据
2、异常流程 需要测试的数据可以理解为无效数据
一般情况下异常流程投入较多精力。一条用例可以包含尽可能多的有效数据，但是无效数据只能同时违背一条规则（也叫控制变量法，无效数据多了就不知道问题到底是哪造成的。）
（数值类型：整数、小数。 非数值类型：字母、特殊字符、空格、空）
（手机号测试：
有效：符合三大运营商规则的手机号码
无效： 非十一位数字
十一位不符合三大运营商规则的数字
十一位包含数字加字母 十一位包含数字加特殊符号 十一位包含数字加空格 空 ）
saas化：微服务构架 software as a service
pass化： 平台即服务 platform as a service
场景：开发给测试讲代码，我们不用懂代码，能编写测试用例就行。
边界值分析方法：
1.定义：
边界值分析法就是对输⼊或输出的边界值进⾏测试的⼀种⿊盒测试⽅法。通常边界值分析法是作为对等价类划分法的补充，这种情况下，其测试⽤例来⾃等价类的边界。
2.与等价划分的区别
1)边界值分析不是从某等价类中随便挑⼀个作为代表，⽽是使这个等价类的每个边界都要作为测试条件。
2)边界值分析不仅考虑输⼊条件，还要考虑输出空间产⽣的测试情况。
3.边界值分析⽅法的考虑：
使⽤边界值分析⽅法设计测试⽤例，⾸先应确定边界情况。通常输⼊和输出等价类的边界，就是应着重测试的边界情况。应当选取正好等于，刚刚⼤于或刚刚⼩于边界的值作为测试数据，⽽不是选取等价类中的典型值或任意值作为测试数据。
因果图法 正交实验法
1、定义：是⼀种利⽤图解法分析输⼊的各种组合情况，从⽽设计测试⽤例的⽅法，它适合于检查程序输⼊条件的各种组合情况。
因果图：简单的理解就是被测对象有多个输入条件，根据排列组合的数学概念，把多个条件结合逻辑的关系(并且,或者)进行组合，得到一个输出的结果信息。
2、因果图法产⽣的背景： 等价类划分法和边界值分析⽅法都是着重考虑输⼊条件，但没有考虑输⼊条件的各种组合、输⼊条件之间的相互制约关系。这样虽然各种输⼊条件可能出错的情况已经测试到了，但多个输⼊条件组合起来可能出错的情况却被忽略了。
== 相等
! 不等
or 或
and 和
因果图结合排列组合设计出来的测试用例的个数是无限扩张的，但是测试资源是有限的，所以在这个情况下，只需要选择有代表性的数据进行测试，这就是正交试验分解法解决了问题。
利⽤因果图来设计测试⽤例时, 作为输⼊条件的原因与输出结果之间的因果关系,有时很难从软件需求规格说明中得到。往往因果关系⾮常庞⼤,以⾄于据此因果图⽽得到的测试⽤例数⽬多的惊⼈，给软件测试带来沉重的负担，为了有效地,合理地减少测试的⼯时与费⽤,可利⽤正交实验设计⽅法进⾏测试⽤例的设计。
正交实验法：筛选有效数据。正交实验是研究多因素、多水平的一种实验方法，它利用正交表来对实验进行设计，通过少数实验代替全面的实验。
常用于功能测试（查询）、配置测试等。（例：查询条件搭配很多：职位、地区、经验、学历、薪资、公司规模... 查询时使用几个条件约束）
4.因果图法设计测试用例的步骤（How）
- 分析程序的规格说明书中哪些是原因，哪些是结果。所谓原因，是指输入条件或输入条件的等价类，而结果是指输出条件。给每一个原因和结果赋一个标识符。
- 分析程序规格说明书中的语义，确定原因与原因，原因与结果之间的关系，画出因果图。
- 由于语法环境的限制，一些原因与原因之间，原因与结果之间的组合不能出现。对于这些特殊情况，在因果图中用一些记号标明约束或限制条件。
- 将因果图转化为判定表。
- 根据判定表的每一列设计测试用例。
当然，若能直接得到判定表，可以直接根据判定表设计测试用例。
5.应用
在界面中有多个控件，控件之间有组合或限制关系，不同的输入组合会对应不同的输出结果，如果想弄清楚不同的输入组合到底对应哪些输出结果，可以使用因果图/判定表法。(因果图/判定表法比较适合测试组合数量较少的情况，一般少于20种)
浙公网安备 33010602011771号