#4 楼 @yangchengtest 呵呵，我现在就在互联网行业，你说的情况是我们现在的一个普遍现象，这个时候可以去了解下敏捷开发下的测试，轻文档是可以的，但是不是不要，另外 case 的形式也可以转换，不一定要用传统的那种，那种确实耗时，但是基本的设计分析在什么行业都不能缺少，展现形式可以灵活。
变有变的好处，那应对变化的策略之一就是自动化的实现。单元测试层，接口测试层都可以考虑。

#3 楼 @seveniruby 这不是理论，这只是多年的经验总结和心得，仅供大家参考。理论高度太高，自觉还没那个能力达到那个层面呢:).
谈论到的细节问题，那是需要真刀真枪去做才能体会的，因为未成理论系统，请恕暂未能提供详细信息。不过这层我可以再考虑，看如何提取。

#15 楼 @oracle 我说的这层被动与否与组织架构无关，属于个人的修为范围。意为我们要自己主动，而不是连思想也是被动的，这无关乎你上面的那层，如果个人是个被动思维的人，上层主动推行也比较费劲的。不过这种情况下，要么被上层同化要么就被取代。

今早一来确实没有想到会有这么多的回复，更没想到会有真正懂我的人，感动啊......
后续我会整理，按照大家的不同纬度来介绍下这些年的心历路程。

#6 楼 @oracle 现在普遍的现象就是测试很被动，不光行为上，有时连思想也很被动。

#4 楼 @seveniruby 嗯，做好被拍的准备了，对于很多人看到这种文章，第一感觉肯定很空洞。

#5 楼 @pighero001 同感阿，找到懂我的人了:)
在面试的时候问技术都是次要的，锦上添花的事情， 关键是考察态度和面对问题时是否乐于思考，勤于解决问题，敢于质疑。

#3 楼 @chenhengjie123 可以的呀，现在看着很多人在走弯路，测试了多年却连测试基本的工作都做不好，内心就很难受，其实他们一开始走对了，会做的比现在更好，测试行业的被质疑声或许能少很多。

#2 楼 @testly 其实我的这八年是一个不断质疑不断验证不断修正的过程，历程比较坎坷。

考虑了好久了，今天终于写了，后续还会继续更新细化。

谢谢分享~

先赞一个，后学习;)

总的一点，就是无论何种测试，测试用例的设计是很重要的，用例设计在任何阶段都一样，只是面对形式不一样，除了边界之类的，需要更多的关注业务，逻辑和场景的考虑，这样发现的问题才更深，而开发的很多 bug 就在这些地方。
关于边界之类的可以按照优先级看时间往后放放。
覆盖率本身是个有争议的东西，东西还是从用户角度出发，能用，好用，逻辑正确为基本总线，所以建议关注这些。
线上监控是必要的，但是测试阶段的 case 设计要涉及更广范围，既然都可以用 python 写脚本了，建议 postman 只做校对工具临时使用，还是尽量实现脚本自动化，让程序来校对正误。
移动端，实在不好意思，暂时提供不了好的建议，但是从用户角度考虑问题是个很重要的解决方式，可以暂时使用。

有了思想，什么样的项目都来者拆招，有了代码，没有思想，项目架构发生变化便死翘翘了，lz 看开点。