《软件测试培训》PPT课件 (2).ppt

软件测试培训 l 测试的基本理论及方法 l 自动化性能和压力测试 测试的基本理论及方法 l对软件测试的误解 l如何理解软件测试 l软件测试的定义 l软件测试的对象 l软件测试分类和比较 l软件测试的目的 l软件测试组织 l软件测试规范 l软件测试的内容和技术 lWEB应用测试 对软件测试的误解 l如果发布出去的软件有质量问题,那是软件 测试人员的错. l软件测试技术要求不高,至少比编程容易多 了. l软件测试随便找一个能力差的人就能做. l有时间就多测试一些,来不及就少测试一些. l软件测试是测试人员的事,与开发人员无关. l设计-实现-测试,软件测试是开发后期的一个 阶段 如何理解软件测试 l软件测试是一种有效的提高软件质量的手段,但即使在投 入上有所保证,测试也不能百分为百发现所有质量隐患.况 且软件质量并不仅仅是测试出来的. l很多人认为软件测试就是运行一下软件,看看结果对不对. 但实际上,如何在有限的投入下,提高软件测试的效率和产 出是一件很见功底的事.好的测试人员不仅要掌握各种测 试技术,还要具备丰富的编程经验和对BUG的敏感.测试的 复杂之处,除了测试技术问题之外,还有测试管理问题. l测试不是可有可无,随心所欲的.规范化的软件开发需要对 软件测试早做计划,分配必要的时间,人力和财力等资源,并 将其作为项目管理的一个部分加以控制和协调. l开发和测试是软件项目相辅相成的两个过程,人员间的交 流,协作和配合是提高整体效率的重要因素. l软件产品开发完毕,再进行测试的观念是有 悖于生命周期理论的.软件产品质量问题越 晚发现,修复的代价越大. 需求设计编程内部测试外部测试发布 修正BUG的代价 l一些常识和经验之谈 l测试能提高软件的质量，但是提高质量不能依赖测 试。 l测试只能证明缺陷存在，不能证明缺陷不存在。“ 彻底地测试”难以成为现实，要考虑时间、费用等限 制，不允许无休止地测试。我们应当祈祷：软件的缺 陷在产品被淘汰之前一直没有机会发作。 l测试的主要困难是不知道如何进行有效地测试，也 不知道什么时候可以放心地结束测试。 l每个开发人员应当测试自己的程序（份内之事）， 但是不能作为该程序已经通过测试的依据（所以项目 需要独立测试人员）。 l80-20原则：80的缺陷聚集在20的模块中，经 常出错的模块改错后还会经常出错 l测试应当循序渐进，不要企图一次性干完，注意“ 欲速则不达”。 软件测试的定义 l软件测试是为了发现错误而执行程序的过 程 l软件测试是根据软件开发各阶段的规格说 明和程序的内部结构而精心设计一批测试 用例(即输入数据及其预期的输出结果),并利 用这些测试用例去运行程序,以发现程序错 误的过程. l软件测试不等于程序测试.软件测试贯穿于 软件定义和开发的整个期间.需求分析,概要 设计,详细设计,以及程序编码等各个阶段所 得到的文档,包括需求规格说明,概要设计规 格说明,详细设计规格说明以及源程序,都是 软件测试的对象. 软件测试的对象 软件生存各个阶段间的确认和验证 l 软件配置：包括软件需求规格说明、软件 设计规格说明、源代码 等； l 测试配置：包括测试计划、测试用例、测 试驱动程序等。实际上，在整个软件工程过程 中，测试配置只是软件配置的一个子集。 l 测试工具：为提高软件测试效率，可使用 测试工具支持测试工具。例如：测试数据自动 生成程序、测试结果分析程序等。 测试的目的 l测试是程序的执行过程,目的在于发现错误; l一个好的测试用例在于发现至今未发现的 错误; l一个成功的测试是发现了至今的错误的测 试. 测试的种类 名称说明 黑盒测试基于软件需求，而不是基于软件内部设计和程序实现的测试方式。 白盒测试基于软件内部设计和程序实现的测试方式。 单元测试主要测试软 件模块的源代码。一般由开发人员而非独立测试人员 来执行，因为测试 者需要懂得该单元的设计与程序实现，测试者 可能需要编写额外的测试驱动 程序。 集成测试将一些“构件”集成一起时，测试它们能否正常运行。这里“构件”可 以是程序模块、客户机服务器程序等等。 功能测试测试软 件的功能是否符合功能性需求，通常采用黑盒测试方式。一 般由独立测试人员执行。 系统测试测试软 件系统是否符合所有需求，包括功能性需求与非功能性需求 。一般由独立测试人员执行，通常采用黑盒测试方式。 回归测试指错误被修正后或软件功能、环境发生变化后进行的重新测试。 回归测试 的困难在于不好确定哪些内容应当被重新测试。 验收测试由客户或最终用户执行，测试软 件系统是否符合需求规格说明书 。 名称说明 负载测试测试软 件系统的最大负载，超出此负载软 件可能会失常。 压力测试概念上与负载测试 相似，叫法不同。 性能测试测试软 件在各种状况下的性能，如在正常或最大负载下的 状况。 易用性测试测试软 件是否易用，主观性比较强。一般要根据很多用户 的测试反馈信息，才能评价易用性。 安装与反安装测 试 测试软 件在“全部、部分、升级”等状况下的安装/反安装过 程。 恢复测试测试该 系统从故障中恢复过来的能力。 安全性测试测试该 系统防止非法侵入的能力。 兼容性测试测试该 系统与其它软件硬件兼容的能力。 比较测试通过与同类产品比较，考察该系统的优点、缺点。 Alpha 测试一种先期的用户测试 ，此时系统刚刚 开发完成。 Beta测试一种后期的用户测试 ，此时系统已经通过内部测试，大部 分错误已经改正，即将正式发行。 测试的分类与比较 l测试方式 l白盒测试：关心软件内部设计和程序实现，主要测试依据是设计 文档 l黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是 需求文档 l 测试阶段 l单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由 内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。 l单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主 要测试单元是否符合“设计”。 l集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般 由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“ 需求”。 l系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试 ，主要测试系统是否符合“需求规格说明书”。 l验收测试与系统测试非常相似，主要区别是测试人员不同，验收 测试由用户执行。 l开发与测试的 V 型关系 l如果软件开发过程采用严格的瀑布模型，那 么开发与测试有“V”型的对应关系 。 需求开发 高层设计 详细设计 编程 单元测试 集成测试 系统测试 验收测试 l测试内容 l接口与路径测试。 l功能测试、健壮性测试、性能测试、用户界 面测试、安全性测试、压力测试、可靠性测试 、安装/反安装测试 测试阶 段 主要依据 测试人员、测试方式 主要测试内容 单单元测试测试系统设计统设计 文档 由开发发小组执组执 行白盒测测 试试 接口测试测试 、路径测试测试 集成测试测试系统设计统设计 文档 需求文档 由开发发小组执组执 行白盒测测 试试和黑盒测试测试 接口测试测试 、路径测试测试 功能测试测试 、性能测试测试 系统测试统测试需求文档由独立测试测试 小组执组执 行黑盒 测试测试 功能测试测试 、健壮性测试测试 、 性能测试测试 、用户户界面测试测试 、安全性测试测试 、压压力测试测试 、可靠性测试测试 、安装/反安 装测试测试 验验收测试测试需求文档由用户执户执 行黑盒测试测试 黑盒测试与白盒测试的比较 测试方式特征依据测试人员测试驱动 程序 黑盒测试只关心软件的外部表 现，不关心内部设计 与实现。 软件需求任何人（包括 开发人员、独 立测试人员和 用户） 一般无需编写 额外的测试驱 动程序 白盒测试关注软件的内部设计 与实现，要跟踪源代 码的运行。 设计文档由开发人员兼 任测试人员的 角色 需要编写额外 的测试驱动 程 序 l问题1：有了“黑盒”测试为什么还要“白盒”测 试？ l黑盒测试只能观察软件的外部表现，即使软件的输入输出都 是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的 运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测 试才能发现真正的原因。 l白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题 。在这方面，黑盒测试存在严重的不足。 l问题2：由于单元测试要写测试驱动程序，非常麻 烦，能否等到整个系统全部开发完后，再集中精力 进行一次性地单元测试呢？ l如果这样做，在开发过程中，缺陷会越积越多并且分布得更 广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是 无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事 而省略单元测试或者“偷工减料”，是“得不偿失”的做法。 l问题3：如果每个单元都通过了测试，把它们集成 一起难道会有什么不妥吗？集成测试是否多此一举 ？ l要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单 元测试中无法发现的问题。例如：数据通过不同的接口时可能出错； 几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接 受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必 要的，不是多此一举。 l问题4：在集成测试的时候，已经对一些子系统进行了 功能测试、性能测试等等，那么在系统测试时能否跳过 相同内容的测试? l不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系 统。再者，单元测试和集成测试通常由开发小组执行。根据测试心理学的分 析，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过 测试的依据。 l问题5：既然系统测试与验收测试的内容几乎是相同的 ，为什么还要验收测试？ l首先是“信任”问题。对于合同项目而言，如果测试小组是开发方 的人员，客户怎么能够轻易相信“别人”呢? 所以当项目进行系统测试之后 ，客户再进行验收测试是情理之中的事。否则，那是客户失职。 l不论是合同项目还是非合同项目，软件的最终用户各色各样（如受 教育程度不同、使用习惯不同等等）。测试小组至多能够模仿小部分用户的 行为，但并不具有普遍的代表性。 l问题6：能否将系统测试和验收测试“合二为一”？ l系统测试不是一会儿就能做完的，比较长时间的用户测试很难组织 。用户还有自己的事情要做，他们为什么要为别人测试呢？即使用户愿意做 系统测试，他们消耗的时间、花费的金钱大多比测试小组的高。 l系统测试时会找出相当多的软件缺陷，软件需要反反复复地改错。 如果让用户发现“内幕”，一是丢脸，二是会吓跑买主。所以还是关起门来 ，先让测试小组做完系统测试的好。 l回归测试 l回归测试是指对某些已经被测试过的内容 进行重新测试。每当软件增加了新的功能 ，或者软件中的缺陷被修正，这些变更都 有可能影响软件原有的功能和结构。为了 防止软件的变更产生无法预料的副作用， 不仅要对新内容进行测试，还要对某些老 内容进行回归测试。 测试人员的组织 l了解开发人员的测试心理 l测试的目的是找出尽可能多的缺陷。所以测试是“破坏性”的，而 开发却是“建设性”的。开发人员总是喜欢欣赏程序的成功之处，而不 愿看到失败之处。让开发者去做“蓄意破坏”的测试，就象杀自己的孩 子一样难以接受。 l开发者对自己的程序印象深刻，并总以为是正确的（自信是应该的 ）。倘若在设计时就存在理解错误，或因不良的编程习惯而流下了隐患 ，他本人很难发现这类错误. l开发者对自己的程序的功能、接口十分熟悉，他自己几乎不可能因 为使用不当而引发错误，这与大众用户的情况不太相似，所以测试自己 的程序不具备典型性。 l结论：开发人员应当测试自己的程序，这是他分内的工作。但是开 发人员在测试自己的程序时，很难做到客观、公正，所以自我测试不具 有说服力。 l如何组织测试人员：应当视企业的人力资源而定 l条件特别好的公司，可以为每一个开发人员分配一名独立的测 试人员。这样的测试人员职业化程度很高，可以完成单元测试、集 成测试和系统测试工作，能够实现开发与测试同步进行。 l条件比较好的公司，可以设置一个独立的测试小组，该测试小 组轮流参加各个项目的系统测试。而单元测试、集成测试工作由项 目的开发小组承担。 l条件一般的公司，养不起独立的测试小组。单元测试、集成测 试工作由项目开发小组承担。当项目进展到系统测试阶段，可以从 项目外抽调一些人员，加上开发人员，临时组织系统测试小组。 l条件比较差的公司，也许只有一个项目和为数不多的一些开发 人员。那么就让开发人员一直兼任测试人员的角色，相互测试对方 的程序。如果人员实在太少了，只好让开发者测试自己的程序，有 测试总比没有测试好吧！ l避免开发人员与测试人员产生矛盾 l开发人员不能很好地测试自己的程序是因为做不到“无情”。但如果测试人员真的 做到了“无情”却会引起开发人员的愤怒，遭人白眼。由于开发与测试存在“对立” 关系，开发人员与测试人员很容易产生矛盾，这对项目而言是一种伤害。 l开发人员的注意事项： （1）不要敌视测试人员。要理解测试的目的就是发现缺陷，是测试人员的工作职 责。不要以为测试人员吃饱了没事干，存心找茬。 （2）不要轻视测试人员，别说人家技术水平差，不配搞开发只好搞测试。 l测试人员的注意事项： （1）发现缺陷时不要嘲笑开发人员，别说他的程序真臭、到处是Bug。 （2）在开发人员压力太大时或心情不好时不要火上浇油，发现缺陷时别大声嚷嚷 。 l尽量不要相互讽刺对方，例如： lA对B说：你唯一的特点就是无能。 lB对A说：你唯一的特点就是粗鲁。 l还要注意的是，如果测试人员与开发人员的关系非常好，可能会导致在测试的 时候“手下留情”，这对项目也是一种伤害。 企业的测试策略 l 理念： l企业的主要目的是获取利润，降低测试成本也是盈利的一种方式。 l用较低的代价实现有效的测试，不应为了追求完美的测试而不失一切代 价。 l 如何合理地减少测试工作量 l减少冗余的测试 l白盒测试与黑盒测试的方式虽然不同，但往往有“异曲同工”之妙 。在很多地方，白盒测试与黑盒测试会产生一模一样的效果（或者能推理出来 ），这样的测试是冗余的。 l在集成测试、系统测试阶段，可能要执行多次“回归测试”。每一 次“回归测试”都会存在不少的冗余，应当设法剔除不必要的重复测试工作。 l减少无价值的测试 l无价值的测试通常是由于不懂得测试技术引起的。例如功能测试， 在等价区间之中，本来只要测试一个典型的输入就行了，如果有人在此区间测 试了100次，那么其中99次就是无价值的。 l如何“偷工减料” l有一些“短、平、快”的项目，经费本来就少，用户对质量要求也 马马虎虎。为了能多挣一点钱，开发方不得不采用“偷工减料”的方式来降低 测试代价。偷工减料的途径无非就是减少测试的内容和频度。但不能砍得太狠 ，否则软件拿不出手。基本方法是找出软件中需要优先测试的部分，其它次要 部分可以忽略或将来再测试。 l“偷工减料”方法的测试优先级： l哪些功能是软件的特色？ l哪些功能是用户最常用的？ l如果系统可以分块卖的话，哪些功能块在销售时最昂贵？ l哪些功能出错将导致用户不满或索赔？ l哪些程序是最复杂、最容易出错的？ l哪些程序是相对独立，应当提前测试的？ l哪些程序最容易扩散错误？ l哪些程序是全系统的性能瓶颈所在？ l哪些程序是开发者最没有信心的？ l l测试何时结束？ l一、基于测试用例的规则 l（1）先构造测试用例（并请有关人员进行评审）。 l（2）在测试过程中，当测试用例的不通过率达到20时，则拒绝继续测试，待开 发人员修正软件后再进行测试。 l（3）当功能性测试用例通过率达到100，非功能性测试用例通过率达到90时， 允许正常结束测试。 l该规则的优点是适用于所有的测试阶段，缺点是太依赖于测试用例。如果测试 用例非常糟糕，那么该规则就失效了。 l二、基于“测试期缺陷密度”的规则 l把测试一个CPU小时发现的缺陷数称为“测试期缺陷密度”。绘制“测试时间缺陷数” 的关系图，如果在相邻n个CPU小时内“测试期缺陷密度”全部低于某个值m时，则允 许正常结束测试。例如n大于10，m小于等于1。该规则比较适用于系统测试阶段。 l三、基于“运行期缺陷密度”的规则 l把软件运行一个CPU小时发现的缺陷数称为“运行期缺陷密度”。绘制“运行时间缺 陷数”的关系图，如果在相邻n个CPU小时内“运行期缺陷密度”全部低于某个值m时， 则允许正常结束测试。例如n大于100，m小于等于1。该规则比较适用于验收测试 阶段，即客户试运行软件期间。 l需求经常变更怎么办 l需求变更可能会让项目所有成员遭殃，如何“预防变更”以及“降低变更的代 价”是软件工程的经典问题。本节仅论述需求变更对测试的影响。 l需求变更将导致软件设计和实现的变更，也导致了测试变更。最让人难过的是 上一次测试有可能白做了，如果软件变更比较大的话。 l测试人员不要只是自认倒霉，应当主动作些应变： l（1）及时了解需求变更的详细情况，尽早调整测试计划，不要闷头按原计划测 试。 l（2）将软件中稳定的部分与易变的部分区别对待，前者先测试，后者后测试。 l（3）向领导反映需求变更对测试造成的影响，为自己争取余地。 l（4）设计一些比较灵活的测试用例，能适应某些变更（不过技术难度比较高） 。 l引申问题：如果在系统测试时，对照需求文档，发现软件多了功能或少了功能 ，该怎么办？ l如果发现软件少了功能，测试人员不可为了少干些活而隐瞒事实。如果发现软 件多了功能，测试人员不可认为这些功能反正是“锦上添花”，便自作主张地测试 了事。两种情况都要报告给项目经理，有可能导致一系列的变更。 测试规范 l测试流程 l第一步：制定测试计划。该计划被批准后转向第二步。 l第二步：设计测试用例。该用例被批准后转向第三步。 l第三步：如果满足“启动准则” ，那么执行测试。 l第四步：撰写测试报告。 l第五步：消除软件缺陷。如果满足“完成准则”，那么正常结束测试。 制定测试计划 设计测试用例 执行测试 写测试报告 消除软件缺陷 审批审批 回归测试 完成 测试 完成准则 启动准则 测试的信息流 l 测试信息流如下图所示： 软件测试的策略 l 在软件工程中，测试过程应该按4个步骤进行，即单 元测试、组装（集成）测试、确认测试和系统测试。下 图给出了软件测试经历的4个步骤。 测试规范 l测试启动准则 l同时满足以下条件，允许开始测试： l（1）测试计划已经制定并且通过了审批； l（2）测试用例已经设计并且通过了审批； l（3）被测试对象已经开发完毕并等待测试。 l 测试完成准则 l对于非严格系统可以采用“基于测试用例”的准则。同时满足以 下条件允许结束测试： l（1）功能性测试用例通过率达到100； l（2）非功能性测试用例通过率达到90时。 l对于严格系统，应当补充“基于测试期缺陷密度”的规则： l（3）相邻n个CPU小时内“测试期缺陷密度”全部低于 某个值m。例如n大于10，m小于等于1。 测试的文档 l测试计划：指明范围、方法、资源，以及相 应测试活动的时间进度安排表的文档。 l测试方案：指明为完成软件或软件集成特性 的测试而进行的设计测试方法的细节文档。 l测试用例：指明为完成一个测试项的测试输 入、预期结果、预期执行条件等因素的文档。 l测试规程：指明执行测试时测试活动序列的 文档。 l测试报告：指明执行测试结果的文档。 测试计划的参考模板 建立测试计划 l定义测试目标 l开发测试矩阵 l软件模型 l结构特性 l批量测试的阶段和用例 l为在线系统作概念上的测试脚本 l软件测试矩阵 l定义测试管理 l测试计划的一般性信息 l定义测试里程碑 l定义管理上的检查点 l书写测试计划 评审测试计划 l涉及评审的问题 l评审测试的开始时间是否会延期 l有没有抵触评审的角色 l一段时间内是否很难得到工作的检查信息。 l更换工具有可能导致他们反感评审工作 l评审结果可能会影响对个人的工作评价 l对于最终成品的检查 l项目的需求规格说明书 l软件返工/维护的文档 l升级后的技术文档 l被更改的源程序 l测试计划 l用户手册（包括在线帮助） 测试用例 测试用例的基本要素有：目的、前提条件、输入数据或动作、期望的响应。 建议测试方法 l测试方法 l测试用例的概念是简单的 l建立有效的测试用例是复杂的 l设计测试文件 l测试用例应当包含合法的和非法的输入 l每一个动作只进行一次关键操作 l输入测试数据 l分析结果 l尝试将测试文件违反程序的规则进行输入 l压力测试的测试工具 l以大信息量的数据进行输入 l这是一个昂贵的测试，应根据需要来选择 l在线系统需要做压力测试 测试报告 l目标 l表示出目前项目的实际状况 l明确什么是测试做的工作，什么是不作的工作。 l给出系统的操作性能的评价 l明确什么时候系统可以进行产品化的工作 l关注点 l测试报告只有真正需要的时候才有用，需要配合市场 和管理 l测试的信息是不充分的（对于评价一个项目来说） l测试状况并不能真实的反应个人的状况 测试期间数据的收集 l有关测试结果的积累数据 l测试任务，测试集合和测试事件的描述 l缺陷分析 l由于计划的问题，导致没有发现的缺陷的数据 l严重的缺陷 l缺陷类型 l为什么缺陷没有发现 l效果 测试报告 l报告目前的软件状态 l功能/测试矩阵 l功能测试的状态报告，侧重点分析 l关于功能的工作时间轴 l期望发现 VS 实际发现的缺陷比 l没有发现的缺陷和改正的缺陷的差距 l按照类型分类，没有改正的缺陷的平均值 l缺陷分类报告 l测试活动报告 软件系统的主要测试内容及技术 l接口与路径测试 l功能测试 l健壮性测试 l性能测试 l用户界面测试 l信息安全测试 l压力测试 l可靠性测试 l安装/反安装测试 l接口与路径测试 l数据一般通过接口输入和输出，所以接口测试是白盒测试的第一步。每 个接口可能有多个输入参数，每个参数有“典型值”、“边界值”、“异常 值”之分，所以输入的组合数可能并不少。根据接口的定义，可以推断某种 输入应当产生什么样的输出。输出包括函数的返回值和输出参数。如果实际 输出与期望的输出不一致，那么说明程序有错误。白盒方式的接口测试和黑 盒方式的功能测试，其方法十分相似。 l一个函数体内的语句可能只有十几条，但逻辑路径可能有成千上万条。 想遍历测试几乎是不可能的，不测试或者胡乱找几条路径测试却又不行。 l对于非严格系统而言，在分析路径方面化费很多精力是不值得的。我认 为在构造接口测试的同时已经建立了测试路径。因为每一种输入将产生唯一 的输出，输入与输出之间的路径也是唯一的。由于接口测试中的输入是有代 表性的，因此相应的路径也具有代表性，不用得着费煞苦心地去找测试路径 。 l路径测试的检查表 l数据类型、变量值、逻辑判断、循环、内存管理、文件I/O、错 误处理 l由于接口测试是枚举的，有可能漏掉某些状况，导致一些重要的路径没 有被测试。预防措施有： l观察是否有程序语句从来没有被执行过。如果发生在这种情况， 要么是程序有错误，存在无用的代码；要么是接口测试不充分，漏掉了一 些路径。 l要特别留意函数体内的错误处理程序块（如果存在的话），这是 最易被人疏忽的路径，隐患最多。 软件系统的主要测试内容及技术 l接口与路径测试用例的参考模板 软件系统的主要测试内容及技术 l功能测试 l功能测试的基本方法是构造一些合理输入（在需求范围之内），检 查输出是否与期望的相同。如果两者不一致，即表明功能有误。也有例 外的情况，如需求规格说明书中的某个功能写错了，而实际上软件 的功能却是正确的，这时要更改的是需求规格说明书。 l功能测试看起来比较简单，只要看得懂需求规格说明书，谁都 会做。难点在于如何构造有效的输入。由于输入空间通常是无限的，穷 举测试显然行不通。那么随便输入一些东西，碰运气行不行？ l功能测试有两种比较好的测试方法：等价划分法和边界值分析法。 l等价划分是指把输入空间划分为几个“等价区间”，在每个 “等价区间”中只需要测试一个典型值就可以了。等价划分法来源于 人们的直觉与经验，可令测试事半功倍。 l“缺陷遗漏在角落里，聚集在边界上”。边界值测试法是对 等价划分法的补充。如果A和B是输入空间的边界值，那么除了典型值 外还要用A和B作为测试用例。 l例如测试函数。凭直觉，等价区间应是（0, 1）和（1, + ）。可取典型值x=0.5以及x=2.0进行“等价划分”测试。再取 x=0以 及x=1进行“边界值”测试。 l功能测试用例的参考模板 l健壮性测试 l健壮性是指在异常情况下，软件还能正常运行的能 力。健壮性有两层含义：一是容错能力，二是恢复能 力。 l容错性测试通常构造一些不合理的输入来引诱软件 出错，例如： l（1）输入错误的数据类型。如“猴”年“马”月。 l（2）输入定义域之外的数值。如上海人常说的“十三 点” l粗暴一些方式俗称“大猩猩”测试法。除了不能拳 打脚踢嘴咬外，什么招术都可以使出来。例如在测试 客户机服务器模式的软件时，把网络线拔掉，造成 通信异常中断。 l恢复测试重点考察一下几项： l（1）系统能否重新运行； l（2）有无重要的数据丢失； l（3）是否毁坏了其它相关的软件硬件。 健壮性测试 l目标 l当在进行安装或组装操作过程中，文件丢失时或发生意外后系统 有能力重新进行操作 l如何使用 l程序的安装，运行方式，工具的使用和关键技术经过足够的评估 l系统开发完毕后，介绍一下发生失败后的处理过程 l例子 l人为的使一个系统在安装或者组装过程中产生错误 l什么时间去使用 l当操作的连续性是个重点的时候 l健壮性测试用例的参考模板 l性能测试 l性能测试即测试软件处理事务的速度，一是为了检验性能是否符合 需求，二是为了得到某些性能数据供人们参考（例如用于宣传）。 l有时人们关心测试的“绝对值”，如数据送输速率是每秒多少比特 。有时人们关心测试的“相对值”，如某个软件比另一个软件快多少倍 。 l在获取测试的“绝对值”时，我们要充分考虑并记录运行环境对测 试的影响。例如网络环境、计算机主频，总线结构和外部设备都可能影 响软件的运行速度。 l性能测试的一些注意事项： l不要试图让人拿着钟表去测时间，应当编写一段程序用于计 算时间以及相关数据。 l应当测试软件在标准配置和最低配置下的性能。 l为了排除干扰，应当关闭那些消耗内存、占用CPU的其它应 用软件（如杀毒软件）。 l不同的输入情况会得到不同的性能数据，应当分档记录。例 如传输文件的容量从100K到1M可以分成若干等级。 l由于环境的波动，同一种输入情况在不同的时间可能得到不 同的性能数据，可以取其平均值。 性能测试技巧 l目标 l确定系统达到了希望达到的性能水平 l如何使用 l使用软件和硬件的监视器 l使用模拟的监控模型，对关心的性能指标进行监控 l创建一个小程序 l例子 l计算通信的时间 l单位时间处理的信息量 l性能测试用例的参考模板 l 用户界面测试 l绝大多数软件拥有图形用户界面。图形用户界面的测试重点是正确 性、易用性和视觉效果。在评价易用性和视觉效果时，主观性非常强， 应当考虑多个人的观点。 l用户界面测试用例的参考模板： l信息安全测试 l信息安全性（security）是指防止系统被非法入侵的能力，既属于 技术问题又属于管理问题。 l信息安全性测试有如下步骤： l（1）为非法入侵设立目标，例如“盗窃某个文件”或“更改数 据库记录”等。 l（2）邀请（或悬赏）一些人扮演黑客，让他们想尽办法入 侵系统，实现“目标”。 l（3）如果有人成功了，请他详述入侵的过程。别忘了给予 奖励。 l信息安全性测试用例的参考模板 安全性测试 l目标 l安全性的缺陷很难被发现。 l大多数的情况下组织能够防止一般性的破坏者。 l如何使用 l对安全性的需求进行评审 l分析与安全性有关的处理流程 l转包给专业的人员 l例子 l定义了被保护的资源，权限进行了控制，日志文件和审查追踪是 可用的。 l什么时间使用 l当被保护的资源对于组织具有重要的价值的时候 l压力测试 l压力测试也叫负荷测试，即获取系统能正常运行的极限状态。了解 “极限”是很有价值的，例如潜艇下潜极限深度。 l压力测试的主要任务是：构造正确的输入，使劲折腾系统却让它刚 好不瘫痪。 l压力测试的一个变种是敏感测试。在某种情况下，微小的输入变动 会导致系统的表现（如性能）发生急剧的变化。敏感测试目的是发现什 么样的输入可能会引发不稳定现象。 l压力测试用例的参考模板 压力测试 l目标 l模拟出实际用户环境 l怎么用 l产生测试数据 l测试组模拟用户处理被创建的数据 l例子 l确定是否分配了足够的磁盘空间 l通讯的容量是否足够 l测试系统过载的情况 l什么时间使用 l当关于容量的信息不确定的时候 l可靠性测试 l可靠性是指在一定的环境下、在给定的时间内、系统不发生故障的 概率。由于软件不像硬件那样可以“加速老化”，按此定义，软件可靠 性测试可能会花费很长时间。 l比较实用的办法是，让用户使用该系统，记录每一次发生故障的时 刻。计算出相邻故障的时间间隔，注意要去掉非工作时间。这样我们可 以方便地统计出不发生故障的“最小时间间隔”、“最大时间间隔”和 “平均时间间隔”。其中“平均时间间隔”会让人们大体了解到系统“ 可靠”的程度。 l安装 / 反安装测试 l安装 / 反安装测试的目的：避免“大风浪都挺过来了，却在阴沟里 翻了船” l目前市面上有非常流行的、专门制作安装/反安装程序的一些工具， 如Install Shelled。制作安装/反安装程序不再是件难事，关键是不要 麻痹大意。主要测试工作： l（1）至少在标准配置和最低配置两种环境下测试； l（2）如果有安装界面，应当尝试各种选项，如选择“全部 ”、“部分”、“升级”等。 WEB应用的测试 l一、功能测试 l 1、链接测试 l 链接是Web应用系统的一个主要特征，它是在页面之间切换和指 导用户去一些不知道地址的页面的主要手段。链接测试可分为三个方 面。首先，测试所有链接是否按指示的那样确实链接到了该链接的页 面；其次，测试所链接的页面是否存在；最后，保证Web应用系统上 没有孤立的页面，所谓孤立页面是指没有链接指向该页面，只有知道 正确的URL地址才能访问。 l 链接测试可以自动进行，现在已经有许多工具可以采用。链接测 试必须在集成测试阶段完成，也就是说，在整个Web应用系统的所有 页面开发完成之后进行链接测试。 l 2、表单测试 l 当用户给Web应用系统管理员提交信息时，就需要使用表单操作 ，例如用户注册、登陆、信息提交等。在这种情况下，我们必须测试 提交操作的完整性，以校验提交给服务器的信息的正确性。例如：用 户填写的出生日期与职业是否恰当，填写的所属省份与所在城市是否 匹配等。如果使用了默认值，还要检验默认值的正确性。如果表单只 能接受指定的某些值，则也要进行测试。例如：只能接受某些字符， 测试时可以跳过这些字符，看系统是否会报错。 l3、Cookies测试 l Cookies通常用来存储用户信息和用户在某应用系统的操作，当 一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送 关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上 ，这可用来创建动态和自定义页面或者存储登陆等信息。 l 如果Web应用系统使用了Cookies，就必须检查Cookies是否能正 常工作。测试的内容可包括Cookies是否起作用，是否按预定的时间 进行保存，刷新对Cookies有什么影响等。 l 4、设计语言测试 l Web设计语言版本的差异可以引起客户端或服务器端严重的问题 ，例如使用哪种版本的HTML等。当在分布式环境中开发时，开发人 员都不在一起，这个问题就显得尤为重要。除了HTML的版本问题外 ，不同的脚本语言，例如Java、javascript、 ActiveX、VBScript或 Perl等也要进行验证。 l 5、数据库测试 l 在Web应用技术中，数据库起着重要的作用，数据库为Web应用 系统的管理、运行、查询和实现用户对数据存储的请求等提供空间。 在Web应用中，最常用的数据库类型是关系型数据库，可以使用SQL 对信息进行处理。 l在使用了数据库的Web应用系统中，一般情况下，可能发生两种错误 ，分别是数据一致性错误和输出错误。数据一致性错误主要是由于用 户提交的表单信息不正确而造成的，而输出错误主要是由于网络速度 或程序设计问题等引起的，针对这两种情况，可分别进行测试。 二、性能测试 1、连接速度测试 用户连接到Web应用系统的速度根据上网方式的变化而变 化，他们或许是电话拨号，或是宽带上网。当下载一个程序时 ，用户可以等较长的时间，但如果仅仅访问一个页面就不会这 样。如果Web系统响应时间太长（例如超过5秒钟），用户就 会因没有耐心等待而离开。 另外，有些页面有超时的限制，如果响应速度太慢，用户 可能还没来得及浏览内容，就需要重新登陆了。而且，连接速 度太慢，还可能引起数据丢失，使用户得不到真实的页面。 2、负载测试 负载测试是为了测量Web系统在某一负载级别上的性能， 以保证Web系统在需求范围内能正常工作。负载级别可以是某 个时刻同时访问Web系统的用户数量，也可以是在线数据处理 的数量。例如：Web应用系统能允许多少个用户同时在线？如 果超过了这个数量，会出现什么现象？Web应用系统能否处理 大量用户对同一个页面的请求？ 3、压力测试 负载测试应该安排在Web系统发布以后，在实际 的网络环境中进行测试。因为一个企业内部员工，特 别是项目组人员总是有限的，而一个Web系统能同时 处理的请求数量将远远超出这个限度，所以，只有放 在Internet上，接受负载测试，其结果才是正确可信的 。 进行压力测试是指实际破坏一个Web应用系统， 测试系统的反映。压力测试是测试系统的限制和故障 恢复能力，也就是测试Web应用系统会不会崩溃，在 什么情况下会崩溃。黑客常常提供错误的数据负载， 直到Web应用系统崩溃，接着当系统重新启动时获得 存取权。 压力测试的区域包括表单、登陆和其他信息传输 页面等。 l三、可用性测试 l 1、导航测试 l 导航描述了用户在一个页面内操作的方式，在不同的 用户接口控制之间，例如按钮、对话框、列表和窗口等； 或在不同的连接页面之间。通过考虑下列问题，可以决定 一个Web应用系统是否易于导航：导航是否直观？Web系 统的主要部分是否可通过主页存取？Web系统是否需要站 点地图、搜索引擎或其他的导航帮助？ l 在一个页面上放太多的信息往往起到与预期相反的效 果。Web应用系统的用户趋向于目的驱动，很快地扫描一 个Web应用系统，看是否有满足自己需要的信息，如果没 有，就会很快地离开。很少有用户愿意花时间去熟悉Web 应用系统的结构，因此，Web应用系统导航帮助要尽可能 地准确。 l 导航的另一个重要方面是Web应用系统的页面结构、 导航、菜单、连接的风格是否一致。确保用户凭直觉就知 道Web应用系统里面是否还有内容，内容在什么地方。 l Web应用系统的层次一旦决定，就要着手测试用户导 航功能，让最终用户参与这种测试，效果将更加明显。 2、图形测试 在Web应用系统中，适当的图片和动画既能起到广告宣传的作用 ，又能起到美化页面的功能。一个Web应用系统的图形可以包括图片 、动画、边框、颜色、字体、背景、按钮等。图形测试的内容有： （1）要确保图形有明确的用途，图片或动画不要胡乱地堆在一起 ，以免浪费传输时间。Web应用系统的图片尺寸要尽量地小，并且要 能清楚地说明某件事情，一般都链接到某个具体的页面。 （2）验证所有页面字体的风格是否一致。 （3）背景颜色应该与字体颜色和前景颜色相搭配。 （4）图片的大小和质量也是一个很重要的因素，一般采用JPG 或GIF压缩。 3、内容测试 内容测试用来检验Web应用系统提供信息的正确性、准确性和相 关性。 信息的正确性是指信息是可靠的还是误传的。例如，在商品价格 列表中，错误的价格可能引起财政问题甚至导致法律纠纷；信息的准 确性是指是否有语法或拼写错误。这种测试通常使用一些文字处理软 件来进行，例如使用Microsoft Word的“拼音与语法检查“功能；信息 的相关性是指是否在当前页面可以找到与当前浏览信息相关的信息列 表或入口，也就是一般Web站点中的所谓“相关文章列表“。 4、整体界面测试 整体界面是指整个Web应用系统的页面结构设计，是给用户的一个整体感。例如： 当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？ 整个Web应用系统的设计风格是否一致？ 对整体界面的测试过程，其实是一个对最终用户进行调查的过程。一般Web应用系统采 取在主页上做一个调查问卷的形式，来得到最终用户的反馈信息。 对所有的可用性测试来说，都需要有外部人员（与Web应用系统开发没有联系或联 系很少的人员）的参与，最好是最终用户的参与。 四、客户端兼容性测试 1、平台测试 市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、 Linux等。Web应用系统的最终用户究竟使用哪一种操作系统，取决于用户系统的配置 。这样，就可能会发生兼容性问题，同一个应用可能在某些操作系统下能正常运行，但 在另外的操作系统下可能会运行失败。 因此，在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试 2、浏览器测试 浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、javascript 、 ActiveX、 plug-ins或不同的HTML规格有不同的支持。例如，ActiveX是Microsoft的 产品，是为Internet Explorer而设计的，javascript是Netscape的产品，Java是Sun的产 品等等。另外，框架和层次结构风格在不同的浏览器中也有不同的显示，甚至根本不显 示。不同的浏览器对安全性和Java的设置也不一样。 测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂 商、不同版本的浏览器对某些构件和设置的适应性。 五、安全性测试 Web应用系统的安全性测试区域主要有： （1）现在的Web应用系统基本采用先注册，后登陆的方式。因 此，必须测试有效和无效的用户名和密码，要注意到是否大小写敏感 ，可以试多少次的限制，是否可以不登陆而直接浏览某个页面等。 （2）Web应用系统是否有超时的限制，也就是说，用户登陆后 在一定时间内（例如15分钟）没有点击任何页面，是否需要重新登陆 才能正常使用。 （3）为了保证Web应用系统的安全性，日志文件是至关重要的 。需要测试相关信息是否写进了日志文件、是否可追踪。 （4）当使用了安全套接字时，还要测试加密是否正确，检查信 息的完整性。 （5）服务器端的脚本常常构成安全漏洞，这些漏洞又常常被黑 客利用。所以，还要测试没有经过授权，就不能在服务器端放置和编 辑脚本的问题。 软件自动化测试 l1.什么是“软件自动化测试”？ l2.软件自动化测试的优点？ l3.自动化测试工具概述； l4.性能测试工具“LoadRunner” 的介绍； 什么是软件测试的自动化？ 定义通过自动化测试工具或其他手段，按照我 们预定的计划进行自动测试的活动。 目的减轻手工测试的劳动量，从而达到节约资 源（包括人工、物品）提高软件质量的目的。 自动化测试的基本原理 在测试者运行应用程序的同时，把他所 有动作，包括键盘操作、鼠标点击等捕获 下来，生成一个脚本文件，这个脚本可以 被“回放”，也就是按照上一次的所有动作重 复执行一遍，实现自动运行和测试。 软件测试的自动化优点 自动录制的测试脚本，可轻松实现回归测试； 减少测试时间，缩短整个软件开发生命周期； 替代手工测试不易达到的测试点（比如：300并发用户的 压力测试） 更好的利用空闲时间（比如晚上或周末机器时）； 增加软件信任度 自动化测试工具 lMI公司 Winrunner（功能测试） Loadrunner（性能负载测试） Testdirector（测试流程管理） lIBM公司 Rational lCompuware公司 QACenter,包括QARun,QAload,QADirector等模块 l其他测试工具 微软WAS(WEB服务器负载测试)，ACT（微软的Visual Studio 和 Visual Studio.NET带的一套进行程序测试的工具 ） Rational Test工具用途列表 软软件（执执行文件名 称） 用途 Rational Administrator 主要用于创创建新的PROJECT，包括需求(RequestPro)、测测 试试(Test Manager)、及缺陷跟踪(Clear Quest)的数据 库创库创 建并建立关联联 ClearQuest变变更管理及缺陷跟踪 ClearQuest Maintenance Tool ClearQuest维护维护 工具，主要用于创创建、修改、删删除 ClearQuest的Connection ClearQuest Designer ClearQuest维护维护 工具,主要用于维护维护 某一指定的 Connect/Schema的用户户、访问权访问权 限及其他属性定义义（ 如缺陷等级级）等维护维护 TestManager测试计测试计 划制定及执执行工具 License Key Administrator Rational注册管理器 软软件（执执行文件 名称） 用途 PureCoverage 白盒测试测试 工具，记录记录 代码码覆盖率。不支持C+ Builder/Delphi Purify白盒测试测试 工具，用于内存泄漏检查检查 Quantify白盒测试测试 工具，用于性能瓶颈颈分析 Purify Plus For Unix 包括以上三个工具，不过过是For Unix RequisitePro需求分析工具 Robot 自动测试动测试 工具，类类似WINRUNNDER，加上VT可以做并 发测试发测试 SoDA for Word 报报表生成工具，需要VBA测试测试 。一般不直接运行，运 行后SoDA在word中增加了菜单单，可以进进行模板设设 计计。 TestFactory可靠性测试测试 ，非常耗时时。 自动化测试工具的分类 白盒测试工具：对代码的测试 黑盒测试工具：功能和性能上的测试 测试管理工具：对测试计划、测试用例、测试实施进行 管理 其他测试工具：专门针对于数据库的测试等工具 什么是性能测试？ l模拟实际用户负载来测试系统，包括：反应速度、最 大用户数、系统最优配置、软硬件性能等 虚拟用户：发起各 种各样的负载组合 GUI 代理：衡量 端到端的性能 主机：负责录制、回放、 监视和分析运行结果 WebAppDB 介绍性能测试工具 -LoadRunner7.5定义 o是一种预测系统行为和负载的性能测试工具。 o通过以模拟上千万用户实施并发负载及实时性能 监测的方式来确认和查找问题。 LoadRunner系列工具 lCreate Virtual Users LoadRunder的Virtual User Gene