[活动]迎五一，庆周年，盖高楼(活动结束)

六月的雪

软件测试原则
        Good-enough: 一种权衡投入/产出比的原则
        保证测试的覆盖程度，但穷举测试是不可能的
        所有的测试都应追溯到用户需求
        越早测试越好，测试过程与开发过程应是相结合的
        测试的规模由小而大，从单元测试到系统测试
        为了尽可能地发现错误，应该由独立的第三方来测试
        不能为了便于测试擅自修改程序
        既应该测试软件该做什么也应该测试软件不该做什么

wolsion

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

wolsion

无效等价类:与有效等价类的定义恰巧相反.

wssgily

不好意思，刚才没有看清题目

high level test case 概要测试用例
没有具体的（实现级别）输入数据和预期结果的
测试用例。实际值没有定义或是可变的，而用逻
辑概念来代替。

六月的雪

在负载压力测试时，不进行功能校验，当功能发生错误时，测试工具不能够记录产生的错误，忽略了负载压力情况下的功能不稳定问题。所以负载压力测试期间必须要进行必要的功能内容校验，即在测试过程中记录所有虚拟用户的操作，及服务器的响应，才有助于判断功能错误，这是当前负载压力测试的最大挑战

六月的雪

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能.

水上飘

软件测试原则
        Good-enough: 一种权衡投入/产出比的原则
        保证测试的覆盖程度，但穷举测试是不可能的
        所有的测试都应追溯到用户需求
        越早测试越好，测试过程与开发过程应是相结合的
        测试的规模由小而大，从单元测试到系统测试
        为了尽可能地发现错误，应该由独立的第三方来测试
        不能为了便于测试擅自修改程序
        既应该测试软件该做什么也应该测试软件不该做什么

水上飘

1.3 数据校验
如果系根据业务规则需要对用户输入进行校验，需要保证这些校验功能正常工作。例如，省份的字段可以用一个有效列表进行校验。在这种情况下，需要验证列表完整而且程序正确调用了该列表(例如在列表中添加一个测试值，确定系统能够接受这个测试值)。
在测试表单时，该项测试和表单测试可能会有一些重复

walker1020

测试和质量(K2)
可以根据测试中所发现的缺陷，对软件功能和非功能性需求以及特性（例如：可靠性、可用性、效率、可维护性和可移植性)进行度量，从而评估软件质量。更多关于非功能测试方面的信息，可以参考第二章。更多关于软件特征的信息，可以参考“软件工程－软件产品质量（ISO 9126）”。
当测试发现很少或者没有发现缺陷的时候，测试就会帮助树立对于软件质量的信心。一个设计合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。

我们应该从以前的项目中吸取经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进软件开发过程(process)。然后，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。这是质量保证工作的一方面。
测试应该作为开发过程中质量保证工作的不可或缺的一部分（与开发标准、培训和缺陷分析一样）。

六月的雪

在负载压力测试时，不进行功能校验，当功能发生错误时，测试工具不能够记录产生的错误，忽略了负载压力情况下的功能不稳定问题。所以负载压力测试期间必须要进行必要的功能内容校验，即在测试过程中记录所有虚拟用户的操作，及服务器的响应，才有助于判断功能错误，这是当前负载压力测试的最大挑战

walker1020

测试是否充分 (K2)
在判断测试是否足够时，需要考虑下面的因素：风险（包括技术风险、商业产品风险和项目风险等）以及项目在时间和预算上的限制等（有关风险的详细内容参见第五章）。
测试需要给利益相关者提供足够的信息，帮助他们决定是否发布被测软件或系统。发布可以表示进入下一个开发过程，或将系统交付给用户。

六月的雪

测试和质量(K2)
可以根据测试中所发现的缺陷，对软件功能和非功能性需求以及特性（例如：可靠性、可用性、效率、可维护性和可移植性)进行度量，从而评估软件质量。更多关于非功能测试方面的信息，可以参考第二章。更多关于软件特征的信息，可以参考“软件工程－软件产品质量（ISO 9126）”。
当测试发现很少或者没有发现缺陷的时候，测试就会帮助树立对于软件质量的信心。一个设计合理的测试过程完成并顺利通过，可以降低整个系统存在问题的风险。而对测试过程中发现的缺陷进行了修正，则软件系统的质量就会提高。

我们应该从以前的项目中吸取经验教训。通过分析在其他项目中发现的缺陷和引起缺陷的根本原因，我们就可以改进软件开发过程(process)。然后，过程的改进又可以预防相同的缺陷再次发生，从而提高以后系统的质量。这是质量保证工作的一方面。
测试应该作为开发过程中质量保证工作的不可或缺的一部分（与开发标准、培训和缺陷分析一样）。

六月的雪

有效等价类:是指对于程序的规格说明来说是合理的,有意义的输入数据构成的集合.利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能

movestar

测试是 “ 泛型概念 ” （全程测试）

我一直反对软件测试仅存在于程序完成之后。如果单纯的只将程序设计阶段后的阶段称之为软件测试的话，需求阶段和设计阶段的缺陷产生的放大效应会加大。这非常不利于保证软件质量。需求缺陷、设计缺陷也是软件缺陷，记住 “ 软件缺陷具有生育能力 ” 。软件测试应该跨越整个软件开发流程。需求验证（自检）和设计验证（自检）也可以算作软件测试（建议称为：需求测试和设计测试）的一种。软件测试应该是一个泛型概念，涵盖整个软件生命周期，这样才能确保周期的每个阶段禁得起考验。同时测试本身也需要有第三者进行评估（信息系统审计和软件工程监理），即测试本身也应当被测试，从而确保测试自身的可靠性和高效性。否则自身不正，难以服人。

houzeal

数据库测试

movestar

另外还需指出的是软件测试是提高软件产品质量的必要条件而非充分条件，软件测试是提高产品质量最直接、最快捷的手段，但决不是一个根本手段。

medoraemon

测试人员可以有的放矢地进行某种确定条件的功能测试。

movestar

80-20 原则

80% 的软件缺陷常常生存在软件 20% 的空间里。这个原则告诉我们，如果你想使软件测试有效地话，记住常常光临其高危多发 “ 地段 ” 。在那里发现软件缺陷的可能性会大的多。这一原则对于软件测试人员提高测试效率及缺陷发现率有着重大的意义。聪明的测试人员会根据这个原则很快找出较多的缺陷而愚蠢的测试人员却仍在漫无目的地到处搜寻。

movestar

80-20 原则的另外一种情况是，我们在系统分析、系统设计、系统实现阶段的复审，测试工作中能够发现和避免 80% 的软件缺陷，此后的系统测试能够帮助我们找出剩余缺陷中的 80% ，最后的 5% 的软件缺陷可能只有在系统交付使用后用户经过大范围、长时间使用后才会曝露出来。因为软件测试只能够保证尽可能多地发现软件缺陷，却无法保证能够发现所有的软件缺陷。

六月的雪

在目前的国内环境下，我们几乎看不到完整准确的客户需求说明书，加以客户的需求时时在变，追求完美的测试变得不太可能。因此作为一个优异的测试人员，追求软件质量的完美固然是我们的宗旨，但是明确软件测试现实与理想的差距，在软件测试中学会取舍和让步，对软件测试是有百益而无一弊的。