功能点分析方法例题

‘壹’ 求AGIL功能分析模式实例

FMEA的具体内容 失效模式和效果分析FMEA有三种类型，分别是系统FMEA、设计FMEA和工艺FMEA， 确定产品需要涉及的技术能够出现的问题 包括下述各个方面： 需要设计的新系统、产品和工艺； 对现有设计和工艺的改进； 在新的应用中或新的环境下，对以前的设计和工艺的保留使用； 形成FMEA团队。理想的FMEA团队应包括设计、生产、组装、质量控制、可靠性、服务、采购、测试 以及供货方等所有有关方面的代表。 记录FMEA的序号日期和更改内容 保持FMEA始终是一个根据实际情况变化的实时现场记录，需要强调的是，FMEA文件必须包括创建和更新的日期。 创建工艺流程图 工艺流程图应按照事件的顺序和技术流程的要求而制定，实施FMEA需要工艺流程图，一般情况下工艺流程图不要轻易变动。 列出所有可能的失效模式效果和原因 对于工艺流程中的每一项工艺，应确定可能发生的失效模式. 如就表面贴装工艺(SMT)而言，涉及的问题可能包括，基于工程经验的焊球控制、焊 膏控制、使用的阻焊剂 (soldermask)类型、元器件的焊盘图形设计等。 对于每一种失效模式，应列出一种或多种可能的失效影响， 例如，焊球可能要影响到产品长期的可靠性，因此在可能的影响方面应该注明。 对于每一种失效模式，应列出一种或多种可能的失效原因. 例如，影响焊球的可能因素包括焊盘图形设计、焊膏湿度过大以及焊膏量控制等。 现有的工艺控制手段是基于目前使用的检测失效模式的方法，来避免一些根本的原因。 例如，现有的焊球工艺控制手段可能是自动光学检测(AOI)，或者对焊膏记录良好的控制过程。 对事件发生频率严重程度和检测等级进行排序 严重程度是评估可能的失效模式对于产品的影响，10为最严重，1为没有影响； 事件发生的频率要记录特定的失效原因和机理多长时间发生一次以及发生的几率。 如果为10，则表示几乎肯定要发生，工艺能力为0.33或者ppm大于10000。 检测等级是评估所提出的工艺控制检测失效模式的几率，列为10表 示不能检测，1表示已经通过目前工艺控制的缺陷检测。 计算风险优先数RPN(riskprioritynumber)。 RPN是事件发生的频率、严重程度和检测等级三者乘积，用来衡量可能的工艺缺陷，以便采取可能的预防措施减少关键的工艺变化，使工艺更加可靠。对于工艺的矫正首先应集中在那些最受关注和风险程度最高的环节。 RPN最坏的情况是1000，最好的情况是1，确定从何处着手的最好方式是利用RPN的pareto图，筛选那些累积等级远低于80%的项目。 推荐出负责的方案以及完成日期，这些推荐方案的最终目的是降低一个或多个等级。对一些严重问题要时常考虑拯救方案，如: 一个产品的失效模式影响具有风险等级9或10； 一个产品失效模式/原因事件发生以及严重程度很高； 一个产品具有很高的RPN值等等。 在所有的拯救措施确和实施后，允许有一个稳定时期，然后还应该对修订的事件发生的频率、严重程度和检测等级进行重新考虑和排序。 [编辑本段]FMEA的应用 FMEA实际上意味着是事件发生之前的行为，并非事后补救。因此要想取得最佳的效果，应该在工艺失效模式在产品中出现之前完成。产品开发的5个阶段包括：计划和界定、设计和开发、工艺设计、预生产、大批量生产。 作为一家主要的EMS提供商，Flextronics International已经在生产工艺计划和控制中使用了FMEA管理，在产品的早期引入FMEA管理对于生产高质量的产品，记录并不断改善工艺非常关键。对于该公司多数客户，在完全确定设计和生产工艺后，产品即被转移到生产中心，这其中所使用的即是FMEA管理模式。 [编辑本段]手持产品FMEA分析实例 失效模式和效果分析在该新产品介绍(NPI)发布会举行之后，即可成立一个FMEA团队，包括生产总监、工艺工程师、产品工程师、测试工程师、质量工程师、材料采购员以及项目经理，质量工程师领导该团队。FMEA首次会议的目标是加强初始生产工艺MPI (Manufacturing Process Instruction)和测试工艺TPI(Test Process Instruction)中的质量控制点同时团队也对产品有更深入的了解，一般首次会议期间和之后的主要任务包括： 1．工艺和生产工程师一步一步地介绍工艺流程图，每

‘贰’ function points是什么

function ponits analysis FPA
功能点分析方法度量的是软件的规模，它是主要从逻辑设计的角度出发，对提供给客户的功能进行量化的方法。所涉及的基本概念如下：

1. 功能点是针对软件的测量单位，类似于用来测量时间的小时、测量距离的英里、测量温度的摄氏等。由于功能点是从功能观点来度量一个系统，因此它独立于技术。不管采用什么样的语言、开发方法或硬件平台，系统的功能点数维持不变。

2. 功能点分析（FPA）是一种将系统分解成较小的单元，以便能较好地理解和分析的方法。通常采用IFPUG 规则。

3. 功能点分析在概念层面上帮助定义两类数据抽象：静态数据和动态数据。动态数据是通过业务进行处理的数据；静态数据是指存储数据，其中由本应用维护的称为内

部逻辑文件，由其他应用维护的称为外部接口文件。

4. 功能点计算的类型：三类主要的软件项目类型（开发、升级、维护）。

5. 功能点计算的步骤,基本过程：确定功能点计算的类型；确定应用边界；识别和评价业务功能类型，确定其对未调整功能点计算所起的作用；确定调整因子值(VAF)； 计算调整后的功能点计算值。

‘叁’ 谁能教我点数字电路里面组合逻辑电路的功能分析的方法

加，减，乘，操作键按下为0，不按为1，这是负逻辑。A B C 为输入，Y1 Y2 为 输出。
A 为 加 的操作按键，按下A=0，输出 Y1=0，Y2=1
B 为 减 的操作按键，按下B=0，输出 Y1=1，Y2=0
C 为 乘 的操作按键，按下C=0，输出 Y1=1，Y2=1
真值表：
A B C Y1 Y2
0 1 1 0 1 A按下， Y1 Y2 =01
1 0 1 1 0 B按下, Y1 Y2 =10
1 1 0 1 1 C按下, Y1 Y2 =11

‘肆’ [软件测试题目]一次测试用例设计的完整的过程描述

黑盒测试（Black-box Testing，又称为功能测试或数据驱动测试）是把测试对象看作一个黑盒子。利用黑盒测试法进行动态测试时，需要测试软件产品的功能，不需测试软件产品的内部结构和处理过程。

采用黑盒技术设计测试用例的方法有：等价类划分、边界值分析、错误推测、因果图和综合策略。

黑盒测试注重于测试软件的功能性需求，也即黑盒测试使软件工程师派生出执行程序所有功能需求的输入条件。黑盒测试并不是白盒测试的替代品，而是用于辅助白盒测试发现其他类型的错误。

黑盒测试试图发现以下类型的错误：

1）功能错误或遗漏；
2）界面错误；
3）数据结构或外部数据库访问错误；
4）性能错误；
5）初始化和终止错误。

一、黑盒测试的测试用例设计方法

·等价类划分方法
·边界值分析方法
·错误推测方法
·因果图方法
·判定表驱动分析方法
·正交实验设计方法
·功能图分析方法

等价类划分:

是把所有可能的输入数据,即程序的输入域划分成若干部分（子集）,然后从每一个子集中选取少数具有代表性的数据作为测试用例.该方法是一种重要的,常用的黑盒测试用例设计方法.

1) 划分等价类: 等价类是指某个输入域的子集合.在该子集合中,各个输入数据对于揭露程序中的错误都是等效的.并合理地假定:测试某等价类的代表值就等于对这一类其它值的测试.因此,可以把全部输入数据合理划分为若干等价类,在每一个等价类中取一个数据作为测试的输入条件,就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况:有效等价类和无效等价类.

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

无效等价类:与有效等价类的定义恰巧相反.

设计测试用例时,要同时考虑这两种等价类.因为,软件不仅要能接收合理的数据,也要能经受意外的考验.这样的测试才能确保软件具有更高的可靠性.

2）划分等价类的方法:下面给出六条确定等价类的原则.

①在输入条件规定了取值范围或值的个数的情况下,则可以确立一个有效等价类和两个无效等价类.

②在输入条件规定了输入值的集合或者规定了“必须如何”的条件的情况下,可确立一个有效等价类和一个无效等价类.

③在输入条件是一个布尔量的情况下,可确定一个有效等价类和一个无效等价类.

④在规定了输入数据的一组值（假定n个）,并且程序要对每一个输入值分别处理的情况下,可确立n个有效等价类和一个无效等价类.

⑤在规定了输入数据必须遵守的规则的情况下,可确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）.

⑥在确知已划分的等价类中各元素在程序处理中的方式不同的情况下,则应再将该等价类进一步的划分为更小的等价类.

3）设计测试用例:在确立了等价类后,可建立等价类表,列出所有划分出的等价类:

输入条件 有效等价类 无效等价类

... ... ...

... ... ...

然后从划分出的等价类中按以下三个原则设计测试用例:

①为每一个等价类规定一个唯一的编号.

②设计一个新的测试用例,使其尽可能多地覆盖尚未被覆盖地有效等价类,重复这一步.直到所有的有效等价类都被覆盖为止.

③设计一个新的测试用例,使其仅覆盖一个尚未被覆盖的无效等价类,重复这一步.直到所有的无效等价类都被覆盖为止.

边界值分析法

边界值分析方法是对等价类划分方法的补充.

（1）边界值分析方法的考虑:

长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部.因此针对各种边界情况设计测试用例,可以查出更多的错误.

使用边界值分析方法设计测试用例,首先应确定边界情况.通常输入和输出等价类的边界,就是应着重测试的边界情况.应当选取正好等于,刚刚大于或刚刚小于边界的值作为测试数据,而不是选取等价类中的典型值或任意值作为测试数据.

（2）基于边界值分析方法选择测试用例的原则:

1）如果输入条件规定了值的范围,则应取刚达到这个范围的边界的值,以及刚刚超越这个范围边界的值作为测试输入数据.

2）如果输入条件规定了值的个数,则用最大个数,最小个数,比最小个数少一,比最大个数多一的数作为测试数据.

3）根据规格说明的每个输出条件,使用前面的原则1）.

4）根据规格说明的每个输出条件,应用前面的原则2）.

5）如果程序的规格说明给出的输入域或输出域是有序集合,则应选取集合的第一个元素和最后一个元素作为测试用例.

6）如果程序中使用了一个内部数据结构,则应当选择这个内部数据结构的边界上的值作为测试用例.

7）分析规格说明,找出其它可能的边界条件.

错误推测法

错误推测法: 基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法.

错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 例如, 在单元测试时曾列出的许多在模块中常见的错误. 以前产品测试中曾经发现的错误等, 这些就是经验的总结. 还有, 输入数据和输出数据为0的情况. 输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况. 可选择这些情况下的例子作为测试用例.

因果图方法

前面介绍的等价类划分方法和边界值分析方法,都是着重考虑输入条件,但未考虑输入条件之间的联系, 相互组合等. 考虑输入条件之间的相互组合,可能会产生一些新的情况. 但要检查输入条件的组合不是一件容易的事情, 即使把所有输入条件划分成等价类,他们之间的组合情况也相当多. 因此必须考虑采用一种适合于描述对于多种条件的组合,相应产生多个动作的形式来考虑设计测试用例. 这就需要利用因果图（逻辑模型）.

因果图方法最终生成的就是判定表. 它适合于检查程序输入条件的各种组合情况.

利用因果图生成测试用例的基本步骤:

(1) 分析软件规格说明描述中, 那些是原因(即输入条件或输入条件的等价类),那些是结果(即输出条件), 并给每个原因和结果赋予一个标识符.

(2) 分析软件规格说明描述中的语义.找出原因与结果之间, 原因与原因之间对应的关系. 根据这些关系,画出因果图.

(3) 由于语法或环境限制, 有些原因与原因之间,原因与结果之间的组合情况不不可能出现. 为表明这些特殊情况, 在因果图上用一些记号表明约束或限制条件.

(4) 把因果图转换为判定表.

(5) 把判定表的每一列拿出来作为依据,设计测试用例.

从因果图生成的测试用例（局部,组合关系下的）包括了所有输入数据的取TRUE与取FALSE的情况,构成的测试用例数目达到最少,且测试用例数目随输入数据数目的增加而线性地增加.

前面因果图方法中已经用到了判定表.判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具.在程序设计发展的初期,判定表就已被当作编写程序的辅助工具了.由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确.

判定表通常由四个部分组成.

条件桩（Condition Stub）:列出了问题得所有条件.通常认为列出得条件的次序无关紧要.

动作桩（Action Stub）:列出了问题规定可能采取的操作.这些操作的排列顺序没有约束.

条件项（Condition Entry）:列出针对它左列条件的取值.在所有可能情况下的真假值.

动作项（Action Entry）:列出在条件项的各种取值情况下应该采取的动作.

规则:任何一个条件组合的特定取值及其相应要执行的操作.在判定表中贯穿条件项和动作项的一列就是一条规则.显然,判定表中列出多少组条件取值,也就有多少条规则,既条件项和动作项有多少列.

判定表的建立步骤:（根据软件规格说明）

①确定规则的个数.假如有n个条件.每个条件有两个取值（0,1）,故有 种规则.

②列出所有的条件桩和动作桩.

③填入条件项.

④填入动作项.等到初始判定表.

⑤简化.合并相似规则（相同动作）.

B. Beizer 指出了适合使用判定表设计测试用例的条件:

①规格说明以判定表形式给出,或很容易转换成判定表.

②条件的排列顺序不会也不影响执行哪些操作.

③规则的排列顺序不会也不影响执行哪些操作.

④每当某一规则的条件已经满足,并确定要执行的操作后,不必检验别的规则.

⑤如果某一规则得到满足要执行多个操作,这些操作的执行顺序无关紧要.

黑盒测试的优点

1. 基本上不用人管着，如果程序停止运行了一般就是被测试程序crash了
2. 设计完测试例之后，下来的工作就是爽了，当然更苦闷的是确定crash原因

黑盒测试的缺点

1. 结果取决于测试例的设计，测试例的设计部分来势来源于经验，OUSPG的东西很值得借鉴
2. 没有状态转换的概念，目前一些成功的例子基本上都是针对PDU来做的，还做不到针对被测试程序的状态转换来作
3. 就没有状态概念的测试来说，寻找和确定造成程序crash的测试例是个麻烦事情，必须把周围可能的测试例单独确认一遍。而就有状态的测试来说，就更麻烦了，尤其不是一个单独的testcase造成的问题。这些在堆的问题中表现的更为突出。

黑盒测试（功能测试）工具的选择

那么，如何高效地完成功能测试？选择一款合适的功能测试工具并培训一支高素质的工具使用队伍无疑是至关重要的。尽管现阶段存在少数不采用任何功能测试工具，从事功能测试外包项目的软件服务企业。短期来看，这类企业盈利状况尚可，但长久来看，它们极有可能被自动化程度较高的软件服务企业取代。

目前，用于功能测试的工具软件有很多，针对不同架构软件的工具也不断推陈出新。这里重点介绍的是其中一个较为典型自动化测试工具，即Mercury公司的WinRunner。

WinRunner是一种用于检验应用程序能否如期运行的企业级软件功能测试工具。通过自动捕获、检测和模拟用户交互操作，WinRunner能识别出绝大多数软件功能缺陷，从而确保那些跨越了多个功能点和数据库的应用程序在发布时尽量不出现功能性故障。

WinRunner的特点在于: 与传统的手工测试相比，它能快速、批量地完成功能点测试; 能针对相同测试脚本，执行相同的动作，从而消除人工测试所带来的理解上的误差; 此外，它还能重复执行相同动作，测试工作中最枯燥的部分可交由机器完成; 它支持程序风格的测试脚本，一个高素质的测试工程师能借助它完成流程极为复杂的测试，通过使用通配符、宏、条件语句、循环语句等，还能较好地完成测试脚本的重用; 它针对于大多数编程语言和Windows技术，提供了较好的集成、支持环境，这对基于Windows平台的应用程序实施功能测试而言带来了极大的便利。

WinRunner的工作流程大致可以分为以下六个步骤:

1．识别应用程序的GUI

在WinRunner中，我们可以使用GUI Spy来识别各种GUI对象，识别后，WinRunner会将其存储到GUI Map File中。它提供两种GUI Map File模式: Global GUI Map File和GUI Map File per Test。其最大区别是后者对每个测试脚本产生一个GUI文件，它能自动建立、存储、加载，推荐初学者选用这种模式。但是，这种模式不易于描述对象的改变，其效率比较低，因此对于一个有经验的测试人员来说前者不失为一种更好的选择，它只产生一个共享的GUI文件，这使得测试脚本更容易维护，且效率更高。

2．建立测试脚本

在建立测试脚本时，一般先进行录制，然后在录制形成的脚本中手工加入需要的TSL（与C语言类似的测试脚本语言）。录制脚本有两种模式: Context Sensitive和Analog，选择依据主要在于是否对鼠标轨迹进行模拟，在需要回放时一般选用Analog。在录制过程中这两种模式可以通过F2键相互切换。

只要看看现代软件的规模和功能点数就可以明白，功能测试早已跨越了单靠手工敲敲键盘、点点鼠标就可以完成的阶段。而性能测试则是控制系统性能的有效手段，在软件的能力验证、能力规划、性能调优、缺陷修复等方面都发挥着重要作用。

3．对测试脚本除错(debug)

在WinRunner中有专门一个Debug Toolbar用于测试脚本除错。可以使用step、pause、breakpoint等来控制和跟踪测试脚本和查看各种变量值。

4．在新版应用程序执行测试脚本

当应用程序有新版本发布时，我们会对应用程序的各种功能包括新增功能进行测试，这时当然不可能再来重新录制和编写所有的测试脚本。我们可以使用已有的脚本，批量运行这些测试脚本测试旧的功能点是否正常工作。可以使用一个call命令来加载各测试脚本。还可在call命令中加各种TSL脚本来增加批量能力。

5．分析测试结果

分析测试结果在整个测试过程中最重要，通过分析可以发现应用程序的各种功能性缺陷。当运行完某个测试脚本后，会产生一个测试报告，从这个测试报告中我们能发现应用程序的功能性缺陷，能看到实际结果和期望结果之间的差异，以及在测试过程中产生的各类对话框等。

6．回报缺陷（defect）

在分析完测试报告后，按照测试流程要回报应用程序的各种缺陷，然后将这些缺陷发给指定人，以便进行修改和维护。

常用的功能测试方法

功能测试就是对产品的各功能进行验证，根据功能测试用例，逐项测试，检查产品是否达到用户要求的功能。常用的测试方法如下：
1. 页面链接检查：每一个链接是否都有对应的页面，并且页面之间切换正确。
2. 相关性检查：删除/增加一项会不会对其他项产生影响，如果产生影响，这些影响是否都正确。
3. 检查按钮的功能是否正确：如update, cancel, delete, save等功能是否正确。
4. 字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
5. 字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
6. 标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
7. 中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
8. 检查带出信息的完整性: 在查看信息和update信息时,查看所填写的信息是不是全部带出.,带出信息和添加的是否一致
9. 信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
10. 检查删除功能:在一些可以一次删除多个信息的地方,不选择任何信息,按”delete”,看系统如何处理,会否出错;然后选择一个和多个信息,进行删除,看是否正确处理.
11. 检查添加和修改是否一致: 检查添加和修改信息的要求是否一致,例如添加要求必填的项,修改也应该必填;添加规定为整型的项,修改也必须为整型.
12. 检查修改重名:修改时把不能重名的项改为已存在的内容,看会否处理,报错.同时,也要注意,会不会报和自己重名的错.
13. 重复提交表单：一条已经成功提交的纪录，back后再提交，看看系统是否做了处理。
14. 检查多次使用back键的情况: 在有back的地方,back,回到原来页面,再back,重复多次,看会否出错.
15. search检查: 在有search功能的地方输入系统存在和不存在的内容,看search结果是否正确.如果可以输入多个search条件,可以同时添加合理和不合理的条件,看系统处理是否正确.
16. 输入信息位置: 注意在光标停留的地方输入信息时,光标和所输入的信息会否跳到别的地方.
17. 上传下载文件检查：上传下载文件的功能是否实现，上传文件是否能打开。对上传文件的格式有何规定，系统是否有解释信息，并检查系统是否能够做到。
18. 必填项检查：应该填写的项没有填写时系统是否都做了处理，对必填项是否有提示信息，如在必填项前加*
19. 快捷键检查：是否支持常用快捷键，如Ctrl C Ctrl V Backspace等，对一些不允许输入信息的字段，如选人，选日期对快捷方式是否也做了限制。
20. 回车键检查: 在输入结束后直接按回车键,看系统处理如何,会否报错.您好!欢迎共同讨论！有时间逛逛IT实验室,天天软件测试网

‘伍’ 项目管理中 fp数 怎么算的

功能点分析法(FPA：function point analysis)是在需求分析阶段基于系统功能的一种规模估算方法，是基于应用软件的外部、内部特性以及软件性能的一种间接的规模测量。FPA法由IBM的工程师艾伦·艾尔布策(Allan Albrech)于20世纪70年代提出，随后被国际功能点用户协会(IFPUG：The International Function Point Users' Group)提出的IFPUG方法继承，从系统的复杂性和系统的特性这两个角度来度量系统的规模，其特征是：“在外部式样确定的情况下可以度量系统的规模”，“可以对从用户角度把握的系统规模进行度量”。功能点可以用于“需求文档”、“设计文档”、“源代码”、“测试用例”度量，根据具体方法和编程语言的不同，功能点可以转换为代码行。经由ISO组织已经有多种功能点估算方法成为国际标准，如：①加拿大人艾伦·艾布恩(Alain Abran)等人提出的全面功能点法(full function points)；②英国软件度量协会(UKSMA：United Kingdom Software Metrics Association)提出的IFPUG 功能点法(IFPUG function points)；③英国软件度量协会提出的Mark II FPA功能点法(Mark II function points)；④荷兰功能点用户协会(NEFPUG：Netherlands Function Point Users Group)提出的NESMA 功能点法，以及软件度量共同协会(COSMIC：the COmmon Software Metrics Consortium)提出的COSMIC-FFP方法，这些方法都属于艾尔布策功能点方法的发展和细化。

功能点分析法的基本计数
功能点分析的基本计数就是依据标准计算出的系统(或模块)中所含每一种元素的数目：①外部输入数(EI：external input)：计算每个用户输入，它们向软件提供面向应用的数据。输入应该与查询区分开来，分别计算。②外部输出数(EO：external output)：计算每个用户输出，它们向软件提供面向应用的信息。这里，输出是指报表、屏幕、出错信息，等等。一个报表中的单个数据项不单独计算。③外部查询数(EQ：external query)：一个查询被定义为一次联机输入，它导致软件以联机输出的方式产生实时的响应。每一个不同的查询都要计算。④内部逻辑文件(ILF：internal logical file)：计算每个逻辑的主文件，如数据的一个逻辑组合，它可能是某个大型数据库的一部分或是一个独立的文件。⑤外部接口文件(EIF：external interface file)：计算所有机器可读的接口，如磁带或磁盘上的数据文件，利用这些接口可以将信息从一个系统传送到另一个系统。

‘陆’ 调研问卷中多选题的分析方法探讨

调研问卷中多选题的分析方法探讨

使用调研问卷的定量研究中，为了更全面地了解研究内容、更广泛地收集信息，经常会用到多选题，但由于多选题多指向性的特点，除了频数表和交叉表（只能与单选题做交叉），较少用到其他的分析方法，损失了很多有用的信息。其实，如果调研时能善用多选题，并在分析时选取适当的方法，就能够充分利用多选题包含的信息，得到更有价值的结论。

前两篇文章分别谈到调研问卷中带有分类性质的多选题、带有求和性质的多选题如何进行分析，本文将侧重说一下带有递进逻辑的多选题如何进行深入分析。

带有递进逻辑的多选题

问卷调研中，常会通过多选题考察用户在某个方面不同层次的情况，如对某个卖家产品各功能的使用情况（经常使用的功能）、使用的满意情况（满意的功能）、需要改进的情况（亟需改进的功能）等，题目与题目之间是同一个问题的不同层次，存在递进的逻辑关系，即使用频率高低与是否满意、是否亟需等，三者之间分别存在逻辑关系。

此时，这种存在递进逻辑的多选题，可以首先考察不同题目相同选项之间的相关性；其次，能够衍生出新的题目，进行深入分析，挖掘表面背后的原因。

其实，这种带有递进逻辑的多选题，可以采用量表的形式进行考察，而量表题涉及到N级量表，相当于每个项目（选项）都是一个题目，具有递进逻辑的项目之间，进行相关分析、衍生变量分析，更能深入挖掘用户在某一方面的综合情况。只是为了节约用户的填答成本，常用多选题代替。

另外，衍生出的新题目，也是可以通过直接询问的方式获得的，但通常题目带有递进逻辑时，需要用户深入全面思考，耗费的精力较大，也容易造成理解上的偏差，给研究结论带来较大的非抽样误差。因此，通过多个简单的题目，计算出带有递进逻辑的结果，更易行更有效。

带有递进逻辑的多选题一般具备以下几个特征：

1、题目与题目之间的递进逻辑存在分析价值，如对某个卖家产品各功能的考察中，卖家对产品功能是否满意与是否亟需改进之间的递进关系，对于产品改进的方向、改进的优先级等有较大的参考价值。如果是满意但亟需改进，表明该功能可能需要创新；若不满意但没有亟需改进，则说明该功能的改进优先级可以适当靠后。

2、相关题目之间的选项相同，选项若不对应，或部分对应，会造成递进逻辑关系不紧密，容易引起结果出现偏差。
会有特殊情况，如某产品经常使用的功能选项，除主要功能外，还有一个互斥的选项“不常用以上功能”；亟需改进的功能选项，除主要功能外，也有一个互斥的选项“均不需要改进”。这类情况中，题目多出来的互斥选项只是为了解决题目设置为必选时，满足某种特殊情况，主要功能仍然是一一对应的，不对应的互斥选项，后续不进入递进关系的分析。

3、相关题目的选项尽可能覆盖全面，选项尽量能够覆盖考察的主要细节点，以免用户过多地选择“其他”选项，削弱了分析递进关系的可能性。

4、相关题目的选项个数最好超过3个，如果选项只有3个或更少，将多选题改为量表题，用户的填答成本不太大，获得的信息会更多，后续利用递进关系进行分析时，可以更加深入。

5、相关题目设置限选时需考虑递进逻辑，若同时限选，限选的个数最好相同；由于递进关系通常是由弱到强，有时可以设置递进关系较弱的题目不限选，较强的题目限选，如满意的功能不限选，亟需改进的功能限选，可以分析递进关系中的强度。但如果递进关系较弱的题目限选，而递进关系较强的题目不限选，则容易造成解读上的偏差，带来不必要的麻烦。

6、数据为0/1格式，即每个选项一个变量，选中为1，未选中为0，多选题转换成此种格式，宜于做深入分析。

当调研问卷中设置了带有递进逻辑的多选题，就可以采用下文介绍的方法进行深入分析。

本文中的例子，采用年初时自主发起的《卖家旺铺选择研究》，研究中涉及两套递进关系的题目：
您目前已经在用的旺铺功能有哪些？（可多选）
您目前最需要的旺铺功能有哪些？（可多选，最多9项）
您目前使用旺铺主要解决了哪些问题？（可多选）
您最希望通过旺铺帮您解决哪些问题？（可多选，最多6项）

相关分析

本文的案例主要研究旺铺，根据版本分析更有价值。以使用拓展版旺铺的用户为例，分别计算已经在用的功能和最需要的功能，再对每一个功能在用的和最需要的变量做相关分析，能够得到如下结论（详见下图，数字略）：

1、已经在用的高比例，同时最需要的也是高比例的功能，对于拓展版旺铺而言，是需要维持的功能。

2、需要维持的功能中，个性化店招、数据分析工具、宝贝30天销售量累积显示、自定义页面布局等功能，在用的与最需要的之间存在显着相关（图中已星号标注，*代表显着相关，**代表非常显着相关），从一个侧面表明，已经在用的用户尤为需要这些功能；而其中没有显着相关的功能，则不能得出这样的结论。

3、已经在用的比例不高，而最需要的比例较高的功能，对于拓展版旺铺而言，是需要加强的功能。

4、需要加强的功能中，营销工具组合、不限类型的旺铺装修模板等功能，在用的与最需要的之间存在显着相关，从一个侧面表明，已经在用的用户对这两个功能的期望较高，也特别需要这两个功能。

5、另外，从具体数据上可以看出，虽然拓展版用户已经在用高级发货、进销存管理、客户关系管理等功能的比例不高，但最需要这三个功能的比例远超过在用的比例，表明部分拓展版用户对这三个功能的需求很旺盛。而这三个功能是旗舰版的功能，反映了这部分用户应该选择更高版本的旺铺。

注：虽然高级版本的旺铺中包含一些特有的功能，但这些功能附属的工具可以单独购买，所以，会出现使用低版本旺铺的用户，已经在用某些高版本的功能。情况相对复杂，分析时需要注意，下文雷同，不再赘述。

衍生变量分析

以使用扶植版旺铺的用户为例，因为“目前使用旺铺解决了的问题”与“最希望通过旺铺帮助解决的问题”存在递进逻辑关系，可以衍生出两个比较关键的变量，即已经解决了且希望解决的问题、尚未解决但希望解决的问题。

有了这两个变量，可以更加深入地分析，希望解决的问题具体情况是怎样的，最终分析结论如下（详见下图，数字略）：

1、提升店铺的流量、增加店铺的可信度、增加店铺的专业程度等，是使用扶植版旺铺的用户非常关注的问题，不论目前是否解决，都非常希望通过旺铺解决，表明这三方面是需要维持的利益点，也是宣传扶植版旺铺的重点。

2、装修更便利、店铺更美观等，是目前解决了，但仍希望通过旺铺解决的问题，表明这部分使用扶植版旺铺的用户，对装修的便利性、装修效果等更重视，希望能做到更好，可以对他们做相应的培训，或直接向他们推荐装修更灵活、呈现更多样的高版本旺铺。（之所以得到这样的结论，主要是因为最希望通过旺铺解决的问题是多选限选，可以根据以往研究经验，假设需求强度不大，已经解决了，就不会再选了。）

3、提升宝贝的转化率/成交量、增加宝贝的点击率、增加买家在店铺的停留时长等，是目前尚未解决，但希望能够通过旺铺解决的问题，表明这部分扶植版旺铺的用户比较直接、实际，非常看重流量和销量，可以对他们做相应的指导，也可推荐引流量的工具或服务。

利用衍生变量深入分析

本研究中在询问功能和解决的问题时，将多个版本的内容融合在一起，后续分析时，可以分析出目前使用某个版本的用户，目前是否适合当前版本，如果不适合，如何引导他们使用更适合的版本；如果适合，是否已经用得足够好，用得不好，如何帮助他们。这些疑问，可以利用衍生变量进行深入分析，从而得到答案。

以使用标准版旺铺的用户为例，首先要明确四个前提步骤：

Step1、由于功能和解决的问题是多个版本融合在一起，需要分清哪些功能是当前版本的，哪些是更高版本才有的，旺铺的高版本兼具低版本的功能。

Step2、分析中需要结合旺铺版本，衍生出一个变量，叫做“更适合的功能点”，即目前未使用，但最需要的功能，且这个功能又是更高版本的旺铺功能；
还需要衍生出另一个变量，叫做“未用好的功能点”，即目前未使用，但最需要的功能，且这个功能是当前版本具备的旺铺功能。

Step3、以往的定性调研表明，一个使用低版本旺铺的用户之所以选择更高版本，往往是看上了高版本的其中一个功能，如宝贝30天销量累积显示。
本例在判断部分使用当前版本的用户，实际上适合更高版本旺铺时，采用了保守的方式，找出前提2中排名前三位的“更适合的功能点”，取平均值，把它当做更适合高版本旺铺的当前版本用户的比例。主要基于假设，这些功能对他们相当重要，理想状态下，后续他们会因为这些功能转用高版本旺铺。
同样，适合但未用好当前版本的用户，也采用了类似的方式计算比例，此不赘述。

Step4、若判定部分当前版本用户适合更高版本旺铺，还需要有促使他们转换的利益点，这些利益点也可以由衍生变量得到，即目前使用旺铺未解决但最希望通过旺铺解决的问题。

也可以找出适合当前版本但未用好的比例，摸清哪些功能点他们没有用好，能够更有针对性地培训，使其充分发挥旺铺的功能。

小结

综上所述，带有递进逻辑的多选题，分析的流程如下：

1、确定在设计问卷时，是否包含递进逻辑的多选题，并确保题目的递进关系存在解读价值、应用价值；

2、根据题目的特点，衍生出新的变量；

3、根据衍生变量的统计量，深入分析样本的相关情况；

4、可以根据其他关键变量（如旺铺版本、星级等）对衍生变量做进一步分析，从而得出更深入的研究结论。

以上是小编为大家分享的关于调研问卷中多选题的分析方法探讨的相关内容，更多信息可以关注环球青藤分享更多干货

‘柒’ 功能点估算法的规模估算

1. 识别功能点的类型。
2. 识别待估算应用程序的边界和范围。
3. 计算数据类型功能点所提供的未调整的功能点数量。
4. 计算人机交互功能所提供的未调整的功能点数量。
5. 确定调整因子。
6. 计算调整后的功能点数量。 通过对需求说明书的分析，我们可以使用“功能点”来对软件产品所提供给用户的功能加以度量。程序长度和复杂性都是对程序的事后分析，软件功能性却可在软件开发的初期进行分析，这对我们预测项目规模，规划项目时间表非常有帮助。
Albrecht的度量方式是先按需求描述对功能点计数，得到未调整功能点，再按系统涉及到的技术功能点对该数值进行修正。
按照软件表示技术，一项需求可描述为若干外部输入、外部输出、外部请求、外部文件、内部文件的集合。对集合中每一子项进行计数，并按其复杂性指派相应的权重，可得未调整功能点UFC：
n
UFC = ∑ (项目i的权重*权重i)
i=1
任何需求的实现，总与一定的技术有关。Albrecht定义了14项技术特性，对应每一特性有一个从0到5的关联值Fi（0说明此项技术特性与功能实现毫无关系，5说明此项技术特性是系统建立必不可少的组成部分）。一项需求的技术复杂性特性值TCF即由这些评分合成，公式如下：
14
TCF = 0.65 + 0.01 ∑ Fi
i=1
最后，功能点的度量值FP，为以上二者的乘积：
FP = UFC * TCF

‘捌’ 功能点估算法的估算过程

估算的过程主要包括规模估算、规模调整、估算工作量、估算工期和确定预算。上一部分主要讲解了估算规模和规模调整这两部分。
根据调整后软件规模，估算工作量，公式如下：AE=(PDR*S)*SWF*RDF
估算工期可根据工作量-工期模型计算，公式如下：D=1.277*(AE/HM 1 )0.404，当期望工期短于估算工期的下限时，应对项目需求进行分析并适当调整。通常，压缩工期会增加项目工作量，及导致生产效率降低。
在获得了工作量估算结果后，可采用以下公式估算项目预算：P=AE/HM 2 *F 2 +DNC
审批预算时应考虑以下因素：预算的合理性；可用于本项目的资金情况；概算或年初总预算额；其他预算项目可行性及投资收益率对比和平衡。（以上内容均摘自行标《软件研发成本度量规范》）