面向软件测试新手的若干个关注点分析.docx

1、面向软件测试新手的若干个关注点分析一 软件测试 从零开始 511 引言 512 测试准备工作 5121 向有经验的测试人员学习 5122 阅读软件测试的相关书籍 6123 走读缺陷跟踪库中的问题报告单 6124 走读相关产品的历史测试用例 6125 学习产品相关的业务知识 613 识别测试需求 7131 主动获取需求 7132 确认需求的优先级 8133 加入开发小组的群组 8134 与开发人员为邻 814 测试用例设计 8141 测试用例的基本格式 8142 重用同类型项目的测试用例 9143 利用已有的软件 Checklist 9144 加强测试用例的评审 10145 定义测试用例的执行顺

2、序 1015 测试用例执行 10151 搭建软件测试环境，执行测试用例 10152 测试执行过程应注意的问题 11153 及时更新测试用例 11154 提交一份优秀的问题报告单 1216 测试结果分析 1217 总结 13二 软件测试的常识 1321 引言 1322 软件测试常识 13221 测试是不完全的（测试不完全） 13222 测试具有免疫性（软件缺陷免疫性） 14223 测试是 “ 泛型概念 ” （全程测试） 14224 80-20 原则 14225 为效益而测试 15226 缺陷的必然性 15227 软件测试必须有预期结果 15228 软件测试的意义 - 事后分析 15229 结论：

3、 15三 浅谈软件开发中的注意事项 1631 项目设计 1632 设计变化和需求变化 1633 代码编写 17331 源程序文件结构 17332 界面设计风格的一致性 17333 编辑风格 17334 命名规 1834 BUG修补 1835 开发人员的测试 18四 软件测试的若干问题 1941 前言 1942 博弈的各方 1943 测试的过程 2044 测试所具备的素质 2045 自动化测试 2046 测试的误区 21五 浅谈功能测试用例模板设计 2151 Excel 模版 2152 测试用例状态转换分析 23六 如何提高软件质量 2361 什么是质量 2462 流程对质量的贡献 2563 流

4、程与技术 2764 全面质量管理 2865 关注测试 2966 成功的铁三角 3067 国际上流行的质量标准 3068 如何起步 32七 ISO和CMM，我们该选择谁 3271 管理水平的适用性 3372 复杂度的适用性 33721何谓研发过程复杂度 34722 何谓组织机构复杂度 3473 量化管理的适用性上 3574 结论 36八 如何做好单元测试 3681 前言 3682 组织结构应该保证测试组参与单元测试 3683 加强单元测试流程规性 37831 制订单元测试的过程定义 37832 单元测试工作产品必须纳入配置管理 38833 必须制订覆盖率指标和质量目标来指导和验收单元测试 388

5、34 加强详细设计文档评审 3984 单元测试者技能的提高 39841 加强对单元测试人员的技能培训 39842 必须引入工具进行辅助 40843 单元测试者加强对被测软件的全面了解 4085 结尾 40九 漫谈人机界面测试 4191 一致性测试 4192 信息反馈测试 4293 界面简洁性测试 4294 界面美观度测试 4295 用户动作性测试 4396 行业标准测试 4397 小结 44十 基于Web的系统测试方法 44101 功能测试 451011 测试 451012 表单测试 451013 Cookies测试 451014 设计语言测试 451015 数据库测试 46102 性能测试

6、461021 连接速度测试 461022 负载测试 461023 压力测试 46103 可用性测试 471031 导航测试 471032 图形测试 471033 容测试 471034 整体界面测试 47104 客户端兼容性测试 481041 平台测试 481042 浏览器测试 48105 安全性测试 48106 总结 49十一 为盈利而测试 49111 引言 49112 什么是软件测试 50113 六个误区 501131 误区一：忽视对正常输入的测试 501132 误区二：忽视设计阶段的参与与评估 501133 误区三：忽视测试计划与测试文档的建立及维护 511134 误区四：忽视缺陷的分析，

7、报告及跟踪 511135 误区五：错误的测试目标及测试终止条件 511136 误区六：不懂得合理调配使用测试人员的知识技能结构 51114 软件质量与软件测试 52115 软件测试的经济目的 541151 满足用户需求，提高产品的竞争力，最终提高产品的销售量 541152 尽早发现缺陷，降低后继质量成本 54116 何时应当停止测试 56十二 整体性能测试剖析 57十三 性能测试工具之研究 62131 性能测试的意义 62132 性能测试工具综述 63133 性能测试工具的体系架构 64134 虚拟用户产生器 Vugen 65135 Proxy 二次捕获的问题 67136 关联的问题 6813

8、7 脚本的问题 70138 Conductor 和 Player 部分 71139 Conductor 和 Player 的技术要点 721310 数据分析工具 Analysis 721311 结束语 72十四 性能测试原理及性能测试实例分析 73141 软件测试中的性能测试 731411 性能测试的含义 731412 性能测试的分解 73142 一个性能测试实例 741421 被测系统 741422 对被测系统进行性能测试 75145 总结 80十五 软件GUI测试中的关注点 80151 不能不说的二个问题 811511 软件测试中的“二八”原则 811512 软件黑盒测试解决的问题 811

9、52 软件黑盒测试常见错误类型及说明 811521 用户界面错误 811522 功能性 811523 人机交互 82153 命令结构和录入 871531 不一致性 871532 “最优化” 871533 菜单 89154 遗漏的命令 901541 状态转换 901542 危机预防 901543 由用户进行的错误处理 911544 其他问题 91155 程序僵化 921551 用户可调整性 921552 控制方式 93156 性能 941561 降低程序速度 941562 缓慢回应 941563 如何减少用户吞吐量 941564 反应拙劣 941565 没有提前输入 951566 没有给出某个操

10、作会花很长时间的警告 951567 程序太多提示和询问 951568 尽量使用简单命令和提示 95157 输出 951571 不能输出某种数据 951572 不能重定向输出 951573 与一个后续过程不兼容的格式 961574 必须输出的很少或很多 961575 不能控制输出布局 961576 荒谬的精度输出级别 961577 不能控制表或图的标记 961578 不能控制图形的缩放比例 96158 错误处理 961581 错误预防 961582 错误检测 971583 错误恢复 981584 边界相关的错误 991585 计算错误 100159 小结 100十六 软件测试技术 10016.1

11、 软件测试基础 10116.1.1 测试目标 10116.1.2 测试原则 10116.1.3 可测试性 10216.2 测试用例设计 10416.3 白盒测试 10416.4 基本路径测试 10516.4.1 流图符号 10516.4.2 环形复杂性 10616.4.3 导出测试用例 10616.4.4 图矩阵 10816.5 控制结构测试 10816.5.1 条件测试 10816.5.2 数据流测试 11016.5.3 循环测试 11116.6 黑盒测试 112一 软件测试 从零开始【摘要】本文面向软件测试新手，从测试前的准备工作、测试需求收集、测试用例设计、测试用例执行、测试结果分析几个

12、方面给出建议和方法。鉴于国的软件开发、测试不规的现状，本文为软件测试新手提供了若干个软件测试的关注点。【关键词】软件测试、测试用例、测试需求、测试结果分析 11 引言 几年前，从学校毕业后，第一份工作就是软件测试。那时候，国的软件企业大多对软件测试还没有什么概念，书店里除了人杰编写的计算机软件测试技术之外，几乎没有其它的软件测试相关书籍，软件测试仅仅在软件工程的教材中作为一个章节列出来，因此，我对软件测试一无所知。不过，在正式走上工作岗位之前，公司提供了为期两周的系统的软件测试技术专题培训，对接下来的软件测试工作有很大的指导意义。现在，我继续从事软件测试的培训与咨询服务，在这个过程中，亲眼目睹

13、了很多软件测试新手面对的困惑，他们初涉软件测试行业，没有接受系统的培训，对软件测试一无所知，既不知道该测试什么，也不知道如何开始测试。下面针对上述情况，给出若干解决办法。 12 测试准备工作 在测试工作伊始，软件测试工程师应该搞清楚软件测试工作的目的是什么。如果你把这个问题提给项目经理，他往往会这样回答： “ 发现我们产品里面的所有 BUG ，这就是你的工作目的 ” 。作为一名软件测试新手，如何才能发现所有的 BUG ？如何开始测试工作？即便面对的是一个很小的软件项目，测试需要考虑的问题也是方方面面的，包括硬件环境、操作系统、产品的软件配置环境、产品相关的业务流程、用户的并发容量等等。该从何处

14、下手呢？121 向有经验的测试人员学习 如果你进入的是一家运作规的软件公司，有独立的软件测试部门、规的软件测试流程、软件测试技术有一定的积累，那么，恭喜你！你可以请求测试经理委派有经验的测试人员作为你工作上的业务导师，由他列出软件测试技术相关书籍目录、软件测试流程相关文档目录、产品业务相关的文档目录，在业务导师的指导下逐步熟悉软件测试的相关工作。其实，在很多运作规的软件公司，已经把上述的师父带徒弟的方式固化到流程中。 如果你进入的是一个软件测试一片空白的软件企业，那么，也恭喜你！你可以在这里开创一片自己的软件测试事业，当然，前提是老板确实认识到软件测试的重要性，实实在在需要提高产品的质量。这时

15、候，可以到国的软件测试论坛和相关上寻找软件测试资源，这种情况下，自学能力和对技术的悟性就至关重要了。 122 阅读软件测试的相关书籍 现在，中文版的软件测试书籍越来越多，有的是国人自己写的，有的是翻译国外经典之作。可以到 .chinapub. 或者 .cnforyou. 等网络购书的站点查找软件测试相关的书籍。目前，从国外引入的软件测试书籍有很多经典之作，但是，翻译成中文后，翻译质量对阅读效果有很大的影响。 123 走读缺陷跟踪库中的问题报告单 如果您所在的公司已经有软件缺陷跟踪库了，无论采用的是商用工具，如 ClearQuest 、 TestDirecter 等工具，还是采用的 Bugzil

16、la 、 Mantis 等开源工具，这都无关紧要，缺陷跟踪库中的缺陷报告单才是有价值的。缺陷跟踪库中的问题报告单是软件测试工程师工作绩效的集中体现，同时也是软件产品问题的集中体现。一般来说，缺陷报告单中最关键的几个部分包括：第一部分是发现缺陷的环境，包括软件环境、硬件环境等；第二部分是缺陷的基本描述；第三部分是开发人员对缺陷的解决方法。通过对上述缺陷报告单的三个部分作仔细分析，不知不觉你已经吸收了其他软件测试人员的工作经验，并掌握了软件产品常见的基本问题。这是迅速提高软件测试经验的好方法。 124 走读相关产品的历史测试用例 如果你所在的公司有测试用例管理系统，那么，走读相关产品的软件测试用例

17、是迅速提高测试用例设计水平的一条捷径。走读测试用例也是有技巧的。测试用例写作一般会包括测试用例项和根据测试用例项细化的测试用例，下面举例说明。 “ 测试用户登录的功能 ” 是一个测试项，该测试项的目的是测试用户登录功能是否正确，是否能够完成正常的登录功能，是否能够对非法用户名和密码做异常处理等等。因此，根据该用例项，可以设计出若干个测试用例，大多数情况下，测试用例项和测试用例是一对多的关系。 通过走读测试用例项目，你可以掌握应该从哪些功能点着手未来的测试工作；通过走读软件测试用例，你可以了解如何根据被测试的功能点开展软件测试用例的设计工作，包括如何确定测试用例的输入、测试用例的操作步骤和测试用

18、例的输出结果等。 总之，走读其他软件测试人员设计的优秀软件测试用例，是提高自身用例设计水平的好方法。 125 学习产品相关的业务知识 软件测试人员不仅要掌握软件测试技术相关知识，对产品相关的业务知识也要学习。这很好理解，如果从事财务软件的测试工作，一定要学习财务知识；如果从事通讯产品测试工作，那么相关的通讯理论知识也是必须的；如果从事银行软件的测试，银行的业务流程也是不可或缺的知识点。 因此，在学习软件测试技术的同时，千万不要忽略产品相关业务知识的学习。如果你是一个软件测试技术专家，但是对产品业务知识一无所知，那么也只能测试出来纯粹的软件缺陷，而面对眼前出现的产品业务相关的缺陷，很可能是视而不

19、见，如此这般，软件测试的效果会大打折扣。 13 识别测试需求 识别测试需软件测试的第一步。如果开发人员能够提供完整的需求文档和接口文档，那固然好。可以根据需求文档中描述的每个功能项目的输入、处理过程和输出，来设计测试用例。如果开发人员没有提供软件需求文档，那该如何是好？下面给出几个有效的方法： 131 主动获取需求 开发人员通常不会更好地考虑软件测试，如果没有开发流程的强制规定，他们通常是不愿意提供任何开发文档，即便有强制规定，需求文档也未必能够真正指导软件系统测试工作。因此，需要测试人员发挥主观能动性，与相关的软件开发项目经理和软件开发人员保持沟通，了解软件实现的主要功能是什么，并记录得收集

20、到的信息。一般来说，开发人员即便没有提供相关需求文档，也会保存一些简单的过程文档，主动向开发人员索要这些文档，可以作为测试的参考。此外，可以与公司的技术支持人员交流，技术支持人员是最贴近用户的人，因此，通过交流可以获取第一手的用户使用感受，在测试的过程中会更加贴近用户。 当拿到相关的资料后，从哪些方面分析需求？如何与开发人员交流需求？其实，只要把握需求分析的几个关键的点就可以解决问题：输入、处理过程、输出、性能要求、运行环境，下面针对每一个项目逐一分析： 软件输入： 与该需求相关的一切可能输入，可以从这几方面考虑，输入来源、输入参数的数量、输入参数的度量单位、输入参数的时间要求、输入参数的精度

21、和输入参数的有效输入围。在测试用例设计中，这部分容作为测试用例输入的依据。 处理过程： 描述对输入数据所执行的所有操作和如何获得输出的过程。测试人员了解处理过程即可，在测试过程中发现 BUG 时候，如果对处理过程了解的深入，对定位问题根源有很大的帮助。 软件输出： 描述每个需求的输出结果，包括输出的位置（如计算机显示器、打印机，文件），输出参数的数量、输出参数的度量单位、输出参数的时序、输出参数精确度、输出参数的有效输出围、错误消息。在测试用例设计中，这部分容作为测试用例的预期输出。 性能要求： 与该需求相关的性能要求，比如 “ 插入 ATM 取款卡后， 3 秒钟弹出提示用户取款的图形界面 ”

22、 。 3 秒钟这一限制，就是对需求的基本性能要求。 运行环境： 软件的运行所需的环境，包括硬件平台的要求、操作系统的要求、数据库的要求，以及其它相关支撑软件的要求。 132 确认需求的优先级 确认需求的优先级是很必要的，如果在产品进度比较紧的情况下，测试人员可以考虑优先测试优先级高的需求项，如果进度允许，那么在测试优先级低的需求项，如果进度不允许，那么就放弃测试优先级低的需求项。如果软件公司有规的流程支撑，开发人员在提供软件需求文档的时候，应该在文档中确定需求的优先级。但是，如果开发人员连基本的软件需求文档都没有提供，又怎能指望他们确定软件需求的优先级？如果是这样，需求的优先级只能由测试人员完

23、成了。 133 加入开发小组的群组 测试人员需要通晓被测试产品，但是，产品在开发的过程中往往是不断变化的。如果软件开发团队有一套变更控制流程，测试人员会对产品的变更了如指掌。如果没有变更控制，那就要采用其他的土方法了。如果公司里面有自动化办公系统，也许采用的是 Lotus Notes 系统，也许使用的是 E-mail 系统，测试人员应该加入到开发人员的群组中。当开发人员通过讨论问题、通知召开技术会议的时候，测试人员可以及时知晓，如果必要，可以参加开发人员的技术会议。即便公司里面有了软件变更控制流程，加入到开发群组也是一个很好的习惯。 134 与开发人员为邻 建议测试人员与开发人员为邻。我所在的

24、测试组曾经与开发组是在相邻的写字间里，开发人员与测试人员的关系非常融洽，抛去同事关系，大家还是不错的朋友。不管开发人员有什么样的活动，测试人员都能第一时间获得信息。无论从事软件测试工作，还是从事其它的工作，与工作中上下游环节的同事保持良好的个人关系对工作有很大便利。一般的公司部都存在部门墙，良好的人际关系是打通部门墙的手段之一。向领导建议测试人员与开发人员为邻，这很必要。 14 测试用例设计 测试需求收集完毕后，开始测试设计。测试用例是什么？测试用例就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。设计测试用例需要考虑以下问题： 141 测试

25、用例的基本格式 软件测试用例的基本要素包括测试用例编号、测试标题、重要级别、测试输入、操作步骤、预期结果，下面逐一介绍。 用例编号： 测试用例的编号有一定的规则，比如系统测试用例的编号这样定义规则： PROJECT1-ST-001 ，命名规则是项目名称测试阶段类型（系统测试阶段）编号。定义测试用例编号，便于查找测试用例，便于测试用例的跟踪。 测试标题： 对测试用例的描述，测试用例标题应该清楚表达测试用例的用途。比如 “ 测试用户登录时输入错误密码时，软件的响应情况 ” 。 重要级别： 定义测试用例的优先级别，可以笼统的分为 “ 高 ” 和 “ 低 ” 两个级别。一般来说，如果软件需求的优先级为

26、 “ 高 ” ，那么针对该需求的测试用例优先级也为 “ 高 ” ；反之亦然， 测试输入： 提供测试执行中的各种输入条件。根据需求中的输入条件，确定测试用例的输入。测试用例的输入对软件需求当中的输入有很大的依赖性，如果软件需求中没有很好的定义需求的输入，那么测试用例设计中会遇到很大的障碍。 操作步骤： 提供测试执行过程的步骤。对于复杂的测试用例，测试用例的输入需要分为几个步骤完成，这部分容在操作步骤中详细列出。 预期结果： 提供测试执行的预期结果，预期结果应该根据软件需求中的输出得出。如果在实际测试过程中，得到的实际测试结果与预期结果不符，那么测试不通过；反之则测试通过。 软件测试用例的设计主要

27、从上述 6 个域考虑，结合相应的软件需求文档，在掌握一定测试用例设计方法的基础上，可以设计出比较全面、合理的测试用例。具体的测试用例设计方法可以参见相关的测试书籍，白盒测试方法和黑盒测试方法在绝大多数的软件测试书籍中都有详细的介绍，这里不作赘述。 142 重用同类型项目的测试用例 如果我看得远，那是因为我站在巨人的肩上 牛顿。 一般来说，每个软件公司的项目可以分为固定的几大类。可以按业务类型划分，比如 ERP 软件、产品数据管理软件、通信软件、地理信息系统软件等等；可以按软件结构来划分，比如 B/S 架构的软件、 C/S 架构的软件、嵌入式软件等等。参考同类别软件的测试用例，会有很大的借鉴意义

28、。如果，公司中有同类别的软件系统，千万别忘记把相关的测试用例拿来参考。如果，系统非常接近，甚至经过对测试用例简单修改就可以应用到当前被测试的软件。 “ 拿来主义 ” 可以极大的开阔测试用例设计思路，也可以节省大量的测试用例设计时间。 143 利用已有的软件 Checklist 在上面一个小节中，按照不同的规则划分了不同的软件类型。每种类型的软件都有一定的测试规，比如， WEB 软件系统在系统测试过程中，会有一系列的式，比如针对 Cookie 就会有很多测试点。在设计测试用例的时候，不妨到网上去搜索相关的 Checklist ，不过国外的很少有这方面的资料，即便有，也不是特别系统。可以先找一份粗

29、糙的 Checklist ，然后，在设计测试用例的时候不断的去完善它，以作为下次测试用例设计的基础。 144 加强测试用例的评审 测试用例设计完毕后，最好能够增加评审过程。同行评审是 CMM3 级的一个 KPA ，如果因为公司没有通过 CMM3 级，就不开展同行评审是不恰当的。测试用例应该由产品相关的软件测试人员和软件开发人员评审，提交评审意见，然后根据评审意见更新测试用例。 如果认真操作这个环节，测试用例中的很多问题都会暴露出来，比如用例设计错误、用例设计遗漏、用例设计冗余、用例设计不充分等等；如果同行评审不充分，那么，在测试执行的过程中，上述本应在评审阶段发现的测试用例相关问题，会给测试执

30、行带来大麻烦，甚至导致测试执行挂起。 145 定义测试用例的执行顺序 在测试用例执行过程中，你会发现每个测试用例都对测试环境有特殊的要求，或者对测试环境有特殊的影响。因此，定义测试用例的执行顺序，对测试的执行效率影响非常大。比如某些异常测试用例会导致服务器频繁重新启动，服务器的每次重新启动都会消耗大量的时间，导致这部分测试用例执行也消耗很多的时间。那么在编排测试用例执行顺序的时候，应该考虑把这部分测试用例放在最后执行，如果在测试进度很紧的情况下，如果优先执行这部分消耗时间的异常测试用例，那么在测试执行时间过了大半的时候，测试用例执行的进度依然是缓慢的，这会影响到测试人员的心情，进而导致匆忙地测试后面的测试用例，这样测试用例的漏测、误测就不可避免，严重影响了软件测试效果和进度。因而，合理地定义测试用例的执行顺序是很有必要的。 15 测试用例执行 测试用例设计完毕后，接下来的工作是测试执行，测试执行中应该注意以下几个问题： 151 搭建软件测试