TP的突出特点（1）

zhuangliang

1)        测试分析设计
测试资产的管理不能仅仅局限在测试用例等工作结果的管理上，还应该对如何产生测试用例的分析设计思维过程进行记录和管理，只有这样才能方便通过分析设计过程的评审来保证测试分析设计活动的质量，保证覆盖率。
TP能够提供5种测试分析方法：继承性分析、质量模型分析、用户场景分析、功能交互分析，测试工程师使用这些方法能够自动生成测试项，同时TP将帮助测试工程师记录和管理测试分析的思维过程，保证测试分析覆盖率。
另外TP提供9种测试设计方法：域测试法（等价类和边界值）、输出域测试法、正交试验法、业务流分析法、状态迁移法、判定表法、因果图法、逐级细分法、错误猜测法，测试工程师使用这些方法能够自动生成测试用例，同时TP将帮助测试工程师记录和管理测试设计的思维过程，保证测试设计覆盖率。
需要设计测试用例的测试场景如下：

该场景是一个比较简单的测试场景，针对该场景使用业务流分析法来进行测试用例设计。用户在TP中完成业务流程图的绘制，TP将根据该流程图自动生成3个测试用例来覆盖3条业务路径。自动生成的测试用例将与业务流程图形成关联，TP将不仅仅记录最终的3个用例，还将设计过程中的流程图信息完整记录下来。

后期如果要追踪用例质量、评估用例覆盖度，可以查看以上的测试用例设计视图，即能完整重现整个测试用例设计过程，即可知道测试工程师是如何考虑测试用例设计的，覆盖了哪几条路径，从而能更好的开展评审，而不是只能根据最终用例结果来判断覆盖情况。
假设通过评审发现设计测试用例时漏掉了一些路径，测试工程师可以在流程图上增加路径，这样业务流程法就会补充测试用例来覆盖路径。

如果测试用例设计好后，测试工程师又自行删除了某条测试用例，这个删除记录同样可以在测试用例设计视图中可以看见，从而避免测试用例的随意删除导致覆盖不全，引起漏测。


2)        计划任务驱动的工作模式
测试计划的难点在于如何能把计划变成能真正实施的具体任务，驱动测试人员完成其工作，同时能对其进度和完成情况进行实时监督。TP借助于OA办公自动化的思路来实现计划任务驱动：管理人员安排各类测试任务，任务会分配到各测试人员“我的工作”区间；测试人员围绕“我的工作”区间中未完成任务，每日进行各类具体测试工作，系统将任务进度自动反馈给管理者。这个闭环过程全部在TP平台上完成，大大提高了沟通效率。以下是TP的实现方式：
        制定测试计划并在该计划中关联了任务的具体工作对象，从而能驱动测试人员进行具体工作，并能量化的评估工作进度。
        测试工程师在“我的工作”区间的工作列表中即可明确知道哪些工作要开展，进度要求分别怎样。
        完成任务过程中，测试工程师须填写工作日志，这样管理员人能了解每个任务的完成状况，并能知道每个任务所花费的工作量。
        有了工作量数据以及进度数据，管理人员能很好的把握整个进度状况。
        同时管理人员还可随时通过度量数据把握整个测试的细节。根据度量数据来进行改进，从而保证计划的按时保质保量完成。
制定测试计划：

在该计划中关联了任务的具体工作对象，从而能驱动测试人员进行具体工作，并能量化的评估工作进度。

测试工程师在“我的工作”区间的工作列表中即可明确知道哪些工作要开展，进度要求分别怎样。

完成任务过程中，测试工程师须填写工作日志，这样管理员人能了解每个任务的完成状况，并能知道每个任务所花费的工作量。

有了工作量数据以及进度数据，管理人员能很好的把握整个进度状况。

同时管理人员还可随时通过度量数据把握整个测试的细节。根据度量数据来进行改进，从而保证计划的按时保质保量完成。



3)        全方位度量体系
度量的难点在于度量数据的收集。测试度量的四大基础度量项为：规模（如需求数、测试用例数等）、工作量（各工作类型的分类统计）、进度、缺陷（缺陷按属性分类统计）。一般的测试管理工具都实现了测试资产的管理，所以规模度量和缺陷度量能够做到自动收集；但工作量度量和进度度量数据由于分布在每个人每天的各类工作中，很难做到自动收集，这是目前很多公司度量体系没有建立起来的根本原因。TP借助上面提到的计划任务驱动模式，通过测试任务关联工作日志来进行工作量和进度数据的收集。
测试工程师每天围绕“我的工作”区间未完成任务进行工作。当一项任务完成，需要关闭时，TP会强制生成一项和该任务关联的工作日志，并自动填写了所投入的工作量、进度等数据，工程师可以在此基础上修正该数据。
收集到的工作量数据和进度数据将会自动进入TP的度量体系中，可以选择查看不同类型工作的工作量以及不同任务的进度。
对工作量、进度等四大基础度量项自动收集存储的问题解决后，度量体系还需要解决如何对这些度量项进行分析。度量分析活动首先需要根据管理需求确定度量指标，如进度指标（如进度偏差度量等）、质量指标（如漏测率等）、生产率指标（测试执行效率等）、成本指标（测试用例设计成本等）等；确定好度量指标后，接下来确定每个指标需要使用的度量项及计算公式（比如测试用例设计成本需要使用测试用例数和测试用例设计工作量这两个基础度量项进行相除得到）；然后设计相应的统计分析图表对这些度量项、度量指标进行对比分析。一般的测试管理工具都会预设一些报表供用户选择，但一旦用户要调整图表中的度量项或度量指标，或者增加新的统计图表，就需要重新开发，很不方便。
TP则给用户提供了自由的选择，可以完全根据自己的管理需求来灵活的自定义度量指标及相关计算公式，然后将这些度量项、度量指标通过拖拽操作进行所需统计分析图表格式的设计，而不需要重新定制开发。下面就是这次在人行试用过程中根据人行情况自定义的几个代表性度量指标：
质量指标：各功能测试通过率（通过用例数/用例数）
生产率目标：测试人员执行效率（执行用例数/执行工作量）
进度指标：各任务进度百分比
成本指标：测试用例设计成本（测试用例设计工作量/测试用例数）
如下图所示，测试工程师每天围绕“我的工作”区间未完成任务进行工作。当一项任务完成，需要关闭时，TP会强制生成一项和该任务关联的工作日志，并自动填写了所投入的工作量、进度等数据，工程师可以在此基础上修正该数据。

收集到的工作量数据和进度数据将会自动进入TP的度量体系中，可以选择查看不同类型工作的工作量以及不同任务的进度。

对工作量、进度等四大基础度量项自动收集存储的问题解决后，度量体系还需要解决如何对这些度量项进行分析。度量分析活动首先需要根据管理需求确定度量指标，如进度指标（如进度偏差度量等）、质量指标（如漏测率等）、生产率指标（测试执行效率等）、成本指标（测试用例设计成本等）等；确定好度量指标后，接下来确定每个指标需要使用的度量项及计算公式（比如测试用例设计成本需要使用测试用例数和测试用例设计工作量这两个基础度量项进行相除得到）；然后设计相应的统计分析图表对这些度量项、度量指标进行对比分析。一般的测试管理工具都会预设一些报表供用户选择，但一旦用户要调整图表中的度量项或度量指标，或者增加新的统计图表，就需要重新开发，很不方便。
TP则给用户提供了自由的选择，可以完全根据自己的管理需求来灵活的自定义度量指标及相关计算公式，然后将这些度量项、度量指标通过拖拽操作进行所需统计分析图表格式的设计，而不需要重新定制开发。下面以几个有代表性的度量指标分析图表的生成来说明：
质量指标：各功能测试通过率（通过用例数/用例数）

生产率目标：测试人员执行效率（执行用例数/执行工作量）

进度指标：各任务进度百分比

成本指标：测试用例设计成本（测试用例设计工作量/测试用例数）


4)        文档自动生成
测试进行过程中或者测试结束时都需要编写一些测试文档，比如测试日报、测试周报、测试报告、测试用例文档等。手工完成测试文档的编写往往会花费较多时间，如果能自动生成符合公司文档模板要求的测试文档出来，将能大大降低编写文档的工作量，将更多时间放到测试本身上去。
TP内嵌了WORD功能，能自定义人行清算中心各类文档模版，并在模板指定位置嵌入项目动态信息（例如开始日期、需求数、用例数等）、测试资产表（如需求表、用例表等）、度量分析图表（如缺陷分类表、人员执行效率表等）。当需要按模板生成文档时，TP将按所选模板生成已经含有上述内容的文档，这个文档可以作为最终文档，最多再加些主观的分析评价，而不需要做其他加工。
下面几张图可以分别看到TP在文档模板中嵌入项目动态信息、度量分析图表、测试资产表的几种情况。
模板中嵌入了项目动态信息：

按上面模板生成的最终文档截图，可以看到文档对应位置已经嵌入了项目实际信息：

模板中嵌入了度量分析图表（在项目度量模块自定义的）：

按上面模板生成的最终文档的截图，可以看到文档对应位置已经嵌入了用例执行进度统计报表：

模板中嵌入了资产表（这里是以用例表为例，将用例各字段嵌入到自定义格式的表格中，并且按需求分层生成）：

按上面模板生成的最终文档的截图，可以看到文档对应位置已经嵌入了用例表，并且用例是按对应需求分层生成在一起，符合所设计的格式：


5)        测试资产复用和变更同步
不同的项目间可能会有不少数据是可以复用的，比如测试用例，这样一方面能减少重复设计测试用例的时间，另一方面能保证测试用例的质量。在不同项目、版本间复用测试资产不能等同于简单的复制粘贴，必须在不同的项目、版本间建立测试资产的复用跟踪关系，这样才能在测试资产维护时根据复用跟踪关系进行变更同步。如果只是项目版本间复制粘贴的话，后期维护成本相当大，根本搞不清楚哪些项目版本用到了这批用例，需要多处查找进行重复修改。
TP通过继承来实现不同项目版本间测试资产的复用，包括版本继承和需求继承。版本继承可以把旧版本中的测试用例都复用到新版本上去，并且其需求跟踪关系也同样继承过来了。除了版本继承，TP还支持需求继承，这样就能跨项目复用测试资产了，从而使得构造测试案例库成为可能。
同时TP内部将自动维护每个测试资产的继承复用跟踪关系，因此一旦参与复用的某个测试用例发生变化，TP可以马上通过继承同步功能将这种变化体现到有复用跟踪关系的用例上去，包括案例库以及其它项目，大大提高测试用例维护效率。
TP通过继承来实现不同项目版本间测试资产的复用，包括版本继承和需求继承。同时TP内部将自动维护每个测试资产的继承复用跟踪关系。
版本继承可以把旧版本中的测试用例都复用到新版本上去。

继承得到的需求都属于继承需求，其需求跟踪关系也同样继承过来了。

版本继承关系可以在项目的版本图中体现出来。

除了版本继承，TP还支持需求继承，这样就能跨项目复用测试资产了，从而使得构造测试案例库成为可能。

由于继承的测试用例之间都存在复用跟踪关系，因此一旦参与复用的某个测试用例发生变化，TP可以马上通过继承同步功能将这种变化体现到有复用跟踪关系的用例上去，包括案例库以及其它项目，大大提高测试用例维护效率。


6)        缺陷分析
通过测试会积累不少缺陷数据，TP中集成的业界常用缺陷分析方法能从这些缺陷数据中挖掘出一些有价值的信息，对现有测试工作进行评估和改进。这些缺陷分析方法包括：ODC分析、Gompertz分析、DRM分析、四象限分析和Rayleigh分析等。
ODC分析方便用户对缺陷各属性进行分析，得到开发或测试改进点；Gompertz分析帮助用户预测缺陷极限数，建立测试退出准则；DRM分析帮助用户通过历史项目缺陷发现情况来确定新项目各阶段质量目标；四象限分析帮助用户判断哪些功能已经进入稳定区，可以退出测试；Rayleigh分析通过软件研发各阶段发现缺陷情况来预测系统测试阶段极限缺陷数。
Gompertz分析：

缺陷去除模型分析：