步入软件测试行业两年多,有着扎实的软件测试理论知识和丰富的项目实践经验。目前感兴趣的研究方向是通用软件产品测试、嵌入式软件测试、自动化测试、测试管理等。现任北京有必通科技有限公司测试主管。

[原创]软件测试基本概念答疑

上一篇 / 下一篇  2008-09-22 15:08:42 / 个人分类:新手天地

      测试时代有会员朋友发了一篇求助帖,帖子的主题内容是不清楚软件测试若干基本概念。考虑到不少测试新手会碰到类似的问题,现转贴我对这篇帖子的回复,希望对大家有所帮助。

     原贴链接:

                                        http://bbs.ltesting.net/thread-48374-1-1.html

问:在php?name=%C8%ED%BC%FE%B2%E2%CA%D4" nclick="tagshow(event)">软件测试理论中,提到software testing methodology的时候,强调三个步骤,1.creating test strategy; 2.create test plan/design; 3.executing test. 可是在一些实际例子中,好像经常第一和第二部分混在一起的情况,test strategy 和test plan 的概念和关系始终很糊涂,恳请高手能从理论和实际应用的两个角度讲解一下。(俺是新手,一些关键的概念搞不清楚,很痛苦,不要批评俺太拘泥于这些东东)

答:test strategy 用来表述如何测试软件系统,如何确定软件系统的测试级别和测试重点。实际项目中,单元测试集成测试功能测试系统测试验收测试等阶段的测试活动都要有不同的测试策略。拿集成测试阶段来说,可以采用自顶向下和自底向上的混合策略完成测试任务。test plan 要求用系统的方法来保障测试任务的顺利完成。包括测试任务的分配,测试资源的分配,测试策略和测试范围的确定,测试用例的设计方法,通过/失败准则的确定,测试风险的评估,日程安排等方面的内容。

问:backend测试主要是确认GUI界面中的显示数据是否与对应后台查询到的数据对应一致?如果是这样,那什么时候才需要进行backend测试?比如说,我注册一个用户,成功后,那我是否需要进行相应的数据库查询,确认注册是否成功?或者在线购物,我成功下了个订单后,然后是不是需要核对‘我的订单‘中的显示订单情况与数据库查询返回的订单结果是否一致?如果是这样,那是不是所有涉及到表单提交,且引起数据库变化的操作,都要进行backend测试?

答:backend测试可以理解为数据库测试。通过GUI键入的数据会被存储在后台数据库中,或者说数据作为记录存储在数据库的数据表中。因此,backend测试不仅要求通过GUI键入的数据被恰当地,正确地存储在后台数据库中,还要求通过GUI调用的这些数据(记录)能够被正确的显示出来。通过上述分析后,楼主的疑虑不难被消除了。

问: 在qcmercury tours实例中,在测试计划Mercury Tours Site—Html Pages目录下里有很多关于web page UI方面的测试,像Html page layout, html page source, html tag,spelling &grammar, tab order等等,我的问题,是针对web页面的UI测试的这些用例,对于web-based application来说,是不是基本都是通用的?

答:那些用例可以作为我们平时UI测试时的参考,但是不提倡生搬硬套。平时的UI测试要根据UI的特征来进行CASE的设计。这些特征包括符合通用的标准和规范,正确性,一致性,舒适性,直观性等等。

问: 在版本基本稳定的情况下,会确认一个基线版本,在此是不是马上就会进行一天一次的(Build verfication test) (Nightly build),还是逐渐的频率越来越高?如果每天都构建新版本,那是不是每天都要进行回归测试

答:BVT也可以被看作冒烟测试。BVT测试具备下面这些特点:它只是测试人员进行全面测试前的一个测试子集,用来验证软件系统主要的功能是否完好;BVT是一种类型的回归测试,在软件每次有新的build版本时进行;测试时间短,不会超过30分钟;BVT的用例要能覆盖软件基本功能;每天有新的build版本时,都要进行BVT。明白了这些,相信楼主的疑惑也是可以取消的。

问: 系统测试是不是可以理解为也是一次全面的功能测试,只不过它是在实际运行环境下进行的?那它的测试用例完全用全部的功能测试用例就OK了吗?

答:功能测试和系统测试是两码事。功能测试主要是验证软件功能的实现情况,不考虑非功能性问题。而系统测试则是在更广的范围内进行的测试,包括:功能测试、安全测试容量测试、安装测试、压力测试等等方面。所以即使执行了全部的功能方面的用例,也是无法完成系统测试的。

问: 类似兼容性测试,压力测试,性能测试,恢复测试,安装测试,它们属于不属于系统测试的范畴?如果不属于,这些测试是在系统测试之前进行还是之后进行?都在运行环境进行吗?

答:上述类型的测试均属于系统测试的范畴。是在用户使用软件系统的近真实的环境中进行的。

问:  关于build和release的概念有点模糊,能否给予解释?是不是build XYZ是指一个具体的基线版本,而build  xyz release  abc,是指这个基线版本下的一个实际的发布的子版本?所谓release是不是就是指一个真正向用户或者公众发布的版本?

答:软件发布前的版本都是build版本,这个阶段的版本是不断发现bug,不断解决bug,不断完善软件的过程。真正向用户发布的版本是release版本,也是软件的最终版本。

问:  Use case相比较用户需求文档或用户设计文档来说,是不是提供了最详细的功能实现细节?它们三者是不是就是个逐步一一细化的关系?

答:Use Case只是描述了软件系统的功能而已,并没有提供功能实现的细节。Use Cases是捕获用户需求的非常有效的机制。通过Use Cases 用户可以看到系统提供的功能,知道自己需要什么样的功能,进而生成用户需求文档。用户接口设计文档应该满足用户需求。补充: Use Case只是描述了系统的功能是怎样的,用户需求里面可能还会关注到系统性能。所以三者的关系不能简单理解为逐步细化。

 

 

 


TAG: 概念 软件测试 原创

seanhe的个人空间 引用 删除 seanhe   /   2008-09-23 10:05:26
本文推荐到了首页
 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2011-05-21  
1234567
891011121314
15161718192021
22232425262728
293031    

我的存档

数据统计

  • 访问量: 621
  • 日志数: 2
  • 建立时间: 2008-09-22
  • 更新时间: 2008-09-24

RSS订阅

Open Toolbar