文档测试如一个软件的help文档的测试用例应是什么样子的啊！

xianyuiou

要编写测试用例，到编写HELP文档的测试用例时，好像跟功能测试的格式不同。而且需求说的很泛泛，比如，哪里描述的准确了，之类的
请问这种TEST CASE应该怎么写！有个模板也好呀！

楠族开心果

根据版主的回答，我觉得help帮助里面我觉得应该有个导航栏，弄个查询（包括模糊查询吧）

Jackc

上面是一个嵌入式终端（你可以把它比作手机）的Help程序，和PC软件的有一些不同。PC软件的Help一般没有“关联程序功能”，因为每一个软件的Help基本都是独立的，在当前程序开启的help自然就是与本程序直接关联的文档。

1、可以从需求中看到，整个软件分为界面和功能两个部分。所以可以分为UI用例和功能用例两个大类。

注意这两类用例可能出现功能重叠的情况，有些公司就干脆把两类用例直接写到一起，这样做没什么问题。
不过我还是将它们分开，UI用例涉及到的功能部分，全部都只提及功能的基本流用例。
比如“主菜单UI检查”用例包含了一个用户最常使用的进入主菜单的功能用例：
前置：当前操作的应用程序配置了“帮助”文档（注意“当前操作的应用程序”，这样描述的用例往往通过被其他调用来实现用例的完整性）；测试终端已进入应用程序主菜单列表界面；

输入：
a、在应用程序的选项菜单中导航键选中“帮助”选项
b、按下OK键

输出：
a、进入与当前应用程序相关的help主菜单导航列表界面
b、列表显示的条目与当前应用程序相关
c、条目按照字母方式从a~z排序
d、标题状态栏显示“帮助”
e、默认高亮第一条导航条目
f、左下角显示“选项”按钮
h、右下角显示“退出”按钮

UI检查的用例大概就是这样，而功能用例则会包括的可选流程，还是以“进入help主菜单”的用例为例
用例1：如果当前程序的help是RTF格式而非XHTML格式时的用例（这里由支持的格式数决定用例数量）
用例2：通过点击方式进入UI主菜单的用例（用例数取决于进入方式的多少）
用例3：关联程序没有help文档的用例

在实际用例部署时，我们就可以把全部用例部署在阿尔法测试阶段，而贝塔测试阶段则只部署UI用例。（注意，就单help程序UI检查而言，每次只测试1~2个模块即可，比如在第20周期，只通过照相机检查相关的Help程序，而第21周期，则只检查浏览器部分的）

2、关联用例的使用技巧
关联用例也被叫做为“公共用例”，通常使用在某测试用例被反复多次使用的情况中。

help程序中，有很多“公共用例”，因为这个程序的初衷就是作为一个其他程序的支撑程序。
在实际设计中，我们可以这种方法来调用“公共用例”。还是以“进入help主菜单”为例，假设是照相机模块调用。
那么只需在照相机模块添加这样一条用例：
照相机_XX用例：参考“help_主菜单检查”用例（或者直接将整个用例复制过来也行，只需将“当前程序”改为“照相机程序”即可）

小结：我认为上面两点是help需要特殊对待的，其他地方应该和普通的阅读软件没有什么区别的，就不再罗嗦了::daxiao:::

Jackc

今天下午接到一个task，有点忙，明天再讨论用例设计的问题。

Help需求框架主要可以分为两部分：显示描述和功能描述

[ 本帖最后由 Jackc 于 2010-7-8 13:35 编辑 ]