传统的软件测试方法体系中的核心内容

　　最近接触的一些软件测试相关比较前沿的概念，和其他人讨论时免不了要说到这些理论或者新概念和传统的软件测试理论有什么不同。但是首先我们对什么是传统的软件测试理论范围的理解有差异，经常有个人说“这个不就和那个xxx一样吗?”，另外一个人立马回复“传统的测试理论还包括这个吗?”，因此我觉得有必要把什么是传统的软件测试理论明确一下。这里的传统软件测试体系等同与经典软件测试体系。

　　软件测试的工作范围

　　软件测试体系一般涉及项目管理，Bug管理，用例管理三个方面。下面我会分开讲各个方面工作的内容

　　一般测试部门的人员角色划分

　　按工作的内容分，常见分成QA，TE，SCM这3种角色， 正式的QA和TE的差别在于，TE负责的是寻找Bug和执行用例的角色，而正式的QA一般在拥有CMMI等级的软件公司中比较常见，他们一般不具体做寻找软件Bug的工作，而是负责项目流程的建设和监督，并随时拿出对该项目的一些度量指标来说明监控项目风险。有的公司也会把QA和TE放在一起就叫QA，干的是TE的活。SCM一般负责版本控制，build出包这活，也不涉及寻找Bug和执行用例，综上，从正式的定义来说，QA偏向流程，TE寻找Bug，SCM负责出包。 所以一个QA和SCM可能会同时负责多个项目，而TE一般则是比较固定在某个项目中的。

　　项目执行与管理

　　在需求评审阶段测试就需要介入，了解整个项目的过程，并积极参与产品需求评审，了解需求方对产品在测试方面的具体需求，比如性能指标，兼容系统范围，本地化支持

　　代码提交测试前，测试这边一般要准备一份测试计划和经过评审过的测试用例

　　测试策略(TestStrategy)一般写上用测试的覆盖范围：比如功能，界面，安全，可用性，易用性，稳定性，数据库，安装，文档

　　测试计划(TestPlan)最主要的是划分测试阶段和测试资源安排,测试阶段即各里程碑要达到的测试效果和目标，对于互联网来说最简单的划分是测试环境和线上正式环境，测试环境上要测试哪些内容，线上正式环境上要测试哪些内容，当然实际项目的测试阶段划分要比这个复杂的多，比如我们的项目一般都是按4个测试阶段在走。测试计划里面还有一个重点是人员的安排，人员安排随测试阶段而变化，最开始可能需要的TE多一下，进入稳定阶段后可逐步减少。

　　测试计划中还规定了每个阶段执行用例的轮数和用例范围。

　　一般我们认为，测试计划=测试策略+测试阶段+测试资源安排。

　　用例编写(TestCase Design)

　　测试分析(Test Anlysis)是为寻找Bug和用例编写服务的，所以用在用例编写这个环节上来说，测试分析主要针对的目标是测试需求分析，即产品需求明确后，测试这边要看看这个需求的测试点有哪些，风险在什么地方，怎么才能测到(有些模块是测不了的)，需不需要额外的工具来辅助测试，或者让开发开放某些接口以便来达到测试目的。

　　用例设计方法：我们认为TE在编写测试用例时应该了解产品的业务需求和实现逻辑，并了解经典的测试用例设计方法，比如边界值，等价类划分，正交矩阵实验法等。最低要求应该掌握《软件测试的艺术》这本书提到的各种方法。

　　用例类型：针对某一个功能在编写用例时除了考虑用上述各种方法去构造测试用例外，至少还应该考虑UI用例，功能用例，交互用例，负面测试(Negative Testig)，可能涉及到的类型。

　　对UI测试的处理：，一种是写成用例或者划分一个测试用例类型，一种是不写用例，拿UI流程图一页一页检查。

　　用例分级与追溯(Trace)：用例分级的目的是为了划分用例的优先级，比如重点功能的用例优先级比较高，负面测试的用例比较低，级别低的用例可能在整个项目中就只执行一遍，而优先级高的用例可能要在不同的阶段被重复执行。

　　用例追溯的目的是为了检查产品需求是不是都被覆盖到了。分级与追溯的作用可参考QC或TestLink的做法。

　　用例评审：

　　用例设计完成后测试内部或者外部对用例的评审。这个过程一般能发现很多开发和产品原先没有想到的逻辑分支和处理。

　　Bug管理

　　对Bug的生命周期(Bug Lifecycle)或者Bug趋势曲线，传统的和非传统看法都比较一致，没什么大的异议。

　　以上体系只是涉及一般的软件测试体系，没有涉及CMM/CMMI或者ISO9000族中对质量管理的体现。

　　软件测试的经典书籍

　　《软件测试》 作者：Ron Patton

　　《软件测试的艺术》 作者：梅尔斯

　　《人月神话》 作者：弗雷德里克·布鲁克斯

　　《有效软件测试——提高测试水平的50条建议》作者：Elfriede Dustin

原文转自：http://agileqa.org/archives/100