对软件测试感兴趣的进来聊聊

死机了怎么办_2

做软件的无非是开发和测试，除了那些扣上“经理”帽子的。
其中，很多人喜欢开发，喜欢设计，喜欢……而测试则又苦又累，又容易跟开发人员结下梁子。
但测试在软件工程中却又必不可少，Microsoft等大公司对测试这部分的投入力度相当大，稍微规范一点的公司也都很重视这一环节。
不知这里有没有对这感兴趣的？
说点感想、经验分享一下。

ganjike

这方面的确了解得不多。
我接触的公司很少有独立的测试部门的。
在vs2005 team 般中就有专门的测试部分，可惜不太会用。

对于专业测试这方面了解不多，
说说自己在软件开发过程中的测试，
大家都知道测试分为白盒，黑盒，
我觉得白盒测试主要在程序员编码过程中实现，在写程序的时候每一行有结果的语句都要考虑
成功怎么处理失败怎么处理。当你编程经验很丰富的时候就自然会忽略不需要的错误处理。
而当你经验不丰富的时候就不能随便忽略错误处理，否则你会死的很惨。
当有更牛的人负责这个项目的时候，在程序员自己测试失败又解决不了的时候，找他，帮你看代码。

黑盒测试就比较难了，估计公司的测试部门就是做这个的。
首先要想测试好软件，你必须对软件的功能有相当的了解，也就是业务熟悉，
因为你不仅要找出技术上错误，还要找出逻辑上的错误。只有你对业务很熟悉，
这样才能找出业务上的逻辑错误。

我提几个找错误方法，
1、在一台最基本的机器上只有操作系统的机器上对软件进行安装测试。
这样能测出你的软件需要什么东西，而你的软件包中没有带。一般用相关工具能得到。如vc6中工具depends
2、当你的软件需要什么支持的时候，就不给他相关支持，看看能否正常处理（提示相关错误，退出）。
比如没数据库，有库没有表，有表没有字段，表全没有数据等。需要配置文件ini或注册表时文件不存在或注册表项为空。
3、不按正常操作顺序操作软件。数据量过大测试(压力测试)，网络（把网线拔下来再接上）不正常时的测试。
用hub,先让几台机器拷贝大量文件把网络带宽都占上然后再测试网络功能。
4、这个测试根你的业务关系非常大，就是测试符合你的业务逻辑但是中间提供的数据异常，看你的结果是否
正确。这个没法具体说。
5、还有就是程序稳定性，是容错方面的能力，不是软件测试了。比如用软件故障注入的方法看软件的稳定性。

死机了怎么办_2

谢谢ganjike兄弟回答。但你对白盒的理解可能有些出入，估计是跟unit testing 混了吧。程序员做开发，自己都已快崩溃了，让他做Unit testing他能老实照做已经很不赖了，把白盒交给他，他只会欣赏自己的代码，而很少有人能主动找错排错。实际上，不管黑白盒，在规范、成熟一点的公司，都是交由专门人员负责的。

黑盒不是太难。因为功能测试是根据需求规格说明书来做的，在需求量化程度和可测性较高的前提下，对照着需求去测就是了。然而，这个前提也不大好办，我看过的很多需求都写得“简练”之极，Infosys他们用500条来具体化的需求，他们只用一两话带过，文档编写者轻松了，但测试员根本无法入手。

后面几个，在测试里面都有提到的，有些还是非常基本的。稳定性其实一般也包括在测试范畴里。

该写用例了，待会儿再谈。顺便ganjike兄弟也可说说对用例设计、管理、实施和自动化等方面的看法。

ganjike

你说的太专业了。很多东西我都不了解。
我虽然在300多人软件企业做过开发，但是他们的开发很不规范。

没有在规范的开发公司工作的经历是我的遗憾，不过我所在的地方也没有这样的公司。
有机会一定到这样的公司学习学习。

程序员做自己的测试，是一种责任的表现，也是对自己负责。
不过现在的人普遍都没有责任感，能推卸就推卸。

我经常对下边的人说写代码一定要清楚自己在写什么，每一行代码功能都要明白，
否则即使你把功能实现了，也会有潜在的问题。不过工作压力特别的大的时候没有时间和精力做到这一点。

我有一个问题如果白盒测试给测试员来做的话，如果测试员的编程水平比程序员的低那么，他很难看懂
程序员的代码，那么如何进行测试？如果他的水平高，那么他会有更好的算法来实现程序员的代码，那不如让
测试员来开发。

我最多的时候有6个学生参与一个课题的开发工作，模块划分，接口定义，我都做的很好，
版本管理用sourcesafe ，就是最后测试这部分工作没有安排好。

今年毕业的学生中有个到威盛电子做软件测试去了，等他工作一段时间向他学习学习如何进行测试的。

[ 本帖最后由 ganjike 于 2006-7-27 12:17 编辑 ]

死机了怎么办_2

“程序员做自己的测试，是一种责任的表现，也是对自己负责。”――这句话有问题。当初Microsoft在90年代初期吧，也没有雇用测试员，往往一个近百人的开发团队，编程的占了60%，设计、写文档，甚至打杂的都占一定比例，就是没有测试，因为管理层觉得这样一大笔开销根本不值得，结果在IE还是OFFICE我忘了，反正一个团队的工作出了大问题，从那开始才引入测试部门。不让程序员自己做测试（不包括UT），是基于人的普遍心理特征，也是从整个软件工程流程来考虑的。第一个，“人莫知其子之过，莫知其苗之硕”，这是几乎不可避免的一种心理，不管他做什么工作。第二个，测试并不是在开发工作结束后才开始的，而是整个项目一开始就要着手。这里关系到测试的内容问题。一般的观点仅仅把对成品软件的测试当作测试，实际上现在国际上通行的看法是：需求、设计、开发及其产品都是测试的内容。举个例子，对于需求的可测性的测试是一个重要方面，项目临近结束时还有文档测试等。

“我有一个问题如果白盒测试给测试员来做的话，如果测试员的编程水平比程序员的低那么，他很难看懂程序员的代码，那么如何进行测试？如果他的水平高，那么他会有更好的算法来实现程序员的代码，那不如让测试员来开发。”――程序员所要提交的不止是程序，还有相应的文档，“文档化”是软件工程的一个重要要求。此外，在进行白盒测试时，测试员所要参考的资料包括了概要设计和详细设计报告（这两者也经过一致性测试，内容上应该保证一致性和连贯性），这里对功能模块或类定义的详细说明将会帮助他看懂代码。假如代码并未严格按照详细设计报告来编写，测试员也有责任把这一结果当做BUG报告上去。

我在的公司，在测试某一软件的时候，是需要先对测试员进行一段时间的评估和培训的，用以保证选拔出符合该项目基本要求的人员，以及在此基础上通过培训达到项目的实际要求。国内很多公司可能一般没这么严格，一为省钱，二为赶进度，也是没办法的事情，可以理解。另外，人员的安排也不是固定的，根据其特长和意向等可做适当调整。

ganjike

受益匪浅

ganjike

原帖由 死机了怎么办 于 2006-7-27 12:52 发表
我有一个问题如果白盒测试给测试员来做的话，如果测试员的编程水平比程序员的低那么，他很难看懂程序员的代码，那么如何进行测试？如果他的水平高，那么他会有更好的算法来实现程序员的代码，那不如让测试员来开发。”――程序员所要提交的不止是程序，还有相应的文档，“文档化”是软件工程的一个重要要求。此外，在进行白盒测试时，测试员所要参考的资料包括了概要设计和详细设计报告（这两者也经过一致性测试，内容上应该保证一致性和连贯性），这里对功能模块或类定义的详细说明将会帮助他看懂代码。假如代码并未严格按照详细设计报告来编写，测试员也有责任把这一结果当做BUG报告上去。

我本身对软件工程这方面了解的不多，因为我觉得这方面知识是通过经验的积累，自然
形成的能力或知识，而不是从书里能学到的。如果你没有多年的经验很难对这方面有深刻的理解。
我比较喜欢从实践向理论总结。

做一个软件，即使你没有写任何文档，这样的文档还是存在的，是存在于软件开发者的头脑中。
只是没有形成文字材料。

文档化的确是个难题，特别是详细设计，因为做一个详细设计文档，相当于把软件实现了一遍。
除了细节性代码，软件的总体构架，主要算法，接口方式，甚至许多非常小功能的数据结构和
过程代码都设计好了。
如果你按照这个设计写代码，相当于把软件做了两边。当然能做到这一点是很好的，我是赞成的。

第一、如果你做的软件很有延续性，则这样做有好处，但是国内大多数软件都是工程性的或者说一次性的。
可能有部分代码可以重用，但是能够重用的不太多，或者不能够总结出重用代码。这样详细文档的代价
就高了。所以多数软件公司只是招来有经验的程序员做开发。因为有经验的程序员需要文档会少一些。

第二、软件产品是有技术含量的即使把所有的代码和文档都给你看，如果你没有一定的基础，还是
很难理解的。我认为软件产品的核心技术只掌握在少数人手里，这些人在其他人的帮助下实现软件，
即使没有其他人帮助，给这些人足够的时间他们自己也能做出这个软件来。但是其他人即使你给他
全部文档他在短时间内只能理解一部分。不可能把这个软件做出来。而软件设计者写文档的时候，
可能写道他们能理解就可以了。详细文档是软件的核心，我想不是任何一个开发人员都能看到核心的
东西吧。

第三、不同技术水平的人需要文档的详细程度也不一样。这个问题很难处理，
当你设计详细文档的时候写道什么程度，这也是我一直苦恼的问题。有些人
我简单描述一下，然后直接定义接口，他就能按照我的想法把功能实现，而且
他可能会提出更好的建议，这样这部分详细设计是我们两个人做的。
而另一些人，我只能非常详细跟他说实现的细节，这个详细设计是我自己做的。


我还是支持做测试的，但是由于文档化的困难，导致测试也很难。

narisu_2

原帖由 ganjike 于 2006-7-27 13:41 发表
受益匪浅

恩  继续