测试计划与手动和自动化项目有何不同？
对于手动测试项目，成本消耗因素为：
人
工具–测试/缺陷管理
基础设施–环境
时间
训练
对于自动化项目，除上述项目外，还需要支出以下费用：
自动化工具
用于测试管理工具集成的加载项
支持AUT的加载项（如SAP，Oracle等）
框架设置
特定于工具的培训
在这种情况下，自动化项目的成功与否取决于编写代码的程度，编写的可重用组件的数量或达到预期结果的代码行数？
没有。
决定成功的因素是一个，也是唯一的一个问题：“与手动方式相比，您是否能够产生更好的ROI（投资回报率）”？–如果不是立即，最终。
如果该问题的答案为“否”，则说明您对自动化项目的计划不正确。
通常，测试计划包含以下部分。我们将讨论其中每一个，重点关注自动化的特定方面：
自动化测试测试计划部分
第1节：范围
选择要在多个周期之间逐步回归的测试用例/场景。
有时，最简单的测试用例需要大量复杂的解决方案才能自动化。如果这些只是一次使用，显然是没有意义的。可重用性应该是您的重点。
自动化测试不会/不能执行探索性测试。
第2部分： 测试策略
本部分在自动化世界中称为“框架”。有些框架创建起来非常具有挑战性，而且也很有效，但是它们要求时间，精力和能力。始终寻找中间立场，并在不损害资源过度利用的情况下尽力而为。
确定要使用的最佳实践编码，命名约定，要存储的测试资产的位置，测试结果的格式等，以保持一致性并提高生产率。
第3节：资源/角色和职责
朝这个方向迈出的第一步是了解团队的能力，并提前预测图中所展示的自动化范围。这将有助于选择适合自动化和手动测试需求的团队。另外，请选择态度正确的人-那些认为手动测试不在其地位之下的人。
选择一个精通AUT，测试管理，缺陷管理和其他SDLC活动的团队
第1节：范围
第4节：工具
根据以下规则选择自动化工具：
公司是否已经拥有某种工具的许可证，请尝试看看是否可以使用它
寻找开源（但可靠）的工具
团队成员是否已经知道该工具，或者我们需要引进新人吗？还是训练现有的？
第5节：时间
包括时间进行代码演练和检查自动化脚本
及时维护脚本。如果创建的代码段在接下来的6个月左右将不使用，请确保定期维护该代码段，以减少失败的机会。
第6节：环境
AUT将要运行的目标环境和要使用的自动化工具应该兼容。这是应考虑对该工具进行预许可的因素之一。
此外，分析其他可用的管理工具和您尝试引入的自动化工具是否可以相互连接以获得额外的好处。
第7节：可交付成果
您的测试脚本就是您的可交付成果。但是，并不是每个人都精通自动化/编程语言。因此，计划创建一个“操作方法”文档，该文档将帮助当前用户和将来的团队成员即使您不在时也能够理解此脚本。
在脚本中也包含注释。
第8节： 风险
如果要提出自动化解决方案，请确保选择具有成本效益的工具和解决方案，以确保自动化工作不会给项目造成负担。
重要的是要设定一个期望，即自动化项目的ROI不能立即为正，而是可以长期清晰地看到。
因此，如果您建议自动化系统，请选择
稳定且不需要太多维护
具有庞大的回归套件的范围
没有太多的手动干预或不依赖于人类的直觉
第9节：测试数据
考虑数据的安全性
不要将任何测试数据硬编码到脚本中。这只会导致脚本维护过多，并可能在修改过程中引发错误。
要非常具体。对于手动测试步骤-“输入名字”，您可以说输入任意5个字符的名称。在测试期间，测试人员可以键入“ Swati”或“ Seela”或其他任何内容。但是对于工具而言，它不能做这样的假设。因此，提供准确的值。
第10节：报告/结果
脚本执行结果也是技术性的，其他团队可能不容易理解。计划将详细结果写到记事本或Excel工作表中，以作为其他措施。
还需要详细的框架文档，审查结果，缺陷报告，执行状态报告。
作为自动化爱好者，我们可能会认为客户/管理人员不容易购买自动化建议。
但是，当我们的最终目标是通过自动化最大化投资回报率时，我们也与管理层/客户的目标完全一致。这将确保我们不仅能够使我们的项目自动化，而且能够在很多人的同意，合作与兴奋下做到这一点。
欢迎将文章分享到朋友圈
如需转载，请在后台回复“转载”获取授权
你点的每个赞，我都认真当成了喜欢