本人刚参加公司，求有关应用程序的测试用例的设计

小不点蜗牛 · 发表于 2010-5-27 12:42:05

如题，本人现在刚刚参加工作，刚接触一些应用程序的软件的测试工作请问高人指点，如何进行一般的通用的应用程序的测试用例的设计，就是你拿到一个应用程序软件，你一般的设计测试用例的思路，如何着手，如何进行分类设计，很希望高手同仁们，过来的朋友们，可以给予本人一些思路，再次先谢过了！！！！
本人这样理解测试用例的设计，不知可否：
可以讲一下通用的应用程序，例如一个迅雷客户端，我是先在主界面里面，给我们的菜单栏进行测试用例的一些设计，再设计主界面的工具栏的测试用例，再设计左面的一个窗口的测试用例，然后再设计中间的窗口的测试用例，之后再设计我们的一些其他的交互功能的测试用例，再然后设计我们的服务器性能的一些测试用例，再然后进行一些简单的猴子测试，不知道我的这个思路对于我的这个软件的黑盒测试工作怎么样？这只是本人的一些个人看法，还请高人指正，谢谢了！！！！

小不点蜗牛 · 发表于 2010-5-27 19:44:13

为什么没有人给我个回音啊，求大家了

Jackc · 发表于 2010-5-28 09:32:06

首先，其实好的需求文档本身就提供了一套较为完整的测试用例框架。

然后，如果抛开需求文档结构，则主要考虑通过划分子功能和各自优先级来搭建用例框架。至于怎么划分与组合，每个人的方式都不同，比如有些人喜欢按照不同界面划分，比如主界面有什么？一级界面有什么？；有些人喜欢按照功能分布区域来划分，比如上方Tool Bar提供了什么？中间的显示区域提供了什么？；还有的人喜欢按照功能实现来划分，比如怎么新建数据？怎么删除数据等等。

最好能根据软件实际情况来选择组合方式，当然，很多时候搭建框架的方式是混合型的，只是其中某一种方式占主导地位而已。

还是以迅雷为例，在脱离需求文档框架的情况下，最常使用的是功能点或界面逐级向下划分测试点的方式来构建整个框架：

首先，将功能测试、交互测试和性能测试这三个一级测试点划出来。（其后主要描述一些功能测试，其他两大测试就不涉及了）

然后，在功能测试上，可以分为：安装/卸载、运行两个部分。
对于任何软件，建议增加一个“风格”的部分。其主要职能是批处理软件中的各个公共模块和公共界面的测试。这部分用例可以先写一部分（可能一次性也不完整），在其后写其他部分用例的时候，再补充。

A、安装/卸载过程较为简单,主要是考虑正常流程、平台兼容、异常纠错以及一些后期维护升级等方面

B、Run是主要的测试部分，可以分为：未启动、运行中、启动/关闭

PS：你的这个问题有些复杂，昨天想了一些，今天刚起一个头，手里来了一个case，看下午有没时间把剩下的补齐

小不点蜗牛 · 发表于 2010-5-28 12:11:24

版主，我的想法跟你的大致一样，可以这样我总是感觉有点太一般了，好像不能最大的覆盖测试的路径，也应该找不到开发部的那边的一些确切的错误，因为软件在开发部那边一出手，他们就已经对于功能大致的进行了一些测试的工作，所以结果是执行了这些功能性测试用例后，仍然不能治根，所以也就找不到一些特别的bug了，版主，我不急，你帮我看看，我等你的回音，谢谢了！！！

小不点蜗牛 · 发表于 2010-5-30 18:31:38

版主，今天有空吗,帮我解决这个大难题吧。。。。。。。。我等你喔。。。。。。。。

Jackc · 发表于 2010-6-2 11:50:10

呵呵，蜗牛，看来你们公司确实很锻炼人，一年多的测试就已经在涉及测试框架和模式的东西了

测试用例对于新人来说是指导规范，对于熟手来说，更多的作用是构建框架，在宏观上控制整个测试执行，保证测试结果不远离测试目标。

测试用例设计的思想其实也只有普通的这几种，但是想把某一种做细，还是很难的。

现在我主要使用的还是NOKIA式的框架：

1、先划分不同的测试类。主要分为“应用”、“框架”和“附件”三部分
“应用”包括测试实体提供的各种独立的主要功能：比如迅雷的新建链接、设置等
“框架”包括UI风格和公共功能：比如编辑框、存储、查找、退出等
“附件”包括一些次要功能：比如广告栏、登录窗口

2、再根据划分好的不同测试类各自设计用例。
这时会出现很多用例出现相互调用的情况，比如，“应用”类新建链接的用例，必然会调用到“框架”类的一种编辑框（编辑框应该存在N种类型）。这里的预期输出就看实际项目对测试粒度的要求了，要求高，就直接套用编辑框的用例；要求低，可以忽略编辑框的测试，只测试新建部分的流程，而编辑框单独测试。

3、错误推断。
这个没什么好说的了，想到多少写多少吧。

至于“交互测试”部分，其实是通过第2点中对不同类型的用例调用处理来实现的。

小结：这种方法的好处在于可以细化需求，并在可控的范围内适当调整测试粒度的弹性。如果测试范围放大到整个产品，也同样可以使用这种方法设计产品测试的框架。
主要的缺点在于对第1点的要求比较高，要求设计人员很熟悉各个功能点，并能逐一列举出来。

当然，换成是对流程比较熟悉，也可以使用UML图来做一个路径覆盖，不过稍微大一点的系统流程都比较复杂，也需要逐层分步来做。