让一切东西合理化

1. 文档

     相信很多测试人员都没有认真写过一份测试文档，包括我在内，很多时候是在项目结束了，草草的把之前的一些测试case像填空一样填到文档模板中，这样做的同时我们心里也充满的反感，因为我们只是在做重复的工作，甚至之后这份文档就被束之高阁，自己都不想再看，何况后来人呢？而这时候换个思路和方式可能就会让这份工作变得有意义得多！

     把这个文档当成项目计划文档来做，里面不要只包括设计case这种功能性的东西，还可以包括项目计划安排

     (1)测试对于文档的理解

     这部分内容的来源可以是产品的需求文档、开发的设计文档、和产品开发的口头沟通、和其他相似功能的产品作对比，通过以上方式测试应该形成对产品的一个框架，并且应该清楚哪些部分会是风险点。在这个阶段就要对产品任何可能存在的问题和开发产品做沟通。

     (2)确定测试范围

     现在很少会有完全从头编写代码的项目，多数都恢复用一些早期的代码，那么这部分需不需要测试，一旦发现了问题是否要修复都会是可能面临的问题，所以针对这部分要实现同开发做好沟通，如果不需要测试可以在文档中详细注明不需要测试的原因。

     (3)测试程度

     测试永远也不会保证代码没有缺陷了，这个缺陷包括功能性、可靠性、易用性、效率等等，那么对于每个测试点测试到何种程度能够满足每个人的需求也需要提前说明，这部分也可以包含在文档中。

     (4)不同模块采用的测试方法

     现在在测试时不大可能会单一的使用某种测试方法，通常是黑盒测试、白盒测试、自动化测试等等融合在一起，但是总归有些部分适合采用某一种方法进行测试，在制定计划时也可以在文档中详细说明。

     (5)工作分工

     如果是大项目会涉及到不同的人来测试不同的模块，把这部分分工记录到文档中可以方便后来的人。

     (6)项目的测试进度安排

     这部分应该是项目初期基于测试人员对于项目的理解给出一个测试时间，通常我们会习惯制定某个日期开始做某件事情，但是这未免太过理想化了，拖沓几乎是不可避免的，或者设计有问题导致编码时间延后，或者是编码遇到问题导致提测推迟，这时候那个固定的日子已经变得毫无意义，为了避免这种情况我们可以采用相对时间，比如载提测后2周完成测试。

     (7)测试case

     这部分我不想多说，因为是几乎每个测试人员都会熟悉的事情

     (8)bug报告

     在测试时我们会发现bug，然后报告给开发，但是有时候这种报告只是口头的通知，可能没有一个规范的记录，这是不好的习惯，其实发现了多少bug并非为了我们的kpi，把他记录下来只是为了方便跟踪，同时有助于我们了解项目的可靠程度，因为bug越多说明项目越不靠谱，那么测试人员你就要小心了！

     工作就是一个不断犯错补错的过程，希望我曾经犯过的错能够给看到这篇文章的人带来一些帮助，少走点弯路！