文档介绍：: .
软件测试总思路
1 博弈的各方
选择意味着痛苦，这个世界上没有选择，可能生活会很简单。人是如此，公司亦然。自从公司内部多了一群专职做测试的人或者部门。管理人员发现，整个管理的对象中又多了一种人――软件测试人员。从此项目经理、业务分析人员、设计人员、程序开发人员、测试人员之间开始沟通了。下面，我个人对各种角色按照普遍的概念对其做一个简单描述：
项目经理：对项目的所有问题负责；
业务分析人员：清楚的了解客户的需求并以文档形式及时传递给每一个角色；
设计人员：根据需求文档做概要设计（或详细设计）
程序开发人员：根据设计文档（可能是自己写的）开发软件；
测试人员：根据需求文档（或设计文档）设计测试用例，并对开发人员提交的软件进行测试；
问题：
如果软件提交到客户那边出现无数个 Bug,那么是谁的问题？我们是否有一套指标体系来判断在哪个环节就已经出现问题了？测试人员应该从哪个环节开始降低风险？测试人员被授权到什么程度？测试人员的能力是通过什么被认可的？
老板会相信谁？笔者认为，在任何一个公司做测试工作首先要搞清楚以上问题。回答好上述问题那么测试工作基本上算入门了；能妥善的协调上面的问题那么就可以独当一面了；
2 测试的过程
如果拉住一个测试负责人一问，软件测试的过程是怎么样的，应该会从计划说到发布。实际上各个项目在开展测试的时候： 1、各个阶段划分的不会太明显； 2、某些阶段的功能会弱化，某些阶段的功能会延伸；下面我指出目前测试工作中基本上做的不足的或者比较常见的问题（有则改之、无则加勉）：
测试策略文档的普遍缺失；测试范围的确认经常被其他文档或经验所取代；
测试计划受制于开发计划；
测试任务应该像BUG—样有明确的分级，不同类型的测试应该有相应的测试用例集合与之对应；
关键路径概念在测试规划时容易被项目经理弱化。
3 测试所具备的素质
很多人都在问我，如果我去做测试需要学一些什么东西比较好。我的答案是，大学学了四年，有多少是工作中直接用到的？对工作有指导意义的往往是当年根本不当一回事的那些知识。
其实，对于多数工作，短期内能提高的只是方法和技巧。基本的素质决定了你人生最终能走多远，而方法和技巧必须要到实际的工作中去摸索。我的建议是：不要去做自己内心就抵制的工作；不要首先给自己下一个定义，“我适合做什么”；在中国很少有人把自己的工作当作自己的乐趣，如果你是这样，那么放下这篇文章，去工作吧；我们在做一件必须要做的事情时，不管你喜欢不喜欢，先把它做好；
4 自动化测试这是一个不得不提的话题。没有做过自动化测试的人，都梦想能精通一个自动化工具，期望以此来提高自己的江湖地位，并解决手工测试带来的痛苦