第2章 测试过程
2.1 软件测试阶段
2.2 测试过程模型
2.3 软件开发与测试过中各环节的任务、角色及其职责
2.1 软件测试阶段
验收测试
1．α测试
α测试是用户在开发环境下进行的测试，也可以是开发机构内部的用户在模拟环境下进行的测试。α测试中，软件在一个自然状态下使用。开发者坐在用户旁，随时记下错误和使用中的问题。这是在受控制的环境下进行的测试。α测试的目的主要是评价软件产品的功能、局域化、可用性、可靠性、性能、支持性（Function，Localization，Usability，Reliability，Performance，Support，FLURPS），尤其注重产品的界面和特色。α测试人员是除产品研发人员之外最早见到产品的人，他们提出的功能和修改建议是很有价值的。
2．β测试
β测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。这些用户是与公司签订了支持产品预发行合同的外部用户，他们要求使用该产品，并愿意返回所有错误信息给开发者。与α测试不同的是，在进行β测试时，开发者通常不在测试现场。因而，β测试是在开发者无法控制的环境下进行的软件现场应用。
在β测试中，由用户记录下遇到的所有问题，包括真的和主观认定的，定期向开发者报告；开发者在综合用户的报告后做出修改，再将软件产品交付给全体用户使用。
单元测试、集成测试、系统测试的比较
回归测试
在测试或其他活动中发现的缺陷经过修改后，应该对软件进行回归测试。回归测试的目的是验证缺陷得到了正确的修复，同时对系统的变更没有影响到以前的功能。回归测试可以发生在任何一个阶段，包括单元测试、集成测试、系统测试。
1．回归测试的策略
如果回归测试需要考虑如何选择重新执行的测试用例，就要确定回归测试的策略。常见的回归测试策略如下。
●完全重复测试：重新执行所有在前期测试阶段建立的测试用例，以确认问题修改的正确性和修改的局部影响性。
●选择性重复测试：选择性地重新执行部分在前期测试阶段建立的测试用例，以测试被修改的程序。具体细分如下。
■覆盖修改法：针对被修改的部分，选取或重新构造测试用例以验证没有错误再次发生的用例选择方法。也就是说，这类回归测试仅根据修改的内容来选择测试用例，这部分测试用例仅保证修改的缺陷或新增的功能实现了。这种方法的效率是最高的，但风险是最大的，因为它无法保证这个修改是否影响了其他功能。在进度压力很大或者系统结构设计耦合性很小的状态下，可以使用该方法。
■周边影响法：不但要包含覆盖修改法确定的用例，还需要分析修改的扩散影响，对于那些受到修改间接影响的部分，选择测试用例以验证它没有受到不良影响。该方法比覆盖修改法更充分。这类回归测试需要分析当前的修改可能影响到哪部分代码或功能，对于所有受影响的功能和代码，对应的所有测试用例都将被回归。如何判断哪些功能或代码受影响依赖于开发过程的规范性和测试分析人员（或开发人员）的经验。对于开发过程有详细的需求跟踪矩阵的项目而言，在矩阵中分析修改功能所波及的代码区域或其他功能是比较简单的，同时有经验的开发人员和测试人员能够有效地找出受影响的功能或代码；对于单元测试而言，修改代码之后，还需要考虑对一些公共内容的影响，如全局变量、输入/输出接口、配置文件等。该方法是业界推荐的方法，适合于一般项目。
■指标达成方法：一种类似于单元测试的方法，在重新执行测试前，先确定一个要达成的指标，如完全覆盖修改部分的代码、覆盖与修改有关的60%的接口等，基于这种要求，选择一个最小的测试用例集合。
2．回归测试流程
回归测试也需要有流程，可参考如下流程。
（1）在测试策略制定阶段，制定回归测试策略。
（2）确定需要回归测试的版本。
（3）发布回归测试版本，按照回归测试策略执行回归测试。
（4）若回归测试通过，关闭缺陷跟踪单（问题单）。
（5）若回归测试不通过，把缺陷跟踪单返回开发人员，开发人员重新修改问题，再次提交测试人员，进行回归测试。
3．回归测试的自动化
回归测试是一个重用以前成果的测试，很难预料到要经过多少次回归系统才能达到满意的水平，因此，回归测试将可能演变成一种重复的、令人心烦意乱的工作，效果与人员的积极性将大打折扣。于是，回归测试的自动化非常重要。
回归测试的自动化包括测试程序的自动运行、自动配置，测试用例的管理和自动输入，测试的自动执行，测试信息与结果的自动采集，测试结果的自动比较和结论（尤其前面提到的各类数据的共享决策）的自动输出。
对于系统测试功能比较简单、测试界面相对稳定并且测试用例良好的测试来说，采用“捕捉回放”工具是比较合适的，这类工具有QTP、Robot Framework、Selenium等。为了实现测试用例的自动化并实现测试结果的自动判断，脚本化的并且包含控制结构和内部实现结果判断的测试用例是唯一的选择，此类脚本语言有Python、Ruby、Java等。
对于特定系统中复杂的测试来说，如果没有通用的商用工具可供选择，可以尝试开发专用的自动化测试工具。
回归测试的自动化（或者说工具化）是一个需要尽早考虑的问题，在确定测试方案时就要考虑这种可能性，必要时应投入资源进行开发，形成可供继承与推广的工具则是最终目的。
2.2 测试过程模型
CMM（能力成熟度模型）
角色（role）入口准则（entry criteria）输入（input）活动（activity）输出（output）出口准则（exit criteria）
评审和审计（review and audit）可管理和受控的工作产品（work product managed and controlled）
测量（measurement）书面规程（documented procedure）培训（training）工具（tool）
双V模型
2.3 软件开发与测试过中各环节的任务、角色及其职责
项目经理
开发工程师
测试工程师
开发经理
测试经理
质量保证人员QA
变更控制委员会CCB
继续学习，未完待续。。。