移山 - 软件测试讨论(5)

　　用一个数字照片编辑软件为例，这个软件的各个模块都是独立开发的，可是用户有一定的典型流程，如果这个流程走得不好，哪怕某个模块的质量再高，用户也不会满意。

　　1.把照相机的储存卡插入电脑

　　2.程序会跳出窗口提示用户导入照片

　　3.导入照片

　　4.对照片进行快速编辑

　　a.调整颜色

　　b.调整亮度，对比度

　　c.修改红眼

　　5.把其中几幅照片用email发送

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

　　1.10Performance Test 效能测试

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

　　效能测试要验证的问题是：

　　软件在设计负载内能够提供令用户满意的服务质量。

　　1.在设计负载内 – 我们要定义什么是正常的设计负载

　　2.令用户满意的服务质量 – 我们要定义什么样的质量是令用户满意的

　　设计负载 – 从需求说明出发，得出系统的正常负载。例如，一个购物网站，客户认为正常负载是每分钟20次客户请求。

　　用户满意的质量 – 同一个购物网站，如果客户定义满意为：每个用户的请求都能在2秒钟内返回结果。

　　我们可以逐步细化 –

　　设计负载的细化，上面我们只提到“20次客户请求”，那这些客户请求到底是什么，我们可以按照请求发生的频率来分类：

　　1. 用户登录 (10%)

　　2. 用户查看某商品详情(50%)

　　3. 用户比较两种商品(10%)

　　4. 用户查看关于商品的反馈(20%)

　　5. 用户购买商品(5%)

　　6. 所有其他请求(5%)

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

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

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

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

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

　　1.11 Stress Test压力测试

　　压力测试严格地说不属于效能测试。压力测试要验证的问题是：

　　软件在超过设计负载的情况在仍能够返回正常结果，而没有产生严重的副作用或崩溃。

　　问：为啥不要求软件在这种情况下仍然在2-3秒钟内返回结果?

　　答：因为我们做不到。

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

　　那我们怎么增加负载?对于网络服务软件来说，主要有下面两个方面：

　　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中。软件的可用性不神秘，就是让软件更好用，让用户更有效地完成工作。

　　但是我觉得“可用性测试”似乎更多地用来描述一套测试软件可用性的过程，这个过程一般不是由测试人员来主导的，而是有对软件设计及可用性有很多研究的“可用性设计师”来实行。网络上有许多关于这方面的文章，大家可以参考。

原文转自：http://www.ltesting.net