编者按：
在软件测试中，系统测试是针对整个产品系统进行的测试，目的是验证系统是否满足了需求的定义，找出与需求规格不符或与之矛盾的地方，从而提出更加完善的方案。系统测试不仅包括需测试的软件，还要包含软件所依赖的硬件、外设甚至包括某些数据、某些支持软件及其接口等。
小编从51Testing网站中，适当的整理了下系统测试这一部分的文章，希望能对大家以后的学习会有所帮助。
【关于系统测试流程的改进与思考】
看了经理的EMAIL，谈到我社系统上线有时存在测试不完善导致的错误，我周末这两天回去也想了很多，也和一些做软件开发的朋友交流看法，知道了我们国内大部分企业对软件测试还不是很重视，由于时间、成本的压力，很多测试流程也都是敷衍了事。但是我们农联社是一个庞大的金融机构，网点众多，每日的交易量成千上万，也意味着我们的一段代码一天会被运行了千万次，对于我们的信息系统来讲，稳定是最重要的因素，必须保证我系统的开发的质量。
经过这两天的思考，结合以前学习过的相关知识，我说说我的一些看法，希望对我们的测试工作有帮助。
1、设计测试用例时，加大在边界值范围的测试强度，因为软件较容易在数据域的边界出现错误。
2、通过输入无效的或非正常的数据，测试系统在错误异常情况下的处理能力。
3、在单元测试时全面覆盖所有路径。除了保证对关键路径的覆盖，还应该覆盖所有逻辑判断路径，保证所有“真”、“假”情况的路径都能被测试到。
4、发布程序时可以考虑下是否先以小部分分社为试点，运行一段时间，看看有没有存在一些未发现的问题，及时改正之后再在全市所有分社推广。
5、随着业务的发展，在未来条件允许的情况下，或许我们可以考虑成立一个专门的测试小组，负责软件开发的质量监管工作。通过专业的测试人员，编写测试用的驱动模块和桩模块，对代码的质量和性能进行深入全面的测试。
关于规范测试流程，我这几天翻阅了一些相关的材料，在软件开发的测试流程上，现在比较流行也比较可靠的是“V”模型。
在测试用例的设计上采用测试先行的方法，即软件开发每做完一个环节，就编写设计的测试方案。需求分析过程结束后，便开始设计验收测试，主要以黑盒测试为主，结合需求分析结果，用于检验系统的系统功能是否达到要求。在开发前期设计测试用例，可以更好的明确开发需求，规范开发思路，把握开发的方向。然后再进行下一环节的开发——概要设计。概要设计相对应的是集成测试的设计，在这个阶段以黑盒测试和白盒相结合，主要用于检验系统各个模块之间的接口以及模块功能是否达到要求。最后是详细设计，与单元测试相对应，主要以白盒测试为主，测试人员主要也是开发人员本身，检验该模块单元内的代码以及所有逻辑路径。
“V”测试模型的好处是设计测试用例的工作可以在软件开发的前期就介入到整个开发过程中来，有很多问题可以在开发前期被发现，可以规避开发风险，降低改正缺陷的成本。但是，“V”模型也存在着一些局限性：
“V”模型依赖于开发文档的准确性，完整性和实时性，文档是测试用例的设计依据，所以，该模型对开发文档提出了较高的要求。由于业务需求的不确定性和易变性，当需求改变的时候，与之相关联的测试文档也必然需要做相应的修改。这提高了文档维护的复杂性。
但是，开发文档是软件工程的核心，它的准确性，完整性和实时性也是保证软件开发质量的内在要求，它贯穿于需求，设计，开发，测试，维护整个软件周期，是不同阶段开发人员相互沟通的桥梁，也是所有开发人员共同遵守的一个开发规范，所以，加强完善文档管理，有利于保证我们农信信息系统的开发质量，把握开发进度，控制开发成本。
我刚参加工作不久，许多地方还需要向同事学习，实践经验也还不是很充足，对于我社综合业务系统的了解还不是很充分，所以以上所说的，难免有一些疏漏和错误，还请各位指正。希望通过我们的努力，能让我们的系统运行得更好，更稳定，更好的为农信的发展服务。
专题入口：http://www.51testing.com/zhuanti/xtcs/xtcs.html
【经验共享：如何做好系统测试】
一套软件做完了，在给客户上线之前，我们自己要进行完整的系统测试，这个工作听起来好象没什么，但其实是很不好做的，这要求测试人员要熟悉业务、熟悉系统的各个功能项、还要有一套完整的测试方法。我们软件销售部从开始做系统分析工作，现在又开始担当系统测试的角色了，没办法，公司人手不够，只能担当多种角色了。不过对于我们来说也有一定好处，系统分析设计是我们做的，现在做好的系统由我们来测试，一是我们对业务比较熟悉，二是对我们来说也是一种自我的检验，检验一下自己设计的系统是否合理，为以后更好的系统分析打好基础。
好了，言归正传，讲一下我们在测试工作中的一点体会吧，写出来一面为自己理一下思路，二也是为自己做工作的一个总结。
一、测试之前要充分掌握业务流程
首先，在进行系统测试之前，要知道系统的业务流程，也就是说要清楚每项业务间发生的前后顺序。只有知道了业务的先后顺序，你的测试数据才能继续在ERP系统功能间流转，否则，无法进行各项业务的全面覆盖测试。
其次，还要明白每一项业务中的详细流程和各个环节涉及的角色，一项比较复杂的业务其详细流程往往比较多，只有了彻底掌握了这项业务，才能对当前业务环节进行全方位的测试。比如：订单管理中，销售业务员创建了一个销售订单，还要经过主管审核，方可执行订单，订单执行完毕后关闭订单。
二、了解业务流程对应的ERP系统的功能
对整个业务有了总体的认识，再把业务分块，在ERP中找出相应的模块与业务对应起来。只有把业务和REP功能完全对应上了，才能说有可能对ERP系统进行全面的覆盖测试。
三、系统功能集中测试和测试方法
找到与具体业务对应的ERP子系统，根据当前业务的流程与角色，对ERP子系统进行集中测试。测试还要讲求方法，尽量做到全覆盖测试，其中注意几点：
1）按正常场景进行测试
根据业务流程，按着正常的顺序，用正确的测试数据测试系统；检查系统的结果是否与预期的结果相同，如果结果相符，表示当前系统模块符合业务逻辑；否则，系统有问题，将错误信息记录到BUG报告中，及时提交开发部门。
2）测试异常场景
根据业务流程，输入异常的测试数据测试系统，查看系统提示哪些异常信息，并查看是否有异常判断，如果有，则表示系统做过异常考虑处理，否则表示系统漏掉了当前异常情况，需要提示开发部门，添加当前异常情况的考虑处理。
3）特殊数据的处理
根据业务流程，在输入测试数据时，输入边缘数据、空值等特殊字符，查看系统是否做了数据录入范围和要求的判断，如果没有，表示系统遗漏数据范围和录入要求的考虑，需要提示开发部门，添加相应数据范围和要求的处理。
......
专题入口：http://www.51testing.com/zhuanti/xtcs/xtcs.html