软件测试领域架构

上一篇 / 下一篇  2012-05-24 11:03:33 / 个人分类:杂谈

一般在接触测试时,都是从黑盒测试方法开始的,因为其技术相对简单一些,只需要关注外部条件,包括输入、输出结果,而不需要关注系统的内部结构。但随着测试的深入,测试人员将不满足于这种黑盒测试方法,开始关注被测试系统的内部构造,并逐渐深入,比如以下从系统的架构设计到代码实现的思考。

-YC%^ZOI6{c0  1)根据系统的内部结构,采取相应的对策实现。例如,数据层和业务逻辑层,都可以采用API 直接调用的测试方法。

U0a4Gv:Co3H0

6q#T:N h:y2Ch }#Y)f~0  2)在代码层,根据程序结构,分别采用代码覆盖、分支覆盖、条件覆盖等方法来设计测试用例51Testing软件测试网kx'jtt#~/Dn

51Testing软件测试网;fy6I0U%a-??

  从这个演化的过程,可以隐隐约约地看到测试架构的形成。为了真正能解决问题,需要提高测试效率和测试覆盖率。测试不是单纯的,测试的方法也不是一成不变的,而且还要有系统性。

MT#i2|3B7o6Xq0

-q+n#C;[H8?v8?6s0  从测试结构来看,不仅要了解全部的测试内容,从单元测试系统测试、从功能测试到非功能测试,如“附录B软件测试的详细分类”,而且需要在分析、归纳和总结的基础上,将测试抽象到更高层面;提纲挈领,从整体上更好地把握测试任务。下面,将就功能测试和非功能测试分别讨论,而自动化测试架构,留到下一节讨论。51Testing软件测试网0Vl0L9dOLQ4J_.H

51Testing软件测试网s/CiC&TX?9k,o1f

  1、功能测试

F|Z#|o a051Testing软件测试网)g&qf MTJJ

   撇开非功能性测试,先谈软件产品的功能测试,以此来分析软件测试的架构。在功能测试中,不仅要完成业务逻辑的验证,还要进行用户界面和输入空间的验证。 我们在讨论软件测试方法时,经常谈到的黑盒方法中的等价类划分、边界值分析、决策表、因果分析等方法,实际上都只是功能测试的冰山一角,仅为对输入空间的 验证。为了使软件具有更好的质量,包括低缺陷率和高稳定性、可维护性,需要在代码这个层面进行充分的测试,就是人们常提到的单元测试,特别是对代码的评 审、通过工具对代码进行静态分析。也就是说,在功能测试中,不光要进行不同层次的测试,还要针对不同空间或领域进行相应的测试,可以用图2-3 简要加以描述。

/K |+]ur+A#J\-L`0

6XD n|DL ~0

图2-3 不同视角看功能测试

!|%L+qF*u:K7m0

  如果展开讨论,不同的测试领域会侧重采用不同的测试方法,如基于用例的测试,主要用于用户界面测试,但也会用于业务逻辑验证;而基于模型的测试,主要用于语法验证和业务逻辑验证等。图2-4 系统地介绍了不同测试领域的测试方法,其中几个用英文书写的说明如下:51Testing软件测试网)C#T$Gv0O&V+c,y$n

  FSM(Finite State Machine,有限状态机)51Testing软件测试网4zC\D.W{

  ForS(Formal Specification,形式规格说明)

k)YC~Va0

  FunS(Functional Specification,功能规格说明)51Testing软件测试网x&O~FB7~~

51Testing软件测试网mmGL3C?A T!C

图2-4 功能测试架构示意图51Testing软件测试网P)CdwQ.EG

  这些测试方法构成了功能测试的架构,即设计一个软件项目的测试功能,就要从用户界面验证、业务逻辑验证、输入空间验证和语法验证4 个方面去考虑。针对不同的方面,根据软件应用系统的技术特点等,选择或决定合适的测试方法、工具等,也是测试架构这个层面需要考虑的。51Testing软件测试网p8`(\-J,^$c6W-W-A

2、非功能测试51Testing软件测试网Cn0OU5WFz;U \

51Testing软件测试网N/e HD!Y$wU"f

  如果从非功能测试角度来考察测试架构,其和软件开发的架构更为贴近,两者在技术要求上是一致、相通的。非功能测试要追溯到设计阶段,软件设计是前提,设计不好,实现得再好可能也无济于事。所以,非功能测试可以看做由两大部分组成。

gV/b_F._7}v051Testing软件测试网xV {*D0X:qy

  1)设计验证:这是纸上谈兵,针对系统设计说明书进行评审,发现设计的缺陷,因可防患于未然而显得更为重要。这也是和开发人员在思路上的辩论,针锋相对地提问,通过讨论甚至辩论来发现问题。

oIsU(Ov0

*J*m@+K;Gj0  2)系统验证:将设计付诸于实施,针对建成后的系统进行验证,以确定系统是否达到设计要求。当然这一步也非常重要,设计得再好,还是要看实际的结果。51Testing软件测试网"P#x B0w.b]'f/C-h

51Testing软件测试网a`BxZz

  对于非功能性测试架构,要在对系统设计和构造理解的基础上来确定测试的具体方法。可以用简单的图来描述,如图2-5 所示。51Testing软件测试网hH7Y&E\6MUa^&L

&S \ sYOkBx0

图2-5 非功能性测试的架构示意图

?~2?by1K)Ys0

  每一类测试可能需要单独考虑,性能测试和兼容性测试、安全性测试都不一样,不同类型的测试,考虑的着眼点不一样,其方法也不一样,所使用的测试工具也不一样。当然,压力测试、稳定性测试可以和性能测试一起考虑。这里以性能测试为例,其包括如下的关键因素。

-P"Ajo'd6P(DL0

  1)测试环境:构造和产品实际运行相当的测试环境。

1c,Tx5v c0

  2)关键业务:根据系统的设计和实现,判断可能存在性能风险的业务操作点。51Testing软件测试网7Ki%MN"O!W5Y

  3)负载:根据系统的负载,确定可能受到的最大负载、平均负载等。

${d"Q+E5fX0

  4)监控指标:哪些系统资源是有限的而且会产生瓶颈,需要在测试过程中被监控。51Testing软件测试网i9I3p"m)M.rdL"O_

  5)结果分析:通过对测试结果分析,确定性能问题,并分析造成性能缺陷的根本原因。

z vB\~2~9V+F0

  分析上面这些因素可知,构造一个良好的性能测试解决方案,关键还是要对系统实现全面了解,特别是对被测试的特性(这 里指性能)要理解,能把握外部因素对系统的被测试特性的影响,从而确定系统测试的输入和测试的输出。除此之外,我们还得用技术的办法来模拟负载、监控系统 的资源或响应,这实际上就是我们经常讲的建模,用逻辑的模型或数学模型来描述实际的物理模型,如图2-6 所示。

g*A^/[(~fT"HMV0

?1Y*WR7p+F0

图2-6 非功能性测试的建模(系统模拟)

0e5B#rz!v z?0

相关链接:51Testing软件测试网L8H}Q6V\BXX-z

什么是软件测试架构51Testing软件测试网| n7l:Ruu:Ec


TAG:

 

评分:0

我来说两句

Open Toolbar