ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 測試的藝術學習筆記

測試的藝術學習筆記

原创 Linux操作系统 作者:Flourish2004 时间:2009-04-09 16:07:58 0 删除 编辑

黑盒測試 : 等價類劃分, 邊界測試, 因果圖分析, 錯誤猜測

白盒測試 : 語句覆蓋, 條件覆蓋, 判定覆蓋, 判定/條件, 多重條件 覆蓋

白盒測試的關注點 : 測試用例執行的程度或覆蓋程序邏輯結構(源代碼)的程度.


學習測試的藝術中講到的測試的幾大原則: (盡量語言簡單化,讀起來方便,又不會讓人感覺在座飛機 :))

 1. 測試用例中一個必需部分是對預期輸出或結果進行定義;

    盡管軟件測試是破壞性的定義是合理的,但人們潛意識中仍然渴望看到正确的結果. 克服這個問題就 通過事先精确定義程序的
    預期輸出, 以對所有的輸出進行仔細檢查. 

    在确定事物存在 "問題" 前, 人們必須已經形成特定的認識. 沒有期望,也就沒有所謂的意外.

 2. 程序員應當避免測試自已編寫的程序
   
    對軟件項目關注的重點發生變化, 就會產生另外一些問題 . 當程序員 "建設性"地設計和編寫完程序之後, 很難讓他突然改變 
   視角用一種 "破壞性" 的眼光來審查程序.  這是一個心理學方面的問題.

   另外, 由于程序員錯誤地理解了疑難定義和規範,導致程序中存在錯誤. 如果情況是這樣, 程序員可能會帶著同樣的誤解來測試
   自已的程序.  

 3. 編寫軟件的組織不應當測試自已故編寫的軟件. 與上相似.

 4. 應當徹底檢查每個測試的執行結果.

 5. 測試用例的編寫不僅應當根據有效和預期的輸入情況, 而且也應當根據無效和未預料到的輸入情況

 6. 檢查程序是否 "未做其應該做的" 僅是測試的一半, 測試的另一半是檢查程序是否 "做了其不應該做的"

 7. 應避免測試用例用後即棄, 除非軟件本身就是一個一次性的軟件.

 8. 計劃測試工作時不應默許假定不會發現錯誤.  所謂測試 是為發現錯誤而執行程序的過程.

 9. 程序某部分存在更多錯誤的可能性, 與該部分已發現錯誤的數量成正比.

10. 軟件測試是一項極富創造性,極具智力挑戰性的工作.

   三個測試原則:

   1. 軟件測試是為了發現錯誤而執行程序的過程.

   2. 一個好的測試用例具有較高的發現某個尚未發現的錯誤的可能性.

   3. 一個成功的測試用例能夠發現某個尚未發現的錯誤.

轉 软件测试原则[收藏此页] [打印]
作者:**ing博客 ★执着★  2009-02-03 内容导航:软件测试原则 第1页: 软件测试原则 文本Tag: 软件测试 【IT168 技术文章

  1、软件测试原则

  1)   尽早和不断的测试

  2)   彻底的测试不可能

  3)   软件测试是有风险的行为

  4)   并非所有的软件错误都能修复

  5)   反相思维逻辑

  6)   由小到大的测试范围

  7)   避免检查自己的代码

  8)   追溯至用户需求

  2.为什么不能完全测试

  1)   测试数据输入量太大

  2)   输出结果太多

  3)   软件的操作步骤太多

  4)   软件说明书并非“盲人手册”

  3、并非所有的错误都能修复,BUG不能被关闭的原因

  1)   不算真正的软件错误

  2)   没有足够的时间

  3)   修复的风险太大

  4)   不值得修复

  4、错误集中发生现象

  1)   错误前置逻辑

  2)   实现人员的疲劳,造成大量代码坏块

  3)   程序人员往往会犯同样的错误,因为大部分代码都是复制、粘贴而来

  4)   软件的基础构架问题,有些软件的底层支撑系统因为“年久失修”变得越来越力不从心了。

  5、发现缺陷的时间越早,BUG所造成的损失会越(小)。

  6、“产品缺陷的(80%)”以上是在产品开发过程中的(需求定义阶段)引入的,

  7、避免检查自己的代码的原因

  1)   程序员从来都不会承认自己写的程序有错误

  2)   程序员的测试思路有明显的局限性

  3)   多数程序员没有经过严格正规的职业训练

  4)   程序员无良好的BUG跟踪和回归测试经验。

  8、错误集中表现在以下几方面

  1)   找到的软件缺陷越多,就说明软件问题越多

  2)   实现人员的疲劳,造成大量代码坏块

  3)   程序人员往往会犯同样的错误

  4)   软件的基础构架问题

 


代碼走查  -- 要求人們組成一個小組來閱讀來直觀止檢查特定的程序.
   在典型的程序中, 通過代碼走查能找出30%-70%的邏輯設計和編碼錯誤. 代碼檢查/走查與基于計算機的測試互補,

代碼檢查 -- 以組為單位閱讀代碼, 它是一系列規程和錯誤檢查技術的集合. 一般有會議主席,編程員, 專業測試師, 另一程序員等組成


用于代碼檢查的錯誤列表:

1. 數據引用錯誤,

   a. 是否有引用的變量未賦值或未初始化

   b. 對于面向對象的語言, 是否所有的繼承需求都來在實現類中得到了滿足;

2. 數據聲明錯誤

   a. 是否所有的變量都進行了明确的聲明,

   b. 是否每個變量都被賦予了正确的長度和數據類型.
 
   c. 是否存在相似名稱的變量.
  
3. 運算錯誤
 
   a. 是否存在不一致的數據類型的變量間的運算,

   b. 是否有混合模式的運算.

   c. 變量值是否超過了有意義的範圍

4. 比較錯誤

   a. 是否有不同數據類型的變量之間的比較運算;

   b. 是否有混合模式的比較運算;

   c. 比較運算符是否正确,程序員經常混淆 "至多,至少,大于,不小于,不于和等于"    等的比較關系;

   d. 每個布爾表達式所敘述的內容是否正确, 在編寫涉及 與 ,或,非 的表達式時,程序員經常犯錯;

   e. 布爾運算符的操作數是否是布爾類型的, 比較運算符和布爾運算符是否錯誤地混在一起,
 
   f. 對于那些包含一個以上的布爾運算符的表達式, 賦值順序以及運算符的優先順序是否正确,

   g. 編譯器計算布爾表達式的方式是否會對程序產生影響,

5. 控制流程錯誤

   5.1 是否存在 '僅差一個' 的錯誤, 如迭代數量恰恰多一次或少一次,
      如 : 執行10次循環,
      for (int i =0 ; i<=10; i++) (wrong)
      for (int i =0;  i<=9 ; i++) (right)

6. 接口錯誤 ;
  
7. 軟件輸入輸出錯誤;

8. 其它檢查;
  
上述討論的是軟件開發人員通常不會考慮到的一種測試形式 - 人工測試, 人工測試在
暴露錯誤方面是很有成效的.
包括有 :
    利用錯誤列表進行代碼檢查;
    小組代碼走查;
    桌面檢查;
    同行評審;
  
(冒煙測試 一般用于每日構建, 構建服務器首先從CVS,VSS服務器上,下栽最新的源代碼, 然後編譯單
元測試, 運行單元測試通過後,編譯可執行文件, 可執行文件若可運行, 并能執行基本功能,則認為
通過了冒煙測試.
 就是先保證系統能跑得起來,不至于讓測試工作做到一半突然出現錯誤導致業務中斷. 目的
     就是先通過最基本的測試, 若有問題直接打加開發部, 減少測試部門時間的浪費)
測試 alpha 測試 : 軟測的第一個版本,(內部測試用)  在開發小組內部進行, 測試的方法也較多, 黑盒,白盒,壓力,應力等;
測試 beta  測試 : 軟測的第二個版本,(給特定的用戶群來測試用) 有選擇地請一些用戶實際使用, 將發現的問題反饋回來再進行修改;
測試 λ    測試 : 軟測的第三個版本,(软件公司发布的版本)
白盒測試

   1. 邏輯覆蓋測試
   白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構的程度.  (page24)

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/183242/viewspace-586899/,如需转载,请注明出处,否则将追究法律责任。

上一篇: 綿雨紛飛
下一篇: 生活
请登录后发表评论 登录
全部评论

注册时间:2009-01-06

  • 博文量
    149
  • 访问量
    169257