iTester是个专注于接口测试的综合管理软件。
1. 为什么要做又一个测试软件？
市场上确实存在不少测试相关的软件。所以很多人问你做这个有市场吗？那当然是有的！毕竟有软件制造就会有软件测试，测试软件市场也不是一家通吃，总有市场的缝隙，最终不过是产品和商业的竞争而已，看谁做的更好！
2. 你凭啥子觉得会做的比别人的好？
说“好”可能容易误解，太绝对了！应该说我跟别人做的不一样，有自己的特色，从我的想法里应该更符合用户的需求。我是个一直做开发、设计、架构和项目管理的老程序员，也许我更懂怎么做好或管理好测试。
3. 那你的产品有那些特色不一样？
总的来说，我希望产品能融合一点TDD（测试驱动开发）理念，集成一些CI/CD（持续集成/发布）的功能，具备需求定义与管理中心的雏形，部署在“云”上SAAS模式运营。具体来说，有几个较为核心的特点：
- 接口测试
这个世界99%的软件都是应用软件，而应用软件的构成无非“界面+功能”，在网络世界里“功能”基本都是用接口调用实现的，所以接口测试占了应用软件测试的半壁江山，在银行、保险等业务密集型应用软件为主领域，接口测试占比更高。
有一些的企业，比如银行，对IT是严重依赖的，多年发展下来，N多的系统互相关联，EAI、ESB、SOA、Gateway ... 一堆的应用整合概念和措施，但将接口（即服务）管理好的企业少之又少，更别说给这些接口配上流程描述、测试案例了。
我这个测试软件能解决的**痛点**就是：企业里的任何合法用户登入系统就能了解这个企业的IT系统，IT系统提供的服务（接口），接口的大致流程，而且这些接口还可以“Run”一下（测试），再不用找这个那个要接口要说明文档。
- 灰盒测试
白盒测试是对接口的**程序代码**逐条覆盖设计测试案例，我这个接口测试不会做到这么细粒度，而是对接口的处理流程节点来逐点覆盖设计测试案例，粒度要粗一些。相比白盒测试什么都看得很透彻，我称之为灰盒测试，有点模糊但大致都清楚。
灰盒描述的流程通常都和业务流程对应着，业务需求被较为“程序化”地描述出来，便于产品、开发和测试团队对需求的共同理解、讨论和明确。也便于自动化地分析测试案例集对需求的覆盖度。这解决了这样一个**痛点**：测试人员因对需求的了解不够而做不好案例设计和测试完备性判断。
- 测试模板
测试人员水平是参差不齐的，就算有了灰盒描述，还需要较为有经验的来设计和判断。测试模板要做的就是把这些案例设计固化下来，让流程节点自动与一组测试案例集关联起来。当用户把流程勾画出来时，测试案例的设计随之就配置好了，并且保证了每个节点都具有案例覆盖率。比如对数据库查询操作是流程的一个动作（节点），其关联的测试案例就包括了查询成功、查询失败、无记录、数据库异常等，测试人员只需要为案例设置数据，准备测试环境即可做基本的测试操作。
测试模板解决的**痛点**是：将测试技能标准化保证基本的测试质量，不遗漏测试案例。
- 半自动化
测试工作中很大部分枯燥而重复，其中包括数据准备和回归测试，而这两类工作如果能让工具自动化地进行，将极大地降低工作强度，提高测试质量。iTester针对这两类工作做了一些功能，比如测试数据准备，根据数据字典定义和报文组成，自动产生测试输入。回归测试则只需要勾选接口或特定案例运行即可。这些自动化工作还可以与CI/CD工作流集成，甚至达到DevOps的终极目标。
