给你一个系统或项目你怎么做测试？

 一、明确测试任务：

1.确定项目的研发周期、项目进度、版本发布时间以便于制定测试计划。

2.查找已有的需求说明，功能设计等文档进行需求分析便于了解自己的工作内容和熟悉项目。

3.与测试负责人、或项目负责人明确工作对接。（提bug是按照已有规则还是自由发挥，具体问题提交给指定人还是统一分发，有没有工作会议等）

二、明确分析测试范围：

1.了解测试对象都有哪些（包括需要测试哪些平台、哪些文件（演示脚本）、各类手册（安装手册、使用手册））

2.了解版本迭代中测试功能有哪些（第三方功能需求测试吗？只包含当前版本提测功能？测试类型有哪些？）

三、制定测试计划、策略、方案：

测试计划：

测试计划制定包括：测试进度、时间安排、测试任务分配、测试任务的责任人、测试任务风险、文档的存放、工具的使用、测试中的资源获取、测试阶段。

测试策略：

⑴测试的优先级：高需求、新功能、旧功能改动、使用率高的功能、危险性大的功能

⑵测试标准：

　　　　　　准出/准入标准：

　　　　　　　　　　 　　 准入： 1.开发人员完成自测

　　　　　　　　　　　　　　　　2.需求功能基本实现，没有需求需要开发提供范围

　　　　　　　　　　　　　　　　3.提测演示通过基本冒烟测试

　　　　　　　　　　　　　　　　4.开发人员提交测试申请和相应的文档

　　　　　　　　　　　　　准出：1.满足客户需求

　　　　　　　　　　　　　　　　2.用例通过评审并完成执行

　　　　　　　　　　　　　　　　3.测试覆盖率达到要求

　　　　　　　　　　　　　　　　4.所有bug已经记录在bug管理系统

　　　　　　　　　　　　　　　　5.一、二级bug修复率100%

　　　　　　　　　　　　　　　　6.三、四级bug修复率达到95%

　　　　　　　　　　　　　　　　7.遗留问题都有解决方案

　　　　　　　　　　　　　　　　8.测试 满足要求

　　　　　　　　　　　　　　　　9.完成测试总结报告

　　　　　　通过/失败标准：

　　　　　　　　　　　　　通过/失败：1.系统测试执行对需求达到100%

　　　　　　　　　　　　　　　　 　　2.高级、中级用例100%执行，低级95% 3.缺陷修复率达到99%，无致命和严重bug

　　　　　　挂起/恢复标准：

　　　　　　　　　　　 　　挂起/恢复：1.测试过程发现致命bug导致用例50%无法进行，堵塞问题修复后恢复测试

　　　　　　　　　　　　　　　　  　　2.高优先级用例未执行100%,待回归测试通过后继续

　　　　　　　　　　　　　　　　  　　3.版本不停变更和需求不停变动，待开发自测后恢复

　　　　　　　　　　　　　　　　  　　4.外部 因素导致测试无法进行，通过项目经理确认后恢复

⑶预估工作量：设计用例时间，执行用例时间，bug回归时间，测试文档交付时间

⑷风险评估：软硬件环境未到位、用例没有完成、需求或界面变更、开发未完成研发

测试方案：

功能、性能、界面、数据库、安全、兼容测试的实施阶段

四、编写测试用例和执行：

1.通过测试用例设计方法进行用例编写：

　　　　等价类划分法：划分有效等价类和无效等价类。有效指对系统的输入是合理的，检验系统实现需求规定的功能；无效指不符合需求的数据输入是否有异常。 例如：手机号 有效：11个整数 无效：输入字母、汉字、特殊符号

　　　　边界值分析法：输入或输入的边界值进行测试 例如：上传10个文件 取点：0、1、5、10、11个文件上传

　　　　错误推测法：根据系统实际情况，结合实际情况进行推断。 例如：日期开始时间大于结束时间；为空、为0的判断

　　　　判定表法：通过输入输出的组合方式进行分析 例如：重要类型1 2 3 4 次要类型A B C D 两两组合输出不同的结果

　　　　正交实验法：测试多因素、多水平的一种情况，通过少数代替全面，选择具有代表性的数据，多用于在查询。 例如：1班和2班男女生成绩及格或不及格

序号	性别	班级	成绩
1	女	1	合格
2	女	1	不合格
3	女	2	合格
4	女	2	不合格
5	男	1	合格
6	男	1	不合格
7	男	2	合格
8	男	2	不合格

 

五、工作内容评审：

1.测试用例评审

2.需求评审

3.提测演示

4.产品验证

六、记录bug进行跟踪管理回归验证

七、测试完成后文档的输出、归档

八、测试完成工作内容讨论和总结

主要讨论本版本在进行测试时遇到的问题，与研发、产品的建议，和自己本次测试总结及技术分享。