软件测试方式

1.考虑到各种输入

• 第一个就是用户从应用程序支持的设备输入UserID、User Name、Alt-F4组合键、Tab键等数据，
• 第二个就是操作系统提供的应用程序运行内存和与应用程序的网络连接。
• 优秀的、有经验的测试设计人员不仅会考虑合法的数据输入，也会考虑非法的和异常的输入。
• 如果用户在UserID中录入了乱字符或者在可接受的输入集外操作了Tab键会出现了什么情况？
• 如果可用内存不够程序会出现什么情况？
• 如果网络连接断线会出现什么情况？

2.错误集中发生现象

找到的软件缺陷越多，就说明软件问题越多.

第一，错误前置逻辑，错误前置逻辑具体表现为：

前置：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处理的。

第四，软件的基础构架问题，有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了

3.跟踪测试错误结果

        一般由A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。

有时候发现的BUG并不是真正的BUG（BUG相互之间的关联特性导致自动关闭，或者被发现的BUG可能悄悄且及时修复）。

4.合理安排测试计划.

• 好的测试计划竖立了一个正确的测试目标、组合了各种有针对性的测试方法、罗列了所有可使用资源等。
• 测试计划制定需要严谨，防止发生测试偏移现象。测试时间安排得尽量宽松（也就是说我们需要预留工作余量），
• 测试计划反映的就是一个测试团队在正常情况下所要完成的工作远景描述。
• 测试计划包含了确定测试需求、测试策略、资源、项目里程碑、可交付工件等几个关键章节

5.测试结果的全面检查

       

        测试结果内夹杂着大量正确的和错误的输出信息，需要我们仔细加以区分。不要让我们艰苦工作后的效果打折扣，这也是我们的口号。有的时候测试输出过于庞大，单靠人工分析有些力不从心，所以需要测试工具介入我们的工作。测试工具可以很好地帮助我们去鉴别测试后输出的数据，并且给出清晰的错误原因分析报告。

6.Pareto 原则应用于软件测试

• 20％的模块消耗80％的资源；
• 20％的模块包含80％的错误；
• 20％的错误消耗80％的修改成本；
• 20％的改进包含了80％的适应性为主的成本；
• 20％的模块占用了80％的执行时间；
• 20％的工具使用占80％的整个工具使用时间。

7.由第三方测试

        为了达到最佳效果，应该由独立的第三方来构造测试。“ 最佳效果 ”指最有可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件测试的最佳人选。