8. 测试总结
每个测试人员在某个时间段，或者一个项目结束后，都应该写一写测试总结，内容可以是在这个过程中获得的新技能，或者发现了自己的哪些不足，还可以是对测试的一些总结，这样，一方面可以在没有测试工作的时候督促测试人员去学习一些新技能，思考一些新方法，另一方面，通过总结，对测试人员自身的发展也是比较好的。
9. 测试会议
每周可以组织一次测试会议，针对某个主题展开讨论，形成一些可以执行的措施，测试会议中，测试人员说明一下当前各自工作内容，分享一些测试心得，使得每个测试人员都可以了解其他测试人员目前在做什么，另外，可以说明一下当前测试工作中碰到的哪些问题，大家一起讨论一个解决方法。
10. 测试文档整理
对测试过程中经常使用的文档，都可以整理成文档模板，比如测试用例模板，测试计划模板，测试报告模板等，虽然测试文档有很多的模板，但是根据公司特点整理的模板就是最好的模板，在写这些文档的时候，根据模板，可以提高工作效率，另外，对于业务文档，测试培训文档都应该整理，这些文档可以作为公司财产，更重要的是，当有新人进来的时候，完整的文档，可以让新人更快的融入团队。
二．测试过程中的缺点
1.需求问题多
需求不确定是测试中经常出现的一个问题，有时候是因为没有专门的需求人有，需求文档不全面，有时候虽然有需求人员，但是，需求人员在完成需求文档的时候，可能是因为时间关系，也可能是因为考虑不细致，需求中总会有一些模棱两可的内容，而测试依照需求编写测试用例的时候，就会发现这一部分需求没有办法写测试用例，询问需求，要么被告知暂时就按需求来，要么需求自己也不知道具体是什么，出现这样的情况，都是不可测试的，很多时候，因为测试依照的是需求，既然需求这么说了，测试就没有什么方法了，要么就是等待，要么就是这一部分现不管了，后来，因为测试要忙其他的时候，逐渐就会把这些给忘记了，直到发布测试版本执行测试的时候，才会发现原来这个地方根本就不知道如何去测试。
需求变动也是测试中经常出现的一个问题，其中有一部分原因是前面描述的需求不确定导致，还有原因是客户或者老板觉得目前的需求是不合理，不完善的需要修改或者增加，需求变动是无法避免的，但是，很多时候，需求变动了，需求口头告诉开发人员，开发人员就按照需求的说明对程序进行了改动，等测试在测试过程中发现程序展现出来的和需求完全不一致，提交bug了，开发拒绝了，说是需求要这样做的，问需求，需求说，是他让开发做的，测试人有比较尴尬，因为提交了无效的bug，又决定委屈，因为的确，根据需求，它就是一个bug，而更严重的是，测试还要修改测试用例，还要考虑开发这样修改，会不会影响到其他地方。
针对以上两个需求的问题，测试最终要的是把握两点，一是需求必须是正确的，完整的，可测试的，无异议的，如果需求没有达到这一点，测试一定要跟着需求，让他将需求修改，如果必要，可以跟更高一级的领导汇报。第二，测试需要在整个项目组确定一种氛围，就是需求如果有变动，一定要以书面形式告之项目组相关人员，之后走需求变更流程，测试重新评估测试时间。如果出现因为需求变动导致的bug，测试不能因为开发是按照需求要求而修改了程序就不提bug，这样的问题，也必须提交bug，并且在总结的时候，一定要说明哪些是因为需求变动没有告之测试而出现的bug，这样，会对需求和开发有一定的影响。
2.开发经常延期
在项目开发过程中，容易出现到了开发承诺提交测试版本的时候，却不能按时提交测试版本，一般情况下，开发延期了，项目都不会顺延的，这个时候，测试完全被动了，不知道在延期的这段时间具体做什么，因为根据计划，是要开始执行测试了，其实，如果测试在更早的时间就能获悉开发要延期，则可以做一些延期准备工作，比如，可以安排准备测试数据，或者安排对测试用例进行组内相互检查，还可以安排对开发进行支持的一些工作。
3.评审效果差
无论是需求评审，还是测试用例评审，开发对这方面表现出来的积极性不够，可能是开发更喜欢设计的工作，对阅读的工作不喜欢，这样虽然是评审，开发只是走走过程，没有实质性的建议提出来。
4.测试用例优先级划分不科学
测试用例的执行，其实并不是每一轮测试都需要全部执行，根据项目的实际情况，可以对测试用例进行优先级分类，但是，在测试过程中，对测试用例的优先级的划分，完全是根据测试人员自己的经验和对被测项目的理解而划分的，因为个人能力的局限性，这样的划分是有很多的缺陷的，如果按照这样的分类进行测试，存在很高的风险，因此，一般的测试过程中，虽然划分了测试用例的优先级，但是，测试人员为了安全，还是会将所有的用例都执行的，测试用例优先级划分起不到应有的效果。
版权声明：原创作品，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。
本文出自小刀的51Testing软件测试博客：http://www.51testing.com/?128005
