产品经理会聆听用户声音进行需求收集，但是真正的需求需要我们去优化。真正优化的应该是从需求的收集到最终形成功能融入到产品中的这个过程。下面做一个简单科学的流程。一、需求收集·从用户、市场、竞品、同事、朋友等渠道无差别收集各类问题、建议、与想法，另外通过数据分析和解读出来的需求也可以添加进去。·尽量详细的记录需求的相关属性信息，如提出人信息、需求场景、需求描述等等
如果你就是程序员，或者你熟悉程序员这个群体，有时候你会发现他们在干一些奇怪的事情。比如说，他们跟你说在写一个脚本，你问他写脚本干嘛?他告诉你，这事情重复做太无聊，写个脚本以后就不用老让我重复操作了。听起来很有道理吧?但如果对比一下时间，你会惊讶的发现，他们重复做200次这件事大概总共只需要花一个小时的时间。但写这个脚本反而得写5个小时。以这个职业之外的人看来，这绝对是有病，完全不可理解
账号丢了，几年没有上测试窝，感谢小窝帮忙找回账号。最近上敏捷项目，需要使用cucumber进行自动化测试，在搭建环境过程中遇到安装问题，在此记录，遇到类似问题的同学可以参考。问题描述：安装好ruby后，在rubycommand安装cucumber报错，输入命令：geminstallcucumber--sourcehttps://rubygems.org/，
2016-09-18
这两天在家写了个Redmine插件，在redmine3.3stable版本上亲测有效。源码地址：https://github.com/applewu/redmine_omniauth_gitlab准确地说，我是改写了redmine_omniauth_google插件，来实现redmine_omniauth_gitlab的。但是我之前没有啃过Ruby代码，对Redmine源码
上图：自己揣摩
Loadrunner 做保险承保业务测试 1. 保险正常业务流程：保费计算---》保存---》申请核保---》核保---》缴费（出保单） 问题描述： 脚本录制，参数化完成后，Replay时，申请核保无法生成待核保状态的单。所有单子都是暂存状态。 解决办法： 将申请核保系统返回结果，打印出来。 参考代码如下： //参数化 //Correlation
测试人员的价值是什么 早些年就有人喊出了“测试已死”的口号，主张开发人员交叉测试。他们想说的，并不是“测试已死”，而是“测试人员已死”。没有人否认测试的价值，他们只是认为不再需要专门的测试人员了。 2010年初，我大四来上海实习。算一算快七年，已经是一名测试老兵了。测试人员的价值是什么？我一直在思考。这个问题是在从业的第五年，也就是去年才逐渐清晰明朗起来。 测试的核心价值，我认为是持续
项目管理一直是一个老生常谈的问题，我们身边项目时时刻刻发生，大到火箭上天，小到家庭装修。老K作为技术出身，大大小小也做了不下50个项目，这里老K从IT的角度，带领大家用理论的知识分享如何做好一个项目。 项目管理有四个要素:工作范围、时间、质量、成本。 对一个项目来说当然最理想的情况就是“多、快、好、省”。“多”指工作范围大，“快”指时间短、“好”指质量高，“省”指成本低。但是，这4
需求定义中的不支持——可能的测试盲区 一款产品必然有其系统需求或规格，在设计说明中定义清楚的不支持，不实现的功能或特性，有的时候也可能是测试设计中的盲区。 （举例：需求定义产品产品的一些属性为—
探索式测试最著名而且大家都熟悉的就是JamesA.Whittaker总结的漫游测试模型。如下图：分为全局探索式测试；局部探索式测试；场景探索式测试。其中局部探索式测试和场景探索式测试，与我们日常测试中很多方法会有些重复。但是下面总结的方法我觉得都很好，有很多方法可以学习，用来在我们日常测试用例
