问
如何使用Microsoft的RSAT进行自动测试
答
Azure DevOps 和Team Foundation Server (TFS) 提供了基于网页的手工测试方案。Azure Test Plan 或者Test hub 可用跨平台跨浏览器使用；替代了原有的基于客户端的测试工具Microsoft Test Manager。RSAT (全称 Regression suite automation tool ) 通过结合 DevOps 中的 test plan 和系统操作步骤录制工具Task recorder，来实现自动测试。使用Task recorder录制的操作步骤，配以可编辑的数据和参数，提供自动测试系统功能和流程，并同时在DevOps中监测和返回测试结果。
在标准文档中，微软建议RSAT可用于UAT阶段的测试。但实际项目经验中发现，在UAT阶段影响测试步骤的功能开发仍然在继续，关键配置仍然在不断的变化；每一次微小的变化都会导致自动测试失败，需要重新录制测试步骤、编辑参数文件和重新生成可执行文件；这些调整所花费的时间成本和人力成本，更胜于手工测试。笔者建议RSAT使用在标准功能演示环节。在标准环境使用依据系统标准步骤录制好的工具，只需要稍微调整参数文件中的数据就可以跨项目使用录制好的工具，重复利用率比较高。其次，系统上线完成后每年微软更新D365版本时的系统测试也是一个很有效的适用场景；此时系统功能、系统流程、系统配置数据、主数据基本定型；可用重复使用已经录制好的测试步骤，利用率非常高，而且能轻易的监测出升级后的功能影响正式系统流程的新功能点。
////
使用RSAT测试前的准备
使用RSAT进行自动测试之前，对普通用户而言，需要先准备好DevOps, D365, 和RSAT。当管理员在DevOps中配置好RSAT后，测试人员需要在DevOps中有用户账号，并被授予Test Plan的使用权限，同时需要建立该用户账号的DevOps token。在D365中该账号需要有D365的访问权限，并授予测试流程涉及到的模块的权限；如果涉及到审批流程测试，还需要设置用户到相应的审批用户组。在RSAT官网上下载最新版本的RSAT安装包后，需要导入证书, 提前准备好证书和密码；lifecycle的管理员能够在lifecycle界面中进行生成和下载证书。
////计划RSAT自动测试
现在可以为测试做一些更具体的计划。
首先，确定哪些功能和流程可以使用RSAT进行测试；通常大部分的功能和流程都可以使用RSAT进行测试，但有些特殊的情况并不适用。
RSAT并不能很好的识别页面中的某组件中的数据。如左右选择列表，RSAT在运行时无法复现选中在录制时选择的数值。比如，在添加用户到用户组的例子中，RSAT运行时，并不能复现选中录制时选中的用户，而只会选中默认的选项；如果需要向下拉列表，用户才能出现在列表中，RSAT并不能重复下拉的动作。
测试目的是验证大量数据的准确性的测试，也不适合适用RSAT。比如报表测试时，运行报表，设置报表参数界面的参数可以使用RSAT进行完成。但是验证报表的输出的数据，却是RSAT无法实现的。RSAT可以简单的验证界面上某些字段的值，但是对报表中的数据验证，RSAT暂时无法实现。
需要与windows互动的流程，RSAT不能支持。例如，测试时需要导入文件需要在对话框中选中某个目录下的一个文件。RSAT并不能重复文件夹和文件选中的动作，也不支持直接把文件路径和文件名当作参数，因此无法自动完成文件选中的动作。
其次，以测试目标为基础，对需要测试的流程和功能，设定好需要测试多少种场景；每个场景需要被录制成哪几个test case，哪些test case可以在不同的场景中重复使用。
在测试销售报价的功能和流程时，可能需要测试一份报价被提交审批并审批成功的场景，另一份报价被审批人员拒绝的场景，第三份报价被提交人撤回场景。其中每个场景都包含的提交审批的过程，这个过程就可以只录制一个test case，并在三个场景中重复使用。
最后，检查并准备测试环境中的数据。
在测试环中，必须具备充足的主数据和业务数据，系统配置数据来支撑流程测试。
////
使用Task Recorder录制适用于RSAT的测试步骤
使用Task Recorder，能非常方便的录制并保存测试步骤。而RSAT 并不能复现所有的用户操作，这里总结一些实际项目中使用到的小技巧。
首先，在录制时确保所有页面都使用Standard view，因为RSAT并不能重现切换view的动作。如果录制的时候使用了自定义的view，那些只出现在自定义的view的字段，在RSAT运行时，并不能被识别到。
其次，在列表中要选中某一条记录时，RSAT并不能像人眼一样，智能的在列表中“看”到并选中要操作的行。常用的方法是，使用“is exactly”过滤列表，使列表中只剩下需要操作的行，然后就行操作。如果，需要过滤的字段未显示在列表中，可以使用advanced filter功能完成过滤。
第三，RSAT貌似有bug， 在多次关闭和打开新的页面后，RSAT不能识别并报错。建议一个test case里面不要打开新的page不要超过2次。页面的退回功能也要慎用。
第四，录制步骤时，task recorder 允许无数次删除步骤再重新录制剩余步骤。但是RSAT在编辑含删除操作的步骤时，容易出现步骤混乱。特别是，一个test case含两次以上的删除后，编译出来的执行文件很多情况下都不可使用。
第五，尽量保持一个test case的步骤简洁明了。好处是避免因过于发杂而导致的重复的录制，而且简单的test case 被不同场景使用的重用率比较高。
////
RSAT 参数文件设置技巧
RSAT 标准文档中已经总结了很多的参数设置技巧。这里强调几个项目中常用的参数。
Test User ：可以不设置用户，默认问空时，执行RSAT的用户将使用自己的账号来运行测试步骤；这要求执行RSAT的用户必须拥有D365的所有相应权限。设置用户的好处是，执行RSAT的用户，可以使用以其他的角色来运行RSAT。另外，在审批流程中，提交人，审批人通常是不同的用户；可以分别录制提交人的test case，和审批人的test case, 并在各自的test case中设置好相应的用户。这样一个人也可以使用RSAT完整的执行整个审批流。
Pause ：在某些步骤执行后，需要等待系统完成该步骤的程序， 在Pause设置等待时间。这种场景下，如果不设置等待时间，系统会报错。
Validate : RSAT提供了验证数据值的能力。Validate操作配合Operator，可以灵活第检验数据值，如是，否，或者具体的某个值。
////执行RSAT并监测测试结果
RSAT的执行结果，只能在DevOps 中查看。执行时，建议勾选一个场景的所有Test Case。执行完成后，回到DevOps 查看详细的执行结果。
DevOps 中可以查看明细的执行步骤结果，和失败原因。
作者：喻大玲
审核：梁 超
编辑：朱思聪
