-
敏捷团队的建立感悟（1）
2015-01-06 14:53:46
最近给一个公司做Scrum Master，有很多感悟：1. 一开始接触的时候，感觉该公司已经做了2年的敏捷开发了，而且走的是XP2. 实际接触以后，发现实际情况完全不一致3. 很多人对敏捷本身理解就很浅4. 导致对敏捷开发产生了很多错误的理解5. 生套很多名词，最后就集中在一个快字上6. 实际上产品，开发，测试一团糟所以，挣扎了三个月之后，决定从以下方面入手：1. 先对所有人进行基础培训，在最基本的概念上达成一致2. 在非实质性的敏捷开发时，不妨屏蔽这个混乱的名词，强调一下瀑布/迭代3. 推行敏捷的理念：瀑布开发本身也是可以敏捷的，不冲突；迭代只是能够让开发敏捷起来的一种方法4. 从源头上推动：先教会产品人员书写User story开始，培养他们的需求来源于真实客户需求5. 压制项目开发的模式，走服务提供的模式6. 压制高层领导的无谓指挥 -
敏捷中常见的陷阱
2014-10-16 14:47:12
以下这些，往往是一个敏捷团队会不知不觉中犯的错误，而不是一个非敏捷团队因为不懂而瞎做的。因为他们本质区别在于：一个是因为上一个成功的迭代没有涉及，从而忽略其中一些；一个是强行的去执行，以为自己就是敏捷。Adding stories to a sprint in progress往进行中的Sprint添加新的故事敏捷的团队有时候因为需求更新或者细化后发现新的/隐藏的用户故事。这是因为在计划会议中大家忽略了。非敏捷的团队习惯了在制定好计划后，觉得有些东西需要提高优先级，强行添加，从外部打断了敏捷过程。Lack of sponsor support缺少领导层的支持敏捷的团队因为过于自组织，对于一些外部环境未必能够及时感知，比如和其它团队形成了竞争，浪费了资源。非敏捷的团队认为自己能够管理自己，对领导成的风险控制反感，强行封闭自己，认为必须遵循不能干扰的原则。Insufficient training缺乏充足的培训敏捷团队中有些成员能够完成一些任务，但是如果有更好的培训的话，能提高团队的生产率。非敏捷团队往往就是随意根据需求抓人，连很多背景内容都没有讲解就强行开发。Product Owner Role is not properly filledProduct Owner角色没有充分发挥自己的职责敏捷团队中的PO因为信赖团队，降低了验收力度和沟通成本，从而带来风险。非敏捷的团队的PO很多时候过多的干预了团队的既定任务和计划。Teams not focused团队缺乏统一的目标敏捷的团队的统一目标很多时候因为减少了日例会的效率，从而出现信息不一致。非敏捷的团队只有一个最终目标，没有个人目标和团队目标的契合过程。Excessive Preparation/Planning过多的准备和计划敏捷的团队因为过于习惯了充分考虑一切，从而浪费了产品上线的最好时机。非敏捷的团队因为没有良好的团队合作，从而在执行过程中不断的重新储备和修改计划Problem-Solving in the Daily Scrum在日例会中解决问题敏捷的团队经常将几句话能说明的事情放到例会中讨论结束非敏捷的团队直接将例会变成了讨论会。Assigning Tasks分配任务敏捷的团队因为对某些人的信赖，不自觉的将一些任务推送给了特定人员非敏捷的团队是直接分配任务给每个人Scrum Master as a contributorScrum Master参与交付敏捷团队的Scrum master有时候因为了解过多，不自觉的参与了交付过程中的某些任务。非敏捷的团队习惯性的在团队中指定一个人作为Scrum MasterLacking test automation缺少自动化测试敏捷团队习惯性的认为保持了代码的稳定，通过结对编程增加了bug排除率，所以自动化规模较小。非敏捷的团队只是对功能进行了自动化，甚至是GUI层面，缺乏深层次的自动化代码检查。Allowing technical debt to buildup允许技术型的债务积累敏捷团队经常喜欢研究更新的的技术，越级更新，缺少了中间的稳定版本。非敏捷团队很少去更新技术和框架。Attempting to take on too much in a sprint试图在一个sprint里交付很多敏捷团队经常在成功的累积产生足够的信心，想增加一部分，或者偶尔加班。非敏捷团队完全不知道优先级和产品战略，直接就拼命的堆功能。Fixed time, resources, scope and quality限定时间，限定资源，限定范围，限定质量要求敏捷团队认为能够在四限下完成交付，缺少风险管理和应对手段。非敏捷团队往往目标是四限，最后只是去cover限定时间。 -
敏捷十二原则
2014-10-16 14:23:20
敏捷本身有一些基础的原则，通过这些原则对你现行的软件开发流程进行敏捷化。
1. Customer satisfaction by rapid delivery of useful software我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。也就是说，我们敏捷化的第一个方向就是转换软件开发的目的，从满足产品的设计要求，到能够快速获得产品用户的反馈并及时响应反馈。所以，敏捷的交付周期一般较短，目的就是能尽快将产品展示给用户去使用，并通过使用来产生真正有价值的回馈。同时，这也要求了开发能将产品需求实现过程中，尽可能的切割成一个个独立的小特性。User Story是广泛使用的方法。2. Welcome changing requirements, even late in development欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。很多公司纠结到底是什么时候允许需求变化，是因为他们还在意于每个交付周期的产出量。真正的敏捷过程，在一个产品的前期会有大量的failed的sprint。所以Git的流行就满足了这方面的需求。3. Working software is delivered frequently (weeks rather than months)经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。有很多团队，觉得为了交付一个产品特性，需要很多底层构建，所以无法满足持续的交付可工作的软件。其实，这是因为在计划会议时，把很多非交付性的或者技术型任务加入了交付迭代中。所以合理的安排任务很重要，必须保证产品设计能够切分成足够独立的特性。对于那些不可分割的底层架构，需要单独的团队去完成。所以看板是很重要的工具，他能将不同的团队的工作协调起来。4. Close, daily cooperation between business people and developers业务人员和开发人员必须相互合作，每一天都不例外。很多敏捷团队都只包含开发人员，这个没有问题，但是每日例会，或者Scrum Master要经常推动开发团队和业务人员进行沟通，因为很多变化就在每日的沟通中就能够潜移默化，不用等到最后一天去fail掉整个sprint5. Projects are built around motivated individuals, who should be trusted激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。敏捷团队的每个人都是独立的交付个体，他们进行自我管理，通过主动精神形成一个敏捷的团队。在这个过程中，需要整个外部环境的支持。要保证他们的资源需求，保证他们的培训力度，保证他们的团队建设，保障他们的个人利益，然后不要打断他们，才能形成一个敏捷的团队。 从来不会有一个敏捷团队能依靠自己的资源建设成功。6. Face-to-face conversation is the best form. of communication (co-location)不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。每日例会是为了寻求帮助，但是沟通要在很多情况下同样适用面对面的交谈。各种会议，各种方案，文档，计划的审核，都需要每一个人发出自己的声音。任何情况下，先保证面对面交流达成一致，然后才用文本方式归档。结对编程，就是两个开发面对面的交流中实现代码，包含可设计，验证，开发，自测，code review等过程在内。7. Working software is the principal measure of progress可工作的软件是进度的首要度量标准。怎么衡量进度，任何口头，数面的确认都没有一个已经能够Demo的产品有说服力。所以，我们要拿Demo作为验收的关键点，没有完成Demo，就没有完成进度。8. Sustainable development, able to maintain a constant pace敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。敏捷是要团队能够稳定的开发，产品才能稳定，质量才能稳定，所以加班是反敏捷的。9. Continuous attention to technical excellence and good design坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。产品更新，不光是需求更新，还会包含技术和架构的更新。这也是一个敏捷的团队成功的标志之一。因为这是每个成员的主动精神的集中体现，愿意将自身的发展和团队的目标绑定一致。10. Simplicity—the art of maximizing the amount of work not done—is essential以简洁为本，它是极力减少不必要工作量的艺术。敏捷要求简洁，简洁的目的是只为了目标达成而必须的工作才去做，所以简洁的架构才更具有扩展性和衍生性。认为设计具有扩展性是复杂的设计过程，那么他对架构设计就是个门外汉。11. Self-organizing teams最好的架构、需求和设计出自自组织团队。自组织团队的标准可以认为是每个团队的成员的工作目的都是为了同一个目标，大家没有相互依赖，而是相互支持。同时，自组织也意味着团队的所有成员都是平级的，任务是自己选择的，而不是分配的。12. Regular adaptation to changing circumstances团队定期地反思如何能提高成效，并依此调整自身的举止表现敏捷的另一个含义就是不断的反思，过程改进，从而不断的重复正确的，成功的步骤达到目标。 -
敏捷宣言
2014-10-16 10:12:57
最近做敏捷推广，发现很多人虽然号称了解敏捷，但是实际的一操作，很多人明显的完全不懂什么是敏捷，所以最后只能从头做起。今天就准备先讲一下敏捷宣言，也就是敏捷的价值。首先我们看一下敏捷的原文：Agile Software Development。很多人都知道这是敏捷软件开发，然后就自动理解为一种新的开发方法或者模型，区别于瀑布，迭代等。岂不知，这应该是敏捷的软件开发的简写。也就是说Agile是个形容词，是说让软件开发变的灵活具备快速应对变化的意思。很多人都没理解到这点，所以出发点就错了。然后看看中文mediawiki上的解释：敏捷软件开发，又称敏捷开发。是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。好吧，不说了，基本上都是似是而非看看英文版的：Agile software development is a group of software development methods in which requirements and solutions evolve through collaboration between self-organizing, cross-functional teams.敏捷软件开发是一个需求和解决方案不停演化的自组织，跨功能团队所拥有的一系列软件开发方法的集合。It promotes adaptive planning, evolutionary development, early delivery, continuous improvement and encourages rapid and flexible response to change.它促进了自适应式规划，演化式开发，预先式交付，持续式改进，并鼓励快速和灵活的响应变化。明显的理解有差异的，这就是中国的通病，很多人只看别人翻译，或者到处转载那些明显有问题的听起来简单的解释，反而南辕北辙。所以想了解敏捷软件开发当初的起源，就需要真正的去看一下敏捷宣言。敏捷宣言从一个整体来说需要按如下顺序阅读读：（要注意，敏捷宣言每一项是按顺序来的，也就是说有相互的依赖）We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：Individuals and interactions over Processes and tools个体和互动 高于 流程和工具Working software over Comprehensive documentation工作的软件 高于 详尽的文档Customer collaboration over Contract negotiation客户合作 高于 合同谈判Responding to change over Following a plan响应变化 高于 遵循计划That is, while there is value in the items on the right,we value the items on the left more 也就是说，尽管右项有其价值，我们更重视左项的价值1. 首先强调人和交流2. 首先强调能够展现的软件3. 首先强调团队合作4. 首先强调按需变化，动态调整5. 但是，并不是说我们追求左边4项就认为右边四项不重要了6. 也就说流程和工具还是必须的，是为了更好的个人产出和高效沟通7. 能够展现的软件是由那些必要的文档实例化的结果，文档对软件是强力的补充8. 合同谈判的目的是为了树立统一目标，然后双方合作，而不是单方检验9. 计划是开始的基础，我们在计划上调整响应变化，而不是没有计划。10. 右边4项必须存在，才能让左边四项发挥更大的作用11. 左边4项就是为了让右边4项敏捷起来12. 敏捷的软件开发是基于有序的开发基础上，更具备灵活性。让我们逐一看一下这四项1. Individuals and interactionsin agile development, self-organization and motivation are important, as are interactions like co-location and pair programming.个人的重要性体现在自我组织和主动精神上。而限制工作区域和结对编程都能带来良好的交互。所以真正敏捷的团队的人都知道，敏捷对每个人的要求很高。需要很强的主动精神，愿意为了达到团队价值全力贡献自己的价值。然后具有很强的自我组织和自我管理的能力。同时，能够和团队所有成员高效协作。这就是为什么一个敏捷团队很少会换人，保持团队的稳定，才能保证团队的敏捷性。为了团队建设，大家面对面的坐在一个限制性的区域里从而能够随时沟通非常重要。而结对编程使得大家能够不停的互相促进，并形成同一种风格，使得产品的稳定性极大增强。2. Working softwareworking software will be more useful and welcome than just presenting documents to clients in meetings.能够直接演示的软件远远比文档更容易被客户所接受。我们能够通过各种文档向客户演示我们要交付的内容，但是这些东西对客户的吸引力完全没有一个能够展示的软件更有力。通过实际的展示，讲解，操作和试用，能够得到极大的UE提升。但是，Demo的时间毕竟有限，各种文档还是必须的，用户不可能在那么短的时间内有效的获取所有信息，所以Demo之后/之前，都可以进行一次文档交付，让用户获得更多的详细信息。3. Customer collaborationrequirements cannot be fully collected at the beginning of the software development cycle, therefore continuous customer or stakeholder involvement is very important.需求在软件开发周期的初始阶段是不可能充分获取的，所以和用户协作不断的探讨和更新需求是非常重要的。合同讨论的其实是一个大的框架，我们首先要知道我们大体要完成内容，这样才能够集中精力去做。也就是说先有Scope，然后才能去制定交付。否则，纯粹开放型的需求等于没有需求。 很多产品人员认为需求可以不断的变更，其实是因为他们根本对客户的需求没有理解透彻，从而不断更新。敏捷强调更新，强调过程中补充，但是不是说你连最起码的目标都不清楚。而且，所谓的补充信息不能是关键点，只能是迭代更新，而不是增量更新。敏捷更会控制需求变更，而不是纯粹的接受所有变更。 所以在很多敏捷框架中，都指明了能够进行需求变更的时间段，以及变更的风险，以及sprint失败的条件。4. Responding to changeagile development is focused on quick responses to change and continuous development.敏捷开发关注于快速的响应变化和持续开发。敏捷开发响应变化的目的是响应用户的变化。 也就是，真正的变化是你在给客户进行Demo之后，然后由客户发起的需求变化。而不是在研发过程中，不停的由产品经理发起变化。为了避免这种情况，所以各个sprint周期才会普遍采用一周/二周的短时间段。就是为了能够用1/2周的损失避免1/2个月的时间损失。所以很多人认为敏捷就是迭代的/增量的开发。其实跟这个一毛钱关系没有，很多敏捷做得好的公司，只要产品目标明确，瀑布开发也能够很敏捷。所以敏捷不依赖于你采用哪种开发模式，它是你如何让你的产品开发敏捷起来而采用的所有方法的集合。现行的敏捷框架都是每个公司自己的成功结果。 -
Jmeter的正规表达式
2014-08-01 10:19:28
JMeter使用Apache Jakarta ORO进行模式匹配可以通过下面的地址对ORO进行更详细的了解：A summary of the pattern matching charactershttp://jakarta.apache.org/oro/OROMatcher User‘s guidehttp://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.txtTest_g0 值为 name="file.name" value="readme.txt"Test_g1 值为 file.nameTest_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开始之前，团队内部demo3. 主持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. 定义个专门测试的sprint9. 雇佣更多的测试人员，设置个资源池，然后各个团队复用第十五章 怎么管理多个sprint团队团队越多，管理越复杂，scrum不可能简单的将管理弄的轻易化。那多少个团队合适，每个团队的人员怎么安排呢？我的经验是，一个产品有一个大团队，然后设置一些虚拟组织（虚拟团队）例如，产品，开发，UI，前端，测试，运维都属于一个产品团队。 其中产品虚拟团队，开发虚拟团队，测试虚拟团队等等都存在。 这样能解决一个人要听两个人的指挥，也能解决我没有个自己的圈子去协作。至于实体团队和虚拟团队怎么分配，还是得看你自己的选择，你怎么能让他们有效的运转起来，就行。那么很多时候超过20个人的大团队也必须分配成几个实体小团队。每个小团队的人数最好不要低于3个，不要超过10个。我喜欢3个一组的小unit，一个中级的带两个初级的，很有效率。 每个团队都是由这一个个小unit组成。而且团队也不是一成不变的，要随时拆分，随时合并，当然是根据情况而来。同时进行多个sprint也可以，但是前提是相互之间没有干扰。而且，同步开发的时候，要保证2，3个sprint后你有机会进行一次团队重组。每个团队，要有一个负责人，但是不是管理者，确切的说是沟通者，这个领导代表整个团队跟其他团队沟通。我们的做法是设置了一个委员会，其实就是各个团队的负责人坐在一起协调资源。是否有保持一个特定的团队，也需要斟酌，比如专门做服务器后台的团队。稳定和高效，以及轮换和机遇永远是个针锋相对的话题。可能的情况是：一个固定模块的团队；一个跨多个模块，但是固定组件的团队。还有一种可能是，你会有个一些人在多个团队里做兼职。甚至，你还需要准备一个救火团队以备不时只需。多个团队的话，还涉及到联席会议，可以像我们一样弄个委员会，也有可能是一个更高级别的管理团队。如果你要自己控制多个团队，那么交错的开会是必须滴。多个团队的时候，是否拆分backlog。在一个大的产品的情况下，这是很正常的，拆与不拆，还得取决于你的团队设置。如果你还保留了一个专门的产品团队，那么一个产品负责人和这个产品团队沟通就行，不用拆。如果需要设置多个产品负责人，最好还是拆吧。一个产品负责人如果负责多个产品backlog，那么我觉得你应该合并产品。多个团队对代码分支的要求也比较严格一些：1. 主分支永远要保持稳定2. 每个版本都有tag3. 只有必要的时候才创建分支，使用完毕后要合并4. 分支用于区分不同的产品生命周期5. 要经常同步多团队的回顾更是有必要。 -
硝烟中的Scrum和XP读书笔记（5）
2014-05-22 17:05:30
第十一章 sprint之间的休息第十二章 怎么制定发布计划 处理固定价格的合同发布计划最重要的是验收标准。一个发布，一般包含若干个sprint。所以每个sprint的验收标准和整体发布计划的验收标准都很重要，能保证每个阶段按时完成。产品计划如同一个超大的sprint计划。时间也是团队进行估算。生产率也是依据团队的能力进行预估。设置好整体的发布计划，就可以在不同的sprint根据优先级塞满各个任务。sprint的计划要保证发布计划能够按时完成。调整发布计划是要先调整sprint计划，然后根据sprint计划调整发布计划。第十三章 怎么结合使用Scrum和XPScrum注重的是管理和组织实践。它是一个框架，不会告诉你具体做什么，一切都要实践。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/Jwebunit2）TestNG/Selenium3）Cucumber/Webdriver/Watir4）HSQLDB5）Jetty
6）Cobertura7）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 backlogbacklog包含所有的，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会议的目的是让团队充分的获得信息，从而能在无干扰的情况下去完成sprintsprint会议的产出是：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，不管那个，你的团队用起来顺手就行。 -
Web安全测试入门（1）
2014-05-20 15:35:04
Web的世界发展越来越迅速，很多产品都在叫嚣着移动互联网。随着各种敏捷技术的应用，功能测试已经不是web测试的主体了，越来越的测试人员开始更多的关注web安全测试。那到底什么是安全测试呢，这里有个大致的描述：当产品面临恶意/有意破坏规则的输入时，是否能够提供健全的服务。猛一下，感觉像是反向测试，对不对。实际上，正向测试和反向测试关注的是功能的完整性。而安全测试更多的是破坏逻辑，（Spock：逻辑！）。它测试的那些破坏正常使用逻辑的场景，而不是那些你现在已经能预知的错误输入的反馈。所以功能测试是为了验证我们的产品是否完成了预期目标，而安全测试关注的是软件的”风险“。功能测试是有终点的，而安全测试是无止境的，永远没有“安全”的产品，但是有“完整交付”的产品。例如：对于最大不超过Max Int的正整数输入，产品返回有效的二进制数字。所以，我们在做功能性测试时需要关注：1. 正常值的输入，例如：52. 边界值的输入，例如：-1，0，Max Int3. 异常处理，例如：-5，5.5和ABC而安全测试会关注：1. 一些特殊的数字会引起多次递归，例如：232323232. 特殊编码集，例如全角２３４５６下面讲述一些你需要了解的基本知识1. 什么样的web应用才需要安全测试？那些根据不同的请求返回不同的结果的应用2. SSL和HPPTS很重要吗？不重要，安全测试只关心末端的应用行为，不关心客户端和服务端如何建立连接3. 基础概念1）服务器：监听HTTP请求的应用2）客户端：发起HTTP请求的应用3）请求：客户端向服务器端发送的要求提供服务的内容，包含：URL，参数，头信息等4）URL：统一资源定位符，来定位服务器应用。是URI的一种子类型。5）参数：附带的变量，是由“=”连接的“键=值”数据对。多个参数用&分割。6）方法：请求附带的方法，常见的有POST和GET。7）构件：组成Web应用的服务组件8）组件：构成服务组件的功能。一般都是基于“模型-视图-控制器”实现的。4. HTTP请求是没有状态的，也就是说任何请求都是独立的。5. HTTP请求是明文的，也就是说很容易被伪造6. 安全测试依赖自动化工具，而且只针对软件本身 -
搭建自动化网页功能和性能测试框架
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的抓图 -
新的产品设计趋势
2013-12-26 13:44:15
做产品设计的，已经从怎么提供给用户很多功能进化到怎么提供给用户单一快捷的服务，从提高用户友好度增加用户体验进化到降低用户的学习成本，达到0学习 -
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.成本性性能调优本身具有一定成本，而且目的也是对成本的调优，要衡量各种调优方法的成本。
标题搜索
我的存档
数据统计
- 访问量: 150565
- 日志数: 185
- 文件数: 6
- 建立时间: 2007-08-06
- 更新时间: 2015-01-06
