谈到软件测试时，很多相关书籍都会体到测试内容和意义：①程序测试是为了发现错误而执行程序的过程；②测试是为了证明程序有错，而不是证明程序无错误；③一个好的测试用例是在于它能发现至今未发现的错误；④一个成功的测试是发现了至今未发现的错误的测试。

但是软件测试决不等同于找BUG。我们在进行软件测试的时候，不能以发现错误为软件的唯一目的。软件测试同样是一个系统的工程，我们的测试工作一直都需要持续的改进，过程也需要不断完善，以下列出几个测试工作的总结，和大家分享。

测试工作重点应该关注输入/输出。

软件缺陷最常见的地方是哪里？一般来说软件缺陷最为密集的地方就是当用户输入非正常输入组合时。一方面软件设计人员较容易忽略一些极难发生的情况，另一方面设计与开发人员往往会把更多的精力用在功能实现上，容错与错误处理往往是开发上的薄弱环节。所以当测试人员将测试目标订在缺陷数量上时，重点测试非正常输入显然就是最好的手段。

软件各个阶段测试的参与和评估。

软件开发过程的每个阶段几乎都需要测试的参与。在软件的需求阶段，测试的工作不是很容易展开，我们可以在需求评审前做必要的测试。需求的测试用例更多的可以是需求流程的情景模拟。我们可能会花很多的图形和文字描述来说明需求中的边界和业务流程，这时，我们的测试用例也可以是一些模拟描述或者是一些假设性的FAQ作为补充，甚至可以把测试用例直接就在需求中进行补充。设计和实现阶段往往没有软件测试人员的参与，甚至有些企业在编码几乎完成了才开始组织测试团队。

同时对于技术可行性与用户需求之间的设计妥协，测试人员也必须要有充分的评估和理解。这样在最紧张的开发后期，才不会把大量的（测试及开发人员的）宝贵时间用于记录和处理那些已在设计阶段确定放弃的功能。

测试计划与测试文档的建立及维护。

测试计划和测试文档按道理在需求阶段就要建立。但是很多情况下这两个对于测试来说是非常重要东西却没有做好，要么敷衍了事，要么找个范本一抄，略作修改便万事大吉。真正测试起来还是全靠灵感与直觉。其实在需求一开始，我们就要不停的问自己，我们的测试计划起到作用了吗？我们的测试文档有没有及时的更新。

对缺陷的分析，报告及跟踪。

找到缺陷本身并不能提高软件的质量。只有缺陷被正确修复了才能真正提高软件的质量。一个好的测试人员不仅仅要善于发现缺陷，同时还要善于描述缺陷的表现特征，并积极跟踪缺陷的处理过程，确保缺陷被正确诊断及修复。对缺陷的报告和追踪可以保证项目的整个进度属于可控状态。实现阶段的测试主要针对的是软件的功能，这时检测和表现出来的错误相对较多，如果没有对缺陷进行追踪，开发人员不对问题进行分析，容易造成见子打子的局面，整天都被许多的问题困扰，都有改不完的缺陷。

错误的测试目标及测试终止条件。

没有缺陷的软件是不存在的。同时也没有方法可以知道一个软件中到底有多少个缺陷。随着测试做细，测试成本也是会升高的。必须考虑一个测试目标和测试终止的点。当然这个终止点一般很难有一个量化的数据。比如说需求的测试到底要做到多细？要花费多少比例的时间和人力来进行测试工作？要达到什么目标？这些问题虽然我们没有能有数据进行回答，但是必须要有这方面的考虑。

牢记软件测试的目的

软件测试的最终目的就是满足用户需求，提高产品的竞争力。只有满足了用户的需求，并能使用户用的方便、用的放心，用户才会对我们投赞成票。所以作为软件品质的最后把关者，软件测试要把用户的想法放在第一位。从设计测试计划到构造测试用例，从实际进行测试到跟踪缺陷处理，都要从用户的角度去考虑每一个问题。软件测试的另一个目标是尽早发现缺陷，降低修复及售后服务成本。显然，每一个已发布产品中的缺陷除了会影响产品及企业的声誉外，还会直接增加产品的售后服务成本。无论是派人到现场调试，或研发、发布补丁程序都要远比在发布前的修复成本昂贵数十倍，甚至数百倍。

随着软件行业的进一步发展，对软件测试及软件测试管理的要求也越来越高，尤其是在当前发达国家渐渐兴起软件外包浪潮的关键时刻，谁能提供低价可靠的软件开发服务，谁就能抢先占领市场，而高效经济的软件测试则必然会成为软件企业竞争力的最大助益。