The PIN Code and PUK Code.

 如果你沒有更改過PIN碼,你可以先嘗試1次以下台灣SIM卡預設PIN碼:

  • 中華電信:PIN1為0000,PIN2為1111
  • 台灣大哥大:1234
  • 遠傳電信:PIN1為8888,PIN2為1234
  • 台灣之星:0000
  • 亞太電信:1234
  • 如果嘗試預設PIN碼失敗,或者你更改過PIN碼,那麼可以向運營商尋求協助。你需要提供身份證明,表示這組號碼是屬於你的,以下是PUK碼查詢與客服專線:

    JIRA + Xray...(a research study note, it's not ready yet.)

     Xray: a research note. (not ready)

    通常在使用一個Xray的測試項目之前,最好先創建一個需求相關的項目,這樣通和需求項目的關聯,我們可以很容易知道測試的覆蓋率。

    在系統中,測試用例會關聯到需求(Requirement) 或是缺陷 (Defect) 中,典型的需求問題會包括:

    Epic, Story, Requirement, Sub requirement, Feature 和improvement 這些,典型 的缺陷問題包托:Bug  and Defect. 


    https://www.atlassian.com/agile/project-management/epics-stories-themes#:~:text=In%20a%20sense%2C%20stories%20and%20epics%20in%20agile,stories%20leads%20to%20the%20completion%20of%20an%20epic.

    What are stories, epics, and initiatives?

    • Stories, also called “user stories,” are short requirements or requests written from the perspective of an end user.
    • Epics are large bodies of work that can be broken down into a number of smaller tasks (called stories).
    • Initiatives are collections of epics that drive toward a common goal.


    FOTA (Firmware Over-The-Air) -NOT ready yet

     What is FOTA?

    FOTA is a mobile software management technology that enables the updating of a mobile device’s operating system.
    The download process for FOTA-capable phones is typically less than 10 minutes.
    (Not anymore)

    FOTA simplifies the process of updating mobile device firmware by allowing manufacturers to provide it through a single, secure and fast method. This eliminates the need for manual downloads and simplifies the process of keeping devices up to date.

    Bugfix allows manufacturers to repair faulty units and remotely update software updates. This method typically involves the consumer downloading and updating mobile device firmware through a manufacturer’s website or server. FOTA updates are generally accessible through the device menu or software or firmware update

    Device management protocols

    LwM2M (OMA Lightweight M2M),
    built by the Open Mobile Alliance, is a light, fast and structured protocol, ideal for low-capacity device.

    OMA-DM (OMA Device Management),
    built by Open Mobile Alliance, but more oriented to mobile applications. Ideal for things in movement (changing IP address for instance). More complex and structured tan LwM2M.

    TR-069,(CPE WAN Management Protocol, remote device deployment)
    created by the Broadband Form and used in hundreds of thousand of devices all over the world, being a protocol widely used by telecommunication operators to provision their routers, etc.

    MQTT, (Message Queuing Telemetry Transport)
    MQTT is an OASIS standard. The standard protocol with the most impact in IoT is MQTT. since is light, robust and overhead-less. It works with in a subscription-publish model, very similar in concept as a lot of chat tools. This protocol is oriented to communication, but it lacks of a native IoT Device Management feature.





    Firmware and Software Upgrade Process

    • To Determine Firmware Versions
      Automatic update check
      Manual update check
    • To Obtain Newer Firmware Versions
      Unicast transport protocols : HTTP / HTTPS (TR-069 mandatory), FTP, SFTP and TFTP
      Multicast protocols : FLUTE and DSM-CC 
    • To Upgrade the Firmware
      Conventional FOTA (without Secure Boot) ?
      Secure Boot Mechanism for Secure FOTA ?
    • To Validating the upgrades

    TR-069 Software Update

    • Setup the Software update test environment
      • Server (TR-69 ACS) / 
      • Client (CPE or CWMP Endpoints)
    • Requirements (Inform RPC method )
      • The CPE MAY at any time initiate a connection to the ACS via a CWMP Endpoint using the pre-determined ACS address.
      • The ACS MAY at any time request that a CWMP Endpoint initiate a connection to the ACS using the Connection Request mechanism. 
    • File Transfers
      • The CPE MAY send the HTTP/GET/PUT over the already established connection.
      • The CPE MUST use TLS when the file location is specified as an HTTPS URL.
    • The Response message
      • A Download response / A Transfer complete message (successful download)
      • A Transfer Complete message sent in a subsequent Session (apply the downloaded file)

    Open Mobile Alliance (OMA)

    The Open Mobile Alliance (OMA) is a standards organization which develops open, international technical standards for the mobile phone industry. It’s a nonprofit Non-governmental organization(NGO), a forum for industry stakeholders to agree on common specifications for products and services.
    Formation :  June 2002 (19 years ago.) Merger of IPSO Alliance : March 2018 (3 years ago)
    • Standard specifications:
      • OMA SyncML Common Specifications V1.1.2
      • OMA Device Management (OMA DM) specification for mobile device management using  SyncML V1.1.2 The OMA DM (based on SyncML DM) specifications define the protocols and mechanisms for how configuration parameters can be delivered to an OMA client from a SyncML DM server that is part of the overall architecture 
      • Device Management Conformance Requirements, Version 1.1.2. file name: OMA-SyncML-DMConReqs-V1_1_2-20030613-A.pdf

    Reference : 
    A Firmware Update Architecture for Internet of Things https://tools.ietf.org/id/draft-ietf-suit-architecture-08.html
    Applicable Protocol for Updating Firmware of Automotive HVAC Electronic Control Units (ECUs) Over the Air https://ieeexplore.ieee.org/document/8726718
    Research of the systems for Firmware Over The Air (FOTA) and Wireless Diagnostic in the new vehicles https://ieeexplore.ieee.org/document/9238345/
    Secure FOTA Object for IoT https://ieeexplore.ieee.org/document/8110218
    Research Firmware Update Over the Air from the Cloud https://ieeexplore.ieee.org/document/8549628
    OMA Specifications (Open Mobile Alliance) https://technical.openmobilealliance.org/index.html
    MT7697 API Reference
    https://www.ibm.com/docs/en/zos/2.4.0?topic=task-types-software-updates
    https://www.muutech.com/en/iot-device-management-protocols-lwm2m-oma-dm-and-tr-069/



    從入門到精通,軟體測試工程師早晚要看的50本書

    本月目標.. 

    1.《Google軟體測試之道 》
    2.《持續交付》
    3.《軟體測試的藝術 》
    4.《代碼整潔之道:程式設計師的職業素養》
    5.《軟體測試 》
    6.《測試驅動開發》
    7.《軟體測試經驗與教訓》
    8.《探索式軟體測試》
    9.《捉蟲日記》
    10.《發布!軟體的設計與部署》

    11.《移動App測試實戰》
    12.《微軟的軟體測試之道》
    13.《顛覆完美軟體:軟體測試必須知道的幾件事》
    14.《有效的單元測試》
    15.《敏捷軟體測試測試人員與敏捷團隊的實踐指南》
    16.《騰訊Android自動化測試實戰》
    17.《完美軟體對軟體測試的各種幻想》
    18.《Python Web開發:測試驅動方法》
    19.《測試驅動開發的藝術》
    20.《軟體測試工程師面試指導》
    21.《自動化測試最佳實踐來自全球的經典自動化測試案例解析》
    22.《Cucumber:行為驅動開發指南》
    23.《Web安全測試 》
    24.《大話移動APP測試:Android與 iOS應用測試指南》
    25.《iOS測試指南》
    26.《全程軟體測試(第2版》
    27.《JUnit實戰》
    28.《xUnit測試模式》
    29.《測試驅動的面向對象軟體開發》
    30.《Java測試新技術TestNG和高級概念》
    31.《測試之美》
    32.《測試架構師修煉之道》
    33.《.NET軟體測試自動化之道》
    34.《 軟體測試之魂》
    35.《模糊測試強制性安全漏洞發掘》
    36.《 單元測試的藝術(第2版)》
    37.《 軟體測試技術經典教程》
    38.《有效軟體測試》
    39.《計算機軟體測試》
    40.《軟體測試基礎教程》
    41.《 Junit in Action 中文版》
    42.《遊戲測試精通 》
    43.《 精通軟體性能測試與LoadRunner實戰》
    44.《完美測試 》
    45.《用例分析技術》
    46.《軟體測試自動化》
    47.《軟體測試面試突擊》
    48.《應用程式性能測試的藝術》
    49.《 軟體測試與持續質量改進》
    50.《Perl Testing程序高手秘笈》


    原文網址:https://read01.com/L2BJz4L.html

    List Of Best Test Management Tools In 2021

    The comparison and review of the most popular test management platforms available in the market:

    1. Zephyr Scale
    2. PractiTest
    3. Zephyr Squad
    4. TestCollab
    5. Requirements and Test Management for Jira (RTM)
    6. XQual
    7. Xray – Cutting Edge Test Management
    8. TestRail
    9. Kualitee
    10. TestFLO for JIRA
    11. SPIRATEST by Inflectra
    12. Qase
    13. Testpad
    14. JunoOne
    15. TestMonitor
    16. Klaros-Testmanagement
    17. QACoverage
    18. JIRA
    reference: 
    https://www.softwaretestinghelp.com/15-best-test-management-tools-for-software-testers/

    Comparison between Zephyr & Xray
    reference:
    https://community.atlassian.com/t5/Jira-articles/Comparison-between-Zephyr-amp-Xray/ba-p/1504907

    Testing Beyond the 5 C’s of IoT -Keysight

    5C's +1 Test Approach ensures your devices thrive

    They need to address the following 5 C challenges across the IoT device lifecycle: 

    • Connectivity ensures that your IoT devices connect to other IoT devices, the cloud, and the world around them.
    • Continuity requires that your IoT devices have an extended battery life to do their jobs.
    • Compliance requires that your IoT devices adhere to global regulations.
    • Coexistence ensures that your IoT devices work harmoniously in crowded IoT environments.
    • Cybersecurity safeguards your data from cyber security threats.

    Build Customer Experience-Centered IoT Devices

    The first five C’s — connectivity, continuity, compliance, coexistence, and cybersecurity — are all important.

    another C, customer experience, puts your device ahead of the competition.

    • Customer experience testing ensures quality products that delight and retain your users.

    Reference:
    https://blogs.keysight.com/blogs/inds.entry.html/2021/09/20/testing_beyond_the5csofiot-19XA.html

    這個人講的東西我全都做了…唉…

    這個人講的東西我全都做了…唉…

    https://ken641201.inin.news/2020/12/23/wifi%E4%B8%8D%E6%98%8E%E7%99%BD%EF%BC%9F%E7%9C%8B%E9%80%99%E7%AF%87%E5%B0%B1%E5%A4%A0%E7%9E%AD/

    Wi-Fi 6 筆記

    Aruba 曾實際測量過公司內之 Wi-Fi 通訊品質,發現辦公室內的數據傳輸是以 256 byte 的封包大小為主。如果要傳輸這樣的小封包,採用 OFDM 的方式,並不符合效率,因為 OFDM 必須要先等前面的封包傳輸完成才行,但 Wi-Fi 6 使用的 OFMDA 就可以依照必要的需求分配頻寬,所以能夠大幅減少用戶等待的時間。

    Wi-Fi 6 的導入還有另一項重點,即有線 LAN 傳輸速度亦須增加,最少須增加數gigabit 以上。此時可利用既有的 CAT 5e/6 的 2.5GbE(Gigabit Ethernet),或是升級為 5GbE 的 Multi-Gigabit 乙太網路(IEEE802.3bz)。雖然亦可將有線 LAN 升級至 10GbE,但 10GbE 用在 Wi-Fi 6 上其實是過高的規格,且需要把線路改為CAT 6a 以上如 Aruba 或 Cisco Systems 等採用提供 Multi-Gigabit 的交換器之作法較實際。

    Fall Detector series

    ## Apple Watch Fall down series

    showing it detected 12 out of 15 actual falls.

    ##A Low-Power Fall Detector Balancing Sensitivity and False Alarm Rate - IEEE

    The Human Trials.
    In the simulated fall (SF) trial, twenty young healthy volunteers (sixteen males and four females, height: 170.3 ± 8.3 cm, weight: 63.9 ± 11.0 kg, age: 27.6 ± 1.8 years) were recruited from staff and students at UNSW. The volunteers were asked to fall onto a foam mattress for safety, and the instructions of these simulated falls were designed based on real-world falls observed by a camera [16]. Before each fall, the
    volunteers stood still on a platform at the same height as a foam mattress, and after each fall the volunteers lay still on the mattress for twenty seconds. Each simulated fall was repeated twice, totaling 200 fall events. A detailed breakdown of the protocol of simulated falls tested is shown in Table I.

    In the free-living (FL) trial, ten young healthy volunteers (six males and four females, height: 167.8 ± 7.6 cm, weight: 62.6 ± 11.6 kg, age: 27.6 ± 1.5 years) were asked to wear the NEON-SD continuously for a day without any specific instructions. The volunteer could take the NEON-SD off if they felt uncomfortable while sleeping. It was verified that healthy young volunteers did not fall in the duration of the FL trial.

    ## Power-Efficient Interrupt-Driven Algorithms for Fall Detection and Classification of Activities of Daily Living - IEEE

    A total number of 83 false positives were registered. This means that, on average, each WD had a false positive rate of 83/(24 × 3) ≈ 1.153 times per day.

    Simulated Falls: 
    As it is difficult to obtain real-world falls, tests of the proposed fall detection algorithm were simulated by four young subjects. Each of them wore a WD on his/her left wrist and performed 4 types of activities:
    (1) walking, (2) walking upstairs, (3) walking downstairs, (4) walking some distance away, sitting down in a chair beside a desk and doing things such as writing, picking up and putting down random objects. Each person performed each activity five times for two minutes each time. Then activities (1), (2), (3) were performed again for five times, but each with
    a fall in the middle. Test results are shown in Table I. It is observed that during continuous walking, falls were never be falsely detected as INACTIVITY interrupt did not have a chance to assert. While sitting down, wrists occasionally hit the desk with high impact, a false positive fall
    will be accidentally triggered. It can also be observed that young subjects easily created false positives (3/20). In contrast, seniors in their real daily lives only creates 1.153 times per day as evaluated.


    References: 
    IEEE SENSORS JOURNAL, VOL. 15, NO. 3, MARCH 2015
    Power-Efficient Interrupt-Driven Algorithms for Fall Detection and Classification of Activities of Daily Living
    IEEE Journal of Biomedical and Health Informatics
    A Low-Power Fall Detector Balancing Sensitivity and False Alarm Rate