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

304543223

等价类中的元素的共同点：如果用等价类中的一个元素进行测试不能发现故障，那么使用等价类中其他元素进行测试液不可能发现故障。也就是说：对揭露软件中的故障来说，等价类中的每个元素是等效的。

304543223

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

六月的雪

从软件开发的过程按阶段划分有

　　
　　A.单元测试
　　B.集成测试
　　C.确认测试
　　D.验收测试
　　E.系统测试

水上飘

从软件开发的过程按阶段划分有

　　
　　A.单元测试
　　B.集成测试
　　C.确认测试
　　D.验收测试
　　E.系统测试

52042722

测试计划的制定

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

水上飘

将测试的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（关闭）），并且一定要进行确认和跟踪。

304543223

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

水上飘

从是否关心软件内部结构和具体实现的角度划分
　　A.白盒测试
　　B.黑盒测试
　　C.灰盒测试

52042722

时间节点的控制（与开发部门的协调控制）

保证测试计划中的全部测试用例跑一遍，如果未按预计的时间将所有计划中的测试用例走一遍，则需分析原因。

六月的雪

从是否关心软件内部结构和具体实现的角度划分
　　A.白盒测试
　　B.黑盒测试
　　C.灰盒测试

ljonathan

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

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

52042722

测试用例（TASE CASE）的编制与优先级的控制

以软件项目的层次图或模块分解图，按模块根据模块功能清单设计编写测试用例（TEST CASE），将测试用例按对系统的影响程度分成优先级。

测试原则：按照优先级的顺序从高到低完成测试用例的测试；测试用例的编制要充分考虑模块间的接口关系，对集成测试的流程要清楚。

六月的雪

☆ 测试是不完全的（测试不完全）  

很显然，由于软件需求的不完整性、软件逻辑路径的组合性、输入数据的大量性及结果多样性等因素，哪怕是一个极其简单的程序，要想穷尽所有逻辑路径，所有输入数据和验证所有结果是非常困难的一件事情。我们举一个简单的例子，比如说求两个整数的最大公约数。其输入信息为两个正整数。但是如果我们将整个正整数域的数字进行一番测试的话，从其数目的无限性我们便可证明是这样的测试在实际生活中是行不通的，即便某一天我们能够穷尽该程序，只怕我们乃至我们的子孙都早已作古了。为此作为软件测试，我们一般采用等价类和边界值分析等措施来进行实际的软件测试，寻找最小用例集合成为我们精简测试复杂性的一条必经之道。

六月的雪

测试计划的制定

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

水上飘

从是否关心软件内部结构和具体实现的角度划分
　　A.白盒测试
　　B.黑盒测试
　　C.灰盒测试

六月的雪

测试用例（TASE CASE）的编制与优先级的控制

以软件项目的层次图或模块分解图，按模块根据模块功能清单设计编写测试用例（TEST CASE），将测试用例按对系统的影响程度分成优先级。

测试原则：按照优先级的顺序从高到低完成测试用例的测试；测试用例的编制要充分考虑模块间的接口关系，对集成测试的流程要清楚

52042722

测试过程控制

合理的进行测试人员的组织与分配，按功能模块并结合测试人员的实际情况（人员素质、测试业务水平、工作态度）进行测试工作的安排（界面测试（风格、字体、提示信息、布局等）可安排一般测试人员）、功能和性能测试需有较深资历的人员进行测试）。

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

52042722

测试反馈

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