Web测试

（整理自网络）

项目的测试流程大只包含的几个阶段：立项、需求评审、用例评审、测试执行、测试报告文档

1、立项后测试须要拿到的文档

一、需求说明书

二、原型图（及UI图）

三、接口文档

四、数据库字典（表的数量、缓存机制）

2、需求评审

参加人员：开发、测试及需求人员，由需求人员主持讲解。

为了会议的有效举行，测试及开发人员须要在会议开始以前熟悉需求文档及原型，将有疑问 的点标注出来在会议中一一确认，对不明确的点要督促开发及需求一并关注，对不能立马获得确定回复的点记录在一块儿，会议结束后，邮件整理好发出给各位参与的人员。

在项目可控的进度中，需求评审时必要的环节。固然，有些比较小的项目会忽略此阶段，我的认为这是很是有必要的环节，这不但减小了后期开发、测试、需求人员的意见分歧，保证项目的进度的必要手段。

3、用例编写（同时根据开发计划编写测试计划）

用例功能类型

所在就任部门将用例分红7类：

一、主流程：该模块实现的主要功能流程。

二、备选流：不必定完成执行一个功能，而是终止了流程。

三、异常流：因为某些异常缘由，使流程的功能没法实现。

四、业务规则：必填项，强制的要求。

五、正常类：返回功能、必填项输入范围、页面按钮的切换等。

六、异常类：网络异常、返回异常等。

七、界面检查：针对每一个页面的样式及内容检查。

注：几个大类中主流程、正常类、异常类、和界面检查四个大类使用的比较多，一个项目不须要涵盖全部的用例类别，只须要根据所在项目的实际状况来进行测试用例的分类便可。

编写用例可在TestLink及excel上进行，通常会在TestLink上进行，小项目会比较习惯用excel进行，excel记录测试用例的字段有：

用例编号、功能模块、功能类型、用例等级、用例描述、前置条件、数据、测试步骤、预期结果、客户端、执行结果、备注、设计人、执行人等

用例编写注意点：

一、尽量结合用例设计方法设计测试用例

二、不要只根据需求文档明确标出的需求编写用例，还须要多考虑一些衍生的场景；

三、用例编写前，先画出整个功能的煎药流程图；

四、用例描述简洁且带有结果，不要重复赘述；

五、用例步骤和预期结果要一致，且一个步骤对应一个预期结果。

测试用例的编写方法

一、等价类划分

二、边界值分析法

三、错误推断法

四、因果分析法

五、场景法

4、用例评审

参与人员：开发、测试、需求人员、项目经理，由测试人员主导。

此环节在开发完成功能以前进行，根据评审时提的点进行用例完善，完善后邮件发给参与人员。

在项目组中，更多状况下测试比开发会更了解需求，专业决定咱们对需求的理解是确定更接近客户的，咱们的对需求理解后的输出产物是测试用例，某种意义上讲用例是对需求细化的一种。 而开发对需求理解会更偏向于功能实现，产物就是程序。因此开发、测试常常会存在需求理解不一致的状况，开发也不会那么细致的去理解需求，这点相信全部的项目经理和需求分析都是有共鸣的：
咱们作测试用例评审的做用有但不局限于如下3点：
一、统一开发、测试、需求三方对需求的理解
二、帮组开发更细致的去理解需求、同时养成看需求的习惯
三、需求分析人员在必定程度上对需求的理解也是有盲点的，经过评审能够挖出这些盲点（需求评审的做用也是同样）
四、测试人员的能力和经验不同，全部用例也会有差别性，经过评审能够指出咱们遗漏的场景，从而能更好的保障我们的项目质量
五、在用例评审时，不少交互设计上的问题，先后台交互的问题等都会暴露
六、若是测试用例在开发完成前进行评审，不少时候开发人员即便不去看需求说明书，只要他认真的参加了用例评审会，基本上也不会出现遗漏需求，需求实现误差太大的状况了.由于你要去每一个开发人员那么仔细的去看需求，短期内是不太可能的。用例评审是这个过渡期的桥梁。

通常可根据计划时间完成用例编写，中间会预留1天给他们看需求。在评审每个模块的用例以前，会明确点名这几我的要注意，在评审的过程当中，问开发一些问题,不是只单纯的讲用例,他们能够不看需求，可是我会提问一下,们要同时提高开发人员的参与感。

5、测试执行

showcase测试：
测试到开发的电脑上进行，主要执行一下关键测试用例、流程用例，由开发操做，测试人员一块儿查看。showcase不经过，则打回，邮件发出。

冒烟测试：
showcase测试经过后，提交到测试，由测试人员开始大量跑关键测试用例。若针对某个模块跑用例时，出现较多问题，则也可从新打回给开发。冒烟测试报告邮件以下字段：测试模块      是否经过   不经过缘由    测试详情    备注

邮件描述大体以下：如下是截止到某个日期，已提交的功能冒烟测试结果，都不经过，详情以下：

ps:冒烟测试不经过的缘由基本上都是。。。。。，麻烦你们相互配合，早点修复提测，谢谢~

功能测试：
功能测试在手工测试中是主要的阶段，这个阶段主要是全量跑测试用例，提交bug到缺陷管理工具。

一、表单测试：

a、表单数据的字段、完整性及表单输入框的长度限制问题

b、一些常理性逻辑验证，好比：出生日期和职业，工做年限是否恰当，所在地省份城市区域间的匹配等，若是设定使用默认值，也须要测试。

二、导航测试：

导航测试，就是在不一样的页面跳转之间，或者按钮、对话框、列表以及窗口等，经过考虑这些因素去判断一个应用是否易于导航：是否直观？系统的主要模块是否能够经过主页访问或者到达？站点是否须要站内地图或者搜索引擎等其余帮助？web系统导航的另一个重点就是页面结构、导航、菜单、风格等是否一致，确保用户能够凭借直觉或者简单的判断就能够找到本身想要的内容。（参考博客http://www.cnblogs.com/imyalost/p/5622867.html）

三、UI测试：

 也能够理解为UI测试，其中包括图片、动画、边框、颜色、字体、背景、按钮等等。

注： 其中要考虑的几个重点，我作了一个大概的总结：

a、图片要有明确的用途，表明；图片尺寸尽可能小，通常采用JPG或者GIF压缩（即规格大小的限制）

 b、页面总体风格是否和系统的用途一致

 c、背景颜色，字体，搭配是否合理

四、内容测试：

这个主要用来检测web系统提供信息的准确性、相关性。

好比：商品的价格，文字描述；信息的准确性，是否有拼写错误；（这点比较容易忽略，须要多注意）信息的相关性，好比不少网站的“相关文章列表，视频列表等”

五、总体界面测试

a、 这个也就是咱们常说的用户体验。用户浏览时是否感受温馨，总体风格等等

b、建议通常作一个相似问卷调查的形式，来断定用户的反馈信息，最好有最终用户的参与，可参考相似的笔记哦啊广泛的系统风格是怎样的，结合实际来考虑本测试系统的风格

六、连接测试（平时在测试过程当中并不关注，而是在权限分配的安全测试中比较注重，主要是不一样权限的人分享的连接是否能正确过滤，保证安全）

七、输入框测试（粘贴博客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）好比登录注册，各项输入条件的断定：是否输入，输入是否正确等

八、用户权限测试（粘贴博客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）

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注入验证

6、测试报告及操做手册

测试报告每一个公司的使用模板可能不尽相同，可是重点都是反映测试结果及测试中出现的bug分配模块，还要关注bug解决的状态，只要根据模板中的须要去进行统计便可。

操做手册主要是写给使用该系统的人员看的，要求是具体详细，什么角色什么模块可进行什么操做的描述要清晰，一步一步配上截图和文字。