测试这东西（三）
任何一种理论都有着它存在的意义，任何一种开发模式也有它生存的理由。对于测试，也是相同。理论上，测试的设计一定会在它所依据的文档通过了评审以后才开始，可是，到那时你又该如何确定这些文档能为你所用呢？当我们从一片混乱，到开始一个正规的测试流程时，我们或许并没有可以借鉴的经验，只能凭着理论带给我们的指导，一步步摸索前进。那么，在实际的过程中，我们如何来进行这场软件过程的革命呢？
以系统测试用例的设计为例。
理论上，当一份需求规格评审通过后，你才开始写系统测试计划、系统测试用例。为了保证需求规格的可测性，测试设计人员一定会参加该文档的评审。可是评审完成后，你会发现，当初明明看得很清晰的文档，现在忽然变成了一个让你迷惑不解的东西，你大致知道了软件要实现的功能是什么，可是你有好多测试思路无法实现，你发觉需求规格根本不能够提供给你所要的信息。于是，你义愤填膺：这标准的过程怎么会是这样？我明明已经评审过，我觉得上面表达的意思很清晰呀，为什么我不能够以它为主要依据来写测试用例？看样子，软件工程一点也不实用！
那么，先不管软件工程是否实用，我们诊断一下为何不能够设计测试用例的原因。当我们首次看到一份需求规格时，我们关注的是他描述是否清晰，是不是已经让我们了解了软件大致要实现的功能。可是我们并没有从测试的角度来考虑，去测试这份文档存在的问题。当评审时间不充分、评审内容过多的情况下，我们没有余力去做充分的考虑，这就导致了我们的后续工作无法展开。因此，分析到这种情况的产生是因为我们生搬硬套了理论，自然不会收到良好的效果。这就需要对我们预定的测试管理过程进行第一步改进了。
作为需求规格评审委员会的成员之一，在项目计划制定时，你就可以要求将各部分文档评审的时间尽量放长，评审的内容尽可能小的切割出来进行评审。这样，你有足够的时间去评审文档是否符合你的要求。你可以在脑中形成一个大致的测试框架，明白在这段内容中，你要测试什么，需要这份文档提供给你哪些信息。最实际的做法，就是在评审的时间就着手写测试用例，当你开始动手时，你的测试思路就会源源不断地运作起来，你才能了解这份需求规格是否真的描述清晰，是否存在二义性，是否考虑到了你所考虑的所有状况的处理。如果没有，你就可以把这些作为缺陷提交出来，请需求规格的分析人员做修正。此时，你发现的缺陷价值远远比你在系统测试阶段要大得多，因为，所有的弊端在初开始时就已经被发现，并及时作了修正，防止了下一环节继续出现偏差，大大节省了开发成本。而此时的测试用例并不能作为你真正发布的版本，因为评审阶段会有大量的缺陷被提出，只有在完全修复后再通过了评审，根据需求规格修复了你的测试用例，才能转化为真正的用例价值。对于这种方式，我们并不能说软件工程的理论跟实际不相符，不是吗？
然而真正作为基线管理的测试用例，并不一定是根据需求规格写完了就被评审的。尽管作为公司灵魂的软件需求规格要求尽可能的详细，但在实际设计与编码中仍然或多或少的会有偏差与变更。系统测试用例就是在这个过程中不断的完善、细化的。
当编码阶段开始时，为了缓和系统测试阶段出现的缺陷过多、有可能延误发布日期的风险，也为了降低缺陷修复的成本，系统测试用例的执行通常是在这个阶段就介入了。此时，测试用例并不能被基线化，在不断的编码单元集成时，测试人员(在此时，我认为最恰当的测试人员是测试设计人员)会抽取相应的测试用例来对集成的产物执行测试，验证测试设计思路是否存在偏差，测试覆盖率是否足够的高，一边执行测试，一边修改与补充测试用例，一边提交测试得到的缺陷。当编码基本结束时，系统测试用例已基本被完善。此时的用例文档便可提交评审。当然，我坚决不鼓励所有的测试用例完成之后才一起评审，同需求规格一样，他也应该是在实际过程中使用迭代的方式进行评审内容的分割，以使评审委员会成员有充分的时间跟精力进行评审。
评审通过后，系统已经集成完毕并通过了集成测试，此时就可以进入系统测试阶段。在系统测试阶段中，测试执行人员从头执行系统测试用例，并根据测试中出现的问题提交缺陷。可能有人说，系统测试都被提前到编码阶段做了，这个时候还能发现缺陷吗？当然可以！缺陷是发现不完的，关键是看你设计的思路，测试的覆盖率只是个相对数，它永远都不可能达到百分之百。因此，我们会在不断的测试过程中发现缺陷，并把缺少的测试用例通过变更流程补充进去，以使测试用例更为完善。在客户验收测试阶段、实际使用阶段，我们仍然会收到用户发现的缺陷，并把这些漏掉的测试用例也补充进去。而这些漏测率也可以作为评估测试用例设计质量的指标。
需要注意的是：测试计划跟测试用例的设计过程是有差别的，评审过程中介入测试设计，也必须介入测试计划，因为你测试设计的思路就是计划中测试策略的一部分，你不能够忘记测试计划的指导意义。当需求规格评审完成时，你首先要做的一件事，就是完成你的测试计划，评审通过后才可去完善测试用例。否则，你不能够让评审委员们接受你的测试策略，又怎么可能越过这一关，执行错误的设计呢？
在测试管理过程中，以上的过程并不是唯一的实用过程，每个企业的环境不一致，采用的方法也不相同，仍然需要灵活的运用。这种方法只适于参考，让相关人员了解实际的状况，识别这些风险，采取更有效的方式来缓和或规避。
作为本文章的终结篇，我并不对缺陷的管理过程作过多描述，缺陷管理是一个相对独立的过程，着重于对评审或测试中出现的缺陷进行严格的追踪与控制。每个企业的环境不同，所使用的管理流程也不同，但目的是一样的，就是使缺陷尽可能的得到修复。
测试、质量控制、质量保证这三个概念通常会被混用，有些测试人员称为QA，却做的只是测试的工作，有些测试人员称为QC，却不明白QC跟QA又有何区别。
测试是通过各种方式来验证软件是否达到规定的要求，他只负责发现缺陷、追踪缺陷，却并不负责产品的质量。而QC是要对软件产品的质量进行控管的，他要考虑缺陷修复的方式、产品发展的方向、软件变更的合理性等等。从广义上来说，QC应该是QA的一部分。但从实际情况考虑，最了解软件产品状态的是测试人员，由他们来负责产品的质量控制无疑是最合适的，可以节约人力资源成本以及独立的测试与QC的沟通成本。狭义的QA指的是对软件开发的过程进行跟踪，发现过程中出现的问题，及时汇报与处理，收集项目中必备的度量数据，使软件过程变得透明化，可控制。QA会分析数据背后的不合理性，找出原因，提出解决方案，促使软件过程的改进，同时汇总历史项目的度量数据，作为下一个项目的参考。
总之，无论是测试，还是QC，或是QA，他们存在的最终意义都是为了软件产品的质量得到保证，不会因为在各个环节中出现了较大的偏差却无法识别，最终造成巨大的成本损失或项目失败。
综上所述，测试这东西说神秘不神秘，说简单不简单，它的理论也就那么一点，毫不复杂，复杂的只是具体的测试工作是如何做的，做得如何。因而测试理论的灵活应用，测试人员的经验值，却成为衡量测试水平的关键。可见，一个测试人员需要具备敏捷的反应，发散的思维，良好的沟通技巧，高度的责任心，深厚的应用领域的业务知识，软件工程理论，以及尽可能多的编程经验。测试人员能力的提高取决于以上因素。
关于程序员与测试人员的评价是：一个有过编程经验的测试人员不一定是优秀的测试人员，但是一个有过测试经验的程序员一定会是优秀的程序员。原因只有一个，就是测试很重要！
:) ding@ 好!太好了,呵呵 ding 说的太好了，说到测试人员心里去了。
页:
[1]
