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

ljonathan

☆ 测试具有免疫性（软件缺陷免疫性）  

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

六月的雪

☆ 测试具有免疫性（软件缺陷免疫性）  

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

六月的雪

☆ 测试具有免疫性（软件缺陷免疫性）  

软件缺陷与病毒一样具有可怕的 “ 免疫性 ” ，测试人员对其采用的测试越多，其免疫能力就越强，寻找更多软件缺陷就更加困难。由数学上的概率论我们可以推出这一结论。假设一个 50000 行的程序中有 500 个软件缺陷并且这些软件错误分布时均匀的，则每 100 行可以找到一个软件缺陷。我们假设测试人员用某种方法花在查找软件缺陷的精力为 X 小时 /100 行。照此推算，软件存在 500 个缺陷时，我们查找一个软件缺陷需要 X 小时，当软件只存在 5 个错误时，我们每查找一个软件缺陷需要 100X 小时。实践证明，实际的测试过程比上面的假设更为苛刻，为此我们必须更换不同的测试方式和测试数据。该例子还说明了在软件测试中采用单一的方法不能高效和完全的针对所有软件缺陷，因此软件测试应该尽可能的多采用多种途径进行测试。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

六月的雪

测试反馈

将测试中发现的BUG反馈给该项目（模块）的负责人，由负责人对该BUG进行定位，并由相应的设计人员进行修改，如果测试人员发送的BUG并非该测试模块的BUG，则由该负责人转发给相应的负责人，由其定位，并指派设计人员修改。

52042722

适当的测试 (adequate testing) —— 尽早开始测试；每次改错或变更之后，都应重新测试。项目计划中要为测试和改错留出足够的时间。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

ljonathan

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

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

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

六月的雪

测试反馈

将测试中发现的BUG反馈给该项目（模块）的负责人，由负责人对该BUG进行定位，并由相应的设计人员进行修改，如果测试人员发送的BUG并非该测试模块的BUG，则由该负责人转发给相应的负责人，由其定位，并指派设计人员修改。

52042722

合理的时间表 (realistic schedules) —— 为计划、设计、测试、改错、再测试、变更、以及编制文档留出足够的时间。不应使用突击的办法来完成项目。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

52042722

可靠的需求 (solid requirements) —— 应当有一个经各方一致同意的、清楚的、完整的、详细的、整体的、可实现的、可测试的需求。为帮助确定需求，可使用模型 (prototypes)。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

ljonathan

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

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

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

水上飘

测试计划的制定

测试计划的制定要与项目开发的总体计划相吻合；测试计划中要充分考虑资源计划（人员安排，设备分配、与其它部门的协调配合以及其它不确定的因素）等；测试计划的制定还要考虑测试版本计划，与开发协调，按照版本生成计划（多长时间出一个版本），制定测试计划。

水上飘

测试计划的制定

测试计划的制定要与项目开发的总体计划相吻合；测试计划中要充分考虑资源计划（人员安排，设备分配、与其它部门的协调配合以及其它不确定的因素）等；测试计划的制定还要考虑测试版本计划，与开发协调，按照版本生成计划（多长时间出一个版本），制定测试计划。

304543223

将测试的BUG的状态进行分类(Active（激活），resolved（解决），postponed（推迟解决，external，fixed（修复），won’t fixed，（无法修复）by design（设计引起），not repro（不重现），closed（关闭）），并且一定要进行确认和跟踪。

52042722

尽可能坚持最初的需求 (stick to initial requirements as much as possible) —— 一旦开发工作开始，要准备防止修改需求和新增功能。要说明这样作的后果。如果必须进行变更，必须在时间表上有相应的反映。如果可能，在设计阶段使用快速的模型，以便使客户了解将会得到的东西。这将会使他们对他们的需求有较高的信心，减少以后的变更。

六月的雪

测试计划的制定

测试计划的制定要与项目开发的总体计划相吻合；测试计划中要充分考虑资源计划（人员安排，设备分配、与其它部门的协调配合以及其它不确定的因素）等；测试计划的制定还要考虑测试版本计划，与开发协调，按照版本生成计划（多长时间出一个版本），制定测试计划。