大师总结的很有禅理

嗯，分情况考虑的做法都是合理的，用例也是工具，更好的借助这个工具来保证测试覆盖率就是可行的。

嗯，现在我们都是用脑图写测试点了，如果思路清晰，写起来还是很快的，另外注意下，如果 UI 特别多，优先写逻辑部分用例，UI 部分可以用截图代替。

说完记得告诉大家你老大的反应，哈哈哈哈哈哈哈哈

是滴是滴，好记性比如烂笔头，我还是倾向要写测试用例的

你这么说，我可就当真了哈

站在巨人的肩上咱们可以看的更远

谢谢支持

向前辈学习

你这么说我写的更带劲了

前两个问题没看懂
第二三个问题，目前我们的情况是这样的：「特别是测试过程中如果发现一些提测说明中没有提到的修改点的问题时」

欢迎提供好的建议供参考，多谢多谢

嗯嗯，大部分需求的问题都会在用例评审之前完成，之所以在用例评审时还做，一方面是加强项目负责人对需求关注的意识，让他知道如果前期没做好，评审时被挑战会很痛苦，另一方面是从其他人角度去对需求进行补充完善。

结果不是唯一目的，还有一个目的是过程中大家的头脑风暴。

好好发挥，多好的机会不要浪费了

这个……部分公司会开放这个权限，但不是所有公司都是这样的

能有代码权限去获取自己需要的信息，这是最好的支持了，很给力

欧耶，谢大佬支持

混 TesterHome 必然是货真价实的测试啦

嗯嗯，学校是放到最后面的教育经历部分来写了~~~

恒捷看过我之前的文章呀，高兴~~~

很赞同你关于简历的观点，支持~~~

之前没人给我反馈过正反例的格式好，好忧伤，后面我继续按照那种方式来写哈，非常感谢支持~~~

嗯嗯，我本来特意不给模版的，看来还是有例子更具体哈，我后面补上

非常感谢