java script:;" onclick="javascript:tagshow(event, '%B2%E2%CA%D4');" target="_self" style="word-break: break-all; color: rgb(0, 0, 102); line-height: norma" name="description" />
ant; margin-top: 10px; margin-right: 0px; margin-bottom: 10px; margin-left: 0px; "> javascript:;" onclick="javascript:tagshow(event, '%B2%E2%CA%D4');" target="_self" style="word-break: break-all; color: rgb(0, 0, 102); line-height: normal !important; text-decoration: underline; ">测试时代有会员朋友发了一篇求助帖,帖子的主题内容是不清楚软件测试若干基本概念。考虑到不少测试新手会碰到类似的问题,现转贴我对这篇帖子的回复,希望对大家有所帮助。
原贴链接:
http://bbs.ltesting.net/thread-48374-1-1.html
问:在php?name=%C8%ED%BC%FE%B2%E2%CA%D4" nclick="tagshow(event)" style="word-break: break-all; line-height: normal !important; ">软件测试理论中,提到softwaretesting 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调用的这些数据(记录)能够被正确的显示出来。通过上述分析后,楼主的疑虑不难被消除了。
问: 在qc的mercury tours实例中,在测试计划的Mercury Tours Site—Html Pages目录下里有很多关于webpage 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只是描述了系统的功能是怎样的,用户需求里面可能还会关注到系统性能。所以三者的关系不能简单理解为逐步细化。