欢迎大家给我个QTP测试设计思路（CRM中实践）
学习QTP也快一个月了，在论坛上面看了好多帖子，还有很多兄弟的帮忙，的确有了不少的进步。现在我在想一个问题，录制脚本、修改、回放脚本是根本不能满足一个系统的测试需求的，就连一个模块也让我难以对付。特别是现在公司做的一个CRM项目（个人感觉很适合用QTP,意思是在CRM系统中QTP能很大发挥其优势，而有些系统使用不使用效果差不多），鼠标点击、输入和查询，还有大量的check，如何的把一个模块手动测试能完成的QTP也全部执行没有遗漏，我想前期的设计是很重要的，现在我在自己公司开发的CRM系统中选了一个模块，根据测试用例我就录制脚本啊，可到最后每个action都显得那么的独立，而且还很混乱，搞得我两眼发黑，感觉好累好累，其中每个action难免也要进行相应的修改，到最后想用循环action调用，做一个调用把所有的整合到一起，我靠问题还真是多，算了还是一个一个的来吧，搞得我感觉比我手工测试麻烦多了。呵呵就此打住。看看我遇到的实际问题吧，大家畅所欲言啊，反正我是糊涂加受不了啦：如题：还是先看下图吧。
=========================================================================
上面的图片我想做个查询
问题出来了：
1.查询我最怕，有多少种组合啊，我的兄弟姐妹们啊，我的QTP跑的在快我也得去设计吧，设计多了麻烦少了达不到效果
？
2、我查询到的信息我怎么知道它是对还是错啊？假使我输入任何组合查询的结果都一样，意思是查询功能没做好，呵呵我假想的啊实际不可能啊，我怎么知道有逻辑性错误呢？
3、4、5.。。。。。。。。。。。。我就不说了累啊。
对了下面就你们说说吧就针对这个查询小问题，我们如何去设计自己的QTP脚本呢，用到完美自如。不然比手工测试搞得还麻烦，搞得信心全没。
嘿嘿，你们就与我分享下你们的经验吧，把测试进行到底！ 1.查询有多少种组合能够达到覆盖要求就不太了解了，当然是覆盖的越有效越好，这就看你自己写case的能力了
2.至于查询你的结果，我想这点还是能够考察的吧，例如：设置查询任务条件为“高”的项，系统执行后，写个for语句查list的“任务等级”column，如果是“高”--〉next；如果不是“高”，写log，如此可以吗？
3、4、5..... 哎！xiaoyaoke第一个问题回答等于没回答吗哈哈，第2个还有点靠谱，干嘛非要揪着人家的问题回答，发表一下QTP前期设计的思想吗，共享下吗？这块俺糊涂着呢！还是很感谢你哦这么给面子第一个捧场:handshake :lol 建议楼主不要想一口吃成胖子，要慢慢来，还不能急躁:lol
做自动脚本的开发，可以说工作量很大，甚至比手工花费的时间长的多，但是这是为后面做准备的。:)
你把你遇到的问题一一理清列出来，估计问题也解决不少了:) 呵呵，也是啊，性子的确是有点急躁，就是想学的快点好点。谢谢喽上的提醒！:) 还是想看看大家是怎么走过来的。免得自己钻牛角:) 1、这种查询不可能达到100%覆盖，选一些有代表性的就可以了。如果查询条件有个7、8项，每项又有N个选择项，这种情况可能都覆盖吗？
2、检查结果的正确性只能查询结果TABLE中的数据与数据库中的查询结果对比，没有其他办法，比较麻烦。 原帖由 sidneylover 于 2007-11-2 09:34 发表 http://bbs.51testing.com/images/common/back.gif
1、这种查询不可能达到100%覆盖，选一些有代表性的就可以了。如果查询条件有个7、8项，每项又有N个选择项，这种情况可能都覆盖吗？
2、检查结果的正确性只能查询结果TABLE中的数据与数据库中的查询结果对比，没有其 ...
说得很对，第一条！
第二条就只有一部分对，因为根本就不麻烦。
请楼主看我签名，100块钱可以达到这个水平。。。:lol :lol :lol
其实你的这个案例是很有代表性的。你可以选择测试全部数据，如果你的数据库中有足够的记录，还可以选择测试部分数据，但是有一条要保证，所有的可选择控件都要遍历。保证你的所有控件都有效。
把这个功能函数设计成可选择参数个数的，然后就可以选择查询条件的个数自由安排。 写一个Function就可以达到需求了，在点击"查找"按钮到页面同步后就开始调用Function，判断页面上显示的查询结果与数据库中实际存在的结果是否一致
Function的思路就没什么好说的了吧，应该都会比较清楚的；至于如何覆盖，那和这个子模块的脚本本身没什么关系了，只与你的测试用例相关 恩，关键我不知道数据库里面的东西怎么调出来和我页面上显示的去比较，还请赐教下。:lol 实在是初学者头痛，没想到拿到实际项目中问题这么多。俺不论开发还是测试工作也才半年呵呵，希望老大们不要嫌弃啊！ 访问数据库的问题已经有很多帖子都讨论过了的，你可以搜索老帖或者在精华区找找看
至于比较的逻辑，只要分别对页面上查询的结果与数据库中查询的结果做个遍历的一对一比较即可，建议逐条访问数据库中的查询结果，然后查找页面上是否存在这样一条结果，有其它需求(比如排序)可以再将其它限制条件。 从界面上看，这个查询条件应该全是“AND”的关系，所以测试重点在
1、单个条件设置时，查询的数据是否正确，因为只有“AND”的关系，单个条件正确了，组合在一些也是正确的。
2、多个条件组合时，是否有程序错误（组合成的条件语句有错）
3、应该有条件为必须设置的，比如时间范围条件，以这些条件的不同组合为重点，比如跨月、年；闰年等。如果时间有时分，就再组合时分。这方面，使用等价类划分和边界值的方法来设计，可以参考“软件测试”一书。
如何分析结果的方法就有很多了，简单的办法，在保存统一数据的情况下，并进行一个的数据设计（比如不同任务状态的任务数量不同），数查询结果的“个”数。
典型的测试设计问题
楼主的问题我想是很多自动化测试新手都会遇到的问题。谈到自动化测试就直奔主题，录制脚本、脚本修改实现等；而往往忽视了测试最重要的环节——测试设计。qtp两个重要的概念，数据驱动和关键字驱动。
第一个问题，关于组合查询的问题，我想楼上的各位都讨论的差不多了，属于用例设计的问题；当然不同的组合都应该对应不同的数据准备、操作和结果；注意：数据是准备好的，然后根据一定的逻辑，得到预期的结果；而不是查询现成的数据库就完了。
第二个问题：如何知道查询到的结果就是预期的结果？ 这个应该也不是自动化测试遇到的问题，我们手工测试时，是不是应该知道预期结果是什么？如何准备满足条件的数据，然后执行哪种情况的操作（查询条件），然后查询到的结果与预期结果比较，判断是否偏离。
手工测试与自动化测试的区别在于一个是将测试设计的内容手工实现了，一个通过代码运行给实现了。但是前提都是由测试设计的，哪怕这个设计只是在你的脑海里而没有落到纸面上，它也是存在的。
设计才是测试的灵魂，其他的工具或者方法都仅仅是实现设计的一种方法而已。 楼上各位的经验之谈，非常精辟，学习了。
对于表格数据的比较，我是这么做的，没有去数据库对比。大家觉得是否可行？
首先确保脚本录制时的查询数据是正确的，并以此作为检查点，以后每次运行将运行结果以此相比较进行判断即可。
可以做
:) 学习.了 咳.就没人谈谈怎么设计吗?我也是,现在觉得设计脚本都不知道从什么地方下手，自己能想到的根本都不能自己去实现,也不知道该去问谁好，公司除了开发都没人懂测试这块的这个了.而且也没时间上论坛发帖子求助了.....好心人谈谈怎么做设计吧..... :) 是啊，12楼的说的很有道理啊，前期的设计实在是太重要了，有效的设计更是难得。如何的把ACTION链接起来，如何的让自动化运行后能通过报告分析整个系统，这些现在我想只有我自己运行自己能看懂。其实这东西我也知道一两句话也是说不清楚的。慢慢体会和学习吧，呵呵！ 我也觉得，我们这里的大虾都交交我们这些新手怎么设计，这样我们能更快的入门。非常感谢！ 我还是 建议 从 查询出来的数据 与 系统 所在数据库数据进行 对比
来个数据库检查点 应该可以吧！
回复 12# 的帖子
我比较赞同12楼的看法，所有的WEB测试里面，最基本常用的就是NEW,MODIFY,DELETE 和 CHECK，我们手工测试的时候，不都是新建之后，查询新建的记录是否存在吗？然后根据需要修改、删除等等操作，其实都是和手工测试一样，只不过是通过代码实现我们手动做的事情而已！！
页:
[1]
2
