软件测试与改错解决方案.ppt

目录 1. 测试的常识与道理 2. 测试的分类与比较 3. 测试人员的组织 4. 企业的测试策略 5. 测试规范 6. 软件产品的主要测试内容及技术 7. 改错的方法 8. 小结 参考书：《软件工程与项目管理解析》，林锐 著，电子工业出版社，2003 1. 测试的常识与道理 1.1 你真的懂测试吗 编程大师说：没有错误的程序世间难求。 （《编程之道》） 你在学校里学过测试吗？（读到博士可能也不懂测试） 你所在的企业重视测试吗？ （小公司程序员的技能更加全面） 临时抱佛脚行吗？你以为有文档模板就会测试了吗？ 如果不懂得有效地进行测试，你不仅得不到功劳，也没人欣赏你的苦劳，你拥有最多的将只是疲劳。 职业软件工程师应当掌握需求开发、系统设计、编程、测试、维护 所有技能。 1.2 测试的目的是什么 测试的目的是为了发现尽可能多的缺陷，不是为了说明软件中没有缺陷。 推论：成功的测试在于发现了迄今尚未发现的缺陷。所以测试人员的职责是设计这样的测试用例，它能有效地揭示潜伏在软件里的缺陷。 千万不要将“测试”与“演示”混为一谈。例如科研鉴定会。 如果产品通过了严格的测试，大家不要不吭气，应当好好地宣传一把 。 1. 测试的常识与道理 1.3 一些常识和经验之谈 测试能提高软件的质量，但是提高质量不能依赖测试。 测试只能证明缺陷存在，不能证明缺陷不存在。“彻底地测试”难以成为现实，要考虑时间、费用等限制，不允许无休止地测试。我们应当祈祷：软件的缺陷在产品被淘汰之前一直没有机会发作。 测试的主要困难是不知道如何进行有效地测试，也不知道什么时候可以放心地结束测试。 每个开发人员应当测试自己的程序（份内之事），但是不能作为该程序已经通过测试的依据（所以项目需要独立测试人员）。 80-20原则：80％的缺陷聚集在20％的模块中，经常出错的模块改错后还会经常出错 测试应当循序渐进，不要企图一次性干完，注意“欲速则不达”。 2. 测试的分类与比较 2.1 测试方式 白盒测试：关心软件内部设计和程序实现，主要测试依据是设计文档 黑盒测试：不关心软件内部，只关心输入输出，主要测试依据是需求文档 2.2 测试阶段 单元测试、集成测试、系统测试、验收测试。是“从小到大”、“由内至外”、“循序渐进”的测试过程，体现了“分而治之”的思想。 单元测试的粒度最小，一般由开发小组采用白盒方式来测试，主要测试单元是否符合“设计”。 集成测试界于单元测试和系统测试之间，起到“桥梁作用”，一般由开发小组采用白盒加黑盒的方式来测试，既要验证“设计”又要验证“需求”。 系统测试的粒度最大，一般由独立测试小组采用黑盒方式来测试，主要测试系统是否符合“需求规格说明书”。 验收测试与系统测试非常相似，主要区别是测试人员不同，验收测试由用户执行。 2. 测试的分类与比较 2.3 开发与测试的 V 型关系 如果软件开发过程采用严格的瀑布模型，那么开发与测试有“V”型的对应关系 。 2. 测试的分类与比较 2.4 测试内容 接口与路径测试。 功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、压力测试、可靠性测试、安装/反安装测试… 2. 测试的分类与比较 2.5 问题 问题1：有了“黑盒”测试为什么还要“白盒”测试？ 黑盒测试只能观察软件的外部表现，即使软件的输入输出都是正确的，却并不能说明软件就是正确的。因为程序有可能用错误的运算方式得出正确的结果，例如“负负得正，错错得对”，只有白盒测试才能发现真正的原因。 白盒测试能发现程序里的隐患，象内存泄漏、误差累计问题。在这方面，黑盒测试存在严重的不足。 问题2：由于单元测试要写测试驱动程序，非常麻烦，能否等到整个系统全部开发完后，再集中精力进行一次性地单元测试呢？ 如果这样做，在开发过程中，缺陷会越积越多并且分布得更广、隐藏得更深，反而导致测试与改错的代价大大增加。最糟糕的是无法估计测试与改错的工作量，使进度失去控制。因此为图眼前省事而省略单元测试或者“偷工减料”，是“得不偿失”的做法。 问题3：如果每个单元都通过了测试，把它们集成一起难道会有什么不妥吗？集成测试是否多此一举？ 要把N个单元集成一起肯定靠接口耦合，这时可能会产生在单元测试中无法发现的问题。例如：数据通过不同的接口时可能出错；几个函数关联在一起时可能达不到预期的功能；在某个单元里可以接受的误差可能在集成后被扩大到无法接受的程度。所以集成测试是必要的，不是多此一举。 2. 测试的分类与比较 2.5 问题 问题4：在集成测试的时候，已经对一些子系统进行了功能测试、性能测试等等，那么在系统测试时能否跳过相同内容的测试? 不能！因为集成测试是在仿真环境中开展的，那不是真正的目标系统。再者，单元测试和集成测试通常由开发小组执