<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Jaunty@软件测试，音乐，还有不一样的生活 &#187; 测试技巧</title>
	<atom:link href="http://jaunty.me/blog/tag/%e6%b5%8b%e8%af%95%e6%8a%80%e5%b7%a7/feed/" rel="self" type="application/rss+xml" />
	<link>http://jaunty.me/blog</link>
	<description>软件测试，自动化测试，QTP，Loadrunner，Java，软件开发，性能测试，开源</description>
	<lastBuildDate>Tue, 24 Aug 2010 03:40:43 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>漫谈Fuzz测试技术</title>
		<link>http://jaunty.me/blog/2009/05/%e6%bc%ab%e8%b0%88fuzz%e6%b5%8b%e8%af%95%e6%8a%80%e6%9c%af/</link>
		<comments>http://jaunty.me/blog/2009/05/%e6%bc%ab%e8%b0%88fuzz%e6%b5%8b%e8%af%95%e6%8a%80%e6%9c%af/#comments</comments>
		<pubDate>Wed, 20 May 2009 01:32:40 +0000</pubDate>
		<dc:creator>jaunty</dc:creator>
				<category><![CDATA[单元测试]]></category>
		<category><![CDATA[安全测试]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[测试技巧]]></category>
		<category><![CDATA[白盒测试]]></category>

		<guid isPermaLink="false">http://jaunty.me/blog/2009/05/%e6%bc%ab%e8%b0%88fuzz%e6%b5%8b%e8%af%95%e6%8a%80%e6%9c%af/</guid>
		<description><![CDATA[Part 1  Security Testing Overview
    我相信大家对测试不陌生，但是对安全测试可能有一些疑问。安全测试关心的问题是不一样的。这种测试也被人叫做工具测试、渗透测试、攻击测试、测试产品安全性。
    这种测试需要首先知道各种各样的攻击的方式和原理，在攻击产生之前尽量多的找到产品的漏洞，尽量多的发现产品里面的问题，再努力把它解决掉。
What is the difference between security testing and traditional function based testing ?

    这两个之间的差别我们可以用一个简单的东西来说明，Targeted towards making sure that the app does what it is supposed to do。
    For Functionality testing：我设计这个产品是1、2、3、4、5，我得让它能干到1、2、3、4、5才行，不是说是1、2、3、4，少1份干不了。这是一般的出来的结果也是一二三四五。
    For Security testing：是说我设计了1、2、3、4、5，我得确定你干出来的不是1、2、3、4、5、6、7，还多出来2个。大家都知道你用word去解析一个文件，看一个文档的时候，是一个代码，具体怎么发生大家可能比较清楚的。
    一般来说，重点是通用的漏洞、Memory问题、堆溢出、栈溢出，还有各种各样的溢出，SQL、XSS和各种各样的validation。被黑客熟悉的除了我们耳熟能详的漏洞之外，还要关注其他的一些东西，比如说Access Control、information、加密方面的问题、认证方面的问题。一些软件安全工程师经常用加密技术，但是用错或者是设计上有一些东西出现错误。
Security Testing一般的方法就是以下这几种：
（1）White BOX：我们一般会用静态的源码扫描工具。通过对源代码的扫描，我们可以把源代码的某一个函数，某一个文件，某一行用了哪些不安全的东西，有哪些漏洞，有哪些缓存区域的漏洞等等，这些东西都能扫描出来。通过扫描把这些漏洞全部做出来以后，从源代码方面能够保证基本上保证常见的漏洞不会出现。 
（2）Black BOX：首先要灵活，会有很多的方法，比较好的有Injection Fuzzer和Dumb Fuzzer，后面会介绍它们之间的区别。
（3）Gray BOX
Part 2  Smart Fuzz Test
    Fuzz这个名词来自于Professor Barton Miller。在1989年一个风雨交加的夜晚，他登陆一台自己的主机，不知道怎么回事，信号通过猫传到主机上，雷电一闪，把里面的高位变低位，低位至高位了，结果到了主机以后改变了。他突发奇想，把这种方式作为一种测试的方式来做。
1、到底什么是Fuzz Test？
    [...]]]></description>
			<content:encoded><![CDATA[<p><strong>Part 1  Security Testing Overview</strong></p>
<p>    我相信大家对测试不陌生，但是对安全测试可能有一些疑问。安全测试关心的问题是不一样的。这种测试也被人叫做工具测试、渗透测试、攻击测试、测试产品安全性。</p>
<p>    这种测试需要首先知道各种各样的攻击的方式和原理，在攻击产生之前尽量多的找到产品的漏洞，尽量多的发现产品里面的问题，再努力把它解决掉。</p>
<p>What is the difference between security testing and traditional function based testing ?</p>
<p><span id="more-116"></span></p>
<p>    这两个之间的差别我们可以用一个简单的东西来说明，Targeted towards making sure that the app does what it is supposed to do。</p>
<p>    For Functionality testing：我设计这个产品是1、2、3、4、5，我得让它能干到1、2、3、4、5才行，不是说是1、2、3、4，少1份干不了。这是一般的出来的结果也是一二三四五。</p>
<p>    For Security testing：是说我设计了1、2、3、4、5，我得确定你干出来的不是1、2、3、4、5、6、7，还多出来2个。大家都知道你用word去解析一个文件，看一个文档的时候，是一个代码，具体怎么发生大家可能比较清楚的。</p>
<p>    一般来说，重点是通用的漏洞、Memory问题、堆溢出、栈溢出，还有各种各样的溢出，SQL、XSS和各种各样的validation。被黑客熟悉的除了我们耳熟能详的漏洞之外，还要关注其他的一些东西，比如说Access Control、information、加密方面的问题、认证方面的问题。一些软件安全工程师经常用加密技术，但是用错或者是设计上有一些东西出现错误。</p>
<p>Security Testing一般的方法就是以下这几种：</p>
<p>（1）White BOX：我们一般会用静态的源码扫描工具。通过对源代码的扫描，我们可以把源代码的某一个函数，某一个文件，某一行用了哪些不安全的东西，有哪些漏洞，有哪些缓存区域的漏洞等等，这些东西都能扫描出来。通过扫描把这些漏洞全部做出来以后，从源代码方面能够保证基本上保证常见的漏洞不会出现。 <br />
（2）Black BOX：首先要灵活，会有很多的方法，比较好的有Injection Fuzzer和Dumb Fuzzer，后面会介绍它们之间的区别。<br />
（3）Gray BOX</p>
<p><strong>Part 2  Smart Fuzz Test</strong></p>
<p>    Fuzz这个名词来自于Professor Barton Miller。在1989年一个风雨交加的夜晚，他登陆一台自己的主机，不知道怎么回事，信号通过猫传到主机上，雷电一闪，把里面的高位变低位，低位至高位了，结果到了主机以后改变了。他突发奇想，把这种方式作为一种测试的方式来做。</p>
<p>1、到底什么是Fuzz Test？</p>
<p>    Generally speaking fuzz is a brute force method which used to break software，就是用大量的测试用例一个一个试，尽可能多的找出有可能出问题的地方。</p>
<p>2、Fuzz怎么工作？<br />
    现在有无数有名的Fuzz工具，有很多人很多还在写，一般包括四个部分。<br />
（1）Generate lots of malformed data as test cases，要生成大量的测试用例。这个测试用力是malformed的，一个软件首先要找到输入点，然后把数据丢进去，这个数据有可能是一个文件，有可能是一个数据包，有可能是测试表里面的一个项，有可能是临时文件里面的一个东西，总之是一种数据，要定义malformed这种非正常的数据。<br />
（2）Drop the test cases into product，把它丢进去，看这个产品怎么反应。<br />
（3）Monitor and log any crash/exception triggered by malicious input.<br />
（4）Review the test log, investigated deeply.</p>
<p>3、Injection Fuzzer和Dumb Fuzzer的区别</p>
<p>    下面我们说一下Dumb Fuzzer和Intelligent Fuzzer之间的区别。</p>
<p>    Dumb就是哑的，就是笨的意思。刚开始Fuzz的时候用的都是这种东西，直接把非法数据丢到软件里边去，这种东西很难真正测试出问题，因为很难把问题放到缓冲区去。比如丢一个Word，不能随便写一个文件，这就很难测试到真正问题，必须基本符合Word本身的文件格式，才有可能测试到结果。要考虑到软件本身执行的流程，你的case放进去，能够放到多深，逻辑放到多深，你要考虑这个问题。你要写这种程序的话，就要非常了解要测试的文档结构。</p>
<p>    什么东西可以被Fuzzed？文件格式可能出问题，数据包也可能出问题。因为数据包在解析数据包的时候也是一个状态机，放进去以后再看下一步到哪里去。抗组件这些东西也是相当容易出问题的。这么多东西，都是可以被Fuzz的。当然有一些东西也是可以被Fuzz的，我们现在说的集中是软件产品，硬件也可能有。</p>
<p>4、几个Fuzz工具</p>
<p>    简单介绍几个Fuzz工具，因为Fuzz的工具特别多，下面结合我在工作中的用到的一些东西，用最简单的方式介绍一下。</p>
<p>（1）Com Raidor</p>
<p>    对于ActiveX，一般来说，我们用的都是Com Raidor，它是非常简单，而且是免费的，它是Idenfense的产品。你只要选中，它里面有很多的项目。因为很多问题是针对IE的，它就会生成测试用例，会把脚本拿出来，一个一个的丢到IE里跑，接下来一直是这个状态。很简单，相信点几下鼠标就可以做。大家如果在测试的时候，其实跑一下也不费什么力。</p>
<p>（2）Fuzz网络协议——SPIKE</p>
<p>    SPIKE第一个提出格式化Fuzz的概念，而且提供了免费的、开源的工具，它发现了很多著名的漏洞。如果我要用SPIKE Fuzz一个文件的话就不是很简单了。Fuzz的时候，你要保证数据结构基本是正确的，不用完全对，完全对的话就不用Fuzz了。改一些小的地方，一次改一点点，一次改一点点，一次改一个地方或者几个地方，不要改太多，这样一丢，才能测试到东西。如果改的太多，最基本的条件没有满足，进去以后它就会走到其他分值区。这是一个结构化的最基本的原理。是要注重数据之间的结构，在这种情况下才能比较准确的找到问题。</p>
<p>    协议一般都有状态，第二个包过来，第一个包回去，第三个包过来，第四个包回去，可能是第三次组合的东西某一项才会触发漏洞。但是如果你从第一个包就开始胡乱的发，也许根本进行不到第三个包去了。所以说，协议Fuzz的文件要更麻烦一点。你要想把它送的深，送的远，送的逻辑远，覆盖的逻辑深，把东西丢到程序里面深一点，你得思考程序到底是怎么样执行的，你得想它控制的东西不是一个重复的。我想它已经不是一个纯黑盒测试了，要考虑程序里面是怎么运行的，还要考虑到程序的具体逻辑。</p>
<p> </p>
<p>    本文主要内容整理自著名软件安全专家王清先生在<a href="http://www.sinoit.org.cn/Security2008/flashindex2.html"><strong>2008中国软件安全峰会</strong></a>上的演讲，欢迎<a href="http://www.sinoit.org.cn/Security2008/PPT下载页面/wangqing.html"><strong>下载本文资料</strong></a>。</p>
]]></content:encoded>
			<wfw:commentRss>http://jaunty.me/blog/2009/05/%e6%bc%ab%e8%b0%88fuzz%e6%b5%8b%e8%af%95%e6%8a%80%e6%9c%af/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
		<item>
		<title>早晨看到的一篇不错的汇总</title>
		<link>http://jaunty.me/blog/2009/01/gui-test-guidelin/</link>
		<comments>http://jaunty.me/blog/2009/01/gui-test-guidelin/#comments</comments>
		<pubDate>Thu, 15 Jan 2009 01:57:31 +0000</pubDate>
		<dc:creator>jaunty</dc:creator>
				<category><![CDATA[手动测试]]></category>
		<category><![CDATA[软件测试]]></category>
		<category><![CDATA[GUI测试]]></category>
		<category><![CDATA[测试基础]]></category>
		<category><![CDATA[测试技巧]]></category>

		<guid isPermaLink="false">http://jaunty.me/blog/?p=74</guid>
		<description><![CDATA[对于UI界面的测试做的久了必然会发现有个共性，今早看到这个老兄给做了个汇总，甚觉受益，转过来以供备用。可以在测试的时候做checklist使用。
UI测试常见BUG汇总
发布时间: 2009-1-14 15:11    作者: my.adi    来源: 51Testing论坛
适用于新手
　　录入界面
　　1.1 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）
　　1.2 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）
　　1.3 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息
　　（1） 长度校验

　　（2） 数字、字母、日期等等的校验
　　（3） 范围的校验
　　1.4 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示
　　1.5 下拉框不选值的时候应该提供默认值
　　1.6 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）
　　1.7 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）
　　1.8 日期参照应该既能输入，又能从文本框选择
　　界面格式
　　2.1 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性
　　2.2 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性
　　2.3 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致
　　2.4 不同界面显示相同字段的一致性（如列表界面和编辑界面）
　　2.5 界面按钮显示要求（查询、新增、删除顺序）
　　2.6 列表的顺序排列应该统一（按照某些特定条件排序）
　　2.7 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定
　　2.8 所有弹出窗口居中显示或者最大化显示
　　2.9 信息列表中如果某个字段显示过长用“…”或者分行显示
　　2.10 人员、时间的缺省值一般取当前登录人员和时间
　　2.11 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”
　　功能问题
　　3.1 按钮功能的实现（如返回按钮能否返回）
　　3.2 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示
　　3.3 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）
　　3.4 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮
　　3.5 没有选择记录点击删除/修改按钮要提示“请先选择记录”
　　3.6 选择记录后点击删除按钮要提示“确实要删除吗？”
　　3.7 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容
　　3.8 界面只读的时候（查询、统计、导入）等，应该不能编辑
　　查询问题
　　4.1 查询条件缺少一些可以查询的字段
　　4.2 有些查询条件需要支持模糊查询
　　4.3 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）
　　4.4 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一
　　4.5 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）
　　4.6 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么
　　4.7 对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]）
]]></description>
			<content:encoded><![CDATA[<p>对于UI界面的测试做的久了必然会发现有个共性，今早看到这个老兄给做了个汇总，甚觉受益，转过来以供备用。可以在测试的时候做checklist使用。</p>
<p>UI测试常见BUG汇总<br />
发布时间: 2009-1-14 15:11    作者: my.adi    来源: 51Testing论坛</p>
<p>适用于新手</p>
<p>　　录入界面</p>
<p>　　1.1 输入字段要完整，且要与列表字段相符合（参照数据库进行检查）</p>
<p>　　1.2 必填项一律在后面用*表示（必填项为空在处理之前要有相关的提示信息）</p>
<p>　　1.3 字段需要做校验，如果校验不对需要在处理之前要有相关的提示信息</p>
<p>　　（1） 长度校验</p>
<p><span id="more-74"></span></p>
<p>　　（2） 数字、字母、日期等等的校验</p>
<p>　　（3） 范围的校验</p>
<p>　　1.4 录入字段的排序按照流程或使用习惯，字段特别多的时候需要进行分组显示</p>
<p>　　1.5 下拉框不选值的时候应该提供默认值</p>
<p>　　1.6 相同字段的录入方式应该统一（手动输入 、点选 、下拉选择、参照）</p>
<p>　　1.7 录入后自动计算的字段要随着别的字段修改更新（如单价变后，金额也变）</p>
<p>　　1.8 日期参照应该既能输入，又能从文本框选择</p>
<p>　　界面格式</p>
<p>　　2.1 字体颜色、大小、对齐方式（根据字段的性质确定）、加粗的一致性</p>
<p>　　2.2 文本框、按钮、滚动条、列表等控件的大小、对齐、位置的一致性</p>
<p>　　2.3 所有新增、修改、查看页面加上页面说明（如：XXX新增、XXX编辑、XXX查看等说明字样），（弹出的）界面要有标题，标题与内容要一致</p>
<p>　　2.4 不同界面显示相同字段的一致性（如列表界面和编辑界面）</p>
<p>　　2.5 界面按钮显示要求（查询、新增、删除顺序）</p>
<p>　　2.6 列表的顺序排列应该统一（按照某些特定条件排序）</p>
<p>　　2.7 下拉框中的排列顺序需要符合使用习惯或者是按照特定的规则排定</p>
<p>　　2.8 所有弹出窗口居中显示或者最大化显示</p>
<p>　　2.9 信息列表中如果某个字段显示过长用“…”或者分行显示</p>
<p>　　2.10 人员、时间的缺省值一般取当前登录人员和时间</p>
<p>　　2.11 对于带有单位的字段，需要字段的标签后面添加如下内容：“（单位）”</p>
<p>　　功能问题</p>
<p>　　3.1 按钮功能的实现（如返回按钮能否返回）</p>
<p>　　3.2 信息保存提交后系统给出“保存/提交成功”提示信息，并自动更新显示</p>
<p>　　3.3 所有有提交按钮的页面都要有保存按钮（每个界面风格一致）</p>
<p>　　3.4 凡是点选或者下拉选择的界面，如果一旦选择完了无法回到不选择的情况，需要加上“清除选择”功能按钮</p>
<p>　　3.5 没有选择记录点击删除/修改按钮要提示“请先选择记录”</p>
<p>　　3.6 选择记录后点击删除按钮要提示“确实要删除吗？”</p>
<p>　　3.7 需要考虑删除的关联性，即删除某一个内容需要同时删除其关联的某些内容</p>
<p>　　3.8 界面只读的时候（查询、统计、导入）等，应该不能编辑</p>
<p>　　查询问题</p>
<p>　　4.1 查询条件缺少一些可以查询的字段</p>
<p>　　4.2 有些查询条件需要支持模糊查询</p>
<p>　　4.3 需要考虑有些查询条件本身的关联性（即某个查询条件的取值范围是依赖于其它查询条件的取值）</p>
<p>　　4.4 查询条件名称与信息列表及信息编辑页面相应的字段名称完全统一</p>
<p>　　4.5 不同模块相同字段的查询方式应该统一（手动输入 、点选 、下拉选择）</p>
<p>　　4.6 出报表的时候，查询条件需要显示在报表标题的下面，这样看报表的时候知道数据的依据是什么</p>
<p>　　4.7 对于范围的查询采用全闭的形式（如 [2006-1-1,2006-12-30]）</p>
]]></content:encoded>
			<wfw:commentRss>http://jaunty.me/blog/2009/01/gui-test-guidelin/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
