测试的“输入”

所谓的“输入”，就是测试同学能够搜集到的信息，包括但是不限于:

• 客户的原始需求和产品实现具体的方案
• “别人家”是如何实现的
• 开发提供的相关文档
• 自身(包括)团队的技术积累

无论是做什么产品，满足客户的需求都是最重要的，这个直接会体现在客户满意度和销售量上。那么理解客户的原始需求是非常重要的起点和根基。如果对需求理解出现偏差，那么就会导致“南辕北辙”的后果，越是投入，越是努力，浪费的资源就越多，偏差可能也越大。因为一般市场/销售/售后是直接接触客户的，因此和这些部门的同学保持顺畅的沟通就能尽可能地获得客户需求的方向和细节。等到产品开发出来后，测试起来也有的放矢。

相信绝大多数产品，市面上的供给都不会只有一家。有一些是在该领域深耕多年，有一些是刚刚杀入的新锐，还有一些可能是和本公司起头并进的竞争者。那么市场上的需求，有很大可能这些友商也会碰到，也会去实现。那么他们积累的经验或是踩到的坑，都可以转换为本公司加速产品成熟的助推器。除非能像苹果公司当年拿出iPhone/iPad这样划时代的创新产品，否则一味地低头蛮干，闭门造车，是难以收获到好的结果的。

开发人员毕竟是用代码对相关特性进行实现，因此在实现细节上天然就有相对于测试人员的优势，这个是客观存在。因此在研发的过程中，开发人员在交付的时候，需要保证相关文档同步甚至要超前一些交付给测试人员。这些文档都是测试人员提炼测试点的重要依据。当然，作为测试人员，不能盲目迷信这些开发文档，更不能“做成什么样子就照什么样子验证”。测试人员需要从纵向(前后版本兼容)和横向(与其它模块交互)多考虑，围绕客户场景进行测试验证。

无论是之前积累下来的测试框架和脚本，还是一些异常/压力/规格等测试思路，在面对版本迭代的时候都能有效地提高测试效率。即便是一个全新的模块或是特性，总归会有一些参照。测试人员必须对当前的技术发展趋势进行持续地跟踪，保证自己的知识储备与时俱进。

测试的“输出”

所谓的“输出”，就是测试周期结束后，究竟能留下什么东西。

• 测试评估报告
• 对开发工作的反馈
• 自身技术支持储备的更新

测试评估报告是测试过程中最重要的产出。应该包括详细的测试项和测试结果，记录测试过程中发现的问题。这份报告应该是产品部最终决定是否升级该版本最重要的参考依据。所以报告中对于测试过程中暴露的问题不能放过，也不能夸大，应该“如实”记录在案。即便当前版本来不及解决，借助一些问题跟踪工具，也不会将问题遗忘。测试报告的测试项建议使用表格形式，记录哪些测试项覆盖了，哪些因故没有覆盖。这样的好处是不会遗漏。

测试过程中，给开发的同学提交bug，本身就是一种对代码质量的反馈。另外针对开发文档的不足之处也要及时指出。

经历过一轮测试，测试人员要认真反思过程中发现的问题和发现问题的方法思路。建议在公司内部建立Wiki，方便技术积累和共享。对于需要反复进行的测试项，一定要想方设法提高自动化覆盖率。即便本轮测试来不及进行，在项目的间隙也要安排人力来予以解决，为后续测试提高效率打下基础。