摘要：沸沸扬扬的诺顿误杀事件，其背后的原因是缺乏对软件的严格测试。在软件测试的价值不被认同的今天，诺顿“误杀门”给国内的软件企业敲响了警钟。软件测试的价值之一在于可以避免软件bug流落到用户手中，从而避免类似诺顿误杀事件给软件企业带来损失。

1. 诺顿误杀事件
诺顿杀毒软件自从进入国内以后，所受到的关注，全部加起来恐怕也不足这半个月多。一起“误杀”事件，将诺顿杀毒软件推上了舆论的峰顶浪尖，一时之间，“诺顿误杀”成为了所有媒体上出现频度最高的热门词汇。

事件的来龙去脉大家都已经耳熟能详了，据诺顿官方的公告称，赛门铁克最近在其病毒分析自动化系统中进行了一处改动，这却无意中引发了自动化系统中使用的一个简单定义发生变化，进而导致简体中文版Windows XP的两个系统文件被错误地检测为恶意软件。其结果是用户更新病毒库后，Windows XP因缺少系统文件而无法启动，直接引起Windows XP系统的崩溃。

其实，杀毒软件的误杀事件并不鲜见，笔者多年来使用过多款杀毒软件，还没有碰到过不误杀的。误杀是很容易理解的，在同质化竞争日趋激烈的杀毒软件市场，标榜自己能查杀多少种病毒，已经成为杀毒软件的宣传套路，谁要是少报了一个病毒，立刻失去用户的信任，遭到用户的抛弃，因此，为了在竞争中不落后于对手，杀毒软件们就都不约而同地采取了“宁可错杀一千，不可放过一个”的策略，如此一来，误杀也就不足为怪了。

只不过，诺顿这次运气不好，误杀了Windows XP的关键系统文件，而这些文件被误杀以后，症状也表现得相当激烈，显而易见的系统崩溃，连最不懂电脑的用户都可以马上看出问题，因此，诺顿此次误杀事件才被闹得沸沸扬扬。

事实上，误杀事件天天都在发生，尤其是自动化程度越高的杀毒软件，其误杀的概率也越高。病毒本身就没有一个准确的定义，有时候连杀毒软件专家也无法区分程序的行为到底是不是病毒行为，何况不具备任何智能的区区杀毒软件呢。聪明的杀毒软件，会在无法作出准确判断时将问题交给用户，让用户来决定采取什么措施，不过这会让用户感到烦恼，他们更喜欢一个在后台默默工作的杀毒软件，而不是时不时跳到前台提出一些愚蠢问题的杀毒软件。因此，高的自动化程度和低的误杀率是一对矛盾，所有杀毒软件都面临着如何平衡这一对相互矛盾的需求。

2. 误杀给诺顿带来的损失
从技术角度看，此次诺顿误杀并没有什么特别之处，和已经发生、正在发生或者将要发生的千千万万次误杀没有什么本质区别，不过，由于机缘巧合，诺顿在这次误杀事件中，伤得很重。

据诺顿官方公告称，从接到报告到发布最新定义的LiveUpdate更新，诺顿对误杀事件的反应可谓相当迅速，只有短短的4个半小时。不过，竞争对手比他们反应更快，这一不可多得的机会，被竞争对手迅速地加以利用了。在诺顿给出解决方案之前，包括瑞星、江民和金山在内的多家杀毒软件厂商，已经性急地发布了诺顿误杀事件的技术分析、应对方法、补救措施，并且非常热心不厌其烦地指导用户如何一步一步操作来从误杀中恢复。诺顿的误杀给了竞争对手一次很好的表演机会，可以肯定，会有一部分诺顿的用户转投竞争对手的阵营，而潜在用户在选择杀毒软件时，也会对诺顿心存芥蒂。诺顿多年来积累的市场占有率，将经受严峻考验。

更加雪上加霜的是，这次诺顿误杀的并非所有的Windows XP系统，而只发生在简体中文版的Windows XP上。中国是诺顿杀毒软件的一个重要市场，尤其是在企业客户上，诺顿的知名度最高，而这一块的利润收入，是最丰厚也最稳定的。中国是个迅速崛起的大国，中国市场的巨大容量，让任何杀毒软件厂商都垂涎不止，诺顿自然也知道中国市场的重要性。与市场容量日益扩大相伴随的，是中国消费者越来越挺起的腰杆，随着消费者权益的深入人心，中国消费者比以前任何时候都要挑剔，也比以前任何时候都容易“受伤”。此前发生的东芝、柯达、戴尔等事件中，国际厂商给予中国消费者的不公正对待，已经在民众心中转化成一腔怒火，随时都可能爆发。

由于误杀只存在于简体中文版的Windows XP，甚至和我们非常接近的繁体中文版都相安无事，中国消费者的民族情节又涌上在不少用户的心头。或许真的是一次巧合，或许诺顿确实漠视了中国消费者的正当权益，我们不得而知，但有一点是肯定的，诺顿如果不能妥善处理此次误杀事件给中国消费者带来的物质和精神上的伤害，中国消费者是不会轻易善罢甘休的。据报道，诺顿的态度在这短短的两周之内发生着戏剧性的变化，首次公告只是道歉，只字未提赔偿事宜，而几天后赛门铁克公司安全响应中心高级发展总监Vincent Weafer就已经松口，称目前的重点是帮助客户使系统恢复，而赔偿等问题，将在用户系统彻底恢复以后考虑。事实上，赔偿问题已经启动司法程序，据悉北京和广州有用户向法院递交了诉状，诺顿很快就会官司缠身。
3. 缺乏测试是误杀的原因
诺顿杀毒软件已经经营好几年了，是一款成熟的软件，笔者曾经在多年前使用过诺顿杀毒软件，许多大公司也都是诺顿的忠实用户，那块小小的盾牌，成为多少电脑用户信赖的标志。平心而论，诺顿杀毒软件的质量是值得信赖的，稳定、可靠以及适度的用户介入要求，基本上符合电脑用户对杀毒软件的期望。那么，这么一款多年来表现良好的杀毒软件，为什么会出现这次的误杀事件呢？缺乏测试应该是根本原因。

现代的杀毒软件，基本上由两大部分组成，一部分是程序，一部分是数据。程序是杀毒软件的主体，负责完成所有功能，而数据则是通常所说的病毒库，是杀毒软件厂商从各种渠道获得的病毒特征代码，杀毒软件程序正是依据这个数据来识别病毒的。
一般来说，杀毒软件程序部分是相对稳定的，而病毒库的更新则很快，有些勤快的杀毒软件公司，甚至数小时之内就会更新病毒库。如同任何商业软件发布之前必须经过测试一样，杀毒软件的每一个新版本，也需要经过严格的测试后才能发布。因为杀毒软件是由程序和数据组成的，所以，测试也包括对程序的测试和对数据的测试。不过，大多数情况下，由于被更新的只是数据即病毒库，所以一般只需测试数据是否正确就可以了，这种测试是相对比较简单的，所需花费的成本很小。

但是，如果杀毒软件的程序部分发生改变，那么，对杀毒软件新版本的测试就要复杂得多了。视程序部分更改的影响范围，可能需要对杀毒软件的某一特定功能、一部分功能或者全部功能进行重新测试，这时的测试工作量，要比单纯更新病毒库大得多。从诺顿官方公告对误杀事件的解释分析，此次诺顿杀毒软件的更新属于后一种情况，即杀毒软件程序的更新。显然，这个更新后的杀毒软件程序，是未经严格测试的。

为什么诺顿向用户发布一个未经严格测试的杀毒软件版本，我们从其官方公告中找不到答案，不过，以笔者从事测试管理的经验来猜测，不外乎无知或者无为两个原因。无知者不知道软件需要经过测试，当然，以诺顿的身份，我们可以排除这个原因，真正的原因应该是无为了。所谓无为，是指诺顿知道要测试，但出于时间或者成本的压力，诺顿没有这样做，或者做得不够充分。
从其他版本不受影响，仅简体中文版被误杀来看，测试做得不够充分是肯定的。或许是诺顿想要赶在竞争对手之前早点推出新版本，或许是软件测试的预算有限，又或许是诺顿心存侥幸，总之，新版本在简体中文版上的测试根本就没有做，因为这个bug太过明显了，只有做过测试，就一定能够发现。

至于为什么是简体中文版，而不是英文版、日文版甚至繁体中文版，只有诺顿才知道。是基于市场重要程度的考虑，还是基于法律环境成熟度的考虑，或者是基于用户维权意识淡漠与否的考虑，我们不得而知。我们希望这只是一个无意的巧合，而不是诺顿有意而为之。

测试用例标准

目录
1. 目的
2. 适用范围
3. 术语及缩略语
4. 测试要求
4.1  软件产品安装
4.2  界面测试用例
4.3  文件操作
4.4  图象处理
4.5  帮助
4.6  软件极限测试用例
 

1. 目的
 为了指导软件测试人员有效地设计测试用例，对所测试软件进行全面地测试，以尽可能发现最隐藏问题。
 
2. 适用范围
 适用于所有软件的测试。
 
3. 术语及缩略语
 本程序采用《质量手册》中的术语和缩略语及其定义。
 
4. 测试要求
4.1  软件产品安装
4.1.1  SETUP程序的运行
 安装主画面上的软件名称及版本信息是否正确
 更改安装程序提供的缺省安装进行安装，程序是否能正确运行
 记录用户姓名及组织机构名称操作是否正确
 程序安装结束语是否正确
 程序组的建立是否正确
 程序项的建立是否正确
 在所有能中途退出安装的位置是否能正确退出安装程序
4.1.2 程序组信息
程序组信息是否正确
程序组文件的建立是否正确
4.1.3 程序项信息
 所建程序项个数是否正确
 各程序项名称是否正确
 各程序项文件是否能正确启动
 配置文件的更新
 各相关配置文件的修改、更新是否正确
4.2  界面测试用例
4.2.1 窗口
 窗口在屏幕上的显示位置是否正确、美观
 窗口标题是否正确
 窗口中各对象位置是否正确、美观
 窗口的系统菜单及按钮操作是否正常
 窗口在各种不同分辨率下是否能全部显示
4.2.2 菜单(Menu Bar及Menu Item)
 菜单是否显示正确
 菜单项文字意义是否明确
 主菜单条上各项是否均有快捷方式
 主菜单条上各项的快捷方式是否有效
 下拉式菜单中各菜单项显示是否正确
 下拉式菜单中各菜单项文字意义是否明确
 有快捷方式的下拉式菜单项的快捷方式是否有效
4.2.3 工具条(Tool Bar)
 工具条显示的位置是否正确
 工具条中各项必须均有浮动说明
 工具条中各按钮必须有按下和抬起两种状态
 可移动工具条在窗口边际位置其形状及位置的相应变化是否正确
 工具条中开关按钮、按钮组及List Box对象必须有缺省值
4.2.4 状态条(Status Bar)
 状态条显示位置是否正确、美观
 状态条内状态信息显示是否根据操作而变化
 状态条内状态信息是否正确
 状态条内状态信息文字是否正确、意义是否明确
4.2.5 对话框(Dialog Box)
 对话框弹出时机及位置是否正确
 对话框内各对象位置是否正确
 对话框内各对象的文字标题意义是否明确
 模式对话框和非模式对话框的属性是否正确
4.2.6 消息框(Message Box)
 弹出时机及位置是否正确
 信息意义是否正确、意义是否明确
 弹出时必须锁住Mouse消息和键盘输入
 必须有正确的对象用于退出Message Box
4.2.7 列表框(List Box)
 列表框显示及位置必须正确、美观
 列表框应有缺省值
 列表框内可选内容必须全面
4.2.8 Redio Box
 显示位置要正确
 文字意义要明确
 Redio Box的成组关系要正确、选择必须互斥
4.2.9 文字Label
 显示位置要美观
 文字意义要明确
 同一界面上字体及字体大小应统一、美观
4.2.10 文字Button
 显示正确且意义明确
4.2.11 图象Button
 应相应的文字说明或意义明确
 应有按下和抬起两种状态
 在界面中所处位置要美观
4.2.12 输入域
 字符输入域
为空
任意字符串(中英文)
功能键及符号键
超界字符串的处理
 时间输入域
 字符串输入域的测试用例
 各种时间表示格式的输入(美国方式及中国方式等)
 整型数字输入域
 字符串输入域的测试用例
 浮点数输入
 超界值处理
 负值输入
 各测试用例中数值在所处输入域中是否有意义
 浮点型数字输入域
 整型数字输入域中的测试用例
 超长浮点数输入
4.2.13 显示域
 显示域中各对象显示位置正确、美观
 显示域中文字Label信息正确
 显示域中文字Label字体及字体大小应统一且美观
 显示域中显示信息应与输入的信息一致
 在屏幕显示不下时，应增加滚动条以确保信息显示的完整
4.3  文件操作
4.3.1 文件打开
文件打开操作通常弹出文件打开对话框，文件打开对话框适用对话框的全部测试用例。此外，文件打开对话框中必须包含驱动器选择域、路径选择域、文件类型选择域及用于编辑和显示文件名的文件名编辑域。文件打开操作适用以下测试用例：
 驱动器选择是否正确
 路径选择是否正确
 文件类型选择是否满足要求且应有“所有文件*.*”选项
 文件列表中显示是否根据驱动器、路径和文件类型的变动而改变且显示内容是否正确
 文件名编辑域中是否正确显示了所选的文件
 在文件名编辑域中手工输入文件名
 在文件名编辑域中手工输入非法或不存在文件名时，必须显示相应的错误信息
4.3.2 文件保存
文件保存操作通常弹出文件保存对话框，文件保存对话框适用对话框的全部测试用例。此外，文件保存对话框中必须包含驱动器选择域、路径选择域、文件列表及用于编辑文件的文件名编辑域。也可包含文件类型选择及文件备注等对象。文件保存操作适用以下测试用例：
 驱动器选择
 路径选择
 文件名编辑
 当从文件列表中选择一已存在的文件时，应提示用户是否覆盖已有文件
4.3.3 文件另存为
 文件另存为操作适用文件保存的全部测试用例
4.3.4 打印输出
 使用打印机或绘图仪输出时，输出结果是否正确
 横向输出和纵向输出 是否均正确
 打印过程中是否能终止打印
4.4  图象处理
 是否允许多种格式文件
 执行各种图形操作之后，执行Undo能否正确恢复
 图象/图形放大或缩小之后是否失真
 具有命令行窗口和菜单窗口两种操作方式时，在不同窗口执行同一种操作得到的结果是否一致
 执行工具条上的各选项能否得到正确的结果
4.5  帮助
 是否具有在线帮助
 帮助的内容是否正确
4.6  软件极限测试用例
4.6.1 所有可输入域的极限输入
 仅可以输入数字的地方是否可以输入其他字符，如字母
 打开文件中是否打开非标准的文件类型
 是否有对输入值的限制，包括建库时最大可以建多少个
 输入文件大小的极大值
 口令输入中可允许的各种标识符的各种组合
 输入为空的情况
 同名输入的情况
 非法用户的判断
 是否可以删除管理员的权限，用户等
 输入文件名长度的最大值(是DOS格式还是WIN95格式...)
 日期类型输入域中输入不符合日期格式的内容
4.6.2 窗口界面对象的极限输入
 水平和竖直滚动条的快速滚动
 通过输入达到一定程度实验水平和竖直滚动条是否起作用
 仅可单击的CommandButton的多次连击
 最多可以打开多少个窗口
 窗口下分类级别最大值
 测试选用各种字体及大小系统相应的运行情况
4.6.3 恶劣软硬件环境下软件运行情况的测试
 客户端在最低硬件配置下，如系统要求最低为128M内存，500M硬盘，800x600x256低分辨率显示的情况下，低网络传输速率，服务器端高负载，多用户的情况下
 在多任务情况下软件的运行情况
 掉电的保护及恢复能抢救多少数据
 退出时是否让用户保存已做的工作，如废纸篓中的内容是否提示用户保存
4.6.4 系统安全及保密性的测试
 是否有系统允许的但又不利于信息系统安全的行为，如关联一编辑器，在其中可以另存读入的文件
 是否有不适当的链接操作
 设定的权限是否准确有效，是否可以利用该权限做其他事情
 安全措施是否有效如口令加密措施是否可以被破译

摘要：高手过招，手中无需用剑，只要轻描淡写地以口代手，三两句话便高下立判，胜者胜得痛快，输者也输得潇洒。然而，除了在武侠小说之内，恐怕很难有地方让你感受到这种“会当凌绝顶”的痛快。本文根据作者在测试工作中的体会，提出了一种被称为“测试用例预演”的方法，用模拟的测试用例执行发现程序中潜在的问题，这种方法究竟有何神奇呢？请见内文。

    武侠小说中的高手大抵有三个层次，第一个级别是“静若处子，动如脱兔，身负成名绝技”的高手，印象中这一个级别的基本是杀手或是性情豪爽的江湖侠客，这种人一旦遇到，打杀的场面最为宏伟，刀枪之声不绝，各出奇招，直到一方倒地或是被制；第二个级别是“落叶飞花，片叶支花均可伤人”的高手，这个级别的高手相遇，少了宏伟的场面，却在看似不经意的凝重中展开残酷的厮杀，胜负只在一念之间；第三个级别的高手寥寥无几，多是成名已久、文武双修的名宿，已至“手中无刀，心中无刀”的最高境界，这种高手若是过招，全不闻金戈之声，全无杀伐之意，轻描淡写的以口代手，三两句话便高下立判，赢的赢得痛快，输的输得潇洒，在武侠中看到此，常不免心潮澎湃，艳羡不已，巴不得自己也能有这个机会一尝绝顶高手之间的这种至高默契。可惜身为开发或是测试工程师，又出生在这个真实的世界，恐怕实在是不太会有机会领会这种至高的境界。

    所幸，我们虽不能飞进武侠小说尝试这种生活，却能在我们的测试工作中体会到这种乐趣。真耶？假耶？且与我一起，探究个究竟。

    回到我们的题目“高手过招的乐趣 —— 测试用例预演”，这里我要提出的是一种可以让你体会到高手过招乐趣的方法：“测试用例预演”。且慢试图在头脑中搜索你对这种方法的印象，因为这是我自创的名词（申明：如果很不幸你通过其他途径确实听到或是见过这种描述，请一定告知本人，本人会慎重考虑，至少到目前为止，我还能有把握地说这是我首先命名和以正式文档描述的一种方法）。之所以把这种算不上十分复杂的方法写下来，是因为本人在实际的工作中发现该方法确实能起到比较大的作用，而且更重要的是，那种高手过招的感觉，很希望能和更多有高手梦的朋友能够感受得到。

    测试用例预演是一种非正式的测试用例执行方法，概括说来，这种方法是无需通过测试用例的真正执行（静态或是动态执行），而只需要开发人员和测试人员之间的口头交流，就能发现被测系统中存在的问题。设想一下，无需动手（测试执行），通过以口代手（开发和测试人员之间的口头交流），就能实现我们的目标（发现缺陷），这不是高手过招是什么？

    l     测试用例预演的一般步骤是：测试工程师与开发工程师以某种方式坐在一起，进入交流状态，这个过程中需要尽可能避免干扰，比较好的时机是坐在一起进餐的时候；测试工程师根据测试用例进行提问，甚至可以临时扩展测试用例，但要注意三点：1）。 不要偏离测试用例太远，以免偏离实际的业务；2）。可以考虑一些在测试用例中没有明确写明的异常情况处理；3）。提问的方式是“如果我这么操作，你的系统会如何反应？”；开发工程师根据测试工程师的问题，做出应答，对每个问题都只需要回答系统的响应即可，不需要描述具体的实现方法；测试工程师仔细聆听开发工程师的回答，需要对开发工程师的答复敏锐反应，不放过任何一个开发人员的迟疑，对拿不准的问题应该记录并需要马上验证；双方继续预演直到预期的预演时间结束或是有一方感到疲倦；记录预演过程中发现的问题到缺陷跟踪库。

    当然，要说明的是，参与交流的开发和测试工程师不是比武双方，真正的敌人只有一个：系统的缺陷，这点务必要牢记，以免弄错了对手，伤了和气。

    测试用例预演不是一种复杂的方法，但根据我的经验，要想在实际工作中应用这种方法并取得较好的效果，必须了解这种方法的适用范围，遵循一定的使用方法，并需要注意一定的技巧。这里我以FAQ的方式提供秘笈一部，各位请留意：Q：测试用例预演可以取代测试执行吗？

    A：这个问题是我捏造出来的，我想大概不会有人真的这么认为：），不过在这个问题的回答中，我希望能尽可能准确地描述测试用例预演方法的适用范围：如前面所提到的，测试用例预演是一种“虚拟”的测试用例执行方法，因为主要是通过口头交互的形式，也就限制了该方法适用的深度，一般来说，针对业务逻辑的较为直观的用例可以采用这样的方法，尤其是那些涉及大量用户复杂交互的用例，采用这种方法非常有效，测试工程师模拟用户或是设备提出各种可能的正常异常情况，很容易发现程序处理中的漏洞。但是，对于那些需要涉及大量地层处理的用例，测试工程师一般不太可能对其机制了解得十分清晰，因此采用这种方式也很难发现问题。

    Q：测试用例预演可以在哪些场合下使用？

    A：测试用例预演的应用场合没有特殊要求，但至少要保证是一个适合双人沟通的场合，没有过多的被打扰，双方都处在能积极思考的状态，这样就可以了。根据我的经验，一起就餐、双方暂时没有明确的工作内容，或是在对设计进行非正式评审的时候是一个比较好的时机，但还要充分考虑双方的喜好，譬如，有人不喜欢在吃饭的时候展开讨论。总之，一个适合双人沟通的场合是最低要求。

    Q：测试用例预演方法可以用在其他地方吗？

    A：中子炮刚发明的时候，科学家们狂热地将中子炮对准任何可以找到的东西；按照这种趋势，测试用例预演方法也必须要考虑是否可以应用在其他地方：）实际上，预演这种方法在评审或是思维游戏的过程中一直都是被广泛应用的，测试用例预演只不过将预演这种方法用到了以往需要真正执行的领域中，除了在测试执行环节，设计评审过程中我们也可以采用这种方法针对设计进行审查，关键在于提问的技巧：“如果我们这么做，你的设计将会怎样反应？”。

    Q：好像我用测试用例预演方法很难达到预期的目标？

    A：测试用例预演方法并非不需要前提条件，至少要保证以下条件才能使测试用例预演发挥较大的作用：开发工程师具有良好的配合意识；测试工程师对产品具有良好的熟悉程度；提问者的提问必须从“如果我这样做，程序会怎样反应”开始；参与预演的开发工程师对用于预演的用例涉及的模块要非常熟悉；其中，测试工程师对产品具有良好的熟悉程度是非常必要的，测试用例预演的主要对象是针对业务逻辑的用例，这就要求测试工程师熟悉产品，熟悉业务。所谓“棋逢对手”，至少要能和开发工程师是一个级别上的。另外，参与预演的开发工程师必须对用于预演的用例涉及的模块很熟悉，如果参与预演的开发工程师是模块的开发者自然没有问题，如果不是，就要求开发工程师必须能够准确了解模块的行为和实现。

    Q：测试用例预演发现的问题需要记入缺陷库吗？

    A：答案是肯定的，测试用例预演是一种“虚拟”的测试执行，预演过程中发现的问题同样要被记录、跟踪。当然，为了标识测试用例的发现阶段，可以专门在缺陷管理系统中增设一个“预演”阶段，统计预演在缺陷发现方面提供的效果。

    Q：如果开发人员不配合，怎么办？

    A：这个问题……我只能说具体问题具体分析了。关键是弄清楚开发人员为什么不配合，可能是开发人员个性羞涩，不喜欢这样面对面的交流方式；也可能是开发人员觉得这种方式浪费时间；又或者是开发人员对测试人员抱有不信任的态度。不管怎样，发挥你的个人所长，让开发人员放下顾虑和成见，认识到这种做法能给他和项目带来的好处，自然可以解决这个问题。

    Q：还有哪些在测试用例预演过程中应该主要的问题？

    A：当然还有一些需要注意的问题，沟通的技巧、对对方反馈的及时分析等等，这些都可以在实际运用测试用例预演方法的过程中逐渐体会。我总结的几点需要注意的问题包括：对每一个开发人员的犹豫都不能放过，一个犹豫很可能就是一个缺陷隐藏的地方；如果可能，最好能和开发人员一起，确定那些不确定的问题，以防开发人员一时马虎放过了本来存在的问题；预演的方式不适合在正式评审会议上应用，因为预演主要是两个人之间的协同思考，在正式评审会议上容易浪费其他人的时间；预演时要注意记录，头脑风暴产生的火花如果不及时记录的话，很可能会在短时间后被遗忘。

软件测试用例是为了有效发现软件缺陷而编写的包含测试目的、测试步骤、期望测试结果的特定集合。正确认识和设计软件测试用例可以提高软件测试的有效性，便于测试质量的度量，增强测试过程的可管理性。

    在实际软件项目测试过程中，由于对软件测试用例的作用和设计方法的理解不同，测试人员（特别是刚从事软件测试的新人）对软件测试用例存在不少错误的认识，给实际软件测试带来了负面影响，本文对这些认识误区进行列举和剖析。

    误区之一：测试输入数据设计方法等同于测试用例设计方法

    现在一些测试书籍和文章中讲到软件测试用例的设计方法，经常有这样的表述：测试用例的设计方法包括：等价类、边界值、因果图、错误推测法、场景设计法等。这种表述是很片面的，这些方法只是软件功能测试用例设计中如何确定测试输入数据的方法，而不是测试用例设计的全部内容。

    这种认识的不良影响可能会使不少人认为测试用例设计就是如何确定测试的输入数据，从而掩盖了测试用例设计内容的丰富性和技术的复杂性。如果测试用例设计人员把这种认识拿来要求自己，则害了自己；拿来教人，则害了别人；拿来指导测试，则害了测试团队。听起来似乎是“小题大做”，但是绝不是“危言耸听”。

    无疑，对于软件功能测试和性能测试，确定测试的输入数据很重要，它决定了测试的有效性和测试的效率。但是，测试用例中输入数据的确定方法只是测试用例设计方法的一个子集，除了确定测试输入数据之外，测试用例的设计还包括如何根据测试需求、设计规格说明等文档确定测试用例的设计策略、设计用例的表示方法和组织管理形式等问题。

    在设计测试用例时，需要综合考虑被测软件的功能、特性、组成元素、开发阶段（里程碑）、测试用例组织方法（是否采用测试用例的数据库管理）等内容。具体到设计每个测试用例而言，可以根据被测模块的最小目标，确定测试用例的测试目标；根据用户使用环境确定测试环境；根据被测软件的复杂程度和测试用例执行人员的技能确定测试用例的步骤；根据软件需求文档和设计规格说明确定期望的测试用例执行结果。

    误区之二：强调测试用例设计得越详细越好

    在确定测试用例设计目标时，一些项目管理人员强调测试用例“越详细越好”。具体表现在两个方面：尽可能设计足够多的设计用例，测试用例的数量阅读越好；测试用例尽可能包括测试执行的详细步骤，达到“任何一个人都可以根据测试用例执行测试”，追求测试用例越详细越好。

    这种做法和观点最大的危害就是耗费了很多的测试用例设计时间和资源，可能等到测试用例设计、评审完成后，留给实际执行测试的时间所剩无几了。因为当前软件公司的项目团队在规划测试阶段，分配给测试的时间和人力资源是有限的，而软件项目的成功要坚持“质量、时间、成本”的最佳平衡，没有足够多的测试执行时间，就无法发现更多的软件缺陷，测试质量更无从谈起了。

    编写测试用例的根本目的是有效地找出软件可能存在的缺陷，为了达到这个目的，需要分析被测试软件的特征，运用有效的测试用例设计方法，尽量使用较少的测试用例，同时满足合理的测试需求覆盖，从而达到“少花时间多办事”的效果。

    测试用例中的测试步骤需要详细到什么程度，主要取决于测试用例的“最终用户”（即执行这些测试用例的人员），以及测试用例执行人员的技能和产品熟悉程度。如果编写测试用例的人员也是测试用例执行人员，或者测试用例的执行人员深刻了解被测软件，测试用例就没有必要太详细。而如果是测试新人执行测试用例，或者软件测试外包给独立的第三方公司，那么测试用例的执行步骤最好足够详细。

    误区之三：追求测试用例设计“一步到位”

    现在软件公司都意识到了测试用例设计的重要性了，但是一些人认为设计测试用例是一次性投入，测试用例设计一次就“万事大吉”了，片面追求测试设计的“一步到位”。

    这种认识造成的危害性使设计出的测试用例缺乏实用性，或者误导测试用例执行人员，误报很多不是软件缺陷的“Bug”，这样的测试用例在测试执行过程中“形同虚设”，难免沦为“垃圾文档”的地步。

    “唯一不变的是变化”。任何软件项目的开发过程都处于不断变化过程中，用户可能对软件的功能提出新需求，设计规格说明相应地更新，软件代码不断细化。设计软件测试用例与软件开发设计并行进行，必须根据软件设计的变化，对软件测试用例进行内容的调整，数量的增减，增加一些针对软件新增功能的测试用例，删除一些不再适用的测试用例，修改那些模块代码更新了的测试用例。

    软件测试用例设计只是测试用例管理的一个过程，除此之外，还要对其进行评审、更新、维护，以便提高测试用例的“新鲜度”，保证“可用性”。因此，软件测试用例也要坚持“与时俱进”的原则。

    误区之四：让测试新人设计测试用例

    在与测试同行交流的过程中，不少刚参加测试工作的测试新人经常询问的一个问题是：“怎么才能设计好测试用例？”。因为他（她）们以前从来没有设计过测试用例，面对大型的被测试软件感到“老虎吃天，无从下口”。

    让测试新人设计测试用例是一种高风险的测试组织方式，它带来的不利后果是设计出的测试用例对软件功能和特性的测试覆盖性不高，编写效率低，审查和修改时间长，可重用性差。

    软件测试用例设计是软件测试的中高级技能，不是每个人（尤其是测试新人）都可以编写的，测试用例编写者不仅要掌握软件测试的技术和流程，而且要对被测软件的设计、功能规格说明、用户试用场景以及程序/模块的结构都有比较透彻的理解。

    因此，实际测试过程中，通常安排经验丰富的测试人员进行测试用例设计，测试新人可以从执行测试用例开始，随着项目进度的不断进展，测试人员的测试技术和对被测软件的不断熟悉，可以积累测试用例的设计经验，编写测试用例。

【简介】

   10月底美国硅谷的软件安全领军企业Fortify Software发布了Fortify SCA 5.0版本。Fortify SCA是业界公认的最佳源代码安全扫描软件，并多次获得Jolt与C Award等大奖。该软件是一强大的代码静态分析工具，可以帮助企业减少自主开发的应用软件中的安全漏洞。Fortify SCA 5.0更是增加了一些新的功能设立了业界的新标准。

   10月底美国硅谷的软件安全领军企业Fortify Software发布了Fortify SCA 5.0版本。Fortify SCA是业界公认的最佳源代码安全扫描软件，并多次获得Jolt与C Award等大奖。该软件是一强大的代码静态分析工具，可以帮助企业减少自主开发的应用软件中的安全漏洞。Fortify SCA 5.0更是增加了一些新的功能设立了业界的新标准。

这些功能包括：

　　以向导驱动的定制安全规则，使得非软件开发人员可以方便使用。

　　一体化的产品使跨国软件开发团队可以协作开发

　　提供针对应用软件安全的新型漏洞的保护措施

　　增加对开发语言和支持，分次提供PHP、Java scrīpt 、Classic、ASP/VB scrīpt（VB6）、COBOL的支持。

　　Gartrer 组织2007年5月发表的题为“市场定义和源代码测试工具选择标准”一文中指出：企业必须采用源代码扫描技术和有关开发流程，因为这是一种战略性的需求， 一种软件安全开发流程必须与日常使用的开发活动相结合。Fortify 公司等汇总了来自世界各地广大用户的类似需求，并将软件开发中的大规模协作，客户化定制和更全面的保护融入企业软件开发安全生命周期之中。

　　Fortify 公司CEO John Jack先生说：我们公司有更好的机会深入了解我们客户所采用的软件安全生命周期流程开发一些世界上最为复杂庞大的系统。这些企业往往面临的是他们的客户选择某种产品是基于该产品的安全性。于是这些企业不得不花费大量时间来研究其软件安全生命周期，对于任何采用的外部解决方案有非常独特的要求。在Fortify SCA 5.0版本的发布中，我们已经将客户这一系列反馈在我们的软件中首次实现，也在业界同类软件中首次实现。

　　Fortify Software自2006年中由上海码德信息技术有限公司引入中国市场以来，已成功在软件测试领域，金融界开发出一批高质量的客户。其中，中国建设银行是金融界第一个成功用Fortify工具实施源代码扫描与开发流程相结合的金融机构。

1 项目背景简介

简要接受项目背景。

2 测试方案简介

2.1 测试策略与目标

明确测试策略与目标。

2.2 测试范围描述

描述本次性能测试涉及的范围。

2.3 测试工具描述

描述用到了什么性能测试工具。

3 测试环境与资源

3.1硬件资源

描述性能测试过程中需要的硬件资源。

3.2人力资源

明确性能测试团队的人员安排和职责。

4 项目里程碑

任务	工作内容	成果	开始时间	结束时间	负责人

5技能培训计划

培训内容	参加人员	时间

6 风险分析

分析本次性能测试过程中的风险。

7 计划结束标准

性能测试计划结束标准。

1文档介绍

1.1文档目的

 

1.2文档范围

 

1.3读者对象

 

1.4参考文献

 

1.5术语与解释

缩写、术语	解    释

 

2测试需求分析

2.1被测试对象的介绍

 

2.2测试范围与目的

 

2.3测试环境与测试辅助工具的描述

3性能测试用例

3.1预期性能指标测试用例

下面的测试方法比较详细，也可以根据实际需要把所有的指标写在一起，简要描述测试方法，以达到节省时间的目的（列出测试对象、期望的性能、实际性能三项即可以）。

1 指标A描述

用例编号：		001
性能描述：
用例目的：
前提条件：
特殊的规程说明：
用例间的依赖关系：
步骤	输入/动作		期望的性能（平均值）	实际性能（平均值）	回归测试
1.	示例：典型值…
2.	示例：边界值…
3.	示例：异常值…
4.	…
5.	…
6.	…

2 指标B描述

用例编号：		002
性能描述：
用例目的：
前提条件：
特殊的规程说明：
用例间的依赖关系：
步骤	输入/动作		期望的性能（平均值）	实际性能（平均值）	回归测试
1.	示例：典型值…
2.	示例：边界值…
3.	示例：异常值…

说的很不错啊！大家可以看看！http://www.rjzl.gov.cn/news.asp?id=1849

   人是测试工作中最有价值也是最重要的资源，没有一个合格的、积极的测试小组，测试就不可能实现。然而，在软件开发产业中有一种非常普遍习惯，那就是 让那些经验最少的新手、没有效率的开发者或不适合干其他工作的人去做测试工作。这绝对是一种目光短浅的行为，对一个系统进行有效的测试所需要的技能绝对不 比进行软件开发需要的少，事实上，测试者将获得极其广泛的经验，他们将遇到许多开发者不可能遇到的问题。

(1)、沟通能力。

一名理想的测试者必须能够同测试涉及到的所有人进行沟通，具有与技术（开发者）和非技术人员（客户，管理人员）的交流能力。既要可以和用户谈得来， 又能同开发人员说得上话，不幸的是这两类人没有共同语言。和用户谈话的重点必须放在系统可以正确地处理什么和不可以处理什么上。而和开发者谈相同的信息 时，就必须将这些活重新组织以另一种方式表达出来，测试小组的成员必须能够同等地同用户和开发者沟通。

(2)、移情能力。

和系统开发有关的所有人员都处在一种既关心又担心的状态之中。用户担心将来使用一个不符合自己要求的系统，开发者则担心由于系统要求不正确而使他不 得不重新开发整个系统，管理部门则担心这个系统突然崩溃而使它的声誉受损。测试者必须和每一类人打交道，因此需要测试小组的成员对他们每个人都具有足够的 理解和同情，具备了这种能力可以将测试人员与相关人员之间的冲突和对抗减少到最低程度。

(3)、技术能力。

就总体言，开发人员对那些不懂技术的人持一种轻视的态度。一旦测试小组的某个成员作出了一个错误的断定，那么他们的可信度就会立刻被传扬了出去。一 个测试者必须既明白被测软件系统的概念又要会使用工程中的那些工具。要做到这一点需要有几年以上的编程经验，前期的开发经验可以帮助对软件开发过程有较深 入的理解，从开发人员的角度正确的评价测试者，简化自动测试工具编程的学习曲线。

(4)、自信心。

开发者指责测试者出了错是常有的事，测试者必须对自己的观点有足够的自信心。如果容许别人对自己指东指西，就不能完成什么更多的事情了。

(5)、外交能力。

当你告诉某人他出了错时，就必须使用一些外交方法。机智老练和外交手法有助于维护与开发人员的协作关系，测试者在告诉开发者他的软件有错误时，也同样需要一定的外交手腕。如果采取的方法过于强硬，对测试者来说，在以后和开发部门的合作方面就相当于“赢了战争却输了战役”。

(6)、幽默感。

在遇到狡辩的情况下，一个幽默的批评将是很有帮助的。

(7)、很强的记忆力。

一个理想的测试者应该有能力将以前曾经遇到过的类似的错误从记忆深处挖掘出来，这一能力在测试过程中的价值是无法衡量的。因为许多新出现的问题和我们已经发现的问题相差无几。

(8)、耐心。

一些质量保证工作需要难以置信的耐心。有时你需要花费惊人的时间去分离、识别和分派一个错误。这个工作是那些坐不住的人无法完成的。

(9)、怀疑精神。

可以预料，开发者会尽他们最大的努力将所有的错误解释过去。测式者必须听每个人的说明，但他必须保持怀疑直到他自己看过以后。

(10)、自我督促。

干测试工作很容易使你变得懒散。只有那些具有自我督促能力的人才能够使自己每天正常地工作。

(11)、 洞察力。

一个好的测试工程师具有“测试是为了破坏”的观点，捕获用户观点的能力，强烈的质量追求，对细节的关注能力。应用的高风险区的判断能力以便将有限的测试针对重点环节。

Interview Questions for Software Testing Engineers
 1.        Describe your working experience in software development and testing.Can you tell me about the projects you had experienced?What kind of techniques you used in your projects?How did you do testing in your projects?How do you make your test plan?
2.        List and briefly describe the testing methods that you know of, and indicate which one/s you have experience with. Black Box TestWhite Box Test       Security Test       Reliability Test       Performance Test      Installation Test       Internationalization Test       Consistence Test       Unit Test       Integration Test
3.        What testing tools do you know, and which one/s you have experience with? LoadRunner WinRunner SilkTest CppUnit JUnit……
4.        Describe what a test case is, and what contents does a test case typically include. What the purpose of a test case?
5.        What are included in a Bug Report? 
6.        What operating system do you have hands-on experience? 
7.        Present your plan to test a can of Coca-Cola. 
8.        What is the must-have attributes for a successful testing professional?

原文http://www.iceshi.com/bbs/viewthread.php?tid=940

首先，何谓"测试脚本语言"？准确的说，"测试脚本语言"这个概念并没有确定的范围，一般是用来指在测试过程中使用到的脚本语言。那么，测试过程中使用的脚本语言到底包括哪些呢？

测试过程中对脚本语言的需求主要来自两个方面: 一方面是测试工具本身使用的脚本语言，另一方面是需要使用某种脚本语言自行编写测试工具，或是实现某个测试任务。

对前者来说，使用何种脚本语言主要取决于工具本身，例如，Robot工具使用的脚本语言类似于VBscrīpt和Javascrīpt，LoadRunner使用的脚本语言是类C和类Javascrīpt的，TestComplete工具使用的脚本语言是类似Delphi的脚本语言。对后者来说，脚本语言的范围就更大了--几乎所有的脚本语言都可以用来实现某种特定的测试任务，因此广义上来说 ，他们都可以被归为"测试脚本语言"。

测试工具使用的脚本语言一般都被限定在特殊的工具中，对脚本语言的掌握体现为对工具掌握的一部分，而且这部分脚本语言的文档很容易获取，在此我们不详细描述。本文中我们重点关注上文描述的后者。

测试中常用的脚本语言包括Perl，Unix/Linux Shell，Python，Ruby等。本文无意评价各种语言的优劣(实际上，很难用短短的几句话描述这些脚本之间的优劣，无论使用哪种语言，只要你真正熟悉它，就可以用它完成所有你想要完成的工作)，而仅仅是给出一些本人在使用这些脚本语言辅助进行测试时的一些思路和想法。

1, 如何选择最适合你的脚本语言(注意，不是"最好的"，而是"最适合你的")
虽说脚本语言很难对其评价为"好"或者"不好"，但真正要选择一种来使用的话，还是可以找到一款最"适合"你的。一般来说，决定选择何种脚本语言可以从以下几个方面考虑:

脚本语言是否与你已经熟悉的某种语言比较接近？
如果你已经习惯用一种面向对象的语言(例如Java)，建议你可以考虑选择完全面向对象的脚本语言Python或者Ruby;
脚本语言是否提供对你所在平台的支持？
如果你的平台是Unix/Linux，除了Windows上的脚本外，其他的你都可以选择;如果你的平台是Windows，基本上除了Unix Shell外，你也都可以选择;
脚本语言是否提供了满足你的测试要求的特性？
一般的脚本语言都会提供很多扩展库来扩充自己，例如Perl的CPAN扩展，Ruby的Watir扩展等等。如果某种脚本提供了一个非常适合你的测试要求的扩展，不妨首先考虑一下使用这种脚本语言(我就是因为使用Watir才转而使用Ruby脚本的)。相比较而言，Windows上的WSH和Unix上的Shell就较少提供扩展。
脚本语言是否有较多的支持？
Perl作为历史最悠久的脚本语言之一，拥有最大的用户群体和最完善和最广泛的支持，Python作为后起之秀在国内也有许多的追随者，相比较而言，Ruby的支持就要逊色一些。不过如果和我一样只是为使用Watir而使用Ruby，这个也就不是很大的问题了。
2, 学习脚本语言的方法
脚本语言本质上也是一门语言，学习他们的方法与学习其他的编程语言并没有本质的区别。"多实践"永远是学习它们的不二法门。我的经验是在实际工作中学习--先对其建立基本的概念和认识，然后在实际的工作中去应用，遇到不懂的再去找文档补充学习。

3, 各脚本语言参考
Perl

Perl中国站
http://www.perl.cn/forum/


Python

Python中文站
http://www.mypython.net/

啄木鸟Python开发社区
http://www.woodpecker.org.cn/

Ruby
Ruby主页
http://ruby-lang.org/en/

Ruby中文手册
http://www.ruby-cn.org/doc.html

Watir项目
http://wtr.rubyforge.org/