摘要： Real-time web features require a long-lived mostly-idle connection per user. In a traditional synchronous web server, this implies devoting one thread 阅读全文

摘要： 三门问题，也称为蒙提霍尔问题（Monty Hall Problem）。你在参加一个节目，面前是三扇关闭着的门。其中一扇后面是小汽车，选中它就可赢得汽车，另外两扇后面各是一只羊。你选择了其中一扇，但没有打开它，这时主持人打开了剩下两扇门中的一扇，后面是一只山羊（这里有个隐含前提：主持人是知道门后的情况的）。主持人问你，要不要换另一扇仍然关闭着的门，还是就要你刚才选中的那扇。那么问题就是，换另一扇门会增加你赢得汽车的概率么？换与不换的概率各是多少呢？因为只剩下了两扇门，其中有一车和一羊，因此答案是换不换概率都是1/2，对么？也有人坚信不换的概率是1/3，那么换的概率就应该是2/3？无论哪种回答，一 阅读全文

摘要： 译自Optimal Loggingby Anthony ValloneGoogle Testing Blog要找到一个系统问题的根本原因，你需要多长时间？5分钟？还是5天？如果你的答案接近5分钟，很大可能是因为你的生产环境和测试环境使用了非常好的日志记录。更常见的情况是，诸如日志、异常处理、甚至测试这类非核心的工作，被当作一种出现问题后的补救方式。同异常处理和测试一样，日志记录真的也需要策略，无论是生产环境还是测试环境。永远不要低估日志的作用。有了使用得当的日志，你甚至可以说debug不是必需的。下面是多年来对我非常有用的日志记录指导原则。保持适度切勿记录过多。大量的磁盘空间被日志占用说明你没 阅读全文

摘要： 之前写过一篇性能测试新手误区（五）：这是性能问题么，主要讲一个有效的性能问题应该是什么样的，其中提到了定位的问题。但是那篇文章只说了WHAT，并没有说HOW，只说tester要有明确的定位，却没提如何才能定位。用流行的话说就是不接地气，有点水：）实际工作中，我也总是接到这种问题，所以还是要写一篇关于方法的文章，来说说HOW TO DO。以一个典型的WEB系统来举例，性能问题一般体现在客户端请求后的响应时间上。在性能测试过程中，即压力增大到某个程度后，响应时间指标迅速增长。但如那篇文章所说，这只能叫做一个现象，测试人员需要找到问题所在，HOW TO DO?首先要搞清楚，客户端从发出请求直到看到最 阅读全文

摘要： 起因现状测试经理不知道性能测试人员在做什么不知道性能测试进展如何不知道性能测试是否有效不知道如何协助性能测试人员本文目的了解性能测试的进展，更好的控制整个测试流程了解性能测试的质量十问性能测试何时介入性能测试的过程是怎样的是否有必要提起性能测试性能测试有哪些类型如何分析性能需求如何衡量性能性能测试（不）能做什么如何检验性能测试的质量…Q1.性能测试何时介入开发生命周期中的性能测试单元测试代码层面的测试。写完一块代码，对代码的执行效率、内存使用、资源占用等情况进行测试，由开发人员完成。组件/服务/接口测试此层面的测试，通常是针对一个已完成的公用功能，此功能向外提供服务或者接口。既可以是代码级别的 阅读全文

摘要： 索引帖：性能测试用户模型分析方法基础数据分析 以下图表均取自互联网，本文是在“已经获取所需数据”的前提下，讲解性能测试的一些设计思路。至于如何才能取得这些数据，将在后续的文章中说明。系统访问量分布 由系统的日访问量分布图，可知系统的访问压力集中在哪个时间段内。系统的压力是在一天中平均分布的，还是集中在某几个更小的时间段内。根据此信息，我们对测试场景的时间进行设计，如从分布图中明显看出每天的大部分访问量集中在9：00～11：00和14：00～16：00两个时段，那么就可以设计2小时内完成一半访问量的测试场景。用户的平均活跃时间 用户活跃时间，是指用户一次使用系统的时长，可用来指导测试脚... 阅读全文

摘要： 索引帖：性能测试用户模型分析方法用户模型 用户的行为主要分为两部分来考虑，一是针对一类特定角色的用户，二是针对整个用户群体。通过一组图形来描述用户的行为、操作路径以及系统各部分的使用率，此种方法称之为用户模型（或者系统使用模型）。 用户模型表示的是系统的使用场景，更准确的说是一个特定时间段的系统使用情况。操作路径是用户模型的核心，通过用户模型，每个人都可以轻易的理解系统是如何被使用的。基本图形：数量或百分比用户类型动作类型同步点（集合点）选择或数据条件循环退出分支合并扩展图形随机顺序访问应用示例 下面以一个在线书店为例，假设我们已经得知以下信息：有4种类型的用户：新用户、已注册用户、... 阅读全文

摘要： 索引帖：性能测试用户模型分析方法概述 在性能测试过程中，很重要的一个部分就是评估待测系统在一定压力下的性能表现。比如系统上线后，真实的性能到底如何？两年后系统的使用用户增加后，性能又如何？这些都是性能测试中，项目相关人最关心的问题。 所谓的性能表现，说的更直观一些，其实就是用户体验。用户不会在乎系统的处理能力是多少、吞吐量是多少，他们能够感受到的只是系统能否处理他们的请求、处理的速度有多快。 这里提到的一个关键词是“一定压力”，这个压力指的是系统在预期的线上场景中所承受的压力。只有准确的定义和模拟预期的压力，才有可能获取到实际场景中真实有价值的用户感受，而不是那些只存在理论意义的数据... 阅读全文

摘要： 系列原创：性能测试新手误区测试人员喜欢在得到某个达不到预期的性能结果后，进行一下“调优”。PM有时也会布置任务，测试完成后“调一个优”。一些人貌似有了这种观念：调优才使性能测试有意义、性能测试的目的就是调优、做调优才能显出测试人员的水平……随着经验的增长和对性能更深入的认识，我越来越体会到调优是一个复杂的过程，不是动动嘴、改俩个参数这么简单，只有通过科学的方法和扎实的技能才能做好，以至于我使用这个词的频率越来越低，因为不敢轻易说出口……在你再一次调优之前，先考虑以下几个问题：为什么需要调优如果问起这个问题，得到的回答通常是“因为性能不够好”，那么接下来我会问性能不好体现在哪里？你要调什么？.. 阅读全文