| 查看: 721 | 回复: 8 | |||
| 【奖励】 本帖被评价1次，作者raulsyp增加金币 0.5 个 | |||
| 当前主题已经存档。 | |||
[资源]
【读书日记】apple20028183的读书日记 3月31日 更新见9楼
|
|||
|
我这个不知道符合不符合要求，我看的是视频讲座，和大家分享吧，开此贴也作为对自己的督促 书籍名称：软件测试视频教程 作者：李哲洙 东北大学网络学院 附件里是我的学习笔记 下载地址里今天看所看的视频 第一次发带附件和网址的帖子，不知道发的对不对，请见教 其实今天看的这几个视频具体的内容并不是很多，就是课程的一些介绍和基础知识 PS：压缩文件要解压到根目录下才能看，点击那个content.htm的文件，然后允许插件运行就好了，希望对大家有帮助 http://www.namipan.com/d/9e688b8dab94a06796e1c4cfa7fdc55fcc428717a943b902 http://www.namipan.com/d/00e0c6e51803fd3abb93e6b82571e393ea86fe4315a77902; http://www.namipan.com/d/3dd8e4755a9ed68c9a83195e3a45b8bab4abed7556187402; [ Last edited by raulsyp on 2009-3-31 at 09:17 ] |
回复此楼» 猜你喜欢
假如你的研究生提出不合理要求
已经有9人回复
-
萌生出自己或许不适合搞科研的想法，现在跑or等等看？
已经有4人回复
-
Materials Today Chemistry审稿周期
已经有4人回复
-
参与限项
已经有3人回复
-
实验室接单子
已经有4人回复
-
全日制（定向）博士
已经有4人回复
-
对氯苯硼酸纯化
已经有3人回复
-
求助:我三月中下旬出站，青基依托单位怎么办？
已经有12人回复
-
所感
已经有4人回复
-
要不要辞职读博？
已经有7人回复
★
signal023(金币+1,VIP+0):幸苦了~ 3-20 08:33
signal023(金币+1,VIP+0):幸苦了~ 3-20 08:33
|
05_09_04_1 软件开发的现状： 软件开发现状分析： 软件测试的背景： 为什么需要软件测试： 什么是软件缺陷：软件未达到需求分析说明书的要求； 05_09_04_2 什么是软件缺陷： 为什么会出现软件缺陷： 一个测试生命周期： 测试过程可以分为如下步骤： 测试计划 测试用例开发 运行测试用例 评估测试结果 软件测试的修复费用：发现缺陷越早修复费用越少 软件测试员工作责任： 软件测试员的目的： 找出软件缺陷，尽可能早一些 怎样成为优秀软件测试员： 软件测试员应具备的素质： 探索精神； 故障排除能力； 不懈努力； 创造性； 追求完美； 判断准确； 老练稳重； 说服力； 05_09_04_3 软件开发过程简介： 构成软件产品的主要部分； 制作软件产品的人和技术； 软件从构想到最终产品的过程； 构成软件产品的主要部分： 功能需求书 项目计划 软件设计文档 测试文档 用户手册 安装、维护手册 白皮书 软件项目成员： 项目管理员（PM、PSM） 设计师 程序员 测试员 技术助理 配置管理员 软件开发模式 瀑布开发模式 原型开发模式 RUP开发模式（重型） XP开发模式 迭代开发模式 组件开发模式 测试级别和测试种类  测试术语：黑盒测试与白盒测试、静态测试与动态测试、测试用例 黑盒测试：在黑盒测试中，软件测试员只需知道软件要做什么即可—而无法看到盒子是如何运行的。只要进行一些输入，就能得到某种输出结果。 白盒测试：在白盒测试中，软件测试员可以访问程序员的代码，并通过检查代码来协助测试—可以看到盒子里面。根据代码检查结果判断多大的数据可能出错，并据此调整测试程序。 静态测试：静态测试是指测试不运行的部分—只是检查和审阅。 动态测试：动态测试是指通常意义上的测试—运行和使用软件。 测试用例： 软件测试的本质是针对要测试的内容确定一组测试用例，在测试中占据中心地位。 测试用例包含的信息： 输入：前提（在测试用例执行之前已经存在的环境）和由某种测试方法所标识的实际输入 输出：后果和实际输出 测试用例的重要性： 只做测试用历史软件测试员最重要的一项任务。不正确的选择可能导致测试量过大或者过小，甚至测试目标不对。 测试员能准确评估风险，把不可穷尽的可能性减少到可以控制的范围是成功的诀窍。 测试人员的数学背景 测试工作注意事项 总结： 什么是软件缺陷； 软件测试的重要性； 软件质量的全面管理； 软件测试员的数学背景； 软件测试员需要具备的技术与人文素质； [ Last edited by 2007mky on 2009-3-19 at 23:23 ] |
2楼2009-03-19 23:12:14
3楼2009-03-20 11:40:29
4楼2009-03-20 21:24:03
★
2007mky(金币+1,VIP+0):谢谢更新日记！望再接再厉！ 3-20 21:48
2007mky(金币+1,VIP+0):谢谢更新日记！望再接再厉！ 3-20 21:48
|
今日更新，本来想继续听开始的那个，但是那个视频总是卡，只能听前十分钟，所以又选了一个视频 听从版主建议把学习笔记直接贴出来了，视频还是上传到我的纳米盘了，欢迎批评指正。 今天学习的视频时希赛的一个老师讲的软件设计师考试中关于软件测试的内容。 第四章 系统开发与软件工程 4.6软件测试与维护 1、软件测试基础 测试目标：以尽可能少的时间和人力发现软件产品中尽可能多的错误 测试用例：测试用例是由测试数据和预期结果构成的 eg：函数ADD（X,Y）的测试用例—X=3，Y=4，R=7 如何衡量一个测试用例的好坏： 成功的测试：发现了至今为止尚未发现的错误的测试 高效的测试：用少量的测试用例，发现被测软件尽可能多的错误 一个规范化的软件测试过程包括以下活动： ① 制定测试计划：包括测试内容、进度安排、测试所需环境和条件、测试培训安排 ② 编制测试大纲 ③ 根据测试大纲生成测试用例 ④ 实施测试 ⑤ 生成测试报告 软件测试的原则： ① 应该尽早地、不断地进行软件测试，把软件测试贯穿于开发过程的始终 ② 所有测试都应该能追溯到用户需求。从用户的角度看，最严重的错误是导致软件不能满足用户需求的那些错误。 ③ 应该从“小规模”测试开始，并逐步进行“大规模”测试。 ④ 应该远在测试之前就制定出测试计划。 ⑤ 根据Pareto原理，80%的错误可能出现在20%的程序模块中，测试成功的关键是怎样找出这20%的模块。 ⑥ 应该由独立的第三方从事测试工作。 ⑦ 对非法和非预期的输入数据也要像合法的和预期的输入数据一样编写测试用例。 ⑧ 检查软件是否做了应该做的事仅是成功的一半，另一半是看软件是否做了不该做的事。 ⑨ 在规划测试时不要设想程序中不会查出错误。 ⑩ 测试只能证明软件中有错误，不能证明软件中没有错误。 测试的分类： 从测试阶段划分，可分为单元测试、集成测试、确认测试、系统测试 测试方法可分为：静态测试和动态测试两大类 静态测试是指被测程序不在机器上运行，而是采用人工检测和计算机辅助静态分析的手段对程序进行检测 人工检测（人工检测的主要方法有个人复查、抽查和会审三种） 计算机辅助静态分析 动态测试是指通过运行程序发现错误。 动态测试又可分为：白盒测试和黑盒测试。 2、软件测试步骤 从测试阶段划分，可分为单元测试、集成测试、确认测试、（系统测试） 单元测试（模块测试） 单元测试也称为模块测试，一般是在编程阶段完成，由程序员对自己编写的模块自行测试，检查模块是否实现了详细设计说明书中规定的功能和算法。 单元测试计划应该在详细设计阶段制定。 单元测试一般采用白盒测试。 单元测试期间着重从模块接口、局部数据结构、重要的执行路径、出错处理、边界条件等几个方面对模块进行测试。 模块接口测试：① 模块的输入参数的形式、个数、属性、单位是否一致。 ② 调用标准函数时所使用的参数、属性、顺序、数目是否正确。 ③ 全局变量在各个模块中的定义和使用是否一致。 ④ 输入是否仅改变了形式参数。 ⑤ 开关语句是否正确。 ⑥ 规定的I、O格式是否与输入输出语句一致。 ⑦ 使用文件之前是否打开了文件，使用文件之后是否关闭了文件。 局部数据结构测试：① 变量的说明是否合适。 ② 是否使用了没有赋值、没有初始化的变量。 ③ 变量的厨师之火默认值是否正确。 ④ 变量是否有错误。 重要的执行路经测试：计算、比较或流控制错误 计算：算术运算优先级次序不正确，理解错误，精度不够等 比较或流控制：eg：分支 出错处理 边界条件 驱动模块和桩模块： 集成测试（组装测试） 集成测试的主要任务是发现模块间的接口和通信问题。 集成测试主要发现设计阶段产生的错误，通常采用黑盒测试。 集成测试计划应该在概要设计阶段制定。 集成的方法可分为非增殖式和增殖式。 增殖式：① 自顶向下的增殖方式（构造桩模块较困难） ② 自底向上的增殖方式（主模块要到最后一步才测试） ③ 混合增殖式方式 ④ 衍变的自顶向下的增殖方式 ⑤ 自底向上—自顶向下的增殖方式 确认测试 确认测试的任务是检查软件的功能、性能和其他特性是否与用户的需求一致。 它是以需求规格说明书作为依据的测试，通常采用黑盒测试。 软件确认测试首先要进行有效性测试以及软件配置审查，然后进行验收测试。 确认测试一般由三个步骤：① 有效性测试 ② 软件配置审查 ③ 验收测试 α测试与β测试（当一个软件是作为产品被许多客户使用时需要用这种测试） 系统测试 系统测试的任务是把软件放在实际的硬件和网络环境中进行测试，主要测试软件的非功能需求和质量属性是否得到满足。 系统测试根据系统方案说明书来设计测试用例，通常采用黑盒测试。 常见的系统测试主要有：恢复性测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试。 恢复性测试：检测系统的容错功能。 安全性测试：检测系统的安全机制、保密措施是否完善，主要是检测系统的防范能力。准则是：非法入侵者所花费的代价比进入系统后得到的好处要大。 强度测试：对系统在异常情况下承受能力的测试，系统在极限状态下的运行性能下降程度是否在允许范围内。 性能测试：检查系统是否满足系统方案说明书对性能的要求，要覆盖到软件测试的各个阶段。 可靠性测试：检查系统的MTBF和MTTR值。 安装测试：检查在安装过程中是否有错误，安装过程的操作是否容易。 调试 调试的任务是根据测试是所发现的错误，找出原因和具体的位置，进行改正。 调试工作主要由程序开发人员来进行，谁开发的程序就有谁来进行调试。 常见的调试方法有以下几种： ① 试探法 ② 回溯法 ③ 对分查找法 ④ 归纳法 ⑤ 演绎法 [ Last edited by raulsyp on 2009-3-20 at 21:42 ] |
5楼2009-03-20 21:27:38
★ ★
nanzai(金币+2,VIP+0):谢谢更新日记！望再接再厉！ 3-24 23:01
nanzai(金币+2,VIP+0):谢谢更新日记！望再接再厉！ 3-24 23:01
|
周六、周日休息没有写读书日记 周一读书了，但是由于收到了趋势实习生的面试通知，所以没有更新 今天面试结束了，把昨天的补上，今天就忙着面试了，没有读关于测试的书 见谅 3、 黑盒测试 黑盒测试： 白盒测试： 黑盒测试在已知产品功能设计规格的基础上进行测试，以证明每个实现了的功能是否符合要求。 黑盒测试可以分等价类划分、边界值分析、错误推测法、因果图四种测试方法。 等价类划分：讲所有可能的输入数据，划分为等价的部分，然后从每个部分中选取少数有代表性的数据作为测试用例。 等价类可以分为有效等价类（合理的、有意义的数据集合）和无效等价类（不合理的、无意义的数据集合）。 在选取测试用例时，应遵从“设计一个新的测试用例时，应尽可能多地覆盖尚未覆盖的有效等价类，但每次应仅覆盖一个尚未覆盖的无效等价类”的原则。 等价类用例的生成有两大步骤 第一步：划分等价类。 划分等价类的原则如下： ① 如果输入条件规定了取值范围或值的个数，则可以确定一个有效等价类和两个无效等价类。 eg：函数能够对小于10000个数据的数列进行排序 设X为待排序数列的元素个数，则1≤X≤10000，则有效等价类是1≤X≤10000，无效等价类是X≤0和X﹥1000。 ② 如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确定一个有效等价类和一个无效等价类。 eg：银行卡密码每位数必须为0~9之间的数字 则有效等价类为0~9，无效等价类为非0~9之外的其他任何字符。 ③ 如果输入条件是一个布尔量，则可以确定一个有效等价类和无效等价类。 ④ 如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可以为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。 ⑤ 如果规定了输入数据必须遵循的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。 第二步：从划分的等价类中选择测试用例。 选择时应遵循以下原则： ① 为每一个等价类规定一个唯一编号。 ② 设计尽可能少的测试用例，覆盖所有的有效等价类。 ③ 针对每一个无效等价类，设计一个测试用例来覆盖它。 eg：三角形问题：接受3个整数a、b和c作为输入，用做三角形的边。整数a、b和c必须满足以下条件： c1：1≤a≤200 c2：1≤b≤200 c3：1≤c≤200 c4：a＜b+c c5：b＜a+c c6：c＜a+b 如果3条边相等，则程序的输出是等边三角形。 如果恰好有两条边相等，则程序的输出是等腰三角形。 如果没有两条边相等，则程序的输出是不等边三角形。 如果c4、c5和c6中有一个条件不满足，则程序输出的是非三角形。 则： 测试用例 a b c 预期输出 1 5 5 5 等边三角形 2 2 2 1 等腰三角形 3 3 4 5 不等边三角形 4 4 1 2 非三角形 5 -1 5 5 a取值越界 6 5 -1 5 b取值越界 7 5 5 -1 c取值越界 8 201 5 5 a取值越界 9 5 201 5 b取值越界 10 5 5 201 c取值越界 11 -1 -1 5 a、b取值越界 12 5 -1 -1 b、c取值越界 13 -1 5 -1 a、c取值越界 14 -1 -1 -1 a、b、c取值越界 边界值分析：对等价类划分法的一个补充，即选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据。 错误推测法：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。 因果图：因果图法是根据输入条件与输出结果之间的因果关系来设计测试用例的，它首先检查输入条件的各种组合情况，并找出输出结果对输入条件的依赖关系，然后为每种输出条件的组合设计测试用例。 4、 白盒测试（逻辑驱动测试） 在已知产品内部工作过程的基础上，通过测试证明每种内部操作是否符合设计规格要求 最常见的方法是逻辑覆盖法。所有要用的方法按覆盖程序从弱到强排序为：语法覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、路径覆盖。 语句覆盖：程序中的每一条语句都被执行一次。 判定覆盖：又称分支覆盖，它的含义是，不仅每个语句至少执行一次，而且每个判定的每种可能的结果（分支）至少执行一次。判定覆盖比语句覆盖强，但对程序逻辑的覆盖程度仍然不高。 条件覆盖：条件覆盖就是设计若干个测试用例，运行被测程序，使得程序中每个条件的可能取值至少执行一次。 判定-条件覆盖：同时满足判定覆盖和条件覆盖的逻辑覆盖称为判定-条件覆盖。它的含义是，选取足够多的测试用例，使得判定条件式中每个条件的所有可能结果至少出现一次，而且每个判定本身的所有可能结果页至少出现一次。 条件组合覆盖：就是设计足够多的测试用例，运行被测程序，使得每个判断的所有可能的条件取值组合至少执行一次。 路径覆盖：就是设计足够多的测试用例，覆盖程序中的所有可能的路径。 eg： 语句路径： (a→c→e) ={(A>1)and(B=0)}and{(a=2)or(X/A>1)} ={(A>1)and(B=0)}and{(A=2)or(A>1)}and{(B=0)and(X/A>1)} ={(A=2)and(B=0)}or{(A>1)and(B=0)and(X/A>1)} (a→b→d) =not{(A>1)and(B=0)}and not{(a=2)or(X/A>1)} ={not(A>1)or not(B=0)}and{not(A=2)and not(A>1)} ={not(A>1)and not(A=2)}and{not(X>1)or not(B=0)}and{not(A=2)and not(X>1)} (a→b→e) =not{(A>1)and(B=0)}and{(A=2)or(X>1)} ={not(A>1)or not(B=0)}and{(A=2)or(A>1)} ={not(A>1)and(A=2)}or{not(A>1)and(X>1)} or{not(B=0)and(A=2)}or{not(B=0)and(X>1)} (a→c→d) ={(A>1)and(B=0)}and not{(A=2)or(X/A>1)} ={(A>1)and(B=0)}and{not(A=2)and not(X/A>1)} 条件组合： (1)A>1,B=0为 (2)A>1,B≠0为 (3)A≤1,B=0为 (4)A≤1,B≠0为 (5)A=2,X>1为 (6)A=2,X≤1为 (7)A≠2,X>1为 (8)A≠2,X≤1为 假定测试用例的格式如下：输入的是[A，B，X]，输出的是[A，B，X]，为上图设计测试用例 语句覆盖测试用例：[2，0，4]，[2，0，3]，该用例可以覆盖路径：L1。 判定覆盖测试用例：[(2，0，4)，(2，0，3)]、[(1，1，1)，(1，1，1)]，则他们符合判定覆盖要求。此用例覆盖的路径为L1、L2。 条件覆盖测试用例： 测试用例 路径 条件取值 [(2，0，4)，(2，0，3)] [(1，0，1)，(1，0，1)] [(2，1，1)，(2，1，2)] 判定-条件覆盖测试用例： 测试用例 路径 条件取值 [(2，0，4)，(2，0，3)] [(1，1，1)，(1，1，1)] 条件组合覆盖测试用例： 测试用例 路径 条件取值 [(2，0，4)，(2，0，3)] [(2，1，1)，(2，1，2)] [(1，0，3)，(1，0，4)] [(1，1，1)，(1，1，1)] 路径覆盖测试用例： 测试用例 路径 条件取值 [(2，0，4)，(2，0，3)] [(1，1，1)，(1，1，1)] [(1，1，2)，(1，1，3)] [(3，0，3)，(3，0，1)] [ Last edited by raulsyp on 2009-3-24 at 21:53 ] |
6楼2009-03-24 21:51:04
7楼2009-03-24 22:29:43
2007mky(金币+0,VIP+0):谢谢更新，面试成功！good luck with you！ 3-26 18:58
|
今天没有看测试方面的内容了，看的是《算法设计与分析》和《高质量c++编程》。 两本书都是开了个头，前一本是中南大学上课用的课本，厚一本是林锐博士写的，网上都能够下载到电子版。算法呢，主要看的就内容就介绍了算法复杂度的度量，即我们平常所说的时间复杂度和空间复杂度的概念，其余的都是了解一下的内容，所有不再赘述，(*^__^*) 嘻嘻……。明天继续看，希望能有多一些的收获吧。 后一本书呢，看了两章，较之第一和第二版，第三版的前两章几乎是全新的内容，笼统介绍了软件的质量、软件工程的概况。本来以为今天能够看到一些关于C++的内容，但是我进度太慢了，(*^__^*) 嘻嘻……，不好意思。 对了，今天还接到电话通知说我昨天的面试通过了呢，好高兴哦 |
8楼2009-03-25 22:02:58
★
nanzai(金币+1,VIP+0):谢谢，学习了 3-31 16:09
nanzai(金币+1,VIP+0):谢谢，学习了 3-31 16:09
|
既然出了新规则，按照规则办事吧，还写我一开始的读书笔记，O(∩_∩)O~ 5、 软件维护 软件维护：在软件交付使用之后直至软件被淘汰的整个时期内为了改正错误或满足新的需求，而修改软件的活动 软件的可维护性：是指理解、改正、改动、改进软件的难易程度。根据Boehm质量模型，通常影响软件可维护性的因素有可理解性、可测试性和可修改性。 软件维护类型：根据引起软件维护的原因，软件维护通常可分为以下4种类型—改正性维护、适应性维护、完整性维护、预防性维护。 注意： ① 只有在软件生命周期的各个阶段都充分考虑维护问题，才能有效提高软件的可维护性。 ② 应用面向对象方法学能提高软件的可维护性。 ③ 结构化设计中注意模块化、信息隐藏、高内聚、低耦合等问题，对于提高软件的可理解性、可测试性和可修改性也都有重要的作用。 ④ 编写程序开发文档以及形成良好的编程风格有助于提高软件的可维护性。 软件维护管理：是指为保证维护质量、提高维护效率、控制维护成本而进行的维护过程管理它要求对软件的每次“修改”均需经过申请、评估、批准、实施、验证等步骤。 软件维护管理的核心是维护评估和维护验证。 维护评估的主要工作包括：判定维护申请的合理性与轻重缓急、确定维护的可行性与时间及费用、制定维护策略与维护计划。 维护验证主要是审查修改后的软件是否实现了维护目标、软件文档是否做了相应的修改。 4.7软件过程改进 CMM（软件成熟度模型） CMM模型描述和分析了软件过程能力的发展过程，确立了一个软件成熟程度的分级标准：初始级、可重复级、已定义级、可管理级、优化级。 关键过程域的分类： 等级\过程分类 管理方面 组织方面 工程方面 优化级 技术改进管理 过程改进管理 缺陷预防 可管理级 定量管理过程 软件质量管理 已定义级 集成（综合）软件管理 组间协调 组织过程焦点 组织过程定义 培训程序 软件产品工程 同级评审 可重复级 需求管理 软件项目计划 软件项目跟踪与监控 软件子合同管理 软件质量保证 软件配置管理 CMMI 2001年12月，SEI正式发布CMMI1.1版本，与原有能力成熟度相比，CMMI设计更广。 CMMI是作为评估标准出现的，所有内容都是必要的，这样才能保证评估的标准。 CMMI是作为改进模型出现的，罗列了较多的最佳实践，以利于过程的改进。 |
9楼2009-03-31 09:17:09