系统级测试一般指对交付的系统进行端到端的测试，验证系统是否满足所有功能和非功能需求。
一般而言，系统测试是整个项目管理工具实践最重要的，但也是成本最大的测试。为了让系统测试能够有效并且低成本，我们先来看看系统测试在整个测试象限中的位置和分类。
如上在敏捷测试四象限，将所有测试实践分为四大类。上图中横轴从支持团队变化到评价产品，纵轴从面向技术变化到面向业务。
Q1：面向技术和支持团队；这一象限中主要包含单元测试和组件测试。该象限中的测试帮助团队获得代码级别的快速反馈，一般借助xUnit测试框架，要求完全自动化。
O2：面向业务和支持团队；这一象限中包含功能测试，原型测试和仿真测试等。该象限中的测试大多也可以自动化，但是需要借助面向领域专门的测试工具。一般是否自动化，取决于是否有低成本的系统级别自动化功能测试工具。
Q3：面向业务和评价产品；这一象限中包含探索性测试、可用性测试等等。探索性测试指靠测试人员的主观发挥去探索系统潜在的故障，该象限中其它的则测试偏重于客户主观感受，所以以手工测试为主。
Q4：面向技术和评价产品；该象限一般包括非功能测试，例如性能测试、压力测试等。非功能测试一般需要依靠专门的测试工具，能否自动化取决于性能工具天生是否对自动化有效的支持。
从上面的分类可见，系统级别测试包含上图中的Q2、Q3、Q4象限中的所有测试。还可以将系统级别测试按如下维度划分：
测试类型
功能测试：对系统功能进行验收的测试，包括用户验收测试、探索测试、A/B测试等；主要分布在Q2、Q3象限。
性能测试：指非功能性测试，包含性能测试、压力测试等；主要分布在Q4象限。
测试方式
自动化测试：包含Q2中容易自动化的功能测试，以及Q4中测试工具支持自动化运行的非功能性测试部分。
手工测试：主要针对Q3中的探索性测试，以及以客户主观感受进行对比和验收的测试用例。
测试策略
经过了前面对系统级测试的分类，我们看到有些测试是必须手动测试的，这些测试是自动化测试替代不了的。
对于可以进行自动化的测试，我们需要利用自动化的优势来降低测试成本，加快反馈周期。
对于一些依靠专有工具进行测试的，我们期望可以改造工具，逐渐将其自动化。
如下我们按照功能测试和非功能测试的分类，分别谈一下其中可以实施自动化部分的测试策略。
功能测试
功能测试原则上需要针对系统要完成的功能点逐一进行遍历测试，一般我们称其为验收测试。当代码发生修改，功能验收测?**枰?龌毓椋?匀繁Ｐ薷牡拇?朊挥衅苹迪低彻δ堋?r
由于功能验收测?**枰?捣钡脑诵泻突毓椋??哉饫嗖馐***枰?】焱ü?远??唇档筒馐猿杀尽Ｈ〈?斯せ毓椴馐缘淖远??馐钥梢允头湃肆Γ?貌馐匀嗽卑阎饕??Ψ旁诜腔?敌缘男枰?丛煨缘奶剿餍圆馐陨稀?r
由于越偏向业务，测试的独特性就越强，所以自动化功能测试工具一般需要?**锌?ⅰ?r
好的消息是对于功能测试来说，测试用例编写、调度、报表生成的部分基本是通用的，所以可以找到不少开源的功能测试框架。但是这类测试框架一般不面向任何领域，只是完成通用的功能并且为扩展留好了接口，由使用者根据自己的领域对工具进行扩展。
自动化测试不能取代人工测试，事实上两种测试的定位是不同的。自动化测试是为了回归，而人工测试是为了探索。一旦探索测试中的一部分开始变得常规化，则可以将其编写成自动化测试用例后续自动执行回归，而让测试人员重新投入更有创造性的测试工作。
另外，自动化的系统测试也不能取代自动化的单元测试。从前面的四象限可以看到，系统测试是帮助产品的，而单元测试为了帮助开发团队的，两者的定位和价值方向不同。
