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

infoback

1、开发过程中开发人员对测试的参与度以及测试方法
作为一位一直从事测试转为开发的软件工程师，我自觉地对此有一定的发言权，对于开发而言，和测试的关注角度往往是不同的，我是从事消费类电子行业，而本身做的产品又是娱乐电子产品，往往测试是从宽度上去进行工作，而开发则是从深度挖掘问题，在生成demo版本的过程中，开发人员应该将可测试这个观点放入，在代码书写过程中，人为的加入可测试代码部分，用以方便快速的生成多个基于相同模块功能的软件版本，这样就可以加快在一个问题上的方便测试人员定位，同时也方便自己的查找。这个类似于集成电路。
其次，我认为开发团队中最好配以一位Dev QA，这位同事工作的角度应和传统QA不同，应该有更深的技术背景，一来方便开发团队的单元测试，和功能反馈，其次也可以作为与测试部门的沟通和负责人员。

2、 使用python,autoit等脚本语言做自动化测试
我是使用phthon，shell的脚本进行自动化测试，业内包括QTP非常适合消费类电子产品，可以快速给出软件的健壮性和鲁棒性的结论，但是消费类电子应是以人为本，注重软件友好型和方便程度，自动化测试仅仅用在压力测试和性能测试上，不能以一代全。

3、单元测试在实际项目中的使用度
正如我第一条中说的，我是强烈建议单元测试的人之一，但是单元测试如何管理，并且如何与测试部门进行结果的良好沟通和对功能的探讨优化，仍需要彼此双方坐下来深入交流，得出一个稳定高效的工作模式，但是单元测试仍是开发应该有的，而且是非常好的一个工作习惯。

仅是一家之言，欢迎大家一同来探讨。谢谢~~

infoback

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

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

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

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