系统的质量属性包括六类，分别是：可用性、可修改性、性能、安全性、可测试性、易用性。其中可测试性是非执行就可见的质量因素。是指通过测试揭示软件缺陷的难易程度，如果在软件中有错误，可测试性就表示软件在下次运行时不能正常运行的可能性。例如《热词分析》的程序，因为我写的《热词分析》程序是java与微信小程序的结合，其中就涉及到了数据、端口号等的问题，不知不觉中可能就会出现错误，可测试性的响应度量处理的是测试在发现缺陷方面的效率以及想要达到某个期望的覆盖范围。需要用多长时间进行测试。
可测试性是代码编写中非常重要的部分，不仅在编写代码时需要进行测试，在程序设计和架构时也需要测试。人们越来越想要提高代码的测试效率，测试效率越低意味着在在开发时的成本越高，如何降低测试成本使得可测试性技术效率更高开始被人们所关注。可测试性技术涉及多个方面，其最终目标是提高软件的质量，降低全寿命周期费用。目前可测试性技术研究主要集中在面向软件代码的可测试性度量上。通过了解，Voas 等[78)并给出了一种基于错误1失效模型的软件可测试性度量计算方法，即PIE(Propagation& Infection&Execution)技术， Jin-Cherng Lin 等人侧提出了-种基于静态检测代码的可测试性度量计算方法，Pu-lin Yeh等人(6l提出了基于数据流的可测试性度量计算方法。这些度量计算方法都是面向程序代码。 一个好的代码离不开测试，作为软件本身的一种特性，软件可测试性应该具有如下特征:
(1)可观察性。可观察性好的软件产品，使得被测对象和测试结果易被观察和跟踪，信息掩盖率低，错误揭示率高;在《热词分析》代码中代码功能明确，爬取，清洗，传递，展示，都容易被观察追踪，且代码都有注释
(2)可操作性。如果设计的软件很少存在BUG，在进行测试时的效率就会很高。
(3)可控制性。可控制性好的软件产品，能够从软件产品的输入来控制它的各种输出，软和硬件状态和变量能直接由测试工程师进行控制，使得软件的自动测试工作变得更容易；换句话说就是软件本身接受定义明确的参数，并且这些参数可由测试者灵活的传入，软件在接受到这些参数后通过一系列运算返回固定的结果。在写《热词分析》的程序时，要应该清楚的表明自己需要什么参数，以及将会生成什么返回值。
(4)易理解性。软件的设计在逻辑上和操作上易于理解;
(5)可分解性。软件可以分解为多个独立的或弱相关的模块，提高软件模块测试的独立性:
(6)简单性。软件在满足需求的基础，上要尽量简单。
有的代码是不好测试的，在进行测试时，会发现程序中某些部分很难进行自动测试，比如耦合程度比较高的类、用户界面、数据库、Servlets和EJB类、等等。首先是不知道测什么，其次是一些代码之间互相依赖严重，在测试环境中要建立起这些类的实例都很难。要在代码层实现可测试性，我们需要做的就是把我们自己写的代码部分和这些代码从物理上尽量的分离开，这样一来我们写的代码就可以测试了。至于Servlets这样的程序，可以使用HttpUnit或者使用一段程序调用其中的业务代码进行测试。我们还要减少类之间的耦合，如果类之间高耦合，那么我们在测试一个类时，同时也需要测试与他相耦合的类，这是非常麻烦的。这也是我们在设计模式中学到的知识，高类聚低耦合。在《热词分析》中，尽量把相关的功能放在一个类，一个类尽量只负责完成一个职责，并且类与类之间要关联的越少越好，这对于代码的可修改性和可测试性以及复用性都是非常有意义的。为了减少类之间的耦合，我们可以进入接口，一个类可以不与其他类耦合，而直接调用这个接口，就可以工作了。在测试时实现一个虚拟的接口，这样就可以很方便的对类进行测试了。
要提高代码层的可测试性，同时也要求程序具有较好的层次性，用户界面和其背后的业务逻辑是分离的，用户界面与其他的逻辑界面的耦合是非常低的，模块间的联系非常是非常松散的，这样在测试时不会出现相互感染，用户界面和逻辑界面可以单独进行测试，一些部分也可以单独进行测试。程序设计一般遵循层次原则，一般说来，上层的程序可以调用下层的程序，同层之间也可能存在互相的调用。一个较好的层次结构代表的是，层次之间原则上坚持单向调用，如果存在层次之间的双向调用，那就破坏了层次原则，在测试时也会变得比较麻烦，程序的可复用性也会降低。
通过学习我发现，提高代码层的可测试性，离不开设计模式，设计模式中的单一责任原则、开放/封闭原则、里氏代换原则、接口分离原则、依赖反转原则都非常重要，坚持面向对象编码原则对于一个软件至为重要。