1．把照相机的储存卡插入电脑
2．程序会跳出窗口提示用户导入照片
3．导入照片
4．对照片进行快速编辑
a.调整颜色
b.调整亮度，对比度
c.修改红眼
5．把其中几幅照片用email发送

这里面每一步出了问题，都会影响用户对这一产品的使用，同时这里面各个模块的用户界面如果很不一致（即使是ok/cancel按钮的次序不同），用户使用起来也很不方便。这些问题都是在单独模块的测试中不容易发现的。

1.10PerformanceTest效能测试

用户使用软件，不光是希望软件能够提供一定的服务，而且还要求服务的质量要达到一定的水平，软件的效能，是这些“非功能需求”，或者说“服务质量需求”的一部分。

效能测试要验证的问题是：
软件在设计负载内能够提供令用户满意的服务质量。

1．在设计负载内–我们要定义什么是正常的设计负载
2．令用户满意的服务质量–我们要定义什么样的质量是令用户满意的

设计负载–从需求说明出发，得出系统的正常负载。例如，一个购物网站，客户认为正常负载是每分钟20次客户请求。
用户满意的质量–同一个购物网站，如果客户定义满意为：每个用户的请求都能在2秒钟内返回结果。

我们可以逐步细化–
设计负载的细化，上面我们只提到“20次客户请求”，那这些客户请求到底是什么，我们可以按照请求发生的频率来分类：
1．用户登录（10%）
2．用户查看某商品详情（50%）
3．用户比较两种商品（10%）
4．用户查看关于商品的反馈（20%）
5．用户购买商品（5%）
6．所有其他请求（5%）

服务质量的细化–有些请求，是要对数据作“写”操作，可以要求慢一些，比如“用户购买商品”，这一服务质量请求可以放宽为3秒钟。

除了用户体验到的“2秒钟页面刷新”目标外，效能测试还要测试软件内部各模块的效能，这要求软件的模块能报告自身的各种效能指标，通过perfmon或其它测试工具表现出来。

和别的测试不同，效能测试对硬件要有固定的要求，而且要每次测试在相同的机器和网络环境中进行，这样才能避免外部随机因素的干扰，得到的效能数据。

同时，效能测试的结果应该成为“发布指南”的一部份，给客户发布和改进系统提供参考。

在VSTS中如何进行效能测试在以后会详细讲解。

1.11StressTest压力测试

压力测试严格地说不属于效能测试。压力测试要验证的问题是：
软件在超过设计负载的情况在仍能够返回正常结果，而没有产生严重的副作用或崩溃。

问：为啥不要求软件在这种情况下仍然在2-3秒钟内返回结果？
答：因为我们做不到。

注意，我们在这一部分要求“正常结果”，啥叫“正常”？我们也要和客户达成一致。比如，同一个购物网站，所有请求都能在网络返回“超时”错误前返回，可以认为是“正常”。或者网站返回“系统忙，请稍候”，也是正常结果。但是，如果用户提交的请求一部分执行，另一部分没有执行；或者用户信息丢失，这些都是不正常的结果，应该避免。

那我们怎么增加负载？对于网络服务软件来说，主要有下面两个方面：
1．沿着用户轴延长
我们用刚才的购物网站为例，正常的负载是20请求/分钟，如果有更多的用户登录，怎么办？那么负载会变成30，40，100请求/分钟，或更高

2．沿着时间轴延长
做过网络服务的同事都知道，网络的负载有时间性，负载压力波峰和波谷相差很大，那么如果每时每刻负载都处于峰值，程序会不会垮掉？这是我们要作的第二点，沿着时间轴延长。

与此同时，我们可以减少系统可用的资源，来增加压力。

注意，压力测试的重点是验证程序不崩溃或产生副作用。在超负载的情况下，我们的程序仍然能够正确地运行，而不会死机。在给程序加压的过程中，程序中的很多“小”问题会被放大，暴露出来。常见的问题是

内存/资源泄露，在压力下这会导致程序可用的资源枯竭，后崩溃。
一些平时认为“足够大/足够好”的算法实现会出现问题。
进程/线程的同步死锁问题，在压力下一些小概率事件会发生，看似完备的程序逻辑也出现了问题。


在VSTS中如何进行压力测试在以后章节中会详细讲解。