关于这东西，玩了四年，仍然没有摸透它的脾气。
有人说，软件测试是为了发现更多的缺陷，也有人说，软件测试是为了保证产品的质量。都没错啊，一个是从职责的角度来看，一个是从控制的角度来看。
软件测试，其实就是一个验证的过程，人员竭尽所能的折腾一套软件，看它是否符合客户要求的标准，是否能经得起折腾，借以评价产品的质量好不好。不就是这样吗？：-）
常规的软件测试理论是遵循了V模型中的V&V过程，也就是Validation and verification。Validation是对客户需求的验证，比如通常所说的验收测试、Beta测试。Verification指的是软件过程中每一次确认活动，包括客户需求确立以后的每一阶段关键产物的评审与测试。
按照V模型的概念，我们将软件过程分为了客户需求、需求规格、概要设计、详细设计、编码、系统测试这几个关键的阶段。每一个阶段都会有相关的评审与测试，因此，以客户需求为主要依据的测试，我们称之为验收测试，着重于用户需求的验证，通常由客户来做；以需求规格为主要依据的测试，被称为系统测试，着重于对产品综合能力的验证，通常由专业的测试人员来做；以概要设计为依据的测试叫做集成测试，着重于对各级别的接口所进行的验证，通常会由编码人员与测试人员一起完成；以详细设计为依据的测试就成为了单元测试，着重于对代码的最小级别进行验证，通常由编码人员实现。看到这样的一个规则，我们很容易理清，每一个测试阶段，所要测试的对象是不同的，而相应的依据一旦通过了评审，便可以着手进行该项测试的准备。
相对于之前的每一个关键阶段而言，测试阶段的执行顺序刚好相反。编码阶段只能执行单元测试，只有单元测试通过了，才可以对单元与单元之间进行集成，测试它们之间的接口，这被称之为集成测试。当软件所有的模块完成之后并且通过了集成测试，那么就可以进入系统测试阶段了。这个时候，测试人员摩拳擦掌，跃跃欲试，不找出Bug不罢休。
然而，到底每一个测试阶段的测试工作是怎样开展的呢？这样的一个过程，我们称之为测试管理过程。每一个测试阶段，都会包括测试计划、测试设计、测试执行这三部分，有些人会把它划分得更细，比如获取测试需求、测试实施、搭建测试环境等。
测试计划并不是单纯的写一个时间表，它是当对应的作为测试依据的文档定格之后（通常我们叫做基线化）就开始做的，最主要的目的是要告诉你的项目组成员，你要做什么（明确测试目的）？对什么来做（明确测试对象及测试需求）？怎么做（制定测试策略）？要使用什么来做（确定测试资源）？何时做（安排测试进度）？需要注意跟控制什么（估计测试风险，使用规避手段）？
测试设计是要在测试计划通过了评审之后才做的，主要的产物是测试用例，是将你的测试策略升级为详细的步骤，对你确定的测试对象进行验证，应该要出现的理想结果是什么。当执行测试的时候，人们依据这份文档，会发现实际的结果与预期的不一样，于是便把它判定为缺陷。辅助的测试设计产物还包括测试环境的搭建、测试脚本、测试使用的数据等。关于测试脚本，是要衡量开发成本与预期收益的，不可以为使用了自动化的测试就是测试高手，这是个极其严重的误区。测试脚本的目的是要提高你的测试效率，怎样设计还是依赖于一个人的测试水平，如果片面的追求编程技能，把这认为是测试技能的提高，那么你不用做测试了，去做开发吧。在单元测试跟集成测试过程中会使用较多的测试脚本，是因为这些代码的复用率极高，几乎编码过程中的每天都会执行N遍。而系统测试阶段，由于测试重点不同，测试脚本的复用率也远远达不到前两个阶段的效果，自然就更要慎重了。要知道，一个常规的80/20法则，描述了一个事实，就是80%的缺陷是手工测试出来的，只有20%的缺陷是使用自动化测试得到的。你花费了两个月的时间去做了一套测试脚本，却只需要执行四五遍，发现的缺陷也寥寥可数，毕竟测试中的很多验证点是程序无法实现的。那么，如果使用两个月的人工测试，收到的效果会是天壤之别。你会选择哪一种方式呢？
测试执行是在必备的代码实现之后才可以做的。拿着文档做设计，却不在真正的环境中执行，就变成了纸上谈兵的赵括。因此，你可以说测试设计是最重要的，我毫不反对，但是，测试执行却是最关键的。只有这个时候，你才能了解软件的质量如何，存在多少问题，需要怎样修复。在这时，才是我们经常说的测试阶段（单元测试阶、集成测试阶段、系统测试阶段）。测试阶段中，缺陷管理变成了重中之重，缺陷的追踪与控制成为弥补软件缺陷、控制产品质量的最直接有效的手段。
在测试的每个环节都会产生相应的文档：测试计划、测试用例、测试报告，这三份文档成为最基本的资源。一份文档的好坏，关键不在于文笔怎样，而是能否清晰的表达你的意图，并让所有的人员能够了解，使得你所做的工作是可见可控的，不会出现较大的偏差。因此，写文档不是随便完成任务那么简单，它融入了你全部的思想、你的技能、你的沟通水准，是站在一定的高度上来完成的。即使你是个捉虫能手，但你不会写文档，不会把自己的思路清晰的表达出来，这至少能表明你不是个优秀的测试人员。
我绝对不赞同一个测试新手去写什么测试计划、测试用例。他能把测试报告、缺陷描述写清楚就不错了。试想，谁也不是天生的文档高手，必然是经过千锤百炼、日益积累而成的。先要学会测试，能从测试中找到很多的缺陷，知道测试应该是怎样一种过程，再开始进行文档的修炼。
我并不认为一个测试人员一开始写测试计划/用例的时候，就能够根据用户需求/需求规格/概要设计/模块设计这类的文档，写出好的东东。毕竟在国内，大多数技术类文档并不是很过关的。因此，我觉得要练习写，就要从一个你比较熟悉的已经成形的软件开始练起。此时你不需要去假想一个软件应该是怎样，而是针对一个实际的软件开始操作，记录你的操作跟你的结果，把它变为你的测试用例。测试计划更不消说，自然是要在你熟悉这套软件，知道怎样去测它的基础上来完成的。
经过了这样一个锻造，你会明白要怎样展现自己的思路，在新项目中，根据分析或设计文档，你只要考虑它具体实现的是什么，然后根据你的测试思想，你的撰写经验，来完成一份较高质量的测试文档。
任何一种理论都有着它存在的意义，任何一种开发模式也有它生存的理由。对于测试，也是相同。理论上，测试的设计一定会在它所依据的文档通过了评审以后才开始，可是，到那时你又该如何确定这些文档能为你所用呢？
当我们从一片混乱，到开始一个正规的测试流程时，我们或许并没有可以借鉴的经验，只能凭着理论带给我们的指导，一步步摸索前进。那么，在实际的过程中，我们如何来进行这场软件过程的革命呢？
