关河的测试生活

上周六在杭州的《互联网软件测试大会》上做演讲的时候提到可测试性的话题，顺手举了一个例子：“B类存在对A类的依赖，A类是一个Singleton类，B类使用到了A类中的一个需要被mock的函数，这种情况下如何处理？” 本来，这是《修改代码的艺术》上曾经提到的一个典型模式，该书中有非常详细的描述。但今天收到某位听众的邮件，问这个问题应该怎么回答。

正好好久没有写过blog了，于是顺手写了一段简单的代码来说明这个问题。

问题：

类Singleton是一个单件类，该类实现了一个名为getUserName()的函数，getUserName函数需要连接到数据库并从数据库中取出用户名称。类DependsOnSingleton类是被测类，该类中的sayHello函数使用到了Singleton类的getUserName函数，在对DependsOnSingleton类进行单元测试的时候，显然我们并不想设置一个真正的数据库，所以最理想的情况是使用mock方式得到一个可以被控制的Singleton类的getUserName函数的实现。如果Singleton类不是一个单件类，这件事情非常简单，使用接口提取的方法从Singleton类提取接口，然后就可以使用mock技术了。但由于Singleton是一个单件类，这件事情就比较棘手了：Singleton.getInstance会返回一个由getInstance自身逻辑决定的Singleton对象，这样就没法直接塞入一个mock对象了。

代码：

代码

 1 public class Singleton {
 2     static private Singleton _instance;
 3     public final String userName = "Dennis";
 4     
 5     private Singleton() {
 6     }
 7     
 8     static Singleton getInstance() {
 9         if(null == _instance) {
10             _instance = new Singleton();
11         }
12         return _instance;
13     }
14     
15     String getUserName() throws Exception{
16         // Connect to DB and return data from DB
17         // Throw Exception instead
18         throw new Exception("There's no DB exist");
19     }
20 }

解决：

其实解决这个问题的思路，按照《修改代码的艺术》一书的说法，主要是解决“分离”的问题。在Singleton情况下，由于getInstance函数不受控导致了这样的情况，所以最简单的做法是为Singleton类增加一个setTestingInstance函数，使用这个函数注入一个受控的实例。

修改后的Singleton：

代码

 1 public class Singleton {
 2     static private Singleton _instance;
 3     public final String userName = "Dennis";
 4     
 5     private Singleton() {
 6     }
 7     
 8     public static Singleton getInstance() {
 9         if(null == _instance) {
10             _instance = new Singleton();
11         }
12         return _instance;
13     }
14     
15     public static void setTestingInstance(Singleton instance) {
16         _instance = instance;
17     }
18     
19     public String getUserName() throws Exception{
20         // Connect to DB and return data from DB
21         // Throw Exception instead
22         throw new Exception("There's no DB exist");
23     }
24 }

测试代码：

代码

 1 import junit.framework.Assert;
 2 import junit.framework.TestCase;
 3 
 4 import org.easymock.EasyMock;
 5 
 6 public class TestDependsOnSingleton extends TestCase {
 7     public void testSayHello() throws Exception{
 8         Singleton depend = EasyMock.createMock(Singleton.class);
 9         Singleton.setTestingInstance(depend);
10         
11         EasyMock.expect(depend.getUserName()).andReturn("Dennis");
12         EasyMock.replay(depend);
13         
14         DependsOnSingleton itu = new DependsOnSingleton();
15         Assert.assertEquals("Hi, Dennis", itu.sayHello());
16         EasyMock.verify(depend);
17     }
18 }

在第四届软件质量年会上的演讲，标题是”让测试敏捷起来“。

下面的链接是InfoQ上的视频和PPT：

让测试敏捷起来

在本系列的第一部分中，我们简要回顾了敏捷开发，以及敏捷测试与传统测试的不同。在第一部分中，我们特别提到，敏捷测试的要点之一就是，不依据于角色而是依据于任务来考虑整个开发过程中的测试。

但是，对一个开发组织来说，组织中一定存在开发工程师和测试工程师的角色划分，作为一个敏捷团队中的测试工程师，他的主要工作职责是什么呢？或者说，他可以在哪些工作上发挥自己的作用呢？

敏捷过程中与测试相关的任务很多，概括说来有如下一些：

1. 建立不同级别的测试验收标准（也就是test suite），包括单元测试、集成测试、系统测试等各个层面的验收标准；
2. 推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致；
3. 通过技术或是管理的手段，保证产品、代码具有良好的可测试性；
4. 通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
5. 与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
6. 深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
7. 建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。

接下来，我更详细的把列出的这7项工作中非常成“测试工程师必须完成的工作”，“测试工程师需要去推进的工作”，以及“能为项目带来巨大价值的工作”。

1. 测试工程师必须完成的工作： 
• 与客户沟通确认客户可接受的软件质量标准，并建立针对此标准的验收测试；
• 深入了解应用系统和业务需求，通过探索性测试方法设计有效的测试用例，发现产品中的缺陷；
• 建立系统和用户验收级别的测试验收标准；
• 通过自动化测试手段缩短每个产品发布周期中测试所需的时间；
2. 测试工程师需要去推进的工作：
• 推动低层次测试（单元测试和接口级别的测试）的进行。低层次是测试对于需要快速发布的敏捷开发来说至关重要，但在大部分国内的软件组织中，开发测试都需要经过不断的推动才能被最终执行下去，测试工程师具有相关的测试技巧，并且能够用翔实的统计数据表明低层次测试的必要性，是最好的推动低层次测试的人选；
• 推动整个组织的质量文化，保证整个组织的成员在质量责任与目标方面达成一致。这一点对于敏捷组织来说也是至关重要的；在许多传统的软件开发组织中，经常能看到开发和测试之间的扯皮，针对一个遗漏的缺陷，大家考虑第一件事不是如何去修复，如何去防止，而是首先“追究责任”─在敏捷过程中，需要一个非常不同的环境：也即，质量责任是由所有工程师共同承担的，对于出现的问题，重要的是解决和预防。
3. 能为项目带来巨大价值的工作
• 建立对整个团队可见的质量度量体系，保证整个团队能够随时看到产品的质量度量值。保证产品质量度量的可见可以让整个团队清楚的看到我们现在正在工作的产品与我们期望交付的产品在质量上还有多大的差距，这样整个团队可以以质量度量作为指示，集中精力工作在这些差距上，从而可以尽快的发布“可工作”的产品。“验收测试的通过度”，“单元测试的通过率”，“功能完成情况”等等项目都可以是质量度量中的度量项。
• 通过技术或是管理的手段，保证产品、代码具有良好的可测试性。良好的可测试性对于产品的维护，自动化测试的进行都是非常有利的─我觉得，甚至可以武断的说，如果一个应用系统没有良好的可测试性，就很难期望可以在该项目上设置良好的测试框架。测试工程师一般不参与具体的设计工作和代码实施工作，但测试工程师可以推动开发工程师在设计和实现时尽可能的考虑可测试性设计，另一方面，测试工程师也可以通过测试覆盖率这个质量及时发现应用中可测试性不强的地方，推动开发工程师的改进。

1. 良好的沟通和协作能力；
2. 良好的设计和代码能力，至少可以和开发工程师在同一水平上讨论具体的设计和代码实现；
3. 快速学习和总结的能力（运用探索性测试发现缺陷）；
4. 对自动化测试有深刻的理解（至少要能清楚的认识到自动化测试不等于UI自动化测试，也不等于用自动化测试工具进行录制和回放）；
5. 快速的风险分析和判断能力（在许多情况下都不会有足够的时间开展full regression，如何判断风险和决定相应的对策至关重要）。

第二部分完结。

第三部分我打算探讨下敏捷测试中的测试过程管理。与传统的软件测试过程不同，敏捷测试过程是一个非常简单的过程模型，我的重点会放在敏捷测试过程管理中的一些实用工具上。

另外，可测试性貌似也是一个很好的话题，不知道有没有对这个话题感兴趣的朋友？