軟件測(cè)試中英對(duì)照實(shí)例

1、A Day in the Life of a Quality Assurance Tester質(zhì)量保障測(cè)試人員的一天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

2、 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.這篇文將討論測(cè)試人員日常工作，及怎樣將質(zhì)量灌輸?shù)杰浖?。我們將先討論什么是軟件測(cè)試，什么是質(zhì)量保障，它們之間如何關(guān)聯(lián)？軟件測(cè)試和

3、質(zhì)量保障涉及到哪些日常工作，有哪些問(wèn)題點(diǎn)和領(lǐng)域可改善，以及作為一個(gè)測(cè)試者，如何在任何軟件開發(fā)生命周期中，都能對(duì)開發(fā)過(guò)程提供價(jià)值呢。What is Software Testing?什么是軟件測(cè)試？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. Wh

4、ile 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 Softw

5、are 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.軟件測(cè)試是分析者用來(lái)發(fā)

6、現(xiàn)軟件缺陷的有組織的過(guò)程。你可能會(huì)問(wèn)，什么是缺陷？缺陷是代碼中導(dǎo)致軟件應(yīng)用中斷的問(wèn)題。沒(méi)有任何軟件是完全無(wú)缺陷的，測(cè)試者的目標(biāo)是減少在項(xiàng)目中找到的缺陷，并且將質(zhì)量灌輸?shù)杰浖?yīng)用中。軟件測(cè)試包括檢驗(yàn)軟件不能滿足用戶需求規(guī)格說(shuō)明中描述的需求及不能滿足用戶所需的過(guò)程。軟件測(cè)試者通過(guò)分析軟件來(lái)獲知軟件是否符合用戶的期望。軟件測(cè)試是一種設(shè)計(jì)來(lái)適當(dāng)保障軟件符合用戶所需質(zhì)量的活動(dòng)。What is Quality Assurance?什么是質(zhì)量保障？Quality Assurance is the sum of all the activities designed to adequately assure

7、that all the software processes in place have been done in an effective and efficacious manner. It involves both doing testingright and doing the right testing. Software Quality Assurance checks that the software processes are correct and are in compliance with the standards that operate within an o

8、rganization. Quality Assurance involves more than software testing and yet software testing is necessary to the Quality Assurance profession. Without it, one cannot say that a Quality Assurance process is in place.How do the two relate to each other?質(zhì)量保障是恰當(dāng)?shù)拇_保軟件過(guò)程在有效的方式下，被有條不紊地被執(zhí)行的所有活動(dòng)的匯總。它涉及到正確的做測(cè)試

9、和做正確的測(cè)試。軟件質(zhì)量保障檢查軟件過(guò)程是否正確且符合組織內(nèi)部運(yùn)作的標(biāo)準(zhǔn)。質(zhì)量保障涉及到軟件測(cè)試外更多的內(nèi)容，但軟件測(cè)試依然是質(zhì)量保障專業(yè)需要的內(nèi)容。缺了它，就不能稱保證質(zhì)量保障過(guò)程是正確妥當(dāng)?shù)摹Ｋ鼈冎g如何互相關(guān)聯(lián)呢？As you can see, Software Testing is just one aspect of Software Quality Assurance. Software Testing is usually called Quality Control. QC is a component of a QA plan in an organization. In s

10、ome organizations, the Software Testing role is split from the Software Quality Assurance Analyst role. In such an organization, Software Quality Assurance involves completion of technical checklists and document reviews to verify that both the software and documents are in compliance with standards

11、.就如你看到的，軟件測(cè)試只是軟件質(zhì)量保障的一個(gè)方面。軟件測(cè)試通常被稱作為質(zhì)量控制。在組織中，質(zhì)量控制是質(zhì)量保障計(jì)劃中的一個(gè)組件。在一些組織中，軟件測(cè)試角色從質(zhì)量保障分析師角色中被剝離出來(lái)。在這樣的組織中，軟件質(zhì)量保障涉及到完成技術(shù)檢查列表和文檔評(píng)審以檢驗(yàn)軟件和文檔均能符合標(biāo)準(zhǔn)。Daily Tasks Involved in Software Testing and Quality Assurance 軟件測(cè)試和質(zhì)量保障的日常任務(wù)Once a Software Requirements Specification (SRS document is produced, the tester “te

12、sts” the document to make sure that therequirements are complete, correct, consistent, and testable. In an agile environment, software requirements are tested as they are written. In a Waterfall SDLC, first the SRS is written and then testing the document occurs. On the topic of completeness, correc

13、tness, consistency, and testability: completeness is measured by whether or not the requirement tells you where to test, how to test, and what to test. Correctness implies that you know something about the application being tested. You have to know a little bit about the software to know if the requ

14、irement is correct.A consistent requirement is one that has no logical flaws. A testable requirement is one for which you can write a test case.軟件需求規(guī)范一旦被產(chǎn)出，測(cè)試人員就“測(cè)試”文檔確認(rèn)需求是否完整、正確、一致，和可被測(cè)試。在一個(gè)敏捷的環(huán)境中，軟件需求一旦編寫出來(lái)就會(huì)被測(cè)試。在瀑布式的軟件開發(fā)生命周期中，軟件需求規(guī)范先被編寫出來(lái)，然后測(cè)試它的完整性、正確性、一致性和可測(cè)試性。完整性通過(guò)需求是否能告訴你在哪里測(cè)試、如何測(cè)試及要測(cè)試什么來(lái)衡量。正確

15、性意味著你知道要測(cè)試的應(yīng)用的一些方方面面。你必須對(duì)你要測(cè)試的軟件有些了解，才能知道需求是否正確。一致性是指需求中不存在邏輯缺陷。可測(cè)試的需求是指一份你可以為它編寫測(cè)試案例的需求。Before or after the requirements review, a Master Test Plan is written which includes an Introduction, Background, Scope, Acronyms, Definitions, Features to be Tested, Features not to be Tested, Constraints, Ass

16、umptions, Risks and Contingencies, Schedules, Roles/Responsibilities, and References. The Master Test Plan is used by the test team to determine how long testing will take. Also, the tester uses the MTP as a testing plan. The Introduction, Background, Scope, Acronyms, Definitions, and References are

17、 preliminary sections in the test plan. They outline the background of the project, the intended audience and exactly what the project definition is-what it includes and what it does not include. The Acronyms outline the abbreviations used in the test plan and theDefinitions section defines any new

18、terms that may be used in the test plan. The References section lists the documents used to create the test plan. Typically, they refer to the SRS and the Software DesignDocuments. The “Features to be tested” section includes the list of all the functional requirements, performance requirements, usa

19、bility requirements, and security requirements that will be tested in the software. The “Features not to be tested” section includes any features that will be excluded from the testing. The Constraints and Assumptions section identifies those factors that will impact the project and the software tes

20、ting effort as well as any underlying beliefs that are held regarding the project. Constraints also represent the limitations of the software project. In the Risks and Contingencies section, all the risks along with contingency plans and mitigation strategies arepresented. No one likes to discuss ri

21、sks but that should be one of the first issues discussed and planned for when formalizing the project plan. Risk analysis is one way to mitigate the risks inherent in software development. Risk analysis is a systematic process that weighs and prioritizes risks of each requirement. The Schedules sect

22、ion discusses the timeline for all the testing activities to take place. TheRoles/Responsibilities section outlines who is responsible for what deliverable. The last section is the Appendix section. These sections are not usually in the order I have presented them in but this listing does include th

23、e major pieces of a Master Test Plan.在需求評(píng)審之前或之后，一個(gè)主測(cè)試計(jì)劃會(huì)被編寫，包括介紹、背景、范圍、縮略語(yǔ)、定義、將被測(cè)試的特性、不被測(cè)試的特性、約束、假設(shè)、風(fēng)險(xiǎn)和意外、日程表、角色/責(zé)任、和參考。主測(cè)試計(jì)劃被測(cè)試團(tuán)隊(duì)用來(lái)決定測(cè)試工作將被執(zhí)行多長(zhǎng)時(shí)間。測(cè)試人員也使用主測(cè)試計(jì)劃作為測(cè)試計(jì)劃。介紹、背景、范圍、術(shù)語(yǔ)、定義和參考是測(cè)試計(jì)劃的前序。它們簡(jiǎn)述項(xiàng)目的背景，預(yù)期的讀者是誰(shuí)及項(xiàng)目的確切定義是什么（包括哪些內(nèi)容和不包括哪些內(nèi)容）。縮略語(yǔ)簡(jiǎn)要描述了測(cè)試計(jì)劃中使用到的縮寫。定義章節(jié)定義了在測(cè)試計(jì)劃中使用到的新術(shù)語(yǔ)。參考章節(jié)列出了建立測(cè)試計(jì)劃用到的文檔資料。典

24、型情況，測(cè)試計(jì)劃引用了軟件需求規(guī)格和軟件設(shè)計(jì)文檔?！皩⒈粶y(cè)試的特性”章節(jié)包括所有軟件需測(cè)試的功能特性的列表、性能需求、可用性需求、和安全需求?！安槐粶y(cè)試的特性”章節(jié)包括不會(huì)被測(cè)試的特性。約束和假設(shè)章節(jié)鑒定出有那些會(huì)影響到項(xiàng)目和軟件測(cè)試的因素，也包括任何項(xiàng)目所持有的基本信念。約束也表述了軟件項(xiàng)目所受的限制。在風(fēng)險(xiǎn)和意外章節(jié)，所有的風(fēng)險(xiǎn)和意外處理計(jì)劃及緩解策略一起被表述。沒(méi)有人喜歡討論風(fēng)險(xiǎn)，但是這應(yīng)該是在規(guī)范項(xiàng)目計(jì)劃時(shí)，最先的被討論的問(wèn)題之一。風(fēng)險(xiǎn)分析是緩解軟件開發(fā)固有的風(fēng)險(xiǎn)的方法之一。風(fēng)險(xiǎn)分析是處理每個(gè)需求涉及到的風(fēng)險(xiǎn)的重要性和優(yōu)先級(jí)的一個(gè)系統(tǒng)過(guò)程。日程表章節(jié)討論測(cè)試活動(dòng)發(fā)生的時(shí)間。角色/責(zé)任章

25、節(jié)簡(jiǎn)述了誰(shuí)負(fù)責(zé)交付什么。最后的一個(gè)章節(jié)是附錄章節(jié)。章節(jié)之間通常并不是按照我所描述的順序，但列出的內(nèi)容已經(jīng)包括了主測(cè)試計(jì)劃的最主要的那些部分。After the review of the SRS is done, the tester then begins writing either test cases or use cases from the SRS. Use cases document how the system interacts with various actors while test cases are much more specific. Depending on

26、 the approach, a test case or use case document is produced. Lets assume the tester writes test cases. In the test case document, the tester will generally put the description, test steps, expected results, actual results, the pass/fail results, and screen shots. The screen shots are a necessary add

27、ition after the testing has started to show evidence that a test case has passed. The test steps are also known as the test script. For the sake of simplicity, lets assume a manual testing approach right now. Later, the discussion will turn to automated testing.在需求評(píng)審結(jié)束后，測(cè)試人員開始依照軟件需求規(guī)格寫測(cè)試案例或用例。用例記錄系統(tǒng)

28、如何和多種角色進(jìn)行交互，而測(cè)試案例的編寫更加具體得多。依照使用的方法，一個(gè)測(cè)試案例或者用例文檔被產(chǎn)出。我們假設(shè)測(cè)試人員編寫測(cè)試案例。在測(cè)試案例文檔中，測(cè)試者通常要放入描述、測(cè)試步驟、期望的結(jié)果、實(shí)際結(jié)果、通過(guò)/失敗結(jié)果和屏幕截圖。在測(cè)試已經(jīng)開始以后，屏幕截圖是一個(gè)用于證明測(cè)試已通過(guò)的必要附件。測(cè)試步驟通常也叫做測(cè)試腳本。為了簡(jiǎn)化問(wèn)題的描述，這里我們假設(shè)采用的是手工測(cè)試的方法。遲一些，我們會(huì)轉(zhuǎn)向自動(dòng)化測(cè)試的討論。The test case document along with the Master Test Plan is then submitted for review as part o

29、f the formal review of the work product. Revisions are made based on the outcome of the review. At the review meeting, all the stakeholders are present including the requirements analyst, developers, the testers, project manager, and if there is a separate person performing an SQA Analyst role, then

30、 he/she is also asked to the review. Each page is discussed to see if any changes need to be made or any points need to be clarified. Once the issues are noted, the tester revises the Master Test Plan and the test cases based on the formal review. Issues are tracked to closure and a decision is made

31、 to haveanother meeting to approve the work product or handle the review of the work product through email.接下來(lái)，作為工作成果中正式評(píng)審的一部分，測(cè)試案例文檔和主測(cè)試計(jì)劃一起被提交評(píng)審?；谠u(píng)審產(chǎn)生修訂后的版本。所有的關(guān)系人需出席評(píng)審會(huì)議，包括需求分析師、開發(fā)人員、測(cè)試人員、項(xiàng)目經(jīng)理。如果有一個(gè)獨(dú)立的執(zhí)行軟件質(zhì)量保障的分析師角色，他（她）也被要求參加評(píng)審。討論每一頁(yè)的文檔，找到是否需要作出一些修改，或需要闡明一些問(wèn)題。一旦問(wèn)題被記下來(lái)，測(cè)試人員基于正式評(píng)審來(lái)修訂主測(cè)試計(jì)劃和測(cè)試案例。問(wèn)題

32、將被跟蹤直到被關(guān)閉，并通過(guò)其它批準(zhǔn)工作產(chǎn)出的會(huì)議制定決策，或者通過(guò)email 處理工作產(chǎn)出評(píng)審。 The tester must also produce a Traceability Matrix which ties the Software Requirements Specifications to the Software Design Document and to the Test Case document. There should be at least a one to one mapping or a one to many mapping of requirement

33、s to test cases. In some firms, a QA Analyst/Tester must also review the Software Design Document making sure that every requirement is accounted for in the SDD. In this way, a tester can adequately assure that every test case is traceable to a requirement and every requirement is traceable to a sof

34、tware routine, option, or menu. Traceability is a key quality attribute of a software testing process.測(cè)試人員還需要產(chǎn)出一個(gè)綁定軟件需求規(guī)格到軟件設(shè)計(jì)文檔和測(cè)試案例文檔的跟蹤矩陣。在需求和測(cè)試案例之間最少需要建立一對(duì)一或者一對(duì)多的映射。在一些公司，質(zhì)量保障分析員/測(cè)試人員還需要評(píng)審軟件設(shè)計(jì)文檔，確認(rèn)每一個(gè)需求都已經(jīng)在軟件設(shè)計(jì)文檔中進(jìn)行了說(shuō)明。用這種方法，測(cè)試人員能完全確認(rèn)每一個(gè)測(cè)試案例可以跟蹤到一個(gè)需求，及每一個(gè)需求可以跟蹤到一個(gè)軟件程序、選項(xiàng)，或者菜單。可跟蹤性是一個(gè)軟件測(cè)試過(guò)程里的關(guān)鍵質(zhì)量

35、屬性。 After development of the code is completed and the build is delivered to the testers then the actual testing begins. Each test case is executed against the application and pass/fail results are recorded. Screen shots are taken as well. Any defects are recorded using a defect tracking tool such a

36、s Rational ClearQuest, Mercury Quality Center, or another defect tracking tool. There should be a process in place for defect tracking and defect resolution. Typically, when the tester writes up a defect in a defect tracking tool, the points to include are the stage of testing, subject, description

37、of the problem, the steps to repeat, and a screen shot if possible. The description of the problem should be recorded as what is the issue that needs to be corrected and where the error is rather than a recording of what is simply left out since no one would be able to determine whether that is a pr

38、oblem. I have seenSharePoint sites used for defect tracking. When such a site is used, it should include the stage of testing that the defect was found. Even when using Rational ClearQuest or Mercury Quality Center, the stage of testing should be noted depending on the type of SDLC that is in presen

39、t in the organization.在代碼的開發(fā)完成且構(gòu)建分發(fā)到測(cè)試人員手中時(shí)，實(shí)際的測(cè)試開始了。針對(duì)應(yīng)用執(zhí)行每一個(gè)測(cè)試案例，成功/失敗結(jié)果被記錄下來(lái)。同時(shí)，用屏幕截圖截取結(jié)果 。 任何缺陷都被用缺陷跟蹤工具（例如Rational ClearQuest 、Mercury Quality Center或其他缺陷跟蹤工具）記錄下來(lái)。缺陷跟蹤和缺陷解決需要有一個(gè)適當(dāng)?shù)倪^(guò)程。典型情況下，當(dāng)測(cè)試人員在測(cè)試跟蹤工具中記錄一個(gè)缺陷，如果可能要包括測(cè)試的階段、主題、問(wèn)題的描述、重復(fù)的步驟及屏幕截圖。問(wèn)題的描述需要記錄需要修正的錯(cuò)誤是什么和錯(cuò)誤在什么地方，而不是一條討論的記錄，因?yàn)闆](méi)人能去確定那是否一個(gè)

40、問(wèn)題。我曾看到SharePoint 站點(diǎn)被用來(lái)做缺陷跟蹤。當(dāng)這樣的一個(gè)站點(diǎn)被使用，當(dāng)缺陷被發(fā)現(xiàn)時(shí)，需要記錄測(cè)試的階段。甚至當(dāng)你使用Rational ClearQuest和Mercury Quality Center，也要根據(jù)組織中使用的軟件生命周期的類型來(lái)確定是否記錄測(cè)試的階段。Depending on the severity of the defects, a new build is created to correct the defects found. The tester retests the defect to make sure it is fixed and then d

41、oes a light regression around that area of functionality to make sure nothing else has broken. Once the tester notifies the team that internal testing is done, then depending on the SDLC, the code is released into production or handed off to the test sites, if any for field testing. If the test site

42、s find defects they are reported to the development team and a new build is released which will then have to go through internal testing before being released to the test sites again. Defects are recorded as before.根據(jù)缺陷的嚴(yán)重性，需要修正找到的缺陷，并為此建立一個(gè)新構(gòu)建。測(cè)試人員重新測(cè)試缺陷來(lái)確認(rèn)它已經(jīng)被修正，然后在缺陷的功能區(qū)域執(zhí)行一個(gè)輕量的回歸測(cè)試，確認(rèn)沒(méi)有其它問(wèn)題被引發(fā)。一

43、旦測(cè)試人員通知團(tuán)隊(duì)內(nèi)容測(cè)試已經(jīng)完成，依賴于軟件開發(fā)生命周期，代碼被作為產(chǎn)品發(fā)布，或根據(jù)需要發(fā)布到測(cè)試網(wǎng)站上做現(xiàn)場(chǎng)測(cè)試。如果測(cè)試網(wǎng)站發(fā)現(xiàn)有缺陷，將缺陷報(bào)告給開發(fā)團(tuán)隊(duì)，新的構(gòu)建將被發(fā)布，然后先經(jīng)過(guò)內(nèi)部測(cè)試，再發(fā)布到測(cè)試網(wǎng)站。缺陷像以前一樣被記錄下來(lái)。Automated Testing自動(dòng)化測(cè)試In automated testing, instead of a Master Test Plan or a along with one, an Automation Test Plan is written that will outline exactly how the automation wi

44、ll proceed and the approach taken. Once that is written, the creation of the automated test scripts begins and corresponds with the requirements written in the SRS o r RSD Requirement Specification Document. After a build is delivered, the test scripts are run against the application to see what has

45、 broken. If it is a true defect, then the defect is written up using the same tools as in manual testing. Depending on the number and severity of changes, a new build is delivered and the automated test scripts are run again against the application. Once the tester has found no defects, he/she can r

46、eport that testing is completed and the build is put into production.在自動(dòng)化測(cè)試中，一份自化測(cè)試計(jì)劃被編寫出來(lái)，用于概述自動(dòng)化將如何執(zhí)行及被選中的測(cè)試方法。它可能是被用來(lái)完全替代主測(cè)試計(jì)劃，又或者僅和主測(cè)試計(jì)劃一起被編寫。一旦文檔被編寫后，自動(dòng)化測(cè)試腳本開始對(duì)應(yīng)軟件需求規(guī)格和需求研究文檔中的需求進(jìn)行編寫。在構(gòu)建被分發(fā)后，測(cè)試腳本針對(duì)應(yīng)用運(yùn)行來(lái)檢查是否存在問(wèn)題。如果確實(shí)是一個(gè)缺陷，那么缺陷被用和手工測(cè)試一樣的工具記錄下來(lái)。依賴修改的數(shù)量和嚴(yán)重程度，一個(gè)新的構(gòu)建被分發(fā)，并再次針對(duì)應(yīng)用運(yùn)行自動(dòng)化測(cè)試腳本。一旦測(cè)試人員發(fā)現(xiàn)已經(jīng)不存在

47、缺陷，他/她可以報(bào)告測(cè)試已經(jīng)結(jié)束，構(gòu)建已經(jīng)可以成為產(chǎn)品。Pain Points and Areas for Improvement可改善的問(wèn)題點(diǎn)和領(lǐng)域1. Building trust in the SQA Tester I had a development manager tell me once that it takes a long time for a project manager to be trustful of a tester. Fortunately, that particular situation worked in my favor but it can be

48、hard for the development team to trust that the tester is going to perform due diligence on the testing project. That is, that he/she will find out and uncover everything there is to know about the project and the coding that can help him or her test the application thoroughly. Often times, this can

49、 be overcome with increasedcommunication and explanation to the project manager and developers the reasoning behind why particular actions are taken.1.建立對(duì)軟件質(zhì)量保障測(cè)試人員的信任 我的一個(gè)開發(fā)經(jīng)理有一次告訴我，項(xiàng)目經(jīng)理需要很長(zhǎng)時(shí)間才會(huì)信任測(cè)試人員。幸運(yùn)的是，我碰到了這種特別的情況。但是讓開發(fā)團(tuán)隊(duì)信任測(cè)試人員將會(huì)盡職盡責(zé)去執(zhí)行工作有可能是困難的。那意味著，他/她將找出或揭露所有關(guān)于項(xiàng)目相關(guān)的事和可以幫助他或她完全測(cè)試項(xiàng)目的編碼。很多時(shí)候，通過(guò)

50、增加交流，并向項(xiàng)目經(jīng)理和開發(fā)者解釋為何要執(zhí)行這些特別的活動(dòng)，這個(gè)問(wèn)題可以被克服。2. Developers who do not believe in the value of Software Testing and Quality Assurance Many times, testers are faced with a situation in which they are constantly butting heads with the developers. Usually, this comes from an antiquated belief that testers do

51、 not know what they are talking about or that anyone can test. However, testing is a skill and it takes years to finely perfect the craft of testing software. Sometimes, the only recourse a tester has is to take the issue up with a much more senior tester who has the position and the backing to tell

52、 the developer to look at the testers findings.2.開發(fā)人員不相信軟件測(cè)試和質(zhì)量保障的價(jià)值 測(cè)試人員會(huì)經(jīng)常面對(duì)著和開發(fā)人員沖突的情形。 通常來(lái)說(shuō)，這來(lái)自一種已過(guò)時(shí)的想法，測(cè)試人員并不知道開發(fā)人員所做的事或者沒(méi)有人能測(cè)試系統(tǒng)。可事實(shí)是，測(cè)試是一種技能，而且人們花費(fèi)了很多年來(lái)完善測(cè)試軟件產(chǎn)品。有些時(shí)候，測(cè)試人員只有依賴于讓一個(gè)有地位和背景，更資深測(cè)試人員去告訴開發(fā)人員，讓他們?nèi)タ礈y(cè)試人員發(fā)現(xiàn)的問(wèn)題。3. Inadequate amount of time to test sometimes there just isnt enough time wit

53、hin the project schedule to adequately test thesoftware. A way to circumvent this issue is to test the requirements as they are written and build the test cases while the requirements are being written. The other thing to do here is to have people who can adequately scope out a project and the deliv

54、erable dates. Also, regular meetings with staff help to identify the status of key personnel in the software development project.3.測(cè)試時(shí)間不足 很多時(shí)候，僅僅是項(xiàng)目計(jì)劃中沒(méi)有足夠的時(shí)間進(jìn)行充分的測(cè)試。一個(gè)解決這個(gè)問(wèn)題的辦法是在需求被編寫時(shí)就同時(shí)測(cè)試它，并在需求被編寫時(shí)，就構(gòu)建測(cè)試案例。另外要做的事是找一個(gè)能夠評(píng)估項(xiàng)目和分發(fā)日期的人。另外，在軟件開發(fā)項(xiàng)目中，人員常規(guī)例會(huì)有助于鑒別出關(guān)鍵人物。4. Poorly written requirements sometim

55、es the requirements are incorrectly captured and need to be revised as the software development project proceeds. This situation is costly to the organization as well as the test team in terms of both money and time. This situation could lead to scope creep in which the delivered code exceeds what h

56、as been written in the requirements. There is no real workaround for thisissue. The best thing to do is nip it in the bud when you see scope creep happening. One way to do this is to make a solid decision beforehand to gain user signoff on the SRS so that scope creep doesnt happen. An other way to n

57、ip it in the bud is to have a change control board in place that approves SRS changes. The change control board then becomes responsible for cost overruns. This avoids the project manager being blamed for scope creep.4.糟糕的需求撰寫 - 有時(shí)候，需求沒(méi)有被正確的捕捉，并在軟件開發(fā)項(xiàng)目過(guò)程中需要修訂。這種情形對(duì)于組織和測(cè)試團(tuán)隊(duì)的錢和時(shí)間都會(huì)有耗費(fèi)。這種情形會(huì)導(dǎo)致范圍漸增（Scop

58、e Creep），從而使分發(fā)的代碼超過(guò)需求中所編寫的內(nèi)容。對(duì)此問(wèn)題，并沒(méi)有一種真正的解決方案。最好的方法是當(dāng)發(fā)現(xiàn)范圍漸增發(fā)生時(shí)就即時(shí)制止。一個(gè)方法是通過(guò)獲得用戶在軟件需求規(guī)格上的簽字，預(yù)先使得決策變得穩(wěn)定，這樣范圍漸增就不會(huì)發(fā)生。另外一個(gè)制止它的辦法是，有一個(gè)變更控制委員來(lái)批準(zhǔn)軟件需求規(guī)格變更。改由變更控制委員來(lái)對(duì)費(fèi)用超支負(fù)責(zé)。這避免了項(xiàng)目經(jīng)理由于范圍漸增而遭責(zé)難。5. Not enough testing resources This issue is a situation for upper management to handle. When there are not enough

59、testing resources, it affects the schedule and could lead to burnout of the few testers that are there to test the product.5.沒(méi)有足夠的測(cè)試資源 這個(gè)問(wèn)題是需要高層去處理的情形。當(dāng)沒(méi)有足夠的測(cè)試資源，它會(huì)影響到時(shí)間表，并且會(huì)導(dǎo)致那些過(guò)少的測(cè)試項(xiàng)目的測(cè)試人員們筋疲力盡。6. Not enough training for testers This situation could lead to testers not understanding the software under test. It affects both time required to test and the money involved in the testing effort.6.測(cè)試人員沒(méi)有足夠的培訓(xùn) 這種情形會(huì)導(dǎo)致測(cè)試