1.传统软件测试过程中的问题

测试在所有的软件开发过程中都是最重要的部分。在软件开发过程中，一方面要求我们通过测试活动验证所开发的软件在功能上满足软件需求中描述的每一条特 性，性能上满足客户要求的负载压力和相应的响应时间、吞吐量要求；另一方面，面向市场和客户，开发团队还要满足在预算范围内尽快发布软件的要求。
传统的软件测试流程一般是先在软件开发过程中进行少量的单元测试，然后在整个软件开发结束阶段，集 中进行大量的测试，包括功能和性能的集成测试和系统测试。随着开发的软件项目越来越复杂，传统的软件测 试流程不可避免地给我们的工作带来以下问题：

问题一：项目进度难于控制，项目管理难度加大

如图一所示，大量的软件错误往往只有到了项目后期系统测试时才能够被发现，解决问题所花的时间很难预料，经常导致项目进度无法控制，同时在整个软件开 发过程中，项目管理人员缺乏对软件质量状况的了解和控制，加大了项目管理难度。

图1：传统测试流程中存在的问题

问题二：对于项目风险的控制能力较弱

项目风险在项目开发较晚的时候才能够真正降低。往往是经过系统测试之后，才真正确定该设计是否能够满足系统功能、性能和可靠性方面的需求。

问题三：软件项目开发费用超出预算

在整个软件开发周期中，错误发现的越晚，单位错误修复成本越高，如图二所示，错误的延迟解决必然导致整个项目成本的急剧增加。

图2：传统测试流程中存在的问题

成功经验二：连续测试

　　测试成功经验连续测试是从迭代式软件开发模式得来。在迭代化的方法中，我们将整个项目的开发目标划分成为一些更易于完成和达到的 阶段性小目标，这些小目标都有一个定义明确的阶段性评估标准。迭代就是为了完成一定的阶段性目标而从事的一系列开发活动，在每个迭代开始前都要根据项目当 前的状态和所要达到的阶段性目标制定迭代计划，而且每个迭代中都包括需求、设计、编码、集成、测试等一系列的开发活动，都会增量式集成一些新的系统功能。 通过每次迭代，我们都产生一个可运行的系统，通过对于这个可运行系统的测试来评估该次迭代有没有达到预定的迭代目标，并以此为依据来制定下一次迭代的目 标。由此可见，在迭代式软件开发的每个迭代周期我们都会进行软件测试活动，整个软件测试的完成是通过每个迭代周期不断增量测试和回归测试实现的。
采用连续测试的软件成功测试经验，不但能够持续的提高软件质量、监控质量状态，同时也使系统测试的尽早实现成为可能。从而有效的控制开发风险、减低测 试成本和保证项目进度。

成功经验三：自动化测试

在整个软件的测试过程中要想实现尽早测试、连续测试，可以说完善的测试流程是前提，自动化测试工具是保证。软件自动化测试工具的自动化测试成功经验主 要是指利用软件测试工具提供完整的软件测试流程的支持和各种测试的自动化实现。
为了使各种软件测试团队更好地进行测试，软件自动化测试工具在提供了测试成功经验之外，还为我们提供了一整套的软件测试流程和自动化测试工具，使软件 测试团队能够从容不迫地完成整个测试任务。
软件自动化测试工具主要为软件测试团队提供测试成功经验、自动化测试工具和全方位的咨询服务三方面的支持，最终实现：一个测试团队，基于一套完整的软 件测试流程，使用一套完整的自动化软件测试工具，完成全方位的软件质量验证，这正是软件自动化测试工具测试解决方案的精髓和终极目标。

易用性
考察评定软件的易学易用性，各个功能是否易于完成，软件界面是否 友好等方面进行测试，这点在很多类型的管理类软件中是非常重要的。
对于易用性测试可遵循以下原则：
1、完成相同或相近功能的按钮用Frame.框起来，常用按钮要支持快捷方式。
2、完成同一功能或任务的元素放在集中位置，减少鼠标移动的距离。
3、按功能将界面划分局域块，用Frame.框起来，并要有功能说明或标题。
4、界面要支持键盘自动浏览按钮功能，即按Tab键的自动切换功能。
5、界面上首先应输入的信息和重要信息的控件在Tab顺序中应当靠前，位置也应放在窗口上较醒目的位置。
6、同一界面上的控件数最好不要超过10个，多于10个时可以考虑使用分页界面显示。
7、分页界面要支持在页面间的快捷切换，常用组合快捷键Ctrl+Tab
8、默认按钮要支持Enter操作，即按Enter后自动执行默认按钮对应操作。
9、可输入控件检测到非法输入后应给出说明信息并能自动获得焦点。
10、Tab键的顺序与控件排列顺序要一直，目前流行总体从上到下，同时行间从左到右的方式。
11、复选框和选项框按选择几率的高底而先后排列。
12、复选框和选项框要有默认选项，并支持Tab选择。
13、选项数相同时多用选项框而不用下拉列表框。
14、界面空间较小时使用下拉框而不用选项框。
15、选项数较少时使用选项框，相反使用下拉列表框。
16、专业性强的软件要使用相关的专业术语，通用性界面则提倡使用通用性词眼。
17、对于界面输入重复性高的情况，该界面应全面支持键盘操作，即在不使用鼠标的情况下采用键盘进行操作。
对于易用性测试还可从以下几个方面入手：
1、导航测试
导航描述了用户在一个页面内操作的方式，在不同的用户接口控制之间，例如按钮、对话框、列表和窗口等；或在不同的连接页面之间。通过考虑下列问题，可以决 定一个应用系统是否易于导航：导航是否直观？系统的主要部分是否可 通过主页存取？系统是否需要站点地图、搜索引擎或其他的导航帮助？
在一个页面上放太多的信息往往起到与预期相反的效果。应用系统的用户趋向于目的驱动，很快地扫描一个应用系统，看是否有满足自己需要的信息，如果没有，就 会很快地离开。很少有用户愿意花时间去熟悉应用系统的结构,因此，应用系统导航帮助要尽可能地准确。导航的另一个重要方面是应用系统的页面结构、导航、菜 单、连接的风格是否一致。确保用户凭直觉就知道应用系统里面是否还有内容，内容在什么地方。
应用系统的层次一旦决定，就要着手测试用户导航功能，让最终用户参与这种测试，效果将更加明显。
2、图形测试
在应用系统中，适当的图片和动画既能起到广告宣传的作用，又能起到美化页面的功能。一个应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮 等。图形测试的内容有：
（1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间。应用系统的图片尺寸要尽量地小，并且要能清楚地说明某件事情，一般都链 接到某个具体的页面。
（2）验证所有页面字体的风格是否一致。
（3）背景颜色应该与字体颜色和前景颜色相搭配。
（4）图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩。
3、内容测试
内容测试用来检验应用系统提供信息的正确性、准确性和相关性。
信息的正确性是指信息是可靠的还是误传的。例如，在商品价格列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准确性是指是否有语法或拼写错 误。这种测试通常使用一些文字处理软件来进行，例如使用Microsoft Word的"拼音与语法检查"功能；信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口，也就是一般Web站点中的所谓"相关文 章列表"。
4、整体界面测试
整体界面是指整个应用系统的页面结构设计，是给用户的一个整体感。例如：当用户浏览应用系统 时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？整个应用系统的设计风格是否一致？
对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般应用系统采取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。对所有的可用性 测试来说，都需要有外部人员（与应用系统开发没有联系或联系很少的人员）的参与，最好是最终用户 的参与。

优秀设计和卓越设计之间的区别是比较小的。一般人可能无法解释说明卓越的设计的具体差别，但他们可以找到自己喜欢的网页设计作品。通过对照一下几个优秀作品，我总结了一下作为卓越设计的几个细节差别。

一、合理使用渐变
渐变不要滥用，更不要把渐变弄的跟彩虹似的，否则你的网页作品看起来比较外行。总而言之，合理的使用渐变对于优秀网站设计是有帮助的。

渐变、散景结合使用
Newism网站色彩丰富，但微妙的渐变与背景在视觉上结合的很到位。如果你也有兴趣在photoshop里面做这个散景效果，可以去Abduzeedo’s tutorial网站上面学习一下。

渐变、投影、纹理结合使用。
OnWired网站应用了这些设计技巧，显而易见，他的设计作品效果是很棒的！自始自终OnWired网站设计在应用渐变、投影、质感这方面是恰到好处 的。我也特别喜欢设计师设计的这些。

二、留白
留白一词往往容易被误解从字面解释 的空白。网页设计较 为准确的描述则是网页各个板块元素之间的空间范围。进一步分析看看A List Apart是如何定义它 的。
“留 白”对于网页设计是很重要的，留白不至于让你页面元素都堆积在一起。对于年轻设计师来说留白可能是一个大问题，他们在做设计的时候将整个页面放的满满 的，没有给页面足够的“呼吸空间”。这对于他们来说可能不是什么问题，如果内容放不下的话，他们可以借助浏览器的滚条来扩大页面的空间。

优秀的留白与巧妙的分割线
Snook网站布局方面设 计的是比较合理、舒服的。同时注意一下，网站里面的虚线将各个板块区分开了，这样我们在浏览网站的时候就一目了然了。

抽象图形
沙发采用抽象、美观、简约的方法。通过使用无背景或杂乱的图像，给浏览者的空间是流畅、舒服的。

三、网格布局
网页设计的网格布局最初的灵感是借鉴了报纸的排版。但是如果你仔细观察周围的事物都可以找到网格现象，从好的设计到生活中的交通网。
960和蓝图可能是两个最流行的网格布局。我个人比较喜欢960网格布局，它简单、重点 突出。你可以用任意对齐方式来安排你网站的元素，对齐在设计一个复杂的页面时，能使你的网站看起来比较精致、井然有序，并且你在网页布局里面添加任何模块内容时候都不用考虑其他的模块内容。

综合使用网格布局
Poccuo网站综合使用了网格布局，它采用3列和5列相结合的布局方式。给人以视觉吸引力和视觉空间。

博客采用列布局
我比较喜欢Web Design Ledger首页最上面的展现方式，他把最新的公告内容放大同时放到页面最顶部，其他的以3列的方式排列。

大量使用相等的列布局
Ecoki漂亮的网页布局显而易见采用的是4列、2行布局，同时幻灯片、缩略图、最新的审 查也是采用相同的方式。

四、改善字体应用
字体应用困扰着大多数的设计师。如果要想提高你的设计水平，字体在其中扮演着重要的角色。不但在可读性方面也扮演着重要的角色，同时还可以增加设计作品的 氛围。

用对比字体引起关注
SimpleBits网站在应用各种对比字体引导浏览者的注意力方面做的很棒。字体对比可以采取不同字体对比、各种颜色对比、字体大小对比等形式。

不要认为字体就像标志
这个网站看齐来就非常的漂亮、舒服，但你可以说出你的想法和感受来描述这个感觉。尤其在间距、字体选择等字体应用这方面做的挺完美的，我就被他的logo字体应用迷住了。

五、明确而有效的导航
良好的导航对于网页设计来说很重要，如果浏览者不能快速、便捷的找到它，他们就很有可能去别的网站了。这是我们所不愿意看到的，同时我知道 MyInkBlog进行了一些改进，并将在以后重新设计中进行彻底的改进。

博客导航下面显示分类导航
在大多数情况下，博客导航放在页面的同时将分类作为第二导航放在页面的边栏。Tutorial9做了一件了不起的事情，他把浏览者关心的photoshop资源以生动的方式展现出来了，并且在鼠标经过二级导航的时候有一个高亮效果。

切换不同的图标效果
图标切换效果在web2.0网页设计里面无论是否需要被大量、胡乱的应用，并且成为 一种趋势。并不是所有的都是不好的，web2.0里用的不好的原因是过度使用、业余使用造成的。在大多数情况下，适当的应用图标切换按钮是相当有效的。Carsonified网站在导航上就运用了单色、简洁的图标切换效果， 并且于他的网站整体感觉想吻合。

六、使用漂亮实用的页脚
一开始我们就将页脚作为次要的内容，在页脚里面放置一些没有多大用处的内容。在设计的时候仅仅花费一点点心思在它上面。现在页脚对于整体设计来说变的越来越重要了，千万别错过好的页脚完成你设计。

展示大量的信息和证书
这个页脚主要展示了网站介绍和版权等必要的信息。Brian Hoff网站更是添加了一些个性、有趣的内容在里面。通过3列布局方式展示了作者的工作和建议性的内容。

添加搜索功能
Elliot Jay Stock’s网站在底部添加了一个特大的搜索框…

来源: 菠菜博

　　误区之一：测试输入数据设计方法等同于测试用例设计方法

　　现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

　　这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试 用例设计人员把这种认识拿来要求自己，则害了自己;拿来教人，则害了别人;拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸 听”。

　　无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

　　在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段(里程碑)、测试用例组织方法(是否采用测试用例的数据库管理)等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标;根据用户使用环境确定测试环境;根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤;根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

　　误区之二：强调测试用例设计得越详细越好

　　在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好;测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

　　这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

　　编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

　　测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”(即执行这些测试用例的人员)，以及测试用例执行人员的技能和产品 熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试 用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

　　误区之三：追求测试用例设计“一步到位”

　　现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

　　这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

　　“唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断 细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用 例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

　　软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

　　误区之四：让测试新人设计测试用例

　　在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例?”。因为他(她)们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

　　让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

　　软件测试用例设计是软件测试的中高级技能，不是每个人(尤其是测试新人)都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

　　因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。

　　在日常需求的测试过程中，因为时间和资源的相对紧张，往往会遇到PRD不够细致，而UC描述也过于简单的情况，这个时候会让经验不够丰富的测试人员有种无从入手的感觉。其实由于思考方式、对需求的理解程度、开发和编写UC的经验、以及文字描述的习惯不同，开发人员首次提交的UC，并不一定能立即指导测试人员编写出一系列相对健壮的TC。

　　虽然说测试人员有权利退回需求不明的测试任务，但是在遇到“不得已而为之”的时候(比如紧急需求)，想办法解决问题，给出需求方建议总是好过什么都不做的退出测试。

　　因此需要在TC编写之前进行UC的评审，而UC的评审过程并不仅仅是一个需求再确认的过程，在评审之前测试人员就应该带着思考(类似于checklist)去尽可能的挖掘UC所覆盖到PRD的点以及所有自己的疑问，并且通过沟通尽早的解决疑问。

　　在这里，我个人想强调一下疑问，因为自己没有疑问并不代表真的没有问题，反而没有疑问才是最大的问题。谁都知道没有什么事物是绝对完美，包括开发人员编写的 UC，测试人员编写的TC，我们做测试不是要追求极致，但是至少要尽可能的降低因为遗漏问题而产生的风险，尽早的发现问题，解决问题。然而没有仔细的推敲和思考很难发现隐藏的问题，所以说没有疑问从某种程度上讲，是我们思考的还不够。举一个最为简单也是最为普遍的例子，我们一定都有过在编写TC过程中才发现有不确定的内容并向开发人员进行确认的经历，从某种角度讲，这就说明了UC的评审过程中，我们有遗漏。所以，只有充分的思考，才有可能捕获疑问，才有可能解决疑问，才有可能降低遗漏。

　　说完了疑问，在这里就不得不说一说思考，到底在UC评审之前我们应该思考些什么，或者说到底有哪些内容是我们需要去把握的，个人觉得可以从以下几点着手：

　　1. 如果说功能测试更多的是站在用户的角度进行测试，那么我们首先关注的必然是页面的展现。即页面的元素。一张好图胜似千言万语。这句话确实有其道理，所以界面原型图不仅能帮助开发人员省去很多文字上的描述，也避免了在测试过程中针对页面布局引起测试人员和开发人员争议，更能让测试人员建立一个整体的概念。因此，测试人员可以“提醒”开发人员提供demo截图，但是并不是每一份UC生成时都有充足的资源来获取demo。无论UC中是否有demo提供，我们真正应该关注的包括两点：一是页面包括哪些元素，是否覆盖了需求，有无冗余。再就是各元素的类型，比如列表、文本框，按钮等等。

　　2.在确定元素之后，就必须考虑元素对用户的开放性。即用户的访问、操作权限。一般而言，权限的控制往往有三种展现方式：一是通过页面元素的直接屏蔽使无权限的用户不可见，一是无操作权限用户使用时提示没有权限，还有就是对于没有权限的用户操作内容显示为不可用状态。测试人员必须确认UC中有该部分的描述，并确认具体属于哪种形式和其控制方式。否则在编写TC过程中就会出现遗漏，从而会导致bug的遗漏。

　　3.明确入口。由于web自身的特点，一个页面的访问往往会存在多个入口，每一个入口的前置条件都有可能不同，因此测试人员必须确认所有可到达的路径及其条件。

　　4. 在明确页面布局及元素、权限控制、入口后，我们就应该进一步了解一些具体的操作细节。例如结合demo图(如果有的话)，确定哪些是输入，哪些是输出。而在考虑这些输入和输出的时候我们不光要知道页面展现出来的输入、输出项，一些未展现出来的的输入、输出项，即隐藏的数据也是测试人员需要了解的。如注册用户，可能我们在页面上只需输入类似用户名、id之类的输入项，当成功后系统也只是提示操作成功，并返回注册的用户信息页面，而实际上，在注册成功的同时，数据库里不仅仅只是添加了用户所输入的信息，用户ID，用户创建的时间等信息都是系统自动生成但又不展现给用户的，尽管用户并不关心此类数据，但是测试人员必须了解并且跟踪这些数据。确保数据的正确创建。因为当错误的数据被调用时，就会引发一系列未知的问题。所以测试人员必须关心数据。

　　5.对于输入项，还应明确有无初始值、默认值设置。如果有，就应该考虑是不是需要与“重置”操作配合。此外，输入项有无输入控制，如果有，还应该确认对应的异常处理机制，包括提示信息的文案说明。

　　6.对于输出项(返回项)，首先要明确具体有哪些输出，其次需要明确是返回当前页面的操作，还是新窗口。若为前者，就需要考虑输出后是否影响输出前的操作; 若为后者，还需考虑是否能从该页面返回原窗口等等。

　　7.除了关注页面展现，测试人员还应该明确需求实现中涉及的所有表结构，包括表之间的关系。通过表关系，可进一步考虑本次需求可能会影响到的其它需求。并通过比对页面元素，了解页面展现和具体表结构的对应关系，从而确定是否有遗漏和冗余。

　　当然，以上这几点可能还很不完整，仅仅是我在近期的日常需求测试过程中的一点感悟，还需要我在实践的过程中去补充和修正，当然也欢迎大家一起来修正。

　　其实，个人认为带着思考去评审UC或者是编写tc，绝对不止是确认需求和描述自己的操作步骤，通过在跟开发人员的沟通过程中，引导他们一起去思考和去检验自己的代码，其实也是在测试，这样的行为可以说大大的提高了测试的效率，因为很多问题在测试人员开始执行测试之前都已被开发人员所修正，如此一来，在执行测试的时间里，测试人员就可以更好地聚焦于业务逻辑层的实现，使得测试更为充分。从某种角度讲这也是缺陷的预防。当然，缺陷预防的路还有很长，但是我们不用害怕和沮丧，一点点做起来，一步一个脚印的走下去，目标总会近，如果我们每个人再加把劲，多多分享和共享，那么我相信，我们的团队会走的更快、更好。

       关于网页UI,UE之类的论点文章网上太多了,更多大师将这些分析到极致,无论是开发领域还是设计领域,这些真正的大师所发表的文章都从不卖弄自己,更多的分析而无私的供献自己的独道见解,他们所写博文与其它政治、娱乐、商业等领域所发表的博文完全不同类型，我不是大师，但我很崇拜大师。

　 一个页面最醒目最吸引用户的应该是Banner了，尤其是Web2.0平台Banner显得更突出，Banner主要体心意旨，形象鲜明的展示所要表达 的内容。因为它醒目，所以放一个很糟蹋的Banner上去效果也当然“醒目”了。因此网页Banner设计在这里起到了至关重要的作用，特别是首页的 Banner,直接决定了用户的停留，下面让我们通过大量优秀的案例进入Banner，走进大师们的灵感世界。

1.大面积的Banner

http://www.tearoundapp.com/
这个Banner非常直接的采用了一个很大的iPhone图片，用户几乎不用思考的就知道网站的大概内容，而且加上与产品类似风格的功能按钮直接展示了部分功能，大的Banner最直接最醒目，处理也最需要谨慎，否则事关功倍。

其它类似Banner

2.文字与图片1/2比例

http://www.scrapblog.com/
这种Banner不是很大，虽然文字与图片占居空间相等，但加上大的Button让文字内容相对比较醒目，这种Banner的处理重点在于背景与和图片和文字的协调，比例要均匀。

其它类似Banner

3.人物与文字

http://www.showandtellsale.com/
采用人物加文字内容,让主题思想显得更鲜明活动,人物可以更直接更友好的告诉用户这里有什么?

其它类似Banner

4.创意矢量图形

http://ideafoundry.info/
纯鼠绘而且的矢量CG图形，独特创意和视觉冲击，精致的矢量风格与网站整体完美结合，体现出网站整体实力。

其它类似Banner

5.软件产品界面

http://bydreamtime.com/
大凡软件产品服务网站都将自己的产品界面直接融合在Banner中,加上文字与个性Button,可以让用户直接深入的了解产品基本功能和构造,甚至会激起用户想立即试用的欲望。

其它类似Banner

6.线条与光线

http://www.scarbantia-art.hu/
渐变的背景在融入线条元素，让Banner更加动感夺目，单色或多色的光线让线条和背景更加炫彩，使Banner充满迷幻进一步刺激用户的探索欲望。

其它类似Banner

7.纯文字内容的Banner

不需要华丽的背景,更不需要图片的点缀,只需要一段文字加上单调的背景色….

http://enviramedia.com/

其它类似Banner

      由于时间有限更多经典案例没来得及整理和未被发现,不同类型的网站搭配不同类型的Banner，Banner的主要功能到底是诱导用户，还是展示形象，还是刺激神经，这些观点都有它的支持者，所有Banner的核心共同点是让用户在短时间内将鼠标滑上去点击。做到这一点，设计人员还需要好好的琢磨。

测试报告编写指南

摘要

测试报告是把测试的过程和结果写成文档，并对发现的问题和缺陷进行分析，为纠正软件的存在的质量问题提供依据，同时为软件验收和交付打下基础。本文提供测试报告模板以及如何编写的实例指南。
关键字

测试报告 缺陷

正文
测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。
下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。
PARTⅠ 首页
0.1页面内容：
密级
通常，测试报告供内部测试完毕后使用，因此密级为中，如果可供用户和更多的人阅读，密级为低，高密级的测试报告适合内部研发项目以及涉及保密行业和技术版权的项目。
XXXX项目/系统测试报告
报告编号
可供索引的内部编号或者用户要求分布提交时的序列号

部门经理 ______项目经理______
开发经理______测试经理______

XXX公司 XXXX单位 （此处包含用户单位以及研发此系统的公司）
XXXX年XX月XX日
0.2格式要求：
标题一般采用大体字（如一号），加粗，宋体，居中排列
副标题采用大体小一号字（如二号）加粗，宋体，居中排列
其他采用四号字，宋体，居中排列
0.3版本控制：
版本 作者 时间 变更摘要
新建/变更/审核

PARTⅡ 引言部分

1.1编写目的
本测试报告的具体编写目的，指出预期的读者范围。
实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。
提示：通常，用户对测试结论部分感兴趣，开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。此部分可以具体描述为什么类型的人可参考本报告XXX页XXX章节，你的报告读者越多，你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得浪费一点时间去关注的。
1.2项目背景
对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。
1.3系统简介
如果设计说明书有此部分，照抄。注意必要的框架图和网络拓扑图能吸引眼球。
1.4术语和缩写词
列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。
1.5参考资料
1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的东东。
2．测试使用的国家标准、行业指标、公司规范和质量手册等等
PARTⅢ 测试概要
测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）
2.1测试用例设计
简要介绍测试用例的设计方法。例如：等价类划分、边界值、因果图，以及用这类方法(3-4句)。
提示：如果能够具体对设计进行说明，在其他开发人员、测试经理阅读的时候就容易对你的用例设计有个整体的概念，顺便说一句，在这里写上一些非常规的设计方法也是有利的，至少在没有看到测试结论之前就可以了解到测试经理的设计技术，重点测试部分一定要保证有两种以上不同的用例设计方法。
2.2测试环境与配置
简要介绍测试环境及其配置。
提示：清单如下，如果系统/项目比较大，则用表格方式列出

数据库服务器配置
CPU：
内存：
硬盘：可用空间大小
操作系统：
应用软件：
机器网络名：
局域网地址：
应用服务器配置
…….
客户端配置
…….

对于网络设备和要求也可以使用相应的表格，对于三层架构的，可以根据网络拓扑图列出相关配置。
2.3测试方法(和工具)
简要介绍测试中采用的方法(和工具)。
提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。
PARTⅣ 测试结果及缺陷分析
整个测试报告中这是最激动人心的部分，这部分主要汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过程度量或者相对较小的项目，例如用于验收时提交用户的测试报告、小型项目的测试报告，可省略过程方面的度量部分；而采用了CMM/ISO或者其他工程标准过程的，需要提供过程改进建议和参考的测试报告－主要用于公司内部测试改进和缺陷预防机制－则过程度量需要列出。
3.1测试执行情况与记录
描述测试资源消耗情况，记录实际数据。（测试、项目经理关注部分）
3.1.1测试组织
可列出简单的测试组架构图，包括：
测试组架构 （如存在分组、用户参与等情况）
测试经理（领导人员）
主要测试人员
参与测试人员
3.1.2测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如 XXX子系统/子功能
实际开始时间－实际结束时间
总工时/总工作日
任务 开始时间 结束时间 总计
合计
对于大系统/项目来说最终要统计资源的总投入，必要时要增加成本一栏，以便管理者清楚的知道究竟花费了多少人力去完成测试。
测试类型 人员成本 工具设备 其他费用

总计
在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间，还可以算出每一个功能点所花费的时/人。
用时人员 编写用例 执行测试 总计

合计
这部分用于过程度量的数据包括文档生产率和测试执行率。
生产率人员 用例/编写时间 用例/执行时间 平均

合计
3.1.3测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
3.2覆盖分析
3.2.1需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
需求/功能（或编号） 测试类型 是否通过 备注
[Y][P][N][N/A]
根据测试结果 ，按编号给出每一测试需求的通过与否结论。P表示部分通过，N/A表示不可测试或者用例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
需求覆盖率计算 Y项/需求总数 ×100％
3.2.2测试覆盖
需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因

实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
测试覆盖率计算 执行数/用例总数 ×100％

3.2缺陷的统计与分析
缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。
3.3.1缺陷汇总
被测系统 系统测试 回归测试 总计

合计
按严重程度
严重 一般 微小

按缺陷类型
用户界面 一致性 功能 算法 接口 文档 用户界面 其他

按功能分布
功能一 功能二 功能三 功能四 功能五 功能六 功能七

最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。

图例
3.3.2缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率 ＝ 缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量 ＝ 缺陷总数/测试用例总数 ×100％
缺陷密度 ＝ 缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向

重要缺陷摘要
缺陷编号 简要描述 分析结果 备注

3.3.3残留缺陷与未解决问题
残留缺陷
编号：BUG号
缺陷概要：该缺陷描述的事实
原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：与预期结果的偏差
缺陷：具体描述
评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
PARTⅤ 测试结论与建议
报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
4.1测试结论
1． 测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2． 对测试风险的控制措施和成效
3． 测试目标是否完成
4． 测试是否通过
5． 是否可以进入下一阶段项目目标
4.2建议
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议

测试报告的内容大同小异，对于一些测试报告而言，可能将第四和第五部分合并，逐项列出测试项、缺陷、分析和建议，这种方法也比较多见，尤其在第三方评测报告中，此份报告模板仅供参考。

参考文献
《实用软件测试方法与应用》 电子工业出版