Tag/
共93个网摘 [
1 2 3 4 ]
下一页 |
mayafree收录，使用标签：使用, Visual, Studio, 2005, Team, System, 进行单元测试并生成用于, Unit, Test, Framework, 的源代码，时间：2008-8-26 16:34:07 | 相关网摘，我也收藏
http://blog.csdn.net/yesbar/archive/2006/04/25/676351.aspx
tonywjd收录，使用标签：test, eclipse, plugin，时间：2008-7-5 13:48:52 | 相关网摘，我也收藏
This tutorial provides a brief introduction to the Unit Tester product of the AppPerfect DevTest4J using a set practice exercises. This tutorial assumes you have successfully downloaded and installed AppPerfect DevTest4J on your machine with the default options. Apart from this pre-requisite, this tutorial is self contained. Instructions given below are Windows-specific; if you are using a non-Windows machine, please use equivalent commands/instructions.
http://www.appperfect.com/support/tutorials/tutorial_plugin.html
AppZ收录，使用标签：test, collect，时间：2008-7-3 14:55:53 | 相关网摘，我也收藏
利用单元测试检查PHP代码
发布时间: 2008-7-03 13:09 作者: 未知 来源: 网络转载
字体: 小 中 大 | 上一篇 下一篇 | 打印 | 我要投稿 | 每周一问，答贴有奖
测试驱动的开发和单元测试是确保代码在经过修改和重大调整之后依然能如我们期望的一样工作的最新方法。在本文中，您将学习到如何在模块、数据库和用户界面（UI）层对自己的 PHP 代码进行单元测试。
Web 应用程序是 24x7 不间断运行的，因此我的程序是否还在运行这个问题会在晚上一直困扰我。单元测试已经帮我对自己的代码建立了足够的信心 —— 这样我就可以安稳地睡个好觉了。
http://www.51testing.com/html/200807/n86581.html
seven2000收录，使用标签：test，时间：2008-5-28 3:02:43 | 相关网摘，我也收藏
软件测试，特别是测试自动化技术属于当前国际软件界最有争议，亟待发展的技术。所谓自动化测试就是希望能够通过自动化测试工具或其他手段，按照测试工程师的预定计划进行自动的测试，目的是减轻手工测试的劳动量,从而达到提高软件质量的目的。
测试工具
在进行测试活动时，采用合适的测试方法和相对应的自动化测试工具是至关重要的。
1．静态分析工具
静态分析工具的特点是一种直接对代码进行分析，不需要运行代码，也不需要对代码编译链接，生成可执行文件，从中寻找可能导致错误的异常情况的测试工具。静态测试工具一般是对代码进行语法扫描，找出不符合编码规范的地方，根据某种质量模型评价代码的质量，生成系统的调用关系图等。
● 静态确认工具
对源程序进行静态分析和确认，从而发现某些常见的错误。这样的测试工具还能进行不可靠结构的检查，识别出可疑的易出错的结构，并进行危险变量的监视。
● 符号执行工具
以符号值作为程序的输入，使程序符号执行。系统可以“穷尽”测试符号的选择，以便能自动或者交互地检查符号执行树的每条路径，并自动对输出结果与输出断言进行比较，一般说来，这样的符号执行系统都具有交互式纠错功能，包括跟踪断点设置、状态存储等。
● 程序验证工具
交互式程序验证系统，是程序正确性证明的一个工具。输入源程序和程序断言；输出是对程序正确性的一个判断，即程序执行结果是否必定满足断言的要求。系统可自动产生程序中的断言，系统的内部实现基于符号逻辑变换和结构归纳。
2．动态分析工具
动态分析工具的主要功能是分析被测程序逻辑中每个语句的执行次数。动态分析工具与静态分析工具不同，动态分析工具一般采用“插桩”的方式，向代码生成的可执行文件中插入一些监测代码，用来统计程序运行时的数据，其与静态分析工具最大的不同就是动态分析工具要求被测系统实际运行。
● 覆盖监视工具
这样的工具系统可在程序逻辑的适当位置安插一些“探测器”，以便对程序进行监视，产生带统计数字的报告。使用该工具可以测试出没有执行的语句，以便增加相应的测试数据。
● 驱动工具
采用自底向上渐增方式测试时需要编写许多虚构的驱动模块。驱动工具可以免除人们编写驱动模块的负担。它提供一种测试语言来写测试过程，表明要测试的模块、使用的测试用例、预期的输出等。这样不再需要人工编写任何驱动程序，系统能自动把输入数据传送给被测模块，并负责将实际输出结果与预期的结果相比较。
● 测试数据产生工具
这是帮助自动选择测试用例的工具。这样的系统利用一个存放程序各种“素材”的共用信息库，使测试人员能用命令方便地定义测试用例，并在适当的时候自动运行这些测试用例。而当被测程序修改后系统能自动个性测试用例，以保持这些测试用例的可用性。此种工具对于测试系统在实际环境中的性能以及测试一个数据库的管理系统时比较方便。
● 符号查错工具
此工具提供屏幕显示功能，显示程序的动态执行情况，或者在程序执行中断时，显示程序执行的当前状态的历史信息，以便进行检查和修改。这样的查错系统，实际上为程序提供了一个执行的环境，能够跟踪监视和控制程序的执行。系统界面以查错命令方式交互工作，系统实现依赖于程序执行的历史记录。
3．综合测试评估工具
把静态分析、动态分析、测试评估等综合在一起，测试人员可以用命令来控制系统执行不同的测试工具，各工具模块之间的通信通过数据库来实现。一个可行的简单办法是建立一组测试工具，或者叫做测试工具库。这些工具可能都是相互独立设计的，彼此间没有什么联系，但都能从某一侧面对程序进行测试，任由用户选择使用。
测试脚本
在测试过程中，测试脚本起着关键的作用。每种脚本技术在支持脚本完成测试事例的时间和开销上都有各自的长处和短处。对于软件测试来说，使用哪种脚本技术并不是最主要的，脚本所支持的实现测试事例体系的整体考虑才是最主要的。
1．线性脚本技术
线性脚本是录制手工执行的测试事例得到的脚本。这种脚本包括所有的击键、功能键、箭头控制测试软件的控制键及输入数据的数字键。如果用户只使用线性脚本技术，即录制每个测试事例的全部内容，则每个测试事例可以通过脚本完整地被回放。几乎任何可重复的操作都可以使用线性脚本技术实现自动化。
2．结构化脚本技术
结构化脚本类似于结构化程序设计，结构化脚本中含有控制脚本执行的指令，这些指令或为控制结构或为调用结构。所有测试工具脚本语言支持三种基本控制结构。第一种形式为“顺序”脚本（即前面介绍的线性脚本）。另外两种控制结构形式的脚本为“选择”或“叠代”。选择控制结构使脚本具有判断功能，最普通的形式是“if”语句判断条件为真或为假; 叠代控制结构可以根据需要重复一个或多个指令序列，有时也将这种结构称为“循环”。
除控制结构外，一个脚本可以调用另一个脚本，即将一个脚本的控制点转到另一个子脚本的开始，执行完子脚本后再将控制点返回到第一个脚本。这种机制可以将较大的脚本分为几个较小的易于管理的脚本。
结构化脚本技术的主要优点是健壮性更好；可以执行许多其他类似的功能，如需要重复的指令可以使用循环结构;还可以作为模块被其他脚本调用。其缺点是使用脚本变得更加复杂，而且测试数据仍然“捆绑”在脚本中。
3．共享脚本技术
共享脚本是指脚本被多个测试事例使用。这种技术的思路是产生一个执行某种任务的脚本，而不同的测试要重复这个任务，当要执行这个任务时只需在每个测试事例的适当地方调用这个脚本。这样将带来两个好处: 第一，可以节省生成脚本（编写或录制指定的操作）的时间。
pZ{ _F L0 第二，当重复任务发生变化时，只需要修改一处脚本。
共享脚本以比较小的开销实现相似的测试用例，结构性好、模块性强、维护成本低于线性脚本，它适合于小型系统或大型应用中的一小部分测试。但是由于每个测试仍需要一个特定的测试脚本，因此维护成本仍然比较高。
4．数据驱动脚本技术
数据驱动脚本技术将测试输入存储在独立的数据文件中，而不是存储在脚本中，脚本中只存放控制信息。执行测试时，从文件中而不是直接从脚本中读取测试输入。这种方法的最大好处是同一个脚本可以运行不同的测试，另一个优点是数据文件的格式对于测试者而言易于处理。
测试的初始建立需要花费一定的时间，然而对于大系统，由于生命周期较长并且改动频繁，使用这个方法，所获得的收益将远远超过所花费的开销。
5．关键字驱动脚本技术
数据驱动技术要求每个测试用例执行的导航和操作必须一样，测试的逻辑知识建立在控制脚本和数据文件中，两者需要统一。如果允许控制脚本支持广泛的测试用例，那么就会增加数据文件的复杂性。这样，就使测试用例自动化变得非常困难。
关键字驱动技术则是将数据文件变为测试用例的描述，用一系列关键字指定要执行的任务，这些关键字存在于测试文件中。解释这些关键字则需要另外的支持脚本。控制脚本读取测试文件中的关键字，并通过关键字调用相关的支持脚本，这样，测试软件或特殊应用对控制脚本的约束将大大减小。这种测试方法有利于当测试工具发生改变时，不需要改变测试用例，只要更新实现测试用例的支持脚本即可。
http://www.51testing.com/?143131/action_viewspace_itemid_65712.html
seven2000收录，使用标签：test，时间：2008-5-28 3:00:51 | 相关网摘，我也收藏
自动化测试是遥不可及的？
对于许多中小型软件企业来说，自动化测试仿佛是一个遥不可及的梦想。一提到自动化测试总是会联想到昂贵的自动化测试软件和费时费力的测试程序编写与调试。而即便下狠心投入了大量的人力物力，所收到的效果也很难说一个“值”字。于是纷纷认为，就现阶段来说，自动化测试根本行不通。
那么自动化测试到底是不是真的不适合中小企业呢？其实关键不在自动化测试本身，而在于如何经济有效的应用它。
首先应当明确的是对于企业来说需要什么样的自动化测试？
自动化测试的目的
自动化测试给人的第一个印象就是替代手工测试。这也许可以算作软件测试的最高理想，但绝无实际价值。就算不谈这种测试软件的成本，就单从技术上来讲，这种软件所需要的人工智能也不是这一个世纪所能开发的出来的。
当前自动化测试的真正目的是提高软件测试人员的工作效率。并且将软件测试人员从一些繁琐的简单劳作中解脱出来，让他们真正发挥他们的专业知识和创造性。
所以只要有简单重复劳动的地方就有自动化测试的用武之地。
那些测试可以自动化
明确了自动化测试的目的，自动化测试就不再是一个抽象的技术或工具了。针对不同的企业，不同的产品，不同的测试计划，需要自动化的部分也不相同。可以是每一个BUILD间的自动重复测试，可以是具体组件或函数的各个输入数据自动生成，也可以是同一个测试用例在各个测试平台的各种配置上的自动重复测试。
总的来说，只要是测试人员觉得繁琐的事，往往就是自动化测试的好方向。
开展自动化测试的常见错误
中小企业在试图开展自动化测试时常犯的两个错误是（许多大企业也会遇到同样的问题）：
1）购买或试图使用一些针对性不强的通用自动化测试软件。
最后往往不是让自动化测试为自己服务，而是最后去迁就自动化测试软件。往往花了很多精力搞的自动化测试完全游离在计划的测试之外，基本对完成最初的测试计划没有实质性的帮助。
2）在自己开发测试自动化软件时缺少必要的资源，或开发目标不够实际。
有些企业用一些缺少编程经验的测试人员开发、维护自动化测试软件，往往造成开发时间过长，软件质量问题过多等弊端。
另一些企业要么编出的自动化软件灵活性过差，只能使用一小段时间。要么就把摊子铺得过大，等自动化软件能用的时候已接近产品发布了。
降低自动化测试的成本
开展自动化测试，首先要围绕着测试计划，将计划中的测试分成三类：
1）不适合自动化测试的。
2）需要专门的、或一次性的测试自动化工具。这一部分可以视其开发难度安排合适的人员自行开发。必要时可以找开发部门的人员帮忙。
3）通用性较强的自动化测试。这一部分对几乎任一企业来说，独立开发都是不太有必要的。最佳的选择应当是外包给专业的自动化测试开发机构。因为专业测试机构一方面可以有较长时间积累相关的函数库及各种必要的工具软件，另一方面可以依靠熟练完整的开发团队在较短的时间内完成自动化测试的开发。更重要的是由于这些自动化测试的通用性较强，专业自动化测试开发机构可以将部分开发成本平摊到多个相似的企业，所以变相的降低了自动化测试的成本。
当然，当前国内这样的自动化测试机构还很少（如果不是没有）。但这是软件测试发展的必然方向。只要能给它们一定的扶持，自动化测试就不再是遥不可及的了。
http://bbs.51testing.com/thread-525-1-23.html
seven2000收录，使用标签：test，时间：2008-5-28 2:45:15 | 相关网摘，我也收藏
一篇翻译的文章, 原文找了半天没找到链接.
其中比较有启发的段落摘抄一段:
Changes to the intervening code（对介入其间的代码进行变化）
介入其间的代码是导致测试死亡的主要因素。而且用户图形界面接口较上文提到的那个接口和一些硬件驱动接口相比更是这个样子。例如：假设用户接口要求你输入电话号码，但是现在变化为要求提供一个电话按键区的视觉表现。这时你要使用鼠标敲击号码模拟使用真实的电话。（这是个非常愚蠢的主意，但是这怪异的事情已经发生了。）尽管接口传给了code under test一个正确的值，但是用户界面的变化很可能破坏一次自动化测试，是因为很可能使用者再没有地方输入电话号码了。
就像另外的一个例子，一个输入的错误用户界面会用其它的方法来告诉用户。它可能会刷新主窗体使其显示红色同时发出特殊的声音来代替弹出的提示信息来告知你不能完成这次操作。但是，如果你的测试是通过测试是不是弹出提示信息来判定的，那么将视这种正常的运行为一个bug。很显然这个测试就没有效果了。
"Off the shelf "测试自动化工具能做避免测试死亡的有限制的工作。例如：大多数的GUI自动化测试工具都可以忽视文本框大小、位置和颜色的改变。从而把握像上面两段所提到的那些大的改变，但是需要事先定制。这需要在你的工程中有一些人去创建test libraries。这样就要求你，一个测试人员，在编写好测试的特殊术语，尽可能多的忽略用户接口的细节。例如，你的自动化测试可能包含这样一行定制的信息：try 217-555-1212 try是test library程序，它的作用是将电话号码翻译成接口可以知道的术语。如果用户界面接受在输入框中输入字符，try会在其中输入电话号码。如果需要通过显示在屏幕上的特定图形区域键入电话号码时，try也会做到。
test library 可以有效地将那些不相关信息过滤掉。这样我们就可以详细的准确的测试那些与功能相关的数据。在输入上，增加这些附加信息是intervening code所必须的。在输出上，它们将intervening code中的信息全部压缩到一个很重要的模块中，其中的信息实际上可以当作是Code Under Test的一个延伸。这种过滤可以用左图来描述：
多数用户界面的变化不会需要对测试做更改，而只需要对test library做相应的修改。应为test Code要比library Code多的多，所以只修改library Code的代价会很低。
但是，尽管我们有更好的补偿性的代码也不可能将测试从所有的变化中隔离出来。它仅仅是尽可能的去预期所有的事情。所以其中有很多可能性，将来很可能出现一些问题破坏你的测试。你必须问自己这样一个问题：
在变化中Intervening Code会把测试保护到什么程度?
你需要估计intervening Code的改变对测试造成影响的可能性。要保证用户界面永远的不会改变是一件不可能的事情，这就使你需要不停的改变自动化测试的脚本以保证测试可以自动的执行。（我不会相信界面冻结后永远不会变化，除非manager答应如果以后每做一个新的修改将会给我100美元）
如果变化是可能的，你一定会被询问对你的test Library保护你的测试不受其影响正常执行有多大的信心。如果说test Library不能保护测试，那么起码它可以很容易的做出改动以适应变化。如果花费一个半小时的时间可以拯救300个测试，那么所做的一切是值得的。但是，小心：很多人往往低估了维护test Library的困难，特别是在变化后需要手工的对测试test Library进行反复的修改。不应该马上就放弃，抛弃所有的测试类和test Library，从头开始，因为很可能只需要简单的修改就可以完成需要的测试。
如果你没有test Library——如果你正在使用自动化GUI测试工具来捕获和重放模式——你不要期待会有任何保护。一次对界面的修改会让你的大部分的测试“死亡”。往往不会有足够的时间来允许我们完成对发生变化的测试进行修改，我们不得不在少的花费和短的生命生存期之间做出选择。
http://bbs.51testing.com/thread-534-1-1.html
seven2000收录，使用标签：test，时间：2008-5-28 2:41:36 | 相关网摘，我也收藏
自动化冒烟测试脚本应当遵循的原则
自动化冒烟测试脚本应当遵循的原则：
1、覆盖主要功能；
冒烟测试不是系统测试或集成测试，所以不需要面面俱到，重点放在保证主要功能或主要业务路径执行正常；
2、易用性；
既然是自动化测试脚本，那么最好的状况是只输入一个命令可以就搞定，不要再让执行人员做各种配置；为了达到这个目的，可能会导致一定的冗余，但是值得，这会降低在冒烟测试阶段的成本。此外，测试结果要清晰明了，成功多少用例，失败多少用例，用例失败的原因，以及出现的异常信息，最好都可以一目了然。
3、引入工程的概念；
独立的测试脚本，如果没有统一的调用管理，则不可能满足易用性的需求；所以，应当引入工程的概念，使用类似TestSuite的概念以管理测试脚本的执行；
4、测试脚本要独立；
也就是经常说到的“高内聚，低耦合”的思想，每个测试脚本要尽可能的独立，执行过程不需要依赖其它测试脚本（lib除外）。此外，每个测试脚本（用例函数）覆盖的测试点要尽可能的单一，不要将多个测试点放到同一个脚本（用例函数）中执行；这样的好处是在功能变更后，修改相应的测试脚本时，对其它测试点的测试执行没有影响，同时，也可以保证在执行冒烟测试过程中，不会因某一个用例没有通过，而导致之后的用例无法继续执行；
5、测试脚本要简单
测试脚本编码要尽可能的简单，如果说测试脚本写的很复杂，那么就需要先测试自己的测试脚本的正确性了，否则，无法保证当冒烟测试过程出现问题后就肯定是被测产品的问题。而对测试脚本的测试是要耗费多余的成本的，不太现实，因此测试脚本要尽可能的简单，从复杂程度上避免测试脚本出现bug。
6、维护必要的文档
一整套的自动化冒烟测试脚本本身也是一个产品，尤其当其以工程的方式管理时，所以必要的文档是必不可少的，要有简单的设计、架构文档，更新日志。如果没有这些文档的话，发生测试人员变更时，新的测试工程师就惨了，只有两条路可选，一是一点一点的看测试代码以搞清测试脚本是如何执行的；二是重新做一个新的测试脚本框架出来；这两种方式成本好像都很高啊。
7、测试结果收集
每一次的测试结果都要留存，对比一段时间内的测试结果，可以知道产品那些功能点质量不稳定，如果同一个测试点在一段时间内经常不能够测试通过，那么这一部分的代码十分有必要进行review，及可能存在更大的隐患。
上面说的原则不只适用于冒烟测试，其实对自动化的回归测试脚本开发也同样适用。
相信有人会说，为什么一个自动化测试还要搞得这么麻烦，还整出些原则来。其实，作为一名测试管理者来说，一方面要考虑提高测试质量，另一方面也要考虑测试成本，像冒烟测试和回归测试这样重复性较强的工作，若没有一个高效合理的自动化测试框架来执行，单靠手工来完成，成本是相当高的，尤其是对一些发布较频繁的产品；同理，如果自动化测试框架不是很合理，执行过程总是需要过多的人工参与，成本同样会很高。测试成本若是降下来了，那么我们就有更多的人力去做其它的事情，生产力就提上去了.
都是自己的一些经验总结，欢迎大家来讨论。
http://bbs.51testing.com/thread-108997-1-6.html
seven2000收录，使用标签：test，时间：2008-5-28 2:05:53 | 相关网摘，我也收藏
GUI测试现状
GUI测试的研究现状及成果：
（1）基于CIS的测试用例生成方法
Case Western Reserve University的Lee White博士在2000年，提出基于CIS脚本转换器来生成完整交互序列测试用例。
优点：能记忆和回放用户操作，减少重复劳动。
缺点：只能被动捕获执行信息, 缺乏交互性。
（2）基于对象建模的GUI测试
北京大学的王立福教授在2000年，提出一种界面类对象建模技术，体现了对象的封装、通信、动态特征。
优点：使得界面对象易于识别。
缺点：GUI测试用例的覆盖程度不够理想
（3）基于界面构件关联图的测试方法
浙江大学的谭建荣教授，2002年提出界面构件关联图,利用构件的相互关系, 提出测试覆盖准则和测试用例生成方法。
优点：有较好的交互关系和覆盖准则
缺点：关联提取复杂，导致关联图冗余
（4) 基于EFSM的GUI测试方法
复旦大学的钱乐秋教授，在2003年提出基于扩展有限状态机测试中测试输入数据自动选取的研究，方便了测试人员从中手工选择测试数据
优点：减少FSM的简单状态冗余。
缺点：EFSM 到 FSM 的转化难以优化。
对于广泛使用的图形用户界面(GUI)系统,其功能测试中测试用例的获取仍主要依赖于软件与其运行环境之间的界面,存在如下问题：
(1)仅凭软件的界面信息,难以评价测试的正确性。
(2)由于不了解系统运行的真实流程,因此无法判定系统实际运行中的实际路径,难以判断测试用例的覆盖程度。
(3)测试中随意性较大,不能判断测试过程何时结束。
http://bbs.51testing.com/thread-3044-1-1.html
seven2000收录，使用标签：test，时间：2008-5-28 1:57:49 | 相关网摘，我也收藏
GUI的自动化测试的三种类型
GUI的自动化测试可以由简入难分成三种类型：
1）纪录回放类：
这一类不需要太多的计划，编程和调试。优点在于简单，方便。缺点在于稳定性差，所以脚本运行寿命短，而且与不同配置的兼容性差。同时由于缺少结果的验证部分，基本上找不到什么Bug。可考虑在产品开发接近尾声时，用于尚未自动化的已知Bug的回归检验。
2）测试用例自动化类：
这一类是指将需要反复测试或在多种配置下重复测试的用例自动化。基本实现过程通常为：
- 设计测试计划
- 设计测试用例
- 针对每一个用例评估自动化的可行性和经济性
- 将决定要自动化的用例作详细步骤分解。
- 编写公用步骤，公用资源库（Logging 和 exception handling 部分是必不可少的）
- 编写自动化程序 （别忘了结果的验证部分）
- 调试
- 实际运行
这一类自动化测试最为灵活，也能发现较多的Bug。又能较好的与测试计划相协调。当前多数测试做的比较好的企业都主要使用这种类型的自动化。
3）自动测试类：
这一类是指自动生成测试用例并自动运行。这类自动化测试的最大的优点在于它的无限可能性。另外它通常能发现手工测试极难发现的错误。而且一旦实现了这种自动化，其维护费用实际上是大大低于前两类测试的。不过这类测试自动化的初始投入非常高，而且它的效果受其智能化程度的制约也非常大。除非是专业测试公司或是象微软、IBM这类超大型企业，多半都没有实力来研究这类测试自动化。
不过从长远来说，只要有较好的工具能将这类自动化的初始投入降下来，这类测试自动化才是软件测试发展的必然方向。
这一类测试的基本实现过程通常是：
- 购买或开发基本测试自动化框架
- 编写必要的接口，钩子，及其他公用资源。
- 建立软件、组件、或功能的行为模型
- 设立测试目标等参数
- 自动生成测试用例及测试计划
- 筛选并运行测试用例
- 评估结果
http://bbs.51testing.com/thread-562-1-1.html
seven2000收录，使用标签：test，时间：2008-5-28 1:55:50 | 相关网摘，我也收藏
GUI测试的工具有很多，他们的原理基本上都相同。通过一个系统级别的钩子（hook）监视您的测试执行过程，并且记录下来，这是捕捉过程；在下次测试时将其记录的消息发送出去就完成了回放过程。理想的情况下，在测试过程中如果将所有的操作都记录下来，当测试人员操作过程中发现问题，需要重现一下，只要将系统恢复到操作以前的状态，然后回放已经记录的测试过程，运气好问题应该就会重现了。但是实际上，并不是这么简单，因为工具记录的只是机械的操作，而测试人员在实际测试时是带有思想在进行测试的。比如测试人员做某个操作，发送命令之后，等待系统返回执行结果，系统返回一个成功的对话框，测试人员将对话框关闭了；此时工具记录的只包括测试人员构造数据发送命令的过程以及关闭对话框的过程，但是测试人员等待的过程工具并不理解，工具只是记住我们那时候可能等待了2秒，为什么是两秒，工具就不知道了。如果测试人员拿这种脚本进行回放，往往不能达到我们的目标，因为工具在等待那个对话框时，那个对话框没有及时出现或者出来的是失败的对话框，或者在目标对话框前面还有其他的对话框等等，工具面对这些情况将可能无法处理。
为了弥补工具的这一缺陷，需要通过自动化测试设计将测试人员在测试过程中思考的过程加入到脚本中，使得测试工具具备一定的‘判断’能力和‘思维’能力，自动测试设计的主要工作就是通过设计让自动测试工具拥有这种能力。
http://www.2008red.com/member_pic_271/files/testingsky/html/article_4902_1.shtml
seven2000收录，使用标签：test，时间：2008-5-28 1:52:09 | 相关网摘，我也收藏
关于GUI自动化测试的收益回收期分析
丁玉伟 dyw@horizon-biz.com
摘 要：软件的界面测试是一项复杂而烦琐的工作，本文对程序界面的手工测试与自动测试两种方法进行比较，重点讨论了自动测试的收益回收期问题。
关键词：程序界面测试 捕捉/回放工具
the Break even of GUI Automation Test
BEIJING HORIZON INFORMATION & TECHNOLOGY CO.,LTD.
Ding Yuwei dyw@horizon-biz.com
Abstract: since GUI testing is an complicated and annoying work, here we compared automation and manual test , talk about the break even of automation test.
key words：GUI Testing GUI CR-tools(capture & replay tools)
引言
对于一个软件产品的评估，从用户角度来讲，程序的界面部分是相当受关注的，这里包括程序界面的交互能力、稳定性、健壮性等，同时今天的软件产品越来越复杂，通常一套软件包括会大量的用户界面，每个界面里又有很多的控制对象，以及各种信息的交互。对于这样一套软件，即便测试只覆盖到部分界面，工作量也是相当大的。由此人们想到利用工具来进行自动化测试，本文希望通过对自动测试与手工测试的比较，指导人们进行测试方法的选择。
CR-tools介绍
程序界面测试（GUI testing）主要包括两项内容：界面显示测试和界面功能测试，这里重点讲解功能测试（black box functional testing）。界面功能的自动测试可以用捕捉/回放工具来完成，（GUI CR-tools ：capture & replay tools )，但是在实际应用过程中，常常因为CR-tools固有的缺隙而大大削弱了它的效力，从而引起人们对自动化测试工具可用性的忧虑。如：
??CR-tools对GUI对象的识别能力严重依赖于被测软件所使用的编程语言，这一因素大大增加了测试脚本的维护工作量。例如如果CR-tools可以识别C++语言开发环境、OO方法定义的对象(如buttons、menu等)，通常在界面布局调整时，它仍然可以识别出新界面上的所有元素，但是很可能它不能够识别Oracle应用程序，如用OCX开发的程序界面中的对象，这时我们不得不向供应商寻找相应的支持选件。
?? CR-tools通过对程序运行过程的录制产生的测试脚本，通常只能做为设计测试用例的初始原型，必须经过大量的修改和对脚本编程的工作，才能重复利用，如增加检查点（check point）、进行参数化等。因此，GUI自动测试的设计也是一项复杂的编程与开发工作。
当然以上问题我们也可以通过采取一些措施尽可能避免，如通过建立测试用例库，实现用例的重用、脚本功能的扩展、脚本语言的规范化、以及减少维护工作量等。所以，虽然自动化测试工具还存在很多问题，但它最大的好处是可以通过用例的重用，来大大减少重复的测试设计工作量，这也是至今人们还坚持不懈研究自动化测试技术的原因。
手工测试与自动化测试的比较
下面我们对手工测试与自动测试的成本开销进行比较，找出影响自动化测试效率的重要因素：自动测试的重复运行次数。
首先我们把软件开发过程定义为六个阶段：定义、分析、设计、实现、测试、发布，其中的测试阶段又可以细分为：测试设计、测试执行、测试分析、问题解决。.
表1是相关实验显示的比较结果：
实验的前提条件：
测试执行前录制程序运行产生测试脚本，在脚本重复回放期间，是完全自动执行的，没有做进一步修改，及其它人工的干预，尽管这在实际情况中会有一定的困难。
表1：
测试
项目
测试准备（V）
测试执行（D）
N
手工支出/自动支出(E)（n次自动测试）
手工(m)
自动(a)
手工(m)
自动(a)
n=1
n=5
n=10
n=20
1
16
56
24
1
1.74
143
45
26
15
2
10
14
2
0.1
2.11
118
73
50
32
3
10
16
4.5
0.2
1.40
112
52
33
20
4
20
28
1.5
0.1
6.15
131
105
86
64
5
10
15
1
0.1
5.56
137
103
80
57
6
10
15
1.5
0.1
3.57
131
89
64
43
7
10
11.5
0.75
0.1
2.31
108
87
71
54
8
10
11.5
0.5
0.1
3.75
110
96
83
68
9
10
14
3
0.1
1.38
108
58
38
23
10
10
10.6
0.5
0.1
1.50
102
89
77
63
总计(t)
116
191.6
39.25
2.1
2.03
125
65
42
26
注：测试准备和测试执行是以小时工作量为单位
Vm：测试设计的时间支出；
Va：测试设计+重复测试的脚本定制、数据准备等支出；
Dm：手工执行一次的时间；
Da：自动测试执行完成后的整理工作量。不含执行过程的时间，因测试是在CR-TOOLS的管理下自动执行的，不需人工干预。
En := Aa/Am = (Va + n*Da)/ (Vm + n*Dm).
实验分析
分析1：
以第二个测试项目为例进行说明，测试准备和设计需要10小时（Vm），如果进行自动测试另外还需4小时的工作，整个自动测试准备阶段需14小时（Va）。手工执行（Dm）与结果分析需2小时，自动执行（Da）与测试结果分析需0。1小时。以上是自动执行一次的情况，由此我们可以计算出重复运行5、10、20次的成本开销比较，其中如果自动运行5次，自动测试的成本是手工运行5次成本的73%，即：
E5 = Aa/Am = (Va + 5*Da) / (Vm + 5*Dm) = (14 + 5*0,1) / (10 + 5*2) = 14,5/20 = 0,725 = 73 %
由此可见，成本回收期限是由测试脚本的重复运行次数，或自动测试脚本的利用率决定的，分析2：
根据等式：
EN = Aa/Am = 100%.
Ntotal =2,03
可见在自动测试第二次执行完成后，手工测试与自动测试的成本支出基本持平。
分析3：
如果你的测试工具在捕捉程序运行生成测试脚本后，只做了一次回放工作，这样的开销是手工测试的125%，因为附加的准备工作开销无法回收：191/116=165%。这里很可能是因为测试脚本语言的编程支持太弱，导致每一次重复运行时都有大量的维护、修改工作量，没有体现出自动测试的优势。
分析4：
对于一个自动测试过程，只要能够重复利用10次，测试费用就能降低40%，可见自动测试的效率提高还是相当显著的。
另外，此结果可以适用于小型、中等软件公司和开发团队的规模情况。当然这些实验和分析没有考虑被测软件、开发环境，测试流程等因素的影响。
结论
1.利用脚本语言编程实现测试用例的自动执行，自动执行一次的资源开销是手工测试一次的165%，在正常情况下，如果第二次重复测试，自动与手工的资源开销基本持平。
2.影响自动测试效率的因素：未经培训的测试人员、人员没有测试开发和编程经验、在软件产品还不稳定情况下过早启动测试、开发与测试人员沟通不足，致使软件修改后测试人员未能及时知道。
3.进行GUI自动化测试需要掌握大量与测试工具相关的知识和技能，因此必须事先经过很好的培训。
4.实现自动测试的过程是一个复杂的软件开发过程，需要测试人员具有相当的的软件测试组织、实施经验和专业的软件开发经验。
5.建立并长期维护一套测试用例库，?能够帮助我们节省资源并能够快速培养测试人员。
http://www.horizon-biz.com/xuqiu.htm
seven2000收录，使用标签：test，时间：2008-5-26 21:42:39 | 相关网摘，我也收藏
恰当选择软件测试自动化方案
2007-12-20 来源：testage.net
随着测试流程的不断规范以及软件测试技术的进一步细化，软件测试自动化已经日益成为一支不可忽视的力量。能否借助于这支外在力量以及如何借助于这支力量来规范企业测试流程、提高特定测试活动的效率，正是本 期所要讨论的话题。
目前，软件测试自动化的研究领域主要集中在软件测试流程的自动化管理以及动态测试的自动化（如单元测试、功能测试以及性能测试方面）。在这两个领域，与手工测试相比，测试自动化的优势是明显的。首先自动化测试可以提高测试效率，使测试人员更加专注于新的测试模块的建立和开发，从而提高测试覆盖率; 其次，自动化测试更便于测试资产的数字化管理，使得测试资产在整个测试生命周期内可以得到复用，这个特点在功能测试和回归测试中尤其具有意义; 此外，测试流程自动化管理可以使机构的测试活动开展更加过程化，这很符合CMMI过程改进的思想。根据Oppenheimer Funds的调查，在2001年前后的3年中，全球范围内由于采用了测试自动化手段所实现的投资回报率高达1500％。
方案选型六大原则
然而存在优势是否就一定意味着选择自动化测试方案都能为企业带来效益回报呢？也不尽然，任何一种产品化的测试自动化工具，都可能存在与某具体项目不甚贴切的地方。再加上，在企业内部通常存在许多不同种类的应用平台，应用开发技术也不尽相同，甚至在一个应用中可能就跨越了多种平台; 或同一应用的不同版本之间存在技术差异。所以选择软件测试自动化方案必须深刻理解这一选择可能带来的变动、来自诸多方面的风险和成本开销。
以下笔者给出企业用户进行软件测试自动化方案选型的参考性原则，这些原则是从笔者实际工作中凝练而成的，它包括以下六个方面的建议:
选择尽可能少的自动化产品覆盖尽可能多的平台，以降低产品投资和团队的学习成本;
测试流程管理自动化通常应该优先考虑，以满足为企业测试团队提供流程管理支持的需求;
在投资有限的情况下，性能测试自动化产品将优先于功能测试自动化被考虑;
在考虑产品性价比的同时，应充分关注产品的支持服务和售后服务的完善性;
尽量选择趋于主流的产品，以便通过行业间交流甚至网络等方式获得更为广泛的经验和支持;
应对测试自动化方案的可扩展性提出要求，以满足企业不断发展的技术和业务需求。
实战模拟
以下笔者结合一个典型的企业客户，剖析其适用的软件测试自动化方案选型过程。
1．公司背景介绍
A公司是一家大型保险公司，拥有近20个城市的分公司，并在其中5个城市建立了IT支持中心。平均每年的上线应用数量在20个左右（新业务系统和原有业务系统的主要版本发布）。目前A公司的专职测试团队人数不足30人，而且测试团队的测试人员技能参差不齐，目前测试只是作为项目上线前的一道工序而已。在测试团队内部也几乎没有自动化的手段，主要依靠手工测试。由于已上线应用系统的问题，开发团队必须分出一部分资源去维护和修复上线应用，而同时测试团队的测试成果和效率却无法和这些应用质量挂钩，也更无从谈起对软件质量的控制。所以，A公司决定在软件质量和测试方面进行投入，他们考虑以下几方面:
引进软件测试流程管理的自动化，提高软件测试过程的管理水平，使软件测试和软件开发一样可被评估、被衡量。
实现性能测试自动化，所有应用上线之前必须有应用性能风险评估报告和相关部门的确认
逐步实现功能测试的自动化，在目前人员配置的情况下，把部分手工测试变成自动化测试，提高测试可信度，降低人为错误。
通过软件测试自动化，管理软件测试中的案例、缺陷、报告等资产，进一步提升软件测试的效率并建立测试基础库。
在规划中，将来的2～3年内使所有的应用系统上线都必须有数字化的测试数据作为依据。
2．公司应用系统的情况
由于保险公司的业务种类繁多，同时在经过了几十年的经营后，公司内的应用系统从早期的终端方式到现代的J2EE和.NET等应有尽有，鱼龙混杂。IT部门已经建立的3年规划，即在未来的3年时间内将所有终端和C/S方式的应用转换成B/S架构，但当前仍然需要对这些旧应用系统进行维护，以保证业务的顺利进行。对于开发部门来说，目前新应用开发基本上已经以B/S架构为主，主要是基于J2EE架构的Web HTTP应用和部分Window.NET Form的应用。
3．公司软件测试现状
企业机构在做测试自动化选型时一定要考虑清楚企业内部哪些部分可以实施自动化、哪些部分暂不实施自动化、哪些部分仅在某几个项目做自动化试点。切忌匆忙上马或盲目否定，缺乏实事求是的理性思考。
测试部门目前仅负责系统测试和对用户验证测试进行管理，对于之前的单元测试和集成测试主要由开发团队中划分出的一部分临时测试人员完成。由于缺乏监测手段，测试部门也无法收集和确定集成测试和单元测试的完成情况，在整个软件测试过程中，业务需求是由开发部门通过Rational RequisitePro进行管理，但测试需求目前尚没有提出要求，测试案例主要通过在公司公用的文件服务器中的目录管理方式管理，对测试中缺陷流程等管理主要依靠邮件的流转进行处理。目前90％以上的测试是通过Excel和Word等测试案例文档来完成，测试人员对软件测试自动化的认识仅停留在“记录＋回放”的认识上。
4．可供选择的方案
方案A: A公司可以采用美科利（Mercury）公司产品为主的软件测试自动化方案。
依照原先的邮件流转过程配置TestDirector缺陷管理流程，为每个保险业务的开发小组和测试团队分配相应的用户许可证，取消原有邮件方式。
部署Mercury Quick Test Professional，以便完成应用程序相关功能测试。
部署Mercury Load-Runner。从测试团队中分化出专职的性能测试自动化工程师和小组，和业务部门协调，建立A公司应用系统上线性能指标，通过LoadRunner给出测试指标。
建议A公司成立专门的质量控制部门，对TestDirector中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
方案B: A公司也可以采用IBM Rational产品为主的软件测试自动化方案。
采用Rational Test manager来进行整个测试流程的管理，为相关开发和测试小组成员分配相应权限，改变以前通过邮件以及Word、Excel文档管理测试的工作方式。
部署Rational Robot，用它来完成功能相关的测试工作以及新版本发布时的冒烟测试。此外，Rational Robot也能较好地完成性能相关测试。统一的操作方式降低了工具的学习周期和培训带来的大笔开销。
部署Rational Purify plus，使测试工作前移到开发阶段。由于Purify plus能较好地支持白盒测试，编程人员在编码阶段引入的错误能尽早被检测到，这大幅降低了后期测试的开销。
建议A公司成立专门的质量控制部门，对Test manager中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
方案C: A公司也可以采用开源软件为主的软件测试自动化方案。
采用Bugzilla来进行Bug跟踪管理，采用Bugzilla Test Runner进行测试用例管理，采用CVS进行测试资源的配置管理。
采用MaxQ和WebInject对B/S结构的应用系统进行功能测试。
采用DBMonster、Open－STA、LoadSim进行性能相关测试。
可采用Xunit架构的开源工具对不同语言的程序单元进行单元测试。
建议A公司成立专门的开源软件维护小组，以解决可能会碰到的工具维护工作。
建议A公司成立专门的质量控制部门，对Bugzilla、Test Runner、CVS中的数据定期进行分析，建立相关质量模型，以便于企业量化管理和过程改进。
5． 方案评价
由于不同客户在组织架构、员工素质以及流程管理水平等方面的不同，我们很难用一个实例、一两句话来说明不同解决方案的适用性。在上面的例子中，笔者给出了3种可行的方案，具体选择哪一个，需要仔细权衡。这里笔者给出一般性的意见，对于不想受制于某个测试自动化厂家的企业，开源绝对是一个理想的选择。此外，它不需要支付成本，工具的源代码可以随意修改，因而具有较好的灵活性。但开源工具的弊端也是明显的: 缺乏使用培训和技术支持，工具的用户界面一般也较为粗糙。而对于那些比较看重培训和售后支持的企业，笔者建议选择IBM Rational或Mercury或其他厂家的产品。这样虽然需要支付一部分费用，但省去了工具维护所需要的大量工作。至于具体选择哪个厂家的产品为好，笔者尚无结论性意见。相信读者朋友都有一些见仁见智的看法，不妨来信交流。
实施中的注意事项
首先，一个企业实施测试自动化，绝对不是拍脑袋说干就能干好的，它不仅涉及测试工作本身流程上、组织结构上的调整与改进，甚至也包括需求、设计、开发、维护及配置管理等其他方面的配合。如果对这些必要的因素没有考虑周全的话，必然在实施过程中处处碰壁，既定的实施方案也无法开展。其次，尽管自动化测试可以降低人工测试的工作量，但并不能完全取代手工测试。100％的自动化测试只是一个理想目标，根据笔者的经验，即便一些如SAP、Oracle ERP等测试库规划十分完善的套件，其测试自动化率也不会超过70％。所以一味追求测试自动化只会给企业带来运作成本的急剧上升。再次，实施测试自动化需要企业有相对规模的投入，对企业运作来说，投入回报率将是决定是否实施软件测试自动化的最终指挥棒，笔者建议企业在决定实施软件测试自动化之前，必须要做量化的投资回报分析。此外，实施软件测试自动化并不意味着必须采购强大的自动化软件测试工具或自动化管理平台，毕竟软件质量的保证不是依靠产品或技术，更多的因素在于高素质的人员和合理有效的流程。
http://www.uml.org.cn/Test/200712202.asp
seven2000收录，使用标签：test，时间：2008-5-26 21:38:49 | 相关网摘，我也收藏
探索中小型企业软件测试之道
在ISO、CMM、各大软件企业、IT公司的最佳实践理论宣导之下，我想国内很多中小型软件企业中的软件测试人员会感到非常的迷茫，缺乏测试资源、缺乏合理的测试流程、缺乏重视质量的大环境，这些都让中小型软件企业的测试人员感觉测试工作非常难做，测试的管理者也会不禁发出感叹“软件测试好难管啊！”，我想中小型软件企业的测试管理必须根据自身组织的特点进行个性化的调整，切忌盲目追崇大企业的做法，但是也不能完全抛弃那些最佳实践。
我把中小型软件企业的测试管理发展之路分成3个阶段，在每一个阶段中，测试培训、自动化测试、测试流程、测试用例等方面需要不同的做法：
（1）初级阶段：“自力更生”。
这个阶段的软件测试非常难做，只能跟着项目走，密切配合进度的要求，质量不可避免地让位给成本、进度。因为大部分中小型软件企业仍然处于起步阶段，最大的困难是生存成本问题，只有尽快出产品、完成项目，才能维持或发展下去。
在这个阶段，测试管理流程不会很规范，测试版本可能会由于缺乏合理的配置管理流程而失去控制，测试计划很难制定，基本上是等待开发人员开发完一个功能，马上进入测试，再反复修改、测试…
在这个阶段，测试用例基本不够时间编写，或者在早期编写出基本的、粗糙的测试用例，后面基本上不会按这些用例来执行，因为程序的变更过于频繁，缺乏需求控制，另外，测试人员频于应付开发人员提交的测试版本，不会有时间完善和修改测试用例库中的测试用例。
因此，有些组织甚至完全抛弃测试用例的管理，不写测试用例。而实际上测试用例的编写还是有好处的，测试人员至少能通过编写测试用例熟悉系统的业务需求（虽然有时候很可能需求文档也是缺乏的！）。“探索性测试”的方法和“敏捷测试”的模式可能更加适合这个阶段的测试人员使用。
在这个阶段，基本上不可能开展自动化测试，因为缺乏足够的资源。
在这个阶段，测试人员只有发挥“自力更生”的精神，不能期待公司给你很多培训资源，必须要靠自己在工作实践中学习、总结，空闲时找书看、寻求各种网络资料来学习。
（2）中级阶段：“英雄时代”。
当软件企业走过艰难的“生存期”后，逐步意识到质量的重要性，市场的“蛋糕”以及分到了一部分，后面就希望通过质量来争强竞争力，摆脱“后来者”的“追击”。
当然，也有些中小企业是被逼认识到质量的重要性的，客户的对产品质量的不认可、项目濒临失败的危险，老板意识到是质量控制没有做好，因此下定决心要把质量搞上去，因此成立了测试组或者测试部门，招聘了更多的测试人员。
在这个阶段，一般会提拔一两个优秀的测试人员作为测试组长或者测试主管。这些测试人员“临危受命”，誓要把质量搞上去。这个阶段是“英雄”的时代，老板寄希望于这些“英雄”的身上，没有意识到质量要靠全体人员，尤其要靠开发人员自身的质量意识。
因为老板给这些“英雄”配的往往是初级测试人员、毕业生。因此“英雄”们需要承担起培训、“带人”、指导测试的艰巨任务。
在这个阶段，会效法教科书的做法，建立测试用例库，但是测试人员没有意识到如何充分利用好测试用例，没有充分理解测试用例的“设计”的重要性，停留在表面的测试用例书写上。
“英雄”们发挥了一定的作用，建立起一套严格的测试提交流程，尝试进行每日构建、冒烟测试，BUG修改流程得到规范化的控制，老板在发布产品前或者实施项目前会征求“英雄”们的意见。
在这个阶段会尝试自动化测试，但是没有受到很好的效果，资源仍然缺乏，尤其是缺乏自动化测试的相关培训，除了“英雄”们，其他测试人员要么对自动化测试“不感冒”，要么没有足够的脚本编写能力。另外，缺乏完善的项目管理、配置管理制度的配合，“英雄”们只能进行非常简单的自动化尝试，并且停留在小范围、个人的尝试。
（3）高级阶段：“法制社会”。
“英雄时代”崇尚的是人治，它不可避免地存在很多弊端，例如过于依赖高级测试人员、测试组长或测试主管，没有形成“梯队”，缺乏人才培养的机制。
中小型企业的软件测试和质量管理工作如果想再进一步提高，则需要往“法制社会”慢慢过渡，从依赖人转变到依赖制度，大家按制度办事。当然，在中国“人治”的思想根深蒂固，通常都是所谓的“事在人为”，要想转变这种思想不容易。而且，事实上，也不应该完全抛弃“人治”（任何时候，我们都是需要“英雄”、“榜样”、“楷模”的），尤其是在IT业，大家习惯了所谓的“不能扼杀了创造性的思维”，很多人都向往那些“穿者牛仔裤上班，喝着可乐干活”的工作模式，要让这些思维“奔放”的人想工厂的蓝领一样扼守规章制度是很困难的事情。
在这个阶段，如果能比较好地过渡到“人治”结合“法制”的管理模式，则软件测试的管理也会相应地规范化，培训会成为常规例行工作，测试用例库会完善地建立，测试人员基于用例展开测试，测试总结报告会被重视，项目的重大决策会依据测试的结果、缺陷的统计分析来定。
自动化测试得到正确的认识，由专门的自动化测试工程师来主导自动化测试项目的开展，部分测试用例得以自动化地实现，大部分冒烟测试通过自动化来实现。
由于项目管理、配置管理的规范化，测试流程也得以规范化，测试得以有计划、有次序地开展，测试时间和测试资源都基本得到保证。
小结
中小企业的软件测试人员通常会很羡慕那些大公司、大企业的软件测试，期待着像他们一样在规范的测试环境下，享受软件测试工作的乐趣，期待得到重视，但是往往由于企业的现状，使得自己的理想无法实现。
我想，“怨天尤人”不是一种积极的态度，更多地应该认清现状，然后积极改变现状，努力为自己争取和创造更好的测试环境。
http://blog.csdn.net/Testing_is_believing/archive/2008/05/18/2455523.aspx
seven2000收录，使用标签：test, 软件工程，时间：2008-5-26 19:39:41 | 相关网摘，我也收藏
在日常需求的测试过程中，因为时间和资源的相对紧张，往往会遇到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，绝对不止是确认需求和描述自己的操作步骤，通过在跟开发人员的沟通过程中，引导他们一起去思考和去检验自己的代码，其实也是在测试，这样的行为可以说大大的提高了测试的效率，因为很多问题在测试人员开始执行测试之前都已被开发人员所修正，如此一来，在执行测试的时间里，测试人员就可以更好地聚焦于业务逻辑层的实现，使得测试更为充分。从某种角度讲这也是缺陷的预防。当然，缺陷预防的路还有很长，但是我们不用害怕和沮丧，一点点做起来，一步一个脚印的走下去，目标总会近，如果我们每个人再加把劲，多多分享和共享，那么我相信，我们的团队会走的更快、更好。
http://testing.csdn.net/page/25c27b89-5bc0-4a1a-a546-9c3363a33858
seven2000收录，使用标签：test，时间：2008-5-26 18:17:44 | 相关网摘，我也收藏
智能测试自动化
——基于应用程序行为的模型驱动测试方法
作者：Harry Robinson
译者：江上舟
【摘要】 如何提高测试的效率，如何让测试人员在测试过程中不会感到单调乏味，是我们一直在思考的问题。本文通过一个虚构的故事，提出了一种根据应用程序的行为描述来生成测试的模型驱动方法，并同手动测试、静态自动化测试和随机测试进行了对照，希望能给人以启示。
【关键字】 模型驱动测试 自动化测试 状态模型
• 快速浏览
通过建模来提高你的自动化测试的效率。
克服手动测试和静态自动化测试的局限性。
注意：你将要读到的故事是虚构的――它很短小，但其寓意是真实的。
在产品周期中，有四位测试人员根据要求开始测试软件。
• 测试员1
立即开始手动测试，并发现一些细微的错误。开发团队高兴的修复了这些错误，然后提供一个新的软件版本以供测试。测试的越多，发现的错误越多，修复的错误也就越多。
测试员1觉得很有成就感，也就会感到快乐――至少一段时间是这样的。
经过几轮这种发现、修复的循环，他开始由于一遍遍的手动重复运行实质上一样的测试而感到乏味和反应迟钝。当测试员1最终丧失积极性――同时也就意味着失去耐性――就会宣称软件可以发布了。
用户发现它有太多的错误，于是购买了竞争者的产品。
• 测试员2
从手动测试开始，但很快就判定创建自动执行按键的测试脚本更有意义。仔细找出那些会使用到软件有用部分的测试后，测试员2将操作记录到脚本中。这些脚本很快达到几百个。按下一个按钮后，这些脚本就被激活并按照步骤运行软件。
测试员2觉得自己很聪明，也就会感到快乐――至少一段时间是这样的。
当软件发生变化时，这些脚本需要大量的维护。他花费数个星期和开发人员争论，要求停止修改软件，因为这破坏了自动化测试。最后，脚本需要太多的维护以致留下太少的时间来进行测试。
当软件发布后，用户发现太多脚本未覆盖的错误。他们停止购买该产品而决定等待版本2的发布。
• 测试员3
不想维护数以百计的自动化测试脚本。她编写了一个测试程序来在应用程序中到处随机点击和按按钮。这种“随机”测试程序不需要一直查看，且发现了很多致命的错误。
测试员3很享受发现这些引人注目的缺陷，也就会感到快乐－－至少一段时间是这样。
由于随机测试程序只能发现那些毁坏应用程序的错误，因此测试员3仍然不得不做大量手动测试，并很快在这个过程中感到乏味和反应迟钝。当软件发布后用户在软件中发现如此多的功能性错误而对公司丧失信任，于是停止购买这种软件。
• 测试员4
通过从手动测试、探索式测试开始熟悉了应用程序――用手动测试中所获得的知识来为应用程序创建一个非常简单的行为模型。测试员4接着使用一个测试程序来测试应用程序的行为是否和模型预测的一致。行为模型相比被测的应用程序要简单的多，因此它很容易创建。由于测试程序知道应用程序应该怎样做，因此当应用程序犯了错误时它能够检测到。
随着产品周期的发展，开发人员为应用程序写出了新的特性。测试员4很快更新了模型，测试得以继续进行。程序白天和晚上都可以运行，持续生成新的测试序列。测试员4可以一次在多台机器上执行测试，将多天的测试放到一个晚上来完成。
经过几轮测试和错误修复后，测试员4的测试生成程序开始发现很少的错误。测试员4为了测试增加的行为更新了模型，然后继续测试。测试4也会为应用程序中那些不值得建模的部分做一些手动的测试和静态自动化测试。
当测试员4的软件发布出来后，只有非常少的错误能被发现了。用户感到高兴。投资者感到高兴。
测试员4感到高兴。
• 评注
这四个场景展现出了当前软件测试中可用的一些方法。
测试员1是一个典型的手动测试者，从键盘手动运行所有的测试。手动测试在当前的工业界很普遍――它能提供直接的好处，但长时间的运行会让测试人员感到单调乏味，对公司来讲成本高。
“我看到的最悲哀的景象之一就是一个人在键盘上手动操作一些可以自动运行的东西。这是悲哀的但也是有趣的。”
－－Boris Beizer，黑盒测试：软件和系统功能测试技术
测试员2实践的是我称为静态测试自动化的测试。静态自动化脚本每次根据同样的次序执行同样的命令序列。当应用程序发生变化时这些脚本的维护成本很高。测试是不断重复的；但由于它们总是执行相同的命令，因此它们很难发现新的错误。
“高度重复的测试实际上将发现所有重要问题的几率最小化了，这和沿着别人的足迹前行将发现自己的天地的几率最小化的原因是一样的”
－－James Bach，“骗人的测试自动化,”Windows技术期刊,1996.10
测试员3的操作接近于自动化测试的边缘。这些类型的随机测试程序被称为蠢猴因为它们就是毫无目的的敲打键盘。它们生成非常规的测试执行序列并发现很多致命的错误，但是想控制它们到应用程序中你想测试的部分却是很困难的。因为它们不知道自己在做什么，所以它们会漏过应用程序中很多明显的错误。
“猴子式的测试不能是你测试的全部。猴子不明白你的应用程序，由于它们的无知它们漏掉了很多错误。”
－－Noel Nyman，“使用猴子式的测试工具,”SQTE,2004.1/2
测试员4通过一种称为“模型驱动测试”的智能测试自动化方法糅合了其它测试员的方法。
模型驱动测试并不像静态测试自动化那样逐字逐句的记录测试序列，也不盲目的在键盘上敲打。模型驱动测试通过对应用行为的描述来判断哪些操作是可能的、期望输出是什么。这种方式不断自动生成新的测试序列，很好的适应了应用程序的变化，能够同时在多台机器上运行，并能整天运行。
“一个艺术家用他的智慧画画，而不是用他的手。”
－－Michelangelo Buonarroti
这个故事的寓意
手动测试是开始测试自动化过程的好的方法。我把这个阶段称为“探索式建模”，因为它综合了探索式测试过程和用来生成测试的模型的发现过程。当你开始搞清每种操作的行为后，你就能创建能帮助建模和测试应用程序的规则。
测试员1的方法需要他的手不停的在键盘上工作。最后测试员1精疲力竭。
测试员2的静态脚本重复他的手已经执行过的那些键盘操作。
测试员3的猴子式测试本质上是无目的的在键盘上乱敲。
测试员4,从另一方面，在其它技术上进行了补充：
思考应用程序的行为，
将行为描述给一个测试生成程序，
让测试生成程序来创建和运行测试用例。
通过根据应用程序行为描述生成测试，测试员4能够执行那些在使用其它测试方法时不可实现的测试。
这个故事的寓意：自动化你的大脑，而不只是你的手。
• 使用你的大脑
让我们看一个创建和使用行为模型来测试应用软件的例子。
手动测试是开始测试自动化过程的好的方法。我把这个阶段称为“探索式建模”，因为它综合了探索式测试过程和用来生成测试的模型的发现过程。当你开始搞清每种操作的行为后，你就能创建能帮助建模和测试应用程序的规则。
这就是模型驱动测试的精髓：按照一种能够被用来生成测试的方式来描述行为。针对你将要测试的每一种操作，问自己以下两个问题：
什么时候这种操作是可能的？
当这种操作被执行时输出是什么？
例如，假设你被要求测试Windows目录下文件的行为。更确切一点，你要测试创建、删除和反选取操作。
• 为创建操作建模
什么时候创建是可能的？为了简单，在这个例子中限制目录中的文件数为1.这样只有在目录中有0个文件时可以创建。
当创建被执行时输出是什么？当你在一个目录中创建一个新的文件时，这个目录中的文件个数加1。这个新创建的文件默认是被选中的，因此在目录中它是加亮的。实际上这个新文件是这个目录中唯一被选的文件，不管在创建操作前有多少被选中。
• 为删除操作建模
什么时候删除是可能的？只有当目录中至少有一个被选中的文件时删除才是可能的。
当删除被执行时输出是什么？当你执行删除操作时，目录中任何被选中的文件都将消失。
• 为反选取建模
什么时候反选取是可能的？在这个模型中反选取总是可能的，即使目录中有0个文件。
当反选取被执行时输出是什么？当你执行反选取操作时，目录中所有被选取的文件将都不再被选取，而所有没被选取的文件将被选取。当目录中有0个文件时，反选取让目录保持不变。
• 建立一个状态模型
如图1所示，现在你可以构建一个系统行为的“状态模型”。它将上面描述的那些行为合在一起。注意反选取操作从0文件状态回到0文件状态的方式。它模拟出当没有什么需要反选取时什么都不做的情况。
图1 状态模型
很好，那接下来呢？
现在你明白应用程序是如何工作的，那么你就可以手动测试这些操作、检验Windows目录是否按照你的预期变化。但是，由于你的理解都存在于你的大脑中，你的测试结果也就受你的时间和体力所限。
另一方面，如果你能将这个状态模型从你的大脑完全的移植到计算机上，计算机将能替你为系统生成和执行测试。
幸运的是，这个模型可以通过计算机能识别的被称为“状态表”的形式进行表达。状态表（见表1）的每一行表明某种操作用于处于开始状态的应用程序后会到达的结束状态。
开始状态 操作 结束状态
0个文件 反选取 0个文件
0个文件 创建 1个被选文件
1个被选文件 反选取 1个未选文件
1个被选文件 删除 0个文件
1个被选文件 反选取 1个被选文件
表1 针对Windows目录中文件行为的状态表
也使用计算机的大脑
一旦我们将状态模型转换成计算机能理解的状态表，计算机可以为我们做些什么呢？我们该如何使用我们有关应用程序行为的那些信息呢？
计算机能够应用状态表来生成测试序列以测试应用。你将在下面的例子中看到，可根据这些测试序列的新颖性、有效性或它们的全面性来选择它们。这种测试生成是应用你对系统的理解的一种强有力的方式――这就是模型驱动测试的内容。
状态模型上的随机路线
生成测试操作的一个简单的方法就是从应用当前状态可用的操作中任意选择一个。例如，如果你在0个文件开始状态，你能够选择下面两种操作中的任意一个：
反选取（让你仍停留在0个文件状态）
创建（让你停留在1个被选文件状态）
按照这种方式随机选取操作，你能生成许多非常规的序列（就象测试员3的随机“猴子测试程序”那样），而最后你将能执行模型中的所有操作。图2显示了一个典型的随机路线。注意这个随机路线在一轮中执行了四次同样的操作（反选取），但是却让剩下的两个其它的操作没有执行到。这就是随机测试的实际情况。
图2 一个随机路线
执 行 的 操 作 结 束 状 态
1 创 建 1 个 被 选 文 件
2 反 选 取 1 个 未 选 文 件
3 反 选 取 1 个 被 选 文 件
4 反 选 取 1 个 未 选 文 件
5 反 选 取 1 个 被 选 文 件
状态模型上一个有效的路线：中国邮递员路线
当模型很大时要到达所有测试操作按照随机路线是很低效的。我们怎样才能有效的测试模型中的每种操作呢？
一个邮递员在递送信件时会遇到同样的问题。设想模型中的每个操作是递送邮件必须经过的街道――模型中每个状态是邮递员改变方向时的十字路口。就像邮递员必须走过每一条街道来递送邮件一样，我们也必须测试模型中的每种操作。在这两种情况下，我们都想将所需的路线长度减小到最短。
一个叫做管梅谷的中国数学家为这个问题提出了一个优秀的解决方案，这就是中国邮递员算法（见图3）。管梅谷的方法生成一条该状态模型的路线，该路线用最少的步数执行到模型中所有的操作。下面列出的测试序列只用5步就覆盖了模型中的5种操作。对于一个你要快速测试的、大的应用程序而言这种效率是很有用的。
图3 一个中国邮递员路线
执 行 的 操 作 结 束 状 态
1 反 选 取 0 个 文 件
2 创 建 1 个 被 选 文 件
3 反 选 取 1 个 未 选 文 件
4 反 选 取 1 个 被 选 文 件
5 删 除 0 个 文 件
一个更有效的路线：状态改变的中国邮递员路线
模型中的一些操作――如当目录中有0个文件时点击反选取――不会改变应用程序的状态。如果你认为当应用程序的状态发生变化时更容易出现错误，你可以优先测试状态改变的操作。
一个简单的方法是将不会改变状态的操作从状态表中过滤掉。对于表1，需要移除第一个操作（反选取）。
在这个简化的状态模型上运行中国邮递员算法生成一个用四步覆盖模型中所有状态改变的操作的测试序列――本质上就是将前一个例子中的第一步移除：
执 行 的 操 作 结 束 状 态
1 创 建 1 个 被 选 文 件
2 反 选 取 1 个 未 选 文 件
3 反 选 取 1 个 被 选 文 件
4 删 除 0 个 文 件
回到开始状态的最短路线
假设你想全面的测试所有让Windows目录从0个文件状态经过几步回到0个文件状态的测试序列。这种不断产生新的变化的测试序列对于测试员2的静态自动化而言是不可想象的。
对于计算机而言根据状态模型生成一系列这种路径是微不足道的。你可以生成长度不断增加的测试序列直到让计算机死掉，这样就能越来越深入的探索模型。
路径A有一步：
A1：反选取
路径B有两步：
B1：创建
B2：删除
路径C有四步：
C1：创建
C2：反选取
C3：反选取
C4：删除
图4 四步或更少的状态回环
使用计算机的手
每种算法的输出是需要执行的测试操作的序列。哪种是执行这些操作的最佳方法？你可以将操作列表交给一个测试人员去手动执行――但这肯定是缓慢的、单调乏味的和痛苦的。谁愿意把他们的时间都花费在执行这些操作上。这种重复性的工作就是那种让测试员1如此痛苦的罪魁祸首。
作为替换，你可以编写一个简单的测试执行程序来读取列表并执行针对列表中每种操作的测试代码。
例如，使用Visual Test，创建操作的执行测试代码为：
WToolbarButtonClick("@1","File") ' Open the File menu
WMenuSelect("New") ' Select New File
WMenuSelect("Text Document") ' Choose Text Document
Play "{Enter}" ' Accept the default filename
在典型的静态自动化中，这段代码将嵌入脚本中――但在一个模型驱动测试程序中，这一小段代码将只在列表中的测试操作需要执行创建操作时才会被调用。
使用计算机的眼睛
自动化测试操作只是战斗的一半。你还需要一种自动判断应用程序是否正确工作的方法。
这种方法――一种用来判断应用程序是否正确响应测试操作的方法－－被称为测试准则。一些测试方法，如测试员3的随机猴子式测试程序，必须基于类似于应用程序是否崩溃的痛苦的测试准则。
模型驱动测试让测试程序有能力检查那些比“系统不崩溃”更细的行为指标。根据状态表中的信息，模型知道每一个状态下哪些操作是可用的以及每种操作的期望输出。例如，模型指出测试程序在一个被选文件的状态下可以执行删除操作。模型同时也指出执行删除操作的结果就是让应用进入0个文件状态。这些知识提供了两种检验应用程序是否正确运行的方法。
第一，测试程序可以判断是否能执行的操作不能执行。如果在应用处于1个被选文件的状态下不能执行删除操作，测试程序将上报一个错误，因为在无法找到菜单中的可选删除项时测试程序会失败。
第二，模型始终知道应用程序应该进入哪种状态。知道每种操作的期望结束状态也就意味着我们能够创建测试准则程序来检查（在每种操作结束后）目录中是否有合适的文件数和被选文件数。例如，当上述的删除操作被执行后，结束状态就应该是目录中有0个文件（当然也就是0个文件被选）。
程序化的测试语言通常提供可用于测试程序检查应用程序各个方面的函数。两个对当前模型有用的Visual Test函数是：
WviewCount()指出目录中的文件数，
WviewItemSelected()指出目录中有多少文件被选。
测试程序能够验证应用程序是否处在正确的状态，如表2所示。 应用程序的状态 WviewCount的期望返回值 WviewItemSelected的期望返回值
0个文件 0 0
1个被选文件 1 1
1个未选文件 1 0
表2 显示Visual Test函数WviewCount()和WviewItemSelected()的状态表
上面讨论的删除操作将让应用进入0个文件状态。如果WviewCount()返回一个非0的值，测试程序准则将上报一个错误，因为目录中的文件数不正确。
如何更新模型驱动测试
还记得测试员2的静态测试自动化尝试由于应用程序的改变而让人灰心吗？相反的是，测试员4能够利用模型驱动测试自动化来很快适应应用程序的改变。
将新的操作合并到模型中
假设你的开发团队告诉你他们实现了全选操作。你该怎样为新的操作更新你的测试呢？很简单――升级你的状态模型来并入全选操作，然后重新生成测试。
第一，通过回答我们那两个基本问题来为全选建模：
什么时候全选是可能的？在这个模型中全选总是可能的，即使目录中只有0个文件。
当全选被执行时输出是什么？当你执行全选时，目录中的所有文件变成了被选。如果目录中有0个文件，全选将使得目录没有变化。这种情况在下面的图示中指示了出来，全选操作从0个文件状态回到0个文件状态。
图5中显示了合并全选之后的新的状态模型。
图5 包含全选的状态模型
在升级后的模型上（见图6）运行中国邮递员算法得到了一个九步的测试序列――用0个文件状态作为开始状态――执行了模型中所有操作，其中包括新加的全选操作：
图6 新状态模型下的中国邮递员路线
执 行 的 操 作 结束状态
1 反 选 取 0 个 文 件
2 创 建 1 个 被 选 文 件
3 反 选 取 1 个 未 选 文 件
4 全 选 1 个 被 选 文 件
5 反 选 取 1 个 未 选 文 件
6 反 选 取 1 个 被 选 文 件
7 全 选 1 个 被 选 文 件
8 删 除 0 个 文 件
9 全 选 0 个 文 件
下一步就是确定用于调用全选操作的代码，不管该操作在测试序列中何时发生。使用Visual Test该代码如下：
WtoolButtonClick(“@1”,”EDIT”)
WmenuSelect(“Select All”)
• 总结
弄清应用程序并为其建模需要相当大的努力。放弃路线简单的手动测试和路线足够长的静态自动化测试，而花费时间思考如何对应用程序进行测试是困难的――就象我们在虚构的故事中所看到的四位测试员所进行的试验和经历的磨难那样。
但是我们获得的回报是丰厚的：
模型驱动测试几乎从开发的第一天起就开始创建灵活的、有用的测试自动化。
模型的修改很简单，因此模型驱动测试在项目的生命周期中进行维护是很经济的。
模型能够根据你的需要来生成数不清的测试序列。
模型让你能够在短时间内完成更多的测试，因为一个测试生成程序能整天在多台机器上创建和验证测试序列。
模型驱动测试能对其它形式的测试进行补充，能够执行那些在其它测试方法下不可实现的测试。
你和我都知道软件测试不是虚构的故事，不可能保证整个过程中都是愉快的。但是在你的测试中加入模型驱动的智能将是帮助你找到通向快乐的终点的强大的工具。
作者简介
Harry Robinson是微软智能搜索组的软件测试经理。他维护着模型驱动测试的主页（www.model-based-testing.org）,是模型驱动测试长时间的倡导者和开拓者。
http://www.51testing.com/emagzine/No2_11.htm
seven2000收录，使用标签：test，时间：2008-5-26 18:14:56 | 相关网摘，我也收藏
· 尝试使用WatiN进行TDD
· 开源Web自动化测试框架-Watir试用手记 · 软件自动化测试在预测试中的应用
· 浅谈自动化测试框架之控制界面的关键 · 针对 SAP 集成应用软件的测试自动化
· 软件自动化测试基础 · 软件测试自动化框架
· 不同水平的人是如何进行自动化的 · 软件自动测试架构设计
· 自动化测试框架：自己的框架 · 自动化测试与自动化测试生命周期
· 基于Agere的GSM手机自动化测试解决方案 · 关于GUI自动化测试的收益回收期分析
· 智能测试自动化——基于应用程序行为的模型驱动测试方法 · 使用 CruiseControl 和 STAF 建立复杂环境下的编译和测试自动化
· 自动化测试成功的关键: 制定计划 · 利用 STAF 实现程序更新包的自动部署测试
· 开源测试框架及工具之不完全手册 · 浅谈Rational Robot自动化测试
· 浅谈自动化测试功能模块的分解 · 恰当选择软件测试自动化方案
· 一个python ODBC数据源插件 · Unix下自动化测试实践
· 使用 RSpec 进行行为驱动测试 · 一个UI自动化的小例子
· 自动化测试软件的体验与比较 · 使用 Selenium 和 TestNG 进行编程式测试
· 集中式拨打测试系统的实现与应用 · 五类软件测试工具
· 使用 Abbot 框架自动化测试 Eclipse 插件的用户界面，第 1 部分 · 纯技术角度看自动化测试的迷思
· 使用Windows Mobile Test Framework进行Windows
Mobile程序的自动化测试 · 使用 Abbot 框架自动化测试 Eclipse 插件的用户界面，第 2 部分
· Mercury QuickTest Professional工作原理 · 软件自动化测试技术选择:驶入测试“快车道”
· 通过有效的手工测试向测试自动化推进 · 使用 TestNG-Abbot 实现自动化 GUI 测试
· 使用IBM Rational的测试理念成功打造测试团队 · 开发一个基于 JUnit 的存储过程自动化测试的 Eclipse 插件
· Ruby+Watir经验谈: javascript popup box · Ruby+Watir经验谈: 设计RUTF的TestRunner以产生格式化的测试结果
· 开源Web自动化测试框架——Watir试用手记 · Ruby+Watir经验谈: 缘起
· 软件测试自动化的成功经验 · Ruby+Watir经验谈: Understanding Watir
· 测试自动化与软件过程改进 · 让开发自动化: 持续测试对代码基址的每一次更改都运行自动化测试
· QTP使用SystemUtil对象 · QTP的Test参数以及顶级Action参数的使用
· Software Test Automation · QTP学习分享
· 软件开发全过程检测及软件测试自动化 · 自动化测试: 真的是银弹？
· 浅谈软件测试自动化解决方案 · 软件自动化测试实例分析
· 软件测试自动化的一些具体做法 · The key to successful automated testing: Planning
· 持续集成与测试自动化 · Q&A with industry experts: How are e-business trends impacting testers and testing teams? Part II - Have Changes in Architecture Affected Testing and Automated Testing Tools?
· 自动化测试在企业中的实施 · Interview with Cem Kaner, Software Testing Authority, Part II: How to Educate and Train Testers
· 什么时候测试应该自动化？ · Quality by design: Enabling cost-effective comprehensive component testing
· 持续集成与测试自动化 · 自动化测试的7个步骤
· 你的组织为自动化测试做好准备了吗？ · 构建可“复用”的软件测试环境
· 游戏项目中的自动化测试和持续集成 · 软件测试技术报告
· 软件自动化测试实例分析 · TCL/EXPECT自动化测试脚本实例
· 自动化测试的7个步骤 · Logiscope测试机理
· 测试工具大比较 · 选择正确的GUI测试自动化工具
· 用Visual Basic 6.0实现自动化测试 · 测试工具的选择和使用
· 软件开发全过程检测及软件测试自动化 · 以RUP原则实施软件自动化测试 第一部分
· The key to successful automated testing: Planning · 基于GUI的自动化测试工具
· 一个多线程&多进程并发测试框架程序的源代码(VC++6,Win2000下编译通过) · 开发自动化测试脚本的技巧和心得
· 何时应进行自动化测试 · 软件测试自动化的一些具体做法
· 用Selenium自动化验收测试 · Functional Test Automation Tools
· 测试工具交流和培训材料 · 自动化测试
· 黑盒工具--QACenter · 安装程序文件测试工具
· 测试工具应用之我见 · 进程检测工具
· 关于软件测试及测试工具比较 · 测试工具应用之我见
· 让编译和测试过程自动化 · 软件测试及其支持工具
· Web测试工具对比--自动化软件测试一 · 基于PB环境下的软件测试
· Web测试工具对比--自动化软件测试二 · Jtest5.0中文使用手册
http://www.uml.org.cn/Test/test_auto.asp
seven2000收录，使用标签：test, UI，时间：2008-5-26 17:46:31 | 相关网摘，我也收藏
web 测试
2008-01-07 10:48:31
web test
1页面部分
（1） 页面清单是否完整（是否已经将所需要的页面全部都列出来了）
（2） 页面是否显示（在不同分辨率下页面是否存在，在不同浏览器版本中页面是是否显示）
（3） 页面在窗口中的显示是否正确、美观（在调整浏览器窗口大小时，屏幕刷新是否正确）
（4） 页面特殊效果（如特殊字体效果、动画效果）是否显示
（5） 页面特殊效果显示是否正确
2 页面元素部分
（1）页面元素清单（为实现功能，是否将所需要的元素全部都列出来了，如按钮、单选框、复选框、列表框、超连接、输入框等等）
（2）素是否显示（元素是否存在）
（3）页面元素是否显示正确（主要针对文字、图形、签章）
（4）页面元素的外形、摆放位置（如按钮、列表框、核选框、输入框、超连接等）
（5） 页面元素基本功能是否实现（如文字特效、动画特效、按钮、超连接）
（6） 页面元素的容错性列表（如输入框、时间列表或日历）
（7） 页面元素的容错性是否存在
（8） 页面元素的容错性是否正确
3 功能部分
（1） 数据初始化是否执行
（2） 数据初始化是否正确
（3） 数据处理功能是否执行
（4） 数据处理功能是否正确
（5） 数据保存是否执行
（6） 数据保存是否正确
（7） 是否对其他功能有影响
（8） 如果影响其他功能，系统能否作出正确的反应
（9） 其他错误
（10） 对模块的具体功能进行测试时可以列出功能模块的所有功能，进行排列组合，测试所有情况
如：某一功能模块具有最基本的增删改查功能，则需要进行以下测试
单项功能测试（增加、修改、查询、删除）
增加——>增加——>增加 （连续增加测试）
增加——>删除
增加——>删除——>增加 （新增加的内容与删除内容一致）
增加——>修改——>删除
修改——>修改——>修改 （连续修改测试）
修改——>增加 （新增加的内容与修改前内容一致）
修改——>删除
修改——>删除——>增加 （新增加的内容与删除内容一致）
删除——>删除——>删除 （连续删除测试）
（11）查询功能分为两种情况，验证操作结果。
一、打开页面时自动显示结果，则不特别强调；
二、需要手工操作进行查询，则每次在其他功能完成后进行。
4 提示信息
（1） 成功、失败提示
（2） 操作结果提示
（3） 确认提示
（4） 危险操作、重要操作提示
（5） 返回页面 提示后显示的页面
5 容错性
注意以下几种情况
（1） 为空、非空
（2） 唯一性
（3 ）字长、格式
（4） 数字、邮政编码、金额、电话、电子邮件、ID号、密码
（5） 日期、时间
（6） 特殊字符 （对数据库）英文单、双引号，&符号
6 权限部分
功能权限： 指定用户可以使用那些功能，不能使用那些功能
数据权限： 指定用户可以处理那些数据，不可以处理那些数据。可
以合并到功能测试
操作权限： 在逻辑关系上，操作前后顺序、数据处理情况。可以合
并到功能测试
权限变化： 可以合并到功能测试
（1） 功能权限是否存在
（2 ）功能权限是否正确
（3） 数据权限是否存在
（4） 数据权限是否正确
（5）操作权限是否存在
（6） 操作权限是否正确
（7） 引起权限变化的功能列表
（8） 功能权限变化还是数据权限变化，或两者兼有
（9） 权限变化是否正确
7 键盘操作
（1） Tab键的使用
（2） 上下方向键的使用
（3） Enter键的使用
（4） 系统设定快捷键的使用（如果设置有快捷键）
8 测试中还应注意的其他事项
（6） 完整性：是否是一个整体，没有功能缺损
（7） 易用性：使用是否方便
（8） 一致性：类似的问题用类似的方法处理
（9） 提示信息：提示信息是否完整、正确、详细
（10） 帮助信息：是否提供帮助信息，帮助信息的表现形式（页面文字、提示信息、帮助文件），帮助信息是否正确、详细
（11） 兼容性：包括操作系统兼容和应用软件兼容，可能还包括硬件兼容
（12） 可扩展性：是否由升级的余地，是否保留了接口
（13） 稳定性：运行所需的软硬件配置，占用资源情况，出现问题时的容错性，对数据的保护
（14） 运行速度：运行的快慢，带宽占用情况
有几点：
1.功能点测试：是否满足需求所要求的功能
2.字符串长度检查: 输入超出需求所说明的字符串长度的内容, 看系统是否检查字符串长度,会不会出错.
3.字符类型检查: 在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型),看系统是否检查字符类型,会否报错.
4.标点符号检查: 输入内容包括各种标点符号,特别是空格,各种引号,回车键.看系统处理是否正确.
5.中文字符处理: 在可以输入中文的系统输入中文,看会否出现乱码或出错.
6.信息重复: 在一些需要命名,且名字应该唯一的信息输入重复的名字或ID,看系统有没有处理,会否报错,重名包括是否区分大小写,以及在输入内容的前后输入空格,系统是否作出正确处理.
7.界面测试：界面的正确性、一致性、友好性、易用性。
用户界面测试是从最终的使用者用户的角度来看软件，软件难以理解，不易使用就是软件缺陷。可以从以下几个方面重点来检查用户界面：
1.易用性检查：确保软件易于理解，方便使用。
2.一致性检查：
a.注意系统页面的风格是否一致，如字的大小、颜色、字体要相同。
b.提示信息的表达方式是否一致。
c.按钮排列顺序是否一致。
d.back, cancel等按钮跳转页面处理是否一致。
e.各字段的名称，位置、长度、类型是否和设计文档要求一致，如Employee No和LoginName不一致。
3.正确性检查：检查页面上的form, button, table, header, footer,提示信息，还有其他文字拼写，句子的语法等是否正确。
4.友好性检查：
a.提示信息是否友好.
b.系统应该在用户执行错误的操作之前提出警告，提示信息.
c.页面分辨率检查，在各种分辨率浏览系统检查系统界面友好性。
5.合理性检查：做delete, update, add, cancel, back等操作后，查看信息回到的页面是否合理。
6.检查本地化是否通过：英文版不应该有中文信息，英文翻译准确，专业。
7.页面最大化检查：测试最大化/最小化/还原时页面是否做了对应的处理
http://www.51testing.com/?116361/action_viewspace_itemid_72061.html
共93个网摘 [
1 2 3 4 ]
下一页