- 1、本文档共31页,可阅读全部内容。
- 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
查看更多
必威体育精装版版强大的软件测试新手学习宝典要点
Page * 目录 1. 测试的常识与道理 2. 测试的分类与比较 3. 测试人员的组织 4. 企业的测试策略 5. 测试规范 6. 软件产品的主要测试内容及技术 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个单元集成一起肯定靠接口耦合,这时可能会产生在单元测试中无法
文档评论(0)