Web 测试概述
功能测试
功能测试指根据产品特性和设计需求，验证该产品的特性和行为是否满足设计需求。
功能测试常见的步骤有：
- 根据需求来细分功能点；
- 根据功能点来派生测试需求；
- 根据测试需求设计功能测试用例；
- 逐项执行功能测试用例验证产品。
功能测试在不同的用户界面类型上会有所不同。主流的用户界面类型包括以命令行为首的非图形化用户界面，和以桌面、可触控移动设备和 Web 为主的图形化用户界面。
功能测试的类型
- 正确性：产品功能是否与需求和设计文档一致。
- 可靠性：用户交互是否引发软件崩溃和其他异常。
- 易用性：软件产品完成特定任务的难易程度。
例：飞机票务系统
例如，我们现在需要验证一个机票预订系统，我们首先要根据需求来细分功能点。然后选取一个功能点，比如单程国内机票预订，由此我们可以派生出测试需求如下：
- 验证有直飞航班的预订功能；
- 验证无直飞航班的预订功能，分为有联程和无联程两种情况；
- 单人预订和多人预订的功能；
- 有票和无票的情况；
- ......
测试需求应当尽量细化，但应该保证落点在具体的功能点上。然后我们可以根据这些测试需求设计功能测试用例，验证产品。
性能测试
性能测试是验证产品的性能在特定负载和环境条件下使用是否满足性能指标，在此基础上发现系统存在的性能瓶颈，优化系统。
对于服务端的性能通常采用 CPU 和内存的使用率来度量，客户端性能通常根据系统处理特定用户请求的响应时间来度量。
响应时间
响应时间指系统对请求作出响应所需要的时间。服务端响应时间指从请求发出开始到客户端接受到最后一个字节数据所消耗的时间，客户端响应时间是指客户端收到响应数据后呈现给用户所消耗的时间。
并发用户数
并发用户数指可以同时处理的最大用户请求数量。并发用户数取决于测试对象的目标业务场景，基于场景计算并发用户数。并发用户数与同时在线数存在区别。
吞吐量
吞吐量是指系统在单位时间内处理的请求数量。吞吐量是性能测试的一个重要指标，它可以反映系统的处理能力。吞吐量是一个综合的指标，它受到并发用户数、响应时间、网络带宽等因素的影响。
性能计数器
性能计数器是描述系统性能（一般是服务器端）的一些数据指标，例如 CPU 和内存占用率，上下行传输速率等。
负载测试
负载测试用于验证系统在某些负载情况下的行为，主要有两种方式：直接到达负载数和逐步增加负载数。
压力测试
压力测试是评估应用系统处于或超过预期负载时的行为。压力测试关注的重点更多放在极限情况下可能出现的漏洞，如同步问题和内存泄漏等。系统性能的下降是可接受的，但是不应该发生崩溃。
此外，压力测试还可以发现系统崩溃的临界点，从而发现系统中的薄弱环节。
Web 测试方法
Web 测试方法种类繁多且较为相近，类似 CheckList，主要包括（了解即可，必要时可查表）：
Web 测试方法
- 功能相关性：删除/增加一项会不会对其他项产生影响（如较长数据）。
- 数据相关性：如果某个列表的数据项依赖于其他模块中的数据，需要检查。
- 检查按钮的功能是否正确：如新建、编辑、删除、关闭、返回、保存、导入，上一页，下一页，页面跳转，重置等功能是否正确。
- 字符串长度检查：输入超出需求所说明的字符串长度的内容，看系统是否检查字符串长度。
- 字符类型检查：在应该输入指定类型的内容的地方输入其他类型的内容(如在应该输入整型的地方输入其他字符类型)，看系统是否检查字符类型。
- 标点符号检查：输入内容包括各种标点符号，特别是空格，各种引号，回车键。看系统处理是否正确。
- 特殊字符检查：输入特殊符号，如@、#、$、%、!等，看系统处理是否正确。
- 中文字符处理：在可以输入中、英文的系统输入中文，看会否出现乱码或出错。
- 检查信息的完整性：在查看信息和更新信息时，查看所填写的信息是不是全部更新，更新信息和添加信息是否一致。
- 信息重复：输入重复的唯一信息，看系统是否检查。
- 检查删除功能
- 检查添加和修改是否一致：例如添加要求必填的项，修改也应该必填。
- 检查修改重名：修改时把不能重名的项改为已存在的内容。
- 重复提交表单：一条已经成功提交的纪录，返回后再提交，看看系统是否做了处理。
- 检查多次使用返回键的情况：
- 搜索检查：有搜索功能的地方输入系统存在和不存在的内容，看搜索结果是否正确。
- 输入信息位置：在光标停留的地方输入信息时，光标和所输入的信息会否跳到别的地方。
- 上传下载文件检查：检测上传文件是否能打开，下载文件是否正确。以及其他格式要求和大小限制。
- 必填项检查
- 快捷键检查
- 回车键检查
- 刷新键检查
- 回退键检查
- 直接URL链接检查：如果系统安全性设计的不好，直接输入各功能页面的URL地址，很有可能会正常打开页面。
- 空格检查：在输入信息项中，输入一个或连串空格，查看系统如何处理。
- 输入法半角全角检查
- 密码检查：密码尽可能地长，尝试使用
uvwxyz等一些码值较大的字符作为密码。 - 用户检查：用户是否越权。
- 系统数据检查
- 系统可恢复性检查：以各种方式把系统搞瘫，测试系统是否可正常迅速恢复。
- 确认提示检查
- 数据注入检查：防止
SQL注入。 - 刷新检查：检测刷新功能对系统或应用造成的影响(白屏)，检查控件是否回归默认初始值，检查是否对系统的性能产生较大影响(如每次刷新都连接数据库查询等)。
- 事务检查：对于事务性操作，断开网络或关闭程序来中断操作，事务是否回滚。
- 时间日期检查
- 多浏览器验证
- 安装测试
- 文档测试
- 测试数据检查：事实告诉我们，测试数据比代码更有可能是错的，因此，当测试结果显示有错误发生的时候，怀疑代码错误前要先对测试数据检查一遍。
- “请让我的机器来运行”
- 异步调用
- 脚本错误
探索式测试方法
探索式测试是一种帮助测试人员在需求不完善的情况下尽早发现更多软件质量风险的测试手段。
目前，缺陷的检测有两种方式：自动化测试和手工测试。自动化测试的坏处在于代码维护成本较高，并且测试程序也有可能有缺陷。手工测试的坏处在于需要手脑并用，工匠（专家）模式，可借鉴的经验较少。基于以上的缺点，诞生了手工测试的技术探索式测试。
整体上来说，探索式测试是一种测试风格和思维，它强调测试人员的主观能动性和过程的规范性。它精心策划以防万一，同时留有发挥空间，让测试人员随机应变。
探索式测试的指导方法
- 局部探索式测试法：小范围的测试，比如一个小型的对话框。在运行任何一个测试用例之前都应当制定许多细微的战术层面决定。
- 全局探索式测试法：以漫游的方式来进行测试。可以将测试比作游客，对各个区块如商业区（热门区域）、旅馆区（长时间运行的服务）等进行测试。核心的思想是对不同的模块进行分类，施加不同的探索式测试方法。
- 混合探索式测试法：把探索式测试和使用脚本的手工测试合并起来。主要靠正式的脚本为探索式测试设立一个明确的框架范围。
局部探索式测试
测试人员在局部探索式测试中了解各种可以变化的东西，就可以更好的进行探索式测试。局部探索性测试从用户输入、状态、代码路径、用户数据、运行环境五个方面考虑软件的变化。一般来说，局部探索式测试的规模不会过大。