模板
教程
环境
性能
功能
管理
自动测试之关键字驱动测试模式初探
曾经在“我看测试”这篇文章中论述过，“测试效率的提高关键是测试手段的改进”。尤其在软件测试领域，没有千遍一律的测试方法，别人都说好的商业工具拿到你产品线来却未必合适。没有最好只有更好，如何才能产出符合淘宝框架的特色测试工具呢?之前在入淘宝之初，对淘宝架构、测试工具不甚熟悉的情况下，提出过《基于TTCN-3的Web应用自动化测试框架》一文，但却与淘宝现有的测试工具不相符合。随着对淘宝环境逐渐熟悉，一直都在思考改进测试的方法，这种方法一定要以现在使用的ITEST为基础，在经过不断地实践摸索以后，结合自己的经验，提出以下测试理论，望大家参详。
一、概念提出
在阐述我的观点之前，先来看看下面的例子。
在ITEST中，订购一个套餐的用例代码如下所示：
/*****************************************代码分割线*****************************************/
public class PlanSubTest extends BaseCase{
final static String NICK= "leizang_test";
final static String PASS_WORD= "taobao1234";
@BeforeClass
public static void login(){
command.login(LOGIN_URL, NICK, PASS_WORD);
}
@AfterClass
public static void loginOut(){
command.loginOut();
}
@Before
public void cleanDB(){
String nick= NICK;
command.dbExecute(
"DELETE FROM upp_sub_plan WHERE nick= '"+ nick+ "'",
"DELETE FROM upp_biz_order WHERE nick = '"+ nick+ "'",
"DELETE FROM upp_prod_subscription WHERE nick = '"+ nick+ "'");
}
@Test
public void test_planSub_雷藏_case01(){
logTestName();
//构造入参
SubOption subOption= new SubOption(getPlanSubUrl(827L), CycleEnum.HALF_YEAR, false);
//从页面订购
command.doSub(subOption);
//结果校验
Command.checkSubResult(subOption,
TableEnum.UPP_BIZ_ORDER,
TableEnum.UPP_SUB_PLAN,
TableEnum.UPP_PROD_SUBSCRIPTION);
}
}
/*****************************************代码分割线*****************************************/
好了，虽然例子比较简单，但足以说明问题。
“command”是在“BaseCase”中生成的一个静态的“遥控器”(姑且这么理解)：
“protected static ActionCommand command= new ActionCommandImpl(); “
它就像我们的电视遥控器，空调遥控器一样，一旦你拥有了它，你就可以发出遥控器所支持的各种指令。所以，下面就理所当然地发出了各种“登录”，“退出”，“清除数据库“，“订购”，“校验”等各种指令，而代码就会依照我们发出的指令去执行，这就是所谓“关键字驱动测试”理念。
二、测试建模
试想一下，现在呈现在你面前的是一个万能机器人，而操控这个机器人的“遥控器“就在你手中，你按下”做饭“键，它会去做饭，你按下”洗衣“键，它会遵照你的命令去洗衣服。但是”巧妇难为无米之炊“，更何况是个没有生命的机器人。你在发出”做饭“指令之前，需要事先给它准备好”米“和”水“，这样它才会按照你预期的要求去做。当它完成任务的时候你需要去检查看看它完成的如何，饭做熟了没有。按照这种思路，我们对”指挥机器人做饭“的任务进行分解：
<!--[if !supportLists]-->1) <!--[endif]-->准备米和水
<!--[if !supportLists]-->2) <!--[endif]-->发出做饭指令
<!--[if !supportLists]-->3) <!--[endif]-->检查饭做好了没有
当你把这些跟上面的测试代码联系起来思考的时候，你会发现这一切是惊人的相似。在你对套餐订购进行测试的时候，你需要做如下几件事情：
<!--[if !supportLists]-->1) <!--[endif]-->准备相关数据
<!--[if !supportLists]-->2) <!--[endif]-->发出订购指令
<!--[if !supportLists]-->3) <!--[endif]-->校验订购结果
我们在编写测试用例的时候，如果能够方便地准备“入参“、”预期“，然后发出指令，代码就能自动地完成测试工作那该多好啊!
那如何才能实现我们这一套方便、智能系统呢?
聪明的你可能已经发现，要想达成愿望，关键在于解决以下三个难点：
<!--[if !supportLists]-->1) <!--[endif]-->相关数据准备方便(用户关心)
<!--[if !supportLists]-->2) <!--[endif]-->要有一个好的遥控器(用户不关心，制造商的事情)
<!--[if !supportLists]-->3) <!--[endif]-->要有一个能正确完成指令的机器人(用户不关心，制造商的事情)
这里存在对应关系：
用户 ——>自动化用例编写者
制造商——>测试框架搭建人员
我们先来解决制造商的两个困扰。
<!--[if !supportLists]-->1、 <!--[endif]-->制造商困扰之一——遥控器问题
遥控器就是一个各种指令的集合。在这里涉及一个问题，“如何划分指令的粒度?”
