从“需求项---测试项---测试用例”的详细分析过程需求目录需求项测试项测试子项测试目的测试用例规划1.快捷调出1.1锁屏亮屏界面双击home键首次使用出厂默认原笔迹模式界面显示查看界面显示UI界面易懂按键图标表意查看界面按键图标按键图标表意明确无歧义记忆上次使用原笔迹模式笔的设置记忆笔的颜色界面显示查看界面显示变化UI界面易懂涂鸦板模式笔的设置记忆笔颜色、类型、大小文本模式背景设置记忆背景1.2第一屏放置随心写APP首次使用出厂默认原笔迹模式记忆上次使用原笔迹模式涂鸦板模式记忆笔的颜色、类型、粗细、画布背景文本模式记忆背景原笔迹模式2.原笔迹模式2.1全屏手写首次使用/保存后新建原笔迹模式时界面显示全屏2.2手写2.3手势放大缩小2.4笔的颜色2.5工具栏表情符号输入空格输入换行退格工具栏不可用时置灰2.6分享以图片方式分享分享后，返回2.8保存保存并新建保存后，内容被保存至列表，界面刷新，等同于新建。自动保存点击Menu,进入列表和新建自动保存2.9取消取消不保存2.10Menu菜单列表新建2.11横屏使用横屏方式原笔迹模块的“需求项---测试项----测试用例”需求目录中存在的问题•1、需求目录分类不合理，当前分类是以功能（或功能集合）作为需求目录，如：快捷调出、原笔迹模式。功能性需求只是所有需求中的一种，它与非功能性需求及约束等是并列的，不能以功能性需求来作为各类需求目录•2、建议依据软件需求分析的思路，将需求目录统一分成：功能性需求、非功能性需求、约束、接口、数据•备注：在分析需求出应分类列出，但在编写具体用例时，可以综合考虑需求项中存在的问题（二）•需求项描述不规范，不能准确的表达一个明确的需求，如：锁屏亮屏界面双击home键、笔的颜色。这两项描述究竟是要传达什么信息呢？•功能性需求描述不准确：如MENU菜单、工具栏，本质上这两项不是需求，用户想要的不是菜单或工具栏，而是它们所承载的功能。导致有些本来应该是需求项的，却放在“测试项”这一列。•没有将SRS中的需求转化成测试的需求，用例表中的需求项与SRS中的需求项没有对应关系。测试项中存在的问题•测试项不是运用“质量模型、功能交互、用户关联图”的工程方法来获得，而是依据经验或策划书编排的菜单级别来展开•对需求项与测试项不理解，两者互相混乱•测试项描述不规范，从描述上不能体现是对需求哪个方面进行测试•测试项中的问题本质上都是对需求理解有误导致的测试目的与测试类别中存在的问题•测试目的不是通过“测试用例设计方法”得出的，而是凭经验或菜单结构的编排，导致从需求项——测试项——测试用例之间没有明确的逻辑对应关系。产生的连环后果是：设计思维不严密，容易遗漏，覆盖率低等后果，不便于评审。•测试类别填写不合理，绝大多数都集中在功能正确性，而其中很多用例不是测试功能正确性，却把测试类别定义为功能正确性，这会对测试策略制订留下隐患。如何正确理解测试项•测试项主要定义测试什么和验证什么•测试项通常包括正确条件和错误条件下的测试•应覆盖所有的需求类别：应覆盖业务规则、功能性需求、非功能性需求、接口需求、数据需求。对产品级需求理解越充分，测试需求也会越充分•测试项中不应包含具体的测试数据，否则会与测试用例分不清，测试数据需在用例中体现如何运用工程方法得到测试项•从需求项中获取测试项的工程方法有四种：用户场景分析、功能交互分析、逐级细分、质量模型分析。对任何一项需求，优先采用用户场景分析方法，其次是功能交互分析方法。质量模型既可用于分析得出非功能性需求，也可以用于得出测试项，但仅限于不能采用其它方法分析测试项的情况下，那么可直接将该非功能性需求项作为测试项。运用工程方法得到测试项的实例（一）•功能性需求：新建名片•对此需求运用工程方法得到以下测试项“验证通讯录为空时能新增名片”（用户场景分析）“验证是否能新建一张名片到通讯录”（用户场景分析）“验证装不同SIM卡新建名片”（用户场景分析）“验证新建重复的名片应不成功”（用户场景分析）“验证通讯录已存满时应该不能新建名片”（用户场景分析）“验证通过导入功能新增名片”（功能交互分析...
