1.目的
本文档的目的是描述任何软件开发项目中的软件测试活动，目的是提供一个标准的测试活动基准。 标准化的测试流程是被需要的,因为它可以提高项目测试的效率和有效性。
* 定义测试过程
* 确保测试过程可重复
* 确保系统中高风险的组件得到测试
* 缩小测试中由于测试人员的背景和技能的不同产生的影响
* 增加“intelligence”去测试
* 为管理和控制测试提供度量
* 为评估和改进测试提供度量
* 提供自动化测试的基础
* 产出具体的测试交付物
2.什么是软件测试？
测试活动的目标是在软件的真正用户使用前尽可能的发现更多的错误，我们使用测试去确定一个程序组件是否满足它的需求。
为了实现它的主要目标（发现错误）或者第二目标（满足需求）， 软件测试必须应用在一个系统方式中。
测试包括了一个系统的操作或者受控条件下的应用和结果评价。
验证和确认
验证和确认是一种软件测试活动去增强被构建的软件质量，V&V被计划并系统化的执行于整个软件生命周期。
* 验证是对一些内容的检查和测试，它包括对于软件规格符合性和一致性的检查，软件测试仅仅是验证的一种，还用到了一些其他的技术比如评审，分析，检查，走查
* 确认是针对那些被用户指定的，满足他们实际期望的需求的检查过程。确认活动可以开始于多数或者所有软件功能按照客户期望完成时。
* 确认测试提供最终的保证，确保软件满足所有功能，运行情况和性能需求。通常黑盒测试被用于该活动。
我们正确的构建了这个项目吗？
我们构建了正确的产品吗？
调试 测试
软件测试不应该与调试混淆。调试是指当软件没有像预期的运行时，进行分析并且找出Bug的过程。 虽然运行软件可以很明显的确认一些Bug，但是有系统地进行软件测试是一种更彻底地来发现 Bug的方法。 因此调试是一种支持测试的活动，但是不能替代测试。同时，不能保证有多少的测试可以发现所有Bug。
常见问题
* 需求不足-如果需求是不明确的、不完整的、太概括、或者不可测，那就会有问题
* 不切实际的进度安排-如果有限时间里有太多工作，不可避免地就会有问题
* 测试不足-在用户抱怨或者系统崩溃之前， 没有人知道程序好不好。
* 需求变更-开发后还有新功能需求提出，这也很普遍
* 沟通错误-如果开发人员不知道需要什么， 或者用户有不正确的期望，肯定会有问题
* 代码文档化不够-源代码中没有足够的注释，没有在文档中体现需求的变更
解决方案
* 可靠的需求-清晰、完整、详细、连贯的、可达到的、可测试的需求，并且取得所有相关人员的同意，可以使用原型的方法来明确需求。
* 合理的进度安排-为计划、设计、测试、缺陷修复、重测试、变更和文档编写预留足够的时间。
* 充分测试-尽早开始测试，在缺陷修复或变更后重新测试，为测试和缺陷修复计划充分的时间。
* 初始需求-做好在开发开始后大量变更和增加的准备，并且解释相应的结果。如果变更是必需的，应该在反映在相应的进度变更中。如果可能，在设计阶段采用快速原型，从而客户可以看到期望的结果。这可以帮助客户决定需求并且减少之后的变更。
* 沟通-在合适的时候要求走查和审查；使用团队沟通工具-电子邮件，缺陷跟踪工具和变更管理工具，intranet等；保证信息/文档的可用并且是最新的；促进团队工作和合作；尽早使用原型，以了解客户的期望。
3.谁需要执行软件测试？
执行软件测试人员最希望有以下技能：
发现问题的态度
了解客户的观点
关注细节
以下的技能可以帮助更好并且更有效的进行软件测试：
* 熟悉软件开发过程
* 在团队中提倡积极的氛围，尽管需要在系统中寻找“消极”的问题
* 有技巧的倡导质量保证过程
* 能够承担压力，在质量不能得到保证或者没有遵循流程的时候说“不”
* 能与技术、非技术人员、经理和客户等进行良好的沟通和交互
* 能够有效的记录并汇报缺陷
4.测试类型
以下列出一些交付前的常见的测试：
单元测试
集成测试
回归测试
系统测试
验收测试
安装测试
4.1.单元测试
单元可以定义为软件设计的最小可测元素。
单元测试是白盒测试技术。是基本路径测试。主要关注于一小部分代码，目标是执行大部分的内部路径。
路径是程序从入口到退出的指令顺序。最简单的方法是保证每个语句至少执行一次。更严格的准则是要求覆盖程序中的每一条路径。
比较实际的准则是至少执行一次每个决定的条件，并且保证所有的变量和参数通过最小值以下、最高值以上和中间值的测试。
白盒测试是所有测试技术中能发现最多错误的。事实上，有研究发现在大型的程序中，全面的路径和参数测试可以发现用户会遇到问题的72.9%。
4.2.集成测试
一个模块是一个有关联关系的源文件集。一个模块可以由相关的功能/单元组成。
集成测试是发现有接口关联的模块/单元相关的问题。模块按部件集成，这样可以比较容易地隔离并纠正错误。
集成测试包括白盒测试和黑盒测试。测试可以采用以下两种方法，自上而下和自下往上，同时也描述了测试的优点和缺点。
测试Driver和Stub(IT)
在集成测试中会用到测试driver和stub的概念。测试driver是一个软件，提供了一个可以设置输入参数、执行单元并且读取输出参数的框架，可以通过执行软件来进行测试。Stub是一个模拟单元，取代真实的单元来推动测试。
4.2.1.自上而下测试
在自上而下测试中，每一个单元通过从其他单元调用来测试，调用的单元与被调用的单元是隔离的。在结构顶端的单元先测试，所有其他被调用的单元由stub代替。继续用实际的被调用单元取代stub，同时下一层单元采用stub。重复这个过程直到最下面一层单元被测试。自上而下测试要求测试stub,而不是测试driver。
图1举例说明要测试单元D需要的测试stub和被测单元，假设在自上而下的方法中，单元A,B和C已经被测试了。
图1中说明了一个程序的测试计划，使用了自上而下的策略：
步骤1
测试单元A，单元B、C和D使用stub。
步骤2
测试单元B, 从已测的单元A中调用，单元C和D使用stub。
步骤3
测试单元C, 从已测的单元A中调用，单元B已测，单元D使用stub。
步骤4
测试单元D，从已测的单元A中调用，单元B和C已测，单元E、F、G使用stub。（如图2.1）
步骤5
测试单元E, 从已测试过的单元D中调用，同时从单元A中调用单元D，此时B和C已测试，单元F、G、H、I、J使用stub.
步骤6
测试单元F，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E已测试，单元G,H, I和J使用stub.
步骤7
测试单元G，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E,F已测试，单元H, I和J使用stub.
步骤8
测试单元H，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E, 其中B,C,E,F,G已测试，单元I和J使用stub.
步骤9
测试单元I，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中B,C,E,F,G,H已测试，单元J使用stub.
步骤10
测试单元J，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中B,C,E,F,G,H,I均已测试。
Figure 1: 自上而下测试
主要特点：先测试受控程序；模块逐步集成；强调接口测试。
优点：不需要测试driver；受控程序和一小部分模块形成基本的早期原型；可以尽早发现接口的错误；模块化的特性帮助调试。
缺点：需要测试stub;早期阶段较长，从而人员组建也会比较慢；关键但是低层的模块中包含的错误会很晚发现。
注释：尽早开始工作可以提升士气，同时帮助将进展情况呈现给管理层；但是实际中很难做到纯粹的自上而下。
4.2.2.自下而上测试
将单元与调用他们的单元隔离，但是使用被调用的单元进行测试。首先测试最底层的单元，然后推动上层单元的测试。其他单元使用被调用并已测试的单元进行测试。重复过程，直到最顶层的单元被测试。自下往上测试要求测试driver，但不需要测试stub。图2说明了测试单元D需要的测试driver和已测单元，假设单元E, F, G, H, I 和 J已经使用自下而上的策略进行了测试。
图2采用了自下而上的测试策略：
步骤1
（注意本步骤内的测试顺序不重要，步骤1中的所有测试可以被并行执行。）
测试单元H，使用driver从单元E调用；
测试单元I，使用driver从单元E调用；
测试单元J，使用driver从单元E调用；
测试单元F，使用driver从单元D调用；
测试单元G，使用driver从单元D调用；
测试单元B，使用driver从单元A调用；
测试单元C，使用driver从单元A调用；
步骤2
测试单元E，使用driver从单元D调用，H、I、J已测。
步骤3
测试单元D,使用driver从单元A调用，E、F、G、H、I、J已测。
步骤4
测试单元A，使用已测的B、C、D、E、F、G、H、I和J。
Figure 2: 自下而上测试
主要特点：允许尽早对特定模块的可行性和实用性进行测试；模块可以根据需要进行集成；主要关注模块的功能和性能。
优点：不需要测试stub;可以方便调配人力资源；关键模块的错误可以尽早发现。
缺点：需要测试driver；在一个可工作的程序出现之前，需要集成很多模块；较晚发现接口错误。
注释：在任何时候，与自上而下测试相比，有更多的代码被编写并测试。很多人认为自下而上是一种更为自发的哲学。
4.3.回归测试
当对软件做变更或者增加新的模块/单元时，可能会有新的数据流、I/O、控制逻辑。变更可能会影响已有的正常运行的功能。回归测试是运行所有已有的测试用例并且验证变更没有带来副作用的过程。
要保证修改没有带来新的错误，或者检查修改是否成功排除已有的错误，回归测试是最可靠的方法。每一次代码被修改或者在新的环境中使用，都应该进行回归测试来检查代码的完整性。理想状态下，每天晚上进行回归测试（自动的夜间build）来保证及时发现并修复错误。
回归测试最常用在已有测试的测试维护。在开发时，当往已经进行集成测试的系统中添加新的模块，也可使用回归测试。
4.4.系统测试
系统测试验证所有元素（模块/单元）配置正常，并且整个系统功能/性能达到要求。
在系统测试中，关注整体应用和环境。将系统作为整体而不是各个组件来测试。系统测试会发现集成测试中未发现的错误。
系统测试包括接口测试和压力测试。
4.5.接受测试（Alpha和Beta测试）
接受测试是向客户显示系统是可接受的过程。当客户软件建立后，客户可以做一系列的接受测试来验证需求。接受测试通常由最终用户执行。他们来决定系统是否满足准则。
大多数开发人员使用Alpha和Beta测试来发现只有最终用户才能发现的错误。Alpha测试由用户在开发现场进行，开发人员监控并记录错误和其他使用问题。
谢谢
