|
前段时间学习完HP公司的3款自动化测试工具,并在一次项目中实际应用后,我本打算写一篇如标题所示的文章。这一点在年前博客中的一篇日志中也曾提到。
不过,我在网上搜索“自动化测试架构”的相关内容时,发现我所想写的东西与其中大部分内容类似,就暂时将这件事搁置起来。
直到最近~我发现一本好书:《Google将带来什么》。其中提到的逆推一件成功的事物来学习他的理念与我的想法不谋而合~才使我认识到写这篇文章的关键不是其中的测试方法~而是这种学习事物的思想~
根据我理解一件事物的经验~一般需要3次大的理解上的变革,才可以趋于稳定~而在第3次观念变革以后只能保留第一次时25%的观点~
我初入软件测试行业~所以以下内容顶多有25%正确~
==================================================
接下来我会描述推测的手工测试的过程,并在括号中注明其来源于QTP或者TD中的哪些内容。
前期的计划就不细说了~(在TD中,因为主要是配合自家的其他2款产品,我觉得“需求管理”部分也主要分功能和性能2类,至于其他方面不用自动化测试工具也罢~在功能类中的每一个控件可分为一个需求点。针对这一控件的数据要求和图像要求等等可再细分,此处对应到QTP时可对这一控件的一个基础action采用不同的参数或检查点来实现。)
在单元测试中,针对陆续做好的各单元模块进行功能测试。此时对常用控件可采用通用的功能测试用例,而不用另行设计。类似于TC最后一章的测试矩阵。并且在测试数据的准备上,为了避免缺陷的抗药性,可事先设计好较多数据,在使用时随机抽取。(在QTP中,可在需求中针对每一个控件录制对应的基础action,并扩展。而测试数据可在EXCEL中做好,使用时放于对应的脚本文件中,用local sheet使用。至于不同的控件在数据上的具体要求,可使用EXCEL中的VBA编程功能在使用时具体输入。QTP中这一数据与脚本分离的做法在数据的维护上确实方便很多~)
在单元测试的后期,可针对本模块内的业务流程设计一个全部使用正向数据的业务流程测试用例。这一用例也可由单一功能点用例组合而成~(在QTP中,可使用一些单一功能action来组合,或从新录制一个实际业务流程的脚本。这一脚本在以后的业务流测试时也可用到。)
在一些模块完成独立测试后,便可陆续集成。而模块间的具体数据传递亦可与用例分离,从而便于管理。(此时便可使用单一模块中录制的基础功能action 组合,并插入所需检查点来测试。比如使用一个“单据录入模块”的“新增单据”action和一个“基础信息管理”模块的“单据查询”action 来组合。而action间的数据的传递可使用global sheet来实现,而一些自定义变量则可以使用action的参数输入输出功能。)
系统测试时,针对不同的业务流程,便可使用单一模块中的那个模块内业务流用例来组合成整体的业务流。数据自然是从与用例分离的数据表格中抽取对应的真实数据~其他的如界面,兼容,安全等与主题无关就不细说了~(这里使用TD中的TESTLAB来组合业务流。数据也使用global sheet传递。)
另外,TD中的筛选功能可以对应到手工测试中的多种索引~而各种统计图表则可对应为针对不同细节采用有针对性的表现形式~
==================================================
欢迎观临我的博客浏览其他软件测试相关文章~http://xinghuaniu.blog.163.com/
===================谢谢观看~========================== |
|