软件测试注意事项_第1页
软件测试注意事项_第2页
软件测试注意事项_第3页
软件测试注意事项_第4页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

在目前的国内环境下 我们几乎看不到完整准确详细的客户需求说明书 而且每一款 软件的开发都需要一定的周期 在软件开发过程中客户的需求一般情况下都不会做到一成 不变 尤其是复杂的 开发周期长的软件 这就导致追求完美的测试变得不太可能 因此 作为一个优异的测试人员 追求软件质量的完美固然是我们的宗旨 但是明确软件测试现 实与理想的差距 在软件测试中学会取舍和让步 对软件测试是有百益而无一弊的 我们应该如何在软件测试的过程中尽可能多的发现问题呢 测试过程中我们应该注意 什么呢 我想说 成败在于细节 大到整个系统的架构流程 小到页面上的一个字体或标 点 都是我们需要注意的地方 1 查找查找 bug 时的注意事项时的注意事项 1 说白了 软件系统的实现过程就是一组控件实现自己的功能逻辑的过程 下面先 让我们通过几个常用的 web 控件 来说明一下我们需要注意的地方 文本框 TextBox 文本框更多的情况下是用来输入信息的 文本框都一样 可是不同地方的文本框 需要输入的信息就不会都一样了 比如说 有的是用来输入时间日期的 有的是 用来输入文字的 首先我们要结合需求 确定文本框的具体作用 要是用来输入 日期时间的 就要注意可以输入几种格式的日期时间 是只读的 还是可进行手 动修改的 是否对汉字 特殊符号等做了输入限制 很多时候 录入不匹配的信 息 系统会出现错误 要是用来输入文字的 验证是否对录入的文字长度做了限 制 如果超出数据库设置的最大值 会出错 还要注意文本框设置的可视长度 和录入的信息以及页面的整体风格是否和谐 标签 label 标签 基本上不用实现什么逻辑功能 只是起到显示标记的作用 对于标签 我 们注意的就是不要出现错别字 当然 任何地方都不能有错别字这样低级的错误 当标签和其它控件联合使用的时候 我们要结合页面的整体风格 确认它的设置 是否合适 如 label 与其他控件之间的距离 标签的字体样式及颜色是否合适等 单选按钮 RadioButton 单选按钮 顾名思义 就是只能选择一个 一般情况下 单选按钮都是以组出现 的 如录入性别信息时 有 男 和 女 两个选项 我们要确认只能选择其中 的一种 不允许两项都可以选择 而且提交的是选择的信息 复选框 CheckBox 可以这样说 复选框和单选按钮的作用是相对的 使用复选框的地方 一定是要 求可以进行多选的 自然就要验证是否实现了多选功能 这里我举这样一个例子 有 A B C 三个查询条件 是用复选框的形式实现的 当验证完每一个查询条 件后 最好再进行组合验证 就是说当只选择 A 和 C 或 B 和 C 时进行查询 也 许有时候 bug 是由后台查询语句出错导致的 并不是复选框本身的错误 我想说 的是不要忘记进行这样的测试验证 下拉列表 DropDownList 下拉列表的作用和单选按钮的功能有些相似 从列表中选择一条自己需要的信息 很多时候 列表的选项中有一条是使用频率最多的 即使用户没有做特殊要求 系统最好把使用频率最多的那一项设置为默认选项 这样可省去用户的一次操作 步骤 不仅是这里 要注意整个系统中对默认选项的设置 软件就是应该最大程度 的方便用户 而且还要注意下拉列表的宽度是否合适 列表信息是否显示完全了 按钮 Button Submit 我们要注意 Button 和 submit 两种按钮的不同之处 Button 主要是用来实现相应的 方法函数 submit 是用来提交相应的表单到相应的 action 处 这里有一点就是 当单击执行一个删除类的按钮时 一定要加上提示信息 而且提示信息上要有确 定和取消功能 以防用户不小心删错信息 2 现在的软件系统不再像以前那样单调 软件中实现了很多特效 举一个简单的例 子来说明一下 比如对一个按钮 当光标放到上面的时候 它是一种效果 当光 标离开之后 它又是另一种效果 也要注意光标的变化 当光标在可输入的文本 框上面时是 I 形状的 在一般的按钮上是弯曲三个手指的小手形状的 我们 要注意特效的统一性 而且特效也不是用的越多越好 效果的实现使系统变得更 加的多彩 用户也会更加愉快的使用软件 3 每一个稍微复杂一点的系统一般都是由多个页面组成的 而不会只使用一个单调 的页面 这时我们就要注意界面显示的色调风格是否统一 字体大小从标题到具 体内容是否体现出层级 同类 同层次的风格设置是否统一 虽说系统可以由多 个界面组成 但是我们也不希望看到冗余的界面 也许有的需求中并没有对界面 作出特殊的要求 但是我认为高质量的界面也是一款高质量的软件不可或缺的组 成部分 4 测试软件时 一定不要漫无目的的测来测去 这样不仅会增大工作量 而且也不 能对系统作出彻底的测试 我们要有计划有目的的进行测试工作 要是担心忘 记某些功能点 地毯式 测试也是行得通的 从页面的第一个功能点到最后一 个进行地毯式的搜索测试 5 注意界面上的分页和滚动条等小问题 有的地方信息很少 一页足可以显示完 就不需要分页功能了 有的窗口会看到滚动条 如果再把窗口设置的大一点 就 可以全部显示了 那就最好把滚动条去掉 我想每个用户都希望一眼就看到所有 的信息 而不想拉来拉去的 还有就是该有时间的地方 一定要有时间信息 尤 其是涉及到打印报表的地方 6 一般的系统都需要使用用户名和密码登陆 而且会为不同的用户分配不同的权限 不要总是使用正确的用户和密码在相应的权限范围内进行测试工作 从打开登陆 窗口的那一刻就要意识到测试工作已经开始了 在测试过程中不要按部就班的操 作程序 你也不知道用户在使用过程中会怎样操作程序 有时候就要反其道而行 之 要知道测试是具有破坏性的 7 用户使用软件的环境和软件开发时的环境不可能完全一样 我们可以考虑并验证 以下这几个问题 其他的浏览器是否有相同的问题 其他的软硬件配置是否有相同的问题 不同的安排设置是否有相同的问题 以前的版本否有相同的问题 2 提交提交 bug 时的注意事项时的注意事项 1 发现一个问题时 不必急着提交 可以先做验证 包括复现 对比测试等 进行证 实 看是概率性问题还是每次必现的问题 需要时也应使用不同版本不同机器做 对比验证 当然 如果已经很确信是一个 bug 了 也就不用浪费时间去对比验证 了 2 描述要清晰 准确 不要使用含糊的词语 例如 好像 似乎 来描述发现的现象 关于这点 如测试某款软件时 提交一个 bug 描述为 软件帮助说明中好像有错 别字 并没有说出哪一页哪一行以及具体哪个字错了 应该修改成什么样的 因此就不能说是个好的描述 3 要考虑开发人员的感受 有些问题尤其是有些主观性比较强的问题 在问题描述 中一般不要出现带强烈感情色彩的词语标点符号 如 要求 必须 和感叹号等 特殊情况除外 在提交此类问题时可以使用一些诸如 建议 希望 请 之类比较委婉些的词语 4 不能确认一个现象是不是一个 bug 的时候可以向其他人或者开发人员进行确认 然后再去提交 5 概率性的问题 测试过程中难免遇到一些概率性问题 很难找出其产生的规律 甚至该问题在测试过程中只出现一次 对于此类问题也一定要提交 并补充说明 无法复现或者无规律 6 描述问题时 要实事求是 不要夸大 比如概率性问题 本来出现的概率只有 10 你把它写成 50 都是不应该的 7 提交 bug 时 应该在描述清楚问题点的时候把正确的预期输出结果写明 即正确 的结果应该是什么样的 这点很重要 现在我们提交的 bug 中有些测试和开发双 方都知道该修改成什么样子了 而在 bug 描述中未写出修改成什么样子的 如 来电时按挂机键不能拒接来电 这样描述一个 bug 并没有写明该如何修改 一 般这样描述大家一看就知道该如何修改 所以写不写预期正确结果大家都可以接 受 但对于有些 bug 的描述一定要把预期的正确结果给写进去 否则开发人员会 无所适从 不知道该修改成什么样子的 8 很多时候 提交的 bug 都需要重现 而有的 bug 是在测试过程中偶然间发现的 时间一长 会对发现 bug 时的特定数据或环境模糊 导致不能重现 bug 所以提 交 bug 时描述的越详细越好 如果语言文字难以清楚的描述出发现的问题 最好 能附件图片或者 log 记录等做辅助说明 9 提交测试 bug 的时候 如果该问题在某一特定环境下才能出现 一定要将该问题 产生的环境 硬件 软件 描述清楚 10 提交问题前要清楚的知道软件需求 规格定义 相信很多人都遇到过这样的尴尬 情况 提交了一个重要问题后 却被告知其实那并不是一个问题 软件就是那样 设计的或者需求就要求那样处理的 11 有些问题出现了 不一定就是我们测试软件本身的问题 也可能是其他一些问题 导致的 如 手机通话时自动掉线 问题 这有可能是信道切换失败导致的 是网 络的问题 不是我们手机软件本身的问题 类似情况还会很多 这都我们有着丰 富的产品背景知识 12 编写 bug report 没有什么定式 没有绝对的范本 最基本的是能够让客户或目标 修改 浏览 bug report 人员看懂 而且在短时间内 而不需反复思考的 其他有 时要考虑目标读者的一些喜欢 例如有些类似的 bug 到底是合并还是单独提交 bug 的步骤划分 到底是每一步都为一点 还是有些点可以合并 在这一点上我 觉得 灵活和适应 是很关键的 13 在发现一个 Bug 并填写完 bug report 之后 在 review 的时候 需要特别注意的一 点是 这个 bug report 会不会让其他人还有联想或发挥的空间 一个好的 bug report 是不可以细分的 换句话说就是这个 bug 是不会让他人觉得你还有些地方 需要在测试一下 或许还有其他的问题 例如 有个测试人员发现在输入 16 这 个数字 允许范围内 且提交时系统会返回一个错误 不能输入 48 以下的数字 这 确实是一个错误 但是如果就只按现在的步骤提交 另一个可能会有这样的想法 是不是输入 48 以下的数字都会有这样的问题呢 这样他有可能要求你在测试其他 的数据 这样就延长了这个 bug 的生命期 而且浪费了大家的时间 14 Bug 提交完毕后 并不是就万事大吉了 后续跟踪验证等还多着呢 3 Bug 提交之后需要注意的事项提交之后需要注意的事项 1 如果编程人员需要问题重现 应尽量减少重现的步骤以达到用最少的步骤来重现 问题 这对编程人员来说是很有帮助发现问题根源的 因为最少的步骤可以开发 人员迅速 准确的锁定问题的根源 2 最好由报 bug 的人验证 bug 是否可以关闭 任何人都可以修复 bug 但只有那个 发现 bug 的人才能够确信 bug 是否真正的已被修复 3 当你的 bug 报告以 not repro 不可重现 打回给你时 先检查一个步骤是否有遗漏 或清晰 再去找编程人员 编程人员通常是在无法用 bug 报告中的步骤重现 b

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论