需求项、测试项、测试用例之间的详细分析过程.pptx

1、从“要求项目-测试项目-测试用例”的详细分析过程开始，对原笔迹模块的“要求项目-测试项目-测试用例”、要求列表中存在的问题，1， 功能性需求是所有需求中的一种，不能与非功能性需求和制约等并列，将功能性需求作为各种需求目录2。 根据软件需求分析的思维方法，统一地分类需求目录：功能性需求，非功能性需求，制约，界面，数据备注：分析需求应该分类，但制作具体的例子时这两个说明到底传达什么样的信息呢？ 功能性需求的记述不正确。 例如，菜单菜单、工具条和两个这些个本质上不是需求，用户希望的不是菜单和工具条，而是它们所搭载的功能。 其结果，本来应该是需求项目的东西，但是放在了“测试项目”的列上。 没有将SRS

2、需求转换为测试需求，用例表中的需求项与SRS需求项不对应。 存在于测试项目中的问题是，测试项目不是使用“质量模型、功能交互、用户关联图”的工序方法获得的，而是在根据经验和企划书组织的菜单水平上展开，不理解需求项目和测试项目，存在于测试目的和测试类别中的问题是， 测试目的不是通过“测试用例设定修正方法”得到的，根据经验和菜单结构，需求项目测试项目测试用例之间没有明确的逻辑性对应关系。 产生的连续结果是设置修订思维不严格，容易泄漏，展望率低等结果，不便于审查。 测试类别填写不合理，大部分集中在功能的精准性上。 其中很多将测试类别定义为功能的精准性，而不是测试功能的精准性，给制定测试策略留下了危险。

3、 正确理解测试项目的方法，测试项目主要定义测试什么，验证的测试项目通常必须涵盖所有需求类别，包括在正确条件和错误条件下的测试。 对业务规则、功能需求、非功能需求、接口需求、数据需求产品层次需求的理解越是一盏茶，测试需求也越是一盏茶的测试项中包含具体的测验数据进行要不得。 否则，测验数据就不能与测试用例区分开来。 该测验数据分为用户场景分析、功能相互分析、阶段性细化、质量模型分析4种。 无论哪种需求，都优先采用用户场景分析方法，接着采用功能交互分析方法。 质量模型可以用于分析以获得非功能性需求，也可以获得测试项目，但只要不能用其他方法分析测试项目，该非功能性需求项目就可以直接作为测试项目。用工程

4、方法得到了测试项目的例子(1)，功能性需求：制作新的名片用工程方法得到了以下的测试项目“验证通讯录为空时可以添加名片”(用户场景分析) “验证是否可以在通讯录上创建新名片”(用户场景分析)“验证无法创建新重复名片”(用户场景分析)“验证通讯录已满时无法创建新名片”交互分析) 考虑“验证添加不同字符类型的名片”(逐步细分用户场景分析)“添加名片后立即给该名片打电话，发送消息”(功能相互分析)、“播放音乐时充电”和“播放音乐时插入USB”的区别。 采用工程方法得到了测试项目的实例(2)，采用功能性要求“用摇滾乐画面明亮的画面界面双喀呖声home牛鼻子就能进入原来的笔迹”的工程方法得到了以下测试项目

5、。 “验证黑画面时，如果双喀呖声home牛鼻子，就不能进入笔迹”(用户场景分析)“验证摇滾乐画面明亮的画面，如果双喀呖声home牛鼻子，就不能进入笔迹”(用户场景分析) “验证摇滾乐画面的明亮画面后，如果双喀呖声home牛鼻子，就不能进入笔迹”(功能相互分析)“验证摇滾乐画面的工程方法得到的测试项目实例(3)， 功能需要：在第一画面上放置原笔迹，用APP工程方法得到的测试项目：“初次使用时验证原笔迹图标在第一画面上”(用户场景分析)“改变原笔迹图标的位置，再次返回商品发货时设定，检查第一画面原笔迹”(用户场景分析) “卸载原笔迹，模仿商品发货时设定，检查第一画面原笔迹”(功能交互分析)“场景台

6、掌门人上的原笔迹在第一画面中验证有木有”，使用测试用例校正方法得到测试用例(1) 验证只有“验证通讯录为空时可以添加名片”编号的名片是否可以新建“验证不能创建新重复名片”“验证通讯录已满时无法创建新名片”“验证添加不同字符类型的名片”“创建新名片后立即打电话通讯录为空时只有编号的名片通讯录为空时只有名称的名片通讯录为空时新制作带有名称和编号的名片，使用等价类、错误推测、新编号相同、名称不同的名片新名称和编号相同的名片、等价类、测试用例订正方法进行测试用例(2) “验证黑画面时不能双喀呖声home牛鼻子进入原来的笔迹”“验证摇滾乐画面后不能双喀呖声home牛鼻子进入原来的笔迹”“验证摇滾乐画面后不能双喀呖声home牛鼻子进入原来的笔迹”“初次使用时验证原来的笔迹的图标在最初的画面上变更原来的