优秀！之前是手机调了闹钟～但是容易不在位置上嘈到别人，无奈 iOS 的定位触发快捷指令也老是不生效，后来做了一个定时触发自动打开打卡软件的指令，得手机解锁情况下才能打开
现在再加上这个～再漏打卡就要深刻反省了。

我的想法跟你有点像耶，我目前看过的脑图用例都是很多内容都被忽略，输入、前提都需要是对业务熟悉的人才能读懂，再要求写详细就不如写标准用例了

目前也有这个困惑，因为我一直都是习惯编写标准用例。
目前算是带 2 个组员吧，测试经验都是一年多，他们毕业以来的习惯都是使用脑图，跟我之后我要求都写标准用例。项目更多是活动类型，活动过了就过了。但是后续可能会有相似的形式，我是觉得标准用例也是有复用意义的。现在有人提出标准用例写得太乱了，希望用脑图更直观简单。虽然理解，因为这种一次过的形式我就让他去尝试，但是这种用例写出来在我看来就像一个测试点，就是熟悉业务的人能看明白。对于一些耦合、递归、循环的场景相互之间的关系，人觉得不能表达得很好，但是每次测试结果过去了就过去了，没有什么大问题也不会有人在意。

可能在编写者角度，对于项目业务本身的测试是基本工作目标，不需要特别提出。
反向其实还需要看项目本身对测试是否足够重视了，如果项目只求稳定、能用、基本符合需求就行，测试很多细节或者业务逻辑的实现是测不下去的，容易失去对业务、项目的执着。这部分需要产品、开发共同配合推动。
「玩点花样」是指接口自动化、UI 自动化么？ 这不算花样吧，对于已经固定下来的交互自动化是很有好处的，这也算是项目本身有益的事情。当项目功能模块增加，每次迭代都需要人工回归测试不是一个好事，自动化有助于提高测试效率，更多时间专注在新功能的测试。
不 “玩点花样”，老老实实测项目～项目稳定运行，实现需求，这不就是个好成绩了么？但是又会被认为没什么成绩？