认识达内从这里开始

一、文档类，这些首先是测试人员的劳动成果，可视化很强。

文档的种类，(评审后的需求文档，需求原型，测试计划，测试报告，测试总结)，这些文档按照不同日期归类到不同文件夹中管理，这样，产品的任何一次变更，

自己对需求的理解，都会有迹可查。当然，SVN，GIT中也会有记录。自己辛苦手动备份一份，更稳妥一些。

我一般都会把需求文档打印出来，更改部分，都在纸张上标注清楚。这样查看非常方便。

需求变更太频繁，自己千万不要以此为借口，不做管理，不然，吃亏还是自己。

另外，对于需求，稍有遗漏测试，就会造成产品质量下降。朝着一个合格的测试人员靠拢，特别是产品人员有时变更需求，只是口头说说，没有落于纸上的情况下，测试人员更要及时把这部分需求记录下来，有记录总比脑子记要好些。(先记录在管理工具里，当天下班前，再复写到纸上，也行。)

测试计划与测试报告，这两种文档很容易管理，变更少，一经成型，很少改变。无非是多出几份报告，注明一下日期，这样就没有问题了。

二、用例类

我没有把这类归到测试文档这块，因为用例类的管理也是非常麻烦的，当产品需求频繁变更后，用例能不能及时补齐，是判断一个合格测试人员的指标。还是那句话，不要找理由，什么…………，愿意不愿意及时补充，修改，在于自己，领导其实也管理不到这么详细。相信我，当你能及时补充后，带给你的好处一定大于你认为带给你的麻烦。这个时间花的很值。

别指望大脑记，落地的用例，比在脑海中更清晰，更能让你思路，场景考虑的全面。

写用例时，多看需求文档，每次审查时，你都会有新的灵感。

这点，我个人也需要提高，一方面需要提高用例的覆盖率，另一方面，提高用例的质量，多审查需求文档。

目前我所在的公司是用EXCEL表格管理用例，也可以用BUG管理工具管理。

对于用例我补充一点，当理解需求后，尽量画出思维导图或写出功能点，业务逻辑后，再写用例，进一步深入。

三、BUG优化建议类。

这个目前大部分公司都会有用例管理工具，如：禅道，testlink,bugfree等。这些工具很实用。尽量用活这些工具，它们有很多的功能，能帮助我们管理用例，有助于我们写测试报告。

也有用EXCEL表格管理BUG，都行。管好，用好。 对待BUG，能跟踪到位吗?直到它消失，是简单的回归一下，还是慎重的多次回归，测试没有侥幸。

四、产品上线后的维护

这一点也可以纳入测试的工作范围，这些问题什么场景下产生的，能不能复现。当时是自己漏测试了，还是开发改动带出来的等，找到原因更好，最主要的是先解决它。对于客户反馈的事情，做到事事有回应，样样有反馈。客户付给公司的钱，70%是买你的产品，剩下的是买你公司的服务的。维护公司的信誉是公司每个人的职责。

客户反馈的问题都必须有记录，可以是客服，网络运维，测试都行，如果不是测试人员，就把客户向你咨询的问题，反馈给对应的记录人员，让他们记录在案。

并定期向客户汇报一次问题改善的进展，让客户心中有底。

五、如果一个测试人员负责多个项目的测试工作，工作量很大，测试任务很重。

如何管理好这些资料与反馈信息，考验一个测试人员的工作效率与工作能力。

我个人建议，先用笔记录下这些资料的地址，项目结束后，再统一整理好这些资料。

人都要珍惜自己的劳动成果。你遗漏的资料与信息都是你的劳动成果，不要轻易放弃它们。

测试技术有很多种，我也一直在学习。如：性能，自动化，安全。

但无论测试技术如何发展，一个好的自身管理水平不会逊色于测试技术。

当某一天你当上了管理人员，你面对的将是如何提高被测试系统的质量的重任。你完全可以把以前你自己的自身管理经验，复制到对下属同事的管理上。

管理---管人与理事。事理清了，安排给合适的人去做。并让他们反馈结果。