修正BUG的代价
需求 设计
编程 内部测试 外部测试 发布
一些常识和经验之谈
测试能提高软件的质量,但是提高质量不能依赖测试。 测试只能证明缺陷存在,不能证明缺陷不存在。“彻
底地测试”难以成为现实,要考虑时间、费用等限制, 不允许无休止地测试。我们应当祈祷:软件的缺陷在 产品被淘汰之前一直没有机会发作。 测试的主要困难是不知道如何进行有效地测试,也不 知道什么时候可以放心地结束测试。 每个开发人员应当测试自己的程序(份内之事),但 是不能作为该程序已经通过测试的依据(所以项目需 要独立测试人员)。 80-20原则:80%的缺陷聚集在20%的模块中,经常出 错的模块改错后还会经常出错 测试应当循序渐进,不要企图一次性干完,注意“欲 速则不达”。
很多人认为软件测试就是运行一下软件,看看结果对不对. 但实际上,如何在有限的投入下,提高软件测试的效率和产 出是一件很见功底的事.好的测试人员不仅要掌握各种测 试技术,还要具备丰富的编程经验和对BUG的敏感.测试的 复杂之处,除了测试技术问题之外,还有测试管理问题.
测试不是可有可无,随心所欲的.规范化的软件开发需要对 软件测试早做计划,分配必要的时间,人力和财力等资源,并 将其作为项目管理的一个部分加以控制和协调.
单元测试:是针对软件设计的最小单位—程序模块,进行 正确性检验的测பைடு நூலகம்工作。一般包括逻辑检查、结构检查、 接口检查、出错处理、代码注释、输入校验、边界值检查。
单元测试的依据是系统的详细设计;一般由项目组开发人 员自己完成。
集成测试:在单元测试的基础上,将所有模块按照设计要 求组装进行测试。一般包括逻辑关系检查、数据关系检查、 业务关系检查、模块间接口检查、外部接口检查。
(4)软件需求、设计报告、程序经常发生变更,每次变更都可能产生 新的Bug。