很现实的三种问题，很实际的三个解决方案，我晚上都是打一局王者转移下注意力才睡……

社区更开放，能听到更多声音，挺好

没想到晋升的话题这么敏感

不是谁一个人说了算哈，评委都是 2-3 人，结论也是大家讨论得出的共同结果，并且都需要提交具体的评价建议的，并不只是给个结果而已啦。

嗯嗯，我们目前使用过程中还没碰到这种情况。

看来是同被坑过

2 个运算符？没看明白……

谢谢点名。

什么是好的测试用例？对于质量的角度来说，覆盖率越全的越好，但是对于回归用例来说，我推荐能发现 bug 的用例就是好用例。

你质疑用例的有效性问题，我理解的是用例设计不到位，才会导致很多 bug 不是通过用例发现的，那么除了发现 bug 外，我们更应该提升我们的用例设计能力，毕竟谁也不会做一辈子执行，不执行就发现不了 bug（保证不了质量），这说不过去吧？

更详细的观点请参考：
到底要不要写测试用例看这篇
通过 bug 来完善自己测试用例设计思路看这篇
怎么体现测试用例的深度看这篇

这个要归类到 TDD 了，个人认为这时候编码能力是最基本的要求了，其他的因为我目前的实践还没有做到这个程度，所以不敢妄言。

嗯嗯，前段时间偷懒了

向大佬学习

好赞

不是的噢，网上搜一下，最近很多人在解释这个概念

支持支持

嗯嗯，找到适合自己的方式才是最好的，没找到自己的方式之前可以使用通用方式。

嗯嗯，方式不固定，能达到效果就是最好的方法。

嗯嗯，探索性测试本身也是一种方法，只是比较依赖个人能力而已，如果能进行经验化的传承就更好了。

嗯嗯，所以发现 bug 后可以及时更新测试用例，然后在以后的测试用例中尽可能考虑复用，让不可控的经验达到可传承的程度，这应该也是测试用例的一个目标吧。

如果对人不信任，这个事情就很难办哈，前提肯定还是相信人，然后每个人执行结果是带上自己名字的，统一提交到 SVN 或者某一个存放文档的地方就可以回溯了。

嗯，这种顺其自然就自适应的感觉真好

同意 +1，如果能一眼就看明白的确实不用写，自己觉得可能有歧义的地方可以注明下，一切以实用为主

厉害呀，我的脑袋瓜子实在是不够用，不写下来就会漏点

为啥思维导图和 excel 不是好的落地方式？是因为看不出来执行人员是否真的执行了？它们都可以做结果标注的噢

我不 1，我 2，所以叫二麻子