13.1.2 方案二
案例13-2：软件测试团队组成结构分析方案二
1．软件测试经理
职责：
- 了解软件测试需求。
- 书写软件测试计划。
- 把握软件测试范围。
- 制定软件测试策略。
- 选取软件测试工具。
- 评估软件测试风险。
- 帮助软件测试系统分析师分析测试用例。
- 监控软件测试进度。
- 评判缺陷严重等级。
- 度量软件测试指标，从而决定软件测试是否可以退出。
- 书写软件测试总结报告。
- 组织软件测试结束活动。
2．软件测试分析师
职责：
- 设计软件测试用例。
- 选择软件测试环境。
- 准备软件测试数据。
- 选择并培训软件测试工具。
- 选择软件测试开发代码，书写基本框架。
- 进行探索式软件测试。
3．软件测试环境工程师
职责：
- 搭建软件测试环境。
- 培训软件测试环境使用。
4．软件测试开发工程师
职责：
- 书写软件测试代码。
- 开发内部软件测试工具。
5．软件测试工程师
职责：
- 执行测试用例。
- 书写缺陷报告。
- 回归测试。
- 重测试。
如本节开始所述，这里仅介绍两种情形。各企业可根据自身情况设置软件测试工程师结构。比如，用友集团的软件测试工程师分为普通软件测试工程师、高级软件测试工程师。高级软件测试工程师可以发展为专家级软件测试工程师或软件测试经理。而专家级软件测试工程师又可发展为高级专家级软件测试工程师。而Google公司的软件测试工程师仅分为软件测试开发工程师和软件测试工程师两种类型。
13.2 软件测试过程
案例13-3：软件测试过程
大概许多人都认为，软件的质量是完全依靠软件测试团队测试出来的，其实这是一个非常错误的观点，著名的日本质量专家田口玄一说得好，“质量是设计出来的，而不是被测试出来的”。软件质量的好坏，包含在软件生命周期的各个环节：客户调研、立项、需求调研、概要设计、详细设计、编码、测试、安装和售后服务等。也正如本书第一篇开始提及的软件测试过程应该包括“软件测试计划”“软件测试分析”“软件测试设计”“软件测试实施”“软件测试执行”“评估出口标准和报告”以及“软件测试结束活动”几个阶段。
软件测试团队应该趁早介入到软件研发工作中去，这种全程化软件测试的思想已经越来越被各个软件企业所接受。
在软件需求阶段开始，如果有条件，可以让一名测试工程师与需求分析师一起与客户了解用户的需求。当需求分析师完成《用户需求说明书》后，这名软件测试工程师应该作为副手，一起帮助审查，然后还应该把说明书提交客户进行多次确认。当《用户需求说明书》得到最终确认后，需求分析师要把它转化为《需求规格说明书》（SRS）。在《需求规格说明书》评审会议上，软件测试工程师也应该全程参与。软件测试工程师在需求阶段参与需求评审的主要职责有两个：第一、在第一时间内掌握系统的需求；第二，检查需求中是否存在问题。另外在这个阶段的后期，软件测试经理也应该协同项目经理和开发经理制定《软件测试计划》。
软件设计期间，软件测试工程师的主要职责是评审《概要设计说明书》与《详细设计说明书》。主要审核点是：设计是否完全包含用户的需求、设计是否在现行技术上可以实现、设计是否具有可测性和可维护性，以及设计是否具有用户友好性等。同时，软件测试系统设计师或软件技术设计师也应该在这个时期规划软件的测试策略、测试方法和测试环境等软件测试的早期设计。
在软件编码阶段，软件测试工程师主要编写《软件测试用例》。同样《软件测试用例》设计完毕也需要进行评审，评审时应该让相应的软件开发工程师参加，其目的是让软件开发工程师在通过《软件测试用例》评审后，在开发代码中对软件的各种操作，特别是异常的操作进行处理，如找不到数据库服务器，操作过程中突然断网等情况。而不是等测试工程师在测试阶段发现缺陷后再进行修改，也就是说测试用例应该百分之百地向软件开发工程师公开。
下面进入到软件测试实施阶段。在软件测试实施阶段，软件测试工程师的主要工作是整理软件测试数据、搭建测试环境以及书写自动化测试脚本。在条件允许的情况下，软件测试工程师应该邀请开发工程师对这些数据和环境进行审核。
接下来进入软件测试执行阶段。一般来说，单元测试以及集成测试应该由开发工程师在开发完毕后进行实施，或者待开发完毕后集成测试由软件测试工程师与开发工程师共同完成。这个期间要重视代码审核（Code Review）。
开发经理认为开发的产品可以送交软件测试部门进行测试，软件配置工程师在配置版本控制软件上打好Tag，编译并且安装好测试软件。首先需要进行冒烟测试，一般为几个小时到半天。如果冒烟测试通过，正式进入系统测试阶段，否则退回开发部门。
进入系统测试阶段，软件测试部门按照事先写好的测试用例自动或手工执行软件测试，一旦发现缺陷，应该立即通过缺陷管理工具交付给开发工程师（注意，缺陷描述一定要书写详尽，便于开发定位，必要情况需要提供截图和Log日志，参见本书“缺陷书写规则”）。这时更需要测试与开发之间沟通，包括缺陷复现、缺陷定位等工作。也正是在这个时期最容易发生由于某个缺陷引起开发与测试之间产生矛盾，大家一定要站在用户的角度上来思考问题，如果对于某个缺陷达不成一致意见，可以请资深的测试/开发工程师，甚至开发/测试经理来解决。
当软件测试满足软件测试退出条件，由软件测试部门经理审核后书写《软件测试总结报告》。
最后千万不要忘记，在软件测试活动正式结束前还有一个非常关键的活动，即软件测试结束活动。这里需要总结整个测试过程中的经验和教训，并且把软件测试期间产生的文件、代码和工具进行统一归档以及把测试设备进行退还。
| 扩展阅读：软件测试质量标准1．测试成熟度模型集成（TMMi） 测试成熟度模型集成（TMMi）包含5个成熟度等级，旨在补充CMMI模型。每一个等级都包括已定义的过程域，组织必须通过实现某个过程域的特殊和通用目标，达到85%的过程域满足度，才能升级到更高等级。 TMMi的成熟度等级分别是：[J6] 1级：初始级 初始级表示测试过程没有正式的记录，而且杂乱无章。测试在编码后以特别的方式执行，与调试没有区别，测试的目的被理解为证明软件正常工作。 l 2级：管理级 2级要求测试过程和调试完全分开。可以通过以下办法达成：设定测试方针和目标，引入基本测试过程中的步骤（如测试计划）和实施基本测试的技术和方法。 l 3级：定义级 3级要求将测试过程集成到软件开发生命周期，并在正式标准、规程和方法中予以记录。组织开展评审，而且有单独的软件测试职能，并对其进行监控。 l 4级：度量级 4级要求组织能够有效地对测试过程进行度量和管理，有利于项目开展。 l 5级：优化级 优化级表示组织的测试过程能力度达到如下状态：测试过程的数据可以用于预防缺陷，而且注意力集中在优化已建立的过程。 2．TPI-NextTPI-Next模型定义了16个关键领域，每个领域覆盖测试过程的一个特定部分，例如测试策略、度量、测试工具和测试环境等。
|
该模型定义了四个成熟度等级： Ø 初始级 Ø 控制级 Ø 高效级 Ø 优化级 对每个成熟度等级的关键领域的评估都设定了特殊检查点。检查结果汇总到成熟度矩阵中展示出来，成熟度矩阵覆盖了所有关键领域。根据测试组织的需要和能力，可以对改进目标的定义和实施方式进行裁减。 使用关键测试过程（CTP）评估模型的基本前提是某些测试过程是关键的。这些关键测试过程，如果实施得当，将会给测试团队带来成功。否则，即便测试人员和测试经理本身再有能力也不会获得成功。该模型识别十二个关键的测试过程，CTP是一个内容参考模型。 CTP模型是一个依赖背景的方法，它允许裁剪，包括： Ø 识别特殊挑战 Ø 认识良好过程的属性 Ø 选择过程改进实施的顺序和重要性 CTP模型是可用于所有软件开发生命周期的模型。除了参与人访谈，CTP模型还包括使用度量，将组织实际情况与行业平均值和最佳实践进行比较。 STEP（系统化测试和评估过程），与CTP比较类似，而与TMMi和TPI-Next不同，并不要求遵循特定的顺序来进行改进。STEP主要是一个内容参考模型，它基于这样的设想：测试是一个生命周期活动，从明确需求期间开始直到系统退役。STEP方法强调“先测试后编码”，而这种方针的实现途径是使用基于需求的测试策略以保证在设计和编码之前，已经设计了测试用例以验证需求规格说明。 STEP方法的基本前提包括： Ø 基于需求的测试策略； Ø 在生命周期初期开始测试； Ø 测试用来作为需求并使用模型； Ø 由测试件的设计引导软件设计（测试驱动开发）； Ø 较早发现缺陷或在整体上预防缺陷； Ø 对缺陷进行系统地分析； Ø 测试人员和开发人员一起工作。 在某些情况下会结合STEP评估模型和TPI-Next成熟度模型。 |
顾翔凡言：
不是好的工作会给你带来好的心情，而是好的心情会给你带来好的工作。
