推荐：想了解一个项目完整测试流程，看这篇文章就OK了

       写在前面：本文来自真实企业测试人员的工作总结，用一个项目的进行流程为线索，记录每个阶段测试包含的内容及关注点。

<ignore_js_op>

　　项目的测试流程大只包含的几个阶段：立项、需求评审、用例评审、测试执行、测试报告文档
　　一、立项后测试需要拿到的文档
　　1、需求说明书
　　2、原型图（及UI图）
　　3、接口文档
　　4、数据库字典（表的数量、缓存机制）

　　二、需求评审
　　参加人员：开发、测试及需求人员，由需求人员主持讲解。
　　为了会议的有效举行，测试及开发人员需要在会议开始之前熟悉需求文档及原型，将有疑问 的点标注出来在会议中一一确认，对不明确的点要督促开发及需求一并关注，对不能立马得到肯定回复的点记录在一起，会议结束后，邮件整理好发出给各位参与的人员。
　　在项目可控的进度中，需求评审时必要的环节。当然，有些比较小的项目会忽略此阶段，个人认为这是非常有必要的环节，这不但减少了后期开发、测试、需求人员的意见分歧，保证项目的进度的必要手段。

　　三、用例编写（同时根据开发计划编写测试计划）
　　用例功能类型
　　所在就职部门将用例分成7类：
　　1、主流程：该模块实现的主要功能流程。
　　2、备选流：不一定完成执行一个功能，而是终止了流程。
　　3、异常流：由于某些异常原因，使流程的功能无法实现。
　　4、业务规则：必填项，强制的要求。
　　5、正常类：返回功能、必填项输入范围、页面按钮的切换等。
　　6、异常类：网络异常、返回异常等。
　　7、界面检查：针对每个页面的样式及内容检查。
　　注：几个大类中主流程、正常类、异常类、和界面检查四个大类使用的比较多，一个项目不需要涵盖所有的用例类别，只需要根据所在项目的实际情况来进行测试用例的分类即可。
　　编写用例可在TestLink及excel上进行，一般会在TestLink上进行，小项目会比较习惯用excel进行，excel记录测试用例的字段有：
　　用例编号、功能模块、功能类型、用例等级、用例描述、前置条件、数据、测试步骤、预期结果、客户端、执行结果、备注、设计人、执行人等
　　用例编写注意点：
　　1、尽可能结合用例设计方法设计测试用例
　　2、不要只根据需求文档明确标出的需求编写用例，还需要多考虑一些衍生的场景；
　　3、用例编写前，先画出整个功能的简要流程图；
　　4、用例描述简洁且带有结果，不要重复赘述；
　　5、用例步骤和预期结果要一致，且一个步骤对应一个预期结果。
　　测试用例的编写方法
　　1、等价类划分
　　2、边界值分析法
　　3、错误推断法
　　4、因果分析法
　　5、场景法

　　四、用例评审
　　参与人员：开发、测试、需求人员、项目经理，由测试人员主导。
　　此环节在开发完成功能之前进行，根据评审时提的点进行用例完善，完善后邮件发给参与人员。
　　在项目组中，更多情况下测试比开发会更了解需求，专业决定我们对需求的理解是肯定更接近客户的，我们的对需求理解后的输出产物是测试用例，某种意义上讲用例是对需求细化的一种。 而开发对需求理解会更偏向于功能实现，产物就是程序。所以开发、测试经常会存在需求理解不一致的情况，开发也不会那么细致的去理解需求，这点相信所有的项目经理和需求分析都是有共鸣的：
　　我们做测试用例评审的作用有但不局限于以下3点：
　　1、统一开发、测试、需求三方对需求的理解
　　2、帮组开发更细致的去理解需求、同时养成看需求的习惯
　　3、需求分析人员在一定程度上对需求的理解也是有盲点的，通过评审可以挖出这些盲点（需求评审的作用也是一样）
　　4、测试人员的能力和经验不一样，所有用例也会有差异性，通过评审可以指出我们遗漏的场景，从而能更好的保障咱们的项目质量
　　5、在用例评审时，很多交互设计上的问题，前后台交互的问题等都会暴露
　　6、如果测试用例在开发完成前进行评审，很多时候开发人员即使不去看需求说明书，只要他认真的参加了用例评审会，基本上也不会出现遗漏需求，需求实现偏差太大的情况了.因为你要去每个开发人员那么仔细的去看需求，短时间内是不太可能的。用例评审是这个过渡期的桥梁。
　　一般可根据计划时间完成用例编写，中间会预留1天给他们看需求。在评审每一个模块的用例之前，会明确点名这几个人要注意，在评审的过程中，问开发一些问题,不是只单纯的讲用例,他们可以不看需求，但是我会提问一下,们要同时提升开发人员的参与感。

　　五、测试执行
　　showcase测试：
　　测试到开发的电脑上进行，主要执行一下关键测试用例、流程用例，由开发操作，测试人员一起查看。showcase不通过，则打回，邮件发出。
　　冒烟测试：
　　showcase测试通过后，提交到测试，由测试人员开始大量跑关键测试用例。若针对某个模块跑用例时，出现较多问题，则也可重新打回给开发。冒烟测试报告邮件如下字段：测试模块      是否通过   不通过原因    测试详情    备注
　　邮件描述大致如下：以下是截止到某个日期，已提交的功能冒烟测试结果，都不通过，详情如下：
　　ps:冒烟测试不通过的原因基本上都是。。。。。，麻烦大家相互配合，早点修复提测，谢谢~
　　功能测试：
　　功能测试在手工测试中是主要的阶段，这个阶段主要是全量跑测试用例，提交bug到缺陷管理工具。
　　1、表单测试：
　　a、表单数据的字段、完整性及表单输入框的长度限制问题
　　b、一些常理性逻辑验证，比如：出生日期和职业，工作年限是否恰当，所在地省份城市区域间的匹配等，如果设定使用默认值，也需要测试。
　　2、导航测试：
　　导航测试，就是在不同的页面跳转之间，或者按钮、对话框、列表以及窗口等，通过考虑这些因素去判断一个应用是否易于导航：是否直观？系统的主要模块是否可以通过主页访问或者到达？站点是否需要站内地图或者搜索引擎等其他帮助？web系统导航的另外一个重点就是页面结构、导航、菜单、风格等是否一致，确保用户可以凭借直觉或者简单的判断就可以找到自己想要的内容。
　　3、UI测试：
　　也可以理解为UI测试，其中包括图片、动画、边框、颜色、字体、背景、按钮等等。
　　注： 其中要考虑的几个重点，我做了一个大概的总结：
　　a、图片要有明确的用途，代表；图片尺寸尽量小，一般采用JPG或者GIF压缩（即规格大小的限制）
　　b、页面整体风格是否和系统的用途一致
　　c、背景颜色，字体，搭配是否合理
　　4、内容测试：
　　这个主要用来检测web系统提供信息的准确性、相关性。
　　比如：商品的价格，文字描述；信息的准确性，是否有拼写错误；（这点比较容易忽略，需要多注意）信息的相关性，比如很多网站的“相关文章列表，视频列表等”
　　5、整体界面测试
　　a、 这个也就是我们常说的用户体验。用户浏览时是否感觉舒适，整体风格等等
　　b、建议一般做一个类似问卷调查的形式，来判定用户的反馈信息，最好有最终用户的参与，可参考类似的笔记哦啊普遍的系统风格是怎样的，结合实际来考虑本测试系统的风格

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

　　7、输入框测试
　　在web测试中，我们经常遇到这种输入框的测试，输入框测试看似简单，实际上包含了很多的测试基本的方法，思考逻辑，下面就是我总结出来的一些注意点：
　　1）验证输入输出信息的一致性
　　2）输入框前面的文字提示是否正确
　　3）对特殊字符的处理、识别：单双引号，括号，逗号、分号等等，以及大小写状态，半角全角状态下的情况
　　4）输入框的大小、长度、边框等
　　5）不同字符的输入，以及字符组合情况的处理（数字+字母+字符等）
　　6）对空格、tab换行键的处理机制
　　7）密码输入框字符星号或者其他星号的转行，加密
　　8）输入框输入字符长度是否有限制
　　9）字符本身显示的颜色，规格等
　　10）有些输入框需要加以限制，如输错，是否有提示？提示是否简单合理？
　　11）输入状态，某种情况下输入框出于不可编辑，当再次处于编辑状态，输入框的输入状态是否有变化？
　　12）输入类型：是否允许复制黏贴剪切等输入操作
　　13）关键字是否支持通配符，以及关键字的搜索能力，敏感字等情况
　　14）输入框输入空格的情况
　　15）比如登陆注册，各项输入条件的判定：是否输入，输入是否正确等

　   用户权限测试
　　用户权限，顾名思义，就是该账号拥有哪些执行操作的权利
　　1）给某账号赋予权限后，登陆该账号，查看是否拥有已赋予的权限，以及权限设置是否正确（权限是否超过或者不足）
　　2）删除或修改已经登陆并且正在执行操作的账号权限，程序能否正确处理，验证
　　3）重新注册系统变更登陆身份后再登陆，程序能否正确执行，之前所拥有的权限能否继续使用
　　4）在用工作分配或者角色管理情况下，删除包含用户的工作组或者角色，程序能否正确处理
　　5）不同权限账号登陆同一个系统，权限范围是否正确
　　6）能否给信息为空、长用户名的账号添加权限
　　7）是否允许删除系统管理员或者修改管理员权限？删除或者修改后的实际情况
　　8）已登录的用户能否修改或者删除自己或者他人的权限，信息
　　9）添加用户（有编号或者标识），不同用户名标识的组合情况下，权限能否处理正确
　　10）修改用户权限或者信息后，对其他模块是否有影响
　　11）如果修改用户信息为和已存在的其他用户信息相同，能否修改成功？是否有对应提示？
　　12）修改某些设置，是否会对与该账号权限相同或者高于/低于该账号的其他账号的权限造成影响
　　13）同一用户是否可以同时属于其他组，各个组的权限能否交叉？

       回归测试
　　回归测试书要是根据在测试执行过程中记录的bug及执行失败的用例来进行的，根据记录的bug进行验证是否已经修改更新好，必要时，根据bug量的多少来评估是否需要重新跑一下系统的流程。

　　兼容性测试
　　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注入验证

　　六、测试报告及操作手册
　　测试报告每个公司的使用模板可能不尽相同，但是重点都是反映测试结果及测试中出现的bug分配模块，还要关注bug解决的状态，只要根据模板中的需要去进行统计即可。
　　操作手册主要是写给使用该系统的人员看的，要求是具体详细，什么角色什么模块可进行什么操作的描述要清晰，一步一步配上截图和文字。