用例设计心得~
我写的系统测试用例设计方法快要完工了，而做项目也做了一段时间了，也设计了些测试用例。突然有了一些灵感，我决定把它些出来。大家共享~~~~很多人现在为写测试用例而头痛，也有很多人现在为了维护测试用例而头痛，更有人为了看不懂别人写的用例而头痛……
我认为，解决的办法就是，规范公司的测试用例管理。包括需求的提取、用例的设计、数据的维护（注意：这里我说的是数据的维护，而不是用例的维护），为什么是数据维护而不说用例的维护呢？我是那么认为的——
要设计很标准的测试用例，写的很详细很详细，我想工作量太大了，而且维护起来会很烦，成本太高，不适合现在的国内企业。就好比国外企业已经是“大人”了，他们可以有足够的金钱时间资源来规范用例，而我们只是“小孩”，“小孩”的能力是有限的，要想做“大人”的事，基本是很困难的。我认为要结合我们自身的情况，制定一个合适本公司的合理的用例管理方法。
现在我就把我的一些想发说出来，大家可以一起讨论，我也只是脑子里刚冒出来的一个想法，请大家指正~~~
首先，测试用例的设计与执行，就是为了发现系统缺陷或是为了验证功能没有错误。也就是说，程序做了它应该做的事情，没有做它不应该做的事情。可见测试用例的设计，必须要能完整覆盖需求规格说明书中的所有需求。所以我认为，测试用例当作一个集合来管理，可能会更轻松。这里的集合，可以有几个，比如操作集合，数据集合等等。把测试数据和步骤分离开，管理更轻松点。具体情况还得到具体项目里考虑。
测试用例设计好了，也就是数据都设计好了，就要维护了。需求变更都遇到过，需求变更会导致测试用例的失效，也就是说，需求变了，测试用例也要进行相应的修改，不然，之前的测试用例就成了一堆废纸。如果用例都写的很详细很标准，到这里需求一变，可想而知用例维护难度有多大了。但如果测试步骤和数据分离开了，维护起来就不会那么困难，只要在步骤集合里加入步骤，在数据集合里加如测试数据，维护成本将降低很多。当然，步骤里的参数变量与测试数据集合里的参数变量名字一定要一样，才能便于维护。
具体就先说那么多吧~~有问题再大家一起讨论~！希望以后能有一个适合现状的管理产生，逐步转向标准~！ 我觉得你比喻的国外企业是“大人”，国内企业是“小孩”的说法很恰当。
但我们不能总当小孩，小孩的烦恼就是想盼着长大，而总是得慢慢等待。
但小孩终究要长大。
而且目前我们在测试中最大的困惑就是无法感受规范的流程，所以我们也需要长大。
页:
[1]
