基于CS应用的软件测试

nullnull第12讲 基于C/S应用的软件测试什么是C/S系统什么是C/S系统计算机体系结构的发展历史 主机系统 PC机器 C/S系统(客户机/服务器系统) 多层结构、B/S系统 功能/计算、数据的演化 集中-〉分离-〉分布什么是C/S系统(续)什么是C/S系统(续)结构：广义的C/S系统 数据一般使用数据库管理，放在Server端 表示层或用户界面一般使用GUI或者Web技术，放在Client端 业务逻辑一般分布在Server端和Client端 Client与Server一般是独立的机器，使用LAN或者Internet联接 多个操作系统平台，多个Client，一个或者多个Server什么是C/S系统(续)什么是C/S系统(续)优势 提升系统性能，减少用户等待时间 集中、共享计算能力 集中、共享数据 减少网络负载 支持多用户并发访问 提升系统灵活性 扩展容易 修改灵活 具备容错能力和恢复能力易于扩展计算能力和数据分布能力 硬件扩展 支持异构系统单独升级数据可以分布并冗余 计算可以分布并冗余 机器硬件可以分布并冗余 异构系统什么是C/S系统(续)什么是C/S系统(续)开发技术 常用Client端开发工具 PB/VB/Delphi，也有VC/Developer 一般使用组件技术，并具备强大的数据库联接能力 事件驱动，可视化编程，对象编程，RAD开发方法 常用Server端数据库 关系型数据库：Oracle/DB2/Sybase/SQL Server 支持SQL和ODBC 支持事务处理、安全机制、并发访问、数据分布C/S系统测试与传统测试的比较C/S系统测试与传统测试的比较C/S系统的测试难度更大 计算与数据分布，导致并发和安全问题，使场景复杂 使用事件驱动和组件技术 设计 领导形象设计圆作业设计ao工艺污水处理厂设计附属工程施工组织设计清扫机器人结构设计 的GUI界面使得测试路径趋近无穷，测试场景复杂 使用对象编程技术使得对象之间的依赖和继承关系复杂，错误修改引起的连锁反应增大 使用对象和组件技术使得系统对第三方组件/类库依赖增强，在质量和技术上存在风险 文档问题 系统本身复杂，导致文档内容复杂 使用了RAD(快速应用软件开发)开发方式，导致文档不详细 多系统，导致文档术语难以统一nullC/S系统测试与传统测试的比较（续）C/S系统的测试难度更大(续) 多系统、多语言使得错误的隐蔽性和数量增大，测试环境的搭建更加困难，测试人员的技术要求更加全面 普通文件 v.s. 数据库系统 难于直接控制数据：数据独立并通过接口访问；内置安全机制和应用层安全机制混在一起 单机 v.s. 网络 硬件之间和软件之间的通讯通过网络和上面的协议 多硬件、多软件、多数据库、多协议标准、多语言 失效、不匹配可能性增大 多开发人员 协调一致难度比较大nullC/S系统测试与传统测试的比较（续）C/S系统测试难度更大(续) 高度依赖于第三方系统 第三方产品的稳定性不能保证 多厂商带来的复杂性和管理问题 厂商之间的版本影响(DLL Hell) 厂商之间的版本更新组合情况复杂 PM是一个总承包商，厂商之间踢皮球 测试历史数据和针对性的测试方法匮乏 可供参照的样板少 系统多样，可重复性比较小 技术比较新，可参考样板少，有经验的组织和个人比较少C/S系统测试的具体目标C/S系统测试的具体目标1、检查系统是否达到公布的功能说明 功能范围要在项目开始之前确定，中途如修改，重新修改项目 计划 项目进度计划表范例计划下载计划下载计划下载课程教学计划下载 和预算 功能说明需要逐步完善，尽可能地将用户的期望写入公布的功能说明 JAD方式(联合应用开发)保证用户参与设计和确认，并降低最后验收的风险 RAD方式帮助用户表达和反馈对于系统的意见 功能的改变尽早提出 越到开发后期，功能改变越要谨慎，代价也越大C/S系统测试的具体目标(续)C/S系统测试的具体目标(续)2、检查是否满足性能要求 用户永远比开发人员更加关注性能 用户要成年累月地面对性能的困扰 不要试图与用户玩文字游戏 如：某个窗口在1秒内可用(实际上，只有窗口10%内容在1秒内显示，其他内容还要等1分钟) 用户是甲方 用户可能当时无话可说，但是满意度下降，信任度下降，容忍度下降 用户一定会在其他的地方找出本来可以忽略的毛病，并揪住不放 如果用户忘记提到某一条性能(实际上是开发人员“忘记”提问)，开发人员不要认为这是一件好事情，最后会造成更大的麻烦 用户新里面一定会有没有说出来的性能期望 用户是甲方C/S系统测试的具体目标（续）C/S系统测试的具体目标（续）3、检查是否能够处理要求的负载 除非做充分的性能测试、负载测试、压力测试和疲劳测试，否则没有人能够预测系统的负载到底如何 小负载的运行性能和功能表现与大负载下的性能和功能表现常不同 资源限制 多用户并发、长时间、大量访问 数据量巨大C/S系统测试的具体目标（续）C/S系统测试的具体目标（续）4、检查在要求的各种软硬件平台上是否有错 测试试验室 各种软硬件设备、技术全面的测试人员 不同硬件、软件、网络平台 每个客户端可能的不同软件环境 安装其他工作需要使用的软件 版本不同 Office、eMail…C/S系统测试的原则与方法C/S系统测试的原则与方法C/S系统测试的原则 原则：全面 不要假设没有问题，必须测试之后才能说没有问题 C/S系统测试的方法 常见错误 测试计划和测试 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 需要关注的地方 常见的测试点 设计测试用例需要关注的地方C/S系统测试的常见错误C/S系统测试的常见错误1、功能性错误 只要列在需求中的功能在最终系统中没有达到，就属于功能性错误 包括因为过程中的指导发生了信息模糊或者矛盾 方法：依照系统需求逐项测试确认C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）2、系统错误 原因存在于开发的C/S系统之外，对C/S系统的运行产生影响的错误 例如：操作系统错误、中间件错误、DLL错误、驱动程序错误、硬件错误、网络设备错误… 难点：隔离并确认错误发生的地点 导致供应商踢皮球； 即使承认，解决问题也需要时间，并且会给系统带来新的不稳定 方法： 1、尽量在开始设计的时候考虑周全，并考察供应商资格和服务 2、绕过这个问题 3、请厂商修改系统 4、更换厂商C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）3、通讯错误 存在于C/S系统之外的，各个层之间通讯问题产生的错误 包括硬件，包括同层。例如： 网卡坏了 电缆接触不良 通讯软件或者驱动程序自身错误 用户权限不够 地址问题 路由器等通讯设备损坏 私有协议错误 是一种特殊的系统错误，分离出来的原因 通讯非常关键 通讯错误非常普遍C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）4、逻辑错误 设计错误，考虑不全面或者理解错误 与传统测试中遇到的问题一样 5、用户界面错误 用户界面不一致 同一个界面之内；同一个模块/产品之内；同一个系统之内 本地化问题 不支持本地化、部分本地化、本地化错误 信息模糊或者矛盾 信息显示不全 操作路径复杂、模糊C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）6、数据错误 SQL简单/强大，但是技巧多/风险大，直接涉及数据更改 开发人员培训SQL，并设置编码 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 互相检查代码 小组内设置SQL专家把关 SQL中的检查点 是否检查了查询的返回错误值，包括Select 仔细检查使用Delete和Update的地方 仔细检查存储过程和触发器 聚合函数的使用陷阱：不单独列出每一个 记录 混凝土 养护记录下载土方回填监理旁站记录免费下载集备记录下载集备记录下载集备记录下载 其它：如年龄的计算方法 数据库本身的检查点 Schema命名机制：变量作用域 安全性策略的设置和检查 多个数据库使用中，日期表示的不同特点C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）7、编码错误 编程错误，坏的编程习惯 变量初始化、变量名字类似/错误使用… 与传统测试中遇到的问题一样 数据类型和移植问题 多系统一致性 计算能力迁移C/S系统测试的常见错误（续）C/S系统测试的常见错误（续）8、测试错误 软件错误模型偏差 开发语言和平台的更换 开发团队/开发规范的变化 软件业务领域的变化 测试策略问题 杀虫剂怪事 虫子聚窝 虫子装死、变异C/S系统测试的常见测试点C/S系统测试的常见测试点1、输入合法性检查 必要性 小概率错误一定会发生 一个小概率错误与一个大概率或者严重错误往往是同一个产生原因 方法 代码中的错误处理分支 数据库中的约束、存储过程/触发器 2、路径测试 类似于白盒测试技术中的路径概念 C/S系统的完全路径测试是不现实的 使用基本测试路径方法C/S系统测试的常见测试点（续）C/S系统测试的常见测试点（续）3、事务测试 事务 设计角度：一个独立的工作单位 数据库角度：一个全部执行/不执行的SQL集合 用户角度：一个完全成功/取消的操作 容易出错的事务处理 在一个表中修改记录，但是同时更新多个表；或者直接更新多个表 影响到表关系的修改操作(比如：删除一个主键) 测试点(测试用例设计)： 输入合法的完整的记录，检查事务是否正确执行 输入合法的完整的记录，在完成之前放弃操作，检查表没有被更改 输入一个记录并故意漏掉一个数据项，检查表没有被更改 输入一个记录并故意有一个不合法数据项，检查表没有被更改 输入一个记录并使它的引用不存在，检查表没有被更改 事务中是否包含不确定的耗时操作，会导致并发失败、性能下降 比如：等待用户输入C/S系统测试的常见测试点（续）C/S系统测试的常见测试点（续）4、循环测试 路径测试 5、边界值测试 取临界数据或者操作作为测试用例 6、日期测试 润年计算、星期几计算 日期+/-数字、日期+/-日期 日期格式：01/12/99 vs 31/12/99 时区、时制C/S系统测试的常见测试点（续）C/S系统测试的常见测试点（续）7、导入导出测试 输出输出设备不正确、繁忙、没有空间等情况 导入/导出文件类型不匹配 导入文件损坏或者内容不正确 当字符集表示方法不同时，能否正确处理 数据恢复机制 尤其是系统升级的时候C/S系统测试的常见测试点（续）C/S系统测试的常见测试点（续）8、安全性测试 锁使诚实的人表现出诚实；防君子不防小人；道高一尺，魔高一丈 在应用程序中，用户是否被正确所定在访问路径和访问窗口中 在应用程序或者操作系统中，用户是否可能直接访问数据库文件 在数据库管理中，用户是否被赋予了不适当的权限 开发人员是否留了后门 更多地依赖于代码审核和管理 病毒检查 平台或者第三方系统本身的安全问题 系统的已公布缺陷是否处理 是否打补丁了 使用Tiger组：安全专家/黑客高手C/S系统测试的常见测试点（续）C/S系统测试的常见测试点（续）9、Login/Logoff测试 是否正确记录登录和退出日志 对于多次登录失败的警告机制 口令强制修改措施的正确执行 每次显示上次登录记录 空闲终端退出 注意空闲条件判断，如：屏幕保护程序 是否符合规定的License要求 10、日志测试 是否正确记录日志内容 日志文件满、被删除、损坏、内容错误、访问权限错误的正确处理 日志文件的安全和访问权限C/S系统测试的步骤C/S系统测试的步骤1、计划测试工作 与传统测试相比，还要： 注意多系统、多厂商的协调 建立测试实验室，注意测试资源(尤其是软件/硬件资源)的配备和管理 使用尽可能多样的系统组合 关注性能测试 尤其关注SQL 只有20%的性能优化来自于数据库管理 需要大量的数据 SQL正确性需要小数据库，性能测试需要大数据库C/S系统测试的步骤（续）C/S系统测试的步骤（续）2、测试设计和测试用例跟踪 与传统测试相比，还要： 注重8种错误类型和10个测试点 使用数据生成工具和性能测试工具 3、缺陷报告和管理 与传统测试相比，还要： 注意记录当时的系统/网络状态 注意记录当时的数据库和本机状态 注意缺陷的分离、重现和优化 4、效果评估 与传统测试相比，还要： 注意版本提交控制和配置管理C/S系统测试工具C/S系统测试工具什么是测试工具 定义：辅助测试整个过程的工具软件 单元测试可以有两种方式 自己编写代码 使用单元测试工具 整个测试过程包括： 静态分析，测试计划，测试设计，测试执行，测试缺陷跟踪，测试报告和质量度量等C/S系统测试工具（续）C/S系统测试工具（续）测试工具的种类 静态分析工具 代码规范审核工具 内存和资源检查工具 测试数据生成工具 测试框架工具 测试结果比较工具 测试度量工具 测试文档生成和管理工具C/S系统测试工具（续）C/S系统测试工具（续）系统测试多样性 用于早期测试与晚期测试 用于不同平台测试 用于不同测试内容 用于项目经理、QA人员、测试人员、开发人员 用于服务器和用于工作站C/S系统测试工具（续）C/S系统测试工具（续）系统测试工具主要功能 1、计划和管理 包括项目管理、缺陷管理、测试用例管理、文档与流程管理 2、源代码控制 甚至配置管理 3、调试器 4、面向对象的测试 5、测试数据库对象 6、测试向导 7、自动测试用例生成 8、数据/数据库生成器C/S系统测试工具（续）C/S系统测试工具（续）系统测试工具主要功能(续) 9、标准测试用例包 SQL语言、通讯协议 10、捕获、回放与比较 无人照料的测试、疲劳测试 11、模拟负载测试 12、模拟并发测试 13、监视程序 14、剖析测试 15、内存泄漏测试C/S系统测试工具（续）C/S系统测试工具（续）系统测试工具主要优点 1、测试流程和数据的标准化、规范化 有助于测试强制性 2、与项目计划、开发计划集成 3、测试用例、缺陷报告、缺陷分析与测试计划集成 4、测试文档管理 5、缺陷跟踪和管理、测试评估 6、测试脚本和测试用例可以重复使用、重新编辑 7、测试数据与测试过程/脚本分离 8、适合回归测试与压力测试、负载测试、疲劳测试 9、观察程序内部信息 对象属性、方法 内部数据变化C/S系统测试工具（续）C/S系统测试工具（续）系统测试工具主要缺点 1、费用风险 购买费用、学习和培训费用、设计费用（包括脚本生成）、修改费用（尤其是版本功能或者结构变化）、技术风险（测试工具本身的错误） 2、集成问题 流程和方法论与具体项目的结合 3、银弹风险 没有银弹 给管理者和项目组不切实际的期望 尤其是管理者（买了工具就能保证质量吗？） 4、测试套件 一般的同一个厂商工具套件之间联系非常紧密 不同厂商之间没有统一标准 5、本地化问题 缺乏中文版本 文档和界面、报告内容、内部数据支持 6、平台多样性 与具体软件类型相关、与具体软件/硬件平台相关、与开发语言/技术相关C/S系统测试工具（续）C/S系统测试工具（续）系统测试工具选择步骤 1、分析测试需求 测试类型、测试平台、软件类型和开发技术、测试人员素质 2、收集产品信息 主要是厂商资料、专业杂志、同行讨论与参观 3、选择产品 费用 购买、学习、实施、支持、升级 市场 资料多、测试工具多、公司背景和产品策略 4、计划引入步骤 5、准备好测试期望 看到好处和坏处 派出人为因素 本地化问题 缺乏中文版本 文档与界面、报告内容、内部数据支持 6、逐步实施并评估效果C/S系统测试工具（续）C/S系统测试工具（续）国内常用类型 1、捕捉回放工具 基于脚本 2、性能测试工具 基于代理模拟 3、测试管理工具 测试计划管理 测试用例管理 缺陷报告管理 测试评估与度量、报告C/S系统测试工具（续）C/S系统测试工具（续）自动测试工具 好处 速度和效率 准确度和精确度 耐性、不休息、可重复 局限 对软件变更，尤其是代码变更比较敏感 先期的测试开发比较费时 有些测试结果无法用工具比较和分析 有些工具的脚本/代码会使程序运行环境不纯净null四、C/S系统测试工具（续）为什么使用自动测试工具 测试工具提高测试效率，节省测试成本 测试设计提高测试效果，同时也可以提高测试效率，节省测试成本 有些测试单靠手工很难完成 压力测试，模拟并发测试等 多数的单元测试 有些测试使用测试工具更合适 回归测试 大量测试数据的生成、部分测试结果的比较 缺陷管理和测试用例管理 质量度量nullC/S系统测试工具（续）如何引入自动测试工具 选择自动测试工具是一个重要的步骤，一定要谨慎 因为测试工作经常会涉及到管理流程和开发流程的改变、涉及到人员的考评标准，所以它有时会对整个企业产生影响 测试工具应该能够管理测试过程和测试文档，并生成各种测试报告 自动测试工具应该允许用户把自动测试数据和流程与手工的测试数据和流程结合到一起 自动测试工具应该能够将业务需求与测试计划、测试设计和测试结果相关联，允许最终用户根据测试结果来评估应用程序的完成情况 自动测试工具中的各功能模块应该紧密集成到一起，共享和重用测试数据，支持回归测试 工具应该可以很容易地利用过去的或者其他人员的测试资料 工具内部应该使用一致的脚本语言和数据格式 自动测试工具的体系结构和文件格式应该是开放的，可以容易地与其他技术或工具进行交互和集成 自动测试工具厂商应该有比较完善的技术培训和技术支持机制，能够为自动测试工具的实施提供咨询和支持C/S系统测试工具（续）C/S系统测试工具（续）WinRunner 能做什么？ 与Director联接、自动记录和回放 什么样子 测试脚本语言、界面对象探测功能、界面对象编历、两个记录模式(Sensitive analog) 方法 录制、修改脚本、回放、结果比较 其它 延迟与同步 GUI/BMP/Text CheckPoint 不同版本之间的比较使用 数据独立驱动