现在再给你个测试任务，你会怎么测试？
撇开自动化测试、性能测试，从功能测试的角度，来阐述下自己的测试过程。
一、测试思路构建：新的任务分配到手中，可能只是一个简单的bug，也可能是一个完整新构建项目。首先要读懂需求所需、业务想要。相关的需求文档当然要仔仔细细的看一遍甚至多遍、把涉及的点面理解到位。我觉得在这里要做到以下几点：
<1>，分块包括状态和页面。把一个系统中的主要功能所有页面分块管理，比如如果是购物系统，需要明白设计点对前后流程的影响，从加入收藏、加入购物车、提交待结算、提交待结算删除订单、结算完成、结算完成删除订单等各个状态值。理清楚各个状态值非常的重要，通常看到一个内容框的值及其状态在制作页面、提交页面、查看页面等都不同，防止遗漏，各个场景都需进行建立相应的测试用例及验证思路。
<2>，找线（有始有终）。从开始到完成，我们需要有始有终。什么意思呢，比如OA系统管理中的请假管理，如果请假人提出请假管理，那么其领导再审批得过程中，可以同意其审批申请，也可以不同意其请假申请，但是，不管同意不同意，我们需要把流程节点回归到请假人初，让请假人知悉这个结果。该任务从请假人处新建到请假人收到通知办结，就是一个有是有终的线。当然负责的业务有流程中不会只有一条线，所以在这里我们就需要把所有的线分离出来，将来做一个单独的业务流程测试。
<3>，估量测试时间，有经验的测试在这里就能够根据业务流程和业务功能等不同的复杂度大概估计测试时间，其实这个非常重要，比如一个项目有三十天的时间测试，那么你就不能三十天都在测试，你最多有二十天的测试时间来保证能覆盖到整个项目的70%-80%的bug，还有十天的冷静期。这十天时间，你可以转换思路，从不同的角度来测试项目，比如再次翻看相关详细设计需求文档，查看数据库、跟踪日志，或者可以再次从整体思维能力看一遍数据库。这些会帮助你把项目覆盖度提高到90%以上。
整体思路构建的好处可以很好的解决我们的测试时间，从整体到局部，再从局部到整体，将分析到的内容罗列其中，包括其中。就能很好地完成测试工作。
二、测试方法分析：根据不同的项目，分解不同的测试方法，项目中常用的测试方法分析：
<1>，顺序测试：顾名思义就是按照顺序，一个页面从上往下、一个流程从开始到结束。这个方法是在功能测试中非常常用的方法，也是对于小的功能块查找bug最多的方法。
<2>，关联测试：所谓关联测试，我理解的是：一个功能点的测试你要考虑到所有与之关联的内容。比如我们常见请假管理中，公司的年假每年每人都有不同的天数设置。如果再请假申请页面提出请假2天的申请，那么与之关联的分别有：a，请假总天数是否大于等于2天；b，请假审批页面改天数是否是两天；c，请假查看页面该天数是否是两天；d，请假申请完结后，请假总天数是否发生相应改变。
<3>，合并测试：在测试中，我们常常会遇到一些功能模块，代用同一个接口或者同一页面，那么在测试的时候，我们可以将其归为一类中的不同，然后进行合并测试，挑其中一个进行详细测试，其他进行验证性测试即可。
<4>，反规则测试：在测试中，一般需求会给一些规范，比如会有关于数字的范围或者小数的保留位数等规则，在验证时，就需要进行反规则测试，按照相反的思路进行测试。其实反规则测试也是我们写测试用例时常用的用例，比较常见。
<5>，拓展测试：拓展我觉得就是想多一点，比如一些文本信息只有字数要求，那么对于就要多想一些，比如对特殊字符的兼容、对空字符的校验等，多想一些，就能让服务更完美一些。
不同的人可能常用的测试方法不同，但是不管什么方法，就是在有限的时间内容尽可能的覆盖项目，减少生产上bug发生率，只要自己用的开发，用的顺手，不一定是这么些的。
三，参考文档，在测试过程中，我们需要去查看一些文档，也需要编写一些文档。其中有一些这些，在测试过程中常用：
<1>，测试过程中参考，《需求设计文档》、《详细设计文档》（可能设计代码逻辑，尽量看懂）、项目Demo（如果有的话）、数据库、日志信息、测试用例。
<2>，测试编写，《测试用例》（前期工作，后续跟踪项目需求，补充完善）、《测试日志》（跟踪自己每天的工作，对整个测试任务把控）、《用户使用手册》（如果需要编写的话，尽可能详细）、《测试总结》（对整个测试过程进行总结，体现工作思路、bug管理、项目总结等）。
四，细心执行，及时反馈。
做好了准备工作，接下来进行测试的过程中，就需要我们根据测试用例进行测试，测试过程一点要细心，并且及时将测试进度与遇到的问题与项目经理进行反馈，做好沟通，更好的完成测试工作。。。