做测试也做了一年多了，稍微写了一下总结性的东东；结合了前辈们的测试经验，又加入了一些自己觉得该注意的地方，测试中应该注意的小点；还存在很多不足的地方，之后慢慢修改；

　　在进行测试前，首先必须理解业务和需求。需求和业务理解了，才知道客户想要系统实现什么。然后按照需求来进行测试，不满足需求要求的都可以认为是BUG。虽然在实际工作中，拿到一份完整详细的需求是很不容易的，但要做好一个功能测试，前提就是要对需求比较熟悉，各个业务细节都很了解，甚至做到比开发人员还要了解。除此之外，对于现在很多的信息处理相关的系统，还需要对整个业务中数据库的操作比较清楚。比如哪个业务需要用到哪些表，做怎么样的操作。了解了这个就可以不单单从程序前台来看程序，看到数据库的过程，更有利于你找到隐藏的BUG。这些是从前台看不出来的，但实际可能会导致程序出现问题。

　　第二，了解程序的框架结构。比如很多B/S结构的系统中，前台是如何和后台通信的，之间是什么协议，什么格式，后台是如何处理这些数据的。再比如C/S结构的系统，服务器端和客户端之间是如何通信的，中间的数据包是什么格式，哪些功能由服务器端实现，哪些功能由客户端实现等等。了解这些有助于你更好的去测试程序以及定位程序错误。

　　第三，和开发人员沟通。这里说的沟通并不仅仅指通过沟通试图让开发人员修改每个BUG，这个当然需要沟通，但是并不是指所有的BUG都需要修改，这中间涉及到成本、技术，还有别的问题。除此之外，通过和开发人员搞好关系，对于BUG我们可以问他发生该BUG的原因，修改的大致方法，甚至不修改的原因等等，这有助于以后测试中多注意、多发现这样的问题，甚至提出修改建议。

　　第四，决定BUG严重性的时候，可以根据该被测对象在整个系统中充当的角色，实现的功能来判定如果该对象出现错误会对整个系统产生什么样的影响，对产生的影响打分，从而定义BUG的严重程度；决定BUG优先级的时候，可以先假设不修复该BUG，出现的这些问题会产生哪些影响，然后判定这些影响的严重性来判定BUG的优先性。

　　第五，容易产生BUG的情况：虽然在开发过程中，软件需求通常都会发生改动，所以如果某一部分的软件需求频繁发生变动，那么就会导致和这部分相关的编码和设计会相应的频繁变动，那么在测试中，这部分编码设计实现的部分出现BUG的可能性就很大。

　　如果根据测试需求设计的某个测试用例描述的业务非常复杂，并且和其他的业务之间也有非常复杂的关系，那么可以判定设计和编码实现也会非常复杂，那么该部分出现BUG的可能性也非常大

　　如果在开发的过程中，大量使用了第三方的组件，或者从别的软件中移植了大量的代码，那么和这些第三方的组件和代码相关部分出现BUG的可能性就很大，尤其是这些第三方组件使用者很少而且没有通过严格的认证的情况下。

　　第六，如何根据频频变更的软件需求确定测试需求：测试内部肯定有个需求管理的负责人，对于当前产品的需求动向有很明确的掌控，那么他的责任不仅仅是在负责需求这块了，他必须去获取最新的需求，明确开发对这些变更需求的操作，同时将这些变更的信息告之相关的测试人员，明确测试任务；当然需求的变更也不仅仅是需求人员的责任，作为项目的测试人员，在确认新版本中包含的需求后，然后和上次的测试版本进行比较，哪些内热哦那个是新增的，哪些内容是被调整过的，哪些内容是在新版本中取消的等等，然后在根据获取的这些信息，确认测试需求，在进行测试过程中，对这些新增的模块和关联性的模块进行测试。

　　第七，需求变更/测试缺陷的跟踪，这两个项任务的跟踪是很重要的；需求变更不及时跟踪会导致这个测试计划的延后，会延伸出很多需求不明确的问题，同样由于需求不明确出现的BUG变相的会导致开发和测试之间出现矛盾；测试缺陷的跟踪，可以间接提高测试的进度，也可以提醒开发对缺陷进行修改。

　　需求变更/测试缺陷的复查，复查工作其实在测试工作中也是很重要的；如需求变更的复查，可能负责跟踪这条需求的测试人员并为完全深入了解需求，或者测试时只关注了片面的需求，如果你不进行复查一遍，只是通过测试人员的反馈就用来进行判定这条需求有没有通过，这是有风险的，不是说不认同测试人员的工作效率，只是在确认修改是否真正实现，避免不必要的遗漏，提高测试质量；

　　第八，描述BUG主题时，应当根据实际情况，简要的描述出自己的操作和希望被重视的现象，不应该包含自己对异常表现出现的原因的推测和猜想。BUG的描述要简洁易懂，作为测试人员，也要尽可能的分析出造成此缺陷的原因，尤其是在业务流程上出现的BUG，不能只简单描述整个流程操作下来后出现某个BUG，应该具体把在这个流程上导致这个BUG出现的点分析出来。出现缺陷的时候，应该能够通过自身对系统的了解，判断出造成这种情况的可能性原因，之后进行判定；

　　第九，不能假设开发人员对他们开发的程序和业务需求都十分熟悉，在提交BUG的时候，一定要说明白是哪个模块的哪个功能，出现了哪种类型的错误，并且，如果需要，应该把这部分相应的需求都描述出来。

　　第十，对基础操作进行测试【增删改】，不仅仅测试他的基本功能，还要根据系统本上的业务状况来判定功能点是否实现正常。相关的模块，相关的页面，随着增删改的相应操作，相关页面会不会及时更新；实际测试过程中很多次遇到这样的情况，比如，当前页面删除功能是实现了，但是相关页面信息还是存在，没有及时删除；所有基本的功能测试要和业务需求点结合起来一起进行测试，不然会遗留很多问题，测试会不全面。