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

myworkstation

获奖名单已公布，详情请看：http://bbs.chinaunix.net/thread-4111091-1-1.html

测试的重要性应该是毋庸置疑的，测试可以尽可能早的发现问题，问题出现的越晚修复的代价就越大，在此讨论一下大家是怎么参与到测试过程中又如何尽量在测试阶段发现问题的？请大家踊跃讨论，有奖品啊

本期话题：
1、开发过程中开发人员对测试的参与度以及测试方法
2、 使用python,autoit等脚本语言做自动化测试
3、单元测试在实际项目中的使用度

活动时间：2013年10月10日-10月30日

本期奖品：
活动结束后，我们会评选出5位积极参与话题讨论的网友奖励《Google软件测试之道》图书1本

　书名：Google软件测试之道
    原书名：How Google Tests Software
    原出版社： Addison-Wesley Professional
    作者：  (美)James Whittaker    Jason Arbon    Jeff Carollo   
    译者： 黄利 李中杰 薛明
    出版社：人民邮电出版社
    ISBN：9787115330246
    上架时间：2013-9-29
    出版日期：2013 年10月
    开本：16开

活动要求：
1、 要言之有物，不能低于20个字
2、 本次话题主要关于软件开发过程中各个阶段的测试方法和心得。

chszs

我不是专职的测试人员，在多年的项目开发过程中，也经常干一些测试工作，其中确实有很多体会。
第一，单元测试是必不可少的，以常见的Web项目为例，后端开发者的主要工作是实现业务逻辑、持久化层、Web服务层，而这些工作都需要写单元测试进行验证。单元测试是由开发人员编写的，当然，专职的测试人员也可以写单元测试，但两者的侧重点是不同的，通常是测试人员的单元测试不能涵盖开发人员的单元测试，但开发人员的单元测试却可以涵盖测试人员的单元测试。
写了很多单元测试之后，可以把这些单元测试类构成测试集。这样，每当有需求变更或者算法更改时，把单元测试集运行一次，以检查模块的功能是否正常。当然，单元测试本身的代码质量也非常重要，代码质量不高，会使得很多问题发现不了，给开发后期带来很多问题。
在这里回答第三个问题，“单元测试在实际项目中的使用度”，单元测试在项目开发的过程中，基本上是必不可少。即使对于资深程序员来说，我觉得仍然需要单元测试。因为“是人就会犯错误”，单元测试可以帮助我们避免这一点。
早些年间，我在一个Java团队中，使用的单元测试一直是JUnit，TestNG我也用过，功能和JUnit同样强大，都是不错的单元测试工具。
要注意，单元测试的编写会占用很多开发时间，以至于有很多人、很多项目没做单元测试。但是，单元测试的优点是不可抹杀的。单元测试是改进我们设计的保证。做为一个优秀的程序员，是会经常优化代码和设计，所以经常的进行重构。一个优秀的程序员绝对不能容忍异味代码。而单元测试就是我们进行重构的信心保证。
第二，开发人员有时候因人手紧张等原因，有时候也会做功能测试，对于前端工程师来说，尤其如此。在把代码提交到测试组之前，所有的界面功能通常会自己测试多次，尽可能地把潜在的问题修复完。即便如此，测试人员常常也会发现新问题。
第三，集成测试。各个模块在开发完成后，会组装在一起进行集成测试。对于开发人员来说，有时候也会做集成测试。对于分工明确的专业团队来说，集成测试由测试人员完成。
集成测试测试组合单元时出现的问题。一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。
使用python,autoit等脚本语言做自动化测试，那些都是测试人员干的事，等待其他朋友评论。

seesea2517

python autoit 偶尔用到，仅实现工作上的一些自动化，不是测试人员没玩过测试，不过这自动化的操作肯定是对测试有帮助的。

qingduo04

回复 2# chszs


    哥们说的真详细，学习了。

qinyiwang

从功能测试和性能测试这不同的方向说明会更好吧

forgaoqiang

Python的话用的还是比较少的 过来围观支持下吧~

CUTianrui007

1：开发过程中开发人员对测试的参与度以及测试方法
      我从来都认为测试和开发是不可分割天生一体的，只是为了软件质量和分工，为了实现软件的工业化才将其分开。真正的程序员应该是开和测试两个方面的好手。所以，软件开发时，一定要写可测试的代码，在写代码时一定要想着如何测试这个代码，这个代码实现了哪个需求，单元测试，功能测试等其它测试如何对它进行检测等，切实做到开发与测试并行。另外，根据我的工作经验，可以尝试以测试驱动开发的模式：也就是对照需求，先由测试人员给出测试点，然后你再根据测试点有针对性地写软件，这样可以做到快速避免问题，极大地加快工期。
      另外，我一直梦想的是，能根据需求自动生成测试脚本或测试文件甚至是自动生成程序本身，不知道有没有公司在这样做。个人感觉这个难度很高，它首先要求你的需求文档要很规范，要能覆盖所有的客户要求，要有很灵活的软件平台，另外，还有选择合适的语言实现需求到脚本或程序的转换，工保证转换的正确性，完整性。


2：使用python,autoit等脚本语言做自动化测试
       自动化测试现在软件工业界已经得到了广泛使用，自动测试软件所基于的软件平台也是五花八门。比如我公司（汽车仪表供应商）使用是MaTeLo，这是一款嵌入式测试软件平台，它基于NI的板卡，由上位机通过图形化编程得到图形化的测试模块，然后由测试模块生成测试脚本（你也可以直接写测试脚本，其脚本类似于VB语言），在MaTeLo环境中执行，它可以通过控制NI板卡向下位机发送指令，包括硬件控制指令和CAN信号。
       据我所知，Autoit主要是针对GUI操作的，在PC机GUI软件测试中极其有用，它能最大程序减少工作量，而对于嵌入式软件几乎无用武之地了。Python由于其调度灵活性，可以将其作为一个入侵式工具对代码内部进行分析、检测，根据代码本身由Python来生成测试文件及测试报告。将Python或Autoit真在做为软件开发工具链的一部分，从根本意识上认识到：软件开发不只是C/C++/Java/C#等主流语言的事情，脚本工具作为前期或后期的维护工具，是必不可少的。
没有成熟的软件开发工具链，意味着软件开发不成熟。

3：单元测试在实际项目中的使用度
      单元测试是最容易展开的测试方法，它为模块提供了一个理想化的测试环境，在这个环境中你可以最大化地自由控制外界输入，实现想要的结果。正是因为如此，它也是最繁琐的，需要很大的耐心去做这件事，特别是对于大型模块，工作量几乎难以承受。在我开发过的软件中，因为如此，单元测试的使用频率不是太高，只是对较小的模块做些单元测试。大型模块一般都是由测试团队直接进行功能测试。

grshrd49

1、开发过程中开发人员对测试的参与度以及测试方法
    在传统的开发测试过程中程序员开发完成后，就直接进入了测试过程。程序员只要保证功能可以正常运行，而测试人员就需要按照通用测试技术和对业务的了解去对功能进行测试。
        这个传统的生产流程其优点在于：分工明确，指责划分清晰，适用需要明确流程的和责任明确的大公司或者10-20人以上的大项目团队。
        但是缺点：在于会产生互相推诿的情况，程序员会认为：反正有测试会帮我测试，完成了功能就直接丢给了测试。有些更过分的连功能都没完成运行直接报错，这样就可能给测试带来很大的麻烦，导致反复打回项目包浪费大量时间。
    而近几年出现的“敏捷团队”则打破了传统生产流程中的开发和测试的指责明确划分的壁垒，敏捷团队中的每一个人都有独挡一面的能力。开发需要懂得测试技术在开发过程中就避免各种非法操作的产生，而测试人员也需要懂得开发技术，从更深层面去测试功能或项目的可能发生的潜在问题，在测试过程中会独立编写测试脚本准备以后的验证测试和回归测试。
        敏捷团队的优点：在于没有更多的流程和形式，每个人都充分发挥自己的优势快速反映快速解决，用户为导向。
        但是敏捷团队的缺点：人员成本会比普通团队的成本更高。其二就是如果没有一个很强的领导，团队将会变成一团散沙各自为政！

2、 使用python,autoit等脚本语言做自动化测试
    py配合selenium2,在加上autoit 简直是全能无敌了，虽然我用的的java+ selenium2平时还用 perl写点测试脚本，测试已经变的很轻松了。selenium在原有的基础上开发了webdriver技术修复了大量1中产生的问题，至少我用到现在页面上的任何操作用selenium2的接口都可以完美的操作。减少了验证测试和回归测试繁琐而无聊的重复劳动！！

3、单元测试在实际项目中的使用度
    我本人不是开发，但是我见过开发在自己的功能模块下些的 junit代码！一个优秀的程序员和一个菜鸟程序员，其中一个区别就是代码下junit类写了多少。我见过不少菜鸟程序员，开发的功能bug一大堆看看他们的eclipse里自己模块下，基本看不到junit类。这个就已经很说明问题了！

tempname2

用自动化测试框架有时会出现不可解的问题，要是在某个版本一定要通过所有测试的背景碰到这种情况就呵呵了。

我至少在Java和Python里碰到两次case跑飞的情况：前一句打印好好的，中间用try框起来也没捕捉到啥，后一句就没了，框架报case fail。

rover12421

很少写测试用例~~~