至于为什么要进行产品说明书的测试，统计资料表明，很多软件的缺陷都是因为产品功能说明书不够全面，经常更改造成的;另外，只有详细的阅读了产品功能说明书，确认产品需要实现的功能，才能拟定切实可行的测试方案。
其方法，具体地说有以下几种。
1.参照需求说明，检查产品功能说明书描述的产品将要实现的功能是否已经完整、准确、一致、合理的描述了产品的功能，并确保这些功能是可测试的。
2.研究产品说明书是否符合现有的软件设计开发的标准或规范。
3.研究同类软件，预测产品的最终结果。
可是如果应用到实际的开发流程中，又有着一定的困难。因为很难做到让软件测试人员在项目的初期就参与项目，一般要等到软件的雏形出来后才会让软件测试人员着手进行测试。即便是在初期测试人员参与项目，也只是根据产品说明书和设计计划制定测试计划。测试人员没有被赋予责任去检查产品说明书。
四，经济的测试。
测试是一项复杂的工作。因此要考虑其效率。经济的测试有几个原则。
1. 如果一个case(X)依赖另一个(Y)，如果Y失败，那么X可以不要测试。
2. 针对一个子集，如果一个输入导致了失败，那么剩下的输入可以不要测试。
3. 针对一个case，如果一个测试子集产生了失败，那么其他的子集可以不要测试。
由此，联想到一个实际问题。开发人员一次送测，按流程，应进行一轮全面的测试。但如果在测试初期发现了缺陷，此轮测试是否要继续?不继续，则此轮测试不完整，无法产出测试报告。继续到完全测试，如果发现的缺陷是严重的必须解决的缺陷，则后面的测试是不经济的，因为此缺陷修复后仍要进行全面的测试。
按照测试的原则，发现缺陷要及时地反馈给开发人员，以便及时了解软件状态。但在实际操作中，开发人员得到反馈后常常随即给出一个修复版，然后再一轮测试。造成的情况是，到项目结束，发现多少个缺陷，往往就经过多少轮测试，每一轮测试仅仅是验证对一个缺陷的修复。
所以我觉得，对于什么时候暂停测试，是否需要暂停，开发人员什么时候送测新的修复版本，应该有一个良好的控制。
五，自动测试
我们是用Rational Robot编写自动测试脚本进行自动测试。主要用与一些AP的UI测试。由于编写SQA Basic代价较高，所以应用于稍具复杂度的程序或需多轮回归测试的项目是比较经济的，如果是简单的UI，或不需进行多轮回归测试的项目，就要比较编写脚本的投入和实施自动测试的经济了。
如果多轮回归测试间程序变化比较多，改写脚本也是负担很重的工作。
以上是一点点心得，零散写下。
文章来源于领测软件测试网 https://www.ltesting.net/
