我给人员培训的测试讲稿

冰封伯爵

step365he

我给人员培训的测试讲稿
1．黑盒测试/白盒测试
在黑盒子测试中，软件测试人员只需要知道软件要做什么即可，而无法看到盒子中是如何运作的。只要进行一些输入，就能够得到某些输出结果。我们不用知道软件是如何运行，为什么这样运行。只是知道程序能够做些什么。
白盒子测试中，测试人员可以访问开发人员的代码，并且通过检查代码来协助测试。通过察看代码，来调整测试程序。
2．静态测试/动态测试
静态测试意思是测试不运行的部分——检查文档和代码
动态测试意思是运行程序
3．静态黑盒子测试——测试需求说明书
1）设身处地为客户着想：把自己作为客户，最好能够熟悉客户领域的知识。
2）研究现有规范和标准。标准和规范的差别在于程度不同。标准比规范更加确定。标准要必须遵守，规范是可选的，是应该遵守。
3）研究类似的程序或者旧版本的程序，为新的项目积累经验。
4）静态黑盒子测试的成果是检查单，通过里面各个项目的检查，能够将需求说明书的作用发挥最大。
4．静态白盒子测试——检查设计文档和代码
通过察看设计文档，程序体系结构，代码，从而找出软件缺陷。它能够找出动态黑盒子测试难以发现的软件缺陷。一般是在开发过程中从底层开始进行。还有一个好处就是，可以为动态黑盒子测试提供思考问题的角度。
这种测试方式的组织结构可以有专门的代码检查小组担任，也可以用开发人员互相负责，也可以由测试人员来负责。
最容易遇到问题的就是不能善终；很多人觉得耗费时间，耗费人力。。。。。。
步骤：
1）确定问题——明确一个中心，代码，不能把问题转移到开发人员身上，不能有个人情绪
2）遵守流程——因为如果执行过程不正规，会遗漏软件缺陷，而且会让开发人员感觉这样做是浪费时间。而且会变成休息聊天
3）准备——为了提高效率，事先充分做好准备
4）编写报告——这部分工作的目的是将产生的问题和经验给其他人员共享。
5．动态白盒子测试——通过对代码分析来运行程序
这部分可以从三个角度进行：
1）编写测试程序，测试每一个单元，测试API
2）获取程序中各个变量以及程序状态信息，以便确定测试和预期结果是否相符合
3）代码覆盖分析——设法进入和退出每一个模块，执行每一行代码，追踪每一条逻辑和决策分支，甚至各种条件。 （代码行覆盖， 路经覆盖，条件覆盖。。。）
6．动态黑盒子测试——测试人员充当客户使用程序；测试工作就是进行输入，接受输出，检查结果。

软件测试，你必须了解的一些问题
1）完全测试是不可能的
输入量太大，输出结果太多，软件实现途径太多，需求文档和设计文档标准不统一，导致缺陷的标准也不同。
2）软件测试有风险
不能完全测试，但不测试又会遗漏缺陷，怎么办？
一个原则既是尽量把风险减少到可以控制的范围。如果完全测试，成本大幅增加，而软件缺陷遗漏的数量不会明显下降；如果简单测试，成本很低，而软件缺陷遗漏的数量是巨大的。因此，我们的目标是找到一个合适的测试工作量。
3）测试不能挖掘出潜伏着的软件缺陷
软件测试可以报告已经发现的软件缺陷，但是不能报告潜伏着的软件缺陷，因此不能保证软件缺陷全部找到。唯一可以做的就是继续测试，可能还会发现一些。
4）发现缺陷越多，隐藏的缺陷也就越多
开发人员劳累过度；
开发人员容易反复犯下自己容易犯的错误，因为习惯是很顽固的；
某些缺陷可能是其他缺陷的预言，似乎刚开始这些缺陷没有关联，但是最后发现它们是由一个非常严重的缺陷造成的。
5）并非所有软件缺陷都能够修复
因为没有完美的程序，所以我们要根据风险决定哪些缺陷需要修复，哪些不需要修复。
可以有下面四个策略进行分析：
——项目时间是否允许：软件功能还没有实现，导致没有时间修复缺陷
——有些缺陷最后变成了某个功能/或者取消了某个功能
——修复的风险太大，因为在紧张情况下，修复一个缺陷可能导致其他软件缺陷出现。所以在发布进度压力下，不去理睬一个缺陷，可以避免出现其他未知缺陷；一些很少出现的缺陷/在次要功能出现缺陷可以放过；
——我们可以躲过，或者用户可以避免/预防的缺陷也可以不用修复。这点往往是从商业角度考虑
6）如果确实有缺陷存在，但是没有人发现，那么算不算软件缺陷？只有发现的才算是“软件缺陷”，没有发现的算“未知软件缺陷”
7）软件测试不容易受欢迎
——尽可能早点发现缺陷，让开发人员有时间处理
——控制测试人员的情绪
——不要总是报告坏消息
8）软件测试有抗药性
常用一种农药杀害虫，害虫就有了抵抗力，农药也就失效了。软件测试也是一样的。测试人员应该常常变化测试角度，测试数据，测试方法


下一篇：林泰龙系列之压力测试、绩效测试与负荷测试

冰封伯爵

step365he



这篇文章中，
步骤：
1）确定问题——明确一个中心，代码，不能把问题转移到开发人员身上，不能有个人情绪
2）遵守流程——因为如果执行过程不正规，会遗漏软件缺陷，而且会让开发人员感觉这样做是浪费时间。而且会变成休息聊天
3）准备——为了提高效率，事先充分做好准备
4）编写报告——这部分工作的目的是将产生的问题和经验给其他人员共享。
有家公司每次项目结束后，开发、测试之间就开始对bug进行讨价还价：从责任归属到bug等级，以及原因；而且不是小会能解决，往往一连好几次冗长会议才能达成一致。这种现象就是四个步骤没有落实必然产生的。此外，惩罚制度的滥用和奖励的吝啬，容易让人见到‘责任’，就像遇见了鬼。

冰封伯爵

jane



写得很全面哦，不过实际中对BUG的汇报还是很有难度，或者说开发人员与测试人员很难走到一块儿去，除非是客户的满意度严重下降，才会让开发人员关注测试结果。不然还是各自忙各自的，测试人员有种无用功的滋味。

step365he

目前一种情况是奖赏重开发，轻测试；处罚轻开发，重测试。
这类企业的领导认为开发人员对产品的重要性是第一位的，更深层次的原因是开发人员的走留，或者工作态度对企业的产品有着决定因素。很显然这类企业的成熟度很低。
或许我写的这份培训讲稿也适合给领导们普及基础。

ps. 我这个讲稿是以《软件测试》为蓝本的。

[ 本帖最后由 step365he 于 2008-5-5 22:47 编辑 ]

yesongke

原帖由 step365he 于 2008-5-5 22:45 发表
目前一种情况是奖赏重开发，轻测试；处罚轻开发，重测试。
这类企业的领导认为开发人员对产品的重要性是第一位的，更深层次的原因是开发人员的走留，或者工作态度对企业的产品有着决定因素。很显然这类企业的成熟度 ...

很正常，软件质量是做出来滴，而不是测出来滴。。。
但是开发人员多数存在把控制软件质量的任务交给测试人员的思想，造成了测试工作压力过大。

lee_huo

测试还应该有个工作，总结缺点根源，总结缺陷类型；然后可以把这些问题的根源或缺陷类型提交给研发主管，或开展有针对性的培训，避免同样的缺陷在接下来的项目中再次发生。作为测试的主管或测试的培训者应该有义务告诉测试人员做这样的同样有意义的工作

liulanger888

完全测试是不可能的:victory:

chenxin9821

:110)

都是经验谈啊，想必楼主没少吃苦头吧，辛苦啊！

jiayan2000cn

好东西!谢了!

yjs916

很不错的

butterfly

学习了 不错

chenxin9821

从商业角度看问题

chenxin9821

楼主还活着吗！出来玩呀！

blueteer

测试还应该有个工作，总结缺点根源，总结缺陷类型；然后可以把这些问题的根源或缺陷类型提交给研发主管，或 ...
lee_huo 发表于 2008-7-12 15:27

这点很值得学习哈！