手工测试还是自动化测试只是软件测试执行的手段，一切软件测试活动和测试质量的源头都是从软件测试分析设计开始， 任何行业的分析设计都主要依赖人脑， 手工和自动化之争我们也许应该说是人脑测试与非人脑测试可能更准确性，在国外有一个名词：smart test。意思就是强调测试中人脑的作用及价值。

　　类比其他行业：

　　软件开发都是从软件需求分析和架构设计开始开工启动，至于后面的代码可以手工生成实施，也可以自动化生成实施执行。

　　汽车、手表行业也是，汽车设计师利用辅助分析设计工具把人脑的想法转为有形载体，最后无论是手工制造还是自动化生成都无法改变前端的分析设计靠人脑的方式。

　　建筑业也是从一个人脑的设计构思开始，才有后面的架构和框架的实现和更小的子模块建设实现。

　　至今为止，还没有任何一个行业可以不先从人脑开始，真正的设计全自动化是不存在的（直接抄袭它人的设计跳到实现阶段的不算，中国不缺山寨工缺设计师） 。

　　所以，我也比较认同有的测试专家提出的，训练测试人员先从测试的脑袋开始训练，如何训练这还处于一个未系统化的起步阶段，但有人开始投入相信未来会有更合适更好的方案。

　　我有一个观点一个厉害的test engineer（not a tester），应该像其他行业的engineer一样，能设计一个测试系统。这个测试系统如软件运行系统一样，有自己的框架（在测试领域是检测框架）保障自己系统的可靠性（测试质量）和性能（测试效率），有自己的实现技术方案。 至于后面的testcase实现还是test code实现如同product code可以通过人工实现也可以软件自动实现。

　　这个测试系统应该包含至少3种测试件：

　　1、测试设计思想体现：包含整体测试设计的检测框架或检测方法架构，各测试类型和后续测试设计侧重及约束； （ 如任何软件产品设计或工程产品设计工作，如乔布斯和苹果首席技术架构设计师对iphone体现的设计实现思想）

　　2、测试实现的基础框架：如自动化测试实现的框架及各类测试工具，可重用的测试用例和方法、各测试类型的测试设计框架；（如iphone的CPU，主板，内存，电源，硬盘，操作系统）

　　3、 拉通设计思想和基础框架的中间载体：testcase和test code； 如 iphoone中的非基础框架的软件代码；

　　当然我们也可以模仿早期的软件开发模式，跳过从上到下分层分面的架构系统设计活动，直接到代码实现阶段通过bug反馈驱动我们不断修改我们的软件最终达到我们的目的。那个年代是一个修改bug的个人英雄时代，我曾见过有的软件开发人员改了一年bug后才开始真正写下自己的代码，写了2个月后又用了10个月改代码。 有一个人做了3年软件工程师，一共只有5个月开发代码其他时间都在帮其他人改bug。正是过去的软件开发原始状态，让我当时顿时失去了读书时代对软件开发的向往，难道我的工作内容大部分就是打补丁改错吗？软件开发就是不设计的混乱状态吗？用当时说法就是一个IT民工，现在说法更像一个码农而不是一个设计师。 直到后来换了环境见到一些资深10年以上软件牛人非常严谨的详细的设计文档（架构文档、子模块设计文档），参加了其工程化科学化的设计讨论及评审会，才体会到好软件都是设计出来的，而不是补丁打出来。虽然他们也经历了IT民工阶段成长过来的，但对软件工程的追求，对成为设计者的追求让他们成为少有的有系统的工程化方法的技术设计者。

　　专业10年后你是系统设计师还是码农，真正取决于自己的追求和付出了。

　　我们软件测试工程师希望追求什么样的工作模式？

版权声明：本文出自 架构师Jack 的51Testing软件测试博客：http://www.51testing.com/?293557

原创作品，转载时请务必以超链接形式标明本文原始出处、作者信息和本声明，否则将追究法律责任。