Mercury Business Process Testing （二）
上一篇 / 下一篇 2010-03-19 11:08:19 / 个人分类：性能测试
将Business Component自动化
再回到Business Components将其转成自动化测试脚本，在Design Steps点选QuickTest Keyword-Driven，将此Business Components转成QuickTest Keyword-Driven类型的测试脚本。Business Components支援三种类型的脚本：QuickTest Keyword-Driven、QuickTest scrīpted、WinRunner。
转成QuickTest Keyword-Driven脚本后，点选Automation就可以看到其Keyword-Driven的脚本，目前都还是ManualStep。
选择Application Area。这个Application Area内含测试物件（Test Object）、Keyword steps、函式库等等。
将Keyword-Driven步骤加入Business Component中
直接在Keyword View上透过选取Item、Operation、输入Value的方式建立Keyword-Driven脚本。
第一个步骤為执行Flight Reservation程式，在Item栏位就不是选取Test Object，而是选取Operation，然后在Operation栏位选择OpenApp表示此步骤是要执行一个程式，同时在Value栏位输入这个程式的路径，这样第一个步骤就完成了。
在Item选取Login Diaglog的Test Object，然后在Operation选取Activate，表示此步骤為开啟登入视窗，Value栏位则不需要输入任何值。
选取AgentName的EditBox，Operation则是Set，表示要在Agent Name这个EditBox输入资料，至於要输入什麼资料就直接输入在Value栏位中。
在Value栏位输入mercury。
以相同的方式加入其他的步骤，完成后整个Business Component的执行脚本如下。
Mercury 在 Quality Center 8.0 时就推出 Business Process Testing，到现在已经进步到 9.0 的版本了。为什么 Mercury 发展出 Business Process Testing 呢？Business Process Testing 的好处在哪？要如何使用Business Process Testing？我将在以下的文章为大家做个介绍。
传动自动化测试的限制
软体的自动化测试在过去一段时间中有长足的进步。每个世代的產品都成功解决了某些重要的挑战，但是同时也引进了不同的问题等待解决。
第一代的自动化测试大概在15年前开始，透过硬体的方式录製键盘的输入并播放，但缺少检查点（checkpoint）的功能，而且测试脚本很难维护。
第二代的自动化测试则大约在10年前开始的，这时已经由硬体转变成透过软体录製/播放（capture/playback）的方式產生测试脚本（scrīpt），并且也增加了检查点的功能，可以对软体做验证，测试的范围也比硬体方式的自动化方式大了许多。比较大的问题是测试脚本也是一种程式语言，所以测试人员也需要懂程式语言，换句话说就是要会写程式。而且当软体有变动时，测试脚本也需要同步更新，这对测试人员来说是一大挑战，测试人员常常就是整个测试脚本再重新录製一遍。
以下為Mercury WinRunner测试脚本的范例
在2001年开始了第三代的自动化测试称為「测试框架（test framework）」，主要是把测试脚本给抽象化（abstraction）（註：如Keyword-Driven Test），让非技术人员（如系统分析师、使用者等）即使不懂测试脚本，不会写程式的情况下，也可以使用自动化测试工具建立自动化测试个案。
举个 Mercury QuickTest Professional Keyword-Driven Test的测试脚本為例子，测试人员不管是录製、编辑或是看到的测试脚本都是以「click the “OK” button」这样的关键字所呈现的。
「测试框架」确实是增加了测试团队的生產力，但是还是有些缺点：
＊ 以Keyword方式建立的测试脚本还是在测试步骤的层次，当设计一个复杂的商业流程测试个案可能还是需要大量的Keyword。对测试人员而言还是需要耗费大量的时间。
＊ 「测试框架」对於测试人员而言，只是测试脚本长得不再像是程式原始码，而像是在Excel中填入Keyword罢了，其实还是在写测试脚本。
＊ 支援「测试框架」的自动化测试工具通常与之前的测试工具做法不同，例如不提供录製的功能，而限制了其弹性。再者，测试人员在使用这类工具时也常常不知其所以然，在不瞭解内部的运作下，很难对Keyword做客製化。
＊ 「测试框架」即使已经被抽象化了，但是其层次还是停留在「步骤」的层次，尚未提升到「业务流程」的层次，迫使测试人员在建立测试脚本时，还是需要以「程式人员」的思考方式建立测试脚本，而不是以「业务人员」的角度来建立测试脚本。
＊ 「测试框架」的测试脚本没有与测试文件建立关联性，测试人员还是需要花费大量的工时在建立与维护测试文件的工作上。
从上面的问题，可以看出「测试框架」这样的方式，对於具备技术背景的测试人员也许还 OK，但是对没有技术背景的测试人员如（业务人员或是使用者），还是有其使用上的困难。
Mercury Business Process Testing – 是一种转变而非一种新技术
Mercury很快地意识到这些挑战，并非只有单单改进第三代自动化测试工具就能解决，需要的是一个全新的方式。所以从测试脚本的设计、自动化、维护以及文件化做一个全面且根本的进化，进而发展出第四代的自动化测试工具「Mercury Business Process Testing」 。
相较於Keyword-Driven Testing，Business Process Testing的抽象化层次更高，到达了「业务流程」的层次。
以下的例子可以看出一个有登入动作的测试个案，使用Keyword-Driven Testing的方式，至少需要4个步骤：开啟应用程式登入视窗、输入帐号、输入密码、按下OK按钮来完成登入的动作。但是以Business Process Testing的方式，登入的动作就成為一个可以接受以帐号、密码為参数而且可以重复使用的业务流程元件。
Business Process Testing的优点
使用Business Process Testing的自动化测试主要有以下的优点：
* 透过非技术性、元件化、以业务流程层次的方式设计测试个案，让业务人员以及一般使用者也可以参与自动化测试的工作。
* 业务元件可以被不同的测试个案所使用，加快建立自动化测试脚本的时间，并降低维护的成本。
* 建立或维护测试脚本时也会同时更新测试个案文件，大大缩短维护测试文件的时间。
如何Mercury Business Process Testing
Business Process Testing需要Mercury Quality Center与QuickTest Professional配合才能运作。同时测试团队中也需要二种角色，一是熟悉QuickTest Professional测试工具的人员（Automation Engineer），负责建立并维护Application Area、物件库（object repository）、library files、recovery scenarios，另外也需要负责对Business Component进行除错的工作；另一是非常熟悉业务流程的人员（Subject Matter Expert），透过Quality Center介面，设计Business Component以及Business Process Test并运用Application Area将其自动化。
使用Business Process Test的流程如下：
建立Business Component
首先建立一个名為Login的Business Component，并且填入相关资讯，如Summary、Pre-Condition、Post-Condition，让想要使用此Business Component的人员知道其目的、用途以及使用条件与限制。
输入测试步骤
点选上方的Design Steps，开始输入测试步骤，含Step Name、Descrīption、Expected Result。
点选New Step将其餘的测试步骤也一併输入，最后可以看到此Busniess Component的执行步骤如下。
建立Business Process Test
点选Mercury Quality Center的Test Plan，建立一个名為「预定机位」的Business Process Test。
输入此测试个案的描述。
将Business Component加入Business Process Test中
在Test scrīpt点选Select Component，将刚刚建立的Busniess Component依序以滑鼠拖拉到中间的区块。此Business Process Test由Login、Create Order、Update Order、Logout 4个Business Component所组成。
将Business Component自动化
再回到Business Components将其转成自动化测试脚本，在Design Steps点选QuickTest Keyword-Driven，将此Business Components转成QuickTest Keyword-Driven类型的测试脚本。Business Components支援三种类型的脚本：QuickTest Keyword-Driven、QuickTest scrīpted、WinRunner。
转成QuickTest Keyword-Driven脚本后，点选Automation就可以看到其Keyword-Driven的脚本，目前都还是ManualStep。
选择Application Area。这个Application Area内含测试物件（Test Object）、Keyword steps、函式库等等。
将Keyword-Driven步骤加入Business Component中
直接在Keyword View上透过选取Item、Operation、输入Value的方式建立Keyword-Driven脚本。
第一个步骤為执行Flight Reservation程式，在Item栏位就不是选取Test Object，而是选取Operation，然后在Operation栏位选择OpenApp表示此步骤是要执行一个程式，同时在Value栏位输入这个程式的路径，这样第一个步骤就完成了。
Item选取Login Diaglog的Test Object，然后在Operation选取Activate，表示此步骤為开啟登入视窗，Value栏位则不需要输入任何值。
选取AgentName的EditBox，Operation则是Set，表示要在Agent Name这个EditBox输入资料，至於要输入什麼资料就直接输入在Value栏位中。
在Value栏位输入mercury。
以相同的方式加入其他的步骤，完成后整个Business Component的执行脚本如下。
TAG:
标题搜索
日历
|
|||||||||
| 日 | 一 | 二 | 三 | 四 | 五 | 六 | |||
| 1 | 2 | ||||||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 | |||
| 10 | 11 | 12 | 13 | 14 | 15 | 16 | |||
| 17 | 18 | 19 | 20 | 21 | 22 | 23 | |||
| 24 | 25 | 26 | 27 | 28 | 29 | 30 | |||
| 31 | |||||||||
我的存档
数据统计
- 访问量: 45133
- 日志数: 57
- 文件数: 4
- 书签数: 1
- 建立时间: 2007-08-24
- 更新时间: 2011-12-23
