之前说了太多的测试技术和测试用例设计方法，猛地发现有点“偏科“了。今天我们放松一些，泡一杯茶，一起来聊一聊测试策略吧。

　　当然，文章脉络肯定是咱们老三样：什么是测试策略，为什么要制定测试策略，怎么制定测试策略。

　　什么是测试策略？

　　在中文的解释里，策略也可以叫做计划、谋略，是可以实现目标的方案集合：

　　首先，有一个确定指向的目标；

　　其次，是一个方案的集合；

　　再次，是灵活可可变动的。

　　所以，我们所说的测试策略，简单来说，可以归纳为：测什么、怎么测。

　　“测什么“是目标，“怎么测”是方法。那么，我们为什么要制定测试策略呢？

　　为什么要制定测试策略？

　　首先，制定测试策略能够帮助测试团队更清楚测试目标，从而更好地判断测试结果、产品质量是否达标，判定产品是否可以发布。

　　其次，对于测试管理来说，制定测试策略能够帮助测试管理人员更好地实现风险管理。

　　清楚测试目标和测试方法，能够让测试管理人员更好地实施基于风险的测试。并且测试策略可以与开发/测试过程进行融合，更好地在子阶段选动态选用测试策略。

　　不仅如此，还能帮助测试人员更深入地理解测试技术/手段/工具地差异性，在测试过程中选用更好地测试方法。

　　总的来说，测试策略是可变的，根据不同场景地变化，具有明确或具体的测试目标。测试策略是为了效益最大化，在有限的条件下选择最适合的测试方法。

　　怎么制定测试策略

　　测试策略需要考虑哪些因素

　　项目环境

　　代表了一组上下文因素，包括项目中的资源、约束条件等，主要包括以下内容：

　　任务，你需要为客户解决的问题。

　　问问自己：为什么要测试？你知道谁是你的客户吗？你的客户或者其他人对你的测试任务有什么样的想法？

　　信息，关于测试所需的产品或项目的信息。

　　问问自己：我们可以咨询谁来了解这个项目？有工程文件可用、用户手册、基于web的材料、规格、用户故事，这个产品有历史版本吗？有哪些遗留的问题？

　　以及你的测试版本是最新的吗？你是如何得知新的或变化的信息的？有没有类似的产品或项目可以让我们收集到重要的信息？

　　开发者关系，你如何与程序员相处，这取决于你有疑问能不能很快且良好地得到解决。

　　问问自己：你是否与程序员建立了友好的工作关系开发人员对你的测试策略有什么看法？

　　测试团队，执行或支持测试的任何人。

　　问问自己：你知道谁将参加测试，他们是否拥有所需的知识和技能？

　　“测试团队”中是否有可能提供帮助的人，那些之前测试过类似产品的人可能会有什么建议，作家、用户、程序员？是否有特定的测试技术，团队中有人有特殊的技能或动机去执行？

　　设备和工具，管理测试所需的硬件、软件或文档。

　　问问自己：是否拥有测试所需的所有物理或虚拟硬件，是否拥有能够自动控制和观察产品行为的工具，是否拥有创建测试数据、设计场景或分析和跟踪测试结果的工具，是否需要任何文档来跟踪或记录测试的进展？

　　时间表，项目事件的顺序、持续时间和同步。

　　问问自己：

　　测试设计：你有多少时间进行测试？

　　测试执行：何时执行测试是否有一些测试是重复执行的，比如，为了回归目的？

　　开发：构建何时可以用于测试、添加功能、冻结代码等？

　　测试项目，要测试的产品。

　　问问自己：

　　范围：产品的哪些部分在你的测试职责范围内，哪些部分不在？

　　可用性：你有要测试的产品吗，你们有可用的测试平台吗？

　　波动性：产品是否在不断变化，如何针对这些变化进行测试？

　　新功能：你知道最近有什么添加到产品中的新功能吗？

　　交付，测试项目的可观察产品。

　　问问自己：

　　内容：你需要做什么样的报告？

　　目的：你的可交付成果是否作为产品的一部分提供，还有其他人帮你做测试吗？

　　标准：你是否有一个特定的测试文档？

　　产品元素

　　涉及产品的各个方面，包括产品固有的方面以及产品与外部事物之间的关系。主要包括以下内容：

　　结构，构成实体产品的所有东西。

　　例如代码、硬件、非执行文件、附属品等。

　　功能，产品所做的一切。

　　例如应用、时间相关、安全相关、启动/关闭、错误处理、交互作用等。

　　数据，产品加工的所有东西。

　　例如输入/输出、预置、持久化、相互依赖/相互作用、无效/噪声、生命周期等。

　　接口，每一个产品被访问或表达的管道。

　　例如用户界面、API/SDK、导入/导出等。

　　平台，产品所依赖的所有东西(以及项目之外的东西)。

　　例如外部硬件、外部软件、嵌入式组件、产品足迹等。

　　操作，如何使用产品。

　　例如用户、环境、常见使用、错误使用、极端使用等。

　　时间，产品和时间之间的关系。

　　例如输入/输出、快/慢、改变速率、并发性等。

　　质量标准类别

　　评价产品质量的标准，例如可靠性、稳定性等，它是主观的、多维的。主要包括以下内容：

　　能力

　　问问自己：它能执行所需的功能吗，它执行的结果正确吗？

　　可靠性

　　问问自己：它会在所有需要的情况下都能很好地工作并抵抗失败吗 ？

　　测试要点如：

　　健壮性：在合理的条件下，产品可以持续运行一段时间而不退化。

　　错误处理：产品在错误的情况下能够抵抗失败，在失败的情况下能够很好地恢复。

　　数据完整性：保护系统中的数据不丢失或损坏。

　　安全性：产品不会出现危害生命或财产的故障。

　　可用性

　　问问自己：一个真正的用户使用这个产品有多容易。

　　测试要点如：

　　易学性：目标用户可以快速掌握产品的操作。

　　可操作性：产品可进行复合操作。

　　易访问性：产品符合相关的标准，并符合O/S易访问性特性。

　　外观性

　　问问自己：产品有多吸引人？

　　测试要点如：

　　美学：产品吸引感官。

　　独特性：产品在某种程度上是新的或特别的。

　　必要性：产品具有用户期望的功能。

　　实用性：产品解决了重要的问题，而且解决得很好。

　　入迷：用户在使用产品时被吸引住，获得乐趣，完全沉浸其中。

　　形象：产品表现出期望的质量印象。

　　安全

　　问问自己：产品如何防止未经授权的使用或入侵？

　　测试要点如：

　　认证：系统验证用户权限操作正确。

　　授权：通过认证的用户在不同的权限级别上被授予的权限。

　　隐私：保护客户或员工数据不受未授权人员侵犯的方式。

　　可伸缩性

　　问问自己：产品部署的规模是扩大还是缩小 ？

　　测试要点如：产品可以扩展或收缩部署。

　　兼容性

　　问问自己：它与外部组件和配置的配合情况如何？

　　测试要点如：

　　应用兼容性：该产品与其他软件产品协同工作。

　　操作系统兼容性：产品适用于特定的操作系统。

　　硬件兼容性：该产品适用于特定的硬件组件和配置。

　　向后兼容性：产品与自身的早期版本兼容性。

　　性能

　　问问自己：它的速度和响应速度如何?

　　可安装性

　　问问自己：

　　系统要求：产品是否识别出某些必要的组件缺失或不足？

　　配置：系统哪些部分受安装影响，文件和资源存储在哪里？

　　卸载：当产品卸载时，是否干净地卸载？

　　测试技术

　　决定了测试人员如何、何处以及何时应用特定技术需要对项目环境、产品元素和质量标准进行分析。主要包括以下内容：

　　功能测试，测试它能做什么。

　　确定产品可以做的事情(功能和子功能)，确保每个子功能都做了它应该做的事，而不是它不应该做的事。

　　域测试，分治数据。

　　寻找产品处理过的任何数据，既要看输入，也要看输出；

　　决定使用哪个特定的数据进行测试，考虑边界值、典型值、方便值、无效值或最佳代表；

　　考虑值得一起测试的数据组合。

　　压力测试，压倒产品。

　　寻找那些在具有挑战性的数据或受限的资源存在时容易过载或“崩溃”的子系统和功能；

　　确定与这些子系统和功能相关的数据和资源；

　　选择或生成具有挑战性的数据，或资源约束条件来测试。

　　例如，大型或复杂的数据结构，高负载，长时间测试运行，许多测试用例，低内存条件。

　　流测试，做一件又一件事。

　　执行端到端连接的多个活动；

　　不要在两次操作之间重置系统；

　　改变时间和顺序，并尝试并行线程。

　　场景测试，测试一个引人入胜的故事。

　　首先考虑产品周围发生的一切；

　　设计测试，包括与产品有意义和复杂的交互。

　　需求测试，确认每一个需求。

　　确定参考材料，包括关于产品的声明(默示或明确)，考虑规范、帮助文本、手册等；

　　分析个人需求，澄清模糊的需求；

　　测试关于产品的每个声明；

　　如果您正在从一个明确的规范进行测试，那么期望它和产品保持一致。

　　用户测试，让用户参与进来。

　　识别用户的类别和角色；

　　确定每一类用户将做什么(用例)，他们将如何做；

　　获得真正的用户数据，或者让真正的用户参与测试；

　　强大的用户测试涉及多种用户和用户角色，而不仅仅是一个。

　　风险测试，想象一个问题，然后找到它。

　　想象产品会有哪些问题，哪一种最重要？关注这些，列出一些有趣的问题，并专门设计测试来揭示它们。咨询专家、设计文档、过去的错误报告或应用风险启发式可能会有所帮助。

　　自动化测试，编写一个程序来生成并运行无数的检查。

　　寻找或开发可以执行许多操作和检查许多事情的工具；

　　考虑部分自动化测试覆盖率的工具；

　　考虑部分自动化oracle的工具；

　　考虑自动变更检测器；

　　考虑自动测试数据生成器。

　　如何将测试策略实体化

　　测试策略转化为测试活动，通过测试策略确定的测试活动，并拆解为一个个测试任务嵌入测试计划，才能将测试策略有效实体化。

　　例如，测试策略S确定了测试活动A1、A2，A1和A2拆解出测试任务T11、T12、T13，和T21、T22。为测试任务分配测试责任人和测试工期，最终成为一个完成的测试计划。

表1 测试策略实体化，最终形成基础测试计划

　　由上所述，本文简单讲述了测试策略的含义、意义以及制定测试策略需要考虑的元素和测试策略的实体化。

　　希望能帮助大家对测试策略有个更全面和清晰的认识。

　　测试进阶

　　在智能驾驶发展得如火如荼的今天，软件测试行业也随之衍生出车载测试的岗位需求。对比其它在招岗位，车载测试的薪资也更加可观。

作者：刘晓佳Rachel    

来源：http://www.51testing.com/html/31/n-7796231.html