如何提高测试用例的复用性？（09-11-9）（获奖名单已公布）
在系统测试阶段编写的测试用例少则几百，多则过万，花费时间很多，而且有相当一部分用例只执行一两次，复用性不佳。这里想讨论一下如何提高用例的复用性，尤其是不同项目之间。
希望大家多谈谈实践和案例。
如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖yolander当当购物卡50元16#三等奖suncentre100论坛积分13#三等奖joycena100论坛积分 24#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
编写测试用例方法心得体会
51Testing第15期免费沙龙(测试用例设计)
加强测试用例在测试过程中的地位
更多内容请点击＞＞＞ 搞一个资料库吧 我觉得产品的用例是应该提高它的复用性
打个比方
产品版本1.0.0，
产品版本1.0.1是给A客户使用，产品版本1.0.2是给B客户使用，
在版本1.0.1，1.0.2中，大部分的用例同于1.0.0.他们的主功能是差不多的，所以主功能的用例应该根据同步更新，以提高复用性。 感觉是不是能把用例做成最小单元化，并对所有输入进行参数化，然后再采用调用单元用例的方式来进行用例的组合，这样，单元化的用例能得到最高的利用率，而情况多变的用例组合又能省时省力 主要是编写测试用例时注意分类，一般一个公司的开发人员编写的模块都有相似性，测试人员在参与测试的过程中可以记录一些开发人员编写共性，详细编写，然后作为公共测试用例。
对这些公共测试的编写就要编写的尽量详细。
对于一些逻辑性比较强的模块的测试用例则可以重点编写思路，对细节问题可以稍微简单一点编写。
这样既可以节省编写测试用例的时间，又可以增加测试用例的重用性 测试用例的复用一般根据软件系统的复用来定.
一开始,针对一个软件产品应有一个标准的测试用例库,这个作为基线版本.同软件产品一样,没有基准的软件产品也谈不上软件系统的复用,没有这个基准的测试用例库也谈不上测试用例的复用了.
当然这个测试用例库里面的测试用例应基于并且完全覆盖该软件产品的所有功能,用例的粒度不应过细,重点在覆盖所有功能点及业务流程,着重于测试范围的确定\测试方法的确定及测试目标.
对于不同的项目,基本都是基于软件产品的部分功能代码的复用及修改,加上个性化的需求的开发.这个时候抽取用例库中复用功能代码部分的测试用例,再加上重新编写新增功能及个性化需求部分的测试用例(这部分的测试用例一开始的粒度与抽取测试用例库中的用例粒度相似),构成针对与该项目的测试用例库,具体测试执行时再细化复用部分及新增部分的测试用例.
最后,通过多个项目的迭代,产品的业务功能逐步完善,测试用例的基线版本也逐步完善.
另,对于测试用例的归集需要考虑人力资源\时间资源\成本和最终的质量要求,尽量做到综合平衡这些方面的要素.
仅个人愚见而已.
[ 本帖最后由 断寒 于 2009-11-10 18:05 编辑 ] 不光是楼上所说的这样子，
最重要的是产品的复用性，
同样一款产品，买给了A单位，版本是1.0，紧接着还要开发2.0或者3.0的后续版本，那么之前的测试用例就可以按照测试用例的级别，挑选部分作为基线继承用例来使用。
如果没有上述原则的话，用例的可用性就不强了，也失去意义了！ 原帖由 zhang_yajin 于 2009-11-10 12:32 发表 http://bbs.51testing.com/images/common/back.gif
感觉是不是能把用例做成最小单元化，并对所有输入进行参数化，然后再采用调用单元用例的方式来进行用例的组合，这样，单元化的用例能得到最高的利用率，而情况多变的用例组合又能省时省力
呵呵,也就是相当于有些要做得和Java的接口一些,嗯...常用的东西单独提取,愚见 小公司的主要功能差不多,所以针对主要功能的测试用例,基本不用改.
不同客户的针对性的测试,只能借鉴,还有的东西,复用很难. 如何提高用例的复用性？
由于公司的软件产品，会存在公用性，提高测试用例的复用性很重要
1、用例要做到是设计出来的，而不是按步骤写出来的。
2、用例编写时，划分清晰的单元模块；对通用性高的模块独立设计；用例最好按优先级区分。
答 如何提高测试用例的复用性
我在公司也做过这方面的文档维护，也研究过测试用例的维护和复用性。下面发表一下自己的收获：
一、组织和编写良好的测试用例具有很强的可复用性，因此，在重复使用的过程中，需要对测试用例进行维护或者更新，测试用例不是一成不变的。在一个阶段的测试过程结束后，或多或少会发现一些测试用例编写得不够合理或缺少测试用例覆盖一些应用场景。而且，当下一个版本在测试中使用前一个版本的测试用例时，其中部分功能可能发生了改变，这时候也需要去修改那些受功能变化影响的测试用例，使之具有良好的延续性。通常情况下，测试用例需要更新，可能有以下几种原因：
1. 先前的测试用例设计不全面或者不够准确。随着测试的深入和对产品规格说明书的深入研究，对某些功能、特性、逻辑等的理解越来越清楚、深刻。
2. 所发现的严重的软件缺陷没有被目前的测试用例所覆盖。
3. 新的版本中有新功能的需求或者原有功能的增强而需要发生改动。
4. 编写的测试用例不规范或者语句错误。
5. 旧的测试用例已经不再适用，需要删除。
二、开发一个软件产品，会发布多个版本，伴随着测试用例的不断维护，测试用例也需要不断完善并与产品功能、特性的变化保持一致，从而使测试用例和产品版本相关联。在线软件服务中，用于不同的客户有不同的需求及定制，而且有些客户激进，有些客户保守，所以软件产品的多个版本常常共存，为不同的客户提供服务，这时测试用例多个版本并存。所以在新建、修改、删除测试用例时要十分小心，确定对正确的版本进行修改，不要错该其他版本的测试用例。无论是对软件产品还是软件服务，多个版本并存的可能性很大，而且可能为不同的主要版本发布不同的补丁包或小版本，这样早期的一些版本所拥有的测试用例还是有效的。
根据产品特性和一致性准则，测试用例的维护可以按下面几种情况分别处理：
1. 产品特性没变，只是根据漏掉的缺陷来完善测试用例。这时候，增加和修改测试用例均可，因为当前被修改的测试用例对相应的版本都有效，不会影响某个特定版本所拥有的测试用例。
2. 原有产品特性发生了变化，不是新功能特性，而是功能增强，这时候原有的测试用例只对先前版本（如 1.0、2.0）有效，而对当前新的版本（如 3.0）无效。这时，决不能修改测试用例，只能增加新的测试用例，不能影响原有的测试用例。
3. 原有功能取消了，这时只要将与该功能对应的测试用例在新版本上置为空标志或“无效”状态，但不能删除这些测试用例，因为它们对先前某个版本还是有效的。
4. 完全新增加的特性，很清楚，增加新的测试用例。
三、每个测试用例记录，针对一个有效版本都有对应的标志位，通过这个标志位，很容易实现上述维护需求。这样，新旧版本的相同测试用例得到一致的维护，测试用例数也不会成几倍、几十倍的增加，可以真正保证测试用例的完整性和有效性。
测试用例的维护是一项长期的过程。
[ 本帖最后由 sunlight0124 于 2009-11-12 22:46 编辑 ] 产品开发做好继承性…… 可以单独整理出一个常用基本功能的测试用例库。
一般情况下，可以将面对客户的项目分为以下两种，
一种是独立项目，完全由客户提出来的；
一种是公司推出的产品，根据客户需要进行的定制。
对于独立项目，比如web页面测试的增删改，
不同项目需要用到时候，可以拷贝过来，在此基础上进行修改，
这样，独立项目的基本用例库就可以得到有效的复用
对于产品定制的项目，整理出的基本功能的测试用例库，只需要基本功能。
因为产品的定制，基本上前提就是产品功能已经比较稳定，无需再对产品进行很细节的测试。
不同的项目，有它略微的需求不同，这个才是该项目的用例重点。
对于基本功能，只需要拷贝用例库的基本功能用例。
当然，如果产品有升级，需要及时更新这个基本功能的测试用例库。
另外，对于产品升级，产品升级的重点就是，本次升级需要改的功能块，以及会涉及到的相关功能的测试风险。
这个需要开发人员协助测试人员进行评估，确定测试重点模块。
编写升级用例，除拷贝基本功能的测试用例库外，需要对修改的功能模块和风险模块进行修改用例。
最后再提醒一句：升级完成后，别忘记及时更新基本功能的测试用例库哦。
总结为：对于客户需求项目，建一个通用的测试用例库；
对于产品相关的项目，建一个产品基本功能的测试用例库。
[ 本帖最后由 suncentre 于 2009-11-14 00:02 编辑 ] 先要整理出一个基本用例库，这个用例库涵盖项目的所有共同点，不同版本之间都可以调用基本用例库。
版本之间的区别可以根据需求进行用例维护，进行新增功能用例添加和需求用例添加。在以后版本测试中如果有相同功能的测试，就可以借用相应的测试用例，而减少用例编写的时间。 首先 测试的用例是针对产品的某一特性或功能而设置的，在编写用例的时候就尽量的不要将此模块的关联模块功能添加进来。将每一个测试用例都设定为单独的一个或一条特定的模块来对待。将测试用例都设计成为独立的个体。用例之间不具备耦合性，具有耦合性的地方 单独来设计测试用例。
其次 拿到软件首先先要分析软件中的哪些功能 或是模块在之前的测试中遇到了，并且有比较大的覆盖面的测试用例可以拿来使用，或是补充完善。
再次，测试用例可以建立起来一个用例库。就像bug管理一样，将用例也按照项目 功能 模块进行管理起来。用例库的完善和调用会方便大家之后的测试和新手的培训 对于测试用例的复用，我想很多测试工程师都会非常有话说，系统变更频繁，业务变化大，工作流不统一等等，很多现实存在的问题，都阻碍了测试用例的复用发展进程，但是金融风暴下，越来越多的IT公司都在为了降低成本而做不屑的努力，如解决方案的产品化、搭建软件系统的可复用平台、开发可复用的功能组件等等，毫无疑问的，这些都会为了我们能够提高测试用例的复用性打下了基础，抛开开发人员的因素不谈，而我们在这里也只针对如何从测试人员自身来提高测试用例的复用性来讨论吧：
这里需要首先区分一下，是手动测试用例还是自动测试用例？
一、对于自动测试用例，首先就是要改变脚本的开发方法，如：
1.数据驱动脚本：将测试数据从脚本中分立，保存在外部文件中，当数据发生变化时，就不再需要更改代码，脚本的维护成本也比较低
2.关键字驱动脚本：把脚本中的检查点和执行操作的控制都维护在外部文件中，同样的，数据也会与代码分离开，可以说是结合了数据驱动的脚本开发方法，提高了测试脚本的共享和复用，缺点就是脚本开发需要更多的编程经验和设计能力
二、对于手动测试用例，那么我们就需要解决如下问题：
1.测试用例管理工具：之前看到很多讨论，都没有提到这个，但我想说的是，工欲善其事，必先利其器，良好的测试用例管理工具，绝对会为测试用例的复用带来简单、方便和快捷，也比office文档更适用于测试用例库的建设和维护
2.测试用例的设计策略：测试策略无非有两种，基于功能和基于风险，之前也在论坛里提到过，还有筒子回贴说，测试策略就是基于功能的，这点我不敢苟同，基于风险的测试用例，往往才是最能被复用的，对于任何同类型产品来说，无论如何进行功能升级，其失效模式也一定大同小异，比如：汽车的失效模式之一——刹车失灵，这个不论是小汽车、三轮车、还是大卡车，都会存在同样的问题，但是功能和性能上，三者之间的差异就比较大了，所以我才会提到我们需要在测试开始前考虑这样一种基于风险的测试策略
3.业务抽象：对于测试来说，同样需要跟研发的系统分析师有相当水平的测试设计师存在，他们的工作职责是分析系统需求、抽象业务用例、设计测试方案来指导测试用例的进行，测试用例的复用也应该在这一环节被考虑，因为一条一条的去查找和审阅相同和相似的测试用例，对于庞大的系统来说，由于海量测试用例的存在，无疑为大海捞针，但是从更高层次的业务用例中去寻找相似性，一定是更快捷的方法，但这也同时需要清晰合理的、能够与分解后业务用例对应的、可跟踪可追溯的测试用例库结构，基于此，我才把管理工具放在了第一位
以上是我对于“如何提高测试用例复用性”的问题答案，其中不考虑“如何正确编写测试用例？”“如何进行测试用例设计”等问题 1.产品的继承一致性提高。
2.测试对象分门别类。
答 如何提高测试用例的复用性
前面13#和16#分别从项目性质和用例执行方式作了总结。个人想从测试的类型来说说，如功能测试，安全测试，本地话测试，安装测试来简单说下。写测试用例时，一定注明所属测试类型（功能，安全，本地，性能等），注明所属模块。对于功能测试用例，对于类似功能，则可以根据模块搜索出已有测试用例，进行复用。对于安全测试，本地化测试，安装测试等无非就是检查那几个方面，可以建一个公共用例库，不用太细致到细节。有需要到细节的到具体项目时再补充。
如果测试用例管理工具没有这两项，可以将这两项作为标题前缀。如：［功能］［登录］验证.....
到时直接根据标题搜索。 原帖由 lydia11 于 2009-11-19 14:20 发表 http://bbs.51testing.com/images/common/back.gif
前面13#和16#分别从项目性质和用例执行方式作了总结。个人想从测试的类型来说说，如功能测试，安全测试，本地话测试，安装测试来简单说下。
写测试用例时，一定注明所属测试类型（功能，安全，本地，性能等），注明 ...
这段话跟我上面描述的业务抽象比较类似，用例的组织结构跟业务相关，结构一清晰，下次查找就比较方便 觉得测试用例的复用性，目前比较容易实现的就是重用一些比较公用的测试用例吧。像一个新的模块，一般都会有查询，查看，编辑等页面，那么我们在设计新模块的测试用例时，是不是可以重用以前那些模块的一些测试用例呢？因为大家都有那几个比较常用的页面，而每个页面在大的方面的检查点都可能比较相似，只是一些很具体的检查点，功能点不同。那样就可以重用以前的一些测试用例，然后补充一下关于这个新模块的具体的一些功能检查点。
页:
[1]
2
