软件测试管理中英文资料外文翻译文献
基于价值的软件测试管理外文文献翻译中英
基于价值的软件测试管理外文文献翻译(含：英文原文及中文译文)文献出处：Ramler R, Biffl S, Grünbacher P. Value-Based Management of Software Testing[M]// Value-Based Software Engineering. Springer Berlin Heidelberg, 2006:225-244.英文原文Value-Based Management of Software TestingR Ramler ，S Biffl ，P GrünbacherAbstractTesting is one of the most resource-intensive activities in software development and consumes between 30 and 50% of total development costs according to many studies. Testing is however often not organize the maximization of business value, nor is it to shoulder the mission of the project. Path testing, branch testing, guidance testing, transformation testing, scenario testing, and requirements testing are all equally important in all aspects of software. However, 80 percent of the value in practice often comes from 20 percent of software. In order to get the maximum return on investment from software testing, test management needs to maximize its value contribution. In this chapter, we will further promote the need for value-based testing, describe the practices that support value-based test management, outline the framework for value-based test management, and illustrate the framework.Keywords: value-based software testing, value-based testing, test costs, test benefits, test managementIntroductionTesting is the most important and widely used method in the software quality assurance process. The checksum verification aims to ensure that the software runs correctly and ensures the quality of the software and the reliability of the software through comprehensive analysis. In IEEE 610.12 (1990), a test is defined as the activity of observing and recording an executed system or component under specified conditions and evaluating the system or component.Tests are widely used in practice and play an important role in many organizations that ensure quality strategies. Software affects the daily lives of tens of thousands of people and shoulders arduous tasks. Therefore, software will be particularly important in the near future. Research shows that testing usually consumes 30% to 50% of software development costs. Even higher proportions of safety critical systems are not surprising. Therefore, the challenge of software testing is to find more effective ways to conduct effective testing.The value of software test management is to strive to reduce test costs and meet demand. Valuable test management can also provide good guidance on project goals and business value. In the first chapter, Boehm cited many potential testing costs. This example illustrates the use of 7%of the customer checkout type to complete a 50% software test benefit. Although 100% testing is an impractical goal, there is still room for improvement and savings to achieve the desired value by adjusting test methods. The value power based on software engineering lies in the fact that current software engineering practice research is equally important in terms of requirements, test cases, test objects, and product defects. This pair of tests is clearly correct and it contributes indirectly to the value of the product. The separation of development and testing makes this problem even more prominent. Testing is often a purely technical issue that will make the relationship between testing and business decision-making more closely linked. This chapter mainly describes the need to improve value-based test management, explains its basic elements, discusses existing examples to support value-based testing, and the basic framework of value-based test management. The basic structure of the rest of this chapter is as follows: Section 11.2 discusses the value of test management contributions; Section 11.3 discusses the case studies of test management support; Section 11.4 describes the value-based test management framework with examples. At the end of this chapter, we will further study the specifics.Description Based on Value TestThe goal of value-based checksum verification is defined as ensuring that the implementation of the software meets its intended target valuebenefits. If we consider from the perspective of value, then where should the contribution of the test be? Basically, it can be considered from two aspects: The internal aspect includes the test cost and the test benefit, the external aspect emphasizes the future system threat and the opportunity. The key to value-based testing is to combine these two aspects, that is, to adjust the internal testing process through customer and market requirements.In order to combine both internal and external factors, it is obviously not appropriate to focus solely on technical tests. On the contrary, test management needs a global grasp.Example 41 describes the dependencies between the internal and external aspects of test management. The internal aspect is like the test manager's control over the entire project. The expenses in this area mainly come from software testing practice and short-term and long-term testing. The external aspect is considered to be some of the benefits and parameter data that the test supervisor can control. Value-based software test management enables testing to satisfy value-based value propositions and focus the entire team on valuable test directions.The first question for an external view of software testing is “How do we ensure the value objectives of the software system?” This goal is to test the valuable parts of the software focus, the most important qualities, and the timely adjustment of project risks by coordinating valuepropositions. Answering such questions includes market opportunities, project value propositions, and cost-effectiveness. Refer to the first chapter for a detailed introduction to opportunities and risks, and refer to Chapter 7 for the introduction and reconciliation of value propositions. Internal views are based on the benefits of value propositions, and the test budget represents an approximate level of the entire project. The main problem is how to use testing as an investment activity. In order to be able to test efficiently and quickly and reduce the development budget. Appropriate internal and external communication coordination can satisfy the benefits of testing.The value contribution of the testCompared to other development processes such as code and user interface design, testing does not immediately create value for the product. However, testing provides and supports valuable task activities generated during software development. The key to understanding the value of test contributions is the contribution of the test. The contribution of the test establishes the relationship between the test and the value of the final product value.The most direct customers are program developers and project managers who are directly linked to the test team. The concentration of power in value-based software engineering testing is the customer and the user (see Chapter 7). Customers and users conduct testing by setting thecontext and scope to reach the value goal of the test.Tested customersDevelopers, project managers, quality supervisors, customers, analysts, end-users or maintenance staff all benefit from the analysis of software systems, rely on feedback to detect problems, reduce uncertainty, and make relevant decisions to accelerate product development. .The following example shows feedback from different groups for test requirements:The extent to which the customer and the user are satisfied with the need for consistency and to what extent the software's value benefits are satisfied. Testing also provides visibility and insight into the progress of the project. The test results can be used to understand the test cases that have passed. When the acceptance test appears unpractical or fails to appear in the actual environment, the α and β tests provide a more solid basis to verify the results. ∙ Sales and product executives obt ain relevant information from test plans, pricing, promotions, and distribution. The difference between the actual quality of the product and the quality expected by the customer and the user can easily lead to misunderstandings and misconceptions that reduce or prevent the realization of true value. In order to be able to successfully meet these expectations and meet the goals of individuals or organizations, product design is adjusted to customer needs to meet certain functions. For projectmanagers, testing supports risk management and project process estimation. The focus is on identifying and eliminating the risk of potential damage and the suppression of value merit. The serious shortcomings that significantly reduced project performance in the early stages were a major goal. Testing reduces uncertainty and helps project managers make better, smarter decisions about removing defects, system stability, and product updates.Quality managers are more interested in the identification of issues and dynamic trends in specific issues. The test results helped the evaluation of the project, the assurance of the quality strategy and the improvement of the process. Rosenberg discusses how testing can contribute to ensuring quality and shows how test problems can be verified as how to improve the process of the project. Developers and users understand the current state of related issues and provide relevant data to measure and predict software quality and reliability.Developers often need to obtain feedback to verify that the test implementation is complete, meets standards, and meets quality requirements. In order to ensure stability, the test provides detailed information about the defect and indicates why the test failed. In addition, tests provide feedback on the improvement of project defects. For example, it is necessary to pay attention to the need to test whether the original function has been changed or the decline has occurred with therelevant changes.For demand engineers, testing is valuable for verifying and confirming requirements. Weinberg once pointed out that "one of the most effective methods is to pass test cases just like testing a complete system to form test requirements." Black box testing can help ensure their integrity, accuracy, transparency, and conciseness through the help of their needs. So testing can increase requirements and move toward test-driven.In short, testing can improve benefits by making plans less uncertain and risky, make related decisions, and strive to control the minimization of unnecessary consumption (internal causes). More importantly, it helps to realize the expected value benefits. The benefits of these benefits are not free, and the cost of testing is often significant (external reasons). Tests can be understood as buying information and can also be considered as reducing cost risks and reducing uncertainty of investment activity. Investment in costs and benefits requires making relevant decisions about test needs. So the next two questions are: What is the cost of testing and what is the test benefit of value activity?中文译文基于价值的软件测试管理作者：R Ramler ，S Biffl ，P Grünbacher摘要根据研究表明测试已经成为软件开发过程中一个很重要的环节, 它占据了整个软件开发成本的百分之三十到五十。
软件测试管理制度模板英文
软件测试管理制度模板英文1. IntroductionSoftware testing is a crucial part of the software development process, ensuring the quality and reliability of the final product. An efficient and effective software testing management system is essential for the successful completion of any software project.This document outlines the software testing management system that will be used for all software testing activities within the organization. It describes the processes, procedures, roles, and responsibilities that will be followed to ensure that all software testing is carried out in a systematic and organized manner.2. ObjectivesThe objectives of the software testing management system are as follows:- To ensure that software testing is carried out in a systematic and organized manner.- To define the roles and responsibilities of the testing team.- To establish processes and procedures for conducting all types of software testing activities.- To ensure that the software testing activities are aligned with the overall software development process.- To provide a framework for continuous improvement of the software testing process.3. ScopeThe software testing management system will cover all software testing activities within the organization. This includes, but is not limited to, the following:- Functional testing- Non-functional testing (performance, security, usability, etc.)- Integration testing- System testing- User acceptance testing4. Roles and Responsibilities4.1 Test ManagerThe test manager is responsible for overseeing all software testing activities. Their responsibilities include:- Defining the overall testing strategy and approach for each project.- Planning, directing, and coordinating all testing activities.- Ensuring that the testing activities are aligned with the software development process. - Monitoring and controlling the progress of the testing activities.- Reporting on the status and results of the testing activities to project stakeholders.4.2 Test Analyst/Test EngineerThe test analyst/test engineer is responsible for carrying out the testing activities. Their responsibilities include:- Analyzing the requirements to identify the test scenarios and test cases.- Developing test cases based on the requirements and test scenarios.- Executing the test cases and recording the results.- Analyzing and reporting any defects found during testing.4.3 Test CoordinatorThe test coordinator is responsible for coordinating the testing activities. Their responsibilities include:- Scheduling and coordinating the activities of the test team.- Establishing and maintaining the test environment.- Managing the test data and test tools.5. Testing Process5.1 Test PlanningThe test planning phase involves defining the testing strategy and approach for the project, as well as identifying the scope and objectives of the testing activities. The test manager is responsible for developing the test plan, which should include the following:- Objectives and scope of the testing- Testing strategy and approach- Roles and responsibilities of the testing team- Test schedule and resource requirements- Test environment and test data requirements- Risk and issue management plan- Test reporting and documentation requirementsThe test plan should be reviewed and approved by the project stakeholders before testing activities commence.5.2 Test DesignThe test design phase involves identifying the test scenarios and test cases based on the requirements. The test analyst/test engineer is responsible for developing the test cases, which should be based on the following:- Functional requirements- Non-functional requirements- Use cases and user stories- Business processesThe test cases should be reviewed and approved by the test manager before testing activities commence.5.3 Test ExecutionThe test execution phase involves executing the test cases and recording the results. The test analyst/test engineer is responsible for executing the test cases, which should include the following:- Defining the test execution strategy and approach- Executing the test cases based on the test schedule- Recording the test results and any defects found during testing- Analyzing the test results and providing feedback to the project stakeholders5.4 Test ReportingThe test reporting phase involves reporting on the status and results of the testing activities. The test manager is responsible for preparing the test reports, which should include the following:- Status of the testing activities- Test coverage and test results- Defect tracking and resolution- Recommendations for improvementThe test reports should be reviewed and approved by the project stakeholders.6. Testing Tools and EnvironmentThe software testing management system will define the testing tools and environment that will be used for all testing activities. This may include the following:- Test management tools- Test automation tools- Defect tracking tools- Test environments (e.g., hardware, software, network)The test coordinator is responsible for establishing and maintaining the test tools and environment.7. Training and DevelopmentThe software testing management system will provide training and development opportunities for the testing team to improve their skills and knowledge in software testing. This may include the following:- Training on testing methodologies and best practices- Training on testing tools and technology- Certification programs for testing professionalsThe test manager is responsible for identifying the training needs of the testing team and providing appropriate training and development opportunities.8. Quality AssuranceThe software testing management system will define the quality assurance activities that will be carried out to ensure the quality of the testing process. This may include the following:- Review and audit of the testing activities- Process improvement initiatives- Compliance with industry standards and best practicesThe test manager is responsible for establishing and maintaining the quality assurance activities within the testing process.9. Continuous ImprovementThe software testing management system will provide a framework for continuous improvement of the testing process. This may include the following:- Periodic review and analysis of the testing process- Identification of improvement opportunities- Implementation of improvement initiativesThe test manager is responsible for ensuring that continuous improvement activities are carried out within the testing process.10. ConclusionThe software testing management system outlined in this document provides a systematic and organized framework for conducting all software testing activities within the organization. By following the processes, procedures, roles, and responsibilities described in this document, the testing team can ensure that software testing is carried out in an efficient and effective manner, leading to the successful completion of software projects.。
软件测试的文章翻译
A Needle in a Haystack ?Who is hiding all the good testers out there? Most agencies send me terrible ‚factory testers‛ that haveCV's splashed with lists and logos! Is there really a shortage of good testers? Have all the jobs gone offshore and testers are now trying themselves out as plumbers and circus entertainers?Over recent years I have developed a series of techniques and procedures that have helped me find the good testers. This article will share my knowledge and recent experience with hiring a full test team. This is not a best practice, but a bunch of great ideas that have worked for me in my situation.I need good testers: my requirements In a recent role as Test Manager, I had to hire a team of testers. The testers had to be good for the product quality to improve, and for me to succeed. They needed these qualities:∙ to put up with a lot of pressure from an environment that was traditionally not tester-friendly∙ to learn fast, and learn a lot of domain critical information∙ to adopt to an agile-like culture, at least it looked like one∙ to work in a deliverables-focussed, time managed environment∙ to adopt a context-driven philosophy and put that into action∙ to speak out when there were issues, but not too loudlyider cont∙ to be able to analyse a function with regard to the wext of people, project and company 大海捞针谁在那隐藏了所有好的测试？很多的机构给我可怕的有CV列表和标志的“测试工厂”！是否真的缺少好的测试人员？海上作业和测试人员现在正试图走出自己的管道工和马戏艺？最近几年我发现了一系列的技术和帮助我发现很多好的测试的程序。
软件工程中英文对照外文翻译文献
中英文对照外文翻译(文档含英文原文和中文翻译)Application FundamentalsAndroid applications are written in the Java programming language. The compiled Java code — along with any data and resource files required by the application — is bundled by the aapt tool into an Android package, an archive file marked by an .apk suffix. This file is the vehicle for distributing the application and installing it on mobile devices; it's the file users download to their devices. All the code in a single .apk file is considered to be one application.In many ways, each Android application lives in its own world:1. By default, every application runs in its own Linux process. Android starts the process when any of the application's code needs to be executed, and shuts down the process when it's no longer needed and system resources are required by other applications.2. Each process has its own virtual machine (VM), so application code runs in isolation from the code of all other applications.3. By default, each application is assigned a unique Linux user ID. Permissions are set so that the application's files are visible only to that user and only to the application itself — although there are ways to export them to other applications as well.It's possible to arrange for two applications to share the same user ID, in which case they will be able to see each other's files. To conserve system resources, applications with the same ID can also arrange to run in the same Linux process, sharing the sameVM.Application ComponentsA central feature of Android is that one application can make use of elements of other applications (provided those applications permit it). For example, if your application needs to display a scrolling list of images and another application has developed a suitable scroller and made it available to others, you can call upon that scroller to do the work, rather than develop your own. Your application doesn't incorporate the code of the other application or link to it. Rather, it simply starts up that piece of the other application when the need arises.For this to work, the system must be able to start an application process when any part of it is needed, and instantiate the Java objects for that part. Therefore, unlike applications on most other systems, Android applications don't have a single entry point for everything in the application (no main() function, for example). Rather, they have essential components that the system can instantiate and run as needed. There are four types of components:ActivitiesAn activity presents a visual user interface for one focused endeavor the user can undertake. For example, an activity might present a list of menu items users can choose from or it might display photographs along with their captions. A text messaging application might have one activity that shows a list of contacts to send messages to, a second activity to write the message to the chosen contact, and other activities to review old messages or change settings. Though they work together to form a cohesive user interface, each activity is independent of the others. Each one is implemented as a subclass of the Activity base class.An application might consist of just one activity or, like the text messaging application just mentioned, it may contain several. What the activities are, and how many there are depends, of course, on the application and its design. Typically, one of the activities is marked as the first one that should be presented to the user when the application is launched. Moving from one activity to another is accomplished by having the current activity start the next one.Each activity is given a default window to draw in. Typically, the window fills the screen, but it might be smaller than the screen and float on top of other windows. An activity can also make use of additional windows — for example, a pop-up dialog that calls for a user response in the midst of the activity, or a window that presents users with vital information when they select a particular item on-screen.The visual content of the window is provided by a hierarchy of views — objects derived from the base View class. Each view controls a particular rectangular space within the window. Parent views contain and organize the layout of their children. Leaf views (those at the bottom of the hierarchy) draw in the rectangles they control and respond to user actions directed at that space. Thus, views are where the activity's interaction with the user takes place.For example, a view might display a small image and initiate an action when the user taps that image. Android has a number of ready-made views that you can use —including buttons, text fields, scroll bars, menu items, check boxes, and more.A view hierarchy is placed within an activity's window by theActivity.setContentView() method. The content view is the View object at the root of the hierarchy. (See the separate User Interface document for more information on views and the hierarchy.)ServicesA service doesn't have a visual user interface, but rather runs in the background for an indefinite period of time. For example, a service might play background music as the user attends to other matters, or it might fetch data over the network or calculate something and provide the result to activities that need it. Each service extends the Service base class.A prime example is a media player playing songs from a play list. The player application would probably have one or more activities that allow the user to choose songs and start playing them. However, the music playback itself would not be handled by an activity because users will expect the music to keep playing even after they leave the player and begin something different. To keep the music going, the media player activity could start a service to run in the background. The system would then keep the music playback service running even after the activity that started it leaves the screen.It's possible to connect to (bind to) an ongoing service (and start the service if it's not already running). While connected, you can communicate with the service through an interface that the service exposes. For the music service, this interface might allow users to pause, rewind, stop, and restart the playback.Like activities and the other components, services run in the main thread of the application process. So that they won't block other components or the user interface, they often spawn another thread for time-consuming tasks (like music playback). See Processes and Threads, later.Broadcast receiversA broadcast receiver is a component that does nothing but receive and react to broadcast announcements. Many broadcasts originate in system code — for example, announcements that the timezone has changed, that the battery is low, that a picture has been taken, or that the user changed a language preference. Applications can also initiate broadcasts — for example, to let other applications know that some data has been downloaded to the device and is available for them to use.An application can have any number of broadcast receivers to respond to any announcements it considers important. All receivers extend the BroadcastReceiver base class.Broadcast receivers do not display a user interface. However, they may start an activity in response to the information they receive, or they may use the NotificationManager to alert the user. Notifications can get the user's attention in various ways — flashing the backlight, vibrating the device, playing a sound, and so on. They typically place a persistent icon in the status bar, which users can open to get the message.Content providersA content provider makes a specific set of the application's data available to other applications. The data can be stored in the file system, in an SQLite database, or in anyother manner that makes sense. The content provider extends the ContentProvider base class to implement a standard set of methods that enable other applications to retrieve and store data of the type it controls. However, applications do not call these methods directly. Rather they use a ContentResolver object and call its methods instead. A ContentResolver can talk to any content provider; it cooperates with the provider to manage any interprocess communication that's involved.See the separate Content Providers document for more information on using content providers.Whenever there's a request that should be handled by a particular component, Android makes sure that the application process of the component is running, starting it if necessary, and that an appropriate instance of the component is available, creating the instance if necessary.Activating components: intentsContent providers are activated when they're targeted by a request from a ContentResolver. The other three components — activities, services, and broadcast receivers — are activated by asynchronous messages called intents. An intent is an Intent object that holds the content of the message. For activities and services, it names the action being requested and specifies the URI of the data to act on, among other things. For example, it might convey a request for an activity to present an image to the user or let the user edit some text. For broadcast receivers, theIntent object names the action being announced. For example, it might announce to interested parties that the camera button has been pressed.There are separate methods for activating each type of component:1. An activity is launched (or given something new to do) by passing an Intent object toContext.startActivity() or Activity.startActivityForResult(). The responding activity can look at the initial intent that caused it to be launched by calling its getIntent() method. Android calls the activity's onNewIntent() method to pass it any subsequent intents. One activity often starts the next one. If it expects a result back from the activity it's starting, it calls startActivityForResult() instead of startActivity(). For example, if it starts an activity that lets the user pick a photo, it might expect to be returned the chosen photo. The result is returned in an Intent object that's passed to the calling activity's onActivityResult() method.2. A service is started (or new instructions are given to an ongoing service) by passing an Intent object to Context.startService(). Android calls the service's onStart() method and passes it the Intent object. Similarly, an intent can be passed to Context.bindService() to establish an ongoing connection between the calling component and a target service. The service receives the Intent object in an onBind() call. (If the service is not already running, bindService() can optionally start it.) For example, an activity might establish a connection with the music playback service mentioned earlier so that it can provide the user with the means (a user interface) for controlling the playback. The activity would call bindService() to set up that connection, and then call methods defined by the service to affect the playback.A later section, Remote procedure calls, has more details about binding to a service.3. An application can initiate a broadcast by passing an Intent object to methods like Context.sendBroadcast(), Context.sendOrderedBroadcast(), andContext.sendStickyBroadcast() in any of their variations.Android delivers the intent to all interested broadcast receivers by calling their onReceive() methods. For more on intent messages, see the separate article, Intents and Intent Filters.Shutting down componentsA content provider is active only while it's responding to a request from a ContentResolver. And a broadcast receiver is active only while it's responding to a broadcast message. So there's no need to explicitly shut down these components. Activities, on the other hand, provide the user interface. They're in a long-running conversation with the user and may remain active, even when idle, as long as the conversation continues. Similarly, services may also remain running for a long time. So Android has methods to shut down activities and services in an orderly way:1. An activity can be shut down by calling its finish() method. One activity can shut down another activity (one it started with startActivityForResult()) by calling finishActivity().2. A service can be stopped by calling its stopSelf() method, or by calling Context.stopService().Components might also be shut down by the system when they are no longer being used or when Android must reclaim memory for more active components. A later section, Component Lifecycles, discusses this possibility and its ramifications in more detail.The manifest fileBefore Android can start an application component, it must learn that the component exists. Therefore, applications declare their components in a manifest file that's bundled into the Android package, the .apk file that also holds the application's code, files, and resources.The manifest is a structured XML file and is always named AndroidManifest.xml for all applications. It does a number of things in addition to declaring the application's components, such as naming any libraries the application needs to be linked against (besides the default Android library) and identifying any permissions the application expects to be granted.But the principal task of the manifest is to inform Android about the application's components. For example, an activity might be declared as follows:The name attribute of the <activity> element names the Activity subclass that implements the activity. The icon and label attributes point to resource files containing an icon and label that can be displayed to users to represent the activity.The other components are declared in a similar way — <service> elements for services, <receiver> elements for broadcast receivers, and <provider> elements for content providers. Activities, services, and content providers that are not declared in the manifest are not visible to the system and are consequently never run. However, broadcast receivers can either be declared in the manifest, or they can be created dynamically in code (as BroadcastReceiver objects) and registered with the system by calling Context.registerReceiver().For more on how to structure a manifest file for your application, see The Android Manifest.xml File.Intent filtersAn Intent object can explicitly name a target component. If it does, Android finds that component (based on the declarations in the manifest file) and activates it. But if a target is not explicitly named, Android must locate the best component to respond to the intent. It does so by comparing the Intent object to the intent filters of potential targets. A component's intent filters inform Android of the kinds of intents the component is able to handle. Like other essential information about the component, they're declared in the manifest file. Here's an extension of the previous example that adds two intent filters to the activity:The first filter in the example — the combination of the action"android.intent.action.MAIN" and the category"UNCHER" — is a common one. It marks the activity as one that should be represented in the application launcher, the screen listing applications users can launch on the device. In other words, the activity is the entry point for the application, the initial one users would see when they choose the application in the launcher.The second filter declares an action that the activity can perform on a particular type of data.A component can have any number of intent filters, each one declaring a different set of capabilities. If it doesn't have any filters, it can be activated only by intents that explicitly name the component as the target.For a broadcast receiver that's created and registered in code, the intent filter is instantiated directly as an IntentFilter object. All other filters are set up in the manifest. For more on intent filters, see a separate document, Intents and Intent Filters.应用程序基础Android DevelopersAndroid应用程序使用Java编程语言开发。
软件测试技术英文作文
软件测试技术英文作文英文：Software testing is a crucial process in software development. It involves various techniques and methods to ensure that the software is functioning as expected and meets the requirements of the end-users. In this article, I will discuss some of the commonly used software testing techniques.Firstly, there is the black-box testing technique. This technique involves testing the software without any knowledge of its internal structure or code. The tester focuses on the inputs and outputs of the software and checks if they are in accordance with the expected results. This technique is useful in detecting errors related to the user interface, functionality, and performance of the software.Secondly, there is the white-box testing technique.This technique involves testing the software with knowledge of its internal structure and code. The tester focuses onthe logic and flow of the software and checks if it is functioning as expected. This technique is useful in detecting errors related to the code, such as syntax errors, logical errors, and runtime errors.Thirdly, there is the grey-box testing technique. This technique is a combination of black-box and white-boxtesting techniques. The tester has limited knowledge of the internal structure and code of the software. This technique is useful in detecting errors related to the integration of different components of the software.In addition to these techniques, there are severalother testing techniques, such as regression testing, performance testing, and security testing. Regressiontesting involves testing the software after making changesto ensure that the existing functionality is not affected. Performance testing involves testing the software for its speed and responsiveness. Security testing involves testing the software for vulnerabilities and weaknesses that can beexploited by hackers.In conclusion, software testing is a critical processin software development. It ensures that the software is functioning as expected and meets the requirements of the end-users. There are various testing techniques and methods available, and it is essential to choose the righttechnique based on the requirements of the project.中文：软件测试是软件开发中至关重要的过程。
软件测试部分中英文对照
Test design : 测试设计
Test driver : 测试驱动
Testing environment : 测试环境
Artifact : 工件
Automated Testing : 自动化测试
Architecture : 构架
Assertion checking : 断言检查 (10)
Audit : 审计
Application under test (AUT) : 所测试的应用程序
Hotfix : 热补丁
G11N(Globalization) : 全球化
Gap analysis : 差距分析
Garbage characters : 乱码字符
Glossary : 术语表
Glass-box testing : 白箱测试或白盒测试
GUI(Graphical User Interface) : 图形用户界面
Decision coverage : 判定覆盖
Debug : 调试
Defect : 缺陷
defect density : 缺陷密度 (60)
Deployment : 部署
Desk checking : 桌前检查
Blocking bug : 阻碍性错误
Bottom-up testing : 自底向上测试 (20)
Branch coverage : 分支覆盖
Brute force testing : 强力测试
Bug : 错误
Bug report : 错误报告
Load testing : 负载测试
Maintenance : 维护
软件测试中英文对照
Acceptance testing | 验收测试Acceptance Testing|可接受性测试Accessibility test | 软体适用性测试actual outcome|实际结果Ad hoc testing | 随机测试Algorithm analysis | 算法分析algorithm|算法Alpha testing | α测试analysis|分析anomaly|异常application software|应用软件Application under test (AUT) | 所测试的应用程序Architecture | 构架Artifact | 工件ASQ|自动化软件质量（Automated Software Quality）Assertion checking | 断言检查Association | 关联Audit | 审计audit trail|审计跟踪Automated Testing|自动化测试Backus-Naur Form|BNF范式baseline|基线Basic Block|基本块basis test set|基本测试集Behaviour | 行为Bench test | 基准测试benchmark|标杆/指标/基准Best practise | 最佳实践Beta testing | β测试Black Box Testing|黑盒测试Blocking bug | 阻碍性错误Bottom-up testing | 自底向上测试boundary value coverage|边界值覆盖boundary value testing|边界值测试Boundary values | 边界值Boundry Value Analysis|边界值分析branch condition combination coverage|分支条件组合覆盖branch condition combination testing|分支条件组合测试branch condition coverage|分支条件覆盖branch condition testing|分支条件测试branch condition|分支条件Branch coverage | 分支覆盖branch outcome|分支结果branch point|分支点branch testing|分支测试branch|分支Breadth Testing|广度测试Brute force testing| 强力测试Buddy test | 合伙测试Buffer | 缓冲Bug | 错误Bug bash | 错误大扫除bug fix | 错误修正Bug report | 错误报告Bug tracking system| 错误跟踪系统bug|缺陷Build | 工作版本（内部小版本）Build Verfication tests(BVTs)| 版本验证测试Build-in | 内置Capability Maturity Model (CMM)| 能力成熟度模型Capability Maturity Model Integration (CMMI)| 能力成熟度模型整合capture/playback tool|捕获/回放工具Capture/Replay Tool|捕获/回放工具CASE|计算机辅助软件工程（computer aided software engineering）CAST|计算机辅助测试cause-effect graph|因果图certification |证明change control|变更控制Change Management |变更管理Change Request |变更请求Character Set | 字符集Check In |检入Check Out |检出Closeout | 收尾code audit |代码审计Code coverage | 代码覆盖Code Inspection|代码检视Code page | 代码页Code rule | 编码规范Code sytle | 编码风格Code Walkthrough|代码走读code-based testing|基于代码的测试coding standards|编程规范Common sense | 常识Compatibility Testing|兼容性测试complete path testing |完全路径测试completeness|完整性complexity |复杂性Component testing | 组件测试Component|组件computation data use|计算数据使用computer system security|计算机系统安全性Concurrency user | 并发用户Condition coverage | 条件覆盖condition coverage|条件覆盖condition outcome|条件结果condition|条件configuration control|配置控制Configuration item | 配置项configuration management|配置管理Configuration testing | 配置测试conformance criterion| 一致性标准Conformance Testing| 一致性测试consistency | 一致性consistency checker| 一致性检查器Control flow graph | 控制流程图control flow graph|控制流图control flow|控制流conversion testing|转换测试Core team | 核心小组corrective maintenance|故障检修correctness |正确性coverage |覆盖率coverage item|覆盖项crash|崩溃criticality analysis|关键性分析criticality|关键性CRM(change request management)| 变更需求管理Customer-focused mindset | 客户为中心的理念体系Cyclomatic complexity | 圈复杂度data corruption|数据污染data definition C-use pair|数据定义C-use使用对data definition P-use coverage|数据定义P-use覆盖data definition P-use pair|数据定义P-use使用对data definition|数据定义data definition-use coverage|数据定义使用覆盖data definition-use pair |数据定义使用对data definition-use testing|数据定义使用测试data dictionary|数据字典Data Flow Analysis | 数据流分析data flow analysis|数据流分析data flow coverage|数据流覆盖data flow diagram|数据流图data flow testing|数据流测试data integrity|数据完整性data use|数据使用data validation|数据确认dead code|死代码Debug | 调试Debugging|调试Decision condition|判定条件Decision coverage | 判定覆盖decision coverage|判定覆盖decision outcome|判定结果decision table|判定表decision|判定Defect | 缺陷defect density | 缺陷密度Defect Tracking |缺陷跟踪Deployment | 部署Depth Testing|深度测试design for sustainability |可延续性的设计design of experiments|实验设计design-based testing|基于设计的测试Desk checking | 桌前检查desk checking|桌面检查Determine Usage Model | 确定应用模型Determine Potential Risks | 确定潜在风险diagnostic|诊断DIF(decimation in frequency) | 按频率抽取dirty testing|肮脏测试disaster recovery|灾难恢复DIT （decimation in time）| 按时间抽取documentation testing |文档测试domain testing|域测试DTP DETAIL TEST PLAN详细确认测试计划Dynamic analysis | 动态分析dynamic analysis|动态分析Dynamic Testing|动态测试embedded software|嵌入式软件emulator|仿真End-to-End testing|端到端测试Enhanced Request |增强请求entity relationship diagram|实体关系图Encryption Source Code Base| 加密算法源代码库Entry criteria | 准入条件entry point |入口点Envisioning Phase | 构想阶段Equivalence class | 等价类Equivalence Class|等价类equivalence partition coverage|等价划分覆盖Equivalence partition testing | 等价划分测试equivalence partition testing|参考等价划分测试equivalence partition testing|等价划分测试Equivalence Partitioning|等价划分Error | 错误Error guessing | 错误猜测error seeding|错误播种/错误插值Event-driven | 事件驱动Exception handlers | 异常处理器exception|异常/例外executable statement|可执行语句Exhaustive Testing|穷尽测试exit point|出口点expected outcome|期望结果Exploratory testing | 探索性测试Failure | 失效Fault | 故障fault|故障feasible path|可达路径feature testing|特性测试Field testing | 现场测试FMEA|失效模型效果分析（Failure Modes and Effects Analysis）FMECA|失效模型效果关键性分析(Failure Modes and Effects Criticality Analysis)Framework | 框架FTA|故障树分析(Fault Tree Analysis)functional decomposition|功能分解Functional Specification |功能规格说明书Functional testing | 功能测试Functional Testing|功能测试G11N(Globalization) | 全球化Gap analysis | 差距分析Garbage characters | 乱码字符glass box testing|玻璃盒测试Glass-box testing | 白箱测试或白盒测试Glossary | 术语表GUI(Graphical User Interface)| 图形用户界面Hard-coding | 硬编码Hotfix | 热补丁I18N(Internationalization)| 国际化Identify Exploratory Tests –识别探索性测试IEEE|美国电子与电器工程师学会（Institute of Electrical and Electronic Engineers）Incident 事故Incremental testing | 渐增测试incremental testing|渐增测试infeasible path|不可达路径input domain|输入域Inspection | 审查inspection|检视installability testing|可安装性测试Installing testing | 安装测试instrumentation|插装instrumenter|插装器Integration |集成Integration testing | 集成测试interface | 接口interface analysis|接口分析interface testing|接口测试interface|接口invalid inputs|无效输入isolation testing|孤立测试Issue | 问题Iteration | 迭代Iterative development| 迭代开发job control language|工作控制语言Job|工作Key concepts | 关键概念Key Process Area | 关键过程区域Keyword driven testing | 关键字驱动测试Kick-off meeting | 动会议L10N(Localization) | 本地化Lag time | 延迟时间LCSAJ|线性代码顺序和跳转（Linear Code Sequence And Jump）LCSAJ coverage|LCSAJ覆盖LCSAJ testing|LCSAJ测试Lead time | 前置时间Load testing | 负载测试Load Testing|负载测试Localizability testing| 本地化能力测试Localization testing | 本地化测试logic analysis|逻辑分析logic-coverage testing|逻辑覆盖测试Maintainability | 可维护性maintainability testing|可维护性测试Maintenance | 维护Master project schedule |总体项目方案Measurement | 度量Memory leak | 内存泄漏Migration testing | 迁移测试Milestone | 里程碑Mock up | 模型，原型modified condition/decision coverage|修改条件/判定覆盖modified condition/decision testing |修改条件/判定测试modular decomposition|参考模块分解Module testing | 模块测试Monkey testing | 跳跃式测试Monkey Testing|跳跃式测试mouse over|鼠标在对象之上mouse leave|鼠标离开对象MTBF|平均失效间隔实际（mean time between failures）MTP MAIN TEST PLAN主确认计划MTTF|平均失效时间（mean time to failure）MTTR|平均修复时间（mean time to repair）multiple condition coverage|多条件覆盖mutation analysis|变体分析N/A(Not applicable) | 不适用的Negative Testing | 逆向测试, 反向测试, 负面测试negative testing|参考负面测试Negative Testing|逆向测试/反向测试/负面测试off by one|缓冲溢出错误non-functional requirements testing|非功能需求测试nominal load|额定负载N-switch coverage|N切换覆盖N-switch testing|N切换测试N-transitions|N转换Off-the-shelf software | 套装软件operational testing|可操作性测试output domain|输出域paper audit|书面审计Pair Programming | 成对编程partition testing|分类测试Path coverage | 路径覆盖path coverage|路径覆盖path sensitizing|路径敏感性path testing|路径测试path|路径Peer review | 同行评审Performance | 性能Performance indicator| 性能（绩效）指标Performance testing | 性能测试Pilot | 试验Pilot testing | 引导测试Portability | 可移植性portability testing|可移植性测试Positive testing | 正向测试Postcondition | 后置条件Precondition | 前提条件precondition|预置条件predicate data use|谓词数据使用predicate|谓词Priority | 优先权program instrumenter|程序插装progressive testing|递进测试Prototype | 原型Pseudo code | 伪代码pseudo-localization testing|伪本地化测试pseudo-random|伪随机QC|质量控制（quality control）Quality assurance(QA)| 质量保证Quality Control(QC) | 质量控制Race Condition|竞争状态Rational Unified Process(以下简称RUP)|瑞理统一工艺Recovery testing | 恢复测试recovery testing|恢复性测试Refactoring | 重构regression analysis and testing|回归分析和测试Regression testing | 回归测试Release | 发布Release note | 版本说明release|发布Reliability | 可靠性reliability assessment|可靠性评价reliability|可靠性Requirements management tool| 需求管理工具Requirements-based testing | 基于需求的测试Return of Investment（ROI）| 投资回报率review|评审Risk assessment | 风险评估risk|风险Robustness | 强健性Root Cause Analysis(RCA)| 根本原因分析safety critical|严格的安全性safety|（生命）安全性Sanity testing | 健全测试Sanity Testing|理智测试Schema Repository | 模式库Screen shot | 抓屏、截图SDP|软件开发计划（software development plan）Security testing | 安全性测试security testing|安全性测试security.|（信息）安全性serviceability testing|可服务性测试Severity | 严重性Shipment | 发布simple subpath|简单子路径Simulation | 模拟Simulator | 模拟器SLA(Service level agreement)| 服务级别协议SLA|服务级别协议（service level agreement）Smoke testing | 冒烟测试Software development plan(SDP)| 软件开发计划Software development process| 软件开发过程software development process|软件开发过程software diversity|软件多样性software element|软件元素software engineering environment|软件工程环境software engineering|软件工程Software life cycle | 软件生命周期source code|源代码source statement|源语句Specification | 规格说明书specified input|指定的输入spiral model |螺旋模型SQAP SOFTWARE QUALITY ASSURENCE PLAN 软件质量保证计划SQL|结构化查询语句（structured query language）Staged Delivery|分布交付方法state diagram|状态图state transition testing |状态转换测试state transition|状态转换state|状态Statement coverage | 语句覆盖statement testing|语句测试statement|语句Static Analysis|静态分析Static Analyzer|静态分析器Static Testing|静态测试statistical testing|统计测试Stepwise refinement | 逐步优化storage testing|存储测试Stress Testing | 压力测试structural coverage|结构化覆盖structural test case design|结构化测试用例设计structural testing|结构化测试structured basis testing|结构化的基础测试structured design|结构化设计structured programming|结构化编程structured walkthrough|结构化走读stub|桩sub-area|子域Summary| 总结SVVP SOFTWARE Vevification&Validation PLAN| 软件验证和确认计划symbolic evaluation|符号评价symbolic execution|参考符号执行symbolic execution|符号执行symbolic trace|符号轨迹Synchronization | 同步Syntax testing | 语法分析system analysis|系统分析System design | 系统设计system integration|系统集成System Testing | 系统测试TC TEST CASE 测试用例TCS TEST CASE SPECIFICATION 测试用例规格说明TDS TEST DESIGN SPECIFICATION 测试设计规格说明书technical requirements testing|技术需求测试Test | 测试test automation|测试自动化Test case | 测试用例test case design technique|测试用例设计技术test case suite|测试用例套test comparator|测试比较器test completion criterion|测试完成标准test coverage|测试覆盖Test design | 测试设计Test driver | 测试驱动test environment|测试环境test execution technique|测试执行技术test execution|测试执行test generator|测试生成器test harness|测试用具Test infrastructure | 测试基础建设test log|测试日志test measurement technique|测试度量技术Test Metrics |测试度量test procedure|测试规程test records|测试记录test report|测试报告Test scenario | 测试场景Test Script|测试脚本Test Specification|测试规格Test strategy | 测试策略test suite|测试套Test target | 测试目标Test ware | 测试工具Testability | 可测试性testability|可测试性Testing bed | 测试平台Testing coverage | 测试覆盖Testing environment | 测试环境Testing item | 测试项Testing plan | 测试计划Testing procedure | 测试过程Thread testing | 线程测试time sharing|时间共享time-boxed | 固定时间TIR test incident report 测试事故报告ToolTip|控件提示或说明top-down testing|自顶向下测试TPS TEST PEOCESS SPECIFICATION 测试步骤规格说明Traceability | 可跟踪性traceability analysis|跟踪性分析traceability matrix|跟踪矩阵Trade-off | 平衡transaction|事务/处理transaction volume|交易量transform analysis|事务分析trojan horse|特洛伊木马truth table|真值表TST TEST SUMMARY REPORT 测试总结报告Tune System | 调试系统TW TEST WARE |测试件Unit Testing |单元测试Usability Testing|可用性测试Usage scenario | 使用场景User acceptance Test | 用户验收测试User database |用户数据库User interface(UI) | 用户界面User profile | 用户信息User scenario | 用户场景V&V (Verification & Validation) | 验证&确认validation |确认verification |验证version |版本Virtual user | 虚拟用户volume testing|容量测试VSS（visual source safe） |VTP Verification TEST PLAN验证测试计划VTR Verification TEST REPORT验证测试报告Walkthrough | 走读Waterfall model | 瀑布模型Web testing | 网站测试White box testing | 白盒测试Work breakdown structure (WBS) | 任务分解结构Zero bug bounce (ZBB) | 零错误反弹。
【计算机专业文献翻译】软件测试
附录2 英文文献及其翻译原文：Software testingThe chapter is about establishment of the system defects objectives according to test programs. You will understand the followings: testing techniques that are geared to discover program faults, guidelines for interface testing, specific approaches to object-oriented testing, and the principles of CASE tool support for testing. Topics covered include Defect testing, Integration testing, Object-oriented testing and Testing workbenches.The goal of defect testing is to discover defects in programs. A successful defect test is a test which causes a program to behave in an anomalous way. Tests show the presence not the absence of defects. Only exhaustive testing can show a program is free from defects. However, exhaustive testing is impossible.Tests should exercise a system's capabilities rather than its components. Testing old capabilities is more important than testing new capabilities. Testing typical situations is more important than boundary value cases.An approach to te sting where the program is considered as a ‘black-box’. The program test cases are based on the system specification. Test planning can begin early in the software process. Inputs causing anomalous behaviour. Outputs which reveal the presence of defects.Equivalence partitioning. Input data and output results often fall into different classes where all members of a class are related. Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member. Test cases should be chosen from each partition.Structural testing. Sometime it is called white-box testing. Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases. Objective is to exercise all program statements, not all path combinations.Path testing. The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once. The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control.Statements with conditions are therefore nodes in the flow graph. Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node. Used as a basis for computing the cyclomatic complexity.Cyclomatic complexity = Number of edges -Number of nodes +2The number of tests to test all control statements equals the cyclomatic complexity.Cyclomatic complexity equals number ofconditions in a program. Useful if used with care. Does not imply adequacy of testing. Although all paths are executed, all combinations of paths are not executed.Cyclomatic complexity: Test cases should be derived so that all of these paths are executed.A dynamic program analyser may be used to check that paths have been executed.Integration testing.Tests complete systems or subsystems composed of integrated components. Integration testing should be black-box testing with tests derived from the specification.Main difficulty is localising errors. Incremental integration testing reduces this problem. Tetsing approaches. Architectural validation. Top-down integration testing is better at discovering errors in the system architecture.System demonstration.Top-down integration testing allows a limited demonstration at an early stage in the development. Test observation: Problems with both approaches. Extra code may be required to observe tests. Takes place when modules or sub-systems are integrated to create larger systems. Objectives are to detect faults due to interface errors or invalid assumptions about interfaces. Particularly important for object-oriented development as objects are defined by their interfaces.A calling component calls another component and makes an error in its use of its interface e.g. parameters in the wrong order.Interface misunderstanding. A calling component embeds assumptions about the behaviour of the called component which are incorrectTiming errors: The called and the calling component operate at different speeds and out-of-date information is accessed.Interface testing guidelines: Design tests so that parameters to a called procedure are at the extreme ends of their ranges. Always test pointer parameters with null pointers. Design tests which cause the component to fail. Use stress testing in message passing systems. In shared memory systems, vary the order in which components are activated.Stress testingExercises the system beyond its maximum design load. Stressing the system often causes defects to come to light. Stressing the system test failure behaviour. Systems should not fail catastrophically. Stress testing checks for unacceptable loss of service or data. Particularly relevant to distributed systems which can exhibit severe degradation as a network becomes overloaded.The components to be tested are object classes that are instantiated as objects. Larger grain than individual functions so approaches to white-box testing have to be extended. No obvious ‘top’ to the system for top-down integration and testing. Object-oriented testing. Testing levels.Testing operations associated with objects.Testing object classes. Testing clusters of cooperating objects. Testing the complete OO systemObject class testing. Complete test coverage of a class involves. Testing all operations associated with an object. Setting and interrogating all object attributes. Exercising the object in all possible states.Inheritance makes it more difficult to design object class tests as the information to be tested is not localized. Weather station object interface. Test cases are needed for all e a state model toidentify state transiti.ons for testing.Object integration. Levels of integration are less distinct in objectoriented systems. Cluster testing is concerned with integrating and testing clusters of cooperating objects. Identify clusters using knowledge of the operation of objects and the system features that are implemented by these clusters. Testing is based on a user interactions with the system. Has the advantage that it tests system features as experienced byusers.Thread testing.Tests the systems response to events as processing threads through the system. Object interaction testing. Tests sequences of object interactions that stop when an object operation does not call on services from another objectScenario-based testing. Identify scenarios from use-cases and supplement these with interaction diagrams that show the objects involved in the scenario. Consider the scenario in the weather station system where a report is generated.Input of report request with associated acknowledge and a final output of a report. Can be tested by creating raw data and ensuring that it is summarised properly. Use the same raw data to test the WeatherData object.Testing workbenches.Testing is an expensive process phase. Testing workbenches provide a range of tools to reduce the time required and total testing costs. Most testing workbenches are open systems because testing needs are organisation-specific. Difficult to integrate with closed design and analysis workbenchesTetsing workbench adaptation. Scripts may be developed for user interface simulators and patterns for test data generators. Test outputs may have to be prepared manually for comparison. Special-purpose file comparators may be developed.Key points:Test parts of a system which are commonly used rather than those which are rarely executed. Equivalence partitions are sets of test cases where the program should behave in an equivalent way. Black-box testing is based on the system specification. Structural testing identifies test cases which cause all paths through the program to be executed.Test coverage measures ensure that all statements have been executed at least once. Interface defects arise because of specification misreading, misunderstanding, errors or invalid timing assumptions. To test object classes, test all operations, attributes and states.Integrate object-oriented systems around clusters of objects.译文：软件测试本章的目标是介绍通过测试程序发现程序中的缺陷的相关技术。
关于软件测试的外国文献
关于软件测试的外国文献软件测试是软件开发过程中至关重要的一环，而外国文献中关于软件测试的研究和实践也非常丰富。
下面我将从不同角度介绍一些相关的外国文献，以便更全面地了解软件测试的最新发展。
1. "Software Testing Techniques" by Boris Beizer:这本经典著作详细介绍了软件测试的各种技术和方法，包括黑盒测试、白盒测试、基于模型的测试等。
它提供了许多实用的指导和案例，对软件测试的理论和实践都有很深入的探讨。
2. "Testing Computer Software" by Cem Kaner, Jack Falk, and Hung Q. Nguyen:这本书介绍了软件测试的基础知识和常用技术，包括测试计划的编写、测试用例设计、缺陷管理等。
它强调了测试的全过程管理和质量保证，对于软件测试初学者来说是一本很好的入门指南。
3. "The Art of Software Testing" by Glenford J. Myers, Corey Sandler, and Tom Badgett:这本书从理论和实践的角度探讨了软件测试的艺术。
它介绍了测试的基本原则和策略，以及如何设计有效的测试用例和评估测试覆盖率。
这本书对于提高测试人员的思维和技巧非常有帮助。
4. "Foundations of Software Testing" by Aditya P. Mathur:这本书系统地介绍了软件测试的基本概念、技术和方法。
它涵盖了测试过程的各个阶段，包括需求分析、测试设计、执行和评估。
这本书还提供了丰富的案例和练习，帮助读者深入理解和应用软件测试的原理和技术。
5. "Software Testing: Principles and Practices" by Srinivasan Desikan and Gopalaswamy Ramesh:这本书介绍了软件测试的原则、实践和工具。
软件测试技术英文作文
软件测试技术英文作文Software testing is an essential part of the software development process. It helps to identify and fix bugs and errors in the software, ensuring that it functions as intended.There are various techniques and methods used in software testing, such as unit testing, integration testing, system testing, and acceptance testing. Each of these techniques has its own unique approach and purpose in ensuring the quality of the software.One common technique in software testing is black box testing, where the tester examines the functionality of the software without knowing its internal code. This allows for a more user-focused approach to testing, as it simulates how an end user would interact with the software.On the other hand, white box testing involves examining the internal code and structure of the software to identifyany errors or vulnerabilities. This technique is more focused on the technical aspects of the software and is often used to ensure its security and stability.In addition to these techniques, there are also various tools and frameworks available for software testing, such as Selenium, JUnit, and TestNG. These tools help to automate the testing process and make it more efficient and reliable.Overall, software testing is a crucial step in the software development lifecycle, and it requires a combination of techniques, methods, and tools to ensure the quality and reliability of the software.。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
中英文资料外文翻译文献基于价值的软件测试管理鲁道夫,斯蒂芬,保罗沈青松译摘要:根据研究表明测试已经成为软件开发过程中一个很重要的环节，它占据了整个软件开发成本的百分之三十到五十。
测试通常不是用来组织商业价值的最大化，也不是肩负着项目的使命。
路径测试、分支测试、指导测试、变换测试、场景测试以及需求测试等对于软件的所有方面都是同等重要的。
然而在实践中百分之八十的价值往往来自百分之二十的软件。
为了从软件测试中得到最大的投资回报，测试管理需要最大化它的价值贡献。
在本章，我们将更加促进对基于价值的测试的需要，描述支持基于价值的测试管理的实践，勾画出基于价值的测试管理的框架，并举例说明该框架。
关键词: 基于价值的软件测试,基于价值的测试,测试成本,测试利益,测试管理11.1 前言测试是软件质量保证过程中最重要和最广泛使用的方法。
校验和验证旨在通过综合分析, 测试软件确保其正确运行功能，确保软件的质量和软件的可靠性。
在IEEE610.12(1990)中,测试被定义为在规定条件下对执行的系统或者组件进行观察和记录,并对系统或者组件进行评价的活动。
测试在实践过程中被广泛的使用，在保证质量策略的诸多组织中扮演着重要的角色。
软件影响着成千上万人的日常生活，担负着艰巨的任务。
因此软件在不久的将来将显得尤其的重要。
研究表明，测试通常消耗软件开发成本的30%至50%。
对于安全危急系统，甚至更高的比例也不足为奇。
因此软件测试具有挑战的就是寻找更多的有效途径进行有效的测试。
软件测试管理的价值在于努力减少测试成本和满足需求。
有价值的测试管理对于项目目标和商业价值也能有很好的向导。
在第一章，Boehm 列举了很多方面的潜在测试成本。
该例子说明了利用客户结账类型的7%的成本来完成50%的软件测试利益。
尽管百分百测试是一个不太切实际的目标, 然而通过调整测试方法, 仍有很大的空间来改进和节省达到预期的价值。
基于软件工程的价值动力在于目前软件工程的实践研究都是把需求, 测试案例, 测试对象和产品缺陷看的同等重要。
这对测试显然是正确的，它对产品价值间接的做出贡献。
开发和测试的分离使得这问题显得更为突出。
测试往往是一个纯粹的技术问题，将使得测试和商业决策之间曾解链的关系变的更加紧密。
本章主要描述了提高基于价值的测试管理的需求, 解释其基本要素, 讨论现有的实例来支持基于价值的测试, 以及基于价值的测试管理的基本框架。
本章接下来部分的基本结构如下：11.2节讨论测试管理的贡献价值； 11.3节讨论已测案例对于测试管理的支持； 11.4节用例子描述基于价值的测试管理的框架。
本章最后将对具体的再作更进一步的研究。
11.2基于价值测试的描述基于价值的校验和验证的目标被定义为确保软件的实施能够满足其预期的目标价值利益。
如果我们从价值的角度去考虑，那么测试的贡献应该在哪呢？从根本上来说, 可以从两个方面来考虑: 内部方面包括测试成本以及测试效益, 外部方面强调未来系统的威胁以及机遇。
对于基于价值的测试，其关键就是要把这两个方面结合起来,也就是说通过客户和市场需求调整内部测试的过程。
为了使内部和外部两方面因素相结合，只专注于技术方面的测试显然是不恰当的。
相反，测试管理需要有个全局的把握。
例41描述了测试管理内外双方面之间的依赖关系。
内部方面的就如同测试经理对整个项目的控制。
这方面的费用主要来自于软件测试实践以及短期长期的测试。
而外部方面被认为是测试主管所能控制以外的一些利益和参数数据.基于价值的软件测试管理使得测试能够满足以利益为重的价值主张，以及使整个小组聚焦在有价值的测试方向上。
对于软件测试的外部观点的首要问题是“我们如何确保软件系统的价值目标？”这目标就是通过协调价值主张来测试软件集中的有价值部分，最重要的品质以及项目风险的及时调整等.回答这样的问题包括市场机遇，项目的价值主张以及成本效益。
参考第一章关于机遇和风险的详细介绍以及参考第七章的价值主张的引出与调和。
内部观点是建立在价值主张的利益之上，以及测试的预算代表着整个项目的一个大概水平。
这主要的问题就是如何把测试作为一项投资活动。
为了能够高效迅速的测试及降低开发预算。
适当的内外部交流协调能够满足测试的利益价值。
测试的价值贡献测试与其他的开发环节诸如代码和用户界面设计相比，它不能立即对产品创造价值。
然而测试提供和支持软件开发过程中产生的有价值的任务活动。
理解测试贡献价值的关键点在于测试的贡献效应。
测试的贡献建立了测试与最终产品价值利益之间的关系。
最直接的客户是直接与测试小组有密切联系的程序开发者和项目主管。
在基于价值的软件工程测试过程中的集中力量是顾客和用户（见第七章）。
顾客和用户通过设定语境和范围来进行测试达到测试的价值目标。
测试的客户开发人员,项目主管,质量主管,顾客,分析者,最终用户或者维修人员们都得益于软件系统的分析,依靠反馈来检测问题,降低其不确定性,做出相关的决定来加快产品进程。
下面的例子显示了不同组对于测试需求的反馈信息：•顾客和用户关于多大程度上需求一致是否满意以及在多大程度上满足软件的价值利益.测试还对项目的进程提供可见性和洞察力.通过测试的结果可以了解已通过的测试案例.当验收测试时出现不实用的或者失败的显示在实际环境中才能出现的问题，α和β测试提供了一个更加坚实的基础来验证结果。
•销售和产品主管从测试计划、定价、促销和分配方面获取相关的信息。
产品实际的质量与顾客和用户所期望的质量之间的差异很容易会导致误解和错误的设想以至于降低或者阻止了真正价值的实现。
为了能够成功地达到这些期望以及满足个人或组织的目标，通过客户需求来调整产品设计满足某些功能。
•对于项目主管，测试支持了风险管理和项目进程的估计。
重点是识别和排除潜在的价值破坏和抑制价值功绩的风险。
早期的大幅降低项目绩效的严重缺陷,是一个主要的目的。
测试降低了不确定性和帮助项目主管对于清除缺陷、系统稳定性以及产品更新发布能够作出更好、更明智的决定。
•质量主管对于问题的识别以及对特定问题的动态趋势较为感兴趣。
测试结果对于项目评估、对于质量策略的保证以及进程的改进提供了帮助。
Rosenberg讨论了测试如何对确保质量作出贡献并展示了测试问题如何验证如何修正以此来提升项目进程。
开发者和用户了解相关问题的当前状态，并且提供相关数据来衡量及预测软件的质量和可靠性。
•开发人员通常需要获取反馈信息来验证测试实施是否完整，是否符合标准，是否满足质量要求。
为了保证稳定性，测试提供了相关缺陷的详细信息，提示测试失败的原因。
除此之外，测试对于项目缺陷的改进作出反馈。
例如，通过相关的修改以后需要测试其是否随着相关的改动使原先的功能有所改动或者出现衰退的情况，这些都是需要注意的。
•对于需求工程师来说，测试对于验证和确认需求是很有价值的。
Weinberg曾指出“最有效的方法之一就是通过测试案例就象测试一个完整的系统来形成测试需求”。
黑盒测试通过其需求帮助能够保证它们的完整性，准确性，透明性及简明性等。
因此测试能够提升要求且向着测试驱动的方向发展。
简言之，测试能够通过降低计划的不确定性和风险性来提升利益，作出相关的决定，努力控制把不必要的消耗减少到最低程度(内部原因)。
尤为重要的是，它有助于实现预期的价值利益。
这些利益的得来也并不是免费的，测试的代价通常也是有意义的(外部原因).测试可以被理解为购买信息，也可被认为降低成本风险，减少不确定性的投资活动。
在成本和利益的投资上需要对测试需求作出相关的决定。
因此接下来的两个问题是：什么是测试成本？什么是价值活动的测试利益？Value-Based Management of Software TestingRudolf Ramler, Stefan Biffl and Paul GrünbacherAbstract:Testing is one of the most resource-intensive activities in software development and consumes between 30 and 50% of total development costs according to many studies. Testing is however often not organized to maximize business value and not aligned with a project’s miss ion. Path, branch, instruction, mutation, scenario, or requirement testing usually treat all aspects of software as equally important, while in practice 80% of the value often comes from 20% of the software. In order to maximize the return of investment gained from software testing, the management of testing needs to maximize its value contribution. In this chapter we motivate the need for value-based testing, describe practices supporting the management of value-based testing, outline a framework for value-based test management, and illustrate the framework with an example.Keywords: Value-based software engineering, value-based testing, cost of testing, benefits of testing, test management.11.1 IntroductionTesting is one of the most important and most widely used approaches for validation and verification (V&V). V&V aims at comprehensively analyzing and testing software to determine that it performs the intended functions correctly, to ensure that it performs no unintended functions, and to measure its quality and reliability (Wallace and Fujii, 1989). According to IEEE 610.12 (1990) testing is defined as “an activity in which a system or component is executed under specified conditions, the results are observed or recorded,and an evaluation is made of some aspect of the system or component.”Testing is widely used in practice and plays a central role in the quality assurance strategies of many organizations. As software pervades more and more critical tasks and affects everyday life, security, and well being of millions of people (Ferscha and Mattern, 2004), the importance of testing will increase in the future. Studies show that testing already consumes between 30 and 50% of software development costs (Beizer, 1990). Even higher percentages are not uncommon for safety-critical systems. Finding more efficient ways to perform effective testing is therefore a key challenge in testing (Harrold, 2000).Managing software testing based on value considerations promises to tackle increasing testing costs and required effort. Value-based test management could also provide guidance to better align testing investments with project objectives and business value. In Chapter 1, Boehm presents an impressive example of potential test cost savings (on project level as well as on global scale) by focusing testing on the most valuable aspects. The example illustrates that with an investment-oriented focus on testing 7% of the customer billing types (1 in 15) achieved 50% of the benefits of testing the software. Completely testing the system requires a constantly increasing effort and, due to decreasing marginal benefits, results in a negative return on investment. Although a “100% tested” status is not a practica l goal, there is still room for a considerable amount of improvement and savings by better adjusting testing to its value contribution.The motivation for value-based software engineering comes from the fact that “much of current software engineering practice and research is done in a value neutral setting, in which every requirement, use case, object, and defect is treated as equally important” (Boehm, 2003). This is especially true for testing, where its indirect contribution to product value leads to a value-neutral perception of testing. The common separation of concerns between development and testing exacerbates the problem. Testing is oftenreduced to a purely technical issue leaving the close relationship between testing and business decisions unlinked and the potential value contribution of testing unexploited.The objectives of this chapter are to motivate the need for value-based management of testing, to explain its underlying elements, to discuss existing practices that support value-based testing, and to outline a general framework for value-based test management. The remainder of this chapter is thus structured as follows. In Section 11.2 we discuss test management under the light of its value contribution. In Section 11.3 we describe existing practices that support value-based testing. Section 11.4 depicts a value-based test management framework using an example for illustration. An outlook on further research directions closes the chapter.11.2 Taking a Value-Based Perspective on TestingThe objectives of value-based verification and validation are defined as “ensuring that a software solution satisfies its value objectives” and organizing V&V tasks to operate as an investment activity” (Boehm and Huang, 2003). What are the contributions of testing if we look at it from a value-based perspective? Fundamentally, we can consider two dimensions: The internal dimension of testing covers costs and benefits of testing. The external dimension emphasizes the opportunities and risks of the future system that have to be addressed. The key challenge in value-based testing is to integrate these two dimensions, i.e., align the internal test process with the value objectives coming from the customers and the market.It becomes clear that a pure focus on the technical aspects of testing (e.g., the testing methods and tools) is inappropriate to align the internal and external dimensions. Instead, test management activities need to adopt a value-based perspective.Figure 41 illustrates the external and internal dimensions of test management and their interdependencies. The internal dimension is similar tothe scope of control of the test manager in the project. This dimension addresses costs from software testing practice as well as short-term and long-term benefits of testing. The external dimension considers stakeholders and parameters outside the scope of control of the test manager. Value-based test management organizes testing to satisfy value propositions of the stakeholders and to focus the team on the most worthwhile testing targets.The key question coming from the external view of software testing is: “How can we ensure th e value objectives of the software system?” The goal is to reconcile stakeholder value propositions by focusing testing efforts on the most worthwhile parts of the software, the most important quality characteristics, and the most urgent symptoms of risks that threaten the value contribution of the project. Answering this question involves market opportunities and threats, project-specific customer value propositions, as well as costs and benefits. Please refer to Chapter 1 for details about opportunities and risks and to Chapter 7 for elicitation and reconciliation of stakeholder value propositions.The internal view builds on the stakeholder value propositions and the test budget that represents the possible level of testing effort in a project. The key q uestion in this view is: “How can we organize testing as an investment activity?”The goal is to achieve effective and efficient testing considering changes in development and budget reductions. Internal project stakeholders consider how plans for software development and associated testing activities can contribute to stakeholder value propositions by supplying system functionality and performance, but also by limiting the impact of project-relevant risks.Appropriate communication is necessary to balance the external and internal dimensions of testing to assure the consistency of testing objectives with stakeholder value propositions.Value Contribution of TestingCompared to other development activities such as coding or user interface design, testing does not create immediate product value. Instead, testing informs and supports other value generating tasks in software development.A key to understanding the value contribution of testing is the contribution chain of testing (see the benefits realization approach described in Chapter 1). The contribution chain establishes the relation of testing to the final product that ultimately creates value for the stakeholders. Usually, the contribution chain of testing is complex and involves several different “clients,” who benefit from testing.Direct clients of testing are developers and project managers, who directly interact with the testing team (representing the internal dimension). However, in the spirit of value-based software engineering important parties for testing are customers and users (representing the external view). Customers and users are the source of value objectives (see Chapter 7), which set the context and scope of testing. Within this context testing informs developers and project managers to what extent value objectives are met and where improvement is required.Clients of TestingDevelopers, project managers, quality managers, customers, analysts, end users, or maintenance staff benefit from a thorough analysis of the software system and rely on feedback for detecting problems, reducing uncertainty, making decisions, or improving products and processes. The following examples show the kind of feedback from testing required by different groups: •Customers and users get information as to what extent mutually agreed requirements are satisfied and to what extent the software meets their value propositions. Testing also provides visibility and insights about project progress. Passed tests reduce the odds of misbehavior and acceptance decisions are thus frequently based on the results of tests.When acceptance tests are impractical or fail to reveal hidden problemsthat become visible only in real-world conditions, alpha and beta testing provide a more solid foundation for acceptance decisions. •Marketing and product managers require information from testing for planning releases, pricing, promotion, and distribution. A gap between the actual quality and the quality expected by customers and users most certainly leads to misleading expectations and wrong assumptions that diminish or prevent value realization (Boehm, 2000b). In order to successfully manage these expectations and to satisfy individual and organizational objectives, reconciling customer needs with product design has to consider quality in addition to functionality.•For project managers testing supports risk management and progress estimation. The focus is on identifying and eliminating risks that are potential value breakers and inhibit value achievements. Early detection of severe defects that significantly reduce project performance is a major objective. Ideally, testing reduces uncertainty and helps project managers to take better, more informed decisions, e.g., for defect removal, system stabilization, and release decisions. •Quality managers are interested in the identification of problems and in particular problem trends. Results from testing are the input for the assessment of development performance and provide the basis for quality assurance strategies and process improvement. Rosenberg (2003) discusses how testing contributes to quality assurance and shows that problems need to be documented, corrected, and can then be used for process improvement; after assessing problem reports for their validity corrective actions are implemented in accordance with customer-approved solutions; developers and users are informed about the problem status; and data for measuring and predicting software quality and reliability is provided.•Developers require feedback from testing to gain confidence that the implementation is complete and correct, conforming to standards, and satisfying quality requirements. For stabilization, testing provides details about defects and their estimated severity, information for reproducing defects, and support for revealing the cause of the failures.Besides, testing provides feedback for improvement and learning from defects. For example, throughout maintenance a detailed and reproducible description of problems contributes to the efficient implementation of changes and regression tests ensuring that these changes do not break existing functionality.•For requirements engineers, testing is valuable to validate and verify requirements. Gause and Weinberg (1989) point out that “… one of the most effective ways of testing requirements is with test cases very much like those for testing a complete system.” Deriving black-box tests from requirements helps to assure their completeness, accuracy, clarity, and conciseness early on. Tests thus enhance requirements and enable development in a test-driven manner.To summarize, testing helps to realize benefits by reducing planning uncertainty, mitigating risks, making more informed decisions, controlling efforts, and minimizing downstream costs (the internal dimension).More importantly, it helps to realize the expected stakeholder value propositions (the external dimension).These benefits, however, do not come for free and the costs of testing are often significant. Testing can be perceived as buying information and can be considered as an investment activity as it reduces the costs of risks, uncertainties, and the reward of taking risks. Making sound decisions about the investment in testing requires understanding their implications on both costs and benefits. The underlying questions therefore are: What are the costs of testing, and what are the benefits of testing for value generatingactivities?。