基于CS应用的软件测试

C/S系统的完全路径测试是不现实的

使用基本测试路径方法
21/41
C/S系统测试的常见测试点（续）
3、事务测试

事务

设计角度：一个独立的工作单位 数据库角度：一个全部执行/不执行的SQL集合 用户角度：一个完全成功/取消的操作 在一个表中修改记录，但是同时更新多个表；或者直接更新多个表 影响到表关系的修改操作(比如：删除一个主键) 输入合法的完整的记录，检查事务是否正确执行 输入合法的完整的记录，在完成之前放弃操作，检查表没有被更改 输入一个记录并故意漏掉一个数据项，检查表没有被更改 输入一个记录并故意有一个不合法数据项，检查表没有被更改 输入一个记录并使它的引用不存在，检查表没有被更改 事务中是否包含不确定的耗时操作，会导致并发失败、性能下降


容易出错的事务处理


测试点(测试用例设计)：



比如：等待用户输入
22/41
C/S系统测试的常见测试点（续）
4、循环测试

路径测试
5、边界值测试

取临界数据或者操作作为测试用例
6、日期测试

润年计算、星期几计算
日期+/-数字、日期+/-日期 日期格式：01/12/99 vs 31/12/99

信息模糊或者矛盾 信息显示不全 操作路径复杂、模糊
17/41
C/S系统测试的常见错误（续）
6、数据错误



SQL简单/强大，但是技巧多/风险大，直接涉及数据更改 开发人员培训SQL，并设置编码规范 互相检查代码 小组内设置SQL专家把关 SQL中的检查点 是否检查了查询的返回错误值，包括Select 仔细检查使用Delete和Update的地方 仔细检查存储过程和触发器 聚合函数的使用陷阱：不单独列出每一个记录 其它：如年龄的计算方法 数据库本身的检查点 Schema命名机制：变量作用域 安全性策略的设置和检查 多个数据库使用中，日期表示的不同特点

是一种特殊的系统错误，分离出来的原因

通讯非常关键 通讯错误非常普遍
16/41
C/S系统测试的常见错误（续）
4、逻辑错误

设计错误，考虑不全面或者理解错误 与传统测试中遇到的问题一样
5、用户界面错误

用户界面不一致

同一个界面之内；同一个模块/产品之内；同一个系统之内

本地化问题

不支持本地化、部分本地化、本地化错误

锁使诚实的人表现出诚实；防君子不防小人；道高一尺，魔 高一丈

在应用程序中，用户是否被正确所定在访问路径和访问窗口中 在应用程序或者操作系统中，用户是否可能直接访问数据库文件
在数据库管理中，用户是否被赋予了不适当的权限
开发人员是否留了后门

更多地依赖于代码审核和管理

病毒检查
平台或者第三方系统本身的安全问题
C/S系统测试的方法

常见错误

测试计划和测试方案需要关注的地方

常见的测试点

设计测试用例需要关注的地方
13/41
C/S系统测试的常见错误
1、功能性错误

只要列在需求中的功能在最终系统中没有达到，就 属于功能性错误

包括因为过程中的指导发生了信息模糊或者矛盾

方法：依照系统需求逐项测试确认
14/41

功能的改变尽早提出

越到开发后期，功能改变越要谨慎，代价也越大
9/41
C/S系统测试的具体目标(续)
2、检查是否满足性能要求

用户永远比开发人员更加关注性能

用户要成年累月地面对性能的困扰

不要试图与用户玩文字游戏

如：某个窗口在1秒内可用(实际上，只有窗口10%内容在1秒内显示， 其他内容还要等1分钟)

系统的已公布缺陷是否处理 是否打补丁了
25/41

使用Tiger组：安全专家/黑客高手
C/S系统测试的常见测试点（续）
9、Login/Logoff测试

是否正确记录登录和退出日志
Hale Waihona Puke Baidu
对于多次登录失败的警告机制
口令强制修改措施的正确执行 每次显示上次登录记录 空闲终端退出

注意空闲条件判断，如：屏幕保护程序
集中、共享计算能力
集中、共享数据 减少网络负载
1.
支持多用户并发访问

提升系统灵活性

扩展容易
1. 2. 3. 4.
数据可以分布并冗余 计算可以分布并冗余 机器硬件可以分布并冗余 异构系统
修改灵活
具备容错能力和恢复能力
4/41
什么是C/S系统(续)
开发技术

常用Client端开发工具

PB/VB/Delphi，也有VC/Developer 一般使用组件技术，并具备强大的数据库联接能力 事件驱动，可视化编程，对象编程，RAD开发方法

常用Server端数据库

关系型数据库：Oracle/DB2/Sybase/SQL Server 支持SQL和ODBC 支持事务处理、安全机制、并发访问、数据分布
4、检查在要求的各种软硬件平台上是否有错

测试试验室

各种软硬件设备、技术全面的测试人员

不同硬件、软件、网络平台
每个客户端可能的不同软件环境

安装其他工作需要使用的软件

版本不同 Office、eMail„
12/41
C/S系统测试的原则与方法
C/S系统测试的原则

原则：全面

不要假设没有问题，必须测试之后才能说没有问题

时区、时制
23/41
C/S系统测试的常见测试点（续）
7、导入导出测试

输出输出设备不正确、繁忙、没有空间等情况 导入/导出文件类型不匹配


导入文件损坏或者内容不正确
当字符集表示方法不同时，能否正确处理
数据恢复机制

尤其是系统升级的时候
24/41
C/S系统测试的常见测试点（续）
8、安全性测试
第12讲 基于C/S应用的软件测试
1/41
什么是C/S系统
计算机体系结构的发展历史

主机系统 PC机器


C/S系统(客户机/服务器系统)
多层结构、B/S系统
功能/计算、数据的演化

集中-〉分离-〉分布
2/41
什么是C/S系统(续)
结构：广义的C/S系统

数据一般使用数据库管理，放在Server端 表示层或用户界面一般使用GUI或者Web技术，放在Client端

整个测试过程包括：

静态分析，测试计划，测试设计，测试执行，测试缺陷跟踪， 测试报告和质量度量等
29/41
C/S系统测试工具（续）

是否符合规定的License要求
10、日志测试

是否正确记录日志内容 日志文件满、被删除、损坏、内容错误、访问权限错误的正确处理 日志文件的安全和访问权限
26/41
C/S系统测试的步骤
1、计划测试工作

与传统测试相比，还要：

注意多系统、多厂商的协调 建立测试实验室，注意测试资源(尤其是软件/硬件资源) 的配备和管理 使用尽可能多样的系统组合 关注性能测试


业务逻辑一般分布在Server端和Client端
Client与Server一般是独立的机器，使用LAN或者Internet 联接

多个操作系统平台，多个Client，一个或者多个Server
3/41
什么是C/S系统(续)
优势

提升系统性能，减少用户等待时间


1. 易于扩展计算能力和数据分 布能力 2. 硬件扩展 3. 支持异构系统 单独升级
10/41
C/S系统测试的具体目标（续）
3、检查是否能够处理要求的负载

除非做充分的性能测试、负载测试、压力测试和疲劳测试， 否则没有人能够预测系统的负载到底如何 小负载的运行性能和功能表现与大负载下的性能和功能表现 常不同


资源限制 多用户并发、长时间、大量访问 数据量巨大
11/41
C/S系统测试的具体目标（续）
18/41
C/S系统测试的常见错误（续）
7、编码错误

编程错误，坏的编程习惯

变量初始化、变量名字类似/错误使用„
与传统测试中遇到的问题一样

数据类型和移植问题

多系统一致性 计算能力迁移
19/41
C/S系统测试的常见错误（续）
8、测试错误

软件错误模型偏差

开发语言和平台的更换 开发团队/开发规范的变化 软件业务领域的变化
C/S系统测试难度更大(续)
7.
高度依赖于第三方系统

第三方产品的稳定性不能保证 多厂商带来的复杂性和管理问题

厂商之间的版本影响(DLL Hell) 厂商之间的版本更新组合情况复杂 PM是一个总承包商，厂商之间踢皮球
8.
测试历史数据和针对性的测试方法匮乏

可供参照的样板少

系统多样，可重复性比较小 技术比较新，可参考样板少，有经验的组织和个人比较少
C/S系统测试的常见错误（续）
2、系统错误

原因存在于开发的C/S系统之外，对C/S系统的运行产生影响 的错误

例如：操作系统错误、中间件错误、DLL错误、驱动程序错误、硬件 错误、网络设备错误„ 难点：隔离并确认错误发生的地点


导致供应商踢皮球； 即使承认，解决问题也需要时间，并且会给系统带来新的不稳定
8/41
C/S系统测试的具体目标
1、检查系统是否达到公布的功能说明

功能范围要在项目开始之前确定，中途如修改，重新修改项 目计划和预算 功能说明需要逐步完善，尽可能地将用户的期望写入公布的 功能说明


JAD方式(联合应用开发)保证用户参与设计和确认，并降低最后验收 的风险

RAD方式帮助用户表达和反馈对于系统的意见
文档问题


5.
系统本身复杂，导致文档内容复杂
使用了RAD(快速应用软件开发)开发方式，导致文档不详细 多系统，导致文档术语难以统一
6/41
C/S系统测试与传统测试的比较（续）
C/S系统的测试难度更大(续)
6.
多系统、多语言使得错误的隐蔽性和数量增大，测试环境 的搭建更加困难，测试人员的技术要求更加全面


尤其关注SQL

只有20%的性能优化来自于数据库管理

需要大量的数据

SQL正确性需要小数据库，性能测试需要大数据库
27/41
C/S系统测试的步骤（续）
2、测试设计和测试用例跟踪

与传统测试相比，还要：

注重8种错误类型和10个测试点

使用数据生成工具和性能测试工具
3、缺陷报告和管理

与传统测试相比，还要：

注意记录当时的系统/网络状态 注意记录当时的数据库和本机状态 注意缺陷的分离、重现和优化
4、效果评估

与传统测试相比，还要：

注意版本提交控制和配置管理
28/41
C/S系统测试工具
什么是测试工具

定义：辅助测试整个过程的工具软件

单元测试可以有两种方式

自己编写代码 使用单元测试工具
用户是甲方


用户可能当时无话可说，但是满意度下降，信任度下降，容忍度下降 用户一定会在其他的地方找出本来可以忽略的毛病，并揪住不放

如果用户忘记提到某一条性能(实际上是开发人员“忘记” 提问)，开发人员不要认为这是一件好事情，最后会造成更 大的麻烦

用户新里面一定会有没有说出来的性能期望 用户是甲方
5/41
C/S系统测试与传统测试的比较
C/S系统的测试难度更大
1. 2.
计算与数据分布，导致并发和安全问题，使场景复杂 使用事件驱动和组件技术设计的GUI界面使得测试路径趋近 无穷，测试场景复杂 使用对象编程技术使得对象之间的依赖和继承关系复杂， 错误修改引起的连锁反应增大
3.
4.
使用对象和组件技术使得系统对第三方组件/类库依赖增强， 在质量和技术上存在风险

普通文件 v.s. 数据库系统

难于直接控制数据：数据独立并通过接口访问；内置安全机制和应用 层安全机制混在一起

单机 v.s. 网络

硬件之间和软件之间的通讯通过网络和上面的协议

多硬件、多软件、多数据库、多协议标准、多语言

失效、不匹配可能性增大

多开发人员

协调一致难度比较大
7/41
C/S系统测试与传统测试的比较（续）

测试策略问题

杀虫剂怪事 虫子聚窝 虫子装死、变异
20/41
C/S系统测试的常见测试点
1、输入合法性检查

必要性

小概率错误一定会发生 一个小概率错误与一个大概率或者严重错误往往是同一 个产生原因 代码中的错误处理分支 数据库中的约束、存储过程/触发器

方法

2、路径测试

类似于白盒测试技术中的路径概念

方法：
1、尽量在开始设计的时候考虑周全，并考察供应商资格和服务 2、绕过这个问题
3、请厂商修改系统
4、更换厂商
15/41
C/S系统测试的常见错误（续）
3、通讯错误

存在于C/S系统之外的，各个层之间通讯问题产生的错误

包括硬件，包括同层。例如：

网卡坏了


电缆接触不良
通讯软件或者驱动程序自身错误 用户权限不够 地址问题 路由器等通讯设备损坏 私有协议错误