测试Web应用程序.ppt

《测试Web应用程序.ppt》由会员分享，可在线阅读，更多相关《测试Web应用程序.ppt（62页珍藏版）》请在三一文库上搜索。

1、测试Web应用程序,姚砺 ,2,内容,C/S系统测试 C/S系统测试方法 C/S系统测试的步骤 C/S系统测试工具,3,C/S系统测试,什么是C/S系统 计算机体系结构的发展历史 主机系统 PC机器 C/S系统(客户机/服务器系统) 多层结构、B/S系统 功能/计算、数据的演化 集中-分离-分布,4,C/S系统测试,什么是C/S系统 结构：广义的C/S系统 数据一般使用数据库管理，放在Server端 表示层或者用户界面一般使用GUI或者Web技术，放在Client端 业务逻辑一般分布在Server端和Client端 Client与Server一般是独立的机器，使用LAN或者Internet联接

2、 多个操作系统平台，多个Client，一个或者多个Server,5,C/S系统测试,什么是C/S系统 优势 提升系统性能，减少用户等待时间 集中、共享计算能力 集中、共享数据 减少网络负载 支持多用户并发访问 提升系统灵活性 扩展容易 修改灵活 具备容错能力和恢复能力,易于扩展计算能力和数据分布能力 硬件扩展 支持异构系统,单独升级,数据可以分布并冗余 计算可以分布并冗余 机器硬件可以分布并冗余 异构系统,6,C/S系统测试,什么是C/S系统 开发技术 常用Client端开发工具 PB/VB/Delphi，也有VC/Developer 一般使用组件技术，并具备强大的数据库联接能力 事件驱动，可

3、视化编程，对象编程，RAD开发方法 常用Server端数据库 关系型数据库：Oracle/DB2/Sybase/SQL Server 支持SQL和ODBC 支持事务处理、安全机制、并发访问、数据分布,7,C/S系统测试,C/S系统测试与传统测试的比较 目标一致 为了尽早发现尽可能多的错误 对“错误”的理解的一个误区：易用性和用户界面美观是不重要的 在使用用户界面上的时间和频度方面，用户比开发人员或者测试人员要多得多；在技术难度不大的地方或者表面上不重要没有精心设计，那么这些错误对用户的影响会越来越大，直至最终掩盖了应用程序的优势。 例如：消费类产品的精心设计 为产品和过程度量提供数据,8,C/

4、S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 1、计算与数据分布，导致并发和安全问题，使场景复杂 2、使用事件驱动和组件技术设计的GUI界面使得测试路径趋近无穷，测试场景复杂,9,C/S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 3、使用对象编程技术使得对象之间的依赖和继承关系复杂，错误修改引起的连锁反应增大 4、使用对象和组件技术使得系统对第三方组件/类库依赖增强，在质量和技术上存在风险,10,C/S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 5、文档问题 系统本身复杂，导致文档内容复杂 使用了RAD开发方式，导致文档不

5、详细 多系统，导致文档术语难以统一,11,C/S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 6、多系统、多语言使得错误的隐蔽性和数量增大，测试环境的搭建更加困难，测试人员的技术要求更加全面 普通文件 v.s. 数据库系统 难于直接控制数据：数据独立并通过接口访问；内置安全机制和应用层安全机制混合在一起 单机 v.s. 网络 硬件之间和软件之间的通讯通过网络和上面的协议 多硬件、多软件、多数据库、多协议标准、多语言 失效、不匹配可能性增大 多开发人员 协调一致难度比较大,12,C/S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 7、高度依赖于第三方系

6、统 第三方产品的稳定性不能保证 多厂商带来的复杂性和管理问题 厂商之间的版本影响(DLL Hell) 厂商之间的版本更新组合情况复杂 PM是一个总承包商，厂商之间踢皮球,13,C/S系统测试,C/S系统测试与传统测试的比较 C/S系统的测试难度更大 8、测试历史数据和针对性的测试方法匮乏 可供参照的样板少 系统多样，可重复性比较小 技术比较新，可参考样板少，有经验的组织和个人比较少,14,内容,C/S系统测试 C/S系统测试方法 C/S系统测试的步骤 C/S系统测试工具,15,C/S系统测试,C/S系统测试的具体目标 1、检查系统是否达到公布的功能说明 功能范围要在项目开始之前确定，中途如果修

7、改，重新修改项目计划和预算 功能说明需要逐步完善，尽可能地将用户的期望写入公布的功能说明 JAD方式保证用户参与设计和确认，并降低最后验收的风险 RAD方式帮助用户表达和反馈对于系统的意见 功能的改变尽早提出 越到开发后期，功能改变越要谨慎，代价也越大,16,C/S系统测试,C/S系统测试的具体目标 2、检查是否满足性能要求 用户永远比开发人员更加关注性能 用户要成年累月地面对性能的困扰 不要试图与用户玩文字游戏 例如：某个窗口在1秒内可用(实际上，只有窗口10%内容在1秒内显示，其他内容还要等1分钟) 用户是甲方 用户可能当时无话可说，但是满意度下降，信任度下降，容忍度下降 用户一定会在其他

8、的地方找出本来可以忽略的毛病，并揪住不放 如果用户忘记提到某一条性能(实际上是开发人员“忘记”提问)，开发人员不要认为这是一件好事情，最后会造成更大的麻烦 用户新里面一定会有没有说出来的性能期望 用户是甲方,17,C/S系统测试,C/S系统测试的具体目标 3、检查是否能够处理要求的负载 除非做充分的性能测试、负载测试、压力测试和疲劳测试，否则没有人能够预测系统的负载到底如何 小负载的运行性能和功能表现与大负载下的性能和功能表现经常不同 资源限制 多用户并发、长时间、大量访问 数据量巨大,18,C/S系统测试,C/S系统测试的具体目标 4、检查在要求的各种软硬件平台上是否有错 测试试验室 各种软

9、硬件设备、技术全面的测试人员 不同硬件、软件、网络平台 每个客户端可能的不同软件环境 安装其他工作需要使用的软件 版本不同 Office、eMail,19,C/S系统测试,C/S系统测试的原则 原则：全面 不要假设没有问题，必须测试之后才能说没有问题,20,C/S系统测试,C/S系统测试的方法 常见错误 测试计划和测试方案需要关注的地方 常见的测试点 设计测试用例需要关注的地方,21,C/S系统测试,C/S系统测试的常见错误 1、功能性错误 只要列在需求中的功能在最终系统中没有达到，就属于功能性错误 包括因为过程中的指导发生了信息模糊或者矛盾 方法：依照系统需求逐项测试确认,22,C/S系统测

10、试,C/S系统测试的常见错误 2、系统错误 原因存在于开发的C/S系统之外，对C/S系统的运行产生影响的错误 例如：操作系统错误、中间件错误、DLL错误、驱动程序错误、硬件错误、网络设备错误 难点：隔离并确认错误发生的地点 导致供应商踢皮球； 即使承认，解决问题也需要时间，并且会给系统带来新的不稳定 方法： 1、尽量在开始设计的时候考虑周全，并考察供应商资格和服务 2、绕过这个问题 3、请厂商修改系统 4、更换厂商,23,C/S系统测试,C/S系统测试的常见错误 3、通讯错误 存在于C/S系统之外的，各个层之间通讯问题产生的错误 包括硬件，包括同层 例如 网卡坏了 电缆接触不良 通讯软件或者驱

11、动程序自身错误 用户权限不够 地址问题 路由器等通讯设备损坏 私有协议错误 是一种特殊的系统错误，分离出来的原因 通讯非常关键 通讯错误非常普遍,24,C/S系统测试,C/S系统测试的常见错误 4、逻辑错误 设计错误，考虑不全面或者理解错误 与传统测试中遇到的问题一样,25,C/S系统测试,C/S系统测试的常见错误 5、用户界面错误 用户界面不一致 同一个界面之内；同一个模块/产品之内；同一个系统之内 本地化问题 不支持本地化、部分本地化、本地化错误 信息模糊或者矛盾 信息显示不全 操作路径复杂、模糊,26,C/S系统测试,C/S系统测试的常见错误 6、数据错误 SQL简单/强大，但是技巧多/

12、风险大，直接涉及数据更改 开发人员培训SQL，并设置编码规范 互相检查代码 小组内设置SQL专家把关 SQL中的检查点 是否检查了查询的返回错误值，包括Select 仔细检查使用Delete和Update的地方 仔细检查存储过程和触发器 聚合函数的使用陷阱：不单独列出每一个记录 其它：如年龄的计算方法 数据库本身的检查点 Schema命名机制：变量作用域 安全性策略的设置和检查 多个数据库使用中，日期表示的不同特点,27,C/S系统测试,C/S系统测试的常见错误 7、编码错误 编程错误，坏的编程习惯 变量初始化、变量名字类似/错误使用 与传统测试中遇到的问题一样 数据类型和移植问题 多系统一致

13、性 计算能力迁移,28,C/S系统测试,C/S系统测试的常见错误 8、测试错误 软件错误模型偏差 开发语言和平台的更换 开发团队/开发规范的变化 软件业务领域的变化 测试策略问题 杀虫剂怪事 虫子聚窝 虫子装死、变异,29,C/S系统测试,C/S系统测试的常见测试点 1、输入合法性检查 必要性 小概率错误一定会发生 一个小概率错误与一个大概率或者严重错误往往是同一个产生原因 方法 代码中的错误处理分支 数据库中的约束、存储过程/触发器,30,C/S系统测试,C/S系统测试的常见测试点 2、路径测试 类似于白盒测试技术中的路径概念 C/S系统的完全路径测试是不现实的 使用基本测试路径方法,31,

14、C/S系统测试,C/S系统测试的常见测试点 3、事务测试 事务 设计角度：一个独立的工作单位 数据库角度：一个全部执行/不执行的SQL集合 用户角度：一个完全成功/取消的操作 容易出错的事务处理 在一个表中修改记录，但是同时更新多个表；或者直接更新多个表 影响到表关系的修改操作(比如：删除一个主键) 测试点(测试用例设计)： 输入合法的完整的记录，检查事务是否正确执行 输入合法的完整的记录，在完成之前放弃操作，检查表没有被更改 输入一个记录并故意漏掉一个数据项，检查表没有被更改 输入一个记录并故意有一个不合法数据项，检查表没有被更改 输入一个记录并使它的引用不存在，检查表没有被更改 事务中是否

15、包含不确定的耗时操作，会导致并发失败、性能下降 比如：等待用户输入,32,C/S系统测试,C/S系统测试的常见测试点 4、循环测试 路径测试,33,C/S系统测试,C/S系统测试的常见测试点 5、边界值测试 取临界数据或者操作作为测试用例,34,C/S系统测试,C/S系统测试的常见测试点 6、日期测试 润年计算、星期几计算 日期+/-数字、日期+/-日期 日期格式：01/12/99 vs 31/12/99 时区、时制,35,C/S系统测试,C/S系统测试的常见测试点 7、导入导出测试 输出输出设备不正确、繁忙、没有空间等情况 导入/导出文件类型不匹配 导入文件损坏或者内容不正确 当字符集表示方

16、法不同时，能否正确处理 数据恢复机制 尤其是系统升级的时候,36,C/S系统测试,C/S系统测试的常见测试点 8、安全性测试 锁使诚实的人表现出诚实；防君子不防小人；道高一尺，魔高一丈 在应用程序中，用户是否被正确所定在访问路径和访问窗口中 在应用程序或者操作系统中，用户是否可能直接访问数据库文件 在数据库管理中，用户是否被赋予了不适当的权限 开发人员是否留了后门 更多地依赖于代码审核和管理 病毒检查 平台或者第三方系统本身的安全问题 系统的已公布缺陷是否处理 是否打补丁了 使用Tiger组：安全专家/黑客高手,37,C/S系统测试,C/S系统测试的常见测试点 9、Login/Logoff测试

17、 是否正确记录登录和退出日志 对于多次登录失败的警告机制 口令强制修改措施的正确执行 每次显示上次登录记录 空闲终端退出 注意空闲条件判断，如：屏幕保护程序 是否符合规定的License要求,38,C/S系统测试,C/S系统测试的常见测试点 10、日志测试 是否正确记录日志内容 日志文件满、被删除、损坏、内容错误、访问权限错误的正确处理 日志文件的安全和访问权限,39,C/S系统测试,C/S系统测试的常见测试点 1、输入合法性检查 2、路径测试 3、事务测试 4、循环测试 5、边界值测试 6、日期测试 7、导出测试 8、安全性测试 9、Login/Logoff测试 10、日志测试,40,内容,

18、C/S系统测试 C/S系统测试方法 C/S系统测试的步骤 C/S系统测试工具,41,C/S系统测试的步骤,1、计划测试工作 2、测试设计和测试用例跟踪 3、缺陷报告和管理 4、效果评估,42,C/S系统测试的步骤,1、计划测试工作 与传统测试相比，还要： 注意多系统、多厂商的协调 建立测试实验室，注意测试资源(尤其是软件/硬件资源)的配备和管理 使用尽可能多样的系统组合 关注性能测试 尤其关注SQL 只有20%的性能优化来自与数据库管理 需要大量的数据 SQL正确性需要小数据库，性能测试需要大数据库,43,C/S系统测试的步骤,2、测试设计和测试用例跟踪 与传统测试相比，还要： 注重8种错误类

19、型和10个测试点 使用数据生成工具和性能测试工具,44,C/S系统测试的步骤,3、缺陷报告和管理 与传统测试相比，还要： 注意记录当时的系统/网络状态 注意记录当时的数据库和本机状态 注意缺陷的分离、重现和优化,45,C/S系统测试的步骤,4、效果评估 与传统测试相比，还要： 注意版本提交控制和配置管理,46,内容,C/S系统测试 C/S系统测试方法 C/S系统测试的步骤 C/S系统测试工具,47,C/S系统测试工具,C/S系统测试工具 多样性 用于早期测试与晚期测试 用于不同平台测试 用于不同测试内容 用于项目经理、QA人员、测试人员、开发人员 用于服务器和用于工作站,48,C/S系统测试工

20、具,C/S系统测试工具 主要功能 1、计划和管理 包括项目管理、缺陷管理、测试用例管理、文档与流程管理 2、源代码控制 甚至配置管理 3、调试器 4、面向对象的测试 5、测试数据库对象,49,C/S系统测试工具,C/S系统测试工具 主要功能 6、测试向导 7、自动测试用例生成 8、数据/数据库生成器 9、标准测试用例包 SQL语言 通讯协议 10、捕获、回放与比较 无人照料的测试 疲劳测试,50,C/S系统测试工具,C/S系统测试工具 主要功能 11、模拟负载测试 12、模拟并发测试 13、监视程序 14、剖析测试 15、内存泄漏测试,51,C/S系统测试工具,C/S系统测试工具 主要优点 1

21、、测试流程和数据的标准化、规范化 有助于测试强制性 2、与项目计划、开发计划集成 3、测试用例、缺陷报告、缺陷分析与测试计划集成 4、测试文档管理 5、缺陷跟踪和管理、测试评估,52,C/S系统测试工具,C/S系统测试工具 主要优点 6、测试脚本和测试用例可以重复使用、重新编辑 7、测试数据与测试过程/脚本分离 8、适合回归测试与压力测试、负载测试、疲劳测试 9、观察程序内部信息 对象属性、方法 内部数据变化,53,C/S系统测试工具,C/S系统测试工具 主要缺点 1、费用风险 购买费用 学习和培训费用 设计费用：包括脚本生成 修改费用：尤其是版本功能或者结构变化 技术风险：测试工具本身的错误

22、 2、集成问题 流程和方法论与具体项目的结合,54,C/S系统测试工具,C/S系统测试工具 主要缺点 3、银弹风险 没有银弹 给管理者和项目组不切实际的期望 尤其是管理者 买了工具就能保证质量吗？ 4、测试套件 一般的同一个厂商工具套件之间联系非常紧密 不同厂商之间没有统一标准,55,C/S系统测试工具,C/S系统测试工具 主要缺点 5、本地化问题 缺乏中文版本 文档、界面 报告内容 内部数据支持 6、平台多样性 与具体软件类型相关 与具体软件/硬件平台相关 与开发语言/技术相关,56,C/S系统测试工具,C/S系统测试工具 选择步骤 1、分析测试需求 测试类型 测试平台 软件类型和开发技术

23、测试人员素质 2、收集产品信息 主要是厂商资料 专业杂志 同行讨论与参观,57,C/S系统测试工具,C/S系统测试工具 选择步骤 3、选择产品 费用 购买、学习、实施、支持、升级 市场 资料多 测试人员多 公司背景和产品策略 4、计划引入步骤,58,C/S系统测试工具,C/S系统测试工具 选择步骤 5、准备好测试期望 看到好处和坏处 派出人为因素 本地化问题 缺乏中文版本 文档、界面 报告内容 内部数据支持 6、逐步实施并评估效果,59,C/S系统测试工具,C/S系统测试工具 国内常用类型 1、捕捉回放工具 基于脚本 2、性能测试工具 基于代理模拟 3、测试管理工具 测试计划管理 测试用例管理 缺陷报告管理 测试评估与度量、报告,60,C/S系统测试工具,C/S系统测试工具 WinRunner 能做什么？ 与Director联接 自动记录和回放 什么样子 TSL 界面对象探测功能 界面对象编历 两个记录模式(Sensitive analog),61,C/S系统测试工具,C/S系统测试工具 WinRunner 方法 录制 修改脚本并update 回放 结果比较 其它 延迟与同步 GUI/BMP/Text CheckPoint 不同版本之间的比较使用 数据独立驱动 TSL语言,62,内容,C/S系统测试 C/S系统测试方法 C/S系统测试的步骤 C/S系统测试工具,