软件测试的原则？？？？？？

1、尽早不断测试的原则

应当尽早不断地进行软件测试。据统计约60%的错误来自设计以前，并且修正一个软件错误所需的费用将随着软件生存周期的进展而上升。错误发现得越早，修正它所需的费用就越少。

2、IPO原则

测试用例由测试输入数据和与之对应的预期输出结果这两部分组成。

3、独立测试原则

独立测试原则。软件测试工作由在经济上和管理上独立于开发机构的组织进行。程序员应避免检査自己的程序，程序设计机构也不应测试自己开发的程序。软件开发者难以客观、有效地测试自己的软件，而找出那些因为对需求的误解而产生的错误就更加困难。

合法和非合法原则。在设计时，测试用例应当包括合法的输入条件和不合法的输入条件。

错误群集原则。软件错误呈现群集现象。经验表明，某程序段剩余的错误数目与该程序段中已发现的错误数目成正比，所以应该对错误群集的程序段进行重点测试。

严格性原则。严格执行测试计划，排除测试的随意性。

覆盖原则。应当对每一个测试结果做全面的检查。

定义功能测试原则。检查程序是否做了要做的事仅是成功的一半，另一半是看程序是否做了不属于它做的事。

回归测试原则。应妥善保留测试用例，不仅可以用于回归测试，也可以为以后的测试提供参考。

错误不可避免原则。在测试时不能首先假设程序中没有错误。

扩展资料

编写软件测试计划要避免一种不良倾向是测试计划的“大而全”，无所不包，篇幅冗长，长篇大论，重点不突出，既浪费写作时间，也浪费测试人员的阅读时间。“大而全”的一个常见表现就是测试计划文档包含详细的测试技术指标、测试步骤和测试用例。

最好的方法是把详细的测试技术指标包含到独立创建的测试详细规格文档，把用于指导测试小组执行测试过程的测试用例放到独立创建的测试用例文档或测试用例管理数据库中。

测试计划和测试详细规格、测试用例之间是战略和战术的关系，测试计划主要从宏观上规划测试活动的范围、方法和资源配置，而测试详细规格、测试用例是完成测试任务的具体战术。

测试资源的变更是源自测试组内部的风险而非开发组风险，当测试资源不足或者冲突，测试部门不可能安排如此多的人手和足够时间参与测试时，在测试计划中的控制方法与测试时间不足相类似。

参考资料来源：百度百科-软件测试方法

参考资料来源：百度百科-软件测试计划

1、测试应该尽早进行，最好在需求阶段就开始介入，因为最严重的错误不外乎是系统不能满足用户的需求。

2、程序员应该避免检查自己的程序，软件测试应该由第三方来负责。

3、设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态，如网络异常中断、电源断电等。

4、应该充分注意测试中的群集现象。

5、对错误结果要进行一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格地确认，是否真的存在这个问题以及严重程度等。

6、制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成一个高水平的测试。

7、妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。

扩展资料：

测试过程：

1、对要执行测试的产品/项目进行分析，确定测试策略，制定测试计划。该计划被审核批准后转向第二步。测试工作启动前一定要确定正确的测试策略和指导方针，这些是后期开展工作的基础。只有将本次的测试目标和要求分析清楚，才能决定测试资源的投入。

2、设计测试用例。设计测试用例要根据测试需求和测试策略来进行，进度压力不大时，应该设计的详细，如果进度、成本压力较大，则应该保证测试用例覆盖到关键性的测试需求。该用例被批准后转向第三步。

3、如果满足“启动准则”（EntryCriteria），那么执行测试。执行测试主要是搭建测试环境，执行测试用例。执行测试时要进行进度控制、项目协调等工作。

4、提交缺陷。这里要进行缺陷审核和验证等工作。

5、消除软件缺陷。通常情况下，开发经理需要审核缺陷，并进行缺陷分配。程序员修改自己负责的缺陷。在程序员修改完成后，进入到回归测试阶段。如果满足“完成准则”（ExitCriteria），那么正常结束测试。

6、撰写测试报告。对测试进行分析，总结本次的经验教训，在下一次的工作中改进。

参考资料来源：百度百科--软件测试

软件测试基本原则

• 所有测试的标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求；

• “尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；

• 程序员应避免检查自己的程序，由第三方进行测试更客观有效；

• 穷举测试是不可能的；

• 充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；

• 设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；

• 注意回归测试的关联性，往往修改一个错误会引起更多错误；

• 测试应从“小规模”开始，逐步转向“大规模”；

• 测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；

• 重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）；
  对测试错误结果一定要有一个确认的过程
  

1. 尽早原则:软件测试应当越早越好，最好是在需求阶段就介入测试，因为最严重的致命错误不外乎系统不能满足用户的需求
2. 走查原则：程序开发人员避免检查自己的程序，应交于第三方来测试
3. 设计测试用例时应考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下还要制造极端状态和意外状态，如网络异常中断、电源断电等。
4. 应该充分注意测试中的群集现象。
5. 对错误结果要进行一个确认过程。一般由A测试出来的错误，一定要由B来确认。严重的错误可以召开评审会议进行讨论和分析，对测试结果要进行严格地确认，是否真的存在这个问题以及严重程度等。
6. 制定严格的测试计划。一定要制定测试计划，并且要有指导性。测试时间安排尽量宽松，不要希望在极短的时间内完成一个高水平的测试。
7. 妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便。
所有测试的标准都是建立在用户需求之上的，测试的目的在于发现系统是否满足规定的需求；
“尽早地和不断地测试”，越早进行测试，缺陷的修复成本就会越低；
程序员应该避免检查自己的程序，由第三方进行测试更客观有效；
穷举测试是不可能的；
充分注意测试中的群集现象，一段程序中一发现的错误数越多，其中存在的错误概率越大，因此对发现错误较多的程序段，应进行更深入的测试；
设计测试用例时应包括合理输入和不合理输入，以及各种边界条件、特殊情况下要制造极端状态和意外状态；
测试应从“小规模”开始，逐步转向“大规模”；
测试用例式设计出来，不是写出来的，应根据测试的目的，采用相应的方法设计测试用例，从而提高测试的效率，更多的发现错误，提高程序的可靠性；
重视并妥善保存一切测试过程文档（测试计划，测试用例，测试报告等）；
对测试错误结果一定要有一个确认的过程

我一直认为软件测试是一件很有原则的工作，这个原则是最重要的，方法都应该在原则指导下进行。软件测试的基本原则是站在用户的角度，对产品进行全面测试，尽早、尽可能多地发现 Bug，并负责跟踪和分析产品中的问题，对不足之处提出质疑和改进意见。软件零缺陷(Zero-Bug) 是一种理念，足够好（Good-Enough）是测试的基本原则。为了达到这个足够好，在软件测试过程中，应注意和遵循的一些基本原则，可以概括为以下几项，我认为适合绝大多数的软件测试工作了。
1. 所有测试的标准都是建立在用户需求之上。正如我们所知，软件测试的目标就是验证产品的一致性和确认产品是否满足客户的需求，所以测试人员要始终站在用户的
角度去看问题、去判断软件缺陷的影响，系统中最严重的错误是那些，导致程序无法满足用户需求的缺陷有那些。
2. 必须基于 “ 质量第一 ” 的思想去开展各项软件测试工作，当时间和质量冲突时，时间要服从质量。强烈质量的意识、理念和文化（如零缺陷、足够好的目标）同样是软件测试工作的基础。
3. 事先定义好产品的质量标准。有了质量标准，才能依据测试的结果对产品的质量进行正确的分析和评估，例如，进行性能测试前，应定义好产品性能的相关的各种指标。同样，功能及其它测试也应该事先定义好标准，包括测试用例应确定预期输出结果，如果无法确定测试结果，则无法进行校验。
4. 软件项目一启动，软件测试也就是开始，而不是等程序写完，才开始进行测试。这个观念现在越来越受重视了，在代码完成之前，测试人员要参与需求分析、系统或程序设计的审查工作，而且要准备测试计划、测试用例、测试脚本和测试环境，测试计划可以在需求模型一完成就开始，详细的测试用例定义可以在设计模型被确定后开始。应当把“尽早和不断地测试”作为测试人员的座右铭。
5. 穷举测试是不可能的。甚至一个大小适度的程序，其路径排列的数量也非常大，因此，在测试中不可能运行路径的每一种组合，然而，充分覆盖程序逻辑，包括业务逻辑、数据流程逻辑等，并确保程序设计中使用的所有条件是有可能的。
6. 第三方进行测试会更客观，更有效。程序员应避免测试自己的程序，为达到最佳的效果，应由第三方来进行测试。测试是带有 ”挑剔性” 的行为，心理状态是测试自己程序的障碍。同时对于需求规格说明的理解产生的错误也很难在程序员本人测试时被发现。 要做出“经得起考验和测试的产品”。
7. 软件测试计划是做好软件测试工作的前提。所以在进行实际测试之前，应制定良好的、切实可行的测试计划并严格执行，特别要确定测试策略和测试目标。 有效的测试策略和明确的测试目标。
8. 测试用例是设计出来的，不是写出来的，所以要根据测试的目的，采用相应的方法去设计测试用例，从而提高测试的效率，更多地发现错误，提高程序的可靠性。除了检查程序是否做了应该做的事，还要看程序是否做了不该做的事；不仅应选用合理的输入数据，对于非法的输入也要设计测试用例进行测试。 要知道好的测试用例真的会有效且事半功倍。
9. 不可将测试用例置之度外，排除随意性。特别是对于做了修改之后的程序进行重新测试时，如不严格执行测试用例，将有可能忽略由修改错误而引起的大量的新错误。所以，回归测试的关联性也应引起充分的注意，有相当一部分最终发现的错误是在早期测试结果中遗漏的。 其它所有工作都应该避免随意性。
10. 对发现错误较多的程序段，应进行更深入的测试。一般来说，一段程序中已发现的错误数越多，其中存在的错误概率也就越大。越需要深入和多次测试。
在实际的测试中时刻牵记这些基本原则，不仅会让工作更充分，而且会让工作越来越轻松，关键是有效果。所以让我们做有“原则性”的测试工作吧！