qileilove

为什么集成测试比单元测试更重要

posted @ 2013-03-19 11:07 顺其自然EVO 阅读(177) | 评论 (0) | 编辑 收藏

LoadRunner 技巧之检查点

posted @ 2013-03-19 10:42 顺其自然EVO 阅读(341) | 评论 (0) | 编辑 收藏

怎样进行数据库性能测试

posted @ 2013-03-19 10:22 顺其自然EVO 阅读(1151) | 评论 (0) | 编辑 收藏

如何做好Code Review：思考、方法和实践

　最近被要求做一个关于Code Review的讲演。首先要说明的是，我并不是太擅长开展Code Review的活动。做这个完全是因为答应了别人又不好反悔。不过在做准备的过程中还是有一些感想。

　　关于Code Review我所了解到的行业中最著名的是Bill Gates汇报。这是微软在软件开发过程中的一个重要环节，因为Bill Gates亲自参加而备受关注，在行业中广为流传。

　　Ok，进入正题了。

　　我们面临的共同问题：

　　1、对于开发周期较长的软件项目，可维护差的代码对项目造成了极大的困扰

　　2、结构复杂的，体系不清楚的代码会导致新成员或者外部干系人很难融入。

　　3、软件项目代码质量低下，Bug众多并且有关联累积效应。

　　以上三个问题是我在以往的Code Review活动中总结出来，可以被影响或者解决的问题。也就是说我的观点是如果没有上述问题，或者在目前的软件产品的规模、开发过程的成熟度还没有达到一定级别时Code Review是可以不做的。当然优秀的开发人员会做自我审查，这是另外一个问题了。

　　总而言之，我认为开展Code Review活动的前提是

　　1、开发过程和质量控制达到了一定的成熟的。

　　Code Review必然与重构相关联。如果开发过程中更本就没有重构这样的活动，那估计Review出来的结果不太容易得到执行。

　　其次是各种标准和规范的齐备性，没有规矩是不能成方圆的，如果只有一个命名规范，那可想而知Review的内容不会太深入，效果因此大打折扣。

　　2、代码达到一定那个的规模一般来说，功能单一的小型项目的体系结构不会太复杂。不太会出现Bug的累积效应。小型项目完全可以通过daily meeting和Test来保证。

　　Code Review并不是一个随便就可以做，或者做了就有好结果的活动。不过无论如何，一旦条件成熟或者资源充足都应该积极的开展Code Review的活动。因为它除了进行质量控制以外，还是一个团队成员之间进行沟通和相互学习的好机会。

　　Code Review的内容：

　　1、代码的规范性

　　　　a、混乱而散漫的命名，例如使用a、b、c这样的单字母对变量进行无意义的命名

　　　　b、随处可见的magic number或则hard code。软件中const在所难免，不过这些const应该被集中管理起来。而不是可以随意、随处的出现

　　　　c、缺少注释，或者注释不完备甚至错误

　　2、代码的结构问题

　　　　a、巨大的类或者巨大的方法

　　　　b、过于复杂的实现

　　　　c、紧耦合

　　　　d、重复的代码

　3、其他问题

　　　　a、缺少验证和异常处理。例如不对数据进行验证，或者不处理异常又或者捕获无法处理的异常

　　　　b、对工具和框架的错误使用。例如有的ORM框架提供非常方便的运行时延迟加载功能，方便倒是方便，滥用却会有性能隐忧

　　　　c、缺少可读性。注释和命名规范是一个问题，不过过深的调用层次都会影响代码可读性。

　　　　d、缺少扩展性。例如在没有DLR的情况下在业务层使用匿名对象。

　　　　e、缺少安全控制

　　　　f、性能隐患。例如在C#中使用了非托管资源而没有进行释放，或者说有过多、过于频繁的I/O访问

　　4、测试问题

　　　　a、没有测试或者覆盖度不够

　　　　b、测试代码滞后，在更改逻辑后没有对测试进行同步更新

　　以上是一些通常的Code Review的内容了。当然这里再强调一点的就是规范的完备性，和开发过程的成熟度。Code Review是一种相对高级软件开发活动，没有必要一定要执行。不过一旦实施成功将会有巨大的回报。

　　在实施过程中还有一些心得：

　　1、做好准备。如果对项目很熟的话，应该知道哪些地方会有问题，Code Review是重新审视和从内因上解决这些问题的良机。

　　2、不要考虑业务逻辑。完全专注于代码的实现，例如算法的效率，抽象的粒度。整个代码体系结构的平衡性

　　3、虚心学习。不要有针对性

　　4、在原则和现实之间平衡。不可能所有事情都完美，所以有的时候我们坚持原则，有的时候修改规范。

　　5、不要让自己Review自己的代码

　　6、总结跟进Review的结果，并且坚持开展这个活动。这才是最重要的

posted @ 2013-03-18 10:11 顺其自然EVO 阅读(567) | 评论 (0) | 编辑 收藏

CMMI过程改进之路——质量保证误区

　如何提升产品质量在业界是一个永恒的话题，零缺陷是理想化的，永远只能作为目标而不能到达，客户基于市场压力和竞争等方面的考虑，优先考虑的往往是进度，如何定位质量保证（QA）角色、如何平衡进度、质量、成本的关系，是质量保证的核心关键，关于质量保证常存在下列误区：

　　（1）组织架构中QA团队误区：

　　在不少公司，基于成本考虑，缺少了真正的高素质的质量保证人才，这其实是管理层的意识问题，认为设立QA岗位，人才的招聘、培训、薪酬、福利、工作环境的消耗将是一笔不小的成本支出，根本没有必要，实际上是一个不好的作法。组建QA团队，确实是需要一笔费用，如果是高水平的团队，付出费用更大，但从长远来看，这笔费用肯定可以从将来产品质量的提升、成本的降低、进度的提前、客户满意度提升、市场占有率等方面获取丰富的回报。一个质量管理优秀的公司，所获得的收益远远超过了QA团队的人力成本。

　　（2）“进度优先还是质量优先”误区？

　　实际上要根据公司的商业目标来确定，如果项目进度是十万火急的，不能按时交货，可能就会遭受严重经济损失或失去生存机会，我想肯定的选择是公司的生存第一，在进度保证的前提下，再考虑质量保证。但在一些业界优秀的公司，进度已经往往作为质量的一部分，进行综合平衡考虑和解决。

　　（3）QA团队的“选人”误区：

　　曾看到一些公司，为了通过CMMI评估，都成立了QA组织，但是选人的标准也是基于成本考虑，往往是一些刚毕业不久的大学生，由于缺乏足够的开发和项目管理经验，在项目的流程执行中，不能给予项目团队有效的指导，不能识别公司的商业目标的价值，只能机械按照过程体系的要求执行，造成项目团队的不信任，甚至引起严重对抗，从而破坏了和诣、开放的卓越团队文化。在一些跨国大公司，其实QA的标准要求是很高的，要有多年的项目开发管理经验，甚至是曾担任过资深的项目经理优先，只能这样，才能够深该理解公司的商业目标和过程体系，并可以作为导师或顾问有效识别、规避项目风险、指引项目团队前进的方向。

　　（4）QA团队的“定位和运作”误区：

　　QA团队并不能只作为高高再上的检查者，或者只定位为“警察角色”，更应该是作为服务者的角色出现，QA团队是必须为项目团队服务的，要有一颗“谦虚”的心，要做到能换位思考，要能站在管理层和项目团队的角度来考虑问题，我想这样就会明白QA团队的价值和意义。

　　QA团队核心工作是推动过程改进、进行缺陷预防，实现公司商业目标 ，因此QA团队最重要的是要明白流程的价值，由于所有流程是基于一定的环境或条件建立的，对不同项目可能作用都不同，甚至可能不适用，要能够从公司全局出发，根据成本、进度、质量、客户满意度等条件进行判断，给项目团队提供帮助，进行过程裁剪，并提供给管理层高价值的真实项目情况，成为管理层真正的“眼睛和耳朵 ”。只有这样，QA团队才能取得管理层的支持，质量保证意识才能融入并扎根于公司卓越企业文化之中。

posted @ 2013-03-18 10:10 顺其自然EVO 阅读(1029) | 评论 (0) | 编辑 收藏

LoadRunner 技巧之集合点设置

Loadrunner 技巧已经整理3篇了，你个一定疑问，这些知识点，网上随处可见。确实，由于长时间没有使用这个工具，造成我的一些概念开始在大脑中模糊，我只是用这种方式来温习。

　　----------------------

　　在loadrunner的虚拟用户中，术语concurrent（并发）和simultaneous（同时）存在一些区别，concurrent 是指虚拟场景中参于运行的虚拟用户。而simultaneous与集合点（rendzvous point）关系更密切，是指在同一时刻一起执行某个任务的虚拟用户。

　　我们来想象一个场景，10名运动员参加长跑比赛，出发点同时起跑，他们是并排奔跑的；跑了N圈之后，因为有体能更强的，有体能稍弱的，他们的队形并排变成了前后。几乎一个跑道就可以供应他们的奔跑（运行），那么其余的9条跑道就是空闲的。

　　为了充分的利用跑道，可以将跑道的起点设置一个集合点，当所有运动员跑完一圈后在起跑点集合，然后再同时起跑。

　　运动员可以看作是虚拟用户，跑道可以看作是系统资源。设置集合点可以模式更加真实的并发请求，从而增加对系统的负载。

　　下面录制一个登录触摸屏版139邮箱的脚本。录制步骤：

　　1、打开登录页面

　　2、插入集合点

　　3、输入用户名密码，点击登录按钮

　　4、登录页面加载完成，录制结束

　　脚本添加集合点

　　当我们在不熟悉脚本的情况下，可以通过世录制操作面板来添加集合点。

　　如果你非常熟悉每一段脚本代码的作用，可以在脚本中添加：lr_rendezvous 集合点函数。

　　录制代码如下：

　控制器中设置集合点策略

　　我们在Virtual User Generator 中回放脚本无法体现集合点的作用。集合点是在多用户并发运行的时候才能起作用。所以，我们需要把脚本导入到Controller 中进行进一步的设置。

　　1、打开Controller （控制器），导入录制的脚本。

　　2、菜单栏 Scenario ---> Rendezvous 打开集合点设置界面

　　我们可以看到Vusers 列表框里有10个集合点（1~10），这里的数量和我们设置的虚拟用户数一致。

　　我们可以点击选中某个集合点，点击“Disable VUser” 按钮，使其不参与集合点。（某班级早晨集合跑步，A同学肚子痛，经过老师的允许不参与早晨的集合跑步。）

　　点击“Policy...”来设置集合点的策略：

　　下面来看看这三种策略的含义：

　　Release when ：当所有虚拟用户中的x % 到达集合点进释放，即仅当指定百分比的虚拟用户到达集合点时，才释放虚拟用户。

　　注意：此选项将会干扰场景的计划。如果选择此选项，场景将不按计划运行。

　　Release when ：当所有正在运行的虚拟用户中的x %到达集合点时释放，即仅当场景中指定百分比的、正在运行的虚拟用户到达集合点时，才释放虚拟用户。

　　还有不在运行的虚拟用户？ 假如，设置为1分钟启动一个用户，当然会存在因为用户还没启动，所以无法参与集合点。

　　Release when ： 当x 个虚拟用户到达集合点时释放，即仅当指定数量的虚拟用户到达集合点时，才释放虚拟用户。

　　这个很好理解，当我用百分比不太好衡量集合点的虚拟用户数，当然可以设置具体的用户数。

　　Timeout between Vusers （虚拟用户之间的超时）框中输入一个超时值。

　　假如设置了集合10用户并发，结果9个用户已经集合到位，还剩1个虚拟用户，左等右等就是等不来。那总不能一直等下去吧。设定了个时间，假如30秒还不来，那就不管它了。

　　超时的时长默认是30秒，我们可以根据具体的被测应用进行调整。

相关链接：

LoadRunner 技巧之协议分析

LoadRunner 技巧之THML 与 URL两种录制模式分析

LoadRunner 技巧之思考时间设置

posted @ 2013-03-18 10:08 顺其自然EVO 阅读(412) | 评论 (0) | 编辑 收藏

LoadRunner 技巧之自动关联

这一节讲loadunner 关联的问题，其实这个东西理解起来简单，但说起来比较麻烦。

　　关联的原理：

　　先来模拟一个场景，我去坐火车，坐火车要先检票，检票员核对火车票的时间、班次等信息正确后允许我坐火车。

　　过了几天，我又拿着一张票去坐火车，检票员再一次核对火车票信息，发现这张票过期了，肯定不让我坐了。那我怎么才能坐火车呢？我先看看旁边那哥们的火车票上的信息，然后把自己的查票涂改成和他一模一样再去坐火车。

　　在我们录制测试脚本时也经常会遇到这样的情况：录制的时候，服务器会给一个唯一的认证码来进行操作，当再次回放脚本的时候服务器又会给一个全新的认证码，而脚本录制是死的，还是拿老的认证码提交，从而导致脚本执行时失败。

　　下面详细来分析一下录制与回放的过程

　　录制过程：

　　1、输入用户名密码登录

　　2、服务器端返回一个sesiionID@@@12345

　　3、客户端拿着获得sesiionID@@@12345进一步请求服务器信息。

　　4、服务器返回客户端想要的信息

　　回放过程：

　　1、输入用户名密码登录

　　2、客户端返回新的sesiionID@@@23456

　　3、因为脚本中的sesiionID@@@12345 是写死的，所以我们会依然拿着老的sesiionID@@@12345去向服务器请求信息

　　4、服务器你经过验证发现你的sesiionID@@@12345 是错误的。

　　为了确保脚本回放的成功，我们需要获得服务器每次返回的动态的sesiionID，再将这个动态数据发回给服务器。而关联能够帮助我们将服务器返回的数据进行处理并保存为参数。

　　OK！通过上面的分析，我们大概明白的关联的原理，下面要解决的问题就是如何设置关联。关联的三种方法：

　　● 自动关联

　　● 手动关联

　　● 一边录制一边关联

　自动关联

　　在录制脚本之后打开recording Options 窗口，点击correlation标签页。确保Enable correlation during recording 选项处于勾选状态。

　　在LoadRunner 自带WebTours为例设置关联，

　　访问WebTours首页，点击administration 链接，设置 Set LOGIN form's action tag to an error page.勾选更新。

　　录制WebTours登录与退出脚本：

　回放脚本出错：

Action.c(47): Error -27987: Requested image not found      [MsgId: MERR-27987] Action.c(47): web_image("SignOff Button") highest severity level was "ERROR", 0 body bytes, 0 header bytes      [MsgId: MMSG-26388]

　　选择菜单栏Vuser ---> Scan Script for Correlations （快捷键ctrl + F8 ）弹出下面窗口

　　扫描相关性可能需要几分钟，你想继续么？ 当然，点击“YES”

　　选中需要关联的内容，点击“ remove Correlation ”

posted @ 2013-03-18 10:04 顺其自然EVO 阅读(419) | 评论 (0) | 编辑 收藏

LoadRunner 技巧之手动关联与预关联

　上一节介绍了关联的原理与自动关联，除了自动关联还有另外两种关联方式：手动关联与预关联。

　　手动关联

　　如果脚本很长，那么我们想找到一个脚本中哪些地方是需要关联的并不是一件容易的事情。这时，我们可以通过脚本对比的方法找出需要关联的内容。

　　1、录制第一份脚本，保存为“关联a” 。

　　2、录制第二份脚本（操作步骤与第一次保持一致），调用loadrunner自带的WinDiff

　　（Tools-->campare with users ），选择“关联a”

　　通过WinDiff 对脚本的对比，我们很容易来判断需要做关联的内容。

　　3、使用web_reg_save_param函数建立关联脚本

　　int web_reg_save_param( const char *ParamName, <List of Attributes>, LAST );

　　第一部分（const char *ParamName）：参数名，用双引号括起来，逗号分开

　　第二部分（<List of Attributes>）：包括LB、RB、RelFameID、Ord、Search、SaveOffiset、SaveLen等。

　　第三部分（LAST ）：结束标志。

　　通过按F1 键打开帮助文档，搜索此函数，查看具体用法。

　　4、LR11 还提供了另一种手动关联方式。

　　选择Tree 视图模式，点击HTTP View 下查看Response Body 中，打到需要关联的内容，右键在下拉列表中选择“Create Coorelation”

　预关联

　　预关联也可以叫做“ 一边录制一边关联”。为什么录制某此系统，会得到一些自动关联函数呢？这就是系统默认提供自动关联设置。如果我们预先知道需要关联的内容时。可以预先设置好要关联的内容，这样在脚本录制的过程中自动对要关联的内容进行关联。

　　在录制脚本时打开Recording Options 设置窗口

　　（本文以loadrunner 自带WebTours 的关联为例）

　　1、点击一New Application 按钮，新建一个叫做WebTours 的应用

　　2、选择这个规则，点击 New Rule 按钮一个规则。

　　3、然后做如下设置：

　　关联函数web_reg_save_param_ex

　　前面的例子用到web_reg_save_param 关联函数，web_reg_save_param_ex 可能也是很常用的一个关联函数。我们碰到函数就胆怯，这个不知道暗具体怎么使用它。

　　菜单栏Insert --- new step 打开add step 窗口

　　搜索web_reg_save_param_ex 函数，选中函数，点击OK，弹出函数的设置窗口：

　Prameter name：此设置存放参数的名称。

　　Left boundary：此处设置左边界，这里是用来填写关联对于数据处理的左匹配内容规则。

　　Match case：默认情况下边界是检查Match case ，也就是检查大小写的。

　　Binary data：如果要关联的内容是非ASCII 字符的，需要选择此项

　　Regular expression：在LR11 中关联提供了使用正则表达式的功能，但是LR11 Patch3 中取消web_reg_save_param_ex 函数对此功能的设置。

　　Reight boundary：此处设置右边界。

　　DFEs：在录制选项和回放中我们提供了DFE的功能，在关联这里也支持DFE的数据处理。（DFE等后面再解释，或你自行查资料）

　　Ordinal：这个关键字在很多函数里面都有应用，在这里可以填写任意一个整数，也可以填All。如果填写数字，那么说明从返回的记录中取出对应顺序的值，而填写All的话将会返回所有内容。

　　Save Offset：设置关联的内容偏移量，从第几位开始进行关联操作。

　　Save Length：关联出来的内容所需要保存的长度。

　　Warm if text was not found (Default is Error)：对于关联的对象不存在的处理。

　　Filters：下面的选项都是帮助关联返回限定的，通过这些设置可以进一步减少返回的范围。

　　----------------------------------------------------

　　关于关联函数的每一个选项的介绍，我将得不是很清楚，你可以找更详细的资料学习。

posted @ 2013-03-18 10:03 顺其自然EVO 阅读(293) | 评论 (0) | 编辑 收藏

如何有效发现UI用户界面层的缺陷

【UI型Bug定义】

　　这里指的UI型指以下两种Bug：

　　第一种是文字型Bug，即和给定的字符资源不一致的Bug，比如文字/字符/提示语/引导语/用户协议等文字方面的不一致。

　　第二种是UI效果不一致的Bug，比如应该是个圆角按钮，做出来的界面却是个平角的按钮；有下拉箭头效果，做出来的界面却没有下拉箭头效果；混动界面应该有3屏，做出来的界面却只有2屏，诸如此类。

　　【UI型Bug的产生】

　　理论上UI型Bug的产生只有一种原因，即开发人员没有按照需求文档或者UI做。

　　开发人员为什么没按需求的要求去实现？通常有两种原因：

　　第一种，开发人员一开始就没按需求实现；

　　第二种，需求方频繁变更，没来得及更新文档。

　　在敏捷Agile场景下，开发人员会把最主要的原因归为需求方没有及时更新文档。

　　【如何减少UI型Bug】

　　理想情况下，所有的环节都按文档做，是不存在所谓的UI型Bug的。即需求方确定文档，开发人员严格按照文档实现。

　　UI文档的变动要及时更新并通知到开发人员和测试人员。

　　开发人员要严格按照文档的需求去开发，不能主动发挥（任何的主动发挥都要征得需求方的同意并通知到下一个环节（即测试环节）的人员）。

　　【QA人员碰到很多的UI型Bug该怎么办？】

　　当UI型Bug占到Bug总数的一定数量后，QA人员有义务想产品或者项目经理提出抗议，说明这是在浪费大家的时间。

　　【AgileHei测试是怎么做的？】

　　测试人员不负责测试UI型Bug，由需求方在验收时统一对UI进行验收（或者在项目中期约定一个时间进行修改）。UI型Bug是很直观的Bug，由需求方和实现方直接达成协议，结对及时修改最有效率。

　　【结论】

　　UI型Bug是沟通不一致的产物，测试人员不要把有限的精力放在UI型Bug上面。为追求所谓的敏捷而导致了后续环节的频繁沟通，不是Agile的本意，是为了敏捷而敏捷，为了增加沟通而沟通。

posted @ 2013-03-12 10:59 顺其自然EVO 阅读(172) | 评论 (0) | 编辑 收藏

Android集成测试

　Android集成测试主要是在单元测试的基础上测试接口访问或者异步任务是否正确，在移动凤巢系统中，大概有30+个接口需要测试，他们都遵循一个特定的访问模式：前台的Activity获取到触发事件后，将它传给这些接口，这些接口都是AsyncTask的实现——即后台异步线程执行某个任务（一般是发送http请求到后端服务或者执行存取数据库等耗时操作），完毕后调用回调函数，示意图如下：

　　一、测试框架

　　对于Android中这种异步接口的自动化测试需要解决3个问题：

　　1）如何获取到异步任务执行结果；

　　2）如何让上层测试代码尽量不处理任务等待；

　　3）如何处理需要登录的接口。

　　对于问题1）每个异步任务在获取结果后就直接调用onPostExecute()方法了，测试代码获取不到结果，所以必须有一个专门的桩Activity负责异步任务的执行并将结果暴露出来；

　　对于问题2）尽量将等待操作交给测试基类，上层测试代码只需要执行被测逻辑；

　　对于问题3）采用模板模式，如果接口需要登录则先执行登录操作后再调用，整体解决方案如下：

　　其中桩Activity的逻辑如下，它实际决定接口的调用方式，如果被测接口需要登录则先登录后调用，如果不需要登录则直接调用。

　　可以看到isCompleted是标识异步任务是否执行完毕的，无论异步任务返回是onSuccess、onError还是onIOException都会进行置位；result则是异步调用的返回，可以看到这里无论接口调用是成功、失败还是io异常都会将这个结果暴露出来以使测试代码能够获取到；

　　interfaceAction是测试代码需要实现的接口，内容如下：

　　由于有些接口是必须登录才能访问的，所以前两个接口实现是为其服务的，如果访问的接口必须处于登录状态则先调用login()方法，然后再调用实际的action()方法。另外，书写测试代码的时候为了减少对异步任务等待的代码以及显示对InterfaceActivity这个桩Activity

　　的调用还需要完善测试基类：这样上层test case只需要关心具体的测试逻辑而不用关心异步调用及等待处理

　二、测试方法

　　以商桥访问接口测试为例，由于它是一个需要登陆才能访问的接口，写自动化case的时候需要完成两个类：BridgeAction和BridgeTest。其中BridgeAction主要是接口的调用，BridgeTest是测试内容：

　　这里BaseLoginAction实现了needLogin()和login()方法，主要是登录逻辑，BridgeAction的action()是真正接口的调用。

　　测试类主要是对BridgeAction的调用，它可以向接口传递不同的参数，同时也可传递登录操作的用户名和密码。waitAsyncTaskComplete(action)完成了接口逻辑的调用及时间的等待，测试代码只需着重关注result并进行断言。

　　三、总结

　　异步接口的集成测试的侧重点在于Android手机端向服务器端发送的请求是否正确，以上测试CASE的断言与后端数据其实是强耦合的，即后端caiye这个账户的数据变化可能导致CASE的fail，所以可以考虑引入hamcrest包，做一些匹配校验，主要测试正常和异常情况服务器返回的内容是否符合预期，比如上面最后一个断言可以写成：assertEquals(intValue()，greaterThan(0))；当然，服务器端接口的正确性正常情况下应该由服务器端的自动化Case来保证，这样才不至于前后端测试紧耦合在一起。

posted @ 2013-03-12 10:46 顺其自然EVO 阅读(849) | 评论 (0) | 编辑 收藏