可以安排测试人员进行测试用例的编写。
对于一些紧急的项目，可以引进敏捷测试。
敏捷测试是最近几年比较流行的测试方法，也拥有了众多的拥护者。
还引出了一个测试思想——测试驱动开发（TDD）
这个概念有时间我单拎出来写。
敏捷测试的最大特点是高频率的快速迭代，几乎是一天一个迭代版本，甚至是一天多个版本。
敏捷测试是遵循敏捷宣言的一种测试实践：
1、强调从客户的角度，即从使用系统的用户角度，来测试系统。
2、重点关注持续迭代地是新开发功能，而不再强调传统测试过程中严格的测试阶段。
3、建议尽早开始测试，一旦系统某个层面可测，比如提供了模块功能，就要开始模块层面的单元测试，同时随着测试深入
持续进行回归测试保证之前测试过内容的正确性。
这种高频率的迭代测试，可以极大地提升产品成型的速度，bug能在最短时间内被处理。
这种测试非常考验测试人员的抗压、责任心、领导力和沟通协调能力。
但是敏捷测试也有很多的缺点，
在这里我只谈自己的感受，如果有不对的地方可以留言和我讨论：
测试人员工作压力大，休息时间少，几乎没有喘息的时间。
不同版本的bug管理比较混乱，验证起来需要梳理清楚，最好是借助专业的管理工具。
bug反复性高，可能在短时间内甚至不回出现bug逐步下降的正常趋势，而是产生较大的波动。
开发无法按照bug等级来确定工作优先级，因为可能在改一个中等bug，突然来了严重bug，也得等上一个bug改完
需求改动频繁，可能昨天做的功能或者做一半的功能突然就舍弃掉了
所以我们正常的测试中一般不回去做敏捷测试，但是有些公司比较推崇
四、集成测试（integration testing）、系统测试（system testing）
集成测试的重点就是测试各模块的接口，也就是组件或系统之间的交互。
集成测试侧重于集成测试的目标包括：
减少风险
验证接口的功能和非功能行为是否符合设计和规定
建立对接口质量的信心
发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部
防止缺陷遗漏到更高的测试级别
于组件测试一样，在某些情况下，自动化集成的回归测试可以增强信心，因为即使产品有变更也不会破坏已有的接口、
组件或系统。
系统测试侧重于整个系统或产品的行为和能力，通常会考虑系统可开展的端到端任务和开展这些任务时所展现的非功能行为。
系统测试的目标包括：
减少风险
验证系统的功能和非功能行为是否按照设计和指定的要求进行验证系统的功能和非功能行为是否按照设计和指定要求进行
确认已完成系统成且系统按预期工作确认已完成系统成且系统按预期工作
建立对整个系统质量的信心建立对整个系统质量的信心
发现缺陷发现缺陷
防止缺陷漏到更高的测试级别或生产防止缺陷遗漏到更高的测试级别或生产
一般情况下，系统测试的测试环境应该与集成测试的相同。
我为什么把集成测试和系统测试放在一起，因为我们在做测试的时候，经常是集成测试和系统测试同时进行。
集成测试意味着开发已经完成所有模块的开发，并且对产品有了一定的信心。
所以我们通常是直接进行集成和系统测试，也就是全用例、全流程、全功能、全接口的测试
测试环境由测试人员进行搭建，尽量与生产环境一致。
测试期间测试还不允许开发人员访问，直到一轮测试结束。
一轮结束后会将测试环境包括数据库移交给开发，用来复现相关问题，并查找问题原因。
开发提交新一轮测试后，测试人员重新大家那环境进行测试。
五、验收测试（acceptance testing）
验收测试通常侧重于整个系统或产品的行为和功能。
验收测试通常是由客户、业务用户、产品负责人或系统操作员负责，也可能涉及其他利益相关方。
验收测试的目标包括：建立对整个系统质量的信心
确认系统是否完整且系统将按预期工作
验证系统的功能和非功能行为符合规范
六、其他（确认测试、回归测试）
确认测试：修复缺陷后，应该在软件的最新版本上，重新执行之前因该缺陷而导致失败的测试用例。为了覆盖修复缺陷
所需要的变化，也可以使用新的测试来测试软件。至少必须在新的软件版本上重新执行这些由缺陷引起失效的步骤。
确认测试的目的是确认是否已成功修复原来的缺陷。
回归测试：部分代码所做的变更，无论是修复代码，还是其他类型的更改，都可能会意外地影响到除更改代码外的其他部分代
码的行为，不管是在同一组件内，还是在同一系统的其他组件中，甚至在其他系统中。变更可能包括环境的变化，例如操作系
统或数据库管理系统的新版本。这种意外的副作用被成为回归。
回归测试的目的是运行测试来检测这些意外的副作用。
七、技术类测（自动化测试、性能测试、接口测试）
自动化测试我会单独写文章讲。
性能测试是非功能测试的一种。
可以看我另外两篇文章
非功能性测试包括：易用性测试、性能测试、安全性测试、稳定性测试等等。
接口测试一般是用postman。