软件测试流程

step1：参与需求评审

（1）什么是软件需求？
   为用户解决某一问题或达到某一目标所需的软件功能，描述软件功能。

（2）什么是需求评审？
   项目相关方就软件需求进行评估和确认的相关活动。

（3）评审的目的
   保证需求说明书完整准确，保证项目团队对需求的理解达成一致。

（4）测试人员在需求评审的职责
   确认自己对需求有清晰的理解，没有疑惑。
   确认需求文档完整准确，能够指导后期工作。
   对需求中不合理的地方提出自己的修改建议。

step2：编写测试计划和方案

step3：编写和评审测试用例

（1）测试用例需求来源：

• 通过文档：《需求规格说明书》、原型、高保真图
• 站在用户角度：测试软件的易用性

（2）测试用例设计步骤：分析需求->整理测试点->编写测试用例
         测试点: 测试中需要关注的具体功能点,用来拆分需求，辅助编写测试用例。

（3）编写用例的原则：能看懂，能执行

step4：执行用例和BUG跟踪

（1）测试结果状态：通过（pass）、失败(fail)、阻塞(block)、忽略(NA)

（2）执行用例原则：严格按照测试步骤执行，失败的用例及时提交缺陷报告

（3）缺陷的严重程度：

• 致命：系统主要功能不可用、系统崩溃、闪退、无法启动等
• 严重：系统次要功能不可用、边界、异常未进行处理等
• 一般：易用性问题、界面显示、小的性能问题等
• 提示：建议性问题

（4）缺陷优先级：

• priority 0：必须在24小时内解决
• priority 1：产品发布前必须修复
• priority 2：可以在下一个版本中修复

（5）缺陷状态：

• 新建（new）
• 打开（open）
• 修复（fixed）
• 拒绝（rejected）
• 延期处理（postponed）
• 重新打开（reopen）

（6）数据库

• 在测试时，通过SQL操作数据库表，为测试提供数据
• 做界面测试中的某些数据统计，因为需求说明书中不能直接说明这些数据（预期结果：SQL统计到的数据；实际结果：界面显示数据）
• 通过SQL语句查询数据表中数据具体的值，通过表中的数据明确定位BUG具体模块（有些BUG可以明确的测试到，但不能定位具体的模块）
• 可以不删除表，不重建表，保留表中数据，给表添加或者删除字段（alter table add/drop cloumn 字段名 类型）

step5：编写测试报告

其他：如何熟悉一个项目？

熟悉项目的步骤：
（1）了解项目的业务特性： 项目是用来做什么的？
（2）了解项目的角色与用户： 项目是给谁用的？
（3）了解项目的组织架构图： 项目包括哪些功能模块？
（4）了解项目的技术栈： 项目是使用哪些技术实现的？

熟悉项目的渠道：
（1）项目中已经存在的文档（需求说明书、用户使用手册、测试用例等）
（2）通过使用项目的现有环境（开发环境、测试环境、 线上环境等）
（3）询问项目中的其他成员（测试组员/组长， 开发人员， 产品经理等）

熟悉数据库表
数据库作为网络的一个重要应用，其在网站建设与网络营销中发挥着重要的作用，与普通网站相比，具有数据库功能的网站网页我们通常称为动态页面，也就是说页面不是一成不变的，页面上内容(或部分内容)是动态生成的， 它可以根据数据库中相应部分内容的调整而变化，使网站内容更灵活，维护更方便，更新更便捷。通过熟悉数据库，也能够帮助我们更深入，更全面地了解项目。