b/s结构信息管理软件，如何设计用例比较好
1。软件的每个子功能除了接口数据流以外，都是新增、查询、修改和删除。且每个子功能的界面类似。以前我的做法是针对每个功能分别界面、功能、接口用例。可是发现太多是重复性的工作，大家是如何做的？
2。查询页面有很多个查询条件，可支持单独查询，组合查询，精确查询，模糊查询，
请问用什么方法才不会遗漏多种组合起来的查询（包括精确和模糊，组合太多了） 1.Data-driven, disign a data-driven template/framework for generating different test cases
2.Actually, this kind of query-combination testing need to be focused on 2 aspects:
a. Verify whether the program constructs the SQL query string correctly according to your combinations
b. Verify whether the SQL queries leads to expected result set from the database 你要对所有功能进行归纳,总结,细分成各个测试子项,针对每个测试子项,运用用例的设计方法,进行用例设计.查询如果有多种情况下的话,可以运用正交试验法的思想来设计用例如果对正交试验法不熟的话,可以在本论坛搜相应的帖子,或搜＜软件测试概论＞这本书，在本论坛里也有．可以参考一下． 现在我的做法是,
1.界面的测试用例,分首页界面用例、新增界面用例、查询界面用例，修改界面用例，即相类似的界面只写一个界面用例，可是每个界面的输入栏位，字段长度（应该也算界面里的一种吧）都是一样的，又如何处理？
２。功能测试用例，即所有的新增用一个用例，所有的修改用一个用例。。。。。
３。功能模块数据流用例。。即模块间极模块内的数据调用用例。。。
４。对于查询，正在想办法考虑用因果图的方法。
大家有什么好方法，路过的都来说几句。。。。 个人意见：查询测试最佳的方式还是白盒单元测试，使用页面进行测试耗费的人工比较多。 请问当一个系统对安全性要求较高时，是采用B/S 结构好还C/S结构好？
TKS！ B/S结构的程序有它的特殊性，需要做三个方面的测试
1。 数据库功能测试：偶主的第二个帖子提到的算是这方面测试。
2。 网页操作测试：这是纯粹考虑到网页特性，包括以下几个方面
2。1 没有合适的理由就使用最新的网页技术（可能不稳定）
2。2 网页链接是否颜色一致
2。3。网页是否太长太宽
2。4 。对于网页内部功能，帮助指导信息是否完善
2。5。是否存在空链接
2。6。 网页内容是否显示正确（文字，图标，图像）
2。7。 组件是否工作正常，包括：下拉框每项是否都有效；复选框和单选框是否每项都有效；文字输入框有没限制输入长度；文字输入框是否许可输入非法信息（比如年份框内输入字母）
2。8。 SUBMIT是否工作正常。每个提交按钮是否都可以正常提交。
3。运行测试：主要指对系统的运行性能的测试，包括：
3。1。 最大可承受的用户链接多少
3。2。在最大量用户链接情况下，响应时间是否可接受
3。3。 能让系统运行满意的软件硬件最优配置。这个优点抽象，可以理解为：怎样设置服务器环境能让系统性能达到最佳（用户连接数最大，而且响应时间可接受）
3。4。 系统最低可在什么样环境（软硬件配置）下运行 每个方面具体哪些做，哪些不做，就根据公司所能动用的资源决定了。 楼上的说得不错,但似乎有点儿偏.
我发这个贴是想大家来讨论一下用例的精细程度及组织方式,大家知道B/S结构的软件,很多都是重复性的.
象界面上字段长度的检测等应该属于界面方面的测试,但是又跟功能揉合在一起的,是每个功能界面一个一个地写用例呢,还是只写一个共公的用例? 原帖由 archonwang 于 2006-6-5 21:29 发表
个人意见：查询测试最佳的方式还是白盒单元测试，使用页面进行测试耗费的人工比较多。
说实话白盒测试俺不会，但是又想把查询条件的各种情况都能测试到，还有别的方法吗？ 明白楼主的意思，我想补充完整b/s系统测试中经常被忽略的部分。b/s系统的测试常常存在重功能测试，而轻操作测试和性能测试的问题。
关于界面字段长度问题，可以归入界面操作测试的一个用例。执行这个用例的时候，测试人员不做别的，专门检察一个一个文本框的输入长度限制。
页:
[1]
