俗话说，万丈高楼平地起，大家都能看见高楼的威武，高耸如云，可是我们往往忽略了他深埋在地下的坚实基石。
测试一样，没有夯实地基的高楼，也就是个漂亮的豆腐渣工程。

那作为一个测试，他的基石是什么？编码？写用例？执行点点操作？都不是，最基本的第一步是去了解质量，建立自己的质量意识，而质量这个东西生活中到处可见，结合生活再理解质量，切合民生去创建自己的质量意识，此处质量不是指为了一些标准而进行的质量度量之类的东西，而纯粹是一个意识的建立过程。
遥想当年，读着克劳士比的《质量无泪》，热血沸腾，明显的感觉到自己的肩上责任之重大，质量保证与人民生活息息相关。他的零缺陷意识指导着我尽职尽责，说服同仁尽量从早期介入项目，不放过自己疑惑的任何一个地方，说服 pm 进行出厂前的初始化安装测试，这才避免了在客户方出现大量初始化安装由于缺少补丁而带来的巨大损失。这是对零缺陷的向往，相信读过的人都了解，零缺陷不是说没有缺陷，而是说从一开始就向着零缺陷努力，那样后期缺陷，后期成本都可以少很多；

那第二个基础是什么？有了质量意识就要去实践，从测试的角度去实现它，这时才涉及到测试的基础知识，用例的涉及，场景的模拟，bug 的描述，这些不能是为了写而写，要结合（一）中的两点，去自己完善，优化 -------- 你的 case，bug 别人能看懂吗？如果好久没接触了，你再接触的时候能很快上手执行吗？还是会推到重做，质量，不但是要让开发做，测试首先要提交高质量的设计文档，该文档不需要漂亮，不需要好多话，只需要告诉别人如何测试，按照你的 case，任何一个人都可以很快上手执行，面对你的 bug 描述，越来越少的开发来让你复现，或许有过第一次，第二次，可是好的 bug 报告，在经历两三次后，对方就会去认真读，而不是说看不懂，因为他按照你的描述可以百分百复现，这就是高质量的报告（这里不说高质量的 case，因为他的依赖条件较多，上述条件满足后只能说是个不错的 case）。

对于高质量的 case，这里需要提点，高质量，不是要多复杂，而是要将复杂的业务逻辑肢解了，拆散了给别人看，单独的 case 或许不是很懂在干什么，可是当别人将你写的 case 执行完之后就会有种突然间明白里面所有的逻辑关系感觉，那你就是将肢解了的东西又重组给别人的眼前了。而这样的 case 结果需要多种设计策略合并使用，有时还会借助思维导图进行梳理，所以本人认为 case 最大工作量不在写上，而在分析和一次次的肢解组合上，而这是测试占用工作量和精力最大的地方，而许多人却不理解，没有认真动脑写 case 的人，就会认为用例就是写出来呗，怎么还没写。

打好这些基础，从自我质量提高开始，那好的质量意识会指导你更多的从生活，从用户去考虑问题，即使遇到不同意见，你也可以比较清晰的给对方描述用户场景，存在风险；好的测试用例设计技能可以让你在各种系统，各种实现手段 -- 自动化，性能，客户端，服务端，显得游刃有余，因为在做这些的时候，你明确知道你的目标是什么，你要干什么，而不是为了自动化而自动，为了并发而并发，不思考，不质疑。而在各种业务系统中，你需要找出他的特别之处加以琢磨，其他主旨都一样，不都是为了能用，好用，耐用，安全吗？