人手少，时间紧的情况下如何写用例？
我们公司一共4个测试人员，20多个开发人员，同时有7、8个项目测试，一直一来都不写测试用例，凭经验测试（根本没时间细写，写粗了也没用，而且也没需求文档做参考，就算写也是事后补，所以感觉写用例没作用）。目前公司项目也都是从老项目移植，改进，所以针对主要业务曾经写过用例，但写出来没人看，而且同样模块由于流程改了，用例也不完全适用，测试人员还是习惯拿着软件就开始测试，没有系统的分析阶段，容易测漏，目前不知道该如何办才好，望大家可出好的建议！ 1.在项目阶段就把用例时间计算进去。
2.跟领导提需要写用例的时间。
3.跟研发沟通。 既然当前情况不适合使用用例，则可以考虑使用其他方法代替用例。
如：测试点列表/模块功能树型图 都能实现用例的基本效果。而对前期准备的资源消耗也较小。
前提：4个测试中不能存在新手 谢谢JACKC的建议，能否说的详细一点，测试点列表/模块功能树型图如何做？
测试点列表：
按模块划分，每个模块保护增、删、改、查、翻页、排序的功能？这样列的话，如何体现分析？ 本帖最后由 Jackc 于 2011-2-15 16:56 编辑
1.check point
对于检查点列表，在坛子的很多帖子中都有涉及。它其实是标准用例的一个简化版本，甚至，你可以把它看作是用例的标题列表。
检查点最明显的特征，它通常没有具体的操作步骤，只是简单记录某一个需求功能需要测试。
————————
如下：简单列一组模块A的检查点（格式范例而已，无需考虑其覆盖性）
模块A主检查点子检查点（可选）三级检查点（可选）
增主界面“增加”按钮增加N组数据
增加字符/长度非法数据
“选项”列表中“新增”选项
“工具”列表中通过“模板”导入
删
改
如上，在实际测试中，通过对各个检查点测试结果的记录，就可以分析出实际测试中，哪些功能已经被测试，哪些功能需要增加测试强度（通常，一个检查点发现多个缺陷时，即表明这个检查点需要加强测试或继续细化），以及遗漏测试点等。
————————————————————————
针对检查点粒度的设计，它主要取决于执行测试员本身。如，对于一个经验丰富的测试员来说，若需在某个点进行容错测试，只需描述“非法/错误”等字样，他就能在实际测试中，完成多个容错测试；而若换成一个年轻的测试人员，则可能就需让其对检查点进行更详细后才能达到相同的效果。（当然，细化后的检查点由于无需设计测试步骤，较测试用例来说，体积还是苗条不少）
——————————————————————————————
2.功能树型图
树型图的结构设计方式很多，即可以按照需求文档来做，也可以按界面来做，当然，还可以按用例（检查点）结构来设计。具体怎么搭建树型图，还是得看设计者希望从图中得到什么。
如，按测试点布局，设计的树型图如下：
————————————————————————————
3.比较两种方法对测试结果统计的优缺点
单论测试结果记录，列表形式的检查点比树型图更快捷。
单论后期维护，列表显然比图形易于维护。
单论测试结果分析，树型图显然比检查点更便于快速阅读。
单论交互测试结果分析，树型图中，只需分析交互模块的线段即可。而使用列表的话，通常需要独立列出一组额外的检查点。（当然，也可以将交互部分放到具体模块的相关测试点中）
————————————————————————————
其实这两种方法都属于用例设计的变异，由于其设计粒度/规则与真实情况结合过于紧密，很难用精确的语言描述出其精髓，我也只是想到哪里说到哪里而已。（话说，单论标准用例的粒度，就是个相当复杂的问题了.....） 列检查点的方法不错！ 我们项目组的情况和这个类似，也是时间紧没有时间去写测试案例，结果公司还要来个案例评审，:funk:
现在也是列检查点的方法来进行测试，感觉功能树型图还不错~ 难道是同一个公司的？？？？ 这样确实省事多了
页:
[1]
