日志 > 恻鉽笁珵

写日志
倡议[幇莇濡婹幇莇哋亾]上一篇 | Software testing [one]下一篇 | 返回日志列表返回日志列表

Software testing [two]

阅读() 评论() 发表时间：2008年03月12日 20:47

本文地址：http://qzone.qq.com/blog/258070605-1205326046

Step 2步骤2
Test unit B, by calling it from tested unit A, using stubs for units C and D.
测试单元B, 从已测的单元A中调用，单元C和D使用stub。

Step 3步骤3
Test unit C, by calling it from tested unit A, using tested units B and a stub for unit D
测试单元C, 从已测的单元A中调用，单元B已测，单元D使用stub。

Step 4步骤4
Test unit D, by calling it from tested unit A, using tested unit B and C, and stubs for units E, F and G. (Shown in figure 2.1)
测试单元D，从已测的单元A中调用，单元B和C已测，单元E、F、G使用stub。（如图2.1）

Step 5步骤5
Test unit E, by calling it from tested unit D, which is called from tested unit A, using tested units B and C, and stubs for units F, G, H, I and J.
测试单元E, 从已测试过的单元D中调用，同时从单元A中调用单元D，此时B和C已测试，单元F、G、H、I、J使用stub.

Step 6步骤6
Test unit F, by calling it from tested unit D, which is called from tested unit A, using tested units B, C and E, and stubs for units G, H, I and J.
测试单元F，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E已测试，单元G,H, I和J使用stub.

Step 7步骤7
Test unit G, by calling it from tested unit D, which is called from tested unit A, using tested units B, C, E and F, and stubs for units H, I and J.
测试单元G，从已测试过的单元D中调用，同时从单元A中调用单元D，此时B,C,E,F已测试，单元H, I和J使用stub.

Step 8步骤8
Test unit H, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F and G, and stubs for units I and J.
测试单元H，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E, 其中B,C,E,F,G已测试，单元I和J使用stub.

Step 9步骤9
Test unit I, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G and H, and a stub for units J.
测试单元I，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中B,C,E,F,G,H已测试，单元J使用stub.

Step 10步骤10
Test unit J, by calling it from tested unit E, which is called from tested unit D, which is called from tested unit A, using tested units B, C, E, F, G, H and I.
测试单元J，从已测试过的单元E中调用，此时单元A调用单元D，单元D调用单元E，其中B,C,E,F,G,H,I均已测试。

Figure 1:  Top-down Testing自上而下测试
Major Features:             The controlled program is tested first
                     Modules are integratedone at a time
                     Major emphasis isone interface testing
主要特点：先测试受控程序；模块逐步集成；强调接口测试。

Advantages:           No test drivers are needed
                     The controlled program plus a few modules form. the basic early prototype
                     Interface errors are discovered early
                     Modular features aid debugging
优点：不需要测试driver；受控程序和一小部分模块形成基本的早期原型；可以尽早发现接口的错误；模块化的特性帮助调试。

Disadvantages:              Test stubs are needed
                     The extended early phases dictate a slow manpower buildup
                     Errors is critical modules at low levels are found late
缺点：需要测试stub;早期阶段较长，从而人员组建也会比较慢；关键但是低层的模块中包含的错误会很晚发现。

Comments:            An early working program raises morale and helps convince management progress is                   being made It is hard to maintain a pure top-down strategy in practice
注释：尽早开始工作可以提升士气，同时帮助将进展情况呈现给管理层；但是实际中很难做到纯粹的自上而下。

4.2.2.                  Bottom-up Testing自下而上测试
Units are tested in isolation from the units, which call them, but using the actual units called as part of the test. The lowest level units are tested first, and then used to facilitate the testing of higher level units. Other units are then tested using previously tested called units. The process is repeated until the unit at the top of the hierarchy has been tested. Bottom up testing requires test drivers, but does not require test stubs.  Figure 2 illustrates the test driver and tested units needed to test unit D, assuming that units E, F, G, H, I and J have already been tested in a bottom up approach.
将单元与调用他们的单元隔离，但是使用被调用的单元进行测试。首先测试最底层的单元，然后推动上层单元的测试。其他单元使用被调用并已测试的单元进行测试。重复过程，直到最顶层的单元被测试。自下往上测试要求测试driver，但不需要测试stub。图2说明了测试单元D需要的测试driver和已测单元，假设单元E, F, G, H, I 和 J已经使用自下而上的策略进行了测试。

A test plan for the program shown in Figure 2 using a strategy based on the bottom-up organization approach could read as follows:
图2采用了自下而上的测试策略：

Step 1步骤1
(Note that the sequence of tests within this step is unimportant, all tests within step 1 could be executed in parallel.)
（注意本步骤内的测试顺序不重要，步骤1中的所有测试可以被并行执行。）

Test unit H, using a driver to call it in place of unit E
Test unit I, using a driver to call it in place of unit E
Test unit J, using a driver to call it in place of unit E
Test unit F, using a driver to call it in place of unit D
Test unit G, using a driver to call it in place of unit D
Test unit B, using a driver to call it in place of unit A
Test unit C, using a driver to call it in place of unit A
测试单元H，使用driver从单元E调用；
测试单元I，使用driver从单元E调用；
测试单元J，使用driver从单元E调用；
测试单元F，使用driver从单元D调用；
测试单元G，使用driver从单元D调用；
测试单元B，使用driver从单元A调用；
测试单元C，使用driver从单元A调用；

Step (2)步骤2
Test unit E, using a driver to call it in place of unit D and tested units H, I and J.
测试单元E，使用driver从单元D调用，H、I、J已测。

Step (3)步骤3
Test unit D, using a driver to call it in place of unit A and tested units E, F, G, H, I and J. (Shown in figure 2).
测试单元D,使用driver从单元A调用，E、F、G、H、I、J已测。

Step (4)步骤4
Test unit A, using tested units B, C, D, E, F, G, H, I and J.
测试单元A，使用已测的B、C、D、E、F、G、H、I和J。

Figure 2:  Bottom-up Testing自下而上测试


Major Features:             Allows early testing aimed at proving feasibility and practical of particular modules
                     Modules can be integrated in various clusters as desired
                     Major emphasis is on module functionality and performance
主要特点：允许尽早对特定模块的可行性和实用性进行测试；模块可以根据需要进行集成；主要关注模块的功能和性能。

Advantages:           No test stubs are needed.
                     It is easier to adjust to manpower needs
                     Error in critical modules are found early
优点：不需要测试stub;可以方便调配人力资源；关键模块的错误可以尽早发现。

Disadvantages:              Test drivers are needed
                     Many modules must be integrated before a working program is available
                     Interface errors are discovered late
缺点：需要测试driver；在一个可工作的程序出现之前，需要集成很多模块；较晚发现接口错误。

Comments:            At any given point, more code has been written and tested than with top-down testing
                     Some people feel that bottom-up is a more intuitive philosophy
注释：在任何时候，与自上而下测试相比，有更多的代码被编写并测试。很多人认为自下而上是一种更为自发的哲学。
4.3.           Regression Testing回归测试
Whenever there is a change to the existing software or when new modules/units are added, there could be new data flow paths, new I/O, new control logics. These changes may impact the existing functions that were previously working flawlessly. Regression testing is the process of running all existing test cases and verifying that the changes have not propagated any side effects.
当对软件做变更或者增加新的模块/单元时，可能会有新的数据流、I/O、控制逻辑。变更可能会影响已有的正常运行的功能。回归测试是运行所有已有的测试用例并且验证变更没有带来副作用的过程。

Regression testing is theonly reliable way to ensure that modifications did not introduce new errors into code or to check whether modifications successfully eliminated existing errors. Every time code is modified or used in a new environment, regression testing should be used to check the code's integrity. Ideally, you perform. regression testing nightly (during automated nightly builds) to ensure that errors are detected and fixed as soon as possible
要保证修改没有带来新的错误，或者检查修改是否成功排除已有的错误，回归测试是最可靠的方法。每一次代码被修改或者在新的环境中使用，都应该进行回归测试来检查代码的完整性。理想状态下，每天晚上进行回归测试（自动的夜间build）来保证及时发现并修复错误。

Regression testing is most often used in testing maintenance to existing programs. It is also used when new modules are added to a system under development, which has already undergone integration testing.  
回归测试最常用在已有测试的测试维护。在开发时，当往已经进行集成测试的系统中添加新的模块，也可使用回归测试。
4.4.           System Testing系统测试
System testing verifies that all elements (modules/units) mesh properly and that overall system function/performance is achieved.
系统测试验证所有元素（模块/单元）配置正常，并且整个系统功能/性能达到要求。

In system testing the focus is on the whole application and its environment.  It is intended to test the system as a whole rather than individual system component.  Inevitably, System Testing reveals errors which were undiscovered during Integration testing.
在系统测试中，关注整体应用和环境。将系统作为整体而不是各个组件来测试。系统测试会发现集成测试中未发现的错误。

System testing involves Interface Testing and Stress Testing.
系统测试包括接口测试和压力测试。
4.5.           Acceptance Testing (Alpha and Beta Testing)接受测试（Alpha和Beta测试）
Acceptance Testing is a process of demonstrating to the customer that the system is acceptable. When customer software is built, series of acceptance tests are conducted to enable the customer to validate all requirements. Acceptance testing is usually performed by the end-users. They will work with the system to determine if it satisfies their criteria.
接受测试是向客户显示系统是可接受的过程。当客户软件建立后，客户可以做一系列的接受测试来验证需求。接受测试通常由最终用户执行。他们来决定系统是否满足准则。

Most software developers use a process called Alpha and Beta testing to uncover errors thatonly the end-users seems able to find.  The Alpha test is conducted at the developers’ site by the customer with the developer monitoring the recording of errors and other usage problems.
大多数开发人员使用Alpha和Beta测试来发现只有最终用户才能发现的错误。Alpha测试由用户在开发现场进行，开发人员监控并记录错误和其他使用问题。

The Beta test is conducted atone or more customer site by the end-user of the software.  Unlike Alpha testing, the developer usually is not present.  Therefore, Beta test is a ‘live’ application in an environment that cannot be controlled by the developer.


空间的其他文章：
倡议[幇莇濡婹幇莇哋亾]上一篇 | Software testing [one]下一篇 | 返回日志列表返回日志列表

发表评论

日志新版升级特性介绍 请选择道具

copyright © 1998 - 2010 Tencent Inc. all rights reserved 腾讯公司 版权所有