Developer Testing

原创 2004年10月19日 23:10:00

Recommended approach to developer testing
1. Test for each relevant requirement to make sure that the requirements have been implemented. Plan the test cases for this step at the requirements stage or as early as possible, preferably before you begin writing the unit to be tested.
2. Test for each relevant design concern to make sure that the design has been implemented. Plan the test cases for this step at the design stage or as early as possible, before you begin the detailed coding of the routine or class to be tested.
3. Use "basis testing" to add detailed test cases to those that test the requirements and the design.

Test first or test last?
1. Writin test cases before writing the code doesn't take any more effort than writing test cases after the code; it simply resequences the test-case-writing activity.
2. When you write test cases first, you detect defects earlier and you can correct them more easily.
3. Writing test cases first forces you to think at least a little bit about the requirements and design before writing code, which tends to produce better code.
4. Writing test cases first exposes requirements problems sooner, before the code is written, because it's hard to write a test case for a poor requirement.
5. If you save your test cases(which you should), you can still test last, in addition to testing first.

Limitations of developer testing.
1. Developer tests tend to be "clean tests". Developer tend to test for whether the code works(clean tests) rather than to find all the ways the code breaks(dirty tests).
2. Developer tests tend to have an optimistic view of test coverage.
3. Developer tests tend to skip more sophisticated kind of test coverage.

Bag of Testing Tricks
Structured basis testing
Is a fairly simple concept. The idea is that you need to test each statement in a proram at least once. The easiest way to make sure that you've gotten all the bases covered is to calculate the number of paths through the program and then develop the minimum number of test cases that will exercise every path through the program.
1. Start with 1 for the straight path through the routine.
2. Add 1 for each of the following keywords, or their equivalents: if, while, repeat, for, and, and or.
3. Add 1 for each case in a case statement. If the case statement doesn't have a default case, add 1 more.

Data-flow testing
Data-flow testing is based on the idea that data usage is at least as error-prone as control flow.

Data can exist in one of three states:
1. Defined. The data has been initialized, but it hasn't been used yet.
2. Used. The data has been used for computation, as an argument to a routine, or for someting else.
3. Killed. The data was once defined, but it has been undefined in some way.
In addition to the three satement, it's convenient to have terms that describe entering or exiting a routine immediately before or after doing something to a variable:
1. Entered. The control flow enters the routine immediately before the variable is acted upon. A working variable is initialized at the top of a routine, for example.
2. Exited. The control flow leaves the routine immediately after the variable is acted upon. A return value is assigned to a status variable at the end of a routine, for example.

Combinations of data states
The normal combination of data states is that a variable is defined, used one or more times and perhaps killed. but some is suspicious:
1. Defined-Defined. If you have to define a variable twice before the value sticks,it's wasteful and error-prone.
2. Defined-Exited. If the variable is a local variable, it doesn't make sense to define it and exit without using it. If it's a routine parameter or a global variable, it might be all right.
3. Defined-Killed. It suggests either that the variable is extraneous or that the code that was supposed to use the variable is missing.
4. Entered-Killed. This is a problem if the variable is a local variable. It wouldn't need to be killed if it hasn't been defined or used. but if it's a routine parameter or a global variable, it's all right as long as the variable is defined somewhere else before it's killed.
5. Entered-Used. It's a problem if the variable is a local variable.
6. Killed-Killed. A variable shouldn't need to be killed twice.
7. Killed-Used. Using a variable after it has been killed is a logical error.
8. Used-Defined. Using and then defining a variable might or might not be a problem, depending on whether the variable was also defined before it was used.

Error Guessing
In addition to the formal test techniques, good programmers use a variety of less formal, heauristic techniques to expose errors in their code.
1. Boundary analysis--off by one errors.
2. classes of bad data
Too little data
Too much data
The wrong kind of data
The wrong size of data
Uninitialized data

Keeping Test Records
1. Administrative description of th defect.
2. Full description of the problem.
3. Steps to take to repeat the problem
4. suggested workaround for the problem
5. Related defects.
6. severity of the problem.
7. Origin of the defect-requirement, design, coding or testing.
8. Subcalssification of a coding defect--off by one, bad assignment, bad array index, bad routine call, and so on.
9. Location of the fix for the defect.
10. Classes and routines changed by the fix.
11. Person responsible for the defect(this can be controverial and might be bad for morale).
12. Lines of code affected by the defect.
13. Hours to find the defect.
14. Hours to fix the defect.

Cocoa Touch 入门记——《精通 iOS 开发》学习心得(4) [应用程序设置]

今天要说的设置,当然是这个了: 嗯,就是在 Settings 里创建一个新的改程序专属的 Settings Bundle。 当然我不得不使用 iPhone Retina (3.5-...
  • u013883752
  • u013883752
  • 2014年03月12日 19:57
  • 1289

debian jessie和testing安装教程

  • Demorngel
  • Demorngel
  • 2017年01月02日 10:10
  • 1755

packstack allinone install log

[root@kilo-rdo ~]# packstack --allinone Welcome to the Packstack setup utility The installation log...
  • nomad2
  • nomad2
  • 2016年12月13日 14:02
  • 2438

HP Unified Functional Testing 使用【不定时更新】

一、HP Unified Functional Testing 打开 1.选择插件 根据需求选择相应的插件,点击 OK HP UFT 主界面   二、新建Test 根据需求选择相应的选项,Test...
  • GhostDY
  • GhostDY
  • 2015年10月16日 22:40
  • 1696

HP Unified Functional Testing的使用

1.新建一个TEST:file-new test 2.打开要录制的软件,点击record,进行录制 录制期间,任何一步操作都会产生相应的代码,所以不要进行不需要的操作 3.进行回放,可以查看结果...
  • Future_gogo
  • Future_gogo
  • 2015年10月18日 20:31
  • 2330

Android Testing Support Library

前沿前两篇只是为自动化做铺垫,开篇有几个问题1.程序员是不是都不写自动化测试和单元测试?或者写其中一种 2.什么是自动化测试? 3.写自动化测试除了增加工作量之外还能带来那些方便? 4.自动化可...
  • o279642707
  • o279642707
  • 2017年01月18日 13:19
  • 662

《Web Services Testing with soapUI》书附带的例子下载

《Web Services Testing with soapUI》书附带的例子下载
  • Testing_is_believing
  • Testing_is_believing
  • 2013年05月17日 15:46
  • 3203

UFT(Unified Function Testing)自动化测试工具简介

UFT(Unified Function Testing)是一种自动化测试工具,以VBScript为内嵌语言。
  • youngyunq
  • youngyunq
  • 2015年10月25日 21:47
  • 1363

测试-- HP Unified Functional Testing

登陆系统 输入Emily订票信息 对Button进行重名命 高亮功能 定为功能 Object Spy的使用 ...
  • Cinderella_7
  • Cinderella_7
  • 2015年10月19日 08:47
  • 1393

Unified Functional Testing 12.01 Patch1

Unified Functional Testing 12.01 Patch1 Feedback Send Email to a Friend  Pr...
  • xiecj_2006
  • xiecj_2006
  • 2014年12月24日 21:21
  • 2885
您举报文章:Developer Testing