俗话说，万丈高楼平地起，大家都能看见高楼的威武，高耸如云，可是我们往往忽略了他深埋在地下的坚实基石。
测试一样，没有夯实地基的高楼，也就是个漂亮的豆腐渣工程。
那作为一个测试，他的基石是什么？编码？写用例？执行点点操作？都不是，最基本的第一步是去了解质量，建立自己的质量意识，而质量这个东西生活中到处可见，结合生活再理解质量，切合民生去创建自己的质量意识，此处质量不是指为了一些标准而进行的质量度量之类的东西，而纯粹是一个意识的建立过程。
遥想当年，读着克劳士比的《质量无泪》，热血沸腾，明显的感觉到自己的肩上责任之重大，质量保证与人民生活息息相关。他的零缺陷意识指导着我尽职尽责，说服同仁尽量从早期介入项目，不放过自己疑惑的任何一个地方，说服 pm 进行出厂前的初始化安装测试，这才避免了在客户方出现大量初始化安装由于缺少补丁而带来的巨大损失。这是对零缺陷的向往，相信读过的人都了解，零缺陷不是说没有缺陷，而是说从一开始就向着零缺陷努力，那样后期缺陷，后期成本都可以少很多；
那第二个基础是什么？有了质量意识就要去实践，从测试的角度去实现它，这时才涉及到测试的基础知识，用例的涉及，场景的模拟，bug 的描述，这些不能是为了写而写，要结合（一）中的两点，去自己完善，优化 -------- 你的 case，bug 别人能看懂吗？如果好久没接触了，你再接触的时候能很快上手执行吗？还是会推到重做，质量，不但是要让开发做，测试首先要提交高质量的设计文档，该文档不需要漂亮，不需要好多话，只需要告诉别人如何测试，按照你的 case，任何一个人都可以很快上手执行，面对你的 bug 描述，越来越少的开发来让你复现，或许有过第一次，第二次，可是好的 bug 报告，在经历两三次后，对方就会去认真读，而不是说看不懂，因为他按照你的描述可以百分百复现，这就是高质量的报告（这里不说高质量的 case，因为他的依赖条件较多，上述条件满足后只能说是个不错的 case）。
对于高质量的 case，这里需要提点，高质量，不是要多复杂，而是要将复杂的业务逻辑肢解了，拆散了给别人看，单独的 case 或许不是很懂在干什么，可是当别人将你写的 case 执行完之后就会有种突然间明白里面所有的逻辑关系感觉，那你就是将肢解了的东西又重组给别人的眼前了。而这样的 case 结果需要多种设计策略合并使用，有时还会借助思维导图进行梳理，所以本人认为 case 最大工作量不在写上，而在分析和一次次的肢解组合上，而这是测试占用工作量和精力最大的地方，而许多人却不理解，没有认真动脑写 case 的人，就会认为用例就是写出来呗，怎么还没写。
打好这些基础，从自我质量提高开始，那好的质量意识会指导你更多的从生活，从用户去考虑问题，即使遇到不同意见，你也可以比较清晰的给对方描述用户场景，存在风险；好的测试用例设计技能可以让你在各种系统，各种实现手段 -- 自动化，性能，客户端，服务端，显得游刃有余，因为在做这些的时候，你明确知道你的目标是什么，你要干什么，而不是为了自动化而自动，为了并发而并发，不思考，不质疑。而在各种业务系统中，你需要找出他的特别之处加以琢磨，其他主旨都一样，不都是为了能用，好用，耐用，安全吗？
不错的。加精吧~~
说的不错，质量意识确实是第一位的。
赞楼主，很用心。理论是一方面，但是实际操作过程中不会这么理想。从楼主的字里行间看，觉得并不像是做移动互联网项目的，倒很像是我们做系统项目的，有很长的迭代时间，可能是 3 个月，也可能是半年，或者更长。个人做了 3，4 年的部门质量跟踪，但是实际涉及到责任心，人力，领导，很多都是做做样子，远没有那么理想。
举个最近的例子，昨天我们老大要我们实现自动化百分比，他关心的是百分比数据，项目进度并不关心。质量那是出了问题以后才讨论的事情。敏捷项目，开发天天变都没有文档，测试用例目前都没有整理，百分比只能忽悠忽悠上面。
时代在变化，以往的经验可能会害死人。而且人力成本也是考虑的重点，领导们都喜欢有通用的方法，有不需要多少人力就能推广见效的成果，如果你长期在一线的话，会明显感觉到现实很头疼。
最近比较愤青。。。见谅哈~
#4 楼 @yangchengtest 不能拿扭曲的敏捷说事。
@xhk1 质量意识，不能只是测试要有，谁都要有。
@seveniruby 个人觉得是实践偏离理论了。现象就是我家门前有片草地，如果要到对面去，需要多走一点路，有人就直接从草地中间开了条道。走捷径不是不好，但是破坏就不好了。
#2 楼 @chenhengjie123 请问老师，我的领导跟我说，未来自动化测试的人才很吃香。因为懂开发写代码的人不爱做测试，做测试的人往往不懂开发不懂代码——我就是后者。但是他告诉我说不懂代码也没关系，以后的自动化测试可以用脚本录制实现。你只需要有足够的 test sence 就够了——您是怎么看待上述这段话的呢？我觉得录制脚本的形式虽然简单，但应该还取代不了编写代码的模式吧？
#4 楼 @yangchengtest 太有道理了。。。整理文档这种活虽然很脏很累，但是总得有人干啊。。。偏偏愿意干这种活的人太少了
#6 楼 @james88233 未来只有两种，1，业务测试高手 2，会测试的开发。
楼上说的对~
#8 楼 @lihuazhang 能具体说说嘛 什么样的叫业务测试高手？不懂代码可以吗？我只想达到一种境界，刚毕业的小孩没有几年的磨练赶不上我。我不知道在手机自动化测试这个领域达到这个地步有多难
#10 楼 @james88233 业务，比如银行贷款的流程啊，比如汽车行业的组装流程啊
#11 楼 @lihuazhang 这个流程之类的东西 毕业生几个月掌握不了吗？
#12 楼 @james88233 。。。还真不行。能掌握大致，但是出问题了，他的经验就不够了。
#13 楼 @lihuazhang 大概明白了 在金融和汽车测试领域，需要一些专业的素养才能掌握测试技巧，对吧
#14 楼 @james88233 嗯 是的。我记得以前有个故事，说是有个系统出了问题，然后开发各种定位不到。有个经验很丰富的测试，一下子就定位到了，是因为这个测试在这个领域接触过各种各样不同的方案，也发现过各种各样的问题。
#15 楼 @lihuazhang 受教了 谢谢 这个经验还真不是一天两天就能学会的
#3 楼 @seveniruby 这不是理论，这只是多年的经验总结和心得，仅供大家参考。理论高度太高，自觉还没那个能力达到那个层面呢:).
谈论到的细节问题，那是需要真刀真枪去做才能体会的，因为未成理论系统，请恕暂未能提供详细信息。不过这层我可以再考虑，看如何提取。
#4 楼 @yangchengtest 呵呵，我现在就在互联网行业，你说的情况是我们现在的一个普遍现象，这个时候可以去了解下敏捷开发下的测试，轻文档是可以的，但是不是不要，另外 case 的形式也可以转换，不一定要用传统的那种，那种确实耗时，但是基本的设计分析在什么行业都不能缺少，展现形式可以灵活。
变有变的好处，那应对变化的策略之一就是自动化的实现。单元测试层，接口测试层都可以考虑。
#5 楼 @lihuazhang 严重同意，人人都应有质量意识，不应该只是质量部门或者测试部门的。
#6 楼 @james88233 录制脚本的形式是简单，可是实现会复杂，其实编码不难，正如你领导说的有了测试 sence，你只需要将它转换成 code 就可以了，当然不是所有的都可以转换。
如果精力允许，还是建议学习下编程，不需要多，一个就够，而且最好在实际工作中应用，这样学的最快
#7 楼 @james88233 不是愿意干的人少，而是又时变化太快来不及更新，此时建议考虑下文档的内容优化和展现形式是否可以更直观而不单单是一大堆文字，可以用图表解决，结构展示，流程显现。
#8 楼 @lihuazhang 补充第三种，1 和 2 的结合，这条路是可以走的。
#6 楼 @james88233 我觉得会写代码和走自动化其实是两回事。
作为 IT 行业的一员，会写一些代码应该是基础技能（不要求能做很厉害的代码，但脚本基本应该是能写的）
目前能真正提高工作效率的测试用例基本都不可能使用纯录制（不能加验证是纯录制的最大缺点，而且纯录制复用度比较低）。
我觉得如 @lihuazhang 所说，测试要不往业务走（开发基本不可能精通业务），要不往开发走（不是指测试开发，而是懂得开发、懂得测试的且主要写测试代码的人）。
至于用户体验，那是 PM 和 UI/交互设计主要做的事情，测试提一下也行，不过大多会被忽略（在这方面没有话语权啊）。。。
#24 楼 @james88233 你的问题楼下的 chenhengjie123 基本已经回答了。这里我再说两句：1.你们公司自己开发录制脚本的工具，现在市面上已经有开源的了，如果真走录制，这些就够了，为何会另外投入精力去做，而且开源的都已经经历好多人的使用测试了；
另外即使是录制的脚本，你也要在此基础上进行修改，增加判断点，到时候开发出来的能不能很好符合你们测试的需求呢？
所以建议是：如果录制工具用开源的，口碑不错的，调研下；如果你们的工具开发团队很强大，建议他们开发测试框架，给出 sample，你们之负责按照 sample 编写测试用例的脚本就可以了，所有函数，判断，规则，报告都有框架团队给出，这样你们就不会被录制的 ui 层的东西来阻碍实际开发，也可以用你的 testsense 更多地关注在用例脚本的实现上。
#27 楼 @james88233 这个主要看你们自己开发的工具，如果该工具是为你们公司的项目特别定制的话，或许使用起来可操作性和准确性都能高点，不过最终看你们的工具的能力了：）
不错啊，高质量的报告很重要