注意，我们在这一部分要求“正常结果”，啥叫“正常”？我们也要和客户达成一致。比如，同一个购物网站，所有请求都能在网络返回“超时”错误前返回，就可以认为是“正常”。 或者网站返回“系统忙，请稍候”，也是正常结果。但是，如果用户提交的请求一部分执行，另一部分没有执行；或者用户信息丢失，这些都是不正常的结果，应该避免。
那我们怎么增加负载？对于网络服务软件来说，主要有下面两个方面：
1． 沿着用户轴延长
我们用刚才的购物网站为例，正常的负载是20请求/分钟，如果有更多的用户登录，怎么办？那么负载就会变成30，40， 100请求/分钟，或更高
2． 沿着时间轴延长
做过网络服务的同事都知道，网络的负载有时间性，负载压力波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉？这就是我们要作的第二点，沿着时间轴延长。
与此同时，我们可以减少系统可用的资源，来增加压力。
注意，压力测试的重点是验证程序不崩溃或产生副作用。在超负载的情况下，我们的程序仍然能够正确地运行，而不会死机。在给程序加压的过程中，程序中的很多“小”问题就会被放大，暴露出来。 最常见的问题是
内存/资源泄露，在压力下这会导致程序可用的资源枯竭，最后崩溃。
一些平时认为“足够大/足够好”的算法实现会出现问题。
进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也出现了问题。
在VSTS中如何进行压力测试在以后章节中会详细讲解。
1.12 Alpha Test, Beta Test
在开发软件的过程中，开发团队希望让用户直接接触到最新版本的软件，以便从用户那里收集反馈，这时开发团队会在开发过程中让特定的用户（alpha/beta用户）使用正处于开发过程中的版本，用户会用特定的反馈渠道（email, BBS）与开发者讨论使用中发现的问题，等等。这种做法成功地让广大用户心甘情愿地替开发团队测试产品并提出反馈。最近有些开发团队增加了反馈的密度，不必再等到Alpha或者Beta发布，而是不断地把一些中间版本发布出去以收集反馈，美其名曰“技术预览版本”或“社区预览版本”。
1.13 Usability Test可用性测试
小燕问：作为测试人员，我们是不是也要作可用性测试?
答：测试人员，以及其他的团队成员都可以对软件的可用性提出意见，包括用bug的形式放在在TFS中。软件的可用性不神秘，就是让软件更好用，让用户更有效地完成工作。
但是我觉得“可用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是有对软件设计及可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。
1.14 Bug Bash
问：我们已经讲得太多的测试了，好像微软还有一个叫“bug bash”的活动，是啥意思？
答：简而言之，就是大家一起来找小强的活动 – 小强大扫除。一般是安排出一段时间（一天），所有测试人员（有时也加入其他角色）放下手里的事情，专心找某种类型的小强。然后结束时，统计并奖励找得最多的，和最厉害的小强的员工。这种活动，如果运用得好，有下面的作用：
鼓励大家做探索试的测试，开阔思路。
鼓励测试队伍学习并应用新的测试方法，例如在做完“软件安全性测试”培训后，立马做一个针对“安全性”的小强大扫除.
找到很多小强，让开发人员忙一阵子
当然，小强大扫除也有一些副作用：
扰乱正常的测试工作
如果过分重视奖励，会导致一些数量至上，滥竽充数的做法。
文章来源于领测软件测试网 https://www.ltesting.net/
