软件工程中的测试技术学习
一、 概述
测试的目的是试图说明一个程序可以做我们期望它所做的工作和在投入使用之前发现程序的缺陷。
如图1.1把被测试系统看作一个黑盒子，这个系统接收来自输入集合Ⅰ的输入数据，在输出集合0中产生输出结果。一些输出结果可能是错误的，这些错误输出在集合0e中，这些结果是由于集合Ⅰe中的输入而产生的。在缺陷测试中，优先去发现在集合Ⅰe中的输入，因为这会暴露系统的问题。有效性测试需要正确的输入来进行测试，这些输入是来自Ⅰe之外的。
1.1 程序测试的输入-输出模型
如图1.2是一个“传统”测试过程的抽象模型，用在计划驱动的开发中。测试用例是对一个输入和特定环境下的期望的输出以及所测试的对象的一个描述，测试数据是为了测试系统而设计的输入。在一些情况下测试数据可以自动产生。但自动测试用例生成是不可能的，因为了解系统应该怎样执行的人必须对期待的测试结果给出定义。测试可以自动执行，预期的结果自动地和预测的结果相比较，所以在测试过程中不需要人来查找错误和异常。
1.2 软件测试过程模型
一个商业软件系统要经过3个阶段的测试：
1.开发测试，即在开发中进行系统测试来发现故障和缺陷。在测试过程中很可能设计系统设计师和程序员。
2.发布测试，即一个测试小组对一个系统的完整版本进行测试，然后发布给用户。发布测试的目的是审查系统是否满足系统信息持有者的要求。
3.用户测试，及系统的用户在他们自己的环境中测试这个系统。
在实践中，测试过程通常既包含手工测试也包含自动测试。在手工测试中，测试人员用一些测试数据来执行程序，然后将结果和预期结果进行比较并报告给程序开发人员有差异的地方。在自动测试中，测试是通过一个程序去执行的，该测试程序会一遍遍地执行正在开发的系统。这个过程通常比人工测试速度快，尤其是当它要进行回归测试时——重新运行先前的测试以检测对程序的变更没有引入新的故障。
二、 开发测试
开发测试主要是一个缺陷测试的过程，即测试的目的是发现系统中的错误。因此，它通常和调试交错执行。调试是定位有问题的代码的过程，然后修改程序来解决这些问题。
1.单元测试
单元测试是测试程序组件的过程，程序组件列入方法或对象类。单个函数或方法是最简单的组价形式，我们的测试应该用不同的输入参数调用这些程序。
当我们测试对象类是，我们应该设计测试来提供对对象所有特征的覆盖。这意味着我们必须：
①测试与对象相关的所有操作；
②设置和检查与对象相关的所有属性；
③让对象处于所有可能的状态下，就是说要模拟所有能改变对象状态的事件。
2.选择单元测试案例
（1）黑盒测试
也称功能测试，它是通过测试来检测每个功能是否都能正常使用。在测试中，把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下，在程序接口进行测试，它只检查程序功能是否按照需求规格说明书的规定正常使用，程序是否能适当地接收输入数据而产生正确的输出信息。黑盒测试着眼于程序外部结构，不考虑内部逻辑结构，主要针对软件界面和软件功能进行测试。
黑盒测试方法
①划分等价类： 等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理地假定：测试某等价类的代表值就等于对这一类其它值的测试.因此，可以把全部输入数据合理划分为若干等价类，在每一个等价类中取一个数据作为测试的输入条件，就可以用少量代表性的测试数据.取得较好的测试结果.等价类划分可有两种不同的情况：有效等价类和无效等价类。
②边界值分析法：边界值分析是通过选择等价类边界的测试用例。边界值分析法不仅重视输入条件边界，而且也必须考虑输出域边界。它是对等价类划分方法的补充。
③因果图法：因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。
（2）白盒测试
白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，你清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。"白盒"法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。
（3）路径测试
路径测试是一种测试策略，其目标是要执行组价或程序中的每一条执行路径。如果每一个条独立路径都执行过，那么组件中的每条语句就肯定至少执行过一遍。
3.组件（接口）测试
软件的组件通常由许多彼此交互的对象组合的符合组件。首先关心的是测试组件接口行为是否符合它们的描述。
4.系统测试
开发中的系统测试包括集成组件来形成一各新版本的系统，然后测试集成后的系统。系统测试确保组件是可兼容的、能挣钱地进行交互，以及通过它们的接口在适当的时候传送正确的数据。它显然与组件测试重叠，但又两个重要的区别：
①在系统测试中，单独开发的可复用组件和商业现货系统可能会与新开发的组件集成到一起，然后对完整的系统进行测试。
②不同小组成员或群组开发的组件可能在这个阶段集成。
三、测试驱动开发
测试驱动开发（TTD）是一种程序开发方法，我们交错进行测试和代码开发。如图过程步骤为：
①从识别所需要的功能增量开始。
②针对此功能编写一个测试并实现为一个自动测试。
③运行此测试，以及所有已实现的其他测试。最初，我们并没有实现这个功能，因此这个新的测试将是失败的。这是有意的，因为它可以表明测试添加了一些新东西到测试集中。
④接着实现这个功能，并重新运行这个测试。这可能涉及重构现有的代码来改善它，并添加新的代码到已经存在的代码中。
⑤一旦所有的测试成功，我们可以转去实现下一个功能块。
测试驱动的开发
测试驱动开发的优势：
①帮程序员对问题有较好的理解。
②代码覆盖。
③回归测试：审查程序中的变更有没有引起新的错误。
④简化调试：当一个测试失败时，问题出在何处很明显。
⑤系统文档：测试本身就表现为一种文档形式，它描述了代码应该做什么。
四、发布测试
发布测试通常是一个黑盒测试过程，测试从系统描述导出。系统被作为一个黑盒子，它的行为只能通过输入和与它相应的输出来确定。这种测试的另一个名称叫做“功能测试”，因为测试者只关心系统的功能并不关心软件的实现。
1.基于需求的测试
好的需求工程实践的一个总的原则是需求应该是可测试的。基于需求的测试是一种系统化的测试用例设计方法，我们考虑每一个需求并得到它的一组测试。基于需求的测试是有效性验证测试而不是缺陷测试。
2.情景测试（脚本测试）
是发布测试的一个方法，设计典型的使用场景并使用这些来为系统开发测试用例。
3.性能测试
一旦一个系统已经完全集成，就可以测试它的总体特性了，这些总体特性的例子有性能和可靠性。性能测试必须设计以保证系统可以处理预期的负荷。要让负荷稳定地增长到系统性能不可接受为止。
性能测试是通过自动化的测试工具模拟多种正常、峰值以及异常负载条件来对系统的各项性能指标进行测试。负载测试和压力测试都属于性能测试，两者可以结合进行。通过负载测试，确定在各种工作负载下系统的性能，目标是测试当负载逐渐增加时，系统各项性能指标的变化情况。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。
内容：性能测试在软件的质量保证中起着重要的作用，它包括的测试内容丰富多样。中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络上性能的测试和应用在服务器端性能的测试。通常情况下，三方面有效、合理的结合，可以达到对系统性能全面的分析和瓶颈的预测。
五、用户测试
目前我们选择进行用户体验测试的一个非常重要目的是为了判定我们的产品是否能让用户快速的接受和使用，或更直接的说法是验证我们的产品是否会不符合用户的习惯，甚至让用户对产品产生抗拒。显然针对这一目的进行的用户体验测试介入时间一定要尽可能的早，试想如果在系统快要发布前才进行该项测试，非常可能因为在用户体验测试时发现页面结构不合用户操作习惯，或有些功能对于用户而言需要强化，或操作步骤过繁，在不推迟发布时间的情况下，此时对代码进行修改和优化，谁都知道这样的行为无疑是危险的。因此，较为合理的做法是当页面的demo定稿时我们就需进行用户体验测试，不过由于此时的测试是静态的，所以还不足以确保用户实际的操作感受，我们还需要在系统提交功能测试后，当功能测试人员验证主流程已能正常流转，用户体验测试就能再次介入进来，此时的用户体验测试不必像功能测试那样关注细节的实现，更重要的是收集用户的操作习惯和使用感受。假使我们不必说明使用方法用户就能流畅的进行操作并且在操作过程中不会对操作习惯进行过多的抱怨，那么我们能认为系统的交互、设计是合理的，反之，我们就需要考虑作出相应的修改和调整。