正在阅读:系统测试与压力应用设计系统测试与压力应用设计

2007-10-17 16:31 出处:PConline 作者:网络文摘 责任编辑:gongjianhui

 

  
  系统测试(System Test)通常是在功能验 证阶段完成,验证了核心功能后进行。它倾向于把整个系统作为一个整体来查找问题 — 弄清 Web 服务作为系统的一部分怎样运作,以及 Web 服务相互之间如何交互。由于系统测试是在开发生命周期快结束时才进行,所以通常不能给它分配足够的时间来完成。又因为紧张的发行日程安排以及开发的各个重 要阶段的后移,系统测试阶段经常被忽略,并且一些通常都可以发现的、少见的错误都不能被检测到。即使发现了这种错误,这时也来不及确定错误的原因并设法修 复它们了。因此,在查找代码错误时,必需把系统测试应用设计得尽可能高效。系统测试通常由三部分组成,它们是:

  性能(Performance):这涉及到确定相关的产品统计数据的过程。例如:每秒有多少条消息?一个服务可同时接受多少个用户?

  案例(Scenario):这是重新创建客户所需的确切配置的过程。因此在案例中发现的任何问题都可以在客户使用该产品之前被检测出来。

  压力(或称工作负载平衡):它 与另两个部分不同,因为它被设计为通过应用很大的工作负载来使软件超负荷运转。如果压力测试通过对产品保持高强度的使用(但不超过性能统计数字确定的限 制)能有效地执行,那么它就经常能够发现许多隐蔽的错误,而这些错误用上面提到的任何其他技术都是发现不了的(这些错误也经常是最难修复的)。

  从检测代码错误这方面来说,可以证明这三个系统测试组件中效率最高的是压力测试部分。但由于这个过程经常跟系统的其他要素或功能测试混淆在一起,所以这个过程涉及到的方法还没有被正确着手处理或实现。

  压力下的错误

  使用压力测试,您有希望找到很多种用其他测试方法更难发现的错误。有两种错误类型是:

  内存泄漏(Memory leak):一种极难检测的现象。内存泄漏经常发生在已发行的产品中,原因很简单,很难设计测试 用例来检测它们。使用简单的功能测试,几乎发现不了内存泄漏问题,因为在产品完成之前测试没对产品进行足够多的使用。内存泄漏通常要求操作要重复非常多的 次数以使内存消耗达到能引起注意的程度。

  并发与同步(Concurrency and Synchronization):压力测试在查找并发性问题上非常出众,这是因为在任何一个测试生命周期中,它都应用了许多不同的代码路径和定时条件。一般的规则是,压力测试运行的时间越 长,涉及并应用的代码路径组合和定时条件就越多。当然,这也的确使得这些问题很难再现(错误可以在 5 分钟或 5 天后发生)。死锁、线程泄漏以及任何一般的同步问题通常只能在压力测试阶段被检测出来。这些类型的问题很难通过执行单元测试来发现。开发人员不会一直考虑 他或她的代码将与其他地方的代码(在执行单元测试时这些代码可能还没写出来)进行交互。

  设计压力应用

  设计试图对 Web 服务进行压力测试的压力测试系统时,要让它们以某种特定的方式运行代码。这些风格超越了功能验证,目的是要弄清楚被测试的 Web 服务是不是不仅能做我们认为它能做的事,而且在被施加了某些高强度压力的情况下仍然继续正常运行。压力测试必须对 Web 服务应用四个基本条件。许多已建立的压力系统应用了这些条件。有效的压力测试系统将应用以下这些关键条件:

  重复(Repetition):或 许最明显的且最容易理解的压力条件就是测试的重复。换句话说,测试的重复就是一遍又一遍地执行某个操作或功能,比如重复调用一个 Web 服务。功能验证测试可以用来被弄清楚一个操作能否正常执行。而压力测试将确定一个操作能否正常执行,并且能否继续在每次执行时都正常。这对于推断一个产品 是否适用于某种生产情况至关重要。客户通常会重复使用产品,因此压力测试应该在客户之前发现代码错误。许多最简单的压力系统只实现这一个条件,但简单地扩 展功能验证测试来多次重复并不能构成一个有效的压力测试。当与下面的一些原则结合起来使用时,重复就可以发现许多隐蔽的代码错误。

  并发(Concurrency):并 发是同时执行多个操作的行为。换句话说,就是在同一时间执行多个测试,例如在同一个服务器上同时调用许多 Web 服务。这个原则不一定适用于所有的产品(比如无状态服务),但是多数软件都具有某个并发行为或多线程行为元素,这一点只能通过执行多个代码示例才能测出 来。功能测试或单元测试几乎不会与任何并发设计结合。压力系统必须超越功能测试,要同时遍历多条代码路径。至于怎么做到这一点取决于具体的产品。例如,一 个 Web 服务压力测试需要一次模拟多个客户机。Web 服务(或者任何多线程代码)通常会访问多个线程实例间的一些共享数据。因额外方面的编程而增加的复杂性通常意味着代码会具有许多因并发引起的错误。由于引 入并发性意味着一个线程中的代码有可能被其他线程中的代码中断,所以错误只在一个指令集以特定的顺序(例如以特定的定时条件)执行时才会被发现。把这个原 则与重复原则结合在一起,您可以应用许多代码路径和定时条件。

  量级(Magnitude):压力系统应该应用于产品的另一个条件考虑到了每个操作中的负载量。压力测试可以重复执行一个操作,但是操作自身也要尽量给产品增加负担。例如,一个 Web 服务允许客户机输入一条消息,您可以通过模拟输入超长消息的客户机来使这个单独的操作进行高强度的使用。换句话说就是,您增加了这个操作的量级。这个量级 总是特定于应用的,但是可以通过查找产品的可被用户计量和修改的值来确定它 — 例如,数据的大小、延迟的长度、资金数量的转移、输入速度以及输入的变化等等。单独的高强度操作自身可能发现不了代码错误(或者仅能发现功能上的缺陷), 但与其他压力原则结合在一起时,您将可以增加发现问题的机会。

  随机变化:最后一点,任何压力系统都多多 少少具有一些随机性。如果您随机使用前面的压力原则中介绍的无数变化形式,您就能够在每次测试运行时应用许多不同的代码路径。下面是几个关于怎样在测试生 命周期内改变测试的示例。使用重复时,在重新启动或重新连接服务之前,您可以改变重复操作间的时间间隔、重复的次数,或者也可以改变被重复的 Web 服务的顺序。使用并发,您可以改变一起执行的 Web 服务、同一时间运行的 Web 服务数目,或者也可以改变关于是运行许多不同的服务还是运行许多同样的实例的决定。量级或许是最容易更改的 — 每次重复测试时都可以更改应用程序中出现的变量(例如,发送各种大小的消息或数字输入值)。如果测试完全随机的话,因为很难一致地重现压力下的错误,所以 一些系统使用基于一个固定随机种子的随机变化。这样,用同一个种子,重现错误的机会就会更大。

 
这些令人意想不到的黑客藏身之处 你猜对几个? 受不了多愁善感的天气?那就选部好片宅在家 追求极致的体验 神画智能影院F1 Pro新品评测 斐讯与他的0元购:一个猜到开头却猜错结尾的故事 不好意思 你在电脑上干了什么我们都知道!

为您推荐

加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多
加载更多

服务器论坛帖子排行

最高点击 最高回复 最新
最新资讯离线随时看 聊天吐槽赢奖品