人手少，时间紧的情况下如何写用例？

zengli80

我们公司一共4个测试人员，20多个开发人员，同时有7、8个项目测试，一直一来都不写测试用例，凭经验测试（根本没时间细写，写粗了也没用，而且也没需求文档做参考，就算写也是事后补，所以感觉写用例没作用）。
    目前公司项目也都是从老项目移植，改进，所以针对主要业务曾经写过用例，但写出来没人看，而且同样模块由于流程改了，用例也不完全适用，测试人员还是习惯拿着软件就开始测试，没有系统的分析阶段，容易测漏，目前不知道该如何办才好，望大家可出好的建议！

yy100t

1.在项目阶段就把用例时间计算进去。
2.跟领导提需要写用例的时间。
3.跟研发沟通。

Jackc

既然当前情况不适合使用用例，则可以考虑使用其他方法代替用例。

如：测试点列表/模块功能树型图 都能实现用例的基本效果。而对前期准备的资源消耗也较小。

前提：4个测试中不能存在新手

zengli80

谢谢JACKC的建议，能否说的详细一点，测试点列表/模块功能树型图如何做？
测试点列表：
按模块划分，每个模块保护增、删、改、查、翻页、排序的功能？这样列的话，如何体现分析？

Jackc

1.check point
   对于检查点列表，在坛子的很多帖子中都有涉及。它其实是标准用例的一个简化版本，甚至，你可以把它看作是用例的标题列表。
   检查点最明显的特征，它通常没有具体的操作步骤，只是简单记录某一个需求功能需要测试。

————————
   如下：简单列一组模块A的检查点（格式范例而已，无需考虑其覆盖性）         

模块A	主检查点	子检查点（可选）	三级检查点（可选）
	增	主界面“增加”按钮	增加N组数据
			增加字符/长度非法数据
		“选项”列表中“新增”选项
		“工具”列表中通过“模板”导入
	删
	改

如上，在实际测试中，通过对各个检查点测试结果的记录，就可以分析出实际测试中，哪些功能已经被测试，哪些功能需要增加测试强度（通常，一个检查点发现多个缺陷时，即表明这个检查点需要加强测试或继续细化），以及遗漏测试点等。
————————————————————————
针对检查点粒度的设计，它主要取决于执行测试员本身。如，对于一个经验丰富的测试员来说，若需在某个点进行容错测试，只需描述“非法/错误”等字样，他就能在实际测试中，完成多个容错测试；而若换成一个年轻的测试人员，则可能就需让其对检查点进行更详细后才能达到相同的效果。（当然，细化后的检查点由于无需设计测试步骤，较测试用例来说，体积还是苗条不少）

——————————————————————————————

2.功能树型图

树型图的结构设计方式很多，即可以按照需求文档来做，也可以按界面来做，当然，还可以按用例（检查点）结构来设计。具体怎么搭建树型图，还是得看设计者希望从图中得到什么。

如，按测试点布局，设计的树型图如下：



————————————————————————————
3.比较两种方法对测试结果统计的优缺点

单论测试结果记录，列表形式的检查点比树型图更快捷。
单论后期维护，列表显然比图形易于维护。
单论测试结果分析，树型图显然比检查点更便于快速阅读。
单论交互测试结果分析，树型图中，只需分析交互模块的线段即可。而使用列表的话，通常需要独立列出一组额外的检查点。（当然，也可以将交互部分放到具体模块的相关测试点中）

————————————————————————————

其实这两种方法都属于用例设计的变异，由于其设计粒度/规则与真实情况结合过于紧密，很难用精确的语言描述出其精髓，我也只是想到哪里说到哪里而已。（话说，单论标准用例的粒度，就是个相当复杂的问题了.....）

xingyunshi

列检查点的方法不错！

测试你

我们项目组的情况和这个类似，也是时间紧没有时间去写测试案例，结果公司还要来个案例评审，
现在也是列检查点的方法来进行测试，感觉功能树型图还不错~

8463212

难道是同一个公司的？？？？

changlijuan

这样确实省事多了