图一根据MIEL描述了软件开发/维护的生命周期。在需求阶段需要确定非功能性需求。接着，对这些需求进行分析，那些可以测试的以及从客户的角度看来非常重要的需求将写入需求说明书，而其他的需求则作为设计目标加入设计中。
图一还指出了软件测试生命周期的不同阶段。请看表一中不同阶段的输入、输出和活动。测试用例开发和测试软件开发是并行活动，可以同时进行。
非功能性需求是相当难确定的，而且像可用性和可维护性这样的需求趋于变得很主观，因此很不容易测试。在这种情况下，确定那些能限定系统这些方面性能的客观属性会很有帮助。在另外一些情况下，比如抗压性和性能方面，在测试中如何进行模拟成为一个挑战。这就要求在软件测试生命周期的每一个阶段都要十分仔细，以确保为测试那些已确定的非功能性属性做好准备。
3. STLC with Non-functional Testing (NFT)
3. 非功能性测试的软件测试生命周期
Table (2) lists different categories of Non-functional Testing along with examples of attributes and brief test procedures for each one of them. Reference [1] has definitions of the different types of non-functional testing.
表二列出了非功能性测试的不同类型，并举出了属性的例子，同时简述了每一类的测试流程。参考一中有各类非功能性测试的定义。
No new phases are introduced into the test life cycle for NFT, but the scope of each activity is broadened to include NF requirements. Specific sections are added in the relevant documents to focus on NFT. The additional activities required in each phase to address non-functional testing are the following:
在非功能性测试的生命周期中并没有引如新的阶段，但是每一个活动的范围都变广了以此来涵盖非功能性需求。并且，在相应的文档中也加进了刻画非功能性测试的特定章节。以下将说明为非功能性测试而在每个阶段中增加的活动：
Test Planning:
测试计划：
Test team needs to identify the categories of non-functional requirements applicable to the project and document the measurable parameters and other requirements, which needs to be tested for in the SSTP. The inputs for this can be from requirements book or the design goals. Test team has to take active part in reviews to ensure that non-functionality requirements are specified in the requirements book and also they are verifiable (by testing, inspections or analysis). The requirements, which can be validated by testing, need to be identified in the SSTP. Example of requirements, taken from Single Cell WiLL project, is shown as Table(3). We will take the example of call setup time and identify what needs to be done in each phase for testing for this.
| Category | Parameter | Criteria | Remarks |
| Performance | Traffic Capacity | X E | |
| Call setup time | X ms | ||
| CLI command acknowledge time | X s | ||
| Usability | Installation | Single command | |
| Portability | Target platform | X BTS | System testing will be completely done on the target platform |
| Volume | No. of subscribers | <= X | Minimum functionality testing to be done with 3000 subscribers |
| Call Duration | TBD | ||
| Call success rate | 99% with 1000 calls minimum | ||
| Stress | Call handling capacity | X BHCA | |
| Concurrent calls | X for 3 sector 1 carrier config. | Possible to simulate in the lab? | |
| X for 6 sector 1 carrier config. | |||
| Call rate growth | X calls per sec. | ||
| Efficiency | GLI2 Memory | <85% usage | Testing need to be done under stress. |
| MCC memory | <90% usage | ||
| GLI2 CPU | <80% usage | ||
| BCP | <90% usage | ||
| CMP | <95% usage | ||
| Recovery | System start-up time | <45 mins. With complete OMC download | |
| <30 mins. with no GLI code download | |||
| V5 comm. Switchover | X s | ||
| GLI Switch over | Time TBD | ||
|
Table 3: Non functional requirements for SCWiLL X is used in place of actual values. | |||
测试团队需要确定可应用于项目的非功能性需求的类型并把可测量的参数以及在SSTP中需要测试的需求文档化。它的输入可以来自需求说明书或者设计目标。测试团队则需要在复查过程中充当积极的角色，这样才能确保需求说明书中说清了非功能性需求并且它们能够通过测试，走查或者分析的方法来验证。在SSTP中，要确定那些可以被测试验证的需求。表三中列出Single Cell Will 项目的需求，下面的论述将以调用启动时间为例并且指出在测试的各个阶段要完成的工作。
Once the non-functional requirements are identified, scheduling and resource requirements need to take care of these as well. This is critical as most non-functionality testing has vastly different requirements from the functionality requirements for the same product. Examples of things which need to be planned for include but are not limited to:
一旦非功能性需求确定下来，就需要注意进度和资源需求。这是非常关键的，因为在同一个项目中，大多数非功能性测试与功能性测试有着天壤之别。下面举出一些需要认真计划的事情：
– Hardware resources for stress and performance testing.
– Scheduling for the time required for volume testing
– Whether usability testing will be performed on prototype
– Sequencing of these tests
— 压力测试和性能测试所需的硬件资源
— 为容量测试的时间需求做安排
— 在原型上实施可用性测试
— 对这些测试进行排序
Even though the number of test cases required for NFT maybe very less compared to functionality testing, the effort requirements will be comparable to that for functional testing.
尽管相对于功能性测试，非功能性测试所需要的测试用例数量会比较少，但是它所需要付出的努力却是相当的。
Test Requirements:
测试需求：
The purpose of this phase is to specify refinements to the strategy as specified in the test plan and also to identify the test case, test setup and test software requirements. These and any other special requirements are identified in this phase. Automation and special tools are normally required for performance and load testing. Configuration testing and load testing sometimes have special setup requirements which need to be identified here. Also required are the user profile and subjects matching such profiles for usability testing. Also to be identified are requirements from the product to support NFT. This may include instrumentation, time measurement at specified points, deactivation of validation etc.
这一阶段的目的是按照测试计划中的说明使测试策略变得更加精细，并且要确定测试用例、测试启动和测试软件需求。以上的以及其他任何需求要在这个阶段得到确定。在性能和载入测试中通常会需要采用自动化和特殊工具。有时，配置测试和载入测试会需要特殊的启动必要条件，此时也要被确定。同时还要确定的是用户概貌以及与之匹配的用于可用性测试的主题。另外，产品需求中支持非功能性测试的需求也要确定，这包括设备、在特定点的时间测量以及确认的钝化等等。
In the case of call setup time for SCWiLL, the time difference between initiation and completion messages of call setup need to be measured. The call setup time will depend upon various factors, which need to be identified. Examples are :
在SCWiLL的调用启动时间的例子中，调用启动的初始化消息和完成消息上的时间差异需要测量。该调用启动时间的长短决定于多个需要确定的因素。例如：
– Current load on the system. Requirement-wise this translates into a script which maintains the load level on the system.
– 系统当前负载。
– RAM available. This decides the setup requirements.
– RAM可用性，这是决定启动的必要条件。
– Points of measurement. These can be inside or outside the system boundaries. And this decides whether a special build of the system is required with instrumentation of the entry and exit timings. Let us assume in this case that the measurement points are external to the system. Therefore the requirement for a tool / script which sends the origination message and receives and validates the setup completion message. The tool will need to send multiple messages like this and measure the response time.
— 测量点。它们可以位于系统边界的内部或者外部，并决定了是否用控制进出时机的工具来构建一个特殊系统。假设测量点位于系统外部，那么构建该特殊系统的必要前提是需要一个发送源以及接受并确认启动完成消息的工具。这个工具将会发出很多这样的消息来测量响应时间。
Test Software Development:
测试软件开发：
Load testing including volumes and stress is normally impossible to execute manually. Therefore automation scripts for this is a must. In many cases this will be an extension of the scripts required to do functional testing. It is also possible that requirements for specially developed tools exist for performance and stress testing
载入测试，以及容量测试和压力测试通常是不可能用手动执行。因此，必须使用自动操作脚本。在很多情况下，它是实施功能性测试所需脚本的一个扩展。此外，临时开发工具的需求在性能和压力测试中也可能存在。
In reference to the call setup time requirement, the tools and scripts required for generating the load level and also for measuring the setup time are developed in this phase.
谈到调用启动时间的需求，为生成载入标准以及测量启动时间所需要的工具和脚本需要在该阶段开发。
Test Execution
测试执行
The main difference from functionality test execution is that the preparation time normally is substantially more than the actual execution time. Examples are setup for stress and performance testing and preparation of a subject for usability testing. On the other hand in Volume testing, the test execution may go on and on.
与功能性测试的执行相比，非功能性测试的最大的不同之处在于准备时间比起实际运行时间来要长的多。例如压力和性能测试的启动以及可用性测试的准备工作。另外，在容量测试中，测试可能会不间断的运行。
In some cases, NFT may need a special build of the software. This will be required if instrumentation or deactivation of some validation is required for testing. In such cases inspection or analysis shall be used to ensure that such changes do not affect any other behavior of the system.
某些情况下，非功能性测试需要构建一个特殊的软件。比如需要使用设备或者测试中某个确认需要钝化。这种情况的话，就需要通过检查或者分析来确定这种变化不会对系统其他行为造成任何影响。
For the call setup time requirement, the tool is run under various load conditions and different setups and measurements are noted down.
对于调用启动时间需求的测试，测试工具将在各种各样的载入条件下运行，不同启动和测量结果将被记录下来。
Test Reporting
测试报告
Immediate reporting of NFT defects is required since most of such defects will be caused by design errors. In many cases the recreation of the issue by the development team will be impossible. This means that the test team will have to work closely with the development engineers at least till the cause is identified and isolated.
及时报告非功能性测试的缺陷是必需的，这是因为大多数缺陷都是由设计错误所引起的。很多情况下，开发人员不可能重新开发它们。这就意味着测试人员必须和开发人员至少要紧密协作到把原因搞清楚为止。
Test reporting phase for the call setup time problem involves coming up with the relationship of the call setup time with any dependent variable including RAM and the load. If the measured value does not meet the requirement under any case, the same is entered into the defect tracking system and tracked to closure.
调用启动时间测试的测试报告阶段涉及到建立调用启动时间和包括RAM以及载荷在内的任何独立变量之间的关系。假如测量值在任何情况下都不符合需求，那么同样要进入缺陷跟踪系统并被跟踪直到终止。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
