对测试的理解和一些测试需要常用的理念及通用方法

[张喜民]

这里只是个人认为测试经常保持的基本思想否则测试就是单纯为了测试而测试，下面的这几点如果做到，测试才真正的发挥作用，并且这个过程需要管理层和项目经理的认可和配合。

一、 测试在项目中的定位和测试的理念
1、 测试是要贯穿整个项目周期的，是项目经理的有利助手，项目经理和测试经理应该是类似于部队军团长和政委之间的关系，相辅相成的。
2、 测试经理不应是单纯的发现系统存在的缺陷，而是应该对项目风险（比如有风险的程序模块、项目进度风险等）有提醒预警的义务和责任。
3、 测试和项目经理的最终目标是一致的，但是测试在原则上是不能允许测试未完成或者遗漏缺陷上线的，如出现此情况应该由项目经理申请经高层领导决策是否上线。

二、 保证测试的常用方法
1、评审非常重要，未雨绸缪、防范未然、谋定后动都在这个环节上，如果没有好的邮件评审反馈意见的习惯，就一定要会议评审，前期浪费些时间可以减少很多风险，项目成本的概念就不多说了。
（1）需求说明书形成后，测试需要评审需求的可测试性及是否有风险，提醒项目经理规避风险。
（2）设计说明书形成后，需要测试评审可测试性、交易及数据的可跟踪性，如有问题提醒项目经理规避风险。
（3）测试需求和测试案例评审时，项目经理、需求人员、开发人员应该参与评审，需求人员检查是否有遗漏的功能，开发人员根据自己修改的内容，检查测试需求和案例是否有遗漏对修改内容的测试。并提醒测试人员重点测试哪些模块。
（4）评审的讲诉者一定要讲出自己对需求的理解和工作思路。

2、项目保障预警提醒
（1）进度预警，如果开发不能按时送测，测试经理应给项目经理预警在指定日期（可以是计划日期，也可以是计划日期后宽限的日期）不能送测对测试进度或者整个项目进度的影响。
（2）功能模块风险预警，当测试发现某个模块缺陷集中时，应给项目经理预警，项目经理应安排对该模块进行整体治理，不应在继续大量投入测试，否则对测试进度、项目整体质量和项目成本控制都是不利的。
（3）缺陷预警，当缺陷出现争议（包括开发和测试有争议或者关联系统间有争议）、缺陷反复出现三次或以上、缺陷驻留时间过长等，应给项目经理预警，召开缺陷讨论会议，尽快明确缺陷责任、缺陷修改方案和计划等。如多个关联系统测试时建议缺陷催促应采用首发负债制度（既首个接到缺陷的系统开发人员负责跟踪到缺陷关闭），但项目经理应起到监督作用，测试应继续关注及及时预警。
（4）项目保障，当项目经理不能及时处理项目风险，导致不能按时送测或者缺陷处理不及时等，测试有义务向上级上报风险，已保障项目风险上级及时了解，采取应对措施。
3、环境部署方面
（1）环境方面，测试环境由对应的测试经理管理，主要负责申请资源、申请配置修改、及测试查询日志等，但是可修改或部署权限的用户由专人管理。测试应只有可读权限，对数据库数据可以有适当的修改权限
（2）部署方面，测试环境部署和生产环境部署，最好是同一批人员。开发送测后，部署人员按部署手册部署，这部分人员最好具备系统工程相关知识，对操作命令应比较熟悉。并且可以处理测试提出的参数配置修改等日常出来和维护。
4、测试人员管理和分工
（1）一般情况写测试案例的人和执行人都是同一个人，可通过测试案例由其他人执行的形式进行交叉测试。可以通过这种方式更多的发现问题，避免因视觉疲劳引起部分缺陷不能发现；也可以通过此方式检查测试执行情况，如果遗漏的大量需求则测试人员需要进行说明和整改；同时也可以未人员备份做准备。
（2）测试的工作是比较杂比较细的，如果有不细致认真的员工，可以通过细化测试案例，通过测试案例跟踪，比如检查测试数据等，对测试工作进行监督。让员工被动的工作。
（3）经常测试的系统，测试案例执行时间是可评估的，分工时应充分考虑时间可控，其他因素也要考虑，比如：如果测试数据是否有不同状态，测试案例的执行是否需要前期准备的，如果有多个系统参与批量，批量计划应谨慎编排并严格执行，不可随意更改批量计划。
5、应及时定期发测试报告
进入测试阶段后，测试报告应定期发给项目相关人员。报告内容应明确说明当前进度，缺陷状态，是否有风险，风险描述，影响范围等。每个需求应单独发测试报告。
三、 测试经理需要的配合
1、 需要项目经理紧密配合，测试提出缺陷预警风险，项目经理应充分重视，并摆正态度，测试在帮助项目经理，一切为了项目不要认为是告状。测试需要项目经理建立起开发和测试的合作纽带。
2、 测试需要把握测试的基本原则，不能因其他考核等影响原则。如不及时提交缺陷或预警风险，是对整个项目不负责。