软件测试演义1——中高级系列.doc

本文档系作者精心整理编辑，实用价值高。软件测试演义第一部分 作者：朱少民 出处：CSDN 测试方法测试方法的辩证统一软件测试的众多方法是辩证统一的，它们相互依赖而存在，相互对立又相互补充，任何一种测试方法都有其优点，在特定的测试领域能得到充分发挥。同时，任何一种测试方法都不能覆盖所有测试的需求，在某些场合存在一定的局限性和不足。这种测试的辩证统一，从下面这些相对应的测试方法就得到很好的印证。白盒测试方法和黑盒测试方法 静态测试 (static test) 和 动态测试( Dynamic test) 手工测试（Manual test）和自动化测试(Automated Test) 有计划测试（Planned Test）和随机测试（Ad-hoc test 或Random test） 新功能测试（new feature test）和回归测试 (Regression testing) 1. 白盒测试方法和黑盒测试方法黑盒测试方法，不考虑程序内部结构和内部特性，而是从用户观点出发，针对程序接口和用户界面进行测试，根据产品应该实现的实际功能和已经定义好的产品规格，来验证产品所应该具有的功能是否实现，是否满足用户的要求。所以，黑盒测试方法技术相对要求低，方法简单有效，可以整体测试系统的行为，可以从头到尾（end-to-end）进行数据完整性测试。黑盒测试方法适合系统的功能测试、易用性测试，也适合和用户共同进行验收测试、软件确认测试。黑盒测试方法不适合单元测试、集成测试，而且测试结果的覆盖度不容易度量，其测试的潜在风险比较高。由于白盒测试方法，已知产品的内部工作过程，针对性很强，可以对程序每一行语句、每一个条件或分支进行测试，测试效率比较高，而且可以清楚已测试的覆盖程度。如果时间足够多，可以保证所有的语句和条件得到测试，测试的覆盖程度达到很高。白盒测试方法所以适合单元测试、集成测试，而不适合系统测试。白盒测试方法准备的时间很长，如果要覆盖全部程序语句、分支的测试，一般花费比编程更长的时间。白盒测试方法所要求的技术也较高，相应的测试成本要大。对于一个应用的系统，程序的路径数可能是一个天文数字，即使借助一些测试工具，白盒测试法也不可能进行穷举测试，企图遍历所有的路径往往是做不到的。即使，穷举路径测试，也不能查出程序违反了设计规范的地方，不能发现程序中已实现但不是用户所需要的功能，可能发现不了一些与数据相关的错误或用户操作行为的缺陷。所以白盒测试方法也存在一定的局限性。2. 静态测试和动态测试静态测试是通过对软件的程序源代码和各类文档或中间产品（产品规格说明书、技术设计文档），采用走查、同行评审、会审等方法来查找错误或收集所需要的度量数据，而不需要运行程序，所以相对动态测试，可以更早地进行。静态分析的查错和分析功能是其他方法所不能替代的，静态分析能发现文档中问题（也只能通过静态测试实现），通过文档中问题或其他软件评审方法来发现需求分析、软件设计等问题，而且能有效地检查代码是否具有可读性、可维护性，是否遵守编程规范，包括代码风格、变量/对象/类的命名、注释行等。静态测试已被当做一种自动化的、主要的代码校验方法。动态测试是通过观察程序运行时所表现出来的状态、行为等发现软件缺陷，包括在程序运行时，通过有效的测试用例（对应的输入 / 输出关系）来分析被测程序的运行情况、或进行跟踪对比，发现程序所表现的行为与设计规格或客户需求不一致的问题。动态测试是一种经常运用的测试方法，无论在单元测试、集成测试中，还是在系统测试、验收测试中，都是一种有效的测试方法。但动态测试不能发现文档问题，必须等待程序代码完成后进行，发现问题相对迟得多，一旦发现问题，必须重新设计、重新编码，必然增大不良质量的成本。3. 手工测试和自动化测试手工测试是指通过测试人员自身对系统进行操作来完成操作，而自动化测试是通过计算机运行测试工具和测试脚本自动进行。自动化测试具有很多优点，如执行速度高而缩短测试周期、可以多次重复运行相同的测试而减少测试的单调性、真实反映测试结果、二十四小时不知劳累运行等等，所以在测试工作中，我们尽力实现测试自动化、或扩大自动化测试的覆盖范围。但是自动化测试前期投入大，对被测对象要求高以及存在其它的局限性。软件测试自动化绝不能代替手工测试，它们两者有相应的测试对象和范围：1) 工具本身并没有想象力和灵活性，根据业界统计结果，自动测试只能发现15-30%的缺陷，而手工测试可以发现70-85%的缺陷；所以自动化测试有其局限性，不适合软件的新功能测试，而特别适合回归测试，可以保证对已经测试过部分进行测试的准确性和客观性。2) 在系统功能的逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，也很难通过自动化测试来实现，多采用黑盒测试的手工测试方法；3) 单元测试、集成测试、系统负载或性能测试、稳定性测试、可靠性测试等比较适合采用自动化测试；4) 当界面、需求变化比较频繁时、开发周期很短的软件、或做一次性软件开发项目（而不是做软件产品）时，自动化测试吃力不讨好，投入大而产出小。5) 有些测试工具只能运行在Windows平台上，不能运行在Mac/Unix等平台上。多数情况下，手工测试和自动化测试相结合，以最有效的方法来完成测试任务。4. 有计划测试和随机测试在测试执行前，我们一般都进行测试的策划、计划，分析测试的重点和范围，精心设计测试用例，来做好测试执行前的准备，通过测试计划和测试用例进行的测试是有计划的测试，而不通过事先计划或不借助测试用例，完全凭感觉、猜测而进行自由、灵活的测试，被称作随机的测试或ad-hoc test。有计划的测试效率高、针对性强，可以很好地达到测试目标，但由于用户使用软件的情景很多、千变万化，测试用例很难覆盖各种情况，特别是一些边界和特殊的操作。根据经验和历史数据统计，对于大型系统软件测试用例的覆盖度一般在90%到95%之间。所以，必须借助一些自由的ad-hoc test，充分发挥测试人员最大的灵动性、创造性，进行各种猜测和试探，去发现一些相对隐藏比较深或偏僻的软件缺陷。ad-hoc test另外一个作用是帮助测试人员尽早地熟悉产品，改进测试用例。5. 新功能测试和回归测试即使在开发一个新软件（第一个版本），在进行系统测试还是功能测试时，总会发现一些严重的缺陷而需要修正，这时就要构造一个新的软件包(Full Build)或新的软件补丁包(Patch),然后进行测试。这时的测试不仅要验证被修复的软件缺陷是否真正被解决了，而且要保证以前所有运行正常的功能依旧保持正常，而没有受到这次修改的影响。对于检验原有正常功能没有出现回归的缺陷而进行的测试，称为回归测试。对于开发第二、三个版本或以后的版本，这种回归测试所占的比重越来越大。所以，一个完整的测试，可以看作新功能或新修改的测试，加上回归测试的组合。在软件产品实现过程中，新功能的实现固然重要，可以增强产品的亮点和竞争力，增加市场份额，但是不能正常工作的已有功能所引起的客户抱怨可能更大，因为客户已经习惯地使用已有功能了，而对于新功能，客户还没怎么使用（没尝到甜头）或者客户可能不知道这个新功能，甚至我们可以在客户知道前去掉这个功能。所以，从这个意义上说，回归测试显得更为重要。前面我们曾谈到测试执行中一种有效性策略，实际就是一个典型例子，显示了有效性和风险性之间的矛盾和统一。测试方法有效性和风险性的这种关系，实际表现在整个测试周期，存在整个开发周期。1. 有效性和风险性, 首先体现在一种测试理念的较量上。虽然，当我们问一个测试工程师，测试是什么？她/他可能会毫不犹豫地说，测试是发现缺陷。当她/他管理一个测试项目或进行测试时，总是想证明所有功能是正常的，而大大降低测试的效率。至少，在心里进行不断的斗争，结果可能会去冒一些风险，可能会牺牲一些效率。2. 在制定测试策略、测试计划时，有效性和风险性的矛盾可能更突出，即确定测试的质量标准、测试范围和测试重点。“如何减少测试范围、抓住测试重点”是具有技巧性和经验性，技巧和经验提高测试有效性，有时也往往引起一些容易忽视的风险。质量标准（产品特性的具体要求）也具有策略性，是市场(marketing requirements) 和工程 (Engineering ) 的一种斗争的结果，也极具平衡的艺术。3. 设计测试用例时，我们也常常为测试用例的“颗粒度”而伤神。如果把测试用例设计得很细，照顾到每一个数据输入、每一个条件、每一个环境、每一个路径，那么测试用例的数量将是巨大的，虽然风险很小很小，但是测试效率会很低，并且测试执行没有思考的空间，可能使测试执行人员变得呆板（除非全部测试自动化），不需要创造力、思考。测试用例设计很粗，测试效率可能比较高，测试人员有一个发挥的空间，使测试更有趣，但这依赖于个人的责任感和能力，风险大得多。4. 在执行时，这种关系也比较突出，前面谈得较多，请参考： /kerryzhu/archive/2006/06/14/796881.aspx测试自动化如何才能做好测试自动化（TA)?在自动化测试引入和应用中，我们清楚一些基本的原则：选择好工具，最流行的工具不一定适合自己，真正适合自己的工具才是最好的。如Robot不一定是最好的，但它的多机交互协作能力是其它工具没有的 根据客户端、Web和服务器的不同特点可选择不同的测试工具，如Web的链接、UI变化快和复杂的逻辑，工具的录制功能要强、稳定，适应不同的平台(Windows, Linux, Mac OS)和浏览器(IE, ForeFox, NS, .)。而服务器一般不存在UI界面，主要是对不同协议的支持。 负载、性能自动化测试比较容易实现，但功能性测试更困难 软件测试自动化(TA)虽然具有很多优点，但只是对手工测试的一种补充，TA绝不能代替手工测试。在系统功能逻辑测试、验收测试、适用性测试、涉及物理交互性测试时，多采用黑盒测试的手工测试方法； 单元测试、集成测试、系统负载或性能、稳定性、可靠性测试等比较适合采用TA。 工具本身并没有想象力和灵活性，自动测试只能发现1530%的缺陷，而手工测试可以发现7085%的缺陷；TA工具在进行功能测试时，其准确的含义是回归测试工具，因为工具不能发现更多的新问题，但可以保证对已经测试过部分进行测试的准确性和客观性 找准测试自动化的切入点，一般从长期的新产品开始、同步进行，并选用一些相对容易进行自动化处理的、手工测试较繁的模块着手，如大量API调用、邮件模板处理等； 把测试开发纳入整个软件开发体系，是必要的，系统不具有可测试性，再好的工具也无能为力。而且测试自动化前期投入大，这样软件开发的前期分配的时间要多些，测试执行的时间可短些；人力分配也不同，进行资源的合理调度。测试自动化依赖测试流程和测试用例。没有好的测试流程或者没有设计有效的测试用例，测试工具会事倍功半。软件测试自动化的投入较大 但有一个问题困扰着我们，即采用下面哪种模式更好？1.专门的TA团队，负责自动化模块开发，开发完后交给进行功能测试的队伍。人为增加了一个交接工作、沟通层次，但TA团队全心再Scipting, 开发效率高，而且有利于留住TA engineer2.将产品的部分模块承包给TA团队，TA开发好了，他们手工测试就少了，让TA团队自己Drive自己，效果应该不错，但开发效率可能会低，或TA团队感觉压力太大，或不喜欢手工测试，容易被逼走去做开发。如何更好达到测试自动化的目的(2) ? 测试自动化的开展，不仅需要具有很好编程经验的工程师，而且也需要测试工程师的合作，两者需要合作。理想的话，两者合而为一。但是，如果所有测试工程师都具有良好的编程经验，其招聘工作比较难、团队的稳定性也值得担心或者成本也相对大的多。功能测试（特别是适用性、逻辑性等）测试，还是需要手工测试，需要人的直觉和经验，技术特别好的工程师做功能测试，肯定不投入，做不好。测试自动化需要一个良好的框架，从开发到运行，层次清楚，操作方便，比如通过Web方式提交任务、查看结果等，和测试执行、Bug跟踪系统的集成。测试工具的选择也是直观重要的，可能要更多去选择Open Source Tool. 测试自动化的应用，也需要建立相应的流程和规范，TA工程师如何和测试工程师、开发工程师的合作和交流，也需要积极引导。测试自动化的脚本管理，当然可以象代码一样管理，也有Check-in/check-out, 用CVS等系统。在脚本编写时，也不能Hard code, 需要积极创造条件构造数据驱动的脚本、结构化脚本，.测试自动化的完整解决方案的详细内容，请参考 http:/gotoSQA.com/uploads/4-others/TA.pdf功能测试自动化的投入和产出 测试自动化，对于系统性能测试、负载测试等效果是明显的，而且我们也不得不为之。我们知道，没有测试工具进行负载模拟，要通过手工测试完成系统测试任务，几乎是不可能的。但在功能测试中，情况就大不一样了。手工测试在功能测试中的优势还是比较大的，我在“测试方法的辩证统一（之二）”已做了讨论，工具本身并没有想象力和灵活性，而人对界面美观性、逻辑合理性，容易作出判断。所以功能测试自动化主要的应用在回归测试中，而且产品的界面(UI)和功能变化较大，自动化的脚本（Script）维护成本较大，投入和产出往往变成我们最关心的问题，在功能测试中实现测试自动化究竟是否合算？举个例子：假如一个功能测试用例，手工运行需要10分钟，而为此测试用例开发脚本需要4个小时，即240分钟，那么意味着这个测试脚本要被运行24次收回成本，如果在加上测试脚本的维护工作量（10），需要重复运行4050次，才收回成本。如果在产品的一个版本中要进行23轮测试（一般是需要的），这个产品需要发布1520个版本才收回成本。所以业界常说，产品发布7个版本才收回成本。如何降低成本、可以相对增加产出或者说更快地收回成本？关键是提高脚本开发速度、提高脚本运行的稳定性和降低维护脚本的工作量，主要方法有：选择较好的、更适合的测试工具 选择适宜自动化的模块 尽量将脚本写成数据驱动的脚本，这一点很重要。 多录制脚本，然后结构化脚本。我们知道，不是所有的模块都可以变为数据驱动方式，这时就要抽象出脚本的结构，进行有效的组合，包括分层，形成有效的层次性。 测试和脚本开发合二为一，效率更明显 下表也部分说明了这个问题。也希望得到您更好的想法。结构成本收益净收益No Automation000Recording and Playback8.3112.7Data-driven structure using data pools8.4189.6Framework structure9.8155.2Framework / data-driven (hybrid) structure focusing on views of the application and using data pools11.6197.4测试自动化普遍存在的问题 对测试工具能够发挥作用，大家都已经了解并认可了，但是很多引入自动化测试工具的软件公司并没有能够让测试自动化发挥应有的作用，其主要原因有以下几个方面：1. 不正确的观念或不现实的期望没有建立一个正确的软件测试自动化的观念，或操之过急，或认为测试自动化可以代替手工测试，或认为测试自动化可以发现大量新缺陷，或不够重视而不愿在初期投入比较大的开支等。多数情况下，对软件测试自动化存在过于乐观的态度、过高的期望，人们都期望通过这种测试自动化的方案能解决目前遇到的所有问题。而同时测试工具的软件厂商自然会强调其工具的优势、有利的或成功的一面，可能对要取得这种成功所要做出持久不懈的努力和困难却只字不提。结果，最初的期望，便得不到实现。2缺乏具有良好素质、经验的测试人才有些软件公司舍得花几十万元去买测试工具软件，但缺乏具有良好素质、经验的测试人才。软件测试自动化并不是简简单单地使用测试工具，还需要有良好的测试流程、全面的测试用例（Test case）等来配合脚本的编写，这就要求测试人员不仅熟悉产品的特性和应用领域、熟悉测试流程，而且很好地掌握测试技术和编程技术。3测试工具本身的问题影响测试的质量一般不会对自动测试脚本再做大规模的测试，所以自动测试脚本的质量往往依赖于TA工程师的经验和工作态度，如果自动测试工具不能提供一种机制来保证脚本的的质量，那将直接影响到测试结果的正确性。通过自动测试工具测试的Test Case是不需要再进行手工测试的，将自动测试与手工测试有效的结合，并在最终的测试报告中也体现自动测试的结果，是比较正确的做法。4没有进行有效的、充分的培训人员和培训是相辅相成的，如果没有良好的、有效的、充分的培训，测试人员对测试工具了解缺乏深度和广度，从而导致其使用效率低下，应用结果不理想。这种培训是一个长期的过程，不是通过一两次讲课的形式就能达到效果。而且，在实际的使用测试工具的过程中，测试工具的使用者可能还存在着这样那样的问题，这也需要有专人负责解决，否则的话，会严重影响测试工具的使用积极性。5. 没有考虑到公司的实际情况，盲目引入测试工具有一点很明确，不同的测试工具面向不同的测试目的、具有各自的特点和适用范围，所以不是任何一个优秀的测试工具都能适应不同公司的需求。某个公司怀着美好的愿望花了不小的代价引入测试工具，半年一年以后，测试工具却成了摆设。究其原因，就是没有能够考虑公司的现实情况，不切实际地期望测试工具能够改变公司的现状，从而导致了失败。例如，国内多数软件公司是针对最终用户进行项目开发-工程性质的软件，而不是产品开发。项目开发周期短，不同的用户需求不一样，而且在整个开发过程中需求和用户界面变动较大，这种情况下就不适合引入黑盒测试软件，因为黑盒测试软件的基本原理是录制/回放（虽然通过修改，形成结构化测试脚本），对于不停变化的需求和界面，可能修改和录制脚本的工作量大大超过测试实施的工作量，运用测试工具不但不能减轻工作量，反而加重了测试人员的负担。这种情况下可以考虑引入白盒测试工具，以提升代码质量。6. 没有形成一个良好的使用测试工具的环境建立良好的测试工具应用环境，需要测试流程和管理机制做相适应的变化，也只有这样，测试工具才能真正发挥其作用。例如，对于基于 GUI 录制/回放的自动测试来说，产品界面的改变对脚本的正常运行影响较大。再者，白盒测试工具的一般在单元测试阶段使用，而单元测试在多数公司是由开发人员自己完成，如果没有流程来规范开发人员的行为，在项目进度压力比较大的情况下，开发人员很可能就会有意识地不使用测试工具，来逃避问题。所以，有必要将测试工具的使用在开发和测试的流程中明确起来，如在项目各个里程碑所提交的文档中，必须包含某些测试工具生成的报告，如集成测试时DevPartner工具生成的测试覆盖率报告、Logiscope生成的代码质量报告等。7其它技术问题和组织问题软件测试自动化所需要的测试脚本其维护量很大，而且软件产品本身代码的改变也需要遵守一定的规则，从而保证良好的测试脚本使用重复性，也就是说测试自动化和软件产品本身不能分离。其次，提供软件测试工具的第三方厂家，对客户的应用缺乏足够理解，很难提供强有力的技术支持和具体问题的解决能力。也就是说，软件测试工具和被测试对象软件产品或系统的互操作性会存在或多或少问题，加之技术环境的不断变化，所有这些对测试自动化的应用推广和深入，都带来很大的影响。还有安全性的错觉，如果软件测试工具没有发现被测软件的缺陷，并不能说明软件中不存在问题，可能测试工具本身不够全面的问题或测试的预期结果设置不对。强大的Web开源测试工具Selenium 介绍Selenium 是 ThoughtWorks 专门为 Web 应用而开发的自动化测试工具，适合进行功能测试、验收测试,其最大的优势有几点：可直接运行在浏览器之上，所见即所得，就像真实用户所做的一样。Selenium 的核心，也称 browser bot，是用 JavaScript 编写的。这使得测试脚本可以在受支持的浏览器中运行。browser bot 负责执行从测试脚本接收到的命令 支持多操作系统（Windows, Mac OS和Linux）和各种浏览器Internet Explorer、Mozilla 和 Firefox，更容易发现浏览器的不兼容性 支持两种开发脚本的模式test runner （HTML文件）和 driven（脚本语言编写），其语言包括Java, .NET, Perl, Python 和 Ruby. 使用 driven 脚本，测试有一部分在浏览器之外运行，而如果使用 test runner 脚本的话，测试是完全在浏览器中运行的。 但是Selenium是轻量的测试框架， 脚本所处理的测试用例构成简单，其实质就是通过HTTP协议，发送请求（request）来完成测试用例，所以很困难处理业务逻辑关系强的测试用例。 更多的讨论： /index.jspaSelenium 命令Selenium 命令分成两类 操作（action） 和断言（assertion）：操作模拟用户与 Web 应用程序的交互。例如，单击一个按钮和填写一个表单，这些都是常见的用户操作，可以用 Selenium 命令来自动化这些操作。 断言验证一个命令的预期结果。常见的断言包括验证页面内容或当前位置是否正确。 在 Selenium 网站上可以找到可用命令的完整列表。通过 Selenium 命令，脚本编写者可以描述 browser bot 在浏览器中所执行的操作组成Selenium IDE：一个firefox的plug-in,可以录制和回放并保存一些test cases, 可以生成一些简单的基于rc 模式的简单code. （相当于Jmeter的gui模式和jmeter脚本的生成-badboy） Selenium Core. 整个测试机制的核心部分，即有assertion（断言） 机制的test suite runner。它由一些纯js代码组成， 可以运行在windows/linux的不同browser上 （相当于Jmeter 的runner 跟 Assertion） Selenium Remote Control：一个代理与控制端， 可代替Selenium core/ Selenium IDE的client端(相当于通过编程来实现一切)，是支持多语言的. (相当于Jmeter的client/server模式,但Selenium Remote Control更强一些) 支持的平台 Windows: oInternet Explorer 6.0 oFirefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+ oSeamonkey 1.0, Opera 8 Mac OS X: oSafari 1.3+ oFirefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+ oSeamonkey 1.0, Camino 1.0a1 Linux: oFirefox 0.8 to 1.5, Mozilla Suite 1.6+, 1.7+ oKonqueror 部署Selenium下载地方：/selenium/selenium目录下的内容： devtests：试验性功能 dom-images: 查看DOM用图片dom-styles: 查看DOM用样式表html-xpath: Xpath库jsmock: javascript mock library jsunit: javascript unit test librarytests: samples(以这个为基础开发测试用例)核心js文件和html文件 如果想要测试自己开发的发布在服务器端的页面，需要把selenium配置在同一个服务器下：Apache ：直接将selenium目录拷贝至htdocs（Apache的确省根目录）目录下，然后启动Apache，用地址http:/server：8080/selenium/TestRunner.html访问例子。Tomcat ：直接将selenium目录拷贝至webapps目录下，启动Tomcat，用地址http:/server：8080/selenium/TestRunner.html访问例子。：IIS：建立一个虚拟目录selenium，将该虚拟目录直接指向实际的selenium目录，用地址http:/server/selenium/TestRunner.html访问例子Test runner 脚本开发模式Selenium test runner 脚本，就是测试用例（test case），是用 HTML 语言通过一个简单的表布局编写的，即使对于非技术人员来说，test runner 脚本也易于阅读和编写。如 清单 1 所示。清单 1. Selenium 测试用例的结构 (HTML格式)Command1/Assertion1Target1Value1Command2 Assertion1Target2Value2test runner 脚本使用与 xUnit 框架相同的测试套件（test suite）和测试用例概念。测试用例和命令按照它们在测试套件和测试用例中出现的顺序依次执行。在 清单 1 中：第一列包含命令 或断言。 第二列包含命令或断言的目标（target）。可以用多种受支持的组件定位符中的一种来指定目标。通常使用的是组件的 ID 或名称，但 XPath 和 DOM 定位符也是受支持的。 第三列包含用于为命令或断言指定参数的值。例如，当使用 type 命令时，这一列可能就是一个文本域所期望的值。 Test runner 脚本通常与所测试的应用程序（AUT）部署在同一个服务器上。这是因为 browser bot 使用 JavaScript 来模拟用户操作。这些脚本在一个受限制的沙箱环境中运行。如果需要绕过这些限制，可以使用一个代理。driven 脚本开发模式driven Selenium 脚本是用多种受支持的编程语言(Java, .NET, Perl, Python 和 Ruby)中的一种编写的。这些脚本在浏览器之外的一个单独的进程中运行。驱动程序的任务是执行测试脚本，并通过与运行在浏览器中的 browser bot 进行通信来驱动浏览器。驱动程序与 browser bot 之间的通信使用一种简单的特定于 Selenium 的连接语言 Selenese。driven 脚本比 test runner 脚本更强大、更灵活，可以将它们与 xUnit 框架集成。driven 脚本编写和部署更复杂些，它必须执行以下任务：启动服务器。 部署所测试的应用程序（AUT）。 部署测试脚本。 启动浏览器。 发送命令到 browser bot。 验证 browser bot 执行的命令的结果。 driven 脚本更依赖于应用程序运行时环境。例如，Java 驱动程序使用一个嵌入式 Jetty 或 Tomcat 实例来部署所测试的应用程序，如将 Selenium 集成到 Ruby on Rails 中。开发测试用例测试用例开发涉及四类文件主文件： TestRunner.html/TestRunner.hta(.hta文件是html application，windows平台特有)； Test suite和Test case文件：需要编写的由一个表格组成的html文件； 引擎库js文件：位于selenium根目录下的核心文件，其中html-xpath目录下的那个文件，也是必须的库文件； user-extensions.js：用来扩展selenium的文件；用户自己编写的函数和扩展的命令都应该放在这个文件中；这四类文件中，除了引擎库以外，其他三类文件都是可以根据具体情况去修改的。selenium 部署完毕后，可以打开浏览器来通过url来访问TestRunner.html文件。初始的时候，TestRunner.html文件中的 TestSuite是链接到tests目录下的TestSuite.html文件，TestCase的frame(上部中间)中打开了 TestSuite.html文件中的第一个Test Case “TestOpen.html”。可以直接修改TestSuite.html文件，让其指向自己开发的Test case html文件。我们也可以建立另外一个目录，然后将自己的TestSuite文件和Test case文件都保存在这个目录中。如果使用后一种方式，那么在打开TestRunner.html的时候需要传递一个参数，例子如下： http:/localhost/selenium/TestRunner.html?test=/testDir/myTestSuite.html下面就是开发测试用例即编辑测试用例的表格。无论Test Suite还是Test Case，表格的第一行都是描述性文字，selenium的引擎是不会处理这一行的内容的。实际内容都是从第二行开始的。Test case的表格列数一定不能少于3列，否则Selenium会出错。而基本的三列组成是： |command| Target| value| 清单 2就是四个测试用例的例子，将执行以下操作：1.通过进入 /change_address_form.html 打开变更地址页面。 2.在 ID 为 address_field 的文本框中输入 Betelgeuse state prison。 3.单击名为 Submit 的输入区。注意，这里使用 XPath 找到 Submit 按钮，这导致表单数据被发送到服务器。 4.验证页面是否包含文本 Address change successful。 清单 2. 在测试用例中使用命令和断言的例子commandTargetValueopen/change_address_form.html typeaddress_fieldBetelgeuse state prisonclickAndWait/inputname=Submit verifyTextPresentAddress change successful 测试套件要达到对应用程序的完全测试覆盖，通常需要不止一个测试用例。这就是 Selenium 使用测试套件的原因。测试套件用于将具有类似功能的一些测试用例编成一组，以便让它们按顺序运行。测试套件和测试用例一样，都是用简单的 HTML 表编写的。Selenium 执行的缺省测试套件的名称是 TestSuite.html。测试套件使用一个只包含一列的表，表中的每一行指向一个包含某个测试用例的文件。对于一个有着多个功能模块、组件的web应用，编写的测试脚本html必然比较多。因此，应该建立一个合理的目录结构来组织这些脚本，一般按web服务、模块、功能来组织，形成层次性结构。 最好的测试工具 非常Cool! 值得一看。盼望已久的测试工具：/5/3/14853/v003/1a1a1a72db3eb01f920167db4fb41745a9188ffd69d8399dcb2c97f865c62f5dc02f9ccbfc30689dd0ff6cdf44bc2c5bc83ba01888b7fc356ea7e0测试执行测试执行中非常有效的策略对于大型项目，软件测试的执行，除了需要很好的测试范围分析、测试计划制定和测试资源的分配与组织之外，还是有一个容易被大家忽视的策略问题。对于大多数应用项目（非国防、载入飞船上天、净室工程等），我们都知道，测试不是为了证明所有的功能能正常工作，恰恰相反，测试就是为了找出那些不能正常工作、不一致性的问题，也就是说，测试的一般工作就是发现缺陷 (detect bug)，当然这些缺陷包括需求分析、设计等的缺陷，不仅仅是程序中的运行。测试的启动和项目启动是同时发生的，测试的重要工作是在测试用例的设计，这是随后测试执行的基础。同时，我们应该承认，测试的主要工作是在测试的执行，当自动化测试工具在功能测试中发挥作用比较困难时，测试执行的工作量还是很大的。如何更早地发现缺陷又不增加风险？测试的本质是什么，发现缺陷还是风险评估？如何引导大家向着一个目标产品及时高质量发布努力？1. 首先就要向测试人员灌输一个概念“测试的一般工作就是发现缺陷 (detect bug)”，达成共识，这是很重要。这样，测试人员，就知道什么是自己真正的工作。这一点，不仅在测试执行时发挥作用，而且在设计测试用例时更能发挥作用。2. 测试执行阶段可以划分为两个子阶段，前一个阶段的目的非常清楚，就是发现缺陷，督促大家就是找出缺陷。测试用例的执行，应该是帮助我们更快地发现缺陷，而不是成为“发现缺陷”的障碍使发现缺陷的能力降低。从理论上说，如果缺陷都找出来了，质量也就有保证了。所以在这一阶段，要不顾风险，就是发现缺陷，这样不仅对开发团队也非常有利，能尽早地修正大部分缺陷；对测试有利，测试效率高，后面的回归测试也会稳定，信心更充分。3. 在代码冻结或产品发布前的稍后的子阶段，目的是减少风险，增加测试的覆盖度，这时测试的效率会低一些，以损失部分测试效率以极大降低风险、获得更高质量的收益。4. 在前一阶段，测