51Testing软件测试论坛

标题: web应用程序测试方法和测试技术详述 [打印本页]

作者: 晓诺    时间: 2007-9-1 19:05
标题: web应用程序测试方法和测试技术详述
(摘自 -UML软件工程组织  北京火龙果软件工程技术中心1. 概述

随着web应用的增多,新的模式解决方案中以web为核心的应用也越来越多, 很多公司各种应用的架构都以B/S及web应用为主,但是有关WEB测试方面的内容并没有相应的总结,所以我在这里对web的测试方法和采用的测试技术进行总结,便于内部交流。
测试方法尽量涵盖web程序的各个方面,测试技术方面在继承传统测试技术的技术上结合web应用的特点。
相关的测试和实现技术也有着很大的关系,由于本公司使用J2EE体系,也许例子中只有JAVA平台可以使用,.NET平台测试技术暂时不涉及,如果你有请与我联系。
2. 测试方法
说明:测试方法的选择取决你的测试策略。
一般的web测试和以往的应用程序的测试的侧重点不完全相同,基本包括以下几个方面。
当然圆满的完成测试还要有好的团体和流程等的方方面面的支持,你同样应该对这些方面进行注意。
有些测试方法设计到了流程,哪些应该在你的测试团队建设中建立。
2.1 界面测试
现在一般人都有使用浏览器浏览网页的经历,用户虽然不是专业人员但是对界面效果的印象是很重要的。如果你注重这方面的测试,那么验证应用程序是否易于使用就非常重要了。很多人认为这是测试中最不重要的部分,但是恰恰相反界面对不懂技术的客户来说那相当关键,慢慢体会你会明白的。
方法上可以根据设计文档,如果够专业的话可以专业美工人员,来确定整体风格页面风格,然后根据这个可以页面人员可以生成静态的HTML,CSS等甚至生成几套不用的方案来讨论,或者交给客户评审,最后形成统一的风格的页面/框架。注意不要靠程序员的美术素养形成你的web风格,那样可能会很糟糕。
主要包括以下几个方面的内容:

web测试的主要页面元素
页面元素清单(为实现功能,是否将所需要的元素全部都列出来了,如按钮、单选框、复选框、列表框、超连接、输入框等等)
测试技术

符合标准和规范,灵活性,正确性,直观性,舒适性,实用性,一致性
1.直观性:
2.一致性
3.灵活性
4.舒适性
2.2 功能测试
对功能测试是测试中的重点
主要包括一下几个方面的内容
测试技术 功能测试的测试技术可是很多的,我们可以结合实际环境选择使用
正确性 (Correctness):计算结果,命名等方面
可用性 (Usability):是否可以满足软件的需求说明。
边界条件 (Boundary Condition)输入部分的边界值,就是使用一般书中说的等价类划分,试试最大最小和非法数据等等.
性能 (Performance) 正常使用的时间内系统完成一个任务需要的时间,多人同时使用的时候响应时间,在可以接受范围内.J2EE技术实现的系统在性能方面更是需要照顾的,一般原则是3秒以下接受,3-5秒可以接受,5秒以上就影响易用性了. 如果在测试过程中发现性能问题,修复起来是非常艰难的,因为这常常意味着程序的算法不好,结构不好,或者设计有问题。因此在产品开发的开始阶段,就要考虑到软件的性能问题
压力测试 (Stress) 多用户情况可以考虑使用压力测试工具,建议将压力和性能测试结合起来进行.如果有负载平衡的话还要在服务器端打开监测工具,查看服务器CPU使用率,内存占用情况, 如果有必要可以模拟大量数据输入,对硬盘的影响等等信息.如果有必要的话必须进行性能优化(软硬件都可以).这里的压力测试针对的是某几项功能,.
错误恢复 (Error Recovery) 错误处理,页面数据验证,包括突然间断电,输入脏数据等.
安全性测试(Security)这个领域正在研究中,不过防火墙,补丁包.杀毒软件等的就不必说了,不过可以考虑破坏性测试时任意.看了一些资料后得知,这里面设计到的知识\内容可以写本书了,不是一两句可以说清的,特别是一些商务网站,或者跟钱有关,或者和公司秘密有关的web更是,需要这方面的测试,在外国有一种专门干这一行的人叫安全顾问,可以审核代码,提出安全建议,出现紧急事件是的处理办法等,在国内没有听说哪里有专门搞安全技术测试的内容.
兼容性 (Compatibility) 不同浏览器,不同应用程序版本在实现功能时的表现,不同的上网方式,如果你测试的是一个公共网站的话.
兼容性测试内容详述
软件配置 (Configuration) 如IE浏览器的不用选项-安全设定最高,禁用脚本程序,等等,你们的程序在各种不用的设置下表现如何.
单元测试技术(Unit Test):
2.2.1 下面是对白盒测试和单元测试的区别的论述:
单元测试和白盒测试是不同的,虽然单元测试和白盒测试都是关注功能虽然他们都需要代码支持,但是级别不同,白盒测试关注的是类中一个方法的功能是更小的单位,但是完成一个单元测试可能需要N多类,所以说作单元测试需要什么写驱动和稳定桩,比如查询单元是一个查询包包N多的测试类,测试数据,运行他需要提供数据的部分,输入参数和发出命令的驱动等等.是比类大的一个整体进行的.
另一个明显的区别是白盒测试不会关注类接口,但是单元测试主要的内容就是类接口测试.
不过很多时候是很少区分的,因为这两种技术实现起来有很多相互关联的部分.不过要看你对质量的关注程度来决定.
2.2.2 功能测试边界测试\越界测试技术详述
另一些该注意的输入:默认,空白,空值,零值和无;非法,错误,不正确和垃圾数据.
2.2.3 状态测试技术
具体测试方法可以参考如下:
2.2.4 竞争条件测试技术
竞争条件典型情形参考如下:


[ 本帖最后由 晓诺 于 2007-9-1 19:08 编辑 ]
作者: 晓诺    时间: 2007-9-1 19:05
2.3 负载\压力测试(StressTest)

在这里的负载\压力和功能测试中的不同,他是系统测试的内容,是基本功能已经通过后进行的.可以在集成测试阶段,亦可以在系统测试阶段进行.

使用负载测试工具进行,虚拟一定数量的用户看一看系统的表现,是否满足定义中的指标.

负载测试一般使用工具完成,loadrunner,webload,was,ewl,e-test等,主要的内容都是编写出测试脚本,脚本中一般包括用户一般常用的功能,然后运行,得出报告。所以负载测试包括的主要内容就不介绍了。

负载测试技术 在各种极限情况下对产品进行测试 (如很多人同时使用该软件,或者反复运行该软件),以检查产品的长期稳定性。例如,使用压力测试工具对web服务器进行压力测试. 本项测试可以帮助找到一些大型的问题,如死机、崩损、内存泄漏等,因为有些存在内存泄漏问题的程序,在运行一两次时可能不会出现问题,但是如果运行了成千上万次,内存泄漏得越来越多,就会导致系统崩滑。用J2EE实现的系统很少但是并不是没有内存问题.

无论什么工具基本的技术都是利用线程技术模仿和虚拟用户,在这里主要的难点在与测试脚本的编写,每种工具使用的脚本都不一样,但是大多数工具都提供录制功能就算是不会编码的测试人员同样可以测试。
对负载工具的延伸使用可以进行系统稳定性测试,系统极限测试,如使用100的Load Size连续使用24小时,微软定义的通过准则是通过72小时测试的程序一般不会出现稳定性的问题。
2.4 回归测试 (Regression Test)

过一段时间以后,再回过头来对以前修复过的Bug重新进行测试,看该Bug 是否会重新出现。

回归测试技术 可以在测试的各个阶段出现,无论是单元测试还是集成测试还是系统测试。是对以前问题进行验证的过程。
回归测试的目的就是保证以前已经修复的Bug不会再出现。实际上,许多Bug都是在回归测试时发现的,在此阶段,我们首先要检查以前找到的Bug 是否已经更正了。值得注意的是,已经更正的Bug 也可能又回来了,有的Bug 经过修改之后可能又产生了新的Bug。所以,回归测试可保证已更正的Bug不再重现,不产生新的Bug。
2.5 Alpha 和Beta 测试 (Alpha and Beta Test):

在正式发布产品之前往往要先发布一些测试版,让用户能够反馈出相关信息,或者找到存在的Bug,以便在正式版中得到解决。

特别是在有客户参加的情况下,对系统进行测试可能会出现一些我们没有考虑的情况,还可以解决一些客户实际关心的问题不同的测试技术区分





3 技术

3.1 覆盖测试技术

说明:测试覆盖率可以看出测试的完成度,在测试分析报告中可以作为量化指标的依据,测试覆盖率越高效果越好。

覆盖测试可以是程序代码的执行路径覆盖,亦可以是功能实现的步骤覆盖(可以理解成流程图的路径覆盖)。

该技术可以用在任何测试阶段,包括单元测坏死、集成测试、系统测试。

使用该技术时可以使用以上的任何测试方法和测试技术。

3.2 白盒测试和黑盒测试技术

白盒测试技术 (White Box Testing)该技术主要的特征是测试对象进入了代码内部,根据开发人员对代码和对程序的熟悉程度,对有需要的部分进行在软件编码阶段,开发人员根据自己对代码的理解和接触所进行的软件测试叫做白盒测试。这一阶段测试以软件开发人员为主,使用Xunit系列工具进行测试,可以包括很多方面如功能性能等。

黑盒测试 (Black Box Testing)测试的主体部分黑盒测试的内容主要有以下几个方面,但是主要还是功能部分。主要是覆盖全部的功能,可以结合兼容,性能测试等方面进行,包括的不同测试类型请参考以上内容。

3.3 手工测试和自动化测试

手工测试 (Manual Testing):即依靠人力来查找Bug。方法可以参考上边的测试,也可以根据对实现技术及经验等进行不同的测试。

自动测试 (Automation Testing)使用有针对工具实行。可以作出自动化测试的计划,对可以进行自动化测试的部分编写或者录制相应的脚本,可以加入功能,容错,表单提交等,可以参考MI,Rational或者其他类测试工具说明.

根据权威的软件测试经验,手工测试还是主要的测试方法,自动测试不够灵活,在这里不再详述。微软的测试过程80%还是手工完成。

自动测试永远也代替不了手工测试,但是手工测试的工作量很大是不争的事实。

3.4 根据RUP标准按阶段区分测试

单元测试 在上边有详细的叙述,还有针对单元测试和集成测试的论述,请参考。

集成测试 分为功能集成测试和系统集成测试,相互有调用的功能集成,在系统环境下功能相互调用的影响等,使用方法可以任意选用上面的内容。注重功能方面。

系统测试 在功能实现的基础上,可以加入兼容性,易用性,性能等等

验收测试 可以包括Alpha和Beta测试,在这里就不再详述。

4. 存在风险及解决方法

说明:测试不能找出所有的问题,只是尽量将问题在开发阶段解决大多数的问题而已。
测试风险如下:

软硬件的测试环境提供上也对测试结果有很大的影响。

测试团队的水平,经验,合作效果等

整个开发流程对测试的重视程度,测试的进入时间等

由于测试环境操作系统,网络环境,带宽等情况可能产生的测试结果可能不同这是就需要经验以及对测试环境的保护等方面下一些功夫。

5. 软件缺陷的原则

软件缺陷区别于软件bug,它是在测试过程中出现的对系统有影响的,但是在设计中没有的或者对修改后的bug测试和开发人员有不同意见等

软件未达到产品说明书标明的功能。
软件出现了产品说明书指明不会出现的错误。
软件功能超出产品说明书指明范围。
软件未达到产品说明书虽未指出但应达到的目标。
软件测试员认为软件难以理解、不易使用、运行速度缓慢,或者最终用户认为不好。
6. 文档测试

产品说明书属性检查清单

完整.是否有遗漏和丢失?完全吗?单独使用是否包含全部内容?
准确.既定解决方案正确吗?目标明确吗?有没有错误?
精确,不含糊,清晰.描述是否一清二楚?还是自说自话?容易看懂和理解吗?
一致.产品功能能描述是否自相矛盾,与其他功能有没有冲突?
贴切.描述功能的陈述是否必要?有没有多余信息?功能是否原来的客户要求?
合理.在特定的预算和进度下,以现有人力,物力和资源能否实现?
代码无关.是否坚持定义产品,而不是定义其所信赖的软件设计,架构和代码?
可测试性.特性能否测试?测试员建立验证操作的测试程序是否提供足够的信息?
产品说明书用语检查清单
说明 对问题的描述通常表现为粉饰没有仔细考虑的功能----可归结于前文所述的属性.从产品说明书上找出这样的用语,仔细审视它们在文中是怎样使用的.产品说明书可能会为其掩饰和开脱,也可能含糊其词----无论是哪一种情况都可视为软件缺陷.

总是,每一种,所有,没有,从不.如果看到此类绝对或肯定的,切实认定的叙述,软件测试员就可以着手设计针锋相对的案例.
当然,因此,明显,显然,必然.这些话意图诱使接受假定情况.不要中了圈套.
某些,有时,常常,通常,惯常,经常,大多,几乎.这些话太过模糊."有时"发生作用的功能无法测试.
等等,诸如此类,依此类推.以这样的词结束的功能清单无法测试.功能清单要绝对或者解释明确,以免让人迷惑,不知如何推论.
良好,迅速,廉价,高效,小,稳定.这些是不确定的说法,不可测试.如果在产品说明书中出现,就必须进一步指明含义.
已处理,已拒绝,已忽略,已消除.这些廉洁可能会隐藏大量需要说明的功能.
如果...那么...(没有否则).找出有"如果...那么..."而缺少配套的"否则"结构的陈述.想一想"如果"没有发生会怎样.




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2