51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

楼主: lsekfe
打印 上一主题 下一主题

[你问我来答第20期]:如何编写好的测试用例?(已结束)

[复制链接]
  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    61#
    发表于 2012-3-31 11:42:43 | 显示全部楼层
    回复 154# femir

    测试用例的字段越多越好你怎么看?
    随着测试的回归,bug数越来越少,怎样才能写出发现至今还没有发现的bug用例?


    不是说测试用例字段越多越好。如果写点无关的,你觉得好吗?测试用例主要还是精确并详细为准。

    写出发现至今还没有发现的bug用例,这个几乎办不到。至今为止,没有任何一款软件自称没有bug的。

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    62#
    发表于 2012-3-31 11:51:08 | 显示全部楼层
    本帖最后由 楠族开心果 于 2012-3-31 12:22 编辑
    WEB页面测试有哪些方面?重点在哪里?需要注意的有哪些?测试用例的方向在哪边?请版主指导!
    link0313 发表于 2012-3-26 11:01
    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。     随着InternetIntranet/Extranet的快速增长,Web已经对商业、工业、银行、财政、教育、政府和娱乐及我们的工作和生活产生了深远的影响。许多传统的信息和数据库系统正在被移植到互联网上,电子商务迅速增长,早已超过了国界。范围广泛的、复杂的分布式应用正在Web环境中出现。Web的流行和无所不在,是因为它能提供支持所有类型内容连接的信息发布,容易为最终用户存取。在基于Web的系统开发中,如果缺乏严格的过程,我们在开发、发布、实施和维护Web的过程中,可能就会碰到一些严重的问题,失败的可能性很大。而且,随着基于Web的系统变得越来越复杂,一个项目的失败将可能导致很多问题。当这种情况发生时,我们对WebInternet的信心可能会无法挽救地动摇,从而引起Web危机。并且,Web危机可能会比软件开发人员所面对的软件危机更加严重、更加广泛。     Web工程过程中,基于Web系统的测试、确认和验收是一项重要而富有挑战性的工作。基于Web的系统测试与传统的软件测试不同,它不但需要检查和验证是否按照设计的要求运行,而且还要测试系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试。然而,InternetWeb媒体的不可预见性使测试基于Web的系统变得困难。因此,我们必须为测试和评估复杂的基于Web的系统研究新的方法和技术。

    一、功能测试
    1
    、链接测试

    链接是Web应用系统的一个主要特征,它是在页面之间切换和指导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方面。首先,测试所有链接是否按指示的那样确实链接到了该链接的页面;其次,测试所链接的页面是否存在;最后,保证Web应用系统上没有孤立的页面,所谓孤立页面是指没有链接指向该页面,只有知道正确的URL地址才能访问。 链接测试可以自动进行,现在已经有许多工具可以采用。链接测试必须在集成测试阶段完成,也就是说,在整个Web应用系统的所有页面开发完成之后进行链接测试。

    2
    、表单测试

    当用户给Web应用系统管理员提交信息时,就需要使用表单操作,例如用户注册、登陆、信息提交等。在这种情况下,我们必须测试提交操作的完整性,以校验提交给服务器的信息的正确性。例如:用户填写的出生日期与职业是否恰当,填写的所属省份与所在城市是否匹配等。如果使用了默认值,还要检验默认值的正确性。如果表单只能接受指定的某些值,则也要进行测试。例如:只能接受某些字符,测试时可以跳过这些字符,看系统是否会报错。

    3
    Cookies测试

    Cookies
    通常用来存储用户信息和用户在某应用系统的操作,当一个用户使用Cookies访问了某一个应用系统时,Web服务器将发送关于用户的信息,把该信息以Cookies的形式存储在客户端计算机上,这可用来创建动态和自定义页面或者存储登陆等信息。

    如果Web应用系统使用了Cookies,就必须检查Cookies是否能正常工作。测试的内容可包括Cookies是否起作用,是否按预定的时间进行保存,刷新对Cookies有什么影响等。

    4
    、设计语言测试

    Web
    设计语言版本的差异可以引起客户端或服务器端严重的问题,例如使用哪种版本的HTML等。当在分布式环境中开发时,开发人员都不在一起,这个问题就显得尤为重要。除了HTML的版本问题外,不同的脚本语言,例如JavaJavaScript ActiveXVBScriptPerl等也要进行验证。

    5
    、数据库测试

    Web应用技术中,数据库起着重要的作用,数据库为Web应用系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。在Web应用中,最常用的数据库类型是关系型数据库,可以使用SQL对信息进行处理。

    在使用了数据库的Web应用系统中,一般情况下,可能发生两种错误,分别是数据一致性错误和输出错误。数据一致性错误主要是由于用户提交的表单信息不正确而造成的,而输出错误主要是由于网络速度或程序设计问题等引起的,针对这两种情况,可分别进行测试。

    二、        性能测试

    1
    、连接速度测试

    用户连接到Web应用系统的速度根据上网方式的变化而变化,他们或许是电话拨号,或是宽带上网。当下载一个程序时,用户可以等较长的时间,但如果仅仅访问一个页面就不会这样。如果Web系统响应时间太长(例如超过5秒钟),用户就会因没有耐心等待而离开。

    另外,有些页面有超时的限制,如果响应速度太慢,用户可能还没来得及浏览内容,就需要重新登陆了。而且,连接速度太慢,还可能引起数据丢失,使用户得不到真实的页面。

    2
    、负载测试

    负载测试是为了测量Web系统在某一负载级别上的性能,以保证Web系统在需求范围内能正常工作。负载级别可以是某个时刻同时访问Web系统的用户数量,也可以是在线数据处理的数量。例如:Web应用系统能允许多少个用户同时在线?如果超过了这个数量,会出现什么现象?Web应用系统能否处理大量用户对同一个页面的请求?

    3
    、压力测试

    负载测试应该安排在Web系统发布以后,在实际的网络环境中进行测试。因为一个企业内部员工,特别是项目组人员总是有限的,而一个Web系统能同时处理的请求数量将远远超出这个限度,所以,只有放在Internet上,接受负载测试,其结果才是正确可信的。

    进行压力测试是指实际破坏一个Web应用系统,测试系统的反映。压力测试是测试系统的限制和故障恢复能力,也就是测试Web应用系统会不会崩溃,在什么情况下会崩溃。黑客常常提供错误的数据负载,直到Web应用系统崩溃,接着当系统重新启动时获得存取权。

    压力测试的区域包括表单、登陆和其他信息传输页面等。

    三、        可用性测试

    1
    、导航测试

    导航描述了用户在一个页面内操作的方式,在不同的用户接口控制之间,例如按钮、对话框、列表和窗口等;或在不同的连接页面之间。通过考虑下列问题,可以决定一个Web应用系统是否易于导航:导航是否直观?Web系统的主要部分是否可通过主页存取?Web系统是否需要站点地图、搜索引擎或其他的导航帮助?

    在一个页面上放太多的信息往往起到与预期相反的效果。Web应用系统的用户趋向于目的驱动,很快地扫描一个Web应用系统,看是否有满足自己需要的信息,如果没有,就会很快地离开。很少有用户愿意花时间去熟悉Web应用系统的结构,因此,Web应用系统导航帮助要尽可能地准确。

    导航的另一个重要方面是Web应用系统的页面结构、导航、菜单、连接的风格是否一致。确保用户凭直觉就知道Web应用系统里面是否还有内容,内容在什么地方。

    Web
    应用系统的层次一旦决定,就要着手测试用户导航功能,让最终用户参与这种测试,效果将更加明显。

    2
    、图形测试

    Web应用系统中,适当的图片和动画既能起到广告宣传的作用,又能起到美化页面的功能。一个Web应用系统的图形可以包括图片、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有:

    1)要确保图形有明确的用途,图片或动画不要胡乱地堆在一起,以免浪费传输时间。Web应用系统的图片尺寸要尽量地小,并且要能清楚地说明某件事情,一般都链接到某个具体的页面。

    2)验证所有页面字体的风格是否一致。

    3)背景颜色应该与字体颜色和前景颜色相搭配。

    4)图片的大小和质量也是一个很重要的因素,一般采用JPGGIF压缩。

    3
    、内容测试
    内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性。

    信息的正确性是指信息是可靠的还是误传的。例如,在商品价格列表中,错误的价格可能引起财政问题甚至导致法律纠纷;信息的准确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软件来进行,例如使用Microsoft Word"拼音与语法检查"功能;信息的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列表或入口,也就是一般Web站点中的所谓"相关文章列表"

    4
    、整体界面测试

    整体界面是指整个Web应用系统的页面结构设计,是给用户的一个整体感。例如:当用户浏览Web应用系统时是否感到舒适,是否凭直觉就知道要找的信息在什么地方?整个Web应用系统的设计风格是否一致?

    对整体界面的测试过程,其实是一个对最终用户进行调查的过程。一般Web应用系统采取在主页上做一个调查问卷的形式,来得到最终用户的反馈信息。

    对所有的可用性测试来说,都需要有外部人员(与Web应用系统开发没有联系或联系很少的人员)的参与,最好是最终用户的参与。

    四、        客户端兼容性测试

    1
    、平台测试

    市场上有很多不同的操作系统类型,最常见的有WindowsUnixMacintoshLinux等。Web应用系统的最终用户究竟使用哪一种操作系统,取决于用户系统的配置。这样,就可能会发生兼容性问题,同一个应用可能在某些操作系统下能正常运行,但在另外的操作系统下可能会运行失败。

    因此,在Web系统发布之前,需要在各种操作系统下对Web系统进行兼容性测试。

    2
    、浏览器测试

    浏览器是Web客户端最核心的构件,来自不同厂商的浏览器对Java,、JavaScript ActiveX plug-ins或不同的HTML规格有不同的支持。例如,ActiveXMicrosoft的产品,是为Internet Explorer而设计的,JavaScriptNetscape的产品,JavaSun的产品等等。另外,框架和层次结构风格在不同的浏览器中也有不同的显示,甚至根本不显示。不同的浏览器对安全性和Java的设置也不一样。

    测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中,测试不同厂商、不同版本的浏览器对某些构件和设置的适应性。
    五、        安全性测试

    Web
    应用系统的安全性测试区域主要有:

    1)现在的Web应用系统基本采用先注册,后登陆的方式。因此,必须测试有效和无效的用户名和密码,要注意到是否大小写敏感,可以试多少次的限制,是否可以不登陆而直接浏览某个页面等。

    2Web应用系统是否有超时的限制,也就是说,用户登陆后在一定时间内(例如15分钟)没有点击任何页面,是否需要重新登陆才能正常使用。

    3)为了保证Web应用系统的安全性,日志文件是至关重要的。需要测试相关信息是否写进了日志文件、是否可追踪。

    4)当使用了安全套接字时,还要测试加密是否正确,检查信息的完整性。

    5)服务器端的脚本常常构成安全漏洞,这些漏洞又常常被黑客利用。所以,还要测试没有经过授权,就不能在服务器端放置和编辑脚本的问题。

    六、总结

    本文从功能、性能、可用性、客户端兼容性、安全性等方面讨论了基于Web的系统测试方法。

    基于Web的系统测试与传统的软件测试既有相同之处,也有不同的地方,对软件测试提出了新的挑战。基于Web的系统测试不但需要检查和验证是否按照设计的要求运行,而且还要评价系统在不同用户的浏览器端的显示是否合适。重要的是,还要从最终用户的角度进行安全性和可用性测试

    web页面测试注意事项:

    Web测试往往不被测试人员重视,认为是没有技术含量的体力活,本人结合自己的工作经验谈谈Web测试中的一些注意事项,或许会对大家有所帮助。测试过程中主要考虑HTML页面、TCP/IP通讯、Internet链接、防火墙和运行在web页面上的一些程序(例如,applet、javascript、应用程序插件),以及运行在服务器端的应用程序(例如,CGI脚本、数据库接口、日志程序、动态页面产生器)。另外,因为服务器和浏览器类型很多,不同版本差别很小,但是表现出现的结果却不同,连接速度以及日益迅速的技术和多种标准、协议。当然还可以借助Web测试工具对其进行自动化测试。其它要考虑的如下:


    1
    、服务器上期望的负载是多少(例如,每单位时间内的点击量),在这些负载下应该具有什么样的性能(例如,服务器反应时间,数据库查询时间)。性能测试需要什么样的测试工具呢(例如,web负载测试工具,其它已经被采用的测试工具,web 自动下载工具,等等)?

    2、系统用户是谁?他们使用什么样的浏览器?使用什么类型的连接速度?他们是在公司内部还是外部?

    3、在客户端希望有什么样的性能(例如,页面显示速度?动画、applets的速度等?如何引导和运行)?

    4、允许网站维护或升级吗?

    5、需要考虑安全方面(防火墙,加密、密码等)是否需要,如何做?怎么能被测试?需要连接的Internet网站可靠性有多高?对备份系统或冗余链接请求如何处理和测试?web网站管理、升级时需要考虑哪些步骤?需求、跟踪、控制页面内容、图形、链接等有什么需求?

    6、需要考虑哪种HTML规范?多么严格?允许终端用户浏览器有哪些变化?

    7、页面显示和/或图片占据整个页面或页面一部分有标准或需求吗?

    8、内部和外部的链接能够被验证和升级吗?多久一次?

    9、产品系统上能被测试吗?或者需要一个单独的测试系统?浏览器的缓存、浏览器操作设置改变、拨号上网连接以及Internet中产生的“交通堵塞”问题在测试中是否解决,这些考虑了吗?

    10、服务器日志和报告内容能定制吗?它们是否被认为是系统测试的主要部分并需要测试吗?

    11、CGI程序、applets、javascripts、ActiveX 组件等能被维护、跟踪、控制和测试吗?

    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    63#
    发表于 2012-3-31 11:57:00 | 显示全部楼层
    庄姐,对于pos机怎么设计测试用例,测试的重点在哪里;需要注意那些地方呢 ?
    天使V3坠落 发表于 2012-3-26 13:10

    可参考http://bbs.51testing.com/thread-12531-1-1.html的回答
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    64#
    发表于 2012-3-31 12:01:40 | 显示全部楼层
    如何提高测试用例的需求覆盖率,
    xihong2004 发表于 2012-3-27 10:39


    请参考http://www.51testing.com/html/14/n-219614.html
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    65#
    发表于 2012-3-31 12:04:17 | 显示全部楼层
    测试用的评审,需要注意一些什么?主要是针对那些人群?
    weeny 发表于 2012-3-29 16:54


    在国内这个评审这个概念很淡薄,但是却是无处不在的。比如经常做的代码走查、立项会议、需求讨论等等其实都是一种简化的评审,有的公司把这叫做“头脑风暴”(往往是遇到难题的时候集中大家的智慧来冲关 )

    1、可以评审的东东很多,需求、策略、计划、用例、代码.....基本上项目中你能想到的东西,都可以拿出来评审。

    2、组织评审需要有清晰的目的(这个是整个环节中重要的部分),很简单,你首先要知道,你需要从这个评审中得到什么?也许是希望被评审东东更加完善,也许是希望增加大家交流的机会,甚至可能是为了应付上面的检查等等。

    3、不同目的评审,参与人员自然也随之变化:
    比如,希望需求更加完善的评审,理论一切与产品有关的人员,大到项目经理,小到一线销售人员都需要来参加。但是,往往评审的人员越多,时间上就越难安排,所以需要结合实际情况来删减。

    当然,也不是说必须要XX人参加的评审才叫评审,比如一个BA与一个客户或开发人员私下的一次交流,只要做了详细的记录,也可以算作是一个评审。

    所以,有内容的评审其实是不拘形式的,假如非得搞个内审或外审来规范,我只能说那是走过场而已。

    4、在组织评审的细节上,有一点很重要:不要在评审过程中“照本宣书”。
    很多公司在评审前不做准备,评审时拉个主持人上去就对着文档、PPT一阵读,半天下来,问大家有没问题,结果只能是只言片语。

    所以,在评审前最好先做预审,也就是在评审前,给予评审人员一定的时间,也许是三、两天,也许是一星期,让评审人员熟悉评审目标,并提出自己的意见,由一个统一的程序收集起来,在评审中逐一解决。这样的效果会好很多。

    5、最后说说比较规范的评审流程
    确定评审目标——确定参与人员(包括主持人、记录员、评审员等)——安排评审时间——预审——整理预审报告——评审——整理评审报告——作者修改评审目标——复审(复审可以走简单流程,由各个提建议的评审人员查看自己的建议是否得到合理的修改)——存档
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    66#
    发表于 2012-3-31 13:48:14 | 显示全部楼层
    我做测试一年了,但是只会输入数据,看数据对不对。感觉没有前途,很迷茫。给些建议吧。
    yuyu2you 发表于 2012-3-31 13:23


    多看些测试的资料;多看些有关的书籍;多练习
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2024-4-24 10:12
  • 签到天数: 536 天

    连续签到: 1 天

    [LV.9]测试副司令

    67#
    发表于 2012-4-1 09:36:39 | 显示全部楼层
    测试用例的粒度怎么个界定.? 碰到功能复杂的测试,书写用例就感觉无从下手
    holly08 发表于 2012-3-31 22:38


    根据需求来定。较复杂的,可以先画出流程图,再进行编写测试用例
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-5-22 02:20 , Processed in 0.075920 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表