<?xml version="1.0" encoding="gb2312"?>
<rss version="2.0">
<channel>
<title>软件测试</title>
<link>http://www.kuqin.com/testing/</link>
<description>挖经验 / 软件测试</description>
<language>zh-cn</language>
<generator>Copyright &amp;copy; 2007-2008 &lt;A href=&quot;http://www.kuqin.com&quot;&gt;酷勤网&lt;/A&gt; All Rights Reserved
&lt;A href=&quot;http://www.miibeian.gov.cn/&quot; target=&quot;_blank&quot;&gt;京ICP备07011765号&lt;/A&gt;</generator>
<webmaster>kuqin.com@163.com</webmaster>
<item>
    <title>可用性测试中的受众细分</title>
    <link>http://www.kuqin.com/testing/20090626/59052.html</link>
    <description>原文：Audience&amp;nbsp;segmentation&amp;nbsp;recruiting&amp;nbsp;for&amp;nbsp;usability&amp;nbsp;tests
作者：Walt Buchan
译者：耿人杰&amp;nbsp;译文来自：http://gengrenjie.com/archives/607
引言：受众细分听的很多。在传统媒体领域，细分主要通过人口统计学指标，通过这个方法可</description>
    <pubDate>2009-06-26</pubDate>
    <category>软件测试</category>
    <author>Walt Buchan</author>
    <comments>耿人杰的网络日志</comments>
</item>
<item>
    <title>实用可用性测试</title>
    <link>http://www.kuqin.com/testing/20090626/58898.html</link>
    <description>5月份有幸参加了人因国际的实用可用性测试，主讲人是董建明博士，曾在IBM、Ebay等公司从事了10多年用研工作。目前国内用研行业尚在兴起阶段，很多大公司已相继成立相关的部门或开设专职，但论经验值几乎为零。大家都知道跟用户打交道是一门很高深的学问，除了靠知识、技</description>
    <pubDate>2009-06-26</pubDate>
    <category>软件测试</category>
    <author>丁香 </author>
    <comments>UED.Alimama.com</comments>
</item>
<item>
    <title>自动化的验收测试──是否只是纸上谈兵？</title>
    <link>http://www.kuqin.com/testing/20090609/55698.html</link>
    <description>编写需求并自动生成验收测试（有时候称作测试驱动需求，故事驱动开发，以及──要看你问的是谁── 行为驱动开发），在这方面已经有了零星的成功案例。然而社区中只有很少数的人这样用过。一些思想领袖公开声称这么做不好，浪费精力。每个迭代开始编写的自动化验收测试</description>
    <pubDate>2009-06-09</pubDate>
    <category>软件测试</category>
    <author>Amr Elssamadisy 译者 张晓庆</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>热衷敏捷测试的10大理由</title>
    <link>http://www.kuqin.com/testing/20090608/55559.html</link>
    <description>最近，Kay Johansen 提出问题“为什么你会热衷于敏捷测试？”收到的答案从严肃到诙谐，不一而足。

    不再需要手工测试脚本！ － 相反，自动运行的脚本让测试人员有更多的时间来挖掘测试。 
    开发人员喜欢我了！ － 迭代结束之前发现问题，而且因为开</description>
    <pubDate>2009-06-08</pubDate>
    <category>软件测试</category>
    <author>Mark Levison 译者 金明</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>Mock不是测试的银弹</title>
    <link>http://www.kuqin.com/testing/20090516/51565.html</link>
    <description>Mock不是测试的银弹，世上也并无银弹存在，测试实践能否正常开展的决定性因素是团队成员对测试流程，测试方法的不断改进而不是先进的测试框架。不要去依赖mock框架，它的强制约定常常是你改进设计和添加功能的绊脚石。</description>
    <pubDate>2009-05-16</pubDate>
    <category>软件测试</category>
    <author>胡凯</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>不要把Mock当作你的设计利器</title>
    <link>http://www.kuqin.com/testing/20090516/51564.html</link>
    <description>Mock Object的行为依赖风险。Mock Object的行为和真实对象的行为必须一致，这在你对真实对象进行重构的时候是很大的风险。即使当前Mock Object的行为和真实Object的行为完全一直，而且所有测试都覆盖到了，其结果也很可能是：代码一处修改，测试到处失败。</description>
    <pubDate>2009-05-16</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ThoughtWorks 李晓</comments>
</item>
<item>
    <title>使用JsUnit和JSMock的JavaScript测试驱动开发</title>
    <link>http://www.kuqin.com/testing/20090506/49945.html</link>
    <description>JsUnit是JavaScript的开源单元测试框架。它受到JUnit的启发，并完全用JavaScript编写。作为最流行的 JavaScript单元测试框架，它还提供了一些ant任务，使开发人员在持续集成服务器上构建时很容易运行测试套件。</description>
    <pubDate>2009-05-06</pubDate>
    <category>软件测试</category>
    <author>Dennis Byrne 译者 张晓庆</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>J.B. Rainsberger：“集成测试是个阴谋”</title>
    <link>http://www.kuqin.com/testing/20090506/49941.html</link>
    <description>他继续解释了为什么开发人员会经常在最后写出了过多的集成测试。他给出了一个场景，其中，一位开发人员（或团队）发现了某个缺陷似乎只能通过集成测试来找到，因此得出了这样的结论——“最好在各处都提供集成测试”——以便找到这样的缺陷。</description>
    <pubDate>2009-05-06</pubDate>
    <category>软件测试</category>
    <author>Mike Bria 译者 陈黎夫</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>测试用例输入数据的设计方法和测试用例设计方法</title>
    <link>http://www.kuqin.com/testing/20090505/49692.html</link>
    <description>测试用例的设计是一项复杂的测试工作，测试用例的设计方法需要考虑测试的目标，被测试软件的特性，测试者人力资源的技术和能力，测试组织形式，测试进度、测试成本等多个方面。</description>
    <pubDate>2009-05-05</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>软件测试的一些基本原则</title>
    <link>http://www.kuqin.com/testing/20090505/49691.html</link>
    <description>软件测试要尽早执行：本条主要想说明一个道理：测试需要贯穿整个软件的生命周期，缺陷修复成本随着各个阶段的靠后而上升。从平时的项目中也已经看出，需求阶段引入的bug不比设计开发阶段少，如何保证好需求的稳定有效已经至关重要。</description>
    <pubDate>2009-05-05</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>.NET Compact Framework下使用NUintLite进行单元测试</title>
    <link>http://www.kuqin.com/testing/20090505/49689.html</link>
    <description>NUintLite是简化版的NUnit，可以应用于.NET Compact Framework,Mono等平台。NUnitLite的Test Runner支持不同的输出，TextUI输出到文件，ConsoleUI输出到控制台(Console)，DebugUI输出Debug信息，新版本还支持TcpUI把结果输出通过TCP发送。</description>
    <pubDate>2009-05-05</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>Visual Studio 2008单元测试实践</title>
    <link>http://www.kuqin.com/testing/20090505/49688.html</link>
    <description>单元测试中，测试的代码不能对被测试的代码施加影响。如果将测试代码写入被测试的代码中，测试完成后再删除的话，测试的正确性将得不到保证。因此，在Visual Studio 2008种提供了一种“Test Project”的项目，测试代码写在Test Project中，并且测试工程可以进行重复使用</description>
    <pubDate>2009-05-05</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>可用性测试的一些心得</title>
    <link>http://www.kuqin.com/testing/20090505/49656.html</link>
    <description>1. 先培训，再上岗，先了解游戏，再进行用研，专业知识结合游戏经验，才能和参与者更好的沟通；2. 避免专业术语，尽量让对方感到亲切，这一点同样适用于跨部门沟通；3. 做测试前，一定要团队人员填饱肚子，可用性测试是一件非常消耗体力和脑力的事情……</description>
    <pubDate>2009-05-05</pubDate>
    <category>软件测试</category>
    <author>Raymond</author>
    <comments>Raymond - 周全的交互设计</comments>
</item>
<item>
    <title>LoadRunner登录脚本认证失败</title>
    <link>http://www.kuqin.com/testing/20090504/49548.html</link>
    <description>发现Loadrunner参数化，是按照它内置的机制执行的，符合这个机制，编译就能通过。后来在Gen中的Tools—&gt;general option中找到了可以更改这个机制的地方，修改完了之后，脚本再次编译，这次OK了。</description>
    <pubDate>2009-05-04</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>关于淘宝网性能测试的思考</title>
    <link>http://www.kuqin.com/testing/20090504/49547.html</link>
    <description>一个超大型的电子商务网站，面对几亿的用户群体，在同一时间，使用用户数是不停变化的，且在同一时刻，即便用户在线，也可能点击浏览的是不同的页面，触发的是不同的请求。如果单从并发用户的角度去考虑问题，进行分析和建模，未必适用。</description>
    <pubDate>2009-05-04</pubDate>
    <category>软件测试</category>
    <author>悟石</author>
    <comments>Taobao QA Team</comments>
</item>
<item>
    <title>JUnit单元测试小记</title>
    <link>http://www.kuqin.com/testing/20090504/49546.html</link>
    <description>对于一些不规范的小公司也许产品的发布不经过测试，但是对于大型的软件开发的时候，这技术往往是必不可少的，因为任何一个小地方出错都可能是一个很难发现的，但是junit技术这个单元测试技术让我们能边开发边测试，使我们的最终产品出错的几率达到最少。</description>
    <pubDate>2009-05-04</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>ITPUB论坛</comments>
</item>
<item>
    <title>UI自动化测试与软件测试开发工程师所面临的挑战</title>
    <link>http://www.kuqin.com/testing/20090428/48649.html</link>
    <description>自动化测试对微软的产品来说，是保证其可以持续成功的重要技术；对于优秀的SDET来说，是一项必不可少的重要的技能；对于刚入职的工程师来说，亲身体验和研究自动化测试，特别是UI自动化，能够让你实现学生生涯到职业生涯的转变。 </description>
    <pubDate>2009-04-28</pubDate>
    <category>软件测试</category>
    <author>熊力</author>
    <comments>微软中国研发集团服务器与开发工具事业部</comments>
</item>
<item>
    <title>有效减少测试迭代次数之我见</title>
    <link>http://www.kuqin.com/testing/20090426/48240.html</link>
    <description>大家都知道缺陷被发现的越早，就越容易解决，成本就越低。所以在第一轮的测试过程中，尽量多的发现缺陷，尽量保证没有漏掉严重的缺陷，除了测试管理上的协助外，测试人员本身的水品和经验就至关重要。</description>
    <pubDate>2009-04-26</pubDate>
    <category>软件测试</category>
    <author>kuailederen</author>
    <comments>IT168</comments>
</item>
<item>
    <title>软件兼容性测试：不可能完成的任务？</title>
    <link>http://www.kuqin.com/testing/20090424/47798.html</link>
    <description>产品部领导想要了解我们产品（下面都用A产品指代）和其他产品（分别是B、C、D、E、F、G、H）对某主流软件的兼容性，于是公司需求组的同事制订了一份详细功能点列表，总数大约是1000多项，交给测试部门。</description>
    <pubDate>2009-04-24</pubDate>
    <category>软件测试</category>
    <author>Finger</author>
    <comments>新浪博客</comments>
</item>
<item>
    <title>.NET平台下Web测试工具横向比较</title>
    <link>http://www.kuqin.com/testing/20090414/45681.html</link>
    <description>对于使用.NET Framework的技术团队来说，Watir不一定是最好的选择。目前社区中已经出现了几款.NET平台下的Web测试框架，测试人员现在就可以使用自己最熟悉的语言来实现同样的功能，并与自己的开发环境无缝集成。</description>
    <pubDate>2009-04-14</pubDate>
    <category>软件测试</category>
    <author>赵劼</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之八 - 打造自己的单元测试框架</title>
    <link>http://www.kuqin.com/testing/20090413/45444.html</link>
    <description>本篇我们就尝试编写一个精简版本的C++单元测试框架：nancytest，nancytest是gtest非常的精简版本，所有直接看代码就可以完全理解。希望这个Demo能够起到抛砖引玉的作用，大家有兴趣可以去实现一个符合自己要求的C++单元测试框架。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之七 - 深入解析gtest</title>
    <link>http://www.kuqin.com/testing/20090413/45443.html</link>
    <description>本文通过分析TEST宏和RUN_ALL_TEST宏，了解到了整个gtest运作过程，可以说整个过程简洁而优美。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之六 - 运行参数</title>
    <link>http://www.kuqin.com/testing/20090413/45442.html</link>
    <description>使用gtest编写的测试案例通常本身就是一个可执行文件，因此运行起来非常方便。同时，gtest也为我们提供了一系列的运行参数（环境变量、命令行参数或代码里指定），使得我们可以对案例的执行进行一些有效的控制。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之五 - 死亡测试</title>
    <link>http://www.kuqin.com/testing/20090413/45441.html</link>
    <description>“死亡测试”名字比较恐怖，这里的“死亡”指的的是程序的崩溃。gtest的死亡测试能做到在一个安全的环境下执行崩溃的测试案例，同时又对崩溃结果进行验证。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之四 - 参数化</title>
    <link>http://www.kuqin.com/testing/20090413/45440.html</link>
    <description>gtest为我们提供的参数化测试的功能给我们的测试带来了极大的方便，使得我们可以写更少更优美的代码，完成多种参数类型的测试案例。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之三 - 事件机制</title>
    <link>http://www.kuqin.com/testing/20090413/45439.html</link>
    <description>gtest的事件一共有3种：1. 全局的，所有案例执行前后；2. TestSuite级别的，在某一批案例中第一个案例前，最后一个案例执行后；3. TestCae级别的，每个TestCase前后。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之二 - 断言</title>
    <link>http://www.kuqin.com/testing/20090413/45438.html</link>
    <description>本文主要总结gtest中的所有断言相关的宏。 gtest中，断言的宏可以理解为分为两类，一类是ASSERT系列，一类是EXPECT系列。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列之一 - 初识gtest</title>
    <link>http://www.kuqin.com/testing/20090413/45437.html</link>
    <description>本文介绍gtest的基本使用：1. 使用VS编译gtest.lib文件 ；2. 设置测试工程的属性；3. 使用TEST宏开始一个测试案例，使用EXPECT_*,ASSER_*系列设置检查点；4. 在Main函数中初始化环境，再使用RUN_ALL_TEST()宏运行测试案例。</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>玩转Google单元测试框架gtest系列</title>
    <link>http://www.kuqin.com/testing/20090413/45436.html</link>
    <description>Google测试框架是在不同平台上（Linux，Mac OS X，Windows，Cygwin，Windows CE和Symbian）为编写C++测试而生成的。它是基于xUnit架构的测试框架，支持自动发现测试，丰富的断言集，用户定义的断言，death测试，致命与非致命的失败……</description>
    <pubDate>2009-04-13</pubDate>
    <category>软件测试</category>
    <author>CoderZh</author>
    <comments>博客园</comments>
</item>
<item>
    <title>如何更高效的进行回归测试？</title>
    <link>http://www.kuqin.com/testing/20090327/43015.html</link>
    <description>全面用例回归测试的策略是最安全的策略，但已经运行过许多次的回归测试不太可能揭示新的错误，而且很多时候，由于时间、人员、设备和经费的原因，不允许选择再测试全部用例的回归测试策略，此时，可以选择适当的策略，进行缩减的回归测试。</description>
    <pubDate>2009-03-27</pubDate>
    <category>软件测试</category>
    <author>51Testing博客</author>
    <comments>IT168</comments>
</item>
<item>
    <title>单元测试工具 TCL/TK 与 C 程序的集成</title>
    <link>http://www.kuqin.com/testing/20090326/42579.html</link>
    <description>本文覆盖了TCL/TK脚本与C 集成的一些基础知识。编译选项部分描述了变量库并包含了建立程序的必要文件。 初始化与注册名令部分解释了怎样开始，怎样从TCL/TK脚本中调用C函数，最后一部分访问变量阐述了怎样来从C函数里来读与写TCL/TK变量。</description>
    <pubDate>2009-03-26</pubDate>
    <category>软件测试</category>
    <author>wangqi</author>
    <comments>新浪开发者博客</comments>
</item>
<item>
    <title>软件测试的若干问题</title>
    <link>http://www.kuqin.com/testing/20090320/41483.html</link>
    <description>并不是有了测试人员软件质量就有了保障。目前所有有测试人员的公司都或多或少的有一种倾向：有了测试人员那么质量就有保障了，这句话反过来理解就是，如果软件质量出了问题那么就是测试人员的问题。</description>
    <pubDate>2009-03-20</pubDate>
    <category>软件测试</category>
    <author>吴长安</author>
    <comments>51Testing软件测试网</comments>
</item>
<item>
    <title>你不知道的测试计划</title>
    <link>http://www.kuqin.com/testing/20090314/39835.html</link>
    <description>如果你是一个测试计划制定者或审阅者，你还是觉得测试计划如此而已的话，那你可以好好看看我的见解。</description>
    <pubDate>2009-03-14</pubDate>
    <category>软件测试</category>
    <author>Aaron Wu</author>
    <comments>博客园</comments>
</item>
<item>
    <title>软件测试的原则和经验</title>
    <link>http://www.kuqin.com/testing/20090314/39834.html</link>
    <description>在任何时候都不要表露出有了测试人员或者有了像你一样的测试人员，产品绝对没有任何问题了。这是在自己打自己的嘴，测试人员要给自己留个退路，要表露出谦虚的一面，“尽量少在用户使用时发现问题”，“我会竭尽全力做好测试工作”。</description>
    <pubDate>2009-03-14</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>51Testing</comments>
</item>
<item>
    <title>从“用断言检查null”到“设计单元测试”</title>
    <link>http://www.kuqin.com/testing/20090313/39710.html</link>
    <description>上个月Mi&amp;#353;ko Hevery写了一篇文章：断言，还是不断言，描述了在构造器中编写断言给单元测试所造成的种种不便。有不少人跟帖反对Mi&amp;#353;ko的观点，他们认为这根本不是断言的问题，而是来自于设计本身。</description>
    <pubDate>2009-03-13</pubDate>
    <category>软件测试</category>
    <author>李剑</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>编写可测试的程序</title>
    <link>http://www.kuqin.com/testing/20090305/38107.html</link>
    <description>自动测试与其说是测试的范畴，还不如说是设计的范畴。能不能自动测试，完全是由设计决定的，单元测试框架和gui测试工具的作用微乎其微。为设计良好的模块编写自动测试程序非常简单，要不要单元测试框架完全是个人偏好。</description>
    <pubDate>2009-03-05</pubDate>
    <category>软件测试</category>
    <author>李先静</author>
    <comments>The linux mobile development</comments>
</item>
<item>
    <title>对ASP.NET MVC项目中的视图做单元测试</title>
    <link>http://www.kuqin.com/testing/20090302/37419.html</link>
    <description>我推荐使用ASP.NET Team提供的Lightweight Test Automation Framework（简称之为LTAF）作为测试工具，它目前已经在CodePlex上更新至Feb Update版本。这个框架的作用与WatiN和Selenium类似，可操作浏览器对应用程序编写回归测试。</description>
    <pubDate>2009-03-02</pubDate>
    <category>软件测试</category>
    <author>老赵</author>
    <comments>博客园</comments>
</item>
<item>
    <title>选择QTP测试工具的一个可行性分析文档</title>
    <link>http://www.kuqin.com/testing/20090302/37407.html</link>
    <description>虽然存在很多风险，大部分都是客观的认为因素，只要条件和时间允许还是能够解决的。个人认为QTP对于公司现在的软件还是很适用的，至少可以让测试人员从以前的无味的测试工作中解脱出来，多做点其他与之相关的事情；让测试人员多接触一些先进的测试工具。</description>
    <pubDate>2009-03-02</pubDate>
    <category>软件测试</category>
    <author>Lin.Wei</author>
    <comments>博客园</comments>
</item>
<item>
    <title>WatiN：在.NET中测试Web应用程序</title>
    <link>http://www.kuqin.com/testing/20090220/35903.html</link>
    <description>手动编写WatiN测试有些令人厌烦，因此社区里又出现了另一个开源项目，能够从浏览器中记录并创建WatiN测试。WatiN Test Recorder并没有发布新的版本，不过它的2.0版本正处于开发过程中，并已承诺会带来一些重大的增强。</description>
    <pubDate>2009-02-20</pubDate>
    <category>软件测试</category>
    <author>Al Tenhundfeld译者 赵劼</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>嵌入式软件测试的10大秘诀</title>
    <link>http://www.kuqin.com/testing/20090215/34980.html</link>
    <description>1.懂得使用工具；2.尽早发现内存问题；3.深入理解代码优化；4.不要让自己大海捞针；5.重现并隔离问题；6.以退为进；7.确定测试的完整性；8.提高代码质量意味着节省时间；9.发现它，分析它，解决它；10.利用初学者的思维</description>
    <pubDate>2009-02-15</pubDate>
    <category>软件测试</category>
    <author>秩名</author>
    <comments>酷勤网</comments>
</item>
<item>
    <title>单元测试 vs. 私有方法</title>
    <link>http://www.kuqin.com/testing/20090205/34226.html</link>
    <description>Agile Tips在08年11月有一篇文章介绍了怎么测试私有方法。文末作者说道：应该为私有方法添加测试么？我的答案是，在成功的用了TDD或者测试驱动重构（Test-Driven Refactoring）以后，你的代码中就不会出现针对私有方法的测试。</description>
    <pubDate>2009-02-05</pubDate>
    <category>软件测试</category>
    <author>李剑</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>由实例驱动的验收测试</title>
    <link>http://www.kuqin.com/testing/20090126/33310.html</link>
    <description>Gojko认为有必要以实例编写研讨会的形式来支持验收测试。他认为：在下个迭代开始前，团队应该大致了解一下下个迭代要开发哪些功能。在不干扰当前迭代工作的前提下，有些团队成员可以参加实例编写研讨会。</description>
    <pubDate>2009-01-26</pubDate>
    <category>软件测试</category>
    <author>Vikas Hazrati译者 郑柯</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>忘掉调试器吧，来使用“Saff Squeeze”</title>
    <link>http://www.kuqin.com/testing/20081204/29420.html</link>
    <description>Beck通过一个比喻介绍了这个他称之为“Saff Squeeze”的方法，该比喻来自美式橄榄球中出现的“三明治”，在这里面带球的人会同时被两个人所击中，一个人击打其“高位”（肩膀附近），另一个人击打其“低位”（腰部或腿部）。</description>
    <pubDate>2008-12-04</pubDate>
    <category>软件测试</category>
    <author>Mike Bria译者 张龙</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>使用Clover的Test Optimization进行更快的测试</title>
    <link>http://www.kuqin.com/testing/20081123/28279.html</link>
    <description>Brendan Humphreys详细描述了Clover是如何完成这个工作的：作为一个代码覆盖工具，Clover度量每个测试的代码覆盖率——也就是说，它会度量哪些测试运行了哪些代码。通过这种方式，针对某个源代码文件，Clover可以精确判断出哪些测试适合它。</description>
    <pubDate>2008-11-23</pubDate>
    <category>软件测试</category>
    <author>Mike Bria译者 张龙</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>对 Web 测试人员的一些建议</title>
    <link>http://www.kuqin.com/testing/20081113/26811.html</link>
    <description>一个 Web 测试人员如果没听过、没用过 cURL ，是不可想像的，cURL 本身就是浏览器，学习浏览器行为，与浏览器对话，用 cURL 会让测试人员事半功倍。如果作为测试人员又恰好懂点编程技能，那么研究一下 libcurl，这肯定不是浪费时间。</description>
    <pubDate>2008-11-13</pubDate>
    <category>软件测试</category>
    <author>Fenng</author>
    <comments>DBA notes</comments>
</item>
<item>
    <title>测试：开发人员理想与现实的大PK</title>
    <link>http://www.kuqin.com/testing/20081112/26661.html</link>
    <description>开发人员无法进行更多类型测试的主要原因是速度。 单元测试已经太慢了，因此没有更多时间去进行那些更慢的测试了，比如包括网络通信的测试。 遗憾的是，并没有人考虑其他变通之策。</description>
    <pubDate>2008-11-12</pubDate>
    <category>软件测试</category>
    <author>Jonathan Allen 译者：王速瑜</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>自动化测试：为什么受伤的总是我？</title>
    <link>http://www.kuqin.com/testing/20081109/26276.html</link>
    <description>为了避免掉入那些主要的自动化测试陷阱，R&amp;D应该在开发过程中把测试这个“T”也考虑进去，而不仅仅考虑那些最新最酷的开发技术。如果发明并使用了最新最好的技术，但是不能被充分测试或者很难被测试到，那么我们如何知道它们的质量水平呢？！</description>
    <pubDate>2008-11-09</pubDate>
    <category>软件测试</category>
    <author>IT168 陈能技</author>
    <comments>IT168</comments>
</item>
<item>
    <title>什么是Nokia测试的价值？</title>
    <link>http://www.kuqin.com/testing/20081107/26019.html</link>
    <description>我们可以这么认为，“Nokia测试”的最初目的是帮助敏捷教练确定Nokia的哪些团队可能会受益于这些引导。但还能否达到其他目的？虽然这个答案几乎可以肯定是的，但是许多时候都违背了在采用过程中需要仔细审查的原则，并且它们往往是遵循了适应为先的原则。</description>
    <pubDate>2008-11-07</pubDate>
    <category>软件测试</category>
    <author>Chris Sims译者 王速瑜</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>使用JRuby测试Java GUI</title>
    <link>http://www.kuqin.com/testing/20081101/25390.html</link>
    <description>GUI测试的一个方法是提供一个交互录制器，监控测试人员，创建一个以后能够重用的脚本。这种方法存在若干问题：根据录制格式的不同，脚本在 UI改变之后可能难以修改；很自然地，测试优先的开发模式不可行。</description>
    <pubDate>2008-11-01</pubDate>
    <category>软件测试</category>
    <author>Mirko Stocker译者 崔康</author>
    <comments>InfoQ</comments>
</item>
<item>
    <title>使用FlexMonkey测试Flex</title>
    <link>http://www.kuqin.com/testing/20081025/24391.html</link>
    <description>FlexMonkey是一个开源的Flex应用和库，可以记录和回放用户界面的交互并生成可重复使用的测试用例，你可以在持续集成框架（如Cruise Control）中运行这些测试用例。</description>
    <pubDate>2008-10-25</pubDate>
    <category>软件测试</category>
    <author>Jon Rose译者 张龙</author>
    <comments>InfoQ</comments>
</item>

</channel>
</rss>
