最近公司又新上马一个项目，为了项目能够尽快抢占市场，产品、设计、开发、测试等小伙伴们在夜以继日地赶进度。除了加班赶进度，摆在大熊面前的一个巨大挑战是：项目组提出每两周迭代并上线一个版本。相信这种情况在各大小公司非常常见，也如大熊一样苦恼着这些问题：1.在版本迭代频繁的情况下，产品的质量如何保证？2.测试人员的测试时间应该留有多少？两周，一周又或者是2天？3.如果测试时间被压缩得很短情况下，质量和进
通过三段式工作的团队需要一个不偏不倚的方式来判断他们的进展。也就是说，你怎么知道“我们在哪一阶段？像任何旅程都有里程碑。我称之为"Look-for's"。正如在这些"look-for's"的东西，可以帮助你确定一个团体如何进行他们的旅程。由于有三个阶段，人们期望有4个里程碑，“起点”加上里程碑标记着每个阶段的完成。我在第一阶段添加了一个里程碑。这样在第一阶段的中间就有一个明显的序列点即团队从总混乱
导语：互联网产品中的检索功能随处可见。当你的项目规模是百度大搜商搜或者微信公众号搜索这种体量的时候，自己开发一个搜索引擎，加入各种定制的需求和优化，是非常自然的事情。但如果只是普通的中小型项目甚至创业团队创业项目，直接拿轮子则是更合理的选择。ElasticSearch就是这样一个搜索引擎的轮子。更重要的是，除去常规的全文检索功能之外，它还具有基础的统计分析功能（最常见的就是聚合），这也让他变得更加
在看过了一些有些的关于敏捷测试的文章（比如这篇），听了许多人在谈论敏捷测试后，我开始意识到敏捷测试跟自己一开始的理解并不太一致。从一个问题问起你认为什么样的团队适合打造成敏捷测试团队？不知道你看到这样的问题时，会怎样去想？或者不妨你可以用几秒钟的时间来想一想这个问题。倒计时，5，4，3，2，1……叮！时间到。笔者一开始接触到敏捷测试的概念的时候，其实是陷入了一个狭隘的误区（产生了一个误解），认为敏
持续交付是当今软件行业的一个热门概念，但它往往似乎是一个不可能的目标。“我们的系统怎么能做到这一点”。在克服几个常见的技术障碍的同时，实践持续交付可能也需要重大的文化变革。在这篇文章中，我将介绍一些我们一个客户使用的关键经历和过程来展现持续交付文化。了解当前过程计算机的事情是不会犯错的，在下一场网络革命到来之前，计算机将继续做他们被编程做的事情–不多做，也不少做。因此，程序员需要明确，无论是自动排
当初就是看到这份由PractiTest发布的STATEOFTESTINGReport2017决定发起一个国内软件测试人员薪水调查（本调查还在继续）。此份报告上面显示工作2-5年的国内测试人员年薪（含奖金）只有12000万美元（相当于人民币8.28万），远低于亚洲平均水平18000万美元（是其2/3的水平，虽然亚洲日本、新加坡、韩国、印度薪水偏高，还有马来西亚、越南、泰国...会低于我国水平），更不
组件化与UI测试在组件化出现之前，我们不谈UI的单元测试，哪怕是对于UI页面进行测试都是一件非常困难的事情。其实组件化并不完全是为了复用，很多情况下也恰恰是为了分治，使得我们可以分组件对UI页面进行开发，然后分别对其进行单元测试。特别是当浏览器中的Web应用越来越庞大的时候，与在后端将大型单体应用拆分成微服务架构的最佳实践一样，前端应用也可以被拆分成不同的页面和特性。（图片来自：http://t.
接上一篇：Rails模式的实际应用--第二部分：Views（一）对Movie的描述我们不会再增加新的行为，这使得我们的实现成为了一个简单的委托。委托的另一种实现方式，可以利用Ruby的Forwardable模块。示例里面我们没有用这个方法是因为这里我们只需要委托一种方法。当需要委托很多方法的时候，Forwardable会有很大的优势。MoviePresenter的全部代码和测试在GitHub上面都
Rails模式的实际应用--第二部分：Views在此系列博文中，我们会一步步亲身实践如何改变Rails应用的默认设计使其变得更加责任清晰并且容易测试。别忘了其他的部分的内容哦！Rails模式的实际应用--第一部分：ModelRails模式的实际应用--第三部分：Controllers你可以参考GitHub上的知识库，里面包含了我们讨论的所有的代码。Ruby的.erb模板是Rail默认的Views。
在上一篇文章里面，通过对DHH的文章以及DHH和KentBeck等讨论的分析，我阐述了对TDD的理解和分类，现在来继续聊聊TDD的实施和分层。现在还有非常多的软件工程师在质疑TDD的可行性，比如太难不会、成本太高无法推动、意义不是很大等，但是他们却一直都在做着TDD，只不过没有意识到而已，这便是“不识庐山真面目，只缘身在此山中”。TDD的实施一般分为思维层面和技术层面。一般来说，思维层面上的实施成
热门文章