QTester-Web自动化测试工具-高清观看-腾讯视频
QTester-Web自动化测试工具
扫描二维码随身看视频
用手机或平板摄像头拍下右侧的二维码，您可以：
1 在手机或平板上继续观看该视频
2 分享给你的微信好友或者朋友圈
视频上传者
上传视频数1
好莱坞影院推荐
徐老怪携众明星打响剿匪大战
爱他或恨他就送他去文艺圈
下载手机APP论文发表、论文指导
周一至周五
9：00&22：00
一种简化自动化测试脚本编写维护的应用方法
&&&&&&本期共收录文章18篇
　　【摘 要】软件自动化测试技术的出现，大大减轻了软件测试人员的测试压力，显著提高了测试工作效率，但是自动化测试脚本的编写和维护也是测试自动化所面临的一项挑战。针对自动化测试脚本编写和维护耗时、自动化测试开展门槛高等问题，提出了一种简化自动化测试脚本编写维护的应用方法，从而有效地降低了使用门槛，提升了测试脚本编写维护效率。 中国论文网 /8/view-4203387.htm　　【关键词】自动化测试 脚本 维护 　　中图分类号：TP309 文献标识码：A 文章编号：（2013）-08-0058-06 　　1 引言 　　随着软件产品在各个应用领域的普及，软件的质量问题正逐渐成为人们关注的焦点。软件测试是提高软件产品质量和可靠性的关键。而软件测试的自动化技术通过代替频繁重复的手工测试可以帮助软件的开发人员和测试人员在更短的时间内开发出更高质量的产品。因此，对于自动化测试技术的研究是具有实际意义的。 　　本文结合自动化测试框架、测试用例生成、测试用例管理维护等技术，探索了一个面向行业应用的自动化测试用例、脚本简单编写、维护的管理方法，很好地解决了现阶段自动化测试中常见的脚本维护成本高、无法持续性开展的难题。 　　2 自动化测试流程 　　2.1 自动化测试 　　自动化测试就是把以人为驱动的测试行为转化为机器执行的一种过程，即通过自动化测试工具或者其它手段，按照我们预定的计划进行自动测试的活动[1]。它是软件测试的一个重要组成部分，能够完成许多手工无法完成或者难以实现的一些测试工作。正确、合理地开展自动化测试实施，能够增强测试的稳定性和可靠性，提高软件测试的准确度和精确度，从而提高软件质量、节省测试人力及资源投入，缩短软件产品发布周期，让产品更快投放市场。 　　2.2 自动化测试流程 　　自动化测试流程主要用来指导自动化测试过程，如图1所示。其主要步骤为： 　　（1）制定测试计划：明确测试对象、测试目的、测试的项目内容、测试的方法、测试的进度要求，并确保测试的人力、硬件和数据资源都准备充分； 　　（2）分析测试需求：用例设计者根据测试计划和需求说明书，分析测试需求，设计测试需求书，以便用例设计时能够覆盖所有的需求点； 　　（3）设计测试用例：通过分析测试需求，设计出能够覆盖所有需求点的测试用例，形成专门的测试用例文档。由于不是所有的测试用例都能用自动化来执行，所以需要将能够执行自动化测试的用例汇总成自动化测试用例； 　　（4）搭建测试环境：在用例设计的同时可以开始搭建测试环境，包括被测环境的部署、测试硬件的调用、测试工具的安装部署、网络环境的部署等； 　　（5）编写测试脚本：根据自动化测试用例和问题的难易程度，采取适当的脚本开发方法编写测试脚本。脚本编写完成后需要反复执行，不断调试，直到运行正常为止。脚本的编写和命名要符合管理规范，以便统一管理和维护； 　　（6）分析测试结果、记录测试问题：及时分析自动化测试结果，以便尽早地发现缺陷； 　　（7）跟踪测试BUG：测试记录中的BUG记录到缺陷管理工具中，定期跟踪回归。 　　3 现有自动化测试持续开展困局 　　现阶段，由于行业应用系统越来越多，且版本升级越来越频繁（如常见的CRM系统、ERP系统等），而现有的测试人力相对匮乏，无法保证每次上线的系统得到充分、全面的测试，从而无法很好地保证系统质量，导致软件上线后出现很多问题。鉴于此，很多企业已经开始引入自动化测试，寄希望于自动化测试的开展能够缓解上述困境。 　　众所周知，自动化测试的实施是需要成本的，创建一次自动化测试所花费的时间比一次手工测试所花费的时间要多的多，所以如果为了自动化而自动化，在不适合的场景中盲目开展自动化测试，最后的结果只能是事倍功半。自动化测试的效果只能体现在测试脚本成百上千次地被使用，而这即是自动化测试的持续开展。 　　为了达到自动化测试持续开展，确保自动化测试实施的效果，需要以下两个必要条件： 　　（1）尽可能保证被测系统的稳定性，但这个往往很难实现，如每一次CRM系统版本上线时业务流程都会有或多或少的变化。 　　（2）要保证能够在被测系统出现变动时及时准确地修改上次的测试脚本，将其更新至符合这次测试的状态。相对而言，这个条件往往在测试中更为实际。但是，现阶段常见的问题是被测系统业务变动了，相对应的测试脚本却无法在规定时间内及时更新。很多企业开展自动化测试实施最后无疾而终，其关键原因就在于脚本更新无法满足测试时间的要求，因为从拿到系统业务变动到修改测试脚本至最后上线测试，留给自动化测试人员的时间窗口往往只有短短的2～3天。究其原因，无非是测试脚本修改或者更新过于复杂，对于测试人员有较高的开发技能要求。以现在业界常见的自动化测试工具RFT和QTP为例，测试脚本分别是基于Java语言和VBScript语言编写，测试人员在编写、修改测试脚本时都需要相应语言的开发技能。同时，因为程序语言自身的复杂性，即使是具备相关技能的人员在修改测试脚本时也都需要花费较长的时间，这也就导致了在短时间内更新大量测试脚本成为无法完成的任务。 　　自动化测试持续开展困难，脚本维护成本太高，并且随着测试脚本的持续增多，缺乏有效规范的管理，导致上线测试环节出现有些脚本在执行过程中被遗忘，这就是现在多数企业开展自动化测试的现状，也是现阶段自动化测试大规模使用所面临的最大问题。 　　4 可持续开展的自动化测试解决方案 　　4.1 简单易用的自动化测试理念 　　针对自动化测试持续开展面临的最大难题，笔者认为应该从测试脚本出发，最大程度地简化测试脚本编写、维护工作。具体可以从两个方面来考虑： 　　（1）降低测试脚本编写的技能要求，最好是不具备开发能力的普通测试人员也可以编写测试脚本，可以按业务变化修改测试脚本； 　　（2）简化测试脚本维护工作，取消或减少脚本录制工作，测试脚本尽量原子化，改动一处不会导致整个测试脚本都需要修改。 　　自动化测试实施过程中，核心其实就是测试脚本的编辑、执行，只有处理好了自动化测试脚本的编写、维护环节，自动化测试才可能持续开展，真正起到节省测试人力，提升测试覆盖率的作用。 　　4.2 新一代自动化测试框架 　　基于上述简单易用的自动化测试理念，笔者团队将注意力集中在了简化测试脚本编写、维护环节上，自主设计并开发出了与现在业界常见自动化测试框架不同[2]的新一代自动化测试框架。如图2所示： 　　该框架主要特性是灵活、易用：首先是测试用例编写、维护灵活，测试用例原子化、复用程度高，这个特性主要表现为测试用例的编写维护既可以在前台页面通过元素拖拽完成，也可以通过Excel编写修改完成。其次是该框架使用门槛低，使用人员只需要关注测试用例编写，不需要具备专业编程技能也能很好地完成自动化测试工作[3]，这个特性主要表现为框架对于使用人员屏蔽了测试脚本的概念，使用人员在该框架上开展自动化测试时只需要关注测试用例的编写及更新即可，即学即会。 　　4.3 测试框架工作原理解析 　　通过使用新一代自动化测试框架开展自动化测试可以很好地解决上述的问题，真正可持续常态化开展测试工作。下面笔者将大致介绍它的工作原理：该框架之所以具有灵活、易用的特点，其主要原因是笔者团队在框架开发初期就花费大量精力用于用例解析引擎和框架文件的设计，确保自动化测试用例的编写、维护简单、灵活、易用。 　　用例解析引擎是整个框架的核心，主要负责将框架文件中的测试用例自动解析，转化为可执行的测试脚本。与常见自动化测试过程往往会受制于工具提供的控制逻辑相比，笔者团队另辟蹊径在测试用例设计阶段只按照测试需求编写符合人类使用习惯的易懂、便于修改的测试用例，执行阶段才依靠用例解析引擎将其转化为适合自动化测试工具使用的测试脚本。具体解析过程如图3所示，用例解析引擎通过查找测试用例中编写的测试操作对象、操作行为和操作数据将其组合转化为测试脚本。 　　因为事先不受制于具体的测试脚本语言，所以新一代自动化测试框架中的所有测试用例都具有易理解、容易编写的特点。同时，用例解析引擎在开展用例解析的时候是以“操作步骤”为一个控制单元，这和常见的自动化测试过程中以一个“业务流程”为控制单元又有很大的区别。毫无疑问，“操作步骤”当然更比“业务流程”单位更小，所以在测试用例因为业务变动需要修改或更新时自然会更灵活、更简单，从而最大程度地减少了测试人员对测试用例和脚本维护的工作量，保证了在小时间窗口内按需要更新完大量测试用例，使自动化测试可以常态化持续开展。 　　另一个重要技术就是框架文件的使用[4]。在新一代自动化测试框架中使用的框架文件是一个Excel表，通过不同的部分来进行框架执行的控制和测试用例、操作数据的分别存储。它的使用方便了测试用例的编写、维护与更新。在下面的实例分析中笔者将对框架文件的具体使用再进行介绍。 　　5 实例分析 　　为了更好地阐述新一代自动化测试框架的工作原理，笔者选取了前段时间开展的自动化测试冒烟测试中的一个测试用例——系统管理员登录来进行分析。 　　第一步是使用框架文件开展测试用例的编写，如表1所示。 　　表1中可见，系统管理员登录用例共有7个步骤，其中涉及了closeAllBrowsers、wait、setText等关键词操作，这些关键词都是在自动化测试框架中预先封装完成的，待测试用例编写中可以直接选用，应该说在使用框架时除了极少数生僻的操作命令外大多数操作命令已经被全部覆盖，测试人员使用还是极其简单的。在对象类型列可以看到，针对不同的类型如Text、Password、Button也是在框架中预先封装好的，针对每一类对象都会有单独的命令操作。 　　正是笔者团队在前期做了大量开发、封装的工作，才使测试用例编写变得简单、门槛降低，使用该框架的人员只要会使用Excel即可，不再需要专业的Java、VBScript开发、编程技能。 　　由于框架文件的组织形式非常清晰，当业务流程变化时，比如在系统管理员登录中，除了需要输入用户名、密码外还需要增加使用工号进行验证时，只需要在步骤4和5之间增加一步即可完成，测试用例的其余部分不需要改变，后续只要直接使用用例解析引擎即可把刚才做的改动自动同步到测试脚本中去。正是这个特性才使得使用新一代自动化测试框架无论是和原始的自动化测试录屏操作相比，还是和直接针对特定自动化测试工具编写测试脚本相比，测试用例维护的工作量都得到极大的缩减。 　　第二步是将编写的测试用例导入到新一代自动化测试框架中，如图4所示。 　　图4中可见，左边用例实现框内即是测试用例导入测试框架后的系统展示，右边对象地图框内是该测试用例涉及的操作对象。在新一代自动化测试框架中，测试用例编写除之前提到的使用Excel外，也可以直接在框架上通过拖拽完成（即从右边对象地图框内选择对象拖拽至左边用例实现框内，加入必要的操作关键词如CloseAllBrowsers、wait等完成用例编写）。而无论是使用Excel来进行测试用例编写还是直接在测试框架内通过拖拽操作完成，都简单、易用。在新一代自动化测试框架中，使用人员从头至尾都不需要直接编写、维护和管理测试脚本，测试脚本的生成由用例解析引擎自动在后台完成。这也就达到了自动化测试理念中提出的不具备开发能力的普通测试人员也可以编写测试脚本，可以按业务变化修改测试脚本的要求。 　　至于由用例解析引擎自动生成的测试脚本则以Java文件（实例中使用的自动化测试工具为IBM RFT）保存在后台的特定目录下，如图5所示。 　　可以看到，在图5中笔者之前通过Excel编写的测试用例被完整地转化为一段Java代码的测试脚本，图中红色箭头标示出的部分即对应测试用例中的每一步骤。 　　在测试用例导入新一代自动化测试框架后，用例执行引擎将其解析转换为测试脚本，通过框架集成的自动化测试工具按调度执行测试脚本，最后在框架上可以直观地看到测试结果并自动生成测试报告，如图6所示。 　　通过实例可以看出，新一代自动化测试框架中使用测试用例编写、维护方法很好地简化了测试用例编写工作，降低了自动化测试开展门槛，保证了自动化测试在实际生产环节中常态化可持续开展。 　　6 结论 　　自动化测试方法的应用大大提高了软件测试工作的效率，尤其在回归测试中，把一些重复的、机械的测试任务交给计算机去做，很大程度上减轻了测试人员的压力，并通过增加测试覆盖率等方式一定程度上提高了回归测试的准确性。当然，它也有其自身的不足，如不能很好地发现软件新出现的问题，也不能根据实际情况及时调整测试流程，且自动化测试脚本编写和维护工作也是一项比较繁杂的工作。本文就自动化测试常态化持续开展难、自动化测试使用门槛高等问题提出了一种基于新一代自动化测试框架的测试用例编写方法，可以很好地降低自动化测试使用门槛，且大幅度减少测试用例、测试脚本的编写和维护时间，从根本上保证了自动化测试可以常态化可持续开展。 　　参考文献： 　　[1] 文昌辞，王昭卿. 软件测试自动化静态分析研究[J]. 计算机工程与设计， ）： 987-989. 　　[2] 邓正宏，高逦，郑玉山. 面象对象自动化测试框架的研究与设计[J]. 微电子与计算机， 2005（2）： 168-171. 　　[3] Mosley D J， Posey B A. Just Enough Software Test Automation [M]. 邓波，黄丽娟，曹青春，译. 北京： 机械工业出版社， 2003. 　　[4] 刘晓丹，武君胜，刘博. 基于数据驱动的自动化测试平台设计[J]. 科学技术与工程， ）： 779-782.★
转载请注明来源。原文地址：
【xzbu】郑重声明：本网站资源、信息来源于网络，完全免费共享，仅供学习和研究使用，版权和著作权归原作者所有，如有不愿意被转载的情况，请通知我们删除已转载的信息。
xzbu发布此信息目的在于传播更多信息，与本网站立场无关。xzbu不保证该信息（包括但不限于文字、数据及图表）准确性、真实性、完整性等。 下载
 收藏
该文档贡献者很忙，什么也没留下。
 下载此文档
正在努力加载中...
一种面向动态网页的Web应用测试用例生成的方法
下载积分：1998
内容提示：
文档格式：PDF|
浏览次数：7|
上传日期： 13:56:38|
文档星级：
该用户还上传了这些文档
下载文档:一种面向动态网页的Web应用测试用例生成的方法.PDF
官方公共微信482,381 二月 独立访问用户
您目前处于：
敏捷自动化测试（2）——像用户使用软件一样享受自动化测试
敏捷自动化测试（2）——像用户使用软件一样享受自动化测试
相关厂商内容
相关赞助商
全球软件开发大会，4月23-25日，北京，！
UI组件库的广泛采用在提高开发效率的同时，也极大的提升了用户体验。基于UI组件库之所以能快速开发出功能强大的页面，是因为UI组件库可以自动生成海量、结构类似的HTML源码（如下图）：
开发人员是幸福的，因为这一切对于他来说完全透明。于是只剩下自动化测试人员独自面对这样&恐怖&的页面源码。
如前文&&中所言，业界常见测试工具的脚本本质上还是针对页面源码的，因此原本就举步维艰的自动化测试在开发使用UI组件库之后变得雪上加霜：
页面DOM结构非常复杂
导致所录制/编写脚本的复杂度变的更大、可读性变得更差。
UI框架的升级很可能会导致DOM结构的变化
因此即使开发人员没对代码做任何改动，测试脚本也会因为UI框架的升级变得无法回放。
控件ID是自动生成的，甚至在每次刷新页面后都会变化
大部分自动化测试工具在&录制&脚本时，都会优先使用ID定位策略，自动生成的ID会导致这种关键的控件定位策略变得无效。
UI框架在各种浏览器下自动生成页面源码可能不完全相同
为了在不同浏览器下&看起来一样&，实际的DOM结构有时也可能是不同的，因此所录制脚本的浏览器兼容性会比较差。
技术的发展是为了让生活变得越来越轻松。从用户的角度来看确实如此：Web应用的功能覆盖范围越来越广、操作越来越方便、界面越来越美观。
为什么自动化测试人员没有感觉工作变得轻松呢？
要回答这个问题，首先要分析&用户使用软件&与&自动化测试软件&之间的一些重要差异：
用户使用软件时只关注界面上能&看&到的，而不用总是&查看页面源码&；
用户会更关注整体业务的正确性、稳定性，而不仅仅是每个孤立页面功能的正确性；
用户对页面样式、响应时间、浏览器兼容性要求越来越高； 如果我们能像用户使用软件一样进行自动化测试，测试就会变得更敏捷：
根据界面快速编写测试脚本：敏捷应对需求的变化；
降低对技术实现（UI框架、页面样式/布局）的依赖：敏捷应对设计/开发的变化；
测试脚本可以稳定支持各种浏览器：敏捷应对环境的变化；
（一）根据界面快速编写测试脚本的实现思路
还是以前文&&中用到的&用户增加&界面为例:
如果你是作为用户在使用上述功能时，心里一定也会默念下面内容吧：
&账号&输入***、&密码&输入***、&姓名&输入***、&性别&选择***、&生日&输入***、&国籍&选择***，点击&保存&按钮。
这就可以理解为&根据界面编写的测试脚本&。
我们在使用Web应用时，心里常常默念的还包括：&展开/收拢/选中&树（Tree）的某个节点、数据表格（Grid）的下一页/上一页、选中数据表格（Grid）的某一行、点击/关闭某个Tab页，等等。
很多人在与笔者交流的过程中都会问&为什么还要手工编写脚本，怎么不提供脚本录制工具呢？&
因此在这里想澄清一下大家对&编写&脚本的误解，与传统自动化测试工具相比，&此脚本&非&彼脚本&。
传统的测试脚本是给特定测试工具执行时使用的，对人类而言可读性极差，更别谈手工编写了，因此&录制/回放&工具往往都是必备组件。即便如此，此类&录制/回放&工具的实际使用效果，也是不尽如人意的。
从这种角度来看，&录制&脚本是&下策&，&上策&应该是让测试脚本大幅简化，并且具备良好的可读性和可维护性，以达到人工编写很容易的程度。
&&以上只是笔者的一点差异化见解，对业界优秀的测试工具没有任何冒犯之意！
（二）降低测试脚本对技术实现依赖度的实现思路
Web页面开发中的技术实现细节主要包括UI框架的选择及版本升级、页面样式设计、页面布局设计，因此我们的主要目标就是降低测试脚本对这些因素的依赖。
为了便于测试脚本的解析和组织管理，目前还不能直接写形如&点击(保存)按钮&这样的纯自然语言，但可以设计成接近自然语言的领域专用语言（DSL:Domain Specific Language），本文采用XML来实现这种DSL。比如：
&event id=&[button]保存& name=&click&/&
这种超级清晰、简短的测试脚本与实际海量的页面源码之间有一条鸿沟，我们可以通过&封装&来屏蔽。下面以的Button控件为例来示意如何完成这种封装：
Button的界面展现如下：
实际生成的页面源码DOM结构如下（省略部分非关键属性）：
&div id=&button-1032& class=&x-btn x-box-item x-btn-default-small
x-noicon x-btn-noicon &
&em id=&button-1032-btnWrap&&
&button id=&button-1032-btnEl& class=&x-btn-center&
autocomplete=&off& role=&button&&
&span id=&button-1032-btnInnerEl&&Cancel
&span id=&button-1032-btnIconEl& class=&x-btn-icon &/&
我们封装所要做的主要工作就是解析出测试脚本中定义的关键信息（button、保存、click），结合对应页面源码的DOM结构，翻译成W3C标准的定位方式（如，XPath）。通过XPath就可以定位到页面上的任何控件。
对于测试脚本（&event id=&[button]Cancel& name=&click&/&），翻译后的XPath可以是（//button/span[text()='Cancel']）。
同理，其它测试脚本还可以包括：
树节点展开/关闭
&event id=&[treeNode]部门& name=&open&/&
&event id=&[treeNode]部门& name=&close&/&
&event id=&[grid]人员列表& name=&nextPage&/&
它们的封装实现比Button稍微复杂一些，但原理是一样的。
（三）增强测试脚本浏览器兼容性的实现思路
这个就比较简单了，只要选用标准化程度高、厂商支持度高、扩展性强的第三方底层实现即可，笔者推荐采用。
通过上面的介绍，有些读者或许会有个疑问：&如果一个Web应用没有采用任何UI框架、而且编码又极为不规范，那么你这种方案岂不就不适用了？&
答案是肯定的。但笔者认为此类Web应用如果想要发展下去，其瓶颈还停留在开发环节，对其进行自动化回归测试的投入产出比不是很大。
此外，为了进一步提高Web应用的可测试性，笔者在实际工作中总结了一些前台页面开发的最佳实践，供大家参考：
页面采用单帧实现
如果页面上的frame/iframe嵌套很多的话，控件的定位会比较麻烦，并且影响展现速度。
兼容Firefox
Firefox有很多强大插件，如Firebug、FirePath，非常有助于在开发、测试过程中的调试问题。
采用统一的UI框架开发复杂控件
对于复杂控件，比如Tree、Grid，如果不基于统一的UI框架实现，开发、测试工作量都会很大。
对于需要设置ID的控件，一定要设置唯一、并且有业务意义的ID
当然对于一般不需要设置ID的控件（如，div）或者控件ID由UI框架自动生成的情况除外。
对于Form中最常见的label+input组合，尽量让label和input有逻辑对应关系
推荐为label设置for属性，属性值等于input的id，这样对最终用户也比较友好：双击label的时候，鼠标焦点能定位到对应的input中。
页面设计时考虑用户体验，往往用户使用方便的时候，自动化测试也会方便
比如，一个页面上不要有多个同名的按钮、通过点击上下微调按钮（箭头）改变输入域值的控件也支持直接输入值、日期选择控件支持用户直接输入、下拉列表控件支持输入过滤，等等
对以上几点最佳实践有如下补充说明：
这些最佳实践不仅能提高Web UI的可测试性，也非常有助于提升用户体验；
这些最佳实践如果能满足更好，即使不能全部满足，也可以开展自动化测试；
按照本文给出的方案，前文&&中用到的&用户管理（增加、删除）&功能的自动化测试脚本就可以改造为如下样式（示意代码）：
&event id=&[button]新增& name=&click&/&
&event id=&[input]帐号& name=&setValue& value=&${account}&/&
&event id=&[input]密码& name=&setValue& value=&1&/&
&event id=&[input]姓名& name=&setValue& value=&${accountName}&/&
&event id=&[input]性别& name=&select& value=&女&/&
&event id=&[input]生日& name=&setDate& value=&&/&
&event id=&[input ]国籍& name=&select& value=&中国&/&
&event id=&[button]保存& name=&click&/&
&event id=&[gridRow]${account}& name=&assertExist&/&
&event id=&[gridRow]${account}& name=&check&/&
&event id=&[button]删除& name=&click&/&
&event id=&[ gridRow]${ account }& name=&assertNotExist&/&
以上测试脚本完全基于界面上&可见&的内容进行编写，大家应该不需要看下面的解读，也能明白脚本的意思：
第1、8、11行表示点击&新增&、&保存&、&删除&按钮；
第2~7行表示为输入域赋值，赋值方式有输入文本、输入日期、选择下拉选项；
第10行表示选中表格中的指定行，即，选中指定行前面的Radio按钮；
第9、12行表示断言表格中指定的行&存在&或&不存在&；
${ account }表示使用外部的变量account；
自动化测试中最关键的两部分是&脚本&和&断言&。至此，自动化测试脚本的编写、维护以及执行已经可以跟上敏捷开发的步伐了。本系列的下一篇文章会就&如何让断言不再成为自动化测试的负担&这个话题来分享一些实践经验，敬请关注！
殷坤，东软集团资深测试经理、技术讲师，10年软件研发、实施、测试及项目管理工作经验。 目前专注于敏捷项目管理及质量控制、过程改善、自动化测试、持续集成、用户体验提升等方面。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（）或者腾讯微博（）关注我们，并与我们的编辑和其他读者朋友交流。
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
Re: 关键字驱动？？
我们公司也是这种思路
Re: 关键字驱动？？
Re: 我们公司也是这种思路
Re: 我们公司也是这种思路
Re: 我们公司也是这种思路
Re: 我们公司也是这种思路
框架的开发不轻松
其实和敏捷没什么关系
Re: 其实和敏捷没什么关系
Re: 框架的开发不轻松
如果要校验数据库怎么办呢？
Re: 如果要校验数据库怎么办呢？
没啥真正有用的内容啊
Re: 没啥真正有用的内容啊
Wang Jensen
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Micha? Bartyzel
Ben Linders
Mike Amundsen
占超群（离哲）
朱照远（叔度）
Matt McLarty
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7