|
7、 测试进度的错误估算。
在项目开发中，领导为督促测试的进程，往往会让项目组汇报工作进度，了解已经
完成的工作占比，从而对工作进度做出判断。我对这种工作方式完全拥护，只是觉得这种方式还有不足。
测试进程不是简单的1＋1过程，不能武断地认为“我用8天干完了80％的工作，那么，剩余工作便能在2天内干完”。著名的Pareto80/20规律告诉我们：测试发现的所有错误中的80％很可能集中在20％的程序模块中，另外20％很可能集中在80％的程序模块中。
所以，没有对测试对象认真分析的基础，单凭工作完成数量而对工作进度做出的的判断往往是错误的。
我认为，“工作实际进度＝工作完成量占比＋测试对象的错误占比分析”才是一个较合理的测试进度估算方式。
测试新思路：
项目的开发风险来自于对需求的误解，来自于设计与开发过程及产品的缺陷，只有尽早发现这些缺陷，才能降低并控制项目风险。基于这种思想，软件业出现了一些新的测试思路，主要有二：
1、测试驱动开发（Test-Driven Development，简称TDD）。这种测试思想被最近流行的XP（Extreme Programming）极限编程方式所大力提倡。它的基本思想是，通过测试来为编程做指导，在某个要开发的需求对象明确之后，在编码之前，先进行相关测试代码（测试代码的内容和需求规格说明书描述是相同的，有人把它称为“可执行的需求规格说明书”）的编写工作，完成之后针对测试代码进行编程，然后再用测试程序对开发代码进行测试，验证其正确性，若程序通过了测试，就说明它是符合需求规格说明书要求的。周而复始，通过这样的过程，开发进程得以层层深入，直到开发完成。而这时单元测试也基本完成了。
这种测试方式的最大的好处是，尽早地发现设计、开发中存在的问题，避免传统开发模式中的“测试过程中发现代码不能满足需求而导致的大量返工”。降低项目风险；同时可以尽早地将“半成品”展示给客户，使客户对需求进行验证、补充及完善，另外测试代码的表达方式相对准确、无二义性，可以降低因需求理解错误而导致的项目风险。
<<上一页
1
2
3
4
5
6
7
下一页>>
数据挖掘工具
| 
