让你的测试有飞一样的感觉——TP使用实践

zhuangliang

很多朋友和我说，TP测试平台不太会用，尤其是直接使用的话，会被功能模块中，各种各样的功能项弄得眼花缭乱，接着内牛满面的和我说“兄弟，真心的复杂”。
在此，我建议大家不要太心急，毕竟罗马不是一天建成的，TP也不是一天能飞起来的，TP这个工具和其他同类型的工具（主要还是偏向于测试资产的管理）而言，
他希望告诉各位的是一种理念。
一种测试思想的理念：在规范的流程为前提下，让你的测试思想有多远，你的测试就能够走多远。
这样，你就能够真正的让你脱离测试执行的苦海，真让你的测试有一种“天高任鸟飞，海阔凭鱼跃”的感觉。
那么下面 ，让我们来看看TP怎么让我们有飞一样的感觉。

zhuangliang

首先，我们来谈谈TP是如何来解放你的思维。对于大部分测试工程师而言，常规的测试用例设计、分析要花掉我们大量的时间，这就造成一个很尴尬的事情：“我整天在做常规的测试用例工作，累的半死，你让我哪有时间去思考测试应该怎么做”。众所周知，常规测试用例永远占了测试用例的比重最大，但是，通过简单的测试用例库来解决这个问题，又不是万能的，主要是出在，用例库要对应单一的产品效果较好。而现阶段中，我在“中国软件测试那些事”中提到，我们现阶段面对还是一个个单一的项目，造成用例库复用的效果较低，为了解决这一问题，TP不再是单一的通过简单的测试用例库的方式来解决，而是通过提供测试用例设计、分析的方法来实现。
接下来，让我们看看这个例子：
《全能音频转换通》--软件介绍
全能音频转换通是一款音视频文件格式转换软件。它支持目前所有流行的媒体文件格式(MP3/MP2/OGG/APE/WAV/WMA/AVI/RM/RMVB/ASF/MPEG/DAT)，并能批量转换。
更为强大的是，该软件能从视频文件中分离出音频流，转换成完整的音频文件，典型的应用如WAV转MP3，MP3转WMA，WAV转WMA，RM(RMVB)转MP3，AVI转MP3，RM(RMVB)转WMA等。
下面是一张主界面截图：

1.1        测试分析
测试分析阶段是对需求管理模块的需求，通过常用的分析方法进行分析，得到高质量的测试项。需求管理部分产生的需求可通过一些工程方法（质量模型分析、功能交互分析、用户场景分析、逐级细分分析）产生测试项。
a)        质量模型分析
质量模型分析主要从软件质量特性进行分析，结合了软件质量的6大特性27个子特性，另外每个质量特性下都有一个质量子特性缺省的状态，在根据实际运用中用户可对质量子特性不明确的情况认为是缺省的情况下进行分析。
结合测试对象“添加文件”这一需求通过质量模型分析，从功能性考虑测试添加文件、选择文件时文件名生成的功能是否被实现；从可靠性的成熟性考虑测试反复多次添加文件的情况，从可靠性的易恢复性考虑测试添加文件中程序异常退出如何处理的情况；从效率的时间特性考虑测试添加文件的响应时间是否满足用户的需求，从效率的资源利用性考虑测试添加文件时的内存消耗是多少。
根据以上的分析思路在TP的测试分析模块选中“添加文件”这一需求后选择质量模型分析对其进行分析从而得到测试项，详情如图所示：

针对特定的需求后可根据实际情况在相应的特性以及子特性下进行添加测试项。
b)        功能交互分析
功能交互分析主要针对需求与需求间发生交互关系产生测试项。当前需求是在测试分析主界面选中的需求；交互需求是在待选需求里选择的需求，与当前需求进行交互的；测试项是根据两个需求进行交互产生的。
结合测试对象“批量转换”这一需求通过功能交互分析，批量转换会与添加正在批量转换的文件、截取转换相同的文件产生功能交互，根据需求间的相互交互产生测试项。
根据以上分析在TP里选中需求再选择功能交互分析，详情如图所示：

c)        用户场景分析
用户场景分析当选择一个需求项来使用用户场景分析时得到的是独立测试场景，当选择多个需求项来使用用户场景分析时得到的是流程测试场景。当需求是添加文件、合并转换、批量转换、截取转换，至少应包含一个转换和添加文件使用用户场景分析时得到添加文件、转换连续交替进行这一测试项。
根据以上分析在TP里选中需求再选择用户场景分析，详情如图所示：

1.2        测试设计
TP工具中提供了多种测试设计方法，方便在测试过程中设计更有效的用例，结合实际例子一一介绍测试用例的设计方法。
a)        域测试法
针对测试项“测试添加文件”使用域测试法进行设计用例，首先对测试项增加输入为测试添加文件，有效等价类为不同文件的存放位置、文件被其它程序占用情况、若干音频文件，在等价类不同文件的存放位置上增加样点为：在其它电脑共享目录下、在U盘上；在等价类文件被其它程序占用情况上增加样点：非独占方式打开、独占方式打开；在若干音频文件上增加样点：1个音频文件（边界值上点）、50个音频文件（内点）、100个音频文件（上点）。根据此分析思路使用域测试法设计用例，详情如图所示：

生成的测试用例如图所示：

b)        输出域分析法
针对测试项“测试截取转换”从输出域分析法考虑，首先增加输出为歌曲名、歌手名，增加有效等价类为与截取转换前一致，针对歌曲名的等价类增加样点为：歌曲名为空、歌曲名包含英文汉字、歌曲名长度为1000；歌手名的等价类增加样点为：歌手名长度为50。输出域法主要通过输出结果反推出输入的输入值。域测试法用例设计详情如图所示：

生成的用例如图所示：

c)        正交试验法
针对测试项“测试批量转换”从正交试验法考虑设计用例，增加一个类别如：批量转换，在此类别下增加参数：输出格式、编码器、输出质量、重命名文件处理，为每个参数增加取值，参数输出格式取值：wma；参数编码器取值：ACELP.net、Windows Media Audio 9；参数输出质量取值：48-44-mono、VBR-48-stereo；参数重命名文件取值：覆盖、跳过、自动换名。通过这种分析思路在TP中根据正交试验法设计测试用例，用例设计详情如图所示：

生成的用例如图所示：

d)        状态迁移法
针对测试项“测试内置播放器使用”从状态迁移的角度考虑设计测试用例，首先分析状态之间的迁移情况，清楚状态之间的转换后画出状态迁移图，这里主要有播放、暂停、停止三个状态，可以从播放-暂停-停止、停止-播放等路径，状态迁移图详情如图所示：
[
根据状态迁移图生成的测试用例如图所示：

e)        判定表法
针对测试项“测试添加文件”从判定表法的角度考虑设计用例，判定表法主要分为两个部分：条件桩、动作桩，由不同的条件产生不同的结果，增加条件桩文件类型、文件被打开情况，文件类型的条件取值：音频、视频、非音视频；文件被打开情况的条件取值：未被其它程序打开、被其它程序独占方式打开、被其它程序非独占方式打开，在条件桩的基础上增加动作桩：能否选择输入列表，动作取值：能、不能，有了分析思路再利用TP工具使用判定表法设计用例，设计详情如图所示：

条件桩与动作桩的取值确定输入以后会先转化为判定表，可以编辑判定表进行合并等操作最终确定测试用例的个数，生成的判定表如图所示：

最终生成的测试用例如图所示：

TP中提供了各种分析与设计方法，可以在测试工作中带来很大方便，同时测试的更加充分，有效的提高软件的质量。
TP的分析设计关键是将人的分析设计思考的过程记录和管理起来了，便于以后查看以及进行评审，直接查看分析设计视图即可。例如：针对测试项“测试添加文件”使用的用例设计方法是判定表法，可直接打开设计视图查看分析的思路，详情如图所示：

zhuangliang

对于我们测试人员而言，通过测试执行工具确实能直接找软件存在的问题，但这些问题只是单一存在，比较接近于细节。
这让我想起了两个名字“工程狮”和“技术猿”，现在大部分的软件测试人员都想成为“工程狮”，但其实还是“技术猿”的工作。
可能会有人不服气说“你又知知道了？！”呵呵~是的，我当然知道了。因为，我就是这样成长起来的。
绝大部分的IT从业人员都希望以后能够成长为项目经理、技术总监等等，而我们一般是这样的认为的，“我的技术能力越强，那么我的我就离这些职位的越近”。
这就走入了一个误区，就是我只管技术，当你深深的钻入了某个点里面去的时候，确实你精通了，但你也就死在上面了，你成了一个不折不扣的“技术猿”，因为，你会发现你所处在的位置只是某一个点上面，而不是全局。
那么“工程狮”怎么去做的呢？他们会将所有去把握整个全局，去评估缺陷、问题及质量，这也是TP第二步想让大家做到的，让思维飞起来，因为只有你的思维有多高，那么你的位置也就能有多高了，这样才能提高你的测试思维及测试质量。
现在我们来谈谈TP去怎么做的吧
大家来看看下面的例子：
TP可以通过统计度量和缺陷分析来实时把握进度、质量等信息，从而为后续工作的调整改进提供数据分析，并找出项目及团队中质量问题的症结而更好的改进这些问题。
1.1        统计报表
TP支持完全用户自定义的需求报表、测试项报表、测试用例报表和测试用例执行报表。在测试工作过程中或者测试结束时都可以通过项目管理中查看项目详细信息时打开统计报表界面：

统计报表界面中提供了各种可以用于进行统计分析的属性值（比如需求状态等）、数据值（比如缺陷数、用例密度等），通过拖拽的方式即可得到各种统计报表：

以下是针对某个项目通过拖拽方式得到的各组每人密度数据度量，行域放的是创建人属性字段，数据项目放的是测试项密度、用例密度、缺陷密度，这样可以同时查看组内每个成员的密度数据，密度数据的高低一定程度反映出测试的细致程度和测试效果：

从该数据可以发现，其中前2个人的用例密度比后2个人的小很多，那有可能说明前2个人的测试用例设计的比较粗，需要再仔细查看一下。
选中表格中的数据，则可以根据自己的喜好来得到图数据，更直观的反映各种数据的对比情况：

如果觉得该图表值得保留下来以便长期查看，可以通过点击右上角的保存按钮保存到左侧列表中，保存的图表既可以只是本项目可以查看，也可以是全系统共享查看。

1.2        缺陷分析
除了针对需求、测试项、测试用例、缺陷一起来进行统计度量，还可以使用一些缺陷分析方法单独对缺陷来进行分析，从而提升测试和开发。缺陷分析方法包含ODC分析、缺陷去除模型分析、Rayleigh分析、Gompertz分析和四象限分析等，其中ODC分析和Gompertz分析是最常用的。
ODC分析用于分析缺陷数据的特征，比如各种严重级别缺陷所占的比重分别是多少，和历史数据相比有没有什么异常等。
进入缺陷分析模块，选择ODC单维度分析Tab页，点击配置按钮，选择显示所有分析属性：

选择要进行缺陷分析的项目，选择要分析的属性字段严重级别，点击开始分析，得到各种严重级别缺陷所占的比重，如果致命和严重缺陷比重太高（比如超过3%）则说明软件整体质量较差，后续需要的轮次会比较多。

Gompertz分析用于根据前面发现缺陷累计数量来预测后面能发现的缺陷数量以及还需要的测试时间，可以很好的用于测试进度的监控，让测试管理者对测试何时可以结束退出有个大致的估计。
选择要进行Gompertz分析的项目、版本或者子项目，点击开始分析，左下半部分将显示根据前面发现的累计缺陷数变化情况拟合出来的Gompertz曲线，根据该曲线则得到右下半部分的预测结果。

zhuangliang

最后，我们来聊一下流程及规范，就个体而言，很多人觉得是规范和流程束缚了我们的思维。
但我想告诉各位，其实，这恰恰相反，之前我的工作经历中，对于我影响最大的两件事情，一件是之前提到的以全局的思维去做测试，另一件事情就是流程规范。
之所以大家觉得规范不舒服的原因，在于规范规定了我做一件熟悉的事情的方式，本来我可以快一点完成的，可是按照流程、规范来做的话，可能就慢了、复杂了，所以，大家不喜欢。
其实，流程规范的原因是在于解决你不了解的事情，这是深有感触的一点。
当你做不了解的事情时候，你无从下手，那么你可以根据流程来做事情，他不能保证你做到最好，但绝对可以保证你把事情完成，而且避免了大部分的错误，这就是流程规范的意义。
那么，TP所给我们带来的一个项目流程又是什么样的呢？
就让我们来看看下面的这个例子：
飞信登录功能，针对此功能展示整个测试流程在TP工具中的应用。
确定测试对象后就从创建项目、添加需求、添加测试项、添加用例、执行用例、提交缺陷这六个角度展开测试。
1.1        创建项目
了解测试对象后以此对象创建项目，在TP工具中项目管理模块下创建项目，填写项目的基本信息，创建项目详情如图所示：

飞信登录功能的项目已经创建，后续的资产会一并在该项目中保存。项目创建好之后应该进行对需求、测试用例等资产的管理。
1.2        添加需求
在已创建的飞信登录项目下添加需求，主要从用户名、密码、登录状态等角度测试，在需求管理模块选中所属的项目下添加需求，添加需求详情如图所示：

针对飞信登录功能简单的添加了用户名输入、密码输入、登录状态三条需求，新添加的需求的状态为初始化状态，需求详情如图所示：

1.3        添加测试项
测试项是在需求的基础上进一步细化得来的，根据需求添加相应的测试项，例：针对用户名这条需求，可以细化为分别以手机号码、邮箱注册的用户名的测试项，添加测试项详情如图所示：

针对飞信登录功能下的用户名输入、密码输入、登录状态三条需求进行细化简单得到以手机号码注册的用户名、以邮箱号码注册的用户名、正确的密码、错误的密码、在线登录、隐身登录六条测试项，添加测试项后需求的状态会自动跟踪到测试分析状态，需求状态变化如图所示：

1.4        添加用例
     根据测试项设计测试用例，测试用例要尽可能多的覆盖测试点，例：针对飞信登录功能下的测试项设计测试用例，一般情况下首先使用手机号码注册的用户名、正确的密码、在线状态登录；再使用邮箱号码注册的用户名、正确的密码、在线状态登录等多种登录情况进行设计用例，添加用例详情如图所示：

针对测试项设计出多条测试用例，使其测试能够更加充分，保证功能的准确性。添加用例后需求的状态自动跟踪到测试设计状态，需求状态变化如图所示：

1.5        执行用例
测试用例设计完成，前期工作准备就绪后进入到用例的执行阶段，在执行用例的过程中根据测试用例的执行情况在最终结果处调整用例的执行结果，用例执行详情如图所示：

用例被执行过以后需求的状态也会自动跟踪起来，如果用例通过则相对应的需求的状态自动跟踪到验证通过状态，用例失败则相对应的需求的状态自动跟踪到验证失败状态，阻塞的用例则相对应的需求的状态自动跟踪到验证状态，需求状态变化如图所示：

1.6        提交缺陷
在测试执行的过程中针对失败的用例提交缺陷，提交缺陷界面如图所示：

缺陷信息填写完整提交后与用例建立跟踪关系。需求、测试项、测试用例、缺陷都可以产生跟踪关系，在用例详情里可以查看用例和缺陷的跟踪关系，以及需求、测试项、测试用例等资产之间的跟踪关系如图所示：


TP工具是基于整个测试流程的，最大的优点是资产集中管理，所有的资产统一进行管理；需求自动跟踪，每个阶段的工作都会与需求自动跟踪产生跟踪关系，并且需求状态发生相应的变化；进度快速查看，方便查看项目的测试进度。

testdc

多谢楼主分享

andrewsun

给力，支持~

为了那片海

看完了帖子 感觉用TP的人真的得做到测试专业才行，否则很难马上断定用例的设计应该使用哪个方法，还有测试需求分析里面那些软件工程的东西真不是测试新手直接能上手的，个人觉得如果理论基础扎实了用TP应该得心应手的。

猫星人

去，没有下载试用地址，多少钱也没有说。。。。毛啊。

wrpky

呵呵,支持一下！