1.web测试

1.1.功能测试

　　链接测试

　　　　测试点：

　　　　　　链接与页面对应：测试所有链接是否按指示的那样确实链接到了该链接的页面；

　　　　　　无空链接：测试所链接的页面是否存在；

　　　　　　没有孤立的页面：孤立页面是指没有链接指向该页面，只有知道正确的URL地址才能访问；

　　　　测试方法：

　　　　　　链接测试执行的时间一般在集成测试阶段，即在整个Web应用系统的所有页面开发完成后进行链接测试；

　　　　　　链接测试可以运行手工测试；也可以通过自动化测试工具测试；

　　　　　　手工测试方法：点击任何一个可能有链接的地方，看页面和链接是否对应，看是否有空链接，看是否存在孤立的页面；

　　　　测试工具：

　　　　　　Xenu Link Sleuth；

　　　　　　HTML Link Validator；

　　　　　　ACT；

　　　　　　Rational sitecheck；

　　　　　　Rational linkbot；

　　表单测试

　　　　测试点：

　　　　　　测试提交操作的完整性，以校验提交给服务器的信息的正确性；

　　Cookies测试

　　　　Cookies通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies访问了某一个应用系统时，Web服务器将发送关于用户的信息，把该信息以Cookies的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息

　　　　测试点：

　　　　　　Cookies是否起作用；

　　　　　　是否按预定的时间进行保存(Cookies保存的时间长度)；

　　　　　　刷新对Cookies有什么影响(登录一个新的用户)；

　　　　测试方法：

　　　　　　黑盒测试；

　　　　　　查看cookies的软件进行（初步的想法）；

　　　　测试工具：

　　　　　　IECookiesView v1.50；

　　　　　　Cookies Manager v1.1；

　　设计语言测试

　　　　测试点：

　　　　　　HTML的多个版本的验证(IE的多个版本,火狐等)；

　　　　　　不同的脚本语言，例如Java、JavaScript、 ActiveX、VBScript或Perl；

　　数据库测试

　　　　测试点：

　　　　　　数据一致性错误,主要是由于用户提交的表单信息不正确而造成的；

　　　　　　输出错误,主要是由于网络速度或程序设计问题等引起的；

1.2.性能测试

　　连接速度测试

　　　　测试点：

　　　　　　登入链接时间,页面刷新时间等；

　　负载测试

　　　　测试点：

　　　　　　在系统”满负荷”的情形下,测试系统是承受能力(能运行多长时间)；

　　压力测试

　　　　测试点：

　　　　　　获取系统正确运行的极限；

1.3.界面测试

　　导航测试

　　　　测试点：

　　　　　　是否易于导航；

　　　　　　导航是否直观；

　　　　　　Web系统的主要部分是否可通过主页存取；

　　　　　　Web系统是否需要站点地图、搜索引擎或其他的导航帮助；

　　图形测试

　　　　测试点：

　　　　　　要确保图形有明确的用途，图片或动画不要胡乱地堆在一起，以免浪费传输时间；

　　　　　　验证所有页面字体的风格是否一致；

　　　　　　背景颜色应该与字体颜色和前景颜色相搭配；

　　　　　　图片的大小和质量也是一个很重要的因素，一般采用JPG或GIF压缩；

　　内容测试

　　　　测试点：

　　　　　　内容测试用来检验Web应用系统提供信息的正确性、准确性和相关性；

　　整体界面测试

　　　　测试点：

　　　　　　当用户浏览Web应用系统时是否感到舒适，是否凭直觉就知道要找的信息在什么地方？；

　　　　　　整个Web应用系统的设计风格是否一致？；

1.4.兼容性测试

　　平台（操作系统）测试

　　　　测试点：

　　　　　　在Web系统发布之前，需要在各种操作系统下对Web系统进行兼容性测试；

　　　　　　市场上有很多不同的操作系统类型，最常见的有Windows、Unix、Macintosh、Linux等；

　　浏览器测试

　　　　测试点：

　　　　　　浏览器是Web客户端最核心的构件，来自不同厂商的浏览器对Java，、Javascrīpt、 ActiveX、 plug-ins或不同的HTML规格有不同的支持；

　　　　　　测试浏览器兼容性的一个方法是创建一个兼容性矩阵。在这个矩阵中，测试不同厂商、不同版本的浏览器对某些构件和设臵的适应性；

　　分辨率测试

　　　　测试点：

　　　　　　在不同分辨率下，界面控件是否能正常显示；

　　　　　　页面版式在 640×400、600×800 或 1024×768 的分辨率模式下是否显示正常? 字体是否太小以至于无法浏览? 或者是太大? 文本和图片是否对齐?；

1.5.安全测试

　　　　测试点：

　　　　　　用户登录；

　　　　　　Web应用系统是否有超时的限制；

　　　　　　为了保证Web应用系统的安全性，日志文件是至关重要的；

　　　　　　当使用了安全套接字时，还要测试加密是否正确，检查信息的完整性；

　　　　　　服务器端的脚本常常构成安全漏洞，要测试没有经过授权，就不能在服务器端放臵和编辑脚本的问题；

2.数据库测试

2.1.数据库测试分类

　　系统测试

　　　　数据库在初期设计中需要进行分析测试；

　　　　 –存储过程，视图，触发器，约束，规则等我们都需要进行需求的验证确保这些功能设计是符合需求的；

　　　　确认数据库设计文档和最终的数据库相同，当设计文档变化时我们同样要验证修改是否落实到数据库上；

　　　　 –数据库设计评审来实现；

　　集成测试

　　　　数据项的修改操作；

　　　　数据项的增加操作；

　　　　数据项的删除操作；

　　　　数据表增加满；

　　　　数据表删除空；

　　　　删除空表中的记录；

　　　　数据表的并发操作；

　　　　针对存储过程的接口测试；

　　　　结合业务逻辑做关联表的接口测试 ，需要对这些接口考虑采用等价类、边界值、错误猜测等方法进行测试；

　　单元测试

　　　　单元测试侧重于逻辑覆盖，数据库开发的单元测试相对简单；

　　　　 –语句覆盖；

　　　　 –通过走读方式；

　　功能测试

　　　　DBunit；

　　　　 –一款开源的数据库功能测试框架，可以使用类似与Junit的方式对数据库的基本操作进行白盒的单元测试，对输入输出进行校验；

　　　　QTP；

　　　　 –通过对对象的捕捉识别，我们可以通过QTP来模拟用户的操作流程，通过其中的校验方法或者结合数据库后台的监控对整个数据库中的数据进行测试。个人觉得比较偏向灰盒；

　　　　DataFactory；

　　　　 –一款优秀的数据库数据自动生成工具，通过它你可以轻松的生成任意结构数据库，对数据库进行填充，帮助你生成所需要的大量数据从而验证我们数据库中的功能是否正确。这是属于黑盒测试；

　　性能测试

　　　　–物理存储方面；

　　　　–逻辑设计方面；

　　　　–数据库的参数调整；

　　　　–SQL语句优化；

　　　　 数据库系统的SQL语句分析工具，分析得到数据库语句执行的瓶颈，从而优化SQL语句；

　　　　 Loadrunner；

　　　　 –通过对协议的编程来对数据库做压力测试；

　　　　 Swingbench；

　　　　 –专门针对oracle；

　　　　 oracle11g提供了real application test，提供数据库性能测试，分析系统的应用瓶颈；

　　安全测试

　　　　SQL 注入攻击 、跨站点脚本攻击、未经授权的用户访问；

　　　　 –所谓SQL注入（SQL Injection），就是利用程序员对用户输入数据的合法性检测不严或不检测的特点，故意从客户端提交特殊的代码，从而收集程序及服务器的信息，从而获取想得到的资料。通常别有用心者的目标是获取网站管理员的帐号和密码；

　　　　数据库强大的存储过程，黑客可以轻松的获得整个系统的权限；

　　系统测试

3.功能测试

　　添加

　　　　特：

　　　　 只添加主表；

　　　　 只添加从表；

　　　　 能够先选择主表，再在主表的基础上添加从表数据；

　　　　 不影响主表原有数据；

　　　　 一个从表数据同一时间只能添加到一个主表数据中；

　　　　 同时添加主从表；

　　　　 首先添加主表，接着提供添加从表数据的界面；

　　　　 从表添加完成后，提交主表，主从表数据成功保存；

　　　　 只保存从表添加，主表添加失败，本次操作失败；

　　　　公：

　　　　 必输项是否有必须输入的标记；

　　　　 能够成功添加；

　　　　 添加后每项数据核查正确；

　　　　 保存后跳转页面正确；

　　　　 如果是添加附件文件，能否正确上传附件文件；

　　　　 添加后能够使用本次添加的数据；

　　　　 添加后在相关查询中可以查询到；

　　删除

　　　　特：

　　　　 删除主表：

　　　　 主表未被其他地方引用，可以成功删除；

　　　　 主表被其他地方引用，不能删除，必须先删除引用，再删除主表；

　　　　 主表下有从表，删除主表，从表同时被删除或者主表下有从表，必须先删除从表才能删除主表；

　　　　 删除从表：

　　　　 从表未被其他地方引用，可以成功删除；

　　　　 删除后，不能使用本从表数据，但不影响主表数据使用；

　　　　 从表被其他地方引用后，不能删除，必须先删除引用，再删除从表；

　　　　 同时删除主从表：

　　　　 主表未被其他地方引用，可以同时成功删除主从表；

　　　　公：

　　　　 必须有“确定删除”的提示信息，给用户放弃破坏性操作的机会；

　　　　 是一般删除还是破坏性删除（彻底删除，从数据库中删除）；

　　　　 是否有相关的数据删除，如果有要确认该相关的数据也已经删除，并且在同一事务中完成；

　　　　 是否有删除约束；

　　　　 只有拥有相关权限的用户才能删除，是否按照权限删除；

　　　　 是否支持Ctrl、Shift多条删除、全部删除；

　　　　 删除空记录；

　　　　 是否支持全部删除；

　　修改

　　　　修改与添加相关需要考虑到修改的编辑框中可以输入哪些类型的数据、数据长度等等，另外还要考虑到以下内容；

　　　　能够修改哪些内容；

　　　　不能修改的地方应该为只读；

　　　　能够修改成功；

　　　　修改主表数据不影响从表数据；

　　　　修改从表数据不影响主表数据；

　　　　修改主从表数据后不影响已经引用的地方；

　　　　修改后在相关处查询为修改后的数据；

　　查询/浏览

　　　　查询功能相对简单，但体现了数据的流向与正确性，可以从以下方面考虑，注意可以使用正交排列法；

　　　　 支持全部查询；

　　　　 按照任意条件可以正确查询出数据；

　　　　 支持任意组合查询；

　　　　 因为各业务引起的数据变化，在查询中能够正确体现；

　　　　 查询结果准确；

　　　　 查询出的数据量大，有分页显示功能；

　　　　 下翻、上翻页正确；

　　　　 可以跳转到任意页；

　　　　 有查询结果说明，如本页多少条数据，共查询出多少条数据；

　　　　 分页的统计数字是否正确，共X页，第N页，共X条记录等；；

　　　　 对于主从表可以查询出主表数据和从表数据；

　　　　 支持模糊查询；

　　　　 支持精确查询；

　　　　 当查询的数据非常多的时候，性能有无问题；

　　　　 对于数据量比较大的表查询时，不容许无条件查询，避免性能问题的出现；

　　　　 查询数据是否正确；

4.功能测试

　　概念

　　　　业务测试是测试人员把系统各个模块串接起来运行、模拟真实用户实际的工作流程，满足用户需求定义的功能来进行测试的过程；

　　测试方法

　　　　 业务测试关注需求和用户；

　　　　 　　站在用户的角度：

　　　　　　　　 –测试人员最好能够全程参与整个开发过程，尤其是需求解决要及早介入到需求，多与客户沟通，真正理解用户手工的业务流程，尽量减少业务理解的偏差；

　　　　 　　重点关注整体业务和分业务：

　　　　 　　　　–在进行业务测试时，是在功能测试成功实施的基础上进行的测试，业务测试的工作重点应该是放在尽可能全面的收集模块需求、了解整体的业务流程、分析主体业务流程和重点业务流程等工作上。；

　　　　　　 现场客户：

　　　　　　　　 –现场客户随时提供对需求细节的指导。如果没有条件，可以定期的邀请用户参加项目例会或安排和用户交流等。另外在需求理解评审和测试设计评审会尽量邀请用户参与；

　　　　 设计业务用例；

　　　　　　 业务流程测试用例同样可以采用边界值和等价类划分的方法。；

　　　　 　　对于业务系统的测试需要考虑基础数据、业务数据。基础数据一般采用客户真实的数据，业务数据要符合实际的业务流程。；

　　　　 　　一般情况下每一个典型的业务操作就是一个业务流程；

　　　　 　　业务流程可以用场景法写，针对一个业务流程设计一个或者多个场景；

　　　　 　　业务流程无需覆盖到所有的功能，只要覆盖到用户的典型业务。业务是贯穿多个功能模块，不受到业务属于哪个功能模块的限制；

　　　　 　　在设计业务用例时，需要理清系统的业务流程，可以采用相关的辅助手段理清业务，例如画总体业务流程图以及分业务流程图等；

　　　　 测试执行；

　　　　　　 在系统测试每轮测试保持测试数据库都是完整的一套初始数据，在每次测试之前保证数据的原始状态；

　　　　　　 一般在版本比较稳定的情况下可以采用自动化工具录制业务流程测试脚本实现整个业务测试的多轮测试过程；

声明：本文部分内容可能来源或整理自网络，如有侵权，请联系删除