系统测试和用户接受测试

系统测试是软件开发的质量检验阶段，由专业的测试人员，根据需求和功能文档进行独立的测试，检验软件是否达到设计目标。进行系统测试要注意以下几点：

l         迭代式的系统测试

在敏捷开发模式中，由于把整个软件开发周期分割成多个迭代小周期，相应地应该也把系统测试引入每次迭代周期，保证每次迭代末期都能发布产品级质量的软件。

l         独立的系统测试

系统测试要保持一定的独立性。测试人员对系统质量有最终评价权。测试人员对测试结果的判断不应该受开发人员的影响。独立性是测试客观、公正的保证。

l         人力资源有保证的系统测试

测试人员需要在项目之初加入并伴随项目结束。测试人员需要足够长的时间了解软件功能需求，否则很难保证测试人员制定的测试用例的质量。测试人力资源需要有客观的保证。一般公认，测试人员和开发人员比例为1比3，或者1比2。据说有的公司比例更高，有2比1的。一定量的人力投入，才能保证进行充分有效的测试工作。

l         流程清晰的系统测试

测试人员和开发人员由于天然的检查和被检查的关系，有时候在交流上难免会发生一些争执。为了消除或者减少这种不必要的争吵，应该建立一套流程清晰的缺陷发现、分析和修改机制，来规范和约束不同角色人员的行为。缺陷跟踪流程简单表示如下：

测试人员发现缺陷->测试人员在缺陷跟踪系统记录尽量详细清楚的缺陷报告->把缺陷分配给相应的开发人员（如果问题范围不清晰，分配给开发团队预先指定的主缺陷分析人）->开发人员分析缺陷报告->开发人员解决缺陷并在缺陷跟踪系统修改缺陷状态。如果测试人员和开发人员对缺陷报告存在异议，提交到项目组开发和测试领导小组解决。

l         有根有据的系统测试

测试人员必须依照需求和功能设计文档进行测试，做到有根有据。测试人员应该避免根据自己主观喜好来对软件功能进行评价。有时候，有的测试人员到了软件后期，比较容易把自己假设成最终用户，在对某些功能设计的缘由不太了解的情况下，根据主观喜好判断测试结果，很简单地把自己当作软件设计师或者用户，势必造成不必要的争吵。我们都知道，软件的每一个细节，特别是有图形用户界面的软件，可能项目之初的所有需求和功能文档都没法明确定义一切细节。当遇到某些没定义的功能，测试员的爱好和软件实现不一致时，最好的方法是测试员把自己的想法先跟用户讨论，在得到用户认可之后，由用户或者测试人员依照一定流程向开发团队提出变更请求。这样做，既能很大程度上避免公说公有理，婆说婆有理的争吵，也保护了测试人员的创作热情，充分发挥了测试人员的创造性。

 

 

对于有明确用户或者用户代表的软件项目，通常开发流程的最后阶段是用户接受测试。用户利用这个阶段对软件做最后的检查，然后确认接受软件。

按道理，用户接受测试在敏捷开发模式下应该很容易通过，因为毕竟前面有经过用户确认的需求和功能文档，有用户持续介入的多个迭代周期，软件功能的实际实现和用户期望应该不会有大的偏差。但在我目前所在公司，内部不同部门之间类似外包模式的工作环境之下，用户接受测试有时仍然遇到很多困难：用户在项目最后阶段随意地提出需求变更。当然根本原因是政治上的，因为我们部门在组织架构上受制于人，再加上是公司内部项目，也没有真正商业合同的约束。在这种情况下，除非政治上有所安排，否则这种现状不能被更好的流程和更好的开发模式解决。

为了应对现实的无奈，在整个开发周期中，我们能做的就是要注意不断提醒用户真正试用预览版软件，提醒他们尽早的发现他们认为必须的需求变更。另外，在估算项目周期时，基于以前的项目经验，给用户接受测试预留足够长的时间，否则到最后，只能傻傻地看着错过项目的最后期限。