去年下半年，公司空降了一位总监，他提出了一个观点：提高交付质量和交付速率！顿时茅塞顿开，对呀，我们工作的目的不就是提高交付的软件系统质量，以及提高效率！

昨晚听同行分享后，思考总结了一下，针对如何提高交付的软件应用质量和速率这个问题，发现自己还有一些细节的地方没考虑到，果然还是经验不足，学习成长的道路，任重而道远！！！

下面的内容，重新整理了大佬分享的几个观点，结合自己的一些想法，算是做一个参考吧。。。

一、需求

1、需求评审

为什么要需求评审？原因有下面几点：

①、熟悉业务，由产品或者业务讲解需求，好做到心中有数，不至于到开发测试阶段暴露出由于业务不熟悉导致的问题；

②、多方协定，在正式进入开发阶段之前，测试、开发、产品就某些需求的不确定点进行确认，达成一致，避免后续的问题；

③、评估工作量，实现难度，以及大概的资源投入；

④、明确开发测试边界、目标和范围，做什么不做什么；

2、需求文档

①、尽可能的详细，需要从需求中提取相应的功能点和测试点；

②、功能点和测试点选取适当的粒度，这样可以较容易的观察到测试结果和需求的偏离度；

③、一般来说，系统越大，业务越复杂，需求的偏离度判定比小系统更容易些；

二、系统架构

除了需求，了解熟悉整个系统的技术架构，也是必须的一点。比如整个系统的架构组成，各自的特点，采用了什么通信服务框架，数据库类型，前后端框架等等，这样可以更方便定位缺陷，

以及根据系统架构选择合适的自动化测试框架、性能测试策略等。

特征：一般来说，系统的稳定性越好，那么它的可适应性就越差，其带来的影响是每次架构变更的成本上升以及开发团队重新建设抑或测试团队整体方向上的变化。

这几年开始流行和大规模应用的分布式架构、微服务等，都是从系统的可用性和伸缩扩展性来考虑，以降低各方面的变更带来的成本。

三、流程管理

测试过程结果的记录应该在一定程度上取决于流程的记录完整程度。

如果涉及到流程更改，也应对不同的观察对象（测试/开发）所产生的效果和结果进行记录，以判断其对质量的影响以及评估标准。

测试流程如下：

①、启动阶段

开发经理在开发计划中确定测试提交时间，测试主管得到当前最新的相关文档资料后进行规模预估并成立测试小组，完成《测试计划》；

②、设计阶段

包含测试计划、测试方案、测试用例等输出文档；

在需求分析文档确立基线以后，测试组需要针对测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。在用例的编写过程中，具体的任务和责任人如下：

③、实施阶段

执行测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础之上；

④、报告阶段

在当天（或每个小的阶段）的测试完成之后，测试工程师需要总结当天测试的结果，报告测试进度；

⑤、总结阶段

在测试结束之后，测试主管编写测试报告，对测试进行总结，并且提交，为产品的后续工作提供重要的信息支持；

⑥、验收阶段

在以上工作全部结束后，对测试的过程，结果进行验收，宣布测试阶段性结束；

⑦、归档阶段

测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档；

四、文档管理

文档对工作的帮助，是很有必要的。虽然现在很多企业提倡敏捷，但敏捷并非没有文档，而是轻文档。文档的重要性有如下几个方面：

1、对历史以及当前测试过程中的知识传递有很大帮助；

2、可以通过对比历史和当前文档的变更，较容易的观察到整个需求变更过程中测试的质量；

3、涉及到人员变更或者缺陷的争论时，有更快的知识传递速率和参考依据；

五、风险管理

项目的每个阶段都存在风险，常见的缺陷有下面几点：

1、需求不明确；

2、系统设计或测试设计不完善；

3、不安全规范的代码编写方式；

4、测试用例不充足，覆盖率较低；

5、测试资源不足，回归工作量预估不当；

7、项目进度安排不妥，其他项目对本项目的影响；

因此，风险管理和防范是必要且重要的一项工作，且测试工程师的职责，不就是提供交付软件的质量么！！！

六、时间管理

有一定测试经验的工程师基本都经历过资源投入不足，时间不足的问题，测试时间被压缩，导致的加班甚至生产事故！因此做好时间管理，就显得如此重要。

会管理时间的人往往离成功更近一步，如何合理的利用时间解决紧急的项目问题、冲突问题、资源安排问题、优先级、测试用例的执行顺序等，做好时间管理是保证质量的因素之一。 

比如涉及到新增需求or需求变更都必须要有相应的文档（可以为需求说明书或邮件说明）作为测试的依据。

以上的几部分内容，描述了测试工程师的岗位职责，以及需要注意的几个部分和一些细节，当然，具体的一些流程管理之类的内容，不同企业有各自的特点，这里只作为参考。。。