测试的原则.ppt

第一个就是用户从应用程序支持的设备输入User ID、User Name、Alt-F4组合键、Tab键等数据， 第二个就是操作系统提供的应用程序运行内存和与应用程序的网络连接。 优秀的、有经验的测试设计人员不仅会考虑合法的数据输入，也会考虑非法的和异常的输入。 如果用户在User ID中录入了乱字符或者在可接受的输入集外操作了Tab键会出现了什么情况？ 如果可用内存不够程序会出现什么情况？ 如果网络连接断线会出现什么情况？ 找到的软件缺陷越多，就说明软件问题越多. 第一，错误前置逻辑，错误前置逻辑具体表现为： 前置：A代码的逻辑是错误的表现为（伪true），B、C代码依赖于A代码表现为（true）。 A代码 - 测试 - 发现A代码的逻辑错误（伪true）。 A代码的逻辑修正 - A代码的逻辑（true）。 浅回归：A代码的逻辑（true） - 回归测试 - 确定A代码的逻辑（true）。 深回归：B、C代码（伪true） - 回归测试 - 确定B、C代码的逻辑（false）。 第二，实现人员的疲劳，实现人员的疲劳表现为实现人员因为疲劳工作，而造成了大量代码坏块。 第三，程序人员往往会犯同样的错误，因为大部分的代码都是Ctrl+V和Ctrl+C处理的。 第四，软件的基础构架问题，有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了。 一般由A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。 有时候发现的BUG并不是真正的BUG（BUG相互之间的关联特性导致自动关闭，或者被发现的BUG可能悄悄且及时修复）。 好的测试计划竖立了一个正确的测试目标、组合了各种有针对性的测试方法、罗列了所有可使用资源等。 测试计划制定需要严谨，防止发生测试偏移现象。测试时间安排得尽量宽松（也就是说我们需要预留工作余量）， 测试计划反映的就是一个测试团队在正常情况下所要完成的工作远景描述。 Rational公司的RUP软件开发过程中，测试计划是一个标准输出工件。 测试策略 测试范围 测试方法 测试安排 测试风险 测试管理 …… 测试计划包含了确定测试需求、测试策略、资源、项目里程碑、可交付工件等几个关键章节。我习惯将第4节资源从测试工件中剥离出来，比如将资源的分配和使用做到MS Project2000的表格中，具体如所示： 测试结果内夹杂着大量正确的和错误的输出信息，需要我们仔细加以区分。不要让我们艰苦工作后的效果打折扣，这也是我们的口号。有的时候测试输出过于庞大，单靠人工分析有些力不从心，所以需要测试工具介入我们的工作。测试工具可以很好地帮助我们去鉴别测试后输出的数据，并且给出清晰的错误原因分析报告。 测试团队管理者不称职。 测试团队之间沟通不畅。 测试团队和项目团队之间沟通不畅。 测试团队过程中，执行角色无准确定义。 测试团队无良好训练体制。 20％的模块消耗80％的资源； 20％的模块包含80％的错误； 20％的错误消耗80％的修改成本； 20％的改进包含了80％的适应性为主的成本； 20％的模块占用了80％的执行时间； 20％的工具使用占80％的整个工具使用时间。 为了达到最佳效果，应该由独立的第三方来构造测试。“ 最佳效果 ” 指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。 1、启动Windows的记事本，输入“联通”后保存至a.txt然后关闭记事本。再次打开记事本看看出现了什么变化，这是软件缺陷吗？为什么？ 2、为什么不可能完全测试程序？ 3、为什么错误不能完全修复？ 4、可以发布有缺陷的产品吗？为什么？ 5、请你考虑下面的测试后两幅图形输出，说说你对当前这个软件质量的看法： 6、对于反向思维逻辑，写出一些你在生活中的实际案例，多多益善。 考虑到各种输入 跟踪测试错误结果 合理安排测试计划 测试结果的全面检查 及时更新测试 由第三方测试 第一个就是用户从应用程序支持的设备输入User ID、User Name、Alt-F4组合键、Tab键等数据， 第二个就是操作系统提供的应用程序运行内存和与应用程序的网络连接。 优秀的、有经验的测试设计人员不仅会考虑合法的数据输入，也会考虑非法的和异常的输入。 如果用户在User ID中录入了乱字符或者在可接受的输入集外操作了Tab键会出现了什么情况？ 如果可用内存不够程序会出现什么情况？ 如果网络连接断线会出现什么情况？ 找到的软件缺陷越多，就说明软件问题越多. 第一，错误前置逻辑 第二，实现人员的疲劳，实现人员的疲劳表现为实现人员因为疲劳工作，而造成了大量代码坏块。 第三，程序人员往往会犯同样的错误，因为大部分的代码都是Ctrl+V和Ctrl+C处理的。 第四，软件的基础构架问题，有些软件的底层支撑系统