本文目录结构
前言
笔者未曾做过纯软件测试，所以接到一个自己不太熟悉的任务，对我来说还是有一些挑战的，如何从容应对方法很重要，以下整理了整个测试过程中的思考，是一个复盘过程也是一个总结，供大家参考同时也希望有什么建议或不足之处能给我留言，交流共同成长。
项目背景
对一个产品做系统测试并不等于产品就会有好的质量，所以要提升产品质量还要有策略，即测什么、怎么测再把这两个问题细化一下，如：
要测试系统的背景、用户人群都都是什么？
定位系统使用人群。系统是内部的人员管理系统，已经上线半年有余，系统还在持续迭代过程中，使用人群包括内部所有员工和管理人员。测试的目标是什么？
系统并非0-1的过程，已经是开发出来的并在持续迭代中，最近一次迭代主要修改了系统的底层接口，系统运营过程中也出现了一些越权的安全漏洞，所以本次测试重点还是要保障系统逻辑与安全。测试的对象和范围是什么？
OA系统通过腾讯云的微搭开发，通过公司内部系统进行鉴权登陆。OA系统与微搭的边界就是业务逻辑层和底座微搭，我们测试的目标主要还是针对业务逻辑层。测试的重点和难点是什么？
- 测试重点：逻辑和安全是首要，另外，根据系统设计文档结合产品的建议，对部分重点模块进行划分并抓要点进行测试。
- OA系统逻辑中有很多需要依赖其他如邮件系统、登陆系统、数据源系统、很多环境模拟成本较高或操作低频（如数据源同步系统到OA，每日用demon同步） 类似的建议放在最后的UAT阶段，由产品、开发和测试一起模拟演示时来验收。
测试的深度和广度是什么？
测试的广度与深度，需要从测试用例角度、项目时间维度的结合来看。从广度上看重点是测试系统的本身，其次是系统的周边依赖；测试深度要看用户画像和用户使用系统的行为路径。如何安排测试活动？
有了测试广度和深度，还要看测试的项目周期并倒退。本测试周期大约有20工作日，按测试用例每人每天能处理100~150之间，前期因测试人员对系统的不了解，保守估计测试用例覆盖在每日100个左右。所以，还要根据时间来对测试用例进行分类，并保障重点的测试用例能覆盖到。
测试过程
前期准备
系统测试首先要了解系统的业务逻辑,特别当前测试的OA系统业务逻辑性还是比较强的，这里可以从产品经理拿到系统设计的原型图、设计文档、需求场景文档和各种规范等，通过文档加深对系统的了解，更高效的方法是请产品经理来讲解这些文档，并围绕重点场景中重点问题来做分析讲解。
了解了系统逻辑后，我们还要看一下都哪些维度需要测试覆盖到，这里可以参考以下截图（来自测试架构师修炼之道一书）。
了解了系统、测试需要覆盖的点，接下来就要设计测试用例。测试用例的好坏，是否覆盖全对最终测试的结果还是有很大影响的，所以还要周全考虑这里的设计，关于设计用例的方法可以参考以下截图。
设计好的测试用例，我们还要对他进行分类与分级，这里级别可以围绕本次测试的重点来做基线，最后还要拉产品+测试同学对用例进行评审，评审后方可测试，以下整理了测试用例的模板供参考。
测试后的问题单，我们可以录入到bug管理系统中（其实这里也可以使用在线文档的方式，其实不管什么方式，主要还是协作时高效就好）。以下是笔者测试过程发现bug后的录入模版字段。
测试过程
功能测试
功能测试,主要保障系统流程特别是主流程的通畅，如所有输入输出的正常、边界值的正常、串行使用系统的正常、并行的正常和有前置如条件的场景正常（如管理员、普通用户在流程中呈现内内容不一致，需要登录不同的账号来测试）。
易用性测试
易用性,是指产品被多数用户使用时是步骤清晰（流畅）、舒适、易上手、易学习。易用性设计关注的是如何让产品被用户更容易、更高效、更愉悦地使用，从而提高产品的整体满意度。易用性设计需要综合考虑表达层、行为层和心理层等多个层面。表达层关注传达准确性，行为层关注使用效率，心理层关注心智构建：
- 表达层：设计师需要确保产品看起来可访问、减少认知负荷、区分视觉权重、贴合用户环境以及保持表达一致性。
- 行为层：设计师需要关注选择代替输入、降低沉没成本、减少重复过程、防止用户犯错、保持行为一致性和基于行为的智能化引导等方面，以提高用户完成任务的速度和效率。
- 心理层：设计师需要关注贴近用户心智模型和创造认知规律，以构建用户对产品的心智框架，让用户在使用过程中感到舒适和自然。
案例
在测试过程中，易用性的检测点，如各页面组件是否一致，以表格组件为例，当数据量大时是否有排序功能、检索功能，当数据维度复杂时是否有模糊搜索功能等；页面跳转是否平滑，如果出现问题报错是否清晰告知用户原因，同时还要告知用户问题对应的解决方案；产品文档是否完整易上手特别文档中如果有操作命令，命令是否可以直接复制并执行等问题，要重点关注这几类问题。
安全性测试
以下整理了关于安全的一些测试点。
笔者也整理了一些公网的开源工具，供大家参考：
- fortify：提供经验和动态应用程序安全测试技术；
- blackduck：对代码进行扫描、审计和管理；
- codesonar：静态缺陷检查和安全性分析工具；
- sonarqube:管理源代码质量工具；
- RSAS：绿盟安全漏洞扫描器；
- Nessus:安全漏洞扫描器；
- AWVS：Web安全漏洞扫描工具；
- burpsuite：用于渗透测试工具。
案例
上文有说本次重点测试是安全，经过了解系统在过往半年中系统也曾出现过安全的风险，不过均由系统使用人反馈给了管理员没有造成什么损失，所以本次重点中的重点是安全中的垂直越权与未授权访问，这里推荐使用 burpsuite 工具，功能还是比较强大的。
性能测试
性能测试要基于系统使用的UV和PV作为基线来进行评估，可惜的是系统历史运营数据没有做保留，所以通过OA覆盖的人数量进行则算来评估这里的访问量，同时性能测试我们要拿到系统的业务接口（一个业务接口可能调用多个原子接口）和业务原子接口，分别测试它们的性能数据。譬如OA系统覆盖5000人的使用量，我们则算10%的并发量也就是500同一秒访问峰值，从200开始做递增压测，这里我们要关注接口的三个指标，并发量、响应耗时时间和错误量等，寻找三者的最佳值，如某A接口并发量在500，平均响应耗时在5秒内，错误率低于20%算为达标（一次并发100个，20个未响应或报错，那么错误率为20%），200-500间按接口的重要程度，来评估接口的风险，低于200并发可能要及时的分析原因并优先修复。关于性能测试工具这里推荐如loadrunner、ab等常用性能测试工具。
UAT测试
在项目前期已经结果了产品系统测试后，在交付用户前还要拉产品+开发+测试做一轮UAT测试，UAT，(User Acceptance Test),也就是用户验收测试。由一个或多个用户角色来模拟使用系统并走主流程过程，大家一起来评估整个过程是否有问题，系统是否流畅、是否符合预期、很多系统低频操作（如从数据源同步数据到OA系统）是否没问题，如果发现问题后，可以根据问题的级别与对系统的影响来评估系统是否达到了上线标准。
测试报告
测试完成后，在上线前还要提供测试报告，而测试报告的信息应该由每天的进行迭代更新而来，而非测试完整后统一整理。测试报告提及的范围：
- 测试目标：需要提及本次测试目标与重点；
- 测试结论：本次测试是否通过，是完全通过还是部分通过，未通过模块的原因和建议是什么；
- 相关风险：从几个维度如质量风险、性能风险、稳定性风险、安全风险和其他风险等；
- 测试过程数据：展示系统测试、安全测试、性能测试和其他补充等；
要展示整个测试的过程数据，更好重点总结测试结论和潜在的风险供产品和系统负责人参考。
项目总结
笔者从事前、事中和事后三个维度来说一下测试的过程。
事前
项目的周期非常短，前期算我共四个人参与，我作为项目负责人前期需要收集到以下信息：
- 项目参与人的校色，如开发团队、需求方、系统背景
- 本次测试中重点解决的问题是什么
- 项目的设计文档、程序部署情况与架构图等信息(为快速了解需要让产品做前期的赋能培训）
- 历史测试用例 & 历史bug单
- 以项目上线节点倒退，进行排期。需要考虑到用例测试量、产生bug修复后回归量、性能测试要与正常测试尽量分开、UAT测试等场景。
- 对系统相关人，如测试、需求方进行一些访谈目的还是能抓住系统测试的重点。
- 项目日邮件、测试用例存放位置、bug单存放位置、修复bug时间与测试时间要区分开灯
- 对测试用例进行用例评审
- 程序要打详细的日志，用于事后问题定位、审计、后续系统迭代时数据支撑
以上这些前期准备后就可以按部就班地推进了，前期更多需要项目能力，能把提前预支的事情想清楚做到有步骤有计划，预防项目的风险等。
事中
测试要围绕本次系统变更的重点来进行测试。我们将测试用例按模块进行分类，并严格按照测试用例执行；并行的还要围绕着用户使用产品的主路径进行发散性测试和不同人的较插测试来保障这里的质量。
测试一方面要进项覆盖全，不要漏测是重点；另外，就是在测试过程中发现的问题的模块进行根因分类，定期汇总不同模块问题数据，当有模块问题比较突出时适当调整人力对此模块进行有针对性的测试，而非在测试之初设置好计划，后续就一成不变。我们重点保障的系统交付是高质量、而测试过程为保障这个目标也要有动态的调整。
画个重点，项目前期更多是需要有项目能力，事中时我们要围绕清晰的目标执行，执行就包括以下三个点：
- 目标：交付高质量的系统
- 重点：基于目标哪些是重点
- 数据：基于产生的bug量进行统计分析，不断修复测试重点和过程
事后
事后更多时前期数据埋点，做到系统质量、可用性可观测，同时还包括：
- 重点测试用例覆盖：要对重点模块中的重点用例进行复测（也可以做成自动化测试，这里要看必要性）
- 日志监控：包括错误码、接口耗时
- 服务器监控：如负载、如果是java程序还要关注内存利用率等
参考书籍
书《测试架构师修炼之道》
一文带你了解测试流程的体系：https://zhuanlan.zhihu.com/p/528715610