测试分析

一、第一部分

（一）需求文档

1.含义：由产品经理编写，用于描述用户的需求；去描述和沟通我们要构建一个什么样的东西，为谁构建，以及如何让客户受益。定义某个产品或特性的价值和目的。

2.目的: 帮助产品团队中的每个人在产品需求和功能理解上保持一致，使得工程、设计、支持和营销团委能够有效的协作，并交付让客户满意的完整产品体验。

3.构成：在查阅《BOS端拍卖会会员行为优化》和《拍卖2.7.5竞拍APP交互优化个人中心》两篇文档后，我总结出需求文档的构成主要为：版本记录和审核记录、项目背景、项目说明、详细产品设计、数据监测、支持信息、管理决定。
①版本记录的内容有：版本号、修改人、修改日期和修改内容，审核记录的内容有：版本号、审核人、审核日期、审核内容。
②项目背景内容为：需求背景、产品概述和功能清单。
③项目说明内容为：项目目标、概念原型、功能模块图。
④详细产品设计：各个功能页面的图片展示和文字描述。
⑤支持信息内容为：前台和后台的兼容的游览器。

（二）测试分析

1.含义：运用不同的方法对被测软件进行理解和分析（运用各种测试用例设计方法进行分析），决定测试的深度和广度。

2.执行
①明确被测软件的需求范围：需要尽可能早和尽可能深入的去了解需。
②明确业务处理逻辑：利用画图（流程、状态转移图、用例图）列出测试场景，将需求变得更加直观。采用分析方法将，将需求更加细化。
③站在客户的角度看问题。

3.分析方法
①等价类：减少工作量和提高测试效率最有效的方法。
按照需求划分出有效和无效等价类（设计用例原则：一条用例尽可能多的覆盖有效等价类，一条用例只能覆盖一个无效等价类）。
②边界值：发现错误能力强，用途广。
通常作为等价类的补充，用例来自等价类的边界，大量的错误发生在输入或者输出范围的边界值上，而不是在输入范围的内部。
③错误推测：基于经验和直觉推测程序可能存在的错误。
④场景法：软件几乎都是用事件触发来控制流程的，事件触发时的情景便形成了场景，而同一事件不同的触发顺序和处理结果就形成事件流。基本流：正常的流程；备选流：非正常流程。
⑤因果图：利用图解法分析输入的各种组合情况。

4.测试分析运用
①项目级：对项目测试范围和测试重点描述。
②模块级：对大功能按照一定的逻辑和维度细化成最小颗粒度功能。
③用例级：具体到某一功能。

（三）测试用例

1.含义：由测试分析产生，为特定的目的而设计的一组测试输入、执行条件和预期的结果。执行的最小实体。设计一个运行场景，使软件程序在这种场景下，必须能够正常的运行且到程序所设计的执行结果。

2.设计原则：能更快、更有效地发现缺陷，确保测试的系统性和全面性。
①测试用例的代表性：能覆盖同一等价类的各种情况。
②测试结果可判定性：结果可判定，每个测试用例有相应的期望结果。
③测试结果可再现性：同样的用例，系统的执行结果应该相同。
④测试步骤的可执行性：步骤清晰，执行人员能较快理解并操作。

 二、第二部分

1.需求文档、测试分析、测试用例关系示例：

 

2.关系：测试分析是分析产品需求文档中描述的业务处理逻辑，以及用户的潜在的需求。识别出测试对象（以上例子中，换芯和按动是测试对象）。以测试的角度对测试对象进行深入的分析。测试用例是在测试分析的基础上，把分析出来的场景具体化，具体到可执行的状态。