5.1.10 并发测试（Concurrency Testing）简介
并发测试（Concurrency Testing）方法通过模拟很多用户在同一时刻访问系统或对系统的一个功能进行操作，来测试系统的性能，从中发现问题。网站就是一个很典型的需要并发测试的应用场景：当网站运行的时候，在世界各地同一时刻都可能有很多用户在进行同一个操作，如图5-6所示。除此之外，类似的还有银行的某些系统、航空的某些系统等，它们都需要大量用户同时访问和操作。
图5-6 用户对Web应用的并发访问
类似小白在本章开始对公司测试网站的访问是无法发现可能存在的并发问题的。即使是公司所有的同事一声令下，也无法做到比较精确的同时访问，数量也很不够。因此，并发测试是无法用人工的方式来完成的，必须依赖一些工具软件来模拟实现，比如HP公司的LoadRunner等，这个软件我们将在后面的章节专门介绍使用方法。
并发测试所要考察的是系统在并发处理方面是否存在缺陷。实现并发的编码与原理是比较复杂的，需要很高级的开发技巧，因此不在本书介绍的范围之内。在实际工作中，我们只需要了解如下3个要点：
并发测试需要用工具模拟多用户的访问。
要熟悉第一点提到的工具测试并发的操作。本书介绍的是LoadRunner。
要了解并发测试所关注的性能问题是什么。
至于并发中深入的线程、进程、内存泄露等知识，则需要在工作中遇到问题时来学习了。
5.1.11 并发测试所关注的性能问题
并发测试关注哪些性能上的问题？为了理解方便，我们用一个通俗的例子来说明。
还是利用传统的类比--饭馆，毕竟民以食为天。在某一时刻的饭馆中，有很多客人都在吃饭，这可以说是一个并发场景。于是，可能出现的问题有如下几个（当然不限于以下的这些）：
餐桌是有限的，客人很多，超出桌子数目，只能排队叫号了。类似这样抢空闲桌子的情况在程序代码中也会出现，叫做资源（内存等也被称为资源，程序运行需要在内存中，而可用的内存又是有限的）的争用（Race）。
如果饭馆还有一个空桌子，但被别人电话预定了，而此时饭馆等位的人又很多，服务员该如何处理呢？一般是等待15分钟、联系预定人的电话等方法。类似这样有关保留预定与放弃预定的情况在程序代码或者数据库中也会出现，根据条件不同（比较复杂，涉及类似多个客户订同一张桌子等细节），分别叫做活锁（livelock）和死锁（deadlock）等。
如果饭馆的服务员应付众多的客人已经忙不过来；或者就是服务员忘记了，经常会出现这样的情况：有一桌客人在吃完饭后已经结账走人，但服务员并没有及时的清理桌布，收盘子、擦桌子等，导致后面的客人无法使用这张桌子进餐，无形中使得饭馆的接待能力下降。由于代码的问题使得类似上面这样的情况在程序运行中也出现，就叫做内存泄露（Memory leak）。
以上几个类比可能不很确切，但是引申出了一个结论：并发测试所关注的性能问题就是：系统中的内存泄露、线程控制（锁的问题）和资源争用。
5.1.12 并发测试的特点与工具
并发测试具备如下的几个特点：
（1）并发测试可以是黑盒测试，也可以是白盒测试。测试工程师可以不了解代码实现的细节，通过工具软件实施并发测试找出Web应用的并发问题。开发工程师也可以通过并发测试对自己编写的代码做单元测试。
（2）并发测试可以在项目进行的大部分时候进行。在项目的早期，它可以通过结果大致验证系统总体设计和结构是否合理；在项目编码阶段，它可以发现代码的并发问题；在项目的测试阶段，它可以发现整个系统的并发问题。
【并发测试工具】
除了前文提到，本书后面章节要介绍的综合性能测试软件LoadRunner之外，还有很多专用的并发测试工具，比如在Java平台下有JProfile、JProbe等；在.NET平台下有CHESS、Zing等。
由于并发测试这部分内容程度比较深，完全展开需要更多的是开发知识，而不是测试知识本身，感兴趣的读者可阅读相关的书籍。
5.1.13 配置测试（Configuration Testing）
所谓配置测试（Configuration Testing）方法，是通过对被测系统所处的软、硬件环境进行设置上的调整，来了解其对于系统性能影响的程度，并根据结果发现环境的最优配置组合。这个测试方法主要用于性能的优化，一般用于Web应用正式投入使用前夕和运行当中。
1．配置测试的实例
实际上，在使用电脑的过程中，我们每个人都可能做过这样的测试。比如，使用Windows XP一段时间后，电脑运行速度可能有所减慢。那么我们可能就会上网查询具体变慢的原因，更改一些系统默认的设置，并从实际的效果来验证这些设置的更改是否有效。无效的配置很可能被恢复成默认值。这可以说就是一种配置测试。
2．配置测试的目的
配置测试的目的就在于发现当前修改的这种配置是否能够有效提高Web应用的性能。
还记得有一种比较流行的工具软件：Windows优化大师吗？它实际上就是通过调整不同的系统软、硬件参数，使得我们的Windows运行起来感觉更快。Windows优化大师的软件界面如图5-7所示，可以发现它是由多个配置修改页面组成的。
图5-7 Windows优化大师的界面
3．配置测试实施的时机
那么，什么时候进行配置测试呢？还是与我们平时使用电脑的情况做类比。当我们尚未把所有需要的软件都安装完毕之前，一般是不会做配置测试的，这是因为这段时间即使修改了软、硬件配置、进行了优化，这种配置也可能被新安装的软件在之后覆盖掉，导致优化失效。同样的道理，在Web应用的程序代码没有开发完毕、测试没有基本完成、有关性能的Bug还远远没有被修改的时候，就进行配置测试、性能优化是不合适的。也就是说，配置测试测试的是Web应用所依赖的软、硬件配置对于性能的影响，对于Web应用的代码本身，已经假设它达到了最好的性能。
配置测试所涉及的系统设置要依照Web应用所依赖的环境而定，一般分为软件和硬件两部分：
软件部分：数据库各参数的设置；操作系统各参数的设置；网络带宽的设置等。
硬件部分：硬盘缓存、硬盘运行模式、磁盘阵列的设置等。
5.1.14 耐久度测试（Endurance Testing）
耐久度测试又叫做浸泡测试（Soak Testing），具体方法是令被测试的软件系统、Web应用在大负荷条件下长时间运行，从中发现问题。从这个定义来看，被测软件系统或者Web应用长时间处于测试状态下，用"浸泡"来描述是很恰当的。
耐久度测试所能发现的问题都和被测系统运行时间变长后，一些资源无法释放，导致系统响应时间慢慢变长有关。详细而言，有以下几类：
严重的内存泄露（请见并发测试小节）导致系统内存慢慢不够使用。
数据库连接、数据库游标、应用服务器资源等没有适时释放，导致系统变慢。
被测系统代码中的数据结构不甚健壮或合理，在长时间运行后，对其的增加、删除、修改、查询等速度出现问题。
耐久度测试需要至少关注以下一些指标：CPU使用率、可用内存、内存使用百分比等。通过隔一段时间记录以上的指标，最终形成数据表和相应的图，从中可以找到规律，如图5-8所示，它是在进行一次耐久度测试时，每小时在线用户数量的结果绘图。
图5-8 某网站最近6天每小时在线用户统计
根据图5-8的变化规律，再结合耐久度测试中定时记录的CPU、内存等指标，如果二者规律不符合（比如当在线用户数少的时候，内存占用并没有下降很多），就可以分析出有关资源分配是否正常的结论。
耐久度测试可以在代码开发阶段，也可以在网站版本接近完成、准备上线前，更可以在网站运行当中。因此，根据这几种情况，进行耐久度测试的时间长度有所不同，但总的原则都是测试时间要尽可能地长，这样才有"浸泡"的作用。
代码开发阶段，主要看开发工作的时间安排与发现问题的早晚。如果运行早期就发现了内存泄露问题，可以中断进行代码的修改。
网站版本接近完成的时候，主要看网站上线时间安排，和发现问题的大小。如果上线时间不变，则耐久度测试进行到上线为止。
网站运行当中的耐久度测试，由于要定时记录各种指标，对于网站本身可能影响较大，需要择机进行，比如在长假、长周末等时间。
【耐久度测试与其他测试的区别】
耐久度测试主要考虑的是时间对于系统或者Web应用的影响，因此，它测试的时间要比其他方法，如性能、压力、负载等测试要长得多。另外，它关注的是系统在一个渐进的资源消耗过程中的表现，与压力测试关注一个固定指标下（可以看作一个时间点）系统的表现、负载测试关注最终的那个最大负载（也可以看作一个时间点）、并发测试关注并发操作发生时系统的表现（也可以看作一个时间点）都不同。
5.1.15 可靠性测试（Reliability Testing）
可靠性测试（Reliability Testing）方法实际上就是前一节所说的耐久度测试，只是这个词一般用于测试大型软件，特别是应用于工业、交通等的行业软件。这是因为IT领域的可靠性测试这个词是从制造业"引用"过来的，带有些许传统大工业机器制造的意味。
5.1.16 尖峰冲击测试（Spike Testing）
与可靠性测试类似，尖峰冲击测试这种方法也是从其他行业借鉴而来。在电力工业，有一种冲击测试，用来验证设备在刚刚接通电源时能否经受住涌流的破坏。所谓涌流，通俗地说，就是电源接通瞬间，电流突然变大的现象。涌流过后，电流逐渐恢复到正常的水平。
软件行业的冲击测试，或者说本书称之的尖峰冲击测试，就是为了验证网站在用户突然极具增加的情况下能够正常工作。我们知道，在网站的运行过程中，会经常出现各种各样用户数量的突然增加：
网站开幕时可能导致用户急剧增加，超过预期。
网站公布与用户极为相关的信息，比如高考成绩、录取分数等。
网站投放一些商业促销广告和促销活动，比如季节性降价，春节前大促销。
网站举办酝酿已久的明星访谈、在线销售演出、比赛门票等吸引眼球的活动。
以上这些情况产生的在线用户数量突然增加都会对网站性能产生巨大影响，读者一定记得通过网络购买奥运会门票时，由于用户非常踊跃，导致售票网站无法打开的案例。
在前文我们介绍过负载测试，但实际情况所产生的负载不会老老实实地遵循最大负载的限制，很可能在短时间内就会超过，这时系统并不一定会出现问题。尖峰冲击测试就是为了验证此时网站的应付能力。
如图5-9所示为网站在某一时刻，在线用户突然增大，形成一个尖峰的情况。这也正是尖峰冲击测试中Spike的由来，Spike在英文中是钉子的意思。
【尖峰冲击测试的实施】
尖峰冲击测试一般也是采用工具软件进行自动测试的。在Load Runner中，可以修改之前性能测试的脚本，令某一个时刻用户数突然增大，就可以达到测试的目的。
图5-9 网站某时刻在线用户数突然增大形成尖峰
5.1.17 失败恢复测试（FailOver Testing）
失败恢复测试（Failover Testing）方法对于大中型的Web应用是很重要的，它针对有冗余备份（Redundant Backup）、负载均衡（Load Balance）的系统。这种测试方法用于验证某部分Web应用发生故障时，整个网站是否能够继续让用户使用的能力。
1．用户访问网站可能出现的问题
我们知道，Web应用是存放在服务器的硬盘上供用户访问的，而服务器一般来说都位于IDC（互联网数据中心，Internet Data Center）机房的机架上。用户访问一个Web应用的过程如图5-10所示，为简单起见，这里只列出大的部分。
图5-10 用户访问网站过程的示意图
从图5-10中可以看出，如果一个用户无法访问某个网站，那么可能是：
用户电脑出现了问题。解决方法：维修用户电脑。
网络线路出现了问题。解决办法：更换网线，修正交换机、路由器等设置。
网站服务器出现了问题。解决办法需要在下文进一步讨论。
那么，如何使得网站具有高可用性呢？
【何为高可用性】
所谓高可用性，就是指网站在绝大多数的时间都能够正常显示。网站的设计说明书中经常提到"保证网站99.99%的时间都可用"这样的承诺，这就需要一定的技术保障。但是Web应用比较复杂，软件代码可能有Bug；用户的持续访问和数量的增加也会造成网站较大的负荷，导致硬件可能失效。
可以用以下几种方法来提高网站能正常运转的时间。
主动防御：尽量修改软件代码中的Bug，提高Web应用本身的健壮性，减少网站出问题的机会。
被动防御：在保持现有Web应用代码、服务器配置不变的情况下，通过适当增加服务器的数量、尽量平均分配网站负荷、采用备份的方法提高可用性。在这些措施中，就有冗余备份，负载均衡等方法，我们将在下面的内容中介绍。
2．提高可用性：冗余备份
冗余备份是用两台或者多台服务器构成一个小的服务器场（Server Farm）来承担网站失败恢复工作的。简单地说，一台服务器作为Web应用的主服务器，另一台作为它一模一样的镜像复制。一旦主服务器发生问题，网站无法正常使用，立刻切换到备用服务器，使得用户的访问能够继续。它的结构示意如图5-11所示。
图5-11 冗余备份的简单结构示意图
由于网站所需要的服务器要比图5-10中多出一台到多台，这些服务器中的数据又是互为备份的，因此，我们把这种方式叫做冗余备份。当图5-10中的Web应用服务器发生故障时，系统检测到（有多种方法能检测服务器故障是否发生：比如"心跳"，即HeartBeat，采用定时ping服务器以及其他指标），系统将把连接服务器与外界的线路自动转接到备份服务器上，从而导致用户端浏览网站时基本感觉不到这种变化，极大地减少了维修Web应用服务器所带来的网站停止时间。
这种方法在生活中也经常采用。比如家里的手机、电视、汽车等出了故障，维修点一般会先给一个替代用品来满足维修期间的需要。不同的是，对于网站来说，主服务器和备份服务器的数据要求尽量完全一致。
3．提高可用性：负载均衡
冗余备份看似很完美地解决了服务器故障所带来的影响，但是它增加了设备，增加了成本，而且备份服务器上网站的备份实际上用户也是可以使用的，平时闲置的话有些可惜。因此，人们又采用了负载均衡的办法，在多台同样的服务器之前，加入一个"调度员"，将用户的访问请求尽量平均分配给它们，导致每台服务器的负担下降，因而出问题的几率也就下降了。整个系统的简单示意如图5-12所示。
图5-12 网站服务器的负载均衡
在实际工作中，还有其他一些方法，人们也往往综合使用这些方法来达到网站的7×24（7天，每天24小时，也就是全天候）可访问目标。
【失败恢复测试的意义】
失败恢复测试一般都是人工进行，有点类似奥运会开幕式的彩排。在模拟一台Web服务器出现故障的时候，验证另外的服务器能否接管用户的请求。当然，目前这些工作都已经可以由专用软件、硬件厂商来提供服务，只需要购买就可以了，实际的操作一般不会由测试工程师参与，技术经理和网络管理参与即可。但是，作为一个Web性能测试工程师，没有进行失败恢复测试的意识是不合适的。在以后的章节中，我们将和小白一起编写测试计划，在其中，应该给失败恢复测试留出一定的文字、安排一定的时间。
（未完待续）
相关链接：
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载二)
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载三)
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载四)
孔子说“人无远虑，必有近忧”，用在软件测试上，是什么意思呢？可以这样理解，如果我们不从发生问题的根源上解决问题，认为测试仅仅是找Bug，千方百计找Bug，觉得Bug总是找不完，意识中就会陷入“永无天日”的状态。然而，有小部分测试人员还真希望软件存在多一些问题（唯恐天下不乱），这样可以多提交Bug，认为业绩比没有提交多少Bug肯定要好。无独有偶，有小部分开发人员也把自己犯下的程序错误视为理所当然，甚至还有个别人会戏虐地说“软件如果没有Bug的话，测试人员不就失业了”。这好像在唱一出双簧戏。软件开发的整个过程中，Bug是理所当然要存在的，是这样吗？软件工程中软件危机的根源问题只能通过找到Bug的手段来控制吗？
实际上，我们都很清楚，任何一个Bug的产生都是有来源的，来源包括需求的设计、软件的设计（含代码的编写）等。相对于前端的设计，测试是事后的验证，是一种“堵”漏洞的措施。然而，在实际工作中，时间与成本并不允许我们去堵住所有的Bug。日本质量大师田口玄一说得好“质量是设计出来的，而不是测试出来的”。如果我们能变被动为主动，在设计之前，就做好设计的防患措施，为设计高质量的软件打下坚实的基础，这便是本节打算向读者介绍的测试的第三重境界：挑战零缺陷。
缺陷的防与堵
几乎在每次面试测试工程师时，笔者都会问一个这样的问题：“你所负责测试过的模块，是否存在漏测的情况”，几乎每个应聘者都回答说“有”。面对复杂的软件，纷繁复杂的运行环境，在有限时间内进行的测试活动，做到真正的零Bug是 不可能的，也是不现实的。但这些都不是理由，所有的测试活动是有目的的商业活动，每个公司有自己测试通过的一套标准或原则。虽然漏测不可避免，但并不是说 漏测是一种正常现象或应该的现象，出现的漏测问题如果超出公司所能接受的原则，就属于不正常的现象，很有必要进行漏测分析。进行漏测分析活动（需要特别注 意的是它绝不是对漏测人员的批斗会），它的主要目的是通过分析过去的教训，找出问题的根源，分析测试中哪个环节工作存在缺失，以拿出规避的可操作的措施出 来。
测试人员进行漏测分析时，免不了对问题进行追本溯源。软件是由开发人员设计出来的，所以漏测分析活动少不了开发人员在场，甚至有时还会涉及需求设计人员。关于漏测分析的追本溯源，这里有一个关于开发与测试之间的工作关系像修筑堤坝一样的有趣比喻，如图2？11所示。开发人员设计软件就像修筑一道堤坝，如果堤坝在结构上存在问题，当洪水冲击时，可能不只是局部的泄漏，而是直接的决堤，犹如软件的崩溃。高高的堤坝，难免会存在漏水的小洞，或渗水的小孔，就好像软件中存在的小Bug。越是在堤坝基部的漏水或渗水问题越难发现，解决的代价也越大。
在设计时要把结构建牢，不存在漏洞当然更好，这是一种防范。如果超越防范界线，把设计带出的大洞小孔遗留到测试环节，它只好拿着各种放大镜（使用各种方法）来检测，以网罗各种深深浅浅、大大小小的问题，最后通过“打补丁”的方式，堵住堤坝上的“百孔千疮”。
在对缺陷的防与堵方面，测试是发现问题的中间角色，告诉开发人员哪里漏水或渗水了。防与堵的工作是由建堤者来做的。当然，防是主动的，堵是被动的，主动变为被动后，中间经历了资源与时间的投入，诚然即使是同一个Bug，它们的代价也是完全不一样的。这种堵越在后面，影响越大，代价也就越大，如表2-6所示（摘自《代码大全》）是一个根据缺陷出现的阶段来增加测试成本的例子。
表2-6 根据缺陷的引入和检测时间，修正同一缺陷所需的平均成本
引 入 时 间 | 需 求 | 体 系 结 构 | 建 设 | 系 统 测 试 | 发 布 之 后 |
需求 | 1 | 3 | 5～10 | 10 | 10～100 |
体系结构 | -- | 1 | 10 | 15 | 25～100 |
建设 | -- | -- | 1 | 1 | 10～25 |
如表2-6所示为在需求阶段引入的一个缺陷。如果立即发现了此问题，修改成本只需要1美元，但如果在系统测试阶段发现它，修改成本就增加了10倍。更为严重的是，如果在版本发布后用户端发现了此问题，则需付出10倍以上甚至是100倍的代价。缺陷在系统中的时间越长，解决它的代价就越大，因为时间越长，开发与测试人员修改的成本就越高，还将影响大面积的用户端升级。
相关链接：
软件测试的第一重境界：围着Bug转
软件测试的第二重境界：站在Bug之上
第一计-瞒天过海
【释义】
防备得周全时，更容易麻痹大意；习以为常的事，也常会失去警戒。秘密常潜藏在公开的事物里，并非存在于公开暴露的事物之外。公开暴露的事物发展到极端，就形成了最隐秘的潜藏状态。
在我们测试过程中，漫天过海是很常用的一种计谋。
很多错误，往往都是隐含在我们已经习惯了正确的区域，这也是为什么，我们在不停的在做让人觉得很枯燥无味和产出比很低的回归测试的原因。
很多测试团队，都是习惯了使用已经存在的功能测试用例来进行回归测试，导致很多bug在被僵化的测试过程所遗漏。所以，进行更加有效的回归测试必须要去探索那些我们遗漏的阴影区域。而如何去探索这些区域呢，一般可以考虑的方法有如下几个：
1、在功能测试完毕后，对bug进行分析，得出bug的分布图和原因。然后在没有发现bug，但是被主要bug趋势范围影响到的功能区域，加强回归测试的深度。
2、在回归测试完毕后，对功能区域进行评价，对于发现问题较多的功能区域进行更加宽泛的广度优先的二次回归。
3、定期的评审回归测试用例，对测试集合进行调整，不要只针对新功能直接影响的，而是那些在底层更迭模块所影响的应用层进行更多的关注。
另外一个大范围使用瞒天过海的测试范畴就是安全性测试。
在安全性测试中，我们大部分的方法就是设置一个虚假的信息，企图访问系统，从而给系统带来损害。
比如我们使用jmeter去获得一个特定角色的访问过程，该角色的权限为低级。我们在测试时，人为的修改该角色的权限，通过jmeter发起请求，看是否能够成功的骗过登录策略进入系统。
还有就是我们认为的修改数据库中的某条数据，然后进行下束流程，看系统是否在流程进行过程中对数据完整性进行有效的校验。
总之，瞒天过海在测试领域里，就是要验证那些隐藏的流程和数据处理过程。这些流程和过程在我们用户前端是被屏蔽或者隐藏掉的。虽然正向的和反向的操作都不会出现问题。但是，除了正向和反向的操作这些已经被开发刻意处理过的范围之外，仍然会潜藏一些常规方法无法探知的缺陷。这些缺陷只有通过非常规的测试手段，主动的攻击才会被表露出来，从而获得更深层次的质量保障。
第二计-围魏救赵
【释义】
进攻兵力集中、实力强大的敌军，不如使强大的敌军分散减弱了再攻击。攻击敌军的强盛部位，不如攻击敌军的薄弱部份来得有效。
围魏救赵其实说起来很简单，大部分人也都试用过。那就是把要测试的对象不断的拆分，一直到最simple的程度。从而避免因为测试一个过于复杂的对象导致bug的遗漏。
这个过程其实就是一个break down的过程。简而言之，就是对一个对象的测试用例进行分层的过程。
我们在测试用例开发过程中，一定要引入分层的概念，这样的好处不但利于我们在各个测试阶段simple的工作从而准确定位bug，而且有利于我们在需求更新时，更加快捷有效的更新我们的测试用例。
一般测试用例分层的策略就是：
1、UI层，只考虑GUI的范畴。
2、Field层，考虑的是各个element本身自有的属性逻辑。
3、Functional层，考虑的是单个或者多个element的实现的业务逻辑流和或者功能。
4、Business Rule，考虑的是上下文，和直接间接被影响的功能区域。
5、安全测试，考虑的是相关的安全策略。
总之，所谓的围魏救赵，目的就是通过将测试对象细化，降低测试的复杂度，有利于我们通过一点来击破整个屏蔽，减少测试的成本。
第三计-借刀杀人
【释义】
敌人的情况已经明了，友方的态度尚未确定。利用友方的力量去消灭敌人，自己不需要付出什么力量
如何才能降低测试成本呢，这是每个测试管理者最大的问题。在传统测试过程中，一般是开发将代码开发完毕后，移交给测试人员进行测试。一般开发人员会进行单元测试和集成测试。
然而，在现在敏捷开发的过程中，开发人员也必须进行一些功能测试，尤其是自动化测试的大量引入，很多人都觉得开发人员必将取代测试人员的角色，从而使得测试人员这个角色逐渐的消亡。
其实这是一个很片面的想法。在敏捷开发过程中，测试角色不是被削弱或者是被取代，而是更加的被强化，测试驱动开发测试敏捷开发的真髓。
在测试驱动开发的敏捷开发过程中，测试人员和开发人员同时对user story进行分析，开发人员根据其进行代码实现，而测试人员是通过书写相关的测试场景来验证开发人员实现的质量。
也就是说，测试人员不再是去根据需求和设计文档在后期进行代码实现度的验证，而是转变为依据或者是贴合最终用户来控制开发的方向和质量。
验证标准也从了是否完成了预期的设计变成了是否满足了用户的需求。
所以，借刀杀人已经成为普遍的开发策略。核心的想法就是，开发人员在做完常规的单元测试和模块测试之后，必须依据测试用例对代码进行功能测试，只有那些完成了p1&p2测试用例的代码，才会提交给测试人员进行测试。
这样的好处是：
1、在开发阶段就能评审代码是否符合用户需求，这是敏捷的灵魂。
2、在测试阶段减少大量因为P1&P2导致的等待时间和重复测试率。
3、开发测试的用例可以是手工测试用例或者自动化测试脚本，这样的话加强了测试人员和开发人员的交互，不再是单纯的质量保证，而是主动质量控制。
所以，借刀杀人的最大核心就是，那些测试用例需要开发人员来执行。这就是测试用例要分层的原因所在，只有分层的测试用例，才能很简单的提取一个测试集合用来执行借刀杀人这个计谋。
第四计-以逸待劳
【释义】
意谓困敌可用积极防御，逐渐消耗敌人的有生力量，使之由强变弱，而我因势利导又可使自己变被动为主动，不一定要用直接进攻的方法，同样可以制胜。
在测试过程中，以逸待劳是对测试计划的一个有力的支撑。
我们在指定测试计划时，就需要根据具体的测试范围，测试资源，测试进度表等进行高效率的设定。
那些需要重点测试， 那些需要回归，那些需要特殊的工具，那些需要特殊的数据集，那些需要特殊的测试环境，测试对象的前后依赖性，开发的进度等等都是影响我们制定测试计划的各种重要因素。
通过测试计划的制定，我们能够在开发阶段有条不紊的进行测试的准备，从而达到并发的执行效率，而不是传统测试中，只有一个简单的时间线，所有的测试都是在要执行之前，才进行更详细的分析。
而以逸待劳就是敏捷测试的另一个优点，在你根据user story进行测试场景的设计时，就已经按照执行时如何更加有效的利用资源进行设计了，而不是传统的那种只是针对use case中包含的单一功能区域进行场景设计。
以逸待劳的核心就是提前准备而不是需要时才动手。基本上减去了测试人员在测试用例开发完毕后等待代码前这段无所事事的idle time。
第五计-趁火打劫
【释义】
本指趁人家失火的时候去抢东西。现比喻乘人之危，捞一把。
趁火打劫基本上大家都已经或多或少的用过了。
在测试过程时，我们经常能发现一个bug之后，然后在周围发现很多bug。这些bug有些是因为原生bug引起的，有些是因为修复bug导致的新bug。
所以趁火打劫的测试思想就是，一旦你发现了一个bug，就要着重的在bug的直接影响功能区域，间接影响功能区域进行更deep的挖掘性测试，从而能够更加有效的获得产品的缺陷。
只有通过趁火打劫，我们才能更加深层次的挖掘出真正的缺陷，如果仅仅是发现一个bug，根据其表象提交之后就置之不理，反正会在后期的过程中出现更大的隐藏缺陷，从而导致整体进度的延迟。
所以，趁火打劫是手段，目的是那些中间过程，临时数据集，被间接调用，或者底层代码的缺陷。
第六计-声东击西
【释义】
此计是运用“坤下兑上”之卦象的象理，喻“敌志乱萃”而造成了错失丛杂、危机四伏的处境，我则要抓住敌人这不能自控的混乱之势，机动灵活地运用时东时西，似打似离，不攻而示它以攻，欲攻而又示之以不攻等战术，进一步造成敌人的错觉，出其不意地一举夺胜。
一般常规的测试数据设计，都是从黑盒角度进行考虑，也就是正向数据集和反向数据集。这样的话，正向数据集是保证的正确的流程和功能。反向数据集是保证了数据验证策略的完整性。
但是，如果仅仅这样，只能说我们还是从正面的效应去考虑产品的特性。
而声东击西，就是要我们不仅仅从应用层去设计测试数据，还要从逻辑层甚至驱动层去设计测试数据。我们不是单单的验证一头一尾的数据完整性，我们还要去主动验证中间数据的有效性。通过直接修改数据来实现这一个效果。
另外，声东击西在性能测试里面也是一个广泛的应用，我们在无法直接测试一个性能点时，通过对他直接影响或者间接影响的功能点进行测试，从而侧面了解该功能点的性能。
最常见的一个示例就是我们无法验证一个用户密码验证过程的性能，但是我们通过大量的有效登录和无效请求的混合用户登录集合，我们能间接的获得验证的效率和瓶颈。
第七计-无中生有
【释义】
运用假象欺骗对方，但并非一假到底，而是让对方把受骗的假象当成真象。
在自动化测试过程中，有时候我们需要测试的模块需要一些未开发完毕的模块的支持，所以需要我们static的提供一些方法或者数据。这种书写测试用的假模块是开发常用的方法。很典型的无中生有的计策应用。
实际上，我们在手工测试中，也可以使用这种计谋，最常见的就是是我们需要一个测试数据时，无法直接获得，那么我们就可以在数据库中直接添加我们的需要的数据。
扩展来看，这种方法在build tesing中最有效。我们现在都是自动code build 然后自动部署，自动测试，并发送一份报告，包含的是一些major path的测试用例的测试结果。从而使得我们对该版本的code有个直接的印象，从而判断是否引入我们的测试环境中。
在这个过程中使用无中生有的方法就是我们会有一个测试数据集存在于一个数据库备份中。当新的build部署完毕后，restore这个backup的db，能够迅速有效的进行测试，而不浪费时间在数据准备上。
总之，这是个应用很广泛的计谋。
第八计-暗度陈仓
【释义】
此计是利用敌人被我“示之以动”的迷惑手段所蒙蔽，而我即乘虚而入，以达军事上的出奇制胜。
在测试过程中，如何使用奇袭呢。在性能测试和安全测试中，经常会使用一些欺骗系统的手段来进行测试。
实际上在功能测试时，也可以。那些写伪代码的方法都很通俗了。改数据库也是很老套的使用了。那么在手工测试中，能否使用呢？
答案是肯定的，我们来举一个示例：
我们在开发测试用例时，每个人都负责自己的功能区域，往往在这些测试用例中，有很多overlap的场景，如果都在各自的测试中包含，很容易造成资源的浪费，而且很容易出现miss scenario的情况。
这时候利用暗渡陈仓的方法就是我们对那些数据依赖比较高的测试用例集中在初始功能模块的测试用例中书写。对于逻辑依赖比较高的测试用例，集中在结束功能模块用例中书写。
第九计-隔岸观火
【释义】
此指敌方内部矛盾激化，以致公开地表现出多方面秩序混乱、倾轧。
隔岸观火的应用也是很典型的。
一种就是我们在手工测试过程中，直接修改数据库，植入一批错误的数据，从而判断系统的处理能力。
另外一种就是在性能测试中，不断的对某些冲突的资源占用过程进行增量，从而获得性能评价。
甚至从广义的说，stress test 就是一个隔岸观火的最大用处。我们通过压垮系统之后，从而使得系统出现错误频出的状态，然后我们分析这些混乱的原因，从而进行性能的调优。
第十计-笑里藏刀
【释义】
比喻外表和气而内心阴险。
在测试过程中，使用笑里藏刀的主要有以下几种情况：
1、在稳定性测试时，进行一些破坏稳定性的操作
2、在压力测试时，定期的定量的发送一些错误的请求，来衡量系统的处理能力
3、安全测试中，发送一些带壳的请求，杀毒软件的测试，这是一个重点。
一般来说，笑里藏刀的主要作用就是对系统进行一些在预先设定的错误处理之外的错误请求。或者主动攻击。
版权声明：本文出自 gigobin 的51Testing软件测试博客：http://www.51testing.com/?26810
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
摘要: 前序： Thread-Per-Message Pattern，是一种对于每个命令或请求，都分配一个线程，由这个线程执行工作。它将“委托消息的一端”和“执行消息的一端”用两个不同的线程来实现。该线程模式主要包括三个部分： 1、Request参与者（委托人），也就是消息发送端或者命令请求端 2、Host参与者，接受消息的请求，负责为每个消息分配一个...
阅读全文
关于开会大家应该都不陌生，而且应该有不少人被过度频繁的会议“伤过”，甚至”谈会色变“ 。当一个组织的人员较多，结构复杂时这个问题会更加突出。如果开发人员/测试人员参加会议过多，会导致工作打断严重，直接影响到团队工作效率。如果管理人员参加会议过多，就会导致管理人员离开所负责的管辖范围时间较长，不能及时响应事情，从而导致团队整体管理效率变低，典型表现是很多事情没有及时处理、开始积压。
当然会议是需要的，主要是我们要总结出一套高效的方法。下面分享一些总结，有兴趣的同事可以一起探讨。
第一，确认会议类型及目的。我认为在我们公司的研发体系里以会议目的划分，会议大体可以分为以下6种：
1、团队建设：激励团队，培养员工的团队意识，让每个参与人员了解共同的目标，树立全局观念，无形中能够帮助团队减少协调成本。例如：版本项目周会。
2、报告绩效：向上级管理层汇告版本当前绩效情况，并且根据需要可以获得适当的资源支持，例如：RDM的项目分析会。
3、平级沟通：针对问题通过会议讨论形成解决方法或是达成处理协议。例如：开发和测试周会，跨部门合作会议。
4、信息传达：将信息传达出来，让相关人得到信息并理解信息，以方便进行下一阶段的工作。例如：新流程培训会议，经验分享会议。
5、创意开发：针对某一个问题的解决方案或是某个方向的创新主题进行讨论。
6、评审会议：技术方案/需求文档评审，疑难问题讨论等。
确定好会议类型及目标之后才能选定出需要讨论哪些内容，汇报哪些信息，以何种方式组织。这里举两个示例：
示例一：一个项目组对RDM做绩效汇报（项目分析会）。我们首先确定会议目标为：
a、向RDM提供版本总体计划情况，当前进展，当前存在风险及计划应对措施，趋势预测等。
b、申请关键资源支持，因为RDM听过完整汇报时，对版本有了比较系统的判断，此时如果确实需要资源协助，比较容易得到批准。
确定目标后，我们就可以发现开发和测试在这里是被作为一个团队看待的，因此在这个会议过程中开发和测试的意见应该是一致的，并且汇报的内容不能重复，但可以各有侧重。因此会议前开发和测试应该进行明确的汇报分工，各自总结完后，内部讨论得出一致结论。基于这样定位而组织的项目分析会，就会非常高效，并且能够在短时间内将版本整体情况展现出来，同时也促进了开发和测试内部一次完整性总结。而如果没有这些前期工作，项目分析会过程中，开发和测试意见就可能非常不符，甚至进行争吵，更严重的是发生互相责怪，推卸责任的情况。
第二，开有准备的会议。有准备的会议需具备以下三个特点：
1、有清晰的会议历程及会议预期
例如：大多数开发和测试的例行沟通会议，是以明确问题及达成协议为主，而不是解决具体的某个问题，如果过于深入会导致时间浪费，更严重的是随意决策。
2、选择合适的人参与
会议召开前需确定好哪些人要必须要出席，哪些人得到讨论结果告知即可。将会议控制在必要范围里的好处在于，避免会议浪费其他人员时间，同时保证会议的发言质量。
3、选择合适的时机
合适的时机是指要评估与会人员的时间繁忙程度、解决问题的条件是否成熟，这个时间开会的效果如何？例如：项目进度非常紧张的情况下，项目组每周举行耗时很长的个人知识及读书经验分享是不合事宜的。
第三，议而有决，决而有行，行而有果。从结果导向来看，会议都是基于某种目标而召开的，因此达成预定目标是非常重要的，会议过程中，组织者要进行有效的时间控制，出现跑题情况时要及时引导纠正，防止参会人员天马星空或过于深入细节，浪费大量时间。这个过程可以简称为议而有决。决而有行是指，会议讨论出的决策要形成任务分解，并落实责任人。行而有果是指，已经分解的任务要进行跟踪，产出效果。第三点总结起来比较简单，但是往往是我们最难以落实的地方，所以经常会出现诸如“这个问题，我们好像上次讨论过”的这类情况。
其他一些小技巧罗列如下：
1、大会之前通常要有小会，从而达成高效
2、会议开始前先讲解会议历程及预期
3、会议上以明确问题、达成协议为主，不深入问题讨论
4、会议上的决策直接指派落实责任人
5、会议记录要在24小时内发出，最晚48小时之内
6、对于例行会议，可以收集参会人员的会议质量反馈，进行持续改进
第5章 Web性能测试方法
良好的开始是成功的一半。小白所在公司网站的代码编写的差不多了，安放服务器的机房也已经找好，只要等第4章选购的服务器正式到位，就可以上机架、部署测试版本网站进行试运行了。离部署测试版的日子还有一段时间，小白对现在这段短暂的空闲，做了如下的安排：
首先要熟悉性能测试的几种方法。
在第4章CPU和硬盘的基础上，熟悉常见操作系统的性能计数器特点，并在自己的电脑上进行一次手工的性能测试。
熟悉常用的几种性能测试软件，听说有Load Runner等，从中选择一个比较好的，毕竟这也是部门经理在第4章开头布置的任务之一。
这3点内容将分别在从本章开始的第5章、第6章和第7章中讲述。现在就开始介绍Web性能测试的一些方法。
5.1 Web性能测试的目的与方法
本节首先介绍测试的目的，然后会介绍最常见的9种Web性能测试的方法，希望读者通过这些方法，对性能测试有深度的认识。
5.1.1 Web性能测试的目的
进行Web性能测试的目的很简单：
获得Web应用的性能表现情况。
发现并验证、修改Web应用中影响性能的Bug。
为网站性能优化提供数据参考。
实际所做的一切测试工作都要围绕这3个目的来进行，这样才不会在出现这样或那样困难的时候迷失方向，导致资源浪费。
5.1.2 Web性能测试方法的先决条件
对于性能测试方法，在某种意义上说，就是性能测试的分类。不同的性能测试分类，决定了需要采用不同的性能测试方法。Web性能测试也是如此。
不过在介绍具体的分类或者方法之前，有必要强调一下进行Web性能测试的先决条件。其实，从前面的章节，我们已经能够发现，进行Web性能测试的先决条件有这样几条：
一个稳定的Web应用版本。该版本必须与投入生产环境的版本极其类似。这一点的原因在前文也介绍过，对一个最终不会上线运行的版本，或者功能没有完成的版本进行性能测试是没有多大意义的，除非为了演练性能测试方法本身。
性能测试所处的测试环境，必须独立于开发环境，并且尽量类似于实际生产环境。这一点也很重要，测试环境必须是可比较的，大致拥有相同的参照物（比如CPU、硬盘速度等），这样的测试结果才更有参考价值。
当然，小白在今后这3章所做的性能测试，是为了在个人电脑上方便快速地了解性能测试方法，熟悉性能测试软件，并不打算将测试报告发送出去形成结果。对于小白和我们一般的初学者，这不失是一个好的学习方法。但是，在真正的性能测试工作中，对于上面的两个Web性能测试（也可以推广到所有的软件性能测试上面），一定要记牢。
下面将介绍Web性能测试方法的具体内容。
5.1.3 Web性能测试的详细分类
在第2章中曾粗略地讲到性能测试包含性能测试方法（狭义的）、压力测试等，现在可以将绝大部分文档中提到的众多分类列举出来了，它们是如下9种：
性能测试（Performance Testing）；
压力测试（Stress Testing）；
负载测试（Load Testing）；
并发测试（Concurrency Testing）；
配置测试（Configuration Testing）；
耐久度测试（Endurance Testing）；
可靠性测试（Reliability Testing）；
尖峰冲击测试（Spike Testing）；
失败恢复测试（Failover Testing）。
看起来分类很多，但它们实际上都是为了性能测试的目的：考察应用对于系统性能的影响状况。因此，它们的区别只在于考察系统性能的角度不同。角度决定方法，这正是本节开始时将性能测试方法和性能测试分类基本划等号的原因。
5.1.4 性能测试（Performance Testing）
在介绍性能测试具体方法之前，首先说明一下性能测试（总称）和性能测试（方法）的区别。我们也分别把它们叫做广义性能测试和狭义性能测试。
【广义性能测试与狭义性能测试】
广义性能测试包括前述所有分类或方法，以考察Web应用对于系统性能影响状况为目的的测试活动。而狭义性能测试则是其中的一个小分类，为了区别广义性能测试中的其他分类。这种测试也是广义性能测试中最基本的方法之一。利用第一章所讲过的维恩图，广义性能测试和狭义性能测试之间的关系如图5-1所示。
图5-1 广义狭义性能测试的包含关系
听起来有些混淆，但对于我们要从事实际工作的人来说，名词并不重要，只需要知道有性能测试这样的总称（广义），还有性能测试这样的方法（狭义）即可。在看相关参考文献的时候，根据上下文一般能很容易判断出当前所指的性能测试是狭义还是广义。
本书中凡是"Web性能测试"这样的字眼，都是指的广义性能测试，特此说明。
【性能测试】
性能测试（英文名称也是Performance Testing）是这样一种方法：它通过模拟实际生产环境中运行的软件平均业务量，测试系统的性能是否满足设计说明书中的性能要求。性能测试方法在所有前述9种方法中是一种最基本、最常见的测试方法。这就是说，它是实施性能测试所必须进行的一种方法。
5.1.5 小白的第一次性能测试
为了尽快熟悉这种方法，小白决定利用自己电脑和公司网站的测试版本来做一次手工性能测试的实践。
一般来说，在网站尚未上线的期间内，网站的技术部门都会维护一个或几个网站的测试版本，方便开发工程师和测试工程师开展工作。即便是网站上线以后，也会继续维护这样的网站，以方便网站每日更新时的调试，待没有问题后再正式上传到生产环境中。这种结构如图5-2所示。
图5-2 网站正式版本与测试版本关系示意
对于小白的第一次性能测试，该如何选择测试所针对的网站版本呢？有两点需要考虑：
由于网站正式版本尚未发布，目前还没有正式版本可供选择。
即使正式版本发布也不能直接使用它来测试（因为这样会影响用户的使用）。
根据以上两点，选择图5-2中的稳定测试版本。
截至目前为止，小白所知道的仅仅是打开网站的响应时间，所以他想从这个时间入手，来评估一下网站测试版本的性能。他是这样进行测试的：
打开浏览器，输入网站测试版本的网址，按下Enter键，并记录此时的机器时间。
在网站全部打开后再记录一次当前机器时间。
两者相减，得到一个时间间隔。
重复多次，最后计算平均时间间隔。
对比网站的设计说明书，在那里一般都会有以响应时间为标准的性能要求。
根据两者数值的比较，决定网站测试版本的性能好坏。
【有关时间的记录】
在性能测试过程中，往往免不了进行当前时间的记录，或者计算两个时间的差值。由于Windows系统任务栏中的时间数字较小，读者可以在互联网中寻找一些显示桌面时钟的免费软件（显示时间最好可以包含秒数以达到精度要求）。当然，这样的时间记录是依赖于肉眼，精度依然不够高。可以通过编程的方法来获得更精确的时间。
虽然小白所列出的上述测试过程看起来与用户浏览网站没有什么不同，而且，也看不到使用哪些高级的工具软件，但它确实是一次人工的性能测试。性能测试真的都是这么简单吗？小白非常好学，进而思考了下列几个问题。
5.1.6 小白的思考
在第3章中我们已经知道响应时间，并且知道用户所感觉的响应时间并不很准确。那么，小白这次测试应用了计算机时间等"高科技"计时装备，是否就意味着准确呢？
1．响应时间的问题
其实，对于感觉和记时两种方法，响应时间数值都是差不多的。那么，访问Web应用，多长的响应时间说明性能比较好呢？实际上依赖于几条标准。
软件设计说明书中的标准：根据用户的需求，一般都会列出。
不成文的习惯标准：如果在设计说明书中没有列出，那么可以参考国外的业内公认标准，即3/5/10原则。
在3秒钟之内，页面给予用户响应并有所显示被认为是"不错的"。
在3～5秒钟内，页面给予用户响应并有所显示被认为是"好的"。
而5～10秒钟是可以"勉强接受的"。
超过10秒钟就有点让人不耐烦了，用户很可能不会继续等待下去。
在尽可能合理的情况下，响应时间应该越快越好。
另外，响应时间包含了网络传输数据的时间、DNS记录查找时间和真正由网站服务器处理的时间，因此，遇到时间间隔很长的情况时，首先要排除前两个时间的影响。
另外，还有很重要的两点不能忽略：
小白只是以一个用户的身份去访问网站的测试版本，而网站一旦投入使用，真实情况是会有上万人同时访问它，那么响应时间还会有现在这么好吗？
小白是在公司内部进行测试的，要知道公司内部的局域网一般都是百兆、千兆网，速度非常快；如果换到家里，用ADSL之类的上网条件，响应时间还会如此快吗？
这几个问题都说明小白的这次性能测试确实欠缺很多因素。不过，这正是我们在下面的章节要学习的。
2．测试场所和指标的问题
小白在进行测试的时候，记录的是自己电脑上的时间间隔，从它数值的大小来间接判断服务器端性能的好坏。那么，能不能直接获得服务器端的性能数据，岂不是更加精确吗？
是的，完全可以。响应时间所带给人的只是性能好坏的大概印象，如果要更加专业的测试性能，需要获取服务器端的指标数据，我们管这些指标叫做性能计数器（Performance Counter），在第6章，我们将重点介绍它们的单个含义以及获取方法。
综上所述，小白基于目前理解的第一次性能测试有了结果，虽然过程远远不够，但也让我们体会到了性能测试所关注的要点，进行的大致过程。简单地说，Web应用的性能测试方法，就是通过模拟若干用户对于网站的访问，获得性能计数器和其他指标的数据，再分析它们以进行性能评估，使得关注性能测试的各方对系统性能有基本的认识。
5.1.7 压力测试（Stress Testing）
相对于前面性能测试方法的普通，压力测试（Stress Testing）方法可以说走了一个极端。它测试Web应用在事先规定的某种饱和状态下，比如CPU处于75%利用率的情况下，系统是否还具备处理业务的能力，或者系统会发生什么样的状况（出现错误？系统宕机？等）。
一句话，压力测试是考验一个系统的抗压能力的：在当前比较大的压力下，它能否承受得住。压力测试的目的是为了测试Web应用的稳定性。
【压力测试与体操比赛】
在体育比赛场上我们可以看到生活中的压力测试，例如体操比赛中的规定动作环节。场上选手在比赛时，其动作组合必须包含组委会所设定的所有规定动作，如图5-3所示的经典规定动作--托马斯全旋。通过在这样的条件下比赛，裁判来考察运动员的完成质量，由于动作难度系数基本一致，重点将是完成质量的稳定性。通过这个类比，压力测试就很好理解了。
图5-3 类似压力测试的体操规定动作比赛（图中动作为托马斯全旋）
压力测试方法有如下的两个特点：
（1）压力测试方法的目的是测试系统（本书中为Web应用）的稳定性。人们对很多软件系统都有这样一个经验：当系统处于较大压力的时候，如果还能够维持正常工作，那么，就能说明它在压力不大的一般条件下，具有长时间正常工作的能力。从这里可以看出，压力测试方法有一点“一叶知秋”、“以小见大”的含义在其中。
（2）压力测试方法的具体操作过程是通过对系统施加负荷（模拟用户对Web应用的访问等），使系统的资源占用保持在一个事先约定的水平（比如前文所提到的CPU占用率75%），来检验此时系统的表现。测试的重点在于系统对于用户的响应时间变化、系统是否出现错误甚至崩溃等。
5.1.8 负载测试（Stress Testing）简介
在实际工作中，负载测试方法和压力测试方法往往被放在一起谈论，因此很容易混淆，其实它们的区别是很明显的。
【负载测试方法】
负载测试（Load Testing）方法通过在被测试系统上不断增加负荷，直到事先选定的性能指标（比如响应时间），变为不可接受或系统的某类资源使用已经达到饱和状态。负载测试方法实际就是一个不断加压，直到找到系统不可用临界点的过程，形象地说，那一点正是“强弩之末”。
【负载测试方法与举重比赛】
在5.1.7节我们把压力测试和体操比赛的规定动作相类比，在这里我们将负载测试方法类比为举重比赛，如图5-4所示。在比赛中，选手不断地增加重量，挑战自己的极限，直到杠铃加到某一个重量时，3次试举都失败。这一重量就是举重比赛的最终结果。
图5-4 举重比赛与负载测试有相同之处
通过负载测试方法，我们可以发现系统的处理极限点在哪里。
5.1.9 负载测试的特点
负载测试方法有如下几个特点。
（1）它的主要目的在于找到系统处理能力的极限，为系统进一步优化做参考。另外，这种测试也可以用来比较不同的优化方法对于性能极限的提升，因此也可以称之为可扩展性测试（Scalability Testing）。这个名词可以用图5-5清晰地表述出来。
在图5-5中，2条曲线分别代表两种优化方法经历负载测试的结果。A方法的性能极限在A点，B方法的性能极限在B点。根据负载测试的定义，比A、B两点值小的部分都是系统的安全运行区间。由于B的数值要大于A，说明采用B方法优化，系统的可扩展性提高了。
图5-5 负载测试用于优化方法的比较：B好于A
（2）负载测试方法的操作是一个不断加压的过程。负载测试方法是一个"性能指标记录--增加负荷"的操作循环，直到预定被关注的性能指标不再令人满意。这个极限点在测试结果中的表示类似这样的形式："在给定条件下当前Web应用将最多允许10000个并发用户访问"、"在给定条件下当前Web应用最多能够在1分钟内处理1000次用户对数据库的修改"等。常见的在负载测试方法中被关注的性能指标包括：Web应用的响应时间、Web服务器平均CPU利用率等，它们的具体数值需要根据实际情况来调整。
（3）负载测试方法要考虑被测Web应用的实际业务负荷量与正确的使用场景，以保证测试结果具有参考价值。
【实战演练：教训】
在这方面，笔者的同事曾经有一个教训。有一个网站，可以通过Web直接访问，也可以通过RSS进行订阅。在网站发布之前，网站技术部门的所有工程师都认为绝大部分用户都是通过Web来访问的，因此，在时间紧迫的情况下，重点测试了Web访问的性能，对于RSS相关代码测试的就很少。结果在网站上线之后，他们惊奇地发现，大部分用户访问都是通过RSS来完成的，因为负载测试做的很简略，结果每过多久服务器就被拖的几乎无法访问了。可见，对于负载测试，乃至整个性能测试而言，模拟真实的应用场景是多么的关键。
（未完待续）
相关链接：
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载一)
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载二)
捉虫记--大容量Web应用性能测试与LoadRunner实战(连载三)
测试的价值仅仅是发现Bug吗？通过“站在Bug之上”测试第二重境界的介绍，希望能帮助读者正确理解测试的真正价值是什么，在实际工作中如何操作以体现 这些价值。不同的理念，将会牵引着测试人员朝不同的方向迈进，“站在Bug之上”可以拓宽测试人员的视野，找到更多可以充分体现测试价值的测试链，让测试 人员为项目的成功做出更大的贡献，从而带来更宽范围的测试成功。
测试的价值不仅仅是发现Bug
一提到测试，大家马上会想到Bug。测试仅仅就是为了发现Bug吗？这是值得我们思考的问题。
从软件测试最基本的定义出发，早在1979年J. Myers在《软件测试的艺术》一书中提到：
● 软件测试的目的就是尽早发现Bug。
● 一个成功的测试就是发现了至今为止尚未发现的Bug的测试。
总之，测试就是为了发现Bug，测试所做的工作无一不是围绕Bug而展开，如图2-8所示。测试发现Bug越多，测试人员越自豪，越有成就感，这个观点已几乎根深蒂固地扎在了我们的心里，测试除了发现Bug真没其他事情可做吗？
发现了很多Bug，测试人员高兴了，但老板肯定是不高兴的。很明显的道理，为了解决这些Bug，他必须付出更多的成本，包括开发人员与测试人员的工资，更 严重的还可能影响产品交付市场的时间。商场如战场，时间就是金钱，时间能给产品带来更多的市场空间，为企业赢得更多的利润。理解这些商业知识能帮助我们做 正确的事，并且正确地做事。认识到这一点后，相信测试朋友就不会再为某个Bug还没有解决，版本却上市而耿耿于怀了。测试人员应该跳出仅发现Bug就沾沾 自喜的圈子，看到项目整体，站在公司的角度想测试可以做什么。只有项目成功了，公司才能获得利润，最终达到员工与公司双赢的目标。
质量、成本、时间是项目管理的三要素。它们像三足鼎立，稳如泰山，即质量好、成本低、工期短，这样的项目当然是项目经理求之不得的。但它们又是矛盾地存在 着，形象地看，它们犹如一个等边三角形，如图2-9所示。对其中的任何一个元素处理不当，三元素的三角关系就会变得不稳定，将给项目的成功带来风险。
软件测试团队是整个项目团队大家庭中的成员之一，在软件质量上把关，要尽可能早、尽可能多地发现Bug。这也是软件测试成立的根本，是质量上能给项目做出 贡献的地方。那么在成本与时间的控制上，测试可以做些什么，要如何做呢？也就是前面提到的测试如何配合项目的成功做正确的事，并且正确地做事。小贴士：
做正确的事与正确地做事
做正确的事出发点是企业利益最大化，而不是站在个人和小团体的立场去做事，也不是怕承担责任，把事推给别人。要求我们在众多的可能性中选择，辨别出什么是正确的，什么是最直接、最可行的做事方式和方法，把企业效益最大化作为办事的标准。
正确地做事，是驱动具体做事的人员如何按照领导的意见去做事，而不去考虑是否符合企业效益最大化的原则。
对于测试，做正确的事就是站在用户的角度，进行常用功能（模块）重点测试，而避免非常用功能的过度测试，浪费成本，包括人力与时间的投入。正确地做事，就是采用合理、全面的测试方法验证软件是否符合用户需求，不想当然地通过用户根本不可能用到的非法操作或后门进行验证。下面讲述关于软件测试的2-8原则，通过此2-8原则，可以使软件测试在项目的成本与时间的应用上做到效益最大化。
举个大家在日常生活中常遇到的例子，如经常看到广告上说，现在的手机软件的功能如何强大，如何丰富，但每一功能用户使用的频度都一样吗？回答是否定的。这 就有了在软件测试范围侧重点上存在的2-8原则，即要把80%的精力放在测试20%的重点功能上。从用户角度出发，这是值得的，也是需要这样做的。
首先，分析在我们的软件系统中，哪些功能对用户来说是核心且重要的功能，然后安排合适的测试工程师负责这些模块。设计出的测试方案、用例进行重点评审，测 试执行过程重点跟踪。每一次软件版本发布时，即使没有更改此部分的代码，也对它们进行回归测试（这种回归需讲究策略与方法），因为它们太重要了，不允许有 错误。
下面是软件测试2-8原则的详细内容。
1、80%的错误是由20%的模块引起的
简单、容易的模块或功能是很少引入过多Bug的，而对于存在复杂逻辑的一些关键模块往往会引起系统80%的错误。只有关键模块稳定了，整个系统才可能真正的健壮和稳定。
这个原则对于测试来说就是站在用户角度（而不是研发实现的角度），正确地选择重要功能模块作为测试的重点，不偏离方向。
2、80%的测试成本花在20%的软件模块中
设计测试用例时，常会用日产多少条用例来衡量工程师的工作。用例的多少与需求量有关，而影响软件架构设计的需求描述往往是比较少的。在这种情况下，设计测 试用例时特别需要结合软件的概要设计、详细设计一起考虑。如果用例设计人员为了达到用例的数量，通过大量复制用例，修改个别字眼，而没有真正去设计高效的 测试用例，那么用如此低效甚至更多的用例数量来对待复杂的20%的核心模块，在测试执行过程中必将导致一部分关键Bug找不出来。
3、80%的测试时间花在20%的软件模块中
对于复杂的模块，前期的测试设计和思考可能会耗费大量时间，而产出的用例量可能并不大。对于复杂的系统，特别是对于全新系统，必须舍得投入充足的时间来优先考虑设计，前期方案、用例设计的时间越短，后期的风险越大。
在项目进展到一定阶段后，增加人力并不一定能解决缩短时间的问题。例如，如果复杂且核心模块在项目的后期才开始执行测试，由于Bug较多，而项目又需要短 时间把版本稳定下来，通常的做法是加人。然而加入的新兵需要一段时间的熟悉期，必要时还需要老兵来带，这本身又会影响到老兵的工作。另外一些性能测试、自 动化测试工作也只有等版本稳定后才会有更好的效果。
相关链接：
软件测试的第一重境界：围着Bug转
1、某电路中有S、T、W、X、Y、Z六个开关，使用这些开关必须满足下面的条件：
（1）如果W接通，则X也要接通；
（2）只有断开S，才能断开T；
（3）T和X不能同时接通，也不能同时断开：
（4）如果Y和Z同时接通，则W也必须接通。
如果现在同时接通S和Z，则以下哪项一定为真？（ ）
A、T是接通状态并且Y是断开状态
B、W和T都是接通状态
C、T和Y都是断开状态
D、X是接通状态并且Y是断开状态
答案：A
2、一个热力站有5个阀门控制对外送蒸汽。使用这些阀门必须遵守以下操作规则：
（1）如果开启1号阀，那么必须同时开启2号阀并且关闭5号阀；（2）如果开启2号阀或者5号阀，则要关闭4号阀；
（3）不能同时关闭3号阀和4号阀。
现在要打开1号阀，同时要打开的阀门是哪两个？（）
A、2号阀和4号阀 B、2号阀和3号阀 C、3号阀和5号阀 D、4号阀和5号阀
答案：B
3、大山中学所有骑车上学的都回家吃饭，因此有些家在郊区的大山中学学生不骑车上学
为使上述论证成立，下列那个断定必须是假设的？
A、回家吃饭的学生都骑车上学
B、家在郊区的学生都不回家吃饭
C、有些家在郊区的学生不回家吃饭
D、有些不回家吃饭的学生家不在郊区
答案：C
4、某县领导参加全县的乡计划生育干部会，临时被邀请上台讲话。由于事先没有做调查研究，也不熟悉县里计划生育的具体情况，只能说些模棱两可、无关痛痒的话。他讲道：“在我们县14个乡中，有的乡完成了计划生育指标；有的乡没有完成计划生育指标；李家集乡就没有完成嘛。”在领导讲话时，县计划生育委员会主任手里捏了一把汗，因为领导讲的三句话中有两句不符合实际，真后悔临时拉领导来讲话。 以下哪项正确表示了该县计划生育工作的实际情况？（ ）
A、在14个乡中至少有一个乡没有完成计划生育指标
B、在14个乡中除李家集乡外还有别的乡没有完成计划生育指标
C、在14个乡中没有一个乡没有完成计划生育指标
D、在14个乡中只有一个乡没有完成计划生育指标
答案：C
5、随着人才竞争的日益激烈，市场上出现了一种“挖人公司”，其业务是为客户招募所需的人才，包括从其他的公司中“挖人”。“挖人公司”自然不得同时帮助其他公司从自己的雇主处挖人。一个“挖人公司”的成功率越高，雇佣它的公司也就越多。
上述断定最能支持以下哪项结论？
A、一个“挖人公司”的成功率越高，能成为其“挖人”目标的公司就越少。
B、为了有利于“挖进”人才同时又确保自己的人才不被“挖走”，雇主的最佳策略是雇佣只为自己服务的“挖人公司”。
C、为了有利于“挖进”人才同时又确保自己的人才不被“挖走”，雇主的最佳策略是提高雇员的工资。
D、为了保护自己的人才不被挖走，一个公司不应雇佣“挖人公司”从别的公司挖人。
6一10、基于以下共同题干：
有7名被海尔公司录用的应聘者：F、G、H、I、w、x和Y，其中有一人需要分配到公关部，有三人需要分配到生产部，另外三人需要分配到销售部。这7名员工的人事分配必须满足以下条件：
（1）H和Y必须分配在同一部门。
（2）F和G不能分配在同一部门
（3）如果x分配在销售部，则W分配在生产部。
（4）F必须分配在生产部。
6、以下哪项列出的可能是这7名雇员最终的分配结果？
A、公关部：W；生产部：F、H、Y； 销售部：G、I、x
B、公关部：w；生产部：G、I、X；销售部：F、H、Y
C、公关部：X； 生产部：F、G、H； 销售部：I、Y、W
D、公关部：x； 生产部：F、I、W； 销售部：G、H、Y
答案：D
7、以下哪项列出的是不可能分配到生产部的完整而准确的名单？
A、F、I、X
B、G、H、Y
C、I、W
D、G
答案：D
8、如果以下哪项陈述为真，能使7名雇员的分配得到完全的确定？
A、F和w分配到生产部。
B、G和Y分配到销售部。
C、I和W分配到销售部。
D、I和w分配到生产部。
答案：C
9、以下哪项列出的一对雇员不可能分配到销售部？
A、G和I
B、G和X
C、G和Y
D、H和W
答案：B
10、如果x和F被分配到同一部门，以下哪项陈述不可能真？
A、G被分配到销售部
B、H被分配到生产部。
C、I被分配到销售部。
D、W被分配到公关部。
答案：B
原帖地址：http://bbs.51testing.com/thread-962796-1-1.html
版权声明：本文由会员 赵佳乐SMILE 首发于51Testing软件测试论坛九周年庆活动。
原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。
无论它是一个数据仓库（DWH）还是一个大数据存储系统，我们测试员关注的基本要素便是这‘数据’。在基础水平上，数据验证是为了在这两种存储系统中针对源系统涉及的数据验证明确业务规则。这是个很容易思考的事，如果我们认识到如何测试一个DWH，我们就知道如何测试大数据存储系统。但遗憾的是，事实并非如此！在博客中，我将会阐述一些区别在这些存储系统和提出一个学习大数据测试的途径。
让我们从下面的3 个观点展示中查看这些区别：
● 数据
● 基础设施
● 验证工具
数据
在DWH 的数据与大数据存储系统的区别是数据的4个基本特性，是数据量、数据种类、数据速率和数据值。
现在能够存储在DWH系统中典型的数据是依据G，而大数据存储系统能够存储&处理数据大小超过PB。
当达到一定数据种类时，在大数据存储系统中能够被存储和处理的数据类型并没有限制。Web日志，无线射频识别，传感器网络，社交网络，互联网文本和文件，互联网搜索引擎，呼叫详细记录，天文学，大气科学，生物学，基因学，生化学，医学的记录，科学研究，军事监视，摄影档案，视频档案，和大规模的电子商务的任何数据，在大存储系统中，无论它是在可容许的运行时间内被存储和有效处理的结构化的或者未结构化的忽略的数据。另一方面，DWH能够存储和处理的仅仅是结构化的数据。
虽然存储在DWH中的数据是通过‘批处理’，大量的数据实现也支持流数据。
因为它的捕获，管理和处理数据集大小的能力是超过DWH的能力，能够派生出大数据实现的数据值/商业价值的信息是成倍大于DWH系统。
这对测试人员意味着什么呢？
一个DWH测试仪拥有与‘结构化’数据兼容的这种优势。（倾向于静态模式数据）。但大数据的测试仪可能需要与‘非结构化或者半导体结构化’数据（倾向于动态模式数据）绝大部分时间兼容。测试人员需要从商业/开发团队那里寻找一些附加输入关于‘如何从已知的数据派生出结构化动态数据’。
在DWH中，当它谈论到实际验证的数据时，测试方法是良好定义的和经过时间考验的。
测试人员可选择使用手动抽样策略或从自动化测试工具里详细的验证策略，像Infosys Perfaware（专业的DWH测试解决方案）。但是考虑到为了验证庞大的数据集，甚至抽样测试在大数据验证的情况下是有挑战的。第三产业和自动化解决方案两者正处于孵化期，测试大数据最好的方法是能够下定决心来只有通过专注研发。这为测试人员提供非常多的机遇来创新、并且加倍努力来构建能够提供测试优势的工具，同样的来提高测试效率。
基础设施
DWH系统是基于RDBMS而大数据存储系统是基于文件系统。当DWH系统在线性数据增长方面受到限制时，那些基于Apache安装的大数据实现是不会受到限制，它们能够在多个集群方面存储数据。这个存储是由HDFS（安装分布式文件系统）来提供的，一个可靠的共享存储系统能够运用分析应用MapReduce技术。
这对测试人员意味着什么呢？
作为HDFS 给客户产生力量来存储大量的数据类型，运行整个数据集的询问和在合理的诗句内返回结果时，它们在自己派生出的大量数据信息方面不再受到限制。应用复杂的转换和业务规则将会是很容易的。这种力量将会通向一种数据探索的新方法。对于一个测试员，这意味着，指数增长大量的需求来进行测试。如果测试程序在可重用和测试集优化方面没有加强，测试包将会巨大的增大，并且导致维修的灾难。
RDBMS 基于数据库（Oracle, SQL数据库等）安装在普通的文件系统中。所以，测试DWH系统没有专门的测试环境，因为它能从DWH 被安装在的文件系统中来操作。当它在HDFS中达到大量数据时，测试员需要一个测试环境基于自己的HDFS。测试员需要学习如何兼容HDFS而这不用于普通的文件系统。
验证工具
对于DWH 系统测试的确认工具是基于SQL（结构化查询语言）。为了比较不同的目的，这DWH 测试仪运用不是参照宏命令基准线就是基于自动化工具的成熟UI。对于大数据，并没有定义工具。目前在安装电子系统的可用工具范围从纯程序设计工具像MapReduce（提供JAVA、Pesl、Ruby、Python等代码）到构建包装在MapReduc上像HIVE QL或PIGlatin。
这对测试人员意味着什么呢？
HIVE QL和SQL并不一样，如果他在SQL 方面有基本技能，尽管它是很容易学习的。HIVE QL为了确认目的也是在孕育期和尚未形成整个结构来从分布式文件系统存取数据。HIVE QL 仅仅适合做平面数据结构而并不能处理复杂的嵌入式的数据结构。为了处理这些，测试人员能够运用PIGLatin，它是一个语句基础而并不需要复杂的编码，但是，为了编写MapReduce 程序的需要，自从HIVE 和PIGLatin 两个同时演变，使的专业综合测试并没有取消。这种形势对于测试人员是巨大的惊人的挑战。要么他们努力达到给他们的配置文件增加脚本编写的技能，要么就等待他们内部的解决方案，要么外置的供应商来供应强大的自动化工具，用外缘资源在HDFS 提供简单的接口来查询和比照数据。
总结
经验至少在WDH 中，只能够缩短大数量测试人员在概念层从源系统到HDFS 理解提取、加载转换数据方面学习曲线。它也并没有提供其它别的用处。
大数据测试人员必须从抓痕学习大数据电子系统组件。直到这时，市场演变和完全的自动化测试工具为了大数据的验证是有效的，测试人员没有任何选择而是如大数据开发人员一样，在借助大数据技术像Hadoop 获得同种技能组合。这对于测试人员来说需要一个惊人的思维转变，和在组织内自测试部件一样好。
为了竞争，在短期来看，这个组织应该投资于测试团队的大数据具体的培训需求，而在长期来看，应该投资于发展自动化解决方案来验证大数据。
什么是SQA？相信不少同事都有着这样的疑问。SQA的工作价值体现在哪里？相信不少刚入行SQA同仁也有这样的迷惑。如何提升SQA的工作价值？我想工作多年的SQA依然有着这样的困扰。这里，我就第二、三个问题谈谈自己的想法。
当前，国内多数IT公司在项目管理上的组织架构，都是弱矩阵的组织形式，因此项目经理没有实际的行政权力。同时，他们有各自的工作，没有较多时间投入项目管理，例如：项目经理主要是由产品、业务、运营等角色担任，他们不是专职和专业的项目经理。
SQA（Software Quality Assurance）软件质量保证：基本职能是依据组织定义的流程，以独立第三方的角度，客观的对项目活动进行稽核和评价。如果该SQA出色的完成了基本工作职能，项目成员可能仍不知道SQA的价值体现。如SQA处理不当，甚至会引起项目成员的反感，他们认为SQA是来找茬的。即便项目在SQA的检查监督下顺利的完成，也会让项目成员感觉不到SQA的存在价值。
基于以上两个背景，SQA的衍生职能应运而生。
一、SQA是项目成员在项目管理上的导师
项目管理是每个SQA从业人员必备的专业知识，而流程则是将项目管理理念结合公司实际工作进行提炼。SQA在项目工作中，应以项目管理专家的角色，在项目管理上对组员进行指导，详细解释流程定义的活动，让成员知道做什么（what）、怎么做（how）、为什么（wh、y）。例如：工作量估算的方法、WBS的分解、进度计划的编制等。
二、帮助项目取得成功，协助项目经理共同管理
实际工作中，总结以下几点：
1、SQA要稽核项目工作，首先要了解项目工作并仔细阅读项目需求，每日及时跟进项目进展，SQA可以此来提升对项目的代入感，同时对项目成员提升SQA的存在感。这是协助管理项目的基础条件。
2、协助项目团队识别和管理风险问题，及时跟进风险问题解决情况，当风险问题不能在项目层面解决时，SQA以独立第三方的身份将问题上升到更高层面解决。
3、指出项目成员在流程上的错误，并告知错误工作可能存在的风险问题，按照流程给出正确的指导。由于SQA涉及项目众多，可以将其他项目曾经发生的问题作为案例，当项目成员再次发生类似违规操作时，可以提出曾经的案例作为反面教材，并告知可能的后果。SQA要让项目成员感到，我们是发现问题而不是找茬。
综上所述，SQA要提升其工作价值，必须做到两个衍生职能，即项目团队的导师和辅助项目管理。我认为，做好第一个衍生职能，能够提升项目成员对SQA的信赖，并更好的融入项目团队中。以此为基础再做到第二个衍生职能， SQA工作才能更好的体现SQA的工作价值。