发布新日志

  • Jmeter的正规表达式

    2014-08-01 10:19:28

    JMeter使用Apache Jakarta ORO进行模式匹配

    可以通过下面的地址对ORO进行更详细的了解:
    A summary of the pattern matching characters 
    http://jakarta.apache.org/oro/

    OROMatcher User‘s guide 
    http://jakarta.apache.org/oro/api/org/apache/oro/text/regex/package-summary.html

    如果你想查看详细的文档,你可以安装一个全版本的Perl来查看Perl相关的模式匹配文档,因为两者几乎一致。

    需要强调的是“contains”和”matches“的不同:
    contains意思是正规表达式匹配上了目标的部分/全部字符,例如:alphabet contains ph.b,因为正则表达式会匹配目标的部分字符,这个示例就是正则表达式ph.b matches了alphabet的子串phab(.可以任意匹配一个字符)
    matches意思是正则表达式匹配上了目标的全部字符,例如:alphabet matches al.*t (.*可以匹配任意多个字符)

    在本例中,相当于完全包装模式的语句:^al.*t$ (^标识匹配开始,$标识匹配结束)

    示例:

    获取单个字符串

    假设你想在一个页面上匹配如下的内容<name="file" value="readme.txt">

    那么可以使用: <name=“file” value=(.+?)">

    ()用于包围要返回的匹配字符串
    . 匹配任意一个字符
    + 多次
    ? 第一个匹配完成后结束匹配

    例如上例,如果没有?结尾,那么.+将会在完成第一个>后,继续向下匹配,直到最有一个>为止

    其实上面的匹配更严谨一些的话,书写为如下:
    <name="file" value="([^"]+)">
    其中的[^"]表示除了"符号外的匹配任意字符匹配
    然后在JMeter的template里面使用$1$


    获取多个值

    如果你想同时获得多个匹配值,那么格式如下

    仍用上面的示例作为匹配对象 
    <name="([^"]+)" value="([^"]+)" 
    然后在Jmeter的template里面使用$1$$2$
    设置变量名为Test

    那么如下的变量将被赋值:
    Test 值为file.namereadme.txt
    Test_g0 值为 name="file.name" value="readme.txt"
    Test_g1 值为 file.name
    Test_g2 值为 readme.txt

    然后在JMeter中使用:${Test},${Test_g2}......


  • Jmeter一些有用的插件

    2014-07-31 15:55:31

    这几天研究新出现的Jmeter插件,发现有些新插件比较有意思 

    支持SSH的samplerhttps://github.com/yciabaud/jmeter-ssh-sampler

    需要maven编译源代码,下载maven后,执行mvn clean package命令即可

    支持REST和Webdriver的

    http://jmeter-plugins.org/wiki/Start/

    比较好玩的是Webdriver这个插件

    另外,最近做一些API接口,发现返回的结果有乱码,需要在bin目录下的jmeter.properties文件中, 搜索的sampleresult.default.encoding这个参数,去掉前面的#,然后改成sampleresult.default.encoding=utf-8
  • 敏捷是一种观念

    2014-07-16 10:21:42

    现在推广敏捷测试,发现很多人没有理解敏捷的实质。

    从本质来说,敏捷是一种思想,不是一种软件工程模式。

    从出发点来说,敏捷不是提高产品的质量,是如何能最大限度的快速获得用户的回馈并反应。

    从流程来说,敏捷可以采用任何流程,瀑布也能敏捷起来。

    从结果来说,敏捷是倒推,用户第一。

    从执行过程来说,敏捷强调的是轻文档(不是不要,是轻量级和关键文档必须),重沟通(需求时刻变化,预设的文档需要不断的细化调整)

    从角色来说,敏捷强调的是用户体验,也就是说所有角色要从用户体验出发。

    从经验来说,敏捷不可复制,没有任何一个成功模板可套用,只能不断试错,然后选择适合自己的。
  • 硝烟中的Scrum和XP读书笔记(7)

    2014-05-23 14:53:06

    第十六章 怎么管理分布式的团队

    我们做离岸外包时,经常成员处于不同城市的团队协作。所以要想办法让这些互相看不到的团队成员相互沟通:

    1. 两个不同城市的人结对编程
    2. 每日例会用视频方式交流
    3. 尽量保持语音交流
    4. 不定期的互相出差,真正的面对面交流
    5. 所有团队成员一起开会
    6. 所有团队的共享信息要实时同步

    但是最重要的是,既然是多个城市的团队,最好能让每个团队成员都逐渐成长起来,打造一个团队,成为协作的团队

    第十七章 作为一个Scrum Master 你需要check那些

    sprint的开始阶段

    1. sprint计划会议之后,创建一个sprint的信息页面
    1)在wiki上(我们是用wordpress/Trello)
    2)打印出来,贴在公告栏,让别人知道你的团队做什么
    2. 发送邮件给所有的相关人
    3.更新sprint文档,加入估算的生产率(工作量),团队的成员和sprint的时间长度

    每一天

    1. 确保每天的Scrum会议按时开始按时完成
    2. 为了保持如期完成sprint,需要删减故事时要个产品负责人沟通
    3. 确保团队都清楚知道sprintbacklog和燃尽图的最新状态
    4. 确保问题和障碍被清除,并及时通知产品负责人
    5. 确保发现风险能被及时通知开发主管和产品负责人

    结束时

    1. 进行开放的sprint的demo,提前2-3天邀请相关人
    2. 在Demo开始之前,团队内部demo
    3. 主持sprint回顾会议
    4. 更新sprint文档,记录实际生产率和回顾会议中的结论
    5. 共享经验给其它团队

  • 硝烟中的Scrum和XP读书笔记(6)

    2014-05-23 13:38:57

    第十四章 我们怎么进行测试

    测试实际上是软件中最困难的一个环节。能影响测试的环节太多了,质量要求,流程规范,性能指标,时间,类型,资源等等都会对测试产生极大的影响。

    看看作者认可的一种方法:
    1. 理想化的Scrum中,每个sprint都有一个可测试的版本发布出来,实际情况是:不
    2. 所以验收测试是必须的,不能跳过
    3. 那么要做的是减少验收测试的消耗
    1)提高开发的代码交付质量(我的团队是多做单元测试,而且集成测试时开发人员要执行测试人员书写的很多手工测试用例)
    2)提高效率。要么是用最好的人(经验丰富,能力强,但是成本高),或是用各种工具(依赖性强,成本高,覆盖率有限)
    3)测试人员参与到Scrum团队中(现在测试人员究竟是全部独立,还是全部在团队中,还是混合方式,都是有优缺点的,只能根据你团队的具体情况进行选择)
    4)减少每个sprint的故事数量(很多时候都是硬塞新的,不可能为了保证质量减少数量,所以更有效的方法是回归实用自动化工具,新功能还是手工)
    5)加强代码审核和互测机制,结对编程也有助于提高质量

    测试是负责验收的,产品验收反而流于形式。

    测试基本上充当了做Demo的主力。

    没东西可测试的时候,测试的工作是要做很多测试准备,比如测试用例编写,审核,测试环境搭建,测试数据准备。如果还没事干,不妨试试,让测试人员和开发人员结对,讨论开发人员实现的代码。

    实际上测试人员不单单是个点点点的人,他有很多非本职觉得事情可以做:
    1.测试环境的搭建
    2.去和产品负责人明确需求
    3.与运营部门讨论部署的具体细节
    4.编写各种文档
    5.协调资源
    6.改进流程和规范
    7.将故事拆分为场景,从而促生出合理的任务集
    8.收集开发人员的问题,并协助解决

    听起来,测试人员成了“测试驱动开发”的完美实践者,甚至起了担当了部分团队管理者的角色

    其实,如果你能足够的强势,在每个sprint里做合理量的任务,才是最终解决测试质量的问题

    验收测试到底包含在当前sprint中不?
    (这是一个争论已久的话题,有些团队喜欢包含,有些团队不喜欢包含。甚至我的团队会专门有个测试的sprint存在。)

    大部分团队不喜欢包含的原因是:
    1)sprint有时间限制,但是测试未必能严格按照时间完成,因为缺陷不等人。
    2)很多sprint没有可交付测试的内容
    3)有很多产品是多个sprint团队进行并发开发,需要都开发完后,集成完毕才能开始测试

    所以大家喜欢在当前sprint里添加新的需求,同时修改上个sprint出现的问题,那么意味着,产品不能立刻发布,需要延迟发布。

    我们是有一个专门的团队进行验收sprint,里面包含了开发和测试。但是成本很高。

    有些是几个开发sprint,然后跟一个专门进行缺陷修复的sprint,集中解决,这取决于你的交付计划是不是允许。

    最糟糕的情况是,你的团队不得不始终去关注新功能,而无暇进行缺陷修复,这个时候,就只能要求代码质量控制的很好才行,否则就是一个千疮百孔的垃圾产品

    所以既然是一个团队,就需要考虑一下如下的可能:
    1. 安排一些测试任务给开发人员
    2. 简化一下测试的流程
    3. 减少测试反复的次数
    4. 开发一些测试工具来提高效率
    5. 增多更多的自动化脚本
    6. 自动化的覆盖度和深度更强
    7. 延长sprint的长度
    8. 定义个专门测试的sprint
    9. 雇佣更多的测试人员,设置个资源池,然后各个团队复用

    第十五章 怎么管理多个sprint团队

    团队越多,管理越复杂,scrum不可能简单的将管理弄的轻易化。

    那多少个团队合适,每个团队的人员怎么安排呢?

    我的经验是,一个产品有一个大团队,然后设置一些虚拟组织(虚拟团队)

    例如,产品,开发,UI,前端,测试,运维都属于一个产品团队。 其中产品虚拟团队,开发虚拟团队,测试虚拟团队等等都存在。 这样能解决一个人要听两个人的指挥,也能解决我没有个自己的圈子去协作。

    至于实体团队和虚拟团队怎么分配,还是得看你自己的选择,你怎么能让他们有效的运转起来,就行。

    那么很多时候超过20个人的大团队也必须分配成几个实体小团队。每个小团队的人数最好不要低于3个,不要超过10个。

    我喜欢3个一组的小unit,一个中级的带两个初级的,很有效率。 每个团队都是由这一个个小unit组成。

    而且团队也不是一成不变的,要随时拆分,随时合并,当然是根据情况而来。

    同时进行多个sprint也可以,但是前提是相互之间没有干扰。

    而且,同步开发的时候,要保证2,3个sprint后你有机会进行一次团队重组。

    每个团队,要有一个负责人,但是不是管理者,确切的说是沟通者,这个领导代表整个团队跟其他团队沟通。

    我们的做法是设置了一个委员会,其实就是各个团队的负责人坐在一起协调资源。

    是否有保持一个特定的团队,也需要斟酌,比如专门做服务器后台的团队。稳定和高效,以及轮换和机遇永远是个针锋相对的话题。

    可能的情况是:一个固定模块的团队;一个跨多个模块,但是固定组件的团队。

    还有一种可能是,你会有个一些人在多个团队里做兼职。

    甚至,你还需要准备一个救火团队以备不时只需。

    多个团队的话,还涉及到联席会议,可以像我们一样弄个委员会,也有可能是一个更高级别的管理团队。

    如果你要自己控制多个团队,那么交错的开会是必须滴。

    多个团队的时候,是否拆分backlog。在一个大的产品的情况下,这是很正常的,拆与不拆,还得取决于你的团队设置。如果你还保留了一个专门的产品团队,那么一个产品负责人和这个产品团队沟通就行,不用拆。

    如果需要设置多个产品负责人,最好还是拆吧。

    一个产品负责人如果负责多个产品backlog,那么我觉得你应该合并产品。

    多个团队对代码分支的要求也比较严格一些:
    1. 主分支永远要保持稳定
    2. 每个版本都有tag
    3. 只有必要的时候才创建分支,使用完毕后要合并
    4. 分支用于区分不同的产品生命周期
    5. 要经常同步

    多团队的回顾更是有必要。



  • 硝烟中的Scrum和XP读书笔记(5)

    2014-05-22 17:05:30

    第十一章 sprint之间的休息

    第十二章 怎么制定发布计划 处理固定价格的合同

    发布计划最重要的是验收标准。

    一个发布,一般包含若干个sprint。所以每个sprint的验收标准和整体发布计划的验收标准都很重要,能保证每个阶段按时完成。

    产品计划如同一个超大的sprint计划。时间也是团队进行估算。生产率也是依据团队的能力进行预估。

    设置好整体的发布计划,就可以在不同的sprint根据优先级塞满各个任务。

    sprint的计划要保证发布计划能够按时完成。调整发布计划是要先调整sprint计划,然后根据sprint计划调整发布计划。

    第十三章 怎么结合使用Scrum和XP

    Scrum注重的是管理和组织实践。它是一个框架,不会告诉你具体做什么,一切都要实践。
    XP关注的是编程实践。它关注的是如何让开发过程更加敏捷。

    所以二者是不同领域的方法,才能有效的结合起来。

    当然,两个也有很多重叠的地方,但是基本上重叠的地方都是Scrum为主。例如:团队是个整体,坐在一起,故事,计划等。

    下面说一些XP的实践:

    1. 结对编程
    1)提高代码质量
    2)集中团队的注意力
    3)反对结对编程的人是因为没真正用过
    4)精神和体力损耗大,不能一直不停
    5)结对要经常互换
    6)提高知识的传播速度
    7)不能不习惯就不推动
    8)必要时从代码审查开始
    9)不是真的两个人只有一台机器
    10)不要强制
    11)结对不是两个人干一个人事,是两个人共同干两个人的有交叉的事
    12)结对的工作量比单独一个人的要多

    2. 测试驱动开发(TDD)

    测试驱动开发意味着你要先写好自动化测试,然后编写能通过该测试的代码,然后重构代码,提高可读性和消除冗余,然后整理一下,添加comment。

    1)TDD很难。其实你只是不愿与是习惯它
    2)TDd对系统设计的正面影响很大,你做开发之前,就想到了很多没说清楚的细节
    3)TDD不是一开始就能用上,需要过一段时间,尤其是在黑盒的集成测试特别有益
    4)需要有经验的人和合适的工具进行推广
    5)需要额外的资源创建基础库

    一般常用的工具有:
    1)Juint/HttpUnit/Jwebunit
    2)TestNG/Selenium
    3)Cucumber/Webdriver/Watir
    4)HSQLDB
    5)Jetty
    6)Cobertura
    7)Spring

    一般都是现在新代码上开始TDD,直接将测试代码开发在新代码中。虽然开始有很多额外的开销,但是你会发现会节省大量的后期维护开销。

    在旧代码上开始TDD很难,因为基本上就是要重新开发了。所以,需要找出那些减少手工测试的入口,然后开发一系列的工具。

    如果你已经陷入了手工回归测试的泥沼,不要企图将它自动化。 首先要做的是减少回归测试的范围和深度,建立特殊检查点来判断回归的覆盖率,然后才考虑,那些东西可以自动化,减少时间。


    3. 增量设计

    增量设计是指一开始要保持设计的简单化,不断的进行改进,而不是为了保持不出错,就不允许更改。

    持续的设计改进,很大程度上要依赖TDD。

    4. 持续集成

    持续的集成,每天自动测试,自动发送报告。但是需要巨大的精力去开发维护集成环境。

    5. 代码的所有权

    要保证代码是集体所有权,也就是说,每一块代码都不是只有一个人能够维护,每个人都有自己的backup。

    6. 充满信息的工作空间

    项目助理的作用就是每天将新的信息发布给所有人感知,去掉那些以及各过时的信息的影响

    7. 代码标准

    代码可以有风格,但是必须遵循一致的标准。

    8. 可持续的开发速度/精力充沛的工作

    加班工作会影响开发效率。 定时上下班的效率比你想象的要高。




  • 硝烟中的Scrum和XP读书笔记(4)

    2014-05-22 15:51:35

    第八章 每日例会怎么进行

    站在看板前,这样你才是有针对性的开会。

    每次控制在15分钟内,每个人都不需要讲,也不需要听太多的细节,因为不是技术研讨会。

    每天开会的目的,是更新看板上的卡片。每个人都讲述昨天做了什么,今天要做什么,同时更新卡片,挪动卡片。

    ScrumMaster会更新燃尽图,然后更新一下sprint backlog。

    怎么处理那些不愿意参加会议的成员呢,弄个存钱罐,来晚的都要往里扔5块钱,用来买零食给大家吃。

    如果钱不够,ok,老板自己往里先扔200作为基金。

    很多时候,有那么一批人会说:我不知道今天干啥

    简单,让别人都讲完,然后把那些没人做的分配给他们。

    当然,有时候并不是没有任务做,只不过他们还不太明白他们究竟在这个任务中做点什么,那么就需要相关的人会后讨论一下细节,以便让他们知道真正要做的。

    如果真的没事可做,那就拉他们过去结对编程。

    还有极端的是,提前完成了,ok,从backlog中,拿出几个合适的故事,加进来。

    如果是那种懒人,就是不想干点什么的时候,怎么办呢?
    1. 羞辱他们
    2. 直接派活
    3. 让其他人给他们施加压力
    4. 奴役他们,干点体力活

    如果还是不能解决问题,干掉他们,不要因为他们影响整个团队。

    第九章 怎么进行Demo

    很多人都不重视Demo,相当于干了很多事,却没人知道。

    其实Demo意味着sprint要成功的结束了,带来的好处有很多:
    1. 团队的成果得到了认可,感觉很爽
    2. 别人终于能看到你的团队实际做出了个什么东西来
    3. 演示能让很多关注度比较高的人提前参与验收,并能在我们没有正式结束前即使的反馈,有一个临门磨枪的补救机会。
    4. Demo是你让你的团队和其他团队进行交际的重要方法。
    5. Demo意味着你的团队必须让产品真正的跑起来,而且问题还不能太多,等于push他们
    6. 一个失败的Demo会让团队成长

    Demo之前,做个检查列表:
    1. 确保Demo能够清晰的阐述你这次sprint的目标。因为有些人不知道你的产品,你不得不花时间讲述一堆他们完全不懂的功能,浪费彼此的时间。所以最好有个简单的背景描述。
    2. 不用浪费时间做什么PPT,直接开讲就行。
    3. 节奏要快,要快速的通过,而不是像买产品那样自卖自夸半天。
    4. 演示的是业务内容,而不是技术架构。所以要串场景,而不是一个个功能的描述。
    5. 允许的话,让参与Demo的外人,现场试验一下。
    6. Demo的主题是唯一的,就是演示你做了什么,不要跟人去讨论细节。
    7. 如果出错,那就说这个正确的实现是怎么样的
    8. 不要企图去展示那些非功能性的需求,太技术性的东西,无法获得认同感。


    第十章 怎么做sprint的回顾

    怎么回顾的前提是:你能够组织回顾,或者说你有东西可以进行回顾。

    很多人不愿意做回顾,因为觉得都做完的,何必要再折腾一次。

    实际上回顾是最重要的事之一,另一个是sprint会议,回顾就是要校验你的sprint会议的完美程度,以便下次sprint会议的时候进行调整。

    前事不忘,后事之师。

    回顾的组织都是看情况而定,一般可能会有这些:
    1. 设置要回顾的内容范围,设定一个时间段
    2. 确定参与者,产品负责人,团队和你都参加
    3. 封闭的空间,避免外界干扰
    4. 不要在团队的工作空间,换个陌生的地方
    5. 找一个人当秘书,做好会议记录
    6. 演示sprint backlog,指出当时出现了那些问题,如何弥补的,带来了那些危害,下次怎么避免等等
    7. 每个人都发言,说说自己的得失和对团队的想法
    8. 对预估的工作量和实际的工作量,以及燃尽图进行讨论,分析下原因
    9. 对大家表示感谢
    10. 聚餐
    11. 发送一个会议记录
    12. 发送一个收集的那些典型问题,处理方法,风险控制,作为知识进行分享

    真正的主题其实只有一个:下一次,怎么做的更好

    所以,会分类。一般有:很好,下次还这么干。一般,其实怎样怎样干效果更好。有点遗憾,下次应该避免怎么怎么样。

    然后,每个人把自己的想法列出来,投票,各选三个。在下一个sprint里分别跟踪一下,看看是不是好转或者变坏。

    回顾有个很重要的作用是在团队之间传播经验。

    回顾还有一个很重要的输出是:那些需要变,那些不能变。

    常见的问题有:
    1. 当时需求没说清楚
    2. 干扰太多
    3. 时间估计的少了
    4. 承诺的太多
    5. 细节考虑的欠缺了
    6. 办公环境不好
    7. 浪费了很多不相干的经历
    8. 团队配合不好
    9. 沟通成本太高
  • 硝烟中的Scrum和XP读书笔记(3)

    2014-05-22 15:21:49

    第五章 我们怎么让别人能理解我们的sprint计划

    做完sprint计划之后,最重要的一个步骤是要让全公司的人都知道和明白我们要做什么。

    本文作者是使用Wiki,建立一个页面,包含了sprint里的主要内容,然后再邮件中发给全公司。

    然后,在Demo之前,也通告全公司,让所有感兴趣的人都知道你们什么时候要做完什么,然后展示给大家看。

    第六章 怎么编写合适的sprint backlog

    backlog包含所有的,sprint backlog包含当前sprint的内容。

    很多人会用excel,Jira和Trello等等,但是最合适的还是看板,一个物理的,贴满小条的看板。

    然后按照你团队实际的情况,划分若干列,把卡片按不同的状态贴上,一目了然。

    但是有一点注意,尽可能的减少列,太多的列只会把简单的事情复杂化,每添加一列时,你都要问一下,这是所有人都需要的列吗,如果不是,那就不要。

    燃尽图是一个很好的工具,deadline作为X轴终点,总工作量(总点数,如果你的点数就是人/天的话)作为Y轴的终点。连接两个点,ok,你获得了一个趋势线,然后每天按实际情况登记你剩下的点数(不是实际付出的点数),然后一目了然的看到你是在超前还是在延迟。

    通过燃尽图,你可以标志各种警示标志,让团队来进行关注,例如 长时间的延迟,或者超乎寻常的超前都是有问题的。需要大家找出问题,然后解决。

    然后,怎么跟踪呢? 如果你想要一个详尽的跟踪报告,OK,看板的方式不适合,,你可能需要的是Jira。

    那点数倒是是用“人/天” 还是 “小时”呢?建议不用小时,因为那会带来更多的管理成本。

    第七章 怎么安排团队的座位

    首先要坐到一个房间里。

    然后留给看板足够的空间,让大家能够站在它面前讨论sprint backlog。

    然后留一个足够大家站在一起的空间,好开会。

    然后留一个角落,让几个人能够不影响他人的情况下讨论。

    然后留一个墙,放整个backlog和一些其它的相关内容。

    座位安排,可以是混编,可以是按工作内容,工作方式,工作种类进行分编。但是一定要保证:每个人都能听到彼此的交谈,能够看到互相的脸,不会为了一个问题跑来跑去。

    然后,最关键的是,产品负责人不要坐进来,否则他会纠结于到底要不要关注这些过程中的临时细节。当然也不能离的太远,能够很容易的找过来回答一些问题。

    对于那些经理和教练来说,刚开始的三天参与一下,一旦团队能够自我管理了,那么隔几天参加一次scrum meeting或者偶尔溜达过来看两眼就行了。或者干脆就参加回顾过程,看看他们犯了那些错,准备怎么避免下次再犯。




     
  • 硝烟中的Scrum和XP读书笔记(2)

    2014-05-21 16:30:59

    第4章 我们怎样制定sprint计划

    sprint计划会议是Scrum的最核心的活动。

    sprint会议的目的是让团队充分的获得信息,从而能在无干扰的情况下去完成sprint

    sprint会议的产出是:
    1. 本次sprint的范围和目标
    2. 参与sprint的人员,角色和职责
    3. 在backlog中标识出本次sprint的内容
    4. sprint中的demo的时间,内容和方式
    5. 确定Scrum会议的时间,地点,内容和参加人

    sprint参与者包含产品负责人和整个研发团队。在讨论过程中,产品负责人要修改范围和每个条目的重要性,而研发团队是对每个范围内的条目进行询问和估时。每个条目都有可能被不停的修改和更新,然后重新估时。

    sprint需要制定足够明确的质量目标
    1. 外部质量:客户直接可以感知的产品服务品质
    2. 内部质量:系统的内部质量,用户未必能知道内部有什么问题。

    永远不要为了应付产品负责人的期待而减少估时,从而用一些临时方案来实现预定的外部质量,这只会让你的内部质量更加无法控制。如果要提前发布,那么唯一的方法就是缩小范围。

    sprint会议从来都是一个漫长的过程,那些很快结束的会议意味着你进入了一个超高风险的迭代期。

    当然最好的方法就是打断会议,既然8个小时都讨论不清楚,那么再花费4个小时也不会有结果的。打断会议的目的是,本次sprint的范围就限定在讨论好的那些条目上,剩下的继续讨论,但是不是所有人都需要参加了。减少无休止的沟通成本。

    所以,既然每次sprint会议都是个漫长的过程,那么开始前,定一个简单的时间表还是有作用的。虽然最后不能明显的减少时间,但是至少我们知道我们把时间耗费在那个环节上了,从而在下次会议前,能够充分准备。

    sprint的长度怎么确定呢?

    短周期的sprint = 频繁的客户反馈 = 频繁的迭代交付 = 错误的低成本 = 团队提升更快

    长周期的sprint = 充足的时间 = 完善的解决方案 = 较小的压力 = 团队更加稳定

    不用着急考虑你的团队用那个sprint长度,随便选个4-6周的时间,走两个sprint就能把自己的节奏找到了。

    怎么确定sprint的目标?

    sprint的目标很难确定,因为它必须用业务术语说明,让客户也能明白,而不是技术术语只有技术团队才明白。

    sprint的目标一般都针对一个终极问题:我们为什么进行这个sprint?然后找个大家都能理解的解释就行。

    怎么决定sprint的范围?

    首先你得了解你团队在这个sprint周期中的产出总量。作为一个塞故事的基准。

    产品负责人可以通过修改每个条目的重要性(点数)来修正本期的内容。也可以修改单个条目的范围,来塞进更多的条目。也可以屏蔽相关性,来分别将两部分上线。

    很多时候,团队都是大致评估一下条目,不会真的精确判断是否能加入当前sprint。

    使用索引卡

    那种一个人拿着笔记本,在墙上投射excel文件,然后逐条讲解的会议是最要不得的。最简单的方法就是用卡片+白板,哪怕你是用Trello,也最好是用它来跟踪汇总更新,而不是用来讨论。

    卡片可以贴来贴去,这对于修改点数后重新排序很方便。
    每个人可以随意查看卡片,从而能够随时编辑,并发编辑。
    而且划定范围后拆分合并,甚至加入新条目时,很简单。
    每个人都参与到了卡片的更新过程中,而不是看一个敲键盘导致注意力不集中,甚至犯困。
    会议结束了,就可以把卡片贴到团队旁的墙上,大家都可以一目了然的跟踪进度
    然后根据卡片更新execl或者Trello,比起边听边匆忙的修改要舒服的多。

    最后,要定义一个完成。到底sprint什么情况下算完成,必须统一约束。

    估时都谁来估?

    估时是一个团队的活动,意味着所有人都必须参与估时。

    谁负责那个不是事先定义的,是讨论过程中得出的结论。

    有可能会多个人共同完成一个故事,那么需要他们分别估时来取一个最大最小时效

    尽量每个人都对所有的故事进行一次估时,这样的话对于那些大家估时差异较大的故事能够进行提前的充分讨论。

    当然,估时的过程也是明确故事的过程。因为你要大致说明一下你估时的理由,或者说如果你完成了,通过什么样的场景能展示这个故事。

    估时的时候,难免出现的是将一堆小故事合并成一个大故事,或者是将一个大故事拆分成几个小故事。


    估时完成了,就要拆分任务了。

    拆分任务是基于故事的场景而不是时间。不要觉得拆解故事成任务就退回了瀑布,其实主要是为了分解成任务后重新审视一下是否很多细节你估时的时候没有考虑清楚,需要重新估一次。这是很普遍的问题。

    预先拆分成任务,好处就是我们在scrum会议的时候有可以讨论的东西,而不是拿一个故事来说完成了多少。

    确定scrum会议的时间和地点

    下午开会的缺点是,你第二天早上还得回想一下昨天怎么说的。

    上午开会的缺点是,你第二天早上还得回想一下昨天都干了什么。

    我喜欢上午开,因为你干了什么忘掉一些没关系,你要是忘记了一下需要干什么就太痛苦了

    技术故事

    有些故事算不上真正的故事,更像是一个技术问题,或者非功能性需求。 需要完成,但是又没什么可验收的交付物,也不会被用户直接感知。

    所以,尽量避免出现过多的技术故事,而是用业务语言去描述他给用户带来的价值。

    缺陷和故事

    缺陷一般都是用Jira之类的跟踪,然而每个sprint又包含了修复缺陷的内容。那么怎么整合Jira和Backlog呢

    一般的做法有:
    1. 将Jira中需要修复的缺陷打印出来,作为故事放到Backlog中
    2. 创建一个故事,放到Backlog中
    3. backlog和Jira分离,单独管理
    4. 将backlog中的故事在Jira中管理
    5. 将sprint作为一个缺陷放到Jira中

    不管哪种方式,总之适合你自己的就好

    好了,sprint会议结束了,好的会议能让你在sprint中工作的舒畅,否则,你就等着崩溃吧。如何判断一个好的sprint,只需要看看你每天上班和下班的时间,和你脸上出现笑容的频率就好了。

  • 硝烟中的Scrum和XP读书笔记(1)

    2014-05-21 13:46:02

    第一章 引论

    Scrum不是方法学,他是一个框架,也就是说Scrum不会告诉你到底应该做什么!

    Scrum的强大和令人痛苦之处就在于你不得不根据自己的具体情况对它进行调整。

    如果公司能保持回顾每个Sprint,那么他们就能够不断的调整,从而更好的引用Scrum。

    每个成功的Scrum案例,只是一个典型的应用,不代表符合你的需求。

    每个成功的Scrum都是把各种原则讨论,变成了动手去做的过程。

    第二章 我们怎么去编写产品的backlog

    产品的backlog是Scrum的核心,是一切的起源。

    Backlog是一个requreiment,user story或者feature等组成的列表,并按照重要性进行了排序,使用的是能够被客户所能理解的术语进行描述。

    Backlog一般包含了如下的基本字段:
    1. ID 统一的标识符
    2. Name 一个简单描述的requriement/user story/feature的名称
    3. 重要性 排序的依据,之所以不用优先级是因为在同等优先级的情况下无法区分顺序。重要性是点数 10/15和50还是很容易区分的
    4. 估时 初步的估时,一般都是人/天来做为单位
    5. 场景 一个大致实现的步骤。 例如:登录,打开xx界面,输入xx,点击xx,在xx界面看到xx结果。
    6. 注释 一些其他的信息。例如:该功能的流程图的位置 P:\\Design\features\HTO.vsd

    当然,你会根据你自己的实际应用添加很多其他字段,比如Assigner,Dead Line等等。

    一般Backlog不要放到版本控制中,因为它需要给所有的参与者看,修改和补充,所以它也没有一个严格的版本控制,需要大家时时的查看一下。 当然,作出修改后,提醒相关的人,留下修改历史都是有益的。

    另一个常见的问题是,当一个有技术背景的人去添加一个新的需求时,使用的是技术术语,例如:给搜索添加一个返回用户名的接口

    OK,这个时候,其他人员:产品,测试,客户,需求都完全没明白他要干什么去做这个任务。

    所以,添加的时候要从业务角度去添加,上面那个示例实际的需求是:我搜索的结果列表中,应该列出该文章的发布者姓名。

    第3章 做sprint计划前,我们需要准备点什么

    有了backlog以后,就可以开始做sprint计划了。但是,还是需要有一些提前准备的任务需要去完成。

    1. 你要有一个真正存在的backlog文档
    2. 一个产品,只能有一个backlog文档和一个产品负责人
    3. 所有的backlog的条目都已经被评过分
    4. 根据评分和产品计划,进行了重新排序
    5. 所有的人都看过了

    对于评分,需要多说几句话:
    1. 低优先级的条目,可以是一个同样的分数,例如300,意味着短期之内根本不会加入sprint计划
    2. 下一个sprint要涉及的条目的分数尽可能的接近
    3. 分数只是用来排序,20和200 不代表任何含义,只是为了排序方便
    4. 最好分数之间有间隔,以便有紧急的需求加入,例如10和20之间很有可能加入一个15的紧急需求
    5. 产品负责人必须清楚的明白这些条目对真正的需求是清楚的描述,而不是稀里糊涂的
    6. 估时是开发团队的事,不要在开发接手之前,就硬加个deadline进去,除非非常特殊的时期

    backlog放到哪里合适呢,现在很多人是用excel,或者Trello,不管那个,你的团队用起来顺手就行。




  • 搭建自动化网页功能和性能测试框架

    2013-12-30 16:03:16

      Cucumber是BDD的自动化测试框架
      Watir WebDriver是基于WebDriver的GUI测试框架
      PhantomJS 是一个非界面化的浏览器引擎(headless WebKit),并附带相应的JavaScript. API。
      YSlowJS是一个以Yahoo性能标准进行页面分析的工具,与原生的YSlow的不同之处是不需要预先生成HAR文件即可进行性能分析。
    安装
    1. 下载并安装Ruby(https://www.ruby-lang.org/zh_cn/downloads/)
    2. 安装Watir Webdriver (gem install watir-webdriver)
    3. 安装Cucumber(gem install cucumber)
    4. 下载并安装PhantomJS (http://phantomjs.org/download.html)
    5. 安装并下载YSlowJS(http://yslow.org/yslow-phantomjs-3.1.8.zip)
    6. 在Jenkins中执行feature文件:

    cucumber d:/test/login.feature --format json --out cucumber.json 

    其中:
    d:/test/login.features是要执行的功能测试用例
    --format 指定生成文件格式为json 
    --output cucumber.json 功能测试结果数据文件

    7. 在页面切换的场景时,添加语句
    System(‘phantomjs /tmp/yslow.js -i grade -threshold “B” -f junit url >yslow.xml’)

    其中:
    /tmp/yslow.js是该文件的路径,你也可以指定绝对路径
    -i grade 指定所有的性能规范都会被执行一遍审核你的页面
    -threshold “B” 指定是低于评分”B”的项,都会认为是失败的。
    -f junit 指得是Jenkins的输出格式
    url指得是前往的页面
    yslow.xml是用junit格式输出的结果数据文件

    或 TAP方式
    System(‘phantomjs /tmp/yslow.js -i grade -threshold "B" -f tap url > yslow.tap’)

    8. 配置发布cucumber,junit 或者 TAP 的测试结果在报告中(Post-build Actions)
    9. 可以使用phantomJS的抓图,也可以用Cucumber的抓图

  • Cygwin卸载

    2013-10-17 10:39:07

    安装了个cygwin,想要卸载,发现没有卸载方式,后来查了一下,发现了一个最科学的:

    安装cygwin时,下载那个那个安装文件就可以用于卸载,点击后,进入下一步,选择从本地目录安装,点击下一步,然后有一个列表用来描述你要安装那些组件,在最上面是all,后面显示default,你点击这个default,就会变成install,reinstall,uninstall,等等,选择uninstall,完成后,就可以去放心的把所有文件夹删除了
  • Gatling的进阶三

    2013-10-11 14:48:49

    1. checks

    check是Gatling非常重要的一个特性,用来判断是场景否真的执行成功了

    .exec(http("request_1")
          .get("/")
          .headers(headers_1)
          .check(status.is(302)) // 我们期望返回的status是302,所以check
      )

    或者
    .check(regex("""<td class="number">ACC${account_id}</td>""").exists)
    判断是否在返回的response中包含正则表达式所匹配的字符串

    check还能够在执行过程中将动态的数据保存下来,例如:
    check(
      regex("""<a href="/excilys-bank-web/private/bank/account/(ACC[0-9]*)/operations.html">""")
      .saveAs("acc1")
    )
    将匹配的数据存放到acc1中,以便在下面的场景中进行使用

    2. session

    当模拟器运行时,每个用户拥有自己独立的session。我们可以利用session做点有益的活动:

    例如上例中,我们使用的account id,每次都需要从feeder的读取中获得,而且必须事前指定,不够动态。实际上,我们可以从过程中直接获得:

    check(
    regex("""<td class="number">ACC(\d+)</td>""")
      .saveAs("account_id")
    )
    然后就可以在接下来的scenario中使用${account_id}

    3. 条件判断

    你可能需要根据不同的状态执行不同的场景,这时候就需要条件判断
    .doIf("${username}", "user7") {
        exec(
          http("request_9")
            ...
        )
        .pause(0 milliseconds, 100 milliseconds)
        .exec(
          http("request_10")
            ...
        )
    }

    通过doIf,只有username是user7的模拟用户,才会执行下面的操作

    还可以使用更高级的scala功能:
    .doIf(session => session.getAttribute("username") != "user7") {
      exec
        ...
    }


  • 性能测试的类型,方法,原则和阶段

    2013-10-11 14:25:53

    性能测试的类型

    1.性能测试
    性能测试的目的是验证系统是否达到了设定的性能指标。包含了一组预先设定的性能参数指标,测试场景的测试方法
    2.负载测试
    负载测试的目的是研究系统在一系列的梯级压力下的性能指标的趋势
    3.压力测试
    压力测试的目的是发现系统各模块,硬件,功能的瓶颈点,来研究和提供系统升级的方案和优化点集合
    4.过压测试
    过压测试的目的是研究系统在超出可承受的范围后的工作状况,用于灾难恢复和紧急处理方案的设定
    5.耐力测试
    耐力测试的目的是研究系统在中值压力情况下持续一段指定时间从而表现的稳定性指标
    6.并发测试
    并发测试的目的是模拟用户的真实操作,从而获得系统的可靠性指标
    7.配置测试
    配置测试的目的是研究系统在不同硬件配置下的性能参数指标,从而获得系统的扩展性指标
    8.监控测试
    监控测试的目的是研究系统在上线后不断的监控制定的性能参数指标,从而获得系统的健壮性指标

    性能测试的方法

    1.线性投射
    用过去的,扩展的或者将来可能发生的数据组成散布图,利用这个图表不断和系统的当前状况对比
    2.分析模型
    用排队论公式和算法预测响应时间,利用描述工作量的数据和系统本质关联起来
    3.用户模拟
    模仿实际用户的使用方法测试的系统性能
    4.基准线
    将预定义的性能指标或者第一次性能测试的结果作为基准,将后来进行所有的测试结果与之进行对比

    性能测试的阶段

    1.开发阶段前期
    使用基准线测试方法来确定应用程序不会因为新代码出现性能下降,类型为性能测试
    2.开发阶段后期
    使用分析模型方法来确定应用程序的稳定性, 选用的类型为负载测试,压力测试,过压测试和耐力测试
    3. 测试阶段
    使用用户模仿方法来确定应用程序的可靠性,选用的类型为并发测试
    4.发布阶段
    使用基准线方法来确定应用程序的扩展性,类型为配置测试
    5.运营阶段
    使用线性投射方法来确定应用程序的健壮性,类型为监控测试

    性能测试的原则

    1.准确性
    应使用几种不同的测试工具或手段进行独立测试,将结果相互印证,避免单一工具或测试手段自身缺陷影响结果的准确性
    2.关注性
    在不同的阶段,针对不同的测试对象,要有不同的关注点,从而选择不同的性能参数,指标和方法
    3.探索性
    性能测试带有一定的探索性,所以应由易到难逐步排查:
    服务器硬件瓶颈 -> 网络瓶颈 -> 服务器软件瓶颈 -> 中间件瓶颈 -> 程序流程业务瓶颈 -> 程序模块瓶颈 -> 程序功能瓶颈
    4.单一性
    性能调优过程中,一次只能进行一个性能指标的调优,并且每次只能改动一个设置,避免相关因素互相干扰
    5.延展性
    调优过程中一次只能进行一个指标的调优,但是要延展到所有的相关指标,进行比较分析,掌握好性能调优的平衡
    6.目的性
    性能调优,要深刻理解“有限的资源,无限的需求”,不能做无意义的调优
    7.有限性
    性能调优必须有一个明确的范围值,或者说有一个明确的调优中止阀值
    8.有效性
    性能调优带来的未必是一个优化的结果,必须承担一定的失败几率
    9.时效性
    性能调优是有一定时效的,超过了时效的调优,没有任何意义
    10.成本性
    性能调优本身具有一定成本,而且目的也是对成本的调优,要衡量各种调优方法的成本。

  • 性能测试工具Gatling - 设置Recorder

    2013-10-11 13:35:13

    利用Gatling自带的Recorder,可以大大节省我们书写scenario的时间。

    用法和selenium的IDE类似,作为一个代理服务器在browser和application之间做桥梁作用,从而将操作过程直接转换为scenario。

    1. 运行
    直接执行bin目录下的recorder.bat或者recorder.sh文件即可

    2. GUI界面
    需要配置的有 Listening Port, HTTP一个,HTTPS一个,默认都为localhost。如果需要一个远程的代理,那么就在Outgoing proxy中填写

    3. 包
    在simulation information中填写packapge和class name,那么将在指定的output目录下自动生成该包目录,和该class名的scala文件

    4. 配置浏览器
    在浏览器中,启用代理服务,将上面的代理服务信息填写

    5. 启动Recorder和Browser
    启动完毕后,就可以在浏览器中进行操作,所有的请求和反馈就在其中展现

    6. 保存
    点击保存后,所有的信息就写入上述生成的scala文件中

    7. 过滤器
    可以添加过滤器,将不需要的信息过滤掉。
    过滤器可以有两种:Java,就是用java语言描述的正则表达式
    Ant,自然语言模式。例如,过滤所有的css文件,就添加一条Ant,然后书写内容:/**/*.css

    8.录制的event
    录制的event主要是如下三种:request,pause和tag

    对于request,以请求模式|请求的URI来显示,例如:GET | http://www.ebusinessinformation.fr/

    选择一个request event,则在request和response区域中显示该请求的详细内容。而且如果request中包含了body,则会被存在另外一个文件夹request-bodies中。

    对于pause,则会自动记录实际的停留时间,可以后期根据需要进行修改
    对于tag,是为了让代码更加好理解,相当于添加的comments

  • Gatling的进阶二

    2013-10-11 13:17:58

    1. 参数化

    Gatling可以很方便使用csv文件进行参数化,例如一个用户信息表:

    /* user_information.csv */
    username,password,account_id
    user1,password1,4
    user2,password2,7
    ...
    user10,password10,34

    那么在gatling中就这样调用参数文件:

    /* Scenario */
    .feed(csv("user_information.csv")) 
    /×获取csv文件,该文件在固定的data文件夹下×/

    .exec(
      http("request_3")
        .post("/login")
        .param("username", "${username}") //参数化的用户名
        .param("password", "${password}") //参数化的密码
        .headers(headers_3)
        .check(status.is(302))
    )
    ...
    .exec(
      http("request_5")
     .get("/private/bank/account/ACC${account_id}/operations.html")//参数化的用户id
     .headers(headers_5)
    )

    2. 重复执行

    很多性能测试需要不断重复的执行同一个场景,那么loop就很必要。Gatling提供两种循环的方法:

    第一种:repeat指定的次数
    repeat(10) { // 重复执行10次
        exec( http(...) ... )
        .pause(...)
    }

    第二种:在指定的时间内重复执行直到时间结束
    .during(20 seconds) { // 在20秒内不断的执行
        exec( http(...) ... )
        .pause(...)
    }


  • Gatling的进阶一

    2013-10-10 16:07:54

    首先 抄袭一个Gatling的介绍

    Gatling是一款基于Scala 开发的高性能服务器性能测试工具,它主要用于对服务器进行负载等测试,并分析和测量服务器的各种性能指标。Gatling主要用于测量基于HTTP的服务器,比如Web应用程序,RESTful服务等,除此之外它拥有以下特点:

    • 支持Akka Actors 和 Async IO,从而能达到很高的性能
    • 支持实时生成Html动态轻量报表,从而使报表更易阅读和进行数据分析
    • 支持DSL脚本,从而使测试脚本更易开发与维护
    • 支持录制并生成测试脚本,从而可以方便的生成测试脚本
    • 支持导入HAR(Http Archive)并生成测试脚本
    • 支持Maven,Eclipse,IntelliJ等,以便于开发
    • 支持Jenkins,以便于进行持续集成
    • 支持插件,从而可以扩展其功能,比如可以扩展对其他协议的支持
    • 开源免费

    Gatling适用的场景包括:测试需求经常改变,测试脚本需要经常维护;测试环境的客户机性能不强,但又希望发挥硬件的极限性能;能对测试脚本进行很好的版本管理,并通过CI进行持续的性能测试;希望测试结果轻量易读等。

    是thoughtworks的工程师对其的描述,懒的自己写了。

    跑起来之后,就需要研究一下到底怎么写和怎么录制了。

    第一,gatling使用的是Scala语言,网站说学起来不难,给出的学习地址是http://twitter.github.io/scala_school/

    国内的教学网站http://www.scalachina.com/

    不过我自己习惯了直接跳过往后看,先知道所以然,然后再去知道然

    直接拿示例看:

    package foo.bar (1)
    import com.excilys.ebi.gatling.core.Predef._ (2)
    import com.excilys.ebi.gatling.http.Predef._
    import com.excilys.ebi.gatling.jdbc.Predef._
    import Headers._
    import akka.util.duration._
    import bootstrap._
    import assertions._

    class SimulationWithFollowRedirect extends Simulation { (3)
    //你的代码从这里开始
      val scn = scenario("我的场景")
            .exec(http("我的页面")             
            .get("http://mywebsite.com/page.html")) (4)

       setUp(scn.users(10)) (5)
    // 代码结束
    }

    1. 包的写法没啥特殊
    2. 这个是唯一必须的引入,要不然,啥也跑不起来
    3. 所有的类都是集成了Simulation这个类,类的定义很标准化
    4. val是保留关键字,用来定义你的测试场景, 类似 def的用法
    5. 从这里开始就是你自定义的场景列表了

    教程说,所有的demo基于http://excilysbank.gatling.cloudbees.net,可惜我连不上。有条件的自己下载,部署一个:https://github.com/excilys/excilys-bank

    然后使用Recoder就可以进行场景录制了,然后得到用于回放的scala文件,如何使用Recorder,请参考另外一篇文章。

    我们拿自带的 BasicExampleSimulation.scala 作为示例

    我们可以看到,该文件主要包含了如下几个部分

    1. HTTP protocol configuration 
    最重要的是定义了使用那个地址作为base URL,并且作为一个Scala value定义好以后,可以在simulation中直接调用,语法是:
    val httpProtocol = http
          .baseURL("http://excilys-bank-web.cloudfoundry.com")

    2. Headers 定义
    Header是作为一个Scala Map来定义的。在这里,你可以定义每个request(请求)在发送给server时使用的header。 这这里预先定义之后,就可以在scenario中使用。虽然看起来把common的header定义出来没什么意思,实际上,这也是变相添加测试压力和模拟真实用户操作的必要方法。语法是:val headers_1 = Map(....)

    3. scenario (场景)定义
    在simulation之前需要定义好执行的场景,因为:在同一个simulation中可以同时包含多个scenario。作为一个Scala value, 语法是:val scn = scenario("场景的名字") ...

    scenario主要的结构就是由exec和pause组成。exec用于描述要执行什么操作,pause用例模拟用户的思考时间

    val scn = scenario("Login action")
      .group("Login"){
         exec(
             http("request_3")    
               .post("/login")
               .headers(headers_3)
               .param("username", "user1")
               .param("password", "password1")
               )
         .pause(1 milliseconds, 100 milliseconds)
         .exec( ...)
         .pause(...)
         }
         ... ...

    上面的示例可以看到,exec要执行的操作是一个http,该http操作的名字是request_3,基于base URL采用了post方式发出请求,并附带了两个参数param。其中的header就是在headers里预先定义好的headers_3。然后执行了一个pause的操作来模拟用户的think time

    如果exec太长,或者你想结构化一下代码,可以用这种方法:
    val chain_1 = exec(...)...
    val chain_2 = exec(...)...
    val scn = scenario("My Scenario")
          .exec(chain_1)
          .exec(chain_2)

    4. simulation (模拟操作)定义

    simulation中的操作是通过setUp来定义的,users标明实际并发的用户数

    setUp(scn.inject(ramp(3 users) over (10 seconds)))
       .protocols(httpProtocol)
       .assertions(
         global.successfulRequests.percent.is(100), details("Login" /"request_3").responseTime.max.lessThan(2000))

    通过assertion来进行断言,scn来标识执行的场景, httpProtocal来标识HTTP protocol配置

    ramp (users) over (times)是指在多长时间内触发多少个指定用户
    注意 
    ramp(3 users) over (10 seconds) 等同于scn.users(3).ramp(10)

  • web性能测试的新利器 - Gatling 介绍

    2013-10-10 15:46:53

    最近发现了一个新的性能测试工具Gatling,貌似比Jmeter还好玩。这几天就先简单介绍一下。 

    该开源项目的地址是:https://github.com/excilys/gatling/wiki

    第一步,让我们看看简单的入门

    1. 下载 
    你可以选择下载 .tar.gz 或者 .zip 包:https://github.com/excilys/gatling/wiki/Downloads
    2. 解压 
    解压到任意一个目录中,网站的提示是不要放到有Programs的文件夹中,因为可能是会出现权限的问题
    3. 优化(可以跳过不看)
    如何从操作系统层面进行优化配置:https://github.com/excilys/gatling/wiki/HTTP#wiki-tuning
    4. 编码(可以跳过不看)
    默认的编码是utf-8,如果需要更改,步骤如下:
    1)在Recoder里选择你想要的编码
    2)在gatling.conf文件中修改为你选择的编码
    3)保证你使用的编辑器和保存过程中为相同的编码
    5. 执行
    直接点击bin目录下的gatling.bat文件就可以运行

    本人遇到了一个问题:-XX:+OptimizeStringConcat 这个配置项导致无法启动,原因是该选项是优化64bit的JVM。我是64bit的win 7, 但是是32 bit的jdk 删掉了该选项就正常运行了

    另外一个问题:版本2.0以上的gatling需要JDK1.7以上的版本

    6. 执行
    运行起来以后,你会看到:

    Collecting simulations...

    Choose a simulation number:

      [0] advanced.AdvancedExampleSimulation

      [1] basic.BasicExampleSimulation

    这两个是自带的例子。你可以选择其中一个进行研究。

    好了,gatling在你的机器上,可以跑起来了


  • 三十六计

    2013-05-26 13:44:13

    一时萌动,写下了这三十六计,算是个人思想的一种总结。以后有机会自己回头在看看更新一下,各位看官看看就得。
  • 测试三十六计-第三十六计-走为上计

    2013-05-26 13:41:03

    【释义】
    指战争中看到形势对自己极为不利时就逃走。现多用于做事时如果形势不利没有成功的希望时就选择退却、逃避的态度。

    我们在测试过程中的走,其实是指所有的东西都是动态的。

    敏捷测试的核心就是动态。

    需求是动态的,用例是动态的,计划是动态的,环境是动态的,资源是动态的,只有所有的一切都能在动态中去进行,才说明你的团队是敏捷的

    放弃那些静态的瀑布模型的恶习吧,那只是一副固定在墙上的山水画。
1461/812345678>
Open Toolbar