测试过程与方法，说说您的心得体会 送《Google软件测试之道》（获奖名单公布-11-11）

qinyiwang

1、开发过程中开发人员对测试的参与度以及测试方法：
    开发在提交版本给测试前，自己完成单元测试和集成测试。但是似乎对单元测试不够重视，花在这上面的时间较少；而用在集成测试的时间相对很多，因为涉及到不同人的工作的整合，工作量就大。
    单元测试从头到尾几乎就是某个开发自己的封闭开发，很少将各限制考虑周全；集成测试前开发会稍微写一些测试用例用于检测各模块。等集成测试差不多了就提交给测试人员去做系统测试了。
    在一些检查代码规范、边界值等方面有过借助工具，在集成测试过程中也会涉及到部分性能测试，如数据库。

    当然要补充两点：
1）. 有的时候，如果开发的过程非常匆忙，甚至代码的review也做的不到位，那么即使测试在早期发现了许多问题，那么dev在修改时候要大改，还会牵一发而动全身，这样会很不值的，对项目影响甚大；
2）. 测试团队在实际的测试中早几个版本时，发现的问题会相对较多些，有些甚至block。在之后的版本会稳定许多，defect的级别会低许多。

2、 使用python,autoit等脚本语言做自动化测试
    功能测试多为手工的测试，即使是加入了自动化的方法，也只有部分能用，像什么检查UI的这种，全靠肉眼；而性能测试涉及到多种编写脚本和使用工具。感觉python用到的地方较多。当然了，如果纯粹想减少点手工work，用个按键精灵帮你点点好了


3、单元测试在实际项目中的使用度
    前面也提到了，单元测试是很重要的，但是似乎开发不够重视。而且一般做一个完整的项目，开发的人数会多于QA，单元测试这种，多在开发自己内部消化了，QA几乎就只能黑盒了。往往快提交系统测试了，开发内部才开会进行代码review，这时候会发现诸多潜在问题。

当然，上述个人写的都是基于对软件的测试。

infoback

看了很多网友的回帖，发现大家都很踊跃，这里我再发表下我的看法，希望能和大家共同交流，正如我之前所说的，功能测试对一款好的产品是非常重要的，除此之外，我们要宏观滴看待测试这个环节，我们将测试分成单元测试，功能测试，集成测试，场景测试盒系统测试，分成这些，就更方便来回答第一个问题：

1）开发过程中开发人员对测试的参与度以及测试方法
其实大家可以从这个表格中看出测试具体规划：
单元测试                  在最低的功能/参数上验证程序的准确性,比如测试一个函数的正确性(开发人员)
功能测试                  验证模块的功能  （测试人员+开发测试人员人员）
集成测试                  验证几个互相有依赖关系的模块的功能 （测试人员+开发测试人员人员）
场景测试                  验证几个模块是否能完成一个用户场景 （测试人员+开发测试人员人员）
系统测试                  整个系统功能的测试 （测试人员）
Alpha测试               软件测试人员在真实用户环境中对软件进行全面的测试 （测试人员）
Beta 测试               真实用户在真实的用户环境中进行的测试  （最终用户+开发测试人员人员）
正如我之前所说的，要有开发测试人员这个角色，这个角色不仅可以很好的将开发和测试融合起来，这样不仅方便不同功能和人员进行够沟通，也可以更好的参与到功能，集成和场景测试中，而对于开发人员，则更好滴在单元测试这个测试点上完善软件健壮性和功能性，而且很多人也从心理觉的角度进行观察，得出单元测试和集成测试通常应由开发小组执行，开发人员测试自己的工作成果虽然是必要的，但不能作为成果已经通过测试的依据。那对于最正统的开发人员如何做好我们的功能测试，就显得特别重要，这里先不涉及开发测试的测试方法论。
单元测试是什么意思呢？单元测试是对软件基本组成单元/模块进行的测试，又称为模块测试。基本单元/模块可以是函数、类实例、方法、存储过程，也可以是任何具有明确功能、规格定义、明确接口定义、并且其规模是一般比较小的程序代码模块的组合体。
单元测试的重点在于发现程序设计或实现的逻辑错误，使问题及早暴露，便于问题的定位解决。单元测试中多采用白盒测试和黑盒测试相结合的方法，既关注单元功能，也关注程序模块的逻辑结构。两者结合起来，既可以避免由于过多关注路径而导致测试工作量很大的问题，又可以避免因从外部设计测试用例而可能丢失一些路径的问题。单元测试的重点应该以功能测试为主，同时统计测试的覆盖率，并且测试模块的输入/输出接口是否正确，内部的数据流是否正确等。
单元测试的步骤应该分为：① 计划 (确定测试所用资源（如人员、设备等）)-> ② 设计(设计单元测试模型) -> ③ 执行 (执行测试用例)-> ④ 评审(进行测试完备性评估)

2）使用python,autoit等脚本语言做自动化测试
在过去的十五年里，人们编写计算机程序的方法发生了根本的转变。这种转变是从c或c++等系统程序设计语言到Perl或Tcl等脚本语言的过渡。其实脚本语言和系统程序设计语言互为补充，而因为脚本语言的编写的易用性和高效独立性，对后端的测试是非常有帮助的。系统编程语言在从头开始构建方面和性能方面会更好点。而脚本语言在重用代码和快速开发方面有优势，是理想的自动化测试语言。
之前说过用过QTP这样的软件进行脚本测试，那么这次我谈谈我用过的一些脚本语言测试的感悟
Perl ：在主要流行的脚本语言当中，语法，功能，效率三方面的赢家，非常均衡，而且易学我觉得。唯一遗憾的是，需要安装Tk扩展包，才能有图形化界面，如果能封装好，原生提供，那我想是极好的~总之非常不错，推荐。
C shell： 来源于C语言，所以对C语言有很好的延伸性和传承性，易上手，在特定的环境下进行自动化测试非常省时省力。
VBA： Excel御用脚本大将，褒贬不一，在Office中做脚本测试或者是宏，还是非常赞的，对于一些数据密集型软件的测试，开放API后，用VBA进行测试，其实可以大大方便本身是黑盒测试人员的上手。

3）单元测试在实际项目中的使用度
单元测试是软件测试的基础，因此单元测试的效果会直接影响到软件的后期测试，最终在很大程度上影响到产品的质量。单元模块运行设计第一个测试用例。第一个测试用例一般是使用最简单的方法执行被测单元。当这个用例可以执行时，就能确定测试环境和测试单元是可用的。同时，我强调设计被测试单元测试用例的重要性。要阅读相关的设计说明，对每一个测试用例都有有针对性地测试，根据说明书中的一项或者多项内容，用以验证设计说明书所对应的功能是否实现。第三步是设计测试功能异常处理方面的测试用例。用可能导致模块功能失效的无效数据，测试模块对无效数据的反应是否合理，以及对异常或错误的处理后模块的反应如何，验证模块有没有做不应该做的工作。之后设计其他的测试用例，验证设计对模块的要求。例如计算精度、性能、可恢复性、安全性等。当设计完用例后，加载测试用例运行程序，需要查看和记录测试结果。最后就是补充测试用例，执行前面测试用例运行没有覆盖到的主要分支和语句。

qinyiwang

楼上谈得好多呀，有些语言很学术