冒烟测试、回归测试、渗透测试、黑盒测试、白盒测试、灰盒测试 1、测试方案：写明将要如何进行测试的文档，包括测试计划、测试环境、测试数据、测试工具、测试方法、风险依赖等方面。 2、测试方案参考目录（可根据项目或产品需要适当删减） （1）功能测试、模块1、模块2、模块3、接口测试、测试内容 （2）包含系统的哪些模块哪些方面（功能、性能、数据）、测试范围、测试环境 、测试工具 、测试数据、测试方法 、测试人力资源安排、测试进度安排、测试输出 、风险分析 、硬件环境、软件环境、借助到的一些测试浏览器兼容性工具、自动化测试工具、性能测试工具 （3）黑盒测试、白盒测试、冒烟测试、验收测试、包含哪些文档、报告等、一般有：测试计划、测试方案、系统评测报告、缺陷报告等、系统上线后可能会出现的问题，一些现在尚未解决的bug，各种使用环境可能出现的问题等； （4）编写目的、读者对象、项目背景、测试目标、参考资料、概述 、测试计划 、集成测试用例 、系统测试用例 、性能测试 **一、立项后测试需要拿到的文档** 1、需求说明书 2、原型图（及UI图） 3、接口文档 4、数据库字典（表的数量、缓存机制） **二、需求评审** **三、用例编写（同时根据开发计划编写测试计划）** **用例功能类型** 所在就职部门将用例分成7类： 1、主流程：该模块实现的主要功能流程。 2、备选流：不一定完成执行一个功能，而是终止了流程。 3、异常流：由于某些异常原因，使流程的功能无法实现。 4、业务规则：必填项，强制的要求。 5、正常类：返回功能、必填项输入范围、页面按钮的切换等。 6、异常类：网络异常、返回异常等。 7、界面检查：针对每个页面的样式及内容检查。 **测试用例的编写方法** 1、等价类划分 2、边界值分析法 3、错误推断法 4、因果分析法 5、场景法 **五、测试执行** **showcase测试：**测试到开发的电脑上进行，主要执行一下关键测试用例、流程用例，由开发操作，测试人员一起查看。showcase不通过，则打回，邮件发出。 **冒烟测试：**showcase测试通过后，提交到测试，由测试人员开始大量跑关键测试用例。若针对某个模块跑用例时，出现较多问题，则也可重新打回给开发。冒烟测试报告邮件如下字段：测试模块 是否通过 不通过原因 测试详情 备注 邮件描述大致如下：以下是截止到某个日期，已提交的功能冒烟测试结果，都不通过，详情如下： ps:冒烟测试不通过的原因基本上都是。。。。。，麻烦大家相互配合，早点修复提测，谢谢~ **功能测试：**功能测试在手工测试中是主要的阶段，这个阶段主要是全量跑测试用例，提交bug到缺陷管理工具。 1、表单测试： a、表单数据的字段、完整性及表单输入框的长度限制问题 b、一些常理性逻辑验证，比如：出生日期和职业，工作年限是否恰当，所在地省份城市区域间的匹配等，如果设定使用默认值，也需要测试。 2、导航测试： 导航测试，就是在不同的页面跳转之间，或者按钮、对话框、列表以及窗口等，通过考虑这些因素去判断一个应用是否易于导航：是否直观？系统的主要模块是否可以通过主页访问或者到达？站点是否需要站内地图或者搜索引擎等其他帮助？web系统导航的另外一个重点就是页面结构、导航、菜单、风格等是否一致，确保用户可以凭借直觉或者简单的判断就可以找到自己想要的内容。（参考博客[http://www.cnblogs.com/imyalost/p/5622867.html](http://www.cnblogs.com/imyalost/p/5622867.html)） 3、UI测试： 也可以理解为UI测试，其中包括图片、动画、边框、颜色、字体、背景、按钮等等。 注： 其中要考虑的几个重点，我做了一个大概的总结： a、图片要有明确的用途，代表；图片尺寸尽量小，一般采用JPG或者GIF压缩（即规格大小的限制） b、页面整体风格是否和系统的用途一致 c、背景颜色，字体，搭配是否合理 4、内容测试： 这个主要用来检测web系统提供信息的准确性、相关性。 比如：商品的价格，文字描述；信息的准确性，是否有拼写错误；（这点比较容易忽略，需要多注意）信息的相关性，比如很多网站的“相关文章列表，视频列表等” 5、整体界面测试 a、 这个也就是我们常说的用户体验。用户浏览时是否感觉舒适，整体风格等等 b、建议一般做一个类似问卷调查的形式，来判定用户的反馈信息，最好有最终用户的参与，可参考类似的笔记哦啊普遍的系统风格是怎样的，结合实际来考虑本测试系统的风格 6、链接测试（平时在测试过程中并不关注，而是在权限分配的安全测试中比较注重，主要是不同权限的人分享的链接是否能正确过滤，保证安全） 7、输入框测试（粘贴博客[http://www.cnblogs.com/imyalost/p/5622867.html](http://www.cnblogs.com/imyalost/p/5622867.html)） 在web测试中，我们经常遇到这种输入框的测试，输入框测试看似简单，实际上包含了很多的测试基本的方法，思考逻辑，下面就是我总结出来的一些注意点： 1）验证输入输出信息的一致性 2）输入框前面的文字提示是否正确 3）对特殊字符的处理、识别：单双引号，括号，逗号、分号等等，以及大小写状态，半角全角状态下的情况 4）输入框的大小、长度、边框等 5）不同字符的输入，以及字符组合情况的处理（数字+字母+字符等） 6）对空格、tab换行键的处理机制 7）密码输入框字符星号或者其他星号的转行，加密 8）输入框输入字符长度是否有限制 9）字符本身显示的颜色，规格等 10）有些输入框需要加以限制，如输错，是否有提示？提示是否简单合理？ 11）输入状态，某种情况下输入框出于不可编辑，当再次处于编辑状态，输入框的输入状态是否有变化？ 12）输入类型：是否允许复制黏贴剪切等输入操作 13）关键字是否支持通配符，以及关键字的搜索能力，敏感字等情况 14）输入框输入空格的情况 15）比如登陆注册，各项输入条件的判定：是否输入，输入是否正确等 8、用户权限测试（粘贴博客[http://www.cnblogs.com/imyalost/p/5622867.html](http://www.cnblogs.com/imyalost/p/5622867.html)） 用户权限，顾名思义，就是该账号拥有哪些执行操作的权利 1）给某账号赋予权限后，登陆该账号，查看是否拥有已赋予的权限，以及权限设置是否正确（权限是否超过或者不足） 2）删除或修改已经登陆并且正在执行操作的账号权限，程序能否正确处理，验证 3）重新注册系统变更登陆身份后再登陆，程序能否正确执行，之前所拥有的权限能否继续使用 4）在用工作分配或者角色管理情况下，删除包含用户的工作组或者角色，程序能否正确处理 5）不同权限账号登陆同一个系统，权限范围是否正确 6）能否给信息为空、长用户名的账号添加权限 7）是否允许删除系统管理员或者修改管理员权限？删除或者修改后的实际情况 8）已登录的用户能否修改或者删除自己或者他人的权限，信息 9）添加用户（有编号或者标识），不同用户名标识的组合情况下，权限能否处理正确 10）修改用户权限或者信息后，对其他模块是否有影响 11）如果修改用户信息为和已存在的其他用户信息相同，能否修改成功？是否有对应提示？ 12）修改某些设置，是否会对与该账号权限相同或者高于/低于该账号的其他账号的权限造成影响 13）同一用户是否可以同时属于其他组，各个组的权限能否交叉？ **回归测试：** 回归测试书要是根据在测试执行过程中记录的bug及执行失败的用例来进行的，根据记录的bug进行验证是否已经修改更新好，必要时，根据bug量的多少来评估是否需要重新跑一下系统的流程。 **兼容性测试：**（参考博客[http://www.cnblogs.com/imyalost/p/5622867.html](http://www.cnblogs.com/imyalost/p/5622867.html)） a、平台兼容 在有很多的操作系统，比如Windows、Unix、Linux、macintosh等；用户使用哪个系统取决于用户，因此，系统兼容测试就很有必要了。 b、浏览器兼容 浏览器是web客户端最核心的组件，不同的浏览器，对Java，JavaScript，css或者HTML的规格都有不同的支持； 另外，采用的框架和结构风格在不同浏览器中也存在不同的显示甚至不显示，不同的浏览器对安全性的设置也是不同的。 测试浏览器兼容，有个方法就是创建一个兼容性矩阵，来测试不同厂商不同版本的浏览器兼容。 比如测试IE浏览器，可以通过一个叫做IEtester的工具来测试兼容，或者可以通过F12控制台来切换浏览器版本来测试兼容以前一些前端元素的显示等 鉴于国内市场浏览器很多，比如360、搜狗，搜狐、QQ浏览器等，这些本土的浏览器基本都采用的IE浏览器内核的双核配置 **安全测试：** 安全测试的主要区域有以下几点： a、现在很多web应用系统都采用先注册后登录的方式，因此，测试用户名和密码的有效无效性，注意大小写敏感，次数限制，是否可以不登录而浏览某些页面等 b、是否有超时限制，链接分享，cookie劫持 c、测试用户操作时相关信息是否写入了日志文件、是否可追踪等 d、如果使用了安全套字，需要测试加密是否正确，加密前后的信息完整性，正确性 e、没有经过授权，是否可以在服务器端或者前端放置和编辑脚本的问题 f、输入框的SQL注入验证