微博上抛出一个讨论话题：下午一test lead问到，有些测试的 bug会在A版本里出现，然后记录它；但开发人员在当前B版本试图重现时发现不能重现，故reject它。那么测试就郁闷了，待到下一轮回归测试可能是C 版D版本，如果再出现自然reopen，但如果不复现是否真的应该关掉它吗？各位对这种sometimes bug怎么处理的啊？ 这个问题可能每个测试人员都会遇到，我说说我个人观点，供大家
继续深挖一下开发测试比的问题。如果一个公司说，我们今年的开发测试比要达到5:1，或者7:1，甚至10:1，目的是什么呢？可能是为了缩短项目周期，节约交流成本，提高开发的质量意识，大家是否同意？那么我们就这几个目的，谈一谈提高开发测试比是否能够达到这些目的。首先，提高开发测试比，只是提高开发人员和测试人员的比例，并不是提高了开发工作和测试工作的比例，对不对？测 试工作花费的时间并没有因为开发人员做测
在现在的公司里，常常会听到开发测试比这个词。这个词也许很多老大的理解是：开发人员个数和测试人员个数的比例。一次高P开会的时候，我记得一个技术团队的老大曾经说过，开发测试比嘛，当然是越高越好。那好，作为一名一线的测试人员，我想谈谈我对开发测试比的一个理解。首先，我要问，为什么要有测试呢？测试的目的是什么？记得有一本书里曾经说，有一个硬件人员转去做软件，他写的代码从来都没有bug，后来有人问他为什么写
不久之前，我们的一个程序员疯了，而且疯的很有气势， 他走进经理的办公室大喊大叫，说着一些奇怪的东西。 如果我不是像了解自己一样了解他，我会以为他是嗑了药。 但实际上他并不是短暂的精神失常。 他是我在编程业界里见过的最勤奋的程序员。他经常晚上在公司加班， 当周末有紧急工作要处理时，他总能随叫随到。目前这个阶段公司并不挣钱， 老板希望项目能尽可能往前赶，于是，任何客户急催的任务都会自动的分配到他那里。
周末抽空看完了“中国合伙人”，不得不说看完了还是有很多共鸣，正面的负面的，很多很多。我听说很多人去电影院看完了之后都站起来鼓掌。是的，我们需要鼓掌，仅仅是为了他们的成功，他们的坚持。但是我们还需要深入的去思考，我们这一代中很多创业者往往觉得我们能够体会，能够理解，能够坚持，能够熬过去，但是真正体会的时候却是另外一番滋味。 我自己毕业以来，所待的全部是创业公司，人数从10人
从前面的描述，我们可以看到， 性能测试的参数， 输入场景， 关键性能指标都是和性能测试的目的密切相关。 比如， 为了验证是否满足一个重要客户的性能要求， 性能测试可以很复杂， 测试环境包括应用服务器Cluster， DB Cluster， 专用的存储服务器，测试耗时一个月； 为了验证是否在版本之间有性能下降， 性能测试也可以很简单， 所有软件都部署在同一个机器上， 且测试集成在DailyBuild
压力输入场景描述了系统输入压力的构成情况。 和性能参数类似， 压力输入场景也是多种多样的。 那么到底选用什么样的压力输入场景呢？ 对于大多数性能测试， 压力场景一般从客户真实环境获得， 然后经过合理的简化，应用在性能测试中。 要注意， 压力输入场景并不是说越真实越好。 因为如果要构造非常真实环境的压力输入场景， 会需要更多的开发成本和执行成本。 合理的简
性能参数是包括所有会对性能产生影响的因素. 比如软件参数设置， 硬件的能力， 输入的类型等等。 性能测试的结果只有在给定性能参数的条件下， 才有意义。 在性能测试中， 性能参数类似于功能测试中的”输入组合“， 所以，设计时都会面对同一个问题， 不可能穷举的可能。 即使对于一个小的软件， 性能参数的组合也可能是一个非常庞大的数字。 这一点对于 企业应用软件产品 尤其是一个
关键性能指标 (Key Performance Indicator, KPI) 如其名字所示， 是能标志系统性能的最关键的指标。最常见的， Resonse Time和Throughput， 他们是网站的关键性能指标。 下面列出了常见的关键性能指标的四种类型。 几乎对于任何系统， 服务能力指标都是最排在第一位的关键性能指标。 分类 举例 服务能力指标* l
一提到性能模型， 可能大多数人马上就想到网站。 网站的性能模型属于“在线交易处理“模型（On-Line Transaction Processing Model），这是最常见的性能模型。 此外我还总结出另外两种。 流水线模型(Pipe Line Model)和静态数据模型(Static Data Model)。 不同的性能测试模型类型，其测试方法， 性能指标都会很不一样。 比如对于OLTP模
