云工作术
各类应用演示
案例故事
逃离恶梦
关于 Ragic
初步创建好数据库，功能都有了，可以喜孜孜上线给大家用了吗？等一下！在“做好功能”跟“正式启用”之间，别漏了一个重要的步骤——它叫做“上线前测试”。
仅管你很可能不是工程师，但当你用 Ragic 创建一张张的表单、设计出表单链接关系、单击钮、公式时，你其实就是在“开发信息系统（开发软件）”了，而“测试”其实是软件开发到上线之间不可或缺的流程。
为什么需要测试？就像做菜端上桌之前要先试口味一样，你可能会在煮汤时舀一小口试喝、炒肉时切一小块试吃，确认做出来的菜符合预期，没有不小心少放了盐、炒不够久，不合预期的话可以马上调整。如果菜都上了一桌、大家都坐好准备开始吃才发现汤味道不够、肉也没熟，那不只扫兴，这时才重新处理这些菜也很麻烦。
信息系统也是一样，我做的表单、功能到底能不能如同预期地运转？有没有设计错了或考量不周全的地方？如果没有跑跑看、甚至新增一些测试数据，用其他用户（非系统管理员）的视角、实际操作的逻辑跑过整个流程，其实很难知道。
即使相较于其他信息系统，Ragic 非常弹性好调整，可以“边做边改”，但先透过测试确认某些东西真的可以运行、排除基本问题，尽量让用户从比较好的体验开始，还是有其必要。
数据库整体大致设计完毕、还没“正式上线使用”之前，该做测试。但除此之外，在 Ragic 其实你随时可以测试：每次设计完一个功能，例如一组公式、一个单击钮、一组链接与加载、一个提醒或寄信功能......，设计保存之后，都可以顺手新增数据，测一下这个你刚做出来的“单一功能”是否合意。等到一切大致完成要上线之前，再做一次整体的测试。
这边要提到一个我们常常跟 Ragic 订户沟通的观念，就是不一定要强求“一次到位”。假如你还不熟悉 Ragic，想从零开始在 Ragic 建置的应用有非常多不同类型（例如想管一点人事数据、派工单，也想做一点设备管理、库存扣减，又想有一张专案预算管理的表单），那并不需要一次就把所有类型的表单、所有设想中的功能都做好。
可以在确定大概体系结构后，先选择一部分比较好入手（或最亟需改善流程）的区块开始设计、导入，让大家试用并调整后再慢慢拓展到其他应用，这样比较容易掌握状况 / 比较容易测试。
——当然，这个“不一定要一次到位”，也要配合表单体系结构来考虑，体系结构上会有密切关连/依存的一组表单，还是最好一开始就一起考量/设计，以免未来修改牵一发动全身。举例来说，你想要导入人事、行政管理、订单管理的应用，其中订单处理最迫切，那么可以先设计订单管理应用，以免开太多战场，但订单管理应用上一开始就设想好要相互链接的表单最好一开始就决定与设计好。
我们特别建议表单中的链接字段最好一开始就设计好，因为在表单中已经有数据后，错误变更链接字段，可能会造成数据遗失或是被替换成错误的数据。如果真的在第一波设计时没想到某些地方，日后要修改链接字段，也请务必先将该张表单的数据汇出来备份、或做整份数据库备份，以防万一。
不过，如果是一些其他的进阶字段设置（例如条件式格式），或自动化流程的设计（自动寄信、单击钮、公式），那就不一定需要一次到位，可以在体系结构阶段厘清最简单必要的基本功能是哪些后，把基础、好上手、逻辑不那么复杂的流程设计出来，有比较稳定的使用习惯后，再从一个一个小地方调整。
在 Ragic，因为修改调整的门槛低，数据库不需要一次建置定生死，建置、测试、使用、调整、扩大，可以是动态周期的流程，这样可以根据用户回馈或公司需求（规模）的更动而弹性调整。只要每一次的调整上线前，搭配完善的测试、完善备份原有数据，就可以减少潜在问题。
环境与资源准备好了，有些人可能还是没头绪，不确定测试流程上实际到底怎么走比较好？其实可以绕回到简单的大原则，既然测试是为了避免“实际使用时发生不如预期的状况”，那么，最重要的就是像演习一样，走一次实际运作的流程、把遇到问题的地方抓出来。
除了前面提到的：“设计完一个小功能，就可以顺手测试一下该功能是否确实能运作”，确认单一功能运作都没问题，设计完全部表单之后，最好也从默认中的用户角度，模拟实际流程，从新增数据、点击链接加载、抛转等...依序跑过一次，看看是否运作正确。
一方面，这样实际走过一次流程，可以抓到设计时可能遗漏的“功能与功能之间的衔接问题”（例如设计了“更新别张表单字段值”后触发目的表单公式的流程，有可能“更新别张表单字段值”和“目的表单公式”设置都没问题，却没考虑到若想“透过更新别张表单字段值来触发公式”，情况跟“手动在目的表单上修改数据触发公式”情况不同，需要在“进阶设置”中做相关勾选）。
另一方面，模拟走一遍实际使用的流程，也可以测试出一些“非关功能”的使用体验，例如用起来是否直觉、是否顺手、默认中的用户是否能领悟如何使用。如果功能没问题，但用起来卡卡的、体验不顺，也可以考虑要不要调整。
先前体系结构数据库雏形的教学文章提到“绘制流程图”的方法，如果在建置数据时有绘制出对应的流程图，就可以直接依照这个流程顺序，模拟不同的主要角色，依序创建数据，看看有没有什么不顺的地方。
以“招募管理模块”为例，如果我自己设计出了这样一组表单，要完整测试流程时，首先我会把流程图找出来：
然后依照流程图，从“内部提报征才需求”开始，先在“征才职缺提报与进度（内部用）”表单新增一笔模拟的征才需求数据，然后到它对应的多版本工作表：“职缺说明（对外）”表单中确认有没有自动新增一笔对应的数据、此表单有没有不适合给外部查看的字段信息；并且确认以非 HR 的其他部门员工身份登录时，是否确实看不到“征才职缺提报与进度（内部用）”的所有详细数据。
接着，模拟求职者的身份进入“履历表”表单填写数据时，审查先前输入的征才需求在履历表表单中点选“应征职务（征才编号）”时是否有正确出现....，另外，分别模拟“部门联络人”、“面试主管”、“人资”角色的流程，一一确认对应流程。
不管是测试单一功能，或整个走一遍流程时，都可能遇到这样的状况：测出某段流程（功能）好像有问题，但不知道为什么发生问题、导致也不知道怎么修正。
此时，你可以把出问题的流程尽量切成范围更小的一个个环节，一一测试，确认哪个环节没问题、哪个环节有问题，藉以收小问题的范围。
举例来说，假设你设计了一个“最低库存水位提醒”功能，希望系统每天固定时间检查商品库存表中的库存数量，并在库存数量低于表单中设置的“最低库存数量”时，寄提醒信给自己，但测试时发现自己没收到应该要收到的信。
假设这个功能是用类似我们博客这篇教学文的方法，利用 Ragic 的公式、每日公式重算 Workflow、提醒组合而成的话，上述任何一个环节出错，都会造成“没收到信”的结果。
因此，可以先挑选其中“提醒”这个环节，把问题拆解成：是系统寄了提醒信但我没有收到，还是系统根本没寄信？
由于在 Ragic，你可以查看数据库中所有系统信件的寄信纪录（帐号设置 > 数据库维护 > 下载系统记录区块），因此可以先查看这个系统纪录，如果有找到对应的寄信纪录，代表信有寄出，在 Ragic 这边的流程没问题，问题出在收信端（例如挡信、把信归类到垃圾信件夹等）。
而如果没有寄信纪录，代表提醒可能没有触发，这时可以聚焦在“提醒没有触发”的问题，进一步归类问题并分头测试，确认提醒没触发是提醒设置的问题、公式触发的问题、还是公式本身设错了？
例如，手动在“提醒日期”字段输入日期并在“排程管理”手动点击“马上运行提醒”，有正确寄出信件的话，那代表不是提醒功能这边的问题。
同理，如果手动输入（或修改）“最低库存数量”字段值，“提醒日期”字段的公式有正确触发，但利用另一笔数据在“排程管理”点“马上运行 Daily Workflow”没触发公式的话，代表是每日公式运算 Workflow 上的问题。如果手动修改字段值时公式就没有正确触发，那就是公式编写问题，要看看句法是否错误。
这样一步一步的把问题拆解成多个环节，每个环节都排除其他变量（例如尽可能搭配比较单纯的“手动输入数据”方式）来测试，可以比较快收小范围并找到出问题的嫌疑犯。
Ragic 提供了很多“检查目前设置”与“查询历史纪录”的工具，是揪错时的一大帮手。另外，如果多知道一些大家常犯的错误，对找出自己的盲点也有帮助。这两个部分因为细节较多，我们另文介绍，请参阅此篇链接。
怎么做测试呢？在已经有部分表单上线使用的情况下，如果你是想局部新增一些功能，例如加一个公式、单击钮、链接关系......你可以新开一个页签创建测试表单，测试完功能之后，再把新增的设置加在原表单、或将测试表单转换成正式版。
不过，如果你要改动的东西牵涉到比较多表单，不方便在原有数据库里创建那么多测试表单，也觉得“穿着衣服改衣服”不够方便，其实你有另一个“创建测试环境”的方法。
你可以用另外一个 email 登记一个全新的数据库当作“测试环境”，利用 Ragic 备份还原的功能就可以快速将既有数据库的设置备份到这个“测试数据库”，修改、测试完没问题之后，将测试数据库的定义檔（不包含数据的设计体系结构）还原回正式数据库就可以无缝接轨地使用了。
“另外创建测试数据库”的建议步骤如下：
步骤一：登记创建一个新的空白数据库，这个数据库会是之后的测试环境（测试用数据库）。由于一个 email 只能登记一个数据库帐号，不能使用你之前用来登记 Ragic 的 email ，要找一个没有登记过帐号的 email 来另外申请，有需要的话请在这个新的测试数据库申请免费试用 30 天专业版。如果以前已经登记过测试用的数据库，付一名用户（测试人员）的专业版费用直接使用即可。
（备注：我们之后规划推入出更适合创建“测试数据库”的机制，到时这个流程会更方便一些～）
步骤二：利用 Ragic 备份还原的功能，在你原本正式使用的数据库运行手动备份。
建议勾选下方的仅下载数据库定义檔（仅下载数据库的设计框架，不包含数据，文件扩展名为 .ragic）。
备注：如果你希望数据也连带放到测试数据库做测试，且单纯汇出、汇入数据有点麻烦的话，也可以不勾选，代表直接备份完整的数据库（文件附檔名为 .ragicdb），但由于“备份、还原完整数据库”代表原本数据库的一些流程性设置，如邀请用户、提醒信件等也会被拷贝过去，所以得记得后续还原时，要将提醒删除（以免测试环境寄出提醒信件让用户困惑）、将不需登录测试环境的用户停权（以免用户被邀请加入测试数据库衍生困惑）。
步骤三：将下载好的备份文件手动还原到测试数据库。这样就可以用比较轻松的方式，不需要重新创建表单就设置好你的测试环境。
步骤四：在测试数据库中直接新增想要的新功能、新设置、新表单与链接等，完成并测试确认一切 OK 后，在测试数据库中运行手动备份，此次一定要选仅下载数据库定义檔。
步骤五：在正式数据库中上载新的数据库定义檔、还原。这样就可以将新的设计体系结构放进原本的正式数据库，同时保留正式数据库原有的数据。
要注意的是，另外创建测试数据库的情况下，就不要在正式环境也同时都操作设计修改了，以免两边内容不同步而出现问题，详细可能出现的问题请参阅这篇文档。另外，如果你的新设计有包含“新增用户群组”的话，由于群组也是系统表单的表单数据，新增的群组在还原定义檔时并不会自动被还原进来。不过，只要到群组表单中将新的群组手动加入或汇入就可以了。
如果你需要测试的功能跟“权限”有关，例如设置一般用户只能看到自己的人事数据、人资群组的人才能看到完整数据且有编修权限，那么你可能需要创建多个“测试用的用户帐号”，用“一般用户”以及“人资群组”的角色分别登录看看权限设置是否如预期运作。
此时，如果没有那么多 email 帐号可用于测试，该怎么办呢？ Gmail 有一个可以让你“创建分身帐号”的小技巧，在此时就很好用！这部分我们已经有一篇详细的教学文章，请参阅这个链接。
这边再次提醒：测试不同用户身份时，记得使用不同的浏览器，或是打开无痕调页（例如 Chrome或 Safari的无痕模式），以免搞错用户身份喔！
