测试Copy （拷贝文件或文件夹）函数时，如何设计测试用例？

819longjiayan

测试Copy （拷贝文件或文件夹）函数时，如何设计测试用例，测试点有哪些？请大家帮忙解答疑惑，尽可能多地覆盖到。
目前考虑到得一些测试点：
1.从函数本身出发，考虑copy的两个参数（是否存在，合法性，文件或文件夹名中英文情况，是否为空）
2.文件属性（权限，隐藏，大小）
3.位置（源文件/文件夹与目的文件/文件夹在统一路径下；多次拷贝，是否提示覆盖等）
4.异常中止情况，是否会做相应提示
5.重复调用copy函数，是否可用，是否支持多线程

暂时只想到这些，请大家多讨论讨论，给出尽可能多得测试点

Jackc

测试Copy （拷贝文件或文件夹）函数时，如何设计测试用例，测试点有哪些？请大家帮忙解答疑惑，尽可能多地覆 ...
819longjiayan 发表于 2013-4-21 22:22

首先，本来想直接弄一个模板照着说，可惜没有带U盘，只能全部手打。。。描述不清楚之处，还请见谅哈。

1. 建议无论针对任何测试目标，最好能弄一个通用的用例设计规范。也不用弄得太复杂，就是简单的测试思想指导手册就可以了。


-----------------------------------测试点只看分割出来的部分即可，其他都是废话
2. 以copy 函数为例：
   2.1。首先考虑函数的参数，最好先覆盖其基础标准是否实现（需求和设计文档已经有描述的要求，都作为第1优先级测试目标）。
          这部分最好根据设计文档来写，依靠设计文档中提及的各个API，设计专门的测试用例。建议以集成测试的方式来实现，这样可以将编/解码分开测试。当然，也可以在黑盒上去测试。只是需要将设计文档每个API的具体表现，转换到实际系统表层的可视输入/输出上来而已。
比如你已经提到的1.2两点，也涉及此类测试项:"1.从函数本身出发，考虑copy的两个参数（是否存在，合法性，文件或文件夹名中英文情况，是否为空）; 2.文件属性（权限，隐藏，大小）"
          如，一般函数都有两个通用的API，input/ouput。 将这两个属性放在一起写，写完后扔到整个用例组的两头就行了。(也可以把Input/output 写到1个用例里，这部分就看公司和个人喜好了)。同时，需求文档也要求了copy的某些对象属性，则可以视copy 函数执行的测试环境（Input条件）。如，文档的有效性属性：格式、大小、权限。。。

   2.2  然后可以从3方面铺开用例设计：
         A：细化参数属性，并分解为测试用例(此部分主要针对需求文档隐藏或未提及，但需要实现的参数属性进行验证)
              此部分为测试目标属性的增强型测试用例设计，主要是针对2.1的补充。简单分为以下几个部分
              ---文档属性(参考此函数具体需要实施的系统背景文档，如XP下执行，则参考XP文档的帮助文档)
              ---文档初始位置与copy目标位置属性（这部分可深可浅，如相同目录下的copy，又如，局域网之间的copy。故测试深度必须要和需求人员核实）
         B：场景用例组(这一部分仍为参数的有效性验证)
              此部分为非测试目标属性的测试用例设计。
              ---系统背景提供的copy Input/output 方式。如Input有鼠标/键盘。。。
              ---文档初始位置与copy目标位置的背景系统存在的限制权限。（此部分仍需参考系统背景文档，如XP常见文档限制：用户权限、重名、磁盘空间、目录层级、文档可执行性等。。另外，如果是跨系统复制，则需考虑文件有效性，如文件名字符类型。）
              ---系统背景提供的文件copy处理方式，此处主要指单个/批量
              ---文档copy传输方式(此部分仅仅限于copy函数支持多种传输协议时，进行场景性的支持和非支持验证)
              备注：B类和A类虽然在设计方法上侧重点不同，但仍会构造出相同的测试用例，故完成A.B后，需要进行一次用例整合。

         C: 异常用例组(此部分针对参数无效性验证)
              此部分为A，B两类测试的补充用例组，主要完成无效性的测试用例测试。（通常，为了保证此部分用例设计的覆盖率，我们也经常把它放到A，B类中，与A，B类共同组成1对1的用例组，即单个有效性属性必然会对应某个无效性属性）
              当然，某些日常的有效性属性，我们通常会忽视，导致此部分无效性用例无法很好的进行对应。
              如，copy 过程中的中断测试用例。其实它会对应“操作过程正常”这个有效性属性，但是通常我们不会专门描述这个有效性，导致容易发生容错场景的测试用例遗漏。
-----------------------------------测试点只看分割出来的部分即可，其他都是废话


小结：写了1堆，其实我只是想说2点：
第一，测试用例设计之前，最好做一个简单的测试大纲，无论好坏，都有利于将你的在整个测试用例设计过程中的各种思想统一起来，做到思维发散而不乱。
第二，功能再简单的测试目标，在没有约定测试环境的情况下，它的测试量是无穷大的。。。

819longjiayan

回复 2# Jackc


谢谢版主详细的回答，非常感谢