我和91的一次小练习

发表于一月 11, 2018

背景介绍

 

最近对因果图又痴迷起来,一连数天的钻研它,渐渐感悟到,其实不仅仅测试人员应该掌握建模的技能可以参考我的书《海盗派测试分析:MFQ&PPDCS第三章“建模”,测试分析时,针对需求有多种建模的方法,因果图只是其中的一种),开发人员同样可以运用因果图等常用的建模方法改善代码质量

 

为了验证这一点,前几天我在FB上抛出了一个小的需求,然后来自台湾的Joey Chen (我们私底下都称他为91)接招了,91Odd-e资深教练,代码功底深厚。以下是我们针对这个练习交互的内容以及我的点评。

 

您可以把下文的“taixiaomei”当做一个测试人员,把“JoeyChen”当做一个开发人员,这是一次DeveloperTester之间的对话。

 

练习的过程

 

1.     抛出题目

Xiaomei Tai

1月3日 12:38 · 

这几天一直在练习一道简单的题目,还是学到不少。感兴趣的不妨一试:请针对如下需求,分析建模(模型不限),设计测试场景(testconditions

2.     第一次需求澄清

 

Joey Chen 第二點是「和為負數」還是「N為負數」啊?

Xiaomei Tai N为负数

Joey Chen Xiaomei Tai gotit!

Xiaomei Tai Joey Chen 若你愿意,也可以把代码写,然后用我建的模型去对应,看看unit checking有无新一些启发

 

3.     迭代1:代码交付

 

JoeyChen 中午趁著吃休息時間練習了一下:https://github.com/.../master/SumNthInteger/UnitTest1.cs

 

91TDD的方式,快速交付了代码,并且写了11UnitChecks:

 

4.     迭代1:测试反馈

 

Xiaomei Tai 1. 我理解不存在类似“Numbers”样的数组,直接算前N个整的和即可;2. 我想知道UnitCheck都是怎么的,有有分析模型可供参考呢

JoeyChen Xiaomei Tai 所以輸入的是一個整數?例如:31678,如果n2,和為4,這種輸入?

Xiaomei Tai 如果N2,那么sum=1+2=3,如果MaxVal=31678,那么输出3

Xiaomei Tai 其实,正是了澄清需求中模糊的地方,所以才想着先练习建模,通过讨论模型,就会更加理解需求,然后再编码或者编写具体的checking;出目的初衷是,大家共同探交流modelmodel一旦有了,如何check的思路也就有了

JoeyChen Yep, 一般來說我的測試用例出來兩個比較有代表性的,我就會用測試用例來進行需求的釐清了

JoeyChen 不過我目前沒有使用什麼模型就是了

Xiaomei Tai 恩,是实例化需求比好的地方

JoeyChen 所以如果n=-3, maxVal=100, 輸出6

Xiaomei Tai 我理解是的

Xiaomei Tai 然,我们现有用户,否可以去向用户澄清需求

JoeyChen 了解,等我騎車回來改一下。多個方法就可以直接用原本代碼了

Xiaomei Tai 目比较简单,不知道,发人员来说,你是如何分析需求的呢?(除了出几个典型的具体的实例以外)

Xiaomei Tai 有更系统一些的思路展需求分析?

JoeyChen Xiaomei Tai 我一開始是把邏輯樹畫出來

JoeyChen 但發現要完成代碼沒什麼太多邏輯分支,所以改走各個變因的相互影響

Xiaomei Tai Joey Chen那我很想看看你的逻辑树~

JoeyChen 加上想用用例驅動出開發,所以依據結果排了一下順序

 

JoeyChen 思路:
1) 
先用 n is 0, 確認和是 0; (確認初始值)
2) 
再用 n is 1, 確認和是 1;(確認不是 hard-code)
3) sum > maxval, 
輸出為 input invalid; (確保大於的條件)
4) sum = maxval, 
輸出為 input invalid; (確保等於的條件)
5) 
 n is 3, 確認和為6, (確保有正確取前 n )
6) 
 n is -3, 確認當 n 為負數,(確保 n 有正確取絕對值)

Xiaomei Tai 第四条应该是返回su m

Xiaomei Tai Joey Chen 是典型的TDD的思路,要是用逻辑树分析会是什么样的呢?

JoeyChen Xiaomei Tai 對耶等於是輸出sum

JoeyChen 我在TDD前會用這類的model去跟測試用例作搭配。
邏輯路徑可能會是好幾個版本演進跟合併的過程。

 


通过这一回合的交流,91又更新了代码,交付了iteration2

 

5.     测试建模

 

了解了开发人员的思路后,我也从测试角度抛出了一些建模的思路:

 

Xiaomei Tai 简单,不过测试思路可以有很多种,到底应该采取哪种呢,很是值得我思考!

Xiaomei Tai 第一种,最版,只验证需求中涉及的每一个逻辑关系。不看出,有两个原子逻辑:一是N为负数时取其绝对值;二是和小于等于MaxVal输出,反之错误提示。因果也比较简单,只要两个测试用例就够了,是完全从黑盒、从需求角度行的分析。

Xiaomei Tai 第一种测试分析得出的测试场景,有2

Xiaomei Tai 第二种,发版,就是上面91出的,根据发人使用测试驱发的思路,边分析需求边测试编码给出的: 
1) 
先用 n is 0, 確認和是 0; (確認初始值)
2) 
再用 n is 1, 確認和是 1;(確認不是 hard-code)
3) sum > maxval, 
輸出為 input invalid; (確保大於的條件)
4) sum = maxval, 
輸出為 input invalid; (確保等於的條件)
5) 
 n is 3, 確認和為6, (確保有正確取前 n )
6) 
 n is -3, 確認當 n 為負數,(確保 n 有正確取絕對值)

Xiaomei Tai 第三种,复版,无是用因果分析出每一种可能的逻辑关系,是用等价类法,很容易考NMaxVal的各种合情况,里有一个复点的例子:

(注:其实个复版已经是我画的第6个迭代版本了)

Xiaomei Tai 对应的,可以出如下12测试场景(test conditions):

1. N非法
2. MaxVal
非法
3. N
正,MaxVal0,和大于MaxValErr3
4. N
为负MaxVal正,和大于MaxValErr3
5. N
0MaxVal为负,和大于MaxValErr3
6. N
0MaxVal0,和等于MaxVal,输出和
7. N
0MaxVal为负,和大于MaxVal,Err3
8. N
为负MaxVal0,和大于MaxVal,Err3
9. N
0MaxVal正,和小于MaxVal,输出和
10. N
0MaxVal正,和等于MaxVal,输出和
11. N
正,MaxVal正,和大于MaxValErr3
12. N
0MaxVal正,和小于MaxVal,输出和

Xiaomei Tai 然,即使经样的一些分析,个需求仍然可以探索出更多值得一问题来里因是重点在模型测试分析上,所以就不展了。迎各位就几种测试的情况发表见解,您测试应该怎么做呢?

 

在我们的对话中,并未展开这个“可以值得更多探索的地方”。其实在海盗派测试微信群里,也就这个练习有过一些讨论,大家更多的是提出了可以探索的问题,这当然也是一种Modeling- 通过探索问问题的建模来了解需求,把它称之为“第四种 探索版”吧,下面是大家问出的一些问题,可以看出很多问题是单单从建模、或者编码的角度很难考虑到的:

 

  • 求和的数,N,MaxVar有限制数据类型吗?比如int还是word16?求和的数是否数据类型是否都一致?

  • 输出用什么方式输出?

  • 被测对象是一个底层c/c++算法函数模块还是什么?

  • N为负数时的描述貌似有歧义,是每个求和数取绝对值相加还是相加完后取绝对值?

  • 2个整数,是 0 1 还是  1 2?前-2个整数,是 0 -1 还是 -1 -2 

  • -∞ 0 都是整数,要给定一个基准坐标吧,譬如100的前N个整数的和

  • 假定N = -2目标数组是1234)如果是指定数组的前-2个整数。那么得到的元素就是43

  • For instance: the code takes an integer asinput, but returns a string. Is that what we want?

  • There is no error code returned by the function;just a string. Are we OK with that?

  • The string “invalid input” is provided when theresult exceeds MaxVal. Is that sufficiently specific?

  • There is a different algorithm available to suma sequence of numbers, and it’s way more efficient for large values of n:  n*(n+1)/2. Might we want to use that insteadof iterating?

  • Where is this function going to be used? It’spart of a system; what system?

  •  “Are theonly two classes of output [some valid number] and ERROR?”

  • 。。。。。。

 

6.     我的第7Model

 

过了几天,我又改进了之前的因果图的Model,这是第7版了

Xiaomei Tai 又更新了下modeltests,共12Test Conditions,不知对应 Joey Chen 的代,是否会发什么问题呢?比如当给N一个极大的字,超出int,会出现数字翻转吗,如果会的算的SUM就不会准确,那么是否有可能出TCon9~12的情形呢?

Xiaomei Tai 7thModel


JoeyChen 非整數、無效整數的部份,在我的情況不會發生,因為我只是寫單元測試來當範例,沒有 UI 的情況,format  validation 可以先忽略。

N
很大導致和溢位這件事,是會發生的,對開發人員來講,這就是該定義需求的部份,例如想要輸出錯誤提示,那測試就會紅燈,然後修正它。

JoeyChen N為極大值時,出現的第一個錯誤,out of memory(stack overflow

JoeyChen 將算法改成 (1+n)*n/2 時,出現第二個錯誤,是 n < 0 的絕對值處理漏了。

JoeyChen 把絕對值的作法補上去之後,發生第三個錯誤,是在 C# 中,int overflow 會自動被轉成負值

JoeyChen 最後的代碼像這樣,我也更新到 github 上了

JoeyChen test cases 9~11, N=0Sum 目前就是 0, 不會有問題,只有 N絕對值極大,會有上述的問題跟演進過程

Xiaomei Tai Joey Chen的代优化了很多!并不是每一个分析出的Test Condition 都要测试,要根据具体的上下文,比如假设:算求和是用户自己的一个函,那么可能出computing error 几个tests就有必要了

Xiaomei Tai 练习其实很好地诠释了一个道理:测试分析最大的价值不是得出几个tests ideas ,然后通过执test ideas验证;而是在于分析的程本身可以帮助更好地了解需求、帮助改善程代量,bug早暴露出

JoeyChen yes, 而且會擴展出原本討論需求或需求釐清時,沒開到的地圖。
這種測試分析,就像 spotlight, 不斷在探索邊界,確認邊界,甚至邊界是會移動的情況。

Xiaomei Tai 谢谢你一直参与到练习讨论,因果建模个点然很小-只是我那本中的一个小点而已-但是我一直认为这可以帮到测试,同样可以帮到发人练习让我更确信一点了!

 

7.     迭代3:代码交付

 

最终的代码如下图右边所示,左边是迭代1的代码,可做对比:

对应的UnitChecks更新:

 

8.     结束语

 

从这个练习中,可以学到很多:

 

  • 无论是开发的编码、还是测试的分析,都不是一次性的过程,都是一个需要数次迭代的、反复优化的过程。

  • 测试分析建模的过程就是一个学习需求、了解产品的过程,无论是开发人员、还是测试人员,都建议学习掌握这个技能

  • 对任何一个哪怕是很小的需求,理论上,可以提出无数个问题,也就是说,需要探索的点有很多,测试人员的发散型思维非常重要。

  • 学习、提升个人技能的一个有效的途径就是做一次又一次这样的练习,不仅仅Practice,还要多思考Reflection,多总结提升Explication,这是我提出的PRE学习model如果测试人员都“懒于思考、勤于搬抄、疏于练习”,那么确实与某些人大声喊叫的“Testing Is Dying”距离不远了。

  • 没有任何一种Model能够覆盖质量的方方面面,对于这个练习,哪怕是,开发人员经过多次迭代写出了高质量、简洁的代码、附有多个Unit Checks;哪怕是,测试人员经过多次分析建模、提出了多个有助于改善质量的问题,当真正去探索去testing时,一定还会暴露出问题来。所以,不论你的事前的测试分析与测试设计多么系统、多么完善,仍然无法保证没有bug遗漏,那种按部就班的“测试计划+测试分析设计+测试执行+测试报告”的瀑布式测试方式是非常危险的

  • 假如您是一名管理者,对目前为止这个练习中的测试质量和开发质量还算满意的话,那么我想说的是,这个效果不是因为使用了“因果图”这样的测试技术、不是因为使用了BenderRBT的测试工具、不是因为开展了“分析建模”这样的测试活动、不是因为采用了“先设计测试用例再运行发现bug”这样的传统测试流程、不是因为设计了高质量的测试用例。。。,因为同样的技术、同样的活动、同样的测试流程存在已久,很多人都在做。使得优秀测试区别于普通测试的,一定是具有专业测试技能、技巧娴熟的测试人员,这才是确保高质量测试的关键,本文提到的“分析建模”技能只是其中之一,还有很多测试技能值得每一个tester去不断练习和提高,这也是海盗派tester一直关注的:

Comment Box is loading comments...