有效测试的 50 条建议 - 测试组（14~15）

第 14 条：测试技巧、行业知识、经验三者缺一不可

• 行业知识
• 技术知识 专业测试人员对软件工程要有一定的了解，还必须深入了解技术平台和组成系统的架构。为了更好的进行测试的准备工作，测试应该掌握编写自动测试脚本、编写自制测试工具、理解诸如兼容性、性能、系统安装之类的技术问题。
• 经验等级 高级职员需要对初级职员进行培训和指导，测试经理要评审需要的技能和个人实际技能之间的差距。初高级测试一起工作，我们可以安排初级测试人员测试风险较低的功能，高级测试人员负责风险较高的功能。测试组应该提供交叉培训，使测试人员熟悉相关的行业知识和技术问题。

第 15 条 评估测试人员的有效性

为了确保测试任务按照预期执行，测试经理必须跟踪、监督、评估测试工作的实现。而执行测试任务的是测试人员，评估测试人员的有效性就变的非常重要。测试人员的有效性很大程度上会影响和项目中其他小组的关系，如其他小组的信任、测试工作的声誉等。评估测试人员的有效性是一项困难的任务，并且经常是主观的任务。评估所有测试表现时需要考虑的典型要素，如出勤率、注意力、态度和主动性，还要求所有测试要明确工作的方向和具备分析能力。
评估的过程应该从招聘开始。如果测试人员是继承来的，测试经理必须书序各类人员的背景，这样就可以根据他们的经验、专业知识、背景，为他们分配任务并进行评估。进一步了解他们的能力后，再调整一些测试成员的角色。

1，列出期望

如果没有指定的角色、职责、任务、时间表和标准，就无法评估测试人员的表现，测试经理必须首先明确表明在什么时间对测试人员的期望是什么。
下面列出对测试人员的期望，这些期望必须要和测试人员达成共识：

• 遵守测试标准和测试过程。
• 保持进度。测试人员必须了解测试时间表，其中包括必须交付测试计划、测试设计、测试过程、脚本、其他测试产品的时间。
• 达到目标和完成指派的任务。为每个测试人员分配的任务形成文档，并需要和他们充分交流，同时必须确定截止期限。测试经理和测试人员必须就分配的任务达成共识。
• 控制预算。必须了解可支配预算，在预算允许范围内开展工作。

2，评估测试人员有效性

• 行业专家和技术专家。

技术型的测试人员履行自动测试职能时，根据预定标准评估自动过程，如：脚本是可维护的、模块化的、可重用的，还是每个系统每个新版本时都必须修改脚本？是否把测试数据库纳入基线，重新运行脚本时能够恢复基线数据库？如果是自制测试工具，那么评估时应使用评估开发人员的一些标准，如代码的可读性和可靠性。
所有测试人员都应当了解系统功能的复杂性和基本概念。
另一个需要评估的是技术能力和适应能力。测试能够无师自通的掌握新工具并熟悉其功能？测试人员如果尚未完全熟悉测试工具的各项功能，应对其进行培训。

• 有经验的测试人员与初学者。

测试人员的技能水平必须收到重视。初学者容易遗漏缺陷，但有经验的测试人员，由于过去的经验，可能会忽略某些缺陷，比如，对某些熟悉的缺陷麻木了，并不在报告那些他们认为不重要的缺陷，但是最终用户却不能接受的。

• 功能性测试与非功能性测试。

测试经理应该评估的还有：测试人员对各种可利用的测试技术的了解程度，以及对哪种技术能够提高手头测试任务的工作效率的了解程度，错误的使用某种技术，可能会产生负面影响。
功能性测试还应该建立在对测试过程的评审基础上。在评估功能测试过程时，应考虑下列问题：
1，测试过程中的步骤是否完全映射为需求的步骤？是完全可追溯的吗？
2，测试的输入、步骤、输出正确吗？
3，在测试过程的功能流中遗漏了重要的测试步骤吗？
4，在设计有效的测试场景时是否经过了一个分析、思考的过程？
5，是否遵从了测试过程创建标准？
6，在认定测试过程有效和完整之前，由于误解和缺乏交流导致的修改次数是多少？
7，在制作测试用例过程中是否运用了有效的测试技术？
在对测试过程走查过程中，必须验证测试过程的 “深度” 或者是否全面。换句话说，测试过程测试的内容是什么？它是只测试了较高层面上的功能，还是确实初级到了应用程序的实质性功能，即不仅要关注高层的功能，也要触及底层实现，避免遗漏细节。

• 测试阶段。

在不同的测试阶段，测试人员要完成不同的测试任务。

• 开发生命周期的各个阶段。

测试人员应从生命周期开始就介入项目，对测试人员表现的评估也应该按阶段进行。虽然对测试人员的评估可能是主管的，但是我们还是应该重视和各个测试阶段有关的因素。

• 服从命令和关注细节。

关注一个测试工程师遵照指示和注意细节的程度是非常重要的。测试经理要对测试人员的可依赖程度和贯彻指示的持久性要做到心中有数。周例会是一种跟踪和测量工作进度的有效方法，在会上测试工程师报告他们的工作进度，在测试阶段的最后时期，类似的会议应该每天召开。

• 缺陷类型、缺陷率和缺陷文档。

在评估过程中还必须考虑测试工程师发现的缺陷类型。当使用这个度量来评估测试人员有效性时，必须要牢记一些因素，其中包括：测试人员的 技能水平、正在进行的测试类型、处在什么测试阶段、正在测试的应用程序的复杂度和成熟度。发现缺陷不仅依赖测试人员的技能，还依赖开发人员，同时依赖负责评审需求、设计、代码走查的审查小组。
还有一个影响评估的因素是确定测试工程师发现的缺陷是复杂的、与行业领域相关的缺陷，还是简单的外观缺陷。
测试经理还必须考虑测试人员负责的具体区域，即使测试人员所负责的部分中大多数缺陷是在产品中才发现的，也不能就此断定这位测试人员表现不佳。如果测试人员所负责的这部分非常复杂并且容易出错，而且产品发行的又非常匆忙，那么遗漏一些缺陷也情有可原。
在产品中发现的缺陷类型也非常重要。如果某个缺陷可以通过现成的测试过程套件中的基本测试发现，并且测试人员也有足够的时间来执行这些测试过程，那么这就是负责此部分的测试人员的重大疏忽。但是，在写结论之前，还应考虑下列问题：
1，测试过程是需要手动执行的吗？手动测试人员可能已经厌倦重复相同的测试，并且因为应用的被测部分以前一直运转良好，所以多次例行公事以后就得出肯定的结论而不再执行测试。
2，软件是在截止期限的夏利下发行的吗？此时，即使完全取消整个测试周期也无法改变软件发行日期。尽管有时间压力，但不满足发行标准就不应该允许软件发行。
3，测试是自动执行吗？自动测试脚本遗漏的测试步骤中是否可能存在缺陷？如果出现了这种情况，那么必须重新评估自动测试脚本。
4，缺陷是通过一些很少执行的基本功能的组合发现的吗？发证这种类型的缺陷也情有可原。
除此之外，在测试工作启东市，还需要对测试目标、项目风险、所作的假设进行评审。如果由于时间限制或者风险很低而决定放弃某类测试，那么测试人员就不应该对此承担责任。只有对可能发生的问题有充分的了解，才能接受这种风险。
有效性也可以通过检查缺陷的文档化方式进行评估，缺陷报告中包含了足够的细节使开发能够重现问题，还是需要开发人员花大量时间才能重现缺陷？必须制定一个详细描述在缺陷报告中需要哪些信息的标准，同时还要充分交流和理解缺陷追踪的生命周期。所有测试人员必须遵从这些标准。
在对测试人员的评估过程中，发现问题，都应该确定问题的原因并找到解决方案。对一个测试人员下结论之前，必须先仔细评估每个问题，认真评估了所有因素并且提供了针对性的附加培训后，才能对测试人员的具体发展方向、分析能力和有效性等方面做出评价。如果我们确定了一个测试人员不注意细节、缺乏分析能力、不善于沟通，那么这个测试人员的表现就应该受到严密的关注和检查，并可还可能需要进行更多的指导和培训，或采取其他恰当的步骤。

要确保测试工作成功完成，就必须不间断的对测试人员的有效性进行评估。

3，测试工程师的自我评价

测试有责任评估自己的有效性，下面列出的问题可以作为制定自我评价的参考。我们假定测试已经理解了分配的任务、角色、职责。

• 关注发现的缺陷类型，发现的缺陷重要吗？或者还是大部分是外观上的、低优先级的缺陷？如果测试人员总是只能发现低优先级的缺陷，那么就需要重新评估测试过程的有效性。
• 测试过程足够详细吗？是否覆盖了发现高优先级的缺陷所必须的深度以及数据和基本功能的组合与变化？是否同时包含了对非法数据和合法数据的测试？
• 是否听取了来自需求人员、开发人员和其他测试人员对测试过程的反馈意见？如果没有，那么测试应该请求这些小组对测试过程进行评审、审查和走查。
• 为了挑选最有效的测试过程，测试是否对可以利用的测试技术（如等价类、正交排列）有足够充分的了解？
• 测试是否对应用程序功能的实质和行业领域有足够深入的了解？如果不是这样，那么测试人员应该加强总体了解并另外接受培训，可以向行业专家请教。
• 是否主要缺陷在测试生命周期中发现的太晚了？如果这种情况经常发生，那么应该重新考虑 下面的要点：
  • 测试工作的开始阶段是否集中在低优先级的需求上？测试工作的初始阶段应该关注高优先级高风险的需求。
  • 测试工作的开始阶段是否集中在对已交付的功能的回归测试上？而这些功能此前一直运转正常？
  • 测试工作的开始阶段应该关注代码修改、缺陷修正和新功能。
  • 回归测试应该晚些时候再进行。理想下，回归测试工作最好自动执行。
• 是否某些正在测试的部分中发现的缺陷少的令人惊奇？如果这样，那么应该重新评估这些部分，来确定：
  • 测试覆盖的内容是否足够全面？
  • 正在执行的测试类型是否是最高效的，是否遗漏了重要的步骤？
  • 正在测试应用程序部分的复杂度是否很低，缺陷确实很少？
  • 功能的实现方式是否不可能留下重要缺陷？例如：编码工作由高级开发人员完成并通过了单元测试和集成测试。
• 考虑缺陷处理的工作流程：
  • 每个缺陷都应及时形成文档。
  • 必须遵守生成缺陷报告的标准。标准中必须列出生成缺陷文档所需的全部信息，以确保开发人员可重现。
  • 如果拿到一个新版本，那么测试应该先集中返测以前出现的缺陷。
  • 应该不断评估开发组对缺陷报告的意见。
  • 测试应该积极的追踪缺陷直至解决。
• 检查附在缺陷文档上意见，这样可以确定开发人员和其他测试人员对它的接受程度。如果缺陷报告经常标注 “工作正常” 或 “无法重现”，那么可能也表明存在下面一些问题：
  • 测试人员对应用程序理解的可能不充分。
  • 需求可能不够明确。
  • 测试撰写文档的技能可能离要求还有差距。
  • 开发人员可能误解了需求。
  • 开发人员可能缺乏耐心来按照详细的缺陷报告重现缺陷。
• 当产品转入生产阶段以后，测试应该密切关注自己负责的部分是否发现了缺陷。如果有这样的问题，那么应进行评估来确定其楼王的原因：
  • 测试人员是否放弃执行了一个可能发现缺陷的测试过程？如果是这样，为什么会忽略这个测试过程？回归测试是自动执行的吗？
  • 是否没有测试过程能发现这些缺陷？如果是，原因是什么？是不是认为这个部分分线很低？此时应该重新评估测试过程的创建策略，并应该在回归测试中添加一个用来发现这种问题的测试过程。测试人员应该和同行或测试经理讨论如何建立更加有效的测试过程，包括测试设计、测试策略、测试技术。
  • 是否由于时间的关系没有执行一个现成的测试过程？如果是这样，那么应该在应用程序上线前，而不是上线后通知管理层。此类问题也应该在测试结束以后，上线之前的会议上进行讨论，并写入测试报告。
• 其他测试人员在他们的工作中是否发现了属于某位测试人员负责的缺陷？如果是，那么这位测试人员应该查找原因并进行相应的调整。

本文章援引《Effective software testing》一书内容，为个人读后笔记，特此声明