摘要：沸沸扬扬的诺顿误杀事件，其背后的原因是缺乏对软件的严格测试。在软件测试的价值不被认同的今天，诺顿“误杀门”给国内的软件企业敲响了警钟。软件测试的价值之一在于可以避免软件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 系统安全及保密性的测试
 是否有系统允许的但又不利于信息系统安全的行为，如关联一编辑器，在其中可以另存读入的文件
 是否有不适当的链接操作
 设定的权限是否准确有效，是否可以利用该权限做其他事情
 安全措施是否有效如口令加密措施是否可以被破译

摘要：一年将尽，心理学家或者一些博学者们，又将对2004年或者更久的将来作出预测。在这次的周末专栏中，Harry Robinson将向我们讲述他对测试未来的预测。

 “预测是件很难的事情，尤其是预测未来” —Yogi Berra

   每年十二月，小报的“未来预测者”们会向大家切揭示即将到来的一年将要发生的事情：“麦丹娜将要乘坐航天飞机”，“美国将迁都 Wichita”，等等。我将加入这个潮流，对软件测试何去何从做一个我自己的预测。并且我希望，我的预测费用能够比我的那些值得尊敬的小报同事更高些。

   我的主要预测就是，将来的软件测试与现在的软件测试看起来很不一样。原因很直接：今天的软件测试很大程度上是臭名昭著的：软件测试参与到项目中的时间太 晚、贡献太少、花费太高。如果我们关心我们产品的质量以及我们的账本底线的话，我们就需要重新思考测试和质量的方法。

   即使遭到一致反对，我也要说：更好的方法，对测试人员更好的培训、更好的欣赏将改革软件产业。具体地说，诸如可执行的说明书、基于模型的测试产生、BUG预防、系统模拟这些技术，将在这场演变过程中扮演重要的角色。

   下面就是我们在将来的几年里可能看到的情形。事实上，某些趋势已经开始了。

   测试人员，需求撰写人员和开发人员，都将看到自己是其中的一份子。

   测试人员帮助需求撰写人员

   测试人员与需求撰写人员共同工作，在需求完成以后，审查以及理解需求。早期的审查以及建模可以暴露很多关于一致性、完整性和模糊性的BUG，这个时候修补这些BUG付出的代价还十分小。

   需求撰写人员帮助测试人员

   测试小组建造模型，用于产生对其产品行为的测试。需求撰写人员审查模型，以确保他们充分覆盖了产品特征集。这样产生的测试模块将成为一个“可执行需求”。

   测试人员帮助开发人员

   因为需求清楚，毫不含糊，开发人员更好的理解了他们的代码将要完成什么。

   在正式的将代码提交做测试之前，测试人员提供给开发人员一些模型，以便开发人员可以在自己的代码中实现它们。

   开发人员帮助测试人员

   基于”特征对特征”这样的方式(防止以往的“后期才介入开发,一股脑找出产品问题”的方式),开发人员和测试人员共同保证代码易于实施自动测试.开发人员的代码中处处都是易测试性的开关,使得错误检测更加容易.

   测试人员帮助测试人员

   测试用一种高级语言来模拟,因此别的特征的测试小组(甚至别的产品的测试小组)可以复查和改进测试模型.这就形成了一个测试专家的共同体.

   方法日趋完善

   BUG预防和早期检测

   因为现在把重点放在产品交付的质量上来了(而不是在于找到了多少BUG), 预防实践和静态分析仪这样的检测工具将成为主流.

   仿真测试

   仿真工具变得很普遍,使得仿造计算机环境变得容易起来.在开发过程的早期就可以进行意外和错误流程的测试.代码稳定后,再用真实环境验证仿真是否准确无误.

   及时的测试用例

   庞大的测试用例管理系统将成为昔日的东西,大量的测试用例生成了却没有被使用.测试用例将不再像腐烂的存货一样被收藏起来,因此,让测试用例保持最新变得容易起来.

   积极的方法

   误导人的方法,比如计算BUG的数量、计算测试用例的数量,将不复存在.有用的方法,比如需求覆盖、模型覆盖、代码覆盖将驱动项目开发.

   更少更精的测试人员

   机器将代替测试人员做大部分他们以往创建测试所做的繁琐工作,测试小组需要比以往更少的测试人员,留下来的测试人员将是经过更多高度培训过的.他们所做的工作将更加有趣,因为在测试中他们将致力于更大的问题,而不是在抱怨中艰难地开展工作.

    更多更好的测试

    测试人员将可以在一天中进行成千上万的测试,所以,如何首先运行最有用的测试将成为一大挑战.相关的工具将允许测试人员为他们的测试区分优先级,以及将测试目标放在那些最易出现重大BUG的地方.

    测试人员的角色更换

    测试中界限模糊

    在测试领域工作使得专职测试的人员和专职创建测试工具的人员界限模糊,一个既是“通过程序破坏事物的测试员”又是”创建程序用于破坏事物的程序员”的专业出现了,――关于如何称呼这个新的专业，新闻圈内的人们还在进行着无休止的争论。

    测试与开发界限模糊

    测试人员与开发人员一前一后，共同创造可测试的、高质量的代码。测试人员帮助开发人员消除需求中的问题，使得开发人员的工作更易完成，同时，开发人员写出更清晰、可测性更高的代码，使得测试人员的工作更易完成。

    顾客反馈与测试合为一体

    交付的产品质量更高。测试人员进行根本原因的分析，我们会问比如“我们怎么会遗漏了这个BUG呢？”或者“我们将来如何防止这类BUG？”这些问题，我们的工作就是使顾客满意。

    新的挑战出现

    复杂和相互关联的计算机世界使得了测试安全这一类的新问题让测试人员不断努力工作，但这没关系――因为这些挑战使测试人员精力充沛。

    测试人员获得尊重

    测试人员将不再是在最后时刻才被叫来“对产品狂轰烂炸”，他们将在整个软件开发过程中提供一个可见的、重要的、增值的服务。人们意识到，测试是有益的、有趣的甚至富有乐趣。

    测试变得流行

    软件测试人员开始扬眉吐气，而且，由于破坏事物至少可以带来创建事物一样的乐趣，人们开始在开发和测试角色之间转换，所有的人将学到更多关于如何得到良好代码的知识。

    激情“吸毒者”继续存在

    新的过程运行得如此良好，使得需求撰写者，开发人员以及测试人员不再具有生命力，这就使得那些在激情掌控的世界被提升的人惶惶不可终日，那样的世界意味着 工作到深夜、最后一刻测试才参与，以及如同交战开火般的会议。而这些人对于那些还没有受新的运行过程控制的公司来说还具有吸引力。

    Elvis Presley是一个软件测试员

    他的会议发放材料的标题就是：“软件质量：就是现在，否则永远不可能”

    今天就为将来准备

    不管我的预测是否成为现实，未来也会按照它自己的方式到来，下面就是如何准备面临未来的五个意见：

    1．积极地不满于现状

    不要接受测试的现状，四处看看，并且思考“我们在做些什么毫无意义的事情？”

    2．抛开人与人之间的封闭

    领悟如何更好的测试，并且分享这些知识。只有每一个人都试图使他所写的代码达到最佳状态时，整体质量才会改进。

    3．学习更多关于测试的东西

    如今，行业受软件测试的创新思维激发。用参加会议，加入邮件列表，网上冲浪，这些方式来解在测试前沿发生的一切。

    4．学习更多关于开发的东西

    参加一个编程学习班，即使你不打算编写大量的代码。将学习班当作是在BUG领土上的一次侦察飞行。

    5．挑战世界

    正如PC先驱Alan Kay所言：“预测未来的最好方式就是开创未来”

 

Predicting the Future of Testing

By Harry Robinson

Summary: As the end of the year approaches, psychics and pundits alike will start making their predictions about what's in store for us in 2004 and beyond. In this week's column, industry veteran Harry Robinson gives us his forecast on the future of software testing.

"It is tough to make predictions, especially about the future."—Yogi Berra

Every December, tabloid fortune-tellers reveal what will happen in the coming year: “Madonna will fly on the space shuttle,” “the U.S. capital will move to Wichita, Kansas” and so forth. I’d like to jump on that bandwagon and make a few predictions of my own about where software testing is going in the next few years. And I can only hope my prophecies fare better than those of my esteemed tabloid colleagues!

My main prediction is that software testing in the future will look very different than it does today. My reasoning is straightforward: Software testing largely stinks today. It comes into a project too late, contributes too little, and costs too much. If we care about the quality of our products and the health of our bottom lines, we need to re-think our approach to testing and quality.

I will even go out on a limb and say that better methods, better training and a better appreciation for testers will revolutionize the software industry. To be specific, technologies such as executable specifications, model-based test generation, bug prevention, and system simulation will play important roles in the unfolding drama.

Here are some scenes we will see in the industry over the next few years. In fact, some of these trends are starting to emerge already.

Testers, Spec Writers, and Developers See Themselves as Partners

Testers Help Spec Writers 

Testers work with spec writers to review and understand the spec as it is being written. Early review and modeling exposes many consistency, completeness, and ambiguity bugs while they are still cheap to fix.

Spec Writers Help Testers

The test team creates models to generate tests of its applications' behavīors. Spec writers review the models to ensure that they adequately cover the feature set. The resulting test model becomes an "executable spec."

Testers Help Developers

Because the spec is clean and unambiguous, the developers understand better what their code should accomplish. Testers provide lightweight models that developers can run against their code before they officially hand it over for testing. 

Developers Help Testers

Proceeding on a feature-by-feature basis (to avoid the late-in-the-cycle, product-pounding approach of the past), developers and testers ensure that the code is easy to test with automated methods. Developer's code is now full of testability hooks, making errors more detectable.

Testers Help Testers

Tests are now modeled in a high-level language, so teams working on other features (and even other products) can help review and improve the test models. This creates a community of test generation experts.

Methods and Metrics Get Better

Bug Prevention and Early Detection

Because the emphasis is now on the quality of the deliverable (and not on how many bugs you found along the way), prevention practices and detection tools, such as static analyzers, are mainstream.

Simulation in Testing

Simulation tools become common, making it easy to “fake” computer environments. Testing for exceptions and error paths now happens early in the development process. After the code has stabilized, real environments verify that the simulations were accurate.

Just-in-time Test Cases

Massive test case management systems are a thing of the past. Most tests are generated on the fly. Test cases are no longer stored away like rotting inventory, so it is easy to keep tests up to date. 

Positive Metrics

Misleading metrics, such as bug counts and test case counts, are dead. Useful metrics, such as spec coverage, model coverage, and code coverage, drive the projects.

Fewer Testers, Better Testers

Machines now perform much of the mundane work that testers previously did creating tests. Teams require fewer testers, and the testers who remain are more highly trained. Their work is more interesting to them because they are focused on bigger issues in their tests rather than slogging through grunt work.

More Tests, Better Tests

Testers can now generate millions of tests on any day, so the challenge becomes how to run the most useful tests first. Combinatorial tools allow testers to prioritize their testing and aim their test runs at the areas most likely to have significant bugs.

Roles Will Change for Testers

Distinctions Blur in Testing

Work in the testing field blurs the line between people who only specialize in hands-on testing and those who only create test tools. A new specialty emerges that encompasses both "testers who like to break things via programs" and "programmers who like to create programs that break things" – people in newsgroups debate endlessly about what to call the new specialty.

Boundaries Blur Between Testing and Development

Testers and developers work in tandem to produce testable, high-quality code. Testers help iron out spec issues to make the developer's job easier, and developers create cleaner, more testable code to make the tester's job easier.

Feedback from Customers Becomes Integrated with Testing

The quality of deliverables becomes higher. Testers routinely conduct root cause analyses. We ask questions such as "How did we miss this bug?" and "How can we prevent this type of bug in the future?" We work to delight our customers.

New Challenges Emerge

The sophisticated and interconnected environment of the computing world guarantees that new problems such as security testing continue to keep testers running hard. This is OK—testers find these challenges invigorating.

Testers Get Respect

Testers are no longer called in at the last moment to "pound on the product." They provide a visible, vital, value-added service throughout the software development process. People realize that testing can be rewarding, interesting, and even fun. 

Testing Gets Trendy

Software testers start to hold their heads high. And, because breaking stuff is at least as much fun as building it, people begin to rotate between positions in development and testing. Everyone learns more about what makes good code.

Adrenaline Junkies Move On

The new process works so well that spec writers, developers, and testers end up having lives. This is disconcerting to some who were raised in the adrenaline-charged world of late-night, last-minute, firefighting sessions. These people gravitate to companies that remain out of control.

Elvis Presley Is Discovered Working as a Software Tester

The giveaway is his conference paper titled “Software Quality: It’s Now or Never”. 

Prepare for the future today

Whether or not my predictions come true, the future is on its way. Here are five ideas for how you can prepare to meet it:

1. Get Actively Dissatisfied

Don't accept the current state of testing. Look around and think, "What are we doing that makes no sense?"

2. Push the Envelope

Figure out how to test better and share that knowledge. Overall quality will improve only if everyone seeks to make the code they are working on the best it can be.

3. Learn More about Testing

At this moment, the industry is exploding with innovative software testing ideas. Go to conferences, join mailing lists, and scour the Web to see what is happening on the cutting edge of testing.

4. Learn More about Development

Take a programming class. Even if you don't plan to write significant amounts of code, view the class as a reconnaissance flight over bug territory.

5. Change the World!

As PC pioneer Alan Kay said: "The best way to predict the future is to invent it."

For more info:

On executable specs: “Executable Specifications: Creating Testable, Enforceable Designs”

On model-based testing: “Intelligent Test Automation”

On system simulation: “Software’s Invisible Users”

About the Author Harry Robinson is Test Architect for Microsoft's Enterprise Management Division. In addition to his day job, he teaches classes on advanced software test automation and is a driving force behind Microsoft's model-based testing initiative. He has been at Microsoft for five years and has a Bachelors and Masters in Electrical Engineering. You can reach him at harryr@microsoft.com.

   正交实验法设计测试用例是考虑用最少的用例来覆盖两两组合的情况，是套用正交表来随机的产生用例，没有主次之分，是一种提高测试覆盖率的简单易用的方法。

   正交实验法的重点是首先确定因子、状态，生成因子状态表;然后用加权筛选的方法去除不重要的因子、状态得到简化的因子状态表（因素分析表）；再利用正交表构造测试数据集。

   如何选择正交表呢？有几条原则：

   1 每个因子状态数目相同的情况，因子数为M，状态数为N，则最佳选择一个M因子N状态的正交表，如果不存在这样的正交表，则选择K因子N状态的正交表（K>M）。

   2 如果不同因子状态数目不相同，选择出现次数最多的状态数（相同的话选择大的）。

   3 如果所选的正交表的状态数小于因子最大的状态数，比如

    a1  a2 

    b1  b2  b3

    c1  c2 

则把b1 b2放在一起，写用例的时候再分开写。

a1	b1b2	c1
a2	b1b2	c2
a1	b3	c2
a2	b3	c1

用例：

a1 b1 c1

a1 b2 c1

a2 b1 c2 

a2 b2 c2

a1 b3 c2

a2 b3 c1 

正交表的下载网址http://www.york.ac.uk/depts/maths/tables/orthogonal.htm 

 正交实验法设计测试用例的例子：

假设一个WEB站点，该站点有大量的服务器和操作系统，并且有许多具有各种插件的浏览器浏览：

WEB浏览器：Netscape6.2、IE6.0、Opera4.0

插件：       无、RealPlayer、MediaPlayer

应用服务器：IIS、Apche、Netscape Enterprise

操作系统：Windows2000、Windows NT、Linux

	WEB浏览器	插件	应用服务器	操作系统
1	Netscape6.2	无	IIS	Windows2000
2	Netscape6.2	RealPlayer	Apche	Windows NT
3	Netscape6.2	MediaPlayer	Netscape	Linux
4	IE6.0	无	Apche	Linux
5	IE6.0	RealPlayer	Netscape	Windows2000
6	IE6.0	MediaPlayer	IIS	Windows NT
7	Opera4.0	无	Netscape	Windows NT
8	Opera4.0	RealPlayer	IIS	Linux
9	Opera4.0	MediaPlayer	Apche	Windows2000

 

 

正交表：

 

	1	2	3	4
1	1	1	1	1
2	1	2	2	2
3	1	3	3	3
4	2	1	2	3
5	2	2	3	1
6	2	3	1	2
7	3	1	3	2
8	3	2	1	3
9	3	3	2	1

一、            提取系统功能说明中的因子：

1、WEB浏览器

2、插件

3、应用服务器

4、操作系统 

二、            分析各因子的状态

   1、WEB浏览器：1＝Netscape6.2、2=IE6.0、3=Opera4.0

2、插件: 1=None、2=RealPlayer、3=MediaPlayer

3、应用服务器: 1=IIS、2=Apche、3=Netscape Enterprise

4、操作系统: 1=Windows2000、2=Windows NT、3=Linux

 

三、            将因子、状态映射到上面正交表中：

 

测试用例	浏览器	插件	服务器	操作系统
1	Netscape6.2	None	IIS	Windows2000
2	Netscape6.2	RealPlayer	Apche	Windows NT
3	Netscape6.2	MediaPlayer	Netscape Enterprise	Linux
4	IE6.0	None	Apche	Linux
5	IE6.0	RealPlayer	Netscape Enterprise	Windows2000
6	IE6.0	MediaPlayer	IIS	Windows NT
7	Opera4.0	None	Netscape Enterprise	Windows NT
8	Opera4.0	RealPlayer	IIS	Linux
9	Opera4.0	MediaPlayer

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

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

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

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

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

    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/