软件测试管理中英文资料外文翻译文献

基于价值的软件测试管理外文文献翻译(含：英文原文及中文译文)文献出处：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.中文：软件测试是软件开发中至关重要的过程。

Testing coverage : 测试覆盖
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.。

软件工程外文翻译文献(文档含中英文对照即英文原文和中文翻译)Software engineeringSoftware engineering is the study of the use of engineering methods to build and maintain effective, practical and high-quality software disciplines. It involves the programming language, database, software development tools, system platform, standards, design patterns and so on.In modern society, the software used in many ways. Typical software such as email, embedded systems, human-machine interface, office packages, operating systems, compilers, databases, games. Meanwhile, almost all the various sectors of computer software applications, such as industry, agriculture, banking, aviation and government departments. These applications facilitate the economic and social development,improve people's working efficiency, while improving the quality of life. Software engineers is to create software applications of people collectively, according to which software engineers can be divided into different areas of system analysts, software designers, system architects, programmers, testers and so on. It is also often used to refer to a variety of software engineers, programmers.OriginIn view of difficulties encountered in software development, North Atlantic Treaty Organization (NATO) in 1968 organized the first Conference on Software Engineering, and will be presented at the "software engineering" to define the knowledge required for software development, and suggested that "software development the activities of similar projects should be. " Software Engineering has formally proposed since 1968, this time to accumulate a large number of research results, widely lot of technical practice, academia and industry through the joint efforts of software engineering is gradually developing into a professional discipline.Definitioncreation and use of sound engineering principles in order to obtain reliable and economically efficient software.application of systematic, follow the principle can be measured approach to development, operation and maintenance of software; that is to beapplied to software engineering.The development, management and updating software products related to theories, methods and tools.A knowledge or discipline (discipline), aims to produce good quality, punctual delivery, within budget and meet users need software.the practical application of scientific knowledge in the design, build computer programs, and the accompanying documents produced, and the subsequent operation and maintenance.Use systematic production and maintenance of software products related to technology and management expertise to enable software development and changes in the limited time and under cost.Construction team of engineers developed the knowledge of large software systems disciplines.the software analysis, design, implementation and maintenance of a systematic method.the systematic application of tools and techniques in the development of computer-based applications.Software Engineering and Computer ScienceSoftware development in the end is a science or an engineering, this is a question to be debated for a long time. In fact, both the two characteristics of software development. But this does not mean that they can be confused with each other. Many people think that softwareengineering, computer science and information science-based as in the traditional sense of the physical and chemical engineering as. In the U.S., about 40% of software engineers with a degree in computer science. Elsewhere in the world, this ratio is also similar. They will not necessarily use every day knowledge of computer science, but every day they use the software engineering knowledge.For example, Peter McBreen that software "engineering" means higher degree of rigor and proven processes, not suitable for all types of software development stage. Peter McBreen in the book "Software Craftsmanship: The New Imperative" put forward the so-called "craftsmanship" of the argument, consider that a key factor in the success of software development, is to develop the skills, not "manufacturing" software process.Software engineering and computer programmingSoftware engineering exists in a variety of applications exist in all aspects of software development. The program design typically include program design and coding of the iterative process, it is a stage of software development.Software engineering, software project seeks to provide guidance in all aspects, from feasibility analysis software until the software after completion of maintenance work. Software engineering that software development and marketing activities are closely related. Such assoftware sales, user training, hardware and software associated with installation. Software engineering methodology that should not be an independent programmer from the team and to develop, and the program of preparation can not be divorced from the software requirements, design, and customer interests.Software engineering design of industrial development is the embodiment of a computer program.Software crisisSoftware engineering, rooted in the 20th century to the rise of 60,70 and 80 years of software crisis. At that time, many of the software have been a tragic final outcome. Many of the software development time significantly beyond the planned schedule. Some projects led to the loss of property, and even some of the software led to casualties. While software developers have found it increasingly difficult for software development.OS 360 operating system is considered to be a typical case. Until now, it is still used in the IBM360 series host. This experience for decades, even extremely complex software projects do not have a set of programs included in the original design of work systems. OS 360 is the first large software project, which uses about 1,000 programmers. Fred Brooks in his subsequent masterpiece, "The Mythical Man Month" (The Mythical Man-Month) in the once admitted that in his management of theproject, he made a million dollar mistake.Property losses: software error may result in significant property damage. European Ariane rocket explosion is one of the most painful lesson.Casualties: As computer software is widely used, including hospitals and other industries closely related to life. Therefore, the software error might also result in personal injury or death.Was used extensively in software engineering is the Therac-25 case of accidents. In 1985 between June and January 1987, six known medical errors from the Therac-25 to exceed the dose leads to death or severe radiation burns.In industry, some embedded systems do not lead to the normal operation of the machine, which will push some people into the woods. MethodologyThere are many ways software engineering aspects of meaning. Including project management, analysis, design, program preparation, testing and quality control.Software design methods can be distinguished as the heavyweight and lightweight methods. Heavyweight methods produce large amounts of official documentation.Heavyweight development methodologies, including the famous ISO 9000, CMM, and the Unified Process (RUP).Lightweight development process is not an official document of the large number of requirements. Lightweight methods, including well-known Extreme Programming (XP) and agile process (Agile Processes).According to the "new methodology" in this article, heavyweight method presented is a "defensive" posture. In the application of the "heavyweight methods" software organizations, due to a software project manager with little or no involvement in program design, can not grasp the item from the details of the progress of the project which will have a "fear", constantly had to ask the programmer to write a lot of "software development documentation." The lightweight methods are presented "aggressive" attitude, which is from the XP method is particularly emphasized four criteria - "communication, simplicity, feedback and courage" to be reflected on. There are some people that the "heavyweight method" is suitable for large software team (dozens or more) use, and "lightweight methods" for small software team (a few people, a dozen people) to use. Of course, on the heavyweight and lightweight method of approach has many advantages and disadvantages of debate, and various methods are constantly evolving.Some methodologists think that people should be strictly followed in the development and implementation of these methods. But some people do not have the conditions to implement these methods. In fact, themethod by which software development depends on many factors, but subject to environmental constraints.Software development processSoftware development process, with the subsequent development of technology evolution and improvement. From the early waterfall (Waterfall) development model to the subsequent emergence of the spiral iterative (Spiral) development, which recently began the rise of agile development methodologies (Agile), they showed a different era in the development process for software industry different awareness and understanding of different types of projects for the method.Note distinction between software development process and software process improvement important difference between. Such as ISO 15504, ISO 9000, CMM, CMMI such terms are elaborated in the framework of software process improvement, they provide a series of standards and policies to guide software organizations how to improve the quality of the software development process, the ability of software organizations, and not give a specific definition of the development process.Development of software engineering"Agile Development" (Agile Development) is considered an important software engineering development. It stressed that software development should be able to possible future changes and uncertaintiesof a comprehensive response.Agile development is considered a "lightweight" approach. In the lightweight approach should be the most prestigious "Extreme Programming" (Extreme Programming, referred to as XP).Correspond with the lightweight approach is the "heavyweight method" exists. Heavyweight approach emphasizes the development process as the center, rather than people-centered. Examples of methods such as heavyweight CMM / PSP / TSP.Aspect-oriented programming (Aspect Oriented Programming, referred to as the AOP) is considered to software engineering in recent years, another important development. This aspect refers to the completion of a function of a collection of objects and functions. In this regard the contents related to generic programming (Generic Programming) and templates.软件工程软件工程是一门研究用工程化方法构建和维护有效的、实用的和高质量的软件的学科。

中英文翻译Database Application Testing1.IntroductionDatabases play a pivotal role in almost every organization in today’s information-based society. Commercial Database managementsystems(DBMSs) provide organizations with efficient access to huge amounts of data without affecting the integrity of data and relieving the user of the any need to understand the low-level implementation details. Over the years tremendous efforts have been devoted to ensuring use of efficient and integrity protecting data structures and algorithms by DBMSs. However, little has been done to develop systematic techniques for ensuring correctness of applications using these DBMSs. Many testing techniques have been developed to help ensure that behaviour of a program is in accordance with the specifications. However, these techniques mostly target programs written in traditional imperative languages and can’t be of much help when it comes to database applications. Like any other program, database application program can be viewed as an attempt to implement a function. Considered this way, both the input and output spaces of this function will include database state apart from the explicit input and output parameters of the application. This affects substantially the way a test case is defined, generated and executed to check correctness of application. Hence there is a need for new approaches specifically oriented towards testing database applications.Testing database application programs involves the following phases :•Extraction of information from database schema•Generation of test data and Populating test database•Generation of test cases as input to the application program•Validation of database state and output after executionUsing live data has several limitations. It may not reflect sufficiently wide variety of possible situations and even if it does, it might be difficult to find them in a large database. Secondly, privacy or security constraints might prevent the user from seeing sensitive data. Hence, various methods for generating synthetic test data have been proposed. When generating data and populating the test database, its important to generate valid and interesting data e.g. it would be advisable to select data so as to include situations which the tester believes are likely to occur or will expose faults in application. The technique used for test data generation will determine the extent of coverage of test database. Selecting a good initial database state so as to include a wide variety of scenarios resembling real data for the particular application is very beneficial. Since database state plays an important role in determining the output, it has to be checked after each execution that only the specified modifications and none others have occurred.2.AGENDA - tool set for testing DB applicationsAGENDA is a tool set has been designed. AGENDA takes as input the application database schema, application source code and files containing sample values which contain suggested values for the attributes provided by the user. The user interactively selects test heuristics and provides information about expected behaviour of test cases. Using this information AGENDA, populates the database, generates inputs to the application, executes the application on those inputs and checks some aspects of correctness of the resulting database state and application output.13. Input Generator :It generates the input data to be supplied to the application by using information derived from Agenda parser and State generator in addition to the information gained by parsing the SQL statements in the application program and information useful for checking test results. Information derived from parsing the source code may be useful in suggesting inputs that tester should supply to the application. The input generator thus generates test inputs by instantiating the input parameters with actual parameters.4. State Validator :The validator monitors the change in application DB state during execution of a test. It automatically logs the changes in the application tables andsemi-automatically checks the state change.5. Output Validator :It captures the application’s outputs and checks them against the query preconditions and post conditions that have been generated by the tool or supplied by the tester.6. Design and Implementation6.1 Parsing toolThe Agenda Parsing tool is based on PostgresSQL parser. PostgresSQL parser creates an Abstract Syntax Tree containing relevant information about tables, attributes and constraints from a given schema. However, this information is spread out at different locations in the tree. In addition, it is possible to have different tree structures having the same underlying information about the tables, because of use of different SQL DDL syntactic constructs expressing the same information. Consequently, the exact location of relevant information depends on the exact syntax of schema definition. Some of the information from DBMS’s internal catalog tables is needed by other components of AGENDA. Allowing them to directly query these tables would have introduced interdependency between AGENDA components which is not desirable. Hence all the information that needs to be processed is stored in Agenda DB which is made available to other components. This decoupling of PostgresSQL from rest of the components allows AGENDA to be ported to different DBMS just by changing the Parser. The Parser extracts information about integrity constraints such as uniqueness constraints, referential constraints and not NULL constraints from schema. It also extracts limited information from semantic constraints, particularly boundary values. This is very useful in automatic data-partitioning and input generation. Next, the Agenda Parser parses the sample-value files containing user-supplied data and stores the sample values, their data groups and associated attributes in the Agenda DB. Attributes involved in composite constraints are marked so that they can be correctly handled by input generator.7 Extensions to AGENDA7.1 Testing Web DB applicationsWith the tremendous growth of World Wide Web, many new web-based services that are driven by data stored in databases are gaining importance. Examples include E-commerce applications such as online stores, and business-to-business support products. Some of these are of critical importance and hence it is essential to ensure their correct functioning. Most web DB applications consist of threes layers - at the base is DBMS and a database, at the top is client web browser and in between lies the application logic - usually developed with a server-side scripting language or Java extended with library that can interface with DBMSs, and can decode and produce HTML pages displayed in the client browser. For a web application a test case is considered as a sequence of pages to be visited along with the input values to be provided to the pages containing forms. The white box approach involves following steps:1. Information extraction from application source :Useful information such as URL links(which includes all other URLs that can be reached from the current page) and parameter information(name-value pairs that are passed to the Servlet) for each URL is extracted from application source. URLs are partitioned into two categories depending on their content - static and data-based(dynamic) page.2. Web application graph generation and path selection :Based on the information extracted earlier, an application graph, where each node represents a URL and edges represent URL links, is generated and then simplified according to URL link types. There is an edge from URL A to URL B if URL A produces a link to URL B in the HTML page it generates. Paths through the graph represent natural sequences of execution of URLs as a user navigates through the web application. Hence, some of these paths are selected as test cases to represent possible scenarios of use of the application.3. Input Generation :For each path selected, AGENDA is used to generate inputs for each URL. The path along with inputs constitute a test case. An XML file is generated corresponding to each such test case.4. Test Execution :The XML file is parsed using XML parser to extract URL information and the test case is executed automatically using open source Jakarta Http Client integrated with AGENDA. After execution of each update or insertion, AGENDA checks the new database states. Output pages are checked by manual inspection or other tools. The tool in its current form is targeted to the Java Servlet model, using JDBC for database access, and makes some assumptions about programming style. However, the basic technique can be applied to more general servlet styles and other web application languages.8.Regression Tests For Database ApplicationsAny application is constantly going through the process of evolution such as its components getting replaced with more powerful components, various optimizations being incorporated and so on. Whenever such modification is introduced in an application, it is important to check for the integrity of the application and that is the purpose of regression tests. There are various tools built for automating the regression testing procedure, most popular being JUnit framework developed for carrying out regression tests for Java applications. Database applications which are composed of many layers and stacked in various layers are, in particular, subject to constant change for instancere-engineering of business processes, authorization rules being changed etc. Changing database applications is very costly and involves great deal of manual work since there aren’t any tools available that can automatically carrying out regression tests on them.9.Conclusions and Future WorkThe AGENDA tool set was designed and implemented in response to a lack of specific work targeted at testing database application. Prior to AGENDA, various approaches had been proposed and implemented for tackling the issues involved in database testing individually. However, no single tool had been designed to tackle all the issues together by integrating the strategies to handle different issues. AGENDA handles a variety of issues such as test data generation, populating the test database, generating interesting test cases and handling integrity constraints of the application database such as not-Null, uniqueness etc, checking the database state after every modification,executing the test case and validating the output. Besides, later extensions to AGENDA have enhanced its ability improving the state checking and input generation mechanism and enabling the tool to test transactions. AGENDA has also served as an aid in testing web-based database applications. However, there are a lot of issues still to be dealt with and many limitations to be addressed. AGENDA uses semi-automatic technique for generating test data. e.g. For attributes having numeric/real value the sample-value file is generated automatically (Section 2.2.1). However, attributes of string type are not handled. Increasing the extent of automation, extracting more information from the embedded SQL statements in the application program source are some of the important tasks that need attention. The tool for testing web-based applications has a lot of limitations as of now. It can currently handle only applications implemented Java Servlets and HTML pages. Further, it assumes that the application source follows certain programming style. These issues are being addressed to. There is also work going on to extend the tool to handle issues like sessions, cookies etc and test web application security. Regression testing is a well-studied technique in Software engineering, however issues specifically related to database applications haven’t received the deserved attention. The whole topic of testing database applications is still in its infancy. No rigorous methodologies have been devised yet and there are several open issues such as the automatic generation and evolution of test runs, the generation of test databases, and the development of platform independent tools. All these challenges are currently being tackled and efforts are on to make the process of testing database applications efficient.数据库应用程序的测试1．引言数据库中的几乎每一个组织在当今信息化社会中发挥了举足轻重的作用。

A Day in the Life of a Quality Assurance Tester质量保障测试人员的一天This paper will discuss the day to day activities of being a tester and instilling quality into software. Begins with a discussion of what is software testing, what is quality assurance, how do the two relate to each other, what are the daily tasks involved in software testing and Quality Assurance, what are the pain points and areas for improvement, and how an individual tester can add value to the development process no matter what type of software development life cycle.这篇文将讨论测试人员日常工作，及怎样将质量灌输到软件中。

我们将先讨论什么是软件测试，什么是质量保障，它们之间如何关联？软件测试和质量保障涉及到哪些日常工作，有哪些问题点和领域可改善，以及作为一个测试者，如何在任何软件开发生命周期中，都能对开发过程提供价值呢。

What is Software Testing?什么是软件测试？Software testing is the systematic process by which an analyst uncovers defects in software. What are defects, you might ask? Defects are flaws in the code that cause a software application to break. While no software is completely defect- free, it is the aim of testers to reduce the number of defects found in software and to instill quality in the software application. Software testing includes the process of validating that the software has incorporated the user requirements present in the Software Requirements Specification document and meets users’ needs. Software testers analyze software to see if the software conforms to user expectations. Software testing is one of the activities designed to adequately assure that the software has the necessary quality required by the users.软件测试是分析者用来发现软件缺陷的有组织的过程。

Acceptance testing 验收测试Accessibility 可接近性Active or open 激活状态Adaptability 适应性Ad-hoc Test 随机测试Architecture 体系结构Audit 审核Auditor 审核员Auditor qualifications 审核员资格Availability 可用性Behavioral test 行为测试Baseline 基线Black-box test 黑盒测试Bottom-up integration 自底向上集成Boundary condition 边界条件Bug 缺陷Bug crawl 缺陷评审会议Build 软件构建包Capability 能力Capacity test 容量测试Certification 认证Change control 变更控制管理CCB，Change Control Bard 变更控制委员会Characteristic 特性Close or inactive 关闭或非激活状态Closure period 修复周期Code audit 代码审计Code completed 代码完成Code freeze 代码冻结Code inspection 代码审查Code walk — through 代码走查Cohesion 内聚度Compatibility 兼容性Compile 编译Complexity 复杂性Component testing 组件测试Comfirmation tests 确认测试Configuration management 配置管理Conformity 合格（符合）Congruent 一致性Continual improvement 持续改进Corrective action 纠正措施Coupling 耦合度Coverage 覆盖率Criteria 准则、指标Critical bug 严重的缺陷Customer satisfaction 顾客满意度C/S, Client/Server 客户端/服务器（机构）Data dictionary 数据字典Data structure 数据结构Data flow testing 数据流测试Debugging 调试Defect 缺陷Delivery 交付Dependability 可信性Design and development 设计与开发Design specification 设计规格说明Development life cycle 开发生存周期Deviation permit 偏离许可Distributed testing 分布式测试Document 文件Effectiveness 有效性Efficiency 效率Encapsulation 封装Entry criteria 进入标准Error seeding 错误播种Error，faults and failures 错误、缺陷与失效Escalate 向上呈交Evaluation 评价评估Exit criteria 退出标准Experience of quality 质量体验Exploratory testing 探索性测试Failure 失效Fatal bug 致命的缺陷Fault injection 错误注入Fault of omission 遗漏缺陷Feasible coverage 可行覆盖率Feature 产品特性Fidelity 逼真度Field-reported bug 现场报告缺陷First customer ship 首位客户送货Fixed or resolved 已修正状态Flexibility 灵活性FMEA 失效模型和效果分析Functional specification 产品功能规格说明书Functional tests 功能测试Functionality 功能性GA 通用有效性Grade 等级Ideal fault condition 理想缺陷条件Identifier 标识符Information 信息Infrastructure 基础设施Implementation requirement 实现需求Input 输入Inspection 检验Integration testing 集成测试Interoperability 互操作性Isolation 隔离Log file 记录文件Maintainable 可维护性Major bug 一般的缺陷Management 管理Management system 管理体系Measurement control system 测量控制体系Measurement process 测量进程Metrological characteristic 计量特性Metrological confirmation 计量确认Metrological function 计量职能Milestone 里程碑Minor bug 微小的缺陷Modified Top-down integration 改进的自顶向下集成Modularity 模块性Module 模块MTBF 失效平均时间MTTR 平均维修时间Necessity condition 必要性条件Nest 嵌套Objective evidence 客观证据Organizational structure 组织机构Orthogonal 正交Output 输出Peer review 同级评审Performance test 性能测试Pilot testing 引导测试Preventive action 预防措施Priority 优先权Procedure 程序过程Program specification 概要说明Process 过程Product 产品Project 项目Qualification process 鉴定过程Quality assurance 质量保证Quality characteristic 质量特性Quality control 质量控制Quality improvement 质量改进Quality management 质量管理Quality manual 质量手册Quality metric 质量度量Quality Objective 质量目标Quality plan 质量计划Quality panning 质量策划Quality policy 质量方针Record 记录Recovery testing 恢复测试Regression 回归Regression tests 回归测试Regression test gap 回归测试间距Release 产品发布Reliability 可靠性Reporting logs 报告日志Requirement 要求Reusability 可重用性复用率Review 评审Risk 风险Root cause 根本原因Scalability 可扩展性Script 脚本Security 安全性保密性Security testing 安全性测试Service manageability 可维护性Severity 严重性SDLC，Software Development Life Cycle 软件开发生命周期Software development process 软件开发进程Software engineering 软件功能Specification（spec）规范Stability 稳定性Standard combining rules 标准组合规则Stress testing 负载（压力）测试Structured programming 结构化成程序设计Structural test 结构测试Stub 桩模块System testing 系统测试Test automation 测试自动化Test case 测试用例Test case library 测试用例库Test casually 随机测试Test coverage 测试覆盖Test environment 测试环境Test phase 测试阶段Test platform 测试平台Test specification 测试规格说明Test suite 测试包测试套件Test system 测试系统Test to fail 基于失效的测试Test to pass 基于通过的测试Test tool 测试工具Testability 可测试性Tolerance test 容错测试Traceability 可追溯性Unit testing 单元测试Usability 可用性Validation 确认Verification 验证Version 版本White-box tests 白盒测试Walk-throuth 走查。

Software Testing: Black-Box TechniquesSmirnov SergeyAbstract – Software systems play a key role in different parts of modern life. Software is used in every financial, business, educational etc. organization. Therefore, there is a demand for high quality software. It means software should be proper tested and verified before system-integration time. This work concentrated on so-called black-box technique for software testing. The several black-box methods were considered with their strengths and weaknesses. Also, the potential of automated black-box techniques for better performance in testing of reusable components was studied. Finally, the topic related to software security testing was discussed.1. IntroductionComputer technologies plays an important role in the modern society. Computers and Software that drives them affect more people and more businesses than ever today. Therefore, there is a pressure for software developers not only to build software systems quickly, but to focus on quality issues too. Low quality software that can cause loss of life or money is no longer acceptable. In order to achieve a production of highquality software the whole process of developing and maintaining of the software has to be changed and developers have to be correspondingly educated and trained. Testing takes an important part in any software development process (Fig. ). As a process by itself it is related to two other processes verification and validation.Validation is a process of evaluation a software system or component during or, at the end of, the development cycle in order to determine whether it satisfies specified requirements [8]. Verification is the process of evaluating a software system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase [8].Software testing is a process or several processes designed to make sure computer code does what it was designed to do and that it does not do anything unexpected [2].The software testers are responsible to design tests that reveal defects and can be used to evaluate usability and reliability of the software performance. To achieve these goals testers must select a finite number of test cases [1]. There are two basic techniques that can be used to design test cases:–Black-box (sometimes called functional or specification);–– White-box (sometimes called clear or glass box). The white-box technique focuses on the inner structure of the software under test (SUT). To be able to design test cases using this approach a tester has to have a knowledge of the software structure.The source code or suitable pseudo code must be available [1].Figure : A Software Development ProcessBy using the black-box approach the software is viewed as a black box. The goal of a tester is to be completely unconcerned about inner structure of the software. Instead, concentrate on software behavior and functionality (Table 1).Table 1: Two basic testing techniquesWhy do we need black-box testing? First, this approach is useful for revealing requirements and specification defects. Another reason is a testing of reusable software components. Many companies use components from an outside vendors that specialize in the development of specific types of software, so-called Commercial Offthe- Shell Components (COTS).Using such components can save time and money. However, the components 1 have to be evaluated before becoming a part of any developed system. In most cases when a COTS component is purchased from a vendor, no source code is available and even if there is some, it is very expensive to buy. Usually just an executable version of the component is in the hands. In this case black-box testing might be very useful.Next sections of the work present the black-box methods and some issues related to an automation of the methods and software security testing.2. Black-Box Software Testing MethodsBy using black-box approach we are considering only inputs and outputs as a basis for designing test cases. However, we should keep in mind that due to finite time and resources an exhaustive test of all possible inputs is not possible. Therefore, it is a goal of a tester by using available resources to produce the test cases that give a maximum number of found defects. There are several methods that can help to achieve the above mentioned goal.Random TestingEach software system has an input domain from which input data is selected for testing. If inputs are randomly selected this is called random testing. The advantage of the method is that it can save time and effort that more detailed and thoughtful test input selection methods require. On the other hand, random test inputs in many cases can not produce effective set of test data [2].Equivalence Class PartitioningAn Equivalence Class Partitioning (ECP) approach divides the input domain of a software to be tested into the finite number of partitions or eqivalence classes. This method can be used to partition the output domain as well, but it is not commonly used.The result of the partitioning allows a tester to select one member of each class and based on it create test cases. It is assumed that all other members of the same equivalence class are processed the same way by the software under test. Therefore, if one test case based on chosen member detects a defect, all the other test cases based on that class would be expected to detect the same defect. And vice versa, if the test case did not detect a defect, we would expect that no other test cases in the equivalence class would produce an error.This approach has the following advantages [1]:–Elimination of the needs for exhaustive testing through the whole input/output domain, that is not possible;––Following the approach a tester selects a subset of test inputs with a high probability of detecting the defects.A test case design by ECP has two steps:1) Identifying the equivalence classes;2) Defining the test cases.We identify the equivalence classes by taking each input condition and partitioning it into two or more groups: valid equivalence classes, that include valid input to the software, and invalid equivalence classes, that represent all other possible states [2]. There are a set of rules that can be used to identify equivalence classes [2]:–If an input condition specifies a range of values, identify one valid equivalence classwithin this range, and two invalid classes out of range on the left and right side respectively.––If an input condition specify a number of values, specify one valid equivalence class within the values, and two invalid equivalence classes out of the number.––If an input condition specify a set of input values and there is a believe that the software handles each value differently, identify a valid equivalence class for each and one invalid equivalence class.––If an input condition specify a …must be“ situation, identify one valid equivalence class and one invalid equivalence class.However, there are no fast rules for identification of equivalence classes. With experience a tester is able to select equivalence class more effectively and with confindence.If there is a doubt, that the software does not process the members of the equivalence class identically, the equivalence class should be split into smaller classes. The second step of defining the test cases is as following [2]:1. Assign an unique number to each equivalence class;2. Write a new test case trying to cover all valid equivalence class;3. Write a new test case for each invalid equivalence class.Boundary Value AnalisisThe Equivalence Class Partitioning can be supplemented by another method called Boundary Value Analysis (BV A). A tester selects elements close to the edges of the input, so that the test case covers both upper and lower edges of an equivalence class [1].The ability of creating a high-quality test cases with the use of the Boundary Value Analysis depends greatly on the tester's experience as in case of the Equivalence Class Partitioning approach.Cause-Effect GraphingThe major weakness of Equivalence Class Partitioning and Boundary Value Analysis is that the methods do not allow to combine conditions. Furthermore, the number of possible combination is usually very large. Therefore, there must be a systematic way of selectiong a subset of input combinations.Cause-Effect Graphing provides a systematic approach for selecting a set of test cases. The natural-language specification is translated into a formal language – a cause-effect graph. The graph is a digital-logic circuit, but in order to build a graph no knowledge of electronics is necessary. The tester should understand only the boolean logic. The following steps are used to produce test cases [2]:–Divide the specification into workable parts. Large specifications make a cause-effectgraph difficult to manage.Figure : Simple Cause-Effect Graphs–Identify the causes and effects in the specification. A cause is a distinct input condition or an equivalence class of input conditions. An effect is an output condition or a system transformation. The causes and effects are identified by reading the specification.Once identified, each cause and effect is assigned an unique number.–From cause and effect information a boolean causeeffect graph that links causes and effects together is created.–Annotations with constraints are added, that describe combinations of causes and/or effects which are impossible.–The graph is converted to a decision table.–The colomns of the decision table are converted into test cases.The simple examples of cause-effects graphs are shown in Figure . The more detailed description with examples of this method can be found in [1] and [2].Error GuessingDesign of test cases using error guessing method is based on the tester's past experience and intuition. It is impossible to give a procedure for an error guessing approach since it is more intuitive and ad hoc process. The basic idea behind is to enumerate a list of possible errors and then write test cases based on this list.State Transition Testing StateTransition Testing can be used for both objectoriented and procedural software development. The approach is based on the concept of finite-state machine and states. It views the softwareunder test in term of its states, transitions between states, and the inputs or events that trigger state changes.A state is an internal configuration of a system. It is defined in terms of the values assumed at a particular time for the variables that characterize the system or component [1].A finite-state machine is an abstract machine that can be represented by a state graph having a finite number of states and a finite number of transitions between states [1].A State Transition Graph (STG) can be designed for the whole software system or for its specific modules. The STG graph consists of nodes (circles, ovals, rounded rectangles) that represent states and arrows between nodes that indicate what input (event) will cause a transition between two linked states. The Figure shows a simple state transition graph [1].Figure : A simple state transition graphS1 and S2 are two states. The black dot is a pointer to an initial state from outside. The arrows represent inputs/actions that cause the state transformations. It is useful to attach to the graph the system variables that are effected by state changes. The state transition graph can become very complex for large systems. One way to simplify it to use a state table representation. A state table for the graph in Figure is shown in Table 2 [1]. The State Table lists all inputs that cause the state transitions. For each state and each input the next state and action taken are shown.Table 2: A state table for the state transition graph in Fig.The STG should be prepared by developers as a part of the requirements specification. Once the graph was designed it must be reviewed. The review should ensure that –the proper number of states is represented;–each state transition (input/output/action) is correct;–equivalent states are identified;–unreachable and dead states are identified.Unreachable states are states that will never be reached with any input sequence and may indicate missing transitions. Dead states are states that once entered can not be exited [1]. After the review the test cases should be planed. One practical approach is to test every possible state transition [4].3. Automated Black-Box TestingA few black-box methods were listed above. The problem with those methods is that often the performance of testing depends greatly on experience and intuition of the tester. Therefore, there is a question if black-box testing can be automated to make testing more thorough and cost-effective.Furthermore, there is need in black-box methods, that can be used for testing reusable software components before integration into a system under development. The reusable components can be independently developed or commercially purchased. The quality of these components can vary from one vendor to another.The general strategy for automated black-box testing of software components was proposed in [5] . The strategy is based on combination of three techniques: automatic generation of component test drivers, automatic generation of test data, and automatic or semi-automatic generation of wrappers serving the role of test oracles.An approach that allows testers to take advantage of the combinatorial explosion of expected results was developed in [6]. There is a possibility to generate and check the correctness of a relatively small sets of test cases by using software Input/Output relationships. Then the expected results can be generated for the much larger combinatorial test data set. It allows a fully automated execution.In [3] Richard Torkar made a comparison of the main black-box methods in order to find their weaknesses and strengths. It was mentioned that the methods such as Cause-Effect Graphing and Error-Guessing are not suitable for automation. The difficulty in case of Equivalence Class Partitioning would be to automate the partitioning of the input domain in a satisfactory way.Since the effectiveness of black-box techniques is close connected to experience of the tester, in our opinion they can be automated by using artificial intellegence methods such as neural networks and fuzzy logic. More information about research in this area can be found in [7]. 4. Black Box Testing and Software SecurityAt the present there is a pressure on software developers to produce high quality software. Thesecurity aspects are highly related to a software quality. Security testing should be integrated in the testing process, but in reality it is not true in most cases. Usually the developers test the software just for functional requirements and do not consider security issues.One way to check software for secure vulnerabilites is to study known security problems in similar systems and generate test cases based on it. Then applying black-box techniques to run these test cases. The black-box methods play an important part in securtity testing. They allow the testers to look at the software under test from the side of attackers, which usually do not have any information about attacked system and therefore consider it as a black-box. Security testing is important for e-commerce software systems such as corporate web-sites. Furthermore, since buffer overflow is a result of bad constructed software programs, security testing can reveal such vulnerabilities, what is helpful for checking both local programs such as games, calculators, office software etc. and remote software such as e-mail servers, FTP, DNS and Internet web servers.ConclusionSoftware testing became an essential part of the software development process. The well designed test cases can significantly increase the quantity of found faults and errors.The mentioned above black-box methods provide an effective way of testing with no knowledge of inside structure of the software to be tested. Nevertheless, the quality of the black-box testing depends in general on the experience and intuition of the tester. Therefore, it is hard to automate this process. In spite of this fact, there were made a several attempts to develop approaches for automated black-box testing.The black-box testing helps the developers and testers to check software under test for secure vulnerabilities. The secure testing is a matter of importance for e-commerce applications, that are available in the Internet for a wide range of people, and for revealing buffer overflow vulnerabilities in different local and remote applications.软件测试：黑盒技术Smirnov Sergey摘要：在现代社会中，软件系统占了一个重要的位子。

STUDY PAPER ON TEST CASE GENERATION FOR GUI BASED TESTINGABSTRACTWith the advent of WWW and outburst in technology and software development, testing the softwarebecame a major concern. Due to the importance of the testing phase in a software development lifecycle,testing has been divided into graphical user interface (GUI) based testing, logical testing, integrationtesting, etc.GUI Testing has become very important as it provides more sophisticated way to interact withthe software. The complexity of testing GUI increased over time. The testing needs to be performed in away that it provides effectiveness, efficiency, increased fault detection rate and good path coverage. Tocover all use cases and to provide testing for all possible (success/failure) scenarios the length of the testsequence is considered important. Intent of this paper is to study some techniques used for test casegeneration and process for various GUI based software applications.KEYWORDSGUI Testing, Model-Based Testing, Test Case, Automated Testing, Event Testing.1. INTRODUCTIONGraphical User Interface (GUI) is a program interface that takes advantage of the computer'sgraphics capabilities to make the program easier to use. Graphical User Interface (GUI) providesuser an immense way to interact with the software [1]. The most eminent and essential parts ofthe software that is being used today are Graphical User Interfaces (GUIs) [8], [9]. Even thoughGUIs provides user an easy way to use the software, they make the development process of the software tangled [2].Graphical user interface (GUI) testing is the process of testing software's graphical user interfaceto safeguard it meets its written specifications and to detect if application is working functionally correct. GUI testing involves performing some tasks and comparing the result with the expected output. This is performed using test cases. GUI Testing can be performed either manually byhumans or automatically by automated methods.Manual testing is done by humans such as testers or developers itself in some cases and it is oftenerror prone and there are chances of most of the test scenarios left out. It is very time consumingalso. Automated GUI Testing includes automating testing tasks that have been done manually before, using automated techniques and tools. Automated GUI testing is more, efficient, precise, reliable and cost effective.A test case normally consists of an input, output, expected result and the actual result. More thanone test case is required to test the full functionality of the GUI application. A collection of testcases are called test suite. A test suite contains detailed guidelines or objectives for eachcollection of test cases.Model Based Testing (MBT) is a quick and organized method which automates the testing process through automated test suite generation and execution techniques and tools [11]. Model based testing uses the directed graph model of the GUI called event-interaction graph (EIG) [4] and event semantic interaction graph (ESIG). Event interaction graph is a refinement of event flow graph (EFG) [1]. EIG contains events that interact with the business logic of the GUI application. Event Semantic Interaction (ESI) is used to identify set of events that need to be tested together in multi-way interactions [3] and it is more useful when partitioning the events according to its functionality.This paper is organized as follow: Section 2 provides some techniques, algorithms used to generate test cases, a method to repair the infeasible test suites are described in section 3, GUI testing on various types of softwares or under different conditions are elaborated in section 4, section 5 describes about testing the GUI application by taking event context into consideration and last section concludes the paper.2. TEST CASE GENERATION2.1. Using GUI Run-Time State as FeedbackXun Yuan and Atif M Memon [3], used GUI run time state as feedback for test case generation and the feedback is obtained from the execution of a seed test suite on an Application Under Test (AUT).This feedback is used to generate additional test cases and test interactions between GUI events in multiple ways. An Event Interaction Graph (EIG) is generated for the application to be tested and seed test suites are generated for two-way interactions of GUI events. Then the test suites are executed and the GUI’s run time state is recorded. This recorded GUI run time state is used to obtain Event Semantic Interaction(ESI) relationship for the application and these ESI are used to obtain the Event Semantic Interaction Graph(ESIG).The test cases are generated and ESIGs is capable of managing test cases for more than two-way interactions and hence forth 2-, 3-,4-,5- way interactions are tested. The newly generated test cases are tested and additional faults are detected. These steps are shown in Figure 1. The fault detection effectiveness is high than the two way interactions and it is because, test cases are generated and executed for combination of events in different execution orders.There also some disadvantages in this feedback mechanism. This method is designed focusing on GUI applications. It will be different for applications that have intricate underlying business logic and a simple GUI. As multi-way interactions test cases are generated, large number of test cases will be generated. This feedback mechanism is not automated.Figure 1. Test Case Generation Using GUI Runtime as Feedback2.2. Using Covering Array TechniqueXun Yuan et al [4], proposed a new automated technique for test case generation using covering arrays (CA) for GUI testing. Usually 2-way covering are used for testing. Because as number of events in a sequence increases, the size of test suite grows large, preventing from using sequences longer than 3 or 4. But certain defects are not detected using this coverage strength. Using this technique long test sequences are generated and it is systematically sampled at particular coverage strength. By using covering arrays t-way coverage strength is being maintained, but any length test sequences can be generated of at least t. A covering array, CA(N; t, k, v), is an N × k array on v symbols with the property that every N × t sub-array contains all ordered subsets of size t of the v symbols at least once.As shown in Figure 2, Initially EIG model is created which is then partitioned into groups of interacting events and then constraints are identified and used to generate abstract model for testing. Long test cases are generated using covering array sampling. Event sequences are generated and executed. If any event interaction is missed, then regenerate test cases and repeat the steps.The disadvantages are event partition and identifying constraints are done manually.Figure 2. Test Generation Using Covering Array2.3. Dynamic Adaptive Automated test GenerationXun Yuan et al [5], suggested an algorithm to generate test suites with fewer infeasible test cases and higher event interaction coverage. Due to dynamic state based nature of GUIs, it is necessary and important to generate test cases based on the feedback from the execution of tests. The proposed framework uses techniques from combinatorial interaction testing to generate tests and basis for combinatorial interaction testing is a covering array. Initially smoke tests are generated and this is used as a seed to generate Event Semantic Interaction (ESI) relationships. Event Semantic Interaction Graph is generated from ESI. Iterative refinement is done through genetic algorithm. An initial model of the GUI event interactions and an initial set of test sequences based on the model are generated. Then a batch of test cases are generated and executed. Code coverage is determined and unexecutable test cases are identified. Once the infeasible test cases are identified, it is removed and the model is updated and new batch of test cases are generated and the steps are followed till all the uncovered ESI relationships are covered. These automated test case generation process is shown in Figure 3. This automated test generation also provides validation for GUIs.The disadvantages are event contexts are not incorporated and need coverage and test adequacy criteria to check how these impacts fault detection.Figure 3. Automated Test Case Generation3. REPAIRING TEST SUITESSi Huang et al [6], proposed a method to repair GUI test suites using Genetic algorithm. New test cases are generated that are feasible and Genetic algorithm is used to develop test cases that provide additional test suite coverage by removing infeasible test cases and inserting new feasible test cases. A framework is used to automatically repair infeasible test cases. A graph model such as EFG, EIG, ESIG and the ripped GUI structure are used as input. The main controller passesgenerator along with the strength of testing. This covering array generator generates an initial set of event sequences. The covering array information is send to test case assembler and it assembles this into concrete test cases. These are passed back to the controller and test suite repair phase begins. Feasible test cases are returned by the framework once the repair phase is complete. Genetic algorithm is used as a repair algorithm. An initial set of test cases are executed and if there is no infeasible test cases, it exits and is done. If infeasible test cases are present, it then begins the repair phase. A certain number of iterations are set based on an estimate of how large the repaired test suite will be allowed to grow and for each iteration the genetic algorithm is executed. The algorithm adds best test case to the final test suites. Stopping criteria’s are used to stop the iterations.The advantages are it generates smaller test suites with better coverage on the longer test sequences. It provides feasible test cases. But it is not scalable for larger applications as execution time is high. As GUI ripping is used, the programs that contain event dependencies may not be discovered.4. GUI TESTING ON VARIOUS APPLICATIONS4.1. Industrial Graphical User Interface SystemsPenelope Brooks et al [7], developed GUI testing methods that are relevant to industry applications that improve the overall quality of GUI testing by characterizing GUI systems using data collected from defects detected to assist testers and researchers in developing more effective test strategies. In this method, defects are classified based on beizer’s defect taxonomy. Eight levels of categories are present each describing specific defects such as functional defects, functionality as implemented, structural defects, data defects, implementation defects, integration defects, system defects and test defects. The categories can be modified and added according to the need. If any failures occur, it is analyzed under which defect category it comes and this classification is used to design better test oracle to detect such failures, better test case algorithm may be designed and better fault seeding models may be designed.Goal Question Metric (GQM) Paradigm is used. It is used to analyze the test cases, defects and source metrics from the tester / researcher point of view in the context of industry-developed GUI software. The limitations are, the GUI systems are characterized based on system events only. User Interactions are not included.4.2. Community-Driven Open Source GUI ApplicationsQing Xie and Atif M. Memon [8], presented a new approach for continuous integration testing of web-based community-driven GUI-based Open Source Software(OSS).As in OSS many developers are involved and make changes to the code through WWW, it is prone to more defects and the changes keep on occurring. Therefore three nested techniques or three concentric loops are used to automate model-based testing of evolving GUI-based OSS. Crash testing is the innermost technique operates on each code check-in of the GUI software and it is executed frequently with an automated GUI testing intervention and performs quickly also. It reports the software crashes back to the developer who checked in the code. Smoke testing is the second technique operates on each day's GUI build and performs functional reference testing of the newly integrated version of the GUI, using the previously tested version as a baseline. Comprehensive Testing is the outermost third technique conducts detailed comprehensive GUI integration testing of a major GUI release and it is executed after a major version of GUI is available. Problems are reported to all the developers who are part of the development of the particular version.flaws that persist across multiple versions GUI-based OSS are detected by this approach fully automatically. It provides feedback. The limitation is that the interactions between the three loops are not defined.4.3. Continuously Evolving GUI-Based Software ApplicationsQing Xie and Atif M. Memon [9], developed a quality assurance mechanism to manage the quality of continuously evolving software by Presenting a new type of GUI testing, called crash testing to help rapidly test the GUI as it evolves. Two levels of crash testing is being described: immediate feedback-based crash testing in which a developer indicates that a GUI bug was fixed in response to a previously reported crash; only the select crash test cases are re run and the developer is notified of the results in a matter of seconds. If any code changes occur, new crash test cases are generated and executed on the GUI. Test cases are generated that can be generated and executed quickly and cover all GUI functionalities. Once EIG is obtained, a boolean flag is associated with each edge in the graph. During crash testing, once test cases that cover that particular edge are generated, then the flag is set. If any changes occur, boolean flag for each edge is retained. Test cases are executed and crashes during test execution are used to identify serious problems in the software. The crash testing process is shown in Figure 4. The effectiveness of crash test is known by the total number of test cases used to detect maximum faults. Significantly, test suite size has no impact on number of bugs revealed.This crash testing technique is used to maintain the quality of the GUI application and it also helps in rapidly testing the application. The drawbacks are, this technique is used for only testing GUI application and cannot used in web applications, Fault injection or seeding technique, which is used to evaluate the efficiency of the method used is not applied here.Figure 4. Crash Testing Process4.4. Rapidly Evolving SoftwareAtif M. Memon et al [10], made several contributions in the area of GUI smoke testing in terms of GUI smoke test suites, their size, fault detection ability and test oracle. Daily Automated Regression Tester (DART) framework is used to automate GUI smoke testing. Developers work on the code during day time and DART automatically launches the Application Under Test (AUT) during night time, builds it and runs GUI smoke tests. Coverage and error report are mailed to developer. In DART all the process such as Analyzing the AUT’s GUI structure using GUI ripper, Test case generation, Test oracle generation, Test case executor, Examining theand test oracles are generated. Fault seeding is used to evaluate fault detection techniques used. An adequate number of faults of each fault type are seeded fairly.The disadvantages are Some part of code are missed by smoke tests, Some of the bugs reported by DART are false positive, Overall effectiveness of DART depends on GUI ripper capabilities, Not available for industry based application testing, Faults that are not manifested on the GUI will go undetected5. INCORPORATING EVENT CONTEXTXun Yuan et al [1], developed a new criterion for GUI testing. They used a combinatorial interaction testing technique. The main motivation of using combinatorial interaction is to incorporate context and it also considers event combinations, sequence length and include all possible event. Graph models are used and covering array is used to generate test cases which are the basis for combinatorial interaction testing.A tool called GUITAR (GUI Testing Framework) is used for testing and this provides functionalities like generate test cases, execute test cases, verify correctness and obtain coverage reports. Initially using GUI ripper, a GUI application is converted into event graph and then the events are grouped depending on functionality and constraints are identified. Covering array is generated and test sequences are produced. Test cases are generated and executed. Finally coverage is computed and a test adequacy criterion is analyzed.The advantages are: contexts are incorporated, detects more faults when compared to the previous techniques used. The disadvantages are infeasible test cases make some test cases unexecutable, grouping events and identifying constraints are not automated.Figure 5. Testing Process6. CONCLUSIONSIn this paper, some of the various test case generation methods and various types of GUI testing adapted for different GUI applications and techniques are studied. Different approaches are being used under various testing environment. This study helps to choose the test case generation technique based on the requirements of the testing and it also helps to choose the type of GUI test to perform based on the application type such as open source software, industrial software and the software in which changes are checked in rapidly and continuously.REFERENCES[1][2]Xun Yuan, Myra B. Cohen, Atif M. Memon, (2010) “GUI Interaction Testing: Incorporating Event Context”, IEEE Transactions on Software Engineering, vol. 99.A. M. Memon, M. E. Pollack, and M. L. Soffa, (2001) “Hierarchical GUI test case generation using automated planning”, IEEE Transactions on Software Engineering, Vol. 27, no. 2, pp. 144-155.X. Yuan and A. M. M emon, (2007) “Using GUI run-time state as feedback to generate test cases”, in International Conference on Software Engineering (ICSE), pp. 396-405.X. Yuan, M. Cohen, and A. M. Memon, (2007) “Covering array sampling of input event sequences for automated GUI testing”, in International Conference on Automated Software Engineering (ASE), pp. 405-408.X. Yuan, M. Cohen, and A. M. Memon, (2009) “Towards dynamic adaptive automated test generation for graphical user interfaces”, in First International Workshop on TESTing Techniques & Experimentation Benchmarks for Event-Driven Software (TESTBEDS), pp. 1-4.Si Huang, Myra Cohen, and Atif M. Memon, (2010) “Repairing GUI Test Suites Using a Genetic Algorithm, “in Proceedings of the 3rd IEEE InternationalConference on Software Testing Verification and Validation (ICST).P. Brooks, B. Robinson, and A. M. Memon, (2009) “An initial characterization of industrial graphical user interface systems”, in ICST 2009: Proceedings of the 2nd IEEE International Conference on Software Testing, Verification and Validation, Washington, DC, USA: IEEE Computer Society.Q. Xie, and A.M. Memon (2006) “Model-based testing of community driven open-source GUI applications”, in International Conference on Software Maintenance (ICSM), pp. 145-154.Q. Xie and A. M. Memon, (2005) “Rapid “crash testing” for continuously evolving GUI- based software applications”, in International Conference on Software Maintenance (ICSM), pp. 473-482.A. M. Memon and Q. Xie, (2005) “Studying the fault-detection effectiveness of GUI test cases for rapidly evolving software”, IEEE Transactions on Software Engineering, vol. 31, no. 10, pp. 884-896.U. Farooq, C. P. Lam, and H. Li, (2008) “Towards automated test sequence generation”, in Australian Software Engineering Conference, pp. 441-450.[3][4][5][6][7][8][9][10][11]研究基于GUI测试生成的测试用例摘要随着 WWW的出现和信息技术与软件开发的发展，软件测试成为一个主要问题。

软件测试1.Objective目的The objective of this document is to describe software testing for use with any software development project. The purpose is to provide a baseline for software testing activities. A standardized testing process is required because it improves the effectiveness and efficiency of testing for the project. It does so in several ways.本文档的目的是描述任何软件开发项目中的软件测试活动，目的是提供一个标准的测试活动基准。

标准化的测试流程是被需要的,因为它可以提高项目测试的效率和有效性。

∙Defines the testing process∙Makes the testing process repeatable∙Ensures high-risk components of the system are tested∙Lessens the effects of individual differences (tester background and skill set) on testing∙Adds “intelligence” to testing∙Provides metrics for managing and controlling testing∙Provides metrics for assessing and improving testing∙Provides a basis for test automation∙Produces specific testing deliverable∙定义测试过程∙确保测试过程可重复∙确保系统中高风险的组件得到测试∙缩小测试中由于测试人员的背景和技能的不同产生的影响∙增加“intelligence”去测试∙为管理和控制测试提供度量∙为评估和改进测试提供度量∙提供自动化测试的基础∙产出具体的测试交付物2.What is Software Testing?什么是软件测试？The goal of the testing activity is to find as many errors as possible before the user of the software finds them. We can use testing to determine whether a program component meets its requirements.测试活动的目标是在软件的真正用户使用前尽可能的发现更多的错误，我们使用测试去确定一个程序组件是否满足它的需求。