脑血管疾病的前兆:单元测试方案整理

发布时间: 2010-10-20 12:02 作者: 未知 来源: 51Testing软件测试网采编　　1、为什么要做单元测试我不想多说　　模块出现问题难定位，为了更早发现bug，定位bug。　　2、关于程序员的职责，强调：　　不是调试不报错就可以了，不要自信自己的程序不会出错。　　任何人都有失误不可避免的。开发的任务是完成程序直至交付和维护。　　3、实践证明　　编码阶段引入的bug多余其他阶段。　　系统测试发现的大多数都是编码缺陷，又得花时间找问题·~⊙﹏⊙b汗　　这样导致的问题，测试版本频繁，进度无休止的拖延。　　4、谈下我们的现状　　业界能做单元测试的都是花软件项目周期的五分之一左右时间编码，而我们绝大部分是百分之五十以上的时间编码，剩下的时间就是所谓系统测试了，而称之为系统测试，实际上都是在系统联调环境或接口问题不断，有效测试时间少之又少，还不断更新版本，测试效果可想而知。　　5、我们的开发充当的角色：　　参与部分高层设计、承担低层设计、程序实现和低层测试。　　6、为啥开发的测试效果不好？这也是我为什么要写这个喇　　没时间测试、不知道怎样测试、不好组织。　　结果单元测试都是堆积到系统测试阶段，给测试痛苦，你们应该对我们好点，%>_<%　　后果就是拖延项目发布时间，难以定位bug，奔命吖~~　　附：业界标杆单位是15%编码、25%单元测试，系统测试只需要4%，这也是为什么我们公司以前测试一个版本3天左右就能搞定。考虑周全，质量本身就不错，等着挑刺了。　　7、单元测试原则：　　● 尽早　　● 保证单元测试的可重复性。　　● 工具支持　　8、单元测试内容，这里是我们需要重点关注的内容：　　● 功能　　● 接口　　● 局部数据结构　　● 重要执行路径（正常数据和边界数据以及错误数据都得试试）　　● 错误处理路径　　● 边界条件测试　　9、我们的单元测试谁做　　主要是开发人员做，测试人员可以针对重点模块实施独立单元测试。　10、对于测试过程我不想要求太多，计划啥的不做过多要求，但要求产出符合要求的代码。　　11、对于二次开发功能可以不要求单元测试，但新模块、核心模块以及代码修改量大于20%左右的模块必须做单元测试。　　12、我想列的功能覆盖单元测试检查点：待续　　13、接口测试，测试驱动开发。。。　　至少要先明确要存到哪里，哪些地方是要给别人用的。　　14、单元测试可以用些工具，我也不太熟悉，推荐Junit，待姐研究后续~~。　　15、一些专业的内容分享，提高可测性：　　1）首先最重要的是坚持测试驱动设计（测试先于设计）的方法。　　优先编写测试代码。这是标准的XP 方法。这不是说您应该一次性编写全部测试代码后，再一次性全部实现。对一些单元接口，编写一些测试代码，实现它们，再编写一些测试代码，再实现它们等等是个更好的办法。设计以这种方式得以进展；在实现阶段捕捉错误并在下一组测试中改正它。　　2）功能分解　　类：把功能分解到细粒度，提倡小类。　　方法：尽量做到每个操作对应一个方法，使方法小型化。　　功能分解促进：提高重用性，降低耦合度　　3）分层原则。　　对于显示部分（GUI），尽量做到显示与控制分离。把代码移到GUI 视图的外面。然后各种GUI 动作就能成了模型上的简单方法调用。这样，对GUI 测试者来说，通过方法调用测试功能比间接地测试功能容易的多。另一个好处是它使修改程序功能而不影响视图变的更容易。　　4）抽象　　我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口。　　GOF的23种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的　　5）对于可能要作为参数的复杂类，可以做一个接口，用接口说明外部程序组件使得我们可以容易地在测试案例中模拟这些组件。当需要时可以实现按接口生成一个模拟类作为参数传入。特别是当该类还没有完全实现时，这种方法最为行之有效。　　6）如果自己不负责测试工作，作为开发员在设计过程中要时刻提醒自己“我如何才能测试这些代码？我如何才能以可测试方式编写这些代码”。　　7）重构是提高可测试性的主要手段　　测试驱动开发　　编写单元测试用例促进解除模块之间的耦合。先编写测试用例，强迫自己从利于调用者的角度来设计单元，关注单元的接口。为了便于调用和独立测试，必须降低单元和周边环境的耦合程度，单元的可测试性得到加强，模块化程度得到提高。这样单元的可重用性也容易被考虑和提高。