测试经验之谈

如何保障软件测试的质量?我们定位这样一个角色：你是一名功能测试人员，在项目组负责某个子系统（或者说后台服务）的一个版本测试，该版本新增了功能，又修改了原有bug。

没有规范的文档，你将如何测试？有人是如此测试的：咨询一下开发修改了哪些功能，拿到手上开始根据开发提供的思路跑流程，测试通过，上生产。

结果生产上造成很严重的问题，而这个问题产生的根源是开发改动了关联部分公共方法。

同时作为测试，根本没有考虑到该版本的功能关联了哪些业务场景，所以也无法发现该问题。

项目经理问责测试：作为对该系统测试了两年多的你，为何这么简单的问题都发现不了？测试用例写得这么粗糙。

这是我眼前的真实存在的一幕。

我无法端坐在旁边，看着可怜的测试人员在无力解释，“我也发现了很多问题，你怎么就看不到？”“我们联调协调的很辛苦……”。

我很想知道问题在何处？思考良久，我知道某个人肯定有问题，但又不全是某一个人的问题。

需求没有文档，开发没有设计思路，测试设计缺失，遗漏该功能的测试，最终问题在生产上“华丽丽”地暴露出来。

姑且不论需求和开发的问题，我认为测试可以往前多走几步。

第一，一定要进行测试设计，站在用户的角度，进行测试设计。

时间紧张时设计的粒度可以只到测试场景，预期结果中包括检查的点。

有充分的时间还是建议编写规范的测试用例，描述清楚前提条件、操作步、预期结果、优先级等。

测试场景必须覆盖所有改动的功能点，而且一定要进行全流程测试。

保证该功能的修改不会影响整条流程。

第二，一定要进行回归测试，这里的回归测试视情况而定，时间足够全量测试，时间不够，一定要对系统核心功能进行回归测试。

例如金融行业的交易，回归测试场景必须包括的各类正常场景和重要的异常场景，保证版本上线以后，用户还能继续使用这些核心功能。

回归测试需要对系统深入理解，判断用户核心业务场景。

第三，版本如何极大低影响性能，需加入负载压力测试、稳定性测试、大数据量测试。

第四，沟通，沟通，再沟通。

把测试的场景全部列出来，给需求和开发过目，请他们协助判断一下是否有漏测，或者理解有误的地方。

对于这种没有文档的项目，系统设计全部留在大家的脑海中，每个人理解可能都不完全一样，通过测试用例去统一大家的思路，保证我们测试的有效性。

第五，如果明知道该版本对功能影响范围较大，而市场或者项目经理又催得很紧，一定要告诉他们风险非常大，具体表现在哪些方面。

这样他们经过仔细斟酌，如果得不偿失是绝对会支持你的，如果他们能够承担风险，就会考虑上线。

如何转做测试管理？很多测试人向往做测试团队管理，结合最近参与面试测试管理角色的观察，简单总结下：1. 眼高手低要不得很多85后们目标都很明确：宁做管理不钻技术。

有明确的目标是优点，但基础不扎实浮于表面的了解在管理一个技术团队时候想游刃有余，可以说不可能！这点和开发团队管理一样，让一个外行架构师领导一群程序员，今天程序员说需要重构明天说接口要改，而架构师不懂只会要求继续赶工的团队想留住人很难！2. 自信十足无实践经验易被识破越来越多测试人胆子特别大，也开始擅长吹牛了，比如连个基本项目都没带过的就面试测试管理职位，不能说不好，至少说明有自信愿意尝试。

但是现实是，几个实践问题问过就知道不能胜任，见过猪跑跟吃过猪肉还是两码事，所以要做管理还是踏实在公司内部锻炼过再跳吧。

3 混淆项目管理和测试团队管理作为一枚测试人负责一个产品的测试甚至负责协调沟通所有此项目相关的合作，这只能算作带项目，比如项目的进度控制，产品需求review，产品测试报告分析，自动化测试技术等等。

而测试团队的管理分两类：一类测试管理者兼职某一项目的测试任务，同时负责团队管理，包括但不仅限于团队建设、资源平衡、招聘面试、跨团队跨角色沟通协调、团队成员的绩效考核、团队成员导师角色，最重要的是建立质量控制流程并持续优化升级；另一类就是纯管理角色，不参与一线测试，仅负责协调沟通、团队管理。

互联网业里前一类人更多，后一种人几乎和流行的敏捷管理合二为一了。

总结需要以下几个主要方面：1. 主动承担更多任务比如负责某一项目的测试，做到可以独立完成一个项目的所有测试任务。

2. 掌握若干关键技术至少有一项突出，成为这一块的顾问角色，也就是大家遇到这类问题第一个想到咨询的人是你，无论业务还是高深技术研究。

3. 学习一些人力资源管理的经验学习团队建设，与人相处的技巧等，向上管理向下管理都要学，只要不是老板一把手，测试管理者都是夹缝里求生存的。

4. 跟对人对普通被领导的测试人来说，跟对人很关键，看看自己想往哪方向发展，那么就向哪个类型的领导学习，不要小瞧潜移默化的威力。

5. 等待时机公司内部锻炼是最佳途径，积极寻求培训等机会。

没有实践经验而直接空降新公司不说能不能hold住团队成员，业务再不熟悉，无数坑等着你踩，无数黑锅等着你背呢。

任何一个角色都不容易，一分付出一分收获，一分责任一分回报。

做技术管理离不开技术，钻研技术会管理百益无害。

做了领导就请学会保护下属，才会让下属死心塌地，离开后都会念念不忘的，那么你就真正地转成功了。

个人信奉无为而治，一个优秀的领导自带气场，可以让团队成员安心做事的管理者才能算上合格的管理者。

产品经理如何进行测试？产品经理，作为一个需要多种技能加身的岗位，在一些人员配备不足的公司中，可能需要同时担任产品和测试两个工作。

当我们完成了产品经理撰写文档，评审，跟进开发工作后，最终拿到开发人员提交的版本，应该如何在测试中尽可能多的发现bug和不符合产品需求的地方？关于如何更好完成测试工作，我有十个方法分享给大家。

1.UI设计测试：页面所包含的所有字段，图片，图标等界面元素，产品经理要和设计人员一起根据设计要求进行验收和反馈。

2.测试用例测试：根据prd撰写测试用列(可按照正常流程/异常流程/分支流程，并使用因果图法遍历功能)，测试用例需要遍历所有功能，测试时根据测试用例进行，也更方便进行bug的定位。

3.错误推测法：根据经验和直觉推测出可能会出现的bug，并对此设计测试用例，作为补充测试用例的一种方式。

4.字符测试：根据特殊字符，长度，表情，中英文，符号，阀值限制等要求进行输入测试。

5.缓存测试：从缓存的数据和大小（峰值设置），缓存时间，缓存环境（有无网络），缓存存储方式等几个方面进行。

6.最多/少数测试：阀值，观察系统的反应及显示（一般指压力测试，需借助一些平台进行操作）。

7.多环境/外部环境测试：同一系统不同版本，不同屏幕分辨率，不同厂家设备，GPS（关闭或不佳），摄像头，加载时长等情况的测试。

8.准确性测试：搜索数据结果的相关性和准确性。

9.排序测试：根据产品设计规则，进行排序测试和调整。

（包括消息列表，产品列表，时间等）10.账号测试：账号首次登录，新建账号登录，同一账号不同机型多次登录，同一设备不同账号登录时数据显示情况测试。

后面的七条方法是会与测试用例一起交叉使用的，这样才能保障遍历大部分用户使用时会发生的情况。

不过人无完人，程序或多或少都会有些错误，希望通过一点经验分享，让更多的产品人在设计产品和测试时逻辑更严谨一些，将自己的产品打磨的更好。

如何制定合理的工作计划？如何制定计划需要考虑的几个重要因素：第一、充分估计整体工作量在进行制定工作计划前，要有一个整体的工作量的估计，这时要粗略估计项目每一个模块的工作量及难度，做到心中有数，制定一个比较粗的计划，大概哪个时间段内要完成哪些模块的工作。

第二、根据个人能力分配任务估计完工作量后，还要根据项目组成员的个人能力来分配任务，这其中要考虑到个人的能力问题，还要考虑到每个人的习惯（比如：有人喜欢一步到位的工作，有人喜欢先搭起基本功能块，再抽时间解决其中的小问题），这样对于一步到位的人，可以基本模块工作时间放长一些；对于喜欢粗略完工，再解决小问题的人，要留出他完善系统的时间。

总之一句话：因人而异的制定工作计划。

第三、及时检查工作，调整计划根据上边讲过的2个因素，可以大概进行计划安排，以周为单位，安排一周的工作，在这一周当中也要及时检查项目的进展，了解有没有难度，进展是否顺利，如果因为前一周的工作没有完成，要充分分析原因，及时调整计划，这时周计划变了，那么在排下一周计划时，要把这些滞后完成的工作和后边的工作合起来，重新周调整工作计划。

第四、遇到难题，集中解决项目在进展过程中，难免遇到难题，我们可以遵循一个这样的原则：如果你遇到一个问题，通过自己的努力在不大于2小时的时间内扔没有一点思路，这时需要把这个问题提出来，大家一起想办法解决，毕竟大家的力量比较大；还有一点，也许这个问题在你这是难题，也许别人有很好的办法帮你解决，所以在遇到问题的时候，我们首先要自己想办法解决，实在解决不了就借助大家的力量来集中解决，千万不要因为一个难题就耽误整体的进度，这样是得不偿失的。

第五、向领导汇报对于TL来说，定期向领导汇报这是少不了的工作，但在向领导汇报之前，首先要自己做到心中有数，当然要努力维护集体的利益，尽量为项目组人员多着想，向领导展示好的一面，但项目中实在有的困难也是要事实汇报；这样中间遇到问题解决了，才不至于影响整个项目的总体进度。

综合以上几点，不难看出，TL在整个项目中起到了“桥梁”和“调和剂”的作用，当然如果工作作的好了，大家可以提些建议一起参加一些活动，增加一下团队的感情，当然也是为了更好的放松，相信心情好了，也会给大家带来工作的积极性；个人觉得只有充分的把握上边列的几点，才能做出一个比较细的工作计划，才可以使项目单元的划分做到最小化，当然这只是我在项目中提练出来的一点经验，欢迎同行的朋友们多提些意见，使大家共同进步！！测试计划和测试方案区别关于测试计划和测试方案的区别，这里主要从编写目的、定义和层次、编写时间和依据、软件过程、文档内容这五方面来说明，具体内容如下：一、编写目的制定测试计划目的：按照所制定的测试计划可以有效的计划、执行、跟踪、组织和管理测试项目。

具体从一下三方面来说：1，领导能够根据测试计划做宏观调控，进行相应资源配置等；2，测试人员能够了解整个项目测试情况及项目测试不同阶段所要进行的工作等；3，便于其他人员了解测试人员的工作内容，进行相关配合工作；设计测试方案目的：软件测试方案的作用非常类似于产品设计说明书（软件概要设计和软件详细设计），开发工程师根据产品功能需求和设计说明来编码实现功能，而测试工程师需要基于产品功能需求和测试方案来设计和执行测试用例。

测试方案是从测试的角度去分析或者说分解需求，在方向上明确要怎么测，分析结果就是测试点和测试方法。

二、定义和层次测试计划是组织管理层面的文件，从组织管理的角度对一次测试活动进行规划。

它是对测试全过程的组织、资源、原则等进行规定和约束，并制订测试全过程各个阶段的任务以及时间进度安排，提出对各项任务的评估、风险分析和需求管理。