通用测试知识（三）

非功能测试

界面测试和易用性测试

界面测试

窗体界面测试

1. 案例
   
   

2. 窗体界面测试用例
   

• 缩放规则：
  • 文本框：宽度可以变，高度不可以
  • 密码框：宽度可以变，高度不可以
  • 单选按钮：都不变
  • 复选框：都不变
  • 下拉列表：宽度可以变，高度不可以
  • 列表框：都不变
  • 滚动条、按钮：都不变

控件界面测试

1. 案例
   
   

2. 控件界面测试用例
   

菜单界面测试

1. 案例
   

2. 菜单界面测试用例
   

特殊属性的界面测试

易用性测试

易用性测试的含义

易用性指软件产品被理解、学习、使用和吸引用户的能力。

易用性测试要点

• 业务符合性
• 功能定制性
• 业务模块的集成度
• 数据共享能力
• 约束性
• 交互性
• 错误提示

案例

控件易用性测试用例

菜单易用性测试用例

快捷方式易用性测试用例

联机帮助易用性测试用例

辅助系统易用性测试用例

• 向导测试
• 信息提示是否用具有可以理解性的语言进行描述
• 对重要的、有破坏性的命令是否提示
• 信息提示是否统一

兼容性测试

兼容性测试的含义

兼容性测试验证软件与其所在的环境的依赖程度，包括对硬件的依赖程度，对平台的依 赖程度、其他软件的依赖程度等。

案例

兼容性测试的前提

• 标准和规范是软件兼容性的保证
  • 高级标准
    • 产品遵守的规则
  • 低级标准
    • 文件格式和网络通信协议
      

兼容性测试的测试点

• 硬件兼容
  • 包括主板、处理器、内存、显卡、显示器、打印机等。
    • 如不同品牌和架构的计算机、不同频率或不同位数的 CPU、不同大小的内存、 硬盘、不同带宽的网络等。
• 操作系统兼容
  • 包括操作系统类型、位数、补丁版本等。选择测试平台要考虑操作系统的流行程度、 年份、类型、生产厂商等方面。
  • 不同操作系统如 Windows、Mac、 Solaris、Linux 等；手机平台如 Android、IOS、 Windows Phone。
• 软件并发兼容
  • 浏览器兼容
    • 不同浏览器如 IE、FireFox、Chrome 和 Safari 等。
  • 与其他软件兼容
• 分辨率兼容
  • 测试不同分辨率下软件都能正常使用。
• 向前、向后兼容
  • 向后兼容或向下兼容
    • 指较高版本的程序能顺利处理较低版本程序的数据或者在较老系统中使用；
    • 新版本软件能够兼容以前各种版本产生的历史数据，确保数据向后兼容， 如 Word2013 能够正常打开之前多个 Word 版本（如 Word 2003、Word 2007 等）产生的用户.doc 文件。
  • 向前兼容或向上兼容
    • 指以前的版本支持现在版本生成的数据，现在的版本支持以后的版本数据或者 在更高版本的系统中使用。
• 不同客户端软件版本和服务器系统的兼容  服务器上一般部署的都是最新版本，但客户端就不一定。
• 数据共享兼容
  • 测试文档的保存和读取数据格式兼容
  • 剪贴板（考虑格式兼容）

文档测试

哪些文档需要测试

• 用户手册
• 联机帮助
• Readme 文件（自述文件）
• 授权/注册登记表/用户许可协议
• 指南及向导
• 包装文字和图形
• 市场宣传材料
• 标签

文档测试检查单

文档测试的测试点

校对+照做

Readme 文档

联机帮助

及时/即时联机帮助

用户手册

文档测试需要注意的问题

• 对于软件用户来说，程序之外的内容也是软件的一部分；
• 文档常常得不到足够的重视，缺乏资金和技术支持以及测试；
• 编写文档的人可能并不是软件特性方面的专家，对软件不了解；
• 由于文档的印刷需要花费时间，所以之间产生的问题得不到修复；
• 文档测试不仅仅是文字校对，还涉及程序本身的错误。

安装测试

安装测试的分类

• 安装测试
• 运行测试
• 卸载测试
• 加密测试

安装测试注意事项

• 安装手册评估
• 安装的自动化程度测试
• 安装选项和设置的测试
• 安装过程中的中断测试
• 安装顺序测试
• 多环境安装测试
• 安装的正确性测试
• 修复安装测试
• 卸载测试

安装测试的测试用例

运行测试的测试用例

卸载测试的测试用例

加密测试

加密测试的内容

• 软件加密
  • 序列号的测试
  • 解密程序的测试
• 硬件加密
  • 加密狗的测试

加密测试的测试用例

性能测试基础

性能测试的含义

什么是性能测试

• 测试软件的性能表现，考量软件运行的如何
  • 一般关注时间/效率、资源占用等情况。
  • 既要马儿快点跑，又要马儿少吃草。

什么时候进行性能测试

• 已通过系统测试，功能比较稳定。

谁关注性能

• 用户
  • 用户体会到的性能是软件对用户操作的响应时间，是用户从提交或输入一个 url 地 址到系统将全部数据呈现出来的时间。
• 系统管理员和性能测试工程师
  • 除与用户的视角一样外，还关注与系统状态相关的信息，如系统资源的使用情况，包括 CPU 的使用、内存的使用情况、磁盘 I/O、数据交互等。
  • 还关注硬件资源的可扩展性即规划性能部分，如系统支持 100 个用户并发没问题， 支持 200个呢？
• 软件开发工程师
  • 关注以上所有问题，还关注内存泄露、数据库是否死锁、中间件以及和应用程序服务器等问题。

性能测试术语

请求

• 客户端向服务器发出的请求获得数据或文件、图片等资源。

响应

• 服务器向客户端发送数据或文件、图片等资源

协议

• 传输层协议：tcp、udp
• 应用层协议：ftp、http、dns、dhcp、smtp、pop

响应时间

• 应用系统从用户发出请求开始，到客户端接收到所有数据所消耗的时间。
• 网页响应时间细分
  • 网络传输时间：N1+N2+N3+N4。
  • 应用服务器处理数据：A1+A3。
  • 数据库处理时间：A2。
  • 

在线用户

• 正在使用软件的用户。

并发用户数

• 指同一时刻与服务器进行数据交互的所有用户数量。
  • 在线用户未必是并发用户。
• 计算并发用户数
  • 一般都根据以往经验和行业标准进行估算。
    • 如电信业并发用户数常为在线用户的万分之一；
    • OA 软件并发用户数一般为在线用户数的 5%-20%。
  • 参考其他同类产品。
  • 分析历史数据（一年或半年内的每天需要处理的交易业务量）。
  • 试上线运行。

虚拟用户

• 性能测试工具使用虚拟用户模拟真实用户的行为。

吞吐量与吞吐率

• 吞吐量
  • 指一段时间内服务器处理的字节数，直接体现服务器的承载能力。
  • 
  • 从吞吐量和 VU （虚拟用户数量）关联图可看出，吞吐量在 VU 增长到一定数量时，软件系统出现性能瓶颈，此时吞吐量不再随 VU 增多而增大，而是趋于平衡。
  • 实际测试时，吞吐量在测试前是不知道的，必须通过不断添加虚拟用户来测试，以找到吞吐量的拐点，即吞吐量的最大值。
• 吞吐率（Throughout）
  • 指单位时间内从服务器返回的字节数，即吞吐量/测试时间，也可以是单位时间内处理的客户请求数。
  • 它是衡量网络性能一个重要指标。通常情况下吞吐量越大，吞吐率的值也越大，吞吐率越大表示系统的负载能力越强。

每秒事务数（TPS，Transaction Per Second）

• 表示每秒系统处理的事务数，是衡量系统处理能力的重要指标。
• 如果每个事务对应一笔业务，那么 TPS 即表示服务器每秒处理的业务笔数。

点击率（Hit Per Second）

• 指每秒钟用户向服务器提交的 HTTP 请求的数量。
• 点击一次可能会向服务器发出多个 HTTP 请求。
  • 通常服务器都具有防刷新机制，以防刷新导致的巨大压力。
• 点击率仅仅反映客户端提交的请求数，不能表现服务器当前承受的压力，因为服务器不能处理全部请求时可以拒绝客户端的部分请求。
• 若把每次点击作为一次提交事务来对待，则点击率与 TPS 同义。

思考时间（Think Time）

• 也称"休眠时间"、等待时间。
• 指用户在进行操作时，每个请求之间的时间间隔。
• 负载测试一般忽略思考时间，压力或可靠性测试根基实际情况设置一个思考时间。通常思考时间设置为 3-5s。

资源利用率

• 资源利用率
  • 指服务器系统中不同硬件资源被占用的程度，主要包括 CPU 利用率、内存利用率、磁盘利用率、网络等。
  • 性能测试中常用资源利用率进行横向对比，如 CPU 使用率很高，而其他资源较低，可知 CPU 是系统瓶颈。
  • 配置调优测试中，通过比较配置调优前后的系统资源利用率来判断调优效果。
• 性能计数器（Counter）
  • 是描述服务器或操作系统性能的一些数据指标。主要是通过添加计数器来观察系统资源的使用情况。
  • 计数器在性能测试中发挥着“监控和分析”的关键作用，尤其是分析系统可扩展性和定位性能瓶颈时。
  • 性能测试中分析测试结果时，必须基于多个不同的计数器进行分析。

性能测试分类

负载测试（Load Testing）

• 通过对被测试系统不断的加压，直到超过预定的指标或者部分资源已经达到了一种饱和状态不能再加压为止。
• 此方法主要是为了寻找系统最大的负载能力，为性能调优提供依据。

压力测试

• 当系统已经达到一定的饱和程度（如 CPU、磁盘等已经处于一种饱和状态）时，测试系统处理业务的能力，测试系统是否会出现崩溃等。
• 一般通过模拟负载等方法，使系统资源达到一个较高水平。
• 此方法一般用于系统稳定性测试。

并发测试（Concurrency Testing）

• 通过模拟用户并发访问，测试多用户同时访问同一应用、模块或数据，观察系统是否存在死锁、系统处理速度明显下降等性能问题。

容量测试（Volume Testing）

• 寻找软件系统某项指标的极限值（如最大并发用户数、数据库记录数、最大负载、工作量等）的测试，是一种测试目标。

可靠性测试（Reliability Testing）

• 或称稳定性测试，健壮性测试。
• 当系统在一定的业务压力下，让系统持续运行一段时间，观察系统是否达到要求的稳定性。
• 可靠性测试一般必须给出一个明确的要求，如系统能够持续无故障运行多少天。
• 是一种测试目标。

配置测试（Configuration Testing）

• 配置测试
  • 通过调整系统软/硬件环境，了解不同环境对系统性能的影响，从而找到系统的最优配置。
  • 此方法一般用于系统调优和规划。
• 基准测试
  • 在一定的软硬件及网络环境下，模拟一定数量的虚拟用户运行一种或多种业务，将测试结果作为基线数据，在系统调优或系统评测过程中，通过运行相同的业务场景来比较测试结果确定调优是否达到效果或为系统的选择提供决策依据。

功能测试的流程

性能测试过程分为四个阶段：测试设计、构建、执行、分析。

设计阶段

• 定义待测试的业务流程、业务的平均处理量、业务处理量的最高峰值、组合业务流程、系统的整体用户和响应时间目标。

构建阶段

• 设计设置和配置测试系统及基础设施、使用自动化性能测试解决方案构建测试脚本和负载方案。
• 具体包括：编写脚本、增强脚本、设计场景。

执行阶段

• 包括运行负载方案和测量系统性能，对系统资源进行监控。

分析、诊断和调节阶段

• 主要测量系统性能并使负载测试进入下一级别，重点查找问题原因以帮助开发工程师迅速解决问题，并实时调节系统参数以提高性能。

主流性能测试工具

本地化和国际化测试

软件全球化（SoftWare Globalization）

• 包括软件本地化与软件国际化两方面。
• 随着全球市场经济的发展，企业在全球各地都可能有子公司、合作伙伴或客户，其产品 可能销往全球。如果企业的产品还只是提供一种区域的语言，那么产品将很难生存。
• 用户界面（UI）、各国多语言、货币、日期格式、计量单位，这些因素影响了产品在全球的竞争力。
• 软件国际化版本是本地化版本的基础，国际化版本的优劣直接影响本地化版本的质量和开发的成本。

国际化测试的测试方法

1. 通用功能

• 测试在各种语言环境下，应用程序是否能被正确地安装；
• 各种操作系统和用户区域设置下，通用功能是否能正确地使用；
• 在不同操作系统和各区域设置下，应用程序是否能被正确地卸载。

2. 文本处理功能

• 使用不同区域的输入法编辑器交互式输入文本时，系统的反应；
• 多语言文本剪贴板操作；
• 用户界面对文本的处理；
  • 改善翻译文本尺寸，使其具有调整的灵活性。
    • 对于不同语言的主窗口及对话框，尽量保持近似的大小。建议对话框的英文字 体为 MS Sant Serif，字号 8，中文字体为宋体，字号 9。
    • 对于控件，应根据实际需要对显示的文本进行大小调节，也就是说，各语言版 本控件不必保持大小一致，以适应各自语言文本长度需要为主，兼顾整体设计。
• 应用程序对双字节字符集的输入和输出处理；
  • 支持 Unicode 字符集、双字节字符。
    • Unicode 事实上包含了现代计算机广为使用的所有字符，提供了 8 位、16 位、 32 位编码形式。其中 16 位是默认编码形式。
    • 由于 Internet 的全球性要求能够适用于所有语言的解决方案，所以 Unicode 特别适合于 Internet 时代。
• 应用程序对多字节字符集文本缓冲区大小的处理。

3. 区域支持功能

• 测试应用程序对不同区域中一些使用习惯的处理；
• 应用程序是否遵循区域标准，正确处理输入、存储、检索区域特定数据；
• 应用程序验证带有数据分隔符的时间、日期和数值的处理情况；
• 应用程序在不同纸张、信封大小上打印的正确性；
• 应用程序对各种区域有关度量的处理是否正确；
• 支持各国的键盘设置
• 系统需求支持各国的键盘设置，但所有的热键应该统一。
• 支持文字排序和大小写切换。
• 支持各国度量衡、时区、货币单位格式设置。

4. 文字镜像

• 世界上大多数国家的文字是从左至右书写，但如阿拉伯语和希伯来语则是从右至左书写，阿拉伯语和希伯来语中的数字又是从左至右书写的。当同一段落混合使用了这两种书写方向时，将之称为双向文稿。
• 当需要对这种双向文稿进行本地化时，测试时就需要注意软件国际化开发过程中是否采用了文字镜像处理，并且镜像处理不仅仅是对本地化的文字顺序，还需要对界面元素（按 钮、菜单等）进行镜像处理。

5. 程序代码与显示内容分离

• 消除硬编码
  • 指将可变变量用一个固定值来代替的方法。
  • java 小例子
  • int a=2,b=2; -硬编码 if（a==2） return false; -不是硬编码 if（a==b） return true;

本地化测试的测试方法

软件本地化过程

本地化版本开发的主要工作为软件的翻译、本地化工程、桌面排版和测试。

翻译

• 是本地化多语言实现的过程。

本地化工程处理

• 包括调整对话框、用户界面元素大小和控件位置，重新设计一些软件的图像。

桌面排版

• 对翻译后的软件手册、联机帮助和其他文档根据本地要求重新排版。
• 所有的本地化内容（软件、文档、手册等）都要经过系统的软件测试，修正缺陷后，才能发布本地化版本。
• 桌面排版和显示需要注意本地化使用习惯、文化和宗教信仰等情况。

本地化测试的测试方法

多语言测试

• 主要是测试翻译后界面显示的情况。
• 由于本地化翻译导致出现热键冲突、热键丢失、热键错误的情况。
• 本应该翻译的字符而未翻译。
• 不需要翻译的专业词语而翻译了。
• 界面中控件字符显示不完整。
• 界面中的文字越界。
• 界面出现垃圾字符。
• 界面出现衔接错误、无效衔接、死链接的现象。
• 界面出现丢失行的现象。
• 界面出现菜单项丢失现象。

区域文化

• 包装
  • 在包装产品时，由于个国家民族风俗习惯的不同，对颜色、数字的使用需要注意，一些国家对某种颜色或数字有忌讳，如日本忌讳数字“4”，送礼时忌讳送 2 万日元和 2 的倍数
• 图标
  • 在使用图标时，需要注意慎用动物图案，不同的国家对动物的喜欢、反感的程度不同，如英国人不喜欢大象、孔雀。
• 广告宣传
  • 在跨地区进行广告宣传时，一个品牌进入另一个市场必须考虑目标市场的社会形态、风俗习惯、消费者的背景、心理因素、宗教信仰、价值观等。
• 政治术语
  • 在系统中应该注意地方规章、宗教信仰和政治术语等的使用。
• 颜色
  • 不同国家对待颜色也有所不同。
• 数字
  • 对数字的使用也需要注意，如日本人忌讳数字“4”，若产品一包中有四小包，在日本不容易销售；西方人忌讳数字“13”，大酒店没有第13层，从12层直接到第14层。
• 地区宗教
  • 几乎每个国家都有自己信仰的宗教，如佛教、道教、伊斯兰教、基督教、天主教、犹太教、东正教、印度教、锡克教、拜火教、波斯明教等，在本地化过程中使用的术语、颜色需要注意是否与当地的宗教信仰相冲突。

数据格式

• 数字
  • 对于数字中的千位，不同国家的使用方式有所不同，有的国家使用点，有的使用句号，有的使用逗号，有的使用空格。针对各国家数字的表示，在设计本地化软件时应该注意。
• 货币
  • 不同的国家使用的货币符号不相同，这些符号所在的位置也有所不同，有的在金额前面，有的在金额后面。
• 时间
  • 有的国家采用 24 小时来表示，有的国家采用 12 小时分上午、下午的方式来表示。
• 时期格式
  • 有的国家采用 MM/DD/YY 来显示月、日、年，有的国家则采用分隔符号（如 “/”和“-”）来表示，中国则使用 YYYY 年 M 月 D 日来表示。
• 姓名格式
  • 英文的姓名格式是名在前，姓在后，姓名之间需一个空格，但在东亚国家（如中国）则是姓在前、名在后。
• 度量衡单位
  • 很多国家使用的度量单位都不一致。虽然很多国家都已开始使用国际公制度量单位，如米、公里、克、千克、升等，但一些国家（如美国和英国）仍然使用自己国家的度量单位，如英尺、英里、英镑等。
  • 在本地化过程中必须对各国的度量单位进行处理，一般情况下，系统应该提供用户可以设置度量单位和在不同度量单位之间的转换。
• 复数问题
  • 对于不同的语言其复数形式有所不同，即使在英语中，复数的规则也并不是一致的，如“apple”的复数为“apples”，而“city”的复数为“cities”。
• 索引和排序
  • 英文排序和索引习惯上按照字母的顺序来编排，但是对于一些非字母文字的国家（如亚洲很多国家）来说，这种方法就不适用了，中国汉字就有按拼音、部首和笔画等不同的方法进行排序。即使是使用文字字母的国家，它们的排序方法和英文也有所不同，如德语有30个字母，在索引排序时应该对多出的4个字母进行考虑。

热键

• 热键也称快捷键，指使用键盘上某几个特殊组键组合起来完成一项特定任务。
• 如果在 Microsoft Word 中可以通过 Ctrl+A 组合键对文本内容进行全选，其中字母 “A”对应的单词为“ALL”。在本地化翻译过程中，当单词“ALL”被本地化后， 很可能首字母不再为“A”，那么这个热键就会出错。
• 假如本地化翻译为德文，单词“All”翻译为“Todos”，此时，热键对应的应该修 改为Ctrl+T，否则在本地化操作过程中，该功能将失效。
  对于使用非字母文字的国家，依然沿用英文中的热键方式，如中国、日本、韩国等。

专项测试方法

Web测试

电子商务站点的基本结构

电商平台的标准架构

相关概念：

• SEO
  Search Engine Optimization，搜索引擎优化。
  SEO 是指从自然搜索结果获得网站流量的技术和过程，是在了解搜索引擎自 然排名机制的基础上，对网站进行内部及外部的调整优化，改进网站在搜索引 擎中的关键词自然排名，获得更多流量，从而达成网站销售及品牌建设的目标。

• ERP
  Enterprise Resource Planning，企业资源计划。
  功能涵盖生产资源计划、制造、财务、销售、采购、质量管理，实验室管理， 业务流程管理，产品数据管理，存货、分销与运输管理，人力资源管理和定期 报告系统。
  目前，在我国 ERP 所代表的含义已经被扩大，用于企业的各类软件，已经统 统被纳入 ERP 的范畴。
  它跳出了传统企业边界，从供应链范围去优化企业的资源，是基于网络经济时 代的新一代信息系统，主要用于改善企业业务流程以提高企业核心竞争力。

• CRM
  Customer Relationship Management，客户关系管理系统。
  企业用 CRM 技术来管理与客户之间的关系，功能涵盖自动化分析销售、市场 营销、客户服务以及应用等流程的软件系统。它的目标是通过提高客户的价值、 满意度、赢利性和忠实度来缩减销售周期和销售成本、增加收入、寻找扩展业 务所需的新的市场和渠道。CRM 是选择和管理有价值客户及其关系的一种商 业策略，CRM 要求以客户为中心的企业文化来支持有效的市场营销、销售与 服务流程。

电商平台的分布式多层结构

Web 测试的测试方法

Web测试的总体策略（三层：表示层、业务层、数据层）

• 表示层：用户操作
• 业务层：操作逻辑
• 数据层：后台数据库问题

Web 测试的范围

• 功能
• 性能
• 界面
• 兼容性
• 安全性
• DB（数据库）
• 文档

Web 测试的方法

功能测试

功能测试主要从链接、表单、Cookies、设计语言、数据库、文件上传等方面进行。

• 链接

  • 也称超链接，是指从一个网页指向另一个目标的连接关系，所指向的目标可能是一个网页、相同网页上的不同位置、图片、电子邮件地址、文件、应用程序等。
  • 链接最容易出现以下几种错误
    • 错误链接：
      如 URL地址拼写错误、URL后缀多余或缺少斜杠、URL地址中出现的字母大小写不完全匹配、用户输入的域名拼写错误。
    • 空链接：
      单击该链接时不会指向任何内容。
    • 死链接：
      原来正常，后来失效的链接。
    • 孤立页面：
      指没有链接指向该页面，只有知道正确的URL地址才能访问。

• 表单

  • 表单是系统与用户交互最主要的界面，测试过程主要关注程序是否能正确地处理客户提交的信息，并将信息正确地反馈到客户端。
  • 测试过程中应该注意以下几方面的测试
    • 文本输入框对长度是否有限制。
    • 文本输入框对字符类型是否有限制。
    • 文本输入框模式匹配是否正确，如该文本框只能输入日期格式的数据，那么只能匹配不同的日期格式，而不能匹配其他格式的数据。
    • 各按钮实现的功能是否正确。

• Cookies

  • Cookies 能够让网站服务器把少量数据存储到客户端的硬盘或内存，或是从客户端的硬盘读取数据的技术。

  • Cookie 有哪些用途

    • 自动登录，登录时，选择记住用户名，下次登录会自动带出用户名来。
    • 广告精准投放，当我们用浏览器搜索过一些关键字，如：web 测试书，某手机，打开浏览器时，会推送相关浏览过的商品。
    • 查看 Cookies
      • 打开 IE，在工具栏点工具→Internet 选项→常规→（Internet 临时文件）浏览历史记录→设置，这样可以查看到 Cookies 所存位置，还可以对其进行设置。
    • 

  • Cookies的测试包含以下几个方面

    • Cookies的安全性：Cookie 中最好不要存储一些敏感的信息，需要时应该对 Cookie中的 一些字段进行加密处理。
    • Cookies的过期时间是否正确；
    • Cookies的变量名与值是否正确；
    • Cookies是否必要，是否缺少：一是生成的 Cookie 文件是否与创建的一致， 不能多也不能少，二是对于不必要的 Cookie 可以删除。
    • Cookies的作用域是否正确合理；
    • 多个Cookies的作用域之间关系的测试。

• 设计语言测试

  • Web 设计语言版本的差异可以引起客户端或服务器端严重的问题，如使用哪种版本的HTML等。
  • 不同的脚本语言，如 Java、JavaScript、ActiveX、VBScript 或 Perl 等，也要进行验证。
  • 关于设计语言的测试，应该注意以下几个方面
    • 不同的浏览器内核引擎不同，会导致与不同的开发语言的兼容情况不同， 当前主流浏览器的内核有 Trident、Tasman、Pesto、Gecko、KHTML、WebCore和WebKit。
    • 不同的设计语言与平台有不同的兼容性。
    • 不同脚本语言执行的时间也不同。
    • 嵌入其他语言的能力。脚本语言对一些操作无法实现，如读取客户端的信息，此时需要同时借助其他语言来实现。要考虑当前脚本语言对其他语言的支持程度。
    • 系统数据库可能升级，测试时需要考虑脚本语言支持数据库的完善程度。

• 文件上传

• 只能上传允许的附件类型；

• 不能上传脚本或可执行文件；

• 不能单纯以后缀名来判断文件类型；

• 浏览好文件后，可以正常处理删除目标文件时出现的异常情况；

• 上传超大文件时可以正常处理，比如给出提示信息等；

• 上传的文件应该提供接口查看；

• 上传的文件不应该直接保存于数据库中，而是将文件保存在服务器端硬盘，而在数据库中保存该文件的基本信息；

• 文件上传到服务器端后应该被重命名，防止文件名冲突。

性能测试

• 链接速度测试
  链接的响应时间不能太长，一般不超过 5 秒。

• 负载测试（Load Testing）
  测试系统能够承受的最大负载（如最大用户量、最大业务量、最大数据量等）以及 性能表现（完成测试的时间）。

• 压力测试（Stress Testing）
  测试系统在一定压力下的性能表现，通常业务的错误率不能超过 5%。

• 界面测试
  GUI（Graphical User Interface）即图形用户界面。

  • 格式验证：
    验证 Web 页面中一些空间默认的标准定义，如默认值、项目按顺序排列等。
  • 导航条测试：
    • 各页面导航条是否能正确地显示；
    • 各页面下导航条显示的内容是否正确；
    • 不同状态下（如登录与未登录），导航条显示的内容是否正确；
    • 导航条的每项内容链接是否正确。
  • 拼写和语法测试
    验证页面内容、菜单和链接、图片、表格内容的拼写和语法。
  • 页面排版测试
    • 页面标题验证；
    • 页面元素（文字、窗体、菜单、链接、公司商标等）排版验证；
    • 页面图形验证；
    • 页面版本信息验证；
    • 不同分辨率下的页面显示情况验证；
    • 页面长度验证。
  • Tab 键测试：
    Tab 顺序正确跳转（从左到右，从上到下）。

• 安全性测试

  • 基本安全测试

    • 各种登录模式的安全性验证、对口令各种要求的测试。
    • 用户权限（如功能限制、数据访问限制等）的验证。
    • Cookie 和 Session 的有效期验证等特殊机制的验证。
    • 敏感数据加密、数据存储安全性的验证。
    • 验证系统的日志文件是否得到保护。
    • 测试软件不会因在异常条件下错误操作而导致不安全状态。
    • 其他各种安全漏洞的检查，如 WSDigger 扫描。
      • 跨站点攻击XSS
        get 方式在 URL 后输入如 name=<script>alert(123456）</script>，若弹出告警框，说明存在跨站漏洞；查看源文件中若包含完整的字符串<script>alert(123456)</script>，则不管有没有弹出告警框，都表明存在跨站脚本漏洞 ；post方式在表单的文本框中输入<script>alert(123456)</script>，若弹出警告或者查看源文件中存在输入的字符串则存在漏洞。
      • SQL注入：
        （1）sql=‘select yhm,mm from users where username=‘+ yhmTextField.getTex(t) +’ and password=’+mmTextField.getTex(t)’
        （2）如用户名中输入 admin’ --后，不输入密码也可以登录。

  • 认证测试

    • 登录页面是否存在验证码，不存在说明存在漏洞。
    • 验证码和用户名、密码是否一次性、同时提交给服务器验证，如果分开提交，则存在漏洞。
    • 在服务器端，只有在验证码检验通过后才进行用户名和密码的检验，否则存在漏洞。
    • 验证码是否为图片形式且在一张图片中，不为图片形式或不在一张图片中，说明存在漏洞。
    • 请求10次观察验证码是否随机生成，如果存在一定的规律（例如 5 次后出现同一验证码）说明存在漏洞。
    • 观察验证码图片中背景是否存在无规律的点或线条，如果背景为纯色（例如只有白色）说明存在漏洞。
    • 验证码在认证一次后是否立即失效。
    • 服务器不能对认证错误提示准确的信息，如用户名错误、密码错误等。
    • 提供合理的锁定策略。
    • 预防认证被绕过+，如 sql 注入。

  • 会话管理测试

    • 用户登录后，身份信息不再由客户端提交，而是以服务器端会话信息中保存的身份信息为准。
    • URL 中不能携带 Session ID 信息。
    • 登录后的页面有明确的"退出"或"注销"按钮，注销时会话信息要清除。

  • 权限管理测试

    • 横向越权：攻击者尝试访问与他拥有相同权限的用户的资源。
    • 纵向越权：一个低级别攻击者尝试访问高级别用户的资源。

  • 文件和目录测试

    • 不存在不需要对外开放的敏感接口或者接口进行了完善的权限控制；
    • 禁止获取敏感的目录或文件信息；
    • 所有对目录的访问均不能打印出文件列表；
    • 禁止访问和下载文档的备份
    • 不能越权获取到不该获取的文件
      • 如 DirBuster 扫描。

• 数据库测试

  • 数据库测试是为了发现错误和缺陷而运行数据库的过程。
  • 数据库测试方法也分为白盒测试和黑盒测试。
  • 数据库黑盒测试：
    • 数据库表结构是否合理；
    • 数据结构（如数据类型、长度）是否正确定义，并且需要注意数据结构与输入界面中数据的类型和长度是否一致，如果不一致，数据库则会报错；
    • 表与表之间的关系是否正确，主外键是否合理；
    • 索引的创建是否合理；
    • 存储过程功能是否完整，能否正确接受输入、输出正确结果；
    • 能否正确插入（增加）、更新、删除数据；
    • 数据库操作权限定义是否正确；
    • 能否正确处理并发操作；
    • 表级、列级完整性约束条件是否满足；
    • 数据库的处理能力、可靠性、可维护性、性能是否满足要求。

App测试

手机 App 测试的范围

• 功能模块测试
• 交叉事件测试
• 性能测试
• 安全测试
• 兼容性测试
• 安装/卸载测试
• 接口测试
• 网络测试

手机 App 测试的方法

功能模块测试

1.1 运行

• App安装完成后的试运行，可正常打开软件。
• App打开测试，是否有加载状态进度提示。
• App打开速度测试，速度是否可观。
• App页面间的切换是否流畅，逻辑是否正确
• 注册
  • 用户名密码长度
  • 注册后的提示页面
  • 前台注册页面和后台的管理页面数据是否一致
  • 注册后，在后台管理中页面提示
• 登录
  • 使用合法的用户登录系统。
  • 系统是否允许多次非法的登录，是否有次数限制。
  • 使用已经登录的账号登录系统是否正确处理。
  • 使用禁用的账号登录系统是否正确处理。
  • 用户名、口令（密码）错误或漏填时能否登录。
  • 删除或修改后的用户，原用户登录。
  • 不输入用户口令和用户名、重复点（确定或取消按钮）是否允许登录。
  • 登录后，页面中登录信息。
  • 页面中有注销按钮。
  • 登录超时的处理。
• 注销
  • 注销原模块，新的模块系统能否正确处理。
  • 终止注销能否返回原模块，原用户。
  • 注销原用户，新用户系统能否正确处理。
  • 使用错误的账号、口令、无权限的被禁用的账号进行注销。

1.2 应用的前后台切换

• APP切换到后台，再回到 App，检查是否停留在上一次操作界面。
• APP切换到后台，再回到 App，检查功能及应用状态是否正常。
• App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
• 手机锁屏解屏后进入 App 注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
• 当 App使用过程中有电话进来中断后再切换到 App，功能状态是否正常
• 当杀掉App进程后，再开启App，App能否正常启动。
• 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
• 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

1.3 免登录

• App 有免登录功能时，需要考虑 OS 版本差异。
• 考虑无网络情况时能否正常进入免登录状态。
• 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
• 根据 MTOP（淘宝无线开放平台）的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
• App 切换到后台，再切回前台的校验
• 密码更换后，检查有数据交换时是否进行了有效身份的校验
• 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
• 检查用户主动退出登录后，下次启动App，应停留在登录界面

1.4 数据更新

• 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动 +自动刷新。
• 确定哪些地方从后台切换回前台时需要进行数据更新。
• 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
• 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
• 检查有数据交换的地方，均有相应的异常处理。

1.5 离线浏览

• 很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。
• 在无网络情况可以浏览本地数据。
• 退出 App 再开启 App 时能正常浏览。
• 切换到后台再切回前台可以正常浏览。
• 锁屏后再解屏回到应用前台可以正常浏览。
• 在对服务端的数据有更新时会给予离线的相应提示。

1.6 App 更新

• 当客户端有新版本时，有更新提示。
• 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动 App 时，仍能出现更新提示。
• 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动 App 时，仍出现强制升级提示。
• 当客户端有新版本时，在本地不删除客户端的情况下，直接更新，检查是否能正常更新。
• 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否具有了新版本的功能。
• 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。
• 升级后可以正常使用。
• 在线跨版本升级。

1.7 定位、照相机服务

• App 有用到相机，定位服务时，需要注意系统版本差异。
• 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
• 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
• 测试定位、照相机服务时，需要采用真机进行测试。

1.8 时间测试

• 客户端可以自行设置手机的时区、时间，因此需要校验该设置对 App 的影响。
• 中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。
  • 比如发表一篇微博在服务端记录的是 10:00，此时，华盛顿时间为 22:00，客户端去浏览时，如果设置的是华盛顿时间，则显示的发表时间即为 22:00，当时间设回东 8 区时间时，再查看则显示为 10:00。

1.9 PUSH 推送测试

• 检查 PUSH 消息是否按照指定的业务规则发送。
• 检查不接受推送消息时，检查用户不会再接收到 PUSH.
• 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到 PUSH。
• 在非免打扰时间段，用户能正常收到 PUSH。
• 当 PUSH 消息是针对登录用户的时候，需要检查收到的 PUSH 与用户身份是否相符，没有错误地将其它人的消息推送过来。一般情况下，只对手机上最后一个登录用户进行消息推送。
• 测试 PUSH 时，需要采用真机进行测试。

交叉事件测试

• 又叫事件冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰测试。如：App 在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。
• 执行干扰的冲突事件不能导致软件应用软件异常、手机死机或者花屏等严重问题。
  • 多个 App 同时运行是否影响正常功能。
  • App 运行时前/后台切换是否影响正常功能。
  • App 运行时拨打/接听电话。
  • App 运行时发送/接收信息。
  • App 运行时发送/收取邮件。
  • App 运行时切换网络（2G/3G/WIFI）
  • App 运行浏览网页。
  • App 运行时使用蓝牙传送/接收数据。
  • App 运行时使用相机、计算器手机自带设备。
  • App 运行时插拔充电器。
  • 注意各交叉事件的优先级别，检验系统是否能依据各事件的优先级别依次进行处理。不能因执行优先级别高的事件而导致优先级别较低的事件吊死。
  • 有中英文模式切换的手机要注意中英文模式切换后的功能实现存在的问题。

性能测试

3.1 响应时间和资源占用测试

• 测试 App 中的各类操作是否满足用户响应时间要求。
  • App 安装、启动、卸载的响应时间。
  • App 各类功能性操作的响应时间。
• 在各种边界压力情况下，如电池、存储、网速等，验证 App 是否能正确响应。
  • 内存满时安装 App。
  • 运行 App 时手机断电。
  • 运行 App 时断掉网络。
• 评估典型用户应用场景下，系统资源的使用情况。

3.2 压力测试

• 反复/长期操作下、系统资源是否占用异常。
• App 反复进行安装卸载，查看系统资源是否正常。
• 其他功能反复进行操作，查看系统资源是否正常。
• 大数量的测试
  • 在特定环境下，客户端一次性更新大量的数据及人员列表时，客户端能否正常处理，分为三种情况：
    • 客户端第一次使用，第一次就更新大量数据及人员列表。
    • 客户端在平时更新中，更新大量的数据。
    • 客户端已经在手机本地下载很多数据后，再次更新大量数据。

3.3 性能评估

• Benchmark测试（基线测试）：与竞争产品对比测试，产品演变对比测试等。

3.4 特定场景测试

• 通过模拟终端低电量（例如 5%电量）的状态来测试功能在该状态下的正确性。
• 通过模拟终端处于特殊地理位置（例如上海）来测试功能在该状态下的正确性。
• 通过模拟终端处于特定网络状态下（例如 3G）来测试功能在该状态下的正确性。

3.5 深度性能测试

• 获取 App 在典型使用场景及待机状态下消耗的电量消耗。
• 获取 App 在典型使用场景及待机状态下消耗的流量。
• 获取 App 在典型使用场景及待机状态下的 CPU 占用率。
• 获取 App 在典型使用场景及待机状态下内存量。
• 获取 App 冷启动和热启动耗时内容。
• 获取 App 特定页面的内容加载耗时。
• 获取 App 退出的耗时。
• 获取 App 在典型使用场景下帧率。

安全测试

4.1 软件权限

• 扣费风险：包括发送短信、拨打电话、连接网络等。
• 隐私泄露风险：包括访问手机信息、访问联系人信息等。
• 对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测。
• 限制/允许使用手机功能接入互联网。
• 限制/允许使用手机发送接收信息功能。
• 限制/允许应用程序来注册自动启动应用程序。
• 限制/允许使用本地连接。
• 限制/允许使用手机拍照或录音。
• 限制/允许使用手机读取用户数据。
• 限制/允许使用手机写入用户数据。
• 检测 App 的用户授权级别、数据泄漏、非法授权访问等。

4.2 安装与卸载安全性

• 应用程序应能正确安装到设备上。
• 能够在安装设备上找到应用程序的相应图标。
• 是否包含数字签名信息。
• JAD 文件和 JAR 包中包含的所有托管属性及其值必须是正确的。
  • 下载 JAVA 程序是通常会发现是两个文件，即 JAR 和 JAD。
  • JAR 文件：是许多信息经过封装后形成的捆绑体，是一个压缩文件。
  • JAD 文件：是 Java 应用程序描述器文件。
• JAD 文件显示的资料内容与应用程序显示的资料内容应一致。
• 安装路径应能指定。
• 没有用户的允许，应用程序不能预先设定自动启动。
• 卸载是否安全，其安装进去的文件是否全部卸载。
• 卸载用户使用过程中产生的文件是否有提示。
• 其修改的配置信息是否复原。
• 卸载是否影响其他软件的功能。
• 卸载应该移除所有的文件。
• 高/低版本覆盖安装。
• 安装、卸载、更新错误报告。

4.3 数据安全性

• 当将密码、信用卡明细或其他的敏感数据输入到应用程序时，其不会被储存在设备中，不以明文形式将数据写到其它单独的文件或者临时文件中，以防止应用程序异常终止而又没有删除它的临时文件，文件可能遭受入侵者的袭击，然后读取这些数据信息。
• 输入的密码将不以明文形式进行显示，同时密码也不会被解码。
• 不同的应用程序的个人身份证不能相互使用。
• 个人身份证和密码长度等必须有设定的要求。
• 备份应该加密，恢复数据应考虑恢复过程的异常。

兼容性测试

• Android、iOS 版本的兼容性。
• 手机不同操作系统版本的支持。
• 手机不同厂家系统的支持。
• 手机不同尺寸的支持。
• 手机分辨率兼容性。
• 网络的兼容性：2G/3G/4G/5G/Wifi，弱网下、断网时。
• 不同浏览器兼容性。
• 与其他APP兼容性。

安装、卸载测试

• 生成 apk 文件在真机上可以安装及卸载。
• Android 手机端通过使用安装工具，如豌豆荚。

网络测试

• 外网测试主要实现模拟客户使用网络环境，检验客户端程序在实际网络环境中使用情况进行业务操作。
• 外网测试主要覆盖到 WiFi/2G/3G/4G/5G/wap、电信/移动/联通、所有可能的组合进行测试。
• 模拟信号屏蔽时候。
• 在高山、丘陵、火车上等特殊环境下进行全面测试。

接口测试

• Client 客户端和 Service 服务端的交互。
• Client 端的数据更新和 Service 端的数据是否一致。
• Client 端更新时断开。
• Client 端更新时，Service 端挂掉