#1 楼
Mindmap与企业所有者一起使用该应用程序的所有高级功能。与利益相关者（例如用户，开发人员，经理和发起人）一起浏览地图。与一些关键人员进行风险评估，也许还根据缺陷报告分析易碎区域。首先为最高风险功能编写自动化的快乐路径测试。
创建测试自动化债务积压，与利益相关者优先处理
同时编写自动化测试还可以解决过去的关键缺陷。
培训开发人员编写针对新功能的自动化测试，以填补缺失测试的空白。
#2 楼
您可以从两个方向解决这个问题。您可以接受这些错误，并询问打开这些错误的人如何重现它们。有您的测试用例。您可能可以立即针对这些错误立即开始自动化回归测试。或者您可以只根据自己的文档和SUT编写测试用例。也许有一个业务能力图，您可以为其编写快乐的路径测试，或者您有带有可接受标准的用户案例，可以为其编写测试用例。或者您通过SUT看看它应该怎么做。
我通常采用这样的方法，即测试代码是测试用例，使用BDD框架，您可以更轻松地创建可读性强的测试用例。并为开发人员和管理层所理解。
结论：
自己编写测试用例，专注于错误回归和愉快的道路。使用BDD框架编写测试用例。从了解功能并创建bug的人那里获得帮助。
另请参见：xunitpatterns文章。
#3 楼
测试自动化与您可以自动化的测试案例无关。这是关于您决定测试自动化策略的。我写了一篇博客文章，其中包含几个链接和想法，从哪里开始。主要思想是从战略开始：您要自动化什么，要收集什么样的信息，如何知道您自动化了正确的事情。如果没有战略就实现自动化，那将是技术上的负担。希望对您有所帮助。评论
感谢您声明您链接的博客文章是您的。还请在您的答案中总结帖子的要点，以便在此处提供要点，但您的帖子会添加参考和建议。
–凯特·保罗（Kate Paulk）
19年4月30日在11:48
@KatePaulk更新完成。我也可以将这些链接放在这里。似乎这里的人不喜欢我的博客。
– kriscorbus
19年4月30日在21:01
#4 楼
如https://sqa.stackexchange.com/a/38917/8992
中所述，详细了解域
捕获现有功能使用诸如Cucumber或RSpec之类的工具对其进行记录
进行英语描述的真实测试
创建冒烟，高兴和悲伤的案例
评论
测试代码的+1应该成为测试用例，请确保它们是可读的。
– Niels van Reijmersdal
19年4月30日在7:28