测试用例制定原则和测试用例的重用

测试用例制定原则和测试用例的重用     软件测试

一、测试用例制定的原则

测试用例要包括欲测试的功能、应输入的数据和预期的输出结果。测试数据应该选用少量、高效的测试数据进行尽可能完备的测试；基本目标是：设计一组发现某个错误或某类错误的测试数据，测试用例应覆盖方面：

　　1、 正确性测试：输入用户实际数据以验证系统是满足需求规格说明书的要求；测试用 例中的测试点应首先保证要至少覆盖需求规格说明书中的各项功能，并且正常。

　　2、 容错性（健壮性）测试：程序能够接收正确数据输入并且产生正确（预期）的输出， 输入非法数据（非法类型、不符合要求的数据、溢出数据等），程序应能给出提示 并进行相应处理。把自己想象成一名对产品操作一点也不懂的客户，在进行任意操作。

　　3、 完整（安全）性测试：对未经授权的人使用软件系统或数据的企图，系统能够控制的程度，程序的数据处理能够保持外部信息（数据库或文件）的完整。

　　4、 接口间测试：测试各个模块相互间的协调和通信情况，数据输入输出的一致性和正确性。

　　5、 数据库测试：依据数据库设计规范对软件系统的数据库结构、数据表及其之间的数据调用关系进行测试。

　　6、 边界值分析法：确定边界情况（刚好等于、稍小于和稍大于和刚刚大于等价类边界值），针对我们的系统在测试过程中主要输入一些合法数据/非法数据，主要在边界值附近选取。

　　7、 压力测试：输入10条记录运行各个功能，输入30条记录运行，输入50条记录运行。。。进行测试。

　　8、等价划分：将所有可能的输入数据（有效的和无效的）划分成若干个等价类。

        9、错误推测：主要是根据测试经验和直觉，参照以往的软件系统出现错误之处。

　　10、效率：完成预定的功能，系统的运行时间（主要是针对数据库而言）。

　　11、可理解（操作）性：理解和使用该系统的难易程度（界面友好性）。

　　12、可移植性：在不同操作系统及硬件配置情况下的运行性。

　　13、回归测试：按照测试用例将所有的测试点测试完毕，测试中发现的问题开发人员 已经解决，进行下一轮的测试。

　　14、比较测试：将已经发版的类似产品或原有的老产品与测试的产品同时运行比较，或与已往的测试结果比较 。

　　说明：针对不同的测试类型和测试阶段，测试用例编写的侧重点有所不同。

　　1、 其中第1、2、6、8、9、13项为模块（组件、控件）测试、组合（集成）测试、系统测试都涉及并重点测试的方面。

　　2、 单元（模块）测试（组件、控件）测试：重点测试第5项。

　　3、 组合（集成）测试：重点进行接口间数据输入及逻辑的测试，即第4项。

　　4、 系统测试：重点测试第3、7、10、11、12、14项。

　　5、 其中压力测试和可移植性测试如果是公司的系列产品，可以选用其中有代表性的产品进行一次代表性测试即可。

　　6、 GMPS基础测试用例设计完成后，其他的测试项目只编写设计与之不同部分的测试用例。

　　7、 对于每个测试项目测试的测试用例不是一成不变的，随着测试经验的积累或在测试其他项目发现有测试不充分的测试点时，可以不断的补充完善测试项目的测试用例。

二、测试用例的重用

         跟测试工程师打交道最多的可能就是测试用例了，先设计出一些测试用例，然后这些测试用例要经过评审，之后要执行这些测试用例，完了以后还有可能需要对这些测试用例进行更新。测试用例的重用是一个很有必要的活动。那怎么重用呢？很多人可能第一时间想到了一些测试管理工具能帮上忙，例如Quality Center，Test Link；又或者是一些保存测试用例的工具，例如Word，Excel。

　　不过这些东西真的能帮助我们重用测试用例么？我想未必。测试用例的重用，应该是测试用例里面的设计思想的重用，而不是具体某个测试用例的，因为对于功能测试的测试用例来说，大多数的测试用例都跟某个具体的被测应用有想到大的关联性，例如要测试一个博客编辑器，对于MySpace的博客编辑器和 facebook的博客编辑器来说，它们的主要功能是相似的，都有发表博客，编辑博客，修改博客等……但是由于这是两个不同公司的产品，他们的具体功能或者UI是完全不一样的，所以拿到的两套测试用例，也应该是不一样的。如果分别提取出测试用例的核心思想（就是那些可以重用的部分），应该能看到很多的共同点，或许会有这么一条共同的用例思想。

　　1. 打开博客编辑器

　　2. 点击插入视频的按钮

　　3. 粘贴视频代码

　　4. 点击保存，发布

　　期望结果是该视频能正确显示在博客上。

　　这条用例可以提取为“验证博客编辑器能够插入视频”，至于实现的细节，可能两家的处理不一样，可能前者用<object>标签，后者用<embed>标签。回到实际的测试用例，前者可能要求将博客编辑器切换到HTML编辑模式下，要看到<object>….</object>的代码，另外一个就是要检查有<embed>….< /embed>的代码。其实测试用例是测试工程师之间的很好的沟通交流工具。通常在一些研讨会上，有人抛出一个问题“对于日期输入框大家会怎么进行测试”，大家接着七嘴八舌地进行讨论，这样的讨论结果就是大家都知道了一些，又好像不知道一些。如果这时候有人拿出自己的测试用例，那么会不会更加一目了然，更加有系统性？

　　举个例子

　　CRUD模式（创建，获取，更新，删除）

　　1. 选择并确定出一条记录或者一个字段

　　2. 产生一个随机的等价类item

　　3. 检查这个新产生的item是没有存在的

　　4. 添加一个新的item

　　5. 读取并且验证这个item的正确性

　　6. 修改该item并且验证item确是已经被修改

　　7. 删除该item并且验证item缺少已经删除

　　以上测试用例可以应用于不同的场景，例如MySpace中的一个帐号，也可以是一条歌单，还可以是一篇博客。这种类型的用例才是可重用的，而不是发布一篇博客，修改博客，删除博客……测试用例的重用，也就是测试用例的精华部分，其设计思想，而不是一些存在QC,TD中的 01010100101001。

原文转自：http://www.ltesting.net