软件测试

1 毕业论文毕业论文 专专 业业: :移动互联应用技术移动互联应用技术 2 摘要 从软件产业的发展初期到目前的大型软件开发过程，软件测试已成 为其中一个不可分割的部分。随着软件规模的日益增大，软件测试 问题也日益突出，现代社会对软件的依赖越来越强,高可信软件测试 有着广泛的需求，基于缺陷模式的软件测试技术作为高可信软件的 重要保证,可以大大降低软件的缺陷密度,提高软件的可信性。本文 从测试的基本概念入手,深入剖析软件测试相关理论 关键字：关键字：软件测试、白盒测试、黑盒测试 3 目录 摘要摘要2 1 软件测试的发展史软件测试的发展史.4 2 软件测试的相关背景软件测试的相关背景.5 3 软件测试的概述软件测试的概述.6 3.1 软件测试的定义.6 3.2 软件测试的描述.6 3.3 软件测试的目的.7 3.4 软件测试的原则.8 4 软件测试的发展趋势软件测试的发展趋势.9 4.1 国外发展前景.9 4.2 国内发展前景.9 4.3 谈国内软件测试行业目前发展遇到的瓶颈问题.11 5 软件测试的内容软件测试的内容.12 5.1 验证(VERIFICATION)12 5.2 确认(VALIDATION)13 6 软件测试的分类软件测试的分类.13 6.1 常用分类.13 6.1.1 黑盒测试.15 6.1.2 白盒测试.15 6.1.3 静态测试.18 6.1.4 动态测试.18 7 软件测试的过程软件测试的过程 .18 8 总结总结.20 9 参考文献参考文献.21 4 1 软件测试的发展史 软件测试的发展历史：20 世纪 60 年代（软件工程建立前） ，为表明 程序正确而进行测试。1972 年在北卡罗来纳大学举行了首届软件测 试正式会议。 1975 年 John Good Enough 和 Susan Gerhart 在 IEEE 上发表了测试数据选择的原理的文章，软件测试被确定为一种 研究方向。 1979 年，Glenford Myers 的软件测试艺术 ，对测试 做了定义：测试是为发现错误而执行的一个程序或者系统的过程。. 20 世纪 80 年代早期， “质量”的号角开始吹响。软件测试定义发生 了改变，测试不单纯是一个发现错误的过程，而且包含软件质量评 价的内容。制定了各类标准。. 1983 年，Bill Hetzel 在软件测 试完全指南中指出：测试是以评价一个程序或者系统属性为目标 的任何一种活动，测试是对软件质量的度量。. 20 世纪 90 年代， 测试工具盛行起来。. 1996 年提出的测试能力成熟度 TCMM（Testing Capability Maturity Model） 、测试支持度 TSM（Testability Support Model） 、测试成熟度 TMM（Testing Maturity Model） 。. 到了 2002 年，Rick 和 Stefan 在系统的软 件测试一书中对软件测试做了进一步定义：测试是为了度量和提 高被测软件的质量，对测试软件进行工程设计、实施和维护的整个 生命过程。 5 2 软件测试的相关背景 相关背景：前段时间, 就是在我没有认真了解测试行业之前, 可能由于测试在中国的重视程度的问题, 我也一直认为测试应该是 不重要的, 甚至认为有必要有专门的测试职业吗？认为软件主要是 开发人员的事, 软件的成果也是由开发人员决定的, 当我在参加工 作后, 真正从学校的学习环境中走上实际运用开发的时候, 事实上 真的不是那么一回事哦。软件无处不在, 软而, 软件是人编的 所以不完美。臭名昭著的软件测试案例： 1、迪士尼的狮子王 （19941995）软件在少数系统中能正常 工作, 但在大众使用的常见系统中不行。后来证实, 迪士尼公司没 有对市场上投入实用的各种 pc 机型进行正确的测试。 2、英特尔奔腾浮点除法软件缺陷（1994）英特尔为自己处理软 件缺陷拿出 4 亿美元支付更换坏芯片的费用。导致付出如此昂贵的 代价, 其主要原因是发现了软件缺陷没有正确的处理。 3、美国航天局火星极地登陆（1999）该项目使用前有经过测试, 两个测试小组双方独立工作都很好, 但从未走在一起。 4、爱国者导弹防御系统 （1991）一枚导弹在多哈击毙 28 名美 国士兵, 症结在于一个软件缺陷：一个很小的系统时钟错误累积起 来就可能拖延 14 小时, 造成跟踪系统失去准确度。在多哈袭击战中 系统被拖延 100 小时。 5、千年虫 （大约 1974）估计世界各地更换或升级该系统程序 6 解决原有 2000 年错误的费用已经超过数亿美元。 3 软件测试的概述 3.1 软件测试的定义 软件测试使用人工或者自动手段来运行或测试某个系统的过程, 其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果 之间的差别。它是帮助识别开发完成（中间或最终的版本）的计算 机软件（整体或部分）的正确度(correctness) 完全度 (completeness)和质量(quality)的软件过程；是 SQA(software quality assurance)的重要子域。 (1)测试并不仅仅是为了找出错误.通过分析错误产生的原因和 错误的发生趋势,可以帮助项目管理者发现当前软件开发过程中的缺 陷,以便及时改进； (2)这种分析也能帮助测试人员设计出有针对性的测试方法,改 善测试的效率和有效性； (3)没有发现错误的测试也是有价值的,完整的测试是评定软件 质量的一种方法。 3.2 软件测试的描述 测试是软件开发过程的重要组成部分, 是用来确认一个程序的 7 品质或性能是否符合开发之前所提出的一些要求。软件测试的目的, 第一是确认软件的质量, 其一方面是确认软件做了你所期望的事情 （Do the right thing）, 另一方面是确认软件以正确的方式来做 了这个事件（Do it right） ；第二是提供信息, 比如提供给开发人 员或程序经理的反馈信息, 为风险评估所准备的信息；第三软件测 试不仅是在测试软件产品的本身, 而且还包括软件开发的过程。如 果一个软件产品开发完成之后发现了很多问题, 这说明此软件开发 过程很可能是有缺陷的。 3.3 软件测试的目的 如果测试的目的是为了尽可能多地找出错误，那么测试就应该 直接针对软件比较复杂的部分或是以前出错比较多的位置。如果测 试目的是为了给最终用户提供具有一定可信度的质量评价，那么测 试就应该直接针对在实际应用中会经常用到的商业假设。 在谈到 软件测试时，引用 Grenford J. Myers 在The Art of Software Testing一书中的观点: (1)软件测试是为了发现错误而执行程序的过程; (2)测试是为了证明程序有错，而不是证明程序无错误; (3)一个好的测试用例是在于它能发现至今未发现的错误; (4)一个成功的测试是发现了至今未发现的错误的测试。 这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示 8 软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导， 认为发现错误是软件测试的唯一目，查找不出错误的测试就是没有 价值的，事实并非如此。 首先，测试并不仅仅是为了要找出错误。 通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者 发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也 能帮助我们设计出有针对性地检测方法，改善测试的有效性。其次， 没有发现错误的测试也是有价值的，完整的测试是评定测试质量的 一种方法。 3.4 软件测试的原则 1应当把“尽早和不断的测试“作为开发者的座右铭。 2程序员应该避免检查自己的程序, 测试工作应该由独立的专 业的软件测试机构来完成。 3设计测试用例时应该考虑到合法的输入和不合法的输入以及 各种边界条件, 特殊情况下要制造极端状态和意外状态, 比如网络 异常中断、电源断电等情况。 4一定要注意测试中的错误集中发生现象, 这和程序员的编程 水平和习惯有很大的关系。 5对测试错误结果一定要有一个确认的过程, 一般有 A 测试出 来的错误, 一定要有一个 B 来确认, 严重的错误可以召开评审会进 行讨论和分析。 6制定严格的测试计划, 并把测试时间安排的尽量宽松, 不要 9 希望在极短的时间内完成一个高水平的测试。 7回归测试的关联性一定要引起充分的注意, 修改一个错误而 引起更多的错误出现的现象并不少见。 8妥善保存一切测试过程文档, 意义是不言而喻的, 测试的重 现性往往要靠测试文档 4 软件测试的发展趋势 4.1 国外发展前景 在软件比较发达的国家，特别是美国，软件测试已经发展成为一个独立的产 业，主要体现: 软件测试在公司中占有重要的地位。比尔?盖茨曾在马萨诸塞州技术学院的 一次演讲中说:“在微软，一个典型的开发项目组中测试工程师要比编码工程师 多得多，可以说我们花费在测试上的时间要比花费在编码上的时间多得多” 。 在微软测试人员与开发人员比例一般为 1:1,甚至在 Windows 2000 开发团队 中，有 1800 个测试人员，900 个开发人员，测试人员与开发人员比例为:1:2。 软件测试理论研究蓬勃发展，每年举办各种各样的测试技术年会，发表了大 量的软件测试研究论文，引领软件测试理论研究的国际潮流。 软件测试市场繁荣。美国有一些专业公司开发软件测试标准与测试工具， MI、Compuware、MaCabe、Rational 等都是著名的软件测试工具提供商，它们 出品的测试工具已经占领了国际市场，目前我国使用的主流软件工具大部门是 国外产品，而且世界各地都可以看到它们出品的软件测试工具，可见国外的软 件测试已经形成了较大的产业。 10 4.2 国内发展前景 中国的软件测试技术研究起步于“六五”期间，主要是随着软件工程的研究 而逐步发展起来的，由于起步较晚，与国际先进水平相比差距较大。知道 1990 年，成立了国家级的中国软件评测中心，测试服务才逐步开展起来。因此，我 国无论是在软件测试理论研究还是在测试实践上，和国外发达国家都有不少差 距，主要体现在对软件产品化测试的技术研究还比较贫乏，从业人员较少，测 试服务没有形成足够的规模等方面。但是，随着我国软件产业的蓬勃发展以及 对软件质量的重视，软件测试越来越人们重视。软件测试正在逐步成为一个新 兴的产业。我国正在迈入测试时代，主要体现在以下几个方面: 我国著名著名的软件公司都已经或者正在建立独立的专职软件测试队伍，虽 然测试人员规模以及所占比例还不能和国外的大公司相比，但是毕竟在公司内 部贯彻了独立测试的意识。 国家人事部和信息产业部 2003 年关于职业资格认 证第一次在我国有了“软件评测师”的称号，这是国家对软件测试职业的高度 重视与认可。 在信息产业部关于计算机系统集成资质以及信息系统工程监理资质的认证 中，软件测试能力已经被定为评价公司技术能力的一项重要指标 ,2001 年信息 产业部发布的部长 5 号令，实行了软件产品登记认证制度，规定，凡是在我国 境内销售的产品必须到信息产业部备案登记，而且要经过登记测试。 自 2001 年起，国家质检总局和信息产业部每年都通过测试对软件产品进行 质量监督抽查。 国家各部委，各行业正在通过测试规范行业软件的健康发展起 到了很好的促进作用。 用户对软件质量要求越来越高，信息系统验收不再走过场，而要通过第三 方测试机构的严格测试来判定。 “以测代评”正在成为我国科技项目择优支持的一项重要举措，比如，国家 “863”计划对数据库管理系统、操作系统、办公软件、ERP 等项 11 目的经费支持，都是通过第三方测试机构科学客观的测试结果来决定的。 软件测试正在成为部分软件学院的一门独立课程，对我国软件测试人才的培养 起到了很好的作用。 第三方测试机构得到了蓬勃的发展，最近两年，在全国各地，新成立的软 件测试机构有 10 多家，测试服务体系已经基本确立。 可见我国的软件测试行业正处于一个快速成长的阶段，我们有理由相信，经 过一段时间的发展，我们会逐步缩小与国外发达国家的差距，从而带动整个软 件产业的健康发展。 4.3 谈国内软件测试行业目前发展遇到的瓶颈问题 可见软件测试在国内发展是如此之快,但是不可忽视的是,在技术方面跟国外 的还有较大的差距.毕竟软件测试在国内起步的晚,是相对年轻的行业.为了以后 更好的发展软件测试打下扎实的根基,应该多吸取国外的测试经验.那让我们一 起来看一下现今国内软件测试主要存在哪些瓶颈. 企业不够重视软件测试。软件行业在国内是属于一个热衷阶段，很多企业只 是看到了眼前的利润，追求短时间的价值回报。软件测试在企业是一个消耗资 金的部门，很多国内的很多中小企业还没有测试部门，就算是有也是不怎么受 重视。如果软件测试得不到重视，那么软件质量在未来是让人堪忧。久而久之， 导致客户对软件市场失去信任，结果是致命的，会严重的阻碍未来计算机的发 展。 缺少专业的从业人员。由于在国内软件测试行业起步晚，在企业里还没得到 足够的重视。企业招人也只要求是计算机相关专业的人都可以做测试，甚至有 些企业只要有相关培训机构的培训非计算机专业的人也可以做测试。这就导致 软件测试人员的专业素质普遍降低。为什么会出现这样的情况，很大程度上是 因为软件测试人员的培养在国内只有极少的高校才有该专业。目前我国多数的 检测工作还停留在设计人员一人身兼多职，这不仅不能保证检测工作的专业程 12 度，同时由于主观因素也会对最终的检测结果真实性受到一定的影响，使检测 工作貌似形同虚设，没有使最完善的软件系统投放到市场中去。如果雇佣专业 的检测分析人员会从更专业校验角度来为软件把关。不仅在研发投放之前进行 软件检测，在使用的过程中也会跟踪性服务，与客户和设计人员之间及时沟通， 及时对后期的问题进行修复并对下一批次软件的研发起到提醒的作用。但这些 我国目前都无法达到相应的标准。 软件测试缺乏统一标准。无论任何的检测都应该有一个与全国统一或是全世 界统一的标准，如此在交付完整软件时其兼容性可以得到最大的满足。如果任 意按自行设定的标准检测其结果不够具有说服力。一般来说。软件测试的代码 都是按一定标准进行编写，在实际工作中，测试代码是不能随意编写的，但是 实际工作中，编写出来的测试代码以及测试代码运行的情况往往表现出一种随 意性和无序性。当今软件测试行业对影响软件缺陷的重要度和修复度都缺乏统 一的标准，使得部分软件缺陷在修复的过程中难免引入新的软件缺陷，影响了 软件的正常使用。所以在今后的软件测试中，必须确保测试的标准要统一，要 求测试者真正做到按照统一的规定来测试。举一个简单的例子:软件工作人员一 般都知道，在软件测试中矩阵的行为测试，列为需求。矩阵中，用数字 l 标识 该行的测试用例核实了该列的需求。 总之，软件测试也应该是被扶植的计算机领域的朝阳产业，无论从人员的 纳入还是技术水平提高要双管齐下，突破目前的发展问题，大力弘扬产业的内 涵文化真正实现软件测试行业的发展创新。才能推动我国软件测试业的高效发 展。 5 软件测试的内容 5.1 验证(verification) 验证(verification)是保证软件正确地实现了一些特定功能的 13 一系列活动, 即保证软件做了你所期望的事情。(Do the right thing) 1.确定软件生存周期中的一个给定阶段的产品是否达到前阶段 确立的需求的过程； 2.程序正确性的形式证明, 即采用形式理论证明程序符号设计 规约规定的过程； 3.评市、审查、测试、检查、审计等各类活动, 或对某些项处 理、服务或文件等是否和规定的需求相一致进行判断和提出报告。 5.2 确认(validation) 确认(validation)是一系列的活动和过程, 目的是想证实在一 个给定的外部环境中软件的逻辑正确性。即保证软件以正确的方式 来做了这个事件(Do it right) 1.静态确认, 不在计算机上实际执行程序, 通过人工或程序分 析来证明软件的正确性； 2.动态确认, 通过执行程序做分析, 测试程序的动态行为, 以 证实软件是否存在问题。 软件测试的对象不仅仅是程序测试, 软件测试应该包括整个软 件开发期问各个阶段所产生的文档, 如需求规格说明、概要设计文 档、详细设计文档, 当然软件测试的主要对象还是源程序。 6 软件测试的分类 14 6.1 常用分类 软件测试的分类可以按照开发阶段、测试实施组织、测试技术、测试过程等 划分。下面重点介绍按照开发阶段划分: 按照开发阶段划分软件测试可分为:单元测试、集成测试、系统测试、确认 测试和验收测试。 单元测试 单元测试又称模块测试，是针对软件设计的最小单位程序模块进行正确 性检验的测试工作。其目的在于检查每个程序单元能否正确实现详细设计说明 中 的模块功能、性能、接口和设计约束等要求，发现各模块内部可能存在的各种 错误。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行 地独立进行单元测试。 集成测试 集成测试也叫组装测试。通常在单元测试的基础上，将所有的程序模块进行 有序的、递增的测试。集成测试是检验程序单元或部件的接口关系，逐步集成 为符合概要设计要求的程序部件或整个系统。 确认测试 确认测试是通过检验和提供客观证据，证实软件是否满足特定预期用途的需 求。确认测试是检测与验证软件是否满足软件需求说明书中规定的要求。 系统测试 系统测试是为验证和确认系统是否达到其原始目标，而对集成的硬件和软件 系统进行的测试。系统测试是在真实或模拟系统运行的环境下，检查完整的程 序系统能否和系统(包括硬件、外设、网络和系统软件、支持平台等)正确配置、 连接，并满足用户需求。 验收测试 15 按照项目任务书或合同、供需双方约定的验收依据文档进行的对整个系统的 测试与评审，决定是否接受或拒收系统。 按照测试实施组织划分:开发方测试、用户测试、第三方测试。 , 按照测 试技术划分:白盒测试、黑盒测试、灰盒测试。或静态测试盒动态测试。 从是否需要执行被测软件的角度, 可分为： 静态测试 和动态测试 从测试是否针对系统的内部结构和具体实现算法的角度来看, 可分为 ：白 盒测试 和黑盒测试 6.1.1 黑盒测试 指的是把被测软件看作是一个黑盒子, 我们不去关心盒子里面的结构是什么 样子, 只关心软件的输入数据和输出结果。 黑盒测试方法是在程序接口上进行测试, 主要是为了发现以下错误: 是否有不正确或遗漏了的功能? 在接口上, 输入能否正确地接受? 能否输出正确的结果? 是否有数据结构错误或外部信息(例如数据文件)访问错误? 性能上是否能够满足要求? 是否有初始化或终止性错误? 用黑盒测试发现程序中的错误, 必须在所有可能的输入条件和输出条件中 确定测试数据, 来检查程序是否都能产生正确的输出。 但这是不可能的。 n 假设一个程序 P 有输入量 X 和 Y 及输出量 Z。在字长为 32 位的计算机上运 行。若 X、Y 取整数, 按黑盒方法进行穷举测试： n 可能采用的 测试数据组： 232232 264 n 如果测试一组数据 需要 1 毫秒, 一年工作 365 24 小时, 完成所有测试需 5 亿年。 黑盒测试的测试用例设计 等价划分法 边界值法 16 错误推测法 因果图法 6.1.2 白盒测试 白盒测试指的是把盒子盖打开, 去研究里面的源代码和程序结构。 白盒测试也称结构测试或逻辑驱动测试, 它是知道产品内部工作过程, 可通 过测试来检测产品内部动作是否按照规格说明书的规定正常进行, 按照程序内 部的结构测试程序, 检验程序中的每条通路是否都有能按预定要求正确工作, 而不顾它的功能。 使用被测单元内部如何工作的信息, 允许测试人员对程序内 部逻辑结构及有关信息来设计和选择测试用例, 对程序的逻辑路径进行测试。 基于一个应用代码的内部逻辑知识, 测试是基于覆盖全部代码、分支、路径、 条件。 白盒测试的主要方法： 逻辑驱动测试 基本路径测试 主要用于软件验证。 使用程序设计的控制结构导出测试用例。 逻辑驱动测试： 主要是测试覆盖率, 以程序内在逻辑结构为基础的测试。包括以下 6 种类型： 语句覆盖 判断覆盖 条件覆盖 判定-条件覆盖 条件组合覆盖 17 路径覆盖 白盒测试的主要目的 保证一个模块中的所有独立路径至少被执行一次； 对所有的逻辑值均需要测试真、假两个分支； 在上下边界及可操作范围内运行所有循环； 检查内部数据结构以确保其有效性 白盒测试的实施方案 在开发阶段 要保证产品的质量, 产品的生产过程应该遵循一定的行业标准。软件产品也 是同样, 没有标准可依自然谈不上质量的好坏。所有关心软件开发质量的组织、 单位, 都要定义或了解软件的质量标准、模型。其好处是保证公司实践的均匀 性, 产品的可维护性、可靠性以及可移植性等。 在测试阶段 与软件产品的开发过程一样, 测试过程也需要有一定的准则, 来指导、度量、 评价软件测试过程的质量。 定义测试准则 为控制测试的有效性以及完成程度, 必须定义准则和策略, 以判断何时结束 测试阶段。准则必须是客观的, 可量化的元素, 而不能是经验或感觉。 根据应用的准则和项目相关的约束, 项目领导可以定义使用的度量方法, 和 要达到的覆盖率。 度量测试的有效性、完整性 对每个测试的测试覆盖信息和累计信息, 用图形方式显示覆盖比率, 并根 据测试运行情况实时更新, 随时显示新的测试所反映的测试覆盖情况。 允许所有的测试运行依据其有效性进行管理, 用户可以减少不适用于非回 归测试的测试的过程。 概念： 1.语句覆盖：语句覆盖就是设计若干个测试用例, 运行被测试程序, 使得 18 每一条可执行语句至少执行一次； 2.判定覆盖（也称为分支覆盖）：设计若干个测试用例, 运行所测程序, 使 程序中每个判断的取真分支和取假分支至少执行一次； 3.条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个判断的 每个条件的每个可能取值至少执行一次； 4.判定-条件覆盖：设计足够多的测试用例, 运行所测程序, 使程序中每个 判断的每个条件的所有可能取值至少执行一次, 并且每个可能的判断结果也至 少执行一次, 换句话说, 即是要求各个判断的所有可能的条件取值组合至少执 行一次； 5.条件组合测试：设计足够多的测试用例, 运行所测程序, 使程序中每个判 断的所有可能的条件取值组合至少执行一次； 6.路径测试：设计足够多的测试用例, 运行所测程序, 要覆盖程序中所有可 能的路径。 6.1.3 静态测试 是指不实际运行被测软件, 而只是静态的检查程序代码、界面或文档中可能 存在的错误的过程。 其中包括代码测试、界面测试和文档测试 3 个方面。对于代码测试, 主要测 试代码是否符合相应的标准和规范。对于界面测试, 主要测试软件的实际界面 与需求中的说明是否相符。对于文档测试, 主要测试用户手册和需求说明是否 符合用户的实际要求。 6.1.4 动态测试 是指实际运行被测程序, 输入相应的测试数据, 检查实际输出结果和预期结 19 果是否相符的过程。所以, 我们判断一个测试属于动态还是静态测试 , 唯一的 标准就是看是否运行程序。 7 软件测试的过程 1,测试计划 首先,根据用户需求报告中关于功能要求和性能指标的规格说明书,定义相应 的测试需求报告,即制订的最高标准,以后所有的测试都将围绕着测试需求来进 行,符合测试需求的应用程序即是合格的,反之即是不合格的,同时,还要适当选 择测试内容,合理安排测试人员、测试时间及测试资源等。 2,测试设计 将测试计划阶段制订的测试需求分解、细化为若干个可执行的测试过程,并 为每个测试过程选择适当的测试用例,测试用例选择的好坏将直接影响到测试结 果的有效性,。 3,测试开发 建立可重复使用的自动测试过程。 4,测试执行 执行测试开发阶段建立的自动测试过程,并对所发现的缺陷进行跟踪管理。 测试执行一般由、组合测试、集成测试、系统联调及回归测试等步骤组成,测试 人员应本着科学负责的态度,一步一个脚印地进行测试。 5,测试评估 第一，结合量化的测试覆盖域及缺陷跟踪报告,对于应用软件的质量和开发 团队的工作进度及工作效率进行综合评价。 在进行测试前,首先必须理解业务和需求。需求和业务理解了,才知道客户想 要系统实现什么。然后按照需求来进行测试,不满足需求要求的都可以认为是 BUG。虽然在实际工作中,拿到一份完整详细的需求是很不容易的,但要做好一个 软件测试,前提就是要对需求比较熟悉,各个业务细节都很了解,甚至做到比开发 20 人员还要了解。除此之外,对于现在很多的信息处理相关的系统,还需要对整个 业务 中数据库的操作比较清楚。比如哪个业务需要用到哪些表,做怎么样的操作。 了解了这个就可以不单单从程序前台来看程序,看到数据库的过程,更有利于你 找到隐藏的 BUG。这些是从前台看不出来的,但实际可能会导致程序出现问题。 第二,了解程序的框架结构。比如很多 B/S 结构的系统中,前台是如何和后台 通信的,之间是什么协议,什么格式,后台是如何处理这些数据的。再比如 C/S 结 构的系统,服务器端和客户端之间是如何通信的,中间的数据包是什么格式,哪些 功能由服务器端实现,哪些功能由客户端实现等等。了解这些有助于你更好的去 测试程序以及定位程序错误。 第三,和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发