1.需求層次

在軟件開發(fā)過程中，需求一般有三個(gè)層次，第一層是用戶有個(gè)想法、困難或者痛點(diǎn)，稱作為用戶需求；基于用戶需求進(jìn)行可行性分析和價(jià)值分析后，在眾多解決用戶需求的方案，選擇一條最優(yōu)解方案，稱之為業(yè)務(wù)需求，基于業(yè)務(wù)需求進(jìn)行分解形成可實(shí)現(xiàn)的系統(tǒng)模塊或者功能，稱之為系統(tǒng)需求。

1)用戶需求

用戶需求是需要重復(fù)考慮，客戶的痛點(diǎn)在什么地方，想要解決什么問題，達(dá)成什么目的，這部分內(nèi)容很多時(shí)候比較隱晦或者用戶自己也很難定義清楚。

比如用戶的需求可能是一架更快的馬車。

比如用戶需求可能是想過河，但表述時(shí)可能是希望能夠有一座橋。

所以對(duì)于業(yè)務(wù)需求一般需要專業(yè)人士，進(jìn)行大量訪談跟蹤，最好以試圖的形式描述業(yè)務(wù)的現(xiàn)狀和期望解決的問題。所以用戶需求一定要了解與商業(yè)目的或者管理目的，了解客戶最后的動(dòng)機(jī)。

2)業(yè)務(wù)需求

業(yè)務(wù)產(chǎn)品經(jīng)理或者業(yè)務(wù)專家，通過對(duì)用戶需求分析提取，價(jià)值分析。梳理出有什么角色(Who)，在什么條件下(When)，在什么地方或者那個(gè)功能入口(Where)，愿意花多少錢來完成，使用什么功能的什么操作(What)來達(dá)成業(yè)務(wù)目標(biāo)。

比如用戶需求是需要一架更快的馬車。

業(yè)務(wù)需求階段可以給出的方案可能是：四駕馬拉的馬車(原來是一匹馬)，自行車，摩托車、汽車、火車、飛機(jī)等等，但通過對(duì)用戶需求價(jià)值分析，通過對(duì)角色能力判斷，確定一個(gè)摩托車的需求是滿足他的需求。一輛摩托車就是根據(jù)用戶需求分析出來的業(yè)務(wù)需求。

這部分實(shí)際上是需求規(guī)格說明書或者產(chǎn)品規(guī)格說明書的內(nèi)容，這部分包含功能出發(fā)的入口，功能說明，功能使用約束的事件，以及執(zhí)行完成后的響應(yīng)及結(jié)果等。

3)系統(tǒng)需求

系統(tǒng)需求或者叫軟件需求，是實(shí)現(xiàn)業(yè)務(wù)需求，實(shí)際上是業(yè)務(wù)需求規(guī)格說明說的主要內(nèi)容，業(yè)務(wù)需求分解為各個(gè)模塊或子系統(tǒng)的那些功能，包含功能的主流程和備選流程，數(shù)據(jù)對(duì)象和接口的結(jié)構(gòu)等。系統(tǒng)需求是根據(jù)業(yè)務(wù)需求的落地實(shí)踐。

比如業(yè)務(wù)需求需要一輛摩托車，系統(tǒng)需求就可以將業(yè)務(wù)需求通過分解成：

一個(gè)扶手方向盤

兩個(gè)輪子

一個(gè)車架

一套剎車系統(tǒng)

這樣就可以實(shí)現(xiàn)一輛摩托車。

2.不同層次需求的測(cè)試關(guān)注點(diǎn)不盡相同

基于以上需求分層，測(cè)試工程師應(yīng)該針對(duì)不同層次的需求采用不同的測(cè)試方法。

如在系統(tǒng)開發(fā)階段，開發(fā)出來的是一個(gè)個(gè)模塊或者子系統(tǒng)，測(cè)試應(yīng)該解決的是單個(gè)模塊的功能是否滿足需求，需要考慮本模塊的核心功能和本模塊中的各種異常情況，包含異常場(chǎng)景中的異常流和備選流，也包含各種異常數(shù)據(jù)導(dǎo)致系統(tǒng)的潛在風(fēng)險(xiǎn)的功能，如某個(gè)功能某個(gè)項(xiàng)的輸入情況(默認(rèn)、為空、超長、不符合業(yè)務(wù)規(guī)則和約束等)。

對(duì)于集成階段，需要考慮的是，即時(shí)每一個(gè)模塊都正常，整體業(yè)務(wù)是否可用，是否滿足業(yè)務(wù)需求，比如上面的例子提到的摩托車這個(gè)產(chǎn)品，在集成階段需要考慮的是，每一個(gè)組件都可用(方向盤、車架、輪子、剎車)，但組合在一起是否能夠跑起來？是否按照業(yè)務(wù)需求的要求？更重要的是確保組裝起來后就是一個(gè)摩托車，而不是一個(gè)自行車。

而對(duì)于用戶驗(yàn)收階段，需要確保完成的產(chǎn)品或者系統(tǒng)是滿足用戶需求的，比如我們?cè)斐龅哪ν熊嚲褪潜锐R車跑的快，而且沒有用戶非常反感的能力。這一條在測(cè)試時(shí)其實(shí)很多時(shí)候都被我們忽略，比如某個(gè)業(yè)務(wù)需求，解決用戶的某個(gè)痛點(diǎn)；通過系統(tǒng)需求分解后，完成某項(xiàng)功能。在測(cè)試時(shí)更多的是關(guān)心該業(yè)務(wù)需求是否被實(shí)現(xiàn)，而沒有關(guān)心該業(yè)務(wù)需求是否解決用戶的痛點(diǎn)。導(dǎo)致很多業(yè)務(wù)需求上線后，通過數(shù)據(jù)分析沒有達(dá)到預(yù)期結(jié)果，是一個(gè)偽業(yè)務(wù)需求。

為了解決以上問題，測(cè)試工程師更應(yīng)該提前介入需求階段，了解用戶需求，基于用戶、業(yè)務(wù)需求需求進(jìn)行測(cè)試，檢驗(yàn)產(chǎn)品實(shí)現(xiàn)是否解決客戶的痛點(diǎn)，進(jìn)行基于業(yè)務(wù)場(chǎng)景的測(cè)試，而對(duì)于系統(tǒng)需求，則需要根據(jù)需求規(guī)格說明書或者產(chǎn)品規(guī)格說明書，按照驗(yàn)證在各種條件，輸入的組合情況下，操作的結(jié)果是否和需求描述的一致。

3.合適的測(cè)試策略

因?yàn)椴煌瑢哟蔚男枨?#xff0c;測(cè)試的關(guān)注點(diǎn)和側(cè)重點(diǎn)是不同的，所以需要針對(duì)不同層次需求或者階段采用不同的測(cè)試策略。測(cè)試策略是好的測(cè)試計(jì)劃的重要組成部分，是測(cè)試與任務(wù)聯(lián)系的橋梁。測(cè)試策略就是如何測(cè)試產(chǎn)品以及更快找出重要的問題？需要對(duì)那部分進(jìn)行特殊的測(cè)試？要運(yùn)用什么手段創(chuàng)建測(cè)試？當(dāng)程序錯(cuò)誤出現(xiàn)時(shí)如何識(shí)別？常見的測(cè)試策略有：

基于階段劃分的測(cè)試策略：如：單元測(cè)試、集成測(cè)試、用戶驗(yàn)收測(cè)試。

基于分層測(cè)試的策略模型，如：單元測(cè)試、服務(wù)接口測(cè)試、UI層測(cè)測(cè)試。

基于原型驗(yàn)證的測(cè)試策略，如：業(yè)務(wù)驗(yàn)證測(cè)試、灰度發(fā)布驗(yàn)證、AB測(cè)試驗(yàn)證。

以上只是簡單列舉，在實(shí)際測(cè)試過程中還會(huì)有各種測(cè)試策略在實(shí)際項(xiàng)目中的應(yīng)用。比如前段時(shí)間我們內(nèi)部有一個(gè)基于B端用戶的APP測(cè)試項(xiàng)目交接過來，該產(chǎn)品有近一年時(shí)間沒有迭代。交接過程中文檔缺失和人員斷檔的情況下，我們對(duì)新一輪App改版上線的策略是：

第一階段：核心功能走查,學(xué)習(xí)了解，確保核心功能正常，完成第一版高階用例梳理。

第二階段：業(yè)務(wù)測(cè)試階段，確保核心、輔助功能、基礎(chǔ)功能業(yè)務(wù)正常可用，可以流程的完成B端客戶的正常業(yè)務(wù)功能，在這個(gè)階段需要完成基本功能測(cè)試、兼容性測(cè)試、穩(wěn)定性測(cè)試、性能測(cè)試、網(wǎng)絡(luò)測(cè)試等等。

第三階段：回歸測(cè)試階段，從用戶視覺進(jìn)行測(cè)試大掃除，確保App正常發(fā)布。

測(cè)試策略是一個(gè)復(fù)雜活動(dòng)，一項(xiàng)測(cè)試任務(wù)是否能夠在以最小的成本，快速高效、高質(zhì)量完成，直接取決于測(cè)試策略是否科學(xué)規(guī)范。

——————— ?End??———————

視頻公開課

釘釘掃描下方海報(bào)進(jìn)入直播群即可！

如能幫到你，為我們點(diǎn)個(gè)在看哦?

總結(jié)

以上是生活随笔為你收集整理的visionmaster视觉软件说明书_测试策略与软件需求层次的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。