为了适应公司新战略的发展，保障停车场安保新项目的正常、顺利开展，特制定安保从业人员的业务技能及个人素质的培训计划ruby,html测试用例报告使用RubyonRails为web应用准备测试数据淘宝网测试部博一摘要：web应用开发大多具有短频快的特点，在大型web应用测试中，测试员通常需要快速准备大量的测试数据，但却没有提供便利的数据准备支持。测试员经常面临这些挑战：大多数web应用并没有提供相应测试性接口来简化准备数据的过程；使用WEB页面自动化来准备数据成本太高、不可靠；SQL方式难于应对多数据库、对数据表的复杂情况。本文提出了一种数据准备策略：通过ORM方式操作数据、克隆数据、备份/还原数据，来解决数据准备的问题。在技术实现上采用目前广泛使用的敏捷web框架RubyonRails。RubyonRails内置的ORM/数据库迁移/seeddata等一系列特性为数据准备带来了很大的方便性；关键词：web测试，RubyonRails，测试数据，ORM，数据快照，数据克隆，seeddata，序列化，反序列化，yml，json，xml概述web应用开发大多具有短频快的特点，尽管淘宝网的业务很复杂，80%的项目周期在2个月以内。在大型web应用测试中，测试人员通常会面临很多挑战，比如：怎样进行有效的测试设计？怎样快速准备好测试数据？怎样实施高可靠的自动化测试？怎样进行低成本的回归测试？锁定问题本文主要讨论如何快速准备测试数据的问题。在web应用测试中，测试员通常需要快速准备大量的测试数据。然而这一看似简单的过程，也经常会听到测试人员抱怨：业务复杂，需要准备的数据类型太多，准备数据的过程很麻烦；我可以手工制作一次，但不要让我重复做；我准备好的数据被不明原因破坏了；人们已经想了很多办法来在降低测试数据准备成本：提供可测试性接口-对设计、开发要求高，WebAPI非常有限；页面自动化自动化脚本开发、维护成本高，可靠性低；数据库管理工具、SQL遇到多数据库、多数据表、或者需要较多数据计算时，这种方法很难凑效；我的数据准备策略针对测试员普遍抱怨的3个问题，可以采用如下解决办法：1、使用ORM替代SQL，简化数据操作的复杂度；2、数据克隆，解决重复制作数据的困扰；3、创建数据快照，实现备份和还原，应对破坏；用户使用场景如下：而这一切需要的技术，RubyonRails早已为我们准好了。为了简化数据库访问，大多web框架支持ORM，实现以程序对象的方式操作数据库，避免写SQL的繁琐。RubyonRails对测试的支持了解RubyonRails测试在创建新的Rails项目时，Rails会自动生成测试基础设施，这些文件被放置在test目录下，里面有4个目录和一个helper文件：清单1.Test目录的内容将您的所有测试放在/test目录中，特殊的测试根据性质和功能分别放在相应的子目录中。下面解释一下/test目录中的每个组件：test_test_文件建立多个测试用例共有的许多默认Rails测试行为。例如，在test_中，设置为以测试环境启动Rails，并加载测试框架。Rails中所有测试都装载test_文件。Fixtures测试夹具，yml格式的数据文件，用于定义测试数据。Rails在运行单元测试时能够装载这些数据。Unit在Rails中，为测试模型编写的测试称为单元测试。一般情况下，要为每个模型编写一个单元测试。在单元测试中，要测试所有可能破坏模型逻辑的东西。基本测试应该包括对检验代码和断言以及数据库操作的测试。Functional为测试控制器编写的测试称为功能测试。它们在高于单元测试的层次上测试应用程序。同样地，一般情况下要为每个控制器编写一个功能测试。功能测试中的每个测试用例，用于验证某个功能，例如：测试成功的Web请求、正确的页面重定向、正确的身份验证以及对特定动作的正确响应。Integration集成测试是涉及多个控制器和动作的测试。顾名思义，这种测试确保不同的控制器和动作按照预期的方式配合工作。集成测试一般比较完整，因为它们覆盖Rails应用程序中各个组件之间的高层交互。PerformanceRails性能测试，用于测试对web请求的响应速度，每个测试结果被保存在tmp/performance。RubyonRails如何简化数据库访问RubyonRails为Web开发提供了MVC框架，默认使用ActiveRecord组件来实现数据层访问。ActiveRecord使用ORM技术来抽象数据库访问，绝大多数情况下，开发人员不需要写SQL，再配合上ruby语言自身的简洁性，有效的提高开发效率。在RubyonRails只需要创建一个ActiveRecord:Base子类，就能实现ORM：在不配置关联的数据表名称时，ActiveRecord将按照约定，自动把Book类与books数据表关联起来，从而建立起了Book类与books的ORM映射。可以看到，在Rails中使用ActiveRecord提供的ORM方式访问数据库是很方便的，只需为数据表建立一个关联的ActiveRecord:Base子类。注：Rails提供了一组方法，来处理字符串与类的关系，例如：String#tableize()用于获取字符串对应的数据表名称；String#classify()用于获取字符串对应的驼峰风格的ruby类名称，用法请参考：http:/classes/ActiveSupport/CoreExtensions/String/RubyonRails对测试数据的支持Fixtures，测试夹具Rails提供测试夹具，用于定义测试数据。在运行单元测试时能够装载这些数据，例如可以定义如下的测试数据：然后在单元测试中使用数据：清单book_可以看出，在准备少量测试数据的时候，fixtures用起来很简单。但如果web系统中，业务数据复杂，在准备大量不同类型测试数据的时候，fixtures就显得很麻烦。例如，如果要测试一个图书分享网站，需要构造上百个用户、上百本书，并且要建立用户与用户之间的关系，该如何准备测试数据呢？Seeddata从RubyonRails开始，提供了一种非常方便的数据初始化技术seeddata，开发人员使用rakedb:seed任务就可以向数据库中初始化数据。应用程序需要的数据可以通过在使用准备数据最大的方便在于，可以直接调用RubyonRails的数据访问层代码，就像是在写Rails代码。配合ruby语言，可以非常容易的构造测试数据，并保持数据的完整性。扩展阅读请参考：http:/episodes/179-seed-data使用RubyonRails为web应用准备测试数据对于非Rails应用又该如何准备测试数据？首先Rails需要具备web应用的数据访问权限，再利用Rails的ORM/fixtures/seeddata特性可以非常方便的准备web应用的数据。记得去年年初的时候，(来自:写论文网:ruby,html测试用例报告)就做过关于如何写测试用例的分享，说了为什么要写测试用例，什么是测试用例，如何写测试用例，什么样的才叫好的用例，什么样的叫不好的用例，也说了写用例的纠结：前提条件和执行步骤的纠结;测试用例标题的纠结;预期结果的验证的纠结等等。个人觉得讲得很详细了，觉得效果不错的，为啥后来那些培训的同学对于写测试用例没有一个系统的概念呢，不知道怎么去写一个好的用例呢?这个blog的作用不是讲这些，而是说下工作一两年内都很容易出现的用例结构问题。你去问一线测试工程师，资深测试工程师，TL，Manager，甚至是Director，都不能对怎么写好用例达成一个共同的意识，以及共同的作业方式，当然我们不期望流程化，死板化，但我希望我们不要忘了我们的测试信念，我们的质量意识。背景介绍：今年部门大量采用新模型进行项目测试，将去年做好基础的自动化测试，接口测试用到项目过程中去，真正的做到测试提前，为开发质量提高更早，更前面的保证和跟踪。模型注意改进点在开发Coding阶段，我们先看下以前SPR模型下，测试做了哪几个工作：1.接口说明文档评审2.数据库设计文档评审3.测试设计4.测试用例编写5.测试用例评审和修改相比较旧模型而言，下面再看下新模型下，测试又会去做什么呢：1.制定测试开发计划2.接口说明文档评审3.数据库设计文档评审4.自动化测试设计5.自动化测试脚本开发准备(PageModel和DBmodel的建立;自动化脚本伪代码编写)6.接口测试设计7.接口测试脚本开发(搭建接口测试环境，接口测试代码编写，调试，后期Hudson上回归)8.自动化测试脚本和接口测试设计评审和修改9.CodeReview大家是不是感觉到了明显的变化，那就是我们测试需要做更多的前期事情，那这样我们就需要对我们的测试用例模型(MM图)进行改进，以适应新的变化。对于做MM图，我自己对MM图的理解也许和大家不一样，我每次做项目，做出来的MM图都比较细，不仅仅是列出我要测试的每个功能点，而且每个功能点的测试设计和测试场景都写出来了，而且我觉得一个非常好的MM图(测试设计)需要经过如下三个步骤：MM1-PRD阶段，使用RBT方法做出来的MM图(功能点划分，P1和P2的用例场景)MM2-UC阶段，使用RBT方法强烈ReviewUC做出来的MM图(补充P1和P2的用例场景，P3和P4的用例场景)MM3-系统设计阶段，通过Review接口说明文档，详细设计文档，数据库设计文档(补充每个功能点容易遗漏的异常场景和详细校验点)当然这里面的MM图不是一成不变的，在测试执行阶段，这个MM图也会新增或修改测试思路(特别是发现了一些用例没有写的bug)，下面就看一下例子吧：那么如果我们使用了新模型后，我们的MM图就必须加一些标记了，新模型的coding阶段，我们测试人员没有太多时间去编写详细的测试用例，我们有很多的自动化测试用例和接口测试用例，这时我们的MM图就可以变成这样了：注意上图的Automan就是自动化测试脚本的标记，iTest就是接口测试脚本的标记，另外一个就是Manual了。当然也不能简单了，我们最好能把自动化测试脚本和接口测试脚本编写的环境连接起来，比如我打开了一个标记为自动化测试用例的环境，如下：PageModel，DBModel和Ruby编程环境，能够把用例标题写入脚本模板中再比如我打开了一个标记为接口测试用例的环境，如下：Java代码编写环境,能够把用例标题写入脚本模板中，优化脚本模板其实这里面区别开我们的手工测试用例，自动化测试用例，接口测试用例可以有2种方式：1.一种是在功能点来进行划分：细分到一个很小的功能点，写测试思路的时候，不用Care是什么类型的测试用例，最好评审完后，加上一个简单的标记即可，上图的方式就是这种方式，就是统计数据比较麻烦一点。2.另一种是根据用例类型来划分：首先划分3个维度，然后再维度后面加上自己的功能点的测试思路这样做的优点就是很清晰的知道不同的测试类型的用例个数或复杂度等，但注意这里面有个缺点：就是有可能一个功能点会存在多个不同的测试类型，所以本人建议使用第一种方式来做。最后需要强调的是我们的测试思路的标题一定要