测试理论（2）

敏捷模式

小步快跑的模式（快速试错）

人数：

项目经理（pm）：1

测试：4

前端：2

后端：5

产品：1

总人数:13

两周一迭代：

第一周：

周一：熟悉需求，评审需求，列计划

周二：编写测试用例

周三：评审测试用例，完善测试用例

周四&周五：编写自动化测试case，等待开发转测，进行冒烟测试验证

第二周：

周一：开始第一轮的测试

周二：回归所有的bug，开始第二轮的测试

周三：开启系统测试，准备提交验收测试

周四：编写测试报告，准备上线前的工作

周五：跟踪上线后的产品情况，然后项目内容复盘

敏捷模型是持续改进的一个过程

 

测试点分析

输入输出、逻辑处理、业务场景

• 通过分析需求描述中的输?、输出、处理、限制、约束等，给出对应的验证内容（功能测试）

• 各个模块之间的业务顺序，和各个功能模块之间传递的信息和数据，对存在给你交互的功能项，给出对应的验证内容（功能业务测试）

• 考虑到需要的完整性，要充分覆盖软件需求的各种特征，包含隐性需求的验证，?如界?的验证，异常情况（界?、易?性、兼容性、安全性、性能）

测试需求相关?影响

开发约束

• 由于了解需求不明确，功能研发不合格导致很多BUG

• 对于BUG反复修改，影响进度和团队情绪

• 进度影响，很可能使公司产品失去市场先机

测试约束

• 与开发是相互制约的关系，如果不了解需求，会?部分时间都被开发牵着???

• 不能及时发现开发的偏差，影响进度和团队情绪

• 没办法保证测试质量

√解决方案：

1、逻辑不清晰，找开发同学多讨论

2、开发与测试意见不一致的情况下，找产品经理

3、产品的逻辑不合理，找产品经理，同时找开发同学，统一意见

 

测试?例七?设计?法

测试?例概述

测试?例是为特定的?的?设计的?组测试输?、执?条件和预期的结果。测试?例是执?的最?实体。简单地 说，测试?例就是设计?个场景，使软件程序在这种场景下，必须能够正常运?并且达到程序所设计的执?结果。

测试?例步骤

拿到测试需求 -> 分析需求（画思维导图） -> 编写?例 -> 划分?例优先级

测试?例编写特征

?致性：主要包括?例模板?致；各同事的编写?法?致；以及?例的细腻度?致。 覆盖率：主要包括对需求的覆盖（也包含隐含的需求）；新需求可能对那些功能会产?影响的覆盖；对各种场景的覆盖等 。 可执?性：主要是指步骤易于理解、信息描述准确、且能快速识别出测试点 。 执?准确性：是指?例执?的准确度，本身没什么技术含量。但这?需要注意的是执??对待执??例的态度。不要因为?例简单或者?些外界的因素，导致部分?例未实际执?标为通过的情况。 持续更新：要及时不断的更新，要尽量减少?例库中失效的?例 。 复?性：主要?例可以被不断的复?，从?减少维护成本  

√测试?例组成元素（测试用例的要素）

• ?例ID；
• ?例名称；
• 测试?的；
• 测试级别；
• 参考信息；
• 测试环境；
• 前提条件；
• 测试步骤；   （清晰明了、通俗易懂）
• 预期结果；
• 设计?员。

 测试用例编写的三种方式：

1、excel/csv 或者WEB平台编写，特点：非常详细，步骤非常明确，缺点：写起来很慢。
2、思维导图（process on \ xmind) 特点：使用一句话描述测试场景 。特点：结构化思维非常强，让人很明晰的可以看到编写测试人员的思维结构。（工作中常用。一句话中尽量包括用例名称、前提、步骤、结果） 思维导图：界面→功能→预期结果分类

3、checklist 特点：记事本上写的。
场景一：比如早上出需求，晚上上线，那么就使用这种方式
场景二：使用该方式梳理出测试的思路
场景三：和开发单独去对一些复杂的逻辑