看了经理的EMAIL，谈到我社系统上线有时存在测试不完善导致的错误，我周末这两天回去也想了很多，也和一些做软件开发的朋友交流看法，知道了我们国内大部分企业对软件测试还不是很重视，由于时间、成本的压力，很多测试流程也都是敷衍了事。但是我们农联社是一个庞大的金融机构，网点众多，每日的交易量成千上万，也意味着我们的一段代码一天会被运行了千万次，对于我们的信息系统来讲，稳定是最重要的因素，必须保证我系统的开发的质量。经过这两天的思考，结合以前学习过的相关知识，我说说我的一些看法，希望对我们的测试工作有帮助。
1，设计测试用例时，加大在边界值范围的测试强度，因为软件较容易在数据域的边界出现错误。
2，通过输入无效的或非正常的数据，测试系统在错误异常情况下的处理能力。
3，在单元测试时全面覆盖所有路径。除了保证对关键路径的覆盖，还应该覆盖所有逻辑判断路径，保证所有“真”、“假”情况的路径都能被测试到。
4，发布程序时可以考虑下是否先以小部分分社为试点，运行一段时间，看看有没有存在一些未发现的问题，及时改正之后再在全市所有分社推广。
5，随着业务的发展，在未来条件允许的情况下，或许我们可以考虑成立一个专门的测试小组，负责软件开发的质量监管工作。通过专业的测试人员，编写测试用的驱动模块和桩模块，对代码的质量和性能进行深入全面的测试。
关于规范测试流程，我这几天翻阅了一些相关的材料，在软件开发的测试流程上，现在比较流行也比较可靠的是“V”模型。
（图片给不出来……呵）
在测试用例的设计上采用测试先行的方法，即软件开发每做完一个环节，就编写设计的测试方案。需求分析过程结束后，便开始设计验收测试，主要以黑盒测试为主，结合需求分析结果，用于检验系统的系统功能是否达到要求。在开发前期设计测试用例，可以更好的明确开发需求，规范开发思路，把握开发的方向。然后再进行下一环节的开发——概要设计。概要设计相对应的是集成测试的设计，在这个阶段以黑盒测试和白盒相结合，主要用于检验系统各个模块之间的接口以及模块功能是否达到要求。最后是详细设计，与单元测试相对应，主要以白盒测试为主，测试人员主要也是开发人员本身，检验该模块单元内的代码以及所有逻辑路径。
“V”测试模型的好处是设计测试用例的工作可以在软件开发的前期就介入到整个开发过程中来，有很多问题可以在开发前期被发现，可以规避开发风险，降低改正缺陷的成本。但是，“V”模型也存在着一些局限性：
“V”模型依赖于开发文档的准确性，完整性和实时性，文档是测试用例的设计依据，所以，该模型对开发文档提出了较高的要求。由于业务需求的不确定性和易变性，当需求改变的时候，与之相关联的测试文档也必然需要做相应的修改。这提高了文档维护的复杂性。
但是，开发文档是软件工程的核心，它的准确性，完整性和实时性也是保证软件开发质量的内在要求，它贯穿于需求，设计，开发，测试，维护整个软件周期，是不同阶段开发人员相互沟通的桥梁，也是所有开发人员共同遵守的一个开发规范，所以，加强完善文档管理，有利于保证我们农信信息系统的开发质量，把握开发进度，控制开发成本。
我刚参加工作不久，许多地方还需要向同事学习，实践经验也还不是很充足，对于我社综合业务系统的了解还不是很充分，所以以上所说的，难免有一些疏漏和错误，还请各位指正。希望通过我们的努力，能让我们的系统运行得更好，更稳定，更好的为农信的发展服务。
