工作這么幾年來(lái)懂傀，見(jiàn)得最多的場(chǎng)景是QA小伙伴追著開(kāi)發(fā)滿(mǎn)辦公室報(bào)bug，不過(guò)有時(shí)候開(kāi)發(fā)卻不樂(lè)意了，當(dāng)時(shí)可沒(méi)說(shuō)要XXX笛粘，要做XXX外臂。
好像QA小伙伴永遠(yuǎn)比開(kāi)發(fā)多一點(diǎn)心眼，即使單元測(cè)試覆蓋率達(dá)到80%犀斋，QA還是變著法都能找出問(wèn)題贝乎。
這其中很大一部分原因都是因?yàn)椤靶枨蟊澈蟮男枨蟆痹斐傻模珺A叽粹、QA小伙伴以為你考慮到了览效，或者默認(rèn)開(kāi)發(fā)需要考慮的却舀。
比如CMS系統(tǒng)中一個(gè)新建文章的需求，不太可能寫(xiě)出需要防止表單二次提交的AC朽肥，然而如果沒(méi)人提出來(lái)誰(shuí)會(huì)知道呢禁筏？
最終QA或者線(xiàn)上的用戶(hù)會(huì)通過(guò)報(bào)bug告訴我們。
我們把這些隱藏到功能需求背后或BA默認(rèn)認(rèn)為開(kāi)發(fā)需要考慮的需求稱(chēng)為為非功能性需求衡招，有時(shí)候又叫跨功能需求篱昔。
下面就來(lái)說(shuō)說(shuō)在工作中常見(jiàn)的非功能性需求和怎么應(yīng)對(duì)。
交互體驗(yàn)相關(guān)
Loading 加載狀態(tài)是最容易被忽略的一個(gè)需求始腾，尤其是現(xiàn)在富客戶(hù)端開(kāi)發(fā)的模式下州刽，數(shù)據(jù)的獲取都是異步加載的。如果忘了考慮這條需求浪箭，在在網(wǎng)絡(luò)條件較好時(shí)會(huì)出現(xiàn)閃爍的情況穗椅，而在網(wǎng)絡(luò)情況差的條件下又看起來(lái)會(huì)卡頓和沒(méi)有響應(yīng)。實(shí)現(xiàn)統(tǒng)一的Loading可以在前端的網(wǎng)絡(luò)請(qǐng)求庫(kù)中增加攔截器奶栖，不過(guò)需要注意使用計(jì)數(shù)器讓多次網(wǎng)絡(luò)請(qǐng)求中途的Loading圖標(biāo)不會(huì)間斷匹表，否則會(huì)有閃爍的問(wèn)題。
表單的二次提交 有一些QA會(huì)使用極端的測(cè)試方法宣鄙，例如快速點(diǎn)擊按鈕多次袍镀，如果頁(yè)面沒(méi)有進(jìn)行處理，會(huì)觸發(fā)表單多次提交的問(wèn)題冻晤。即使后端API增加限制則可能同時(shí)出現(xiàn)成功和失敗的提示苇羡，會(huì)讓用戶(hù)感到更加迷惑。處理這個(gè)問(wèn)題有幾種途徑：
- 使用蒙層的Loading 就會(huì)自帶阻塞用戶(hù)的操作的效果鼻弧。
- 點(diǎn)擊后禁用表單事件或在程序中增加請(qǐng)求中的狀態(tài)设江。
- 依賴(lài)后端配置一次性表單令牌（通常用來(lái)防CRSF）
輸出格式化 需求中一般會(huì)告訴開(kāi)發(fā)怎么展示數(shù)據(jù)，但是往往忘記如何格式化數(shù)據(jù)攘轩。例如我們想讓數(shù)字使用千分位分隔或其他顯示方式讓數(shù)字閱讀不那么困難叉存；字符串溢出的處理截取方式；時(shí)間的格式化方法撑刺，有一些項(xiàng)目會(huì)使用“1小時(shí)前”鹉胖，“一天前”或者具體日期等更為人性化的顯示方式；圖片的輸出需要寬度進(jìn)行縮放够傍，如果是封面圖需要非拉伸截取等甫菠。
請(qǐng)求用戶(hù)確認(rèn)和提示 這兩項(xiàng)專(zhuān)業(yè)BA一般都會(huì)考慮到，也會(huì)通知UX設(shè)計(jì)對(duì)應(yīng)樣式冕屯。不過(guò)這里面的細(xì)節(jié)還是值得討論寂诱。
- 如果在一系列操作的中途提示用戶(hù)確認(rèn)，需要明確用戶(hù)點(diǎn)擊取消后安聘，應(yīng)該回退到用戶(hù)的哪一步操作狀態(tài)痰洒。有很多的APP在用戶(hù)編輯好數(shù)據(jù)后瓢棒，點(diǎn)擊提交然后系統(tǒng)提示是否繼續(xù)，如果用戶(hù)點(diǎn)擊取消丘喻，頁(yè)面上的數(shù)據(jù)會(huì)被清除脯宿。開(kāi)發(fā)需要和BA確認(rèn)好具體的交互以及提示文案。
- 成功和錯(cuò)誤的提示除了文案之外泉粉，和BA需要確認(rèn)的還有：是獨(dú)立的提示頁(yè)還是返回到來(lái)源頁(yè)面连霉？提示需要自動(dòng)關(guān)閉還是等待頁(yè)面刷新后關(guān)閉？用戶(hù)可以主動(dòng)點(diǎn)擊關(guān)閉嗎嗡靡？
交互體驗(yàn)這部分還有一個(gè)需求噩耗就是跺撼，保持統(tǒng)一！Ｌ直恕歉井！我想這個(gè)是交互體驗(yàn)上最為致命又不會(huì)寫(xiě)在需求中，但是QA往往能從中找到bug哈误。
安全相關(guān)
身份校驗(yàn)和權(quán)限 URL上資源可以被枚舉和請(qǐng)求的資源沒(méi)有驗(yàn)證用戶(hù)權(quán)限哩至，這屬于致命而低級(jí)的安全問(wèn)題，當(dāng)然BA會(huì)默認(rèn)開(kāi)發(fā)要去做這些蜜自。不過(guò)現(xiàn)實(shí)就是在一些遺留項(xiàng)目中這種例子太多了憨募，例如通過(guò)修改URL上的資源ID甚至userID此類(lèi)參數(shù)進(jìn)而修改其他用戶(hù)的數(shù)據(jù)。幾年前袁辈，可以發(fā)現(xiàn)很多此類(lèi)漏洞，甚至在我學(xué)生時(shí)期用某電信運(yùn)營(yíng)商的權(quán)限漏洞得手了不少付費(fèi)游戲珠漂。如果系統(tǒng)設(shè)計(jì)了權(quán)限管理模塊晚缩，在開(kāi)啟新功能時(shí)也應(yīng)該和BA確認(rèn)是否納入權(quán)限管理。
表單驗(yàn)證 用戶(hù)輸入的數(shù)據(jù)如何驗(yàn)證這部分也是經(jīng)常在需求上忘記體現(xiàn)出來(lái)的地方媳危，而且這部分QA特別容易給出Bug荞彼，數(shù)據(jù)驗(yàn)證充滿(mǎn)了大量的條件邊界。還有一個(gè)老生常談的問(wèn)題待笑，表單驗(yàn)證應(yīng)該服務(wù)器端還是前端做鸣皂？ 這很顯然，后端為了安全必做暮蹂，前端為了體驗(yàn)選做寞缝。
SQL注入和XSS攻擊 SQL注入這兩年隨著成熟的ORM框架普遍使用幾乎沒(méi)有了，但是XSS可以說(shuō)還是有很多仰泻。處理SQL注入和XSS攻擊的共同點(diǎn)是不要相信任何用戶(hù)的輸入荆陆、任何來(lái)源。在瀏覽器中用戶(hù)輸入不僅有表單還有URL集侯，而往往URL輸入?yún)?shù)很容易被數(shù)據(jù)校驗(yàn)忽略被啼。
文件上傳 文件上傳背后的需求有上傳文件的類(lèi)型帜消、大小限制；需要和BA確認(rèn)是否能批量上傳浓体，上傳前是否需要預(yù)覽泡挺；上傳后如何命名，是否需要在上傳過(guò)程中對(duì)圖片或視頻進(jìn)行壓縮命浴。這里的安全需求是娄猫，不應(yīng)該上傳可執(zhí)行文件；需要獲取文件真實(shí)后類(lèi)型信息而非后綴名咳促。文件上傳的一個(gè)陷阱就是使用了客戶(hù)端來(lái)源的文件名作為文件存儲(chǔ)的文件名稚新，這是極為不可靠的，在上傳后的文件系統(tǒng)中需要使用內(nèi)建的唯一命名跪腹，并通過(guò)數(shù)據(jù)庫(kù)來(lái)記錄用戶(hù)上傳的文件名褂删。
性能相關(guān)
響應(yīng)時(shí)間 說(shuō)實(shí)話(huà)，沒(méi)見(jiàn)過(guò)那張卡上有明確的指標(biāo)那些功能需要在多久之內(nèi)完成響應(yīng)冲茸。但是如果不在分析業(yè)務(wù)需求的階段提出來(lái)屯阀，響應(yīng)時(shí)間過(guò)長(zhǎng)肯定通不過(guò)QA測(cè)試。在需求分析階段的響應(yīng)時(shí)間包含了3個(gè)注意點(diǎn)：
- 系統(tǒng)性能設(shè)計(jì)要求轴术。對(duì)一般需求而言难衰，技術(shù)上應(yīng)該達(dá)到基本的性能指標(biāo)，當(dāng)然實(shí)現(xiàn)的方式不盡相同逗栽，例如優(yōu)化SQL盖袭、優(yōu)化靜態(tài)資源等。
- 該功能是否適合同步操作彼宠。然而有一些部分的需求是根本不適合使用同步的操作鳄虱，例如數(shù)據(jù)導(dǎo)入這類(lèi)耗時(shí)很長(zhǎng)的操作，服務(wù)器應(yīng)該接受用戶(hù)請(qǐng)求然后不斷返回任務(wù)處理的狀態(tài)凭峡，而不是讓用戶(hù)端等待完成拙已。實(shí)現(xiàn)上可以使用一些消息系統(tǒng)，例如JMS等摧冀。
- 第三方系統(tǒng)集成倍踪。如果和第三方系統(tǒng)集成，需要和資源提供方溝通是否需要增加批量的數(shù)據(jù)操作索昂，避免循環(huán)獲取數(shù)據(jù)建车。例如json API標(biāo)準(zhǔn)中提供了include方法聚合多個(gè)資源到一次請(qǐng)求中。另外調(diào)用方可以注意使用一些非阻塞的網(wǎng)絡(luò)請(qǐng)求方法楼镐，如RxJava或AsyncRestTemplate癞志。
實(shí)時(shí)消息通知 我們?cè)谧鲆恍╊?lèi)似站內(nèi)信、系統(tǒng)消息的功能時(shí)框产，有時(shí)候BA凄杯、QA容易默認(rèn)消息的狀態(tài)和數(shù)量（小紅點(diǎn)）應(yīng)該實(shí)時(shí)的顯示在頁(yè)面上错洁，并及時(shí)更新。但開(kāi)發(fā)小伙伴可能認(rèn)為web上的一些信息需要用戶(hù)刷新后可見(jiàn)戒突，這個(gè)很容易達(dá)成理解不一致屯碴。如果實(shí)時(shí)刷新作為需求確實(shí)需要的話(huà)，從技術(shù)上需要做一些調(diào)整才能實(shí)現(xiàn)膊存，比如使用輪詢(xún)导而、HTTP長(zhǎng)連接、websock等方法才能實(shí)現(xiàn)隔崎，這會(huì)帶來(lái)額外的工作量今艺。
游離數(shù)據(jù)管理 從事服務(wù)器開(kāi)發(fā)的小伙伴可能有這種體會(huì)，有一些數(shù)據(jù)一旦創(chuàng)建了爵卒，用戶(hù)或者管理員就沒(méi)法找到或者跟蹤了虚缎。比較明顯的例子有兩處：
- 新建資源處，異步上傳的圖片或者其他資源钓株。比如在用戶(hù)操作新建文章頁(yè)面实牡，這個(gè)時(shí)候文章表可能還沒(méi)有寫(xiě)入數(shù)據(jù)，但是需要允許用戶(hù)上傳一些封面或者其他圖片轴合。如果用戶(hù)體完成了整個(gè)操作创坞，圖片會(huì)和文章關(guān)聯(lián)，但是假如用戶(hù)放棄了操作受葛，圖片就會(huì)變成游離狀態(tài)無(wú)法繼續(xù)管理题涨，造成大量垃圾數(shù)據(jù)占用系統(tǒng)資源。
- 刪除操作总滩，沒(méi)有刪除一些關(guān)聯(lián)數(shù)據(jù)携栋。例如商品表和商品屬性表關(guān)聯(lián)，如果刪除操作不是事務(wù)性的一起刪除咳秉，就會(huì)造成數(shù)據(jù)空間浪費(fèi)，且可能影響后續(xù)的統(tǒng)計(jì)功能鸯隅。
對(duì)于新建資源的圖片上傳澜建，可以和BA溝通使用草稿的方式在用戶(hù)進(jìn)入創(chuàng)建頁(yè)就完成數(shù)據(jù)插入操作，也可以設(shè)計(jì)一個(gè)圖片空間來(lái)提醒用戶(hù)使用已經(jīng)上傳的圖片蝌以；對(duì)于刪除操作炕舵，系統(tǒng)不復(fù)雜可以設(shè)計(jì)為數(shù)據(jù)庫(kù)表標(biāo)記刪除，而不是真的刪除跟畅，也可以設(shè)計(jì)回收站功能統(tǒng)一移動(dòng)到備份表咽筋。
分布式系統(tǒng)延遲 由于現(xiàn)在稍大的系統(tǒng)都是用了分布式或微服務(wù)設(shè)計(jì)，系統(tǒng)之間存在系統(tǒng)存在同步延遲徊件，比如數(shù)據(jù)庫(kù)主從同步奸攻，靜態(tài)資源服務(wù)器同步等蒜危。在一些對(duì)文案要求比較嚴(yán)格的項(xiàng)目中一個(gè)隱藏的需求是，需要提醒當(dāng)前的信息可能存在延遲睹耐，請(qǐng)稍后再試辐赞。或者前端增加定時(shí)刷新頁(yè)面的或者資源的回退策略硝训，在我經(jīng)歷的一個(gè)項(xiàng)目中响委，上傳圖片成功返回圖片URL后，前端可能會(huì)延遲2s左右才能從正常打開(kāi)圖片窖梁，因此需要增加onload赘风、onerror進(jìn)行重試或后續(xù)操作。
其他非功能性需求
兼容性 瀏覽器兼容性是前端開(kāi)發(fā)中頭疼的事情纵刘，從IE6到微信webview邀窃，無(wú)論技術(shù)發(fā)展到哪個(gè)時(shí)代都逃不掉。那么那些事情是需要和BA確認(rèn)的呢彰导？
- 各種瀏覽器內(nèi)核具體的型號(hào)蛔翅，而不是討論搜狗、360這類(lèi)殼瀏覽器位谋。如果是APP內(nèi)部的webview山析，這就需要收集相關(guān)安卓或IOS的版本號(hào)。
- 是否允許一定程度上的降級(jí)策略掏父？比如在老式的安卓手機(jī)中大量的CSS3特性不支持笋轨，可能會(huì)造成動(dòng)畫(huà)失效，是否我們可以不在老式的手機(jī)中要求過(guò)渡動(dòng)畫(huà)等赊淑。
升級(jí)策略 前端有兼容性問(wèn)題爵政，那么服務(wù)器端就沒(méi)有了么？不幸的是如果APP不是同步發(fā)布的話(huà)陶缺，API的修改需要照顧老的客戶(hù)端钾挟。即使是同步發(fā)布的APP很難強(qiáng)制用戶(hù)升級(jí)。在服務(wù)器端開(kāi)發(fā)的時(shí)候保持一定兼容性的同時(shí)饱岸，更重要的是需要和BA一起設(shè)計(jì)出合理的升級(jí)方案掺出。我的經(jīng)驗(yàn)是設(shè)計(jì)API時(shí)，需要在URI路徑中預(yù)留版本號(hào)苫费，例如V1/your-api/{id}汤锨。同時(shí)也需要增加契約測(cè)試來(lái)保證API的修改不會(huì)破壞原來(lái)的邏輯。
本地化和國(guó)際化 在一些國(guó)際化的項(xiàng)目中百框，這一點(diǎn)尤為重要闲礼，不過(guò)有時(shí)候容易被忽略。多語(yǔ)言和時(shí)區(qū)問(wèn)題需要在項(xiàng)目之初就和BA確認(rèn)，統(tǒng)一增加國(guó)際化方案柬泽。而其他本地化則需要在每個(gè)功能上注意慎菲，例如日期、貨幣聂抢、單位钧嘶、標(biāo)點(diǎn)符號(hào)的輸出方式。
用戶(hù)行為分析埋點(diǎn) 越來(lái)越多的項(xiàng)目開(kāi)始使用用戶(hù)的行為分析工具了琳疏，例如Google的Gtag和更加專(zhuān)業(yè)的dynatrace有决，使用這些工具會(huì)對(duì)系統(tǒng)造成一定的侵入性，需要對(duì)用戶(hù)的操作進(jìn)行埋點(diǎn)空盼。如果項(xiàng)目有類(lèi)似的需求书幕，針對(duì)特定的功能很多用戶(hù)行為分析的系統(tǒng)會(huì)提前定義一些標(biāo)簽，那么在開(kāi)始一個(gè)新功能時(shí)需要確認(rèn)用戶(hù)行為分析的一些規(guī)則揽趾。
最后
寫(xiě)作本篇的目的是分享在工作中開(kāi)發(fā)在做一張卡背后需要考慮多少注意事項(xiàng)台汇。細(xì)節(jié)想的越多，讓業(yè)務(wù)邏輯變得更完整篱瞎，可以讓開(kāi)發(fā)工作變得更為順暢苟呐。
在參加公司某次培訓(xùn)時(shí)，恰好也有很好的非功能性需求的課程俐筋，非常詳細(xì)牵素，以至于長(zhǎng)達(dá)數(shù)頁(yè)，但遺憾的是沒(méi)有非常詳細(xì)的解釋和應(yīng)對(duì)方法澄者。因此決定根據(jù)自己在工作中遇到過(guò)的場(chǎng)景作為例子笆呆，給大家分享出來(lái)。
在敏捷團(tuán)隊(duì)中一個(gè)痛點(diǎn)是我們很少有一個(gè)大而全的需求文檔粱挡，如果在開(kāi)卡的時(shí)候有一些需求沒(méi)有被想到或者沒(méi)有在A(yíng)C中體現(xiàn)出來(lái)赠幕，就需要反復(fù)找BA、UX反復(fù)確認(rèn)询筏。開(kāi)發(fā)和BA溝通調(diào)整需求榕堰、交互的時(shí)候可能忘記知會(huì)QA或者UX，或者沒(méi)有更新故事卡內(nèi)容嫌套，就又會(huì)造成溝通的麻煩局冰。
經(jīng)驗(yàn)之談，多提意見(jiàn)灌危，謝謝！
