转载：https://www.cnblogs.com/imyalost/p/8613501.html
一、需求
1、需求评审
为什么要需求评审？原因有下面几点：
①、熟悉业务，由产品或者业务讲解需求，好做到心中有数，不至于到开发测试阶段暴露出由于业务不熟悉导致的问题；
②、多方协定，在正式进入开发阶段之前，测试、开发、产品就某些需求的不确定点进行确认，达成一致，避免后续的问题；
③、评估工作量，实现难度，以及大概的资源投入；
④、明确开发测试边界、目标和范围，做什么不做什么；
2、需求文档
①、尽可能的详细，需要从需求中提取相应的功能点和测试点；
②、功能点和测试点选取适当的粒度，这样可以较容易的观察到测试结果和需求的偏离度；
③、一般来说，系统越大，业务越复杂，需求的偏离度判定比小系统更容易些；
二、系统架构
除了需求，了解熟悉整个系统的技术架构，也是必须的一点。比如整个系统的架构组成，各自的特点，采用了什么通信服务框架，数据库类型，前后端框架等等，这样可以更方便定位缺陷，
以及根据系统架构选择合适的自动化测试框架、性能测试策略等。
特征：一般来说，系统的稳定性越好，那么它的可适应性就越差，其带来的影响是每次架构变更的成本上升以及开发团队重新建设抑或测试团队整体方向上的变化。
这几年开始流行和大规模应用的分布式架构、微服务等，都是从系统的可用性和伸缩扩展性来考虑，以降低各方面的变更带来的成本。
三、流程管理
测试过程结果的记录应该在一定程度上取决于流程的记录完整程度。
如果涉及到流程更改，也应对不同的观察对象（测试/开发）所产生的效果和结果进行记录，以判断其对质量的影响以及评估标准。
测试流程如下：
①、启动阶段
开发经理在开发计划中确定测试提交时间，测试主管得到当前最新的相关文档资料后进行规模预估并成立测试小组，完成《测试计划》；
②、设计阶段
包含测试计划、测试方案、测试用例等输出文档；
在需求分析文档确立基线以后，测试组需要针对测试需求编写测试用例，在实际的测试中，测试用例将是唯一实施标准。在用例的编写过程中，具体的任务和责任人如下：
③、实施阶段
执行测试用例将花费测试组绝大部分时间，这些工作都是建立在前期很多计划工作的基础之上；
④、报告阶段
在当天（或每个小的阶段）的测试完成之后，测试工程师需要总结当天测试的结果，报告测试进度；
⑤、总结阶段
在测试结束之后，测试主管编写测试报告，对测试进行总结，并且提交，为产品的后续工作提供重要的信息支持；
⑥、验收阶段
在以上工作全部结束后，对测试的过程，结果进行验收，宣布测试阶段性结束；
⑦、归档阶段
测试归档是在测试验收结束宣布测试有效，结束测试后，对测试过程中涉及到各种标准文档进行归档；
四、文档管理
文档对工作的帮助，是很有必要的。虽然现在很多企业提倡敏捷，但敏捷并非没有文档，而是轻文档。文档的重要性有如下几个方面：
1、对历史以及当前测试过程中的知识传递有很大帮助；
2、可以通过对比历史和当前文档的变更，较容易的观察到整个需求变更过程中测试的质量；
3、涉及到人员变更或者缺陷的争论时，有更快的知识传递速率和参考依据；
五、风险管理
项目的每个阶段都存在风险，常见的缺陷有下面几点：
1、需求不明确；
2、系统设计或测试设计不完善；
3、不安全规范的代码编写方式；
4、测试用例不充足，覆盖率较低；
5、测试资源不足，回归工作量预估不当；
7、项目进度安排不妥，其他项目对本项目的影响；
因此，风险管理和防范是必要且重要的一项工作，且测试工程师的职责，不就是提供交付软件的质量么！！！
六、时间管理
有一定测试经验的工程师基本都经历过资源投入不足，时间不足的问题，测试时间被压缩，导致的加班甚至生产事故！因此做好时间管理，就显得如此重要。
会管理时间的人往往离成功更近一步，如何合理的利用时间解决紧急的项目问题、冲突问题、资源安排问题、优先级、测试用例的执行顺序等，做好时间管理是保证质量的因素之一。
比如涉及到新增需求or需求变更都必须要有相应的文档（可以为需求说明书或邮件说明）作为测试的依据；
这里推荐两本书：《番茄工作法》、《高效能人士的七个习惯》
标签：需求,架构,系统,进阶篇,测试用例,文档,测试,岗位职责,软件测试 From： https://www.cnblogs.com/ceshi2016/p/16818413.html