1、测试概念的范畴
广义上讲，测试是指软件产品生存周期内所有的检查、评审和确认活动。如：设计评审、系统测试。
狭义上讲，测试是对软件产品质量的检验和评价。它一方面检查软件产品质量中存在的质量问题，同时对产品质量进行客观的评价。
2、测试的目的
简单地说，就是替用户受过，测试的最终目的是确保最终交给用户的产品的功能符合用户的需求，把尽可能多的问题在产品交给用户之前发现并改正。在可接受的开销下，提高对软件的信心。
具体地讲，测试一般要达到下列目标：
1） 确保产品完成了它所承诺或公布的功能，并且所有用户可以访问到的功能都有明确的书面说明------在某种意义上与ISO9001是同一种思想。最后，书面文档的不健全甚至不正确，也是测试工作中遇到的最大和最头痛的问题，它的直接后果是测试效率低下、测试目标不明确、测试范围不充分，从而导致最终测试的作用不能充分发挥、测试效果不理想。
2） 确保产品满足性能和效率的要求
使用起来系统运行效率低(性能低)、或用户界面不友好、用户操作不方便(效率低)的产品不能说是一个有竞争力的产品。用户最关心的不是你的技术有多先进、功能有多强大，而是他能从这些技术、这些功能中得到多少好处。也就是说，用户关心的是他能从中取出多少，而不是你已经放进去多少。
3） 确保产品是健壮的和适应用户环境的
健壮性即稳定性，是产品质量的基本要求，尤其对于一个用于事务关键或时间关键的工作环境中。另外就是不能假设用户的环境(某些项目可能除外)。
3、 测试的原则---GoodEnough
对于相对复杂的产品或系统来说，zero-bug是一种理想，good-enough是我们的原则。
Good-enough原则就是一种权衡投入 / 产出比的原则：不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负责任的表现。我们的操作困难在于：如何界定什么样的测试是不充分的，什么样的测试是过分的。目前状况唯一可用的答案是：制定最低测试通过标准和测试内容，然后具体问题具体分析。
4、 测试的规律----木桶原理和80-20原则
1） 木桶原理。
在软件产品生产方面就是全面质量管理(TQM)的概念。产品质量的关键因素是分析、设计和实现，测试应该是融于其中的补充检查手段，其他管理、支持、甚至文化因素也会影响最终产品的质量。应该说，测试是提高产品质量的必要条件，也是提高产品质量最直接、最快捷的手段，但决不是一种根本手段。反过来说，如果将提高产品质量的砝码全部押在测试上，那将是一个恐怖而漫长的灾难。
2） Bug的80-20原则。
一般情况下，在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的Bug，而系统测试又能找出其余Bug中的80%，最后的5%的Bug可能只有在用户的大范围、长时间使用后才会曝露出来。因为测试只能够保证尽可能多地发现错误，无法保证能够发现所有的错误。
5、传统测试流程遇到的挑战和对策----问题发现得越早，解决的代价就越小
对于测试理论，主要依据软件生命周期V字模型
可见软件测试贯穿了软件开发周期的大半，其各级测试的依据是对应开发阶段的各种详细文档。测试目前主要依赖于：测试人员的经验和素质；产品说明文档和项目组的技术咨询；测试工具的使用；测试计划的设计。
6、测试分类
按功能分：
–白盒测试(Whitetest)
–黑盒测试(BlackTest)
按测试时间来分：
–单元测试(UnitTest)
–集成测试(IntegrateTest)
–确认测试(ValidationTest)
–系统测试(SystemTest)
按运行状态来分：
–静态测试(StaticTest)
–动态测试(DynamicTest)
按方向来分：
–正向测试
–逆向测试
7、测试策略：
测试策略描述测试工程的总体方法和目标。描述目前在进行哪一阶段的测试（单元测试、集成测试、系统测试）以及每个阶段内在进行的测试种类（功能测试、性能测试、覆盖测试等）。
测试策略包括:
1、要使用的测试技术和工具；
2、测试完成标准；
3、影响资源分配的特殊考虑例如测试与外部接口或者模拟物理损坏、安全性威胁。测试计划最关键的一步就是将软件分解成单元，按照需求编写测试计划。
把软件分解成单元有几个好处：
1、软件需求是测试设计和开发测试用例的基础，分成单元可以更好地进行设计；
2、详细的测试需求是用来衡量测试覆盖率的重要指标；
3、测试的需求包括各种测试实际的开发以及所需资源。
测试计划的输入为被测软件、基于需求的测试设计；输出为测试过程和测试用例通过设计测试计划创建可以重用的测试过程和测试用例，同时维护测试过程、测试用例与相关测试需求的一一对应。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
