在一个软件团队里，不同的人有不同的投入，不同的人还要在团队中担负不同的任务，我们也要讲一下。

　　团队中的 PM 负责分析市场，设想功能，定义用户到底要什么 – Why & What.

　　团队中的 Dev 负责实现功能，搞清楚怎么才能满足用户的需求 – How.

　　团队中的测试人员搞清楚我们的软件是否满足了用户的需求 – Whether.

　　后所有成员一块决定产品是否能发布，什么时候能发布 – When.

　　测试/Test 和 质量保障/QA （Quality Assurance） 这两个词经常混用，这两个概念是完全同等，还是只是有一部交集，还是一个是另一个的真子集，众说纷纭。大多数人说起 Test 的时候，会认为：

　　Test （测试） 是验证代码的行为是否符合功能规格说明书 （spec） 的规定。

　　这个解释过于狭义，我个人认为这只是 QA 工作的一部分。

　　对测试工作的种种误解

　　大家对“测试”这一工作还有很多误解例如下面的似是而非的观点：

　　（1）测试在项目的后进行可以了。

　　这是远远不够的。当你在项目后期发现了问题，问题的根源往往是项目早期的一些决定和设计，这时候，再要对其进行修改比较困难了。这要求测试人员从项目开始要积极介入，从源头防止问题的发生。有人会说，我是一个小小的测试人员，项目开始的时候我能做什么？这是小小测试人员努力的方向。

　　（2）测试得根据规格说明书（spec）来测，所以是很机械的。

　　那不一定，即使你的软件产品功能 符合spec 的要求，但是用户也可能非常恨你的软件。这时，测试人员没有尽到责任，因为测试人员要从用户的角度出发，测试软件。

　　（3）测试人员当然也写代码，但是质量不一定要很高。

　　开发人员的代码没写好，可以依赖于测试人员来发现问题。但是如果测试人员的代码没写好，我们依赖谁来测试和改错呢？这要求我们测试人员的代码质量特别高，因为我们是后一道防线，如果我们的代码和测试工作有漏洞，那么Bug会跑到用户那里去。

　　各种测试方法

        功能、压力、回归、冒烟、效能、白盒、黑盒......

　　基本名词解释及分类

　　统一思想要从基本名词解释开始。

　　1、Bug：缺陷软件的缺陷

　　Bug可以分为这三个组成部分：症状（Symptom）、程序错误（Fault）、根本原因（Root cause）。

　　（1）Symptom：即从用户的角度看，软件出了什么问题。

　　例如，在输入（3 2 1 1）的时候，程序错误退出。