初め
| この作品は、カリキュラムに属し | リンク |
|---|---|
| どこの仕事でこの要件 | リンク |
| チーム名 | ランニングマン |
| 対象のジョブ | Αのプロジェクトチームは、最初のテストバージョンとリリースを完了しました |
第二に、チームメンバーのリスト：
| Lixing陳 | 201731091410 | リーダー |
|---|---|---|
| 劉イワン | 201731062603 | 乗組員 |
| 陳Jiaying | 201731104215 | 乗組員 |
| チェ・タン・ウェイ | 201731062416 | 乗組員 |
| タン・ウェイ | 201731062415 | 乗組員 |
第三に、アドレスを公開し、手動操作のプロジェクト：
公開アドレス:( http://121.199.76.80:3000）
ウェブサイトの操作マニュアルです。
（1）ログイン及び登録を使用
ブラウザでプロジェクトの発行サイトを入力し、当社のホームページにアクセスしてください。（注：これは、Googleのブラウザを使用することをお勧めします）
ホーム：
、ホーム・ページの右上にあるログインボタンをクリックして登録ログイン画面を入力してください。
まず登録するサイトの必要性を入力し、ユーザー名、電子メールまたは電話番号、パスワードを入力します。あなたは、登録メールまたは電話番号を完了するために、次の要件に従って識別コードとしてログインすることができます。
ログイン登録：
（2）は、注文ユーザマニュアルを発行しました
そこユーザー、リリース発注の2種類があり、党登録ログイン方法の受注を受け入れることは同じです。ログインに成功した後、リリース発注を動作させることができ、ページの要件に従って情報を入力し、[発行]をクリックします。
（3）受注ユーザ（実行中の用事メンバー）マニュアルを受け入れます
用事を実行するための認定メンバー①
個々の中心をクリックして、あなたの本当の情報に用事を行うことができる学校のスタッフの認定を用事メンバーを慎重にクリックしてください。
証明：
（注：DOは用事がタスクを受け入れることができないタスクの唯一の認定メンバーを発行することができます実行しません）
②絵ラウンドバックホームページをクリックして、順序を受け入れるためにクリックし、注文がインターフェイスに行うことができます。
あなたが順序を受け入れるようにしたいかどうかを判断するための簡単なタイトルで、あなたは、さらに2つの方法で判断することができ、あなたは、発行者とのチャットを確立するためにクリックする、または私は特定の情報の順序を確認したい注文をクリックすることができます：
注文操作：
セッションウィンドウ：
具体的な受注：
最後に、私は完了した注文が動作オーダーをクリックします。
（4）個人センター
現在の注文、メッセージセンター、個人的な信頼性と実行用事メンバーに認定されてしまう：個人的なセンターは、4つの機能を備えて
①現在の順位は、次のとおり、現在の注文状況を確認し、あなたの履歴注文状況を見ます。
②メッセージセンター：ビューあなたが最近送られたことをあなたが受信したメッセージとメッセージ
③個人的な信頼性：あなたの現在のクレジットを表示して、あなたの信用記録
あなたの身元を完了するために、学校情報：④は、実行用事メンバーに認定されてしまいます
第四に、テスト
試験報告書のα版
テスト作業の手配
プロジェクトの現在の位相の試験は、主に試験組成物のα端の開発の現段階の通常のユニットテストおよび開発プロセスによって製造されます。チームメンバーは後に提出を経由して、コード、テストコードを完了した後、適切なユニットテストを行います。主開発のこの段階の完了のテスト作業後のα試験。αテストは、ソフトウェア開発環境でのトライアルチームのメンバーで、主に需要分析ソフトウェア要件、非公式の受け入れの発展のこの段階の結果に応じて、ソフトウェアの機能とインターフェイスに焦点を当てました。
| グループメンバー | モジュールの責任 |
|---|---|
| Lixing陳 | ログイン登録 |
| 劉イワン | チャット |
| 陳Jiaying | 公開された注文 |
| タン・ウェイ | 個人センター |
| 唐魏でした | 用事モジュールを実行するためのメンバーの用事 |
テストツールを選択します
RESTfulなインターフェースの設計、試験された郵便配達の後端部によって提供されるインターフェイスを使用するため、このプロジェクトで使用されるJUnitのユニットテストは、使用して行います。試験中のフロントエンド主流のクロムブラウザのWindowsオペレーティングシステム。
テストケース
登録機能テスト
| テストケース数 | 試験手順 | 期待される結果 | リマーク |
|---|---|---|---|
| 0001 | 任意のデータを入力しないでください | ユーザー名プロンプトを入力してください。 | |
| 0002 | 唯一のユーザーのユーザー名を入力します。 | ユーザー名はの入力を求め入力してください | |
| 0003 | 唯一のユーザー名と電話を入力してください | パスワード・プロンプトを入力してください。 | |
| 0004 | 入力電話が登録されています | プロンプト登録失敗 | 携帯電話は、ユーザーを登録することができます |
| 0005 | 自分のユーザー名を入力し、電話が使用されていない、とパスワード | 登録は、ログインに成功すると調整 |
ログ機能検査
| テストケース数 | 試験手順 | 期待される結果 | リマーク |
|---|---|---|---|
| 0006 | 任意のデータを入力しないでください | ユーザー名プロンプトを入力してください。 | |
| 0007 | 唯一のユーザー名を入力してください | あなたのパスワードを入力するように求め | |
| 0008 | 正しいユーザー名とパスワードエラーを入力します。 | ログインの失敗 | |
| 0009 | 正しいパスワードを入力し、不正なユーザー名 | ログインの失敗 | |
| 0010 | 正しいユーザー名とパスワードを入力します。 | 自動ログインに成功、ホームページにジャンプ |
チャット機能テスト
| テストケース数 | 試験手順 | 期待される結果 | リマーク |
|---|---|---|---|
| 0011 | チャットを開始するためにログオンしないでください。 | ヒントログイン | |
| 0012 | ログイン後にチャットを開始 | チャットウィンドウを入力します。 | |
| 0013 | 入力されていない、メッセージを送信 | ヒントは、コンテンツを入力します。 | |
| 0014 | メッセージを送ります | 送信成功、データベースに保存されたチャットデータ | メッセージセンターには、開発中です |
用事モジュールを実行するためのメンバーの用事
| テストケース数 | 試験手順 | 期待される結果 | リマーク |
|---|---|---|---|
| 0015 | 入力された学生の数がすでに存在している一般ユーザは、認証、 | ヒント認証失敗 | 学生数のみ認定者 |
| 0016 | 普通のユーザーは、認定の学生数は、未使用を入力してください | ヒント認証が成功しています | |
| 0017 | メンバーは、用事の注文を実行していました | ヒント受注成功 | |
| 0018 | センターでは、現在の個人的な用事の注文を表示します | 文として注文状況 | |
| 0019 | 変更オーダーステータス | 提示更改成功 |
个人中心测试
| 测试用例编号 | 测试步骤 | 预期结果 | 备注 |
|---|---|---|---|
| 0020 | 未登录点击个人中心 | 跳转到登录 | |
| 0021 | 登录后进入用户中心 | 成功进入 | |
| 0022 | 查看历史订单 | 和数据库中的数据吻合 | |
| 0023 | 查看信誉积分 | 和数据库中的数据吻合 |
发布订单测试
| 测试用例编号 | 测试步骤 | 预期结果 | 备注 |
|---|---|---|---|
| 0024 | 表单不完整 | 提示表单不完整 | |
| 0025 | 表单完整，未登录 | 提示未登录 | |
| 0026 | 表单完整，且登录 | 提示发布成功 |
测试阶段人员总结：
| 谭伟 | 本来以为测试是一件简单的事，可是在真正测试时，遇到了许多的问题，如网页间的跳转关系不对，导致网页就像一团乱码，在各处跳转，又如前端返回出来的值与后端想要的值不同，导致在前端显示null，于是又重新梳理了一遍项目逻辑，在一遍又一遍的调试中，逐渐将代码完善，在这中间也学到了许多有用的知识，如有效利用浏览器的查看源码功能，以及端点的使用，这些都是很有效的测试方法。总之，在这一次测试所获良多。 |
|---|---|
| 陈嘉莹 | 测试时要考虑用户未认证和已认证两种情况；且用户没有订单，含有订单，含有被评价的订单都要分别测试查看返回的json数据是否正确。测试的过程比较繁琐，由于我只是做部分功能的测试，需要在本地数据库里添加大量数据，经常被表与表之间的外键关系给搞晕。另外，本地测试成功了部署到服务器上可能会出现一些不适配的问题，当然最后我们都解决啦。 |
| 刘伊凡 | 对前端进行了测试之后，发现的前端问题比较少，都能够很轻松的改正。在网络请求导致界面变化，与后端交互等操作都表现得正常可行，但第一个版本仍然有不够完善的地方，有的功能还没有办法检验，在后续的开发中会持续的完善。 |
| 李星晨 | 测试会帮助人们发现很多思考不周到的地方，很多时候我们完成某个功能是按照固有的思维或者按照设计文档去做，但是会出现数据不正确或者很多地方对接不上的情况出现。利用好测试，可以帮助我们很好的改善我们的项目，是一个很优秀的方式。 |
| 唐财伟 | 每次在编写完后端程序，尤其是Dao层和service层程序后，都使用junit进行单元测试，能够很好的将问题扼杀在摇篮状态。为前端结合前端进行调试做好了保障。也更容易发现在α测试中不容易发现的问题。在α测试中，更多是站在使用者的角度对项目进行验收性的测试，除了考验程序的正确性之外，还要考虑程序的性能，易用性等。α测试是对项目的更高层次的检验，也是我从未体验过的全新感觉 |
五、项目第一阶段记录
1.git仓库：点一下
（ps：仓库中master分支上一部分提交没了，丢失的那一部分提交记录在tcw分支上，所以之前的提交记录需要去分支里面的tcw里面查看~）
2.任务记录
因为这次的项目比之结果而言，更注重的过程和分析部分，所以这次更能锻炼每个成员的分工和协作。
但是因为学生身份，像每天开例会的方法并不适合我们，所以我们使用了一个项目管理软件——禅道。
在禅道上，我们充分利用其来管理我们的项目，对我们项目进行一系列的管理操作：如需求分析、任务分配、燃尽图、文档管理，项目设计等等...
在禅道到，我们组的成员采用的方式是先由组长发布任务，建立需求，设置优先级。组员自己设置任务进度，达到开发透明，大家对项目进度有一个明确的掌握，同时，显著的优先级的表示法能够让开发人员充分明白任务的重要性，达到明确优先级。
同时，组员拥有修改的权限，可以对分配不合理的地方进行修改。
展示部分记录
发布任务展示：
任务看板展示：
项目总览：
后台管理：
六、项目情况总结
- 在第一次α版本发布之后，本项目完成了内容
| 注册登录功能 | √ |
|---|---|
| 核心功能：发布订单 | √ |
| 核心功能：接受订单 | √ |
| 查看订单 | √ |
| 会话窗口功能 | 80% |
| 个人信誉 | 80% |
| 个人中心 | 50% |
| 评分功能 | 50% |
和项目预期相比未完成功能
基本符合项目预期
下一次的展望和安排
①展望
在下一次的α项目中，我们需要对功能的进一步完善，完成会话窗口和个人信誉部分，同时完成评分功能，个人信息功能完善。同时对UI界面要进一步完善，优化用户体验。
②安排
时间 作業内容 1-2日 フィニッシュセッションウィンドウ 3-4日 注文状況セクションの完璧な 5-6日 ライン上で採点 1-7日 UIインターフェイスの改善