适读人群

互联网&游戏&传统软件即可。
打算对测试开发发展的 OR 想了解原理即可。
游戏内容会在后续章节里，单独对主流的二种类型讲述。

业务很重要

适读人群里的行业在项目的不同阶段，你遇到是面试也或者说是业务上计划做得更好或者和其他成员讲解，都需要懂业务，这里谈谈业务一个其他切面的知识点 传输的是什么。
懂业务不只是对某个和公司同样业务软件或者自己公司产品十分了解产品需求或者业务架构（业务上的运行流程和条件）
可能还需要对产品传输数据的文本格式有一定的了解。文本格式这个也是在所有产品中可以提炼出来的通用性技术。你先需要知道自己公司项目序列化传输的是什么类型的文件。这里游戏，互联网传统都一样。

比如 -->json 格式数据，那么 python 技术相关 json 和 simplejson 的如何选择，APi 几乎是类似的，效率上肯定是 simplejson 高。这里如果是内存中解析回来的 json 和直接处理.json 文件是不一样的 API.

比如 -->googleprotobuf 文件格式，pb 版本是多少？是否业务上需要让其对其他文件解析读出来，如果要传 json，上面选择用 simplejson 了，那么是否合适互转？实际上叠加了这个条件后，应该上面修改为用 json.

比如-->xml 文件，java 工程或者 ajax 用。这里是否可以选择用 json。但是前提业务上是从 html 解析过来的呢。

比如-->文本文件 是直接从硬盘直接加载，还是先把文件加载成一个字符串对象，然后按标记切割，逐行处理。

比如-->数据驱动层面，读取csv 文件可能会根据不同版本选择不同的库。
ini 文件比较历史悠久的，至今在游戏产业用的十分多，也是测试框架中写部分配置的，虽然慢慢也被别的替代了。

以上，还有二进制文件等等没说，这些都不是编程的技术，而是对于这些通用的业务的理解，无论是选型自己做还是指导其他人完成。
业务是由一个个模块拼起来的，支撑这些模块走得更稳定的是这些选择。

代码习惯 OR 业务可读

核心业务代码业务都懂很清晰，中间用的方法也有都调了，也没自己去写都是调成熟的，为什么会有 bug 呢？bug 排查很多原因，不光是上下文的。上下文也是业务测试的一部分吧
但是有一点是很多教科书上的例子 假定了返回和入的参数给予的值一定是在范围内完全并且不会被其他修改的，但实际代码中并不会这样。
然后这个时候会选择看一些类似军规和更好的编码习惯的书。然后这里简单总结一下，不一定能提高代码质量，但是写边界处理并不多写代码也不破坏代码结构。边界不是业务测试的一部分吗？答也是啊。

public class Files {

    static boolean LoadFileConText(final String filename) throws IOException {
        //final已经确保中间不会被篡改 下面单行是做异常保护 如果为null或者长度为0 堆里面长度也是0 那么返回false不执行
        if(null ==filename && filename.length()==0)return false;
        if(!new File(filename.trim()).exists()){ //判断文件是否存在，这里只是测试代码！ .trim()是保护验证空格。
            new File(filename.trim()).createNewFile();
            return false; //没有的话创建，返回false
        }
        return true; //已经有了就不用创建了
    }

    public static void main(String[] args) throws IOException {
        System.out.println(LoadFileConText("2.txt"));
    }

}

以上只是一小段测试代码。在异常保护那边被拒绝了，就是不处理下面，也就是不判断文件到底在不在。真实代码在下面因为有 return 的关系，分别是 2 个区域。可以形使不同的逻辑。
因小而见大，这样写没有破坏本身代码结构。

在业务过程中，那么又是否需要注释下为什么要加这块异常呢？有些不会存在的异常是否可以用更安全写法保护下，比如泛型或者是入参 final。在某些系统环境下可能不在意处理空格，有些确需要。这些是需要好好思考的。
补充说明，关注这句，同时在测试人员自动化过程中，虽然都是调 api，为啥有的人每次定位都到了，而且就算定位不到都有办法兜住，有些会每次自动化同一个，结果不一样。

暂时先写到这里，下篇会对业务关注点的其他层面进行介绍。