测试分析——业内对测试分析有着不同的看法，是否取舍都有自己的市场。
A公司：流程非常严谨的公司：用户需求->软件需求->软件需求规格说明书->用例
B公司：取反（流程非常严谨的公司）：用户需求->产品需求->测试分析->用例
从A公司来看，所有输入质量都已非常稳定，具备了从需求直接到用例的粒度。测试只需要直接验证需求与功能的一致性即可。有点“被测试”的感觉。
从B公司来看，输入质量不高，产品需求更像一个功能清单，只知道我要什么，但是具体到你要的东西是否已经有另一种形式存在了？他与其他功能的联系是什么？他要的是A还是A'？因此，在这种情况下，需要有测试分析把问题统统理清。
结论是什么？……测试的世界里永远没有理想境界。
测试用例——这也许是最没有争论的东西。
我很少完全按着用例来执行，但我会把用例写得非常详细。
原因有：测试时，我已对功能验证点了如指掌。可过一阵子，我可能完全忘记它。
缺陷——需要测试来分析缺陷产生的原因吗？
之前看到有个文章说，提交缺陷时只需要描述现象即可，过多的分析可能会误导开发。但自从有一次，开发看到我缺陷描述中的原因分析，兴奋不已时。我才醒悟，“自己能做到的我从来不去麻烦别人”。分析问题原因也是一种测试，是对开发思想的测试。当然前提是你分析的依据是充分的。
测试报告——报告给谁看？
如果非要选出一个最需要看的对象。我觉得那就是你：如果你对自己的工作都不负责，那你期望谁对你的报告负责？
（以上言论仅代表作者的个人观点，不代表51Testing观点）
版权声明：本文出自int的51Testing软件测试博客：http://www.51testing.com/?227355
原创作品，允许转载，转载时请务必以超链接形式标明文章原始出处 、作者信息和本声明，否则将追究法律责任。
