【摘要】本文针对测试的过程、测试所具备的素质、自动化测试、测试的误区等进行了简单的探讨，希望能给大家以启示。
【关键词】测试策略测试计划自动化测试
30年前，《人月神话》中说道“不为系统测试安排足够的时间简直就是一场灾难”
10年前，中国的软件公司大部分只有测试工作而没有测试人员
5年前，中国的软件公司开始让“老弱病残”做专门的软件测试
1年前， 很多中国的软件公司发现，没有通过专业测试人员测试过的软件根本不敢给客户看
今年，我发现有一期《申江服务导报》上列举的最新职业中，其中有一项是“软件测试人员”，看到这条消息我感到由衷的欣慰，欣慰之中包含了太多的辛酸和无奈。
时至今日，我想不管是做测试的还是看测试的，都已经有一套理论了。所以本文，我就着重写点我自己从事测试工作的一些感受。
选择意味着痛苦，这个世界上没有选择，可能生活会很简单。人是如此，公司亦然。自从公司内部多了一群专职做测试的人或者部门。管理人员发现，整个管理的对象中又多了一种人――软件测试人员。从此项目经理、业务分析人员、设计人员、程序开发人员、测试人员之间开始沟通了。下面，我个人对各种角色按照普遍的概念对其做一个简单描述：
项目经理：对项目的所有问题负责；
业务分析人员：清楚的了解客户的需求并以文档形式及时传递给每一个角色；
设计人员：根据需求文档做概要设计（或详细设计）
程序开发人员：根据设计文档（可能是自己写的）开发软件；
测试人员：根据需求文档（或设计文档）设计测试用例，并对开发人员提交的软件进行测试；
问题：
- 如果软件提交到客户那边出现无数个Bug，那么是谁的问题？
- 我们是否有一套指标体系来判断在哪个环节就已经出现问题了？
- 测试人员应该从哪个环节开始降低风险？
- 测试人员被授权到什么程度？
- 测试人员的能力是通过什么被认可的？
- 老板会相信谁？
笔者认为，在任何一个公司做测试工作首先要搞清楚以上问题。回答好上述问题那么测试工作基本上算入门了；能妥善的协调上面的问题那么就可以独当一面了；
如果拉住一个测试负责人一问，软件测试的过程是怎么样的，应该会从计划说到发布。实际上各个项目在开展测试的时候：1、各个阶段划分的不会太明显；2、某些阶段的功能会弱化，某些阶段的功能会延伸；下面我指出目前测试工作中基本上做的不足的或者比较常见的问题（有则改之、无则加勉）：
- 测试策略文档的普遍缺失；
- 测试范围的确认经常被其他文档或经验所取代；
- 测试计划受制于开发计划；
- 测试任务应该像BUG一样有明确的分级，不同类型的测试应该有相应的测试用例集合与之对应；
- 关键路径概念在测试规划时容易被项目经理弱化。
很多人都在问我，如果我去做测试需要学一些什么东西比较好。我的答案是，大学学了四年，有多少是工作中直接用到的？对工作有指导意义的往往是当年根本不当一回事的那些知识。
其实，对于多数工作，短期内能提高的只是方法和技巧。基本的素质决定了你人生最终能走多远，而方法和技巧必须要到实际的工作中去摸索。我的建议是：
- 不要去做自己内心就抵制的工作；
- 不要首先给自己下一个定义，“我适合做什么”；
- 在中国很少有人把自己的工作当作自己的乐趣，如果你是这样，那么放下这篇文章，去工作吧；
- 我们在做一件必须要做的事情时，不管你喜欢不喜欢，先把它做好；
- 自动化测试
- 这是一个不得不提的话题。
- 没有做过自动化测试的人，都梦想能精通一个自动化工具，期望以此来提高自己的江湖地位，并解决手工测试带来的痛苦；
- 正在做自动化测试的人，都很清楚自动化往往是一个大麻烦，老板总认为自动化上来了（当然是盗版的）就能解决所有的问题，堵枪眼就靠他了；
其实，自动化测试是一个很广泛的概念，目的不同需要的工具也不一样，每种工具都有自己独特的属性，在做一般功能测试的时候往往觉得所有的工具都差不多，当自动化测试开展到一定精细程度的时候，就会发现最初选择工具的重要性了。
开展自动化测试必须要做的两件事情：1、首先需要判断所测试的软件是否合适做自动化测试；2、选择一个合适的工具；
作为测试人员我们一定要搞清楚一点：我们不是救世主
软件开发是一个系统工程，决定一个项目（产品）的成败是所有环节和参与人员的合力的结果，在整个过程中的任何一个环节出现问题都可能导致最终的客户满意度的下降。问题往往暴露在测试这个阶段，即使很多企业号称全面质量管理，往往也是如此。
并不是有了测试人员软件质量就有了保障。目前所有有测试人员的公司都或多或少的有一种倾向：有了测试人员那么质量就有保障了，这句话反过来理解就是，如果软件质量出了问题那么就是测试人员的问题。如果这种观点是正确的话，那么没有测试人员参与的产品质量就应该是最好的，而事实上并非如此。
本文转载自51testing软件测试网：http://www.51testing.com/html/14/n-8714.html