不管你是刚进入测试行业还是准备进军测试行业，不管你是在测试部门健全的公司还是测试部门刚建立的公司，最起码你需要了解测试的整个流程。这样你在工作中才能做到心中有数，不至于太慌乱、进去之后四处抓瞎。

　　其实在进入这个行业的时候，自己也有过迷茫，看起来简单的事做起来却并不简单。甚至很多时候自己觉得自己无事可做，因为在小公司任职，老板也无暇顾及测试整天都在忙些什么，自己也真的是整天悠闲悠闲的混日子，到了项目上线时自然忙的焦头烂额、心里也很没谱，后来跟一些测试大神沟通完之后，真是获益匪浅。那么我总结了下从整体上如何安排测试的，或许并不是绝对的完善，但是希望给那些跟我一样有过迷茫的孩子一点参考。那就言归正传吧。

　　首先，你需要知道的是，项目立项开始，是否有《需求说明文档》（也就是《需求说明书》）？

　　如果有，那么前期以此为准开展评审，再审以及最终确认。由于需求评审阶段各个部门及人员所采集的信息不同，但最终都必须达成一致，如果需求确认后，不同部门的工作内容也就明确，开发来说主要确定开发语言，数据库，同时需要输出概要设计和详细设计文档（包括功能的概述，逻辑的整理，建模等），一般服务器等配置这个阶段也可以开始着手做，产品需要根据需求设计原型图及demo。测试在此阶段需要做的就是确认需求是否都是明确的，是否都是可测的，逻辑是否都是合理的等等，应及时反馈需求中存在缺陷，作为测试负责人需要做的就是工作的记录用时多少个工作日，都干了什么？得到什么结果？是否有遗漏？组员是否都参与？是否对过程中的输出项已经熟悉并认同等等，在公司大流程以及部门规范前提下，当前的工作是否已经可以结束并进入下一阶段？和其他部门是否达成共识？有不明确项要及时发起会议，会议过程中要做好会议记录，会议结束发送参会人员确认，同时明确分工，截止时间等，目前公司是team leader和主管去，谁去无所谓，重要的信息的共享和及时传达，人家带你就去，不带就算了，他们得给你详细文档，如果没有文档的话，就功能点细节你得多交流，刚才说那么多等到该确认的都已确认，作为负责人来说接下来就该准备测试计划了，编写出完整的测试计划，有测试覆盖面，人员安排，工作评估，异常事件处理，结果总结，文档交付，组织评审及最终确认，测试人员就按着测试负责人的计划来进行工作，测试用例的编写（一般都有模版），测试环境的准备，缺陷管理规范和缺陷工具等，理论上用例也需要发起会议评审，分内部和外部直到最终确认，以上都是你有了《需求说明文档》之后，以此为基准开展的前期的测试准备工作，也就是未接到测试版本之前需要做的，理论上测试计划不怎么可靠，因为过程中发生什么谁也无法预料，但是好的计划前期的确可以说明一些事，无非就是设备调用，人员安排，测试覆盖面和深度以及一些特殊情况说明，切记所有的信息的传递及确认一切以邮件为准，为了避免日后的麻烦千万不要认同口头答复。

　　接下来就是接收版本开始测试，这时候前阶段的准备就可以发挥作用了。作为测试负责人，接收测试版本后可以安排测试，首先就是冒烟测试，验证当前版本是否满足后续测试，满足则发邮件说明，不满足也同样发邮件说明并打回该版本，这个过程基本是已经规范好的，没什么特别说明。

　　好了，说完有《需求说明文档》的公司，下面说没有《需求说明文档》的公司。

　　目前大多数公司都这样，在这类公司工作说白了就是干活，别跟人家提流程、文档和规范，人家要么不了解、要么压根就不知道，第一，时间不允许，没空搞那些，既然答应多久能给出产品，那么为了能在相应的时间内完成产品，一般情况下需求人员也是刚弄明白需求，就召集开发人员进行口头讲解，然后开发人员就直接进行开发，若在开发中有不明确的，就再来问需求人员，边开发便询问需求人员；第二，怕麻烦，几句话能讲清楚的事何必麻烦的进行文档的编辑，万一需求变动大，那岂不是三天两头进行需求文档的编辑，需求变动大又能怎样，这时候需求人员又从新讲解，开发人员又接着从新编写代码；第三，老板及管理层只看结果，测试的存在性极低，存在也是为别的部门背锅。以上的情况决定了测试获取信息的不全面，受阻，这样的情况可能大多数人会选择离职或者破罐子破摔，每种环境的存在都有其合理性，当然这样的环境也可以锻炼人，为了自保，工作还得认真的做，他们乱自己不能乱，信息获取不全面可以直接去问，不要怕麻烦，沟通也要有技巧，不要撕破脸（也可以撕破脸，那就是你准备要离开的时候）。有测试任务，先确认任务的目的，内容以及异常情况，一切搞清楚发邮件，来编写测试计划，说明测试时长，测试覆盖范围，异常因素影响测试的等等。

　　这里就有个很大的问题就是这个测试计划的安排与测试时长，因为前期我们并不了解需求，这样就不能很好的了解每个模块的难易程度也就无法准确安排自己的工作。那肯定有人说，那在需求人员给开发讲解需求的时候你也去旁听就好，我觉得这个方法也可以，但是最大的问题是你一个人还是无法了解整个系统的需求，除非有多少需求人员就有多少测试人员，一个测试跟一个需求人员，想必这个也很难实现，因为公司宁愿多招几个需求和开发也不愿多招一个测试，就是我之前说的，因为老板觉得测试闲暇时间实在是太多、忙的时间太少。然而并不是测试不想忙，只是在前期他们觉得测试人员没必要参与。测试人员在拿到测试版本之后才开始慢慢了解这个系统，但是，完全没有多余的时间去深入了解这个系统，因为这个时候离上线时间不远了，得抓紧测bug了，改完了好去上线。看吧，这样测试的作用就是看功能是否报错，界面过的去就行。老板对测试的成功检验也只是功能是否报错，如果上线时没有错误那就是你测试测得好，有了问题就是你测试没好好干活，他忽略了一点就是测试只是尽可能的降低错误，是人就会犯错，更何况是人写的代码，牵一发而动全身的代码，不是改了错误就没了，也可能会迸发其他错误。出了问题测试永远是最大的背锅者，但是没办法，你干的就是这一行，而行业中大多数公司也都是这样，要想在这种环境下生存，你唯有适应这个环境，尽可能的完善自己，多学点知识充实自己，在工作中，大方针不变的情况下灵活点，结合自己的实际情况稍微变通自己的工作方式。