+ {{ content | expand_urls: root_url }}
+
+ 
+ Google+
+
+ A little something about me.
++ Copyright © {{ site.time | date: "%Y" }} - {{ site.author }} - + Powered by Octopress +
diff --git a/.themes/classic/source/_includes/custom/head.html b/.themes/classic/source/_includes/custom/head.html new file mode 100644 index 0000000..85879f4 --- /dev/null +++ b/.themes/classic/source/_includes/custom/head.html @@ -0,0 +1,3 @@ + + + diff --git a/.themes/classic/source/_includes/custom/header.html b/.themes/classic/source/_includes/custom/header.html new file mode 100644 index 0000000..35f9c05 --- /dev/null +++ b/.themes/classic/source/_includes/custom/header.html @@ -0,0 +1,6 @@ + +不过在测试领域中，算是一个新现象。最近在看《Google软件测试之道》，里面有一篇James Whittaker写的短文，谈了谈对众包的看法，感觉不错，转了过来。以下内容是转发：
- --]]>James Whittaker: 众包
- -众包是测试领域的一个新现象，它的产生基于一下事实：测试人员在数量上很少，而且拥有的资源也很有限；但用户则为数众多，而且拥有每一种我们希望用来测试应用的硬件和环境组合。当然会有一部分用户愿意帮帮，对不对？
- -来看看群众的力量：一部分对测试懂行的高级用户，愿意来帮忙并拿到合理的报酬。他们只需要能访问预发环境并运行被测应用即可，然后通过某种机制提供反馈和bug报告。类似Chromium这样的开源项目，很适合大众测试；而那些更敏感和保密的、只能在内网访问的项目就麻烦一些，必须交给可信的测试人员。
- -大众用户除了可以带来大量的硬件和配置，还能提供多种不同的视角。以前是一个测试人员想像1000个用户的使用场景，现在是1000个真实用户在做测试的工作。在发现导致应用出错的用户场景方面，还有比邀请用户注册来试用并提交反馈更好的方法吗？关键在于变化性和规模，大众用户两者兼备。
- -今天，愿意做软件测试的人群数量很大，而且7x24小时可用。假定我们想在新发布的Chrome里测试1000个著名网站，1个测试人员=1000次测试，20个测试人员=50次测。这就是人民群众的力量。
- -大众测试员的主要弱点是需要一定的时间来学习被测应用，并跟上其更新的步伐。考虑到大众测试员的数量，这意味着惊人的浪费。然而，这仍然世可以管理的。对Chrome，我们编写了产品导览（tours），以供大众测试员参考来开展探索式测试和运行用户场景。这些导览使测试工作变得更加明确，可以直接将用户引导到应用的特定部分。为了合理分工，可以编写多个导览指南，分发给不同的大众用户。
- -大众测试是Google的金丝雀、开发、测试、dogfood系列测试的一个扩展，是我们与早期用户联系的一种方式。这些用户可以在早期就发现和报告bug。在Google，希望试用产品的内部测试人员、在各个产品组之间按需流动的外包员工，以及商业性的众包公司如uTest.com，他们都曾经参与过Google产品的测试。我们还悬赏奖励最佳bug发现者。
最开始的时候，我们是用word来写这份文档的。方便是方便，但是当时间长了以后，文件数越来越多，每次写这个文档也不是固定的人，有时候需要复查一下很久前写的东西，就不那么方便了。所以很期望能把这个部署文档也纳入版本控制当中，这样就可以像代码一样，不管是谁写完文档，check in到repository里，以后想要查找、对比都方便很多。
- -但是word文档本身并不能直接纳入到版本控制中，需要check in的是纯文本。我们还想提供给客户的文档有一定的格式，所以直接发送纯文本的方式也被否定了。
- -这个时候就是我们的主角Docbook登场的时候了！Docbook可以把符合自己格式的XML文件转变成pdf，我们可以把pdf作为发送给客户的最终文档。下面就让我们看看，如何使用Docbook来实现文档的版本化吧！
- -我们这里以Windows环境为例。
- -依据链接1的步骤，可以很方便的搭建起来Docbook环境。搭建的过程很简单，把那个链接当中提到的东西都下载安装后，就可以了。 -之后，我们的重点就可以放在编辑XML文件了，Docbook本身有很多规则，可以参考链接2。由于我们只是准备一份文档，不许要像论文、书籍那么复杂，所以可以只用几个简单有用的元素，就满足我们的需求了。
- -下面是一个简单的例子，创建一个叫做 docbook5-demo.xml 的文件，编辑如下：
- -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 -32 -33 - | |
很好理解的文件，对吧。
- -第1行，是来规定文件的编码格式。
- -<article>定义一个article的开始，在最后有相应的</article>来关闭他。
<artheader>作为article的头，定义了文档的名称，以及作者，同样需要相应的</article>。
<sect1>就是章节的划分了，在示例文件中我们会看到多个<sect1>，这些章节的序号会自动按照1、2、3这样的顺序生成。示例中的第一个section是一个插图，可以讲指定的图片插入到我们的文档中。<title>指出了该章节的标题；<graphic>元素中指出了插图的路径和名称，这里XML文件跟png文件在同一路径下。
往下看，我们会发现<sect2>这样的元素，他是我们插入的子章节，他的页面效果是这样的。第一层的<sect1>，会被展现成 2. 这样子，可以认为是表示第二章。<sect2>则会被展现成 2.1 这样子的，表示是第二章第一小节。后面的<sect2>和<sect3>以此类推。17行中的<para>表示一个章节中普通的段落。
在25行中，我们可以看到<itemizedlist>这个元素，他是一个列表。
到这里，我们已经编辑完我们的XML文件了。然后我们就可以按照最开始提到的链接1中所描述的那样，用相应的工具把这个XML文件转换成pdf文件。
-这里分两步：
-1. 首先要把XML文件转换成fo文件，在命令行模式中，去刚才编辑好的XML文件所在路径，运行：xsltproc -o ../output/fo/docbook5-demo.fo E:\DevRoot\docbook\config\docbook-xsl-ns-1.77.1\docbook_fo.xsl docbook5-demo.xml 这里，-o 参数后面跟的是本次将要生成fo文件的路径和名称；E盘路径那个参数，表示生成fo文件时所要参考的格式文件；最后的参数，就是刚刚编辑好的XML文件.
-2. 然后我们会得到一个叫做docbook5-demo.fo的文件，再运行：E:\DevRoot\docbook\tools\fop-1.0\fop.cmd -c E:\DevRoot\docbook\config\fop\fop.xconf -fo ../output/fo/docbook5_demo.fo -pdf ../output/pdf/docbook5_demo.pdf 这里，第一个E盘路径表示我们此次要运行的命令，可以根据自己所设置的位置来调整；-c 跟的参数，表示此次转换时要是用的配置文件； -fo 就是刚才生成的fo文件路径； 最后-pdf表示此次要生成的pdf的路径和名称。
运行完上面两步，我们就可以得到一个pdf文件了！
- -最后，我们可以在本地自己搭建一个repository（git或者hg，随你自己喜欢），把编辑好的XML文件check in上去了。以后每次写完，可以运行上面两条命令来得到交付的pdf文件；编辑完的XML文件则完全纳入版本管理当中了，可以集中、方便地管理，查询以前的提交，两次之间的diff，都是方便得很～～
-]]>由于项目中客户的一些原因，我们不能直接接触产品环境的服务器。导致我们每次部署产品代码前，需要给客户的IT团队准备一份部署文档，然后他们遵循这份文档来部署产品。
- -最开始的时候，我们是用word来写这份文档的。方便是方便，但是当时间长了以后，文件数越来越多，每次写这个文档也不是固定的人，有时候需要复查一下很久前写的东西，就不那么方便了。所以很期望能把这个部署文档也纳入版本控制当中，这样就可以像代码一样，不管是谁写完文档，check in到repository里，以后想要查找、对比都方便很多。
- -但是word文档本身并不能直接纳入到版本控制中，需要check in的是纯文本。我们还想提供给客户的文档有一定的格式，所以直接发送纯文本的方式也被否定了。
- -这个时候就是我们的主角Docbook登场的时候了！Docbook可以把符合自己格式的XML文件转变成pdf，我们可以把pdf作为发送给客户的最终文档。下面就让我们看看，如何使用Docbook来实现文档的版本化吧！
- -我们这里以Windows环境为例。
- -依据链接1的步骤，可以很方便的搭建起来Docbook环境。搭建的过程很简单，把那个链接当中提到的东西都下载安装后，就可以了。 -之后，我们的重点就可以放在编辑XML文件了，Docbook本身有很多规则，可以参考链接2。由于我们只是准备一份文档，不许要像论文、书籍那么复杂，所以可以只用几个简单有用的元素，就满足我们的需求了。
- -下面是一个简单的例子，创建一个叫做 docbook5-demo.xml 的文件，编辑如下：
- -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 -32 -33 - | |
很好理解的文件，对吧。
- -第1行，是来规定文件的编码格式。
- -<article>定义一个article的开始，在最后有相应的</article>来关闭他。
<artheader>作为article的头，定义了文档的名称，以及作者，同样需要相应的</article>。
<sect1>就是章节的划分了，在示例文件中我们会看到多个<sect1>，这些章节的序号会自动按照1、2、3这样的顺序生成。示例中的第一个section是一个插图，可以讲指定的图片插入到我们的文档中。<title>指出了该章节的标题；<graphic>元素中指出了插图的路径和名称，这里XML文件跟png文件在同一路径下。
往下看，我们会发现<sect2>这样的元素，他是我们插入的子章节，他的页面效果是这样的。第一层的<sect1>，会被展现成 2. 这样子，可以认为是表示第二章。<sect2>则会被展现成 2.1 这样子的，表示是第二章第一小节。后面的<sect2>和<sect3>以此类推。17行中的<para>表示一个章节中普通的段落。
在25行中，我们可以看到<itemizedlist>这个元素，他是一个列表。
到这里，我们已经编辑完我们的XML文件了。然后我们就可以按照最开始提到的链接1中所描述的那样，用相应的工具把这个XML文件转换成pdf文件。
-这里分两步：
-1. 首先要把XML文件转换成fo文件，在命令行模式中，去刚才编辑好的XML文件所在路径，运行：xsltproc -o ../output/fo/docbook5-demo.fo E:\DevRoot\docbook\config\docbook-xsl-ns-1.77.1\docbook_fo.xsl docbook5-demo.xml 这里，-o 参数后面跟的是本次将要生成fo文件的路径和名称；E盘路径那个参数，表示生成fo文件时所要参考的格式文件；最后的参数，就是刚刚编辑好的XML文件.
-2. 然后我们会得到一个叫做docbook5-demo.fo的文件，再运行：E:\DevRoot\docbook\tools\fop-1.0\fop.cmd -c E:\DevRoot\docbook\config\fop\fop.xconf -fo ../output/fo/docbook5_demo.fo -pdf ../output/pdf/docbook5_demo.pdf 这里，第一个E盘路径表示我们此次要运行的命令，可以根据自己所设置的位置来调整；-c 跟的参数，表示此次转换时要是用的配置文件； -fo 就是刚才生成的fo文件路径； 最后-pdf表示此次要生成的pdf的路径和名称。
运行完上面两步，我们就可以得到一个pdf文件了！
- -最后，我们可以在本地自己搭建一个repository（git或者hg，随你自己喜欢），把编辑好的XML文件check in上去了。以后每次写完，可以运行上面两条命令来得到交付的pdf文件；编辑完的XML文件则完全纳入版本管理当中了，可以集中、方便地管理，查询以前的提交，两次之间的diff，都是方便得很～～
-Crowdsourcing，翻译成中文是众包，这并不是一个新的概念了。在wiki上有一些关于他的解释，可以参考这里。
- -不过在测试领域中，算是一个新现象。最近在看《Google软件测试之道》，里面有一篇James Whittaker写的短文，谈了谈对众包的看法，感觉不错，转了过来。以下内容是转发：
- --James Whittaker: 众包
- -众包是测试领域的一个新现象，它的产生基于一下事实：测试人员在数量上很少，而且拥有的资源也很有限；但用户则为数众多，而且拥有每一种我们希望用来测试应用的硬件和环境组合。当然会有一部分用户愿意帮帮，对不对？
- -来看看群众的力量：一部分对测试懂行的高级用户，愿意来帮忙并拿到合理的报酬。他们只需要能访问预发环境并运行被测应用即可，然后通过某种机制提供反馈和bug报告。类似Chromium这样的开源项目，很适合大众测试；而那些更敏感和保密的、只能在内网访问的项目就麻烦一些，必须交给可信的测试人员。
- -大众用户除了可以带来大量的硬件和配置，还能提供多种不同的视角。以前是一个测试人员想像1000个用户的使用场景，现在是1000个真实用户在做测试的工作。在发现导致应用出错的用户场景方面，还有比邀请用户注册来试用并提交反馈更好的方法吗？关键在于变化性和规模，大众用户两者兼备。
- -今天，愿意做软件测试的人群数量很大，而且7x24小时可用。假定我们想在新发布的Chrome里测试1000个著名网站，1个测试人员=1000次测试，20个测试人员=50次测。这就是人民群众的力量。
- -大众测试员的主要弱点是需要一定的时间来学习被测应用，并跟上其更新的步伐。考虑到大众测试员的数量，这意味着惊人的浪费。然而，这仍然世可以管理的。对Chrome，我们编写了产品导览（tours），以供大众测试员参考来开展探索式测试和运行用户场景。这些导览使测试工作变得更加明确，可以直接将用户引导到应用的特定部分。为了合理分工，可以编写多个导览指南，分发给不同的大众用户。
- -大众测试是Google的金丝雀、开发、测试、dogfood系列测试的一个扩展，是我们与早期用户联系的一种方式。这些用户可以在早期就发现和报告bug。在Google，希望试用产品的内部测试人员、在各个产品组之间按需流动的外包员工，以及商业性的众包公司如uTest.com，他们都曾经参与过Google产品的测试。我们还悬赏奖励最佳bug发现者。
Crowdsourcing，翻译成中文是众包，这并不是一个新的概念了。在wiki上有一些关于他的解释，可以参考这里。
- -不过在测试领域中，算是一个新现象。最近在看《Google软件测试之道》，里面有一篇James Whittaker写的短文，谈了谈对众包的看法，感觉不错，转了过来。以下内容是转发：
- --James Whittaker: 众包
- -众包是测试领域的一个新现象，它的产生基于一下事实：测试人员在数量上很少，而且拥有的资源也很有限；但用户则为数众多，而且拥有每一种我们希望用来测试应用的硬件和环境组合。当然会有一部分用户愿意帮帮，对不对？
- -来看看群众的力量：一部分对测试懂行的高级用户，愿意来帮忙并拿到合理的报酬。他们只需要能访问预发环境并运行被测应用即可，然后通过某种机制提供反馈和bug报告。类似Chromium这样的开源项目，很适合大众测试；而那些更敏感和保密的、只能在内网访问的项目就麻烦一些，必须交给可信的测试人员。
- -大众用户除了可以带来大量的硬件和配置，还能提供多种不同的视角。以前是一个测试人员想像1000个用户的使用场景，现在是1000个真实用户在做测试的工作。在发现导致应用出错的用户场景方面，还有比邀请用户注册来试用并提交反馈更好的方法吗？关键在于变化性和规模，大众用户两者兼备。
- -今天，愿意做软件测试的人群数量很大，而且7x24小时可用。假定我们想在新发布的Chrome里测试1000个著名网站，1个测试人员=1000次测试，20个测试人员=50次测。这就是人民群众的力量。
- -大众测试员的主要弱点是需要一定的时间来学习被测应用，并跟上其更新的步伐。考虑到大众测试员的数量，这意味着惊人的浪费。然而，这仍然世可以管理的。对Chrome，我们编写了产品导览（tours），以供大众测试员参考来开展探索式测试和运行用户场景。这些导览使测试工作变得更加明确，可以直接将用户引导到应用的特定部分。为了合理分工，可以编写多个导览指南，分发给不同的大众用户。
- -大众测试是Google的金丝雀、开发、测试、dogfood系列测试的一个扩展，是我们与早期用户联系的一种方式。这些用户可以在早期就发现和报告bug。在Google，希望试用产品的内部测试人员、在各个产品组之间按需流动的外包员工，以及商业性的众包公司如uTest.com，他们都曾经参与过Google产品的测试。我们还悬赏奖励最佳bug发现者。
由于项目中客户的一些原因，我们不能直接接触产品环境的服务器。导致我们每次部署产品代码前，需要给客户的IT团队准备一份部署文档，然后他们遵循这份文档来部署产品。
- -最开始的时候，我们是用word来写这份文档的。方便是方便，但是当时间长了以后，文件数越来越多，每次写这个文档也不是固定的人，有时候需要复查一下很久前写的东西，就不那么方便了。所以很期望能把这个部署文档也纳入版本控制当中，这样就可以像代码一样，不管是谁写完文档，check in到repository里，以后想要查找、对比都方便很多。
- -但是word文档本身并不能直接纳入到版本控制中，需要check in的是纯文本。我们还想提供给客户的文档有一定的格式，所以直接发送纯文本的方式也被否定了。
- -这个时候就是我们的主角Docbook登场的时候了！Docbook可以把符合自己格式的XML文件转变成pdf，我们可以把pdf作为发送给客户的最终文档。下面就让我们看看，如何使用Docbook来实现文档的版本化吧！
- -我们这里以Windows环境为例。
- -依据链接1的步骤，可以很方便的搭建起来Docbook环境。搭建的过程很简单，把那个链接当中提到的东西都下载安装后，就可以了。 -之后，我们的重点就可以放在编辑XML文件了，Docbook本身有很多规则，可以参考链接2。由于我们只是准备一份文档，不许要像论文、书籍那么复杂，所以可以只用几个简单有用的元素，就满足我们的需求了。
- -下面是一个简单的例子，创建一个叫做 docbook5-demo.xml 的文件，编辑如下：
- -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 -32 -33 - | |
很好理解的文件，对吧。
- -第1行，是来规定文件的编码格式。
- -<article>定义一个article的开始，在最后有相应的</article>来关闭他。
<artheader>作为article的头，定义了文档的名称，以及作者，同样需要相应的</article>。
<sect1>就是章节的划分了，在示例文件中我们会看到多个<sect1>，这些章节的序号会自动按照1、2、3这样的顺序生成。示例中的第一个section是一个插图，可以讲指定的图片插入到我们的文档中。<title>指出了该章节的标题；<graphic>元素中指出了插图的路径和名称，这里XML文件跟png文件在同一路径下。
往下看，我们会发现<sect2>这样的元素，他是我们插入的子章节，他的页面效果是这样的。第一层的<sect1>，会被展现成 2. 这样子，可以认为是表示第二章。<sect2>则会被展现成 2.1 这样子的，表示是第二章第一小节。后面的<sect2>和<sect3>以此类推。17行中的<para>表示一个章节中普通的段落。
在25行中，我们可以看到<itemizedlist>这个元素，他是一个列表。
到这里，我们已经编辑完我们的XML文件了。然后我们就可以按照最开始提到的链接1中所描述的那样，用相应的工具把这个XML文件转换成pdf文件。
-这里分两步：
-1. 首先要把XML文件转换成fo文件，在命令行模式中，去刚才编辑好的XML文件所在路径，运行：xsltproc -o ../output/fo/docbook5-demo.fo E:\DevRoot\docbook\config\docbook-xsl-ns-1.77.1\docbook_fo.xsl docbook5-demo.xml 这里，-o 参数后面跟的是本次将要生成fo文件的路径和名称；E盘路径那个参数，表示生成fo文件时所要参考的格式文件；最后的参数，就是刚刚编辑好的XML文件.
-2. 然后我们会得到一个叫做docbook5-demo.fo的文件，再运行：E:\DevRoot\docbook\tools\fop-1.0\fop.cmd -c E:\DevRoot\docbook\config\fop\fop.xconf -fo ../output/fo/docbook5_demo.fo -pdf ../output/pdf/docbook5_demo.pdf 这里，第一个E盘路径表示我们此次要运行的命令，可以根据自己所设置的位置来调整；-c 跟的参数，表示此次转换时要是用的配置文件； -fo 就是刚才生成的fo文件路径； 最后-pdf表示此次要生成的pdf的路径和名称。
运行完上面两步，我们就可以得到一个pdf文件了！
- -最后，我们可以在本地自己搭建一个repository（git或者hg，随你自己喜欢），把编辑好的XML文件check in上去了。以后每次写完，可以运行上面两条命令来得到交付的pdf文件；编辑完的XML文件则完全纳入版本管理当中了，可以集中、方便地管理，查询以前的提交，两次之间的diff，都是方便得很～～
-+#+# +require './plugins/titlecase.rb' + +module Jekyll + + class Blockquote < Liquid::Block + FullCiteWithTitle = /(\S.*)\s+(https?:\/\/)(\S+)\s+(.+)/i + FullCite = /(\S.*)\s+(https?:\/\/)(\S+)/i + AuthorTitle = /([^,]+),([^,]+)/ + Author = /(.+)/ + + def initialize(tag_name, markup, tokens) + @by = nil + @source = nil + @title = nil + if markup =~ FullCiteWithTitle + @by = $1 + @source = $2 + $3 + @title = $4.titlecase.strip + elsif markup =~ FullCite + @by = $1 + @source = $2 + $3 + elsif markup =~ AuthorTitle + @by = $1 + @title = $2.titlecase.strip + elsif markup =~ Author + @by = $1 + end + super + end + + def render(context) + quote = paragraphize(super) + author = "#{@by.strip}" if @by + if @source + url = @source.match(/https?:\/\/(.+)/)[1].split('/') + parts = [] + url.each do |part| + if (parts + [part]).join('/').length < 32 + parts << part + end + end + source = parts.join('/') + source << '/…' unless source == @source + end + if !@source.nil? + cite = " #{(@title || source)}" + elsif !@title.nil? + cite = " #{@title}" + end + blockquote = if @by.nil? + quote + elsif cite + "#{quote}" + else + "#{quote}" + end + "Wheeee!
+#
#{blockquote}" + end + + def paragraphize(input) + "
#{input.lstrip.rstrip.gsub(/\n\n/, '
').gsub(/\n/, '
')}
+# -- nicely escaped highlighted code --
+# <sarcasm> Ooooh, sarcasm... How original!</sarcasm>
+# 
+#
+#
+
+module Jekyll
+
+ class ImageTag < Liquid::Tag
+ @img = nil
+
+ def initialize(tag_name, markup, tokens)
+ attributes = ['class', 'src', 'width', 'height', 'title']
+
+ if markup =~ /(?