测试计划启发
|
启发 |
基础启发 |
|
1、测试应该被优化以便更快地找到问题，而不是尝试用相同的优先级去把所有问题找出来 |
问题发现得越迟，在ship date之前安全地修复问题的风险越高。 |
|
2、测试策略应该主要专注于潜在的技术风险，同时还要关注低风险的区域，预防出现错误的风险分析 |
完全的测试是不可能的 |
|
3、测试策略应该指明测试的平台配置，产品怎样操作，产品怎样观测，怎样评估产品 |
忽略这些方面可能造成一些重要的问题不被发现 |
|
4、测试策略应该根据测试技术和方法变化。评估测试覆盖的方法应该考虑覆盖的多维性，包括结构、功能、数据、平台、操作方式和需求等 |
没有一项测试方法能发现所有重要问题，我们也永远不能确信我们是否发现了所有问题。测试策略的多样性可以减少单一测试方法只发现特定类型的问题的风险。 |
|
5、测试策略应该指明测试数据怎样设计和产生 |
测试策略通常围绕功能和代码来组织，让测试员在测试时再考虑与数据连接。那通常意味着测试策略过于关注功能的验证，而忽略了可靠性。 |
|
6、并不是所有测试都需要详细地预先指定。测试策略应该让测试员充分考虑环境因素去推理，转注于重要的但非预期的问题。 |
在不冒犯基本的覆盖的前提下，鼓励测试的合理变化，例如，与哪个结果交互，探索性测试，增加偶发的测试覆盖 |
|
7、针对隐含的需求进行测试 - 需求所蕴含的，而不仅仅是需求所说的 |
只是针对所写的需求进行测试是揭露不了重要问题的，因为需求的定义通常是不完整的，自然语言通常是容易引起误解的。 |
|
8、测试员应该尽可能与开发人员、技术支持人员和技术文档编写人员多交流，还应该多与真正的用户和客户多接触以便更好地理解需求 |
其他组员或利益相关方通常有很多对测试非常有用的关于产品的问题或潜在问题的信息 |
|
9、测试员应该多请教开发人员以便帮助他们构建可测性更强的产品 |
测试策略的有效发挥有赖于产品的可测试性 |
|
10、测试计划应该强调非常规的、项目特有的测试策略和测试项目的方面 |
不要让测试计划看起来跟测试模板没什么两样 |
|
11、测试项目应该在人手测试做得好的地方使用人手测试，在自动化测试做得好的地方使用自动化测试。手工测试应该应用在需要思考的地方，自动化测试应该应用在需要高度重复的地方，需要快速进行的地方，不怎么调整的地方 |
手工测试和自动化测试是两种完全不同的测试方法 |
|
12、测试时间表应该体现与开发进度的依赖关系，产品的可测试性，报告问题所需的时间，风险的评估 |
测试不是独立的活动。 |
|
13、测试进度应该尽可能保持独立于决定性的路径。这只能通过测试与开发工作并行，测试员发现错误的速度尽可能比开发人员修复的速度快 |
这对于为了减轻压力而裁剪测试过程来说非常重要 |
|
14、测试员与开发人员之间的反馈周期应该尽可能紧密。测试流程应该设计提供一个快速反馈的机制，让开发人员反馈关于最近新增功能和所做的改变，在一个完整的回归测试开始前测试员应该获取这些信息 |
这对于最大化质量改进的速度和效率来说非常重要。 |
|
15、测试项目应该获取关于质量的信息以便帮助评估和调整测试项目，不仅仅通过正式的测试渠道，还可以通过审查、beta测试、测试组以外的非正式测试 |
防止正式测试所采用的测试策略不能发现的盲区 |
|
16、与测试策略相关的文档，包括测试用例和测试方法应该通过评审 |
通过评审揭露测试设计的盲区，还能互相学习和提高 |
