一、软件测试的目的
1）软件测试是为了发现错误而执行程序的过程。
2）测试是为了证明程序有错，而不是证明程序无错。（发现错误不是唯一目的）
3）一个好的测试用例在于它发现至今未发现的错误。
4）一个成功的测试是发现了至今未发现的错误的测试。
注意：
1、测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征。可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，通过分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。
2、没有发现错误的测试也是有价值的，完整的测试是评定测试质量的一种方法。详细而严谨的可靠性增长模型可以证明这一点。例如Bev Littlewood发现一个经过测试而正常运行了n个小时的系统有继续正常运行n个小时的概率。
二、软件测试的原则
1）应当把“尽早地不断地进行软件测试“作为软件开发者的座右铭。
2）测试用例应由测试数据和与之对应的预期输出结果这两部分组成。
3）程序员应避免检查自己的程序。
4）在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。
5）充分注意测试中的群集现象。
6）严格执行测试计划，排除测试的随意性。
7）应当对每一个测试结果做全面的检查。
8）妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
三、软件测试的流程
立项阶段-需求阶段----设计阶段----编码和单元测试阶段----集成测试阶段----系统测试阶段-----验收测试阶段-----结项总结阶段
补充：
根据不同的测试阶段，测试可以分为单元测试、集成测试、系统测试和验收测试。
体现了测试由小到大、又内至外、循序渐进的测试过程和分而治之的思想。
单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。
集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既验证“设计”，又验证“需求”。
系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。
验收测试与系统测试相似，主要区别是测试人员不同，验收测试由用户执行。
黑盒测试不考虑程序内部结构和逻辑结构，主要是用来测试系统的功能是否满足需求规格说明书。一般会有一个输入值，一个输入值，和期望值做比较。
白盒测试主要应用在单元测试阶段，主要是对代码级的测试，针对程序内部逻辑结构，测试手段有：语句覆盖、判定覆盖、条件覆盖、路径覆盖、条件组合覆盖
集成测试主要用来测试模块与模块之间的接口，同时还要测试一些主要业务功能。
系统测试是在经过以上各阶段测试确认之后，把系统完整地模拟客户环境来进行的测试。
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/sinat_33718563/article/details/73826381
补充：
软件测试基于不同的立场，存在着两种完全不同的目的。从用户的角度出发，普遍希望通过软件测试暴露软件中隐藏的错误和缺陷，以考虑用户是否可以接受该产品。而从软件开发者角度出发，则希望测试成为表明软件产品不存在错误的过程，验证该软件已正确地实现了用户需求，确立人们对软件质量的信心。因此他们会选择那些导致程序失效概率小的测试用例，回避那些易于暴露程序错误的测试用例。同时，也不会着意去测试，排除程序中可能包含的付作用。显然，这样的测试对完善和提高软件的质量毫无价值。因为在程序中往往存在着许多预料不到的问题，可能被疏漏，许多隐藏的错误只有在特定的环境下才可能暴露出来。如果不把着眼点放在尽可能查找错误这样的基础上，这些隐藏的错误或缺陷就测试不出来，就会遗留到运行阶段中去。如果站在用户的角度上，替他们设想，就应该把测试活动的目标对准揭露程序中的错误，在选取测试用例时，会从各种角度考虑那些易于发现程序错误的一些测试数据与用例。
有鉴于此，Grenford J.Myers就软件测试目的提出以下观点：
（1） 测试是程序的执行过程，目的在于发现错误；
（2） 一个好的测试用例在于能发现至今未发现的错误；
（3） 一个成功的测试是发现了至今未发现的错误的测试；
测试的目的是想以最少的时间和人力找出软件中潜在的各种错误和缺陷。如果成功地实施了测试，就能够发现软件中的错误。测试的附带收获是，它能够证明软件的功能和性能与需求说明相符。此外，实施测试收集到的测试结果数据为可靠性分析提供了依据。
根据这样的测试目的，软件测试的原则应该是：
（1）应该尽早地和不断地进行软件测试。由于原始问题的复杂性，软件的复杂性和抽象性，软件开发各个阶段的多样性，以及参加开发各种层次人员之间的配合关系等因素，使得开发的每个环节都可能产生错误。所以不能把软件测试看成是软件开发的独立阶段，而应该把它贯穿到软件开发的各个阶段中。坚持软件开发的各个阶段的技术评审，这样才能在开发过程中尽早发现和预防错误，把软件错误尽量在早期发现，杜绝某些隐患、提高软件质量。
（2）测试用例应该由测试输入预置条件和与之对应的预期输出结果这两部分组成。测试之前应该根据测试要求正确选取需要执行的测试用例。
（3）程序员应该避免检查/测试自己的程序。测试工作需要严格的作风，客观的态度和冷静的情绪。人们常常由于各种原因具有一种不愿否定自己工作的心态，认为揭露自己程序中的问题总不是一件愉快的事。这一心态就成为测试自己程序的障碍。另外，程序员对软件规格说明理解错误而引入的错误则更难发现。如果由别人来测试程序员编写的程序，可能会更客观、更有效、并且等容易取得成功。要注意的是，这点不能和程序调试相混淆。调试由程序员自己来做可能更有效。
（4）在设计测试用例时，应该包括合理的输入条件和不合理的输入条件。合理的输入条件是指能够验证程序正确的输入条件，而不合理的输入条件是指异常的临界的，可能引起问题异变的输入条件。在测试程序时，人们往往更多的考虑合法的和期望的输入条件，而忽略了不合法和意想不到的输入条件。事实上，软件在投入运行之后，用户的使用往往不遵循事先的约定，使用了一些意外的输入。如果开发的软件遇到这种情况时不能做出适当的反应，给出相应的信息，那么就容易产生故障，轻则产生错误的结论，重则导致软件失效。因此软件系统处理非法命令的能力在测试时也必须考虑。用不合理的输入条件测试程序时，往往比用合理的输入条件进行测试能够发现更多的错误。
（5）充分注意程序测试中的群集现象。测试中不要以为找到程序中的几个错误，问题就已经解决，不需要继续测试了。经验表明，测试后程序中残存的错误数目与该程序中中已发现的错误数目或检错率成正比。根据这个规律，应当对错误群集的程序段进行重点测试，以提高测试投资的效益。在测试软件程序时，若发现的错误越多，则残存在程序中的错误数目可能就越多，这种错误群集性现象，已为许多程序的测试实践所证明。例如美国IBM公司的OS/370操作系统中，47％的问题仅与该系统4％的程序模块有关。这种现象对测试很有用。如果发现某一程序模块比其它的程序模块有更多的程序错误趋向时，则应该化更多的时间和代价测试这个程序模块。
（6）严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选取，测试的控制方式和过程。系统的组装方式，跟踪规程，以及回归测试的规定等和测试结束准则。
（7）应对每一个测试结果做全面检查。这是一条最明显的原则，但常常被忽视。有些错误的征兆在输出实测结果时已经明显地出现了，但如果不仔细地全面检查测试结果，就会使这些错误被遗漏掉。所以在设计测试用例时必须对预期的输出结果明确定义，对实测结果仔细分析检查，抓住征候，充分暴露问题。
（8）妥善保存测试计划，测试用例，出错统计和最终分析结果，为维护提供方便。
（9）所有的测试应该追溯到用户需求。正如我们所知，软件的测试目标在于揭示错误。而最严重的错误（从用户角度上看）是那些程序不能满足用户需求的错误。
（10）测试应该从“小规模”开始，逐步转向“大规模”即渐增式build测试。
