测试用例的书写方式及测试模板大全_436套软件开发需求文档_VD516-软件开发需求文档_07测试用例文档（16份）

测试用例的书写方式及测试模板大全 一个优秀的测试用例，应该包含以下信息： 1 ） 软件或项目的名称 2 ） 软件或项目的版本（内部版本号 ） 3 ） 功能模块名 4 ） 测试用例的简单描述，即该用例执行的目的或方法 5 ） 测试用例的参考信息（便于跟踪和参考 ） 6 ） 本测试用例与其他测试用例间的依赖关系 7 ） 本用例的前置条件，即执行本用例必须要满足的条件，如对数据库 的访问权限 8 ） 用例的编号（ ID ），如可以是 软件名称简写 - 功能块简写 -NO. 。 9 ） 步骤号、操作步骤描述、测试数据描 述 10 ）预期结果（这是最重要的）和实际结果（如果有 BUG 管理工具，这 条可以省略） 11 ）开发人员（必须有）和测试人员（可有可 无） 12 ）测试执行日期 例如以下这个模板：技术出口合同网络申领系 项目 / 软件 程序版本 1.0.25 统 功能模块名 Login 编制人 xxx 用例编号 - TC-TEP_Login_1 编制时间 2010.10.12 相关的用例 无 功能特性 用户身份验证 验证是否输入合法的信 测试目的 息，允许合法登陆，阻止非 法登陆 特殊规程如数据库访 预置条件 无 说明 问权限 需求说明中关于 “ 登陆 参考信息 ” 的说明 测试数据 用户名 =yiyh 密码 =1 实实 际际 测试 操作步骤 操作描述 数 据 期望结果 结结 状态 果 果 显示警告信 用户名 输入用户名称，按 “ 登 息 “ 请输 1 =yiyh ， 陆 ” 按钮。 入用户名和 密码为空 密码！ ” 显示警告信 用户名为 输入密码，按 “ 登陆 ” 息 “ 请输 2 空，密码 按钮。 入用户名和 =1 密码！ ” ------------>>> 项 目 测试人员 开发人员 负 责 人 =====需求测试用例======= 开发人员－系统说明书-功 客户需求列表－需求说明书 测试人员－－功能点测试列表 能列表 1注册功能 1用户可以自动注册 （对比发现问题）===== 接口测试用例＝＝＝ 接口 A 的函数 原型 输入 / 动作 期望的输出 / 相应 实际情况 典型值 … 边界值 … 异常值 … 接口 B 的函数 原型 输入 / 动作 期望的输出 / 相应 实际情况 典型值 … 边界值 … 异常值 … … ==== 路径测试的检查用例==== 检查项 结论 数据类型问题 （１）变量的数据类型有错误吗？ （２）存在不同数据类型的赋值吗？ （３）存在不同数据类型的比较吗？ 变量值问题 （１）变量的初始化或缺省值有错误吗？ （２）变量发生上溢或下溢吗？ （３）变量的精度不够吗？ 逻辑判断问题 （１）由于精度原因导致比较无效吗？ （２）表达式中的优先级有误吗？ （３）逻辑判断结果颠倒吗？ 循环问题 （１）循环终止条件不正确吗？ （２）无法正常终止（死循环）吗 ？ （３）错误地修改循环变量吗？ （４）存在误差累积吗？ 内存问题（１）内存没有被正确地初始化却被使用 吗？ （２）内存被释放后却继续被使用吗？ （３）内存泄漏吗？ （４）内存越界吗？ （５）出现野指针吗？ 文件 I/O 问题 （１）对不存在的或者错误的文件进行操作 吗？ （２）文件以不正确的方式打开吗？ （３）文件结束判断不正确吗？ （４）没有正确地关闭文件吗？ 错误处理问题 （１）忘记进行错误处理吗？ （２）错误处理程序块一直没有机会被运 行？ （３）错误处理程序块本身就有毛病吗？如 报告的错误与实际错误不一致，处理方式不 正确等等。 （４）错误处理程序块是“马后炮”吗？如 在被它被调用之前软件已经出错。 … =====功能测试用例===== 功能 A 描述 用例目的 前提条件 输入 / 动作 期望的输出 / 相应 实际情况 示例：典型值 … 示例：边界值 … 示例：异常值 … 功能 B 描述 用例目的 前提条件 输入 / 动作 期望的输出 / 相应 实际情况 ……======健壮性测试- 容错能力 / 恢复能力测试用例===== 异常输入 / 动作 容错能力 / 恢复能力 造成的危害、损失 示例：错误的数据类型 … 示例：定义域外的值 … 示例：错误的操作顺序 … 示例：异常中断通信 … 示例：异常关闭某个功 能 … 示例：负荷超出了极限 … ======性能测试用例======= 性能 A 描述 用例目的 前提条件 输入数据 期望的性能（平均值） 实际性能（平均值） 性能 B 描述 用例目的 前提条件 输入数据 期望的性能（平均值） 实际性能（平均值） …… =====界面测试用例－界面检查表=======检查项 测试人员的类别及其评价 窗口切换、移动、改变大小时正常吗？ 各种界面元素的文字正确吗？（如标 题、提示等） 各种界面元素的状态正确吗？（如有 效、无效、选中等状态 ） 各种界面元素支持键盘操作吗？ 各种界面元素支持鼠标操作吗？ 对话框中的缺省焦点正确吗？ 数据项能正确回显吗？ 对于常用的功能，用户能否不必阅读手 册就能使用？ 执行有风险的操作时，有“确认”、 “放弃”等提示吗？ 操作顺序合理吗？ 有联机帮助吗？ 各种界面元素的布局合理吗？美观吗？ 各种界面元素的颜色协调吗？ 各种界面元素的形状美观吗？ 字体美观吗？ 图标直观吗？ … ======信息安全测试用例========= 假想目标 A 前提条件 非法入侵手段 是否实现目 代价－利益分析 标 …… 假想目标 B 前提条件 非法入侵手段 是否实现目 代价－利益分析 标 ……======压力测试用例=========== 极限名称 A 例如“最大并发用户数量” 前提条件 输入 / 动作 输出 / 响应 是否能正常运 行 例如 10 个用户并发操作 例如 20 个用户并发操作 … 极限名称 B 前提条件 输入 / 动作 输出 / 响应 是否能正常运 行 … ======可靠性测试用例======== 任务 A 描述 连续运行时间 故障发生的时刻 故障描述 …… 统计分析 任务 A 无故障运行的平均 （ CPU 小时） 时间间隔 任务 A 无故障运行的最小 （ CPU 小时） 时间间隔 任务 A 无故障运行的最大 （ CPU 小时） 时间间隔 任务 B 描述 连续运行时间 故障发生的时刻 故障描述 ……统计分析 任务 B 无故障运行的平均 （ CPU 小时） 时间间隔 任务 B 无故障运行的最小 （ CPU 小时） 时间间隔 任务 B 无故障运行的最大 （ CPU 小时） 时间间隔 ====== 安装 / 反安装测试用例============ 配置说明 安装选项 描述是否正常 使用难易程度 全部 部分 升级 其它 反安装选项 描述是否正常 使用难易程度 测试的基本原则<-> 在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。 这里有一组测试原则： 1 、所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在 于揭示错误。而最严重的错误（从用户角度来看）是那些导致程序无法满 足需求的错误。 2 、应该在测试工作真正开始前的较长时间内就进行测试计划。测试计 划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型 被确定后立即开始。因此，所有测试应该在任何代码被产生前就进行计 划和设计。 3 、 Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中的 80 ％很可能起源于程序模块中的 20 ％。当然，问题 在于如何孤立这些有疑点的模块并进行彻底的测试。 4 、测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测 试通常把焦点放在单个程序模块上，进一步测试的焦点则转向在集成的 模块簇中寻找错误，最后在整个系统中寻找错误。 5 、穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数 量也非常大。因此，在测试中不可能运行路径的每一种组合。然而，充分 覆盖程序逻辑，并确保程序设计中使用的所有条件是有可能的。 6 、为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软 件工程师并不是构造软件测试的最佳人选。 7、 不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样 也是一种不负责任的表现. 测试的基本原则<二> 1．应当把“尽早和不断的测试”作为开发者的座右铭 2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件 测试机构来完成。 3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边 界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电 源断电等情况。 4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习 惯有很大的关系。 5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错 误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分 析。6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极 短的时间内完成一个高水平的测试。 7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多 的错误出现的现象并不少见。 8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往 要靠测试文档。 软件测试从零开始 －－－－－－－－－－－－－－(威哥) 51testing 本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例 设计、测试用例执行、测试结果分析几个方面给出建议和方法。鉴于国内 的软件开发、测试不规范的现状，本文为软件测试新手提供了若干个软 件测试的关注点。 【关键词】软件测试、测试用例、测试需求、测试结果 分析 引言 几年前，从学校毕业后，第一份工作就是软件测试。那时候，国内 的软件企业大多对软件测试还没有什么概念，书店里除了郑人杰编写的 《计算机软件测试技术》之外，几乎没有其它的软件测试相关书籍，软件 测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测 试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系 统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意 义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼 目睹了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接 受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如 何开始测试。下面针对上述情况，给出若干解决办法 。 1、测试准备工作在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目 的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发 现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软 件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面 对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包 括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用 户的并发容量等等。该从何处下手呢？ 2、向有经验的测试人员学习 如果你进入的是一家运作规范的软件公司，有独立的软件测试部 门、规范的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！ 你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师， 由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产 品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关 工作。其实，在很多运作规范的软件公司，已经把上述的师父带徒弟的方 式固化到流程中。 如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜 你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确 实认识到软件测试的重要性，实实在在需要提高产品的质量。这时候，可 以到国内的软件测试论坛和相关网站上寻找软件测试资源，这种情况下， 自学能力和对技术的悟性就至关重要了。 3、阅读软件测试的相关书籍 现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有 的是翻译国外经典之作。可以到 www.chinapub.com 或者 www.cnforyou.com 等网络购书的站点查找软件测试相关的书籍。目前， 从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译 质量对阅读效果有很大的影响。4、 走读缺陷跟踪库中的问题报告单 如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用 工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzilla 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有 价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中 体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关 键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环 境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决 方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经 吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问 题。这是迅速提高软件测试经验的好方法。 5、 走读相关产品的历史测试用例 如果你所在的公司有测试用例管理系统，那么，走读相关产品的软 件测试用例是迅速提高测试用例设计水平的一条捷径。走读测试用例也 是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细 化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测 试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正 常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根 据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和 测试用例是一对多的关系。 通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来 的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功 能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测 试用例的操作步骤和测试用例的输出结果等。 总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自 身用例设计水平的好方法。6、学习产品相关的业务知识 软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的 业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要 学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识 也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺 的知识点。 因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知 识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无 所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业 务相关的缺陷，很可能是视而不见，如此这般，软件测试的效果会大打折 扣。 7、 识别测试需求 识别测试需求是软件测试的第一步。如果开发人员能够提供完整 的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功 能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提 供软件需求文档，那该如何是好？下面给出几个有效的方法： 8、 主动获取需求 开发人员通常不会更好地考虑软件测试，如果没有开发流程的强 制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文 档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主 观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解 软件实现的主要功能是什么，并记录得收集到的信息。一般来说，开发人 员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向 开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术 支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获 取第一手的用户使用感受，在测试的过程中会更加贴近用户。当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交 流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输 入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分 析： 软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑， 输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、 输入参数的精度和输入参数的有效输入范围。在测试用例设计中，这部 分内容作为测试用例输入的依据。 处理过程： 描述对输入数据所执行的所有操作和如何获得输出的 过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果 对处理过程了解的深入，对定位问题根源有很大的帮助。 软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机 显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参 数的时序、输出参数精确度、输出参数的有效输出范围、错误消息。在测 试用例设计中，这部分内容作为测试用例的预期输出。 性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款 卡后， 3 秒钟内弹出提示用户取款的图形界面 ” 。 3 秒钟这一限制， 就是对需求的基本性能要求。 运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系 统的要求、数据库的要求，以及其它相关支撑软件的要求 。 9、 确认需求的优先级 确认需求的优先级是很必要的，如果在产品进度比较紧的情况下， 测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在 测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的 需求项。如果软件公司有规范的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本 的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？ 如果是这样，需求的优先级只能由测试人员完成了。 10、加入开发小组的邮件群组 测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是 不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产 品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如 果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许 使用的是 E-mail 系统，测试人员应该加入到开发人员的邮件群组中。 当开发人员通过邮件讨论问题、通知召开技术会议的时候，测试人员可 以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有 了软件变更控制流程，加入到开发邮件群组也是一个很好的习惯。 11、 与开发人员为邻 建议测试人员与开发人员为邻。我所在的测试组曾经与开发组是 在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关 系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能 第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工 作中上下游环节的同事保持良好的个人关系对工作有很大 便利。一般 的公司内部都存在部门墙，良好的人际关系是打通部门墙的手段之一。 向领导建议测试人员与开发人员为邻，这很必要。 A 测试用例设计 测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例 就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是 确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下 问题： 测试用例的基本格式软件测试用例的基本要素包括测试用例编号、测试标题、重要级别 测试输入、操作步骤、预期结果，下面逐一介绍 。 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的 编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称＋测 试阶段类型（系统测试阶段）＋编号。定义测试用例编号，便于查找测试 用例，便于测试用例的跟踪。 测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试 用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情 况 ” 。 重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然 ， 测试输入： 提供测试执行中的各种输入条件。根据需求中的输入 条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有 很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试 用例设计中会遇到很大的障碍。 操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试 用例的输入需要分为几个步骤完成，这部分内容在操作步骤中详细列出。 预期结果： 提供测试执行的预期结果，预期结果应该根据软件需 求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期 结果不符，那么测试不通过；反之则测试通过 。 软件测试用例的设计主要从上述 6 个域考虑，结合相应的软件需 求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、 合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍， 白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。 B 重用同类型项目的测试用例 @@@@@如果我看得远，那是因为我站在巨人的肩上 －－牛顿。 @@@@@ 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业 务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息 系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架 构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借 鉴意义。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用 例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以 应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例 设计思路，也可以节省大量的测试用例设计时间。 利用已有的软件 Checklist 在上面一个小节中，按照不同的规则划分了不同的软件类型。每种 类型的软件都有一定的测试规范，比如， WEB 软件系统在系统测试过 程中，会有一系列的范式，比如针对 Cookie 就会有很多测试点。在设计 测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国内外的 网站很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗糙 的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下 次测试用例设计的基础。 加强测试用例的评审 测试用例设计完毕后，最好能够增加评审过程。同行评审是CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展 同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件 开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果 认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设 计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行 评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测 试用例相关问题，会给测试执行带来大麻烦，甚至导致测试执行挂起 。 定义测试用例的执行顺序 在测试用例执行过程中，你会发现每个测试用例都对测试环境有特 殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺 序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务 器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这 部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的 时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧 张的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测 试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会 影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测 试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而， 合理地定义测试用例的执行顺序是很有必要的。 测试用例执行 测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该 注意以下几个问题： 搭建软件测试环境，执行测试用例 测试用例执行过程中，搭建测试环境是第一步。一般来说，软件产 品提交测试后，开发人员应该提交一份产品安装指导书，在指导书中详 细指明软件产品运行的软硬件环境，比如要求操作系统系统是 Windows 2000 pack4 版本，数据库是 Sql Server 2000 等等，此外，应 该给出被测试软件产品的详细安装指导书，包括安装的操作步骤、相关配置文件的配置方法等等。对于复杂的软件产品，尤其是软件项目，如果 没有安装指导书作为参考，在搭建测试环境过程中会遇到种种问题。 如果开发人员拒绝提供相关的安装指导书，搭建测试中遇到问题 的时候，测试人员可以要求开发人员协助，这时候，一定要把开发人员解 决问题的方法记录下来，避免同样的问题再次请教开发人员，这样会招 致开发人员的反感，也降低了开发人员对测试人员的认可程度。 测试环境搭建之后，根据定义的测试用例执行顺序，逐个执行测试 用例。在测试执行中需要注意以下几个问题： 全方位的观察测试用例执行结果： 测试执行过程中，当测试的实 际输出结果与测试用例中的预期输出结果一致的时候，是否可以认为测 试用例执行成功了？答案是否定的，即便实际测试结果与测试的预期结 果一致，也要查看软件产品的操作日志、系统运行日志和系统资源使用 情况，来判断测试用例是否执行成功了。全方位观察软件产品的输出可 以发现很多隐蔽的问题。以前，我在测试嵌入式系统软件的时候，执行某 测试用例后，测试用例的实际输出与预期输出完全一致，不过在查询 CPU 占用率地时候，发现 CPU 占用率高达 90 ％，后来经过分析，软 件运行的时候启动了若干个 1ms 的定时器，大量的消耗的 CPU 资源， 后来通过把定时器调整到 10ms ， CPU 的占用率降为 7 ％。如果观察 点单一，这个严重消耗资源的问题就无从发现了。 加强测试过程记录： 测试执行过程中，一定要加强测试过程记录。 如果测试执行步骤与测试用例中描述的有差异，一定要记录下来，作为 日后更新测试用例的依据；如果软件产品提供了日志功能，比如有软件 运行日志、用户操作日志，一定在每个测试用例执行后记录相关的日志 文件，作为测试过程记录，一旦日后发现问题，开发人员可以通过这些测 试记录方便的定位问题。而不用测试人员重新搭建测试环境，为开发人 员重现问题。 及时确认发现的问题： 测试执行过程中，如果确认发现了软件的缺陷，那么可以毫不犹豫的提交问题报告单。如果发现了可疑问题，又无 法定位是否为软件缺陷，那么一定要保留现场，然后知会相关开发人员 到现场定位问题。如果开发人员在短时间内可以确认是否为软件缺陷， 测试人员给予配合；如果开发人员定位问题需要花费很长的时间，测试 人员千万不要因此耽误自己宝贵的测试执行时间，可以让开发人员记录 重新问题的测试环境配置，然后，回到自己的开发环境上重现问题，继续 定位问题。 与开发人员良好的沟通： 测试执行过程中，当你提交了问题报告 单，可能被开发人员无情驳回，拒绝修改。这时候，只能对开发人员晓之 以理，做到有理、有据，有说服力。首先，要定义软件缺陷的标准原则，这 个原则应该是开发人员和测试人员都认可的，如果没有共同认可的原则， 那么开发人员与测试人员对问题的争执就不可避免了。此外，测试人员 打算说服开发人员之前，考虑是否能够先说服自己，在保证可以说服自 己的前提下，再开始与开发人员交流。 及时更新测试用例 测试执行过程中，应该注意及时更新测试用例。往往在测试执行过 程中，才发现遗漏了一些测试用例，这时候应该及时的补充；往往也会发 现有些测试用例在具体的执行过程中根本无法操作，这时候应该删除这 部分用例；也会发现若干个冗余的测试用例完全可以由某一个测试用例 替代，那么删除冗余的测试用例。 总之，测试执行的过程中及时地更新测试用例是很好的习惯。不要 打算在测试执行结束后，统一更新测试用例，如果这样，往往会遗漏很多 本应该更新的测试用例。 提交一份优秀的问题报告单 软件测试提交的问题报告单和测试日报一样，都是软件测试人员 的工作输出，是测试人员绩效的集中体现。因此，提交一份优秀的问题报 告单是很重要的。软件测试报告单最关键的域就是 “ 问题描述 ” ， 这是开发人员重现问题，定位问题的依据。问题描述应该包括以下几部 分内容：软件配置、硬件配置、测试用例输入、操作步骤、输出、当时输出设备的相关输出信息和相关的日志等。 软件配置： 包括操作系统类型版本和补丁版本、当前被测试软件 的版本和补丁版本、相关支撑软件，比如数据库软件的版本和补丁版本 等。 硬件配置： 计算机的配置情况，主要包括 CPU 、内存和硬盘的相 关参数，其它硬件参数根据测试用例的实际情况添加。如果测试中使用 网络，那么网络的组网情况，网络的容量、流量等情况。硬件配置情况与 被测试产品类型密切相关，需要根据当时的情况，准确翔实的记录硬件 配置情况。 测试用例输入 / 操作步骤 / 输出： 这部分内容可以根据测试用例 的描述和测试用例的实际执行情况如实填写。 输出设备的相关输出信息： 输出设备包括计算机显示器、打印机、 磁带等等输出设备，如果是显示器可以采用抓屏的方式获取当时的截图， 其他的输出设备可以采用其它方法获取相关的输出，在问题报告单中提 供描述。 日志信息： 规范的软件产品都会提供软件的运行日志和用户、管 理员的操作日志，测试人员应该把测试用例执行后的软件产品运行日志 和操作日志作为附件，提交到问题报告单中。 根据被测试软件产品的不同，需要在 “ 问题描述 ” 中增加相 应的描述内容，这需要具体问题具体分析。 测试结果分析 软件测试执行结束后，测试活动还没有结束。测试结果分析是必不 可少的重要环节， “ 编筐编篓，全在收口 ” ，测试结果的分析对下一 轮测试工作的开展有很大的借鉴意义。前面的 “ 测试准备工作 ” 中， 建议测试人员走读缺陷跟踪库，查阅其他测试人员发现的软件缺陷。测 试结束后，也应该分析自己发现的软件缺陷，对发现的缺陷分类，你会发现自己提交的问题只有固定的几个类别；然后，再把一起完成测试执行 工作的其他测试人员发现的问题也汇总起来，你会发现，你所提交问题 的类别与他们有差异。这很正常，人的思维是有局限性，在测试的过程中， 每个测试人员都有自己思考问题的盲区和测试执行的盲区，有效的自我 分析和分析其他测试人员，你会发现自己的盲区，有针对性的分析盲区， 必定会在下一轮测试用避免盲区。 总结： 限于文章的篇幅，本文不可能给出一个类似于 checklist 的指导性 的软件测试新手入门。无论从事软件测试还是从事其它的工作，技术上 的和技巧上的问题都可以通过查询相关的软件测试技术书籍获取，掌握 一套基本的方法论是最重要的。以上文字，都是作者从事软件测试工作 积累的经验之谈，如发现谬误之处请不吝指出。 WWW.51testing.com....