一．测试过程中的优点 1. 对需求的测试
测试人员在获得需求后，对需求进行正确性，一致性，完整性，可理解性等的检查，将检查过程中发现的问题都记录下来，然后在需求评审之前一到两天统一汇总到需求人员手中，需求人员对测试人员的问题进行解答，在进行需求评审会议的时候，需求人员在讲解完需求后，再针对测试提交的问题进行解答，解答完问题后，评审人员根据之前的情况再提问需求人员，这样可以提高评审会议的效率，同时，测试人员在检查需求，以及参与需求评审的时候，对需求的理解就会更深入。
2. 测试风险的估计及应对
写在测试计划中的测试风险，一定要有明确的可执行的应对方法。否则，如果在测试过程中出现了风险防范中列举的风险，但是没有可执行的方法，可能会严重影响到测试工作，最常见的的，比人测试人员的离职会不会对整个项目测试工作造成影响，有没有可以预防的方法，因为，新招聘一个测试人员参与项目，不但会严重影响到测试进度的，还可能出现因为交接不充分而出现测试遗漏。
3. 测试时间安排
测试计划中，测试时间安排是最重要的一个方面，要将测试时间安排的最合理主要有两个方面，一个是测试人员的能力，一个是测试工作量的估算，能力决定了测试人员擅长或者不擅长的方面，分配测试工作的时候，应该量体裁衣，每个测试工作人员做自己最擅长的部分，对于能力较弱的，可以分配一些简单的测试工作，但是量可以多一点。另一个方面是测试工作量的估算，它决定了测试时间安排的合理与否，测试项目可以分为好几个测试阶段，每个测试阶段的测试内容可以分为不同的测试任务，而每个测试任务又可以分为测试子任务，不能再分的测试子任务才能作为一个独立的测试任务，估算该测试任务需要花费的时间，在估算测试工作量的时候，还要考虑缓冲，测试工作量如果估算的十分精确，一定要有缓冲时间，因为，人不可能完全按照计划工作。
4. 测试用例评审
测试用例评审之前，主持人要做好准备工作，向测试用例提前发送给邀请的对象，同时在会议开始之前准备好会议室，电脑等，在测试用例评审过程中，因为测试用例很多，不能一一都过，最重要的是，测试人员在测试评审的时候，讲解清楚每个测试用例，或者每组测试用例是用来验证什么的，以及这些测试用例执行后能够发现哪些类型缺陷，讲解清楚自己的一个测试思路。
5. 测试汇报进度
从测试进入项目开始，测试人员最好是每天能够汇报当天的进度以及以后一两天的工作安排，汇报对象为测试组成员，测试经理，而测试经理则将每个人的汇报汇总后，发邮件给需求，开发，这样，一方面督促测试人员做好自己的工作，令一方面，也可以让其他项目相关人员了解测试人员的工作进度，更好的做好前提工作，因为测试人员的工作基本上是依赖于需求和开发的。
6. 测试环境管理
测试环境最好是有测试人员管理，这样，一方面可以锻炼测试人员的能力，更重要的是可以杜绝开发随便修改测试环境中的数据。保证测试环境的独立性。
7. 版本控制
如果测试人员测试的版本，每个版本之间是迭代开发完成的，则需要针对每个版本都做冒烟测试，对每个版本都要根据测试策略做完整的测试。如果每个版本提交比较频繁，测试人员只针对重要的版本进行测试，但针对每个版本都应该做版本验证测试，以免遗留有重要的缺陷。
8. 测试总结
每个测试人员在某个时间段，或者一个项目结束后，都应该写一写测试总结，内容可以是在这个过程中获得的新技能，或者发现了自己的哪些不足，还可以是对测试的一些总结，这样，一方面可以在没有测试工作的时候督促测试人员去学习一些新技能，思考一些新方法，另一方面，通过总结，对测试人员自身的发展也是比较好的。
9. 测试会议
每周可以组织一次测试会议，针对某个主题展开讨论，形成一些可以执行的措施，测试会议中，测试人员说明一下当前各自工作内容，分享一些测试心得，使得每个测试人员都可以了解其他测试人员目前在做什么，另外，可以说明一下当前测试工作中碰到的哪些问题，大家一起讨论一个解决方法。
10. 测试文档整理
对测试过程中经常使用的文档，都可以整理成文档模板，比如测试用例模板，测试计划模板，测试报告模板等，虽然测试文档有很多的模板，但是根据公司特点整理的模板就是最好的模板，在写这些文档的时候，根据模板，可以提高工作效率，另外，对于业务文档，测试培训文档都应该整理，这些文档可以作为公司财产，更重要的是，当有新人进来的时候，完整的文档，可以让新人更快的融入团队。
二．测试过程中的缺点
1.需求问题多
需求不确定是测试中经常出现的一个问题，有时候是因为没有专门的需求人有，需求文档不全面，有时候虽然有需求人员，但是，需求人员在完成需求文档的时候，可能是因为时间关系，也可能是因为考虑不细致，需求中总会有一些模棱两可的内容，而测试依照需求编写测试用例的时候，就会发现这一部分需求没有办法写测试用例，询问需求，要么被告知暂时就按需求来，要么需求自己也不知道具体是什么，出现这样的情况，都是不可测试的，很多时候，因为测试依照的是需求，既然需求这么说了，测试就没有什么方法了，要么就是等待，要么就是这一部分现不管了，后来，因为测试要忙其他的时候，逐渐就会把这些给忘记了，直到发布测试版本执行测试的时候，才会发现原来这个地方根本就不知道如何去测试。
需求变动也是测试中经常出现的一个问题，其中有一部分原因是前面描述的需求不确定导致，还有原因是客户或者老板觉得目前的需求是不合理，不完善的需要修改或者增加，需求变动是无法避免的，但是，很多时候，需求变动了，需求口头告诉开发人员，开发人员就按照需求的说明对程序进行了改动，等测试在测试过程中发现程序展现出来的和需求完全不一致，提交bug了，开发拒绝了，说是需求要这样做的，问需求，需求说，是他让开发做的，测试人有比较尴尬，因为提交了无效的bug，又决定委屈，因为的确，根据需求，它就是一个bug，而更严重的是，测试还要修改测试用例，还要考虑开发这样修改，会不会影响到其他地方。
针对以上两个需求的问题，测试最终要的是把握两点，一是需求必须是正确的，完整的，可测试的，无异议的，如果需求没有达到这一点，测试一定要跟着需求，让他将需求修改，如果必要，可以跟更高一级的领导汇报。第二，测试需要在整个项目组确定一种氛围，就是需求如果有变动，一定要以书面形式告之项目组相关人员，之后走需求变更流程，测试重新评估测试时间。如果出现因为需求变动导致的bug，测试不能因为开发是按照需求要求而修改了程序就不提bug，这样的问题，也必须提交bug，并且在总结的时候，一定要说明哪些是因为需求变动没有告之测试而出现的bug，这样，会对需求和开发有一定的影响。
2.开发经常延期
在项目开发过程中，容易出现到了开发承诺提交测试版本的时候，却不能按时提交测试版本，一般情况下，开发延期了，项目都不会顺延的，这个时候，测试完全被动了，不知道在延期的这段时间具体做什么，因为根据计划，是要开始执行测试了，其实，如果测试在更早的时间就能获悉开发要延期，则可以做一些延期准备工作，比如，可以安排准备测试数据，或者安排对测试用例进行组内相互检查，还可以安排对开发进行支持的一些工作。
3.评审效果差
无论是需求评审，还是测试用例评审，开发对这方面表现出来的积极性不够，可能是开发更喜欢设计的工作，对阅读的工作不喜欢，这样虽然是评审，开发只是走走过程，没有实质性的建议提出来。
4.测试用例优先级划分不科学
测试用例的执行，其实并不是每一轮测试都需要全部执行，根据项目的实际情况，可以对测试用例进行优先级分类，但是，在测试过程中，对测试用例的优先级的划分，完全是根据测试人员自己的经验和对被测项目的理解而划分的，因为个人能力的局限性，这样的划分是有很多的缺陷的，如果按照这样的分类进行测试，存在很高的风险，因此，一般的测试过程中，虽然划分了测试用例的优先级，但是，测试人员为了安全，还是会将所有的用例都执行的，测试用例优先级划分起不到应有的效果。
摘自：http://www.51testing.com/html/46/n-109746.html
